10:57 a.m.
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(a)ccrma.Stanford.EDU>
To: Greg DeKoenigsberg <gdk(a)redhat.com>
Cc: nando(a)ccrma.Stanford.EDU
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(a)ccrma.Stanford.EDU>
To: planetccrma(a)ccrma.Stanford.EDU
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