[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: VFolder 1.5 category (and .desktop spec) comments

On Wed, Jul 24, 2002 at 08:45:50PM -0500, Chris Lawrence wrote:
> Great!  I also missed AdventureGame on my first pass through.  (The
> other Game categories correspond pretty well with Debian's.)

Added this ...

> > I'm not sure how common this is, perhaps this could be solved by using an
> > X-Mozilla-MozillaGroup category.  Then you could build a vfolder file that
> > querried for that and made it a submenu.  A similar thing is used in GNOME2
> > for sawfish settings.
> Hmm.  That would require intelligence in the menu system to figure out
> whether a certain package is installed or not (i.e. the menu system
> would have to be updated for each application that used this feature).
> For example, if a third-party application (MyApp) shipped something
> with the category X-MyApp-MyAppDir, the menu system wouldn't use that
> category unless specifically hacked for MyApp.  (e.g. you might want
> all of OpenOffice together in one submenu, rather than split among
> Spreadsheets, Word Processors, Presentation Software, etc.)

Yeah, though perhaps a debian specific extension would work here now.  In acy
case this can be a different proposal/spec from the vfolder as it doesn't
conflict with the vfolder at all.

> > > About the only remaining problem is the massive overloading of
> > > Utilities (formerly "Tools") in Debian, but I haven't come up with a
> > > good category list for it yet.  Some of that stuff will migrate
> > > elsewhere once maintainers manually tweak the Categories of their
> > > packages, but certainly not all of it.
> > 
> > Yeah.  It's also getting your vfolder queries right, and that only depends on
> > the set of applications that's installed.
> Well, a priori there's no way to know what set of applications will be
> installed on a Debian box (you could have several thousand menu
> entries).  A layout that makes sense with a small number of packages
> (like GNOME2's menus) looks absolutely horrible with lots of entries
> (like GNOME2's menus once I symlink ~250 converted desktop files into
> /usr/share/applications).  Ideally we want to end up with a menu
> system that can cope with anywhere from 20 (probably the bare minimum
> you'd ever see) to 1000 menu entries in a reasonably graceful way.

Well perhaps you could have an adaptive vfolder file, you'd need to rewrite
the gnome vfolder implementation, but the spec itself allows it.  I suppose
you could even just extend it.  Add 'alternative' branches to the menu which
would trigger on certain conditions.  For example have a 'Utilities'
folder, which would have two definitions, the first one would be tried and
if there were over say 20 entries, you'd try the second one which would
define sub-folders.

I think in the end we should get away from trying to do user menu-editting
using file operations so we don't have to worry I don't think about how that
interacts with an adaptive approach.   We just need to write a good vfolder
view for nautilus (in GNOME2's case) that does all the menu editting in a
more logical style (I doubt most normal users will want to 'edit' their menus
in the first place and will just leave them as the distributor ships them),
so menu editting can be a more 'advanced' feature.  IMO anyway.

In any case, GNOME2 is already a little adaptive in being able to not show
folders that are empty.

I think the cool thing about the vfolder spec as it is currently is that it
doesn't tie you to a certain implementation of the vfolders.  It just says
how .desktop files look and where they are installed.  You can go nuts on how
you present and organize them to the user.


George <jirka 5z com>
   The only thing that interferes with my learning is my education.
                       -- Albert Einstein

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]