updating menus

A7r and I had a discussion about menu updating a few days ago. Since
having that discussion, I looked at Debian's update-menu system. It
does pretty much what we want, although the details we agreed on
differ from Debian's. So, my question is: do we want to be
gratuitiously incompatible with Debian or do we want to run with what
they designed?

My feeling is that Debian's stuff is lightweight enough for us to run
with it. Any program that wants a menu entry just includes a small
file in /usr/lib/menu. Any window manager that wants its menu updates
includes a program to do so in /etc/menu-methods/. I'm not sure I
agree 100% with their menu category choices, but wasn't that
predictable?
-russ

<nelson> Blackbox's menus need work. Really, they ought to be dynamically created.
<nelson> For example, Input Methods should include fstroke if I've got it installed.
<a7r> yup.
<a7r> We need to have a v0.5 developer meet.
<nelson> suggestion: that the window manager menu be created by grovelling through a directory tree, and that programs which want to be on the menu install a shell script in the right place in that directory tree. The window manager package should have a script which rebuilds its menu from the tree.
<a7r> there's also the question of dealing w/ more than blackbox.
<jacques> nelson: like wmx ?
<nelson> a7r: that's what I mean. The application menu tree should be window manger-agnostic.
<a7r> nod.
<nelson> The tree should either have a shell script, or a symlink to the program. Doesn't have to be a shell script.
<jacques> nelson: something I have wondered about the shell script thing...
<a7r> I'd like to see a directory per menu entry, with scripts, and descriptions and whatever underneath the directory.
<jacques> nelson: does that leave a shell running as long as the chosen app is running?
<nelson> Why? Why not have the name of the entry be the menu entry? Yes, spaces and all.
<jacques> that would be hard on menmory
<nelson> jacques: no no, the shell script should 'exec' as the last thing it does.
<a7r> jacques: no.. the shell can exec what ever it wants.
<jacques> nelson: heh, OK. that's what I'm doing wrong then
<a7r> nelson: because there's more than just a name, there's the app's icon, the description, and a bunch of other potential shit.
<nelson> Hrm.
<nelson> What description is needed for the purpose of the menu?
<a7r> look at NeXTSTEP/Mac OS X as an example of the way to do things.
<nelson> And do you want to have menus with icons in them (blargh)
<a7r> because like I said, there's more to this than blackbox.
<a7r> this directory structure could be used by an app launcher.
<nelson> Okay, how about a "Menu Item" file, and a "Menu Item.icon" file for the icon?
<a7r> Menu Item Description. File?
<a7r> What happens when you want to have different localizations for a different app?
<nelson> Sorry, my imagination is limited. I don't see the need for a description. Make the menu item more descriptive.
<jacques> a7r: sounds like you want a database :-)
<a7r> Nope. I'm imaginging us having all sorts of different apps.. lets just make it extensible to begin with.. different apps that this generates can choose to ignore functionality.
<a7r> jacques: what do you think a filesystem is. ;>
<nelson> Yo creo mas Espanol a lo que pickar por el menu.
<a7r> Haha
<a7r> Windows has a registry.. UNIX has a filesystem.
<nelson> Dare I suggest that localization should happen at the package level?
<jacques> one XML file per menu entry
<nelson> As in, if you want Spanish, install the Spanish-locallized package set.
<a7r> nelson: that's a potential.. what if you want to have both installed?
<a7r> different users w/ different localizations.
<nelson> Don't borrow trouble.
<a7r> Don't make constraints you don't need to.
<a7r> it doesn't hurt you to have them directories.
<a7r> and it gives you extensibility.
<nelson> The constraints are physical, and very real.
<nelson> Okay, so make the menu directory go under a localization tree.
<a7r> what happens when you want to add a large and a small icon for things?
<nelson> /var/po/LANGUAGE/menu/foo
<nelson> OMG, okay, let's support 320x240 icons.
<jacques> cool
<jacques> :-P
<nelson> /var/po/LANGUAGE/menu/"Menu Item".big-fat-hairy-icon
<a7r> you done yet?
<nelson> I haven't yet started.
<nelson> Okay, okay, okay, so make it a directory:
<nelson> /var/po/LANGUAGE/menu/"Menu Item"/big-fat-hairy-icon
<a7r> have you looked at the real size difference?
<a7r> by putting a directory in place, I mean.
<nelson> No, not really. It's not that important to me. All I'm arguing about is one file, and if we make the directory name be the name of the menu item, then it's a wash.
<a7r> Great.
<nelson> So, like, pick a directory, and I'll write it up in the wiki, and write some shell scripts to rewrite blackbox-menu (e.g.)
<a7r> nod.
<a7r> the only thing I'm thinking about is how to store icons and such for directories that contain elements.
<nelson> Cross that river when we get to it? As long as there's a place to put them, we can decide on the name of the icon file when we have software that will use them.
<nelson> No point in bloating packages with icons that nobody uses.
<a7r> you're right, but I'd like to have the naming hammered down.
<nelson> How about the obvious: .../icon ?
<a7r> that's fine for apps, but if a directory has an icon, it means you can't have a menu item named icon.
<nelson> Well, but isn't a directory icon going to be called ".icon"?
<a7r> nod, having them as .files is fine, but then I wonder if the apps shouldn't be done by .file to make it easier on scripts.
<a7r> it could just be a differentiating factor.
<nelson> I'm sorry, I don't see how that makes it easier. What am I missing?
<a7r> it doesn't make it really hard, it just means that apps wouldn't use dot-files, and directories would.. we could make them both use dot-files, or just expect that directories have dot-files, and apps don't.
<a7r> I don't like having slightly different interfaces.
<nelson> Yeah, but the .icon is the icon for the directory and "icon" is user data -- the icon for the menu item.
<a7r> OKay, let's go w/ the difference for now.
<nelson> k
<nelson> But what directory does the menu item go into, and what are the suggested subdirectories?
<a7r> also, how are we planning on controlling ordering?
<a7r> a directory is going to need information about the order of the menu items.
<nelson> Hrm. Alphabetical?
<a7r> Nah.
<nelson> And what about a <hr>-style delimiter?
<a7r> Yeah.
<a7r> there should be a config file.
<nelson> Sigh. I thought that the whole point was to get away from a config file, and adapt to whatever set of packages happens to be installed?
<a7r> Yup.. then let it be optional.
<a7r> it needs to be supported, though.
<nelson> sysset applet.
<nelson> :)
<a7r> haha
<nelson> Well, why not? You don't like the order, fucking fix it yourself.
<nelson> Damn whiney lusers.
<a7r> yup.
<a7r> or whiney developers having to put out releases, like me. ;>
<nelson> Okay, how 'bout this rule, then? Newly-discovered packages get appended to the end of the existing menu file.
<nelson> Newly-deleted packages get whacked from the menu file.
<a7r> or, to make it more of a no brainer, if they're not listed, don't put them in at all, and have the default behavior be to tack them on willy nilly.
<nelson> And sysset lets them move menu items around, insert delimiters, comment out items.
<a7r> nod.
<nelson> What do you mean "if they're not listed, don't put them in at all"?
<a7r> heh, two half baked thoughts in one sentence: if they aren't in the directory's ordering list, then whatever app is using the structure should just append them to the end in indeterminate order.
<a7r> although, if everyone adds new entries using an abstraction (i.e. registers their app some how), this will be less of an issue.
<nelson> Package installation time is no time to adjust the order of menu entries.
<a7r> that's why I'm thinking that when an app is registered, it just doesn't worry about ordering, and doesn't append itself to the ordering list.
<nelson> Oh, I was figuring that we just let users edit the menu file directly. No ordering list needed.
<a7r> I was thinking something like:
<a7r> 0 menu/Applications/PIM Apps/Expenses/icon
<a7r> 0 menu/Applications/PIM Apps/Expenses/description
<a7r> 4 menu/Applications/PIM Apps/Expenses
<a7r> 8 menu/Applications/PIM Apps
<a7r> 0 menu/Applications/.icon
<a7r> 12 menu/Applications
<a7r> 0 menu/Utilities/.icon
<a7r> 4 menu/Utilities
<a7r> 4 menu/Configuration
<a7r> 4 menu/.ordering
<a7r> 28 menu
<nelson> Nahhhh. Not necessary. We can't predict how users might want to order items.
<a7r> huh?
<a7r> Yeah you can.
<a7r> wait, .ordering doesn't get setup when the package is installed.
<a7r> .ordering is the file edited by sysset.
<nelson> Ahhhh, I see.
<nelson> I was thinking that the window manager would have a menu file, a shell script to append a new item to it, and a sysset applet to edit it.
<a7r> nod, but there's no reason that couldn't be used in a more general sense.
<nelson> When ipkg installs something, it (special hack) runs the shell script, which looks for created or deleted applications.
<a7r> nod.
<a7r> Rendering the directory structure into appropriate config file formats.
<nelson> I'm just trying to keep things simple without limiting configurability.
<a7r> yup.. having them as .ordering or something makes it pretty extensible.. having multiple ordering formats if necessary.
<nelson> I don't think people care that much -- and if they do, they can run sysset.
<a7r> I care.
<a7r> I have apps that I know are going to use that kind of functionality.
<a7r> lets hack some stuff up, and see what we've got.
<nelson> Okay. There aren't going to be third-party apps all that fast anyway, and they'll looooooove this functionality so much they'll immediatley add support for it, eh?
<a7r> I'm going to be writing apps for this kind of thing soon.
<a7r> so regardless of what other people are doing, I'd like the functionality.
<nelson> Should I target blackbox first?
<nelson> It's the only wm so far, right?
<nelson> Oh, one other thing to remember: we want to have a "Startup" menu, so that /etc/init.d/x knows what to start up,
<a7r> Nod.
<a7r> Yeah, blackbox is the man to go after for now.
<nelson> Okay, will do. But must make Indians happy right now....
<a7r> Werd, hasta.
<nelson> If you get more ideas/inspirations, throw them up and I'll look at 'em in the morning.

-- 
-russ nelson <sig@russnelson.com>  http://russnelson.com
Crynwr sells support for free software  | PGPok | Microsoft rivets everything.
521 Pleasant Valley Rd. | +1 315 268 1925 voice | Linux has some loose screws.
Potsdam, NY 13676-3213  | +1 315 268 9201 FAX  | You own a screwdriver.