Re: fmenu

> > Any more requests?
> Yep, got one more idea over the weekend ;)
Cool.

> Can it be done that tapping on a icon and keeping it pressed pops up a
> menu after some timeout?
I'd thought of that; WinCE does something similar with the contacts, I
don't know about the menu though.

> This would be very nice to add options like "instead of starting it once I
> really want to start this program as a new instance of it" or later on a
Good thought.

> properties editor or ...
That's the one I'd come up with.
> But that's really for the future. For now it is already more than we all
> could expect in this short time!
What can I say, I was bored :)

> Another thing that could be important is rereading the program list.
> Say you have installed a new applications which conforms to our standards
> and has added itself to the launcher. When will it be displayed?
> Could fmenu be SUGHUPed to reread it?
It already can, and has been since I first released it (IIRC).
I just never bothered to mention it. There is a small memory leak every
time it happens though; I'm not sure what from. The last time I ran
memprof it didn't show any leaks. (It's probably Gtk+ and the leaks get
unref'd at the end or something).
[Just noted your post saying you've found it]

> > Things I have in mind:
> > * single-instance only: but how? /proc/, ps, xsingleinstance[0]?
> I still vote for xsingleinstance ;)
Ok. I have reservations but they are fading fast, esp. given that we'll
have to change to the window if it's already open - and for that we need
the name anyway.

> > * feedback on programs that don't run
> Coming!
;-D

> > * add-to-menu-only-if-the-program-exists
> Hopefully not needed when the system is ready and the applications install
> their files themselves.
Only if everyone who makes packages does the icons; in theory it works
well but not always - eg. GNOME has menu entries for emacs and heaps
others IIRC.

> > * automatically determining the number of columns to have
> > (eg. for landscape)
> Good thought ;)
I'm looking into the GIMP's toolbox's widget, gtkwrapbox, to do it.

> > * reading /usr/lib/menu
> > The last point brings an interesting dilemma (IMHO): Do we even want to?
> > It is the 'proper' place programs get installed, but there are problems
> > mapping it to a PIM environment. Do we take the first level as the
> > groups, the second level as the programs and ignore all others? (eg.
> > PIM/* gets put in, but Utilities/Suspend/* won't). Note that this way
> > will stop the terminal from being in the launcher. Or should it be left
> > as it is, with a seperate menu?
> AFAIK we should just ignore it, see more below...
You mean ignore /usr/lib/menu and use only /usr/lib/fmenu, as it does
now?

> > [0] - the problem is we have to know the name of a window the program
> > creates IIRC.

> I think we can do some assumptions as WE now set the standard for our
> environment. New applications/applets and so on have to conform to it or
> might end up beeing not so nicely integrated. That's it.
> Why?
> We cannot provide solutions for any possible combination or configuration.
> For conformant applications we specify it. Now.
> You already started: Tab-icons are 16x16 pixels, dot.
Uh, I think i just said that they *should* be, not that it won't work
otherwise - if you have a 800x600 or so flat-screen ebook (or whatever),
why stick with 16x16 icons?
Ok, this is G*P*E, but still - why force the issue if you don't have to.
Also, even with conformant programs we have to know the window's name -
the menu item would have to be kept up-to-date. Of course, it should
really switch to if it's already running; for that we'll need the title.
(I guess, anyway).

> We can also specify that the configuration for your fmenu has to have an
> additional field for the proper window-title. We will have to know this
> anyway since the window manager will also get a list of known windows
> (applications). If you look at other systems, like good-old fvwm for
> example, it was exactly the same way to apply the styles to certain
> windows.
Why will we already have to know this just because the WM does? But
anyway, you've changed my mind :) We'll also have to regex match for
programs like dillo.

> I wouldn't have any problem with that approach. It is easy and IMHO the
> cleanest.
Should the config file be changed? Adding fields to the end of the file
seems icky.

XML is probably total overkill; but we want something *really* easily
parseable. (maybe just "name Dillo\nexec /usr/bin/dillo\nWindowTitle
Dillo*\nicon /usr/share/pixmaps/dillo48.png\n" etc., replacing \n with,
well, '\n' where appropriate).

Also, should the group's icon be configurable? And how - another config
file, one per group? Or is /usr/share/pixmaps/group_%s.png enough given
that the system is in a 'known state' (in theory).

I definately think that choosing text/icons/both for the tabs should be
an option; maybe per-group but probably not.

> nils faerber
Gotta go, got TV to watch. (yes, at midnight :-)
mibus

-- 
Robert Mibus <mibus@bigpond.com>
"If you can't make it good, at least make it look good"
 (Bill Gates)