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

List:       kde-core-devel
Subject:    Re: separators and titles in the kmenu
From:       Havoc Pennington <hp () redhat ! com>
Date:       2003-01-31 17:35:46
[Download RAW message or body]

On Fri, Jan 31, 2003 at 05:43:27PM +0100, Alexander Neundorf wrote:
> I don't know how the specs look, just a stupid note:
> I think using an own file for each aspect will probably slow things down, 
> grouping more things into fewer files speeds up reading.

My personal feeling is that adding the order to the XML files makes
most sense. If you like fewer files more, and George thinks adding to
the XML file sounds best, it sounds like we have some consensus on
this.
 
> I use it this way:
> 
> Office -> Abiword
>           WordPerfect
>           * KOffice *       <- this one is a title
>           KWord
>           KSpread
>           ....
>           * OpenOffice *    <- this one too
>           OO Writer
>           OO Calc
>           ....

I see, that makes sense. It does look like using .directory files for
the titles would work pretty well, then. (Allows us to have
translations.) But of course the actual position of the title is in
the XML file, along with the position of any separators.

Right now the ordering of include/exclude elements in the XML file is
significant for determining how menu merging works, so can't really be
overloaded for determining the user-visible order.

I would say what we need to know before we define the relevant XML
elements is how explicitly-sorted items relate to other items that are
added to the menu; George says GNOME has historically just put all
explicitly-sorted items first, then the unsorted items. That doesn't
sound great to me but I guess it's a solution.


Another thought: what if we did titles as submenus that are "inlined"
- i.e. to do a subsection such as your KOffice subsection, we just do
it like a submenu called KOffice, then have a flag "inline this
submenu" that would suck the submenu into the parent menu for display
purposes. I guess this might be hard to express via virtual file
system, though. You'd sort of want to do it at the last minute while 
building menus I think, not in the VFS layer.

This doesn't address the ordering issue, but it does mean the whole
"subsection" for say KOffice will be kept as a unit, instead of having
to explicitly move newly-added KOffice components below the title.
With this method the title is for a specific set of include/exclude
"queries" rather than just a standalone single item that's inserted
into the menu.


Getting back to ordering - a way I can think of doing it is:

 - save the list of ordered items in order (logically equivalent 
   method: save the position of each ordered item as an integer)

Given that, here are two ways to handle new not-in-the-list items:

 - dump them all at the beginning or end

 - first sort alphabetically, then swap items that *are* in the sort
   list until those items are ordered as they are in the list, leaving 
   the not-in-the-list items in their alphabetic locations

Another way different from saving a list of ordered items:

 - save the position of each item as "before foo.desktop" or "after
   bar.desktop" - this means that saving a single user move 
   operation does not have a side effect of locking the order of 
   the whole menu, but it also means you lose ordering if you delete
   items, and generally seems fragile.

Any other possibilities?

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