[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: KWin breakage: reset
From: Karol Szwed <gallium () physos ! info>
Date: 2002-01-08 2:18:56
[Download RAW message or body]
Sorry for the late reply.
On Thu, 3 Jan 2002 16:00:14 +0100, Matthias Ettrich wrote:
>There are some bugs that keep reoccuring, this one I fixed probably 5 times
> - and now it's back again. [snip]
>
>Those plugins have been simplified greatly to always call
>Workspace::slotResetAllClientsDelayed() which is a wodden hammer that
>basically removes all window decorations and builds them up from scratch.
Since Kwin itself provides no way for styles to know what has actually
changed, instead of introducing lots of code duplication in the styles
whereby they cache prior settings then compare these to the new settings
during reset(), it was easier at the time to "use the wooden hammer". I
agree, this is not nice and does introduce flicker, but never the less it
works. Being pressured to make kwin support button tooltips near a pending
release also prompted its use, as it guaranteed that setting changes were
applied correctly.
Currently, the kwin styles can reset themselves in two ways:
1. The very badly abused Options->resetClients() signal, which was often
connected to in each Client making resets slow. If there were 10 client
windows, some styles re-created their pixmaps 10 times. Nasty work.
2. The newer kwin plugin interface which provides the "reset()" cdecl, and
is called only once. Currently, the style plugins do not have the faintest
idea if it was the button positions, tooltip on/off or a non-style related
setting. They still get the reset() signal.
>As a result, simple operations in kcontrol like change the focus policy or
>opaque/transparent window movement result in a visual effect that looks like
>restarting the window manager - like with good-old CDE :-(
>
>Can't the style plugins be a little bit smarter? If things like button
>positions etc. change, maybe it's ok to use the big hammer, but for color
>changes or for _no_changes_at_all, a simple noop or at worst a repaint()
>should be entirely sufficient.
>
>Any comments?
Obviously the current handling of the dcop "reconfigure" signal is
inadequate. Its not only the styles at fault here, kwin itself should be
smarter in the way it handles setting changes. For example, if there are no
changes at all or the changes only involved focus policies and the like,
then why is the plugin's reset() function even called?
To fix this problem once and for all, I propose that the kwin style plugin's
reset function be changed, to something as shown below:
ResetAction reset( ResetHint rh );
where ResetAction, and ResetHint are something like:
enum ResetAction { NoAction, Repaint, ClientHandledReset, ResetAllClients };
typdef uint ResetHint; // Hint Flags
enum KWinResetHint {
NoChange = 0x00000000, // KWin got a "reconfigure" but detected no change.
// Could be a custom style configuration change via kwindecoration.
ColorChanged = 0x00000001,
ButtonPositionChanged = 0x00000002,
etc. };
By doing this, KWin will give hints to the styles telling them what has
changed (in a general, global sense), allowing the clients to reparse their
custom configuration options, and then return a ResetAction telling KWin
whether nothing should be done, clients should be repainted, the "wooden
hammer be hit" or if the style can manually reconfigure each client window.
Thus, the styles would never ever call slotResetAllClientsDelayed()
themselves, they would only ask KWin to do so if they determine its
necessary.
What do you think?
Cheers,
Karol
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic