Re: [compiz] [PATCH] Resize improvements (Multiple resize modes, better aspect ratio constraining)
On Mon, 2007-04-23 at 17:54 +0200, Danny Baumann wrote: Hi, 0001-Added-options-for-additional-resize-modes.patch - I think I'll just leave this patch out and add these options once we converted the resize plugin to use the new metadata system. Yes, that's ok as it has the same effect ;-) I've done this. The description for this option mentions that it's the default resize mode because I think it makes a lot of sense to add match options that defines what resize mode to use for a specific window. This allow the user to more dynamically choose which resize mode should be used. It might also make sense to add specific actions for each resize mode so the user can set up shortcuts that will always initiate a specific resize mode. 0002-Added-painting-code-for-additional-resize-modes.patch - I think we want the paintWindow function to paint it's own instance of the window like switcher and scale plugins are doing instead of transforming the core instance. The outline drawing is OK. No big deal, will change that (although I still think that for things like resizing/minimization we should go with modifying the core instance because I don't see why we should add a second fake window instance - but we discussed this earlier ;-) ). 0003-Update-resize-logic-to-reflect-additional-resize-mod.patch - I see a lot of calls to damageScreen in this patch when damageScreenRegion should be used in all those cases to avoid redrawing more than we need. Motion events shouldn't cause the window to be move when resizing in stretch-mode and rightEdge, bottomEdge variables can be removed once that's changed. So you mean the window should just be translated in stretch mode? That makes a lot of sense, right. You're also right about the damageScreen calls (I don't think the difference will be huge as these calls are executed very rarely, but I get your point). Let's add one resize mode at a time, starting with the outline mode and what's necessary to make that work properly. We'll look at the stretch mode once that's done. Can you provide a patch against head that only adds the outline mode? 0004-Added-proper-constraining-code.patch - I hope we can avoid including all this code and instead improve the core constraint function to solve any problems that currently exist. Can you provide some details on how the constraining is not currently working properly in the resize plugin so we can discuss how to best solve that? The main point the current constraining code is lacking are the following: 1) ability to apply only a subset of all the constraints (e.g. only applying minimum/maximum size constraints) - no big deal with passing a bit mask to constrainNewWindowSize ok, let's fix that. btw, why do we need to only apply a subset of the constraints? 2) abilitity to resize windows with aspect ratio hint set to other directions than the lower right The code in the patch (which was taken from Metacity) takes the resize direction into account in order to compute the best possible window size depending on the resize direction. The problem that I see here is: how to pass the direction of resizing to constrainNewWindowSize properly? Perhaps we could pass it using an enum and assume some default behaviour when there is no clear direction (e.g. when called from addWindowSizeChanges). Sounds good to me. 0005-Warp-pointer-if-resizing-hit-constraints-to-avoid-mo.patch - I had something similar to this in the resize plugin before but removed it as it can't be done properly, it will always look bad as the cursor can never be constrained perfectly. I'd like to avoid this completely. Ok. 0006-Added-screen-damages-which-were-missing-if-the-resiz.patch - Again, damageScreen should never have to be called. You want to use damageScreenRegion. Right, will update this. 0007-Avoid-resizing-windows-to-negative-sizes.patch - The constrain size code should be fixed to take care of this if it doesn't already. It does, but there is some weird effect when only one coordinate is negative. In my testing, the size (-1|700) became something like (20| 20). I will have a look into this if there is a more appropriate solution than that patch. ok, good. 0008-Avoid-window-flashing-back-to-its-old-size-for-a-sho.patch - Does this have to be a special case? Can't we have the final size change always be the indication that the resizing is done (not only for stretch mode)? I'm not sure if I completely got your question, but the problem is as follows: - resize done - configureXWindow is called - server information is updated - ... (server processing) - (drawing during that time using the not updated w-attrib coordinates) - server processing finished, resizeWindow is called, w-attrib is updated Yes, the resize should finish once server and client processing is done and the window can be rendered at the new size. Not doing this for
[compiz] new meta data system
The most important parts of the new meta data system is now in place. Some of you might have seen that all core options, the annotate plugin and the resize plugin have been updated to use it. The meta data system allow us to reduce the amount of code in the core and plugins. It makes adding new options much easier. It allows plugin and application developers to add any additional meta data they find useful without the need to modify the core. It makes it easy and convenient to provide meta data in a separate file that can be used by configuration systems for offline reading. All this without removing any flexibility previously provided. Plugins are not required to use this new meta data system but it's highly recommended. You're not required to provide an xml file with meta data for your plugins. You can put all meta data you like to provide in the source code and only allow reading of it at run time but for configuration systems that allow manipulation of options when compiz isn't running the xml file is useful and it is recommended to provide one. Commit 5c97749750e150187775e90b1c7fb2a6f47241bd (Update resize plugin to use new metadata system) is a good example of how to update a plugin to use the new meta data system. Commit 08126fab8609a3289943e64308bfba1b1e61d89d (Add resize mode option to resize plugin) shows how easy it is to add a new option when you're using the meta data system. To do: - All plugins in the fdo repo should be updated to use the meta data system. - Option description fields should be removed from the CompOption struct and only provided through the meta data system. Requires minor updates to some plugins (e.g. dbus). - Plugin description fields should be removed from the plugin VTable struct and only provided through the meta data system. - Plugin dependencies should be removed from the plugin VTable struct and only provided through the meta data system. - Methods that allow reading of meta data for core and plugins at run-time should be added to the dbus plugin. - gconf-dump plugin and gconf schema generation should be replaced by a simple XSLT description. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] Scheme extension language plugin.
I've put a scheme plugin in users/racarr/compiz-scheme on gitweb.open-compositing.org. Essentially it allows the user to define a startup file (~/.compiz/startup.scm) and fill it with scheme code to do neat things and extend Beryl. On one hand it acts like a super powered state plugin, on the other it lets you define useful behavior specific to what you do with your Compiz and share these new behaviors with other people. Following are a few examples: #Following snippet gives you transparent dropdown menus. (window-rule #Define a window rule (make-rule #Make a rule passed in (set-opacity-when # Set opacity of a window when (window-is dropdownp) # The window is a dropdown menu 0.75))) # Set to 0.75 #Following snippet shades maximized windows when you grab them. (grab-rule # Define a window grab rule. (make-rule # Make a rule passed to grab-rule (if (maximizedp w) # If window maximized. (toggle-shaded w #Shade window (define amatch (make-match type=normal|state=sticky)) #Define a match for sticky windows or normal windows (bind-key s #Bind the key ctrl+super+s (lambda () #Define an anonymous function to be passed to bind-key (toggle-shaded-when #Toggle window shaded then (lambda (w) (matchp w amatch) #Window passed matches amatch You can read ~/.compiz/window.scm to see some of the wrapping around the C level functions (which themselves are wrapped in the C files). Ask me if you have any questions or want an example of how to do anything. I'll be improving this and doing documentation in the near future. Regards, Robert ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] drawing framework changes
When I created the current drawing framework, all we were interested in drawing was client windows. We want to draw a lot more today and the design needs to be changed to allow this properly. My current plan is to just adjust the drawing code so it's possible to draw different kind of objects. The core will be aware of some object types and plugins will be able to create it's own type of objects and properly integrate them into the drawing framework. Common to all objects will be a unique identifier and that they will all respect a transformation matrix and a set fragment attributes. 2D objects like client windows, cursors and such will easily be able to inherit all the details in the current drawing framework. Most objects will provide a tree structure and the core will probably be aware of the following objects: screen - output - root window - frame windows - client windows It will be easy for a plugin to create it's own set of objects and insert them into existing objects. E.g. decoration plugin will create a decoration object that can be inserted into the frame window object. The video plugin will create a video output object that can be inserted into the client window object. This is just some initial details about the changes I've got planned and much more details will be provided once I start writing some initial code for this. I'd like to get the vertex generation system updated first and we need to get rid of all the use of transformation attributes in the ScreenPaintAttrib and WindowPaintAttrib structures. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] Fix unredirect fullscreen windows
David Reveman napsal: On Mon, 2007-04-23 at 18:04 -0700, James Jones wrote: While trying to reproduce an error with input handling and unredirect fullscreen windows, I noticed the option didn't work at all in compiz master. This patch gets it working again. Yes, I guess that's been broken since we added the new occlusion detection code. Thanks, - David Hello, am I the only one having the following problem with unredirect_...? The fullscreen windows (think of xscreensaver) very often remain visible after unmapping and only the mouse cursor changes according to what should be where on screen. I thought invoking cube rotation or so could help (redrawing all the screen), but it does not, I need to launch and kill xscreensaver again hoping that time it will succeed. This, obviously, prevents me from using this option. I hoped this patch was meant for that issue, but it doesn't help here... To be exact, I have seen this only with xscreensaver, but since I am not a gamer, I have only that and mplayer to test. However, this is nothing serious for me, it can be caused by any part of the chain, and if it is rare, I don't want anyone to spend his time hunting this bug :-) - Vasek [nVidia GeForce FX5200] ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Flat file backend (ini)
On Thu, 2007-04-05 at 19:50 +0100, Mike Dransfield wrote: Diogo Ferreira wrote: The current INI plugin seems to fail loading when there isn't a ~/.compiz dir. Since most users won't have it I believe it makes sense to mkdir it before trying to mkdir the sub-options directory. I would have done it but since you use the get dir function a lot it would mean changing the structure a little and since it's your plugin I think you know best how to change it accordingly. Ive been meaning to get some clarification on whether or not I can rely on .compiz existing. When I first wrote the ini plugin, I though I could. Its more a global directory so I do not create it, but I can if its required. Should I be creating this directory? OR should it be the responsibility of core to make sure this exists (it is defined there) There's no way we can ever guarantee that a ~/.compiz directory exists. ~/ could be read only or the disk could be full so make sure your code can deal with that properly. Whoever wants to write something to ~/.compiz should be responsible for trying to create the directory if it doesn't exist. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] Re: compiz: Changes to 'master'
On Wed, 2007-04-25 at 11:09 -0700, Robert Carr wrote: include/compiz.h |1 + 1 files changed, 1 insertion(+) New commits: commit 2402215a6a3bd50e9d87e99d4a45de14b635ecea Merge: 1b0ae38... 7f518da... Author: Robert Carr [EMAIL PROTECTED](none) Date: Wed Apr 25 14:09:38 2007 -0400 Merge branch 'master' of git+ssh://[EMAIL PROTECTED]/git/xorg/app/compiz commit 1b0ae388155a18ea07f148d6163cf7d5deaa0cbd Author: Robert Carr [EMAIL PROTECTED](none) Date: Wed Apr 25 14:09:25 2007 -0400 Add a priv entry to CompAction. For a use case see: compiz-scheme. It's neccesary to implement in a proper way actions that have to go through a wrapper C function. In general the idea of having Actions without an assosciated Option / Actions added at run time needs to be explored a bit more because the current code is not well suited for it. Why did you add it to the CompOption struct? If we need some user data attached to actions then that should go into the CompAction struct but I'm not sure we want that at all. If you want to create run-time actions like your compiz-schema code is doing I suggest that you just use addScreenAction and check for a matching event manually in handleEvent. btw, when you're making changes to compiz.h, please make sure that they are indented correctly and matching coding style is used. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Re: compiz: Changes to 'master'
David Reveman wrote: On Wed, 2007-04-25 at 11:09 -0700, Robert Carr wrote: include/compiz.h |1 + 1 files changed, 1 insertion(+) New commits: commit 2402215a6a3bd50e9d87e99d4a45de14b635ecea Merge: 1b0ae38... 7f518da... Author: Robert Carr [EMAIL PROTECTED](none) Date: Wed Apr 25 14:09:38 2007 -0400 Merge branch 'master' of git+ssh://[EMAIL PROTECTED]/git/xorg/app/compiz commit 1b0ae388155a18ea07f148d6163cf7d5deaa0cbd Author: Robert Carr [EMAIL PROTECTED](none) Date: Wed Apr 25 14:09:25 2007 -0400 Add a priv entry to CompAction. For a use case see: compiz-scheme. It's neccesary to implement in a proper way actions that have to go through a wrapper C function. In general the idea of having Actions without an assosciated Option / Actions added at run time needs to be explored a bit more because the current code is not well suited for it. Why did you add it to the CompOption struct? If we need some user data attached to actions then that should go into the CompAction struct but I'm not sure we want that at all. If you want to create run-time actions like your compiz-schema code is doing I suggest that you just use addScreenAction and check for a matching event manually in handleEvent. I had the same problem with the python plugin (ie runtime generation of options/actions). I solved it by comparing the memory address of the action since CompActionInitiateProc has a reference to it. I am not sure this is a very nice thing to do, but it works well so far. I might have a look at doing the python plugin this way, but the lazyness inside me is saying not to ;) btw, when you're making changes to compiz.h, please make sure that they are indented correctly and matching coding style is used. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Re: compiz: Changes to 'master'
On Wed, 2007-04-25 at 20:45 +0100, Mike Dransfield wrote: David Reveman wrote: On Wed, 2007-04-25 at 11:09 -0700, Robert Carr wrote: include/compiz.h |1 + 1 files changed, 1 insertion(+) New commits: commit 2402215a6a3bd50e9d87e99d4a45de14b635ecea Merge: 1b0ae38... 7f518da... Author: Robert Carr [EMAIL PROTECTED](none) Date: Wed Apr 25 14:09:38 2007 -0400 Merge branch 'master' of git+ssh://[EMAIL PROTECTED]/git/xorg/app/compiz commit 1b0ae388155a18ea07f148d6163cf7d5deaa0cbd Author: Robert Carr [EMAIL PROTECTED](none) Date: Wed Apr 25 14:09:25 2007 -0400 Add a priv entry to CompAction. For a use case see: compiz-scheme. It's neccesary to implement in a proper way actions that have to go through a wrapper C function. In general the idea of having Actions without an assosciated Option / Actions added at run time needs to be explored a bit more because the current code is not well suited for it. Why did you add it to the CompOption struct? If we need some user data attached to actions then that should go into the CompAction struct but I'm not sure we want that at all. If you want to create run-time actions like your compiz-schema code is doing I suggest that you just use addScreenAction and check for a matching event manually in handleEvent. I had the same problem with the python plugin (ie runtime generation of options/actions). I solved it by comparing the memory address of the action since CompActionInitiateProc has a reference to it. I am not sure this is a very nice thing to do, but it works well so far. Pointer comparison is fine, there's nothing wrong with that but it's not currently allowed to add options at run-time in any other way than by activating a plugin. I might have a look at doing the python plugin this way, but the lazyness inside me is saying not to ;) If we want to run-time actions and hooking into handleEvent and manually checking if the event matches an action is currently too much trouble or not appropriate for some reason an interface for run-time actions should be added. It should be very easy to add this. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Re: [PATCH] Transparent cube
On Sun, 2007-04-22 at 14:22 +0300, Roi Cohen wrote: Hi, I re-generated the patches, so it will work now against latest git. Please note that the vertical rotation bug is now fixed, due to this commit: http://gitweb.freedesktop.org/?p=xorg/app/compiz.git;a=commit;h=36ca8bf259d79ef5ee3630e1741a213163ebbfb6 David, what do you think of these patches? Some feedback is still appreciated. I'm interested in the transparent cube feature but I'm not very happy about the set of patches that is required to get this working in the current drawing framework. I don't want to push that additional complexity into the core and force all plugins to support it. It makes more sense to provide this functionality using an interface that allow you to push painting of a set of objects to an off-screen surface. Such an interface will likely not be added until other major drawing framework changes are in place but it's definitely something that should be added eventually. So, I'm not interested in adding transparent cube support to the cube plugin I maintain until there's a more appropriate way to do it. I'm sure the transparent cube feature is popular and there's an interest in having it available today. There's no nice solution to this but you should be able to create a plugin that is loaded before all other plugins and implement the same screen painting solution as what's provide with your patch to the core. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Re: [PATCH] Transparent cube
Am Mittwoch, 25. April 2007 23:21 schrieb David Reveman: On Sun, 2007-04-22 at 14:22 +0300, Roi Cohen wrote: Hi, I re-generated the patches, so it will work now against latest git. Please note that the vertical rotation bug is now fixed, due to this commit: http://gitweb.freedesktop.org/?p=xorg/app/compiz.git;a=commit;h=36ca8bf25 9d79ef5ee3630e1741a213163ebbfb6 David, what do you think of these patches? Some feedback is still appreciated. I'm interested in the transparent cube feature but I'm not very happy about the set of patches that is required to get this working in the current drawing framework. I don't want to push that additional complexity into the core and force all plugins to support it. It makes more sense to provide this functionality using an interface that allow you to push painting of a set of objects to an off-screen surface. Such an interface will likely not be added until other major drawing framework changes are in place but it's definitely something that should be added eventually. I don't see a reason to do this with offscreen rendering. This still wouldn't solve the problem that windows have to be painted in the reversed order to make the faces in the background look right. Another disadvantage would be that transparent cube would be only supported on cards that have offscreen rendering support (fbo's). The only advantage would be be that we wouldn't need to redraw each face on each repaint. Correct me If I'm wrong here. So, I'm not interested in adding transparent cube support to the cube plugin I maintain until there's a more appropriate way to do it. I'm sure the transparent cube feature is popular and there's an interest in having it available today. There's no nice solution to this but you should be able to create a plugin that is loaded before all other plugins and implement the same screen painting solution as what's provide with your patch to the core. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] glu dependency
The following commit seems to have added a dependency on glu but does no checks to see if it is actually available: commit fa5bf5754d8a2e47d659a3abe5cb59a7b0e304d7 Author: David Reveman [EMAIL PROTECTED] Date: Tue Jan 16 06:07:39 2007 +0100 Project vertices and only update minimum required destination texture region. Some more optimizations should be done here but the current changes should still give a major performance improvement. My autofoo is very much lacking so I'm not sure how to add such a check. -- Travis Watkins http://www.realistanew.com ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
