Compiz-settings - Compiz Configuration tool

[Guest]

compiz-settings 0.07-2

Compiz-settings is a compiz configuration program with a SLAB style interface

The project is now hosted on launchpad, so Please file any bugs/suggestions here https://bugs.launchpad.net/products/compizsettings/+bugs

Source: http://compiz.biz/compiz-settings/compiz-settings_0.07-2.tar.gz
Changes: http://compiz.biz/compiz-settings/compiz-settings_0.07-2_i386.changes

Ubuntu
Unofficial * Edgy Package 0.07-2: http://mogoshare.com/download.php?file=963576 (Thanks flargen)
Official * Edgy Package 0.05: http://compiz.biz/compiz-settings/compiz-settings_0.05_i386.deb
Official * Fiesty Package 0.07-2: http://compiz.biz/compiz-settings/compiz-settings_0.07-2_i386.deb

Other distros - Maybe slightly out of date
PKGBUILD for arch linux provided by baze: http://aur.archlinux.org/packages.php?do_Details=1&ID=7783

If anyone builds anymore packages send them to me and I'll put the links here, or better yet if anyone ones to put them in a repository let me know.

To Compile

./autogen.sh --prefix=/usr
make
sudo make install

To Run
compiz-settings
or
System >> Preferences >>Compiz Settings Manager

http://www.compiz.biz/compiz-settings/Screenshot.png
http://www.compiz.biz/compiz-settings/Screenshot-1.png

Any comments/feedback would be appreciated.

[amgeex]

Looking great man! I think that the icons should all look similar... That's my only complaint for the moment, haven't downloaded it. I'll try it soon tho. :D

[gandalfn]

one word, fantastic ! :). I you want, you can use libgnome-compiz-manger objects to get or set option and/or disable or enable plugin. It's made for that, else you can also pick some objects on it.

gandalfn

[RYX]

Great work! It is very nice and simple. Really good job.

I have some additional ideas/comments (only in case you don't have enough to do ;) )
- activate/deactivate-checkbox for plugins is hard to find (I overlooked it first)
- a global "path-indicator" at the top (like "Plugins / Wobbly / General Options") would be good for orientation
- a tree-widget for the Navigation (top left) would be easier to navigate
- a information-area with additional info for each option (ideally using a html-widget to be able to embed images)

Of course these are only some thoughts I had on the first impression. I really like yact the way it is (though I am no fan of that yet-another-* naming ... too Suse-like). It is very good for an initial version.

:)

[wedderburn]

you're more than welcome to reuse the beryl-setting-manager's icons they're more tango'ish and all look uniform.

http://bugs.beryl-project.org/trac/browser/trunk/beryl-settings/pixmaps for all the svg's.

if you need some icons to be made better ( with the higher resolution) just email me.

[RAOF]

Thank you very much for providing the package source, too.

It's now in my repository, for all those crazy AMD64 users running Feisty here :).

EDIT: or will be, as soon as I fix the package's build-depends line. Zootreeves, want the diff?

[mikedee]

Looks nice - seems like you have paid attention to the details.. I personally am very happy that the sliders do not move with the scroll wheel, this was the worst bug in csm that I saw.

Just a couple of thoughts that I had about this.

Wobbly settings are way too confusing and configurable for most new users. My suggestion is that we could make groups of the 3 options and then create different wobbly profiles eg. Springs, Gloopy, Spongy etc this should make it easy for them to get the correct setting. Advanced would obviously be available if you want.

Maybe we should group all of the key bindings, mouse binding and corners away from the general plugin settings, at the moment there isnt an action type given with the setting so you cannot tell whether to render an edge selector or not. The actions inside compiz are set so that they can only be key/mouse/edge etc. Gconf shows you options for edge bindings for every action but most do not have them.

I was also thinking about the interesting point you made about not being able to configure anything if compiz is not running. I have given it some thought and I do not think it would be a great idea to fall back to gconf in this instance. The are a few reasons for this.

1. Gconf does not have the full information about actions so the GUI would have to render all of the options, people will be confused why it is different than when compiz is running.
2. I dont think it is very easy to work out exactly which config plugin people will use if they do eventually launch compiz. The config plugin is dictated by the startup command.
3. What use will people get from it? As far as I can see the only time configuring compiz whilst it is not running would be useful is to remove plugins that are crashing it. In this case they can be pointed to gconf-editor.

Overall I think the disadvantages of including a fallback probably outweigh the benefits. Maybe the method could be defined at compile time so they could compile --use-gconf/dbus, the gconf version would have less features but would not require dbus?

What do you think?

[mikedee]

Oh, and I think I will see if I can add a CompOptionTypeImage to the core so that you will know which options are images and you can then check the file against a list of aceptable file types and sizes, make sure it exists etc.

I thought it might be a good idea for the configuration tool to accept any file type for the skydome image, if it is jpeg of the wrong size then it can be converted by imagemagick (if they have it installed). This way people are not confused by getting the correct image (png, power of 2 etc)

[Guest]

amgeex: I agree the icons should all look the same, but i don't have time at the moment to create them. If anyone feels up to it?

gandalfn: I hope to move yact to use dbus as a backend soon, so converting the current backend to use libgnome-compiz-manger would be a bit of a waste of time as I would have to remove it again anyway soon.

RYX:
- activate/deactivate-checkbox for plugins is hard to find (I overlooked it first)
mxpxpod (on #compiz-dev) suggested an improvement for this which I will create for the next version, but it's quite hard to find a suitable place to put the enable/disable checkbox.
- a global "path-indicator" at the top (like "Plugins / Wobbly / General Options") would be good for orientation
Agreed, will be in next version
- a tree-widget for the Navigation (top left) would be easier to navigate
Do you not think this is a bit excessive for navigation as it's only going to be a maximum of two levels deep. I think just a button to the main panel is suitable.
- a information-area with additional info for each option (ideally using a html-widget to be able to embed images)
I was planning on doing something like this, loading additional info from a hints file. Mabye not for a few versions yet though
I am no fan of that yet-another-* naming
When I release v 1.0 i think i might rename it to something else (maybe just compiz-settings)

wedderburn: Thank you very much! If I use your icons I will be sure to include credit in program

ROAF: Yes please :)

Mikdee:

Wobbly settings are way too confusing and configurable for most new users. My suggestion is that we could make groups of the 3 options and then create different wobbly profiles eg. Springs, Gloopy, Spongy etc this should make it easy for them to get the correct setting. Advanced would obviously be available if you want.

I could add something like "Make my windows Spongy", "...Gloopy" etc into the common tasks for wobbly. Different profiles for plugins is something I may add later.
Oh, and I think I will see if I can add a CompOptionTypeImage to the core so that you will know which options are images and you can then check the file against a list of aceptable file types and sizes, make sure it exists etc.

Yeah that would be cool, If david accepts it.

[Guest]

0.02, nothing really worth mentioning, just renamed to compiz-settings (I decided i agree with RYX i really didn't like the name yact).

[Sorcerer]

The package seems to only contain documentation, no binaries.

[Guest]

Sorry, changed.

[gandalfn]

gandalfn: I hope to move yact to use dbus as a backend soon, so converting the current backend to use libgnome-compiz-manger would be a bit of a waste of time as I would have to remove it again anyway soon.

Precisely, I made libgnome-compiz-manger so that it can use any type of backend.

For the moment it supports only gconf but in the long term it will use a system of plugin for configuration backends and these dependencies will be limited only to glib.

We could perhaps amalgamate our two systems to propose a common library for configuration tools.

What think about it?

gandalfn

[mikedee]

Here it is then, the clash of the configuration methodologies!

In the red corner is libsettings, in the blue corner is dbus

Here are the stats.

libsettings

It has the power to load smaller modules which can be used by any backend
It can configure compiz even if compiz is not running, although it has a hard time telling what configuration backend to actually use. There are a few methods but they all have problems.
It does not require dbus to be running or the dbus plugin to be loaded
Can be prone to crashing if the correct version is not compiled with the settings manager

dbus

Dbus has magic powers which allow any language to talk to it, this means that python, perl, java and even haskell bindings are allready written for us. Dbus knows that libsettings will be late to the fight because it will have to prepare its on language bindings, it will also have to go back to the changing room regularly.
Dbus is very popular amongst the desktop environments, both gnome and kde are fully supporting dbus.
Dbus has much more power than just the ability to change your settings, dbus can integrate almost any signal or property of the window manager and pass this insider information onto friendly settings managers (or any other app, eg messengers). libsettings does not know if the user changes the settings outside of it (ie by directly interacting with gconf-editor) whereas dbus can tell the settings manager what happened so it can update its internal state.
Dbus will silently use what ever backend compiz is using, far outbeating the power of libsettings to load modules.
Dbus will upgrade silently whilst libsettings users will be frustrated by 'blah not defined' errors when upgrading.

I personally back dbus for the winner, the libsettings looks like a bit of a fatty, whilst dbus appears to be hovering above the ring!

People can back who they like, but libsettings will spend more time in the dressing room.

[mikedee]

BTW the fight is being run live on the beryl-project channel, the libsettings supporters are currently unaware of dbus's power to change settings. They are surely about to receive some killer information!

Stay tuned to find out in this exciting fight to the death!

http://forum.beryl-project.org/viewtopic.php?t=552

[gandalfn]

I agree which dbus is the best solution for compiz dialog. I want in no way to recreate the setting model of compiz;).

But for me, there are two visions of settings, this one of compiz adapted to its operations and this one of the configuration tools adapted to the user.

In short compiz have operational parameters what explains the number of settings and libgnome-compiz-manager have functional parameters, if one takes for example plugins activation, to append a plugin for compiz, you should add the plugin name in the active_plugins list what is functional point of compiz is excelent but from user point not really, but append a GLPlugin in GLManager object is more correct for this one.

You can, indeed, modify dbus plugin so that it integrates this vision but I think isn't to compiz to adapt at configuration like beryl but inverse.

The nearest example that I know is gnome-system-tools, this one is cut out into three part:

- configuration backends with their dbus interface (system-tools)
- liboobs which represents operation with a user vision
- and tools of configuration gnome-system-tools which dialogues with the backends via this interface.

libgnome-compiz-manager is not used to configure compiz but simply to translate compiz setting into a configuration tools form and never, never, it will replace the compiz system settings.

I hope that I expressed myself rather well in English to explain my view point, don't hesitate to correct me if I made language errors

gandalfn

[mikedee]

I agree that there are functions which a compiz manager would need which is not part of dbus or compiz. These are mostly validation functions and GUI element generation. As far as I can see, the layers should be like this.

compiz

Compiz has its own internal datatypes (part of the options). Compiz has no awareness of how those settings are serialized to disk.

The settings plugin

This only deals with translating compiz internal datatypes to something on disk (and back again).

dbus plugin

This exposes the compiz options to any other programs which are interested in the data. All the data exchange between compiz and external apps should go through this. This will mean that the data representation is consistant plus it means that there is an air gap between compiz and the settings manager which means you will not have to recompile on every minor compiz revision.

GUI specific libraries

These libraries could make it easier for people to write custom GUI elements which represent compiz datatypes. This could also be used to provide grouping of compiz options or to allow data to be validated before sending to compiz.


I think this sounds fairly reasonable and it keeps everything nicely grouped and seperated, any data that you need to exchange with compiz should be done with dbus, if there is any sort of metadata that needs to be layered over the top, it could be done in the GUI library. As long as each function is kept seperate, it should be easy to debug and hopefully bugs will be kept to a minimum.

What do you think?

[RAOF]

I think that compiz should register itself as a DBUS service (and have a --config-only command-line parameter). If you're going to use DBUS as universal application-level compiz-configuration system (and I think you should) then there probably needs to be some way to configure compiz when it's not actually running. Similarly, it'd be nice to configure plugins that aren't currently loaded.

The first could be acheived by registering compiz as an auto-startable DBUS service - then, should a configuration program attempt to access the settings bus, it would auto-start compiz (in the settings-only, non-wm mode). I think the second also requires some core changes.

Then, on top of this, you can have a libcompizgui which does all the DBUS and guification work. But you're still able to eg: Pythonically configure compiz, or with any CIL language, or even bash.

[RAOF]

Ok. Now, finally, with a buildable source-package in my repository, and a built package for all those lucky AMD64 users!

http://raof.dyndns.org/falcon/dists/feisty/eyecandy/

Will net you links :).

[mikedee]

I think that compiz should register itself as a DBUS service (and have a --config-only command-line parameter). If you're going to use DBUS as universal application-level compiz-configuration system (and I think you should) then there probably needs to be some way to configure compiz when it's not actually running. Similarly, it'd be nice to configure plugins that aren't currently loaded.

The first could be acheived by registering compiz as an auto-startable DBUS service - then, should a configuration program attempt to access the settings bus, it would auto-start compiz (in the settings-only, non-wm mode). I think the second also requires some core changes.

Both of these sound like very good ideas, I have had a quick look at the compiz main.c file and it looks like it would be easy to patch it so that it starts but without initializing anything. I think we just need to stop the addDisplay function running and compiz will not take over, but it will still be possible to load and read plugins. The dbus plugin would somehow have to be loaded since this is normally done in the addDisplay function. It would also have to be modified to be actived without a display, this might be much more tricky.

The second point should also be fairly easy, the plugins are initialized in stages which means we can load a plugin without it being activated. I think dbus can take care of this internally.

Another problem that I cannot work out is how to tell what configuration method the user would use if they were running compiz. This is defined by whatever they type into the compiz startup line. The only real solution is to have something like a ~/.compizrc file which stores this information and can be read externally. The only problem here is that we have to expect that file to be there (although we could just default to gconf if it isnt).

Ill try to write some code so that you can get and set information for plugins that are not loaded in a running compiz. The first point will probably take a bit of thought and experimentation.

[PaK]

So in that scenario dbus plugin for compiz still should be a plugin ? Maybe this should became internal part of compiz ?

[Amaranth]

Why? Someone might eventually want to write a different IPC plugin.

[crankyjack]

The tricky part of the config-only scenario seems to be to fully initialize the configuration persistence plugin (usually, but not necessarily gconf) and the RPC plugin (usually, but not necessarily dbus), but only to load and to initialize the options of the other plugins. When compiz starts with the --config-only option, it needs to distinguish those two types of plugins: "fully initialized", and "load-and-init-options-only". Maybe it might fully initialize those plugins passed to it as command line arguments. Or there could be a configuration option containing the list of fully initialized plugins for the config-only mode; the configuration persistence plugin must be passed on the command line and fully initialized anyway. The first possibility appears more flexible, and also simpler to implement. The second one would need two passes of full initialization.

[RYX]

Do you know elektra? It was once posted on the old compiz-forums as a proposal for replacing gconf. I don't know anything practical about it, but after reading some comments and articles from various sources I found it very promising. It is a "better" version of gconf ... (according to some linux-magazines and the author himself).

Elektra Website ... (http://elektra.sourceforge.net/)

[mikedee]

Maybe it might fully initialize those plugins passed to it as command line arguments. Or there could be a configuration option containing the list of fully initialized plugins for the config-only mode; the configuration persistence plugin must be passed on the command line and fully initialized anyway.

It all looked fairly easy when I first looked at it. It is easy enough to build a dummy plugin which could be called on the command line instead of gconf. This could then take care of loading dbus and gconf. The problem is that they are not fully operational until the Display has been created and their initDisplay/Screen functions have been called.

This is what I am thinking at the moment.

dbus kicks off compiz with the '--config-only dummy' line, this then does everything as normal except it runs a function called 'addDummyDisplay'. This could create the display structure but not actually grab the display. Each plugin then could be individually loaded and the settings read.

Just thinking out loud really ;)

[PaK]

From their wiki:
"Compared to GConf, Elektra is not a daemon, was designed from the begining for global system usage, is lightweight, is concerned about security and avoids any dependencies." Too bad i didn't found any comparison of Elektra to KConfig XT, and probably for now there is no gui tools for manage it under gnome. Overall Elektra seems to be lightweight, no complex dependency library with api for many languages. Btw. there are any plans to drop Gconf and Kconfig and start doing sth over the distributions ? Well elektra is that initiative, but it is independent, there are any voices from gnome, kde, xfc etc. to create one configuration layer ?

[RYX]

From elektra wiki:
What we are planning for these desktop frameworks is not to completely switch their configuration layers, but to collaborate with them reimplementing their interfaces that deal with configurations. The tactics are:

* For Gnome: write a GConf backend based on Elektra
* For KDE: reimplement KConfig XT methods to be able to have configuration affairs with a key database

Maybe implementing elektra as compiz-settings-backend would help making it more well-known. I think an desktop-independent settings-backend is of great importance for further improvement of the Linux-desktop in general.

But its just a proposal, I still know nothing about using it.

:)

[mikedee]

I have never really understood the fasicination with compiz's configuration... As far as I can see it is the most boring part of it and as long as it stores data I dont really care. :)

What sort of cool things are possible with a different backend?

This isnt a flame, I am just a bit confused by it all :?

[Guest]

I think we just need someone to write a kcontrol backend, I don't think elektra is the solution because its just one more thing for everyone to install whether your a gnome or kde user. I think once that's done the backend issue can finally be laid to rest. The really issue is how configuration programs can change setting regardless of the backend, but I think we've all pretty much decided that dbus is the way to go with this.

[maurs]

Hi guys.

I have some questions ;) Sorry 4 my english.

I use Gentoo with Kde, and i changed the compiz ebuild to compile it with --disable-gconf and --disable-gnome coz i don't want to compile all gnome libs (damn, i want only kde :P).

After this. I compiled Compiz-Settings, but only General Options and Fade plugin settings are showed. And in either only Audio and Visual options are showed!

So my question is: i need to compile gconf to make compiz-settings works?
There will be an ebuild for Gentoo users?
It is full compatible with Kde?

Perhaps, This is the output of autogen

./autogen.sh --prefix=/usr
processing .
Creating ./aclocal.m4 ...
Running glib-gettextize... Ignore non-fatal messages.
Copying file mkinstalldirs
Copying file po/Makefile.in.in

Please add the files
codeset.m4 gettext.m4 glibc21.m4 iconv.m4 isc-posix.m4 lcmessage.m4
progtest.m4
from the /usr/share/aclocal directory to your autoconf macro directory
or directly to your aclocal.m4 file.
You will also need config.guess and config.sub, which you can get from
ftp://ftp.gnu.org/pub/gnu/config/.

Making ./aclocal.m4 writable ...
Running aclocal ...
/usr/share/aclocal/pth.m4:43: warning: underquoted definition of _AC_PTH_ERROR
run info '(automake)Extending aclocal'
or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
/usr/share/aclocal/pth.m4:55: warning: underquoted definition of _AC_PTH_VERBOSE
/usr/share/aclocal/pth.m4:61: warning: underquoted definition of AC_CHECK_PTH
/usr/share/aclocal/ao.m4:9: warning: underquoted definition of XIPH_PATH_AO
Running autoheader...
Running automake --gnu ...
Running autoconf ...
Running ./configure --enable-maintainer-mode --prefix=/usr ...
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking for library containing strerror... none required
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking dependency style of gcc... (cached) gcc3
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking dependency style of gcc... (cached) gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for PACKAGE... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking locale.h usability... yes
checking locale.h presence... yes
checking for locale.h... yes
checking for LC_MESSAGES... yes
checking libintl.h usability... yes
checking libintl.h presence... yes
checking for libintl.h... yes
checking for ngettext in libc... yes
checking for dgettext in libc... yes
checking for bind_textdomain_codeset... yes
checking for msgfmt... /usr/bin/msgfmt
checking for dcgettext... yes
checking for gmsgfmt... /usr/bin/gmsgfmt
checking for xgettext... /usr/bin/xgettext
configure: creating ./config.status
config.status: creating Makefile
config.status: creating src/Makefile
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands
config.status: executing default-1 commands
Now type `make' to compile.

Sorry for the little OT :oops: in this discussion and tnx u 4 reply.

[Guest]

Yes you need gconf for it to work at the moment, until the dbus changes are made.

[mikedee]

You might want to test the new dbus that are in today, they are slightly different to my patches so let me know if you have problems handling the data. I used dictionary bindings which seemed to make it easier for python users.

[Guest]

I would really like to see those changes, don't suppose someone could tar me up a copy of the latest git? Just I can't use it because i'm behind a proxy

[maurs]

You might want to test the new dbus that are in today, they are slightly different to my patches so let me know if you have problems handling the data. I used dictionary bindings which seemed to make it easier for python users.

This is I obtain with 0.02 version:
http://i13.tinypic.com/2ykkxa8.jpg

Where i can download your patches? ;)

[mikedee]

Here you go

http://www.anykeysoftware.co.uk/compiz/compiz-git-2006-12-11.tar.bz2

maurs : You should probably wait a few days, my patches are not official and are a bit different from the official ones which we will be working on.

[RAOF]

...

Another problem that I cannot work out is how to tell what configuration method the user would use if they were running compiz. This is defined by whatever they type into the compiz startup line. The only real solution is to have something like a ~/.compizrc file which stores this information and can be read externally. The only problem here is that we have to expect that file to be there (although we could just default to gconf if it isnt).
...

Aha! Having thought about this, it's actually not too hard. What we want falls into two categories:
1) Compiz is running. In this case, awesome. Nothing more required.
2) Compiz isn't running. In this case, when we ping the DBUS, the compiz service will get auto-started with whatever command-line options are specified in the service file. So, basically the service file will specify "compiz --config-only gconf" or "compiz --config-only kcontrol" or "compiz --config-only bsm". This makes determining which backend gets used easy for packagers, who are really our target audience. Anyone who still writes their own compiz-start scripts can additionally change the service definition file to match their backend.

[Amaranth]

Uh, that doesn't help. Take Ubuntu, for example. That one dbus event script would need to work with ubuntu, kubuntu, xubuntu, etc. And you can't have different packages offer different versions of the file because some people have both KDE and GNOME installed (think of a multiuser system).

[RAOF]

Uh, that doesn't help. Take Ubuntu, for example. That one dbus event script would need to work with ubuntu, kubuntu, xubuntu, etc. And you can't have different packages offer different versions of the file because some people have both KDE and GNOME installed (think of a multiuser system).
Bah! I have an awesome idea and all people can do is poke huge holes in it :P.

And I suppose that it's actually possible to have compiz setup to use different backends on Gnome & KDE, isn't it.

In which case, even a ~/.compizrc file isn't going to help. Does DBUS offer per-user service definitions? That'd be a start.

[Amaranth]

If a single user is flipping back and forth between KDE and GNOME I'm sure he'd rather have his settings consistent. Even if that's not the case, I'd say that shouldn't be a supported use case. You have to draw the line somewhere (unless you want to get into the hell that is DE detection).

[RAOF]

Ok. From the documentation, it seems that DBUS will search for service files from this:
<standard_session_servicedirs/> is equivalent to specifying a series of <servicedir/> elements for each of the data directories in the "XDG Base Directory Specification" with the subdirectory "dbus-1/services", so for example "/usr/share/dbus-1/services" would be among the directories searched.
...which includes $HOME/.local/share/dbus-1/services (on Ubuntu, at least, since $XDG_DATA_HOME is not set).

So we could get compiz to maintain a service definition file there, and it would be per-user. If DBUS correctly follows that spec (and Feisty's version does, I've just checked), we could also install a global service file in /usr/share/dbus-1/services to catch the case when a user installs compiz and then tries to configure it before running it, since $XDG_DATA_HOME is checked first.

Verifying that works was surprisingly easy. You specify a dbus service that just touches a file :).

[maurs]

maurs : You should probably wait a few days, my patches are not official and are a bit different from the official ones which we will be working on.

But they should be included in next version of Compiz? ;)

[baze]

using dbus for configuring compiz sounds very nice. :)
i'd like to know if it is really neccessary to use libgnomeui for compiz-settings.
it would be great if you could do it using gtk only, so you don't have to install libgnome when using compiz with xfce for example.

[Guest]

Thanks mikedee for the tar ball

i'd like to know if it is really neccessary to use libgnomeui for compiz-settings.
Sorry this was a pretty bit oversight on my part, I didn't realise it was depending on libgnomeui. I have changed this and uploaded 0.03 which only depends on gtk and gconf.

Sorry as well for not including anything new, just I havn't had much time to work on it lately.

[baze]

hm, nice to see that it should be possible, but with 0.03 i only get lots of errors when i try to start it:

(process:14506): Gdk-CRITICAL **: gdk_window_invalidate_rect: assertion `window != NULL' failed

(process:14506): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed

(process:14506): Gtk-CRITICAL **: gtk_style_attach: assertion `window != NULL' failed

and then it segfaults.

[Guest]

new package, should be fixed?

[baze]

yes, that one works. thank you :)

btw, i created a PKGBUILD for arch linux: http://aur.archlinux.org/packages.php?do_Details=1&ID=7783

[Guest]

New package Fixed segfault, haven't changed the version number

[shogun_panda]

New package Fixed segfault, haven't changed the version number

For me segfaultes didn't resolve. I have a Gentoo box...
By debugging the code, I realized that segfaults due to your diffuse use of nested function like this:

void foo(){
void foo2(){}
}

which fooled the compiler...
Can you remove them?

[Guest]

New Version. The main change is I've added a checkbox next to each of the plugins to quickly activate and disable plugins with a right click (left click as normal to configure). If anyone has any comments or problems with this can you please let me know.

shogun_panda I've removed some of the nested functions, can you give me a back trace so I can locate the problem? Is it bad practice to nested functions?

[Guest]

Version 0.05 added mouse and keyboard grab buttons that make it much easier to grab shortcuts.

I have a lot more time to work on this at the moment, so keep any ideas and bug reports coming in.

[RAOF]

...
shogun_panda I've removed some of the nested functions, can you give me a back trace so I can locate the problem? Is it bad practice to nested functions?

You learn something new every day. I didn't even know C supported nested functions :).

[Guest]

0.06 - Preliminary dbus support if it's active so sliders will now have the right range, color pickers for color options and combo boxes for strings with a restriction.

I'm not sure how this will behave with older compiz version, probably will cause problems so I suggest only using it with 0.3.4 and above.

mikedee any update on getting CompOptionTypeImage option type?

[mikedee]

Seems to be working fine here, just a few points...

1. The main panel navigation button could do with being bigger and having a home symbol on it. I couldnt find it initially.
2. There are no list settings (I assume you know this :))
3. When I am entering a keybinding with the super key, it enters it as <Mod4><Hyper> rather than <Super>. Super is treated seperatly in compiz from the other keys.
4. It might look nicer for the tabs to be on the same page but grouped, most plugins do not have that many options and I think it would be clearer.
5. I can add more information to the action options so you can tell if they are set up for edges/keyboard/mouse. A lot of the actions are not set up to work with edges so you can save a lot of space that way.
6. I will look at adding a Image type, the recent changes made a lot of my plans obsolete so I will have to rethink it. You will be able to validate any image by which image handling plugins are loaded.

[Guest]

0.07 - This is the last gconf release, 0.08 and above will rely solely on dbus.

This version should be faster, more stable and generally more polished. Other than that you won't notice much difference, apart from Action Keys are now grouped under one 'Bindings tab' (not sure whether i prefer this) and There is a reset options button.

Just a little roadmap:
1. Replace all gconf with dbus (0.08 )
2. String list support (0.08 )
3. Plugin dependency and conflicts
4. "Recommendations" button
5. Tooltips, better option descriptions
5. Profile Support
6. Translations
7. Submit to ubuntu MOTU (0.1)

Seems to be working fine here, just a few points...
1. Done
2. Yeah I know :) Next version
3. Added Work around for it
4. Not sure I understand this
5. Yes that would be very useful

[lagorgy]

/usr/include/dbus-1.0/dbus/dbus.h:30:2: error: #error "Please define DBUS_API_SUBJECT_TO_CHANGE to acknowledge your understanding that D-Bus hasn't reached 1.0 and is subject to protocol and API churn. See the README for a full explanation."
make[2]: *** [main.o] Error 1
make[2]: Leaving directory `/home/orgy/Desktop/compizsettings-trunk/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/orgy/Desktop/compizsettings-trunk'
make: *** [all] Error 2


hi, im getting that error. Im on edgy, am i doing anything wrong?

[baze]

i have the same error on arch linux.

[mikedee]

Open the file src/dbus.c then change this

#include <dbus/dbus.h>
#include <dbus/dbus-glib.h>
#include <dbus/dbus-glib-lowlevel.h>
#define DbusDomain "org.freedesktop.compiz"
#define DBUS_API_SUBJECT_TO_CHANGE

to this

#define DBUS_API_SUBJECT_TO_CHANGE
#include <dbus/dbus.h>
#include <dbus/dbus-glib.h>
#include <dbus/dbus-glib-lowlevel.h>
#define DbusDomain "org.freedesktop.compiz"

(ie, just move the subject to change bit to the top)

[Guest]

sorry, changed.

[nightfrost]

compiz-settings 0.7 sometimes crashes on me. This is the output:

3d De-activated
Button clicked
settings medium interface to false
destroy_icon_group destroying group
tile Activated

(compiz-settings:3493): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GtkToggleButton'

(compiz-settings:3493): Gtk-CRITICAL **: gtk_toggle_button_set_active: assertion `GTK_IS_TOGGLE_BUTTON (toggle_button)' failed

(compiz-settings:3493): GLib-GObject-WARNING **: invalid cast from `GtkLabel' to `GtkToggleButton'

(compiz-settings:3493): Gtk-CRITICAL **: gtk_toggle_button_set_active: assertion `GTK_IS_TOGGLE_BUTTON (toggle_button)' failed
3493: assertion failed "dbus_type_is_basic (type)" file "dbus-marshal-basic.c" line 513 function _dbus_marshal_read_basic
Aborted

I'm not aware of anything particular I did when it crashed. I just disabled the 3D plugin and enabled the tile plugin, IIRC.

Hope it helps.

[Guest]

Yeah i picked this error up just after i uploaded the new version, uploaded a fixed version now, compile the source or download the package again and it should be fixed.

[Guest]

*New Version 0.07-2 - I know I said there wouldn't be another release with gconf support, but there are a few bugs in 0.07 so I've made some minor changes and repackaged. Also will now get string restriction for > 0.35

[flargen]

A version 0.07-2 deb for Ubuntu Edgy is here (http://mogoshare.com/download.php?file=963576).
Thanks for this great application zootreeves!

[baze]

please don't use -2 in the source names. 0.0.7.2 would be better, because the -2 part is used for package versioning

[nightfrost]

0.07 - This is the last gconf release, 0.08 and above will rely solely on dbus.

Does this mean that the gconf plugin does not need to be loaded, and therefore not even built? Does it mean that compiz can be started with

compiz --replace dbus

and that all the gnome dependencies can be dropped for KDE-users?

[mikedee]

No - you must always load the gconf plugin.

The gconf plugin stores the configuration data, the dbus plugin communicates that data to compiz-settings.

If you are a web type person, this is a good anology.

gconf = mysql database
dbus = xml rpc

In the future there will be kde based storage, but it will still be communicated via dbus, so compiz settings will work with kde.

In theory you could drop gconf and compiz-settings will still work, your settings will be lost on every restart though. You would then need to specify each plugin on the command line. dbus would not load your other plugins.

[nightfrost]

Ah, thanks alot. I was expecting that, but sometimes one just needs it as clear as clear can be. I was wondering since I was packaging compiz for archlinux in split packages (compiz-core, compiz-gnome, and compiz-kde). I wasn't sure whether I should add the gconf plugin to core or gnome. I've added it to core now.

I've also created a PKGBUILD for extra plugins that grabs the sources straight from http://www.anykeysoftware.co.uk/compiz/plugins/. Am I right in assuming that the plugins from there are more up-to-date than the gandalfn package?

[penguin]

Hi

I tried to compile the compizsettings tool i get this error
:~/Download/compizsettings-trunk$ make
make all-recursive
make[1]: Entering directory `/home/dini/Download/compizsettings-trunk'
Making all in src
make[2]: Entering directory `/home/dini/Download/compizsettings-trunk/src'
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -DPACKAGE_DATA_DIR=\""/usr/local/share"\" -DPACKAGE_LOCALE_DIR=\""/usr/local/share/locale"\" -DORBIT2=1 -pthread -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/libpng12 -I/usr/include/startup-notification-1.0 -I/usr/include/compiz -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gconf/2 -I/usr/include/orbit-2.0 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/freetype2 -g -O2 -MT main.o -MD -MP -MF ".deps/main.Tpo" -c -o main.o main.c; \
then mv -f ".deps/main.Tpo" ".deps/main.Po"; else rm -f ".deps/main.Tpo"; exit 1; fi
In file included from main.c:157:
functions.c: In function ‘keyboard_shortcut_pressed’:
functions.c:505: error: ‘GdkEventKey’ has no member named ‘is_modifier’
make[2]: *** [main.o] Fehler 1
make[2]: Leaving directory `/home/dini/Download/compizsettings-trunk/src'
make[1]: *** [all-recursive] Fehler 1
make[1]: Leaving directory `/home/dini/Download/compizsettings-trunk'
make: *** [all] Fehler 2

My Distr. is Debian Etch Compiz 0.3.6 with Nvidia drivers.
I hope somebody can help and sorry for my bad english thx

[stjepan]

Imo Compiz-settings is VERY ugly.
What do you think of this:

http://pix.nofrag.com/c2/30/11c5424c1a34d2e693ae89b4ef5c.jpeg

[baze]

i just found that the window notifying you about the dbus plugin failing, when compiz is not runnin when you open compiz-settings, is below the main window of compiz-settings, so you don't see it at first and wonder why nothing works.
you should probably open that notification window after opening the main compiz-settings window and make it modal.

[RYX]

As far as I know, the compiz-settings-tool is currently "orphaned" ... It needs someone to continue working on it.

[benr]

I'm still maintaining it just a lot slower than before. But if someone wants to put more time into it and take over the project i have no problem with that.

~zootreeves

[RYX]

Hi benr - I'm really glad to see you're back ... :D

Please don't misunderstand my previous post - I didn't want to "give away" your project, I only wanted to ensure that the most wanted (and needed) compiz-related app gets developed further ... Of course I'd like best if you are the one to continue working on it.

:)

[benr]

It's been a while since the last update I know :) but i'm going to work on it a bit more now.

Here's the first update:

http://files.to/get/379585/49783/compizsettings-trunk.tar.gz

it's not a release it's just i'm looking for a few people to test it with the latest compiz git as it does not work fully with 0.3.6. All the gconf dependencies have been removed and it now relies only on dbus. However it cannot seem to set String list, so it can't activate/disable plugins i'm not sure whether this is a compiz bug, dbus bug or compiz-settings bug.

Can anyone have a look at this bit of code and tell me if i'm doing anything wrong?

if (CompType == CompizSettingsOptionStringList) {
//GSList to dynamic string array (list of plugins comes in as a gslist)
int i = 0;
GSList * list = data;
char **strs = g_new (char *, g_slist_length(list) + 1);;

while(list) {
strs[i] = list->data;
strs[i + 1] = NULL; //Null terminated
list = list->next;
i++;
}

dbus_g_proxy_call_no_reply (proxy, method,
G_TYPE_STRV, strs,
G_TYPE_INVALID,
G_TYPE_INVALID);

}


All from the command line it doesn't work
dbus-send --type=method_call --dest=org.freedesktop.compiz /org/freedesktop/compiz/core/allscreens/active_plugins org.freedesktop.compiz.set array:string:'dbus','decoration','place'

so is this a compiz bug?

Also do people prefer the way in the screen shot below or the current way of changing screen edges?
http://img248.imageshack.us/img248/9899/screenshotgz8.th.png (http://img248.imageshack.us/my.php?image=screenshotgz8.png)

Thanks,
Ben

[wfarr]

I prefer the example in the screenshot.

[nightfrost]

Yay!! Thanks for continuing on this!

I prefer the method in the screenshot as well.

[delfick]

cool :D

the screenshot looks much better :D

[maurs]

David Revemas is going to implement a simple test configuration file (ini) in the next release of compiz.
Will you continue using dbus or you'll switch to ini file? :)
When we'll see the next snapshot of compiz settings?

Tnx you in advance for reply.

[mikedee]

David Revemas is going to implement a simple test configuration file (ini) in the next release of compiz.

Dammit ;)

Will you continue using dbus or you'll switch to ini file? :)
When we'll see the next snapshot of compiz settings?

The idea is to keep using dbus.

I think people are confused about what dbus is. It is not a storage method, it is simply a way to communicate with compiz.

Now there are 2 non-volatile storage methods for compiz, ini and gconf. You can choose which you want.

On top of that there are now 2 different ways to ask compiz to change those settings, dbus and (now partly) fuse (fs). Both of these just tell compiz to tell the backend to change the settings.

compiz-settings will work if you use gconf as a backend OR ini as a backend. That is the reason it is used rather than going straight to gconf.

Just to clarify

backend storage - ini, gconf
inter process communication - dbus, fs (fs is read only at the moment)

They provide totally separate functions even though they work together. You cannot replace ini or gconf with dbus or fs. Compiz-settings does not need to know what storage method is being used, it just needs a way to communicate directly with compiz core.

[RYX]

I am working on a small settings-tool written in python - mostly as an exercise for dbus-support in the screenlets. Please don't get me wrong - I absolutely don't want to compete with compiz-settings, instead it follows the csm-style and is adressed at more advanced users. It currently uses dbus but I will add a backend for the fuse-based configuration, once it is read/write. I like the ability to add file-watches to "listen" for option-changes (... cause I am still unable to retrieve compiz-signals from dbus :().

I think a settings-tool written in python would allow more people to participate in its further development (and its a little masochistic to write gui-apps in plain C :D ...).

:)

[Amaranth]

RYX: You might be interested in the code I have for this. It implements a gnome control center style UI, same as compiz-settings.

http://www.realistanew.com/random/mockery/mainview.png

That's all the further I went on it though, porting libslab to python sort of burned me out on the idea. You'd have to implement the individual plugin options stuff on your own.

Code is at http://dev.realistanew.com/mockery/

[delfick]

instead it follows the csm-style and is adressed at more advanced users.

awsome :D finally!! :D

@Amaranth:: why the SLAB style ?? (sry, personal hatred of slab style)

why not something like this http://delfick.storage.googlepages.com/mockup5.html (it's a mockup i made before the current bsm was released and is based on the idea the bsm was based on...the only special thing about it is the "show all plugins" button at the bottom which was like a search thing (and animated :D), just play around with that :D)

and also the drop down menus for the groups at the top...

[M@]

hello everybody, i tried to compile it but get this error during the make command...could you tell me how to solve it?
tnx in advance
qwerty@homeLESS:~/Desktop/compiz-settings-0.07$ make make all-recursive
make[1]: Entering directory `/home/qwerty/Desktop/compiz-settings-0.07'
Making all in src
make[2]: Entering directory `/home/qwerty/Desktop/compiz-settings-0.07/src'
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -DPACKAGE_DATA_DIR=\""/usr/share"\" -DPACKAGE_LOCALE_DIR=\""/usr/share/locale"\" -pthread -DORBIT2=1 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/libpng12 -I/usr/include/startup-notification-1.0 -I/usr/include/compiz -I/usr/include/gconf/2 -I/usr/include/orbit-2.0 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/freetype2 -g -O2 -MT main.o -MD -MP -MF ".deps/main.Tpo" -c -o main.o main.c; \
then mv -f ".deps/main.Tpo" ".deps/main.Po"; else rm -f ".deps/main.Tpo"; exit 1; fi
In file included from main.c:157:
functions.c: In function 'keyboard_shortcut_pressed':
functions.c:505: error: 'GdkEventKey' has no member named 'is_modifier'
make[2]: *** [main.o] Error 1
make[2]: Leaving directory `/home/qwerty/Desktop/compiz-settings-0.07/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/qwerty/Desktop/compiz-settings-0.07'
make: *** [all] Error 2
qwerty@homeLESS:~/Desktop/compiz-settings-0.07$

M@

[RYX]

Thanks Amaranth :) Looks damn cool ... but my intention was to not follow the SLAB-style (btw: what does SLAB mean? :) ...). But maybe it can be abstracted in a way that it can use both interfaces - it isn't impossible. I was thinking about something like a "Compiz Access Library" that provides the settings-backends (dbus, fuse, ...) and a nice interface-class to easily work with compiz from python over various backends.

And thanks delfick, too ... The mockup looks pretty cool - but it's not advanced enough for my taste :D :D ... I thought of something like THIS (http://ryxperience.com/storage/compset-screenshot.png) ...

The "General"-tab should contain info/desc, a "Presets"-option and an additional hook for adding custom widgets - these could be additional, specialized option-inputs or editors for special things some plugins may need (e.g. Image-selectors, Mesh-viewer, ...).

Maybe I can get it to a first working state within the next few days. It's my side-project which I work on when I am too fed up by my other work ... (and I am pretty much fed up by my other work atm :D ...).

:)[/url]

[Amaranth]

@Amaranth:: why the SLAB style ?? (sry, personal hatred of slab style)

why not something like this http://delfick.storage.googlepages.com/mockup5.html (it's a mockup i made before the current bsm was released and is based on the idea the bsm was based on...the only special thing about it is the "show all plugins" button at the bottom which was like a search thing (and animated :D), just play around with that :D)

and also the drop down menus for the groups at the top...

Because if you're going to split plugins into groups the libslab style is the only way to do it that isn't a usability nightmare.

With the way beryl-settings does it (and the way your mockup does it) you have to randomly guess what group the plugin you want is in. Your mockup has the advantage over beryl-settings in that you can scrub the group bar to find your plugin but this is still inefficient.

I learned about usability from the GNOME HIG, asktog, and my experience with website usability. I'm not just making this stuff up. :)

[RAOF]

I didn't immediately like the gnome control centre when it was introduced into Feisty (and I don't really miss it now it's gone), but it started to grow on me.

I don't think it'd need to be changed much before it became something I preferred over the current menu system. A little bit of Composite love and some animations would go a long way to making it really useable, I think.

/me adds "Beautify control centre" to his mammoth TODO list

[delfick]

And thanks delfick, too ... The mockup looks pretty cool - but it's not advanced enough for my taste :D :D ... I thought of something like THIS (http://ryxperience.com/storage/compset-screenshot.png) ...

but mine is like yours accept without the settings, and with groups (groups are much better than a list)....
lists both look really bad, and are hell to try and find anything in when they get so long they need a scrollbar.....

With the way beryl-settings does it (and the way your mockup does it) you have to randomly guess what group the plugin you want is in. Your mockup has the advantage over beryl-settings in that you can scrub the group bar to find your plugin but this is still inefficient.

hence the "show all plugins" button :D (i love that button :D)
and anyway, they're grouped in a way that makes sense (or meant to anyways (it's better grouped in the actual bsm than my mockup...)...and it's much easier to search for one thing out of many when the many is broken into groups...like trying to find a file on your computer, it's much easier when all your files are in folders and sub folders (in a way that makes sense) than when all your files are all bunched together in the same place (i think so anyways :D) and with the bsm, there's only like 20 plugins........

[maurs]

backend storage - ini, gconf
inter process communication - dbus, fs (fs is read only at the moment)


I know that... but all the changes @ the ini file, are applies in real time. So it could be used as a inter process communication. I forgot to say this ;) sorry.

[wfarr]

I have to agree with Amaranth here - using libslab is the _only_ way to get a clean, easy-to-use interface.

The problem with BSM and others is that they're either just a reworking of gconf (RYX's) or not usable (BSM). While the reasons naturally differ between the two, neither is a success in usability - which Compiz MUST be.

[RYX]

To be honest - I _hate_ SLAB-style. :)

That's what I mean with "more advanced" - I don't want to offer another "clean and friendly" tool which drives me mad because it isn't straight-forward and I always have to search for things. My approach doesn't need to be more than a dynamic settings-tool which doesn't require any kind of additional setup or info - it should just work.

It is definetly no rework of gconf - gconf isn't user-friendly and defining new actions is a real pain even for advanced users. Browsing to /apps/compiz/*/allscreens/... over and over again just sucks. And most important - gconf is too specialized - connecting through dbus/fuse is more neutral and allows the use of varying backends for compiz (gconf, ini, kconfig, ...)

Afaik, the grouping-feature from beryl is only possible because beryl has included the groups into the core/plugins - which isn't optimal and decreases the user's freedom because everyone feels different about what group a certain plugin belongs to. I think I will add a grouping-feature using a tree on the left (the list is only temporary yet) - so that everyone can group the plugins any way he likes.

(And once again - it should be possible (and the best way) to abstract the ui from the app and to create a tool which offers both, SLAB _and_ gconf-style ... and that's where Amaranth's lib could come into play. So there's hope for everyone ... :D)

:)

[delfick]

(And once again - it should be possible (and the best way) to abstract the ui from the app and to create a tool which offers both, SLAB _and_ gconf-style ... and that's where Amaranth's lib could come into play. So there's hope for everyone ... :D)

that would be cool :D

so basically, user selects how the program looks :D

does that mean i can eventually see a settings tool that looks and acts like my mockup ?? :D (eventually being the keyword..)

[mikedee]

backend storage - ini, gconf
inter process communication - dbus, fs (fs is read only at the moment)


I know that... but all the changes @ the ini file, are applies in real time. So it could be used as a inter process communication. I forgot to say this ;) sorry.

No, please dont even think this ;)

The ini file format may change without warning, but the dbus api will not. In fact I might just change the format regularly to stop people modifying it in this way :twisted:

Also fs is not so great for a configuration tool because the location of the mounted filesystem could change at any time. You can find it, but it would be a bit hit and miss.

RYX: Did you check the latest python-dbus package? In there is an examples directory with signal listening examples. You should be able to tweak them for compiz. Make sure you get the latest version (0.8.2 I think) because there were lots of breaks from 0.7.0 - 0.8.0 and the 0.8.2 version contains all the workarounds. You will have to add the signal listener to each object and make sure you ask for the extra information (path).

[wfarr]

To be honest - I _hate_ SLAB-style. :)

I'm sorry you feel that way.

That's what I mean with "more advanced" - I don't want to offer another "clean and friendly" tool

Just because we're offering a more advanced array of options does not mean that we should make the utility unnecessarily difficult to use: when there is a way to make a usable and simplified interface that allows for advanced usage, it should be utilized.

which drives me mad because it isn't straight-forward and I always have to search for things.

To be quite fair, while SLAB's Control Center is still improving, I put far more stock in the extensive usability testing that has gone into it than the opinions of a few groups scattered about the Internet who hate it with a passion.

SLAB is usable - there's a reason things like the Control Center are going to be in GNOME 2.20.

My approach doesn't need to be more than a dynamic settings-tool which doesn't require any kind of additional setup or info - it should just work.

That is exactly what SLAB does - just work.

It is definetly no rework of gconf - gconf isn't user-friendly and defining new actions is a real pain even for advanced users. Browsing to /apps/compiz/*/allscreens/... over and over again just sucks. And most important - gconf is too specialized - connecting through dbus/fuse is more neutral and allows the use of varying backends for compiz (gconf, ini, kconfig, ...)

I was not at all referring to its implementation in terms of the settings itself.

The UI you suggested is a list of plugins, which have more "nicely-named" options that are just copy/pasted from gconf.

Afaik, the grouping-feature from beryl is only possible because beryl has included the groups into the core/plugins - which isn't optimal and decreases the user's freedom because everyone feels different about what group a certain plugin belongs to. I think I will add a grouping-feature using a tree on the left (the list is only temporary yet) - so that everyone can group the plugins any way he likes.

This seems largely unnecessary. The plugins can be definitively and clearly grouped in such a way that makes sense - and as SLAB offers the immediate use of a filter, even if the "groups don't make sense to Jim and Jill", then they can just start typing the name of their plugin.

In terms of usability, the ability to group plugins as one likes is an entirely unneeded feature; and yes, there is such a thing.

[RYX]

Sorry to say, but who likes SLAB should stick with compiz-settings for now. I personally don't like the "noobification" of gnome and prefer the kcontrol-style (to give another example of a really good control-center that follows the "navi-tree on the left"-style) - even though I am a gnome-user ...

The SLAB-approach makes it difficult to navigate and is only useful for people without any knowledge about computers. I really can't understand why everyone makes such a hype about this ... but it's just another matter of taste.

:)

[Amaranth]

The ini file format may change without warning, but the dbus api will not. In fact I might just change the format regularly to stop people modifying it in this way :twisted:

Not true at all, I plan to change the DBus API a lot in the near future. :) Should just be one big change then mostly static after that though.

[wfarr]

Sorry to say, but who likes SLAB should stick with compiz-settings for now. I personally don't like the "noobification" of gnome and prefer the kcontrol-style (to give another example of a really good control-center that follows the "navi-tree on the left"-style) - even though I am a gnome-user ...

The SLAB-approach makes it difficult to navigate and is only useful for people without any knowledge about computers. I really can't understand why everyone makes such a hype about this ... but it's just another matter of taste.

:)

We'll just have to agree to disagree.

I find KControl (which uses groups too!) to be messy and unorganized.

I also think things like the GNOME main menu (the one in GNOME, not SLAB's menu) is tedious and very "1995" in its approach, preferring gnome-main-menu version2 (currently svn) by the SLAB guys. :)

[mikedee]

The ini file format may change without warning, but the dbus api will not. In fact I might just change the format regularly to stop people modifying it in this way :twisted:

Not true at all, I plan to change the DBus API a lot in the near future. :) Should just be one big change then mostly static after that though.

A post about whats going to change and why would be nice ;)

I thought you were OK for introspection for the moment?

[Amaranth]

Right, introspection stuff is done. Most of the other work will be simple cleanups/additions.

Examples:
Changing everything to StudlyCaps to match DBus standard.
Moving getPluginMetadata to getMetadata on the plugin objects
Adding methods to allow you to dynamically walk the object tree (list of screens, etc).
Changes to activate (like your example) to make it work with introspection


That's pretty much all I have for now, haven't really dug into the idea yet.

[mikedee]

Adding methods to allow you to dynamically walk the object tree (list of screens, etc).

This would probably fit better into the netwm dbus api that I have planned. These functions will return values (as apposed to option activate which does not). Have a look in the plugin development section for a rough api. I'd be interested if you would like to help build that api as a library which could then be added to the dbus plugin.

Changing function names is probably OK (although you have to convince David ;)) but you should include a depreciated function for at least 1 version after, otherwise you will cause unnecessary pain. The introspection data can mark functions depreciated so people will get warnings ahead of time.

[delfick]

but it's just another matter of taste.

exactly :D
like the fact i love usp (http://www.ubuntuforums.org/forumdisplay.php?f=156) and hate the slab menu while others are opposite...
and like i love chander's control center (http://www.ubuntuforums.org/forumdisplay.php?f=157), instead of slab control center.. (and others are opposite)

:D (let that offtopic end there :D)

as for letting users select how the plugins are grouped, i think that's a great idea....have the plugins sorted into decent groups by default and give the option for the user to change a) what groups to choose from and b) how the plugins are sorted in those groups...

this way, it suits all needs :D
(same sort of idea for letting people choose the style of application :D)

[wfarr]

as for letting users select how the plugins are grouped, i think that's a great idea....have the plugins sorted into decent groups by default and give the option for the user to change a) what groups to choose from and b) how the plugins are sorted in those groups...

this way, it suits all needs :D
(same sort of idea for letting people choose the style of application :D)

This would be a gigantic waste of coding time.

How much time do people spend constantly fiddling with settings? Not that much. Maybe a little occasionally, but not enough to set there and lay out their groups how they want.

[delfick]

This would be a gigantic waste of coding time.

How much time do people spend constantly fiddling with settings? Not that much. Maybe a little occasionally, but not enough to set there and lay out their groups how they want.

hence it should become a long-term goal :D

[RYX]

How much time do people spend constantly fiddling with settings? Not that much. Maybe a little occasionally, but not enough to set there and lay out their groups how they want.
How long does it take to right-click on the tree, select "Add group ...", enter a name in the popup and drag/drop the plugins into your new group ... or drag another group into your new group ... it's pretty straight-forward. Deleting a group would be not more than right-click, select "Delete", yes - I really want to delete, ... gone :) ..

I'd say - it's always as difficult as the developer wants to have it ... and most "real" devs think too complex imho. The SLAB-style requires navigating forth and back between different views, while the splitted view of the kcontrol-style allows navigating _and_ using it at the same time.

But I think we have very different ways of thinking, so maybe we have also very different ways of organizing - thus we need totally different interfaces to improve our personal workflow. There should be an "adaptive UI"-system (don't come up with glade now ;) ...), which is capable of reacting to the way the user handles it. The UI should decide what the users likes by the way the users acts - of course leaving the possibility to manually configure stuff. (yes, I am dreaming)

:D

[wfarr]

How much time do people spend constantly fiddling with settings? Not that much. Maybe a little occasionally, but not enough to set there and lay out their groups how they want.
How long does it take to right-click on the tree, select "Add group ...", enter a name in the popup and drag/drop the plugins into your new group ... or drag another group into your new group ... it's pretty straight-forward. Deleting a group would be not more than right-click, select "Delete", yes - I really want to delete, ... gone :) ..

I'm simply saying, out of the potential userbase for Compiz and Compiz-Settings, especially now with Feisty shipping Compiz by default, 90% of users will in no way, shape, or form wish to re-organize their groups like that. They expect clear grouping that organizes the layout in an effective manner - not to establish their own system for doing so.

But I think we have very different ways of thinking, so maybe we have also very different ways of organizing - thus we need totally different interfaces to improve our personal workflow. There should be an "adaptive UI"-system (don't come up with glade now ;) ...), which is capable of reacting to the way the user handles it. The UI should decide what the users likes by the way the users acts - of course leaving the possibility to manually configure stuff. (yes, I am dreaming)
:D

If this is to be the case, then I think we can both agree that it is entirely crucial that we create a `libcompizsettings`that'll allow anyone to stick the written GUI of their choice right on top.

Personally, I think that would at least be a worthwhile investment. As for what language to write it in... I'd really prefer to use Python, as most of the actions we'll be taking will be requiring DBus, and Python's DBus bindings are quite good.

That said, should we take this route, we should probably start deciding on a standard API we'll want to maintain for the lib.

[Amaranth]

If it's supposed to be a standard library then python is out of the question, it has to be in C with bindings for other languages.

[wfarr]

If it's supposed to be a standard library then python is out of the question, it has to be in C with bindings for other languages.

If that's the case, I cannot help with the library, nor the bindings. :(

[delfick]

I'm simply saying, out of the potential userbase for Compiz and Compiz-Settings, especially now with Feisty shipping Compiz by default, 90% of users will in no way, shape, or form wish to re-organize their groups like that. They expect clear grouping that organizes the layout in an effective manner - not to establish their own system for doing so.

choice is good :D

i.e. those who want to organise can, those who don't want to organise don't have to.

[wfarr]

I'm simply saying, out of the potential userbase for Compiz and Compiz-Settings, especially now with Feisty shipping Compiz by default, 90% of users will in no way, shape, or form wish to re-organize their groups like that. They expect clear grouping that organizes the layout in an effective manner - not to establish their own system for doing so.

choice is good :D

i.e. those who want to organise can, those who don't want to organise don't have to.

The model of implementing every possible feature that could ever come to mind is inherently flawed. You end up with an attempt at a swiss army knife rather than a usable application.

[delfick]

a swiss army knife

but swiss army knifes are cool :D :D

so then....how about the grouping feature being implemented (i'm sure it wouldn't be that much work ??and it doesn't really bloat it that much.... (i can't program, excuse me if i'm wrong)

and then have the different interfaces as "plugins" to the configurator.....

or something similar so that the different ui's are seperate to the actual thing, so that by default it has say the bsm style (up to debate :D) and then those users who want a different style of configurator, can choose to download another ui to use (ignore the over simplification of that idea :P).....

[RYX]

If this is to be the case, then I think we can both agree that it is entirely crucial that we create a `libcompizsettings`that'll allow anyone to stick the written GUI of their choice right on top.

Personally, I think that would at least be a worthwhile investment. As for what language to write it in... I'd really prefer to use Python, as most of the actions we'll be taking will be requiring DBus, and Python's DBus bindings are quite good.

That said, should we take this route, we should probably start deciding on a standard API we'll want to maintain for the lib.
Yes, that's finally something we can really agree on :D .. That's what I meant with the CompizAccessLibrary - a library that abstracts the settings from the backend and can be used from any settings-tool. The settings-tool simply uses functions from the CAL, the CAL communicates with compiz (through any backend you define) and spits out CompOption-objects you can easily work with in the settings-tool. Ideally, the CAL would automatically choose the best available backend (like prefer fuse over dbus over gconf).

Such a CAL wouldn't need many functions, only the common dbus-api from compiz would be required.

:)

[FunkyM]

As this seems to go into the direction of looking for the best UI concept on a compiz configuration tool I'll add my cent.

From the usability tests done at http://www.betterdesktop.org/ you can see that the current openSUSE bundled configuration approach with the "Desktop Effects" control-center applet is by far not optimal.

Despite it's "abstract a setting" approach which usually should simplify the process (e.g.: "Windows are translucent while being moved.", etc.), people still failed to locate the corresponding settings for a targeted effect.

I think the reason for this was the lack of embedded icons and bad wording in the UI.

So how to find the best way of creating a configuration tool?

Define a set of requirements (GNOME-wise, what I seen in the posts so far):

The options of plugins should be dynamically retrieved (dbus introspection or a custom new abstracted settings layer API)
The UI should follow HIG, be simple (doesn't imply "giant-overlord abstraction") and integrate into the remaining desktop
The configuration tool should be placed in the control-center (capplet, tray-icon is a totally different tool here)
Icons with a clear metaphor should be used for known options
The options should be grouped in a hierarchy which allows simple navigation and works for all plugin types
Some things that might be up for discussion yet:

- Hierarchy?

Current SLAB approach: Groups, Plugins => Options
BSM/CSM: Groups => Plugins => Options
How about this: Groups, Window Manager Action => Plugin, Options

- There is a conflict between people wanting slightly abstracted options and people demanding advanced option configuration (Slider for a value vs. Text Input to write value, Checkbox for modifiers vs. Textbox for key modifiers, etc.). I think the abstraction wins here as an effect of the usability aims, however the abstraction should not differ too much from the features an advanced approach can offer. (Example: With a Textbox you could define any Keymodifier while a "bad" abstracted option approach might only offer a checkbox for "<ctrl>" and "<alt>".)
- Configuration backend? I don't know why this is still being discussed, it's clearly cross-DE DBUS as afaik. it will also be the only one yet to offer introspection and thus allow the configuration tool to dynamically populate it's settings; except you decide to develop an abstraction layer which offers the same (plus using different backends, possibly by autodetecting compiz plugin list).

Something like gnome-compiz-preferences from gandalfn already comes close to all this.

Using the requirements will for sure simplify the process of designing the
optimal UI for a compiz configuration tool.

[RYX]

Configuration backend? I don't know why this is still being discussed, it's clearly cross-DE DBUS as afaik. it will also be the only one yet to offer introspection and thus allow the configuration tool to dynamically populate it's settings; except you decide to develop an abstraction layer which offers the same (plus using different backends, possibly by autodetecting compiz plugin list).
The fuse-plugin which will come with the next release will offer a possible alternative to dbus. A compiz-access-library for python would offer a unified layer to "talk" to compiz and could use either dbus or fuse or whatever to do the real communication in the background.
It would make sense to separate this functionality into its own library beause there might come other python-apps who are interested in communicating with compiz and there is some boilerplate-code which can be reused by all of them (option-classes, callbacks, ...).

I don't think we neccessarily need only one config-tool for compiz. But if we have more than one they should maybe rely on the same library and only provide their own frontend. I understand that most non-advanced users would prefer a SLAB-style, but there are also many people prefering the kcontrol/bsm-style.

(Can you please explain your hierarchy-suggestion a bit more? :) Thanks ...)

:)

[wfarr]

I don't think we neccessarily need only one config-tool for compiz. But if we have more than one they should maybe rely on the same library and only provide their own frontend. I understand that most non-advanced users would prefer a SLAB-style, but there are also many people prefering the kcontrol/bsm-style.

I just had an idea.

Why not incorporate both into one front-end (since the aim for coming releases is to have an official compiz settings manager anyway) through means of an Basic and Advanced 'styles'.

The basic style could be a SLAB-esque front-end that is kept very user-friendly. It would have plugin descriptions and be organized similar to Control Center's style. It would contain options for low-to-average users.

The Advanced style, on the other hand, would replace the left-ward bar with a TreeView and would allow for re-arranging of the items in the tree. The advanced style would also contain EVERY possible option (things like elasticity of wobbly, etc)

[RYX]

Sounds good. That's very close to what I initally had in mind :D ...

(The "basic" and "advanced" styles would be represented through the various tabs in my approach)

I only wanted to avoid SLAB-style and leave the plugin-devs a possibility to create an individual settings-page for their plugin by adding a python-script to it. It would allow amazing user-friendliness - much more than SLAB ever could. The SLAB-thing is only for navigating anyway so we shouldn't make it too much of a problem ... it could easily be made optional.

:)

[pacho]

Is compiz-sttings still alive?

Thanks for information

[Kevin]

Don't post very often around here, but I thought I'd chime in on this one :)

I don't think having a SLAB style interface as the basic view is a good idea. Considering one SLAB interface controls all of gnome, I don't think we should need it for compiz only ;)

Basic should definitely be the gnome-compiz-manager front-end. Its simple, works like any normal gnome applet, and in there could have a button for an advanced dialog.

For the advanced dialog though, I'm not sure I really see the merits of a SLAB interface. If you're aiming to expose every single option, and have it for advanced users only, I think it'd actually be better just having every plugin listed and have its own dialog. To put this in a SLAB interface, this means having an icon for each plugin, which then opens another whole window with its options. Having them just listed on the left, with the options in a section on the right seems much simpler to me.

[benr]

Just a heads up, i'm waiting for Compiz 0.4.0 to be released before the next compiz-settings as the dbus api i think is going to change then so there's no point in updating now.

[wfarr]

Just a heads up, i'm waiting for Compiz 0.4.0 to be released before the next compiz-settings as the dbus api i think is going to change then so there's no point in updating now.

As Amaranth wrote the new DBUS, he could probably just give you the API. =)

[mikedee]

The dbus api in 0.4.0 is the same as the one now. 0.4.0 was branched a few days ago. I do not think the API will change drastically even after 0.5.0.

[RYX]

As far as I know Amaranth's changes only concentrate on the Introspection and some minor additions - he won't change the API (though it may be useful).

:)

[maurs]

It's normal when i try grab mouse i obtain (for ex.) <Control><Alt><Mod2>Button8 instead of <Control><Alt>Button8?

Naturally, it doesn't work how it should do...

P.S. When the next alpha release? :P

[maniac]

It's normal when i try grab mouse i obtain (for ex.) <Control><Alt><Mod2>Button8 instead of <Control><Alt>Button8?

Naturally, it doesn't work how it should do...

I don't know what doesn't work in your particular case, but FYI: Mod2 is the Numlock key.

[maurs]

I don't know what doesn't work in your particular case, but FYI: Mod2 is the Numlock key.

In my particular case, i would like to associate the button8 of mouse with the rotation of the cube (the classic <control><alt>button1). But when i change from compiz settings, i doesn't work anymore, either with the default settings.
I know it's a pre-release yet... but i think this info could be usefull for debug ;).

[cornelius]

Just reported a bug that has been annoying me:
https://bugs.launchpad.net/compizsettings/+bug/103373
Do you observe this too, or is it just me?

[Panacea]

Is there something wrong with the mirrors hosting the .debs? I'm trying to get the source/.deb for Feisty, and I can't connect to the server. Is there a mirror up someplace where I could get either of them?

[Kevin]

If this is being developed again, do you think someone should change the compiz-settings wiki entry, which has the big "All the links are dead and the project is abandoned" warning at the top?

[cbudden]

I am unable to get any file on compiz.biz, would someone mirror the feisty deb on rapidshare or something please.

Thanks

[rememo]

Treviño has the deb in his feisty eyecandy repository (along with latest compiz-git packages).
Find it here:
http://3v1n0.tuxfamily.org/dists/feisty/eyecandy/
and search for compiz-settings 0.07-1 .

[cbudden]

Treviño has the deb in his feisty eyecandy repository (along with latest compiz-git packages).
Find it here:
http://3v1n0.tuxfamily.org/dists/feisty/eyecandy/
and search for compiz-settings 0.07-1 .

Thanks.