Tue 06 Jan 2009 08:10:23 AM UTC, comment #10:
I close this bug report, as we are back to the old behaviour now. There is still plenty of romm for improvements here. First we should not resize the content view twice, instead we could improve the resizing in the decoration view.
We also need a more general mechanism to add new subviews to the decoration view. What about a subclass of NSView that knows about orientation (the border of the window the subview will be belong to) and priority (to allow multiple subviews on the same border, eg menu and toolbar at the top). That subclass will need a layout method that gets the current (or better the remaining) window content size and will return the size needed for the specific view. This will require a lot of interesting code on decoration view and I currently don't have the time for it :-)
|
Sat 03 Jan 2009 07:51:57 PM UTC, comment #9:
I updated and tested the changes you made this morning to make the window resize. They appear to work better now.
Thanks for the great work so far! :)
|
Sat 03 Jan 2009 04:36:19 PM UTC, comment #8:
You did beat me by quarter of an hour, I just did the same test (with the same problem) and wanted to report them :-(
I also checked the new code in SVN on KDE and it almost behave the same (apart from some very, very strange window movements when the window is close to the top screen border), but with other window managers we might have different results.
The method constrainFrameRect:toScreen: on NSWindow, that gets called inside of setFrame:display:, should do the trick in most cases. At least for resizable windows, we may need additional code for non-resizable ones.
|
Sat 03 Jan 2009 04:16:18 PM UTC, comment #7:
Greg's project wouldn't build on my machine until I hacked the project file to remove the pch stuff. I attach the hacked version, to which I also added a button to toggle the toolbar, and fixed the window size (you can easily unfix the size again in interface builder). What I found ...
1. setting the window to a fixed size has no effect on the toolbar behavior, the window still gets resized when the toolbar is added/removed.
2. adding/removing the toolbar usually causes a window resize with the top of the window remaining fixed and the window growing downwards
3. If the window is near the bottom of the screen, adding a toolbar causes it to grow and be repositioned so that the entire window is still on screen.
4. if adding a toolbar to it would make the window larger than the full height of the screen, the content view gets resized instead of the window being resized.
(file #17204)
|
Sat 03 Jan 2009 03:25:55 PM UTC, comment #6:
I changed the code in GSWindowDecorationView back to resize the window. (Keeping the top of the window at the same spot)
While doing so, I fixed a bug that caused the toolbar view to overlap the content view. So things should now be almost as before.
What is still different is that the content view now gets resized twice, one time directly and the other when the window frame is resized. There is no warranty that this will end up with the same layout of sub views as before. An easy work around here is to directly adopt the size of the GSWindowDecorationView when adding the toolbar and check for that size, when setting the window frame. When the size already fits no resizing of the content view is needed.
My next step will now be to run Greg's test application on Apple and see, what I can learn from it.
|
Sat 03 Jan 2009 01:29:51 PM UTC, comment #5:
Posted the test program. Hope this helps.
I'm not sure if the behavior ever changes. At least, I haven't seen it change.
Please take a look at the attached program.
Thanks, GC
|
Sat 03 Jan 2009 10:10:34 AM UTC, comment #4:
Yes, we need a test app to demonstrate the 'correct' behavior when adding/removing a toolbar. This behavior may vary depending on where the window is on the screen (eg if the title bar would be moved off screen when the window is made larger by adding a toolbar), the window style (eg a a window with a titlebar and/or borders might behave differently from one without), and programatic settings like whether the window is resizable or not and whether it has resize increments set.
|
Sat 03 Jan 2009 09:48:53 AM UTC, comment #3:
The change that the window is no longer resized when a toolbar is added was done on purpose. I even asked on the public mailing list before doing so.
There are arguments for both behaviours. When the window expands automatically to make room for the toolbar, no special behaviour is needed for the contents view. On the other hand this leads to flickering windows that grow and shrink.
I tested with the Bean application on OS X and there the window stays the same size when the toolbar is added.
Perhaps we can come up with a mixed implementation where both behaviours are possible, but how to decide which window should be treated in what way? Perhaps we could say that windows that have a fixed size (not allowed to be resized) should grow when a toolbar is added, whereas resizable windows should have the toolbar added internally. This may seem the wrong way round, but when a window allows resizing, it should handle the internal addition of a toolbar.
PS: Could you please re-add your test application, I could not find it.
|
Sat 03 Jan 2009 03:47:23 AM UTC, comment #2:
(gdb) continue
2009-01-02 22:41:10.791 ToolbarTest[24347:813] BEFORE TOOLBAR: window={{335, 390}, {480, 382}}, view={{0, 0}, {480, 360}}
(gdb) continue
2009-01-02 22:41:11.795 ToolbarTest[24347:813] AFTER TOOLBAR: window={{335, 334}, {480, 438}}, view={{0, 0}, {480, 360}}
It seems apparent that the size of the window does change when the toolbar is added.
I have added the test application I wrote to this bug as an attachment, so that you can test it as well, but the result seems fairly clear... the window size changes, the content view does not.
GC
|
Sat 03 Jan 2009 03:05:27 AM UTC, comment #1:
The window should be taller and also the text portion of the image appears to be cutting into the window content.
|
Sat 03 Jan 2009 03:04:19 AM UTC, original submission:
Gorm doesn't do anything special with the toolbar.
Please see the attatchment for what's happening.
GC
|