[Usability] Re: Lightening up the XDG menu

Alan Horkan horkana at maths.tcd.ie
Sun Mar 28 21:19:42 EEST 2004

On Sat, 27 Mar 2004, William Leese wrote:

> Date: Sat, 27 Mar 2004 20:00:37 +0100
> From: William Leese <william at leese.nl>
> To: KDE Usability Project <kde-usability at kde.org>
> Cc: xdg at freedesktop.org, usability at gnome.org
> Subject: [Usability] Re: Lightening up the XDG menu
> Frans Englich wrote:
> > We all know how important the XDG menu specification is for
> > integration between the various desktop environments. But,
> > unfortunately it creates a usability problem when for example both
> > GNOME and KDE is installed on one computer - the menu becomes
> > overcrowded. For example, in KDE's KMenu there's a lot of applications
> > which are either irrelevant or duplicates functionality.

It is a seperate issue but hopefully the duplicate functionality will
gradually be addressed by applications devolving some of their
functionality into general purpose libraries and theming interoperability
will get better so that users will be more easily able to choose the best
applications and not discriminate based on toolkit.  (I highly commend the
application developers that roll their functionality out into libraries
and I'm well impressed by the KDE developers who make that kind of
functionality reusable again higher level through Kparts)

I'm really hoping that some sort of XML based user inteface description
can be adopted by both Gnome and KDE (be it Glade XML, Mozilla XUL or
whatever else).

I'm going to go way offtopic for a second but for quite a while now I have
wondered: Why I cannot have support for importing Photoshop Documents (at
least as a flat rendering*) in all my graphics applications when I have
the necessary functionality installed with the GIMP; Why I cannot have at
least a plain text import of Microsoft Word documents in Gedit if I have
the functionality import functionality installed with OpenOffice.org?  I
am reliably informed that the old Amiga had something they called
DataTypes which allowed programmers to add support for a file format once
and the whole desktop would benifit and although I'm completely offtopic
and shameless abusing the lists by crossposting I'd be immensely pleased
if some one could explain if something like this could be added to both
Gnome and KDE?

* I'm aware of GdkPixbuf, and I have been immensely pleased to see
various applications gain functionality when it gets added in one single
place and it is part of the reason I couldn't help wondering why there is
not a similar standard text buffer (even just plain text) available to all

I so very much want to see an open source desktop that really leverages
being open source and comes together to be so much more than the sum of
its parts and to make sure that there is no technological or practical
need for developers to duplicate functionality.

>  > Similar, but listed so their counterparts are more clear.
> Keep into consideration that these menu's are often, from a user point
> of view, a listing of all (be it graphical) the applications available
> on their computer. So hiding either gedit or kedit based on which
> desktop is being used would be more confusing than anything else.
> Consider a user who one day decides to take a look at this 'GNOME'
> thing. Suddenly he has no (apparent) access to the applications he/she
> once used.

To bring this a little bit more back on topic:

This hiding of menu items bothers me a little, not as much as the hiding
Microsoft do but similarly annoying so I hope you can provide a a quick
and easy way to disable hiding of menu items.
What happens to users who want to see a list of all available
applications?  I realise it is ugly but a long list of all available
applications is very useful.
Due to the difficult I have had with the menus changing in various ways
over the past few years I mostly just use the Run Dialog which provides me
with such a list of (almost?) all available applications but then I'm not
a new user and I do know the names of most of the applications I want to

- Alan H.

More information about the xdg mailing list