CCSM and python-plugins

[RYX]

Hi ccsm-developers :)

Several users reported a problem with the python-plugins not showing up in ccsm. An opended bug has been closed with the reason that the python-plugins are the problem, which is - honestly - a slightly biased view of the problem. However - since Mike and I want to make everything working perfect for everyone, I thought I'd open up this thread in the hope that we can work out a solution to that problem, together ...

Maybe we can sum up a few things the python-plugins have to implement to make them show up in ccsm (even though it could likely be the other way round ;)). Is it enough to add a metadata-file (the plugins already define the metadata in their code and it should be internally available)? They have their own loaderListPlugins-function so they usually should be found through the common core functions (btw: they _are_ found when listed over dbus) ...

Thanks in advance for helping your users to enjoy the full power of compiz instead of only advertising the things our friendly beryl devs brought with them.

:)

Rico

[RYX]

A little update on this: From what I heard, the ccsm-developers are not interested in supporting python-plugins in ccsm. If some of you are (or want to start) developing plugins in python and want them to show up in ccsm, you'll have to add an external metadata-file. That is because ccsm doesn't support internal metadata, otherwise the python-plugins would show up without this workaround.

For everyone who is interested in the python API for compiz: I'd like to note that the python-plugins are usable, valid plugins. They follow the common rules and behave exactly as the ones written in C (with obvious differences in the way _how_ they achieve what they do, but that is a common thing with two different languages ;)). I am using plugins written in python for my everyday work, without any problems.

The python-plugin itself is 95% API complete and it contains only very few known bugs (which we are working on to get them fixed). Many of the preinstalled fusion plugins are much less complete than the python-plugin (I don't say this to discredit the fusion-plugins, I only want to mention that most of all available plugins aren't complete yet and using that as a reason for not supporting a plugin in the settings-tool is a weak excuse for having personal motives).

We should maybe start working together instead of letting our actions get ruled by personal feelings, so I am still awaiting an answer from the ccsm-devs.

:)

[maniac]

Maybe we can sum up a few things the python-plugins have to implement to make them show up in ccsm (even though it could likely be the other way round ;)). Is it enough to add a metadata-file (the plugins already define the metadata in their code and it should be internally available)?

Yes, this is enough. CCS assumes metadatato be present.
I think having the metadata externally is better anyway for some reasons:
- It's in line with the behaviour of all other plugins. No non-Python plugin has integrated metadata.
- When the metadata is external, it can be translated easily.

[quote:503d4]
They have their own loaderListPlugins-function so they usually should be found through the common core functions (btw: they _are_ found when listed over dbus) ...
[/quote:503d4]
I see no problem there. When activated, the plugin's name is just appended to the active plugin list and should be detected by core.

[quote:503d4]
Thanks in advance for helping your users to enjoy the full power of compiz instead of only advertising the things our friendly beryl devs brought with them.
[/quote:503d4]
ARGH! Rico, please stop stuff like that - I am really sick and tired of that. :( :roll:

[RYX]

I think both ways of retrieving metadata should be supported by a good settings-tool. In case of the python-plugins it would hurt the "scripted nature" if things had to be splitted up in two files. It is ok if we have it as an alternative, but if someone wants to define just a toggle-action and has to create a separate file for that it is highly suboptimal ... The translation is no problem here, it could also be easily done through gettext (more pythonic and standard conform and applied at compile-time).

Ccsm (i.e. libcompizconfig) should read internal metadata as well, otherwise it fails its purpose as a general configuration-tool/-library. I don't think the plugins should be held responsible for the design problems of the settings-library.

btw: the only reason for my continuing "pissedness" is the behavior of some of your companions, I am sorry that you are always the person who has to neutralize the bad feelings your buddies create. I was about to forgive and forget several times, but some of your buddies can't shut their mouths and let the adults do the thinking.

p.s.: This is slightly off-topic, but do you have any idea why I can't get the default/min/max/... metadata-values through the dbus interface anymore? Is it the intended behavior that the dbus-plugin now is heavily decreased in functionality? You are more into the core-development so maybe you know?

[Jupiter]

Thanks in advance for helping your users to enjoy the full power of compiz instead of only advertising the things our friendly beryl devs brought with them.

:)

Rico

btw: the only reason for my continuing "pissedness" is the behavior of some of your companions, I am sorry that you are always the person who has to neutralize the bad feelings your buddies create. I was about to forgive and forget several times, but some of your buddies can't shut their mouths and let the adults do the thinking.
RYX you truly are a pissy little punk. You come in here and make snide remarks WITHOUT PROVOCATION.
You just couldn't make a post without making a little whinny comment. Look in the mirror punk before
you think yourself as an adult and, check your own behavior before you criticize others. I feel sad
for your parents. If my son had your attitude when he was your age, i would have bitch slapped him.
You need to take your own advice and just shut up, if your just gonna whine.

[RYX]

The fact that you would slap your own son tells a lot about you ... better slap yourself and then start being constructive, not off-topic. What did you actually contribute to compiz, the community or the project? I don't know who you think you are. You are 20 years older than me and act like a little child ... poor old man.

btw: the provocation started on the ML, but who cares if there is a chance to act like being someone, right?

:D

[Jupiter]

The fact that you would slap your own son tells a lot about you ... better slap yourself and then start being constructive, not off-topic. What did you actually contribute to compiz, the community or the project? I don't know who you think you are. You are 20 years older than me and act like a little child ... poor old man.

btw: the provocation started on the ML, but who cares if there is a chance to act like being someone, right?

:D
As usual you have no clue. I said IF. Fortunately for me, my son was never an arrogant whinny pissy punk as you.
It doesn't matter who you think i am. What matters is that you continue to disparage this community and it's
members. Stop your crying.
[url=http://img107.imageshack.us/my.php?image=handelmanmf7.jpg:f83d6]http://img107.imageshack.us/img107/4140/handelmanmf7.th.jpg[/url:f83d6]

[RYX]

Especially from an official team member I would have expected some better manners. I can't really understand why you need to personally attack me (and my parents) and drive this post more off-topic. I doubt you even understand what this post is about, right? Please focus on things within your capabilities and stop insulting me. Thanks.

btw: When did I attack/disparage the community or its members? The only persons I attack are the ones insulting me for no reason and without any valid arguments ... e.g. you, nesl, Marex, ...

[Jupiter]

The reason i did respond to this thread is because of your snide remarks as i quoted above.
If you don't want to hear from me then STOP with your remarks. Stick to the subject of
your post. It is not necessary to make snide remarks every time you make a post. You
seem to have a habit of doing that here and in the ML. Stop it and you will not hear from me.

[RYX]

My snide remarks are related to reasonable complains about the general layout of ccsm. I discussed that several times with the ccsm-devs and they are absolutely not willing to move away from their idea of replacing standardized and existing solutions with own inventions (e.g. the ccp-plugin as "replacement" for dbus).

This doesn't mean that I don't accept other opinions or so, but the above example with the python-plugins shows that we now face problems with the way ccsm/ccp/cc work. These are problems that could have been avoided if we had started with designing solutions together and listening to other people's comments, instead of everyone cooking his own soup and keeping up rivalry with the other devs. This is also the main reason for my complains on the ML. We are all working for the same idea, but we don't always coordinate our actions well and instead work against each other.

I think you just don't know the whole story, so you should try to reduce your insults and maybe have a look at forum.compiz.org and try to make yourself an (unbiased) image of what an "arrogant pissy punk" I really am ... ;)

[maniac]

I think both ways of retrieving metadata should be supported by a good settings-tool. In case of the python-plugins it would hurt the "scripted nature" if things had to be splitted up in two files. It is ok if we have it as an alternative, but if someone wants to define just a toggle-action and has to create a separate file for that it is highly suboptimal ... The translation is no problem here, it could also be easily done through gettext (more pythonic and standard conform and applied at compile-time).

XML also can be translated by gettext. dbus-delivered metadata does not contain the full XML contents.
There would be a code path that relies on a special plugin being loaded (dbus) and does not contain all of the data - I don't see this as optimal. I would suggest providing an XML for now and raising this topic on the Compiz ML. I would really be interested in David's opinion about using dbus for settings managers - if he thinks this is the desired way to do it, the dbus plugin should be extended so that it (optionally) returns a full XML blob, which could be parsed by CCS.

[quote:23487]
Ccsm (i.e. libcompizconfig) should read internal metadata as well, otherwise it fails its purpose as a general configuration-tool/-library. I don't think the plugins should be held responsible for the design problems of the settings-library.
[/quote:23487]
Yeah, we know CCS is crap, blah, blah... :roll:
Seriously, you are complaining Patrick says "it isn't possible" and you respond by "it must be possible, otherwise it's crap"? You must be kidding.

[quote:23487]
p.s.: This is slightly off-topic, but do you have any idea why I can't get the default/min/max/... metadata-values through the dbus interface anymore? Is it the intended behavior that the dbus-plugin now is heavily decreased in functionality? You are more into the core-development so maybe you know?[/quote:23487]
min and max are returned here:
[code:23487]
daba@rechenknecht:~$ dbus-send --print-reply --type=method_call --dest=org.freedesktop.compiz /org/freedesktop/compiz/animation/screen0/magic_lamp_max_waves org.freedesktop.compiz.getMetadata
method return sender=:1.31 -> dest=:1.34
string "Magic Lamp Max Waves"
string "The maximum number of waves for Magic Lamp."
string "int"
int32 0
int32 20
[/code:23487]
Returning the default value isn't currently possible as it isn't included in the CompOption structure and parsing it on the fly from the XML isn't currently implemented.

[RYX]

I am not surprised that you still don't want to agree that the source of all problems was your (i.e. Dennis') decision to NOT use dbus as the way of communicating to compiz and instead use your own invention - ccp. And my comment "it should be possible, but ccs doesn't support it" is absolutely not comparable with Patricks's "I am not interested"-attitude - please stop this "you mut be kidding"-crap and start using valid arguments yourself.

I don't think all of you are really interested in making good software, some of you guys are more interested in making your own stuff look good ... I _never_ heard a single valid reason for not using dbus and not implementing a solution that allows using dbus while compiz is not running (i.e. by adding some display-less mode).

Concerning the default-values I wonder why it isn't possible anymore (and I truly wonder why dbus-send returns min/max and the dbus-bindings don't)? Was it David's decision? Or was it because some of you (i.e. Dennis/you/?) see no use in retrieving default values through any other settings-system than your own one? It is not that nobody ever told you before ...

But you're right - let's ask David about this and see what he thinks is best. We seem to have too different ideas.

[RYX]

I would suggest providing an XML for now and raising this topic on the Compiz ML. I would really be interested in David's opinion about using dbus for settings managers - if he thinks this is the desired way to do it, the dbus plugin should be extended so that it (optionally) returns a full XML blob, which could be parsed by CCS.
As I said, it is ok to add an external metadata-file if you have more than one or two options, but for small scripts it somehow destroys the ease-of-installation (not dramatically, but I hope you get the point). However - as a temporary solution it should be ok.

I think the extension to the dbus-plugin would just need "getMetadataXML" and "getPluginMetadataXML" - I guess it should be quite simple to create. The metadata could then be created on the fly when it gets requested (retrieving the options shouldn't be done more than once anyway so it should be no negative impact on performance). Maybe it could also be retrieved from core, depending on what is faster ... (If this would finally solve the ccs-issue then I'll even add it myself :))

Concerning the usage of the ML for development-stuff: I'd prefer discussing this here, too. I think it is a problem between the community-driven parts "ccsm/libcompizconfig" and "python-plugins". We should just ask for David's opinion on the dbus-usage ...

btw: I think we should generally try to use either this development-section (which, sadly enough, is very empty and mostly contains off-topic things) or the one at compiz.org. That way all community-members and -guests have a chance to get "under the hood" of development by simply following technical discussions. I think that "dev-stuff on the dev-list"-idea is a big problem we have since the early days of compiz and stops many people from starting development on compiz, compiz-plugins or related apps ... (and I quite often heard people in the community saying the same). It is also likely the reason why people prefer talking about dev-stuff on IRC, where all info gets lost for other people outside the chat.

:)

[maniac]

I am not surprised that you still don't want to agree that the source of all problems was your (i.e. Dennis') decision to NOT use dbus as the way of communicating to compiz and instead use your own invention - ccp. And my comment "it should be possible, but ccs doesn't support it" is absolutely not comparable with Patricks's "I am not interested"-attitude - please stop this "you mut be kidding"-crap and start using valid arguments yourself.

There are valid reasons for using the ccp plugin approach (such as DE integration and there's no dependency on a working dbus) as well as there are valid reasons for using Dbus (such as getting settings data for plugins without metadata). You think that Dbus is the way to go, I/we think that the plugin approach is the one to go. But as there isn't only black and white, the truth is somewhere inbetween.
We haven't implemented Dbus access yet because the coding effort isn't justified by the amount of advantages yet.

[quote:e9c46]
I don't think all of you are really interested in making good software, some of you guys are more interested in making your own stuff look good ... I _never_ heard a single valid reason for not using dbus and not implementing a solution that allows using dbus while compiz is not running (i.e. by adding some display-less mode).
[/quote:e9c46]
See above. No one has added such a display-less mode yet - do you happen to know why? If it's so important, why didn't e.g. you or Mike prepare some patches?

[quote:e9c46]
Concerning the default-values I wonder why it isn't possible anymore (and I truly wonder why dbus-send returns min/max and the dbus-bindings don't)? Was it David's decision? Or was it because some of you (i.e. Dennis/you/?) see no use in retrieving default values through any other settings-system than your own one? It is not that nobody ever told you before ...
[/quote:e9c46]
Neither Dennis nor me did ever change anything to the dbus plugin, so we surely aren't the right people to ask.

[quote:e9c46]
As I said, it is ok to add an external metadata-file if you have more than one or two options, but for small scripts it somehow destroys the ease-of-installation (not dramatically, but I hope you get the point). However - as a temporary solution it should be ok.
[/quote:e9c46]
I get the point, but please consider it until we have a better solution working for everybody. Having an external metadata file is the easiest method available at the moment to satisfy everybody.

[quote:e9c46]
Concerning the usage of the ML for development-stuff: I'd prefer discussing this here, too. I think it is a problem between the community-driven parts "ccsm/libcompizconfig" and "python-plugins". We should just ask for David's opinion on the dbus-usage ...
[/quote:e9c46]
Yes. We should also ask if he prefers metadata to be separated from the code or if he thinks it also could be integrated.

[RYX]

I am not surprised that you still don't want to agree that the source of all problems was your (i.e. Dennis') decision to NOT use dbus as the way of communicating to compiz and instead use your own invention - ccp. And my comment "it should be possible, but ccs doesn't support it" is absolutely not comparable with Patricks's "I am not interested"-attitude - please stop this "you mut be kidding"-crap and start using valid arguments yourself.

There are valid reasons for using the ccp plugin approach (such as DE integration and there's no dependency on a working dbus) as well as there are valid reasons for using Dbus (such as getting settings data for plugins without metadata). You think that Dbus is the way to go, I/we think that the plugin approach is the one to go. But as there isn't only black and white, the truth is somewhere inbetween.
We haven't implemented Dbus access yet because the coding effort isn't justified by the amount of advantages yet.
Well, that's an information I can live with. But you know that DBus will replace dcop in KDE and it is a standardized and well-tested system so it should be prefered over self-written and non-standardized solutions. Even if it may require several changes to libcc and core. I am pretty sure David would agree here.

[quote:4a350]
I don't think all of you are really interested in making good software, some of you guys are more interested in making your own stuff look good ... I _never_ heard a single valid reason for not using dbus and not implementing a solution that allows using dbus while compiz is not running (i.e. by adding some display-less mode).

See above. No one has added such a display-less mode yet - do you happen to know why? If it's so important, why didn't e.g. you or Mike prepare some patches?[/quote:4a350]
Because dbus has no big "lobby" (like ccs has) and Mike and I have to care for a billion other things, too ... :) .... also Mike proposed it several times but it always got shot down by ccs-lobbyists ... :D

[quote:4a350]
Concerning the default-values I wonder why it isn't possible anymore (and I truly wonder why dbus-send returns min/max and the dbus-bindings don't)? Was it David's decision? Or was it because some of you (i.e. Dennis/you/?) see no use in retrieving default values through any other settings-system than your own one? It is not that nobody ever told you before ...

Neither Dennis nor me did ever change anything to the dbus plugin, so we surely aren't the right people to ask.[/quote:4a350]
Dennis and you had heavy influence on several changes to the metadata-system, right? During all those changes nobody tried to keep the compatibility with dbus-driven settings-systems. That's what I meant. I know David supports the metadata-idea.

[quote:4a350]
As I said, it is ok to add an external metadata-file if you have more than one or two options, but for small scripts it somehow destroys the ease-of-installation (not dramatically, but I hope you get the point). However - as a temporary solution it should be ok.

I get the point, but please consider it until we have a better solution working for everybody. Having an external metadata file is the easiest method available at the moment to satisfy everybody.[/quote:4a350]
Yup - that should work. But, hopefully, this is not the final solution.

[quote:4a350]
Concerning the usage of the ML for development-stuff: I'd prefer discussing this here, too. I think it is a problem between the community-driven parts "ccsm/libcompizconfig" and "python-plugins". We should just ask for David's opinion on the dbus-usage ...

Yes. We should also ask if he prefers metadata to be separated from the code or if he thinks it also could be integrated.[/quote:4a350]
From what Mike said David wants to support internal AND external metadata. If it is correct, then I think that the configuration-system should support both, too. That's all I tried to say :) ..

[maniac]

[quote:eb7ba]
I don't think all of you are really interested in making good software, some of you guys are more interested in making your own stuff look good ... I _never_ heard a single valid reason for not using dbus and not implementing a solution that allows using dbus while compiz is not running (i.e. by adding some display-less mode).

See above. No one has added such a display-less mode yet - do you happen to know why? If it's so important, why didn't e.g. you or Mike prepare some patches?
Because dbus has no big "lobby" (like ccs has) and Mike and I have to care for a billion other things, too ... :) .... also Mike proposed it several times but it always got shot down by ccs-lobbyists ... :D
[/quote:eb7ba]
That "lobby" argument is bullshit, sorry. Who should these "lobbyists" be? And proposing something is easy, writing the code is harder. If there are valid technical reasons to prefer one solution over another, it's simply not possible to "shoot them down" without informed people noticing that.

[quote:eb7ba]
Dennis and you had heavy influence on several changes to the metadata-system, right? During all those changes nobody tried to keep the compatibility with dbus-driven settings-systems. That's what I meant. I know David supports the metadata-idea.
[/quote:eb7ba]
Dennis wrote 70 or 80% of the metadata system. I don't think he did anything on bad intention, and IIRC he didn't adapt the dbus plugin to the metadata system. In fact, reading default values wasn't possible since the metadata retrieval was added, as you can see [url=http://gitweb.freedesktop.org/?p=xorg/app/compiz.git;a=commitdiff;h=8eab0bf16bb30efdf1138ce5 06681d5bd73788fb:eb7ba]here[/url:eb7ba].

[quote:eb7ba]
From what Mike said David wants to support internal AND external metadata. If it is correct, then I think that the configuration-system should support both, too. That's all I tried to say :) ..[/quote:eb7ba]
Reading [url=http://lists.freedesktop.org/archives/compiz/2007-April/002038.html:eb7ba]the announcement[/url:eb7ba] sounds like David highly recommends to provide an XML file while explicitly mentioning configuration systems for offline settings reading. This doesn't mean that internal metadata is completely unsupported, but also not encouraged.

[RYX]

This part in the announcement rather sounds like both ways should be supported: All this without removing any flexibility previously provided. Plugins
are not required to use this new meta data system but it's highly
recommended. You're not required to provide an xml file with meta data
for your plugins. You can put all meta data you like to provide in the
source code and only allow reading of it at run time but for
configuration systems that allow manipulation of options when compiz
isn't running the xml file is useful and it is recommended to provide
one.


So this means that the python-plugin developers should "not (be) required" to add an external metadata-file, too. I think Mike's interpretation of David's statement is absolutely correct. Internal as well as external metadata is supported. I am talking about a "compiz-is-running"-case here ...

The whole "manipulating compiz while offline"-thing could also be approached differently as described several times (the reason why nobody implented it yet could be that there was no consensus about it and no final decision).

:)

[SmSpillaz]

Hi ccsm-developers :)

Thanks in advance for helping your users to enjoy the full power of compiz instead of only advertising the things our friendly beryl devs brought with them.

I'm sorry for saying that the bottleneck _is_ at your end of this... but it _is_. If you want your stuff to be a _known_ part of compiz fusion, go ask iXce for a user account on opencompositing.org. Don't expect us to fix something we didn't even know was ours.

BTW : If you don't want to do that, I can always adapt it to the universal build system and stick it in my repo here (git://git.opencompositing.org/users/sms ... ebcopbuild (git://git.opencompositing.org/users/smspillaz/mikebcopbuild)) and write some metadata for it so it better adapts to the 'Compiz Fusion' organizations system. Do you have any instructions for writing metadata for the python plugins?

Yes other devs, that means I _have_ volunteered to do the jobs.

Thanks

SmSpillaz

[onestone]

I have somewhere a xml-dump plugin that could be used to create xml files for the python plugins. But mike could also try to add a system to the python plugin interface to generate a xml metadata files directly out of the python plugin code without compiz.
The xml files could then be used in ccs and also to generate gconf schema files.

I would never say that ccs is perfect. We decided to develop the ccs system because it offers more (for us importand) advantages than a dbus based system. One problem with dbus is that you have first to load a plugin before you can get the metadata. But you need the metadata to load a plugin in the right order, because some plugins will not initialize if the loading order is wrong.

I could list here more disadvantages of a dbus system, but also some of ccs. There is no perfect solution, but both sides should respect the other system and the intention of the developers behind it.

[RYX]

Hi ccsm-developers :)

Thanks in advance for helping your users to enjoy the full power of compiz instead of only advertising the things our friendly beryl devs brought with them.

I'm sorry for saying that the bottleneck _is_ at your end of this... but it _is_. If you want your stuff to be a _known_ part of compiz fusion, go ask iXce for a user account on opencompositing.org. Don't expect us to fix something we didn't even know was ours.
Why can't we finally put away this "we and you"-attitude and instead simply think of "we"? There is nothing like "yours" and "ours", it is all "ours" (in sense of "we all" at all those different places we tend to visit).

BTW : If you don't want to do that, I can always adapt it to the universal build system and stick it in my repo here (git://git.opencompositing.org/users/sms ... ebcopbuild (git://git.opencompositing.org/users/smspillaz/mikebcopbuild)) and write some metadata for it so it better adapts to the 'Compiz Fusion' organizations system. Do you have any instructions for writing metadata for the python plugins?

Yes other devs, that means I _have_ volunteered to do the jobs.

Thanks

SmSpillaz
In the end it is Mike's decision where to host it and he hosts it at his personal fd.o-repo. I think it is ok because the python-plugin should be closely related to the core, ideally it should even become a default-plugin. But I appreciate the offer and I am sure we can build some better collaboration once the python-plugin is really API-complete. I just think it shouldn't be included into some plugin-bundle and I'd highly prefer a separate package like "compiz-python" for it, because python-based plugins could then depend on that package (and it is simply the most common way to do it).

The metadata for the python-plugins is exactly the same as for the C-based ones. The current plugins in Mike's git-repo are partly outdated anyway, maybe I'll find the time to update them these days.

:)

[RYX]

I have somewhere a xml-dump plugin that could be used to create xml files for the python plugins. But mike could also try to add a system to the python plugin interface to generate a xml metadata files directly out of the python plugin code without compiz.
The xml files could then be used in ccs and also to generate gconf schema files.
That would be nice, but it's also not really essential. The metadata-files are not complicated to write, I personally like the metadata and even think it is a good idea to have those files, I just would like to not make them a requirement but a recommendation. Though I get the point why the metadata may become required sooner or later. But auto-generating it may be a good idea in case it doesn't exists.

I would never say that ccs is perfect. We decided to develop the ccs system because it offers more (for us importand) advantages than a dbus based system. One problem with dbus is that you have first to load a plugin before you can get the metadata. But you need the metadata to load a plugin in the right order, because some plugins will not initialize if the loading order is wrong.
That is indeed a problem, but it got introduced with the metadata and David's decision to remove the load order from core, I guess. Also the fact that plugins depend on each other wouldn't be a problem if we would just load the plugin, get its options and then unload it again (something like a display-less mode). I think the problem is that nobody ever focused on the idea of a dbus-based system and that's why it isn't really well supported now (6 months ago it worked quite well). I don't mean that as critics, it is the logical consequence of the bigger user and developer support behind ccs (that' what I meant with the "lobby"). Mike and I always tried to "advertise" DBus, but most of the times it got misunderstood as some sort of "remote-control" ...

I could list here more disadvantages of a dbus system, but also some of ccs. There is no perfect solution, but both sides should respect the other system and the intention of the developers behind it.
Yes, that's true. I always respected your intentions, I just didn't fully understand them. But maybe we can work out a way to allow ccs using either ccp or dbus as communication-interface.

[SmSpillaz]

Hi ccsm-developers :)

Thanks in advance for helping your users to enjoy the full power of compiz instead of only advertising the things our friendly beryl devs brought with them.

I'm sorry for saying that the bottleneck _is_ at your end of this... but it _is_. If you want your stuff to be a _known_ part of compiz fusion, go ask iXce for a user account on opencompositing.org. Don't expect us to fix something we didn't even know was ours.
Why can't we finally put away this "we and you"-attitude and instead simply think of "we"? There is nothing like "yours" and "ours", it is all "ours" (in sense of "we all" at all those different places we tend to visit).

BTW : If you don't want to do that, I can always adapt it to the universal build system and stick it in my repo here (git://git.opencompositing.org/users/sms ... ebcopbuild (git://git.opencompositing.org/users/smspillaz/mikebcopbuild)) and write some metadata for it so it better adapts to the 'Compiz Fusion' organizations system. Do you have any instructions for writing metadata for the python plugins?

Yes other devs, that means I _have_ volunteered to do the jobs.

Thanks

SmSpillaz
In the end it is Mike's decision where to host it and he hosts it at his personal fd.o-repo. I think it is ok because the python-plugin should be closely related to the core, ideally it should even become a default-plugin. But I appreciate the offer and I am sure we can build some better collaboration once the python-plugin is really API-complete. I just think it shouldn't be included into some plugin-bundle and I'd highly prefer a separate package like "compiz-python" for it, because python-based plugins could then depend on that package (and it is simply the most common way to do it).

The metadata for the python-plugins is exactly the same as for the C-based ones. The current plugins in Mike's git-repo are partly outdated anyway, maybe I'll find the time to update them these days.

:)

OK. What I recommend is that you make a git repo that is a mirror or mike's fd.o repo with some slight adjustments (Makefile updates / metadata category sorting etc) so that it will *intergrate*

I'm also happy that you want to work with us again :D. Just, please dont come in complaining, espcially if it gives the impression that you are _sick_ of working with us :D

SmSpillaz

[maniac]

I would never say that ccs is perfect. We decided to develop the ccs system because it offers more (for us importand) advantages than a dbus based system. One problem with dbus is that you have first to load a plugin before you can get the metadata. But you need the metadata to load a plugin in the right order, because some plugins will not initialize if the loading order is wrong.
How about returning to writing the active_plugins setting instead of ____plugin_enabled? The load order sorting could be done by ccsm then.
Disadvantages are that users may screw their plugin load order when manually manipulating the settings store (their own fault in that case) and that users may have the idea to use the gconf plugin with ccsm (which is unsupported as it would break the DE integration). Advantages would be cleaner code (we could drop the special handling for ____plugin_enabled options), we could support manually sorting the plugin list eventually (for advanced users) and the one described below ;)

I have some patches ready that implement that change which are 95% working. What is currently missing is setting some default value for the active_plugins setting that would replace the <autoenable> tags.

When we do that change, we could eventually support integrated metadata by loading the plugin in order of active_plugins and load the settings metadata in InitPluginForScreen/Display if not already present through parsing from the XML before applying the settings.

ccsm could use dbus (if available) to retrieve the internal-only metadata. However, all this stuff is a lot of effort and I think we should really raise the question if providing metadata files should be optional or mandatory on the Compiz ML.


I could list here more disadvantages of a dbus system, but also some of ccs. There is no perfect solution, but both sides should respect the other system and the intention of the developers behind it.
Yes, that's true. I always respected your intentions, I just didn't fully understand them. But maybe we can work out a way to allow ccs using either ccp or dbus as communication-interface.
We just need to implement the missing metadata retrieval in the dbus plugin, then libcompizconfig based configuration (using ccp) and dbus based configuration can coexist peacefully ;)

[onestone]

I would never say that ccs is perfect. We decided to develop the ccs system because it offers more (for us importand) advantages than a dbus based system. One problem with dbus is that you have first to load a plugin before you can get the metadata. But you need the metadata to load a plugin in the right order, because some plugins will not initialize if the loading order is wrong.
How about returning to writing the active_plugins setting instead of ____plugin_enabled? The load order sorting could be done by ccsm then.
Disadvantages are that users may screw their plugin load order when manually manipulating the settings store (their own fault in that case) and that users may have the idea to use the gconf plugin with ccsm (which is unsupported as it would break the DE integration). Advantages would be cleaner code (we could drop the special handling for ____plugin_enabled options), we could support manually sorting the plugin list eventually (for advanced users) and the one described below ;)

I have some patches ready that implement that change which are 95% working. What is currently missing is setting some default value for the active_plugins setting that would replace the <autoenable> tags.

When we do that change, we could eventually support integrated metadata by loading the plugin in order of active_plugins and load the settings metadata in InitPluginForScreen/Display if not already present through parsing from the XML before applying the settings.

ccsm could use dbus (if available) to retrieve the internal-only metadata. However, all this stuff is a lot of effort and I think we should really raise the question if providing metadata files should be optional or mandatory on the Compiz ML.


I could list here more disadvantages of a dbus system, but also some of ccs. There is no perfect solution, but both sides should respect the other system and the intention of the developers behind it.
Yes, that's true. I always respected your intentions, I just didn't fully understand them. But maybe we can work out a way to allow ccs using either ccp or dbus as communication-interface.
We just need to implement the missing metadata retrieval in the dbus plugin, then libcompizconfig based configuration (using ccp) and dbus based configuration can coexist peacefully ;)

I would like to make such bigger changes after the first release of ccs (compiz 0.6). We should concentrate now on stabilisation of the current system.

[RYX]

I would never say that ccs is perfect. We decided to develop the ccs system because it offers more (for us importand) advantages than a dbus based system. One problem with dbus is that you have first to load a plugin before you can get the metadata. But you need the metadata to load a plugin in the right order, because some plugins will not initialize if the loading order is wrong.
How about returning to writing the active_plugins setting instead of ____plugin_enabled? The load order sorting could be done by ccsm then.
Disadvantages are that users may screw their plugin load order when manually manipulating the settings store (their own fault in that case) and that users may have the idea to use the gconf plugin with ccsm (which is unsupported as it would break the DE integration). Advantages would be cleaner code (we could drop the special handling for ____plugin_enabled options), we could support manually sorting the plugin list eventually (for advanced users) and the one described below ;)
I don't fully understand what you are talking about, but I think I agree here :) ...

I have some patches ready that implement that change which are 95% working. What is currently missing is setting some default value for the active_plugins setting that would replace the <autoenable> tags.

When we do that change, we could eventually support integrated metadata by loading the plugin in order of active_plugins and load the settings metadata in InitPluginForScreen/Display if not already present through parsing from the XML before applying the settings.

ccsm could use dbus (if available) to retrieve the internal-only metadata. However, all this stuff is a lot of effort and I think we should really raise the question if providing metadata files should be optional or mandatory on the Compiz ML.
Sounds all really convincing. It would be great if these changes could eventually make their way into ccs.

I could list here more disadvantages of a dbus system, but also some of ccs. There is no perfect solution, but both sides should respect the other system and the intention of the developers behind it.
Yes, that's true. I always respected your intentions, I just didn't fully understand them. But maybe we can work out a way to allow ccs using either ccp or dbus as communication-interface.
We just need to implement the missing metadata retrieval in the dbus plugin, then libcompizconfig based configuration (using ccp) and dbus based configuration can coexist peacefully ;)
That should be a very democratic and satisfying solution. Nice.

:)

[RYX]

I would like to make such bigger changes after the first release of ccs (compiz 0.6). We should concentrate now on stabilisation of the current system.
I understand that you want to stabilize the current system, but wouldn't it make more sense to first improve it to work as supposed to (i.e. supporting all plugins, including those loaded by pluginloader-plugins) instead of stabilizing everything to then make the required changes and unstabilize it again? Compiz 0.6 release isn't really _that_ close, is it?

[maniac]

I would like to make such bigger changes after the first release of ccs (compiz 0.6). We should concentrate now on stabilisation of the current system.
I understand that you want to stabilize the current system, but wouldn't it make more sense to first improve it to work as supposed to (i.e. supporting all plugins, including those loaded by pluginloader-plugins) instead of stabilizing everything to then make the required changes and unstabilize it again? Compiz 0.6 release isn't really _that_ close, is it?
Plugins loaded by plugin-loader-plugins are supported, plugins without external metadata are unsupported at the moment - that's a difference ;)
As Compiz 0.6 probably isn't too far away (see [url=http://lists.freedesktop.org/archives/compiz/2007-July/002562.html:906c2]here[/url:906c2] - I guess we want to see 0.6 in Fedora 8), I also think it's a good idea to stabilize first. I would also think it would be a good idea to release the Compiz Fusion stuff together with 0.6, which would be another reason to put big changes in Compiz into a 0.7/0.8 line and release a 0.6 ASAP (and yes, David is ok with that).
For now, there is a pretty easy workaround available (provide external metadata - and please include the <require> tag for the python (loader) plugin in the metadata of the python plugins ;) ) which should work ok for the moment.

[RYX]

I still have no positive testing-reports about the python-plugins showing up if they have external metadata. A user at compiz.org wasn't able to get it running, even though he seemed to do everything right. Where does the metadata need to be placed, in user or system-wide dir? Both should be ok, shouldn't it? I have no ccs installed and I assume you have no python-plugin running atm, so how do we get this confirmed? Someone has to "jump over his shadow" - let's throw a coin ... :D

[maniac]

I still have no positive testing-reports about the python-plugins showing up if they have external metadata. A user at compiz.org wasn't able to get it running, even though he seemed to do everything right. Where does the metadata need to be placed, in user or system-wide dir? Both should be ok, shouldn't it? I have no ccs installed and I assume you have no python-plugin running atm, so how do we get this confirmed? Someone has to "jump over his shadow" - let's throw a coin ... :D
I need no coin :P

For me, it works (at least basiczoom).
What I did:
- installed python plugin
- copied basiczoom.xml to ~/.compiz/metadata and basiczoom.py to ~/.compiz/plugins
- activated both
- fixed the loading order of python and basiczoom (possible in my local copy only for the moment)

So it looks like the only obstacle is the load order requirement.
Do you have a
[code:d79de]
<deps>
<relation type="after">
<plugin>python</plugin>
</relation>
</deps>
[/code:d79de]
in your <pyplugin.xml>?

[RYX]

OK, cool. After re-reading the post on compiz.org I realized that "my tester" wasn't able to load any plugin at all (maybe due to the load order?). Good to hear that it works. Concerning the load-order - it should be no problem to add it and make it a requirement for the python plugin's metadata.

:)