FrapMenu menu/item ordering

[Jannis Pohlmann]

On Wed, 21 Feb 2007 21:42:13 +0100, Stefan Stuhr wrote:

> ons, 21 02 2007 kl. 21:28 +0100, skrev Jannis Pohlmann:
> > On Wed, 21 Feb 2007 20:42:36 +0100, Stefan Stuhr wrote:
> > > I will admit that I don't know the fd.org menu standard, but if
> > > the implementation in GNOME follows the standard (I do believe
> > > that it does), then the order does matter - and not necessary a
> > > sorted order.
> >
> > See below. BTW, what GNOME does is not relevant to me. I think their
> > implementation sucks (internally), so I prefere to concentrate on
> > the specification itself.
> >
> > > E.g. in the GNOME menu editor, alacarte, it's possible to manually
> > > move menu items around (be it menu directories/submenus, menu
> > > entries, or separators), and place them in a manual, non-sorted
> > > order of choice.
> >
> > I don't know how they do this, but the spec only mentions
> > alphabetical order in relation to menu layouts (which have not been
> > implemented in FrapMenu yet).
>
>
> >From the spec[1]:
>
> <Layout>

For this discussion (which is all about the menu content order),
especially one part of the specification is important:

First of all, <Layout> *can* be used for moving certain items to the
top, bottom or between special separators. However, there's no way to
have a special order apart from that. The specification is (as I
already mentioned) very clear about the usual order: Alphabetical.

Currently, there is no <Layout> support, which means that everyone who
wants to use FrapMenu already will have to "emulate" the
<DefaultLayout> for all menus, which looks like this:

  <DefaultLayout show_empty="false" inline="false" inline_limit="4"
                 inline_header="true" inline_alias="false">
    <Merge type="menus"/>
    <Merge type="files"/>
  </DefaultLayout>

<Merge> inserts children of the given type ("menus", "files", "all") in
alphabetical order. As you can see, the default is to insert menus
before menu items.

> As far as I can tell, if FrapMenu is going to support <Layout> (which
> I can now see is an optional part of the spec) in the future, then it
> will have to support manually defined order of items. Otherwise,
> <Separator> just wouldn't make sense.

... <Separator> imples <Layout> as it is not allowed anywhere else.

  - Jannis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.xfce.org/pipermail/xfce4-dev/attachments/20070221/dae33e93/attachment.pgp>