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

List:       kde-bugs-dist
Subject:    [Bug 4229] Right click on K menu does not give RMB menu to edit
From:       Andreas Leuner <almighty () atlantis ! wh2 ! tu-dresden ! de>
Date:       2004-07-23 16:01:37
Message-ID: 20040723160137.709.qmail () ktown ! kde ! org
[Download RAW message or body]

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
      
http://bugs.kde.org/show_bug.cgi?id=4229      




------- Additional Comments From almighty atlantis wh2 tu-dresden de  2004-07-23 \
18:01 ------- Implementing the proposals made in this BR, especially those in #34 and \
#35, is indeed "difficult" or doesn't seem to be feasible to me. Unlike the windows \
start menu the K menu is _not_ implemented as a directory structure. Instead it is \
implemented with so-called "virtual folders" which could be compared to (try googling \
for) "database views".

Database views are predefined queries that can be accessed like tables, except that \
they are normally readonly. Any modifications are normally done in the underlying \
tables.

The virtual folders are now prepared as follows

* There is a store (table) of all menu entries' .desktop files (rows) situated under \
                KDE-PREFIX/share/applications.
* Each of those files has a number of key-value pairs (columns) in it - defining, for \
example, the name or icon path of the menu entry. See the "Desktop Entry Standard" at \
http://freedesktop.org/Standards/desktop-entry-spec, section "Recognized desktop \
                entry keys" for a list of other keys.
* A (sub)menu, as you see it in K menu is the selection of menu entries (rows) by the \
                basis of the key (column) values.
* The (all applications part of the) K menu is a collection of such selections. These \
selections are specified in KDE-PREFIX/etc/xdg/menus/applications.menu. Their \
results, the (sub)menus, aren't stored. Instead when KDE is started those selections \
are performed among all menu entries and the result is displayed by K menu. There may \
be a cache in the process to speed things up however.

Now we can see that hand-editting the K menu is like editting the results of a \
database query. This is possible to simulate, which is hard to do properly (as the \
menu editor shows ;-). 

The better thing to do would be to guess why users would drag menu items around and \
provide means to automatically satisfy the needs they want to satisfy by hand. In \
                other words adjust the selections for the menus.
Example: I want items I often use appear first in a menu.
Solution: Count application invocations and sort descending by number of them. \
Following the database analogy this would be easy.

I don't say this is already possible with the K menu, but the "virtual folders" \
concept would be good for it.

And so on. The assumption is that nobody drags around menu items just for fun but \
that a general rule can be stated. Otherwise "virtual folders" are not suitable.


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