What's up with compiz-sharp?

[RYX]

I just "re-discovered" compiz-sharp (http://www.ndesk.org/CompizSharp) which was developed about 4 months ago as a Google SOC 2006 project. I know that David would like to see it going into official compiz (he said that on the list) but it hasn't been actively developed for a while ...

Is anyone interested in picking it up and developing it further? Or does anyone know of a reason why it isn't maintained anymore?

I think creating compiz-plugins in C# would put compiz a HUGE step forward because it is (nearly) as powerful as C but much less complicated to code ... and the base is already there ...

:)

[mikedee]

I think that in order for the compiz-sharp bindings to be maintained we would need to have at least 1 good c# plugin.

So far nobody has written one but as far as I know they will work with very small modifications. As far as I know the binding part is actually done, its just waiting for a plugin to be written.

Have you tried to get it to work without success? I am sure its just a small change required to work with current compiz. There was some discussion of it recently on the mailing list.

[stjepan]

because it is (nearly) as powerful as C but much less complicated to code ... and the base is already there ...
I don't agree, C# isn't really that powerful and it is even more complicated, just like C++ is. C# is just easier to use for beginners, just like WIndows is easier than Linux (but complicated) and Ubuntu easier than Crux, Slackware or Archlinux (but complicated).
I prefer C over C++ because of simplicity. There aren't so many keywords, everything is much simpler, no streams, no exceptions, no weird stuff with inheritance.

[PaK]

I agree with stjepan. Even if we have c# bindings for compiz, does we still have easy way to access opengl ? Even if we could have c# and opengl# what it will give for developers ? Do you thnik it will really bring for us many great plugins written in c# for compiz ? If someone got idea, but dont know how to program it he should post that idea on forum, if this idea is really good somone will code it, if not it was probably not worth of coding that idea. If somone is to lazy to learn c, he will be probably to lazy to finish his work on his idea in c#. For god sake, plugins will not be biger than 200 kb so why we really care about sth like that ? C# is good for really big thing where doing sth in c would be 2x/4x slower that doing it in c# for professional coders.

[PaK]

And last thing, c# is slower and need more memory than c ;) it needs mono, do compiz really need to depend on sth that is (c) of microsoft at all ? yeah mono is os implementation of .net but it is still patented by microsoft, i thnik sooner or later microsoft will do sth with it.

[RYX]

Your position is the typical developer's pov - "why should I make things easier if its easy enough for me" ... that is a little selfish and not good for the evolution of a project. I don't want to offend you, your position is the way many people think about this ... but I, personally, don't see it like that.

Looks like we have a very different meaning of what is "simple". C-sharp is a higher-level language, it is easy to understand and allows access to all native libraries. OpenGL-coding is available through tao and glut (but I have never used them) ... You don't have to use managed code, you can write unmanaged code as well ... if you handle exceptions properly, there is no problem in that. It is a war of belief and a personal decision if OOP-code is better than traditional coding. I think it would be a great addition and wouldn't affect the existing compiz at all. It is a plugin you can use if you want - or you disable it and fine.

(An example: you really think that the WRAP/UNWRAP in C is easier than saying "s.PreparePaint += OnPreparePaintScreen"?)

@mikedee: No, I hadn't time to test it yet. I'll try to get it working later ... There is one example plugin included that shows the basics pretty well.

[RYX]

@PaK: I think the C#-language is not (or at least not entirely) invented/patented by Microsoft - the .NET-Framework is ... but we only use the language and the mono-runtime (which is a Novell-project - and they saved their asses with the "deal with the devil" anyway). And it would be no dependancy, more an option like "--librsvg" ...

[PaK]

@PaK: I think the C#-language is not (or at least not entirely) invented/patented by Microsoft - the .NET-Framework is ... but we only use the language and the mono-runtime (which is a Novell-project - and they saved their asses with the "deal with the devil" anyway). And it would be no dependancy, more an option like "--librsvg" ...
http://en.wikipedia.org/wiki/Mono_(software)#Mono_and_Microsoft.27s_patent
Ok we can discuss about that.. but imho for example java right now is more free ;-) than mono.

Well all that is my POV. This plugin will not change much. But i can be wrong.

[PaK]

Your position is the typical developer's pov - "why should I make things easier if its easy enough for me" ... that is a little selfish and not good for the evolution of a project. I don't want to offend you, your position is the way many people think about this ... but I, personally, don't see it like that.

(An example: you really think that the WRAP/UNWRAP in C is easier than saying "s.PreparePaint += OnPreparePaintScreen"?)

But it will give benefits for _developers_, so why i should look at this point from other side? As i said, if we talk about futures it doesn't matter how are they will be coded, asm, c, c#. Imho even if we get this plugin, and somone will write some cool plugin using c# with c# compiz plugin (sic!) soner or later it will be provided in c.

"s.PreparePaint += OnPreparePaintScreen" yeah it look really cool, and easy. But is this really necessary ? I mean we will get it but with more cpu and memory consumption right ?

Why David wrote compiz in c ? if c is so hard ?

But indeed it will be plugin and i dont need to use it right ? :)

[RYX]

I think the idea of a good software architecture is to write low-level things in a low-level language and provide extensions to higher-level languages to allow writing things in a higher-level (or interpreted/embedded) language. It is a common way to do this and it is not only limited to C#, all mono-based languages are supported ...

C-coding is not beginner-friendly, C#-coding is ... It will make understanding the core much easier. Switching to C is not very difficult once you understood the general way things work in compiz. Compiz needs more developers and such a plugin could attract them ...

(again - only my pov :))

[stjepan]

An example: you really think that the WRAP/UNWRAP in C is easier than saying "s.PreparePaint += OnPreparePaintScreen"?
Yes I am really thinking that. It's easier to understand how WRAP and UNWRAP #defines work than how delegates work.

[RYX]

As I said - a matter of taste ... :D

(But how about string-handling? It's not needed so often in compiz-plugins, but it is a pain in C ...)

I tried to compile the plugin but I wasn't able to make it work ... compiz crashes when I activate it. Adding getVersion and updating vTable didn't solve it. Can maybe someone have a look at it? I think it's something simple ...

:)

[RAOF]

If I had the time, I would totally maintain the mono bindings*. I think the CIL is one of the most interesting and important things to happen in the programming world for a while.

There are many things that Compiz does that aren't performance critical. The actual "window manager" stuff, for example. The ability to use of higher level languages there would make sense, and expand the pool of possibly contributing coders.

As a gross oversimplification, CPUs are becoming almost infinitely fast, so the importance of micro-optimisations compared to efficient algorithm design is tending to zero. C is all about the micro-optimisations :).

Oh, and C# (and Python, and Java, and all the other CIL languages) are exactly as powerful as C, in the mathematical sense. Actually, the C++ template mechanism is also Turing complete, so any program you can write in C you can write with only the C++ template system. Compiling the code is how you run it :).

* Incidentally, compiz-sharp should probably be renamed "compiz-cil". It's not just C#, it's any CIL language.

[RYX]

A quote from the mailing list (http://www.mail-archive.com/compiz@lists.freedesktop.org/msg00861.html)- David's answer to the question: "Do you think it is a good idea to use compiz-sharp for writing a plugin?":
Yes, I think it's a good idea to use a higher level language than C for plugins. A lot of things in compiz core can be made more convenient and less hard to understand when wrapped in a language like C#.

(And yes - it should be called compiz-mono or compiz-cil ...)

So anyone wants to help me get this thing working? :D

[RAOF]

...
So anyone wants to help me get this thing working? :D

I want to. Whether I can or not is yet to be determined :).

[mikedee]

I actually agree with both sides. C is great if you want lots of power and I actually find it more intuitive. However everyone is different and what often separates languages is their bindings or how easy it is to do certain things. I assume C# would make some things easier for some people. Personally I'd like to see an HTTP plugin which I think would be much easier in C# than C. I doubt something like cube would be much easier since its all opengl which is using the same API (as you probably found using cairo with python ;))

It should work straight away, apparently it worked before and not much (if anything) has changed with the plugin loading code since then. There have been changes to the vTable so you might need to tweak things there (basically just getVersion and the features stuff is new). If you have a go at getting it to work, I can try to help with anything from that side.

[RYX]

Instead someone is interested, a good starting point is the Embedding Mono Tutorial (http://www.mono-project.com/Embedding_Mono) by Miguel de Icaza ("mono-man") ...

I guess it is necessary to understand the basics of embedding mono to be able to continue work on the "compmono"-plugin (that's its name when compiled).

I am closer to tracking down the problem - it is in the monoInit()-function where the mono-runtime loads the compiz-sharp.dll ... I think compiz-sharp.dll has to be installed into the gac, but I don't know how (yet).

EDIT: Thanks, mikedee - the plugin gets loaded. I am now messing with mono. The biggest question is where I have to put the compiz-sharp.dll and the plugins (the C# ones) ... no further info on the author's website. Google's results for "compiz-sharp.dll" - 0 ... :(

:)

[mikedee]

compiz-sharp.dll

Ahh the memories....

Anyway good to see dll hell is alive on Linux and in the 21st century ;)

[RYX]

:D ... Yes, but it's a managed dll ... (I think) more like a pyc-file than like a so-file.

:)

[RYX]

A little update: I got the plugin working, added some error-checking and learned something about mono :) ... (I am pretty amazed by David's excellent plugin-loader system ...). The next task will be to get the C#-plugins working ... Unfortunalety, the tao-packages (which provide opengl-functions in C#) seem to be not part of ubuntu's repos :( ... so no 3d for me tonight.

[RAOF]

A little update: I got the plugin working, added some error-checking and learned something about mono :) ... (I am pretty amazed by David's excellent plugin-loader system ...). The next task will be to get the C#-plugins working ... Unfortunalety, the tao-packages (which provide opengl-functions in C#) seem to be not part of ubuntu's repos :( ... so no 3d for me tonight.

I'll look at packaging those up, if you like. There's still time for them to make it into Feisty universe :)

Edit: Ugh. There's a reason that TAO isn't packaged into Universe. The build-system is crazy.

[rememo]

Hi,

I remember the compile hell with Tao very well (needed it for banshee's fleow plugin). I found good source-packages for Tao 2.0 (seems to be the latest release) at this site: https://colliertech.com/downloads/tao/ .
They simply run with configure and make, make install (don't care what the readme or install says it's wrong) but I had to install a lot of other mono-packages.

Maybe you will also need gtk-glareasharp (which is not packaged, too), I found a good source package here: https://colliertech.com/downloads/gtkglarea-sharp/ (running with autogen, configure, make, make install), but I remember messing around with gac because after installation to the /usr/local/lib/mono path it wasn't found and I had to copy it to /usr/lib/mono/gac.

Here is a good tutorial on compiling everything (it describes tao and gtk-glarea installation)
http://www.mono-project.com/GtkGlAreaSharp:Installation

There was a packager request over at debian, but it's from 2006 (I think) and he didn't packaged it yet. Would be glad if someone could package it for ubuntu :wink: , because unless there is a package the compiz# plugins will be pretty useless for the users.

[RYX]

Thanks for your help :) ... I'm getting closer to the problem. I didn't install tao yet (it is not really essential, only for 3d) - I am still fighting with the PluginLoader.cs ...

The PluginLoader inside the compono-plugin (the "non-glue" part) has to be modified to let the VTable support getVersion/CompFeature ... I never did such low-level/embedding stuff in C#, so it's a tough piece of work.

After uncountable crashes I finally got compiz to hang up (mouse still moveable but no input-handling ... which means ungraceful reboot (i.e. reset-button)) ... And, surprisingly, I think it is a "good sign" - I assume the loader is working and the plugin simply hangs up ... but it is not a very smart way of developing if you have to reboot whenever your plugin doesn't work as its supposed to ...

Maybe contacting Alp Toker (the author of compiz-sharp) would make sense - maybe he can give a little summary of what is done, how it is done and where/why he stopped working on it ...

:)

[RYX]

I got it! The mono-PluginLoader works ... I wrote a small script that kills compiz after 10 seconds to avoid being forced to reset the PC when compiz hangs up. Got some nice output by the mono-runtime and the problem was an unhandled exception within the plugin ... (one of many, many of them).

Next step will be to implement the missing handlers (currently the Compiz.Plugin-class only has initScreen, initWindow, finiWindow) ... *sigh* (gets easier each time :) ... )

The Compiz.Options are only rudimental, too - I guess it will take a good amount of work to get that stuff working as smooth as the C-plugins ... but I am so amazed by the way the compiz-pluginloader works, I just can't stop now (you can simply put the (managed) dll-plugins into the plugin-path and load the plugin just like any other)

(my C# needed a little refresh, anyway ... :))

:)

[RAOF]

...

There was a packager request over at debian, but it's from 2006 (I think) and he didn't packaged it yet. Would be glad if someone could package it for ubuntu :wink: , because unless there is a package the compiz# plugins will be pretty useless for the users.

I think I'll file an intent-to-package on Tao, sometime. Unless someone beats me to it, I suppose I'll be the package maintainer of that autotools-less mess :roll:

[RYX]

After digging some deeper into the compmono-plugin, I realized that it is even less complete than I thought yet ... The only thing working (if tao was available) is painting GL-stuff to the screen. The classes Texture, Screen and Window are somehow existent but lack a lot of features ... Option, Display is missing nearly 90%. The compiz-API is partly imlemented but (as far as I can say) also missing about 50% of its features ...

All Screen/Display/Window-callback procs are missing (except preparePaint, Paint, DonePaint in Screen ...).

I think the original author offered a good base but the real work is yet to do. I made some progress, fixed the PluginLoader, figured out the paths where stuff needs to go, made the (non-tao) plugins run - but it is such a huge amount of work that I think I am unable to finish this alone ...

Anyone wants to join? The plugin is much more than a C#-plugin ... It can load any CIL-based dll-libs, so you could code compiz-plugins in nemerle, boo, C#, even VisualBasic (if you were a pervert) ... as long as you get a managed dll-file in the end.

@RAOF: Thanks for your efforts :) ... Maybe we can work on this some more, but if we don't - I think nobody cares, anyway.

:|

[PaK]

For the start... where i could download source of that plugin with your current work ? Maybe you culd put it into go-compiz git ?

[davidcanar]

I could help too, It would be very nice to have compiz-sharp working. We really need something simpler than C to program plugins. No offense but it is a pain to program in C compared to C# (it is just beautiful not to worry about memory management).
I do ASP.NET in C# for living so if I can help doing something, here I am. It would be nice to have the changes RYX made to the code in a repository so we can start hacking to the new code.

David

[RYX]

Hi David! Thanks for joining this discussion ... It is good to have an experienced C#-coder on board. :)

The changes I made to the original compiz-sharp are very few - I only corrected some things related to the versioning/vTable to make it run with current compiz.

I am by far not a "real" C#-coder (more self-taught) so maybe you can have a look at original compiz-sharp and tell me (i.e. us) if it is good and how complete it is (especially the implementation of compiz-options as Attributes is something I don't really understand yet ...).

(I can post a patch for plugin/pluginloader tomorrow but maybe we should first put it on compiz git and then start adding patches and work on it ...)

:)

[RAOF]

...
(I can post a patch for plugin/pluginloader tomorrow but maybe we should first put it on compiz git and then start adding patches and work on it ...)

:)

Yes, please! Get it on git! :)

[RYX]

Should be possible, I think. Mikedee, do you maybe know if we can simply upload it to compiz-git or if we need some special account or any special permissions?

:)

[mikedee]

Just contact David and he can give you an account :)

[davidcanar]

Hi David! Thanks for joining this discussion ... It is good to have an experienced C#-coder on board. :)

The changes I made to the original compiz-sharp are very few - I only corrected some things related to the versioning/vTable to make it run with current compiz.

I am by far not a "real" C#-coder (more self-taught) so maybe you can have a look at original compiz-sharp and tell me (i.e. us) if it is good and how complete it is (especially the implementation of compiz-options as Attributes is something I don't really understand yet ...).


Hi RYX thanks! I have worked with C# for almost 2 years but by any means I'm a C# GURU nor a professional C# developer. I'm still learning new things every day.
I downloaded the compiz-sharp source code and I'll take a look at it tonight. I'm not very familiar with the compiz API so I will need some help from you or from other experienced compiz hackers to understand better what is going on. I'll be posting my questions and findings.

DavidC

[RYX]

Thank you, DavidC!

Here are two patches with my (very few) changes. I also applied the compiz-style formatting (no tabs, instead 4 spaces) to the compiz-mono.c (the compiz-plugin).

Link: compiz-mono.patches.tar.bz2 (http://www.ryxperience.com/storage/compiz-mono.patches.tar.bz2)

IMPORTANT: You have to fix the absolute path in compiz-mono.c and set it to the path where you placed the compiz-sharp.dll (the compiled PluginLoader.cs). The PluginLoader assumes dll-plugins to be located in your $HOME/.compiz/plugins directory for now.

NOTES:
- I was unable to get the screen-callbacks working, I think we need some help there.
- If you want to compile Tao.OpenGl and Tao.FreeGlut, I really recommend compiling them by hand. It is done in two minutes and you need no other packages than opengl/freeglut ...

If you have any questions, I'll help where I can.

:)

[mikedee]

How can I compile plugins with this? I did the normal make install but that only installed libcompmono.so which I assume is the glue part (ie I should load compmono into compiz plugins). Which other bits do I need and how to compile them?

[RYX]

Yes, compmono is the glue. The src-dir contains the pluginloader (compiz-sharp.dll) which gets embedded by the plugin. You need libmono-dev for compiling the plugin. And gmcs (the mono compiler 2.0) is needed for compiling the compiz-sharp.dll.

Enter the src-directory and run make, then make the plugin itself ...

The plugins-dir contains a Makefile for building the example-plugins but I recommend using the TestPlugin from the src-folder first.

(The src/Main.cs compiles to compiz.exe but I wasn't aware of how it gets used (I think its only for testing))

:)

[mikedee]

OK - I went to src and typed make, I got this error

make
gmcs -debug -d:TRACE -unsafe -out:compiz-sharp.dll -t:library Display.cs Icon.cs Option.cs Plugin.cs PluginLoader.cs Screen.cs Texture.cs Window.cs Image.cs
Screen.cs(176,20): error CS0136: A local variable named `screen' cannot be declared in this scope because it would give a different meaning to `screen', which is already used in a `parent or current' scope to denote something else
Screen.cs(169,18): (Location of the symbol related to previous error)
Screen.cs(216,20): error CS0136: A local variable named `screen' cannot be declared in this scope because it would give a different meaning to `screen', which is already used in a `parent or current' scope to denote something else
Screen.cs(208,18): (Location of the symbol related to previous error)
Screen.cs(260,20): error CS0136: A local variable named `screen' cannot be declared in this scope because it would give a different meaning to `screen', which is already used in a `parent or current' scope to denote something else
Screen.cs(253,18): (Location of the symbol related to previous error)
Compilation failed: 3 error(s), 0 warnings
make: *** [compiz-sharp.dll] Error 1

Any ideas? Ill have a look to see if its anything easy ;)

I assume that once everything is compiled compiz will load the dll plugins by adding them to gconf in the normal way (after compmono)?

[RYX]

Does it compile without my patch for PluginLoader.cs applied? These were my first patches, maybe they are not ok ...

I assume that once everything is compiled compiz will load the dll plugins by adding them to gconf in the normal way (after compmono)?
Exactly - but currently they seem to "swallow" edge-clicks (or simply don't know about edges?).

[mikedee]

Same error without the patch for PluginLoader :(

Here is the version of gmcs I am using if it helps

1.2.2.1

[RYX]

Ubuntu is a little behind (as always) - I am using 1.1.17.1 ... maybe there were some changes to 1.2 and it became more strict?

I try to understand the error but I am not very used to the delegates-system in C#. I think I'll try to find a changelog for gmcs 1.2 to see what it could be ...

[RYX]

I didn't find anything like a changelog, but maybe you can fix the error. The source of the error seems to be that there are two "screen"-variables. The outer block defines a "CompScreen* screen" and an embedded function-definiton. Inside the embedded function there is another "screen"-variable ... that seems to cause the error. Maybe renaming the "inner" variable from "screen" to "scr" fixes the problem ...

A very interesting (and huge) article that will be of help for anyone interested in improving compiz-sharp: Interop_with_Native_Libraries (http://www.mono-project.com/Interop_with_Native_Libraries)

Another essential tutorial about mapping C-structs to C# (http://www.vsj.co.uk/articles/display.asp?id=501) ...

:)

[RYX]

Another update: I have fixed the CompScreen-structure and it is now possible to connect to Screen-callbacks. The problem is the wrong size of the "data"-field in the CompScreen-structure (which is used as a placeholder) - it results in NullReferenceException when trying to access its fields.

This is the fixed structure ... replace the one in Screen.cs with this one:
[StructLayout (LayoutKind.Sequential, Pack=1)]
public unsafe struct CompScreen
{
public CompScreen* Next;
public CompDisplay* Display;
public CompWindow* Windows;
public CompWindow* ReverseWindows;

//not so great (needs to be updated on any change to CompScreen)
public fixed byte data[2120];
// NOTE: we need the byte-offset between the fields in this struct
// to be able to get the position of these function pointers

public IntPtr PreparePaintScreen;
public IntPtr DonePaintScreen;
public IntPtr PaintScreen;
public IntPtr PaintTransformedScreen;
public IntPtr ApplyScreenTransform;
public IntPtr PaintBackground;
public IntPtr PaintWindow;
public IntPtr DrawWindow;
public IntPtr AddWindowGeometry;
public IntPtr DrawWindowGeometry;
public IntPtr DrawWindowTexture;
public IntPtr DamageWindowRect;
public IntPtr GetOutputExtentsForWindow;
public IntPtr FocusWindow;
public IntPtr SetWindowScale;

public IntPtr WindowResizeNotify;
public IntPtr WindowMoveNotify;
public IntPtr WindowGrabNotify;
public IntPtr WindowUngrabNotify;

public IntPtr WindowStateChangeNotify;
public IntPtr OutputChangeNotify;

public IntPtr privates;
}

@mikedee: Sorry, but I couldn't find anything yet. Did you try renaming the vars in the embedded functions? Or are you too disgusted by C# :D ...?

:)

[Thoemy]

@mikedee, ryx: see http://bugzilla.ximian.com/show_bug.cgi?id=79025
So renaming is the only real solution to fix that problem.

[RYX]

Thanks for the info, Thoemy. I will add it to my patches ... :)

I just got Tao.OpenGl and Tao.FreeGlut running. The compilation is no problem but it seems it can't find the appropriate system (X11). Hard-coding the native library names into the source is a workaround for that (but maybe I was just too stupid when adding it to mono's config).

:)

[Thoemy]

Unfortunately the compiler throws an exception if I rename the variables and try to compile.
RYX have you tried to contact Alp Toker?

[RYX]

I wanted to contact him but I haven't yet ...

EDIT: What exception do you get?

[Thoemy]

He should know that people are interested in his work. Maybe he will continue to work on it.

[RYX]

I have updated my patches for compmono-plugin (http://www.ryxperience.com/storage/compiz-mono.patches.tar.bz2). Can someone tell me if it now works with mono>=1.2, please? It also contains the fixed Screen-class ...

EDIT: And I just sent Alp Toker an e-mail to inform him about this discussion ...

:)

[Alp]

Hi,

I'm encouraged to see some renewed interest in the binding. It's true that I did drop the ball on this one but I do think it's a sensible foundation for future work.

In response to a few posts:

The binding is meant to reduce boilerplate overhead in writing and maintaining effects plugins -- it should be as fun to write plugins as it is to use them. It is a failure if it negatively impacts performance in any observable way or makes writing plugins harder. Mono has a first class JIT compiler and I have written software which meets or exceeds the performance of similar C libraries.

I'm very much against software patents and proprietary software. This is in fact part of the reason why I've chosen this technology and avoided any non-standardised .NET modules.

The binding aims to be CLS compliant so it should not be limited to C#, but any of the brilliant open source languages targeting .NET. Imagine implementing recursive, self modifying effects using lambda functions in Nemerle? Python plugins? Get your Visual Basic-hacking little sister to cook up a "Hello world" desktop effect? You got it.


There are incomplete sections of code in the binding, and some of it can probably done with a simpler approach. I hope the fact that the work has been done in a git repository has allowed people to experiment in my absence with patches that can be reviewed and cherry picked. Certainly I have some hindsight that I could apply to improve things if I start to work on this again.

If there is a real demand for this, maybe we can get the ball back in play. Thoughts?

[RYX]

Hi Alp!

Thank you for following my invitation and joining this discussion. As I already explained, I am really interested in getting compiz-sharp to a stable version and would like to help as far as I can. I absolutely agree with what you say about the advantages of compiz-sharp (which perhaps would better be named compiz-mono to avoid confusion). I believe that once there is an ability to write plugins in a language different than C, compiz will gain much more developers.

A huge problem for creating usable effect-plugins is the state of the Tao-framework which currently needs some tweaking to be installed on mono. Hopefully the upcoming releases of the big distributions will include Tao within their repos.

However - I would like to help work on this and I think some others do, too. It would be great to have you, as the author of the bindings, on board.

I have created a few small patches to make your git-version run with compiz 0.3.6. I am sure it can be done better, my C#-skills are quite limited (though getting better).

:)

[RAOF]

When Tao releases version 2.0 (they seem to be up to 2.0rc2), I'll file a Debian intent-to-package and pull together a package for it. That'll (hopefully) cover Debian & Ubuntu (and all the other Debian derivatives, too).

Secondly, I'd like to make a vote for calling it "compiz-cil", mainly because that's what the Debian/Ubuntu package would be called :). Although compiz-mono would still be better than compiz-sharp.

[RAOF]

Hm. Even the latest mono updates in Feisty don't fix gmcs. I'll just go file a bug against it...

[Who]

This sounds cool - I wish I could offer more than the assertion that I think it is cool you guys are working on this!

A _lot_ of people know C# or Java, and it would be great to flatten the learning curve for writing Compiz plugins!

Do you think writing plugins in C# will allow people to go faster from ideas to implementations? If so, then it is also great as a way to test ideas out, and then if people really feel that it is necessary (for whatever reason) the same stuff could be done in C... right?

[RYX]

Do you think writing plugins in C# will allow people to go faster from ideas to implementations? If so, then it is also great as a way to test ideas out, and then if people really feel that it is necessary (for whatever reason) the same stuff could be done in C... right?
Right. :)

[iznogood]

Recently mikedee coded a new configuration plugin based on ini files and also a new version of monodevelop was released.
These 2 things made me thing about writing a configuration tool and also a conifiguration plugin in C#.

.Net makes UI development very easy and it is better suited for data management stuff rather than graphics programming.
I believe that making a configuration tool in mono and also providing any configuration backend it might need on mono will give us a good opportunity to work on compiz-sharp.

[RYX]

Unfortunately, compiz-sharp is far from allowing to create anything options-related with it ... It would require a lot of work before you could write such a plugin.

I think with mikedee's config-plugin it should be possible to write a settings-tool without using an additional settings-plugin (like libberylsettings), but I don't really know.

[Thoemy]

compiz-sharp can now be build with mono-svn. This (http://bugzilla.ximian.com/show_bug.cgi?id=80878) bug is now fixed.

Recently mikedee coded a new configuration plugin based on ini files and also a new version of monodevelop was released.
These 2 things made me thing about writing a configuration tool and also a conifiguration plugin in C#.
I think mikedee's intension was to use DBus for a configuration tool because you don't have to worry about the backend.

[mikedee]

Recently mikedee coded a new configuration plugin based on ini files and also a new version of monodevelop was released.
These 2 things made me thing about writing a configuration tool and also a conifiguration plugin in C#.
I think mikedee's intension was to use DBus for a configuration tool because you don't have to worry about the backend.

Exactly, you only need to use dbus and you do not have to worry about the backend storage method. I am not sure if mono dbus bindings exist but I would not be surprised if they do. There are 2 main methods, get and set on each option so the API is easy to use.

As RYX says though, there is still some work to do before writing a configuration backend plugin in C#. I think the work required is all in C# land and hopefully C# developers can pitch in. The plugin I wrote only wraps 6 functions, the rest is native stuff. If you could perfect the wrapping functionality in this plugin then it will allow people to do a lot of things.

[PaK]

http://www.freedesktop.org/wiki/Software_2fDBusBindings There are mono bindings but they are unmaintained :( I thnik we dont need yet another compiz configuration tool, are we ? It would be better to improve one of that is alredy exsists and get it into compiz git as native compiz configuration tool

[flargen]

I am not sure if mono dbus bindings exist but I would not be surprised if they do.
More than just bindings, dbus implemented in C#:
http://www.ndesk.org/DBusSharp

[mikedee]

I have updated my patches for compmono-plugin (http://www.ryxperience.com/storage/compiz-mono.patches.tar.bz2). Can someone tell me if it now works with mono>=1.2, please? It also contains the fixed Screen-class ...

I applied these patches with a clean checkout and I get these errors when trying make in the src directory.

gmcs = 1.2.3.0

gmcs -debug -d:TRACE -unsafe -out:compiz-sharp.dll -t:library Display.cs Icon.cs Option.cs Plugin.cs PluginLoader.cs Screen.cs Texture.cs Window.cs Image.cs
Exception caught by the compiler while compiling:
Block that caused the problem begin at: Screen.cs(173,45):
Block being compiled: [Screen.cs(178,9):,Internal(1,1):]
System.NullReferenceException: Object reference not set to an instance of an object
Exception caught by the compiler while compiling:
Block that caused the problem begin at: Screen.cs(166,4):
Block being compiled: [Screen.cs(173,7):,Internal(1,1):]
System.NullReferenceException: Object reference not set to an instance of an object

Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object
at Mono.CSharp.ScopeInfo.CreateScope (Mono.CSharp.Block block) [0x00000]
at Mono.CSharp.Block.CreateScopeInfo () [0x00000]
at Mono.CSharp.LocalVariableReference.DoResolveBase (Mono.CSharp.EmitContext ec) [0x00000]
at Mono.CSharp.LocalVariableReference.DoResolve (Mono.CSharp.EmitContext ec) [0x00000]
at Mono.CSharp.Expression.Resolve (Mono.CSharp.EmitContext ec, ResolveFlags flags) [0x00000]
at Mono.CSharp.SimpleName.DoSimpleNameResolve (Mono.CSharp.EmitContext ec, Mono.CSharp.Expression right_side, Boolean intermediate) [0x00000]
at Mono.CSharp.SimpleName.SimpleNameResolve (Mono.CSharp.EmitContext ec, Mono.CSharp.Expression right_side, Boolean intermediate) [0x00000]
at Mono.CSharp.SimpleName.DoResolve (Mono.CSharp.EmitContext ec, Boolean intermediate) [0x00000]
at Mono.CSharp.Expression.Resolve (Mono.CSharp.EmitContext ec, ResolveFlags flags) [0x00000]
at Mono.CSharp.Expression.Resolve (Mono.CSharp.EmitContext ec) [0x00000]
at Mono.CSharp.Assign.DoResolve (Mono.CSharp.EmitContext ec) [0x00000]
at Mono.CSharp.Expression.Resolve (Mono.CSharp.EmitContext ec, ResolveFlags flags) [0x00000]
at Mono.CSharp.Expression.Resolve (Mono.CSharp.EmitContext ec) [0x00000]
at Mono.CSharp.ExpressionStatement.ResolveStatement (Mono.CSharp.EmitContext ec) [0x00000]
at Mono.CSharp.StatementExpression.Resolve (Mono.CSharp.EmitContext ec) [0x00000]
at Mono.CSharp.Block.Resolve (Mono.CSharp.EmitContext ec) [0x00000]
at Mono.CSharp.Block.Resolve (Mono.CSharp.EmitContext ec) [0x00000]
at Mono.CSharp.Unsafe.Resolve (Mono.CSharp.EmitContext ec) [0x00000]
at Mono.CSharp.Block.Resolve (Mono.CSharp.EmitContext ec) [0x00000]
at Mono.CSharp.EmitContext.ResolveTopBlock (Mono.CSharp.EmitContext anonymous_method_host, Mono.CSharp.ToplevelBlock block, Mono.CSharp.Parameters ip, IMethodData md, System.Boolean& unreachable) [0x00000]
make: *** [compiz-sharp.dll] Error 1

[RAOF]

That bug is https://bugs.launchpad.net/ubuntu/+source/mono/+bug/87736 and is apparently fixed in mono SVN.

I'll try an find the commit which fixed it, then the patch'll get backported to Feisty's mono.

That probably doesn't help you, mikedee, but if I find it I'll post the commit so you can patch your mono, too :).

Edit: Fixed with
SVN log tells me that the fix is in:
r73375 | marek | 2007-02-24 05:59:02 +1100 (Sat, 24 Feb 2007) | 5 lines

2007-02-23 Marek Safar <marek.safar@gmail.com>

A fix for bug #80878
* class.cs, cs-parser.jay: Event property can host anonymous methods.