[haiku-development] Re: Differences in behavior R5 - Haiku
- From: "Stephan Assmus" <superstippi@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 07 Sep 2008 18:10:59 +0200
-------- Original-Nachricht --------
> Datum: Sun, 07 Sep 2008 17:14:51 +0200
> Von: julun <host.haiku@xxxxxx>
> An: haiku-development@xxxxxxxxxxxxx
> Betreff: [haiku-development] Differences in behavior R5 - Haiku
> Hi,
>
> while helping out stargater with ArtPaint, I noticed at least two
> differences in behavior between R5 and Haiku.
>
> First one belongs to BMenuField, while created in a BView not attached
> to a window, calling ResizeToPreferred on it will not modify the
> BMenuField at all on R5, whereas it does resize it on Haiku. This goes
> even so far, that still in the views AttachedToWindow the BMenuField
> has it's initial size, but in the views AllAttached() it has magically
> resized at least it's height. (BeOS R5)
>
> Haiku's behavior therefor breaks the whole layout code in ArtPaint.
> Sure it's easy to change for apps with source available, but other
> apps might depend on it as well.
>
> I also noticed that the code that works on R5, gives a 'broken'
> BMenuField on Haiku (it misses half of the menu, need to call
> SetDivider() on it to show properly).
>
>
> The second on belongs to window resizing, while a programmatically
> resize during a user resize is a valid operation on R5, we prevent
> this in ServerWindow.cpp line 892 + following.
>
> ArtPaint uses this to resize the tool window in a special way, it
> builds up a matrix view and resizes the window accordingly in its
> width. Note the window is created with B_NOT_H_RESIZABLE, thus not
> allowing the user to widen it. This breaks proper 'resizing' the window.
>
>
> So my question is what to do here, stay compatible with R5 behavior?
> While i don't like what BMenuField does on R5, I see at least no need
> to prevent the programmatically resize durign a user resize. I
> disabled the check and did not notice any bad behavior so far.
>
>
> Should i file bug reports about this? And when, which release should i
> target, alpha or R1?
To be honest, I have had quite a few troubles with BMenuField and their
unexpected behavior in BeOS. So if possible, I'd like to find a good balance
between sane behavior and being as much compatible with BeOS without loosing
the sane behavior. That ResizeToPreferred() does nothing unless the BMenuField
is attached is quite annoying on BeOS for example, and I would not like to
replicate it.
As for the programmatical resize during resizing, the only problem I could
imagine is that resizing starts to behave weird when the user reaches a size
limit for the window in one direction, moves the mouse past the limit (window
size stays fixed) and then moves the mouse in the other direction again. The
correct (and current) behavior is that the relative offset of the mouse to the
resize corner of the window stays fixed. It may change when a limit is reached,
but should return to the previous offset when the resize drag enters the limits
again. If that works, please go ahead and commit your patch, no need to file a
but report. As for filing bugs under Alpha or R1, only use the Alpha target for
bugs that would seriously hinder Haiku as a development platform.
Best regards,
-Stephan
Other related posts:
