Re: [compiz] KDesktop 3 transparency patch
For those who don't already know, similar patches for libeel and nautilus are available at: http://bugzilla.gnome.org/show_bug.cgi?id=444320 and a wallpaper plugin that supports the hint and images/flat fills/gradients is available at http://gitweb.opencompositing.org. I plan to add compositing of elements/scaling in the near future. Regards, Robert On 6/6/07, Dennis Kasprzyk [EMAIL PROTECTED] wrote: Hello, this patch adds support for real transparency to kdesktop. It adds two new composite manager related features. To activate the features kdesktop has to be started with the --bg-transparency option. The first one allows you to change the opacity of the background image. This works currently with the beryl transparent cube and will also work with compiz once the transparent cube gets applied. To activate the feature add the following to your kdesktoprc: [Background Common] BackgroundOpacity=90 (0 = fully transparent / 100 = opaque) The second feature allows compiz (and later maybe other composite managers) to tell kdesktop not to paint the background image (_COMPIZ_WALLPAPER_SUPPORTED x atom). In this case compiz is able to paint a viewport dependent background or to make it even animated. This feature looks for changes to the x atom, so that kdesktop will automatically switch back to normal background if kwin gets started or compiz stops to render the wallpaper. This patch is against the current kde3 svn. You can also find it with screenshots on http://www.kde-apps.org/content/show.php/KDesktop+transparency+support?content=59864 Regards Dennis ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] state plugin
The Compiz-scheme can function as a state plugin of sorts. It embeds the Guile interpreter for the Scheme language in to a Compiz plugin and provides bindings/hooks in to events. You can find it at http://gitweb.opencompositing.org (compcomm/plugins/compiz-scheme) it has an example startup file with commented snippets including state like usage and a few other documentation and tutorial files. As to porting the original state plugin, there isn't really any documentation on ... anything, though I think the winrules plugin (also at gitweb.opencompositing.org) does something similar. On 5/17/07, Kresimir Kukulj [EMAIL PROTECTED] wrote: hi, I saw that Mike Dransfield tried to port 'state' plugin from beryl. What does it do? It should be able to place windows, based on name, class etc., to specific viewports. I recently converted to compiz window manager from WindowMaker (used it for 8 years), and I miss automatic 'pinning' of specific windows to particular workspace (or viewport in this case). Mike's old port can be found here: http://www.anykeysoftware.co.uk/compiz/plugins/state.tar.gz This is a bit old and does not use new plugin system for options (metadata). I am tyring to see if it could be tweaked to new plugin infrastructure, but it is not trivial (or at least not for me :)). Can someone point me to some documentation so I could port this. Or is this functionality already planned for compiz (or maybe someone already has functonal plugin?). Regards Kresimir -- Kresimir Kukulj [EMAIL PROTECTED] +--+ Remember, if you break Debian, you get to keep both parts. ___ 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] compiz-scheme. Interactive prompt and example startup file.
Beyond the general work on compiz-scheme (new wrappings, hooks, code improvements, etc), I've added a few large new things: 1. Key bindings with modifiers. This lets you from any of your scheme files/interactive prompt bind an arbitrary key + modifier to an arbitrary scheme function. So you can define new Compiz behaviors and shortcuts on the fly. 2. An interactive prompt. This sets up a PTTY and connects xterm to one end, and compiz-scheme to the other. You can then enter scheme expressions and have them evaluated by compiz-scheme on the fly. You can hit super+o to hide/show this. 3. An example startup file (compcomm/plugins/compiz-scheme/startup-example.scm on opencompositing.org GIT). The startup file contains the following: Opacity for dropdown menus Opacity for tooltips. Opacity when moving/resizing windows. Shade maximized windows when grabbing them. Keybinding for raising all GAIM windows. Keybinding for toggling shade on all windows. Keybinding for toggling half opacity on maximized windows. Keybinding for moving all windows to the current viewport (say to recover lost windows). What I want to do next with this is: 1. Add option setting functions. 2. Implement place inside of a scheme script. 3. Fill in another 30 or so missing utility functions. 4. Pretty-print to interactive prompt. It's also worth noting that it's developed in compcomm/plugins/compiz-scheme rather than users/racarr/compiz-scheme now. Once again if you have any questions on how to do something in compiz-scheme, feel free to ask. Regards, Robert ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] Compiz-scheme documentation.
I've documented the 80+ functions available in compiz-scheme (those not available in regular scheme) at: http://people.freedesktop.org/~racarr/DOCUMENTATION and furthermore in the git repo. Additionally a 5 minute tutorial to scheme and a 5 minute tutorial to using compiz-scheme as a state replacement (though this is certainly not all it does!) is available at: http://people.freedesktop.org/~racarr/TUTORIAL Regards, Robert ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] Re: Extension languages and Compiz.
It's worth noting that another alternative is ifdefing code for specific interpreters in various plugins (and insuring the plugins that need to set up the interpreter enviroment load first) and having ./configure --with-scheme --with-python --without-ruby. Or something of the vein. But I don't think we really want this either. On 4/26/07, Robert Carr [EMAIL PROTECTED] wrote: My recent work on Compiz-scheme has brought to my attention several problems preventing a real compiz extension language. Note that when I refer to an extension language, I am not referring to the ability to add plugins in some other languages, but more of something in the vein of emacs lisp. The major problem right now is extension languages are locked in to one plugin and what core exposes. What I mean by this is it's easy to add support for something like: (window-rule (make-rule (set-opacity-when (window-is tooltipp) 0.5))) However it's impossible to add support for something like: (scale-window-when (window-is negativep)). There are two possible solutions to this: 1. Add basic support for a specific interpreter in core. Core would expose wrapper functions around the interpreter to easily enable plugins to add C functions to the interpreter. On one hand, we probably want to avoid binding core to a specific interpreter, on the other hand this sounds rather pleasant compared to the alternative. 2. Add an interpreter interface, with wrappable functions for plugins embedding a specific interpreter to wrap. I think it is abundantly obvious why such an interface would be unreasonably complex and likely bug ridden, exposing no specifics of an interpreter to individual plugins, but still having conversion from interpreter types-native types (a variable number of arguments per function + return types), plus adding new types and other constructs is exceedingly difficult, and complex to the point where I don't think we would want it. Does anyone else have any thoughts? Regards, Robert ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] Scheme extension language plugin.
I've put a scheme plugin in users/racarr/compiz-scheme on gitweb.open-compositing.org. Essentially it allows the user to define a startup file (~/.compiz/startup.scm) and fill it with scheme code to do neat things and extend Beryl. On one hand it acts like a super powered state plugin, on the other it lets you define useful behavior specific to what you do with your Compiz and share these new behaviors with other people. Following are a few examples: #Following snippet gives you transparent dropdown menus. (window-rule #Define a window rule (make-rule #Make a rule passed in (set-opacity-when # Set opacity of a window when (window-is dropdownp) # The window is a dropdown menu 0.75))) # Set to 0.75 #Following snippet shades maximized windows when you grab them. (grab-rule # Define a window grab rule. (make-rule # Make a rule passed to grab-rule (if (maximizedp w) # If window maximized. (toggle-shaded w #Shade window (define amatch (make-match type=normal|state=sticky)) #Define a match for sticky windows or normal windows (bind-key s #Bind the key ctrl+super+s (lambda () #Define an anonymous function to be passed to bind-key (toggle-shaded-when #Toggle window shaded then (lambda (w) (matchp w amatch) #Window passed matches amatch You can read ~/.compiz/window.scm to see some of the wrapping around the C level functions (which themselves are wrapped in the C files). Ask me if you have any questions or want an example of how to do anything. I'll be improving this and doing documentation in the near future. Regards, Robert ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] re-work option initialization
We could set up bcop to generate the code for a library for each plugin that just contains the functions required to get the settings. Furthermore these settings could be represented through some hypothetical CompOptionMetadata struct which could contain all the useful metadata we want. With something like this there is no need for the actual plugin to contain the metadata. Regards, Robert ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] Beryl and Compiz Merge: What's actually going on?
Compiz and Beryl merge: What's really going on? Recently Quinns post to the beryl-dev mailing list entitled 'Merge on' has led to a lot of discussion, some of which has been good and some of which has led to a lot of misinformation, to clear things up I'd like to give the story of the merge, and the justification for some of the more peculiar aspects. Basically lets try to avoid misinformation and make sure everyone has a realistic picture of what's happening. The first thing I want to note is: The merge is NOT ON, it looks incredibly likely, and it's looked incredibly likely for a few weeks now, but there are still some very important things to work out, and a lot of discussion still needs to happen. Around a month and a half ago some of us were discussing some rather radical changes to the design of beryl-core which we inherited from Compiz, this inevitably led to We should talk to Compiz about this to keep things synced, which even more inevitably leads to If we are going to talk to Compiz to keep our designs similar, so on, so forth, are our differences really so large that we need to be two seperate projects?. After talking to a few people I sent an email to David Reveman of Compiz on a personal basis suggesting the idea as something worth discussing, and not really sure what to expect as a response (not having interacted with David before). The response was better than I could have hoped for, and David seemed very interesting in working with us. Excited, a few of us organized a quick adhoc-meeting and worked out a few things that we'd feel neccesary for a merge to work, and a few of these have raised some rather controversy ridden discussion now that they are well known, so I'd like to enumerate some and justify them here. Beryl has about 3 times as much code as Compiz, we've written this because we feel it's neccesary or improves things in some way and we want to see things integrated rather than go to waste. This one is trivial really, it's obvious why we would like this, and we set up a list of differences, discussed it a bit with Compiz people, and we're able to quickly come to answers on most of the differences. This was eased by Compiz's announcement that they plan to make compiz-extras more of an official project, which has much of the same structure as Beryl, this made it evident that a lot of our goals really were the same. New project under a new name, this has been the most controversial point as a lot of people don't feel it's fair or that it will lead to a lot of unneccesary difficulty, that it will lead to distributions unwilling to support such a new window manager or dozens of other complaints. I've thought about this quite a bit, and I'm going to try and justify here why we initially asked for this, and likely why Compiz is good with it. The primary reason is the difference in structure between the two projects, Beryl and Compiz handle management differently, handle new contributors differently, handle releases differently, handle a LOT of things differently. Frankly I feel if we merged under one of the previous projects (Call it X), then there would be a tendancy to just give everyone from the other project (Call it Y) a developer account, start merging the code from Y and say Merge done!. This will NOT work, all of us feel pretty strongly that for the new project to succeeed it needs to include the best aspects of both Beryl and Compiz, and under the envelope of the already established Project X it's difficult and possibly impossible to integrate the 'core' (not as in beryl-core as in metaphorical core), of Y properly. It's better to start from a blank organizational state and decide everything together, we HAVE to decide things together, frankly the worst imaginable situation is a month from now Project Y says This isn't what I expected from a merge! REFORK!. Another crucial point is the communities, open source projects are built around communities, and no community wants to be absorbed en masse in to another, theres a lot of bitterness between the Compiz and Beryl communities and theres no better way to resolve this than the two work together to make a new and better community. We'd also all like to avoid the new project being stuck with whatever conceptions formed around the name of the aforenamed project X, the new project will be a merger of the Compiz and Beryl code yes, but it will be something new, better, and with a broader scope, and we hope it can be looked at that way. Some sort of well defined leadership structure, probably decided through some sort of vote. Again, the reasons for this are obvious. And no just Having David and Quinn share leadership is most definitely definitely definitely not a viable option. So, anyway back to the story. After this David and I (more on behalf of Beryl at this point) exchanged quite a few emails back, having some basic discussion as to how the technical differences can be resolved, and then the discussion kind of died for a
[compiz] Drawing interface
More on the subject of the internal implementation than the method of communication, I believe a setup as follows for a drawing interface makes sense: Wrappable function: grabDrawingRequests , this would allow for multiple methods of communication and protocols to be implemented in plugins (such as over a shared memory transport, dbus, text file, etc). grabDrawingRequests would be called before the screen is painted. Plugins wrapping grabDrawingRequests would be responsible for translating from their method of communication to a format internal to the compositor (The format inside the compositor could be relatively simple as there are very few things required to set up complex drawings). Another function such as addDrawingRequest(CompDrawingRequest * dr) would likely be added as a utility for plugins to add the resulting internal format drawing request to a linked list. Core would be responsible for doing the actual painting at appropriate points during screen painting. It also seems reasonable to consider the idea of a wrappable handleDrawingRequest function but this seems like it is not desirable. Plugins would be required to identify whether they wanted to handle the request based on some flag in a structure, this would become a mess to handle and in the long run probably be less extensible. I'm out of town until Sunday but should be able to get some code working for this next week. Regards, Robert ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] scaler plugin fixes
On Tue, 2007-02-20 at 12:47 +0100, Anders Storsveen wrote: Hi I think this is mostly a question of preference for my part, but I think it would give an overall better quality feel. What I'm talking about is mostly the movement it uses. As I've come to understand, it uses velocity and direction, and a target point. This means that it updates it velocity and direction every X seconds (timestep), and gives it the possibility to be unaccuarte, like overshoot its goal and wobble a little. What my issue is though, is that even though you set timestep very low, it still is a little wobble present. What I would love would be another movement, like the one that is used in the animation plugin, where timestep is just how many times to redraw the animation of it, this makes it 100% accurate all the time, and makes it seem more professional in my oppinion. A second smaller issues I have with the scaler is that I have a feeling that the target point used is a corner and not the center of the window. or perhaps the center of original sized window, because the movement has a tendency to go in a curved line. this is hard to describe, but if you imagine a window attached (in the upper right corner of the window) to a straight line going from the top left to the bottom right, and you scale that window while moving it down. it will go straight when you look at the upper right corner, but curved when you look at the bottom left. If you attacht the window to the line via the center, it will always move straight. :) Hope that explanation was sufficient, and that you see the issues I'm talking about. My general intentions is making the compiz effects look more professional, so it could appeal to wider audiences. Yes, I'm perfectly aware of these issues and they should be fixed. There's some pretty bad code involved with this right now and I want all point-animation code to be replaced with some nice shared code that allow you to select which algorithm to be used for any point-animation. By point-animation a mean an animation that can be expressed as a transition of one or more points. I like to do the same for rectangle-animations as well eventually. - David As I mentioned to you a few days ago I've been thinking about a very similar system for Beryl. I have quite a bit of work on outlines for a system like this with a few ideas that I think would be interesting. Basically I would like to do it with a constraints type system (such as akamaru). Then two setups, one for just creating an animation and stepping it (stepping would return a value in the 0.0f-1.0f range representing position, by position I mean integral of the speed function from 0 to the current time in a 0.0f-1.0f range. Essentially I imagine there would be a few animation types AnimationTypeSpring, AnimationTypeQuadratic, etc and you would create an animation like this with a few other attributes, and it would return an int handle you can use to start/stop/step the animation. Also I would like some sort of other system that automatically handles animation of windows, for things such as movement, attributes, rotation, scaling, etc. With a constraint system it would also be easy to say constrain the rotation vector to the opacity vector to the scaling vectors, and then animate the scaling vectors which would have an overall effect of scaling the window while spinning it and fading it out. It would also be great if there were some way to allow external apps to leverage this library. It's rather hard to articulate what I mean, but I will be posting a more specific outline of the implementation and API on the Beryl mailing list within a day or two, I can post it here or CC you as well. ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
