[compiz] Compiz has been selected as the Window Manager of the Year
For those who haven't seen this already: Compiz has been selected as the Window Manager of the Year in the 2007 LinuxQuestions.org Members Choice Awards: http://www.linuxquestions.org/questions/2007-linuxquestions.org-members-choice-awards-79/window-manager-of-the-year-610196/ Congratulations to everyone who's helped make compiz what it is today! -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Object framework status?
On Mon, 2008-01-21 at 17:46 +0100, drago01 wrote: Hi, Whats the current status of the work on the object framework branch? Is there any ETA for merging it? It has been a while since it was announced. I have unfortunately not had much time to work on it lately but it should be in a pretty good state as of now. Some minor additions to the signal system needs to be done to allow file and timer objects to be implemented properly. I'll hopefully have time to get that done this week and after that, I'm all for merging it asap. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Tooltips show up on all screens of cube
On Thu, 2007-11-29 at 17:48 +0100, rudolf randal wrote: When ever i hover over something that gives me a tool tip - it is showing on all sides of my cube - dont want that - is there a cure ? Not really as we're not allowed to change the location of the tool tip windows inside compiz. They are override-redirect windows and window managers are not allowed to touch them. We could of course just avoid rendering them on more than one side of the cube but that would be pretty bad unless we also redirected the input. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Blur is incredibly slow on the intel i915
On Sun, 2007-11-25 at 20:15 +0900, Sam Spilsbury wrote: I'm getting about 1 frame every 7 seconds with alpha or focus blur enabled. Is this normal? I get around 30-40 FPS when using water on high settings. Yes, that's expected. The driver need to accelerate glCopyTexSubImage2D for blur plugin to be usable. Would framebuffer_object support for the driver be of any use? Would it make things faster? Framebuffer object support itself isn't going to help but a driver that supports framebuffer objects is also very likely to accelerate glCopyTexSubImage2D so switching to such a driver might very well help. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] window stacking bug #1
On Wed, 2007-11-21 at 22:05 +0100, Bogdan Butnaru wrote: Hello! I'm trying to find where to send a bug report/fix, and this mailing list is the best I found. I noticed several problems in how Compiz handles full-screen windows*, and I hacked a bit around the source to try to find their source. (*: I use this pretty much as a replacement for full-screen, all the time.) The first two are together below, because they seem caused by the same code. For the third I'll send another email. In all cases below, full-screen windows are NOT un-redirected. * Problem one Say the topmost window is non-full-screen and the window _immediately_ below it is a full-screen window (so the two are the topmost windows). In this case, if the user moves the normal, top-most window by dragging its title-bar, the window is immediately hidden below the full-screen one. (The move can be continued correctly, but without the benefit of actually seeing the window, unless the full-screen one is semi-transparent.) However, if the window is moved using alt+drag outside the title-bar, everything is normal. Note that this doesn't happen if there are at least two normal windows above the full-screen window. * Problem two: If the topmost window is a full-screen window, the widget layer is displayed below it when the user presses the show widgets shortcut. This means the widgets are invisible, unless the full-screen window is transparent. (Note that the window is correctly shaded. I took a look at the source, and the problem seems to be in src/window.h, function raiseWindow(). The function uses findSiblingBelow (w, FALSE) to position the window it's called on, where the FALSE parameter means that the sibling (on top of which the window is moved) cannot be a full-screen window. The result is that if the topmost window is full-screen, calling raiseWindow() on a window will leave it hidden. In the case of problem one, here are the two scenarios: When the user initiates moving a window using the Alt+drag combination, compiz calls (among other things): updateWindowAttributes(w,CompStackingUpdateModeAboveFullscreen) followed by updateWindowAttributes(w,CompStackingUpdateModeNone) However, when the user initiates a window move by dragging its title bar, the calls (excerpted) are: updateWindowAttributes(w, CompStackingUpdateModeAboveFullscreen) raiseWindow(w) updateWindowAttributes(w, CompStackingUpdateModeNone) In this case, the first call puts the window at the very top, and then raiseWindow actually moves it downwards, below the full-screen one. I believe the raiseWindow is caused by the (standard) behavior of raising a window on click. I don't know why it doesn't happen for clicks below the title-bar, though, and I couldn't find where it originates. For the second problem, it seems the Widget plugin calls raiseWindow to put the widget windows (I use screenlets) on top of the screen. Which of course can't happen if the topmost window is full-screen, because of how raiseWindow is defined. *** I'm not sure exactly why raiseWindow is defined the way it is now. Unless there's a very good reason for it, I propose changing the second parameter of findSiblingBelow to TRUE. This would automatically fix the two issues I mentioned above. However, if there is a really good reason why raiseWindow should stack below topmost full-screen windows, we need to find solutions for the other two problems. What do you think? raiseWindow should probably be allowed to stack above fullscreen windows. I'm not sure why it's not doing that right now. I'm not sure what cases we have where we don't want to allow a window to be stacked above fullscreen windows but for a window that is not a transient of the fullscreen window to be stacked above it, the fullscreen window must first be lowered below the dock-window layer (e.g. gnome-panel) and you don't want that to happen unless it really makes sense. The current stacking code is pretty error prune and I've been thinking about replacing it with some less complex code that validates the complete stack of windows every time a stacking change need to be made. It will be easier to handle all these special cases for fullscreen windows once this gets done. However, I prefer to wait with this until we have a proper object system in place. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] video plugin update
On Tue, 2007-09-04 at 15:16 +0200, Dominik 'Rathann' Mierzejewski wrote: Hello, On Friday, 13 July 2007 at 14:11, Colin Guthrie wrote: David Reveman wrote: I had to update the video plugin interface slightly to fix some bugs. I've attached an updated mplayer patch. David, Is this patch ever going to make it upstream to mplayer do you think? Has it been submitted/reviewed by upstream devs? Any progress here? Users keep coming and asking why they can't use MPlayer with compiz. We do not have the resources to implement this (not to mention that none of the core developers use compiz). The current patch is unacceptable for inclusion in MPlayer (due to unnecessary code duplication). See this document for MPlayer patch submission guidelines: http://www.mplayerhq.hu/DOCS/tech/patches.txt There's going to be a new more appropriate video interface soon, for which support is more likely to be included upstream. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] object framework design
I'm going to start today by posting the first two, out of a series of four documents describing the work done in the object-framework branch. This post is just a heads-up but I'd also like to make sure people understand that what's described in these docs and what's in the object-framework branch is not set in stone in any way. It's a proposal based on my experience with the current compiz code-base and the research I've done lately for how we can move to what I think is a much more appropriate architecture. Feedback is much appreciated. I'm confident that with the object-framework branch work as base, together we can implement a system that is hugely superior to what we currently have. Thanks, -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] re-architecting compiz
I'd like to start with apologizing for my lack of response to the mailing list for the last couple of months. I'm working my way through all posts right now... Here's what I've been up to lately.. I did a critical review of the state of compiz about 6 months ago. I realized it was pretty bad (not that there's actually anything better out there but still), it's hard to maintain, hard to write proper code for and in some ways not dynamic enough for people to do what they want. None of the features I need to implement can be done properly in the current architecture. I spent a lot of time trying to come up with a way for us to re-engineer the core of compiz and fix all the issues that exist in the current architecture. I did a fair amount of research and experimenting before I got an idea of what would be a good future architecture. What's emerging in the object-framework branch is the result of this work and what I believe to be the best way forward. There's still some important pieces missing before I consider merging it to master a good idea but it's now at least at a stage where I'm comfortable with people starting to look at it and start discussing merging it to master. Even though I've made sure that the rewrite allows existing plugins to be fairly easily ported, it's still going to be the most significant change to compiz since the initial version was realized. If we ever had released a 1.0, this would definitely qualify for a 2.0. Most of the ground work for this new architecture has already been done in the object-framework branch but even when we've gotten it to a state where it can be merged, there's still a lot of work left to make the existing core functionality and plugins take advantage of it. However, the considerably more modularized nature of this new architecture would allow us to move to a much smaller core and get it ready for a 1.0 release in a short amount of time. I'm going to send a series of posts to the list that explains the different parts of the new architecture in more detail (hopefully the first one during the weekend) but here's a few key features of the new architecture: A strict hierarchical structure. A very well-defined way for how the different parts of the system communicate with each other (it's obvious when some code is doing something inappropriate and it's also hard to write code that is doing something inappropriate). Whether the code is in the core or in a plugin is of no significant importance, which means that pretty much anything can be modularized. Plugins can be inserted into different parts of the object tree and only affect a sub-tree of objects. An internal communication system that maps efficiently and conveniently to various IPC systems. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] core improvements
On Fri, 2007-09-07 at 17:11 -0400, Kristian Høgsberg wrote:
On 9/7/07, David Reveman [EMAIL PROTECTED] wrote:
...
- Object model
We need to easily be able to create new types of objects that plugins
can keep track of and add options to without breaking the API or even
the ABI.
The initial part of this is already in head. The object system I've
added is very simple but still sufficient. It allows us to add new core
objects without having to update any plugins.
Next step is to add an interface that will allow plugins to add their
own type of objects. This is a simple addition to the current object
system and you can expect it to land in head shortly.
I browsed the patch, and it look mostly good, but I wondered why you
decided to go for a 'type' integer instead of the more custom 'class'
pointer (or objectInfo pointer). Then you could just do
char *
compObjectName (CompObject *object)
{
return (*nameObject-ObjectInfo) (object);
}
and the CompObjectInfo structs can be static variables in the relevant
files (screenObject info in screen.c etc) and the functions they point
to can be static too.
Yes, I think we want that eventually. However, I currently use the type
integer as a dispatch table index in a lot of places (like the
initObject VTable functions) and some of the current objectInfo
functions need to be called without an instance of the object (e.g.
forEachObject).
The dispatch index can be avoided once we make all wrap-able functions
part of the object type. This is basically just the next step towards
more standard polymorphism.
I don't want to enforce a specific data type for keeping track of
objects. The forEachObject function solves that but it can simple be
moved into the object type vtable instead. Same thing for the findObject
function.
I'll try to come up with a step by step plan for how we accomplish this
and send it to the list sometime soon...
TODO
- Matching interface
The matching interface should be updated to work with all kinds of
objects and not only window objects. This should be easy to get done as
I had something like this in mind when I first implemented the matching
system.
- Replace the option system
This sounds like more work than what it is. All I want to do is rename
existing options to properties and add methods and signals. A property
will be pretty much exactly the same thing as an option is today except
that there's not going to be an action property. A method will be
similar to what an action option is today but it will include a
signature and the initiate/terminate bs ripped out.
What options provide today is really just a IPC mechanism. D-BUS got a
very good model for this and I'd like to adjust compiz so it matches
that model as much as possible.
Sounds cool.
- Output plugin support
The actual rendering should be separated from the core. Most of the
current rendering code will be moved into a GL output plugin. Multiple
output plugins can be active at the same time and they shouldn't
necessarily have to be drawing to the screen. E.g. the screenshot plugin
will be an output plugin that render to a file instead of the screen. An
xrender output plugin could easily be created. However, some of the
existing plugins will rely on the GL output plugin, e.g. blur and video
plugins.
Interesting. Where do you see this going? What's the motivation for
supporting other output methods?
There's a few things that we like to accomplish.
Some people have asked for xrender output support. These changes would
allow that to be implemented even though some of the more impressive
plugins are not going to work without GL. This might not make a lot of
sense for the regular desktop machine but for some remote composited X
situations (I'll talk about this at XDS) it can make a lot of sense.
It allows me to integrate the remote composited X experiments I've been
playing with properly.
Would make it very easy to support AGL, WGL if desired. It even be
possible to support Direct3D.
It would also provide a well defined way for screen capturing,
printing..
-David
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] core improvements
I've been making a large set of important updates to the code base recently and there's more stuff on it's way but I'd like to get some feedback first. I know that some of the changes I've made and will be making require a fair amount of work by plugin and config tool developers but I hope you can bear with me. They are very important for the future of the project. - API, ABI and plugin interface separation This is in head already. compiz.h now contains an API that will be kept fairly stable. It's useless in it's current state but more functions will be added and simple plugins will be able to use this API and work across multiple ABI versions. Regular symbol resolution performed by dlopen and a simple minor version number check is enough to ensure that a plugin is not accidentally loaded into compiz with an incompatible API. The ABI will likely always change rapidly and any plugin that includes compiz-core.h is also responsible for verifying the ABI version when being loaded. The plugin interface can be found in compiz-plugin.h and it will rarely change. The getCompPluginInfo symbol needs to change every time the plugin interface changes to ensure that plugins with an old interface aren't accidentally loaded. - Object model We need to easily be able to create new types of objects that plugins can keep track of and add options to without breaking the API or even the ABI. The initial part of this is already in head. The object system I've added is very simple but still sufficient. It allows us to add new core objects without having to update any plugins. Next step is to add an interface that will allow plugins to add their own type of objects. This is a simple addition to the current object system and you can expect it to land in head shortly. - Multiple displays Being able to manage multiple displays might seem unnecessary but making sure that it works improves the design of the core and I'm also working on a related project that will take advantage of it. I've updated the core and most plugins so they work correctly with multiple displays. However, our configuration plugins needs some more work. - Core object There's now a core object. This is the only object that is allowed to be parentless, every other object needs a parent. A lot of hooks that currently exist in the display object should be moved into core object. All general object hooks should be in the core object. TODO - Matching interface The matching interface should be updated to work with all kinds of objects and not only window objects. This should be easy to get done as I had something like this in mind when I first implemented the matching system. - Replace the option system This sounds like more work than what it is. All I want to do is rename existing options to properties and add methods and signals. A property will be pretty much exactly the same thing as an option is today except that there's not going to be an action property. A method will be similar to what an action option is today but it will include a signature and the initiate/terminate bs ripped out. What options provide today is really just a IPC mechanism. D-BUS got a very good model for this and I'd like to adjust compiz so it matches that model as much as possible. So basically, each plugin can provide an interface for every object. The interface contains a set of properties, methods and signals. E.g. a Key or Button property is just a property that defines a key/button combination that will trigger invocation of a specific method. Full interface descriptions that can be used by applications to generate bindings can easily be created from the compiz meta-data. Further on, a plugin can be seen as a service and D-BUS could be able to handle plugin loading and unloading as desired by applications. The key names used by gconf plugin and group names used by kconfig plugin needs to change to properly reflect the new object system. gconf should use /apps/compiz/'plugin'/'object-path'/'property' as key name. kconfig should use 'plugin'_'object-path' as group name. 'object-path' could be something like this: display/:0/screen/0 This will break existing configuration tools but it can't be avoided and the should be easy to update all tools that exist. - Output plugin support The actual rendering should be separated from the core. Most of the current rendering code will be moved into a GL output plugin. Multiple output plugins can be active at the same time and they shouldn't necessarily have to be drawing to the screen. E.g. the screenshot plugin will be an output plugin that render to a file instead of the screen. An xrender output plugin could easily be created. However, some of the existing plugins will rely on the GL output plugin, e.g. blur and video plugins. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] WindowRemoveNotifyProc
On Wed, 2007-08-22 at 12:53 -0400, Nicolas Viennot wrote: Hello, I'm doing a C++ wrapper and I need the counterpart of WindowAddNotifyProc Every plugin must be rebuild since CompScreen is modified, hence ABIVERSION should be changed as well. Would it be possible to implement it ? Patch attached Thanks, I applied it to my local branch. However, we need these kind of hooks for any kind of object so WindowAddNotifyProc/WindowRemoveNotifyProc has now been replaced by ObjectAdd and ObjectRemove hooks. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [ANNOUNCE] compiz-0.5.4
On Mon, 2007-08-20 at 16:22 -0400, Kristian Høgsberg wrote: On 8/20/07, David Reveman [EMAIL PROTECTED] wrote: A new compiz release 0.5.4 is now available from: http://xorg.freedesktop.org/archive/individual/app/compiz-0.5.4.tar.gz Oh... I guess I expected the next development release would be 0.7.0, since a 0.6.0 maintenance branch was created. I hope (and assume) the 0.5.4 release isn't intended to be a pre-release for the 0.6.0 stable release, especially with the new XCB requirement, but the release numbering is a little confusing. We're shipping 0.5.2 in Fedora rawhide now, and I'm expecting to spend some time fixing whatever bugs show up and contribute fixes back to the 0.6 branch (and head, of course). And I'm hoping that we can release that branch as 0.6 in time for me to pull that into the upcoming Fedora 8 release. What's the roadmap? 0.5.4 is just another development release and part of my new strategy to push out development releases every second week or when a major new feature has landed. The release number probably got wrong, though. It should probably have been 0.7.0. I'll get this right in the next release. I'm not sure what will end up in 0.6 and not. I'm not going to be much in charge of what goes into 0.6 and not. We can revert the commit that added the XCB requirement and re-base the 0.6 branch on head if people are interested in that. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] [ANNOUNCE] compiz-0.5.4
A new compiz release 0.5.4 is now available from: http://xorg.freedesktop.org/archive/individual/app/compiz-0.5.4.tar.gz which can be verified with: http://xorg.freedesktop.org/archive/individual/app/compiz-0.5.4.tar.gz.sha1 761e5ac96426cab48588d14960e84971ad103372 compiz-0.5.4.tar.gz http://xorg.freedesktop.org/archive/individual/app/compiz-0.5.4.tar.gz.sha1.asc (signed by David Reveman) Additionally, a git clone of the source tree: git clone git://git.freedesktop.org/git/xorg/app/compiz will include a signed compiz-0.5.4 tag which points to a commit named: dacb4c77f110a57185400b0635d8b8b5c985f87e which can be verified with: git verify-tag compiz-0.5.4 and can be checked out with a command such as: git checkout -b build compiz-0.5.4 WHAT'S NEW == XCB is now required. Major improvements to option system that makes configuration backend integration much less complex. Kconfig plugin that provides proper KDE configuration support. Kcfg files are generated from the meta-data and they can be used to generate C++ source code that will provide an API for applications to access all compiz configuration data used by the kconfig plugin. -David Changes since compiz-0.5.2: Danny Baumann: Remove trailing whitespace. Formatting fixes. Fix possible memleaks. Fix typos. David Reveman: Post release version increment. Fix typo. Remove whitespaces. Require x11-xcb. Add XCB connection handle to CompDisplay. Add CompNoMask to REAL_MOD_MASK. Select for focus change events on frame windows. Revert Select for focus change events on frame windows. Usage of lastFoundWindow in findTopLevelWindowAtDisplay is Avoid using lastFoundWindow in findWindowAtDisplay. Reduce code by using findWindowAtScreen in This should be taken care of by unhookWindowFromScreen. Include proper compiler flags and link libdecoration to Avoid use of strcasestr and case insensitive matching of Rearrange some headers to avoid compile issues on solaris. Cleanup. Fix many function declarations that were missing the 'const' Make compInitOptionValue and compFiniOptionValue available to Use equalRange when checking if new value is equal to Fix event handle matching. This caused inotify plugin to Default alpha value for color options is 1.0. Add key-binding option, which is just a key-binding only Add button-binding option, which is just a button-binding only Add edge option, which is just a edge only action option. Add bell option, which is just a bell only action option. Add edge modifiers. Deprecates edge button functionality. Handle new option types properly. Add isActionOption function. Add passive grabs and update event handling to trigger Switch to new action option types for all core options. Most Use new action option types in annotate plugin. Use new action option types in blur plugin. Use new action option types in clone plugin. Use new action option types in cube plugin. Use new action option types in move plugin. Use new action option types in plane plugin. Use new action option types in resize plugin. Use new action option types in rotate plugin. Use new action option types in scale plugin. Use new action option types in screenshot plugin. Use new action option types in switcher plugin. Use new action option types in water plugin. Use new action option types in wobbly plugin. Use new action option types in zoom plugin. Remove complex action option handling from gconf plugin as Remove duplicate initialization of option. Action options should no longer be in the schemas Print bell action type properly. Fix edge string parsing. Remove complex action option initialization. Update edge option metadata. Update parsing of edge metadata. Trigger edge button events properly. Avoid using binding type when determining if action Remove complex action option handling from ini plugin. Remove complex action option handling from dbus plugin. Remove complex action option handling from fuse plugin. Remove unused edgeButton variable from action struct. Free list option values properly. Cleanup. Make sure initiate, terminate and state variables in action Use compFiniOptionValue in fuse plugin. Cleanup. Button actions should be initialized with CompActionStateInitEdge Add button action options for all switcher actions. Check action type properly when comparing action values. Better default colors. Clean up. Add kconfig plugin and style-sheets that generate a default Remove use of kcfg Enum type. Add screen
[compiz] configuration updates
I just pushed out a large set of configuration updates that I've been working on for the last couple of days. A major difference from before is that the action options have now been slit up into key, button, edge and bell options. Action options still exist but they can only be triggered through dbus or a similar mechanism. It's very convenient to have every option type easily represented as a string and that's now the case. If multiple primitive options are supposed to be represented as one large option, the metadata should be used to achieve that. One benefit is that it simplifies the configuration system a lot and once this was done I was able to quickly implement a proper kconfig backend plugin (I'll follow up with another mail regarding this shortly). I've also re-written large parts of the gconf plugin and it's now in a much better state than before. Any plugin that uses action options will need to be updated but the changes that need to be made are simple. Each action option needs to be split up into a key, button, edge and bell option. However, you should only add the ones that makes sense. E.g. if the option is only supposed to be triggered using a key-binding, don't add the other options. I've already updated the core and all plugins in the fdo repository. Look at these changes to see how to best update other plugins. By adding the _key suffix to key actions, _button suffix to button actions etc you'll avoid breaking configuration tools as the gconf plugin was exposing the old action options like this before anyhow. I haven't added key, button, edge and bell options for all old action option. Mostly just the key option but it's trivial to add the other ones so just let me know if you for example want a button or edge option for an action that is only exposed as a key option and I'll add it quickly. Configuration backends need to be updated as well but the changes there are also simple, mostly about removing old complex action option handling code. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] kconfig plugin
I've added a kconfig plugin and all kde based configuration tools should rely on it. A file watch plugin like the inotify plugin will have to be loaded for configuration changes to be picked up by the kconfig plugin at run-time. kcfg files are generated from the metadata and they can be used to generate C++ source code that will provide an API for applications to access all compiz configuration data. As an example of how easy it now is to create a kde config tool for compiz, I've attached a tarball with a simple xslt style-sheet, a makefile and 20 lines of C++ code that will create a configuration dialog that can be used to configure all compiz options in the core and the plugins specified in the makefile. The xslt style-sheet that is used to generate UI descriptions can be improved a lot by someone who's interested. As far as configure-it-all kind of tools goes, I think this auto-generated zero maintain cost example is the best solution. Much more interesting would be if someone would write a real kcontrol module that integrate properly with the kde desktop. E.g. doesn't present options that are already available in some other kcontrol module, only expose options that a majority of users are actually interested in and have the same look and feel as the rest of the kcontrol modules. -David example.tar.bz2 Description: application/bzip-compressed-tar ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Metadata additions
On Thu, 2007-07-12 at 03:54 +0200, Dennis Kasprzyk wrote: With this mail I would like to make a proposal to add additional informations to the core and plugin metadata files. Currently these tags are already handled in the ccs configuration system. Ccs automatically adds this informations to the core/plugin option set, but I think that it would make more sense to add this to the official files, to allow similar features in other configuration systems. 1.) Group and subgroups: plugin display option .../ option .../ group shortThis is a functional group/short option .../ option .../ subgroup shortThis options belong together/short option .../ ... /subgroup /group ... There are often a lot of different opinions how options should be grouped, but this could be discussed after we have decided to add group/subgroup tags. Currently the core has two lists (opacity_matches and opacity_values) that should be handled together, because the opacity of the opacity_values list will be assigned to the corresponding match in the match list. In ccs we automatically combine such values if all options inside a subgroup have the list type, but we could also add a combine=”true” attribute to the subgroup tag, to make this functionality configurable. Sure, this seems OK. It makes a lot of sense to slit up the action options we have today into multiple less complex options and just group them together using metadata. It will simplify the configuration system a lot. 2.) Option hints: A string option (there may be others too) can be used for different things like commands,files, and images. To allow a configuration to handle such options in a spacial way (open a file open dialog), I would like to add a hints tag to such options. The hints tag would contain a semicolon separated list of strings that inform the configuration system to handle this options in a special way. These are the possible hints: command; = open a file dialog to select an executable file image; = open a file dialog that already filters all image files that are currently supported by currently loaded image plugins and shows previews of the images file; = open a file dialog that allows you to select any file file:txt,doc; = open a file dialog that allows you to select *.txt and *.doc files Sounds good. 3.) Plugin categories: Currently we have a lot of plugins and we will have more in the future. I think that it makes sense to group plugins to functional categories like “Effects”, “Window management” and “Image loaders”. A category tag could be added the plugin section to achieve this functionality. There are currently 3 different ways how the contents of this tag could be handled: - We define short category definitions like fx,wm and image and the configuration system will need to have the “long” names and their translations. - We add directly the English long category names like “Effects”, “Window management” and “Image loaders”, and the configuration system will need to have translations for them. This has the disadvantage that the configuration system would need to have a list of all long names to be able to automatically generate a .pot file for translations. - We add long category names to the metadata and translate them with the current translation system like we do for option descriptions. This has the disadvantage that plugins from different sources could also have different or none translations for the same category and the configuration systems would need a way to find the best solution. I definitely prefer that we add long category names to the metadata. We can make it possible for external plugins to use the po files from the core repository when translating metadata. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] Unbound modifiers and CompNoMask
On Sun, 2007-08-05 at 05:21 -0400, Andy Hefner wrote: This patch fixes an undesirable behavior in the comparison of modifier bits necessary to initiate an action - if the modifier is not configured on the user's X server (thus having CompNoMask in its position in d-modMask), the comparison always behaves as though the modifier were pressed, due to CompNoMask falling outside the REAL_MOD_MASK ~d-ignoredModMask bitmask. This causes actions to be invoked inappropriately (for instance, if the user has no keysyms assigned for the Super modifier, the zoom plugin can be triggered on unmodified scroll wheel events, interfering with normal scrolling). Good catch. I added CompNoMask to the REAL_MOD_MASK define, which should take care of the problem. Thanks, -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Focus problem for shaded windows
On Mon, 2007-08-06 at 10:15 +0200, Danny Baumann wrote: today, I noticed a problem in focus handling for shaded windows which is pretty easy to reproduce: - Disable Click to focus - Shade a window - Hover another window - Hover back to the window frame of the shaded window - Press Ctrl+Alt+S Expected behaviour would be that the shaded window is unshaded. What happens is that the last active window is shaded. I investigated this a bit and found the cause for this behaviour, but wasn't able to work out a proper fix for that: - The function shade() uses d-activeWindow to determine the window to (un)shade via the window option. - d-activeWindow is set from the FocusIn event handler, but only if w-managed is set for the window which is hovered or whose frame is hovered - As w-managed is unset in the UnmapNotify handler (and so after a window is shaded), hovering a shaded window frame does not set d-activeWindow to that window. Any idea regarding that one? w-managed should not be unset when getting an UnmapNotify event cause by shading. The window is still managed by compiz while being shaded. w-pendingUnmaps should be greater than 1 when a window is shaded but I guess that's broken somehow... You are right. This also works as intended. I walked a false path there, sorry. The real problem is that we don't select for FocusChange events for frame windows and thus never get FocusIn events for them. Correcting this revealed another problem: The lastFoundWindow variable was (IMO incorrectly) sometimes also set to frame windows. The attached patch seems to do the trick - any comments? I applied the FocusChange change just before I realized that it shouldn't be needed as we'll select for focus change events when the window gets added using the addWindow function and this change shouldn't make a difference. lastFoundWindow is just an optimization to avoid walking the list of windows when a window is looked up multiple times. The way lastFoundWindow is updated right now is more correct than what your patch will do. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] KDE Window decorator offset on maximized windows.
On Fri, 2007-08-03 at 16:43 +0100, Colin Guthrie wrote: Diogo Ferreira wrote: On Thu, 2007-08-02 at 10:34 +0100, Colin Guthrie wrote: Hi, Any reason why this would happen that you can think of? http://qa.mandriva.com/show_bug.cgi?id=32215 I have no idea why it happens but I think it depends on the theme, kde-window-decorator must be bugged somewhere, sometimes decorations won't even appear like in this screenshot: http://public.underdev.org/upload/files/no_decoration.png I've mentioned this before in the kwd-crash thread, hope this time it gets some more attention from the people who understand kwd. It seems that polyester doesn't have this problem but plastik does. Perhaps that will help to debug? no, I used plastik when testing. :( -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Focus problem for shaded windows
On Tue, 2007-08-07 at 20:44 +0200, Danny Baumann wrote: Hi, today, I noticed a problem in focus handling for shaded windows which is pretty easy to reproduce: - Disable Click to focus - Shade a window - Hover another window - Hover back to the window frame of the shaded window - Press Ctrl+Alt+S Expected behaviour would be that the shaded window is unshaded. What happens is that the last active window is shaded. I investigated this a bit and found the cause for this behaviour, but wasn't able to work out a proper fix for that: - The function shade() uses d-activeWindow to determine the window to (un)shade via the window option. - d-activeWindow is set from the FocusIn event handler, but only if w-managed is set for the window which is hovered or whose frame is hovered - As w-managed is unset in the UnmapNotify handler (and so after a window is shaded), hovering a shaded window frame does not set d-activeWindow to that window. Any idea regarding that one? w-managed should not be unset when getting an UnmapNotify event cause by shading. The window is still managed by compiz while being shaded. w-pendingUnmaps should be greater than 1 when a window is shaded but I guess that's broken somehow... You are right. This also works as intended. I walked a false path there, sorry. The real problem is that we don't select for FocusChange events for frame windows and thus never get FocusIn events for them. Correcting this revealed another problem: The lastFoundWindow variable was (IMO incorrectly) sometimes also set to frame windows. The attached patch seems to do the trick - any comments? I applied the FocusChange change just before I realized that it shouldn't be needed as we'll select for focus change events when the window gets added using the addWindow function and this change shouldn't make a difference. It does make a difference. We're currently selecting for FocusChange events of the _window_, not the _frame_. The problem is that although we correctly set the input focus to the frame window if the window is shaded (window.c:2870), we never get a FocusIn event in response and thus never will set the shaded window active (where findTopLevelWindowAtDisplay will retrieve the main window for the focussed frame). That's why we IMO need to select for FocusChange events also for the frame window. We do select for FocusChange events on the frame window at window.c:1974. The frame window will be added to the window list just as all other windows and we'll then select for FocusChange events, which is why we don't have to do this when creating the window. lastFoundWindow is just an optimization to avoid walking the list of windows when a window is looked up multiple times. The way lastFoundWindow is updated right now is more correct than what your patch will do. I disagree. lastFoundWindow is used for both findWindowAtDisplay/Screen and findTopLevelWindowAtDisplay/Screen. This has the side effect that the behaviour of findTopLevelWindow depends on which window was processed by findWindow before: - Assumption: findWindowAtScreen is called for a frame window (which is a valid scenario) sure. - findWindowAtScreen returns the frame window CompWindow struct and sets lastFoundWindow to that yes. - if findTopLevelWindowAtScreen is called after that for the window the frame window belongs to, the frame window is returned No, how can that happen? lastFoundWindow-id will not match the id passed to findTopLevelWindowAtScreen so it will walk the window list until it finds the appropriate window with a matching id and return it. - if lastFoundWindow would have been unset, the window itself would have been returned by findTopLevelWindowAtScreen. lastFoundWindow being unset doesn't change anything. lastFoundWindow is only a cache of the last found window. That's all. lastFoundWindow is only used when lastFoundWindow-id match the id we're searching for. That's a behaviour change which shouldn't be caused by an optimization. Maybe a better fix for that would be to track the last found top level window and last found window separately (that's what the attached patch does). We could keep a separate cache for top-level windows but they are not searched for as often so I don't think it will make much of a difference. I think I just found the bug that is causing the problem. findWindowAtScreen and findTopLevelWindowAtScreen are fine. However, findTopLevelWindowAtDisplay is broken. It shouldn't check lastFoundWindow. I pushed out changes that will fix this problem and clean up findTopLevelWindowAtScreen so it will be a bit easier to understand how lastFoundWindow is used. Let me know if this fixed your problem. -David ___ compiz mailing list compiz@lists.freedesktop.org
Re: [compiz] [ANNOUNCE] compiz-0.5.2
On Tue, 2007-08-07 at 20:57 +0200, Dennis Kasprzyk wrote: Am Dienstag 07 August 2007 20:44:12 schrieb David Reveman: On Tue, 2007-08-07 at 19:35 +0200, dragoran wrote: On 8/3/07, David Reveman [EMAIL PROTECTED] wrote: A new compiz release 0.5.2 is now available any chance for a 0.6.0 release before 2007/08/28 ? (fedora 8 feature freeze) I wont have time but we could create a 0.6 branch for this if a some people are interested in working on it. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz Create a 0.6 branch out of the 0.5.2 (without xcb) version please. Yes, I don't think we want the xcb dependency if we're doing a 0.6 branch today. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] [ANNOUNCE] compiz-0.5.2
A new compiz release 0.5.2 is now available from: http://xorg.freedesktop.org/archive/individual/app/compiz-0.5.2.tar.gz which can be verified with: http://xorg.freedesktop.org/archive/individual/app/compiz-0.5.2.tar.gz.sha1 0d0a4a39bfbe0ada770d9206b7a1b6b443c53c29 compiz-0.5.2.tar.gz http://xorg.freedesktop.org/archive/individual/app/compiz-0.5.2.tar.gz.sha1.asc (signed by David Reveman) Additionally, a git clone of the source tree: git clone git://git.freedesktop.org/git/xorg/app/compiz will include a signed compiz-0.5.2 tag which points to a commit named: 65ccbbd18c5028c610042dd552eec0de3a41bde8 which can be verified with: git verify-tag compiz-0.5.2 and can be checked out with a command such as: git checkout -b build compiz-0.5.2 WHAT'S NEW == Better support for multiple X-screens. XML-based meta-data system for handling of various kinds for meta-data like plugin descriptions, default option values, etc. Major improvements to option initialization based on the new meta-data system. Logging framework. Support for configurable button layout in metacity themes has been added to gtk-window-decorator. Glib plugin that allows plugins that use the glib main loop to integrate properly with the compiz main loop without waking up periodically to check for pending events. Plugin plugins that make it possible to adjust and extend the behavior of existing plugins through new plugins. More dynamic handling of output devices, which allows the output device configuration used when rendering to be changed between frames. Transparency support in cube plugin. Introspection support in dbus plugin. -David Changes since compiz-0.5.0: Bellegarde Cedric: Fix placement mode option. Cedric: Fix typo in matching code. Daniel Nylander: Update swedish translation. Danny Baumann: Check for active screen grabs before unsnapping a maximized window. Reflect minimum size hint when adding size changes. Add 'group-drag' as an allowed screen grab for edge flipping. Merge branch 'master' of git+ssh://[EMAIL PROTECTED]/git/xorg/app/compiz Avoid explicit comparison with FALSE constant Fix rectangle-in-range calculation for outputDeviceForGeometry. Another attempt at correctly fixing the calculations in outputDeviceForGeometry. Make gwd build without Metacity support. Added possibility to call updateWindowAttributes without requesting any stack changes. Raise windows whenever their fullscreen, above/below or maximization state changed. Merge branch 'master' of git+ssh://[EMAIL PROTECTED]/git/xorg/app/compiz Fix mem leaks Fix dangling comma in list writing. Some beautification. Fix stack corruption caused by an insufficient size of an allocated buffer. Fixed string length calculations. Bump ABIVERSION due to warpPointer() changes. Update decoration on map request before core handles the request. Added PlaceWindowProc function. Merge branch 'master' of git+ssh://[EMAIL PROTECTED]/git/xorg/app/compiz Added an Y viewport parameter to the function moveWindowToViewportPosition. Remove unneeded code. Update zoom plugin to use new metadata system. Update wobbly plugin to use new metadata system. Update water plugin to use new metadata system. Update video plugin to use new metadata system. Fix typo. Make all option info structures const. Update switcher plguin to use new metadata system. Update svg plugin to use new metadata system. Update screenshot plugin to use new metadata system. Update scale plugin to use new metadata system. Merge branch 'master' of git+ssh://[EMAIL PROTECTED]/git/xorg/app/compiz Fix some minor metadata errors. Merge branch 'master' of git+ssh://[EMAIL PROTECTED]/git/xorg/app/compiz First attempt to focus the window under the pointer if 'click to focus' is not enabled. Fix typo. Merge branch 'master' of git+ssh://[EMAIL PROTECTED]/git/xorg/app/compiz Make constrainNewWindowSize return TRUE whenever constraining was applied. Don't issue ungrab notify before server side processing is finished. Fix typo. Track the first grabbed window, not the last one. Merge branch 'master' of git+ssh://[EMAIL PROTECTED]/git/xorg/app/compiz Don't make fill colors entirely transparent by default. Notify other clients of window resizing. The fullscreen output is not a real screen output, reflect that in its id. Convert usage of restricted string options to int descriptions in scale plugin. Convert usage of restricted string options to int descriptions in wobbly plugin. Fix option type for int description options. Rename scale's displayPrivateIndex to scaleDisplayPrivateIndex so that wrapping plugins
Re: [compiz] Couldn't activate plugin 'rotate'
On Thu, 2007-08-02 at 17:04 +0200, Dennis Kasprzyk wrote: Am Dienstag, 31. Juli 2007 19:45:19 schrieb David Reveman: On Tue, 2007-07-31 at 00:19 +0200, Dennis Kasprzyk wrote: Am Montag, 30. Juli 2007 16:28:27 schrieben Sie: On Sun, 2007-07-29 at 20:31 +0200, Dennis Kasprzyk wrote: Am Samstag, 28. Juli 2007 00:24:10 schrieben Sie: On Mon, 2007-07-16 at 23:44 +0200, Dennis Kasprzyk wrote: Am Montag 16 Juli 2007 20:49:32 schrieb Kresimir Kukulj: First, I would like to compliment you all for a great work you put in developing compiz. I have it running for more that a month and it did not crash. Stability is very good. Great work! Today I updated compiz from git tree and found that rotate generates this error: compiz (core) - Error: Couldn't activate plugin 'rotate' The problem is that the load after cube got removed from the rotate metadata. I reverted it now. The ccs configuration system doesn't handle require rules automatically as load after rules. There is also a case where we have a require and a load before rule for the same plugin (3d). I don't think it should be allowed to ask for some plugin to be required but loaded after. Plugins that do this should be fixed so they don't have to ask for such a relationship and the load after cube information in the rotate metadata should be removed again. -David We removed the whole plugin order system from core to make it more flexible. That's the reason why we shouldn't mix now requirements with relations and limit the functionality. But if you want I can remove the load after cube information in the rotate metadata and add this to the internal configuration system metadata file. We're not limiting functionality by having requirements also implicitly mean that the plugin must be loaded after. We're just making the existing tags make more sense. If you like some metadata information that indicate that a plugin must be loaded after, then you can always add that through a new tag. The reason I like to have the requirement tag also implicitly mean load after is that a plugin that requires another plugin to be loaded after seems to be designed poorly and I think we should do our best not to encourage that. However, you're welcome to prove me wrong and show that requiring that another plugin is loaded after necessarily isn't bad design, in which case I'm happy to allow the requirement tag not to implicitly mean load after. -David The problem is here that we have a plugin (3d) that has to be loaded before cube but also requires cube. It needs to be loaded before cube because it's paintTransformedOutput needs to be called for each cube face, but it also needs some variables from cube to work correctly. To get into cube it uses then init/finiPluginForDisplay. So we have a plugin that requires another plugin but needs to be loaded before that plugin. That is the reason why I don't like requirement tag also implicitly mean load after. cube plugin should provide hooks that allow 3d to be loaded after cube and hook in where appropriate and not use paintTransformedOutput. -David Maybe we could try to make the plugin plugins system independent of the plugin loading order. My idea is to provide two additional wrapable functions pluginLoaded( CompPlugin *p, CompDisplay *d) and preparePluginUnload( CompPlugin *p, CompDisplay *d). pluginLoaded would be called if a plugin has been fully initialized (display/screens/windows) and preparePluginUnload before compiz calls the fini(window|screen|display) functions of a plugin. With such a system a plugin plugin could be loaded before it's main plugin gets loaded and the initialization of the plugin connections would be done in the pluginLoaded/preparePluginUnload functions. This would also increase the flexibility for plugins that offer some functionality but if another plugin gets loaded it hooks into it and provides more features. It seems over-engineered to me. The simple stack based plugin system that we have today seems sufficient. I did some experimenting with a non-stack based plugins system when I first started writing compiz and that stacked based solution proved much easier to maintain, especially as long as we allow wrapping of function pointers. Wrapping of function pointers and a non-stack based plugins system doesn't go well. Maybe we should also provide a convenience function to hook into other plugins. I'm thinking about something like Bool getPluginPrivateIndex( CompDisplay *, char * name, int abi_version, int * privateIndex); Yes, this should definitely be done. I'd also like to move the core ABI version into an option and have the plugins check this in much the same way
Re: [compiz] [R300] high Xorg process CPU usage
On Mon, 2007-07-30 at 10:54 +0200, Michel Dänzer wrote: On Fri, 2007-07-27 at 23:45 -0400, Andrew J. Barr wrote: I am trying out the Compiz Fusion stuff on my PowerBook G4 (RV350) and I have the aiglx-zero-copy-tfp patches from here[0] on Mesa 6.5.2, xorg-server 1.3, and xf86-video-ati 6.6.191. I notice that the Xorg process has a high level of CPU utilization (higher than with metacity or vanilla compiz), but the graphics aren't insanely choppy like they are without aiglx-zero-copy-tfp. Is this normal? git-bisecting compiz pointed me to this being related to the translucent cube feature, and I discovered that the /apps/compiz/plugins/cube/screen0/options/inactive_opacity gconf key was set to 90. Changing it to 100 restores sanity for me. Not sure how it came to be less than 100 in the first place, but if it can happen by default that should probably be fixed. I haven't been able to reproduce this and I can't see anything suspicious by looking at the code. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Dual-screen compiz mostly working
On Wed, 2007-08-01 at 12:03 +0200, Michel Dänzer wrote: On Wed, 2007-08-01 at 07:50 +, Mick Semb Wever wrote: - my second screen doesn't render properly. Compiz events cause it to redraw but application events do not cause a redraw! This is a showstopper for me so i'm still using metacity when in dual- screen setup. That sounds weird, can you create screenshots or something to illustrate the problem? - my screens must be vertically positioned. Compiz doesn't render the full width when the screens are side by side. Even when vertically position i cannot have the second screen at 1600x1400 for the same reason. Is this a limitation of compiz? Are there plans to fix/improve it? This is most likely due to the coordinate limits of the hardware 3D engine. That could be worked around in the Mesa driver, but there would still be the texture size limit others pointed out, and that can't be worked around in the drivers with the current GLX_EXT_texture_from_pixmap API so it would have to worked around by different means by compiz. - my fonts are not nearly as clean and crisp under compiz as they are under metacity. It's like the fonts are thick and fuzzy under compiz. I've seen this before, I think it happened when /apps/compiz/general/allscreens/options/texture_filter is set to 2 (maybe also 1) and /apps/compiz/plugins/cube/screen0/options/inactive_opacity was set to less than 100 (which I think is a bad idea in general). compiz will always use NEAREST filter when windows aren't transformed and the texture_filter option will only change the filter that is used for transformed windows. Anyhow, if the BILINEAR filter happens to be used when a window isn't transformed, a decent OpenGL implementation should provide BILINEAR texture filtering that is accurate enough to not produce a visible difference between NEAREST and BILINEAR filters in the non-transformed case. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Couldn't activate plugin 'rotate'
On Sun, 2007-07-29 at 20:31 +0200, Dennis Kasprzyk wrote: Am Samstag, 28. Juli 2007 00:24:10 schrieben Sie: On Mon, 2007-07-16 at 23:44 +0200, Dennis Kasprzyk wrote: Am Montag 16 Juli 2007 20:49:32 schrieb Kresimir Kukulj: First, I would like to compliment you all for a great work you put in developing compiz. I have it running for more that a month and it did not crash. Stability is very good. Great work! Today I updated compiz from git tree and found that rotate generates this error: compiz (core) - Error: Couldn't activate plugin 'rotate' The problem is that the load after cube got removed from the rotate metadata. I reverted it now. The ccs configuration system doesn't handle require rules automatically as load after rules. There is also a case where we have a require and a load before rule for the same plugin (3d). I don't think it should be allowed to ask for some plugin to be required but loaded after. Plugins that do this should be fixed so they don't have to ask for such a relationship and the load after cube information in the rotate metadata should be removed again. -David We removed the whole plugin order system from core to make it more flexible. That's the reason why we shouldn't mix now requirements with relations and limit the functionality. But if you want I can remove the load after cube information in the rotate metadata and add this to the internal configuration system metadata file. We're not limiting functionality by having requirements also implicitly mean that the plugin must be loaded after. We're just making the existing tags make more sense. If you like some metadata information that indicate that a plugin must be loaded after, then you can always add that through a new tag. The reason I like to have the requirement tag also implicitly mean load after is that a plugin that requires another plugin to be loaded after seems to be designed poorly and I think we should do our best not to encourage that. However, you're welcome to prove me wrong and show that requiring that another plugin is loaded after necessarily isn't bad design, in which case I'm happy to allow the requirement tag not to implicitly mean load after. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Read commandline defaults from a file?
On Sat, 2007-07-28 at 10:46 +0200, dragoran wrote: David Reveman wrote: On Thu, 2007-07-12 at 10:42 +0200, dragoran wrote: Right now compiz has hardcoded defaults for command line options like direct vs indirect rendering etc. Because most users use scripts like gnome-wm to start compiz its not that easy for them to change this options. My solution would be to have a file (~/.compizrc) where the default values are saved. So that compiz checks for the file first and pic up this values. If no file is found it fails back to the hardcoded one. Would this cause any problems? If not I can implement it and send patches. We should just make all these command line options real options with metadata attached to them. That way you can easily patch the metadata files to change the default values for them or override them by putting you're own metadata files in ~/.compiz. but can settings like direct/indirect rendering be set this way? Sure, we probably don't want to go through the trouble of making such an option adjustable after initialization but that's not a problem, it can be read-only. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] Resize plugin not finishing resizing
On Sat, 2007-06-23 at 19:53 +0200, Bellegarde Cedric wrote: In current git, when starting a resize and finish it without any change, resizeTerminate() need to do a resizeDamageRectangle(). This patch fix the issue... ok, should be fixed in head now. thanks, -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] Always use mipmaps in cube plugin
On Wed, 2007-06-27 at 01:35 +0200, Bartosz Taudul wrote: Currently, the cube plugin uses mipmapping only when cube is unfolded. When the cube is rotated, mipmaps are not used, which leads to ugly look of textures. Yeah, using mipmap filtering in those cases should be optional. I've avoided it so far because it adds a significant overhead compared to bilinear filtering as the mipmap levels needs to be updated every time a texture changes. The attached patch fixes this. This leads to another kind of artifacts, which are fixable with anisotropic filtering. http://team.pld-linux.org/~wolf/aniso.png The leftmost image is the current state of cube plugin. The center image is with mipmaps enabled. The rightmost is with mipmaps and anisotropic filtering. Sure, anisotropic filtering should be added as well if we allow mipmaps to be used in cases where it makes a difference. So far mipmap filtering have only been used in cases where it doesn't make any difference. It might make sense to add this as a global filter method instead. E.g. used automatically when core texture_filter is set Best. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] Correct linking for png-plugin
On Sun, 2007-07-08 at 22:14 +0200, Hanno Böck wrote: If compiled with LDFLAGS=-Wl,--as-needed, compiz fails to correctly link the png-plugin. Attached patch fixes it (though I don't know if this is the correct way to do this in autotools). I made some changes that should have taken care of this. Let me know if it's still a problem. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] video plugin update
On Fri, 2007-07-13 at 10:32 +1000, Christopher Halse Rogers wrote: On 7/12/07, David Reveman [EMAIL PROTECTED] wrote: I had to update the video plugin interface slightly to fix some bugs. I've attached an updated mplayer patch. Just to check, since I'm interested in applying this to Ubuntu's mplayer, but this patch is still not ready for upstream mplayer, right? I remember the last such thread ending in we should probably wait for the retained-mode interface - do the same comments apply here? In a related question, any news on such an interface? :) The communication mechanism will be slightly updated but the mplayer patch will look much like it does today unless someone wants to put more work into it. Upstream mplayer might want to put this in a compiz-xv output backend rather than in the xv backend itself but that's just some cut-n-paste work that anyone could do... -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] Case insensitive matching for the regex plugin
On Wed, 2007-06-20 at 14:53 +0200, Danny Baumann wrote: Hi, I have created an addition to the regex plugin that allows case insensitive matching for title/class/name/role. To enable the case insentive matching, I chose to prepend an 'i' before the tag (ititle=, iclass=, ...). The patch is obviously attached ;-) Are there any objections against putting this code in? No, but instead of adding a second set of tags maybe we should allow the expressions to end with /i for case insensitive matching like perl. I'm ok with either solution and not really sure which one I actually prefer. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] KWD Maximize bug and crash
On Sun, 2007-06-24 at 18:58 +0100, Diogo Ferreira wrote: Hi, KWD is crashing regularly here when closing a window (especially mplayer), I've attached the debugging information. Also, there's this bug when windows are maximized, in some themes the decoration is drawn incorrectly, sometimes it's not drawn at all, I'm not sure if it's a known bug. I've seen this bug before and the debugging information is unfortunately not that useful in this case. If you could reproduce this when running kwd in valgrind, that might be more useful. Use something like: valgrind --tool=memcheck kde-window-decorator in case you haven't used valgrind before.. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Focus problem for shaded windows
On Mon, 2007-06-25 at 15:35 +0200, Danny Baumann wrote: Hi, today, I noticed a problem in focus handling for shaded windows which is pretty easy to reproduce: - Disable Click to focus - Shade a window - Hover another window - Hover back to the window frame of the shaded window - Press Ctrl+Alt+S Expected behaviour would be that the shaded window is unshaded. What happens is that the last active window is shaded. I investigated this a bit and found the cause for this behaviour, but wasn't able to work out a proper fix for that: - The function shade() uses d-activeWindow to determine the window to (un)shade via the window option. - d-activeWindow is set from the FocusIn event handler, but only if w-managed is set for the window which is hovered or whose frame is hovered - As w-managed is unset in the UnmapNotify handler (and so after a window is shaded), hovering a shaded window frame does not set d-activeWindow to that window. Any idea regarding that one? w-managed should not be unset when getting an UnmapNotify event cause by shading. The window is still managed by compiz while being shaded. w-pendingUnmaps should be greater than 1 when a window is shaded but I guess that's broken somehow... -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Features for image loader plugins
On Thu, 2007-07-12 at 01:41 +0200, Patrick Niklaus wrote: Hi, I just had a look at the old beryl plugin tree and found out that it originally was imagemime:image/png (for using mime types as identification) and imageext:png (of file extension identification). While porting the features to metadata imagemime has become imageext (probably just a little cp mistake). So actually it makes sense to have a mime-type and extension identification. I attached an updated patch which should fix the typo. applied. thanks, -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] window walking interface
On Tue, 2007-06-12 at 19:27 +0200, Dennis Kasprzyk wrote: Am Dienstag 12 Juni 2007 14:52:53 schrieb Danny Baumann: Hi, Thanks for putting these changes in git, it indeed makes more sense than the way I did it first. I re-made the transparent cube patches to work now with this new interface. Tell me what you think about it. I re-did Roi's patches for latest cube plugin changes and coding style. Attached are the following: 0001-cube-painting-order.txt: This is good to go in if you're able to help fix any regressions that may appear. There's some coding style changes that need to be made before I can let this go in, though. Please replace all C++ comments with C comments, keep declarations at the beginning of each scope and make sure lines are no longer than 80 columns. This one is replaced by 0001-Improve-cube-paint-order-calculations.patch. 0002-plugin-events.txt: This is not OK. Plugin events should not be used at all now that 3d and rotate plugins can hook into the cube plugin directly. Just add whatever hooks that are appropriate to the cube plugin. Replaced by 0002-Added-rotation-state.patch. With that patch, there is a rotation state variable in CubeScreen that is written by the plugin rotating it, rotate in the current case. 0003-transparent-cube.txt: Looks OK. The same coding style changes need to be made here too, though. Replaced by 0003-Add-cube-transparency.patch (which adds the cube transparency) and 0004-Added-option-to-enable-cube-transparency-only-on-but.patch (option to enable transparency only on 'manual' rotation). Are these patches ok to go in? Regards, Danny Hi, here are some additional transcube patches. 0005: Fixes the FrontToBack calculation for inside cube mode. 0006: Makes the checkFTB function wrapable to allow other plugins like cubereflex to change the result of this function. Yep, this is what I had mind for proper integration of the 3d plugin functionality. 0007: Separates paintTopBottom into individual functions and fixes normals and painting order of the top and bottom caps. 0008: Adds a wrapable paintInside function to allow other plugins to render something inside of the transparent cube. All good. Please commit. Thanks. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] window walking interface
On Tue, 2007-06-12 at 21:16 +0200, Dennis Kasprzyk wrote: Am Dienstag 12 Juni 2007 19:27:41 schrieb Dennis Kasprzyk: Am Dienstag 12 Juni 2007 14:52:53 schrieb Danny Baumann: Hi, Thanks for putting these changes in git, it indeed makes more sense than the way I did it first. I re-made the transparent cube patches to work now with this new interface. Tell me what you think about it. I re-did Roi's patches for latest cube plugin changes and coding style. Attached are the following: 0001-cube-painting-order.txt: This is good to go in if you're able to help fix any regressions that may appear. There's some coding style changes that need to be made before I can let this go in, though. Please replace all C++ comments with C comments, keep declarations at the beginning of each scope and make sure lines are no longer than 80 columns. This one is replaced by 0001-Improve-cube-paint-order-calculations.patch. 0002-plugin-events.txt: This is not OK. Plugin events should not be used at all now that 3d and rotate plugins can hook into the cube plugin directly. Just add whatever hooks that are appropriate to the cube plugin. Replaced by 0002-Added-rotation-state.patch. With that patch, there is a rotation state variable in CubeScreen that is written by the plugin rotating it, rotate in the current case. 0003-transparent-cube.txt: Looks OK. The same coding style changes need to be made here too, though. Replaced by 0003-Add-cube-transparency.patch (which adds the cube transparency) and 0004-Added-option-to-enable-cube-transparency-only-on-but.patch (option to enable transparency only on 'manual' rotation). Are these patches ok to go in? Regards, Danny Hi, here are some additional transcube patches. 0005: Fixes the FrontToBack calculation for inside cube mode. 0006: Makes the checkFTB function wrapable to allow other plugins like cubereflex to change the result of this function. 0007: Separates paintTopBottom into individual functions and fixes normals and painting order of the top and bottom caps. 0008: Adds a wrapable paintInside function to allow other plugins to render something inside of the transparent cube. Regards, Dennis This is an additional patch that compines the two orientation checking function into one. It also disables the orientation checking functions for the inside cube mode. In inside cube mode some points of the orientation checking function get projected outside of the visible range and this produces wrong results. Sounds good. You know the related code better than me so feel free to make adjustments as you like. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] new release?
On Thu, 2007-06-07 at 09:53 +0200, dragoran wrote: It has been a while since 0.4.0 and 0.5.0 has been released... any plans for a new release (0.6.0/0.7.0) in the near feature? I think we should try to make one or two developer releases before a stable 0.6 release. 0.5.2 within a week or so sounds good to me. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] fixes for =libwnck-2.19.3
On Thu, 2007-06-07 at 10:45 -0500, [EMAIL PROTECTED] wrote: Hi. libwnck broke API with the 2.19.3 release. This effects compiz as the WNCK_WINDOW_MODAL_DIALOG is no longer supported by it. The attached patch allows compiz to build against the library. Thanks. I made it check for libwnck 2.19.4, as we're already checking for that version. I hope that's good enough. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Problem with new cube and scale with ini
On Fri, 2007-06-08 at 11:44 +0100, Mike Dransfield wrote: I think I have a slight problem with the new hookable plugins and the ini plugin. I haven't looked into it too much, but the plugins use an option to store their abi version. This value is stored so that when the cube/scale plugins are updated it will not be changed and things will not work. I'm not sure I understand. In what way doesn't it work? The cube/scale plugins should always be able to set the abi option properly, independent of how options are stored. Do we need some sort of flag to tell ini not to save these options? I assume that it is OK for gconf because the option is not stored because it is not added to the schema. There's a read-only metadata hint that should be sufficient for this. The other option would be to get the cube plugin to set its options when they change internally, but ideally these things shouldn't be written to disk at all. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCHES] Fixes for java apps and firefox in scale, switcher and wobbly
On Thu, 2007-06-07 at 01:17 +0200, Treviño wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Reveman ha scritto: On Wed, 2007-06-06 at 19:42 +0200, Treviño wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've made these patches that basically, make the java apps and firefox items well being recognized by some compiz plugins (scale, switcher and wobbly), I don't know if those can be considered workaround, but this helps in using your desktop tools. Basically java apps are seen as: * name=sun-awt-X11-XFramePeer (default windows = Normal) * name=sun-awt-X11-XDialogPeer (secondary - child - dialogs = Dialog) * name=sun-awt-X11-XWindowPeer (Menus, tooltip, OSD co...) While firefox items as: * type=Normal override_redirect=1 These are all workarounds for apps that are not setting window hints correctly and I think most people agree that it's not a good idea to adjust our default option values for this. Feel free to add the workarounds to the compiz.org wiki, though. Yeah, I suspected they were workarounds, but I don't think that either java or firefox will release fixes soon, however you're right not including them upstream, but I think that's a good thing for distributiors waiting for official fixes, isn't it!? Yes, this information is very useful for distributors. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] Use X-Fleur cursor on move
On Wed, 2007-06-06 at 18:56 +0200, Treviño wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I'm Treviño (AKA Trevinho, AKA 3v1n0, AKA trevi55 ;P) it's my first message here, also if I'm reading the ML from the archives since long time... I maintened a beryl-svn (then git) repository, and I'm planning to do the same as soon as I can for compiz-git (BTW, some pre-release packages are at http://tinyurl.com/396up9), however for doing so I'm applying some patches to compiz; mostly of them are the ones already posted here or taken from the ubuntu gutsy source package, but I've made some of them too. The first one, that I've attached here is a patch for the move plugin to make it show the X-fleur mouse cursor while moving a windows instead of the X-plus. This is needed to use the same cursor used by the most common Desktop Environments like KDE and GNOME (I don't know in xfce and others). Simply take the patch and apply it (it's only 1 line); then you won't have anymore the bad (imho) + cursor ;) OK, we'll use the fleur cursor for now. We'll have to add a cursor option to the move plugin if someone isn't happy with this new cursor, though. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCHES] Fixes for java apps and firefox in scale, switcher and wobbly
On Wed, 2007-06-06 at 19:42 +0200, Treviño wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've made these patches that basically, make the java apps and firefox items well being recognized by some compiz plugins (scale, switcher and wobbly), I don't know if those can be considered workaround, but this helps in using your desktop tools. Basically java apps are seen as: * name=sun-awt-X11-XFramePeer (default windows = Normal) * name=sun-awt-X11-XDialogPeer (secondary - child - dialogs = Dialog) * name=sun-awt-X11-XWindowPeer (Menus, tooltip, OSD co...) While firefox items as: * type=Normal override_redirect=1 These are all workarounds for apps that are not setting window hints correctly and I think most people agree that it's not a good idea to adjust our default option values for this. Feel free to add the workarounds to the compiz.org wiki, though. I suggest that you submit java and firefox bug reports for this if you haven't already. That way it might get fixed where it's supposed to be fixed. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] status of input redirection
On Tue, 2007-06-05 at 00:17 +0300, Daniel Stone wrote:
On Mon, Jun 04, 2007 at 05:06:20PM -0400, David Reveman wrote:
On Sat, 2007-06-02 at 04:29 +0300, Daniel Stone wrote:
On Fri, Jun 01, 2007 at 03:47:17PM -0400, David Reveman wrote:
+ switch (events[i].u.u.type) {
+ case MotionNotify:
+ case ButtonPress:
+ case ButtonRelease:
+ case KeyPress:
+ case KeyRelease:
+ case EnterNotify:
+ case LeaveNotify:
Hi,
This needs to be aware of Xi events.
Yea, I forgot about that. Will the attached patch work or are those
device events not using the keyButtonPointer structure?
Unfortunately, they're not using keyButtonPointer, and you can't put it
in a case, as the event numbers are non-constant. They use
deviceKeyButtonPointer, but you also need to check deviceValuator. See
dix/getevents.c, and mi/mieq.c.
I've adjusted the patch for deviceKeyButtonPointer. Like in my previous
patch, device events are checked for in the default so that they are not
constant should already be handled fine. Not sure exactly what to do
about deviceValuator events yet.
-David
--- a/dix/events.c
+++ b/dix/events.c
@@ -4686,8 +4686,9 @@ WriteEventsToClient(ClientPtr pClient, int count, xEvent *events)
for (i = 0; i count; i++)
{
- WindowPtr pWin;
- int x, y, dx, dy;
+ deviceKeyButtonPointer *deviceEvent;
+ WindowPtr pWin;
+ int x, y, dx, dy;
switch (events[i].u.u.type) {
case MotionNotify:
@@ -4720,6 +4721,34 @@ WriteEventsToClient(ClientPtr pClient, int count, xEvent *events)
events[i].u.keyButtonPointer.eventY += dy;
}
break;
+ default:
+ if (events[i].u.u.type == DeviceMotionNotify ||
+ events[i].u.u.type == DeviceButtonPress ||
+ events[i].u.u.type == DeviceButtonRelease ||
+ events[i].u.u.type == DeviceKeyPress ||
+ events[i].u.u.type == DeviceKeyRelease)
+ {
+ deviceEvent = (deviceKeyButtonPointer *) events[i];
+
+ pWin = LookupIDByType (deviceEvent-event, RT_WINDOW);
+ if (pWin)
+ {
+ x = deviceEvent-root_x;
+ y = deviceEvent-root_y;
+
+ CompositeXYScreenToWindowRootCoordinate (pWin, x, y,
+ x, y);
+
+ dx = x - deviceEvent-root_x;
+ dy = y - deviceEvent-root_y;
+
+ deviceEvent-root_x += dx;
+ deviceEvent-root_y += dy;
+ deviceEvent-event_x += dx;
+ deviceEvent-event_y += dy;
+ }
+ }
+ break;
}
}
#endif
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] A little patch to make scale's show-desktop behaviour optional
On Sat, 2007-06-02 at 23:25 -0400, Quinn Storm wrote: This particular behaviour drives me nuts, its so easy to accidentally click on desktop during scale and then all of your windows get minimized, which is no fun. This little patch just makes this optional, leaving the default to be the normal behaviour. Applied. Thanks. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] A little patch to make scale's show-desktop behaviouroptional
On Tue, 2007-06-05 at 11:54 +0200, Andrea Volani wrote: Hi, I'm only a compiz user, but just a question: is possible to have scale plugin to undo the window expose just with a re-push the desktop corner, just like macos do. I remember this happens in the early versions of compiz Sometimes my mouse goes accidentally on the corner and i'll like to undo the scale by hitting the corner again. This should now work OK for the non DnD case. DnD needs some additional work. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] N_ macro
On Sun, 2007-06-03 at 15:37 +0100, Mike Dransfield wrote: I have just updated the place plugin to use integers rather than strings with restrictions (as per the other plugins). The only thing which is now using the N_ macro is windowTypeString which I think can be removed. I think some plugins may still be using this so I have not removed it just yet. Once this is gone it will be possible to remove the N_ macro as well, is this OK? Yep, please remove it and if all occurrences of string restrictions have been removed from the FDO repo, string restrictions should also be removed completely from the CompOptionRestriction union. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Direct and Indirect: Difference in rendering quality
On Tue, 2007-06-05 at 18:01 +0100, Matt Russell wrote: Hi Why is the quality of scaled textures/objects using --indirect-rendering much worse than direct rendering? Also, vsync does not work with indirect-rendering. Scaled texture quality problem might be caused by GLX_EXT_framebuffer_object extension not being supported when using indirect rendering. This means that mipmap filter can't be used with pixmaps bound to textures. GLX_SGI_video_sync extensions is used for vsync and that extension will only work properly with direct rendering. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] window walking interface
On Tue, 2007-06-05 at 16:01 +0300, Roi Cohen wrote: Hi, Thanks for putting these changes in git, it indeed makes more sense than the way I did it first. I re-made the transparent cube patches to work now with this new interface. Tell me what you think about it. 0001-cube-painting-order.txt: This is good to go in if you're able to help fix any regressions that may appear. There's some coding style changes that need to be made before I can let this go in, though. Please replace all C++ comments with C comments, keep declarations at the beginning of each scope and make sure lines are no longer than 80 columns. 0002-plugin-events.txt: This is not OK. Plugin events should not be used at all now that 3d and rotate plugins can hook into the cube plugin directly. Just add whatever hooks that are appropriate to the cube plugin. 0003-transparent-cube.txt: Looks OK. The same coding style changes need to be made here too, though. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] status of input redirection
On Sun, 2007-06-03 at 05:26 +0200, Dennis Kasprzyk wrote: Am Freitag, 1. Juni 2007 21:47:17 schrieb David Reveman: On Fri, 2007-06-01 at 13:28 -0400, Kristian Høgsberg wrote: On 5/31/07, David Reveman [EMAIL PROTECTED] wrote: On Tue, 2007-05-29 at 08:53 +0200, dragoran wrote: There where some patches to implement input redirection in xorg a while ago... what happend to them? are they still beeing worked on? The attached patches work well. The server patch needs some more work if we want to allow different pickers and I haven't had time to do that yet. Can we merge the server patch as is and punt on the pluggable picker idea for now? I mean, can we do this in a way that lets the interested parties add this support in a second step without breaking backwards compatibility? If that's doable, I don't think we need to block on the pluggable picker idea now. I've attached a new patch with a more appropriate change to WriteEventsToClient. I'm OK with merging the patch in it's current state. Pluggable pickers can definitely be added later without breaking backwards compatibility. There's a few things that needs to be improved but I think the current patch is good enough for common use in compositing managers. TODO: I've tried to move the event coordinate transformation into FixUpEventFromWindow, which means making copies of events in a lot of places as FixUpEventFromWindow is sometimes called multiple times with the same xEvent. However, I never got that to work correctly and I haven't had time to figure out exactly why yet. The pointer grab code might need some more work but the patch should of course not affect non-transformed input in any way. I think that transformed input of non top-level windows isn't working correctly. This should be easy to fix though, I just need to write a good test app. -David After playing with this patches I thought that maybe this interface could also be extended to some basic real input redirection. Instead of a mapping from the transformed coordinate space to the real window coordinate space, there could be an additional value, that tells the xserver to redirect and transform the input from the transformed coordinate space to another window coordinate space. With something like this we could realize something like cloned windows in different stack positions (using input only windows and the composite manager). I think about somethink like this: XCompositeSetTriangularCoordinateMesh(Display *dpy, Window source, Window destination, XTriangle *triangle, int ntriangle); I don't know enough about the xserver internals to tell if something like this is possible, but I think that this could extend the range for possible effects. It might be a good idea to add a destination window. It shouldn't be very hard to implement. The destination window can't be an ancestor, though. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] add 'sticky' mode to cube to allow sticky+not-on-bottom windows to stick to the screen when the screen is transformed
On Fri, 2007-06-01 at 08:22 +0800, Sam Spilsbury wrote: Does this mean that cube zoom will be implimented? I remember a while back it was implimented using switchers zoom functionality, probably not implimented the right way. 3D still requires PAINT_WINDOW_FRONT_TO_BACK_MASK to work properly however. Is there a chance that anyone can get this and transcube fixed up? PAINT_WINDOW_FRONT_TO_BACK_MASK is not going to be added but I definitely like to see both the window elevation and translucent cube functionality supported sometime soon. It should be a lot easier to get this working properly now that the cube plugin can export any hooks we find useful. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] status of input redirection
On Fri, 2007-06-01 at 13:28 -0400, Kristian Høgsberg wrote:
On 5/31/07, David Reveman [EMAIL PROTECTED] wrote:
On Tue, 2007-05-29 at 08:53 +0200, dragoran wrote:
There where some patches to implement input redirection in xorg a while
ago...
what happend to them? are they still beeing worked on?
The attached patches work well. The server patch needs some more work if
we want to allow different pickers and I haven't had time to do that
yet.
Can we merge the server patch as is and punt on the pluggable picker
idea for now? I mean, can we do this in a way that lets the
interested parties add this support in a second step without breaking
backwards compatibility? If that's doable, I don't think we need to
block on the pluggable picker idea now.
I've attached a new patch with a more appropriate change to
WriteEventsToClient.
I'm OK with merging the patch in it's current state. Pluggable pickers
can definitely be added later without breaking backwards compatibility.
There's a few things that needs to be improved but I think the current
patch is good enough for common use in compositing managers.
TODO:
I've tried to move the event coordinate transformation into
FixUpEventFromWindow, which means making copies of events in a lot of
places as FixUpEventFromWindow is sometimes called multiple times with
the same xEvent. However, I never got that to work correctly and I
haven't had time to figure out exactly why yet.
The pointer grab code might need some more work but the patch should of
course not affect non-transformed input in any way.
I think that transformed input of non top-level windows isn't working
correctly. This should be easy to fix though, I just need to write a
good test app.
-David
--- a/composite/compalloc.c
+++ b/composite/compalloc.c
@@ -141,6 +141,7 @@ compRedirectWindow (ClientPtr pClient, WindowPtr pWin, int update)
cw-oldy = COMP_ORIGIN_INVALID;
cw-damageRegistered = FALSE;
cw-damaged = FALSE;
+ cw-pInputMesh = NULL;
pWin-devPrivates[CompWindowPrivateIndex].ptr = cw;
}
ccw-next = cw-clients;
--- a/composite/compext.c
+++ b/composite/compext.c
@@ -512,6 +512,45 @@ ProcCompositeReleaseOverlayWindow (ClientPtr client)
return client-noClientException;
}
+static int
+ProcCompositeSetTriangularCoordinateMesh (ClientPtr client)
+{
+CompWindowPtr cw;
+WindowPtr pWin;
+int n, status;
+
+REQUEST (xCompositeSetTriangularCoordinateMeshReq);
+REQUEST_AT_LEAST_SIZE (xCompositeSetTriangularCoordinateMeshReq);
+
+pWin = (WindowPtr) LookupIDByType (stuff-window, RT_WINDOW);
+if (!pWin || !pWin-parent)
+{
+ client-errorValue = stuff-window;
+ return BadWindow;
+}
+
+cw = GetCompWindow (pWin);
+if (!cw)
+{
+ client-errorValue = stuff-window;
+ return BadWindow;
+}
+
+n = (client-req_len 2) -
+ sizeof (xCompositeSetTriangularCoordinateMeshReq);
+if (n (n % (sizeof (xTriangle) * 2)))
+ return BadLength;
+
+n /= sizeof (xTriangle);
+
+status = CompositeSetTriangularCoordinateMesh (client, pWin, n,
+ (xTriangle *) stuff[1]);
+if (status)
+ return status;
+
+return client-noClientException;
+}
+
int (*ProcCompositeVector[CompositeNumberRequests])(ClientPtr) = {
ProcCompositeQueryVersion,
ProcCompositeRedirectWindow,
@@ -522,6 +561,7 @@ int (*ProcCompositeVector[CompositeNumberRequests])(ClientPtr) = {
ProcCompositeNameWindowPixmap,
ProcCompositeGetOverlayWindow,
ProcCompositeReleaseOverlayWindow,
+ProcCompositeSetTriangularCoordinateMesh
};
static int
@@ -646,6 +686,19 @@ SProcCompositeReleaseOverlayWindow (ClientPtr client)
return (*ProcCompositeVector[stuff-compositeReqType]) (client);
}
+int
+SProcCompositeSetTriangularCoordinateMesh (ClientPtr client)
+{
+int n;
+REQUEST(xCompositeSetTriangularCoordinateMeshReq);
+
+swaps (stuff-length, n);
+REQUEST_AT_LEAST_SIZE(xCompositeSetTriangularCoordinateMeshReq);
+swapl (stuff-window, n);
+SwapRestL (stuff);
+return (*ProcCompositeVector[stuff-compositeReqType]) (client);
+}
+
int (*SProcCompositeVector[CompositeNumberRequests])(ClientPtr) = {
SProcCompositeQueryVersion,
SProcCompositeRedirectWindow,
@@ -656,6 +709,7 @@ int (*SProcCompositeVector[CompositeNumberRequests])(ClientPtr) = {
SProcCompositeNameWindowPixmap,
SProcCompositeGetOverlayWindow,
SProcCompositeReleaseOverlayWindow,
+SProcCompositeSetTriangularCoordinateMesh
};
static int
--- a/composite/compint.h
+++ b/composite/compint.h
@@ -85,6 +85,21 @@ typedef struct _CompClientWindow {
intupdate;
} CompClientWindowRec, *CompClientWindowPtr;
+typedef struct _CompTriangle {
+xTriangletri;
+xFixed_48_16 area;
+} CompTriangle;
+
+typedef struct _CompTriangleMap {
+CompTriangle parent;
+CompTriangle child;
+} CompTriangleMap;
+
+typedef struct _CompTriangularMesh {
+CompTriangleMap *map;
+int nMap
Re: [compiz] Changing gconf-key/apps/compiz/plugins/water/allscreens/options/initiate_keydoes not work
On Sat, 2007-05-19 at 11:27 +0200, dragoran wrote: Mike Cook wrote: On Fri, May 18, 2007 at 11:06 AM, dragoran [EMAIL PROTECTED] wrote: Hello, I noticed that the control+super key kombi no longer works with the rain plugin.. I went to check why and found out that its disabled in gconf. so I tryed to change it back to ControlSuper (which is the default) but it changes itself back to disabled... any idea why? Hm, I see the same problem with the Shift modifier trying to active snapping with wobbly. If it try to set it to ShiftT or something, then it seems to take the Shift and it works. I'm not sure if this is a GConf problem or something in the Compiz metadata that's not allowing just modifiers without another key. any solution? it was working before and I have not updated gconf so it looks like a compiz bug Should now be fixed. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Some suggestions for extra metadata
On Mon, 2007-05-21 at 14:01 +0100, Mike Dransfield wrote: Here are a few extra attributes which I have not seen mentioned yet which I think would be useful. Any comments would be appreciated. *Version* The version of the plugin, I think the reasons for this are obvious. version major0/major minor1/minor patch0/patch /version *Addition to features* Just add an attribute to the features tag so that features can be unique or non-unique. This will mean that we can add lots more features like 'config', 'matchhandler', 'imageloader' etc etc. They need to be defined somewhere so that plugin developers can check a list of official features like this (whilst still adding their own if needed). feature unique=truelargedesktop/feature This should default to true if not provided. *Match Handler Tag* If a plugin provides window matching functionality then it could provide tags like this. matchhandler handler matchtitle/match !-- optional command to be run to get the attribute for a window -- commandxprop | grep ^WM_NAME | .../command /handler handlername/handler etc... /matchhandler *Option Group* Some plugins and the core have options which work in groups. Hints can be provided to group these options so that configuration tools will be able to display them as a grid rather than as individual options. optiongroup option name=opacity_match / option name=opacity_values / /optiongroup *Web based information* I think it would be a very nice feature to add some web based attributes which means things can be easily updated without the user updating the plugin. There are probably others that could be added. info !-- xml file with update info -- updateurlhttp://www.example.com/plugin-update.xml/updateurl !-- html page with additional information about the plugin -- infourlhttp://www.example.com/plugin-info.html/infourl /info screenshots screenshot mime=text/htmlhttp://www.example.com/plugin.html/screenshot screenshot mime=image/jpeghttp://www.example.com/plugin.jpg/screenshot screenshot mime=application/swfhttp://www.example.com/plugin.swf/screenshot /screenshots Some good ideas here. I suggest that we add things as a use for it is implemented and not add everything we can think just in case it might be used. I recommend that any configuration or control utility that is interested in compiz metadata is implemented in such a way that in can include it's own set of additional metadata for known plugins. New tags can first be added to the additional metadata files and if they make sense and are useful for other configuration utilities we'll move them into the official metadata files. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] Fix imageBufferToTexture for MSBFirst platforms.
On Wed, 2007-05-23 at 15:37 +0200, Michel Dänzer wrote:
Fixes icon colours on my PowerBook.
Given that the preprocessor test was reversed when the code was reorganized
and
nobody on !MSBFirst platforms complained, one code path should suffice.
Hm, I'm not sure what's going on here. I fixed the mistake from the
reorganization. If byte order doesn't actually matter for the icon data
then I think the iconToTexture function should be changed to reflect
that and not imageBufferToTexture.
---
src/texture.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/src/texture.c b/src/texture.c
index 4170c70..7021643 100644
--- a/src/texture.c
+++ b/src/texture.c
@@ -164,13 +164,8 @@ imageBufferToTexture (CompScreen *screen,
unsigned int width,
unsigned int height)
{
-#if IMAGE_BYTE_ORDER == MSBFirst
-return imageToTexture (screen, texture, image, width, height,
-GL_BGRA, GL_UNSIGNED_BYTE);
-#else
return imageToTexture (screen, texture, image, width, height,
GL_BGRA, GL_UNSIGNED_INT_8_8_8_8_REV);
-#endif
}
Bool
--
1.5.2-rc3.GIT
-David
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] add 'sticky' mode to cube to allow sticky+not-on-bottom windows to stick to the screen when the screen is transformed
On Sun, 2007-05-27 at 19:41 -0400, Quinn Storm wrote: I've attached the patch since I don't yet have an easy way to make git format-patch and kmail play nice together. The basic idea is during a rotate/other cube transform, 'sticky' windows stick to the screen instead of being redrawn once per face (its an option, the default is the old behaviour) Consider this, please, essentially an RFC - this particular behaviour was available previously in Beryl, and was (at least according to screenshots/casts) widely used. Yea, this behavior makes a lot of sense for sticky windows. The problem is that during cube motion these windows suddenly becomes on top of windows that they are normally stacked below and that looks pretty bad unless it's animated. I think it will look better if the cube is moved back a bit during motion like when windows are being elevated and maybe it makes more sense to make this functionality part of the 3D plugin, which btw should hook into the cube plugin the same way rotate plugin now does. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] status of input redirection
On Tue, 2007-05-29 at 08:53 +0200, dragoran wrote:
There where some patches to implement input redirection in xorg a while
ago...
what happend to them? are they still beeing worked on?
The attached patches work well. The server patch needs some more work if
we want to allow different pickers and I haven't had time to do that
yet.
-David
--- a/composite.h
+++ b/composite.h
@@ -63,8 +63,9 @@
#define X_CompositeNameWindowPixmap 6
#define X_CompositeGetOverlayWindow 7
#define X_CompositeReleaseOverlayWindow 8
-#define X_CompositeRedirectCoordinate 9
-#define X_CompositeTransformCoordinate 10
+#define X_CompositeSetTriangularCoordinateMesh 9
+#define X_CompositeRedirectCoordinate 10
+#define X_CompositeTransformCoordinate 11
#define CompositeNumberRequests (X_CompositeTransformCoordinate + 1)
--- a/compositeproto.h
+++ b/compositeproto.h
@@ -192,6 +192,15 @@ typedef struct {
CARD8 compositeReqType;
CARD16 length;
Window window B32;
+} xCompositeSetTriangularCoordinateMeshReq;
+
+#define sz_xCompositeSetTriangularCoordinateMeshReq 8
+
+typedef struct {
+CARD8 reqType;
+CARD8 compositeReqType;
+CARD16 length;
+Window window B32;
BOOLredirect;
BYTEunused1;
CARD16 unused2 B16;
--- a/configure.ac
+++ b/configure.ac
@@ -24,7 +24,7 @@ dnl
dnl Process this file with autoconf to create configure.
AC_PREREQ([2.57])
-AC_INIT([CompositeProto], [0.3], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([CompositeProto], [0.4], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
--- a/configure.ac
+++ b/configure.ac
@@ -34,7 +34,7 @@ dnl protocol, so Xcomposite version l.n.m corresponds to protocol version l.n
dnl that 'revision' number appears in Xcomposite.h and has to be manually
dnl synchronized.
dnl
-AC_INIT(libXcomposite, 0.3.1, [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], libXcomposite)
+AC_INIT(libXcomposite, 0.4.0, [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], libXcomposite)
AM_INIT_AUTOMAKE([dist-bzip2])
AM_MAINTAINER_MODE
@@ -52,7 +52,7 @@ if test $VERSION = ; then
fi
COMPOSITEEXT_VERSION=[`echo $VERSION | sed 's/^\([0-9][0-9]*\.[0-9][0-9]*\).*$/\1/'`]
AC_SUBST(COMPOSITEEXT_VERSION)
-PKG_CHECK_MODULES(XCOMPOSITE, [compositeproto = $COMPOSITEEXT_VERSION] x11 xfixes xext fixesproto)
+PKG_CHECK_MODULES(XCOMPOSITE, [compositeproto = $COMPOSITEEXT_VERSION] x11 xfixes xext fixesproto xrender renderproto)
AC_SUBST(XCOMPOSITE_CFLAGS)
AC_SUBST(XCOMPOSITE_LIBS)
--- a/include/X11/extensions/Xcomposite.h
+++ b/include/X11/extensions/Xcomposite.h
@@ -47,6 +47,7 @@
#include X11/extensions/composite.h
#include X11/extensions/Xfixes.h
+#include X11/extensions/Xrender.h
#include X11/Xfuncproto.h
/*
@@ -92,6 +93,12 @@ XCompositeGetOverlayWindow (Display *dpy, Window window);
void
XCompositeReleaseOverlayWindow (Display *dpy, Window window);
+void
+XCompositeSetTriangularCoordinateMesh (Display *dpy,
+ Window window,
+ _Xconst XTriangle *triangle,
+ int nTriangle);
+
_XFUNCPROTOEND
#endif /* _XCOMPOSITE_H_ */
--- a/src/Xcomposite.c
+++ b/src/Xcomposite.c
@@ -391,3 +391,40 @@ XCompositeReleaseOverlayWindow (Display *dpy, Window window)
UnlockDisplay (dpy);
SyncHandle ();
}
+
+void
+XCompositeSetTriangularCoordinateMesh (Display *dpy,
+ Window window,
+ _Xconst XTriangle *triangle,
+ int nTriangle)
+{
+XCompositeExtDisplayInfo *info = XCompositeFindDisplay (dpy);
+xCompositeSetTriangularCoordinateMeshReq *req;
+int n;
+long len;
+
+XCompositeSimpleCheckExtension (dpy, info);
+LockDisplay (dpy);
+while (nTriangle)
+{
+ GetReq (CompositeSetTriangularCoordinateMesh, req);
+ req-reqType = info-codes-major_opcode;
+ req-compositeReqType = X_CompositeSetTriangularCoordinateMesh;
+ req-window = window;
+ n = nTriangle;
+ len = ((long) n) * (SIZEOF (xTriangle) 2);
+ if (!dpy-bigreq_size len (dpy-max_request_size - req-length))
+ {
+ n = (dpy-max_request_size - req-length) /
+ (SIZEOF (xTriangle) 2);
+ len = ((long) n) * (SIZEOF (xTriangle) 2);
+ }
+ SetReqLen (req, len, len);
+ len = 2;
+ DataInt32 (dpy, (int *) triangle, len);
+ nTriangle -= n;
+ triangle += n;
+}
+UnlockDisplay (dpy);
+SyncHandle ();
+}
--- a/src/xcompositeint.h
+++ b/src/xcompositeint.h
@@ -51,6 +51,7 @@
#include X11/Xlib.h
#include X11/Xlibint.h
#include X11/Xutil.h
+#include X11/extensions/renderproto.h
#include X11/extensions/compositeproto.h
#include X11/extensions/Xcomposite.h
@@ -83,4 +84,16 @@ XCompositeFindDisplay (Display *dpy);
#define XCompositeSimpleCheckExtension(dpy,i) \
if (!XCompositeHasExtension(i)) { return; }
+/*
+ * Xlib uses long for 32-bit values. Xcomposite uses int. This
+ * matters on alpha. Note that this macro assumes
Re: [compiz] who know how to debug compiz with gdb or Eclipse
On Tue, 2007-05-29 at 23:01 +0800, Zhu, Jack wrote: All, Intel SSG/OTC/UMD PRC Software EngineerglRotated You can use gdb with compiz as with any other app but you probably want to be logged in from a remote machine when running gdb and compiz as you will of course not be able to get any output on the local machine when the compiz process is stopped by gdb. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Zoom plugin changes
On Thu, 2007-05-31 at 02:19 +0200, Kristian Lyngstøl wrote: I'm sorry for being rude, but I am quite upset by this, because it has gone too far. I posted a few weeks ago that I was going to be working on zoom over the summer to improve the accessibility, and I have already begun to do that. Every step of the way I have made frequent commits to opencompositing.org and described the progress in my blog. I asked for information about what your (David) plans was, you thanked me for informing me on what I was going to work on and said you'd get back to me. You never did. Now today you commit 11fe37b7673b15e5cbd4be21759311087d9d8694 which introduce major changes to the zoom plugin. You did NOT give a heads up on this, even though you should have known I was working on this. This is simply unacceptable. When you are going to make changes and people have already told you they are working on that code, you have to actually communicate with them, not drop a 1k diff on them. It's not just your time that matters here, but ours too. This is not how people are supposed to co-operate. And also, when you write something, you have to document it. A few lines for each function, explaining what it does. You don't have to explain how or why, just WHAT. This is a common practice that I should NOT have to explain to an experience developer. Please document your changes to the zoom plugin properly so our USERS don't have to choose between two different feature sets when they want to zoom. Because this is about the users, not my pride. I never intended my zoom plugin to be the zoom plugin. It's just a zoom plugin that implements some zoom functionality. I hope that people haven't been under the impression that any zoom functionality that could be written would have to go into my zoom plugin. That's definitely not what I'd like to see. I'd like to see different zoom plugins that implement different zoom functionality. There's no reason the user should have to choose between them, they should be able to use them all at the same time if they want that. I always though that my zoom plugin was useless and more for demo purposes. I wrote a more useful zoom plugin a while ago and I though it made sense to replace the existing zoom plugin with this one, which is what I did yesterday. If someone found the old functionality useful or if you've been able to build something useful from it then I'm happy to see it available as an additional zoom plugin. The things I wanted to get back to you on related to the zoom work you do has very little to do with the implementation of zoom plugins and more to do with how other changes are important to make zoom functionality useful. E.g. changes I'd like to make to the core which will allow applications to incrementally move towards using resolution independent retained mode rendering etc. but I have unfortunately not had time to do that yet. You can ignore my recent changes to the zoom plugin in the fdo repo and keep working on your zoom plugin. I don't want my changes to cause you any unnecessary pain and I'm sorry if they got you upset. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] place plugin
On Fri, 2007-05-25 at 20:00 +0200, dragoran wrote: David Reveman wrote: That's a bug in the decoration plugin. It's not adjusting the position of windows properly when adding decorations to them. There were some issues before that made it a bit hard to fix this but I think it should be easy to fix in the current code. are you planning to fix this? or should I try to play with the code a bit to see what can be done? please go ahead and play with it. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Window specific actions and edge buttons
On Fri, 2007-05-18 at 15:14 +0100, Mike Dransfield wrote: David Reveman wrote: On Wed, 2007-05-16 at 11:51 +0100, Mike Dransfield wrote: David Reveman wrote: On Tue, 2007-05-15 at 00:29 +0100, Mike Dransfield wrote: There is a problem with some window specific actions like scale_group and rotate_with_window when they are activated by an edgebutton. The basic problem is that each of those actions use the window option provided to the action. When an edgebutton is used the window id sent is actually the id of the edge window, this means that actions which rely on this stop working. The obvious solution would be to change the affected functions to work on the active window rather that the one passed to the action. Yes, I think that's what should be done. OK - I did that for those two. I am just about to push out similar changes for close_window, minimize_window and maximize_window. If they reduce some functionality then please let me know and I will write it so that it checks for an edge and only uses activeWindow then. This is likely not what you want when a button press triggered an action and it removes the possibility to remotely trigger those actions for specific windows. OK - I didn't think of that possibility. I'll change it back to the old way. I would like to keep the ability to do both without breaking either method. How about adding edge_window to the list of options which are sent? If the action was edge+button then it would be set to the id of the edge window. The window option could be set to active window in this case. Yes, that sounds pretty good. Maybe it's better to add a more general event_window to the list instead. For scale_group and such I think you want to only use the active window if the provided window is an edge window or a maybe a window that isn't managed. I don't see any reason why close_window, etc should be changed. I think it is a useful accessibility feature, there are lots of people who find it hard to click precisely on the decorator buttons. Pushing to the corner and clicking is easier because it does not require such fine motor skills. OK, I didn't get that this was the reason you wanted to change those functions. Yes, it seems useful. Adding an event_window argument will allow those functions to work with screen edges without modifying them. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] Descriptions for dbus when plugin not loaded
On Fri, 2007-05-18 at 15:17 +0100, Mike Dransfield wrote: David Reveman wrote: On Tue, 2007-05-15 at 19:23 +0100, Mike Dransfield wrote: Here is a quick patch for dbus to make it try to load the metadata from a file if the plugin is not loaded. I have tested it and it works fine, but I wanted to check to see if you had something else in mind. Yes, I think we should load/initialize and read the metadata from plugins. Some minor changes need to be made to the plugin system before we're able to load and initialize a plugin without activating it but it should be easy to fix. I thought you might have something like that in mind, I shall wait for that to be done. I looked at the code and you should be able to implement this without any changes to the plugin loading system. The dbus plugin will have to manually call p-vTable-getVersion, p-vTable-init and p-vTable-fini when retrieving metadata from an non-active plugin but that's fine. BTW, I'm not very interested in just returning the descriptions. The GetPluginMetadata method should return an array of full meta data documents. This needs to be supported by the dbus plugin before we can remove plugin dependencies from the core. Once the above is done, I can look at modifying the getMetadata function. I think it would be appropriate to change this function to return a dictionary because its likely that it will be modified and it will save breaking scripts. You can go ahead and add this right now. If you don't know exactly how to do the plugin loading and meta data reading then just leave that to me. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] kde-window-decorator crashes
On Tue, 2007-05-15 at 18:50 +0100, Diogo Ferreira wrote: Silvan Calarco wrote: Hi, I've updated compiz to the 0.5.0 release and since my release 0.3.something I keep on seeing seldom crashes from kde-window-decorator when running it both on Xorg with AIGLX+nvidia card and Xorg+Xgl+ATI card. The crashes most often happen at desktop login and when loading certain applications (kmail, kaffeine, ...). The strange thing is that if I try to attach to kde-window-decorator with gdb it doesn't crash anymore! What might be the reason? If anybody can tell how I can make more debugging and give you more information. The distribution is openmamba. Could be related to this bug: http://bugs.freedesktop.org/show_bug.cgi?id=9526 I think someone reported that the workaround we have in libdecoration doesn't always work. I should probably go ahead and commit that fix to libXrender. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] place plugin
On Thu, 2007-05-17 at 14:06 +0200, dragoran wrote: The place plugin has a bug: when compiz is restarted or started to replace another wm it the windows are placed in weird positions ( titlebar behind the panel etc.) shouln't the place plugin loop over all open windows and place them correctly when loaded? this should solve this issues. any reason why this isn't done? have I missed something or is this just a bug? compiz should not place existing windows at startup. compiz doesn't really try to avoid weird positions. the move plugin have some code that avoids moving windows to weird positions but that's only for when moving windows. A plugin that makes sure that windows are never placed at weird positions could be written for this purpose. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] place plugin
On Mon, 2007-05-21 at 20:34 +0200, dragoran wrote: David Reveman wrote: On Thu, 2007-05-17 at 14:06 +0200, dragoran wrote: The place plugin has a bug: when compiz is restarted or started to replace another wm it the windows are placed in weird positions ( titlebar behind the panel etc.) shouln't the place plugin loop over all open windows and place them correctly when loaded? this should solve this issues. any reason why this isn't done? have I missed something or is this just a bug? compiz should not place existing windows at startup. but it seems that it does (they get moved to weird position if compiz is started while some windows are open).. it should atleast leave them at their old position. (metacity does not do this) It's a bug if they gets moved. compiz doesn't really try to avoid weird positions. the move plugin have some code that avoids moving windows to weird positions but that's only for when moving windows. A plugin that makes sure that windows are never placed at weird positions could be written for this purpose. how would this fix the problem for windows gets misplaced at startup? It doesn't. I can't reproduce the misplacement issue on my system and I don't know what's causing it. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Crash in blur.c (SIGSEGV)
On Sat, 2007-05-19 at 12:14 +0200, Artur Uszyński wrote: Hello. System info: OS: FC6 x86_64 video: Nvidia GF 7900 GT, driver version 97.55 compiz version: git config backend used: ccp I can reproduce this crash every time on my system. When blur plugin is active and I try to access any right-click menu, regular application menu or drop-down list, compiz crashes. Backtrace produced by crashhandler plugin shows crash in blur.c in function blurWindowResizeNotify, in the following line: if (bw-state[BLUR_STATE_CLIENT].threshold || The values of bw seem to be wrong and IMO indicate classic problem with null or uninitialized pointer (although I'm not a programmer): bw = (BlurWindow *) 0x0 Sometimes instead of 0x0 I get values like 0x40 or 0x33373b3338393932, which don't seem to be right either. After restarting compiz and immediately accessing exactly the same object (for example repeating right-click on desktop) crash does not happen, but then accessing other similar object crashes compiz again. After commenting out the whole if statement mentioned above compiz no longer crashes, but probably graphics glitches are introduced instead. There was a report including similar description sent on Wed Feb 21 04:34:20 PST 2007: When I start blurdemo, that works too. The problem is that sometimes changing the filter type crashes compiz. If I run it under a debugger it starts working again. All the filter types work with blurdemo. changing the filter type might be a symptom of the same problem (accessing drop-down list). This crash is likely caused by decoration and blur plugins calling wrapped functions from initWindow. I just pushed out some code that solves this by adding a new WindowAddNotify function that these plugins now hooks into. I'm pretty sure that this will fix your crash. Give the latest code a try and let me know. Thanks, -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] place plugin
On Mon, 2007-05-21 at 21:45 +0200, dragoran wrote: David Reveman wrote: don't know what's causing it. It doesn't. I can't reproduce the misplacement issue on my system and I try this: start metacity open a maximized window start compiz titlebar is behind the top panel (need to press alt to move it back to its original place, because its impossible to grab the titlebar for moving). That's a bug in the decoration plugin. It's not adjusting the position of windows properly when adding decorations to them. There were some issues before that made it a bit hard to fix this but I think it should be easy to fix in the current code. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] place plugin
On Mon, 2007-05-21 at 22:06 +0200, Guillaume Seguin wrote: 2007/5/21, David Reveman [EMAIL PROTECTED]: On Mon, 2007-05-21 at 20:35 +0200, Guillaume Seguin wrote: 2007/5/21, David Reveman [EMAIL PROTECTED]: On Thu, 2007-05-17 at 14:06 +0200, dragoran wrote: The place plugin has a bug: when compiz is restarted or started to replace another wm it the windows are placed in weird positions ( titlebar behind the panel etc.) shouln't the place plugin loop over all open windows and place them correctly when loaded? this should solve this issues. any reason why this isn't done? have I missed something or is this just a bug? compiz should not place existing windows at startup. compiz doesn't Would it be possible to change that startup behaviour? Switching from metacity to compiz is quite awful at the moment. And there are also some minimize problems (windows that are mapped but are known as minimized by X, so that you just can't do anything) Whatever bugs that exist should of course be fixed. If there's other things than bugs that is causing it to be awful, please explain more. -David The startup problems are the placement one (which was described above) and the minimized windows problem : When switching from metacity to kwin, minimized windows are mapped (I mean visible and updating) but they are still in minimized state (wnck menus show Unminimize window, but triggering that doesn't help), so that all you can do with them is close them (input is impossible, and you can't unminimize them). I'll try to get some xprop feedback and screenshots next time it happens. It's a bug in compiz. Minimized windows should always be mapped when the WM closes down. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] about matchbox + compiz solution
On Fri, 2007-05-18 at 16:42 +0800, Zhu, Jack wrote: Instead of use compiz windows manager, I want to use matchbox, but I want reuse compiz plugins, means I use matchbox + compiz as windows manager + 3D desktop effect solution, would you please give me some suggestion about my plan. What about the effort? Would you please give me some suggestion. Thanks. I assume you want to use matchbox because it's lightweight and designed to work well with small displays. The effects that exist in compiz plugins require OpenGL so there's no way you can avoid that dependency. Other than that, compiz's modular design allows it to be as lightweight as matchbox and whatever special functionality you need that matchbox provides could be added to compiz through plugins. If there's anything in compiz core, other than the OpenGL dependency, that makes matchbox more appropriate for you, I'm very interested in fixing that. My suggestion is that you use compiz as windows manager and we'll make sure it fits your needs. Its modular design should make that straightforward. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] compiz run on DISPLAY :2 error: No composite extension
On Fri, 2007-05-18 at 17:00 +0800, Zhu, Jack wrote:
I can enable compiz on default DISPLAY :0 on gnome on FC6, all
features are OK, but when I set up a DISPLAY :2 with Xnest, try to
run compiz in DISPLAY :2, fail,
Error info:
compiz: No composite extension
I check compiz source code:
if (!XQueryExtension (dpy,
COMPOSITE_NAME,
d-compositeOpcode,
d-compositeEvent,
d-compositeError))
{
fprintf (stderr, %s: No composite extension\n,
programName);
return FALSE;
}
NAME
XQueryExtension, XListExtensions, XFreeExtensionList - list
available extensions
ARGUMENTS
display Specifies the connection to the X server.
name Specifies the extension name.
DESCRIPTION
The XQueryExtension function determines if the named
extension is present. If the extension is not
present, XQueryExtension returns False; otherwise, it
returns True. If the extension is present,
XQueryExtension returns the major opcode for the extension to
major_opcode_return; otherwise, it returns
zero.
who can help me ?
Xnest simply doesn't support the composite extension that is required to
run compiz. Compiz is a compositing window manager and none of the
effects that compiz plugins provide could be implemented without this X
server extension.
You can use Xgl if you want to run an X server in a window that support
all the extensions required by compiz.
- David
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Window specific actions and edge buttons
On Wed, 2007-05-16 at 11:51 +0100, Mike Dransfield wrote: David Reveman wrote: On Tue, 2007-05-15 at 00:29 +0100, Mike Dransfield wrote: There is a problem with some window specific actions like scale_group and rotate_with_window when they are activated by an edgebutton. The basic problem is that each of those actions use the window option provided to the action. When an edgebutton is used the window id sent is actually the id of the edge window, this means that actions which rely on this stop working. The obvious solution would be to change the affected functions to work on the active window rather that the one passed to the action. Yes, I think that's what should be done. OK - I did that for those two. I am just about to push out similar changes for close_window, minimize_window and maximize_window. If they reduce some functionality then please let me know and I will write it so that it checks for an edge and only uses activeWindow then. This is likely not what you want when a button press triggered an action and it removes the possibility to remotely trigger those actions for specific windows. For scale_group and such I think you want to only use the active window if the provided window is an edge window or a maybe a window that isn't managed. I don't see any reason why close_window, etc should be changed. If close_window is used with edge+edgebutton then it crashes which is obviously a problem elsewhere. Is it fairly obvious to you where this bug would be? Otherwise I'll track that down too, I assume it must be just a case of setting the correct allowed actions hint on edges? It probably crashes because close_window will try to terminate the client that created the window and that happens to be compiz itself. close_window action should be updated to only close managed windows. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Window specific actions and edge buttons
On Tue, 2007-05-15 at 00:29 +0100, Mike Dransfield wrote: There is a problem with some window specific actions like scale_group and rotate_with_window when they are activated by an edgebutton. The basic problem is that each of those actions use the window option provided to the action. When an edgebutton is used the window id sent is actually the id of the edge window, this means that actions which rely on this stop working. The obvious solution would be to change the affected functions to work on the active window rather that the one passed to the action. Yes, I think that's what should be done. It could also be possible to modify the actions higher up to ignore edge windows, but I suppose some people might want that functionality. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Building Compiz
On Mon, 2007-05-14 at 19:12 -0700, Grant Patterson wrote: Hi Folks, I work at VMware, where I'm making the multi-monitor feature new in Workstation 6.0 (just released!) more robust. Long story short, window managers don't consistently expose a good way for a single window to go fullscreen across more than monitor, which is what we need to do to display the monitors we expose to a guest virtual machine. So we've proposed a new hint for the wm-spec that lets us do this in a clean way; anticipating its approval (or something close to it), I'm implementing the functionality in a variety of window managers, including Compiz. Anyway, I got the source via git and I'm trying to build it. I'm not having much luck. I'm running Ubuntu Dapper and have the latest version of XFixes according to apt-get, but get this error when I try make: cursor.o: In function `addCursor':/src/compiz/src/cursor.c:57: undefined reference to `XFixesHideCursor' Any idea what's going on? You'll need a newer version of xfixes and it's a bug that the configure script doesn't check for this. However, that cursor code is not yet used so I just disabled the call to XFixesHideCursor for now. If you get the latest changes it should not be a problem anymore. configure.ac should be adjusted to require a newer version of xfixes once we enable this cursor code. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Dbus plugin problem: Setting reset
On Tue, 2007-05-15 at 15:45 +0200, Danny Baumann wrote:
Hi,
since quite some time I encounter a problem which I believe is in the
dbus plugin: Sometimes when I load or unload plugins by changing the
configuration, all settings of all plugins are reset. At the same time,
the following message appears multiple times in the terminal I started
Compiz from (which makes me believe the problem is in the dbus plugin):
A handler is already registered for the path starting with path[0] =
org
These warnings were introduced with the dbus introspection, I
doubt they are related to your problem.
They are just warnings because some paths are being reregistered.
First let me say: That's correct - it really was coincidence. ;-)
I haven't been able to track it down yet because it happens rarely (but
regularly).
After this happens, the only ways to restore my custom config are to
reload Compiz or to 'touch' each single setting ('touch' meaning change
it and change it back).
This has happened to me using both ini and ccp as setting storage
backends, so I doubt it's related to that.
I finally have found the reason for the problem: It is wrapping into
initPluginFor(Display|Screen) while executing initPluginFor(Display|
Screen).
Let me show this with the call stack. 'storage' in this example is the
option storage plugin.
- d-initPluginForDisplay (plugin.c:300) is called at some point for the
storage plugin
- this calls core's initPluginForDisplay, which calls initDisplay
(plugin.c:189)
- storage WRAPs into initPluginForDisplay
- initPluginForDisplay is called for the next plugin (e.g. dbus ;-) )
- storageInitPluginForDisplay is called
- storage UNWRAPs
- core's initPluginForDisplay is called
- initDisplay for the plugin is called
- plugin WRAPs into initPluginForDisplay
- storage WRAPs into initPluginForDisplay again
This is the reason why the pointer to storageInitPluginForDisplay will
get lost afterwards and newly loaded plugins thus won't get their
settings initialized.
So in short: We are WRAPping a function while executing it, which is
bad(TM). Does anyone have a suggestion how to fix it?
Yes, that's bad. The appropriate fix seems to be to move the plugin
initialization out of initPluginForDisplay and initPluginForScreen. I've
attached a patch that does this, let me know how it works.
Thanks for catching this one,
- David
--- a/src/plugin.c
+++ b/src/plugin.c
@@ -186,15 +186,26 @@ initPluginForDisplay (CompPlugin *p,
CompScreen *s, *failedScreen = d-screens;
Bool status = TRUE;
-if (!(*p-vTable-initDisplay) (p, d))
- return FALSE;
-
for (s = d-screens; s; s = s-next)
{
+ if (p-vTable-initScreen)
+ {
+ if (!(*p-vTable-initScreen) (p, s))
+ {
+ failedScreen = s;
+ status = FALSE;
+ break;
+ }
+ }
+
if (!(*s-initPluginForScreen) (p, s))
{
fprintf (stderr, %s: Plugin '%s':initScreen failed\n,
programName, p-vTable-name);
+
+ if (p-vTable-finiScreen)
+ (*p-vTable-finiScreen) (p, s);
+
failedScreen = s;
status = FALSE;
break;
@@ -202,8 +213,13 @@ initPluginForDisplay (CompPlugin *p,
}
for (s = d-screens; s != failedScreen; s = s-next)
+{
(*s-finiPluginForScreen) (p, s);
+ if (p-vTable-finiScreen)
+ (*p-vTable-finiScreen) (p, s);
+}
+
return status;
}
@@ -214,9 +230,12 @@ finiPluginForDisplay (CompPlugin *p,
CompScreen *s;
for (s = d-screens; s; s = s-next)
+{
(*s-finiPluginForScreen) (p, s);
-(*p-vTable-finiDisplay) (p, d);
+ if (p-vTable-finiScreen)
+ (*p-vTable-finiScreen) (p, s);
+}
}
Bool
@@ -225,12 +244,6 @@ initPluginForScreen (CompPlugin *p,
{
Bool status = TRUE;
-if (p-vTable-initScreen)
-{
- if (!(*p-vTable-initScreen) (p, s))
- return FALSE;
-}
-
if (p-vTable-initWindow)
{
CompWindow *w, *failedWindow = s-windows;
@@ -268,9 +281,6 @@ finiPluginForScreen (CompPlugin *p,
for (w = s-windows; w; w = w-next)
(*p-vTable-finiWindow) (p, w);
}
-
-if (p-vTable-finiScreen)
- (*p-vTable-finiScreen) (p, s);
}
static Bool
@@ -297,6 +307,17 @@ initPlugin (CompPlugin *p)
if (d)
{
+ if (p-vTable-initDisplay)
+ {
+ if (!(*p-vTable-initDisplay) (p, d))
+ {
+ (*p-vTable-fini) (p);
+
+ return FALSE;
+
+ }
+ }
+
if (!(*d-initPluginForDisplay) (p, d))
{
fprintf (stderr, %s: Plugin '%s':initDisplay failed\n,
@@ -317,8 +338,13 @@ finiPlugin (CompPlugin *p)
CompDisplay *d = compDisplays;
if (d)
+{
(*d-finiPluginForDisplay) (p, d);
+ if (p-vTable-finiDisplay)
+ (*p-vTable-finiDisplay) (p, d);
+}
+
(*p-vTable-fini) (p);
}
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Fragment interface on Intel
On Tue, 2007-05-15 at 07:40 +0800, Sam Spilsbury wrote: On 5/15/07, Sam Spilsbury [EMAIL PROTECTED] wrote: OK. Just to let you know - it most likely IS the fragment interface - Water fragmentation worked before the fragment interface was out On that note - do you think I can get a git revision that includes the blur plugin but does not include the fragment interface? no, there's no such revision. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] removing string restrictions
On Fri, 2007-05-11 at 18:53 +0200, Dennis Kasprzyk wrote: Am Freitag, 11. Mai 2007 17:15 schrieb David Reveman: On Fri, 2007-05-11 at 11:45 +0200, Dennis Kasprzyk wrote: Am Donnerstag, 10. Mai 2007 21:24 schrieb David Reveman: We've previously discussed if we should add some sort of selection option type and not use string options and string restrictions for that purpose. I don't think we need a new option type for this. The integer type should do just fine. The attached patch changes the blur plugin's filter option from string to integer type and adds the relevant metadata. I suggest that we change all existing options that use string restrictions in a similar way and remove the string restrictions completely. Questions? Does it sounds OK? - David I like the idea, but I would prefer a different XML style. desc _name value=1Foo/_name _name value=2Foo2/_name _name value=3Foo3/_name /desc I wanted the desc tag to look the same for every option type and not all option type values can be represented as strings. e.g. actions. All option values in the meta data are currently within tags, hence it makes sense to keep these values within tags as well. - David Maybe you should provide some kind of final layout description (also for the dependency rules), so that we can start to implement it. Getting everything together from different mails is painfull. The dependency rules are unrelated to this and should be implemented independently. I don't see any reason for merging the changes or the discussions. This string restriction change is easy as it can be done incrementally once we've agreed on what XML style to use. Someone could maintain a .dtd with all standard tags but plugins and configuration tools are always allowed to extend it in whatever way they want. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] Water fixes
On Sun, 2007-05-13 at 18:03 -0500, Erkin Bahceci wrote: Hi, I had a look at some problems I saw in the Water plugin. Here are the patches fixing those. The file names should be self-descriptive. Great, I've committed all patches except Stop-Water-drawing-right-after-waves-disappear as I'm not sure how you came to the conclusion that the count variable could be decremented at that rate. Did you make any calculations to come up with that or is it just based on testing on your machine? - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] xsltproc, schemas.xslt
On Mon, 2007-05-14 at 15:08 -0500, Travis Watkins wrote: On 5/14/07, David Reveman [EMAIL PROTECTED] wrote: libxslt.pkg seem to be the pkg-config file we need to check for. I've updated configure.ac. Is this accurate with how ubuntu packages xsltproc? No, having libxslt.pc does not guarantee xsltproc will be installed. You have to actually check for the binary like my patch does. xsltproc is distributed as part of the libxslt package, hence separating xsltproc and the libxslt.pc file like ubuntu has done seems like a mistake to me but I guess it doesn't hurt to include a check to ensure that the binary is present so I've included your patch. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] meta data update
On Fri, 2007-05-11 at 11:52 +0200, Dennis Kasprzyk wrote: Am Montag, 7. Mai 2007 18:22 schrieb David Reveman: The switch to the new metadata system is almost complete. All plugins in the fdo repo except plane and ini have been converted. I'll probably go ahead and convert those plugins as well sometime soon unless the original authors of those plugins tells me not to. The horrible gconf-dump plugin has been removed and replaced by a simple xslt stylesheet. gconf schemas are now generated from the xml meta data files as part of the build process and the stylesheet and a compiz-gconf pkg-config file is installed so a command similar to this: xsltproc -o compiz-plugin.schemas `pkg-config --variable=xsltdir compiz-gconf`/schemas.xslt plugin.xml can be used to generate a schema file for a plugin outside the fdo repository. Plugin dependencies have not yet been moved to the meta data system. I'd like some feedback before we do this. I suggest that we use tags similar to this: compiz plugin name=cube featurelarge-desktop/feature deps requirement pluginpng/plugin featuresome-feature/feature some_propertyname-of-required-property/some_property /requirement conflict pluginplane/plugin featuresome-other-feature/feature /conflict /deps /plugin compiz It will make it easy to add new meta data tags that can be used as requirements or conflicts. I like the idea but we should really define before and after tags. The other thing that needs to be discussed related to this is whether the core should be aware of any of these dependencies. I think that not having the core be aware of any dependencies is definitely the best solution. I would also like this, but I see here problems with users that don't use a config tool and create a wrong active plugin list directly in gconf/ini and report bugs because there are problems with some plugins. If there's actually bugs, then those should be fixed and not avoided through dependencies. If it's not working the way they want it to because they're miss-configuring it that's not our problem. They should use a configuration tool if they can't configure it manually. It's up to the plugins to deal with conflicts. Whether that is to fail when loading or lack functionality doesn't matter but they will of course not be allowed to crash. If each plugin will have it's own conflict checking code, it will end that each plugin will have nearly the same conflict checking system, and we will have to move it to core. Most plugins are not going to need any conflict checking at all. Some might need a simple check to see if some other plugin is loaded and bail out if that's the case. I believe that a good plugin shouldn't need any checking at all, it should work in well-defined way no matter what other plugins are loaded. It's important that the core is designed in a way that allow this. I'm convinced that not having the core provide support for any dependency checking is good in the long run. It will give us better plugins and make sure that the hooks provided by the core are properly designed. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] meta data update
On Tue, 2007-05-08 at 07:28 +0200, Danny Baumann wrote: Hi, Plugin dependencies have not yet been moved to the meta data system. I'd like some feedback before we do this. I suggest that we use tags similar to this: compiz plugin name=cube featurelarge-desktop/feature deps requirement pluginpng/plugin featuresome-feature/feature some_propertyname-of-required-property/some_property /requirement conflict pluginplane/plugin featuresome-other-feature/feature /conflict /deps /plugin compiz It will make it easy to add new meta data tags that can be used as requirements or conflicts. Sounds good. What I am missing in your suggestion, however, is the definition of load order hints. Following your suggestion for requirements conflicts, I would suggest the following: compiz plugin name=someplugin loadorder beforesomeotherplugin1/before aftersomeotherplugin2/after /loadorder /plugin /compiz Sure but I would prefer something like this: compiz plugin deps relation type=before pluginsomeplugin/plugin /relation /deps /plugin /compiz The other thing that needs to be discussed related to this is whether the core should be aware of any of these dependencies. I think that not having the core be aware of any dependencies is definitely the best solution. It's up to the plugins to deal with conflicts. Whether that is to fail when loading or lack functionality doesn't matter but they will of course not be allowed to crash. Sounds fine to me. Good, it's seems like everyone is OK with this so I think we can start updating plugins. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] meta data update
On Fri, 2007-05-11 at 18:50 +0200, Dennis Kasprzyk wrote: Am Freitag, 11. Mai 2007 17:09 schrieb David Reveman: On Fri, 2007-05-11 at 11:52 +0200, Dennis Kasprzyk wrote: Am Montag, 7. Mai 2007 18:22 schrieb David Reveman: The switch to the new metadata system is almost complete. All plugins in the fdo repo except plane and ini have been converted. I'll probably go ahead and convert those plugins as well sometime soon unless the original authors of those plugins tells me not to. The horrible gconf-dump plugin has been removed and replaced by a simple xslt stylesheet. gconf schemas are now generated from the xml meta data files as part of the build process and the stylesheet and a compiz-gconf pkg-config file is installed so a command similar to this: xsltproc -o compiz-plugin.schemas `pkg-config --variable=xsltdir compiz-gconf`/schemas.xslt plugin.xml can be used to generate a schema file for a plugin outside the fdo repository. Plugin dependencies have not yet been moved to the meta data system. I'd like some feedback before we do this. I suggest that we use tags similar to this: compiz plugin name=cube featurelarge-desktop/feature deps requirement pluginpng/plugin featuresome-feature/feature some_propertyname-of-required-property/some_property /requirement conflict pluginplane/plugin featuresome-other-feature/feature /conflict /deps /plugin compiz It will make it easy to add new meta data tags that can be used as requirements or conflicts. I like the idea but we should really define before and after tags. The other thing that needs to be discussed related to this is whether the core should be aware of any of these dependencies. I think that not having the core be aware of any dependencies is definitely the best solution. I would also like this, but I see here problems with users that don't use a config tool and create a wrong active plugin list directly in gconf/ini and report bugs because there are problems with some plugins. If there's actually bugs, then those should be fixed and not avoided through dependencies. If it's not working the way they want it to because they're miss-configuring it that's not our problem. They should use a configuration tool if they can't configure it manually. Currently there is one one system that provides automatic sorting of plugins and this is the ccs (compiz configuration system) at git.opencompositing.org and it is still under heavy development. But I would really happy if the current dependency checking code would be removed from the core. Whether one, zero or a bunch of systems currently support sorting doesn't matter. It's up to the plugins to deal with conflicts. Whether that is to fail when loading or lack functionality doesn't matter but they will of course not be allowed to crash. If each plugin will have it's own conflict checking code, it will end that each plugin will have nearly the same conflict checking system, and we will have to move it to core. Most plugins are not going to need any conflict checking at all. Some might need a simple check to see if some other plugin is loaded and bail out if that's the case. I believe that a good plugin shouldn't need any checking at all, it should work in well-defined way no matter what other plugins are loaded. It's important that the core is designed in a way that allow this. I'm convinced that not having the core provide support for any dependency checking is good in the long run. It will give us better plugins and make sure that the hooks provided by the core are properly designed. For such basic checks we should really add a screenGrabExists function to core. I was talking about bailing out at initialization time. Refuse to load if some other plugin is already loaded. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] meta data update
On Fri, 2007-05-11 at 17:36 +0100, Mike Dransfield wrote: Dennis Kasprzyk wrote: Am Freitag, 11. Mai 2007 17:09 schrieb David Reveman: On Fri, 2007-05-11 at 11:52 +0200, Dennis Kasprzyk wrote: Am Montag, 7. Mai 2007 18:22 schrieb David Reveman: The switch to the new metadata system is almost complete. All plugins in the fdo repo except plane and ini have been converted. I'll probably go ahead and convert those plugins as well sometime soon unless the original authors of those plugins tells me not to. The horrible gconf-dump plugin has been removed and replaced by a simple xslt stylesheet. gconf schemas are now generated from the xml meta data files as part of the build process and the stylesheet and a compiz-gconf pkg-config file is installed so a command similar to this: xsltproc -o compiz-plugin.schemas `pkg-config --variable=xsltdir compiz-gconf`/schemas.xslt plugin.xml can be used to generate a schema file for a plugin outside the fdo repository. Plugin dependencies have not yet been moved to the meta data system. I'd like some feedback before we do this. I suggest that we use tags similar to this: compiz plugin name=cube featurelarge-desktop/feature deps requirement pluginpng/plugin featuresome-feature/feature some_propertyname-of-required-property/some_property /requirement conflict pluginplane/plugin featuresome-other-feature/feature /conflict /deps /plugin compiz It will make it easy to add new meta data tags that can be used as requirements or conflicts. I like the idea but we should really define before and after tags. The other thing that needs to be discussed related to this is whether the core should be aware of any of these dependencies. I think that not having the core be aware of any dependencies is definitely the best solution. I would also like this, but I see here problems with users that don't use a config tool and create a wrong active plugin list directly in gconf/ini and report bugs because there are problems with some plugins. If there's actually bugs, then those should be fixed and not avoided through dependencies. If it's not working the way they want it to because they're miss-configuring it that's not our problem. They should use a configuration tool if they can't configure it manually. Currently there is one one system that provides automatic sorting of plugins and this is the ccs (compiz configuration system) at git.opencompositing.org and it is still under heavy development. But I would really happy if the current dependency checking code would be removed from the core. This is not strictly true. My web based settings tool does automatic plugin ordering based on the data provided by dbus. I think RYX also has a python library which does this. It's up to the plugins to deal with conflicts. Whether that is to fail when loading or lack functionality doesn't matter but they will of course not be allowed to crash. If each plugin will have it's own conflict checking code, it will end that each plugin will have nearly the same conflict checking system, and we will have to move it to core. Most plugins are not going to need any conflict checking at all. Some might need a simple check to see if some other plugin is loaded and bail out if that's the case. I believe that a good plugin shouldn't need any checking at all, it should work in well-defined way no matter what other plugins are loaded. It's important that the core is designed in a way that allow this. I'm convinced that not having the core provide support for any dependency checking is good in the long run. It will give us better plugins and make sure that the hooks provided by the core are properly designed. For such basic checks we should really add a screenGrabExists function to core. I think the point is that plugins should not be aware of other plugins at all and should not do anything bad if those plugins are not loaded. They should be written in such a way that it does not matter if the dependencies are not loaded, they will just lack some functionality. ie. It should be possible to load rotate without cube and it would not behave badly, the same for loading rotate before cube. Eventually, I'd like to see no conditionals or code at all that depend on the existence of other plugins. Cube/rotate is always a bad example. That separation started out as a test and it's a shame that it still works like that. The rotate functionality should be part of the cube plugin. If we want to be able to separate that kind of functionality into different plugins, it should be done through
Re: [compiz] White boarders on size 32 shadows. Intel platform only
On Sun, 2007-05-06 at 13:59 +0800, Sam Spilsbury wrote: So, wait, does that change the shadow *size* to another value other than 32? It's the radius of the gaussian function used to generate the shadow. A small change might not change the number of pixels required for the shadow but a large one will. On 5/4/07, David Reveman [EMAIL PROTECTED] wrote: On Thu, 2007-05-03 at 07:02 +0800, Sam Spilsbury wrote: Is it possible for the user to specify how big they want thier shadow to be in gconf? I know its possible in the emerald window decorator yes, shadow_radius key. - David - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] Transparent cube
On Mon, 2007-05-07 at 21:24 +0300, Roi Cohen wrote:
Hi.
I re-created my patches to work on latest git, and use the order system.
David, what do you think of these patches now?
Did we solve all issues with the order interface? How can multiple
plugins use that interface reliably? I'd like to make sure that we at
least have a good plan for how to deal with that before we add this.
- David
Regards,
Roi.
On 5/4/07, David Reveman [EMAIL PROTECTED] wrote:
On Tue, 2007-05-01 at 23:06 +0200, Dennis Kasprzyk wrote:
Am Dienstag, 1. Mai 2007 22:54 schrieben Sie:
On Tue, 2007-05-01 at 23:29 +0300, Roi Cohen wrote:
Hi David.
I thought about your suggestion a bit more, and i think it has a
problem, although it's a bit hard to explain it.
How will plugins exactly wrap this function? I mean, obviously they
will just call the WRAP / UNWRAP macros, but what i'm asking is, what
will they actually do inside this function?
I guess it needs to be something like this:
nextInStack(w)
{
if (Plugin makes an effect and needs to change order)
return next;
UNWRAP;
call;
WRAP;
}
If one plugin needs to change painting order, plugins loaded before it
won't get the chance to change their painting order.
3D and cube will still work together, but only because of luck - 3d
needs to be loaded before cube (it needs the openGL matrices of the
cube's transformations to know how to reorder the painting) which
means that theoretically, 3d's paint order won't be executed. However,
it will work because 3d doesn't need to change painting order for ftb
faces, and cube doesn't need to change painting order for btf faces.
Again, I consider this as a lucky coincidence, both 3d and cube will
work, but it shows why I think wrapping this function is somewhat
problematic.
Dennis Kasprzyk suggested another approach to this problem - instead
of wrapping this function, we will pass another argument to
paintTransformedScreen which is:
struct CompWindowListSort {
// Function pointers
FirstInStackProc* first;
LastInStackProc* last;
NextInStackProc* next;
PrevInStackProc* prev;
}
This way, plugins won't wrap this function, and the plugin which is
loaded first gets the call on painting order, instead of the last
plugin which is loaded last.
It fixes the problem with 3d and transcube - 3d's paint order will
always be prefered over cube's one.
I'm not really sure this is the best solution - there isn't really a
reason to prefer the first loaded plugin over the last loaded one.
Do you think we should stay with your original idea, ignoring the
problems that will occur when 2 different plugins want to change
painting order (after all, similar problems occur with window
transformations etc), or do you have another idea?
Yes, maybe it's better to just require a depth buffer and destination
alpha for these kind of effects and construct an proper interface for
that instead.
- David
But this could also cause problems with something like skydome. I think
that
every solution can cause problems with other plugins, but I think it is
better to add a solution that will not add additional dependencies. And I
think that the order change system is more flexible so that we could use
it
for another effects later.
I fail to see how it could cause problems with the skydome but using
destination alpha is definitely not going to work with the blur plugin.
We're going to have to address the problem with drawing intersecting
translucent objects at some point but as we don't have a perfect
solution for that yet, the order system seem like a good idea to start
with.
- 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] removing string restrictions
We've previously discussed if we should add some sort of selection
option type and not use string options and string restrictions for that
purpose.
I don't think we need a new option type for this. The integer type
should do just fine. The attached patch changes the blur plugin's filter
option from string to integer type and adds the relevant metadata. I
suggest that we change all existing options that use string restrictions
in a similar way and remove the string restrictions completely.
Questions? Does it sounds OK?
- David
--- a/include/compiz.h
+++ b/include/compiz.h
@@ -3087,6 +3087,12 @@ matchPropertyChanged (CompDisplay *display,
/* metadata.c */
+#define STRINGIFY(x) #x
+#define TOSTRING(x) STRINGIFY (x)
+#define MINTOSTRING(x) min TOSTRING (x) /min
+#define MAXTOSTRING(x) max TOSTRING (x) /max
+#define RESTOSTRING(min, max) MINTOSTRING (min) MAXTOSTRING (max)
+
typedef struct _CompMetadataOptionInfo {
char *name;
char *type;
--- a/metadata/blur.xml.in
+++ b/metadata/blur.xml.in
@@ -38,15 +38,24 @@
_longBlur behind translucent parts of windows/_long
defaulttrue/default
/option
- option name=filter type=string
+ option name=filter type=int
_shortBlur Filter/_short
_longFilter method used for blurring/_long
- default4xBilinear/default
- allowed
- value4xBilinear/value
- valueGaussian/value
- valueMipmap/value
- /allowed
+ default0/default
+ min0/min
+ max2/max
+ desc
+ value0/value
+ _name4xBilinear/_name
+ /desc
+ desc
+ value1/value
+ _nameGaussian/_name
+ /desc
+ desc
+ value2/value
+ _nameMipmap/_name
+ /desc
/option
option name=gaussian_radius type=int
_shortGaussian Radius/_short
--- a/plugins/blur.c
+++ b/plugins/blur.c
@@ -37,11 +37,10 @@ static CompMetadata blurMetadata;
#define BLUR_GAUSSIAN_RADIUS_MAX 15
-typedef enum {
-BlurFilter4xBilinear,
-BlurFilterGaussian,
-BlurFilterMipmap
-} BlurFilter;
+#define BLUR_FILTER_4X_BILINEAR 0
+#define BLUR_FILTER_GAUSSIAN1
+#define BLUR_FILTER_MIPMAP 2
+#define BLUR_FILTER_LAST BLUR_FILTER_MIPMAP
typedef struct _BlurFunction {
struct _BlurFunction *next;
@@ -121,8 +120,7 @@ typedef struct _BlurScreen {
Bool blurOcclusion;
-BlurFilter filter;
-intfilterRadius;
+int filterRadius;
BlurFunction *srcBlurFunctions;
BlurFunction *dstBlurFunctions;
@@ -190,17 +188,6 @@ typedef struct _BlurWindow {
#define NUM_OPTIONS(s) (sizeof ((s)-opt) / sizeof (CompOption))
-static BlurFilter
-blurFilterFromString (CompOptionValue *value)
-{
-if (strcasecmp (value-s, gaussian) == 0)
- return BlurFilterGaussian;
-else if (strcasecmp (value-s, mipmap) == 0)
- return BlurFilterMipmap;
-else
- return BlurFilter4xBilinear;
-}
-
/* pascal triangle based kernel generator */
static int
blurCreateGaussianLinearKernel (int radius,
@@ -280,11 +267,11 @@ blurUpdateFilterRadius (CompScreen *s)
{
BLUR_SCREEN (s);
-switch (bs-filter) {
-case BlurFilter4xBilinear:
+switch (bs-opt[BLUR_SCREEN_OPTION_FILTER].value.i) {
+case BLUR_FILTER_4X_BILINEAR:
bs-filterRadius = 2;
break;
-case BlurFilterGaussian: {
+case BLUR_FILTER_GAUSSIAN: {
int radius = bs-opt[BLUR_SCREEN_OPTION_GAUSSIAN_RADIUS].value.i;
float strength = bs-opt[BLUR_SCREEN_OPTION_GAUSSIAN_STRENGTH].value.f;
@@ -293,7 +280,7 @@ blurUpdateFilterRadius (CompScreen *s)
bs-filterRadius = radius;
} break;
-case BlurFilterMipmap: {
+case BLUR_FILTER_MIPMAP: {
float lod = bs-opt[BLUR_SCREEN_OPTION_MIPMAP_LOD].value.f;
bs-filterRadius = powf (2.0f, ceilf (lod));
@@ -561,7 +548,7 @@ blurSetScreenOption (CompPlugin *plugin,
CompOptionValue *value)
{
CompOption *o;
-int index;
+int index, filter;
BLUR_SCREEN (screen);
@@ -613,9 +600,8 @@ blurSetScreenOption (CompPlugin *plugin,
}
break;
case BLUR_SCREEN_OPTION_FILTER:
- if (compSetStringOption (o, value))
+ if (compSetIntOption (o, value))
{
- bs-filter = blurFilterFromString (o-value);
blurReset (screen);
damageScreen (screen);
return TRUE;
@@ -624,7 +610,8 @@ blurSetScreenOption (CompPlugin *plugin,
case BLUR_SCREEN_OPTION_GAUSSIAN_RADIUS:
if (compSetIntOption (o, value))
{
- if (bs-filter == BlurFilterGaussian)
+ filter = bs-opt[BLUR_SCREEN_OPTION_FILTER].value.i;
+ if (filter == BLUR_FILTER_GAUSSIAN)
{
blurReset (screen);
damageScreen (screen);
@@ -635,7 +622,8 @@ blurSetScreenOption (CompPlugin *plugin,
case BLUR_SCREEN_OPTION_GAUSSIAN_STRENGTH:
if (compSetFloatOption (o, value))
{
- if (bs-filter == BlurFilterGaussian)
+ filter = bs-opt[BLUR_SCREEN_OPTION_FILTER].value.i;
+ if (filter == BLUR_FILTER_GAUSSIAN)
{
blurReset (screen);
damageScreen (screen);
@@ -646,7 +634,8 @@ blurSetScreenOption (CompPlugin *plugin,
case
[compiz] meta data update
The switch to the new metadata system is almost complete. All plugins in the fdo repo except plane and ini have been converted. I'll probably go ahead and convert those plugins as well sometime soon unless the original authors of those plugins tells me not to. The horrible gconf-dump plugin has been removed and replaced by a simple xslt stylesheet. gconf schemas are now generated from the xml meta data files as part of the build process and the stylesheet and a compiz-gconf pkg-config file is installed so a command similar to this: xsltproc -o compiz-plugin.schemas `pkg-config --variable=xsltdir compiz-gconf`/schemas.xslt plugin.xml can be used to generate a schema file for a plugin outside the fdo repository. Plugin dependencies have not yet been moved to the meta data system. I'd like some feedback before we do this. I suggest that we use tags similar to this: compiz plugin name=cube featurelarge-desktop/feature deps requirement pluginpng/plugin featuresome-feature/feature some_propertyname-of-required-property/some_property /requirement conflict pluginplane/plugin featuresome-other-feature/feature /conflict /deps /plugin compiz It will make it easy to add new meta data tags that can be used as requirements or conflicts. The other thing that needs to be discussed related to this is whether the core should be aware of any of these dependencies. I think that not having the core be aware of any dependencies is definitely the best solution. It's up to the plugins to deal with conflicts. Whether that is to fail when loading or lack functionality doesn't matter but they will of course not be allowed to crash. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] meta data update
On Tue, 2007-05-08 at 00:48 +0100, Mike Dransfield wrote: David Reveman wrote: The switch to the new metadata system is almost complete. All plugins in the fdo repo except plane and ini have been converted. I'll probably go ahead and convert those plugins as well sometime soon unless the original authors of those plugins tells me not to. The attached patch should save you the trouble. I cannot commit it at the moment. Thanks. I've now also updated the plane plugin. The horrible gconf-dump plugin has been removed and replaced by a simple xslt stylesheet. gconf schemas are now generated from the xml meta data files as part of the build process and the stylesheet and a compiz-gconf pkg-config file is installed so a command similar to this: I suppose we will need to work out an xslt for the ini plugin, but I am not in any hurry at the moment. I assume everything will continue to work because the default values are loaded from the metadata, so maybe this would not be needed at all? Not unless you like to store some default values in a system wide directory. I would avoid that if possible. You can read the default values for options at run-time from the meta data objects provided by each plugin. I remember that you were interested in this earlier. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] Option for activation behaviour on window close
On Thu, 2007-05-03 at 14:51 +0200, Danny Baumann wrote: Hi, please find attached a patch that makes the behaviour of window activation when a window is closed optional. Currently, always the last active window is activated. Sometimes this might not be the desired behaviour, but users (like me ;-) ) would like the window under the pointer to be activated. This patch adds the latter behaviour as an option while still keeping the former behaviour as default. Questions / concerns / objections / opinions anyone? Is there any reason someone using click-to-focus would want this? Is there any reason someone not using click-to-focus wouldn't want this? From my point of view: Two times no. Alyone got a different opinion? David, so you are fine with adding this code, but not making it depend on its own option, but on the click_to_focus option? Yes, let's add this as part of the click_to_focus option and we'll improve it if someone complains. Please use the word Pointer instead of Mouse in the focusMouseTarget function name. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] White boarders on size 32 shadows. Intel platform only
On Sun, 2007-04-29 at 17:43 +0800, Sam Spilsbury wrote: Recently, I brought up a topic about white boarders being drawn instead of shadows in Gnome-Window-Decorator. A patch was made up by gandalfn to correct this by making 32 pixel shadows 33 pixels, however the patch was not committed because it was a workaround. This is a huge functional annoyance to us intel users and needs to be cured. There are two soultions I can think of: 1 Get in contact with the X.org i810 team and ask them to correct the issue in their driver which does not allow 32 pixel shadows to be drawn. 2 Allow the user to specify in GConf or something the depth of the shadows that GWD creates. Emerald from Beryl currently allows this so I don't understand why it would be too hard to implement. Yes I *know* #2 is more like a workaround but at least it allows the user to specify how big they want this shadows to be. (Please dont confuse this with X-offset adn Y-Offset). I did some quick testing and the problem indeed seem to be a driver issue but I haven't had time to track down exactly what's causing it. There's nothing we can do until someone have been able to track it down. You can enter a intel 3d driver bug for this if you want and if we're lucky someone might be able to help us track this down. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Wobbly jerkyness
On Sun, 2007-04-29 at 17:54 +0800, Sam Spilsbury wrote: About a month ago, David made a commit to wobbly to the spring engine which has introduced some bugs. They are hard to explain so bear with me. In a sense, the wobbly plugin does not seem as smooth as it used to be and the windows jerk all over the place. For example, I sometimes notice that when I move a large window (around 2/3 of the size of the desktop window), If I moved it down, the top of the window would jerk up then come down quickly. If you want me to explain further then let me know I didn't change anything in the wobbly plugin, I changed how the move plugin works. The jerkyness and high CPU load is actually expected behavior. The high CPU load is caused by the move plugin changing the server-side window attributes to reflect the current position of the window in real-time. The move plugin doesn't have to do this but it's important that things don't break when it does. I've already been able to fix a number of performance issues after making this change and I think there's some more low hanging fruit that can be taken care of quickly. Eventually, I'll make it possible to not have the move plugin update the window attributes in real-time and I can guarantee that performance will be at least as good as before I did these changes to the move plugin. However, before I can make this possible we need to improve the way window animations are performed. What the move plugin was doing before was wrong and I'm not going to change back to that. You're very welcome to help out with testing, profiling and fixing issues related to how the move plugin currently works. If you're not interested in that and if you can't live with the issues and performance of the current move plugin, you're welcome to use an older version of the move plugin with the bad but better performing behavior. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Re: Plugin Interface for Decoations
On Mon, 2007-04-30 at 17:24 +0200, Patrick Niklaus wrote: I realized some major problems with this approach. To give you a better idea of what I'm actually talking about, take a look at this schema: http://media.beryl-project.org/Decoration-Schema.png As you can see KWD, GWD and Emerald would run in the same applications, as plugins. This might cause problems because the main loops of Qt and Gtk are conflicting here, which was actually one of the reasons why the decorator was not a own plugin in compiz. Another problem is the settings backend. To integrate into the desktop each plugin uses its own backend. For example the emerald plugin uses ini/gkey files + libemeraldengine but GWD gconf + metacity functions. So basically we would end up with a complete window decorator, ported to a plugin, which is not really what I had in mind. An alternative would be, remaining the current structure of having several decorator running as an own application and expand emerald to an highly-customizeable and extentable decorator, which relies on plugin architecture. The main goal of that decorator would be to provide an independently theme and other rather experimental things like animations. This architecture is shown in this schema: http://media.beryl-project.org/Decoration-Schema2.png I'm not really sure which one would fit our needs best here (or if there would be other solutions), so it would be the best if we could discuss that here. Regrads, Patrick 2007/4/29, Patrick Niklaus [EMAIL PROTECTED]: Hi, this email is basically the result of a small discussion which made me think what the real end-goal of my work on Emerald-2 would be. Since Emerald has already a extensible system (Engines) I thought about giving the engines wider access, so that they are more like plugins. However the first thing needed is a nice plugin API. The base for that is the new settings backend of Emerald-2. Settings backend might not be the right word here, since it handles a lot more, it could also be called engines backend. (= libemeraldengine) The next step is, taking GWD (which has a proper usage of libdecoration), port it to that system and also port most of Emerald features to it. This includes pixmap buttons and usage of the button interface for libdecoation, which will described in detail in another mail. Basically we would end up with a better Emerald, working name Emerald-2. Now, if we got that working properly we need to think about what will be moved to a plugin and what will stay in core. At this point we also need an exact definition of the plugin API. A first general definition can be found below. It would be really nice if I could get some feedback or suggestions on my plans. BTW. Please do not start a flame war because of the working name, it will be probably changed and I don't want to decide about it yet, but since it shares most of its features I choose this name for now. The Plugin Interface * Settings: - make use of libemeraldengien settings backend = could cause problems because Metacity and KDE have different backends - maybe extent it so it would better fit our needs - but keep in mind that we won't need a second implementation of the compiz options system * Event handling: - provide notifies for plugins for some specific events - not sure which one will be needed - however resize/move/enter/leave will probably be included * Integration into Emerald-2: - standard button drawing will be probably handled by plugins - window title drawing probably too - we need a system so plugins can sign up for providing functions = wrapping stack like in compiz = slot system, so only one plugin at the same time can sign up for it * Integration into DE's: - add a plugin for Metacity support - maybe port the KDE decoration also to a plugin (if thats possible) Regards, Patrick You're welcome to improve emerald, rewrite it or write a completely new decorator, I'm definitely not going to stand in the way of that. However, I suggest that you avoid duplicating work when not necessary and avoid creating alternatives to existing solutions. libdecoration contains code that is used by all decorators. If you find some code that makes sense for more than one decorator, it likely makes sense to put that code in libdecoration. What's missing in current decorators? The following is what I think is missing and how it's most properly fixed. KDE - Expose a few things in kwd that will make is possible for kwin plugins to use alpha channels and less resources. That's it, the kwin plugin API is flexible enough do do pretty much anything so I don't see a need to create an alternative here. GNOME - The existing metacity theme system is pretty limited but extending it with something like theme engines, which would allow metacity themes to look fancier
Re: [compiz] gtk-window-decorator Wnck warnings
On Mon, 2007-04-30 at 01:22 -0500, Erkin Bahceci wrote: Hi, I'm getting a lot of warnings like this one: (gtk-window-decorator:8442): Wnck-WARNING **: Unhandled action type (nil) Does anyone else see these warnings or know what causes these? That warning is caused by compiz setting the new ACTION_ABOVE hint on windows and old versions of libwnck doesn't recognize that hint. It's harmless and if you upgrade to a newer version of libwnck (I think you need the svn version) it will disappear. That libwnck spits out a warning just because it doesn't recognize an action type is sort of bug. Also, it seems that this lost textures bug https://bugs.freedesktop.org/show_bug.cgi?id=10789 usually happens only when these warnings are spitted out, so the bug is probably related to these wnck warnings. I haven't looked at the lost textures bug but I can guarantee that it's not related to this libwnck warning. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Re: [PATCH] Transparent cube
On Fri, 2007-04-27 at 03:13 +0200, Dennis Kasprzyk wrote:
Am Donnerstag, 26. April 2007 23:08 schrieben Sie:
On Wed, 2007-04-25 at 23:48 +0200, Dennis Kasprzyk wrote:
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=36ca8
bf25 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.
You're right, I don't know what I was thinking of yesterday. Off-screen
rendering is not going to be of much help here. I clearly didn't look at
this closely enough yesterday.
I think I got a better understanding now and it seems that the BTF / FTB
patch is a solution for some special cases where windows should not be
rendered using their server side stacking order. A more general solution
that makes it possible for plugins to adjust the order in which windows
are rendered would make more sense to me.
Here's a suggestion:
Instead of just walking the list of windows when rendering them like
this:
for (w = s-window; w; w = w-next)
we can do something like this:
for (w = (*s-stackFuncs.first) (s); w; w = (*s-stackFuncs.next) (w))
and the core version of stackFuncs.next would just look like this:
CompWindow *
stackNext (CompWindow *w)
{
return w-next;
}
plugins can provide any stacking order they want when rendering windows
by wrapping the stackFuncs struct with it's own stack functions. This
should be good for transparent cube and things similar to what the 3d
plugin is doing, right?
What do you guys think? My biggest concern with the BTF / FTB patch is
the way the screen can first be painted with BTF order and then with FTB
order and some plugin must then prevent the core from painting the
window twice.
- David
Great idea but we also should have stackFuncs.last and prev to do the
occlusion detection right and maybe a MASK to be able to disable the
occlusion detection.
yes, .last and .prev are in that struct too of course.
This should be enough to realize transparent cube and most parts of the 3d
plugin.
The last point we should look here are the wrapable clipping planes patches.
I
think the attached picture describes what we have now and what we would like
to have. Sorry but I'm a very bad painter ;-)
yes, I know what you mean. I'm trying to figure out what's the best
solution here. Maybe it's to add the clip planes as arguments to
paintTransformedScreen function. I'm not sure.
- David
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH]Make wobbly's bezier patch to work with grids that aren't 4x4.
On Thu, 2007-04-26 at 17:30 +0300, Roi Cohen wrote: Hi, Recently, I started taking a look at wobbly's source (I was interested in it's physics... ;-)) I noticed that GRID_WIDTH and GRID_HEIGHT were defined to be 4, and I wanted to see how the physics look like with grid sizes that aren't 4x4. I changed the defines to my new grid size, but unfortunately it didn't work. I investigated this bug (it's not exactly a bug because users can't change the grid size), and found out the bezier patch was written for specifically 4x4 grids. The attached patch makes the bezier patch to work on every grid size defined (grid sizes could even be an option, although i think 4x4 indeed gives the best effect). I think the bezierPatchEvaluate function that your patch modifies is one of the most CPU intensive functions that exist in the fdo compiz plugins. Hence, I'm concerned about how this patch affects performance. As the 4x4 grid still gives best results it might be better to just remove those defines from the top of the file and add a comment about the code being hard-coded to a grid size of 4x4. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Re: Maximized windows dissappear
On Sun, 2007-04-29 at 15:17 +0100, Mike Dransfield wrote: Jesper Andersen wrote: Replying to my own email here: On Fri, 2007-04-27 at 09:05 +0200, Jesper Andersen wrote: I am using the lastest git version of compiz and just run in to a new problem after switching to using the ini configuration plugin over the gconf-one. When I maximize a window and then try to move it to another viewport, the cube rotates but the maximized window disappears instead of moving along to the new viewport. The maximized window can be found using the scale plugin (only on show-all action). Further, if I then try to unmaximize the window, the window again disappears and I have to use scale's show-all action. Now, however the window appears in some random almost out of viewport location and I have to drag it back into position. I do not know whether it was my switch to the ini plugin that caused this annoying change in behavior. I now tried with either gconf and ini (with the same settings) and nothing changes. However I noticed the following: whenever I move a window with some contents below the bottom edge of the screen to another viewport, it is immediately displaced on the new viewport so that most of the window's content is above the top edge of the screen. How much seems related to how much was hidden below the bottom edge before the move (this is only when moving a window to a new viewport by AltShiftLeft/Right and similar, not for the usualy mouse-dragging of windows and also not for windows that are beyond any other screen edges). I have tried toggling the Constrain y option in the move-plugin to no avail. I also tried changing the detect outputs in the general options, also to no avail. I am not sure when this strange behavior was introduced and I am wondering whether I am really the only one seeing this? No you are not. I can see both of these problems now and I have tracked the problem down to the moveWindowToViewportPosition function OR the w-output.top calculation. The exact line is this one if (m - w-output.top w-screen-height - vHeight) In the case I just tested this variables had these values. m = 20 w-output.top =23 w-screen.height and vHeight are both 1050. This if statement returns true because -3 0 and it shifts the window down. Sorry, I am not sure how to best fix this one but it is a reproducible problem. I also see the offset problem as well and suspect its related to the same thing. It should now be fixed. Thanks for tracking this down, Mike. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] adding XCB dependency
I intend to make compiz depend on XCB and Xlib/XCB sometime soon so we can start using XCB where it's beneficial [1]. I'm mostly interested in using it for asynchronous reading of window properties but we should eventually try to use it for as much as possible. Removing Xlib completely might not make sense as we need to support multiple implementations of GLX but getting to a stage where it's possible to disable Xlib at build time for those who are interested in that would be neat. If you've got any issues with XCB and Xlib/XCB being added as dependencies please speak up asap. Thanks. [1] http://xcb.freedesktop.org - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Compiling from source (0.4.0)
On Thu, 2007-04-26 at 01:12 +0200, unwiredbrain wrote: Hi to the whole list and **THANKS** for all the job you've done since now! Keep that great work up, guys! I would like to know what the `--with-default-plugins' make options means and how to use it -- I mean: `--with-default-plugins=foo,bar,...,some,more,stuff' and what `--with-max-desktops' will do. PS: I apologize if I am writing in the wrong place. --with-default-plugins will just adjust the plugins that will be default in the gconf schema file. --with-max-desktops is just going to set the hard-coded maximum number of desktops. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
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] 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
