Hello Quentin,

On 2007-12-13 23:31:03 +0100 Quentin Mathé <[EMAIL PROTECTED]> wrote:

> Le 30 nov. 07 à 11:39, Andreas Schik a écrit :
> 
>> Hi there,
>> I have become a real fan of the horizontal main menus and of 
>> EtoileMenuServer. However, what bothered me was that on right- clicking the 
>> application only real context menus are poppimg up, but  no longer the main 
>> menu, which is feature I also used a lot.
>> Thus, i have hacked NSApplication+Hackery to enable this. In my hack  i 
>> create a temporary vertical copy of the horizontal main menu to  pop up 
>> beneath the mouse pointer. For those who are interested in  this (and I 
>> believe some of you are) I attach the patch for this.  The patch is against 
>> the latest SVN.
> 
> Hi Andreas,
> 
> Thanks a lot for your patch. I have an updated version of it that I  will 
> commit tomorrow. Instead of overriding -mouseDown: in  NSApplication, I have 
> choosen to override +defaultMenu in NSResponder  and NSView. I think it fits 
> better with AppKit API and allows to  display this menu in any views even if 
> a superview redefines - rightMouseDown:. In this case, with your patch the 
> superview would  intercept -rightMouseDown: in the responder chain and 
> NSApplication  would never get it.
> If a view defines a contextual menu, this vertical main menu won't be  shown.
> I may add a preference in future allowing to disable this feature, but  for 
> now it's turned on by default.
I am glad that this has found its way into the official product, even if if has 
a different form now :-)
Actually, I do not really care in which method the menu is opened as long as it 
comes up.

> 
> Initially my plan was to let the user free to decide whether he  prefers to 
> use normal contextual menus or this vertical main menu as  contextual menu. 
> But AppKit allows to override all menus related  methods, so you cannot 
> ensure the developer won't break the default  behavior. We could tell the 
> developer he must call a superclass  method, but AppKit documentation needs 
> to be updated then. The best  way would be to add an AppKit private method 
> that is called everytime  a contextual menu is going to be displayed, but 
> this involves  overriding many more methods (which I prefer to avoid) or 
> making a  feature request to GNUstep. So it will remain in the current state  
> unless someone is really interested to work out a solution.
> 
I do not quite understand this. Why would the user need to decide whether to 
use the main menu as context menu or the context menu defined by the 
application/developer? Currently, in plain GNUstep we have both: if a view has 
a context menu this will pop up on a right mouse click, otherwise the main menu 
pops up. Good example for this are GNUMail and GWorkspace. I would expect this 
behaviour in  Étoilé as well (at least if the project team decides to have 
right click menus). My original patch does exactly this and I suspect that the 
way you finally integrated it would have the same behaviour (I couldn't test it 
so far.).
But it may well be that I simply misunderstand you. It may also well be that my 
patch does not in all cases ensure the desired behaviour of menus, as I 
did/could not test all cases/programs that use context menus.
Concerning the developer's behaviour you more or less don't have a choice at 
all, but to give recommendations how to make a program fit into the Étoilé 
concept.

Thanks for your work. Cheers,
Andreas
RFC3156 defines security multipart formats for MIME with OpenPGP.

Attachment: pgpSd5KPLMITl.pgp
Description: PGP signature

_______________________________________________
Etoile-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-discuss

Répondre à