When a theme has specified resize_opacity, move_opacity, popup_opacity, show_frame_shadow, show_popup_shadow, they somewhat conflict with those in the xfce-mcs-manager -> Window Manager Tweaks -> Compositing tab. Example: In themerc: move_opacity=60 show_frame_shadow=true Then in the xfce-mcs-manager, the "Show shadows under regular window" seems to have no effect. And if you change the "Opacity of windows during move", it works until you change the other settings on the same tab such as the other sliders. Had a brief look in the code. Everytime when a setting is changed, loadSettings is called, which calls loadRcData, loadMcsData, loadTheme in that order, which explains why the settings from the themerc overriding the previous ones. The real question is what should the behaviour be in this situation, might need a policy or something.
The themerc has precedence, so themes creator should definitely force such options in the themerc
(In reply to comment #1) > The themerc has precedence, so themes creator should definitely force such > options in the themerc If any of these options was specified in a themerc file, the corresponding control widget in the MCS settings dialog should be disabled. They can’t be changed anyways, so why confusing the user?
Sorry I meant theme creators should *not* force those values, it is wrong to do that, although possible. So do you really want to parse all the themerc and disable the options because some theme creators think it is cool to force some option on the user? That's not worth the effort (and CPU cycles) IMHO.
(In reply to comment #3) > Sorry I meant theme creators should *not* force those values, it is wrong to do > that, although possible. Then why not just drop recognizing those options in themerc files altogether? > So do you really want to parse all the themerc and disable the options because > some theme creators think it is cool to force some option on the user? That's > not worth the effort (and CPU cycles) IMHO. There should be not much additional CPU cycles since Xfwm4 already does parse all the themerc and set the options a theme creator has specified. Disabling the GUI widget belonging to these options should be doable.
Yes, sure, of course everything is doable but I am not interested in implementing workarounds to stuff that should not be set in the first place.
(In reply to comment #5) > Yes, sure, of course everything is doable but I am not interested in > implementing workarounds to stuff that should not be set in the first place. I understand this. Then please consider dropping the recognition of these options within themerc files. Otherwise the scenario "Theme creator specified hard coded options → User switches to one of the creator’s themes → User can’t change these options in the Window manager tweaks anymore → User is confused" will continue to happen.
No, that would add more corner cases to the code, while I do not see real benefit in this. As for parsing, xfwm4 does indeed parse the themerc, but the plugins that chnaget hecopositor settings don't, it's even independant from the theme selector plugin, so adding what you want would really add useless complexity, so I am sorry, but this is wontfix.
(In reply to comment #7) > No, that would add more corner cases to the code, I would like to know some of these cases. > while I do not see real > benefit in this. Consistency, for example. The example I posted above is one where there is a inconstency which confuses the user in the end. > As for parsing, xfwm4 does indeed parse the themerc, but the plugins that > chnaget hecopositor settings don't, it's even independant from the theme > selector plugin, so adding what you want would really add useless complexity, > so I am sorry, but this is wontfix. I can see the work required to get this going. But please leave this report open in case someone (or me) wants to take care of this.
(In reply to comment #8) > (In reply to comment #7) > > No, that would add more corner cases to the code, > > I would like to know some of these cases. The wmtweaks would have to !) learn about the theme used (this is not the case now) and 2) read and parse the associated themerc (this is not the case today) and 3) listen to changes in the theme used and react accordingly. > > while I do not see real > > benefit in this. > > Consistency, for example. The example I posted above is one where there is a > inconstency which confuses the user in the end. This is pedantry. Xfce has lost its roots, this is the kind of things that drives to waste of time,resource and end in bloat in the code. > > As for parsing, xfwm4 does indeed parse the themerc, but the plugins that > > chnaget hecopositor settings don't, it's even independant from the theme > > selector plugin, so adding what you want would really add useless complexity, > > so I am sorry, but this is wontfix. > > I can see the work required to get this going. But please leave this report > open in case someone (or me) wants to take care of this. > But I shall oppose to this patch anyway.
> > I would like to know some of these cases. > > The wmtweaks would have to !) learn about the theme used (this is not the case > now) and 2) read and parse the associated themerc (this is not the case today) > and 3) listen to changes in the theme used and react accordingly. Why not modify the user configuration when a property is encountered in a themerc that is also user-configurable, such as move_opacity, and then have the user preferences have precedence over the themerc? This would remove any need for the compositor settings plugin to parse anything new. > > > while I do not see real > > > benefit in this. > > > > Consistency, for example. The example I posted above is one where there is a > > inconstency which confuses the user in the end. > > This is pedantry. Xfce has lost its roots, this is the kind of things that > drives to waste of time,resource and end in bloat in the code. I feel pedantry is necessary in this sort of a situation in order to ensure the end experience is the expected one.
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfwm4/-/issues/13. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev