Hi,
On 4/5/06, Aaron Levinson <[EMAIL PROTECTED]> wrote: In order to get
an empty menu structure, all I did was use ./configure without any
options. An examination of the source code demonstrates
that
it uses the OTHERS_MENU_CONF_DIR define for the default menu location
on
disk, and OTHERS_MENU_CONF_DIR gets defined as
$(sysconfdir)/others-menu.
When using ./configure without any options, $(sysconfdir) (along with
other directory variables) starts at /usr/local, and the 770 file
structure doesn't use /usr/local for anything. At run-time, because it
cannot find the others-menu directory, no menu entries are displayed.
Too bad the others-menu location is hardcoded this way. Seems like it
might be appropriate to use gconf for this.
I think you mean "Too bad the others-menu location is build-time
configurable" as that's what it is...?
If you build to a different prefix (/usr/local) and the apps install
their stuff in another prefix (the usual /etc), is it really a
surprise they are not found?
In any case you need a predefined location for the .desktops (so that
app-devs will know where to put them), so what would be the benefit to
have it in gconf?
Is that not the case that on debian based systems it is the communly
used aproach that prefix defaults to /usr and sysconfdir defaults to
/etc right?
Which is different from the default of the autoconf as annoying as
it can be. The lesson to learn is that "make install" is bad
and only "fakeroot dpk-buildpackage -nc" should be used when developing
debian like stuff. :-)
pkgconfig here is a nice thing to have for the applications.
The bigger problem is that the actual desktop entry paths are not
according to the latest standard described in freedesktop.org
menu specification...
Br,
Sampo
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
