SSIA. Planet.compiz-fusion.org should still follow compiz-stuff. I’ll still be writing about Compiz, but other stuff too, so go visit http://kristian.blog.linpro.no (err, I work at Redpill Linpro…).
Expect a several interesting/relevant Compiz-posts in the near future. Just waiting for stuff to go public.
I’ve started my bachelor final year project last week with Christian Frøseth and Eirik Askheim, and we’ll be working on visual improvements in the Totem media player.
Our main focus will be the full screen ui, redesigning it with Cairo/Composite effects.
Given this context, I’m very much looking for input and ideas on how to design a full screen user interface. We have some ideas our self obviously, but maybe you have something that has been bothering you with Totem, or something you feel is missing. Or something you think Totem does better than any other player, when it comes to the UI.
This is your chance to really influence our work for the coming months, and the Totem media player, so grab a pen and start drawing (or just write a comment.)
The maximumize plugin was invented during the ubuntu developer summit, and is incredibly simple at the moment.
All it does is resize a window so it fits the largest available space it’s in. That is, if you have two terminals, maximumizing both will fill screen. This is convenient for using all of your screen real estate.
However, the plugin is not properly finished, and not suitable for a release right now. It ended up in the shadow of school work and other projects, and now behind shelf too. However, it is not forgotten.
It currently does the basic maximumizing, but that’s all it does, and it’s not extremely smart about it.
I’ve been talking with Gavintlgold and Fyda on IRC (and the forums) about it the last few days, and we’ve come up with a few ideas, some which were already planned.
First of all, it needs an animation, and there are a few ways of doing this. Second, it needs to be smarter about which windows to ignore and not, this is easily achieved through the window matching interface. It also needs the ability to deal with overlapping windows. Right now, it has a little bit of tolerance, but not much (40px).
The basic algorithm for expanding the window is also incredibly stupid, it would serve as a perfect text book example of a completely un-optimized algorithm which could easily be improved in steps. All it does is increase the window size by 1 pixel at a time, which means you’ll iterate a lot in most cases. This could be improved in different ways, and doing so would allow the plugin do use this function more frequently, thus allowing it to also have a mode that moves the window to the location with the biggest free area.
Allowing the window to actually shrink might also make sense, that’s a quick hack in any event.
I intend to do all of this when I’m finished with Shelf, but I welcome input and ideas. As for a date, I expect I’ll finish the majority of shelf during Christmas. However, I do have another significant project planned which might take precedence.
I’ve been working on a new Compiz Fusion plugin currently known as Shelf (it was named miniwin2 for a brief period, more on this further down). This is a fairly straight forward idea, and I’m doing this as a bounty for Canonical.
What it does is simple: It visually scales a window down in size. Unlike resizing, this keeps the content of the window as-is, and just makes it seem all together smaller.
At the current time, the plugin is in an alpha-phase. It does the job of scaling quite well and it also masks out input. It hasn’t got an animation yet, nor is it very flexible. There are three preset scale factors: 1.0 (normal size), 0.5 (half size) and 0.25 (quarter size), and you cycle through them, default binding is currently super+l, though that seems to be taken.
It can deal with being moved naturally (in fact, it doesn’t even have to deal with it, it happens all by it self), it can take keyboard input, and it seems to generally work well.
What it lacks is an animation, more intelligence behind the interaction, input-handling of the mouse (currently you actually click the upper left corner of the window when you click a scaled down window, this will be changed), and general tweaking.
The name is courtesy of Gavintlgold who made a forum post recently about this basic idea. This isn’t a new idea, however. There was a supposedly problem-ridden “miniwin” plugin back in the old days before Beryl (and before compiz fusion of course), that did this. We’ve had to deal with input masking and such in other plugins by now, so we’ve been getting better at handling these sort of plugins. Danny Baumann pointed me in the right direction, as he’ve worked with the Shape extension for the group plugin.
It’s been somewhat quiet from the Compiz and Compiz Fusion front lately, relatively speaking, and there’s a reason for that.
A while back, David Reveman started working on what is known as the “object framework” for Compiz, which represent the single biggest do-over that Compiz has had since it’s inception. To quote David [1]: ” If we ever hadreleased a 1.0, this would definitely qualify for a 2.0.”.
During the last few days, David has also posted a few documents [2][3][4] about the reasoning behind and plans ahead for these major changes. To make a long story short: We are in for a major re-design of the core which will (hopefully) give us a more robust, flexible and maintainable core.
What this means for the user is that there will be little new flashy stuff for a while. We will need time to adjust for these changes when the object framework is eventually merged with the master branch. Until that is done, there will be no significant core changes.
This, in turn, means that things such as input transformation/redirection will be delayed. However, this is somewhat good news. Not that it is delayed, but these core changes will allow for a cleaner implementation of important features like that.
One of the great things this will lead to is the ability to have Compiz running without OpenGL support, as a standard window manager. This will allow Compiz to run regardless of your hardware, which will give a more consistent feel, since the “fallback” wm and main wm is the same.
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:
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.
I just got back from the GNOME Boston Summit, and spent quite a few hours traveling with my laptop at hand. This brings up the question whether Compiz Fusion is suited to be run on a laptop on battery power or not.
My current laptop is a HP Compaq NC4010, with an ATI Radeon IGP video card (IGP means no discrete video memory, among other things). Due to the age of this card, it is necessary to run X in 16 bit color depth to get fluent animations, which is something I recommend everyone with slightly older cards do.
As for battery usage, there are two concerns; Whether just having Compiz running, doing nothing, enables features on the video card that draws more power, and whether what Compiz and the general Composite environment it self causes more wakeups and thus higher power consumption. For the first question I don’t have any real answer, I would assume this varies from card to card. The second is fairly easy to answer though, with the help of Powertop. It seems to me that compiz in general doesn’t really cause much extra power consumption. Ironically, the feature in Compiz Fusion that causes the most wakeups is the mouse polling in eZoom, so when I’m traveling I set the mouse poll intervall to 500, which results in far fewer wake ups, but also in an almost unusable mouse which only updates twice a second. For me, that’s not an issue because I don’t use the mouse that much while on the road.
I’m currently at day two of the GNOME Boston summit, and I spent time yesterday discussing and pushing some of my orca hacks off to Joanmarie who’re going to fix them up and get Orca talking to eZoom.
We talked about creating a new API for general accessibility functionality to complement AT-SPI, for instance with regards to what Orca is actually doing, but decided somewhat against it as it is not really necessary. The existing D-Bus interface that eZoom offers will likely be refined to cover the needs that we discover during the implementation of eZoom-control in Orca.
The support for a cross hair for the mouse cursor was also requested, and I agreed to look into implementing it inside of eZoom, even though it could be done as a separate plugin. The reason I’m considering this is twofold: First; if you are using the cross hair you are almost certainly using eZoom too. Second; Due to the mouse code in eZoom, it is difficult and hacky at best to figure out where the zoomed cursor is.
Since I already had a patch for Orca and a reasonably sane D-Bus interface in eZoom, these discussions left me with little specific to do here in Boston since we decided to go with what we have instead of creating something new, but I assume I’ll be put to work when we all catch up, as I’ve been promised several(?) RFE’s, which is a good thing.
I recently participated in a Compiz Fusion development sprint in London to make sure Compiz Fusion is a smooth experience in Ubuntu Gutsy Gibbon, to be released this month, with Compiz Fusion by default.
We fixed some very specific issues, and generally smoothed things over. The wrapper script that is now used in Gutsy is a piece of code that started as my own code but has switched a lot of hands, but is now back under the Compiz Fusion name. It was originally intended to be used by distributions as well as users choosing to install Compiz Fusion from source, as such it has always been important for me to adapt it to the needs of distributions.
I recently installed Gutsy on two laptops, and was unlucky enough with the hardware to experience the issues we have to deal with: Hardware and driver issues. The first problem I ran into was on an evo N410C with an Ati Radeon 16MB DDR card. The problem was that the wrapper script’s tests to determine if compiz will run or not succeeded, but compiz still crashed claiming lack of FBConfig. After some experimenting I determined that the card/driver is simply confused. At a colour depth of 24 (Default), glxinfo will claim the card supports 1024 wide textures, which it seems it doesn’t. At Colour Depth 16, however, it will claim to only support 512 wide textures, so the wrapper scripts doesn’t attempt to start Compiz, however it really does support 1024 wide textures.
Since these tests are very important for both old and very new hardware, it’s a bit of a problem that they fail like this. However, it’s not easy to solve either. Not in a script anyway.
On the performance note, the card did very while running 16bit color depth. The relevant specs for the machine would be a 1.2GHz Pentium 3 with 256MB of memory. I won’t claim that openoffice and firefox is quick to boot up, but it’s absolutely usable.
The other laptop I got a hold of is a HP Compaq nc4010, considerably faster (1.8GHz Pentium M/ 1GB ram), but with an ATI Radeon IGP card. This card doesn’t have any discrete video ram, and I’ve also had some issues with it in the past on other hardware. The card was not really able to run smoothly at 24 bit colour depth, and the texture size limit seemed to be 1024 which made it far to easy to get solid white decorations when a window was maximized (due to the textures being bigger than the screen resolution of 1024×768… a bit annoying since it’s going white on behalf of image data that is off screen.).
However, at 16 bit colour depth, it was, not surprisingly, very smooth.
It seems to me that the bigger problem is that this setup doesn’t actually provide working xv output, leaving me without accelerated video. For me personally this isn’t a huge issue; I’m using mplayer’s -vo x11 combined with eZoom to watch videos, but in genera this is a bit of a major issue.
Cards like this is getting blacklisted in the compiz-manager script, though such a list is easy to override. The idea being that it’s better for people to end up with metacity working perfectly than Compiz working without proper video support.
I am very excited about Compiz Fusion being enabled by default, and a little nervous. I am not entirely convinced we’re ready for it, due to issues like what I described above. But this certainly pushes the work forward, and I believe that the people who’s hardware is able to run Compiz Fusion will enjoy it under Gutsy. The people working on the Ubuntu packages have done a good job smoothing over issues with somewhat overly optimistic configuration defaults and bugs without appropriate upstream fixes.
Summer of code is over, and by and large, things are working. I’ve gotten some text-caret stuff working through python, but on the POC level, and this would be the only missing part of my project, which I personally believe have exceeded the original goal in other areas. We WILL have text-caret tracking.
But, this post is about XFixes.
With Ezoom, there is an option to hide the original mouse pointer, and this is done through XFixes, and it triggers a bugged behavior. Basically, animated cursors will be reported as having width==height==1, and they’ll be invisible. What is worse, they will even be invisible after you unhide the cursor.
However, you need this for some of the best tricks ezoom can pull off. I consider the bug worth it in my daily use, because I use default cursors, so the only animated cursor I have, is the Firefox “page loading” one.
I recently applied a tiny patch that somewhat helps, it’s so simple, you can probably understand it with zero C knowledge, this is inside the “zoomUpdateCursor” function which is called when XFixes tells us a cursor change occurred, and we try to fetch the new one:
+ if (ci->width height
This means that if the new cursor has a width and height equal to or less than 1, we ignore it. Simple ass that. The result is that, when you are zoomed in and the cursor would otherwise go invisible, you won't see a change at all. It's a bit awkward, it's an ugly workaround, but it's so simple and I figure that it's better to have this than have no cursor at all.
The animated cursors will still be invisible when ezoom is NOT zoomed in, however, because X draws the pointer, not compiz, when we're not zoomed in.
I am interested in any feedback on the result of this hack, drawbacks you experience, success stories, anything.
Powered by WordPress