help with "Xfce menu" on panel

[Brian J. Tarricone]

Jason Keltz wrote:

> Brian J. Tarricone wrote:
>
>> Nope.  The menu plugin for the panel is intended to be independent of 
>> the desktop menu (uses the same code, but, as you've found, not 
>> necessarily the same file).  Why not just start off by copying your 
>> premade menu to ~/.config/xfce4/desktop/menu.xml?  Then edits to that 
>> via the desktop menu will automatically show up in the panel plugin 
>> menu.
>
>
> Hi Brian.
>
> I have a couple of issues with this.  I'm interested in your feedback.
>
> First -- when it comes to referring to configuration files in Xfce, the
> default behaviour seems to be to always check the users home directory
> first (~/.config/xfce4).  If the file does not exist there, it checks
> the global settings (sysdir/etc/xdg).  The behaviour in this plugin
> differs from what seems like the "default" behaviour.

However, all the panel plugins, in general, always (and only) look for 
config files in the user's home directory.  I'm not necessarily 
disagreeing with you here though.  It does seem a bit inconsistent.

> Even if I did copy the menu.xml file to each users home directory, it
> seems to me that I am forced to use a full path to the filename.  That
> is, I need to reference "/home/user/.config/xfce4/desktop/menu.xml". 
> There are variables like XDG_CONFIG_HOME that I should be able to use 
> to hide the details of "/home/user/.config", but unless I'm wrong, and 
> I may very well be, there doesn't seem to be a way for me to use the 
> XDG_CONFIG_HOME syntax in Xfce.  Specifying the explicit 
> "/home/user/.config" just seems wrong to me.

This is a bug then.  I thought the filename handler in the plugin was 
expanding shell variables first, but I guess not.

> In my case, many users will not change their default settings because
> the settings that I have provided are more than reasonable for our
> systems.  In my opinion, this should mean that if I make a change to the
> global "Xfce menu" file (in this case, the desktop menu), those users
> who have not made changes to their own personal copies should get the
> new global file.  For example, if I were to install a new piece of 
> software and would like to make that selection available globally, I 
> could add it to the global desktop menu file.  If I copy the file into 
> each users home directory, I can no longer make global changes to the 
> file.

Agreed, that's annoying.

> The menu plugin shares the same code as the "desktop menu", yes, and if
> I'm not mistaken, the location of this code is in
> xfdesktop-4.2.0/panel-plugin/desktop-menu-plugin.c... If this is really
> a "desktop menu plugin" then symantically, I would expect for it to load
> the desktop menu, and track its changes.  If this isn't the case, and 
> its functionality has become generic so that it doesn't relate 
> directly to the desktop menu any longer, I would think you might want 
> to change the name of the file.  if it isn't intended to update as the 
> desktop menu updates, it certainly shouldn't be called 
> desktop-menu-plugin!

This is mainly for historical reasons, but, really, the name of the 
source file (or even the shared object) is irrelevant.  The only name 
that's intended to be user-visible (and therefore describe its 
function), is the name showed in the panel's Add Item dialog - "Xfce Menu".

> Finally, it appears that on top of all of this, the module does 
> actually what I want/need it to do, but only for a little bit! There 
> is definately a bug here....
>
> If I:
> erase .config and .cache,
> login,
> add an "Xfce Menu" to the panel using the location of the global
> "menu.xml" config file (which happens to be the default!)
> add an entry to the "Desktop menu" using the "desktop menu" settings, 
> and the "Edit desktop menu" button.  From what you have said, this 
> should not update my Xfce menu.  However....
> Now, when I click on the "Xfce Menu" on the panel, there is a pause as
> it updates, and it actually does indeed update to show the entry that I
> just added to the desktop menu!  If this continued to operate like 
> this, I wouldn't have a problem.  It has indeed copied the desktop 
> menu into my home directory, and that copy shows my change even though 
> the properties of the "Xfce menu" still show that it is pointing at 
> the global menu.xml file.
>
> If I then logout and then back in again, the "Xfce menu" on the panel
> still displays my added setting to the desktop menu in my last session.
> However, if I open up the "Settings" and add another item to the desktop
> menu, and click on the "Xfce menu" on the panel, there is another 
> pause as it reloads again, but this time it displays the original 
> global menu.xml file without either of the changes that I just made.
>
> Now I'm definately confused!

Yeah, so am I.  I'm betting the menu code doesn't properly remember when 
it has its filename explicitly set over when it's just supposed to use 
the default.

I agree that this is confusing and somewhat inconsistent, though.  When 
I first wrote the plugin, it simply did as you currently expect: it 
mirrored xfdesktop's menu, and did whatever it did.  Then someone asked 
to be able to specify a menu filename, so they could either have 
multiple buttons with different menus, or just have a different menu 
than their desktop menu.  So I implemented that, but it seems the 
original behavior got lost/broken somewhere in there.

I think the real solution here is to change the plugin so it has a "use 
default desktop menu" checkbox, which disables the filename entry box 
(this should be the default, and it'll do exactly what you want).  Then, 
if the user decides to override that with a filename, it should always 
use that filename, regardless of anything else that happens.  I'll try 
to fix this for 4.2.1.  If you wouldn't mind, could you open a bug on 
bugzilla.xfce.org?  I probably won't be able to get to this immediately, 
and I tend to forget things if I'm not reminded.

Thanks,
Brian