[opensuse-xfce] Updated XFCE brandings still not fully functional for existing users
Hi there, I just installed the latest updates from X11:xfce/openSUSE_Leap_15.0, logged out and in again, and my main panel is screwed up again. Here are the differences between what I had and what I got after the updates: 1. systray got removed, including its settings 2. a separator got added instead Not as bad as with the last updates, but still... HTH, cheers. l8er manfred
Hello Mafred, First of all thanks for bringing up the bug. When you modify your panel, configs are stored here: .config/xfce4/xfconf/xfce-perchannel-xml/xfce4-panel.xml. If the plugins IDs in that config file don't match the file in the root directory, the panel fails to load them or mistakes them for something else. The new update restores the correct ID numbers as they were before the "bad" update. However, if meanwhile you modified the panel, this update breaks your config again because the plugins would be using a different ID again. This was the reason I suggested in Factory ML to wait for the fix before updating. Please keep in mind that repos like X11:xfce are for development and the packages there are be considered as "experimental". Cheers, Maurizio Galli (MauG) On Sun, Dec 16, 2018 at 6:05 PM Manfred Hollstein <mhollstein@t-online.de> wrote:
Hi there,
I just installed the latest updates from X11:xfce/openSUSE_Leap_15.0, logged out and in again, and my main panel is screwed up again. Here are the differences between what I had and what I got after the updates:
1. systray got removed, including its settings 2. a separator got added instead
Not as bad as with the last updates, but still...
HTH, cheers.
l8er manfred
-- To unsubscribe, e-mail: opensuse-xfce+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-xfce+owner@opensuse.org
Hi all Am 16.12.18 um 12:02 schrieb Maurizio Galli (MauG):
Hello Mafred, First of all thanks for bringing up the bug. When you modify your panel, configs are stored here: .config/xfce4/xfconf/xfce-perchannel-xml/xfce4-panel.xml. If the plugins IDs in that config file don't match the file in the root directory, the panel fails to load them or mistakes them for something else.
The new update restores the correct ID numbers as they were before the "bad" update. However, if meanwhile you modified the panel, this update breaks your config again because the plugins would be using a different ID again. This was the reason I suggested in Factory ML to wait for the fix before updating.
I was thinking about these problems when I last modified the panel xml file to add the statusnotifier plugin and the xfce4-notifyd notification plugin. A problem is, that if we have used plugin IDs 1-10 before and now add plugin 11 and 12, but the user had already added id 11 by configuring an additional plugin, then there might be trouble. I had envisioned to use higher IDs for the "factory shipped" configuration, say, starting at ID=100 (or 256 or whatever). The drawback is, that this would break updates for sure. We then should at least offer an easy "reset panel to factory defaults" button to have the users reset their config.
Please keep in mind that repos like X11:xfce are for development and the packages there are be considered as "experimental".
OTOH, if knowledgeable Users like Manfred do not test from there, we'll ship these bugs unnoticed to Factory/Tumbleweed, so it's good that at least someone is testing the "unreleased" code ;-) Have fun, Stefan -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-xfce+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-xfce+owner@opensuse.org
We then should at least offer an easy "reset panel to factory defaults" button to have the users reset their config.
There is the tool called xfce4-panel-profiles in the X11:xfce repo that can back up panel configs and restore them. But as Stefan pointed it out, in some cases it fails. https://bugzilla.xfce.org/show_bug.cgi?id=14934
OTOH, if knowledgeable Users like Manfred do not test from there, we'll ship these bugs unnoticed to Factory/Tumbleweed, so it's good that at least someone is testing the "unreleased" code ;-)
Indeed! I wouldn't have noticed it if Manfred didn't bring it up and I appreciate that :-) Maurizio Galli (MauG) On Sun, Dec 16, 2018 at 7:37 PM Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
Hi all
Am 16.12.18 um 12:02 schrieb:
Hello Mafred, First of all thanks for bringing up the bug. When you modify your panel, configs are stored here: .config/xfce4/xfconf/xfce-perchannel-xml/xfce4-panel.xml. If the plugins IDs in that config file don't match the file in the root directory, the panel fails to load them or mistakes them for something else.
The new update restores the correct ID numbers as they were before the "bad" update. However, if meanwhile you modified the panel, this update breaks your config again because the plugins would be using a different ID again. This was the reason I suggested in Factory ML to wait for the fix before updating.
I was thinking about these problems when I last modified the panel xml file to add the statusnotifier plugin and the xfce4-notifyd notification plugin.
A problem is, that if we have used plugin IDs 1-10 before and now add plugin 11 and 12, but the user had already added id 11 by configuring an additional plugin, then there might be trouble.
I had envisioned to use higher IDs for the "factory shipped" configuration, say, starting at ID=100 (or 256 or whatever).
The drawback is, that this would break updates for sure. We then should at least offer an easy "reset panel to factory defaults" button to have the users reset their config.
Please keep in mind that repos like X11:xfce are for development and the packages there are be considered as "experimental".
OTOH, if knowledgeable Users like Manfred do not test from there, we'll ship these bugs unnoticed to Factory/Tumbleweed, so it's good that at least someone is testing the "unreleased" code ;-)
Have fun,
Stefan -- Stefan Seyfried
"For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-xfce+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-xfce+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-xfce+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-xfce+owner@opensuse.org
Stefan, Could a bash script to reset the default panel the way to go? I made one here and seems to do the trick: https://paste.opensuse.org/3974206 Maurizio Galli (MauG) On Sun, Dec 16, 2018 at 7:54 PM <mauriziogalli@opensuse.org> wrote:
We then should at least offer an easy "reset panel to factory defaults" button to have the users reset their config.
There is the tool called xfce4-panel-profiles in the X11:xfce repo that can back up panel configs and restore them. But as Stefan pointed it out, in some cases it fails. https://bugzilla.xfce.org/show_bug.cgi?id=14934
OTOH, if knowledgeable Users like Manfred do not test from there, we'll ship these bugs unnoticed to Factory/Tumbleweed, so it's good that at least someone is testing the "unreleased" code ;-)
Indeed! I wouldn't have noticed it if Manfred didn't bring it up and I appreciate that :-)
Maurizio Galli (MauG)
On Sun, Dec 16, 2018 at 7:37 PM Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
Hi all
Am 16.12.18 um 12:02 schrieb:
Hello Mafred, First of all thanks for bringing up the bug. When you modify your panel, configs are stored here: .config/xfce4/xfconf/xfce-perchannel-xml/xfce4-panel.xml. If the plugins IDs in that config file don't match the file in the root directory, the panel fails to load them or mistakes them for something else.
The new update restores the correct ID numbers as they were before the "bad" update. However, if meanwhile you modified the panel, this update breaks your config again because the plugins would be using a different ID again. This was the reason I suggested in Factory ML to wait for the fix before updating.
I was thinking about these problems when I last modified the panel xml file to add the statusnotifier plugin and the xfce4-notifyd notification plugin.
A problem is, that if we have used plugin IDs 1-10 before and now add plugin 11 and 12, but the user had already added id 11 by configuring an additional plugin, then there might be trouble.
I had envisioned to use higher IDs for the "factory shipped" configuration, say, starting at ID=100 (or 256 or whatever).
The drawback is, that this would break updates for sure. We then should at least offer an easy "reset panel to factory defaults" button to have the users reset their config.
Please keep in mind that repos like X11:xfce are for development and the packages there are be considered as "experimental".
OTOH, if knowledgeable Users like Manfred do not test from there, we'll ship these bugs unnoticed to Factory/Tumbleweed, so it's good that at least someone is testing the "unreleased" code ;-)
Have fun,
Stefan -- Stefan Seyfried
"For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-xfce+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-xfce+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-xfce+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-xfce+owner@opensuse.org
Am 16.12.18 um 13:49 schrieb Maurizio Galli (MauG):
Stefan, Could a bash script to reset the default panel the way to go? I made one here and seems to do the trick: https://paste.opensuse.org/3974206
Something like that, maybe with moving stuff into a backup location instead of deleting it and forcing a logout instead of killing / restarting (I'm not sure how good other parts cope with xfconfd going away), and with some nice popup window asking to confirm ;-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-xfce+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-xfce+owner@opensuse.org
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.
(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?
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) On Sun, Dec 16, 2018 at 9:59 PM Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
Am 16.12.18 um 13:49 schrieb Maurizio Galli (MauG):
Stefan, Could a bash script to reset the default panel the way to go? I made one here and seems to do the trick: https://paste.opensuse.org/3974206
Something like that, maybe with moving stuff into a backup location instead of deleting it and forcing a logout instead of killing / restarting (I'm not sure how good other parts cope with xfconfd going away), and with some nice popup window asking to confirm ;-)
-- Stefan Seyfried
"For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-xfce+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-xfce+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-xfce+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-xfce+owner@opensuse.org
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
Hi Guys,
Don't move it across potential mount boundaries, please.
No problem :) I created a very simple script that uses zenity for dialogs and adds date/time to the back up file. It requires zenity package to work. It does not force the user to log out but when it's done it prompts a warning and the log out window appears. Please let me know if you think this would be enough: https://paste.opensuse.org/35034082 Cheers, Maurizio Galli (MauG) On Sun, Dec 16, 2018 at 11:36 PM Manfred Hollstein <mhollstein@t-online.de> wrote:
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
-- To unsubscribe, e-mail: opensuse-xfce+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-xfce+owner@opensuse.org
Hi Maurizio, On Sun, 16 Dec 2018, 18:33:03 +0100, Maurizio Galli wrote:
Hi Guys,
Don't move it across potential mount boundaries, please.
No problem :)
I created a very simple script that uses zenity for dialogs and adds date/time to the back up file. It requires zenity package to work. It does not force the user to log out but when it's done it prompts a warning and the log out window appears. Please let me know if you think this would be enough: https://paste.opensuse.org/35034082
looks to me like it should work ;) Thx.
Cheers,
Maurizio Galli (MauG)
Cheers. l8er manfred
Hello, The script has been packaged as xfce4-panel-restore-defaults. It adds a menu entry and an entry in the xfce settings for easy access. It's now in X11:xfce and would automatically install as xfce4-panel dependency. Cheers, Maurizio Galli (MauG) On Mon, Dec 17, 2018 at 4:24 AM Manfred Hollstein <mhollstein@t-online.de> wrote:
Hi Maurizio,
On Sun, 16 Dec 2018, 18:33:03 +0100, Maurizio Galli wrote:
Hi Guys,
Don't move it across potential mount boundaries, please.
No problem :)
I created a very simple script that uses zenity for dialogs and adds date/time to the back up file. It requires zenity package to work. It does not force the user to log out but when it's done it prompts a warning and the log out window appears. Please let me know if you think this would be enough: https://paste.opensuse.org/35034082
looks to me like it should work ;) Thx.
Cheers,
Maurizio Galli (MauG)
Cheers.
l8er manfred
-- To unsubscribe, e-mail: opensuse-xfce+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-xfce+owner@opensuse.org
participants (4)
-
Manfred Hollstein -
Maurizio Galli -
Maurizio Galli (MauG) -
Stefan Seyfried