Re: [compiz] [PATCH] Grab state & Last state remembering
Hi, > This patch should be removed i think. > > http://forum.go-compiz.org/viewtopic.php?p=5071#5071 > > I just post a version of group plugin working without lastState from core. > > Danny, you can save previous window state in GroupWindow instead of core: > look > at previousState variable i add. Yes, you are right. But IMO, saving it locally still isn't perfect ;-) The best way to go is what David just started: Using changeWindowState instead of setWindowState (and keeping setWindowState static) so a state diff (or the last state) can be passed along the state change notify. Regards, Danny ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] BCOP: The Beryl/Compiz XML options parser
Am Montag, den 05.03.2007, 19:17 +0100 schrieb Dennis Kasprzyk: > ... Bcop allows you easily to describe > options in XML and will autogenerate the needed Beryl/Compiz C code for you... Hey, handlich. Got to check that out. Best regards... MacSlow -- email - [EMAIL PROTECTED] www - http://macslow.thepimp.net lowfat - http://macslow.thepimp.net/sponsor-it ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] place plugin window matching
David Reveman wrote: On Tue, 2007-03-06 at 01:08 +0100, Bellegarde Cedric wrote: Le lundi 5 mars 2007, vous avez écrit : The patch was good, I just wanted to reduce some code and make it possible to match both vertical and horizontal viewport position So here my question, what is a vertical viewport position? I can see the concept in some WM, but in compiz... The cube plugin just doesn't support it. Plane plugin support it and there might be other plugins too that I'm not aware of. Wall plugin [1] supports it too, change both these options to 3 and then load wall instead of cube and rotate and initiate expo mode (Super+e) general/screen0/vsize, general/screen0/hsize That shows vertical viewports, I assume your original patch wouldn't allow you to place a window on the middle or bottom rows. [1] http://forum.go-compiz.org/viewtopic.php?t=551 ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] Grab state & Last state remembering
Le lundi 5 mars 2007, David Reveman a écrit : > I've applied the patch. However, all code that cause a change to the > state should be modified so that a mask of changed bits can be passed to > the state change notify function instead. This lastState variable > shouldn't have to exist. This patch should be removed i think. http://forum.go-compiz.org/viewtopic.php?p=5071#5071 I just post a version of group plugin working without lastState from core. Danny, you can save previous window state in GroupWindow instead of core: look at previousState variable i add. Cedric ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] place plugin window matching
On Tue, 2007-03-06 at 01:08 +0100, Bellegarde Cedric wrote: > Le lundi 5 mars 2007, vous avez écrit : > > The patch was good, I just wanted to reduce some > > code and make it possible to match both vertical and horizontal viewport > > position > > So here my question, what is a vertical viewport position? I can see the > concept in some WM, but in compiz... The cube plugin just doesn't support it. Plane plugin support it and there might be other plugins too that I'm not aware of. > > > . I haven't actually tried the changes I put in :) so please let > > me know if it's not working correctly. > > Just a little mistake ;) > http://hibbert.univ-lille3.fr/~cbellegarde/Compiz/place_mistake.patch Of course. Thanks. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] CompWindowActionMoveMask (move plugin)
On Tue, 2007-03-06 at 00:34 +0100, Bellegarde Cedric wrote: > Le lundi 5 mars 2007, vous avez écrit : > > I have not looked at this problem yet. How is _NET_WM_ACTION_MOVE > > removed from the list of allowed actions? > > > > - David > > winrules plugin use a copy of compiz setWindowActions() as it's not > available > in compiz.h, maybe i'm missing something > It should be cool to have access to it instead of duplicate code. > > But i've got another problem with that: > > When a window emit a PropertyNotify with XA_WM_NORMAL_HINTS, compiz > handleEvents() call updateNormalHints () and recalcWindowActions () calling > setWindowActions(). > So, when winrules plugin set an action restriction, it is removed by > recalcWindowActions (). For exemple, every Kde apps living in systray emit > such a PropertyNotify after MapNotify. > > I have looked at kwin code, they do the same but at the end, they call an > updateAllowedActions() function not reseting locked actions. > > Maybe we can add a restrictActionMask to CompWindow allowing plugins to set > actions that should not be updated by setWindowActions() ? Yes, it's not currently supported to restrict available actions. We need a getRestrictedActions screen function and a function that triggers recalculation of available actions. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] Grab state & Last state remembering
On Mon, 2007-03-05 at 17:07 +0100, Danny Baumann wrote: > Hi, > > while porting "Group with tabs" to Compiz > (http://forum.go-compiz.org/viewtopic.php?t=649), I noticed some things > which are available in Beryl, but not in Compiz and which I believe > Compiz should have, too: > > - Remembering of the last window state inside the state change notify > This is useful for properly tracking down the window state changes (e.g. > has the window been maximized in that state change?). In Beryl, we added > a variable lastState into CompWindow, which is updated inside core's > stateChangeNotify. The attached last-window-state.patch brings that > behaviour to Compiz. I've applied the patch. However, all code that cause a change to the state should be modified so that a mask of changed bits can be passed to the state change notify function instead. This lastState variable shouldn't have to exist. > > - Remembering the grabbing state > Previously, only one window could be grabbed at a certain time. However, > when using group, a number of windows can be grabbed at a certain time, > so I think it's useful to provide this information to all plugins > without requiring them to wrap into the grab / ungrab notifies. Applied this too but the whole grab/ungrab window interface is probably a big mistake to start with. It was sort of a simple hack to get the wobbly plugin working a long time ago. Do we have other plugins that use this today? > > - Resize diff information > I sent this patch to the list before, may I ask if it could be > commited? ;-) done. > > Additionally, some more things are needed for group (and probably other > plugins), which I currently solved locally (inside group), but believe > that it would make sense to put them inside core: > > - A function screenGrabExists > This function, as the name implies, checks if a certain plugin has a > screen grab. It's pretty similar to otherScreenGrabExists and could > share a lot of code with it. We need this kind of functionality in group > to distinguish between user initiated / non user initiated window > moves / resizes; but I can imagine that this kind of function could come > in handy to other plugins as well. This is probably OK. I'm a bit reluctant to adding things that provide functionality that allow plugins to know about other plugins. I believe that the more dependencies between plugins we have the harder it's going to be to maintain and keeps things stable. > > - A fixed byte ordering image loading > In group, we have some hard-coded textures (for glow) inside a header > file which - obviously - have a fixed byte ordering. If those textures, > generated on an Intel CPU, are displayed on a PC using a PPC CPU, the > byte ordering is reversed by the function imageToTexture causing the > texture being displayed incorrectly. In my opinion, it would make sense > to add a parameter to the function imageBufferToTexture which > enables/disables this byte swapping inside imageToTexture. Do you mean the byte-order or scanline-order? That function will not do any byte swapping it will only tell the GL that the data is in native byte order. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] place plugin window matching
Le lundi 5 mars 2007, vous avez écrit : > The patch was good, I just wanted to reduce some > code and make it possible to match both vertical and horizontal viewport > position So here my question, what is a vertical viewport position? I can see the concept in some WM, but in compiz... > . I haven't actually tried the changes I put in :) so please let > me know if it's not working correctly. Just a little mistake ;) http://hibbert.univ-lille3.fr/~cbellegarde/Compiz/place_mistake.patch Cedric ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] CompWindowActionMoveMask (move plugin)
Le lundi 5 mars 2007, vous avez écrit : > I have not looked at this problem yet. How is _NET_WM_ACTION_MOVE > removed from the list of allowed actions? > > - David winrules plugin use a copy of compiz setWindowActions() as it's not available in compiz.h, maybe i'm missing something It should be cool to have access to it instead of duplicate code. But i've got another problem with that: When a window emit a PropertyNotify with XA_WM_NORMAL_HINTS, compiz handleEvents() call updateNormalHints () and recalcWindowActions () calling setWindowActions(). So, when winrules plugin set an action restriction, it is removed by recalcWindowActions (). For exemple, every Kde apps living in systray emit such a PropertyNotify after MapNotify. I have looked at kwin code, they do the same but at the end, they call an updateAllowedActions() function not reseting locked actions. Maybe we can add a restrictActionMask to CompWindow allowing plugins to set actions that should not be updated by setWindowActions() ? Cedric ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] place plugin window matching
On Mon, 2007-03-05 at 14:47 +0100, Bellegarde Cedric wrote: > Here a patch to enable window position/viewport matching in place plugin: > > http://hibbert.univ-lille3.fr/~cbellegarde/Compiz/place_matches.patch I'm sure a lot of people find this useful. I re-worked your patch a bit and put it in head. If you have any questions about the changes I made please let me know. The patch was good, I just wanted to reduce some code and make it possible to match both vertical and horizontal viewport position. I haven't actually tried the changes I put in :) so please let me know if it's not working correctly. > > I don't know how to initialise properly x and y position max value in options > initialisation. MINSHORT, MAXSHORT makes most sense and if we want to actually constrain the position to the screen size, that must be done dynamically when matching. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] CompWindowActionMoveMask (move plugin)
On Sun, 2007-03-04 at 20:41 +0100, Bellegarde Cedric wrote: > Here a patch to make move plugin take care of CompWindowActionMoveMask. > > http://hibbert.univ-lille3.fr/~cbellegarde/Compiz/respectWindowActions.patch applied. > > There is also a bug in gtk-window-decorator. > > If you use this plugin: > http://forum.go-compiz.org/viewtopic.php?t=643 > > Set your terminal to be non movable, terminal window doesn't have > _NET_WM_ACTION_MOVE, but you can move it with decoration. Use Alt+Button1, > window move and then gtk-window-decorator know that window can't be moved. > (this exemple doesn't work with my patch as move plugin will not let > gtk-window-decorator move the window). > > Remove move restriction, gtk-window-decorator can't move window, use > Alt+Button1 to move window, then gtk-window-decorator can move window. > > It seems that there is a sync problem between current window actions and > gtk-window-decorator. I have not looked at this problem yet. How is _NET_WM_ACTION_MOVE removed from the list of allowed actions? - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] dbus introspection
Travis Watkins wrote: We to advertise the dictionary method with introspection but still support the old method. Not sure if you can do it with the same "activate" message though. It should be easy enough, just a case of checking the type of the first iterator and handling either string or array. Ill try to get something better done once your other changes are in for the option setting/getting. You can just leave out activate methods since they aren't useful for building a settings GUI. If dbus-send now supports dictionary types then there is no need to keep the old functionality. ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] My last post buggered - FWD about patch version2
On Sun, 2007-03-04 at 11:45 -0500, Will Farrington wrote: > No idea why my last post buggered, so here's what I meant to send > (attached is his actual patch): > > Hi! > I made a little patch I'd like to see integrated (if appropriate) done. > which makes Compiz usable in desktop+TV-out setups. It adds the > --only-current-screen option to compiz which tell it to only manage > the screen defined by $DISPLAY and leave the others alone. > > With this patch I can finally use Compiz on my desktop monitor > (DISPLAY=:0.0) while TV-out (DISPLAY=:0.1) is independently running > fullscreen apps like MPlayer/MAME/ZSnes/MythTV/etc... > > Regards, > Per Wigren aka Tuxie, [EMAIL PROTECTED] Thanks, - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] dbus introspection
On 3/5/07, Mike Dransfield <[EMAIL PROTECTED]> wrote: Those patches were fairly rough. I think they would need to be fixed so that the old behaviour was still accepted (ie. series of kv pairs), it would also need some error checking. I think that a dictionary will break dbus-send compatibility because they claim not to support the dictionary type in their man page (they also claim not to support array, but they do) We to advertise the dictionary method with introspection but still support the old method. Not sure if you can do it with the same "activate" message though. -- Travis Watkins http://www.realistanew.com ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] sticky windows and rotate focus
On Sat, 2007-03-03 at 10:31 -0700, Steve Leung wrote: > Hi everyone, > > One thing that has always annoyed me about compiz is how rotate > handles sticky windows. If you have a sticky window on your desktop, > it will usually (always?) get focus when you rotate to a different > face on the cube. This happens even when other windows have been > focused more recently on the face you rotate to. The problem is that when you map a sticky window or make a window sticky you usually give it input focus. Later when switching to a different viewport the sticky window will be the last window of the windows on the new viewport that had focus, hence it receives input focus again and is now the last focused window when when you rotate to some other viewport. > > This seems like silly behaviour, because sticky windows are (for me) > 'background' windows like media players, IM clients, and so on. The > non-sticky windows are where I do all my work, so focus should go > there whenever I rotate faces. I don't like to add special treatment to sticky windows because they are often used in a specific way but I guess it's not too bad and I don't have a better solution right now. Do you know what other WMs are doing about this problem? > > I've attached a patch that fixes this. It makes focusDefaultWindow > only focus a sticky window if it already had focus. This means that > if you do focus a sticky window and rotate faces, that window will > stay focused. > > I'm not really sure what other consequences this change has, but I > haven't found any problems so far. Can anyone offer some advice? The problem would be that someone would have sticky windows that they don't want to behave this way and would complain about them not getting focused properly. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] decoration mask
On 3/5/07, David Reveman <[EMAIL PROTECTED]> wrote: Some of my plans for the drawing infrastructure in compiz will solve this problem nicely so if we can live without it for now, I'd be happy. We seem to be able to work around it for now, dunno why it's needed in beryl actually. -- Travis Watkins http://www.realistanew.com ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] CompDisplay from loaderLoadPlugin
On 3/5/07, David Reveman <[EMAIL PROTECTED]> wrote: Wrap setDisplayOption and track changes to the active_plugins option. That will let you know when a plugin gets loaded or unloaded. That's what I was doing originally but then you have to keep a copy of the active_changes list around and compare old to new. Wrapping initPluginFor(Display|Screen) works fine though. -- Travis Watkins http://www.realistanew.com ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] rxvt-unicode windows
On Sat, 2007-03-03 at 09:41 +1000, Patrick Ohearn wrote: > With latest compiz from git and latest stable version I have an issue > with rxvt-unicode (urxvt). Every window seems to get screwed up, I can't > touch the window title at all, I have to use the move key-bind to move > the window around. > > The title bar also is half white half blue, Has anyone else encountered > this issue. It is not present in Metacity or Openbox. But it is in > beryl. > > Here is a screenshot of the behavior > http://ge3k.net/files/rxvt-unicode-compiz.png Works fine for me. It looks like a old bug that got fixed a some time ago. Are you sure you're using latest version of gtk-window-decorator? - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] CompDisplay from loaderLoadPlugin
On Fri, 2007-03-02 at 23:43 -0600, Travis Watkins wrote: > I'm trying to use custom functions for loaderLoadPlugin and > loaderUnloadPlugin to register/unregister plugin paths in the dbus > plugin as needed but I need to get access to a CompDisplay or > DbusDisplay in order to do so. Is there any way to get access to this? Wrap setDisplayOption and track changes to the active_plugins option. That will let you know when a plugin gets loaded or unloaded. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] Role window matching
On Fri, 2007-03-02 at 21:42 +0100, Bellegarde Cedric wrote: > http://hibbert.univ-lille3.fr/~cbellegarde/Compiz/role_match.patch > > This patch add a new match type in regex plugin. > > You can now add a "role=" in match strings... > > This will enable me to put window matching into bs plugin and remove > Opacity/Brightness/Saturation window matching from state plugin (currently in > conflict with opacity window matching from core). Patch is good except that it doesn't track changes to the role property. I fixed that and applied it. git diff 5377991cd9af5cfebe38907030704ba43a4f0ead bdb337ada2f0689617bfea5d80d5b45f6436ddf3 if you want to see what was missing. Thanks, - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] prevention focus obsolete
On Fri, 2007-03-02 at 13:17 +0100, Bellegarde Cedric wrote: > http://hibbert.univ-lille3.fr/%7Ecbellegarde/Compiz/prevention.patch > > Here a patch to remove focus_prevention option. Put a zero string in > focus_prevention_match do the same. Yes, the focus_prevention option seem unnecessary now. I've applied your patch. Thanks, - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Xvideo and X.org on Intel GMA
On Fri, 2007-03-02 at 12:44 +0100, Thomas Liebetraut wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > Hiho, > > I already reported this in <[EMAIL PROTECTED]> and found > time to reinstall compiz yesterday and the problem still persists. > I have Ubuntu's X.org 7.1.1 running on a Intel GMA 950 and latest > compiz. When watching Xvideo files, the overlay window remains black. If > I slightly move the video window, the video appears with the usual > Xvideo quality and smoothness, but it usually disappears soon after or > is overlapped by some black boxes where other window are below the video > window. > Is there any solution to this problem or am I the only one experiencing > this? I start compiz with LIBGL_ALWAYS_INDIRECT set to 1 for it to > recognize AIGLX' GLX_EXT_tfp, but this is another issue... > Would the problem go away if I'd use Xgl? Is Xgl even supported on Intel > graphics cards and is Xgl's Xvideo acceleration still based on fragment > shaders? Xgl works fine on intel graphics cards and if the card supports ARB_fragment_program it will expose it. You should give the new video plugin a try. Patch Xgl to support 8bit GLX pixmaps so the YV12 image format can be used and you'll get very efficient video playback. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] decoration mask
On Fri, 2007-03-02 at 00:28 -0600, Travis Watkins wrote: > Beryl has this mask called PAINT_WINDOW_DECORATION_MASK that the > decoration plugin sets when it's drawing the decorator windows. It > lets you apply an effect to a window that doesn't affect the > decorations. Does this sound like something that would be useful in > compiz? Some of my plans for the drawing infrastructure in compiz will solve this problem nicely so if we can live without it for now, I'd be happy. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Composite retained drawing protocol
On Thu, 2007-03-01 at 20:19 -0500, Robert Carr wrote: > I've recently drafted a rough idea of a composite manager agnostic > protocol for leveraging the compositor for retained drawing in a way > suitable for highly interactive and flexible applications. > > It seems to be that for anything like this to be a success it would > have to be developed with the support of multiple window managers, and > I would appreciate any feedback, ideas, and contributions to the draft > on behalf of the Compiz crowd. > > The RFC is available at: > http://wiki.freedesktop.org/wiki/Standards_2fComposite_2dretained_2ddrawing > > PDF (much better formatting) at: > http://gitweb.beryl-project.org/?p=users/racarr/architecture/.git;a=blob_plain;f=cmrds.pdf;hb=HEAD > >From reading the draft it's not obvious that it's a retained mode drawing interface. It looks more like an immediate mode drawing interface to me. Anyhow, whatever we'll come up with for retained mode rendering, I strongly believe that the retained model should be completely separated from the communication protocol. I don't know what kind of retained mode drawing interface that will be good for the future and I'm not really interested in selecting one. I'm interested in coming up with a very general description that only defines a loose hierarchical model which can be extended to fit whatever retained mode drawing that we want today and tomorrow. The current drawing code in compiz needs some work. It was originally design for much less than what it's doing today, it still does a decent job today. We've been extending and tweaking it to make it work for what we want to do and we've been able to do this without making it too messy but it's far from good. I have some pretty exciting ideas for how we can re-design the drawing infrastructure in compiz and incrementally make changes to get there. I'll send an outline for this to the compiz list sometime soon so it can be discussed more. However, the re-design of the compiz drawing framework relates very much to the need for being able to provide retained mode drawing interfaces and I look forward to discussing this more. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] dbus introspection
Travis Watkins wrote: On 3/5/07, David Reveman <[EMAIL PROTECTED]> wrote: I haven't looked at it yet. I will soon. If all the functionality that the current dbus plugin provides works OK, then I don't see any reason for holding back on this one. Should I add mikedee's changes? They change the interface for activate. If you want I can add that and then split the patch into pieces. Those patches were fairly rough. I think they would need to be fixed so that the old behaviour was still accepted (ie. series of kv pairs), it would also need some error checking. I think that a dictionary will break dbus-send compatibility because they claim not to support the dictionary type in their man page (they also claim not to support array, but they do) ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Flat file backend (ini)
On Mon, 2007-03-05 at 18:03 +, Mike Dransfield wrote: > Gerd Kohlberger wrote: > > > > The IN_MODIFY bit isn't really useful for text files. > > > > If you watch the event sequence which get emited by inotify you'll see > > something like: > > > > 1) MOVE compiz.conf -> compiz.conf~ > > 2) MOVE compiz.conf~ -> compiz.conf > > 3) DELETE compiz.conf~ > > > > So if you watch compiz.conf directly and you open it in a text editor > > it gets moved. > > After that inotify seems to loose track of that file and the kernel > > will send an IN_IGNORED event, > > which automatically removes the watch. This is why modify only works > > the first time. > > > > I think the best solution would be to watch only the ~/.compiz/options > > dir and put all files in > > this directory. You could changed the filenames to something like > > -.conf to represent > > the different screens. > > Thanks for the advice, I have changed it to do exactly that and it now > seems to be working perfectly for all editors that I have. > > It seems that I still need IN_MODIFY because without it I was only > receiving notifications on the temp file. > > I think all the major problems are solved now, its just a case of tidying > up here and there. I will probably need to add proper file locking but > it shouldn't cause too many problems. What happens when a file is > deleted will still need to be resolved (at the moment it just writes it > back) Great! > > http://www.anykeysoftware.co.uk/compiz/plugins/ini.c > > I have ifdef'd out the MODIFY bit so it will still compile without the > IN_MODIFY patch. IN_MODIFY is already in head so you don't need that anymore. It looks good. I'd like to get this into head today but the header needs to be fixed first. Novell, Inc. clearly don't hold the copyright to this file. Do "s/Novell, Inc./Mike Dransfield/" if nothing else. Thanks, - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] dbus introspection
On Mon, 2007-03-05 at 12:47 -0600, Travis Watkins wrote: > On 3/5/07, David Reveman <[EMAIL PROTECTED]> wrote: > > I haven't looked at it yet. I will soon. If all the functionality that > > the current dbus plugin provides works OK, then I don't see any reason > > for holding back on this one. > > Should I add mikedee's changes? They change the interface for > activate. If you want I can add that and then split the patch into > pieces. Let's first put your update in and then apply mikedee's changes. I'll look at your patch and apply it to head asap. Thanks, - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] gtk-window-decorator segfault
First sorry for my late answer. On mer, 2007-02-21 at 12:40 +0100, David Reveman wrote: > On Tue, 2007-02-20 at 19:17 +0100, gandalfn wrote: > > Hi, > > > > I confirm with last feisty update which include libXrender patched the > > problem disappears. Thanks very much. > > Does that mean that my XFlush workaround that's currently in the code > doesn't help? Could you check that the gradient creation wrappers in > libdecoration with XFlush calls are actually used when you use a version > of libXrender without my patches? It would seem that the problem came from the libXrender 0.9.0, I have make some test before update in version 0.9.1 and even with the XFlush workaround the problem be always present. Once the updated library, I can't reproduce the problem, with and without the Xrender patch. > > > > > Moreover, i made 2 small patchs for compiz debs : > > > > first fix gconf key for mouse move key : > > http://librarian.launchpad.net/6477876/11-fix-mouse-move-key.patch > > Yes, that's an obvious bug. > > > > > second initialize iNotifyDisplay in inotifyInitDisplay which fix crash > > on inotify plugin. > > http://librarian.launchpad.net/6477865/10-init-inotify-struct.patch > > It was just the watch pointer that wasn't initialized properly, right? yes it's that, I had made a little brutal patch, only the initialization watch pointer was enough indeed > > Thanks, > > - David > > � > Thanks for all Nicolas -- gandalfn <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] BCOP: The Beryl/Compiz XML options parser
Adding new options to a plugin is a pain. There is a lot of code that has
allways to be changed for that. This is the reason why I've created the
Beryl/Compiz XML options parser (bcop). Bcop allows you easily to describe
options in XML and will autogenerate the needed Beryl/Compiz C code for you.
The only think that needs to be changed in a existing plugins is to include
the xxx_options.h file. The autogenerated code appends the new options to the
existing options, this gives the possibility to handle some special cases in
the plugin directly.
I have not found the time to write a README that describes the functionality,
but there is a "example.options" file ("bcop [--compiz] example.options" will
generate example_options.h and example_options.c). The most interesting parts
are the automatic handling of restricted strings (type="enum") as enum and
the handling of restricted string lists (type="selection") as masks. Reading
the autogenerated code should not be that hard.
The group,subgroup and hints XML keys are only used for beryl code generation.
I have also added a new version of my generic plugins Makefile that now
handles Beryl and Compiz, multiple source files and the bcop interface.
You can checkout the code from Beryl svn with:
svn co svn://svn.beryl-project.org/beryl/trunk/bcop/
The whole system is not well tested yet. I've created a bcop component in the
beryl bug tracker at http://bugs.beryl-project.org please report bugs and
problems there.
Dennis "onestone" Kasprzyk
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] 0.4 release
On Fri, 2007-03-02 at 13:14 -0700, Mike Cook wrote: > >>> On Thu, Mar 1, 2007 at 8:03 AM, David Reveman wrote: > >>>On Thu, 2007- 03- 01 at 12:57 - 0700, Mike Cook wrote: > >> Thanks, David, that seems to partially correct it... Now if I use switcher > >> without the popup then it looks fine, but if I switch with the popup it > >> appears the texture is still clipped to the output while it zooms out, but > >> as > >> soon as the zoom animation finishes the rest is painted (which is about one > >> second later). It's more obvious if you use autorotate and the first > >> window > >> it shows causes a rotate, but as soon as the zoom out is done any later > >> rotates are fine until you terminate the switch. > > > > I can't reproduce any of this, it looks fine for me. > > > > If you do this: > > > > 1. position window X so half of it is right of the screen. > > 2. Initiate switcher in normal mode using Alt- Tab. > > 3. Switch until you get to window X. (don't terminate the switcher) > > 4. Initiate rotate using Control- Alt- Button1. > > 5. Rotate so you're in front of window X, which should be floating > > slightly above the cube. > > > > Is window X rendered correctly when doing this? It should be. > > Yes, that appears to render fine... As an update, I tried this update both > in SLED10 (with nVidia 9746 and Xgl) and openSUSE10.2 (with nVidia > 9746 and their aiglx). I see the problem with the clipping during switcher > zoom animation in SLED10, but I don't see that now in openSUSE (but > did previously). I have two different sized outputs (1600x1200 & > 1280x1024) using an nVidia 7300 GS card. I also verified that it started > with the updates around Jan 23-26, so looks like it may be related to > the change to use clipping planes like you suspected. Yes, it might related to the clipping planes and using two different sized outputs. My dual head setup is currently using the same resolution on both heads. > > >> Also, I noticed I see the same clipping behavior if I drag move a window > >> to the edge and it triggers a rotate. > > > > That should definitely work. It's pretty easy to test, especially when > > using slow animations (Shift- f10), right? I don't know why it's broken > > for you, maybe clip planes are broken in your driver. What HW/driver are > > you using? > > I see this problem on both SLED10 and openSUSE. Here's a partial > screenshot of what I'm seeing when dragging a window over the edge to > trigger a rotate. (Basically on the left output I see the left half of each > cube > face, and on the right output I see the right half of each cube face). > > http://i154.photobucket.com/albums/s273/m1kecook/Compiz/drag_rotate_clipping.png > (Note that I the tearing is just an artifact of trying to get a screenshot > during animation.) I don't know exactly what I'm seeing in that screenshot but it looks bad. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Flat file backend (ini)
On Sun, 2007-03-04 at 23:06 +0100, Gerd Kohlberger wrote: > Mike Dransfield schrieb: > > David Reveman wrote: > >> On Fri, 2007-03-02 at 13:35 +, Mike Dransfield wrote: > >> > >>> This seems roughly what I would need. I applied your patches and added > >>> IN_MODIFY since I need that too. > >>> > >> > >> Yes, we need a MODIFY bit. > >> > > > > I am attaching a patch for that > > > > I have also changed the notification functions as you said. > > I now create a custom structure to pass through which contains > > all the information that I need. > > > > There are 2 major problems though: > > > > 1. If I add a delete and a notify function then the closure gets > > mixed up. Everything works if I just add 1 but more than 1 and > > they seem to interact with each other. I am creating the watches > > with different functions, I just pass the same closure (line 1031). > > > > 2. The modify notification works, but only the first time. With > > the current version I can modify a file once and I get the notification > > and the option reloads, but if I modify the file a second time then > > I get no notification. > > > > The IN_MODIFY bit isn't really useful for text files. > > If you watch the event sequence which get emited by inotify you'll see > something like: > > 1) MOVE compiz.conf -> compiz.conf~ > 2) MOVE compiz.conf~ -> compiz.conf > 3) DELETE compiz.conf~ > > So if you watch compiz.conf directly and you open it in a text editor it gets > moved. > After that inotify seems to loose track of that file and the kernel will send > an IN_IGNORED event, > which automatically removes the watch. This is why modify only works the > first time. > > I think the best solution would be to watch only the ~/.compiz/options dir > and put all files in > this directory. You could changed the filenames to something like > -.conf to represent > the different screens. > > Also the inotify plugin should probably handle those kernel events (like > IN_UNMOUNT), because if watches get automatically > removed by the kernel, it will confuse compiz internal list of watches. But i > haven't really tested this, so might not be necessary. Yes, inotify plugin should deal with that. I left that out for later and any patches that would improve the current code would be greatly appreciated. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Flat file backend (ini)
On Sun, 2007-03-04 at 22:47 +0100, Gerd Kohlberger wrote: > David Reveman schrieb: > > hm, you're currently suppose to use different call-back functions for > > this. > > > > e.g. if you want to know the difference between move or delete do: > > > > addFileWatch (d, path, NOTIFY_MOVE_MASK, fileMovedCallBackFunc, (void *) > > data); > > addFileWatch (d, path, NOTIFY_DELETE_MASK, fileDeleteCallBackFunc, (void *) > > data); > > > > instead of: > > > > addFileWatch (d, path, NOTIFY_MOVE_MASK | NOTIFY_DELETE_MASK, > > fileRemovedCallBackFunc, (void *) data); > > > >> Currently the name variable in the callback sends the event->name of the > >> inotify struct, > >> but that's not very useful. eg. if you watch two files directly, there is > >> no way to distinguish > >> between them in the callback, because event->name will be empty. > > > > if you want to watch two different files you should currently use two > > different call-back functions. The name variable is intended for when > > you're watching directories. > > > >> So the new CompNotifyEvent will send the watch path if a file is watched, > >> or the relative filename if a directory is watched. > >> > >> I think this can be very useful for the ini plugin and for other plugins > >> as well. > > > > I'm not sure we want to do these changes as unless I'm misunderstanding > > something the current interface provides the same functionality. What > > are the advantages of changing this way? > > Yes the functionality is already there, but with this patch it's just more > convenient > to monitor more than just 2 or 3 files. > I modified inotify while playing around with the ini plugin and do doing it > with the > current interface will get you lots of callback functions which isn't really > necessary. > > e.g if you listen for 3 different events in 5 files, you would need 15 > callbacks in a plugin. Well if you need to handle all those cases differently, you need to dispatch into 15 different segments of code and whether that is done in the file watch interface or in your plugin shouldn't matter much. One call back can be convenient when you're doing almost the same thing for all those 15 cases and it makes it easy to share code. You can share just as much code the other way too, you just have to use more functions. If you want to use only one call back function and do the dispatch in your plugin then that's easily done by providing dispatch details in the user-data parameter. I like the current interface because it's simple but still efficient. Reporting exactly what caused the file watch to trigger might be trivial in the inotify plugin but it might make another file watch handler unnecessarily complex. > > You don't have to include the patch, i just thought it might be useful, but > it seems Mike has > already an ini version which works with the current interface. OK, good. If I'm presented with an example where the current interface definitely cause more trouble than necessary, then I'm of course interested in changing the interface. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] dbus introspection
On 3/5/07, David Reveman <[EMAIL PROTECTED]> wrote: I haven't looked at it yet. I will soon. If all the functionality that the current dbus plugin provides works OK, then I don't see any reason for holding back on this one. Should I add mikedee's changes? They change the interface for activate. If you want I can add that and then split the patch into pieces. -- Travis Watkins http://www.realistanew.com ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] window matching interface and the new match option
On Sat, 2007-03-03 at 21:04 +, Mike Dransfield wrote: > David Reveman wrote: > > If you have any questions related to this or if you have problem > > converting some plugin to use the new match option, please let me know. > > > > > > I have been doing some testing with the blur plugin. > > Here is my match string for alpha_blur > > class=Konsole & !state=maxvert > > This should remove the blur when it maximizes, but it > doesn't. I have tried it with other state matches and other > plugins with the same effect. There is no matchPropertyChanged > notification when a window changes state. Yes, that's probably true. I think it only notifies you when a ClientMessage caused the change. I'll fix this. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] dbus introspection
On Sun, 2007-03-04 at 02:19 -0600, Travis Watkins wrote: > On 3/1/07, Travis Watkins <[EMAIL PROTECTED]> wrote: > > Remaining problems: > > * need to figure out what to do with activate/deactivate > > * core doesn't get any options registered > > > > Updated the patch. It now registers/unregisters plugins on load/unload > by wrapping initPluginForDisplay and friends. I also cleaned the code > up a bit. > > Known problems: > * still don't know what to do with activate/deactivate > * had to comment out a couple free()s in my added code to make it > work, dunno why > > Please comment. I haven't looked at it yet. I will soon. If all the functionality that the current dbus plugin provides works OK, then I don't see any reason for holding back on this one. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Flat file backend (ini)
Gerd Kohlberger wrote: The IN_MODIFY bit isn't really useful for text files. If you watch the event sequence which get emited by inotify you'll see something like: 1) MOVE compiz.conf -> compiz.conf~ 2) MOVE compiz.conf~ -> compiz.conf 3) DELETE compiz.conf~ So if you watch compiz.conf directly and you open it in a text editor it gets moved. After that inotify seems to loose track of that file and the kernel will send an IN_IGNORED event, which automatically removes the watch. This is why modify only works the first time. I think the best solution would be to watch only the ~/.compiz/options dir and put all files in this directory. You could changed the filenames to something like -.conf to represent the different screens. Thanks for the advice, I have changed it to do exactly that and it now seems to be working perfectly for all editors that I have. It seems that I still need IN_MODIFY because without it I was only receiving notifications on the temp file. I think all the major problems are solved now, its just a case of tidying up here and there. I will probably need to add proper file locking but it shouldn't cause too many problems. What happens when a file is deleted will still need to be resolved (at the moment it just writes it back) http://www.anykeysoftware.co.uk/compiz/plugins/ini.c I have ifdef'd out the MODIFY bit so it will still compile without the IN_MODIFY patch. Regards Mike ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] A couple of bugs...
Hello! > > 1. kde-window-decorator crashes every now and then. > > This seems to be especially often when starting > > kaffeine media player, but not exclusively. I've > > attached a backtrace, though I don't know if it is > > useful in this form... > > I haven't been able to reproduce this yet. kaffeine > starts fine for me. > valgrind might give us some useful information. Try > running kwd like > this: > > $ valgrind --tool=memcheck kde-window-decorator Well, you need to be persistent, sometimes it works a couple of times in a row, and sometimes it doesn't... Anyway, i've attached the output of valgrind. > > 3. When mplayer starts the player window has > strange > > dimensions resulting in blank (white) window > > decorations... > > mplayer has never done this for me. could you send > that output from > xprop and xwininfo for the mplayer window? The output of xprop and xwininfo for the player window is attached... I've to add the problem happens with gmplayer and doesn't seem to exist with pure mplayer... thx. for your efforts ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de==10581== Memcheck, a memory error detector. ==10581== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==10581== Using LibVEX rev 1658, a library for dynamic binary translation. ==10581== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==10581== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation framework. ==10581== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==10581== For more details, rerun with: -v ==10581== ==10581== Invalid read of size 4 ==10581==at 0x4014729: (within /lib/ld-2.5.so) ==10581==by 0x4005B69: (within /lib/ld-2.5.so) ==10581==by 0x4007995: (within /lib/ld-2.5.so) ==10581==by 0x4010D74: (within /lib/ld-2.5.so) ==10581==by 0x400CF95: (within /lib/ld-2.5.so) ==10581==by 0x40108C8: (within /lib/ld-2.5.so) ==10581==by 0x4512F01: (within /lib/tls/i686/cmov/libc-2.5.so) ==10581==by 0x400CF95: (within /lib/ld-2.5.so) ==10581==by 0x45130B4: __libc_dlopen_mode (in /lib/tls/i686/cmov/libc-2.5.so) ==10581==by 0x44EE2CE: __nss_lookup_function (in /lib/tls/i686/cmov/libc-2.5.so) ==10581==by 0x44EE3BF: (within /lib/tls/i686/cmov/libc-2.5.so) ==10581==by 0x44F0125: __nss_passwd_lookup (in /lib/tls/i686/cmov/libc-2.5.so) ==10581== Address 0x556F024 is 36 bytes inside a block of size 38 alloc'd ==10581==at 0x4021380: malloc (vg_replace_malloc.c:149) ==10581==by 0x4007F33: (within /lib/ld-2.5.so) ==10581==by 0x4010D74: (within /lib/ld-2.5.so) ==10581==by 0x400CF95: (within /lib/ld-2.5.so) ==10581==by 0x40108C8: (within /lib/ld-2.5.so) ==10581==by 0x4512F01: (within /lib/tls/i686/cmov/libc-2.5.so) ==10581==by 0x400CF95: (within /lib/ld-2.5.so) ==10581==by 0x45130B4: __libc_dlopen_mode (in /lib/tls/i686/cmov/libc-2.5.so) ==10581==by 0x44EE2CE: __nss_lookup_function (in /lib/tls/i686/cmov/libc-2.5.so) ==10581==by 0x44EE3BF: (within /lib/tls/i686/cmov/libc-2.5.so) ==10581==by 0x44F0125: __nss_passwd_lookup (in /lib/tls/i686/cmov/libc-2.5.so) ==10581==by 0x449CF2D: getpwuid_r (in /lib/tls/i686/cmov/libc-2.5.so) ==10581== ==10581== Invalid read of size 4 ==10581==at 0x4014713: (within /lib/ld-2.5.so) ==10581==by 0x4005B69: (within /lib/ld-2.5.so) ==10581==by 0x4007995: (within /lib/ld-2.5.so) ==10581==by 0x4010D74: (within /lib/ld-2.5.so) ==10581==by 0x400CF95: (within /lib/ld-2.5.so) ==10581==by 0x40108C8: (within /lib/ld-2.5.so) ==10581==by 0x4512F01: (within /lib/tls/i686/cmov/libc-2.5.so) ==10581==by 0x400CF95: (within /lib/ld-2.5.so) ==10581==by 0x45130B4: __libc_dlopen_mode (in /lib/tls/i686/cmov/libc-2.5.so) ==10581==by 0x44EE2CE: __nss_lookup_function (in /lib/tls/i686/cmov/libc-2.5.so) ==10581==by 0x5604F0B: (within /lib/tls/i686/cmov/libnss_compat-2.5.so) ==10581==by 0x560605C: _nss_compat_getpwuid_r (in /lib/tls/i686/cmov/libnss_compat-2.5.so) ==10581== Address 0x556F5A8 is 32 bytes inside a block of size 35 alloc'd ==10581==at 0x4021380: malloc (vg_replace_malloc.c:149) ==10581==by 0x4007F33: (within /lib/ld-2.5.so) ==10581==by 0x4010D74: (within /lib/ld-2.5.so) ==10581==by 0x400CF95: (within /lib/ld-2.5.so) ==10581==by 0x40108C8: (within /lib/ld-2.5.so) ==10581==by 0x4512F01: (within /lib/tls/i686/cmov/libc-2.5.so) ==10581==by 0x400CF95: (within /lib/ld-2.5.so) ==10581==by 0x45130B4: __libc_dlopen_mode (in /lib/tls/i686/cmov/libc-2.5.so) ==10581==by 0x44EE2CE: __nss_lookup_function (in /lib/tls/i686/cmov/libc-2.5.so) ==10581==by 0x5604F0B: (within /lib/tls/i686/cmov/libnss_compat-2.5.so) ==10581==by 0x560605C: _nss_compat_getpwuid_r (in /lib/tls/i686/cmov/libnss_compat-2.5.so) ==10581==by 0x449CE52: getpwuid_r (in /lib/tls/i
[compiz] compiz composited video and alpha only GLX pixmaps
I've added a simple plugin to compiz that provides a way to render video
efficiently on a composited desktop.
A video playback client basically copies video data to a pixmap and sets
an X property on a client window that describes the image format of the
data and where it should be rendered.
The compiz video plugin will scale and perform necessary colorspace
conversions when compositing the desktop.
It provides very efficient playback of video on a composited desktop and
it requires much less resources than e.g. XVideo as no intermediate
buffer is required and hence also no accelerated offscreen rendering.
RGB and YV12 image formats are currently supported but it's of course
very easy to add support for additional formats.
YV12 format requires GL_ARB_fragment_program and 8 bpp alpha only GLX
pixmap support. The server doesn't provide alpha only pixmaps today. The
attached patch adds an alternative PICT_a8 visual to composite and that
is enough for xgl to support alpha only GLX pixmaps (not sure it will
work with aiglx or nvidia's driver, I would guess not).
Adding an alpha only X visual might be a bad idea. It doesn't cause any
issues with the clients I've been running but I've seen that GDK thinks
the server is broken and spits out some warnings when it finds a visual
with masks set to 0. Might be a better idea to just add the fbconfig and
no visual but the current GLX code in the server relies on every
fbconfig having a matching X visual so it will need a bit more work and
I'd like some feedback before I start doing anything like that.
I've created a patch to mplayer's xv output code that makes it use
compiz video interface when available. Works pretty well and it even
dynamically detects when the compiz video interface isn't available
anymore and then switches to xv instead. Similar patches can easily be
created for other video playback clients, of course.
- David
diff --git a/composite/compinit.c b/composite/compinit.c
index 5a13612..bd7eeb6 100644
--- a/composite/compinit.c
+++ b/composite/compinit.c
@@ -180,6 +180,7 @@ static CompAlternateVisual altVisuals[NUM_COMP_ALTERNATE_VISUALS] = {
{ 24, PICT_r8g8b8 },
#endif
{ 32, PICT_a8r8g8b8 },
+{ 8, PICT_a8 }
};
static Bool
diff --git a/composite/compint.h b/composite/compint.h
index 9395512..3156135 100644
--- a/composite/compint.h
+++ b/composite/compint.h
@@ -110,9 +110,9 @@ typedef struct _CompSubwindows {
#endif
#if COMP_INCLUDE_RGB24_VISUAL
-#define NUM_COMP_ALTERNATE_VISUALS 2
+#define NUM_COMP_ALTERNATE_VISUALS 3
#else
-#define NUM_COMP_ALTERNATE_VISUALS 1
+#define NUM_COMP_ALTERNATE_VISUALS 2
#endif
typedef struct _CompOverlayClientRec *CompOverlayClientPtr;
--- libvo/vo_xv.c (revision 22417)
+++ libvo/vo_xv.c (working copy)
@@ -92,6 +92,517 @@
static uint32_t dwidth, dheight;
static uint32_t max_width = 0, max_height = 0; // zero means: not set
+#include "libswscale/swscale.h"
+#include
+
+#define GRAVITY_WEST (1 << 0)
+#define GRAVITY_EAST (1 << 1)
+#define GRAVITY_NORTH (1 << 2)
+#define GRAVITY_SOUTH (1 << 3)
+
+#define COMPIZ_IMAGE_FORMAT_RGB (1 << 0)
+#define COMPIZ_IMAGE_FORMAT_YV12 (1 << 1)
+
+static Atom vo_supporting_wm_check_atom;
+static Atom vo_compiz_video_atom;
+static Atom vo_compiz_video_supported_atom;
+static Atom vo_compiz_video_image_format_rgb_atom;
+static Atom vo_compiz_video_image_format_yv12_atom;
+static int vo_compiz_formats = 0;
+static int vo_compiz_format = 0;
+static Pixmap vo_pixmap = None;
+static GC vo_pixmap_gc = None;
+static Atom vo_xprop = None;
+static XImage *ximage = NULL;
+static XShmSegmentInfo compizShminfo;
+static int pixmap_width;
+static int pixmap_height;
+static int pixmap_height;
+static int pixmap_depth;
+static int pixmap_offsets[3];
+static int pixmap_pitches[3];
+static struct SwsContext *swsContext = NULL;
+static Window wm_check_window = None;
+
+static int x11_get_property (Atom type, Atom **args, unsigned long *nitems)
+{
+int format;
+unsigned long bytesafter;
+
+return (Success ==
+ XGetWindowProperty(mDisplay, mRootWin, type, 0, 16384, False,
+ AnyPropertyType, &type, &format, nitems,
+ &bytesafter, (unsigned char **) args)
+ && *nitems > 0);
+}
+
+static int error_handler (Display *dpy, XErrorEvent *e)
+{
+return 0;
+}
+
+static Bool x11_update_wm_check_window (void)
+{
+Atom actual;
+int result, format;
+unsigned long n, left;
+unsigned char *data;
+
+result = XGetWindowProperty (mDisplay, mRootWin,
+ vo_supporting_wm_check_atom,
+ 0L, 1L, False, XA_WINDOW, &actual, &format,
+ &n, &left, &data);
+
+if (result == Success && n && data)
+{
+ XErrorHandler old;
+ Window win, root;
+ unsigned int ui;
+ int i;
+
+ memcpy (&win, data, sizeof (Window));
+ XFree ((void *) data);
+
+ old = XSetErrorHandler (error_handler);
+
+ XSelectInput (mDisplay, win, StructureNotifyMask);
+
+ if (!XGetGeometry (mDisplay, win, &root, &i, &i, &ui, &ui, &ui, &ui
[compiz] [PATCH] Grab state & Last state remembering
Hi,
while porting "Group with tabs" to Compiz
(http://forum.go-compiz.org/viewtopic.php?t=649), I noticed some things
which are available in Beryl, but not in Compiz and which I believe
Compiz should have, too:
- Remembering of the last window state inside the state change notify
This is useful for properly tracking down the window state changes (e.g.
has the window been maximized in that state change?). In Beryl, we added
a variable lastState into CompWindow, which is updated inside core's
stateChangeNotify. The attached last-window-state.patch brings that
behaviour to Compiz.
- Remembering the grabbing state
Previously, only one window could be grabbed at a certain time. However,
when using group, a number of windows can be grabbed at a certain time,
so I think it's useful to provide this information to all plugins
without requiring them to wrap into the grab / ungrab notifies.
- Resize diff information
I sent this patch to the list before, may I ask if it could be
commited? ;-)
Additionally, some more things are needed for group (and probably other
plugins), which I currently solved locally (inside group), but believe
that it would make sense to put them inside core:
- A function screenGrabExists
This function, as the name implies, checks if a certain plugin has a
screen grab. It's pretty similar to otherScreenGrabExists and could
share a lot of code with it. We need this kind of functionality in group
to distinguish between user initiated / non user initiated window
moves / resizes; but I can imagine that this kind of function could come
in handy to other plugins as well.
- A fixed byte ordering image loading
In group, we have some hard-coded textures (for glow) inside a header
file which - obviously - have a fixed byte ordering. If those textures,
generated on an Intel CPU, are displayed on a PC using a PPC CPU, the
byte ordering is reversed by the function imageToTexture causing the
texture being displayed incorrectly. In my opinion, it would make sense
to add a parameter to the function imageBufferToTexture which
enables/disables this byte swapping inside imageToTexture.
If you agree with me, I can provide patches for the latter points.
Regards,
Danny
diff --git a/include/compiz.h b/include/compiz.h
index 18c51bc..982e835 100644
--- a/include/compiz.h
+++ b/include/compiz.h
@@ -2204,6 +2204,7 @@ struct _CompWindow {
unsigned int wmType;
unsigned int type;
unsigned int state;
+unsigned int lastState;
unsigned int actions;
unsigned int protocols;
unsigned int mwmDecor;
diff --git a/src/window.c b/src/window.c
index 9163786..fd37386 100644
--- a/src/window.c
+++ b/src/window.c
@@ -1949,6 +1949,7 @@ addWindow (CompScreen *screen,
w->alpha = (w->attrib.depth == 32);
w->wmType= 0;
w->state = 0;
+w->lastState = 0;
w->actions = 0;
w->protocols = 0;
w->type = CompWindowTypeUnknownMask;
@@ -2681,6 +2682,7 @@ windowUngrabNotify (CompWindow *w)
void
windowStateChangeNotify (CompWindow *w)
{
+w->lastState = w->state;
}
static Bool
diff --git a/include/compiz.h b/include/compiz.h
index 18c51bc..fa6afaa 100644
--- a/include/compiz.h
+++ b/include/compiz.h
@@ -2228,6 +2228,7 @@ struct _CompWindow {
Bool inShowDesktopMode;
Bool shaded;
Bool hidden;
+Bool grabbed;
unsigned int desktop;
diff --git a/src/window.c b/src/window.c
index 9163786..c8aa58a 100644
--- a/src/window.c
+++ b/src/window.c
@@ -1782,6 +1782,7 @@ addWindow (CompScreen *screen,
w->inShowDesktopMode = FALSE;
w->shaded = FALSE;
w->hidden = FALSE;
+w->grabbed = FALSE;
w->desktop = 0x;
@@ -2671,11 +2672,13 @@ windowGrabNotify (CompWindow *w,
unsigned int state,
unsigned int mask)
{
+w->grabbed = TRUE;
}
void
windowUngrabNotify (CompWindow *w)
{
+w->grabbed = FALSE;
}
void
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] [PATCH] place plugin window matching
Here a patch to enable window position/viewport matching in place plugin: http://hibbert.univ-lille3.fr/~cbellegarde/Compiz/place_matches.patch I don't know how to initialise properly x and y position max value in options initialisation. David may have an idea ;) Cedric ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] [PATCH] decoration plugin window matching
Here a patch to enable window matching in decoration plugin: http://hibbert.univ-lille3.fr/~cbellegarde/Compiz/decor_match.patch And a shema file if you want to test: http://hibbert.univ-lille3.fr/~cbellegarde/Compiz/decor.schema For removing shadow on panels, just add "type=dock" to no_border_match Cedric ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
