[haiku-development] Differences in behavior R5 - Haiku
- From: julun <host.haiku@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 07 Sep 2008 17:14:51 +0200
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?
Many thanks,
Karsten
Other related posts:
