GNOME Bugzilla – Bug 691461
Debian testing package 3.5.3-1 does not support Xfce
Last modified: 2021-05-25 17:44:45 UTC
I'm working on the unofficial LMDE Xfce: http://forums.linuxmint.com/viewtopic.php?f=61&t=118890 and found out that there were some naming issues, and the deb would pull in a large amount of gnome dependencies when running Xfce. I found Alacarte in github and assumed that it was alright to create a pull request there. A user however, mentioned that you'd probably never see the change, and advised me to file a bug here. You can find the pull request here: https://github.com/GNOME/alacarte/pull/1 P.S.: For the unofficial LMDE Xfce I repackaged the patched 3.5.3-1 as 3.5.4-1
It seems the GNOME repository is out of date. I do not know who maintains it, but official sources are here: http://git.gnome.org/browse/alacarte And it contains several fixes towards using alacarte under other DEs: http://git.gnome.org/browse/alacarte/commit/?id=a4db6799f41947b5cd08231e77d41c561d94170a Setting $XDG_MENU_PREFIX is the proper way to select the correct menu. gnome-panel is used for gnome-panel-desktop-item-edit. It's been on my TODO list to implement the edit dialog internally in alacarte. Otherwise, what naming issues are there?
Unfortunately $XDG_MENU_PREFIX is not always set and returns None. To workaround this: You know where the applications.menu file is located. If you glob that, you'll get the appropriate menu file. At least, that was my approach to overcome an empty XDG_MENU_PREFIX. To overcome the desktop-item-edit issue, I did two things: 1. If not on gnome: exo-desktop-item-edit (defaults to gnome-desktop-item-edit). 2. Drop the line "Recommends: gnome-panel" in the control file. The naming issues I meant are: 1. Not finding the correct applications.menu file name. 2. Not selecting the appropriate desktop-item-edit name. Shall I close the github pull request (as it's not yours)?
(In reply to comment #2) > Unfortunately $XDG_MENU_PREFIX is not always set and returns None. Then that means that a proper menu-spec implementation should load 'applications.menu'. Why is another file being loaded by XFCE?
The default menu path in xfce is: $HOME/.config/menus/xfce-applications.menu Anything else (including no menu file at all) will throw this error (line numbers may differ): $ alacarte Traceback (most recent call last):
+ Trace 231366
main()
app = MainWindow(datadir, version)
self.editor = MenuEditor()
self.applications = Menu(util.getApplicationsMenu())
self.load()
if not self.tree.load_sync():
return info.invoke(*args, **kwargs)
Sorry, I need to clarify this: Anything else then xfce-applications.menu will not load the proper menu. If this is changed into gnome-applications.menu, Alacarte will throw the above error (but will not show the menu). This also happens if you point to a custom menu file (which can have any name the user desires).
What sets that path? Is it hardcoded in XFCE? Debian? Mint? alacarte is a menu-spec compliant menu editor, so that means that we respect $XDG_MENU_PREFIX and use that to build a path to the editor: http://standards.freedesktop.org/menu-spec/menu-spec-latest.html#paths Software like gnome-menus, which Alacarte uses, sets this environment variable to determine which menus file to load: http://git.gnome.org/browse/gnome-menus/tree/libmenu/gmenu-tree.c#n412 I will not add DE-specific hacks to alacarte or gnome-menus to assume $XDG_MENU_PREFIX be "xfce-" when detected to be running under that DE, which will break other distributions that ship XFCE but don't use a separate menus path. The standards-compliant way to configure the menu path chosen is to set $XDG_MENU_PREFIX.
Created attachment 233151 [details] xfce4-panel.xml with custom menu file setting
OK, so it looks like the issue is that users can choose which menu they want to show. I'm fine with allowing another menu file to be specified on the command line, so that whatever starts alacarte has a chance to provide another menu file to the editor. I'd still stress that if XFCE/Mint wants to ship with the default being "/etc/xdg/menus/xfce-applications.menu", they really should be setting $XDG_MENU_PREFIX, as specified in the standard.
Setting XDG_MENU_PREFIX I can live with. So, no problem. Allowing to startup alacarte with a menu path parameter poses another problem: that should be picked up by the maintainers of the applications menu, and I simply don't have the time at the moment. Isn't that something you would like to pick up and coordinate with them? And how would you tackle the gnome-desktop-item-edit/exo-desktop-item-edit issue?
(In reply to comment #9) > Setting XDG_MENU_PREFIX I can live with. So, no problem. > > Allowing to startup alacarte with a menu path parameter poses another problem: > that should be picked up by the maintainers of the applications menu, and I > simply don't have the time at the moment. Isn't that something you would like > to pick up and coordinate with them? I may be able to do that. Unfortunately, I don't know much about XFCE. Does XFCE allow you to launch alacarte from the applications menu applet directly? Do you know what the module name is for the XFCE applications menu, so I can find where they're launching alacarte, or other menu editors? > And how would you tackle the gnome-desktop-item-edit/exo-desktop-item-edit > issue? I'd replace gnome-desktop-item-edit entirely, and drop the gnome-panel dependency now by building a dialog replacement in-tree. I'll try to get to that today.
(In reply to comment #10) > I may be able to do that. Unfortunately, I don't know much about XFCE. Does > XFCE allow you to launch alacarte from the applications menu applet directly? It does in the latest Xfce 4.10: when alacarte is installed and a default menu file is used, it shows a button to launch alacarte > Do you know what the module name is for the XFCE applications menu, so I can > find where they're launching alacarte, or other menu editors? I think it's libgarcon-1-0 > I'd replace gnome-desktop-item-edit entirely, and drop the gnome-panel > dependency now by building a dialog replacement in-tree. I'll try to get to > that today. That's fast!
(In reply to comment #11) > I think it's libgarcon-1-0 I couldn't find any reference to launching alacarte in this project. I did find a bug reference: http://git.xfce.org/xfce/garcon/tree/garcon/garcon-menu-merger.c#n1008 For now, I've pushed the behavior that allows users to specify an alternate menu basename as the second argument of the command line.
OK, it took a little bit longer than I may have wanted otherwise, but I've replaced gnome-desktop-item-edit with a built-in editor, and the code's a lot cleaner. I haven't extensively tested it, so any help would be appreciated.
I'll take a look at it this weekend.
I'm afraid that the right ui's are not commited to git (3 .ui files in data directory). This is what I get when I start alacarte: (alacarte:4994): Gtk-CRITICAL **: gtk_accel_label_set_accel_closure: assertion `gtk_accel_group_from_accel_closure (accel_closure) != NULL' failed (alacarte:4994): Gtk-CRITICAL **: gtk_accel_label_set_accel_closure: assertion `gtk_accel_group_from_accel_closure (accel_closure) != NULL' failed Traceback (most recent call last):
+ Trace 231372
app.run()
self.loadMenus()
self.loadMenu({ None: None })
for menu, show in self.editor.getMenus(parent):
Unfortunately, the set_accel_closure issue is a GTK+ bug as far as I can tell, but I'll ask someone about it. The second issue sounds like you didn't re-generate the "alacarte" runner script. I've pushed a commit to simplify the runner script so that this won't happen again, but you'll need to regenerate it.
Aha, I cannot overwrite the old files in the deb file with the new files? How do I do re-generate the "alacarte" runner script? The install readme seems out-of-date and the autogen.sh bash mentions" "You need to install the gnome-common module and make sure the gnome-autogen.sh script is in your $PATH." which is logical: I'm running Debian with Xfce.
Unfortunately, the build scripts rely on GNOME infrastructure, and that's unlikely to change. You might be able to get by running "autoreconf" and then "./configure"
I've been at it for the past three hours and was unable to build alacarte. Is it possible for you to create a deb file? If not, I'm afraid I have to look for an alternative.
I don't have a Debian system available at the moment, so I can't create a .deb file. It shouldn't be too hard to build alacarte from source. gnome-common shouldn't pull in anything else gnome-specific, and it's a fairly small package that only has some macros and scripts for helping to build software. Is there a reason you are against installing it?
No, not at all, but (even on Ubuntu) it keeps throwing missing dependencies that are not in the repositories. After three hours trying, I throw in the towel.
That's very interesting. If you'd like me to help you help get it built on IRC, I'd be more than happy to do that. #gnome-os on irc.gnome.org is usually where we deal with building/compiling issues.
I appreciate your genuine intention to help, I really do. But, for me it's too much effort for something that potentially could break things in the future. Continuity and stability of my distributions is my first priority. As long as there's no stable Alacarte package in the repository or otherwise downloadable, I cannot take the risk. Thank you very much for your efforts and I hope that Alacarte will have a debian package for non-gnome desktops available soon.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new enhancement request ticket at https://gitlab.gnome.org/GNOME/alacarte/-/issues/ Thank you for your understanding and your help.