Posted on 2007-11-03
I just got back from FOSS Camp and the Ubuntu Developer Summit, and that was quite a rush. Technically, I am writing this on Logal Airport in Boston, waiting for my flight to board to go back home.
I am not going to go into details about that was discussed, there was just too much, but I will try to cover what is relevant to Compiz, Compiz Fusion and related software.
Keep in mind that these are not final decisions and that they may be altered. Also, this is written with little or no sleep; I figured it was better to write it when it was fresh and get it out as soon as possible.
Session management, the lack of redirected direct rendering and no input transformation is currently the big issues.
Session management is something we should and could fix inside of Compiz, by re-implementing session management as a plugin. We may need some core hooks, for this, but ideally we should be good. This is just a matter of sitting down and doing it, and doing it right. Travis Watkins (Amaranth) has parts (?) of this sorted, but it definitely needs work.
As for both redirect indirect rendering and input transformation, we (Robert Carr, Mirco ... and myself) had a chat with Kristian Høgsberg about this, and it sounded promising. Kristian Høgsberg has been working on redirected direct rendering for a while (see his blog) and says it should be ready to hit upstream x.org in not too long, which will finally solve a lot of issues.
Input transformation patches for upstream X has existed for a while and in a workable state. It has been somewhat unknown why they haven't been pushed into X.org, but it turns out it is because of broken applications. Applications that grab the mouse will get mouse events relative to the root window, to convert them to be relative to the application window, they often use their own window extens, while they should use the child window provided by the event. In non-transformed mode this doesn't matter, but when input is transformed, it does.
Robert will be re-doing some of the Compiz input transformation patches to get them working, and a significant portion of the Compiz Fusion developers will likely use these and the X.org patches to find problems and fix them in the most significant of the bugged applications. This should help us get the input transformation patches into up-stream X.org
Emerald is a heap of unmaintained and messy code, and we need to do something. My idea is to write a Python-based decorator for rapid prototyping and experimenting. Unfortunately Scott shot down my idea to use this in Ubuntu Hardy Heron because of a memory budget, so what will probably happen is that when the experimenting is finished, we (Robert volunteered to help) will re-implement it in C.
The reason we want to do it in Python first is twofold: First off it is a lot nicer to maintain and it's faster to code in. We also want to test a few different approaches to do this, for instance re-parenting versus the current approach. Such changes are a lot nicer to play with in Python.
As for features, we want a rich themeing support, and we want to be able to have themes that uses GTK and/or KDE themes or colors. This way, we can have a theme that changes with your GTK theme, but looks a lot better than the normal metacity themes.
I have volunteered to do the initial work on the python decorator, but I hope to get some work on the theme editor so it can be at least as flexible as the one that comes with Emerald. We also wish to move away from the concept of theme engines, as we don't want a theme designer to have to pick between different features, but we want them to be able to use all available functionality in any given combination.
We want to basically remove all key bindings, then re-add the ones that are actually needed. Ubuntu will help us map out which we really need, which is a tremendous help. This should hopefully clear up this mess once and for all.
One thing we also wish to do is to be able to display keybindings in a coherent way for the entire desktop. This is currently impossible in ccsm, which shouldn't be too hard to fix, but we want it for the entire desktop environment too.
We have thought about several ways of improving this situation, we discussed using a menu for the window manager to expose more of the functionality in an intuitive manner, but there was some disagreement about this. We will at the very least have improved hotcorner logic, by adding support for a modifier and possibly delayed hot corners.
Robert Carr, Michael Vogt and myself went over simple-ccsm and evaluated the need from a user perspective and came up with some significant changes that are necessary.
First of all, the idea of a slider between profiles is just not good. It switches around too much functionality and the star-system just doesn't improve the situation.
We will either change simple-ccsm or just create a new one from scratch that will have a front page giving you control over your hot corners and the desktop style (cube or wall) on the front page.
Under an animations tab it will have the ability to set open, close and minimize animations (like simple-ccsm) and which switcher application the user wants.
We will remove the accessibility tab and replace it with one just for zoom (or move zoom to an other page), and then move the configuration of the color filter to the accessibility menu on the main menu.
We will most likely also have a link to ccsm, and ccsm will be enhanced. CCSM has never been meant to be an end-user tool, but I don't think there is any point in pretending it hasn't become one for advanced users. We can improve it by chumping certain type of options together in addition to where they are now: Performance-related options and keybindings is what first comes to mind.
The whole settings discussion was fairly brief, so nothing is written in stone. I know this is a subject we will definitley discuss on the compiz fusion development list or other places related to Compiz Fusion Development.
Compiz Manager is an on-going discussion. I never got that much time to discuss it during UDS, but I spoke with Jiggish about it recently and he showed me what SuSE is doing.
I also believe that splitting it up so the actual checks and the execution-logic is seperate. This makes it easy for distributions to use the same checks but different logic in whether they want to use XGL or not, or maybe a fallback wm.
I still think this idea needs some thinking through. It is my goal that every GNU/Linux distribution shipping compiz can use compiz-manager, and thereby giving the user the same basic experience on all distros, and avoiding unnecesarry code duplication. If you are a distribution packager and have a problem with compiz-manager, however small, I want to hear about it. It is also my goal that tools like fusion-icon will use compiz-manager.
We are not aming for anything huge in Hardy, since we would rather want a properly tested experience than extra bling. There still are decent ideas though.
I myself wrote a small "maximumize" plugin, which resizes a window to take up as much of the available screenspace as possible without overlapping with other windows. It's nothing fancy, but I think it can come in handy.
Robert wants to write a menu plugin as mentioned before. He also wanted a plugin that grabs hotcorners + modifier and configures them "on-the-fly": If a user uses ctrl+upper right for instance, he will get a menu asking whether he wants it to do something and that will be saved. Ask Robert for details.
We are all curious about Compiz 0.7. We know there will be major changes, as large chunks of core code is being re-written to a object-based system.
One of the hoped for results is the ability to use XRender output instead of OpenGL when OpenGL is not available, thus limiting the need for fallback window managers.
While I've worked a lot on Beryl multihead and a decent amount of Compiz multihead issues, one think I believe we need is testing of XRandr setups and situations. Specially with regards to dynamic changes. I have a very poor grasp on the state we are in here, but I suspect there is work to be done.
We are also limited by hardware, driver and X.org infrastructure limitations. It is impossible to use XRandr over multiple video cards, and what we really want is to be able to even accelerate this.
This is being worked on in upstream X.org though, and withthe new DRI and memory manager comming to X.org, this is exciting. Unfortunantly, this is highly unlikely to make it in time for Ubuntu Hardy Heron.
The last point on my list is "Scott's scale binding annoyance". I will leave out the details. It should be fixed.
I also remember two issues brought up that we actually have been aware of or some time, but that we need to properly adress: - XScreensaver + unredirect fullscreen windows can accidently remove the display grab that XScreensaver has. - New tabs in gnome-terminal don't show up until you click on them, easier to see (with my setup) by going back and forth between fullscreen and maximized.
As for social events, it was just a great event all together, and I hope I will be able to participate again in 6 months. There were a ton of people to meet and greet. I couldn't have asked for a better way to spend 7 days. Well, almost.