Compiz web based settings framework

[mikedee]

Here is a new way for people to access compiz settings. This is 2 pieces of software in one.

1. HTTP -> DBUS -> JSON bridge
2. Web based settings application based on that

The most important part is the first because it allows you to change compiz settings using HTTP requests made to a locally running http server.

To install this untar the file below and copy the cws directory to your ~/.compiz directory and copy cws.py to your autostart folder. Once cws.py is running it provides a web server on port 8899 (by default) which runs the default web app. This app is just something I made quickly to demonstrate and develop everything. You should be able to come up with something much nicer ;)

To checkout from git

git-clone git://people.freedesktop.org/~mike/cws

Git web

http://gitweb.freedesktop.org/?p=users/mike/cws.git;a=summary

TECHNICAL

The web server responds to requests similar to dbus and it responds with JSON data, this is the easiest to evaluate with web based languages.

The API is like this, look in http.js for examples of its use with HTTPRequest.

The path you make the request to relates to the dbus object path. Each path has different methods. You tell it which method with a GET request.

/ (root path)

?method=getPluginMetadata&plugin=cube - get metadata about a plugin
?method=loadPlugin&plugin=cube - loads a plugin, performs dependency checking so you can load any plugin without worrying about order
?method=unloadPlugin&plugin=cube - unloads a plugin
?method=getAvailablePlugins - Lists all available plugins (not loaded ones)
?method=getActivePlugins - Lists all active plugins

if no method is specified then it will return the index.html file from ~/.commpiz/cws/<theme>/

/cube (plugin path)

Any request to this url will return a list of all options for that plugin (grouped by screen)

/cube/allscreens (screen path)

Any request to this URL will respond with a list of all options for that screen

/cube/allscreens/unfold (option path)

?method=set&value=val - will set an option value
Lists must be sent with the name ending in square brackets (ie. value[]=val1&value[]=val2)
Actions are the same but the action part name must be in the brackets (ie. value[bell]=1&value[key]=<Super>F1

Any other request to an option path will return the options value.

[Gusar]

I must say, an interesting approach to configure compiz. However, it doesn't work here :(. The interface shows up when I go to http://localhost:8899/ and says to click on a plugin on the left, but there is no plugin list on the left. The console where I started cws.py prints this:localhost - - [11/Apr/2007 18:00:13] "GET / HTTP/1.1" 200 -
localhost - - [11/Apr/2007 18:00:13] "GET /cws-static/http.js HTTP/1.1" 200 -
localhost - - [11/Apr/2007 18:00:13] "GET /cws-static/header.gif HTTP/1.1" 200 -
----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 59755)
Traceback (most recent call last):
File "/usr/lib/python2.4/SocketServer.py", line 222, in handle_request
self.process_request(request, client_address)
File "/usr/lib/python2.4/SocketServer.py", line 241, in process_request
self.finish_request(request, client_address)
File "/usr/lib/python2.4/SocketServer.py", line 254, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "/usr/lib/python2.4/SocketServer.py", line 521, in __init__
self.handle()
File "/usr/lib/python2.4/BaseHTTPServer.py", line 316, in handle
self.handle_one_request()
File "/usr/lib/python2.4/BaseHTTPServer.py", line 310, in handle_one_request
method()
File "./cws.py", line 52, in do_GET
self.handle_root_request (query_data)
File "./cws.py", line 158, in handle_root_request
plugins = self.dbus.call_method (self.compiz_dbus_root, 'getPlugins', None)
File "./cws.py", line 345, in call_method
return func ()
File "//usr/lib/python2.4/site-packages/dbus/proxies.py", line 85, in __call__
return self._proxy_method(*args, **keywords)
File "//usr/lib/python2.4/site-packages/dbus/proxies.py", line 169, in __call__
reply_message = self._connection.send_message_with_reply_and_block (message, timeout)
DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method "getPlugins" with signature "" on interface "org.freedesktop.compiz" doesn't exist

----------------------------------------
----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 59756)
Traceback (most recent call last):
File "/usr/lib/python2.4/SocketServer.py", line 222, in handle_request
self.process_request(request, client_address)
File "/usr/lib/python2.4/SocketServer.py", line 241, in process_request
self.finish_request(request, client_address)
File "/usr/lib/python2.4/SocketServer.py", line 254, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "/usr/lib/python2.4/SocketServer.py", line 521, in __init__
self.handle()
File "/usr/lib/python2.4/BaseHTTPServer.py", line 316, in handle
self.handle_one_request()
File "/usr/lib/python2.4/BaseHTTPServer.py", line 310, in handle_one_request
method()
File "./cws.py", line 52, in do_GET
self.handle_root_request (query_data)
File "./cws.py", line 170, in handle_root_request
plugins = self.dbus.call_method (active_path, 'get', None)
File "./cws.py", line 345, in call_method
return func ()
File "//usr/lib/python2.4/site-packages/dbus/proxies.py", line 85, in __call__
return self._proxy_method(*args, **keywords)
File "//usr/lib/python2.4/site-packages/dbus/proxies.py", line 169, in __call__
reply_message = self._connection.send_message_with_reply_and_block (message, timeout)
DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method "get" with signature "" on interface "org.freedesktop.compiz" doesn't exist

----------------------------------------

The problem is definitely somewhere in the web interface, because dbus itself works; for instance the following command will print all available plugins:dbus-send --print-reply --type=method_call --dest=org.freedesktop.compiz /org/freedesktop/compiz org.freedesktop.compiz.getPlugins

[mikedee]

Oops, sorry. I didn't realize but python requires the introspection data. I was using a version of dbus with introspection. I will hopefully release those soon, when thats done Ill bump this thread and it should work.

[delfick]

cool :D

what is this autostart folder you speak of ??

[RYX]

cool :D

what is this autostart folder you speak of ??
KDE-stuff :D ... (gnome users could add it to their session's startup-programs)

[mikedee]

Ive just updated the dbus in git with Amaranths changes, so this will work now... Sorry about the false-start :oops:

[RYX]

Works well and looks pretty cool. :D ...

I wrote a compizutil-library which should be extended to become a universal communication-lib for talking to compiz through a single interface which uses any type of backend (fuse, dbus, ...). Maybe you can try to base your server on that library, too? The server could use the library for communicating and the library could get cws as new type of backend (of course we should avoid a reverse dependancy).

:)

[mikedee]

I wrote a compizutil-library which should be extended to become a universal communication-lib for talking to compiz through a single interface which uses any type of backend (fuse, dbus, ...). Maybe you can try to base your server on that library, too? The server could use the library for communicating and the library could get cws as new type of backend (of course we should avoid a reverse dependancy).

Sounds good, where is this library?

[bijoux]

I must say, that pretty awesome stuff, mike. Keep it up! :D

[delfick]

hmmm, i just updated compiz git, and the script gives me this

iambob@bob-linux:~/.compiz/compiz-web-settings$ ./cws.py
Traceback (most recent call last):
File "./cws.py", line 361, in <module>
httpd = BaseHTTPServer.HTTPServer (server_address, compizRequestHandler)
File "/usr/lib/python2.5/SocketServer.py", line 330, in __init__
self.server_bind()
File "/usr/lib/python2.5/BaseHTTPServer.py", line 101, in server_bind
SocketServer.TCPServer.server_bind(self)
File "/usr/lib/python2.5/SocketServer.py", line 341, in server_bind
self.socket.bind(self.server_address)
File "<string>", line 1, in bind
socket.error: (98, 'Address already in use')
........



hmmm, dbus doesn't seem to work

iambob@bob-linux:~$ dbus-send --print-reply --type=method_call --dest=org.freedesktop.compiz /org/freedesktop/compiz org.freedesktop.compiz.getPlugins
Failed to open connection to session message bus: Failed to connect to socket /tmp/dbus-QEQTFa7JGP: Connection refused


but when i run the autogen.sh script in compiz git, it comes up saying dbus : yes ................

[wfarr]

The DBUS plugin is loaded in Compiz, yes?

[delfick]

The DBUS plugin is loaded in Compiz, yes?

i'm not sure, how do i check ??

[karmapolice]

In gconf-editor :p , do you have it in your list?

socket.error: (98, 'Address already in use')
This error is because the port is already in use, maybe you have another instance already running?

[delfick]

In gconf-editor :p , do you have it in your list?

socket.error: (98, 'Address already in use')
This error is because the port is already in use, maybe you have another instance already running?

i'll have a look when i get back into linux......

(spending the day in windows doing various things in flash)

[RYX]

(spending the day in windows doing various things in flash)
Ever heard of the FREE Flex SDK from Adobe? Entirely written in Java so working on any platform ... includes ActionScript3-compiler. Also a nice first step into programming - and once you understand what ActionScript3 can do you'll never use that boring Flash IDE again ;) ... (and can safely get rid of Windows :D ...)

It would be much more useful to NOT use any proprietary Windows-format (FLA) for a compiz-config tool, right? If you write it in plain Actionscript it would be your first own open-source application :D ...

(EDIT: And you could be sure that I would help you with that - but it would mean rewrite from scratch :) ...)

:)

[maniac]

Does that one work with Python 2.5 only? On 2.4 (Fedora Core 6), I get the following:


Traceback (most recent call last):
File "./cws.py", line 361, in ?
httpd = BaseHTTPServer.HTTPServer (server_address, compizRequestHandler)
File "/usr/lib/python2.4/SocketServer.py", line 330, in __init__
self.server_bind()
File "/usr/lib/python2.4/BaseHTTPServer.py", line 101, in server_bind
SocketServer.TCPServer.server_bind(self)
File "/usr/lib/python2.4/SocketServer.py", line 341, in server_bind
self.socket.bind(self.server_address)
File "<string>", line 1, in bind
socket.gaierror: (-2, 'Name or service not known')


Any clues?

[mikedee]

I am using 2.4 so it should work there

The error message looks like you do not have a hosts entry for localhost. What does 'ping localhost' output?

[maniac]

I am using 2.4 so it should work there

The error message looks like you do not have a hosts entry for localhost. What does 'ping localhost' output?
Yes, you are completely right, it was the missing hosts entry. Thanks!

This stuff definitely has potential ;)

[delfick]

(spending the day in windows doing various things in flash)
Ever heard of the FREE Flex SDK from Adobe? Entirely written in Java so working on any platform ... includes ActionScript3-compiler. Also a nice first step into programming - and once you understand what ActionScript3 can do you'll never use that boring Flash IDE again ;) ... (and can safely get rid of Windows :D ...)

If you write it in plain Actionscript it would be your first own open-source application :D ...

(EDIT: And you could be sure that I would help you with that - but it would mean rewrite from scratch :) ...)

:)

two problems there

a) time :( :(....time is evil.....

b) expertise....i'm not good enough to write the whole thing in actionscript....and anyway,writing the whole thing in actionscript would be uncessary annoying :D

It would be much more useful to NOT use any proprietary Windows-format (FLA) for a compiz-config tool, right?

proprietary is overrated :P :D

[delfick]

i got it to work :D !!!!!!!!!!!!!!!!!!!

i had extracted everything into the .compiz folder, rather than just the cws folder...


I'M LOVING THIS !! :D

also, how do i give it a favicon so that i know which bookmark it is (i have all my bookmarks at the top right of the browser, with no text ...)

[mikedee]

also, how do i give it a favicon so that i know which bookmark it is (i have all my bookmarks at the top right of the browser, with no text ...)

I have just uploaded a new version which has a favicon (you can change it if you want)

Remember to clear your cache or it will not show up

[delfick]

also, how do i give it a favicon so that i know which bookmark it is (i have all my bookmarks at the top right of the browser, with no text ...)

I have just uploaded a new version which has a favicon (you can change it if you want)

Remember to clear your cache or it will not show up

thnx :D

[delfick]

is it possible to export my beryl settings straight to compiz ?? :D

[mikedee]

is it possible to export my beryl settings straight to compiz ?? :D

Afraid not :(

[delfick]

is it possible to export my beryl settings straight to compiz ?? :D

Afraid not :(

damn..... thought so.....oh well..life goes on :D

[franzrogar]

Probably a stupid question:

I use compiz git & have compiled the -extras (13-april-07) and cws complains that my "This plugin is not supported by your currrent version of Compiz" :?

Maybe cws is outdated?

[mikedee]

Probably a stupid question:

I use compiz git & have compiled the -extras (13-april-07) and cws complains that my "This plugin is not supported by your currrent version of Compiz" :?

Maybe cws is outdated?

The plugin must be outdated in your ~/.compiz/plugins/ directory or there is another version in /usr/lib/compiz which you have to remove. The unsupported message is just what compiz is telling me so cws does not have much to do with it.

[franzrogar]

Probably a stupid question:

I use compiz git & have compiled the -extras (13-april-07) and cws complains that my "This plugin is not supported by your currrent version of Compiz" :?

Maybe cws is outdated?

The plugin must be outdated in your ~/.compiz/plugins/ directory or there is another version in /usr/lib/compiz which you have to remove. The unsupported message is just what compiz is telling me so cws does not have much to do with it.
That's not probable because I installed Debian yesterday and compiled evrything one. Anyway, I deleted evrything on lib/compiz & .compiz/plugins but still persits.

I had them loaded with gconf and they're on. If I select "unload", then, the plugins became "not supported" even when they were working in the same session.

[RYX]

I can confirm that - unloaded plugins appear as "not supported" ...

[mikedee]

Probably a stupid question:

I use compiz git & have compiled the -extras (13-april-07) and cws complains that my "This plugin is not supported by your currrent version of Compiz" :?

Maybe cws is outdated?

The plugin must be outdated in your ~/.compiz/plugins/ directory or there is another version in /usr/lib/compiz which you have to remove. The unsupported message is just what compiz is telling me so cws does not have much to do with it.
That's not probable because I installed Debian yesterday and compiled evrything one. Anyway, I deleted evrything on lib/compiz & .compiz/plugins but still persits.

I had them loaded with gconf and they're on. If I select "unload", then, the plugins became "not supported" even when they were working in the same session.

Thats very strange, what is output when you type in this command (replace png with a plugin which does not work)

dbus-send --print-reply --type=method_call --dest=org.freedesktop.compiz /org/freedesktop/compiz org.freedesktop.compiz.getPluginMetadata string:'png'

EDIT : Also what is output in your browser if you click this url (again replace png with a plugin which does not work)

http://localhost:8899/?method=getPluginMetadata&plugin=png

[franzrogar]

The command one output is:


method return sender=:1.3 -> dest=:1.10
string "blur"
string "Blur Windows"
string "Blur windows"
boolean true
array [
string "before:video"
]
array [
string "blur"
]


And web over "blur":

{"name":"blur","shortDesc":"Blur Windows","longDesc":"Blur windows","supportedABI":"True","deps":["before:video",""],"features":["blur",""]}


I think the problem is that cws tends to think that if they're not loaded on gconf, then, they're "not supported". So, when you "unload" any plugin, it becames "not supported" too.

[mikedee]

Thanks, thats the information I needed :)

I have uploaded a new version, can you try that and send the web information again if it still does not work.

[franzrogar]

Great! It works perfect now :)

Loading/unloading works for each plugin in -core & -extras.

EDIT:

Wrong.

I deleted from gconf entries one plugin and now, cws is not listing any plugins in left list...

[franzrogar]

This is whay cws says:


localhost - - [14/Apr/2007 00:20:01] "GET /cws-static/http.js HTTP/1.1" 200 -
localhost - - [14/Apr/2007 00:20:01] "GET /cws-static/header.gif HTTP/1.1" 200 -
Introspect error: The name org.freedesktop.compiz was not provided by any .servi ce files
----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 45810)
Traceback (most recent call last):
File "SocketServer.py", line 222, in handle_request
self.process_request(request, client_address)
File "SocketServer.py", line 241, in process_request
self.finish_request(request, client_address)
File "SocketServer.py", line 254, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "SocketServer.py", line 521, in __init__
self.handle()
File "BaseHTTPServer.py", line 316, in handle
self.handle_one_request()
File "BaseHTTPServer.py", line 310, in handle_one_request
method()
File "/usr/bin/cws.py", line 54, in do_GET
self.handle_root_request (query_data)
File "/usr/bin/cws.py", line 165, in handle_root_request
plugins = self.dbus.call_method (self.compiz_dbus_root, 'getPlugins', None)
File "/usr/bin/cws.py", line 352, in call_method
return func ()
File "/var/lib/python-support/python2.4/dbus/proxies.py", line 25, in __call__
ret = self._proxy_method (*args, **keywords)
File "/var/lib/python-support/python2.4/dbus/proxies.py", line 102, in __call_ _
reply_message = self._connection.send_with_reply_and_block(message , timeout)
File "dbus_bindings.pyx", line 455, in dbus_bindings.Connection.send_with_repl y_and_block
DBusException: The name org.freedesktop.compiz was not provided by any .service files
----------------------------------------
Introspect error: The name org.freedesktop.compiz was not provided by any .servi ce files
----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 45811)
Traceback (most recent call last):
File "SocketServer.py", line 222, in handle_request
self.process_request(request, client_address)
File "SocketServer.py", line 241, in process_request
self.finish_request(request, client_address)
File "SocketServer.py", line 254, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "SocketServer.py", line 521, in __init__
self.handle()
File "BaseHTTPServer.py", line 316, in handle
self.handle_one_request()
File "BaseHTTPServer.py", line 310, in handle_one_request
method()
File "/usr/bin/cws.py", line 54, in do_GET
self.handle_root_request (query_data)
File "/usr/bin/cws.py", line 177, in handle_root_request
plugins = self.dbus.call_method (active_path, 'get', None)
File "/usr/bin/cws.py", line 352, in call_method
return func ()
File "/var/lib/python-support/python2.4/dbus/proxies.py", line 25, in __call__
ret = self._proxy_method (*args, **keywords)
File "/var/lib/python-support/python2.4/dbus/proxies.py", line 102, in __call_ _
reply_message = self._connection.send_with_reply_and_block(message , timeout)
File "dbus_bindings.pyx", line 455, in dbus_bindings.Connection.send_with_repl y_and_block
DBusException: The name org.freedesktop.compiz was not provided by any .service files
----------------------------------------


Seems the same issue that you talked about here (http://forum.compiz.org/viewtopic.php?p=7071#7071) ;)

[delfick]

some plugins don't stay loaded after i load them via cws ......

for example, scale, showdesktop, widget, resize....

they stay loaded untill i restart compiz and then they're no longer loaded

[mikedee]

some plugins don't stay loaded after i load them via cws ......

for example, scale, showdesktop, widget, resize....

they stay loaded untill i restart compiz and then they're no longer loaded

What backend are you using?

Check the ini file or gconf-editor to see if active plugins actually changes.

I have only checked this in Firefox and it may not work properly in other browsers. If it is showing you the options then the plugin was almost certainly loaded.

[mikedee]

@franzrogar - you must make sure that at least dbus and gconf are loaded before it will work. Those errors mean the dbus plugin is not loaded

[franzrogar]

mikedee, you were right again but the weirder thing is that I didn't unloaded it :? So that's why I thought it was just like that post.

@delfick They stay loaded for me too. I use Epiphany on Debian Etch. Well, in honour of truth, I couldn't check them all 'cause some of them simply breaks compiz. (as ex desktopclick, which restarts compiz, and mousegestures, which do nothing at all :? )

[delfick]

some plugins don't stay loaded after i load them via cws ......

for example, scale, showdesktop, widget, resize....

they stay loaded untill i restart compiz and then they're no longer loaded

What backend are you using?

Check the ini file or gconf-editor to see if active plugins actually changes.

I have only checked this in Firefox and it may not work properly in other browsers. If it is showing you the options then the plugin was almost certainly loaded.

well...i checked and....does it matter if i have both gconf and ini in the active plugins thingo in gconf ??

also, i tested to see if resize would come up in gconf (in active_plugins) and well.....it seemed to load and work fine (mind you, after resizing the window with it, i had to left click it for the window to become a different size) and then my computer froze....the mouse was still movable but i couldn't do anything.....even the restart button on the computer wouldn't work *wtf?*

but anyway, i have work to get done, so i won't be able to play with that for today....

[mikedee]

well...i checked and....does it matter if i have both gconf and ini in the active plugins thingo in gconf ??

Yeah - its probably best to have only one :)

[delfick]

well...i checked and....does it matter if i have both gconf and ini in the active plugins thingo in gconf ??

Yeah - its probably best to have only one :)

ok then, i just got rid of "ini"

now when i load a plugin, it appears in the active_plugins list

but then when i restart compiz, it disapears from the list...

[mikedee]

well...i checked and....does it matter if i have both gconf and ini in the active plugins thingo in gconf ??

Yeah - its probably best to have only one :)

ok then, i just got rid of "ini"

now when i load a plugin, it appears in the active_plugins list

but then when i restart compiz, it disapears from the list...

How are you actually starting compiz? Go to a terminal and type compiz --replace gconf & and then check again. You are probably starting compiz --replace ini, but your general-allscreens file has gconf in it too. Otherwise I cannot see how this would happen.

[delfick]

well...i checked and....does it matter if i have both gconf and ini in the active plugins thingo in gconf ??

Yeah - its probably best to have only one :)

ok then, i just got rid of "ini"

now when i load a plugin, it appears in the active_plugins list

but then when i restart compiz, it disapears from the list...

How are you actually starting compiz? Go to a terminal and type compiz --replace gconf & and then check again. You are probably starting compiz --replace ini, but your general-allscreens file has gconf in it too. Otherwise I cannot see how this would happen.

i'll see about starting compiz via terminal next time i'm in linux

as for currently, i'm starting it via the beryl manager...

[delfick]

it doesn't seem to work anymore :(

(oh yeah, i don't read the forums anymore, so i probably won't see replies to this ...)

[mikedee]

I have just fixed the dbus plugin in core so this should work again.

If you use python as well then you should update that too because there was a small bug there too.

[mikedee]

Now in git! There is a slight modification, but nothing serious

git-clone git://people.freedesktop.org/~mike/cws

Git web is available here

http://gitweb.freedesktop.org/?p=users/mike/python.git;a=summary

[delfick]

Now in git! There is a slight modification, but nothing serious

cool :D

......

[delfick]

ok then, so how do i use cws to get

the names of the groups
the names of the plugins in each group
determine wether a specific plugin is enabled or not
tell the server wether a plugin has been enabled or not

??

[mikedee]

the names of the groups

This would need dbus to be modified to read the internal metadata (NOT THE XML FILES!!). I haven't bothered yet, but it will probably be added at some point.

Personally I dont know why you would want to read the groups anyway, they are only there so that ccsm could be written with the least possible effort. As a few people have pointed out, it does not make for a good GUI because options are repeated and there are just waaaayy too many

If I were you I would DESIGN it to be usable, not quick to code. Otherwise you will just end up with a crappy flash version of ccsm (nobody wants that).

Remember that you never need to know what backend is being used, it only needs dbus to be loaded and the backend does not matter. If your code directly accesses the backend storage then it is broken.

the names of the plugins in each group

See rant above above :)

determine wether a specific plugin is enabled or not

Read the general/allscreens/active_plugins list and check for the plugin you are interested in.

tell the server wether a plugin has been enabled or not

The server == compiz so as they say, in Soviet Russia, the server TELLS YOU!

There is a loadPlugin method (or something like that) so you can load and unload plugins, it tries to get the ordering right, but since that was removed it probably does not work (the ordering that is, it will just add them at the end). An alternative is to just modify active_plugins directly.

There are dbus signals sent when options change (plugins loading is just the active_plugins option changing) so you can get this information, the problem is translating it from dbus to HTTP. It would need HTTP push in the server and I havent bothered with that yet. You can get the same effect by polling the option you want to check, if you manage to get something running then I will look at adding this, hows that ;)

[delfick]

Personally I dont know why you would want to read the groups anyway, they are only there so that ccsm could be written with the least possible effort. As a few people have pointed out, it does not make for a good GUI because options are repeated and there are just waaaayy too many

If I were you I would DESIGN it to be usable, not quick to code. Otherwise you will just end up with a crappy flash version of ccsm (nobody wants that).

i need the groups (we are talking about plugin categories right?) because that's how the flash thing is laid out

what i have so far is found here http://delfick.storage.googlepages.com/flashbsm.zip

Remember that you never need to know what backend is being used, it only needs dbus to be loaded and the backend does not matter. If your code directly accesses the backend storage then it is broken.

that's why i want to know how to use cws with flash

determine wether a specific plugin is enabled or not

Read the general/allscreens/active_plugins list and check for the plugin you are interested in.

read it from where?

tell the server wether a plugin has been enabled or not

The server == compiz so as they say, in Soviet Russia, the server TELLS YOU!

There is a loadPlugin method (or something like that) so you can load and unload plugins, it tries to get the ordering right, but since that was removed it probably does not work (the ordering that is, it will just add them at the end). An alternative is to just modify active_plugins directly.

There are dbus signals sent when options change (plugins loading is just the active_plugins option changing) so you can get this information, the problem is translating it from dbus to HTTP. It would need HTTP push in the server and I havent bothered with that yet. You can get the same effect by polling the option you want to check, if you manage to get something running then I will look at adding this, hows that ;)

ok then.............
(though to be sure, get what running exactly?)

thnx :D

[mikedee]

Personally I dont know why you would want to read the groups anyway, they are only there so that ccsm could be written with the least possible effort. As a few people have pointed out, it does not make for a good GUI because options are repeated and there are just waaaayy too many

If I were you I would DESIGN it to be usable, not quick to code. Otherwise you will just end up with a crappy flash version of ccsm (nobody wants that).

i need the groups (we are talking about plugin categories right?) because that's how the flash thing is laid out

what i have so far is found here http://delfick.storage.googlepages.com/flashbsm.zip

Look at this as a configuration tool objectively rather than looking at how you can tweak all the options. I would say that over 50% of the plugins do not need their own tab, most of them never need to be mentioned at all and they only serve to confuse the user.

ini/gconf - Why would a user change this at all? Why would they care? The backend is chosen by the start script and is not relevant to them at all once things are started up. Having this as an option will only make it harder to use.
png/jpeg/text - Again why do they care? If they choose a jpeg image for anything then the config tool should be clever enough to make sure that the correct plugins are loaded and available. If someone checks the 'show text on thumbnails option' then it should load text for them. If text is not available then the option should be grayed with some message saying how to enable it (preferably an autodownload/install).

Then we have duplication of things which make no sense unless you know why they happen.

Background images - They can be set in cube but if you change cube to wall then they will stop working, even then you have to do some voodoo to make it work. Make the config app disable the current background manager if necessary.
Window snapping - Enable it in wobbly, unless you dont use wobbly, in which case enable the snap plugin, changes to the snap plugin may have strange effects if you have it enabled in wobbly. If you disable snap and snapping still happens, check the wobbly snapping option under wobbly -> accessibility -> key bindings -> snap windows on moving.... Yeah - right

Remember that you never need to know what backend is being used, it only needs dbus to be loaded and the backend does not matter. If your code directly accesses the backend storage then it is broken.

that's why i want to know how to use cws with flash

You will need to work out how to send http requests to the server, in the html version I use the HTTPRequest object, I think there is something similar in action script (?)...

This might be useful, you can probably find some examples of use somewhere else.

http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/net/package-detail.html

read it from where?

http://localhost:8899/?method=getActivePlugins

OR

http://localhost:8899/core/allscreens/active_plugins?method=get

You have to get actionscript to get this url and the result is a comma separated list.

(though to be sure, get what running exactly?)

Anything that works really ;)

[delfick]

Look at this as a configuration tool objectively rather than looking at how you can tweak all the options. I would say that over 50% of the plugins do not need their own tab, most of them never need to be mentioned at all and they only serve to confuse the user.

ini/gconf - Why would a user change this at all? Why would they care? The backend is chosen by the start script and is not relevant to them at all once things are started up. Having this as an option will only make it harder to use.
png/jpeg/text - Again why do they care? If they choose a jpeg image for anything then the config tool should be clever enough to make sure that the correct plugins are loaded and available. If someone checks the 'show text on thumbnails option' then it should load text for them. If text is not available then the option should be grayed with some message saying how to enable it (preferably an autodownload/install).

as simple as removing it from the plugins.xml file in the xml folder.....

for example, put this plugins.xml (http://delfick.storage.googlepages.com/plugins.xml) file into the xml folder and refresh flashbsm.html

I plan on making that configurable within the thing itself

though anything on this will take a long time because
a) I have very basic programming "skills"
b) i don't leave much time for this
c) i start uni again next week

Then we have duplication of things which make no sense unless you know why they happen.

Background images - They can be set in cube but if you change cube to wall then they will stop working, even then you have to do some voodoo to make it work. Make the config app disable the current background manager if necessary.
Window snapping - Enable it in wobbly, unless you dont use wobbly, in which case enable the snap plugin, changes to the snap plugin may have strange effects if you have it enabled in wobbly. If you disable snap and snapping still happens, check the wobbly snapping option under wobbly -> accessibility -> key bindings -> snap windows on moving.... Yeah - right

i'm gonna get it to act like the ccsm and get all the options for all plugins before i start playing around with making it more specialised....which if it works out as i intend, will just involve editing the plugins.xml.....

Remember that you never need to know what backend is being used, it only needs dbus to be loaded and the backend does not matter. If your code directly accesses the backend storage then it is broken.

that's why i want to know how to use cws with flash

You will need to work out how to send http requests to the server, in the html version I use the HTTPRequest object, I think there is something similar in action script (?)...

i believe so............

This might be useful, you can probably find some examples of use somewhere else.

http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/net/package-detail.html

hmm, yes it will be helpful when i convert to actionscript 3, which i plan to do one day, but not for a long time :P

read it from where?

http://localhost:8899/?method=getActivePlugins

OR

http://localhost:8899/core/allscreens/active_plugins?method=get

thought that's what you meant

You have to get actionscript to get this url and the result is a comma separated list.

ok then, i was unsure how exactly flash could read it but i'll look up how flash can read comma seperated list and i'm sure i'll figure it out...

(though to be sure, get what running exactly?)

Anything that works really ;)

fair enough :D

[RYX]

How about this XML-layout:<config>
<groups>
<group name="Effects" icon="group-effects">
<description>Plugins that produce eyecandy effects...</description>
<plugin name="3D Windows" icon="3d">
<description>Elevates windows while rotating the cube</description>
<options>
<tab name="Corner Bevelling">
</tab>
<tab name="Misc. Options">
</tab>
</options>
</plugin>

</group>

</groups>
</config>

This is more easy to parse and better ogranizing things within the XML. Having the groups and the plugins separated is a bit suboptimal.

:)

[delfick]

How about this XML-layout:<config>
<groups>
<group name="Effects" icon="group-effects">
<description>Plugins that produce eyecandy effects...</description>
<plugin name="3D Windows" icon="3d">
<description>Elevates windows while rotating the cube</description>
<options>
<tab name="Corner Bevelling">
</tab>
<tab name="Misc. Options">
</tab>
</options>
</plugin>

</group>

</groups>
</config>

This is more easy to parse and better ogranizing things within the XML. Having the groups and the plugins separated is a bit suboptimal.

:)

fair enough, i shall do that...

I'm gonna start to learn php now, and i find i learn better by doing something with the language and learning as i need some function from that language, it's one of the reasons i'm doing the flashbsm, so i can learn AS2 .....

so when i know enough php to make a php script to make the plugins.xml (currently use the tracer.fla as explained by the readme) i'll remake the plugins.xml as you've suggested....

[delfick]

hehehe, far from elegant but it works :D

MyVars = new LoadVars ();
MyVars.load ('http://localhost:8899/?method=getActivePlugins');
MyVars.onLoad = function () {
var string = new String(this.toString().split("%2C").join(",").split("%22").join("").split("%20").join("").split("%5B").join("").split("%5D").join("").split(",\"\"=&onLoad=typeFunction")+"\"test\"")
var myArray = string.split(",")
trace(myArray[5])
};

[RYX]

I just wondered if you'll need to receive the options at all. If you dynamically generate the UI from the XML, you'll have no need to retrieve options from compiz directly. You just offer a fully user-configurable UI with some different XML-files as profiles/setups and the necessary background-stuff to apply options to compiz (using cws) whenever a user makes changes within the UI ... (maybe you have to connect to signals in compiz for being able to update your inputs when options are changed from the outside, but that can be added later).

You could alternatively receive the complete list of options using a small script and then auto-generate the full list of options and create some sort of "complete"-setup in form of another XML-file.

The difficult task of all this is to create a dynamically generated UI, but there are always the default components and input-elements so it shouldn't be very hard even for a beginner.

:)

[delfick]

If you dynamically generate the UI from the XML, you'll have no need to retrieve options from compiz directly.

exactly :D

[RYX]

Even though you maybe should add it as an alternative option. It would be good if one could just synchronize the GUI with compiz without changing any XML, which should be no problem at all. You could just add a button which allows completely recreating the UI according to the list you retrieved from compiz. But it should be described as an advanced feature for people who know what they do, because the live-retrieved options are not (may not be) completely compatible and optimized to work with the dynamic UI (as mikedee explained above).

:)

[RYX]

I think ideally such a tool should be configurable in a way that a distributor/packager/user could add his own XML-file with the settings he wants to offer and then use a small host-application that displays the flash-movie inside a normal application window (or shows a JavaScript-popup noting that flashplayer isn't installed and how to get it). Maybe he should be able to add his own background-image to make it even more personal ... That way everyone could create his very own settings-tool without any programming knowledge. (I think I start to like this idea ... unfortunately I have no time for it either)

:)

[delfick]

I think ideally such a tool should be configurable in a way that a distributor/packager/user could add his own XML-file with the settings he wants to offer and then use a small host-application that displays the flash-movie inside a normal application window (or shows a JavaScript-popup noting that flashplayer isn't installed and how to get it). Maybe he should be able to add his own background-image to make it even more personal ... That way everyone could create his very own settings-tool without any programming knowledge. (I think I start to like this idea ... unfortunately I have no time for it either)

:)

nice idea :D

also, i've sort of got it to load with the correct plugins enabled (according to what cws tells it, otherwise it does it randomly), but it's playing up a little...but i'm too tired and i've got the fifth cold since october last year (tee exams didn't leave me a very well person) so i should probably go sleep now.....

[delfick]

an idea has occurred to me....

how hard would it be for you to add another method to cws that creates an xml file containing the information for each plugin as i'm trying to get for the flashbsm thingo ??

such as

?method=createMetadataFile&file=~/.compiz/cws/plugins.xml

?? :D

so that if my flashbsm doesn't find a plugins.xml file, it can tell the cws to create one....

and I doubt some scabby php script going though these random xml files will be quite as good.....

[RYX]

You should generate the XML yourself from the data you get from cws (by simply looping through the list of plugins and through the screen-/display-options for each plugin). You may need additional tags or attributes for your UI-creation so it is wise to have full control over the data (i.e. the XML) you use to generate your UI from (e.g. you may want to add special attributes only available to your UI, like callbacks or other nice things).

You _could_ also use the metadata to generate your UI from, but you will be limited to a fairly poor subset of tags and attributes some people chose for you ... (I personally dislike certain naming conventions within the metadata, but it is up to everyone's taste)

:)

[delfick]

You should generate the XML yourself from the data you get from cws (by simply looping through the list of plugins and through the screen-/display-options for each plugin). You may need additional tags or attributes for your UI-creation so it is wise to have full control over the data (i.e. the XML) you use to generate your UI from (e.g. you may want to add special attributes only available to your UI, like callbacks or other nice things).

You _could_ also use the metadata to generate your UI from, but you will be limited to a fairly poor subset of tags and attributes some people chose for you ... (I personally dislike certain naming conventions within the metadata, but it is up to everyone's taste)

:)

at least to make a file to start from

because it is currently very annoying having to get everything from all over the place....

and anyway, changing names and stuff and adding "fake plugins" would have to be done by hand......

but if i could get a base file to work from that would make it so much easier.......

[RYX]

What do you need? You are not sure how to layout the XML-file? Or do you have problems with creating the XML from the data you receive from cws?

It should be like this (at least in theory :)):- retrieve list of plugins from cws
- open your "<config>"-tag
- start a loop and loop through the names of the plugins:
- open your "<plugin>"-tag
- get list with names of options for plugin from cws (at least two times, once for display, once for screen0)
- open your "<display>"/"<screen0>" tag
- start a loop and loop through the options:
- get info/metadata about option from cws
- build your XML-tag for the option (name/type/desc/default/min/max/...)
- add your "<option>"-tag
- (maybe add list-items or choices)
- close your "<display>"/"<screen*>"-tag
- close your "<plugin>"-tag
- close your "<config>"-tag

This is only a rough outline of what should happen, I can't guarantee that it works like that (it did a while ago) :D ...

(Though I think maybe Mike should really add a getMetadata-action for the sake of completeness)

:)

[RYX]

And I think you don't need to receive any options at all, you should rely on the XML-files. You could auto-generate your first XML-file containing all compiz-options from all plugins, but I'd recommend using a python-script for that instead of doing it through cws (I can write that for you, I guess).

You should only use cws for applying options/commands, not for retrieving them. I think it should make it easier for you and you can focus on the important (fun-)stuff (like dynamic UI-creation) and don't have to redo existing things again.

:)

[delfick]

i already know how to create the xml file and i already have with actionscript

but i can't be bothered to converting it to php (uni started again, and i'm a slow self-learner) and trying to collect the information from both the xml files in /usr/local/share/compiz and the global.xml file in /usr/local/share/compizconfig just seems dodgy, which is why having cws create the file seems less dodgy

the actionscript i was talking about can be found here http://docs.google.com/Doc?id=dhk9csv4_235cbtzbk

[delfick]

but I'd recommend using a python-script for that instead of doing it through cws (I can write that for you, I guess).

if you could, that'd be awsome :D

i don't really care how the base plugins.xml file is made.....

and you can focus on the important (fun-)stuff (like dynamic UI-creation) and don't have to redo existing things again.

well that's pretty much already done, all i have to do now is populate the settings area which i'm gonna start attempting to do some time.....

it hopefully shouldn't take too long, but seeing as uni just started and my "skills" in programming are still very basic, it'll won't be a two minute job for me :D (but i'm not rushing here, so it's all good)

[delfick]

but I'd recommend using a python-script for that instead of doing it through cws (I can write that for you, I guess).

something like this would be desirable http://docs.google.com/Doc?id=dhk9csv4_236gnn2cs

[RYX]

Here is a simple "option-dumper". for some reason it doesn't get the default-values (and restrictions, min, max, ...). I think, that since the new metadata-system, this info is no longer available through dbus ... but I hope it is only a temporary issue or another problem:

Run like "python compiz-dump.py > compiz-dump.xml" to generate the file. Dbus-plugin must be active.

compiz-dump.py#!/usr/bin/env python

# A little test of connecting compiz from python over dbus ...
# Should be a good base for creating a simple settings-manager in python.
#
# (by RYX) - can be used freely

import dbus

# for testing
DEBUG = False
# init service/interface
COMPIZ_DBUS_SERVICE = 'org.freedesktop.compiz'
COMPIZ_DBUS_INTERFACE = 'org.freedesktop.compiz'
COMPIZ_DBUS_OBJECT = '/org/freedesktop/compiz'

# get session bus
try:
bus = dbus.SessionBus()
except:
print "Error: Either dbus is unavailable, compiz isn't running or the dbus-plugin is not loaded."
import sys
sys.exit(1)

# utility function to call methods in compiz
def compiz_call (obj_path, func_name, *args):
"""Call method in obj_path in compiz-service over dbus. The compiz-object's
path does not need to be passed."""
path = COMPIZ_DBUS_OBJECT
if obj_path:
path += '/' + obj_path
obj = bus.get_object(COMPIZ_DBUS_SERVICE, path)
iface = dbus.Interface(obj, COMPIZ_DBUS_INTERFACE)
func = getattr(iface, func_name)
if func:
try:
return func(*args)
except Exception, ex:
if DEBUG:
print "compiz_call('" + obj_path + "'): Dbus-error: " + str(ex)
return None


# open outer tag
print '<config>'
# open plugins-tag
#print ' <plugins>'
# get list of plugins and loop over it
plugins = ['core']
plugins.extend(compiz_call('', 'getPlugins'))
for p in plugins:
# open plugin-tag
if p != 'core':
print ' <plugin name="%s">' % p
else:
print ' <core>'
# get metadata for a specific plugin
p_meta = compiz_call('', 'getPluginMetadata', p)
if p_meta:
print ' <short>%s</short>' % p_meta[1]
print ' <long>%s</long>' % p_meta[2]
# loop through all screens
for s in ('allscreens', 'screen0'):
# get list of options from plugin
try:
p_options = compiz_call(p + '/' + s, 'list')
except:
p_options = None
# if we have options, show tag for screenX
if p_options:
# open screen-tag
print ' <' + s + '>'
for o in p_options:
# get meta for option
o_meta = compiz_call(p + '/' + s + '/' + o, 'getMetadata')
if o_meta:
print ' <option name="%s" type="%s">' % (o, o_meta[2])
print ' <short>%s</short>' % o_meta[0]
print ' <long>%s</long>' % o_meta[1]
print ' </option>'
# close screen-tag
print ' </' + s + '>'
# close plugin-tag
if p != 'core':
print ' </plugin>'
else:
print ' </core>'
# open plugins-tag
#print ' </plugins>'
# close outer tag
print '</config>'

[delfick]

tha'ts a good start, thankyou

[RYX]

No problem :D ... The groups have to be added manually because compiz doesn't offer them (but that should be obvious) ...

[delfick]

No problem :D ...

:D :D

The groups have to be added manually because compiz doesn't offer them (but that should be obvious) ...

then how do the plugin.xml and global.xml files know the categories?

[RYX]

The groups have to be added manually because compiz doesn't offer them (but that should be obvious) ...
then how do the plugin.xml and global.xml files know the categories?
Because you type them in there :D ...

You need to create the groups by hand, shouldn't be really difficult - just select a block of code, hit tab to indent the block, add a <group>-tag around it and you have a group ... Compiz has no groups by default (yeah, well ... in the metadata it has, but you want your own ones, right?).

(I have still no clue about the default values and min/max/... - let me know if you find out, I need that, too :D)

:)

[delfick]

The groups have to be added manually because compiz doesn't offer them (but that should be obvious) ...
then how do the plugin.xml and global.xml files know the categories?
Because you type them in there :D ...

no, i'm talking about the xml files in /usr/local/share/compiz and the global.xml file in /usr/local/share/compizconfig, how do they know the categories?

[RYX]

Maybe because someone else added them. I don't really know where those files come from ... Most likely ccs. The groups never came from compiz because it makes no sense for compiz to group its plugins. It is entirely the configuration system's job to group the plugins, so you should use your freedom as a developer and add your very own idea of grouping the plugins ... please not adopt too much from that crappy/cryptic complicated/confusing stuff/**** ...

:D

[delfick]

Maybe because someone else added them. I don't really know where those files come from ... Most likely ccs. The groups never came from compiz because it makes no sense for compiz to group its plugins. It is entirely the configuration system's job to group the plugins, so you should use your freedom as a developer and add your very own idea of grouping the plugins ... please not adopt too much from that crappy/cryptic complicated/confusing stuff/**** ...

:D

ok then.......

how about we make a seperate xml list as well along the lines of

<group>group1Name</group>
<plugin>plugin1Name</plugin>
<plugin>plugin2Name</plugin>
<plugin>plugin3Name</plugin>
<plugin>plugin4Name</plugin>
</group>
<group>group2Name</group>
<plugin>plugin1Name</plugin>
<plugin>plugin2Name</plugin>
<plugin>plugin3Name</plugin>
<plugin>plugin4Name</plugin>
</group>
<group>group3Name</group>
<plugin>plugin1Name</plugin>
<plugin>plugin2Name</plugin>
<plugin>plugin3Name</plugin>
<plugin>plugin4Name</plugin>
</group>


that your python script goes through to determine the groups......

[mikedee]

Especially at a time when they are slowly realising that if you want something good, you cannot make it autogenerated. I notice a few people complaining that ccsm has too many options and that it is not user friendly because there are so many plugins. I think you should totally forget that compiz has plugins if you want to create a decent settings gui. The users simply do not understand or care about the fact that everything is a plugin, that is just a technical point. Users just want a dropdown to choose between cube and wall (for example).

Just my 2 cents anyway ;)

[delfick]

Especially at a time when they are slowly realising that if you want something good, you cannot make it autogenerated. I notice a few people complaining that ccsm has too many options and that it is not user friendly because there are so many plugins. I think you should totally forget that compiz has plugins if you want to create a decent settings gui. The users simply do not understand or care about the fact that everything is a plugin, that is just a technical point. Users just want a dropdown to choose between cube and wall (for example).

Just my 2 cents anyway ;)

agreed.......

autogeneration is good as a base to a settings gui, but when there are too many options, it's good to manually cut down on that base.....

though mind you, ccsm is incredibally better than some settings frontend i've seen, such as what is used by litestep http://www.litestep.net/index.php *shudders* :D

[maniac]

Maybe because someone else added them. I don't really know where those files come from ... Most likely ccs. The groups never came from compiz because it makes no sense for compiz to group its plugins. It is entirely the configuration system's job to group the plugins,

The groups for core plugins come from global.xml, installed by ccs.


please not adopt too much from that crappy/cryptic complicated/confusing stuff/**** ...
:D
No comment. You think it's funny to insult other people's work? :(

[maniac]

Especially at a time when they are slowly realising that if you want something good, you cannot make it autogenerated. I notice a few people complaining that ccsm has too many options and that it is not user friendly because there are so many plugins. I think you should totally forget that compiz has plugins if you want to create a decent settings gui. The users simply do not understand or care about the fact that everything is a plugin, that is just a technical point. Users just want a dropdown to choose between cube and wall (for example).

Just my 2 cents anyway ;)
NACK - at least partially. Autogenerated SM definitely aren't suited for _everybody_, but they are suited for a number of people. There should be more than one type of settings manager, as there is more than one user type (novice / experienced / geek). Eventually, there should be one SM per user type, but as Rome wasn't built in one day, it makes no sense to have 5 half finished settings managers.
Noone ever said autogenerated SM are the sorcerer's stone ;)

[RYX]

Maybe because someone else added them. I don't really know where those files come from ... Most likely ccs. The groups never came from compiz because it makes no sense for compiz to group its plugins. It is entirely the configuration system's job to group the plugins,

The groups for core plugins come from global.xml, installed by ccs.


please not adopt too much from that crappy/cryptic complicated/confusing stuff/**** ...
:D
No comment. You think it's funny to insult other people's work? :(
You know this is no real insult (maybe a bit teasing) and you know that ccs has some points that should be up to discussion (especially the name, the usefulness of replacing dbus and the usefulness of more language bindings than python). Why don't you just answer on my "CCSM and python-plugins"-post on oc.o instead so we can start working on making it more usable for everyone?
I can't use it because of that, so I can only say what I feel about it: it doesn't work for me and appears bloated and confusing, it's names are cryptic which makes it all complicated to understand. That's why that stuff still appears crappy to me. I don't know how I should say it otherwise ...

[maniac]

Maybe because someone else added them. I don't really know where those files come from ... Most likely ccs. The groups never came from compiz because it makes no sense for compiz to group its plugins. It is entirely the configuration system's job to group the plugins,

The groups for core plugins come from global.xml, installed by ccs.


please not adopt too much from that crappy/cryptic complicated/confusing stuff/**** ...
:D
No comment. You think it's funny to insult other people's work? :(
You know this is no real insult (maybe a bit teasing) and you know that ccs has some points that should be up to discussion (especially the name, the usefulness of replacing dbus and the usefulness of more language bindings than python). Why don't you just answer on my "CCSM and python-plugins"-post on oc.o instead so we can start working on making it more usable for everyone?

Do you have a link, please? I just didn't see it yet.
And what's the problem with the name? IMO "libcompizconfig" describes perfectly what it is.


I can't use it because of that, so I can only say what I feel about it: it doesn't work for me and appears bloated and confusing, it's names are cryptic which makes it all complicated to understand. That's why that stuff still appears crappy to me. I don't know how I should say it otherwise ...
There is a difference between _thinking_ something and yelling it out in the public. Surely we can talk about needed fixes/enhancements/..., but hearing "crappy", "bloated", "cryptic" just feels hostile to me, sorry.

[RYX]

Ok, I apologize for calling it "crappy". I don't mean to insult you or your work (you should know that I don't mean you personally). I had different ideas of a settings-lib, maybe because I just like it more simple and less complicated. However - besides the personal taste, the name is still a problem because "ccsm" and "ccp" are horrible names for anything ... communist-parties and -countries gave themselves familiar names in the past. Why don't you just call ccsm "compiz-config" or "compiz-config-manager" or "compiz-configuration" instead? You always mention other projects as example, so please do it as all other projects do and use descriptive names (e.g. "gnome-session-manager" isn't called "gsm").

The link to my ccsm/python-post is here (http://forums.opencompositing.org/viewtopic.php?f=16&t=1659) ... I really hope we can fix that problem together, instead of Patrick's "This just doesn't work and I don't care"-attitude ...

:)

[maniac]

Ok, I apologize for calling it "crappy". I don't mean to insult you or your work (you should know that I don't mean you personally).

I know you don't mean me personally, but after having written "please stop that" around 10 billion times I can't stand the feeling you want to provoke a bit here and there, which I find terribly annoying, because I like talking about the software itself better.


I had different ideas of a settings-lib, maybe because I just like it more simple and less complicated. However - besides the personal taste, the name is still a problem because "ccsm" and "ccp" are horrible names for anything ... communist-parties and -countries gave themselves familiar names in the past. Why don't you just call ccsm "compiz-config" or "compiz-config-manager" or "compiz-configuration" instead? You always mention other projects as example, so please do it as all other projects do and use descriptive names (e.g. "gnome-session-manager" isn't called "gsm").

Hmm, I think this is a matter of personal taste, too... I like better to type ccsm instead of typing compizconfig-settings-manager in the command line ;) Additionally, you'll find examples for both at other projects (example: "gdm" vs. "gnome-control-center"). Would you really suggest calling the ccp binary (==Compiz Configuration Plugin) "libcompiz-configuration-plugin.so"?
The "official" name of ccsm is "CompizConfig Settings Manager", with ccsm being the abbreviation. Maybe this should be communicated a bit better.


The link to my ccsm/python-post is here (http://forums.opencompositing.org/viewtopic.php?f=16&t=1659) ... I really hope we can fix that problem together, instead of Patrick's "This just doesn't work and I don't care"-attitude ...

Thanks, and already answered. And another example of the above mentioned provoking stuff :?

[mikedee]

Hmm...

You claim that ccsm is not suited for everyone and that you must address needs one at a time (which is obviously correct), but why on earth do you start with the advanced tool? All the propaganda that comes out of beryl says that you want to make things EASIER for new users to use, why didn't you atsrt with an easy to use tool rather than an easy to code one? You have spent over a year trying to get it right, but with little success (sorry if you think thats flaming/trolling/fud/whatever you call it these days) but it is my honest assessment.

ccsm is no more functional than gconf editor, and judging by the comments I hear its not too popular with the new users.

I think that ccpsm is way beyond offering fixes and improvements, the whole design is (like RYX says) complicated and over-engineered and I think you should go back to basic principles and work out what you want for users, rather than constantly trying to reinvent the wheel and trying to prove your ways are better.

[maniac]

Hmm...

You claim that ccsm is not suited for everyone and that you must address needs one at a time (which is obviously correct), but why on earth do you start with the advanced tool? All the propaganda that comes out of beryl says that you want to make things EASIER for new users to use, why didn't you atsrt with an easy to use tool rather than an easy to code one? You have spent over a year trying to get it right, but with little success (sorry if you think thats flaming/trolling/fud/whatever you call it these days) but it is my honest assessment.

It 's fine that it's your opinion. Everyone has a different opinion, as can be seen by delfick's statement above.
As long as Compiz is in its infancy, and as long as new plugins are popping up every few days, I don't think it makes sense to put too much effort into a hardcoded settings manager.


ccsm is no more functional than gconf editor, and judging by the comments I hear its not too popular with the new users.

If that was the case, noone would use it. There seem to be quite a number of people who use it, so there seem to be quite a number of people disagreeing with you.
I wish a lot of fun setting up animation's effect options in gconf-editor.


I think that ccpsm
Huh? What?

is way beyond offering fixes and improvements, the whole design is (like RYX says) complicated and over-engineered and I think you should go back to basic principles and work out what you want for users, rather than constantly trying to reinvent the wheel and trying to prove your ways are better.
Instead of telling us what we have to do, would you bother even answering my questions on the ML to your "simplification" suggestions? You think the stacking Compiz - libcompizconfig - python bindings - ccsm is complicated, I think the stacking compiz - dbus plugin - dbus python bindings - json - browser is complicated - so what? The only difference is that I don't scream out in the public that "cws is crappy, overengineered stuff".
You work on cws, we work on libcompizconfig, the future and users will tell which one they will like better. I see no problem with that.

[mikedee]

Instead of telling us what we have to do, would you bother even answering my questions on the ML to your "simplification" suggestions? You think the stacking Compiz - libcompizconfig - python bindings - ccsm is complicated, I think the stacking compiz - dbus plugin - dbus python bindings - json - browser is complicated - so what? The only difference is that I don't scream out in the public that "cws is crappy, overengineered stuff".
You work on cws, we work on libcompizconfig, the future and users will tell which one they will like better. I see no problem with that.

If you think it is too complicated then dont use it, compiz -> dbus -> gui is not complicated, but if you want offline settings then you can do gconf -> gui. It does not matter that people can change backend every day of the week. Reality check - I do not really care if people use cws at all, I just wrote it as a quick demo because it is easier than writing dbus bindings for flash. I am not promoting it as the official compiz config method. You can say what you like about it.

Simplification is all about the API not the internal mechanisms. Users and gui coders do not care or need to know about these things, there is no performance penalty. Instead they need an easy to use API to build tools with (thats why there isnt a mass of guis from the public - the API is complicated and undocumented, we have both tried to use it and that is our feeling).

People seem to have gotten the impression that the way to write a gui is by editing an xml metadata file, nobody ever mentions usability at all which is very sad to see.

I think this is why I never really bother to explain, your minds are already made up.... You do not seem to listen to your users at all who are crying out for an easier to use settings manager, they only use it because it is better than gconf-editor and they are told to use it (you could hardly manually edit Default.ini). Instead you are always coming up with excuses upon excuses as to why it is not perfect yet. It does not take over a year of > 4 people working part-time to make an easy to use gui. If this were a business I would be holding a very important meeting right now.

[maniac]

If you think it is too complicated then dont use it, compiz -> dbus -> gui is not complicated, but if you want offline settings then you can do gconf -> gui. It does not matter that people can change backend every day of the week. Reality check - I do not really care if people use cws at all, I just wrote it as a quick demo because it is easier than writing dbus bindings for flash. I am not promoting it as the official compiz config method. You can say what you like about it.

I just wanted to point out that the understanding of a design being complicated may differ between people.


People seem to have gotten the impression that the way to write a gui is by editing an xml metadata file, nobody ever mentions usability at all which is very sad to see.

Huh? Do you mean SmSpillaz? Besides him, I never saw anyone suggesting to combine the disadvantages of hardcoded and autogenerated settings managers.


I think this is why I never really bother to explain, your minds are already made up.... You do not seem to listen to your users at all who are crying out for an easier to use settings manager, they only use it because it is better than gconf-editor and they are told to use it (you could hardly manually edit Default.ini).

I can't write everything myself, the same applies to Dennis, Patrick and so on. If there is such an urgent need for an easy settings manager and it's so easy to write one, why didn't anyone bother writing _and_ constantly maintaining one?


Instead you are always coming up with excuses upon excuses as to why it is not perfect yet. It does not take over a year of > 4 people working part-time to make an easy to use gui. If this were a business I would be holding a very important meeting right now.
Time is limited. ccs is around 4 months old, with three people working several hours per week on it. What do you expect? It's easy to hack up a simple demo, but the devil is in the details. This is no business, this is open source development (reality check, hint hint).
And please, please try to realize that there is _not_ only one user type. You constantly are ignoring power users and mention novices only.

[mikedee]

If you think it is too complicated then dont use it, compiz -> dbus -> gui is not complicated, but if you want offline settings then you can do gconf -> gui. It does not matter that people can change backend every day of the week. Reality check - I do not really care if people use cws at all, I just wrote it as a quick demo because it is easier than writing dbus bindings for flash. I am not promoting it as the official compiz config method. You can say what you like about it.

I just wanted to point out that the understanding of a design being complicated may differ between people.

Sounded like you were creating a straw man, but like you say things differ between people ;)

Huh? Do you mean SmSpillaz? Besides him, I never saw anyone suggesting to combine the disadvantages of hardcoded and autogenerated settings managers.

I am not really sure what you mean by 'combine the disadvantages of hardcoded and autogenerated settings managers' sounds like another distraction. My point was that people feel that ccsm is not user-friendly and is complicated. My evidence is here.

http://forums.opencompositing.org/viewtopic.php?f=46&t=1647#p11309 - jug
http://forums.opencompositing.org/viewtopic.php?f=44&t=1682 - Fluxid, azathothgr
http://forums.opencompositing.org/viewtopic.php?f=16&t=1520 - phil, SmSpillaz

This is just a small sample, if you know anything about statistics, you will know that the number of unhappy users is MUCH higher. I have only taken a very quick rough poll of your forum. All these posts relate to general unhappiness about the complexity of ccsm.

I can't write everything myself, the same applies to Dennis, Patrick and so on. If there is such an urgent need for an easy settings manager and it's so easy to write one, why didn't anyone bother writing _and_ constantly maintaining one?

The big problem is that you do try to maintain everything yourselves, the backend storage methods, the communication layer.. everything is maintained by you even though you are reinventing the wheel. I think that if you and Dennis spent your time improving the existing systems for everyone rather than constantly rewriting everything then we would all be better off.

I think that bsm-- was an attempt as something more simple, unfortunately it was released just before the merge and was not ported (ironically if it was written to use dbus or gconf directly then it would still work without modifications)

And please, please try to realize that there is _not_ only one user type. You constantly are ignoring power users and mention novices only.

What I am saying is what are your goals? To write a settings gui for advanced users? To me it seems like the emphasis was on the new users (startup scripts, guis etc) so why start with the advanced users (who maybe only make up 10% of your target userbase). Trust me, advanced users are not using ccp ;)

[delfick]

It 's fine that it's your opinion. Everyone has a different opinion, as can be seen by delfick's statement above.
As long as Compiz is in its infancy, and as long as new plugins are popping up every few days, I don't think it makes sense to put too much effort into a hardcoded settings manager.

i'd have to agree with that

this is the reason we have autogenerated settings managers

because it was really really annoying back when settings managers were hardcoded (the original compiz-settings comes to mind, the one with eventually had like 20 tabs along the top) where if some new options were created, and the settings manager wasn't updated for quite a while, and so you had to use gconf anyways......

ccsm is good because it shows every option and no-one has to maintain it (it terms of updating what settings are there)

but unfortunately, some people want more specialised settings managers that combine settings of some plugins....

which goes back to the problem of maintaining when settings change

which seems to happen a lot with this project....

we have ccsm for every option, it is not meant to cater specialised settings

unless it could be made to see "fake plugins" like i plan for the flashbsm......

[maniac]

Huh? Do you mean SmSpillaz? Besides him, I never saw anyone suggesting to combine the disadvantages of hardcoded and autogenerated settings managers.

I am not really sure what you mean by 'combine the disadvantages of hardcoded and autogenerated settings managers' sounds like another distraction.

I meant that SmSpillaz proposes to put a static inter-plugin setting grouping into the XML. This combines the disadvantages of hardcoding (static inter-plugin option grouping, what happens if there is a new plugin whose options match an already existing group?) with the disadvantage of autogeneration (some option listing/sorting may look random).


My point was that people feel that ccsm is not user-friendly and is complicated. My evidence is here.

http://forums.opencompositing.org/viewtopic.php?f=46&t=1647#p11309 - jug
http://forums.opencompositing.org/viewtopic.php?f=44&t=1682 - Fluxid, azathothgr
http://forums.opencompositing.org/viewtopic.php?f=16&t=1520 - phil, SmSpillaz

This is just a small sample, if you know anything about statistics, you will know that the number of unhappy users is MUCH higher. I have only taken a very quick rough poll of your forum. All these posts relate to general unhappiness about the complexity of ccsm.

You take 5 posts as a sample for people in general being unhappy about CCSM? Are you kidding? If _you_ know anything about statistics, you will know that the percentage of unhappy people complaining (especially if you have people like jug who complain about almost everything) is much higher than the number of happy people writing that they are happy.


I think that bsm-- was an attempt as something more simple, unfortunately it was released just before the merge and was not ported (ironically if it was written to use dbus or gconf directly then it would still work without modifications)

Yeah, it would work, besides things like string lists with restrictions -> ints with descriptions and such. Every code degenerates if not maintained for some time.
I already agreed that we need a more simple settings manager, so what point are you trying to prove here?


What I am saying is what are your goals? To write a settings gui for advanced users? To me it seems like the emphasis was on the new users (startup scripts, guis etc) so why start with the advanced users (who maybe only make up 10% of your target userbase).

Goal is to get _one_ settings manager right first and add more settings managers for different user types later on.


Trust me, advanced users are not using ccp ;)
Yeah, I know, they are using ini :roll:

[delfick]

is it just me or does ?method=unloadPlugin not work anymore ??

i try http://localhost:8899/?method=unloadPlugin&plugin=wobbly

but it does nothing...

once i get that working, then my flashbsm should be able to disable and enable plugins as i've got it communicating with localhost :D (all i had to do was put it under localhost)

[some-guy]

Delfik why dont you just make flashbsm have a list of plugins not to show (i.e. gconf,ini, inotify, dbus, etc.) make groups for the compiz-core plugins, and use the grouping in the compiz fusion plugins for those plugins, this wayit can see any plugin that pops up tomorrow, and hide the unneeded ones :)

[delfick]

Delfick why dont you just make flashbsm have a list of plugins not to show (i.e. gconf,ini, inotify, dbus, etc.) make groups for the compiz-core plugins, and use the grouping in the compiz fusion plugins for those plugins, this wayit can see any plugin that pops up tomorrow, and hide the unneeded ones :)

I'm replying to this over here http://forum.compiz-fusion.org/showthread.php?p=22021#post22021