[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSSplitView patch
From: |
Nicola Pero |
Subject: |
Re: NSSplitView patch |
Date: |
Mon, 17 Feb 2003 01:09:49 +0000 (GMT) |
> > > > Thanks Enrico, I applied your patch ... with some small changes: the
> > > > correct code was already there, and had been commented out for unknown
> > > > reasons!
> > >
> > > Ok, now it works. But I'd added the second NSPoint "costrP", to permit to
> > > the divider to draw following the mouse movements; only on mouseUp the
> > > size of the subviews is set.
> >
> > Thanks - yes - I think this is what happens at the moment - the `ghost'
> > divider follows the mouse movements; on mouseUp the position of the
> > `ghost' divider becomes the position of the actual `real' divider, and the
> > size of the subviews is set to that.
>
> In fact, in the Apple documentation, it seems that, if the delegate
> implements:
>
> -splitView:constrainSplitPosition:ofSubviewAt:
>
> the divider is drawn at the costrained position. Actually my openstep is
> broken and I can't verify, but I remember that, on openstep, the divider
> follows the mouse anyway, being costrained only on mouseUp
Thanks - Ok - if such is the difference, I think the Apple/gnustep
behaviour is definitely better. :-)
If the divider is constrained, there should be visual feedback that it is
constrained, so that when you release the mouse button, you know exactly
where the divider will move ... without unexpected behaviours and
surprises caused by constrains being applied only after you release the
mouse button.
As far as I can see, on Apple Mac OS X there is complete visual feedback -
even better than on gnustep because you actually move the `real' divider
directly (which is of course constrained directly) ... this is less
efficient, but much nicer because the UI metaphor is more strongly
represented by moving the divider directly.