Bug #257... what do we do ?

[Brian J. Tarricone]

all right... then here's my suggestion on how to proceed.  we'll have 
two main directories that we care about:  ~/.config/xfce4/ and 
~/.cache/xfce4/.  the bulk of data from ~/xfce4 will move to 
~/.config/xfce4, but they need to be organised better.  the only _files_ 
that should be in the toplevel directory should be Xft.xrdb and 
xinitrc.  if there are other global xfce4 files, those too.  everything 
else should be in an app-specific directory.  personally, i'd like to 
see the app-specific config files be renamed to 
settings.{xml,rc,whatever} to be consistent.  i'd suggest that panel 
plugin config files go in ~/.config/xfce4/xfce4-panel/plugins/  (they 
can create subdirs for themselves if they have more than one config 
file, or just use (plugin_name).{xml,rc,whatever}.  the one exception to 
this is the MCS manager.  so, i'd like something like this:

~/.config/xfce4/
|- xfce4-panel/
|  |- settings.xml (old xfce4rc)
|  `- plugins/
|     |- weather.xml
|     `- notes.xml
|- xfdesktop/
|  |- menu.xml
|  `- backdrops.list
|- xfce-mcs-manager/
   |- backdrop.xml
   |- display.xml
   |- gtk.xml
   ...
   `- xfwm4.xml

and so on.  my first reaction is that this is overdoing it, and there 
are way too many directories, but i think this is more consistent with 
the XDG spec, and just more organised in the end.

as for ~/.cache/xfce4/, it should be organised the same way.  the 
session data is already there, the xfdesktop menu cache is already there 
(unfortunately, there's no way of making the xfdesktop cache file and 
the panel plugin cache file go to a different location).  the xffm 
history files and such should go there as well.  comments?

after all the locations are worked out and implemented, i'll work up a 
script to migrate old settings, and xfce4-session can run it and then 
touch ~/.config/xfce4-session/config_migrated or something, and never do 
it again.

    -brian


Olivier wrote:

>On Mon, 2004-07-19 at 22:52, Brian J. Tarricone wrote:
>  
>
>>so what'll it be?  shall we make the change, or resolve the bug 
>>"wontfix"?
>>    
>>
>
>Well, we can do it, but please, don't count on packagers to fix the
>potential issues that may arise because of such a change...
>
>Cheers,
>  
>