This is an interesting idea, but I see two problems.

1. the scope you are working with is actually inherited from uiLayout, so you'll be changing all splitbars, right?
2. you are initializing scope.hideprev and scope.hideafer using !== undefined, which will lead to unintuitive behaviour, because falsy values will set it to true.

• For each uiLayoutContainer, it generate a separate splitterbar with its parent uiLayoutContainer scope. So hideprev and hideafter should have the same scope with its parent uiLayoutContainer but not share a common scope with other.

var splitbar = angular.element('<div ui-splitbar><a ng-show="!hideprev"><span class="ui-splitbar-icon"></span></a>'
                                            + '<a ng-show="!hideafter"><span class="ui-splitbar-icon"></span></a></div>');

element.after(splitbar);
$compile(splitbar)(scope);

• I am not sure, because at beginning I thought ng-show="hideprev" with a false value is also weird.I can change it or any better suggestion?

Ah sorry, you are right. My bad.

I think I see a glitch, though. I think that hideprev won't always work, because the splitbar is compiled with the scope of the previous container. That means that if you have 3 containers, hideprev in the second hides the prevButton of the following splitbar and hideprev in the third container does nothing. That seems confusing to me.
Your proposal basically allows to create something like accordion with pinned panes and I think that makes sense. Obviously, you find it useful!
You are right that the attribute names are little confusing. You are setting up a container and suddenly you are asked to decide if you want to hide something "prev" or "after"... Since the splitbar is using the previous container's scope, there could be a directive or attribute for setting up the splitbar, like splitbar="{hidePrevButton: false, hideAfterButton: true}" or something like that. That would make it clearer. And then you could ng-hide="hidePrevButton". Or maybe shorter splitbar="{prevButton: false, nextButton: true"} with ng-show="afterButton".

Actually, why is if(0 < index && !ctrl.hasSplitbarBefore(scope.container)) even there? When does this happen? After container is removed? Have to look at it later with a clear head.

A side note: I was actually thinking about something like your proposal myself. In #154 I've introduced a notion of a "central" container, which doesn't implement the hiding, but it's motivated by what other layout libraries, like jquery ui-layout, have. A central container which always takes up the remaining space (and can never be closed - this I have not implemented yet, I simply hide the splitbar). That's the common theme we see around (the editor is central and around it a file tree, symbol tree, toolbar, statusbar, etc. all of which can be closed, except for the editor). I'm planning to extend the "central" container by disabling the inward toggles around it.

Sorry I haven't been keeping up with things lately, should be back on track now. @petrsimon thanks for doing some review!

@zsp1987 This looks useful and I'd love to bring it in if we can get over the bumps mentioned by @petrsimon .

@petrsimon Thank you for the advices. Add splitbar attribute with options to uiLayoutContainer is much clear. Have implemented this.

if(0 < index && !ctrl.hasSplitbarBefore(scope.container)) I guess now. Each uiSplitbar is immediate follows a uiLayoutContianer. So the splitbar indeed does not function well for the last one.

@zsp1987 I like how this is coming together. Can you add some documentation about your new feature to the readme?