State plugin, new options

[gnumdk]

http://puffy.homelinux.org/~gnumdk/compiz/state.tar.gz

New version of state plugin with some new options:
- skiptaskbar => c:Kopete:1 and kopete windows will not be present in taskbar.
- skippager => c:Kopete:1 and kopete windows will not be present in pager.
- above => c:MPlayer:1 to make mplayer above others windows by default.
- below => c:MPlayer:1 to make mplayer below others windows by default.

Please test it and report any bug! :)

[mikedee]

Seems to work here, the only problem is that if you set a window to on top, it does not update like it does if you change the opacity etc. Would it be possible to make it update all of the windows when the options are changed?

[gnumdk]

Will work on this

[gnumdk]

http://puffy.homelinux.org/~gnumdk/compiz/state.tar.gz

It now set windows state on the fly :)

[gnumdk]

I just backport some beryl code.
Now support regex !!!

beryl changelog:
-add both regexes and globbing to state
-regexes are extended, case-sensitive
-globbing is case-insensitive
-to use globbing, use like regular state (p:A*b:n)
-to use regexes, use this format: p/a|b/n

[mikedee]

I have been taking a closer look at the state code and here are my thoughts

A lot of the code complexity could be removed by having a WindowFilter option type (similar to the color special type). This would remove a lot of the complexity and we could add some helper functions to core to see if a particular window matches an option.

There is also a lot of redundant code there, eg. if you change the brightness list, the plugin changes every setting that it knows about. The code is also complicated because it uses direct Xlib calls.

I recently posted on the mailing list about this particular issue and Daivd thinks it is a good idea to include this special option type. We can also move the setting and getting of xhints functions into core so the plugin will be much less complicated.

I would like to work out a solution that can be used by other plugins as well and will allow individual plugins to enhance it. The other plugins could also access these settings so that we could cooperate with them, eg you could add a hint which stops wobble or animation on very specific window types.

With your workings on state, did you have any other ideas on how this option type could be implemented?

[gnumdk]

With your workings on state, did you have any other ideas on how this option type could be implemented?

I think i haven't skill to help you on how to implemente this ;) But i will follow your work, it will make me able to understand how compiz core works ;)

Thanx for all!

[iznogood]

Just to report a problem with state

I set the above option p:gnome-terminal:1 but it is not enabled unless i restart compiz. And the terminal must be already running because if it is started after the option is set, then nothing happens.

I had the same problem with the widget plugin and then i though that it was widget's problem but it must be located in state.

How does it work for you guys ?? Is it a bug or i do something wrong ???

[gnumdk]

http://puffy.homelinux.org/~gnumdk/compiz/state.tar.gz

Here is a new version of plugin, i remove some stupid xlib code and now use compiz to set windows state.

iznogood, i tried with p:konsole:1, it doesn't work too :(

If i put c:Konsole:1, it works for new started konsole, it should work for already started konsole ... :(

I'm going to try to implement mikedee idea (WindowFilter type) so i will try to fix all bugs.

Cedric

[iznogood]

Wouldn't it be better if we break down the functionality of the plugins??

For example state alters some window props and so do other plugins, we have fade plugin and fade effect in animation etc.

Thats what davidr posted about the roadmap

7. A pluggable shader interface that will allow different plugins to
plug in to different parts of the fragment shading. E.g. we can have one
plugin that is doing some parallax mapping, another one that performs
some advanced scaling algorithm for accessibility purposes and one
plugin that blends the result with blurred destination fragments all
working at the same time. The plugins should only have to provide shader
code for their specific part and this shader interface will build and
cache appropriate shaders/fragment programs.


Wouldn't it be nice to have plugins that offer functionality like fade and this should be in one place not replicated in every plugin. These plugins should offer a minimum functionality and everything else should be handled by external plugins - scripts that manipulate them (with dbus or any other way available).
I post this because i feel that if we add functionality in the plugins the code will eventually become bloated. Things like regular expression handling, could be external stuff so that the core remains simple, fast and easy to bugfixing

This is just my opinion though, so tell me what you thing of it

[iznogood]

i only post this because i looked at traifocus code and i saw that it updates the render props directly.

Wouldn't it be better if it used state or some other generic plugin??
(Initially i thought that it did just that but i haven't looked at the code)

[gnumdk]

While trying to implement mikedee idea, same reflexion come into my mind...

Puting window filtering in core is not the solution i think. Window matching in a composite manager...

So, what about some libs?

libwmcompiz for compiz window management facilities.
lib3dcompiz for compiz effects facilities.

state, put, place will link with libwmcompiz for exemple, it will make plugins code much more easy to read.

Am i wrong?

[iznogood]

Yes it sounds cool, and it will give people a chance at implementing plugins without actually knowing the internals of compiz that much.

Ok the only missing is to decide what actions - props each will implement.
I will give this a try a bit later and post my suggestions here. Others can to the same and we can split the job among us

I would like to hear mikedee's opinion on that though...

what to you say???

[PaK]

Right now David is trying to drop some complexity from whole compiz (point 2-4 from roadmap) maybe after that you shuld think about what part of compiz shuld be available as library ? And i thnik if you dont know how compiz really works it is not good to create plugin for compiz, well off cours you make make plugin thats do same fancy effect with only opengl and glx knowladge but is this plugin would be really productive and useful ?

[gnumdk]

>And i thnik if you dont know how compiz really
>works

I was talking about compiz core ;)
I don't know anything about opengl, texture_from_pixmap and how all this is working...

>plugin thats do same fancy effect with only opengl
>and glx

I don't know how to do this :)
What i want, it's a good window manager.
That's why i'm thinking about lib for window management, and why not effects...

exemple, i think setWindowState() should be in a libcompizwm for exemple, same thing for window filtering...

[iznogood]

ok i thing that state has a lot of bugs!!!
I can not make it work with dbus.The line below has no effect
dbus-send --type=method_call --dest=org.freedesktop.compiz /org/freedesktop/compiz/state/screen0/above org.freedesktop.compiz.set string:'p:konsole:1'

c:konsole:1 does not work too...

Also it does not read variables, unless i restart compiz.If i do that the setting is activated also...

Has anyone tried it with dbus and actually worked ??? I try to use it with dbus so i can implement a screensaver script that uses state plugin, but if dbus is not working i can not communicate with compiz...

[gnumdk]

c:Konsole:1 should works...

There is a bug but i don't know where...

On window creation(CreateNotify), i call stateAdjustWindowsStateParams() and it works!

When changing a setting, i call stateAdjustWindowsStateParams() for all windows and it doesn't works :(
But it works for skippager and skiptaskbar... It's really strange...

[iznogood]

Check this post
http://mailman.linuxchix.org/pipermail/techtalk/2003-May/015402.html

We need to inform the WM about the changed property by sending a clientmessage to the root window.

After some debugging i saw that the code runs fine but the property _NET_WM_STATE_ABOVE is not set.Maybe its related to the above

I will try to fix this tomorrow because i need to get some sleep

[mikedee]

I just had a quick poke through window.c and it looks like this function is what you might need.

setWindowState (CompDisplay *display,
unsigned int state,
Window id)

Calling something like this should work.

setWindowState (w->screen->display, (w->state | CompWindowStateAboveMask), w->id);

I havent checked though

[iznogood]

ok i will try it, thanks

[gnumdk]

http://puffy.homelinux.org/~gnumdk/compiz/state.tar.gz

Here is a new version fixing some bugs...

State plugin already use setWindowState ()...

I tried to patch compiz core adding _NET_WM_STATE_ON_TOP_ but without sucess :(

it's really strange that a windows with _NET_WM_STATE_ABOVE, _NET_WM_STATE_STAYS_ON_TOP is not on top.

[iznogood]

ok the following code in stateAdjustWindowsStateParams does the trick...


if (above != -1) {
XEvent xev1;
XEvent xev2;

xev1.xclient.type = ClientMessage;
xev1.xclient.serial = 0;
xev1.xclient.send_event = True;
xev1.xclient.window = w->id;
xev1.xclient.message_type = XInternAtom (w->screen->display->display, "_NET_WM_STATE", FALSE);
xev1.xclient.format = 32;
xev1.xclient.data.l[0] = 0;
xev1.xclient.data.l[1] = XInternAtom (w->screen->display->display, "_NET_WM_STATE_BELOW", FALSE);
xev1.xclient.data.l[2] = 0;
xev1.xclient.data.l[3] = 0;
xev1.xclient.data.l[4] = 0;

XSendEvent (w->screen->display->display, w->screen->root, False,
SubstructureRedirectMask | SubstructureNotifyMask,
&xev1);

xev2.xclient.type = ClientMessage;
xev2.xclient.serial = 0;
xev2.xclient.send_event = True;
xev2.xclient.window = w->id;
xev2.xclient.message_type = XInternAtom (w->screen->display->display, "_NET_WM_STATE", FALSE);
xev2.xclient.format = 32;
xev2.xclient.data.l[0] = 1;
xev2.xclient.data.l[1] = XInternAtom (w->screen->display->display, "_NET_WM_STATE_ABOVE", FALSE);
xev2.xclient.data.l[2] = 0;
xev2.xclient.data.l[3] = 0;
xev2.xclient.data.l[4] = 0;

XSendEvent (w->screen->display->display, w->screen->root, False,
SubstructureRedirectMask | SubstructureNotifyMask,
&xev2);
}


Obviously this needs a lot of work but it works when you set the param for an existing window (at least on my system).
Unfortunately it does not work for a new window(created after you set the param) and also the plugin fails to reset the window's initial state if you unset the param, but these where bugs before so ...

Anyway this should be coded the compiz way and not using Xlib calls but its a start.Credit should go to the gtk+ people because that was the place i looked to see some code that works

If anyone can comment on that i would like to hear it. Until then i will try to work on it

[iznogood]

ok i have a new version you can get it here

http://iznogood.i8.com/Compiz/state/

i fixed a few bugs(segfaults) and above-below states now work although with Xlib code. I will replace that when i have a workaround from davidr

However above-below does not work for new windows at least not on my system. I believe the reason is that the windows should be mapped(unmapped windows can not use this code)
But a new window gets a CreateNotify and not a MapNotify event, at least on gtk. If Qt has different behaviour i do not know about it, i will try it later

Anyway i will try to fix that too. According to Xlib docs, many toolkits do not allow MapNotify events to propagate to the Clients so the notifications are never reaching us and the code in CreateNotify might be running too early...

I will see what i can do. Any comments - suggestions are welcome

[mikedee]

But a new window gets a CreateNotify and not a MapNotify event, at least on gtk.

I think new windows get a CreateNotify followed by a MapNotify.

If you wait for the notifications in core for new windows etc, you will not have to worry about xlib as much.

I get this when I try to download the plugin

wget http://iznogood.i8.com/Compiz/state/state.tar.bz2
--19:33:51-- http://iznogood.i8.com/Compiz/state/state.tar.bz2
=> `state.tar.bz2'
Resolving iznogood.i8.com... 64.136.24.160
Connecting to iznogood.i8.com|64.136.24.160|:80... connected.
HTTP request sent, awaiting response... 403 Forbidden
19:33:52 ERROR 403: Forbidden.

[iznogood]

yes, yes sorry
try http://iznogood.i8.com/Compiz/state/
and get it from there.
I don't have any time to set it up properly

Sorry again

[iznogood]

btw i saw the post on the mailing list and i should wait, however if we encapsulate X calls correctly in libraries we would not need to wait for davidr
We could use them now and replace them later as they come in the core

What do you thing???

[mikedee]

I have looked at the code and I think it is just a simple case of logic error :)

This is my modified version of the stateAdjustWindowsStateParams function. Note the removing of the above and below masks before starting. Also I changd the assignment of the w->state, but this might not be necessary.

static void
stateAdjustWindowsStateParams (CompWindow *w)
{
STATE_SCREEN (w->screen);

unsigned int windowState = w->state;
int b = stateGetParamForWindow (w, fs->borders);
int skipTaskBar = stateGetParamForWindow (w, fs->skiptaskbar);
int skipPager = stateGetParamForWindow (w, fs->skippager);
int above = stateGetParamForWindow (w, fs->above);
int below = stateGetParamForWindow (w, fs->below);

windowState &= ~(CompWindowStateAboveMask);
windowState &= ~(CompWindowStateBelowMask);

if (b != -1)
{
XChangeProperty (w->screen->display->display,
w->id,
w->screen->display->mwmHintsAtom,
w->screen->display->mwmHintsAtom,
8,
PropModeReplace,
(unsigned char *) &fs->mwmHints,
sizeof (fs->mwmHints));
}

if (skipTaskBar != -1)
windowState |= CompWindowStateSkipTaskbarMask;

if (skipPager != -1)
windowState |= CompWindowStateSkipPagerMask;

if (above != -1)
windowState |= CompWindowStateAboveMask;
else if (below != -1)
windowState |= CompWindowStateBelowMask;

w->state = windowState;

setWindowState(w->screen->display,
w->state,
w->id);
}

You might need to do the same for skip pager etc, I didnt check them.

[mikedee]

One last tweak that is needed it to call raise/lower window if the option is being changed, that way it will replicate the kicker right click menu action.

[iznogood]

Indeed you are right!!! :lol:

However its strange because initially, the window has no option set so unsetting one of the states shouldn't have changed anything...(normally i guess).This is the reason i didn't thing about that...

i will update it with your fix
Ok now that is working i can continue with the screensaver,
thanks

[iznogood]

ok i updated the tarball wih mikedee's fix and a couple changes. Now it works fine here for existing windows and also for newly created ones...
Before it failed to set above-below state if a window was created after the option was set.

It required a change in stateHandleEvent. Now paint and state events are handled on MapNotify because CreateNotify runs too early. Also added a PropertyNotify to raise - lower a window when above-below state changes

Get it at http://iznogood.i8.com/Compiz/state

i would like to hear some comments on it

[gnumdk]

Some comments? It works well, thanks ;)

[mikedee]

Works perfectly :)

I have tidied up the state handle event so that it is a bit more 'compiz style', and hopefully a bit easier to read. You were redefining the window structure, plus it is standard in compiz for the variables to be defined at the start (although in the end I removed the 'st' variable since its easier to read and understand this way).

static void
stateHandleEvent (CompDisplay *d,
XEvent *event)
{
CompWindow *w;

STATE_DISPLAY (d);

if (event->type == MapNotify)
{
w = findWindowAtDisplay (d, event->xmap.window);
if (w && (!w->placed))
{
stateAdjustWindowPaintParams (w);
stateAdjustWindowStateParams (w);
updateWidgetStatusForWindow (w);
}
}

UNWRAP (fd, d, handleEvent);
(*d->handleEvent) (d, event);
WRAP (fd, d, handleEvent, stateHandleEvent);

if (event->type == PropertyNotify)
{
w = findWindowAtDisplay (d, event->xproperty.window);
if (w)
{
if (w->state & CompWindowStateAboveMask)
raiseWindow(w);
else if (w->state & CompWindowStateBelowMask)
lowerWindow(w);
}
}
}

MapNotify also gets called when a window is unminimized so this code is probably running too often. It is not a major problem now, we can wait for the better window notifications.

[mikedee]

Also I noticed that these 2 atoms are defined in the CompDisplay structure so you can remove them from the state display.


fd->utf8String => d->utf8StringAtom
fd->wmNameAtom => d->wmNameAtom

[mikedee]

Is it only me who found Davids reply on the mailing list a bit confusing?

It seems to be working now, but he says that it shouldnt work (or do I have it wrong?)

[iznogood]

ok i have posted on that before. This is what the documentation says for various toolkits(Actually i checked gtk+ and also some tutorials since i am not an expert on the subject)

Since it works how do we proceed???
I guess that by not sending the client messages, we might be losing some X functionality(like some notifications that are not send back ??? i don't know)

[gnumdk]

http://puffy.homelinux.org/~gnumdk/compiz/state.tar.gz

Here is a new version of state plugin correcting some issues:

************************************************** ***

Remove PropertyNotify => not working making a lot of above window appear as below... No way to fix this... So, i do this another way... One more, windowlower/raise was called a lot of time for nothing (origin of the bug)

************************************************** ***

Remove MapNotify => Why change paint/state here? Don't see any good reason.
Re-enable CreateNotify (please test this iznogood, i see no reason for this to not work!)

Now, paint/state params are changed in CreateNotify:
- it make configuration dialog of transparent apps non transparent (ok, just for kde apps, don't works with gtk apps tested here)
- Only change windows params one time, not the case in old code.

************************************************** ***

Please test this and tell me if it works, seems to be good for me.

[mikedee]

Everything seems to work here except that the states do not change back when you remove them from the list.

My hack before was to just remove those flags before reapplying them. It works but the problem is that you can manually set the on top/bottom by right clicking on kicker. This means that if you manually set an application to be on top and then change the on top state values, it will remove the on top state.

The best way around that I can see is to use window private variables to store whether the on top was added by the state plugin, it can then reset those flags without worrying about interfering with manually set states.

[iznogood]

The code you sent, i have coded my self a couple days ago and it didn't work...Also it does not work now... What system are you working on ??
Mine is Celeron 660 nvidia 6200 gentoo 2.6.19 nvidia drivers 1.0-9631


Remove MapNotify => Why change paint/state here? Don't see any good reason.
Re-enable CreateNotify (please test this iznogood, i see no reason for this to not work!)


Create Notify seems to run too early and newly created windows have not the correct state. Have you checked it with xprop??


Remove PropertyNotify => not working making a lot of above window appear as below... No way to fix this... So, i do this another way... One more, windowlower/raise was called a lot of time for nothing (origin of the bug)

I strongly disagree with that. Do not forget that compiz is hosted on a message driven environment (X server). You set a state, you get notified and then you continue. Otherwise things in X might not be a the right state when you call raise-lower a window. Consider how its done in MS windows:Lets say that you want to paint something on the screen when a user clicks a button.First you hook on the proper mouse down message, set a variable and then you hook the paint message and paint the thing. Otherwise if you put it on the wrong place, you risk your changes been overwritten by some other code...

Also the code by mikedee that resets the state is correct. I tested your changes and i end up with windows having both above and below states set
(i copy it from xprop _NET_WM_STATE(ATOM) = _NET_WM_STATE_ABOVE, _NET_WM_STATE_BELOW)

I submitted my code just for testing, it was far from ready. I see no point optimizing it unless i am sure that it works first. If you believe that some codes runs more times than needed, yes you are right, but its better to set a couple of window privates (invalidateStateParams, invalidatePaintParams) and check them accordingly

Anyway, what do you thing. Also what is mikedee's opinion?? He seems to know his way around here quite well

[gnumdk]

Nvidia 6600 driver 7942 => debian sid
Tested also on an Nvidia 5200. => kubuntu edgy


>Have you checked it with xprop??

gnumdk@milouse:~$ xprop |grep STATE
WM_STATE(WM_STATE):
_NET_WM_STATE(ATOM) = _NET_WM_STATE_ABOVE, _NET_WM_STATE_STAYS_ON_TOP
gnumdk@milouse:~$

On a just launched konsole.

>I tested your changes and i end up with windows
>having both above and below states set

I know this, but haven't any idea on how to fix this. Mikedee idea is good i think.

>You set a state, you get notified and then you
>continue. Otherwise things in X might not be a the
>right state when you call raise-lower a window.

I'm going to try to fix you code with bug i see here while coding mikedee idea. I think you right ;)

[iznogood]

ok i have fixed all that and a bit more...

i have put an extra structure StateWindow to hold a few extra variables per window so that i can control how many times a function is called, just for optimization
i continue to use MapNotify instead of CreateNotify which works fine here, and PropertyNotify. I also must say that i tested it under kde and works fine there too

Also i fixed a bug that did not restore the value of a paint property when the user unset it.

I will debug it a bit more and post it for comments - suggestions tomorrow

Also since the compiz Api is getting richer we can try to replace some of the Xlib calls with compiz calls where its possible

The only problem is that we don't get any feedback from other people so that we can see how it works for others...

[mikedee]

Also since the compiz Api is getting richer we can try to replace some of the Xlib calls with compiz calls where its possible

I made a post on the mailing list about plugins being able to easilly set and get x hints for individual windows, that way plugins can more easilly share their information about a window state (our examples are covered by compiz/xlib but we could have other bits of information).

The functions in state are a start but they only get window hints, not set them. It would be nice if we could have some functions in core which could do this easilly. eg.

setWindowHint( CompWindow *w, char *hintName, CompOptionValue *value)
getWindowHint( CompWindow *w, char *hintName, CompOptionValue &value)

The three stateGetXProperty* functions could be reduced to 1 (I think) and then these functions could be used to set XHints or custom hints for the plugins to communicate.

[gnumdk]

>i continue to use MapNotify instead of CreateNotify
>which works fine here, and PropertyNotify. I also
>must say that i tested it under kde and works fine
>there too

I really don't understand why CreateNotify don't works for you. I've tested on an OpenSuse 10.2(intel card) and it works ... Are you sure you haven't strange building option in you portage configuration?

>I will debug it a bit more and post it for
>comments - suggestions tomorrow

What is buggy currently in state plugin:
When receiving an PropertyNotify, state plugin should raise the window only if above state was set by state plugin. In kde (and i think gnome), when a popup appear, it has above propertie and compiz raise it... State plugin raise it again and the popup appear below kicker :-/


One thing interesting to note, while debuging the plugin, i print Xevent on Screen. Moving cursor over a Qt apps generate few Xevents. Moving cursor over a gtk apps generate a lot of CreateNotify, DestroyNotify and PropertyNotify eating a lot of CPU. So, Gtk sux!

[mikedee]

>i continue to use MapNotify instead of CreateNotify
>which works fine here, and PropertyNotify. I also
>must say that i tested it under kde and works fine
>there too

I really don't understand why CreateNotify don't works for you. I've tested on an OpenSuse 10.2(intel card) and it works ... Are you sure you haven't strange building option in you portage configuration?

It maybe because the WRAP/UNWRAP is after the create notify handle. If I am right, the stateHandleEvent wraps the core event handling function. When compiz receives the CreateNotify, it creates the window. Our function is called before the window is created.

What is buggy currently in state plugin:
When receiving an PropertyNotify, state plugin should raise the window only if above state was set by state plugin. In kde (and i think gnome), when a popup appear, it has above propertie and compiz raise it... State plugin raise it again and the popup appear below kicker :-/

This is true, in theory we should have to just set the on top hint and then raise the window manually. I am still concerned about David saying that the setWindowState shouldnt be used, we will need to create our own version of it by the looks of it.

One thing interesting to note, while debuging the plugin, i print Xevent on Screen. Moving cursor over a Qt apps generate few Xevents. Moving cursor over a gtk apps generate a lot of CreateNotify, DestroyNotify and PropertyNotify eating a lot of CPU. So, Gtk sux!

Yes I noticed this too, I assumed it was just gconf-editor. I am a happy KDE user so I think thats the only gtk app I use.

[gnumdk]

for gtk bugs, seems to be fixed in last gtk, can't test on my debian.

[iznogood]

ok i uploaded a new version here http://iznogood.i8.com/Compiz/state/

It fixes a few bugs :

receiving an PropertyNotify, state plugin should raise the window only if above state was set by state plugin


Put a couple of window flags needsRaise, needs Lower.(Could be one flag, i will change it later)
Also put 2 flags to check inside MapNotify, unless i find a way to make CreateNotify work

Fixed a bug with skipPager and skipTaskbar. They did not reset their state if you unset the parameter

Also did the same for opacity, brightness and saturation. But since i have no previous state to return to i choose to set their values to MAX.However this needs a bit more work because code in changeOpacity, changeSaturation and changeBrightness might put some extra windowDamage(like if some other plugin changes the above properties, maybe trailfocus). I will test this a bit more...i am not sure yet...

Also put all code in handleMessage after WRAP/UNWRAP...I can not see a reason to run before...(maybe widget plugin but it does not work anyway)

Anyway if someone has any thoughts i will gladly hear them

Btw i updated to compiz git yesterday and things go a A LOT slower. Is this just me or its happening to anyone else??

[iznogood]

I really don't understand why CreateNotify don't works for you. I've tested on an OpenSuse 10.2(intel card) and it works ...


since i am no expert on the subject (and i thing none of us is) i checked how they do it in Gtk...From what i saw they call different functions depending on whether the window is mapped or unmapped. Also they use Client Messages. Thats why i used Client Messages in my first version...

Right now i am at work and i can not do much from here, however when i get home i will check this a bit more and also will check on Qt to see how they do it there


Are you sure you haven't strange building option in you portage configuration?


Obviously this has nothing to do with portage or build options...Otherwise nothing would work. I was asking about your system to see what video card - driver you use and whether you run compiz with AIGLX, XGL, or nvidia... I use nvidia rendering bypassing AIGLX and XGL. I do not thing that this matters at all.
However could this be different if someone used XGL or AIGLX since they are different X servers??? XGL works on top of a normal server so who handles-broadcasts all these messages and how is window state management done if you run XGL????

[RAOF]

...
However could this be different if someone used XGL or AIGLX since they are different X servers??? XGL works on top of a normal server so who handles-broadcasts all these messages and how is window state management done if you run XGL????

XGL manages all the stuff. As far as X clients are concerned, XGL is a perfectly normal X server.

As I understand it, the only thing the underlying X server does for XGL is set up the screen resolution, driver init, etc, then give it an OpenGL context for it to render in.

[moppsy]

Among the many changes, the border code has ended up back in MapNotify. It really belongs in CreateNotify.

HandleEvent should also use a switch/case statement for consistency with the rest of compiz.

I have a patch for this that also fixes some issues with formatting as well as removing the redundant atoms.

state-border.patch (http://home.comcast.net/~moppsy/compiz/state-border.patch)

[iznogood]

hi moppsy,

yes i totally screwed up the code formatting...Can you tell me how to fix it??
I use eclipse, are there any special settings? I read davidr's post on code format but its hard if you are not used to it...

Anyway, you are half right about the border code... Because its true that its better suited in CreateNotfy but you also removed it from stateAdjustWindowStateParams and existing windows don't have their border removed if you set the param...

Also i get a strange behaviour on borders... I set it and then create a window, but the border is drawn normally and the param is ignored. However if you try to click-drag on the border the window is not notified... Its like X knows there is no border but the window decorator ignores it...This looks more like a decorator bug and i will look into it...I use gwd and compiz from git

I have included your patch and made a few more changes...I noticed that the code that changes opacity, saturation, and brightness is very similar to the code in the compiz message handler in event.c. So instead of duplicating in the plugin, i chose to communicate with compiz core via Client Messages just like David posted a few days ago on the mailing list... Originally the post was about the keepAbove-keepBelow properties but it also applies nicely here and it also offers a nice way to avoid internal dependencies on the code. This way we let compiz core manage all the internal details for the X properties and avoid some nasty code copy-paste.I checked it on my system and it works very nice.

I wanted to post this a few days ago but there was no time. So get it from here and post any suggestions http://iznogood.i8.com/Compiz/state/

[moppsy]

yes i totally screwed up the code formatting...Can you tell me how to fix it??

I just do it manually to match David's style.

Anyway, you are half right about the border code... Because its true that its better suited in CreateNotfy but you also removed it from stateAdjustWindowStateParams and existing windows don't have their border removed if you set the param...

Yes, I see. Not an occasion I accounted for.

Also i get a strange behaviour on borders... I set it and then create a window, but the border is drawn normally and the param is ignored. However if you try to click-drag on the border the window is not notified... Its like X knows there is no border but the window decorator ignores it...This looks more like a decorator bug and i will look into it...I use gwd and compiz from git

That is just like an old problem I used to have before David added the better handling of MwmHints (http://gitweb.freedesktop.org/?p=xorg/app/compiz.git;a=commit;h=2903d0bce6eb31972dc29590f332 b32744592a39). I had worked around it by adding a property change to winDecorAtom, setting it's data to winDecorBareAtom. Though it had other undesirable side effects.

I noticed that the code that changes opacity, saturation, and brightness is very similar to the code in the compiz message handler in event.c. So instead of duplicating in the plugin, i chose to communicate with compiz core via Client Messages just like David posted a few days ago on the mailing list... Originally the post was about the keepAbove-keepBelow properties but it also applies nicely here and it also offers a nice way to avoid internal dependencies on the code. This way we let compiz core manage all the internal details for the X properties and avoid some nasty code copy-paste.I checked it on my system and it works very nice.

Excellent!

[iznogood]

First of all,
HAPPY NEW YEAR everyone (and may compiz be with you...always)

Moppsy thanks for taking the time to respond to my post, i appreciate it.
About the problem with the window borders that are not managed correctly, i noticed that border plugin works ok, so either i will use code from there or just alter border plugin to expose functionality that can be used from state plugin to change the border of windows (unless this functionality already exists via dbus maybe??? I will check it).
I would have done that sooner but since i got no replies, i thought that no one takes an interest about state plugin so i postponed it for later...

Finally with the recent changes in state plugin i got a nice bonus...I managed to have widget plugin working(before it did not do anything if you set - unset the widget params in state plugin unless you restarted compiz).
I also had to fix a very minor bug which i can post on widget plugin thread if anyone is interested.

I know that a new version is planned, so i wonder if these changes are going to be merged ???

Anyway, thanks for your time
iz

[mikedee]

Finally with the recent changes in state plugin i got a nice bonus...I managed to have widget plugin working(before it did not do anything if you set - unset the widget params in state plugin unless you restarted compiz).
I also had to fix a very minor bug which i can post on widget plugin thread if anyone is interested.


Yes - I'd be interested :) I have been giving widget some thought recently and I *think* i know how to put it on top of the cube.

I know that a new version is planned, so i wonder if these changes are going to be merged ???

If you guys can prepare a final version, I will put it on my site and then put it into the extras package. :)

[mikedee]

I have just changed my copy to remove the widget stuff - it isnt needed anymore.

My copy is on my server but I am not sure I modified the latest version (I think it was)