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 ti=
mes
> - 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=
=2E

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 i=
t
 works. Being pressured to make kwin support button tooltips near a pendi=
ng
 release also prompted its use, as it guaranteed that setting changes wer=
e
 applied correctly.

Currently, the kwin styles can reset themselves in two ways:
1.=09The very badly abused Options->resetClients() signal, which was ofte=
n
=09connected to in each Client making resets slow. If there were 10 clien=
t
=09windows, some styles re-created their pixmaps 10 times. Nasty work.

2. =09The newer kwin plugin interface which provides the "reset()" cdecl,=
 and
 is called only once. Currently, the style plugins do not have the fainte=
st
 idea if it was the button positions, tooltip on/off or a non-style relat=
ed
 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 colo=
r
>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 plugi=
n's
reset function be changed, to something as shown below:

=09ResetAction reset( ResetHint rh );

where ResetAction, and ResetHint are something like:
enum ResetAction { NoAction, Repaint, ClientHandledReset, ResetAllClients=
 };
typdef uint ResetHint;=09// Hint Flags
enum KWinResetHint {
=09NoChange=09=3D 0x00000000, // KWin got a "reconfigure" but detected no=
 change.
=09=09=09=09=09=09=09 // Could be a custom style configuration change via=
 kwindecoration.
=09ColorChanged =09=3D 0x00000001,
=09ButtonPositionChanged =3D 0x00000002,
=09etc. };

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 the=
ir
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 windo=
w.
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