I'll take a look later today to see how this impacts the Windows and GNOME themes.
GC On Sun, Sep 18, 2011 at 10:39 AM, Fred Kiefer <[email protected]> wrote: > I played around with that code and have it basically working now. This > version has about the functionality that our current in-window menu support > in gui provides, but it is very likely to break the existing themes that > offer extended support for this. > > I could now either put that code into a branch where nobody would be using > it. Or commit it to gui trunk and have other fix the remaining issues with > that code. These are mainly in the tracking code, that has become so > complicated that I wont dare to touch it. There we sometimes use the menu > representation of the main menu, and this of course wont be correct any > more. The actual used menu view wont be accessible from the main menu any > more, as each window will use its own one. > > If this is fixed and all the themes work again, then the next step may be > done. in my opinion this would be the introduction of a new class > GSMenuRepresentation that stands between the NSMenu and the NSMenuView. The > main purpose of that class would be to hold the window we currently store in > the NSMenu. Instead of the two windows NSMenu would have two > GSMenuRepresentations one for the standard and one for the transient > display. That class would delegate most of the operations on to the menu > view. The important point here is not to use this class where it isn't > needed. We should try to avoid any internal knowledge of the menu > representation in gui (and even more in user code). That way we make it a > lot easier for themes to replace the actual menu display implementation. > > > > On 14.09.2011 21:48, Gregory Casamento wrote: >> >> This change is certainly wrong. Fred's assessment is correct. >> Treating the Windows menu in a special manner is not going to fix the >> overall issue. >> >> I recall a discussion some weeks or months ago about this very subject >> in which we all agreed that decoupling NSMenu and NSMenuView is the >> correct solution. >> >> I have been working on the buildtool and other things so that we can >> build Xcode projects and can get rid of/deprecate pbxbuild so my >> attention has been taken from this, but this should get back on my >> radar within the next few weeks. >> >> In-window menus on Windows are working quite well. I believe the >> reason that this approach works is that it does what fred is >> describing. When I wrote the code for the Windows theme that does >> this it uses NSMenu as a model and builds the necessary Windows Menu >> structures from it. I expect when following the same paradigm for >> adding them to the Gtk/GNOME theme (i.e. building the GtkMenu by >> recursing the NSMenu structure) it will work equally well there too. >> Both the windows and the gnome theme use the callback [GSTheme >> setMenu:forWindow:] in the theming framework. >> >> The callback in GSTheme is, I believe, correctly placed. It's the >> current in-window menus implemented in GNUstep which are the problem. >> The implementation for this has never been perfect. At first the >> menus were being added only to the currently active window and removed >> when the window lost key and added to the new key window. This was >> unacceptable. When I added code to make the menu appear in all key >> windows, this was something of a kludge to begin with. So the state >> of the current code for in-window menus is partly my fault. >> >> That being said, I believe that no further changes should be made to >> the code for GNUstep rendered in-window menus until we have time to >> start working on the correct solution as suggested by Fred. >> >> Later, GC >> >> On Tue, Sep 13, 2011 at 4:36 AM, Fred Kiefer<[email protected]> wrote: >>> >>> On 13.09.2011 03:45, � wrote: >>>> >>>> Author: espectador >>>> Date: Tue Sep 13 03:45:13 2011 >>>> New Revision: 33837 >>>> >>>> URL: http://svn.gna.org/viewcvs/gnustep?rev=33837&view=rev >>>> Log: >>>> Improvements to menu in window >>>> >>>> Modified: >>>> libs/gui/trunk/ChangeLog >>>> libs/gui/trunk/Source/GSThemeMenu.m >>> >>> This patch looks like just another one in the long list of horrible >>> changes >>> to support in-window menus. Not that this patch helps in any way, it just >>> keeps the impression that in-window menus are working up a bit more. If I >>> understand it correctly, this patch is trying to replace the Windows sub >>> menu whenever the menu gets set again on a window. What is the point of >>> this? All the other menu and sub menu entries might just change as much >>> as >>> the Windows sub menu. Why add any special handling here? If you are >>> really >>> interested in in-window menus, which I am not, then you should start to >>> look >>> for real solutions, which would be the decoupling of NSMenu and >>> NSMenuView, >>> and not just add another layer of hacks to the code. >>> >>> Why can't the people interested in in-window menus form a special >>> interest >>> group. Discuss possible solutions and then come back with a proper >>> proposal >>> to implement this, instead of making random changes to the gui classes? >>> >>> Sorry, I know this isn't a polite way of putting this, but the in-window >>> menu code has annoyed me a lot already and I really regret adding that >>> possibility at all into gui. >>> As I stated before, I am even willing to help to develop a concept here. >>> What I don't want to do is maintain all these hacks in gui. > > -- Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc. yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
