bugGNUstep - Bugs: bug #24601, NSToolbar: [NSWindow contentView]...

Group
 
 

bug #24601: NSToolbar: [NSWindow contentView] should not return a view which contains the toolbar in it once the toolbar is opened.

Submitter:  Gregory John Casamento <gcasa>
Submitted:  Sat 18 Oct 2008 10:55:49 PM UTC
   
 
Category:  Gui/AppKit Severity:  4 - Important
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  FredKiefer
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 18 Jun 2010 11:18:59 AM UTC, comment #8: 

A lot of further cleanup was done in NSToolbar. Can this bug considered to have been fixed?

Riccardo Mottola <rmottola>
Group Member
Sun 11 Jan 2009 10:36:48 PM UTC, comment #7: 

I think that the original problem should be resolved by he current code. There is still plenty of room for further changes. For example I really would like to see more generic code in the decoration view that would allow for moving the menu there as well. But all of that would be change requests.

Fred Kiefer <FredKiefer>
Group Member
Mon 01 Dec 2008 09:34:46 PM UTC, comment #6: 

At the time, I wrote the toolbar code. I checked Mac OS X implementation which does what you suggest. I didn't implement it that way at this time, because not everybody agreed on having some special toolbar code inside NSWindow. iirc GSWindowDecorationView wasn't also yet part of gnustep-gui.

From what I recall, in GNUstep there is an NSWindow ivar named _wv which represents the window view. On Mac OS X, this window view contains the content view, the widget views and the toolbar view if a toolbar is visible. So the toolbar view can either be a subview of _wv (as Mac OS X does it) or belong to the GSWindowDecorationView. I think this last option you propose is cleaner.

Quentin Mathé <qmathe>
Group Member
Tue 21 Oct 2008 03:11:16 PM UTC, comment #5: 

Okay, this definitely seems to be the right way to go then.

Gregory John Casamento <gcasa>
Group administrator
Tue 21 Oct 2008 02:16:11 PM UTC, comment #4: 

The whole idea of having a separate view for decorations was to allow us to draw things outside of the window's content view ... so putting the toolbar there is completely correct (assuming that the toolbar on macos-x is not a subview of the content view).
The decoration view should always exist (irrespecrtive of whether X draws window decorations).  It's just that, when x draws decorations it is normally the same size as the content view.  Adding toolbar support would just mean that the code for converting between content view coordinates and window coordinates would need to be adjusted to allow for the content view being a bit smaller.

Richard Frith-Macdonald <CaS>
Group Member
Tue 21 Oct 2008 02:01:48 PM UTC, comment #3: 

The only thing which concerns me about moving it to the decorations view is whether or not it would get drawn when GSX11HandlesWindowDecorations is set to YES.

Gregory John Casamento <gcasa>
Group administrator
Mon 20 Oct 2008 01:30:25 PM UTC, comment #2: 

I just implemented the first half of my proposal. What is left to do is to move the toolbar handling into the decoration view.

Fred Kiefer <FredKiefer>
Group Member
Sun 19 Oct 2008 10:01:23 PM UTC, comment #1: 

Just some idea, would it be a better solution to move the handling of the toolbar into the GSWindowDecorationView?
That way the content view of the window would be just that and everything else that also is displayed in the same window gets managed by the decoration view. This could include toolbars, menus, actual window decoration and whatever else we come up with later.

For that to work we will first need to delegate all the content to frame computation of a window to its actuall decoration view (methods like contentRectForFrameRect: which currently go to the NSWindow class first). This is needed as not all windows will have a toolbar or menu, so the computation will depend on the existince of these extensions. This should be fairly easy to change on NSWindow and GSWindowDecorationView.

Next we will need move the toolbar view handling to GSWindowDecorationView and adjust the frame computations there. This could be a bit more work and will require some understanding of the current toolbar code.

Fred Kiefer <FredKiefer>
Group Member
Sat 18 Oct 2008 10:55:49 PM UTC, original submission:  

See the subject.

The issue here is that the window's content view then becomes the original view + the toolbar's view.   The toolbar view is not supposed to be part of the window, but yet it is... we have a special function to get JUST the contentView which is called contentViewWithoutToolbar.

This is what is currently causing the GNUmail problem earlier reported by Riccardo.   Since GNUmail adds and moves views around in the window it is directly modifying the contentView of the window, which should be acceptable... but in this case it's adding additional views into the contentview which contains the toolbar view which, according to code in the contentViewWithoutToolbar should only contain 2 views, the original contentView and the toolbarView.

Thanks, GC

Gregory John Casamento <gcasa>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by rmottola (Posted a comment)
  • -email is unavailable- added by qmathe (Posted a comment)
  • -email is unavailable- added by CaS (Posted a comment)
  • -email is unavailable- added by FredKiefer (Posted a comment)
  • -email is unavailable- added by gcasa (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-10-03 FredKiefer StatusReady For Test Fixed
        Assigned toNone FredKiefer
        Open/ClosedIn Test Closed
    2009-01-11 FredKiefer StatusIn Progress Ready For Test
        Open/ClosedOpen In Test
    2008-12-15 FredKiefer Dependencies- bugs #23652 is dependent
    2008-10-20 FredKiefer StatusNone In Progress

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code