[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 1:33:36
[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]