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

List:       kfm-devel
Subject:    Re: Patch: window menu keyboard shortcuts
From:       Keunwoo Lee <klee () cs ! washington ! edu>
Date:       2000-11-14 19:58:42
[Download RAW message or body]

On Tue, 14 Nov 2000, David Faure wrote:

> There's a little bug in the code though: if the smart thing didn't
> manage to put a '&' (it can happen, in a very crowded menu, "found"
> will still be false), then activating the item won't work (if it can't
> find '&', it returns at once).

I don't follow.  In slotProfileActivated(), we only go ampersand hunting
when we fail to find a profile's unmodified name in the map.  If there's
no ampersand, we jump directly to loading the view profile.

We can test this case even with a small (2-item) menu by renaming our
profiles to something like "A" and "A_".  "A" will get hotkey 'a', and
"A_" will get no hotkey & hence no ampersand.  Selecting "A_" still works.

> In fact, if we populate the menu using an iterator over the QMap, we
> don't have to use the menu text to find the item when we know that
> item 5 has been activated. All we need to do is to iterate again the
> QMap, to find the 5th item. This way, slotProfileActivated can be
> rewritten much more cleanly.

Oops.  Yes, of course.  I was just doing a quick & dirty fixup of what was
there previously.

> > BTW "smart automatic hotkey generation" seems like it would be useful for
> > other apps' dynamically generated menus, or for lazy programmers who don't
> > want to manually set hotkeys in static menus.  It may be worthwhile at
> > some point to factor this code into something reusable.
> 
> Yes, and in fact that's why I wouldn't want all this code to go into
> konq_viewmgr. Somehow, what we want is a method (function) that takes
> a QStringList and find a smart way to populate shortcuts into it. We
> would then use the result to create the items. And maybe we don't even
> need a QMap at that point, and we just have two qstringlists of the
> same size, one with the texts (not even stored permanently in the
> class) and one with the profile names (for slotProfileActivated).
> 
> What do you think ?

More or less what I was thinking of.  I guess the proper place, once it
was done, would be kdeui, since it's a general menu-related facility.

Right now I think it should be a template function that takes an iterator
returning a string, and populates a QStringList (or arbitrary collection?)
with a menu-ized version:

template <class Iter, class Deref>
void generateMenuShortcuts(Iter begin, Iter end, QStringList& target,
                           Deref deref) {
    for( ; begin != end; ++begin) {
        QString str = deref(begin);
        // do stuff
    }
}

We could provide Deref classes (QMapIterDeref, QStrListIterDeref), use
template specialization with default arguments, and then overload it on
the collections directly, to make it maximally convenient.

I don't hack kde full-time :) but I may take a break from my real work
sometime "soon" (i.e., before KDE 2.1) to write this.

~k.lee

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