Version: (using KDE 3.5.9) Installed from: SuSE RPMs Take a look at kdevelop, I know I have to set shortcuts for folding, so I type: fold nothing appears. That's because there is no such item. But when you look at the menu -- there is. My wish: provide two modes. List -- all items are simply listed, you can sort them, no structure Tree -- all items are presented in a structure which is 1:1 copy of menu (structure). When I type "fold" this time I would get "fold" tree node, then I could clear search entry and look at the subitems. This way it is easier to get to the items when you don't know the exact name but you know where they are in the menu(or you simply know the "category"). Currently the view is a mixture of those two, and it has only drawbacks of them -- you cannot really sort the list because it is not the list and you don't see the structure because it is really not a tree.
The tree view is technically impossible.
Andreas, why?
PS. Konq. bookmarks editor has such mode and it is pretty close to what I wished for -- instead of one value (URL) in this case should be two values (primary shortcut and secondary shortcut).
Well, its not really technically impossible (its software so everything is possible), however its completely against how QAction and KAction are designed. Both are supposed to be useable with any widget you want, they are not tied to a menu. So if you give the shortcuts editor a list of actions to configure it cannot be sure that those actions are actually in a menu structure. In particular many games have actions that aren't in a menu or toolbar, kdevelop has some actions which will never be in any menu unless you as a user hack it in. However the fact that an action has a different string in the shortcuts editor and the menu is a bug actually. What you see in the menu should be the same as in the editor and I'm really astonished this is not the case as KAction has only one title property.
I just checked and in fact there's no item in the menu that has "fold" in its title, except for "Show Folding Markers" and that one you can find via searching.
ad.#5 the problem is there are more actions _related_ to folding, and searching by name will not list them, like collapse/expand, it is folding feature, but there is no "fold" phrase, and that is what I was looking for ad.#4 I see your point, so I rephrase -- if it is possible it should be 1:1 copy of the menu structure, if not, I have to idea (now) what to do with "dangling" items, maybe some node "Application" or "Main" But Andreas, if I understand correctly, you are saying that it is bad to have tree view, because some items does not fit in tree view, right? But: a) if the whole app is not suited to have tree view (games) that such app should not provide tree view at all, problem solved b) if some app has some "free" actions, it can mark them as described above I see those as minor problems. Look at the benefits -- you would like to set shortcut for that item, in the edit menu, it was, finding, or searching, let's take a look at keyboard shortcuts, edit -> it was somewhere near the beginning, oh, there it is, find text It is absolutely easy if you have a bit of visual memory. What do you think?
The implementation for this IMHO outweighs any such minor benefits. If you know there's an item in one of the menus its _very_ easy to find that item in the menu and memorize the first few letters of its title. Then go to the shortcuts editor and search for that. It would also slow down the shortcuts editor even more, because it would have to go through the menu structure every time its loaded (or at least once each time an app is started) to find out where each action sits in the menu. Besides the standard shortcuts dialog doesn't have any connection to the actual application mainwindow currently.
> If you know there's an item in one of the menus its > _very_ easy to find that item in the menu and memorize the first > few letters of its title. Then go to the shortcuts editor and > search for that. You are right. For one item. But for even to shortcuts you have to close the dialog, look for the item, call it again. For several shortcuts it is a headache. > It would also slow down the shortcuts editor even more, because it > would have to go through the menu structure every time its loaded > (or at least once each time an app is started) to find out where > each action sits in the menu. Besides the standard shortcuts dialog > doesn't have any connection to the actual application mainwindow > currently. No, no, it is the responsibility of the application to pass the tree structure to the function. If application will pass a list, the tree view would be not available.