2 Sep
2014
2 Sep
'14
12:42 a.m.
On Mon, 1 Sep 2014, Philipp Überbacher wrote:
I like the desktop file idea a bit more, simply
because it uses an
existing mechanism. I understand that scanning desktop files could
increase startup time, but I have no idea how long it would actually
take. On my machine I have around 180 files in /usr/share/applications,
but maybe another directory would also need to be scanned. In case it
takes significant time something like a simple cache could help to
speed things up on subsequent runs. I have no idea how long reading
those files takes.
Yes there are other directories to search, but in general they are session
specific and should not have application *.desktop files in them. The one
other place that may need to be looked in would be:
~/.local/share/applications/
For user added files... though to be honest, I do not think alacart or any
user is likely to add anything worth your looking at anyway.
A cache file would help for sure. Keeping the m date in there of the
directory may be enough to know if anything has changed since the last
time.
I don't think that the chicken-egg problem is
significant. You could
suggest to developers to add a desktop file with the necessary
information. I wouldn't require it but strongly suggest it. It is an
almost trivial amount of work.
One has to start somewhere :) Many developers do not make desktop files
for their work, so it ends up getting done by the packager (man pages too
by the way).
> The existing JACK autostart mechanism works fine
as far as I know
No. Jackdbus conflicks with jackd and there seems to be no way for auto
starting jackdbus. There are functions that are not possible without
jackdbus. So having an appliocation autostart jackd kills jackdbus. I
ended up chmod -x jackd.
Thanks for reminding me of the ~/.jackdrc. However, a
simple jackstart
client (or a generic mechanism that can be used for this purpose) would
allow different sessions to use different jack settings. A simple
example: One session may require jack to run at 48 kHz, another at 44.1
kHz, a third might require jack to run at a very low latency setting.
~/.jackdrc does not help in this case.
With jackdbus many of these things can be changed "on the fly". However,
that is not the best as some applications don't like getting these things
changed while they are running. Latency can be changed at any time with
jackd too.
--
Len Ovens
www.ovenwerks.net