Porting plugins from Beryl HOWTO

[mikedee]

I thought I would write a quick post to explain the differences as far as a plugin developer is concerned. These are the problems that I have fixed to get all of the plugins working. There are other differences which I do not know about.

The header file

Starting with the easy and obvious, change the header file from beryl.h to compiz.h.

vTable differences

The vTable is different in a few minor ways. Beryl's vTable is bigger and has the version done in a different way. To change from Beryl to Compiz, do this.

Remove the last 6 entries, thats everything from BERYL_ABI_INFO down.

Remove the 16th entry, it should be labeled updateLibraryFunction and will probably be 0.

Add a function called <plugin_name>GetVersion (just copy from a Compiz plugin and change the name). Then add this after the long description.

Action differences

There are 2 related changes to the actions which need to be changed before they will work.

Firstly, in Beryl there is no keycode member of the CompAction, instead there is keysym. This means that the function used to get this is slightly different to Compiz.

In Beryl

o->value.action.key.keysym = XStringToKeysym (PLUGIN_OPTION_KEY_DEFAULT);

In Compiz

o->value.action.key.keycode = XKeysymToKeycode (display, XStringToKeysym (PLUGIN_OPTION_KEY_DEFAULT));

Just change the keysym to keycode and add the XKeysymToKeycode function.

Secondly, now you have added that function which takes display, you must re-add the Display *display parameter to the <plugin_name>Display/ScreenInitOptions function. Then you need to find all occurances of that function and add the extra parameter where it is called. NOTE: This is a Display not a CompDisplay. The Display is a held in the display member of the CompDisplay.

Option changes

Each beryl option now has 4 extra members for their settings system. They are advanced, group, subGroup and displayHints. They look like this.

o->advanced =False;
o->group = N_("");
o->subGroup = N_("");
o->displayHints = "";

Just delete then, they are no use to us.

pointerX/Y

For some reason, in Beryl the pointerX and pointerY are stored as members of CompDisplay rather than being global. Just remove the d-> from any references to d->pointerX.

PAINT_SCREEN_ORDER_BACK_TO_FRONT_MASK

As far as I know this is exactly the same as PAINT_SCREEN_WITH_TRANSFORMED_WINDOWS_MASK, all the plugins seem to work the same way with it replaced with this.

See this post for more info. http://lists.freedesktop.org/archives/compiz/2006-December/000989.html


This is 99% of the changes that are required for most of the plugins. The rest of the work that I have done has been fixing bugs which somehow work in Beryl but fail in Compiz. I know for sure of 1 bug in Beryl which allows plugin developers to write sloppy code. There seem to be a few others too.

If the plugin has functions like getBaseAddWindowGeometry, then it is a workaround for when windows are wobbling. This has been replaced in compiz, you can either remove them, or rewrite the function so that it uses addWindowGeometry as a callback.

[maniac]

I know for sure of 1 bug in Beryl which allows plugin developers to write sloppy code. There seem to be a few others too.
Could you please shed a bit of light on this? Just mentioning that there are bugs doesn't help in fixing them ;)

[mikedee]

I know for sure of 1 bug in Beryl which allows plugin developers to write sloppy code. There seem to be a few others too.
Could you please shed a bit of light on this? Just mentioning that there are bugs doesn't help in fixing them ;)

Since you are new around here I will go easy on you :D

I think you must have missed my posts on my thoughts of the Beryl project. I would recommend reading the thread entitled 'Beryl makes me sad'. I am now much happier and more productive on this forum, so I am not really going to go into the reasons here.

If you are still having trouble working out why I am not being cooperative, come back and I will give you a less subtle response ;) Put it this way though, I am not interested in helping fix self-inflicted bugs in beryl.

[maniac]

I think you must have missed my posts on my thoughts of the Beryl project. I would recommend reading the thread entitled 'Beryl makes me sad'. I am now much happier and more productive on this forum, so I am not really going to go into the reasons here.

No, I didn't miss your post as I already read that topic. It's perfectly ok that you have your own opinion about the Beryl project, so I don't want to discuss that here.
But...


If you are still having trouble working out why I am not being cooperative, come back and I will give you a less subtle response ;)

Sorry, I don't get that. Perhaps your answer was too subtle for me :?


Put it this way though, I am not interested in helping fix self-inflicted bugs in beryl.
I do not completely understand that. Nobody expects you to help in fixing bugs, but just stating there is a bug without mentioning a rough idea how the bug could look like (which is way different from emntioning how it can be fixed) is a bit implausible to me :(

[iznogood]

Ok, it seems that the flamewar has migrated here.

I want to ask everyone (politely) to stop!!!!!

This includes mikedee.Comments about beryl's code is not productive.
I respect what you do for compiz but we don't need that, especially now.We try to make a new community and this kind of response is making the whole effort looks bad, so please everyone, STOP IT NOW.

The flamewars have stopped at beryl forum, don't bring it back here
(RYX: i would like some help here pls)

[RYX]

First: Everybody calm down please ... I think my "job" as a moderator requires to intervent here.

@mikedee: Thank you for the interesting and helpful tutorial. It is great that you do these things and I thank you for that (and everyone else does, too). As far as i can see you misunderstood the intention behind maniac's question. I think he only wanted to know about the bugs you fixed to make plugins work in compiz, so there is no reason to point him to the "flamewar-thread". Please react a little bit less upset on that topic, ok? Maybe you can briefly explain which bugs you were talking about, since apparently they affect compiz, too (so they are worth notifying).

@maniac: Welcome to the forums. Nice to see you here.

@iznogood: Thanks for interventing and calling for politeness, that's very kind. You're right in what you said and I can only agree.


And now: peace, please ...

:)

[mikedee]

Yeah, sorry... :oops:

The problem is related to a random damageScreen somewhere, I have no idea where it is.

Some of the plugins needed an extra damage screen to work properly, although the damage should be restricted to just what is needed. The problem is that there is a lot of use of damageScreen when really it should be just damaging the needed region. This is all as far as I know and I am not the expert (we all know who that is).

This is not a flame, more of constructive criticism. If you do not have any experts who can vet the code, then there will be many problems like this happening in the future.

[mikedee]

maniac, one of the bugs you fixed yourself, here is your comment.

r1122 | maniac | 2006-11-10 16:15:52 +0000 (Fri, 10 Nov 2006) | 4 lines

showdesktop plugin:
- fixed wrong allocated memory size and thus some crash potential (WTF? Why did this ever work?)
- some small cleanup

Without proper guidance/QA before things like this are checked in, you will be relegated to fixing these bugs all day (as you appear to be doing based on the logs). I see this is as a huge waste of resources which is why I am not supportive.

If anyone has any idea why that code would work I would love to hear. Hopefully for you guys it is not a deep subtle bug introduced in Beryl.

Anyway, this place is for learning how to write new plugins, not fixing others so Ill stop now and get onto something more productive.

[maniac]

@maniac: Welcome to the forums. Nice to see you here.
Thanks :)

Yeah, sorry... :oops:

The problem is related to a random damageScreen somewhere, I have no idea where it is.

Some of the plugins needed an extra damage screen to work properly, although the damage should be restricted to just what is needed. The problem is that there is a lot of use of damageScreen when really it should be just damaging the needed region. This is all as far as I know and I am not the expert (we all know who that is).

Interesting. This answer sounds much better. The question is if it is in beryl-core or -plugins, but this is not a question you have to answer.


This is not a flame, more of constructive criticism. If you do not have any experts who can vet the code, then there will be many problems like this happening in the future.
We have experts, just not enough ;)


Without proper guidance/QA before things like this are checked in, you will be relegated to fixing these bugs all day (as you appear to be doing based on the logs). I see this is as a huge waste of resources which is why I am not supportive.

The problem is the following: While the bug is pretty obvious, it was hidden most of the time (due to the fact that the ShowdesktopPlacer struct isn't that big, it was allocated +32 times and most of the times there aren't that much windows in one viewport)...that's why it isn't a testing issue alone. And I don't believe nominating a committee which validates each commit is a good idea, at least for the development model Beryl has (from my understanding).


If anyone has any idea why that code would work I would love to hear. Hopefully for you guys it is not a deep subtle bug introduced in Beryl.

Which code? The showdesktop one (this should be already explained) or the damageScreen() one (here I guess it's related to plugins calling damageScreen more often than neccessary and/or than called in compiz).

[Sorcerer]

OK, I applied the howto to snow plugin but now I get this:
$ make
compiling : snow.c -> build/libsnow.losnow.c: In function 'snowPaintScreen':
snow.c:207: error: 'PAINT_SCREEN_ORDER_BACK_TO_FRONT_MASK' undeclared (first use in this function)
snow.c:207: error: (Each undeclared identifier is reported only once
snow.c:207: error: for each function it appears in.)
snow.c: In function 'snowDisplayInitOptions':
snow.c:442: error: 'CompOption' has no member named 'group'
snow.c:443: error: 'CompOption' has no member named 'subGroup'
snow.c:444: error: 'CompOption' has no member named 'displayHints'
snow.c:455: error: 'CompOption' has no member named 'group'
snow.c:456: error: 'CompOption' has no member named 'subGroup'
snow.c:457: error: 'CompOption' has no member named 'displayHints'
snow.c:468: error: 'CompOption' has no member named 'group'
snow.c:469: error: 'CompOption' has no member named 'subGroup'
snow.c:470: error: 'CompOption' has no member named 'displayHints'
snow.c:481: error: 'CompOption' has no member named 'group'
snow.c:482: error: 'CompOption' has no member named 'subGroup'
snow.c:483: error: 'CompOption' has no member named 'displayHints'
snow.c:494: error: 'CompOption' has no member named 'group'
snow.c:495: error: 'CompOption' has no member named 'subGroup'
snow.c:496: error: 'CompOption' has no member named 'displayHints'
snow.c:507: error: 'CompOption' has no member named 'group'
snow.c:508: error: 'CompOption' has no member named 'subGroup'
snow.c:509: error: 'CompOption' has no member named 'displayHints'
snow.c:520: error: 'CompOption' has no member named 'group'
snow.c:521: error: 'CompOption' has no member named 'subGroup'
snow.c:522: error: 'CompOption' has no member named 'displayHints'
snow.c: At top level:
snow.c:606: warning: initialization from incompatible pointer type
snow.c:607: warning: initialization from incompatible pointer type
snow.c:608: warning: initialization from incompatible pointer type
snow.c:609: warning: initialization from incompatible pointer type
snow.c:610: warning: initialization from incompatible pointer type
snow.c:611: warning: initialization from incompatible pointer type
snow.c:614: warning: initialization from incompatible pointer type
snow.c:615: warning: initialization from incompatible pointer type
make: *** [build/libsnow.lo] Error 1

when compiling. This error also happens to Beryl users without the latest svn. Maybe there are some changes in Beryl's svn that should also be added in this Howto.

[mikedee]

There are a couple of new changes to beryl which need to be removed now.

Firstly, there are 3 new members for each option. They are group, subGroup and displayHints, just remove them as they are not necessary.

There are also a couple of new paint masks so that it can paint only on the desktop window. This is where the PAINT_SCREEN_ORDER_BACK_TO_FRONT_MASK comes from. I personally do not think this is the right way to acheive this, plus they have some code which damages each window individually on each screen paint. This makes it really really slow. I am sure there is a 'correct' way to just paint the desktop window.

I have had a look at snow and changed it slightly so that it snows over the top of the screen, personally I think its a better effect plus it runs at full speed, rather than killing everything off (animation was bad).

Here is my current version which loads and runs with compiz. The problem I have is that it is not loading the png file correctly. If I delete the file then it snows with white squares, but if the image file is there then nothing shows.

http://www.anykeysoftware.co.uk/compiz/plugins/snow.tar.gz

[Sorcerer]

Thanks, mikedee. It almost works. The plugin loads (even the png files), and it starts snowing :D, but then my whole screen freezes. I cant see animations and cube rotation anymore and screen isn't updated anymore.

[mikedee]

Sorry, forgot to mention... Load before cube or it messes with it!

I turned animation off, but loading it before that may help too

[Sorcerer]

Thank you, loading it before cube helps, but it still freezes with animation on.

[pichalsi]

Try changing

glTexCoord2f (0, 0);
glVertex3f (hs->allSnowFlakes[i][0], hs->allSnowFlakes[i][1], hs->allSnowFlakes[i][2]);

glTexCoord2f (0, hs->snowTextureSize[1]);
glVertex3f (hs->allSnowFlakes[i][0], hs->allSnowFlakes[i][1] + snowSize, hs->allSnowFlakes[i][2]);

glTexCoord2f (hs->snowTextureSize[0], hs->snowTextureSize[1]);
glVertex3f (hs->allSnowFlakes[i][0] + snowSize, hs->allSnowFlakes[i][1] + snowSize, hs->allSnowFlakes[i][2]);

glTexCoord2f (hs->snowTextureSize[0], 0);
glVertex3f (hs->allSnowFlakes[i][0] + snowSize, hs->allSnowFlakes[i][1], hs->allSnowFlakes[i][2]);

to

glTexCoord2f (0, 0);
glVertex3f (hs->allSnowFlakes[i][0], hs->allSnowFlakes[i][1], hs->allSnowFlakes[i][2]);

glTexCoord2f (0, 1);
glVertex3f (hs->allSnowFlakes[i][0], hs->allSnowFlakes[i][1] + snowSize, hs->allSnowFlakes[i][2]);

glTexCoord2f (1, 1);
glVertex3f (hs->allSnowFlakes[i][0] + snowSize, hs->allSnowFlakes[i][1] + snowSize, hs->allSnowFlakes[i][2]);

glTexCoord2f (1, 0);
glVertex3f (hs->allSnowFlakes[i][0] + snowSize, hs->allSnowFlakes[i][1], hs->allSnowFlakes[i][2]);


this helped in beryl, i changed it there to this and it worked (at least on my nvidia card and a few other people reported it working without high cpu load), however author of the plugin fixed it in some other way around which i dont understand, if you want look at it in svn http://bugs.beryl-project.org/browser/branches/beryl-plugins-with-snow

[stjepan]

And how to port beryl-type config to gconf schemas?

[mikedee]

The gconf schema can be dumped out once the plugin is loaded using the gconf-dump plugin. See the gconf-dump.c source for info on how to do that.

[Storm]

I'm a little bit confused.
I can't find the gconf-dump plugin.
Only an old one from the beryl-svn, but I don't want
to port it to compiz.

Maybe you can post a link?

[mikedee]

The gconf-dump plugin is part of the standard compiz distribution.

You need to enable it at compile time with --enable-gconf-dump in the configure line.

[bijoux]

hey mike,
do the changes in core affect this how-to? if yes, could you please update it? really like to try porting a few beryl plugins

[mikedee]

Hi,

I am not sure what changes to core you mean, there have been changes on both sides which I have not updated yet. In my experience each plugin brings its own specific core functions.

Which plugin were you interested in porting? I think these instructions should be enough but if you have troubles then post here and I will try to help.

[bijoux]

Hi,

I am not sure what changes to core you mean, there have been changes on both sides which I have not updated yet. In my experience each plugin brings its own specific core functions.

Which plugin were you interested in porting? I think these instructions should be enough but if you have troubles then post here and I will try to help.

i saw a plugin last time i was at the beryl forums called desktopclick. dont really know the specifics. basically its a plugin which gives you a configurable menu when you left click the desktop (a la fluxbox) in gnome. ill give it a shot. hopefully i can get it to work without hassle. i could really use that feature. btw, thanks for this how to

[mikedee]

You should be alright with that one. The only thing I can think that it would have is the windowOnlyOnDesktop function (or something like thta) - you can copy it straight from beryl core and put it into tyhe plugin. Everything else should be standard.

[mikedee]

I have just updated the original post slightly.

I have also ported the desktop click plugin, Ill post that on another thread.