Check this. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- ---------- Forwarded message ---------- Date: Tue, 02 May 2006 23:08:19 -0700 From: Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx> To: Greg DeKoenigsberg <gdk@xxxxxxxxxx> Cc: nando@xxxxxxxxxxxxxxxxxx Subject: [Fwd: [PlanetCCRMA] Planet CCRMA menu tree for fcx] Just to keep you up to date on relevant stuff... (let me know the moment I send too much stuff to your account :-) -------- Forwarded Message -------- From: Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx> To: planetccrma@xxxxxxxxxxxxxxxxxx Subject: [PlanetCCRMA] Planet CCRMA menu tree for fcx Date: Tue, 02 May 2006 22:50:15 -0700 Hi all... I'm starting work on the Planet CCRMA menu tree for fc5[*] - which will later percolate to previous fc versions (I think I know now what I need to do, at least on fc5, some tests today were successful). It used to be (in fc3) that the menu tree _and_ the desktop entries were all part of the Planet CCRMA menu packages. There were several reasons for this, but all (I think) are historical at this point (mainly because I started working on the menus long after I released the packages and I did not want to rerelease everything just to fix them). It makes sense now to fix this before starting to release more stuff (the "menuable" packages I released are not that many so far), and incorporate the categories into the .desktop files included in the packages themselves. The way this would work is that the most important or unique packages (good luck defining what that is!) would show up automatically in the "Sound and Video" menu, and those, and the rest, would be (more or less) neatly organized in the Planet CCRMA submenu tree. If the "planetccrma-menus" package is not installed you would just get the "Sound and Video" menu with the crucial packages there. There are two aspects to this, one is how to split apps into categories, and the second is what visible names to give the categories. Things can be fixed later but the internal category names in the .desktop files will stay for a while, I imagine. Anyway, a good start is better than nothing. So it would be good to take a look at the old tree to see how it looks today, so, this is what I used to do (comments through the list, "_" would be transformed into " " for the menu text): ALSA_Mixers (probably should be changed to just "Mixers"?, hmm, or "Soundcard control"?, this includes general purpose mixers like gamix and card specific programs like echomixer, hdspmixer, envy24control, etc) Digital_Processing Drumming DSSI_Plugins Graphics Jack_Apps (maybe a better name would be just "Jack"? or "Jack_and_friends"?) LADSPA_Plugins MIDI (sequencers _and_ midi utilities) Miscellanea Multitrack Notation Patch_Bays Players Programming Recorders Sequencers (maybe "Sequencers" is redundant given that we have midi already?, not to my eyes at least for now) Sound_Editors Synthesis (should this be part of "Digital Processing"?) System (this should probably go, it contained only "Synaptic" - which really does not belong there - and I can't think of anything else that belongs here) Trackers Video ("Video" could be split, I guess, but that could be done later) [maybe another category for "measuring instruments"? Like jaaa, japa, kmidimon, etc?, can't think of a proper name for that] Each one of the submenus has entries for starting up the app, and then two additional submenus, one for documentation (with links to the online web pages for each program and local documentation when available), and another one for "extra" applications that could be bumped from the main submenu into the subsubmenu. The submenus don't appear if there's nothing in them. In some occasions there could be documentation links and _no_ entry for the program itself, a perfect example is ecasound. It is a command line utility but very very useful. Having it in the menu somewhere is good because it raises awareness of the program for users that don't venture to the command line. I used to have also another submenu for popping up man pages, probably overkill (and something that could be added later). Applications can map into more than one category of course, I'm attaching a file that has a dump of what my old script created so that you can see what I mean. Some examples: ardour:Jack_Apps ardour:Multitrack ardour:Recorders or should we have an "Audio Workstations" category, whatever that means? rosegarden4:MIDI rosegarden4:Notation rosegarden4:Sequencers zynaddsubfx:Jack_Apps zynaddsubfx:MIDI zynaddsubfx:Synthesis freqtweak:Digital_Processing freqtweak:Jack_Apps libfishsound:Programming libgig:Programming liblo:Programming liblrdf:Programming liblscp:Programming liboggz:Programming ... and more ... Anyway, you get the idea. Obviously any categorization will leave someone unhappy but it is better to have something rather than nothing (as is proven by the humongous "Audio and Video" menu in fc4). I'll move fast on this as it has to be somehow solved before I start releasing more packages for fc5 (each package will have the category names hardwired into its .desktop file). One more problem is the contents of the .desktop entries themselves. Usability is not always a priority for linux audio software developers :-) Some packages, if not started with the proper command line incantation just die without warning and that's not good. For example, Jack clients. Some pop up a window and say something if Jack is not already running, others just die and print something to stderr, which will mean that if you start them from a menu you don't see anything. When I generated the Planet CCRMA specific .desktop entries separately from the packages this was less of a problem as I could, for example, make the command line "qjackctl /usr/bin/ardour" in the .desktop file and then qjackctl would first start jack and then spawn ardour and everyone would be happy. A second invocation of a different program from the menu, for example "qjackctl aeolus -J" would find the first instance of qjackctl and then just start aeolus, etc, etc. But this all predicates on qjackctl being there already, which you could mandate through explicit "Requires:" in the packages, but that's certainly overkill (there's no real need for qjackctl to be there, you could be starting Jack in a terminal and all Jack clients would be perfectly happy!). So I feel inclined to just assume that Jack is actually running (for programs that are Jack clients, of course) and just add the command line switches that some programs need to tell them they should use Jack. That can/will break using those programs from the menu with just ALSA, for example. But well, you can't have everything. Otherwise those programs will break when trying to use Jack. Tricks can be done with scripts so that they capture stderr and pop up a window with its contents when the program exits with an error code but then you have to either include the script everywhere or test for it or whatever and again everything is more complicated which is bad. Anyway, that would be a band-aid and not a cure (which would be to fix the program so that it does reasonable things when run from a menu). Enough for now. Wow, this was long... anyone still reading? :-) Any thoughts? -- Fernando
