Thanks for posting this video Tobias!  This way I can explain WHAT is
going on and WHY, so that hopefully leave you with a greater
understanding and appreciation for it.

>> But it resizes all the time
>>
>> No, it does NOT do that.  If it did, I wouldn't use it myself.
>
> Well it does, watch:  http://netshed.de/split.mov
> It moves the splitter everytime I select some different pane.

Of course it does!  How else could it do its job to minimize
whitespace and maximize exposed information?

> At sec 3, the [instance] button becomes illegible.

Drag the bar yourself, the same thing happens.  It has _nothing_ at
all to do with Smart-Splitters and simply a matter of the
LayoutFrame's limits needing to be fixed  (can't remember exactly
which attribute..the one which causes the halt in the splitter when
you try to drag it too far -- SS is only restricted by the same).

> At sec 19, the protocol pane becomes too narrow…

All four panes are balanced w.r.t. the number of occluded characters.
Why do you say only the protocol pane is too narrow?  They're all too
narrow.  What do you expect the smart-splitters to do in this
situation?

> At sec 25, the right splitter collapsed completely.

Again, Smart-Splitters does not cause this bug, it simply exposed it.
Drag the splitter manually yourself that way, and you'll see it
collapses.  We need to fix the limits specified in the LayoutFrame.

> At sec 27, the code pane shrinks.

To expose more list without truncating anything in the code pane.
That's the whole purpose of the feature.  Had you waited a bit longer
before your next click it would have shrunk to an exact-fit in the
code-pane.

> At sec 31, the splitter does not know whether to turn left or right.

Yes it does.  When the protocol pane was empty, it knew to go right to
expose more in the left panes.  But you immediately selected
StringSocket, causing the contents of the protocol pane to be filled,
which causes Smart-Splitter to want to balance the number of occluded
characters on either side.

It did exactly what it's supposed to.

> At sec 49, selecting the method leads to its name in the message pane being illegible.

The video ended before it had a chance to readjust yet again to your
frenetic clicking around.  :)

---------

So, it might also help to understand the algorithm is entirely
localized within each SplitterMorph.  Each splitter morph looks only
at the panes either side of it and makes a 1 or 2-pixel adjustment,
+/- toward the more optimal, in its #step method.

So in browsers that stack panes greater than 3-wide, there will be
some interactions between the adjustments.  This is analagous to the
animated morphs of an Etoys application responding to other animated
Morphs in their surroundings.  Smart-splitters already greatly softens
this with internal stepTime delays, but apparently not enough for your
taste.  :-(

I'm doubtful such a localized algorithm will ever be able to meet your
expectations.  Which is unfortunate, because I'd be sorry if you
missed out on something quite good simply because it's not quite
perfect.  Hopefully it can be tweaked it a little closer to perfection
in 4.6.  I already know a couple of things I want to improve.

Its worth noting, you chose the particular browser (besides the
debugger) that is least-flattering for this feature because it stacks
4-panes wide, which means there will be some extra interactions
between the optimizations made in the adjacent panes.  Using a browser
_designed_ for browsing the class-model (e.g. Hierarchy browsers),
instead of the package-model, only stacks 3 panes wide, so no
interactions!

HTH!