testing panel plugins

[Nick Schermer]

On Wed, Jan 19, 2011 at 3:57 PM, Florian Rivoal <frivoal at gmail.com> wrote:
> On Wed, 19 Jan 2011 08:21:00 +0900, Nick Schermer <nickschermer at gmail.com>
> wrote:
>
>> On Tue, Jan 18, 2011 at 7:05 PM, Mike Massonnet <mmassonnet at gmail.com>
>> wrote:
>>>
>>> 2011/1/18 Yves-Alexis Perez <corsac at debian.org>:
>>>>
>>>> On mar., 2011-01-18 at 18:58 +0100, Mike Massonnet wrote:
>>>>>
>>>>> I don't understand what you are trying to achieve. If you put desktop
>>>>> files in the panel config dir, for 4.6, what are you expecting?
>>>>
>>>> I guess that they appear in the Panel / Add new item menu?
>>>
>>> I re-read the directory name...
>>>
>>> Right! So yeah, if it ain't working you can file a bug IMO :)
>>
>> Not a bug, of at least if was left out on purpose. The reason was
>> operating system that have 32 and 64 bit libs/apps on 1 system. They
>> cannot be mixed, but were detected by the panel. /lib and /share are
>> hardcoded during compile time (also the X-XFCE-Module-Path thingy
>> became unneeded), so easy to lookup, in ~/.local this is not the case
>> and could results in crashes is 64/32 are mixed.
>
> I see. In my case, for plugin development, I can just put the .desktop files
> under /usr/share.... mildly inconvenient, but nothing severe. On the other
> hand, it makes it completely impossible for people who do not have root
> access to install and use plugins under their account only.
>
> I wonder if it would be possible to find a way to let people have plugins
> and .desktop files under their account, while avoiding the 32/64 bit
> compatibility issues you mentioned.

Well its open for discussion. I've no idea which distros combine 32/64
bit; seems a bit pree 2000 to me. I can also configure-option this and
make it behave like the old panel by default; when the configure
option is enable, we only allow strict location in the same prefix as
the panel.

Nick