Elements changes for today and the future

Remember the last time I said elements was ported? Well, turns out I lied. It only compiled and loaded, then I went off to study for exams, totally forgot about it and in reality it was really really broken. I had to spend about 3 days fixing it.

Anyways, obligatory screenshot

Fireflies and OSD
Fireflies and OSD

One of the key changes is that all the internal elements have been removed completely. So what, you say, we’re back to separate plugins?

Well, yes and no – we are using the new buildsystem to integrate the build process between elements and its sub-plugins. This was done using the new CMake buildsystem and was implemented in just a few lines of code.

The other key difference is that all the main code has stayed pretty much the same and it has been rethought with C++ to use polymorphism and other cool object oriented concepts. This means that instead of having 6 huge 1000 line plugins, we now have one 1500 line plugin, and each sub-plugin comes in at just under 100 lines. They are really really simple and look something like this:

#include "stars.h"

COMPIZ_PLUGIN_20090315 (stars, StarPluginVTable);

StarElement::StarElement ()
{
}

StarElement::~StarElement ()
{
}

static float
starBezierCurve (float p,
 float time)
{
 float out;

 out = p * (time + 0.01) * 10;

 return out;
}

Element *
StarElement::create ()
{
 Element *e = (Element *) new StarElement;

 return e;
}

bool
StarElement::init ()
{
 float init;
 StarScreen *ss = StarScreen::get (screen);

 ELEMENTS_SCREEN (screen);

 dx = es->mmRand (-50000, 50000, 5000);
 dy = es->mmRand (-50000, 50000, 5000);
 dz = es->mmRand (000, 200, 2000);
 x = screen->width () / 2 + ss->optionGetStarOffsetX (); /* X Offset */
 y = screen->height () / 2 + ss->optionGetStarOffsetY (); /* Y Offset */
 z = es->mmRand (000, 0.1, 5000);
 init = es->mmRand (0,100, 1);

 x += init * dx;
 y += init * dy;

 return true;

}

void
StarElement::move ()
{
 ELEMENTS_SCREEN (screen);

 int updateDelay = es->updateDelay ();

 float xs, ys, zs;
 float starsSpeed = anim->speed () / 500.0f;
 float tmp = 1.0f / (100.0f - starsSpeed);

 xs = starBezierCurve(dx, tmp);
 ys = starBezierCurve(dy, tmp);
 zs = starBezierCurve(dz, tmp);

 x += xs * updateDelay * starsSpeed;
 y += ys * updateDelay * starsSpeed;
 z += zs * updateDelay * starsSpeed;
}

StarScreen::StarScreen (CompScreen *screen) :
 PluginClassHandler <StarScreen, CompScreen> (screen)
{
 type =  ElementType::create ("stars", "Stars", StarElement::create);
}

StarScreen::~StarScreen ()
{
 type->destroy ();
}

void
StarElement::fini ()
{
}

bool
StarPluginVTable::init ()
{
 if (!CompPlugin::checkPluginABI ("elements", COMPIZ_ELEMENTS_ABI))
 return false;

 return true;
}

This means that it should be easy to add new elements to the mix and have them integrate seamlessly with the whole plugin. the entire process is transparent – we just use virtual functions and function overrides to handle everything.

Later this week I will comitt a change that will permit you to toggle each element using separate keybindings, I am currently working that out now. This gives you the ‘old’ behaviour of the old plugins and elements plugin. You will still need to define the element in the list however (even though all the ones that ship with the plugin are in the list by default now).

The Future

Ideally however, I’d like to take elements out of compiz completely and make it into it’s own separate application. It doesn’t make sense for a window manager to be drawing random things on screen – the only reason that we did was because we get an alpha channel for free when drawing in Compiz GL context. However, with DRI2 for almost every major piece of hardware, we now have redirected direct rendering, which makes OpenGL applications with an alpha channel in a compositor a viable alternative. It also makes things like drawing under windows a lot neater. However it does mean that we will not be able to have elements ‘coming off’ the cube anymore.

Taking elements out of compiz will give me an easy way to use it with other compositing window managers like mutter, kwin, xfwm etc, it allows us to work around some of the problems the compiz options system poses to it and it also removes another area where compiz could malfunction and crash (especially with element’s plugin system).

Cube Addons

Cube Addons (i.e reflection, cylinder and sphere) were also ported last week, if you’re on 0.9 and want to check them out

0.9 Release Plan?

Considering that there is only the group, animationaddon, stackswitch, 3d, atlantis and dbus remaining to port, I would hope that we can get a 0.9.0 out before $FESTIVE_HOLIDAY. I’ll be running through some of the other improvements that come with the new architecture before the release. My free time will increase *a lot* after Dec 4.

edit: removed debug message ….

5 thoughts on “Elements changes for today and the future

  1. 1) Hey, good to know it’s getting closer and closer to 0.9 release 😉 After Dec 4, try not to forget about the wobblines I moaned about 😉 (remember the forum topic?)

    2) Offtopic: How did you remove the “File, Edit, View etc…” bar from Firefox?

  2. I think this plugin make sense only as efect drawer (frame work) for other plugins. So for exmaple some moustrail plugin should be able to draw varios efects for clicks and movement, without itself implementation. The particles will be hanled in one plugin which can also implement some interactions for them… Also you will be able change level of detail in one place – in efect plugin. Also there should be more effects not only particles …

  3. Doesn’t the elements plugin allow sprites to travel in front or behind the application windows?

    I haven’t used compiz since beryl merged, but I remember a snow plugin in beryl that had this feature, and I assume elements carries this feature.

    If so, as an application the elements system will be restricted by the window stack unless the window manager provides an interface to allow sprites to travel behind or below other application windows.

    I realize this feature is not essential in an elements plugin, and if I’m mistaken, then disregard this comment.

    However, as a programmer I find that one of my biggest disappoints in trying to implement an idea is that the underlying system lacks any means for my program to function as desired. I just wanted to identify one possible aspect of elements that may be lost when moved to an application in the hopes that you will reconsider. We may not have a suitable idea for productively using elements, but that doesn’t mean someone down the road may not find it.

  4. I’m new to C++, but wouldn’t it be a good idea to make a FallingElement class, which would have the shared logic for SnowflakeElement, StarElement, FireflyElement etc.?

Leave a reply to peeepan Cancel reply