[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Context menus
From:       Matthias Ettrich <ettrich () troll ! no>
Date:       1999-11-25 19:18:02
[Download RAW message or body]

On Thu, 25 Nov 1999, Richard Moore wrote:
> Waldo Bastian wrote:
> > 
> > On Thu, 25 Nov 1999, Bernd Gehrmann wrote:
> > > Does any KDE application have the ability to open context
> > > menus by keyboard? If not, then it's time to establish
> > > conventions wrt which key is used for this purpose and
> > > at which position such a menu is opened in QListView,
> > > QListBox and QIconView.
> > >
> > > Bernd.
> > 
> > Good point.
> > 
> > We are talking about RMB-menus?
> > 
> > My keyboard here has this nice "menu"-key. Seems like a good candidate.
> > Since this key is not on _every_ keyboard, I guess we need an
> > alternative as well. I propose Ctrl+M.
> 
> Sounds good to me, how does Qt assign keycodes to unusual keys like
> the Windows key, RMB key etc? We should make the windows key fire up
> the main kicker menu.


Yes, Qt has keycodes for most of them.  But making the menu key configurable on
the application (=KDE-) level sounds a bit like overkill to me. That's almost
like making the spacebar configurable.

X defines a symbol XK_Menu, I suggest we simply use this. We can motivate the
Linux distributors and/or XFree to map the menu key to the XK_Menu symbol in
their default configuration (most should do this anyway, right?). Qt maps this
symbol to Key_Menu.

Strange, my X produces Hyper_L when typing the menu key.... but that's easy to
fix in an Xmodmap.

On the other hand: we don't need to require people to hack their Xmodmaps.... I
will write a utility class KContextMenu that also deals with the press/release
issue (remember: we still didn't decide whether to show a context menu on press
or on release. Personally, I prefer release now, but probably we have to make
it configurable. Encapsulated in one class, that's easy.)

Regarding the position where the menu should show up: that's also easy: we use
the micro focus hint (see QWidget::setMicroFocusHint(....) ). All widgets that
have a caret (i.e. text-input widgets or navigation widgets like
QListView/QIconView) should set the hint to something reasonable. May not work
currently, but will work for sure soon.  Basing the context popup on the hint
will at least show us all the widgets where the hint is wrong :)

Unfortunatly Qt lacks a get function for the hint, I will add this. When
switching to a newer snapshot after KRASH, we can use this.


Matthias

[prev in list] [next in list] [prev in thread] [next in thread]