Re: fmenu

> This was my point. I, (for one), write programs. I don't know whether
> or not people will run these programs in GPE or not. I would like to
> create a single menu entry in a single format. We already have a
> format for the menu entries that should work just fine, so I don't
see
> why we would need to create anything new.
Fair enough, maintenance sucks, but packages for GPE would 99% be
installed by joe-user through ipkgs - a pretty sure giveaway that
they'll want "fmenu" entries. The extra maintenance needed for making
ipkgs (ie. editing CONTROL/) is more than that of the extra menu entry.

> > I saw that; However this still leaves problems - we *can* strip out
> > below the second level, but then important programs (eg. rxvt)
> won't be
> > in the menu.
>
> No. You misunderstood me here. What I meant was that fmenu could drop
> *categories* below the first level, but preserve all menu entries:
>
> eg. Utilities/Terminal/7 -> Utilities/"Terminal 7" or some such.
Ah, OK, fair 'nuff. But then we have to limit programs putting stuff
in there. eg. "LCD Frontlight 16", "LCD Frontlight 32", etc. etc.
eg. "Rotation Portrait", "Landscape Left", etc. etc.
eg. "Puzzles gSoko"
eg. "ipaqstat normal", "ipaqstat kill"
etc. etc.
my point is that mapping an existing (potentially large) menu into a
PDA app launcher doesn't always work so well. It could get worse as
more storage becomes availabe on PDAs, if you're running debian have a
look at /usr/lib/menu/!
Besides, do you really want five entries just for the terminal? Thats
almost two full rows in portrait mode.

> The specification allows arbitrary name-value pairs. Everything is
> done by convention, so feel free to extend things as needed. Existing
> Debian packages currently use "icon=...", perhaps it would make sense
> to adopt icon32=, icon16=, etc.? The menu generation step could
select
> the icon it prefers from those available for any particular menu
> entry.
Thats good, at least.
There is, of course, nothing to stop fmenu from using the same format
but in a different directory. Or, maybe a better idea - use "gpe=yes"
or a more generic form of it to say "hey, I'd work on a PDA and not be
a pain"? That to me sounds good. It would both fit in the
current /usr/lib/menu scheme *and* allow for the seperation of PDA/non-
PDA packages.

Of course, there'd be an extra performance hit involved for parsing
the extra non-PDA ones but it probably wouldn't be noticable.

> > Another issue is that ATM you can copy files into RAM, have a
> > /mnt/ramfs/fmenu, SIGHUP fmenu & see the new programs. If the
> ramdisk > were to be emptied and fmenu had another SIGHUP, the
> programs would
> > disappear. Can /usr/lib/menu have, say, /mnt/ramfs/menu as well?
>
> No reason why it can't. Should be trivial to make the menu read from
> multiple directories.
What would have to be changed? update-menus would presumably have to
be re-run with a list of menu directories? It would be even better
that way as gtk-menu etc. would also benefit from extra programs.
 
> > I feel that it's important to allow for such things incase
> people have,
> > say, CF cards with programs - whack it in, SIGHUP fmenu, see
> new menu
> > entries - how cool would that be!
>
> Exactly. And what I would like to avoid is inventing two independent
> systems that largely solve the same problem.
>
> Thanks for your time!
Ditto. Note that I'm not trying to argue the point, more make sure
that we get it right the first time :)

> -Carl
mibus

> Thanks for all your work.
Heh ;-)
No worries - it was only because *I* wanted it done.

 
Received on Thu Jan 03 2002 - 18:12:40 EST