help with "Xfce menu" on panel
Brian J. Tarricone
bjt23 at cornell.edu
Fri Feb 18 01:34:30 CET 2005
Jason Keltz wrote:
> Brian J. Tarricone wrote:
>
>> 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.
>
> I still recommend that Xfce adopt a policy where-by plugins look in a
> users home directory first, and if a file is not there, they look in
> the global settings. It seems this provides the most flexibility, and
> the least redundancy, allowing a user to keep in their home directory
> only files that are changed from the default.
This doesn't necessarily extend to all things. For example, the xkb
plugin allows the user to pick their preferred keymap. There isn't
really a concept of a default here (well, the X server itself manages
the default, I guess), so I don't see the value in having it look in
some system location. For something like the weather plugin, it makes
sense to have an admin-configurable default, since presumably people
sitting down at that machine would want the local weather. Of course,
if it's a headless machine, and people log in remotely, a default is
rather meaningless, as they could be anywhere.
So I agree with you in that sometimes looking to the system location is
a good idea, but I think having a "policy" is a bit much.
At any rate, looking in the system location is trivial - one can easily
check both by using xfce_resource_lookup(), and it'll return the first
one found.
>> 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".
>
>
> While I agree that the name is irrelevant to the average user, Xfce at
> present has a very clean source tree. It is important to clean up
> things like this to keep it that way. This is just a personal opinion
> though, and I know this has nothing to do with the actual running of
> the software. I'd just like to see Xfce stay as clean as it is.
My main objection to renaming the file is that it would lose all its CVS
history, for what I see as little to no gain.
>> 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.
>
>
> A "use default desktop menu" would solve this particular problem for
> me, but still leaves the generic problem that someone couldn't do the
> same thing with any other menu -- ie. having global settings that are
> used in the event that the user does not have the file. Maybe, by
> default, if a person specifies a path not beginning with "/" for the
> XML file, the system could look in HOME/.config/xfce4/PATH. if that
> file doesn't exist, check in sysdir/etc/xdg/xfce4/PATH. Clicking the
> "use default desktop menu" would simply specify "desktop/menu.xml" as
> the file. If the user wanted to have other menus that have global
> defaults, this could be done with something like
> "panel/xfcemenu/menu1.xml". That's just my personal opinion.
> I understand what you're thinking -- you wrote a module to allow you
> to provide the desktop menu as a plugin because that's what you
> needed. Someone wanted something else, and now I want something else,
> and I'm sure other people will want other things... I have ways of
> making Xfce do what I want to do through a hacks, but I just would
> prefer Xfce to do the work for me.
> I appreciate your hard work on the module, and will report the issue
> as a bug.
> Thanks.
I like that kind of solution for its flexibility, but it's absolutely
terrible when it comes to usability. This feature isn't easily
discoverable, and it's not always easy to decide what to do without
requiring user intervention (and, to most users, they probably won't
immediately understand why the question is even being asked). For
example, if the user opens up the file chooser, and selects
~/.config/xfce4/panel/panelmenu.xml, what do we do? Do we assume that
they really mean (one of $XDG_CONFIG_DIRS)/xfce4/panel/panelmenu.xml?
Or do they really mean they just want us to load that one file, and none
other? The plugin shouldn't be making that decision for the user, and
adding an option for it just sounds confusing.
So, I'm going to stick with what I originally said - a checkbox to use
the default menu, or an option to specify a menu file (which will allow
for interpolation of shell variables). Actually, as a hidden easter
egg, I'm thinking about looking specifically for $XDG_CONFIG_DIRS, and,
in that case, testing each directory in succession. But we'll see how
hackish that is. At the very least, it won't interfere with normal
operation.
-b
More information about the Xfce
mailing list