Moin, On Sun, 16 Dec 2018, 16:02:20 +0100, Maurizio Galli wrote:
Something like that, maybe with moving stuff into a backup location instead of deleting it
Yes should be easy enough to do with something like: mv ~/.config/xfce4/xfconf ~/xfconf.bak Open to better suggestions.
Don't move it across potential mount boundaries, please. I use directories like ~/.config (and others) as bind mounts to ~/.OS/os15.0/.config (etc.) in order to protect against such incompatible changes (KDE told me a lot in this regard...); so, please move it to ~/.config/xfce4/xfconf.bak, if ever.
(I'm not sure how good other parts cope with xfconfd going away)
To be confirmed, but having xfconfd killed / not running, seems to be a necessary step to correctly regenerate the config files. Also xfconfd is restarted as soon as xfce4-panel is reloaded and personally I did not experience side effects although I cannot completely exclude that.
and with some nice popup window asking to confirm ;-) I am not good at this stuff but I will wrap my head around it to find a way ;-). Should we include this script in the panel package or branding package?
Perhaps a test if a user is running XFCE while these updates should be pulled in would be appropriate. E.g. kernel packages request an explicit confirmation for installation because a reboot would be in place; something in this area might me applicable here, too.
I don't know how long I need to get this one ready but I think I should push the update to Factory ASAP first, or more people will update and risk to mess up their configs.
Cheers,
Maurizio Galli (MauG)
Cheers. l8er manfred