Re: Making a Python/GTK CheckMenuItem, when clicked, not close the menu

["Freddie Unpenstein" <fredderic excite com>]

> On Fri, 2010-01-29 at 00:27 -0500, Freddie Unpenstein wrote:
> > One thing did occur to me, though. It's kind of annoying when you click
> > a check menu item, and the menu doesn't go away. And having some
> > that do, and some that don't, would probably drive me balmy.
>
> My scenario, however, is a tray icon with a bunch of preferences for
> network interfaces and I'd like it so that you go into the submenu for
> the NIC and then tick a series of boxes to configure it. In this case
> having the menu not disappear makes some sense IMO.

The question remains, how do you dispatch the menu when you've done your selecting.  In some enviroments, you 
can't just click off the menu, because that click will land on whatever it was you clicked, and strange 
things can happen.  This has been trouble for me when I've brought up a menu and changed my mind.  Let alone 
a menu that intentionally doesn't close when you click on something.

On one machine I've used, the text part of a menu either did nothing, or activated some function.  Nothing 
strange about the latter, except when it's also the lead item of a sub-menu, and to bring up the sub-menu, 
you have to click the little arrow to the side.  Terribly bizarre.  One thing I *DID* like about their 
system, though, was that clicking the space for the checkmark didn't close the menu, where clicking the text 
attached to the checkmark USUALLY did (except when it did something different).

But that kind of thing has made me a little weary of menus that don't do what you expect them to, also.  One 
alternative, if you DID go down that road, might be to colour the non-closing items differently, and have an 
explicit "do nothing but close this" DONE item.  Still, dialog boxes make more sense, and probably play 
better with assistance mechanisms.


> > Back to the original question; the "better" way, would probably be
> > to use a dialog box in this instance, to allow these options to be
> > changed without having to go back to the menu all the time.
> > Perhaps depending on usage, an Options menu item as well as
> > the individual options, which brings them up in a dialog for when
> > you need to change multiple options.
> Dialog box looks the way forward. Maybe tabbed or something.

I take it you can have several sub-menu's with basically the same options.  Might be able to do something 
with that.  At the simplest, have all the interfaces listed as tabs in a notebook, and pre-select the one 
from the menu.  At the other end, perhaps a grid of toggle buttons so you can see how those options are set 
across all the interfaces.  Also allows for an extra column to change a setting on all interfaces (as is 
found in /proc).  Depends on what exactly you're doing, though. Just a thought.


One thing I do often wish, is that it was easier to share one notebook page between several tabs, or even 
more, being able to multi-parent widgets (I suspect that would be a rather radical change, though.  ;) )


Fredderic

------------------------------------------------------------
Want to lose weight? Click here for diet help and solutions.
Diet Help
http://tagline.excite.com/c?cp=33U4g1Jl0TtVObNdDx9AAQAAKZS4OohqXEN8zZrBVHP9bxeIAAYAAAAAAAAAAAAAAAAAAADNAAAAAAAAAAAAAAAAAAAYQME6nvI=