Kristian’s look on things

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.

[1] re-architecting compiz

[2] object framework design

[3] object framework design, part I: OBJECT MODEL

[4] object framework design, part II: COMMUNICATION