On Fri, 25 Mar 2011 02:17:42 +0000 Gustavo Sverzut Barbieri <[email protected]> said:
> On Fri, Mar 25, 2011 at 2:09 AM, Carsten Haitzler <[email protected]> > wrote: > > On Thu, 24 Mar 2011 14:13:25 +0100 Thomas Gstädtner <[email protected]> > > said: > > > >> On Thu, Mar 24, 2011 at 13:34, Gustavo Sverzut Barbieri > >> <[email protected]> wrote: > >> > On Thu, Mar 24, 2011 at 12:19 PM, Thomas Gstädtner > >> > <[email protected]> wrote: > >> >> On Thu, Mar 24, 2011 at 11:01, Gustavo Sverzut Barbieri > >> >> <[email protected]> wrote: > >> >>> On Thu, Mar 24, 2011 at 7:57 AM, Carsten Haitzler > >> >>> <[email protected]> wrote: > >> >>>> On Tue, 22 Mar 2011 20:13:47 +0000 Gustavo Sverzut Barbieri > >> >>>> <[email protected]> said: > >> >>>> > >> >>>>> Hi all, > >> >>>>> > >> >>>>> Recently I had to do a new install and that's the time when you > >> >>>>> realize shortcomings exist :-) For instance I use Gentoo and we > >> >>>>> don't ship gnome-menus or kde-similar by default, so the result is > >> >>>>> an empty applications menu. > >> >>>>> > >> >>>>> Google reminded me of > >> >>>>> http://wiki.enlightenment.org/index.php/E17_and_Efreet with hints on > >> >>>>> how to hack around it. Not good if we're willing to release. > >> >>>>> > >> >>>>> Given that pulling in gnome-menus will bring in lots of unneeded > >> >>>>> stuff just for a handful of .directory or .menu, why not create our > >> >>>>> own and install it with E17 or Efreet? We can get either Gnome or > >> >>>>> KDE files and derive our own, that is always installed and we > >> >>>>> default to it. > >> >>>>> > >> >>>>> Comments, suggestions? > >> >>>> > >> >>>> the problem is.. for this file to work it has to be installed > >> >>>> out-of-prefix.. so we can install it but.. we'd put it in > >> >>>> PREFIX/etc/xdg/menus (ie /usr/etc/xdg/menus > >> >>>> or /usr/local/etc/xdg/menus). you'd have to symlink it from there... > >> >>>> but e's menu config panel and wizard will pick up these locations > >> >>>> just fine. if we call it enlightenment.menu or such... no problems. > >> >>>> of course user will have to select it in wizard or config gui... but > >> >>>> its a few clicks away. > >> >>> > >> >>> I don't see why, user can install --sysconfdir or even append more > >> >>> search paths to $XDG_CONFIG_DIRS > >> >> > >> >> There are some proper ways to handle this: > >> >> 1) Install to ${PREFIX}/share/${APPLICATION}/ and let the > >> >> packager/distribution link to /etc/xdg/... > >> >> 2) Install to ${PREFIX}/share/doc/${APPLICATION}/ and let the > >> >> user/packager/distribution copy it to /etc > >> >> 3) Use E's wizard to put it in ~/.local/share/xdg or wherever this > >> >> stuff resides on a per-user base. This also would allow to use a > >> >> menu-editor. > >> >> > >> >> 3 can be used in combination with 2 or 1. > >> > > >> > Actually it is /etc/xdg/menus/${XDG_MENU_PREFIX}applications.menu > >> > (/etc/xdg being the standard, but you can override with > >> > $XDG_CONFIG_DIRS as well). The XDG_MENU_PREFIX is generally set by DE, > >> > like gnome-, kde-4.4 and similar. > >> > > >> > http://standards.freedesktop.org/menu-spec/latest/ar01s02.html > >> > > >> > It should be always possible to edit per-user as the spec states that > >> > user-local replaces the global if it exists. > >> > > >> > >> That's exactly what I mean. > >> The goal should be to provide the xdg menu as a file and install it > >> into ${PREFIX}/share where such data should be. > >> Then the user can decide if he wants to use it as global menu and copy > >> it to /etc, or the packager can check if another package is installed > >> that already provides an /etc/xdg/applications.menu and can put it > >> there if not. > >> As I said, additionally the E's wizard could provide the menu for the > >> user if no global config exists or if the user wishes to, this way it > >> works for everybody, allows the user whatever to do whatever he wishes > >> (what imho always was E's philosophy), while not making any > >> interaction necessary - also the distributor can chose what he thinks > >> is best for his user (while not robbing him of the possibility to > >> still do whatever he wants). > > > > installing into PREFIX/share/... is pretty useless. a packager can just > > provide their OWN menu file as part of the package if thats what you want > > to do. that's the current situation. it belongs in SYSCONFDIR/xdg/menus - > > it mean that by default is stays entirely within PREFIX so its a > > predictable and containable install AND e can work out of the box. secondly > > we should call it enlightenment-applications.menu. it won't overwrite or > > interfere with any menu files that may be in the menu dir where e installs > > AND e will offer it as an option on start and int is menu config dialog. > > the user can link ot copy it into /etc/xdg/menus or whatever. > > yes, 99% agreed... just don't need to copy as we can force e17 to > lookup into $PREFIX as you said. yup. and if person compiling does --sysconfdir=/etc - it goes into /etc anyway.. and packagers will do that either way and thus get the menu file.. and e ALREADY looks in these common prefix etc dirs for menu files :) well /opt/e, /usr, and /usr/local :) i guess we should make it ALSO look in e's install prefix if it is not already listed :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
