Closed maandree closed 10 years ago
Please elaborate. What do you mean by suffers? What would this opt-in do, why would it be needed?
With suffers I mean that is a feature that has been added without being opt-ed and at its current state its is a negative feature unless you are using GNOME. It can cause double decorations and massive CPU load when moving around, and its really does not look native unless you are using GNOME. So what is happened is that redshift-gtk has become somewhat of a GNOME application becuase of upstream changes in GTK+.
Perhaps it is better to go back to GTK+ 2.
I am using GNOME so perhaps that is why I have not noticed any difference when we moved from GTK+2 to GTK+3. I have not heard any mention of these issues before though so I am quite surprised that switching to GTK+3 would cause such bugs. Do you know if these bugs are these reported upstream? Since GTK+2 (PyGTK) seems to be deprecated I don't think it would be a good idea to go back to GTK+2.
Actually there have been lots of critisism over how poorly GNOME handled client-side decorations and GTK and GNOME are very well aware of the issues.
How about Qt?
I cannot really demonstrate the CPU issue, but here how it looks if tiled in a tiling window manager. It should actually look worse in stacking window managers.
Seems to be working okay in KDE nowadays (although it sort of looks those programs that do there own decorations, because well that is whats happening). But not to good in the only window manager, other than xmonad, I use: twm.
I hear the GTK+ folks are working to resolve this, and appearantly planned to all along and just did not tell us.
The info-dialog for redshift-gtk suffers those client-side decorations as seen in GNOME. Is it possible to switch to "server-side" decorations, perferably with opt-in (or opt-out) to client-side?