Re: Menu Proposal
On 30 Nov 2006, at 05:17, Christopher Armstrong wrote: Richard Frith-Macdonald wrote: I have been assuming that we could support per-window menus by dynamically moving the menu view from window to window as the menu in each window needs to be drawn (since this is what is already done for transient menus), but having multiple menu views may be better. In terms of the event handling system, how would such a mechanism work? There still needs to be a "view" in each window of some sort, so are you proposing some sort of "dummy" view in each window where the real NSMenuView is ripped out each time an update is triggered and temporarily pasted into the window. I don't think I understand what you mean. Not really proposing that (though obviously some placeholder view class would be needed which would replace itsself with the menu representation when necessary) ... hopefully it's clear below that I think multiple menu representation views are *probably* the best approach, but that other options are possible and should be examined. Not necessarily ... the current implementation already uses the same view in two different windows (for transient menu support) ... but it's probably better to have multiple views (in the current implementation the rectangle the view is drawn in is the same in both windows, but that would not generally be the case). I would suggest carefully examining the option of extending the single-view-moved-between windows approach before deciding that multiple views are really necessary/best. What was your ideas as to how a single view is moved between windows. I can't picture how this would work. I forget how it's done in NSMenu ... probably just calls -addSubview: to place the menu view inside the content view of the window. In general, the controlling code would need to call -addSubview: and then -setFrame: to resize the subview to fit a new rectangle, and the window representation view would need to override -setFrame: to recalculate layout according to the window and frame it is in. This could be controlled by the windows decoration view ... ie when the decoration view is told to redraw any part of itsself, it draws window decorations and when it gets to the point where it wants to draw the menu, it adds the menu view from the main menu and asks it to draw itsself, then it puts the menu view back in the main menu. However, having multiple menu views, each permanently in a separate window, may be a cleaner/simpler solution. I haven't done much work on menus for a long time, so i don't currently have a good enough grasp of the menu code to know what the detailed technical advantages/ disadvantages of the two approaches are. Conceptually, multiple views seems clearer, but I guess there must have been a reason for the current implementation using a single view shared between two windows. Reading this email gave me a different idea. Instead of trying to develop a protocol for an intermediary layer, perhaps we could extend allow NSMenuView to associate a NSMenu with it, without actually causing the NSMenu to "own" it. In addition, NSMenu should allow the option of turning off its display of an NSMenuPanel with the NSMenuView in it. The "extra" NSMenuViews should probably rely on NSMenu notifications so they can update themselves. We could probably rely on NSMenu to continue handling transient menus in this instance as well. That sounds good to me. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Menu Proposal
Richard Frith-Macdonald wrote: On 29 Nov 2006, at 12:19, Christopher Armstrong wrote: I have been looking at the code in NSMenu, and at the moment NSMenu is reponsible for creating an NSMenuView and the NSPanel object that it is housed in. As a result, this code makes the assumption that a menu is always in a separate window, and that there is only one displayed representation of a menu. It also assumes that the menu representation is drawn in the same process with an NSMenuView object. I have been assuming that we could support per-window menus by dynamically moving the menu view from window to window as the menu in each window needs to be drawn (since this is what is already done for transient menus), but having multiple menu views may be better. In terms of the event handling system, how would such a mechanism work? There still needs to be a "view" in each window of some sort, so are you proposing some sort of "dummy" view in each window where the real NSMenuView is ripped out each time an update is triggered and temporarily pasted into the window. I don't think I understand what you mean. In order to support different paridigms, such as the (addmittedly broken but popular) one-menu-per-main-window on Win32/Gtk/Qt or Etoile's menu server, I believe that programmers currently need to modify NSMenu through means such as subclassing or overriding using categories. These methods are prone to breakage as they often depend on internal implementations. I am proposing that we separate the visual representation of a menu (which includes the window it is drawn in (NSMenuPanel), the view (NSMenuView) and the item cells (NSMenuItemCell)) from the abstract representation of a menu (NSMenu). I am suggesting we do this allowing people to supply an object which will receive menu update notifications (such as items being added, removed, etc.) and be responsible for coordinating the drawing of the menus and handling events. It should be different from the current use of the "NSMenuRepresentation" which assumes that the menu representation is a subclass of NSView. This "object" should implement some sort of protocol for communication between itself and NSMenu, the protocol supplying methods which inform the object of changes in the NSMenu, something like the interaction between a Model and Controller in MVC. I think the current separation, using notifications, is a pretty good start and could be extended if necessary ... but I'm not sure that it *is* necessary to go much further ... the assumption that the menu representation is a subclass of NSView appears to be OK for doing per-window menus, and in the etoile case of having a completely separate process handling the menu, it seems to me that the best solution is to replace the entire NSMenu with a proxy to that remote process. I agree, although -menuRepresentation makes the assumption that there is one and only one representation of a menu i.e. there can't be many menu views. Whilst the "multiple menu views" idea involves multiple instantiations of NSMenuView, practically they should all be displaying exactly the same thing, just with consideration for the window they are displayed in. For example, you may wish to place a menu on each of your document windows, but this breaks the current assumption that there is only one visual representation (view) of the menu. Not necessarily ... the current implementation already uses the same view in two different windows (for transient menu support) ... but it's probably better to have multiple views (in the current implementation the rectangle the view is drawn in is the same in both windows, but that would not generally be the case). I would suggest carefully examining the option of extending the single-view-moved-between windows approach before deciding that multiple views are really necessary/best. What was your ideas as to how a single view is moved between windows. I can't picture how this would work. In this case, the intermediary object would sit between NSMenu and the associated set of NSMenuViews which reside in each document window. It would be responsible for receiving update messages from the NSMenu object and forwarding them to each of the NSMenuViews. These views in turn would somehow notify the NSMenu when they are clicked/selected. Alternatively, the menu can send a notification, and all views associated with it could watch for that notification and handle it. The notification mechanism is already used to inform menu representations of changes to the items in a menu, and implicitly has the feature that multiple views can observe the same notification. The notification center is acting as the intermediary object you suggest. The use of notifications has the additional advantage that it allows other objects outside the menu/representation mechanism to track the operation of menus. For having a menu in the current process with a representation in a separat
Re: Menu Proposal
On 29 Nov 2006, at 12:19, Christopher Armstrong wrote: I have been looking at the code in NSMenu, and at the moment NSMenu is reponsible for creating an NSMenuView and the NSPanel object that it is housed in. As a result, this code makes the assumption that a menu is always in a separate window, and that there is only one displayed representation of a menu. It also assumes that the menu representation is drawn in the same process with an NSMenuView object. I have been assuming that we could support per-window menus by dynamically moving the menu view from window to window as the menu in each window needs to be drawn (since this is what is already done for transient menus), but having multiple menu views may be better. In order to support different paridigms, such as the (addmittedly broken but popular) one-menu-per-main-window on Win32/Gtk/Qt or Etoile's menu server, I believe that programmers currently need to modify NSMenu through means such as subclassing or overriding using categories. These methods are prone to breakage as they often depend on internal implementations. I am proposing that we separate the visual representation of a menu (which includes the window it is drawn in (NSMenuPanel), the view (NSMenuView) and the item cells (NSMenuItemCell)) from the abstract representation of a menu (NSMenu). I am suggesting we do this allowing people to supply an object which will receive menu update notifications (such as items being added, removed, etc.) and be responsible for coordinating the drawing of the menus and handling events. It should be different from the current use of the "NSMenuRepresentation" which assumes that the menu representation is a subclass of NSView. This "object" should implement some sort of protocol for communication between itself and NSMenu, the protocol supplying methods which inform the object of changes in the NSMenu, something like the interaction between a Model and Controller in MVC. I think the current separation, using notifications, is a pretty good start and could be extended if necessary ... but I'm not sure that it *is* necessary to go much further ... the assumption that the menu representation is a subclass of NSView appears to be OK for doing per-window menus, and in the etoile case of having a completely separate process handling the menu, it seems to me that the best solution is to replace the entire NSMenu with a proxy to that remote process. For example, you may wish to place a menu on each of your document windows, but this breaks the current assumption that there is only one visual representation (view) of the menu. Not necessarily ... the current implementation already uses the same view in two different windows (for transient menu support) ... but it's probably better to have multiple views (in the current implementation the rectangle the view is drawn in is the same in both windows, but that would not generally be the case). I would suggest carefully examining the option of extending the single-view-moved- between windows approach before deciding that multiple views are really necessary/best. In this case, the intermediary object would sit between NSMenu and the associated set of NSMenuViews which reside in each document window. It would be responsible for receiving update messages from the NSMenu object and forwarding them to each of the NSMenuViews. These views in turn would somehow notify the NSMenu when they are clicked/selected. Alternatively, the menu can send a notification, and all views associated with it could watch for that notification and handle it. The notification mechanism is already used to inform menu representations of changes to the items in a menu, and implicitly has the feature that multiple views can observe the same notification. The notification center is acting as the intermediary object you suggest. The use of notifications has the additional advantage that it allows other objects outside the menu/representation mechanism to track the operation of menus. For having a menu in the current process with a representation in a separate process a proxy to forward notifications would be simple. I think this may be a reasonably opportune time to play with the current design, as Apple have deprecated the usage of NSMenuView and NSMenuItemCell along with the -menuRepresentation property of NSMenu (according to the Cocoa docs). Before I possibly attempted to implement such a solution, I wanted to discuss it with the list as I fear this solution may be too complex where simpler solutions exist, and I know it has implications for some other areas in the AppKit (especially popup buttons). I don't wish to engage anyone in debate about the merits or disadvantages of stacked vs horizontal menus; I think this has been discussed enough on these mailing lists before. I believe we should be pragmatic and offer people a choice. Hopefully the st
Re: Menu Proposal
Fred Kiefer wrote: I like the original idea, although I currently don't see to much benefit from it. Perhaps we should have the interface for the new implementation first, before we get any new code. I do wish to devise some sort of protocol before I carry out any work. This was meant as a sort of discussion around the issue of different menuing paridigms, and a solution which I think is feasible and doesn't encourage too much breakage. I feel it is necessary as what we current have doesn't allow other menuing paridigms to be implemented as easily, such as those that place a copy of each menu in each document window. Multiple menu views or a menu view in a document window (as opposed to in NSMenuPanel) isn't supported by what we currently have. I admit that I'm not sure how flexible this proposal should be in terms of how much it allows an application writer to change the appearance of their menus. As for the second mail on NSPopUpButton I totally seem to miss the point here. What is the problem here? I have been involved in the development of NSPopUpButtonCell, so I may be blind to the fact that the code here is "hodge podge". There is some dependency on NSMenuView for NSPopUpButtons, but it is not to the extent as suggested by the second email on this topic. It is not my intention to completely discard NSMenuView, in fact, I would be looking to reuse it as much as possible. I think we have a pretty clear separation between NSMenu and NSMenuView as it is, but I was hoping to extend it a little further in order to be more flexible. Cheers Chris ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Menu Proposal
Matt Rice schrieb: > On 2006-11-29 04:19:25 -0800 Christopher Armstrong > <[EMAIL PROTECTED]> wrote: > >> Hi all >> >> I wish to make a proposal regarding NSMenu. There has been alot of >> debate about GNUstep's stacked menus in the past. It is clear that alot >> of people like GNUstep's stacked menus, but alot of people also have >> different ideas about how menus should be displayed. I want to propose >> one pragmatic solution that should make it easier to support multiple >> menuing paridigms. >> >> I have been looking at the code in NSMenu, and at the moment NSMenu is >> reponsible for creating an NSMenuView and the NSPanel object that it is >> housed in. As a result, this code makes the assumption that a menu is >> always in a separate window, and that there is only one displayed >> representation of a menu. It also assumes that the menu representation >> is drawn in the same process with an NSMenuView object. >> >> In order to support different paridigms, such as the (addmittedly broken >> but popular) one-menu-per-main-window on Win32/Gtk/Qt or Etoile's menu >> server, I believe that programmers currently need to modify NSMenu >> through means such as subclassing or overriding using categories. These >> methods are prone to breakage as they often depend on internal >> implementations. >> >> I am proposing that we separate the visual representation of a menu >> (which includes the window it is drawn in (NSMenuPanel), the view >> (NSMenuView) and the item cells (NSMenuItemCell)) from the abstract >> representation of a menu (NSMenu). I am suggesting we do this allowing >> people to supply an object which will receive menu update notifications >> (such as items being added, removed, etc.) and be responsible for >> coordinating the drawing of the menus and handling events. It should be >> different from the current use of the "NSMenuRepresentation" which >> assumes that the menu representation is a subclass of NSView. This >> "object" should implement some sort of protocol for communication >> between itself and NSMenu, the protocol supplying methods which inform >> the object of changes in the NSMenu, something like the interaction >> between a Model and Controller in MVC. >> >> For example, you may wish to place a menu on each of your document >> windows, but this breaks the current assumption that there is only one >> visual representation (view) of the menu. In this case, the intermediary >> object would sit between NSMenu and the associated set of NSMenuViews >> which reside in each document window. It would be responsible for >> receiving update messages from the NSMenu object and forwarding them to >> each of the NSMenuViews. These views in turn would somehow notify the >> NSMenu when they are clicked/selected. >> >> I think this may be a reasonably opportune time to play with the current >> design, as Apple have deprecated the usage of NSMenuView and >> NSMenuItemCell along with the -menuRepresentation property of NSMenu >> (according to the Cocoa docs). Before I possibly attempted to implement >> such a solution, I wanted to discuss it with the list as I fear this >> solution may be too complex where simpler solutions exist, and I know it >> has implications for some other areas in the AppKit (especially popup >> buttons). I don't wish to engage anyone in debate about the merits or >> disadvantages of stacked vs horizontal menus; I think this has been >> discussed enough on these mailing lists before. I believe we should be >> pragmatic and offer people a choice. >> >> It would be helpful to gain some feedback about this idea, particularly >> its feasibility. I think it is not too difficult to implement and I do >> think it is necessary if we want to be flexible in supporting different >> kinds of menu paridigms. >> >> >> Cheers >> >> Chris >> > > another thing to consider is context sensitive menus, which regardless > of main menu implementation want a vertical menu > > i for one would like to see NSPopUpButtons cleaned up, > as it is theres NSPopUpButton has a NSPopUpButtonCell has a NSMenu has a > NSMenuView has a NSMenuPanel, > there seems to be more code for pop-up buttons in the NSMenu* classes > than NSPopUpButton* > (seems like it'd be cleaner to have just a window with a matrix in > NSPopUpButtonCell).. > > also it seems like this class has been updated sequentially to conform > to apples NSMenu implementation of the day > and its sort of a hodge podge of characteristics from all the different > NSMenu implementations > > so i'm basically indifferent twords support of different menu paridigms, > i definately think NSMenu* needs an audit > I like the original idea, although I currently don't see to much benefit from it. Perhaps we should have the interface for the new implementation first, before we get any new code. As for the second mail on NSPopUpButton I totally seem to miss the point here. What is the problem here? I have been involved in the development of NSPopUpButtonCel
Re: Menu Proposal
On 2006-11-29 04:19:25 -0800 Christopher Armstrong <[EMAIL PROTECTED]> wrote: Hi all I wish to make a proposal regarding NSMenu. There has been alot of debate about GNUstep's stacked menus in the past. It is clear that alot of people like GNUstep's stacked menus, but alot of people also have different ideas about how menus should be displayed. I want to propose one pragmatic solution that should make it easier to support multiple menuing paridigms. I have been looking at the code in NSMenu, and at the moment NSMenu is reponsible for creating an NSMenuView and the NSPanel object that it is housed in. As a result, this code makes the assumption that a menu is always in a separate window, and that there is only one displayed representation of a menu. It also assumes that the menu representation is drawn in the same process with an NSMenuView object. In order to support different paridigms, such as the (addmittedly broken but popular) one-menu-per-main-window on Win32/Gtk/Qt or Etoile's menu server, I believe that programmers currently need to modify NSMenu through means such as subclassing or overriding using categories. These methods are prone to breakage as they often depend on internal implementations. I am proposing that we separate the visual representation of a menu (which includes the window it is drawn in (NSMenuPanel), the view (NSMenuView) and the item cells (NSMenuItemCell)) from the abstract representation of a menu (NSMenu). I am suggesting we do this allowing people to supply an object which will receive menu update notifications (such as items being added, removed, etc.) and be responsible for coordinating the drawing of the menus and handling events. It should be different from the current use of the "NSMenuRepresentation" which assumes that the menu representation is a subclass of NSView. This "object" should implement some sort of protocol for communication between itself and NSMenu, the protocol supplying methods which inform the object of changes in the NSMenu, something like the interaction between a Model and Controller in MVC. For example, you may wish to place a menu on each of your document windows, but this breaks the current assumption that there is only one visual representation (view) of the menu. In this case, the intermediary object would sit between NSMenu and the associated set of NSMenuViews which reside in each document window. It would be responsible for receiving update messages from the NSMenu object and forwarding them to each of the NSMenuViews. These views in turn would somehow notify the NSMenu when they are clicked/selected. I think this may be a reasonably opportune time to play with the current design, as Apple have deprecated the usage of NSMenuView and NSMenuItemCell along with the -menuRepresentation property of NSMenu (according to the Cocoa docs). Before I possibly attempted to implement such a solution, I wanted to discuss it with the list as I fear this solution may be too complex where simpler solutions exist, and I know it has implications for some other areas in the AppKit (especially popup buttons). I don't wish to engage anyone in debate about the merits or disadvantages of stacked vs horizontal menus; I think this has been discussed enough on these mailing lists before. I believe we should be pragmatic and offer people a choice. It would be helpful to gain some feedback about this idea, particularly its feasibility. I think it is not too difficult to implement and I do think it is necessary if we want to be flexible in supporting different kinds of menu paridigms. Cheers Chris another thing to consider is context sensitive menus, which regardless of main menu implementation want a vertical menu i for one would like to see NSPopUpButtons cleaned up, as it is theres NSPopUpButton has a NSPopUpButtonCell has a NSMenu has a NSMenuView has a NSMenuPanel, there seems to be more code for pop-up buttons in the NSMenu* classes than NSPopUpButton* (seems like it'd be cleaner to have just a window with a matrix in NSPopUpButtonCell).. also it seems like this class has been updated sequentially to conform to apples NSMenu implementation of the day and its sort of a hodge podge of characteristics from all the different NSMenu implementations so i'm basically indifferent twords support of different menu paridigms, i definately think NSMenu* needs an audit ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: 64 bit GNUSTEP
Sorry, I should have sent out an update. Thanks to some help i got on the irc channel, i figured out that most of the problems seemed to be because i needed to recompile ffcall with -fPIC. I also forced the host type since its seemed to be not recognizing it. (configure was coming up with x86_64-unknown-linux-gnu instead of the expected x86_64-pc-linux-gnu) not sure if that later detail made any difference, but recompiling ffcall with -fPIC was the big fix. jb On 2006-11-29 10:12:32 -0500 Adam Fedor <[EMAIL PROTECTED]> wrote: > > On Nov 27, 2006, at 1:40 PM, Joseph T. Bore wrote: >> *** Warning >> The mframe software has not been ported to x86_64. >> Using information from unknown. >> >> *** Warning >> The mframe software has not been ported to x86_64-linux-gnu. >> Using information from unknown/generic. >> >> > I only see warnings, which are mostly normal. Is there an actual > error that > you get? > RFC3156 defines security multipart formats for MIME with OpenPGP. pgpKmpKLFyez1.pgp Description: PGP signature ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Menu Proposal
On Nov 29, 2006, at 7:19 AM, Christopher Armstrong wrote: I am proposing that we separate the visual representation of a menu (which includes the window it is drawn in (NSMenuPanel), the view (NSMenuView) and the item cells (NSMenuItemCell)) from the abstract representation of a menu (NSMenu). One point to consider here is whether additional modifications will be needed elsewhere in GUI, e.g. to take account of the height of a menu bar in window frame calculations if an in-window menu option is chose. Similarly for screen dimensions and Mac-style top menubars. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep Testfarm Results
Fine by me if people want that. I used to send it to the CVS list, but I can't do that anymore since we changed hosts. On Nov 29, 2006, at 6:07 AM, Nicola Pero wrote: Can we disable the alert email when everything is OK ? Or maybe only send it to Adam (or some volunteers) so he knows that the testing system is running ? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: 64 bit GNUSTEP
On Nov 27, 2006, at 1:40 PM, Joseph T. Bore wrote: *** Warning The mframe software has not been ported to x86_64. Using information from unknown. *** Warning The mframe software has not been ported to x86_64-linux-gnu. Using information from unknown/generic. I only see warnings, which are mostly normal. Is there an actual error that you get? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
RE: GNUstep Testfarm Results
Can we disable the alert email when everything is OK ? Or maybe only send it to Adam (or some volunteers) so he knows that the testing system is running ? Thanks -Original Message- From: "Adam Fedor" <[EMAIL PROTECTED]> Sent: Wednesday, November 29, 2006 12:34 pm To: gnustep-dev@gnu.org Subject: GNUstep Testfarm Results Test results for GNUstep as of Wed Nov 29 06:34:17 EST 2006 If a particular system failed compilation, the logs for that system will be placed at ftp://ftp.gnustep.org/pub/testfarm If you would like to be a part of this automated testfarm, see http://wiki.gnustep.org/index.php/Developer_FAQ#How_can_I_take_part_with_a_GNUstep_autobuilder_for_the_testfarm.3F Success Compile i386-unknown-netbsdelf3.1 Wed Nov 29 03:56:34 CET 2006 Success Compile powerpc-apple-darwin7.9.0 Wed Nov 29 03:09:36 MST 2006 Success Compile sparc-sun-solaris2.7 Wed Nov 29 01:35:11 EST 2006 Success Compile x86_64-unknown-linux-gnu Wed Nov 29 04:09:50 GMT 2006 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Menu Proposal
Hi all I wish to make a proposal regarding NSMenu. There has been alot of debate about GNUstep's stacked menus in the past. It is clear that alot of people like GNUstep's stacked menus, but alot of people also have different ideas about how menus should be displayed. I want to propose one pragmatic solution that should make it easier to support multiple menuing paridigms. I have been looking at the code in NSMenu, and at the moment NSMenu is reponsible for creating an NSMenuView and the NSPanel object that it is housed in. As a result, this code makes the assumption that a menu is always in a separate window, and that there is only one displayed representation of a menu. It also assumes that the menu representation is drawn in the same process with an NSMenuView object. In order to support different paridigms, such as the (addmittedly broken but popular) one-menu-per-main-window on Win32/Gtk/Qt or Etoile's menu server, I believe that programmers currently need to modify NSMenu through means such as subclassing or overriding using categories. These methods are prone to breakage as they often depend on internal implementations. I am proposing that we separate the visual representation of a menu (which includes the window it is drawn in (NSMenuPanel), the view (NSMenuView) and the item cells (NSMenuItemCell)) from the abstract representation of a menu (NSMenu). I am suggesting we do this allowing people to supply an object which will receive menu update notifications (such as items being added, removed, etc.) and be responsible for coordinating the drawing of the menus and handling events. It should be different from the current use of the "NSMenuRepresentation" which assumes that the menu representation is a subclass of NSView. This "object" should implement some sort of protocol for communication between itself and NSMenu, the protocol supplying methods which inform the object of changes in the NSMenu, something like the interaction between a Model and Controller in MVC. For example, you may wish to place a menu on each of your document windows, but this breaks the current assumption that there is only one visual representation (view) of the menu. In this case, the intermediary object would sit between NSMenu and the associated set of NSMenuViews which reside in each document window. It would be responsible for receiving update messages from the NSMenu object and forwarding them to each of the NSMenuViews. These views in turn would somehow notify the NSMenu when they are clicked/selected. I think this may be a reasonably opportune time to play with the current design, as Apple have deprecated the usage of NSMenuView and NSMenuItemCell along with the -menuRepresentation property of NSMenu (according to the Cocoa docs). Before I possibly attempted to implement such a solution, I wanted to discuss it with the list as I fear this solution may be too complex where simpler solutions exist, and I know it has implications for some other areas in the AppKit (especially popup buttons). I don't wish to engage anyone in debate about the merits or disadvantages of stacked vs horizontal menus; I think this has been discussed enough on these mailing lists before. I believe we should be pragmatic and offer people a choice. It would be helpful to gain some feedback about this idea, particularly its feasibility. I think it is not too difficult to implement and I do think it is necessary if we want to be flexible in supporting different kinds of menu paridigms. Cheers Chris -- Christopher Armstrong carmstrong ^^AT^ fastmail dOT com /Dot/ au ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
GNUstep Testfarm Results
Test results for GNUstep as of Wed Nov 29 06:34:17 EST 2006 If a particular system failed compilation, the logs for that system will be placed at ftp://ftp.gnustep.org/pub/testfarm If you would like to be a part of this automated testfarm, see http://wiki.gnustep.org/index.php/Developer_FAQ#How_can_I_take_part_with_a_GNUstep_autobuilder_for_the_testfarm.3F Success Compile i386-unknown-netbsdelf3.1 Wed Nov 29 03:56:34 CET 2006 Success Compile powerpc-apple-darwin7.9.0 Wed Nov 29 03:09:36 MST 2006 Success Compile sparc-sun-solaris2.7 Wed Nov 29 01:35:11 EST 2006 Success Compile x86_64-unknown-linux-gnu Wed Nov 29 04:09:50 GMT 2006 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
