Brainstorming for new settings-tool

[RYX]

Hi everyone!

We all know that the biggest problem we have is the lack of a good and up-to-date settings-tool. I spent a while working on that topic and want to start this thread as a brainstorming for ideas and to sum up the ideas and things I have already. This is a basic outline of what I expect from a serious settings-tool (feel free to add your own expectations):

- less is more (!!!!) - which means: if it is not essentially needed on the first look, hide it
- written in Python to allow as many people as possible to contribute
- uses compizutil-library as interface between backend (dbus/fuse/...) and frontend (the UI) to allow accessing compiz over various backends (should work with CompOtion-classes)
- has tree-like navigation on the left (similar to kControl or the eMail-tree in evolution)
- offers user-configurable groups in the tree (like in evolution), default grouping should match the (upcoming) new "grouping by target" in the wiki (see here for details (http://forum.compiz.org/viewtopic.php?t=812))
- searchbox above (or below) navigation to quickly find plugins or single options
- dynamic UI-creation using abstracted ui-classes like "StringInput, FloatInput, ... which would also allow implementing various frontends using different toolkits (gtk/qt/...)
- plugin-system to allow compiz-plugin-coders (or other people) to add additional input-elements and UI for individual plugins (e.g. the wallpaper-plugin could offer an additional tab/input with a representation of the user's viewports and a simple and attractive way to set images on the different viewports - e.g. by drag&drop)
- maybe a differentiation between simple and advanced mode, the simple-mode could be also defined by a plugin (i.e. script) which simply defines what options should be displayed in the "simple"-mode
- ideally it should be made to be extensible to not only configure compiz but also other apps (or at least not requires a rewrite if we want to do such things in the future)
- should automagically care for plugin-dependancies and/or -conflicts and display information-dialogs with human-readable information (!!!) whenever something can't be loaded
- plugin-based frontpage with a "frequently used settings"-plugin as default
- possibility to let two plugins appear under the same configuration (i.e. let one plugin "plugin-in" into the configuration of another plugin) ... (Note: maybe the grouping-feature could support something like that)

I will add things to this list as soon as they come to my mind (or other people note them). I already have written a (unfinished but working) compizutil-library and have a basic settings-tool to play with but I want to design the structure and workflow before coding any further.

Once we have a good and extensible base, we can setup a git-repo for it and everyone can work on it and contribute to it as he/she likes.

:)

[Spillaz]

THANK YOU!!!!!

This is exactely what we need. Three more things though

-MetaVtables, For example, Cube and rotate cube both control the same "feature" so why have two separate settings pages for them? Have them both on the "Desktop Cube" page
-Front page has "Most frequently changed settings"
-In expert mode, you should be able to decide the order in which compiz loads plugins. If the order is known to make compiz not load plugins then the user should be warned and the box should say [OK - Suggest a new order] or [No - Leave the order as it is]

[RYX]

Thanks, Spillaz - I added your suggestions to the list (slightly modified) :)

[wfarr]

- offers user-configurable groups in the tree (like in evolution), default grouping should match the (upcoming) new "grouping by target" in the wiki (see here for details (http://forum.compiz.org/viewtopic.php?t=812))

Seems largely unnecessary to me.

I also still dislike the tree idea. ;)


I'd much prefer a SLAB-based interface.

[RYX]

I remember that :D ...

My personal opinion is that SLAB is not extensible. A big amount of options and groups results in a total mess. A tree-like organization is much more flexible and dynamic. If SLAB-interfaces are so much more usable I wonder why everywhere else things are organized in trees ...

But - I think it would be possible and fit into the whole thing to add an alternative SLAB-style UI. Basically it is just another way of displaying the input-elements so it should be somehow possible to abstract it.

:)

[delfick]

methinks the frontend should be seperated from the backend so you can choose what interface you want...

i.e. slab
bsm
my mockup
gconf
whatever else type of interface there is..

......i love configurability :D

[bijoux]

My only request is _no automation_ whatsoever, just plenty documentation (information about plugins ie. requires, load befores, or conflictings)
I get so much errors dealing with GUIs than standard flat/text files as far as settings go.

thats just me though
:P

[Spillaz]

I just thought of another thing that could end this whole DBUS vs Text-based thing.

How bout the config files are written to when the settings are changed all the time no matter if compiz is running or not (So then you resume from the config files so to speak) and when compiz is running use DBUS and write the config files at the same time.

[Spillaz]

methinks the frontend should be seperated from the backend so you can choose what interface you want...

i.e. slab
bsm
my mockup
gconf
whatever else type of interface there is..

......i love configurability :D

Delfick, Its clear that your mockup >> everything else. If there is anything good about slab then we will put it into your mockup

[mikedee]

How bout the config files are written to when the settings are changed all the time no matter if compiz is running or not (So then you resume from the config files so to speak) and when compiz is running use DBUS and write the config files at the same time.

Could you explain why its so important to change the settings whilst compiz is not running? It seems like it has very limited uses

[RYX]

How bout the config files are written to when the settings are changed all the time no matter if compiz is running or not (So then you resume from the config files so to speak) and when compiz is running use DBUS and write the config files at the same time.

Could you explain why its so important to change the settings whilst compiz is not running? It seems like it has very limited uses
I agree that I can see not much use in it, but it would be easily possible to write a backend for the compizutil-library which directly reads/modifies the ini-files instead of taking the round-trip over dbus ... It would have the same effect and could be just another option.

:)

[Spillaz]

We had a topic before on this with an INI vs DBUS. DBUS had many upsides and was obviously much better than ini but had one problem. It couldn't change the settings while compiz was not running, meaning that if a user had some setting preventing compiz from starting up then they couldn't change it. The whole thing of applying changes in real time through DBUS and saving them to an ini/gconf/kconf file is a compromise between these two systems. it essentially allows compiz to "load" settings that have been applied while it wasn't there and also allows for settings to be changed in real-time. It is the ultimate safety net, much like journaling is in ext3.

Also has libbs been renamed to compiz-utilibrary or something?

[mikedee]

We had a topic before on this with an INI vs DBUS. DBUS had many upsides and was obviously much better than ini but had one problem. It couldn't change the settings while compiz was not running, meaning that if a user had some setting preventing compiz from starting up then they couldn't change it. The whole thing of applying changes in real time through DBUS and saving them to an ini/gconf/kconf file is a compromise between these two systems. it essentially allows compiz to "load" settings that have been applied while it wasn't there and also allows for settings to be changed in real-time. It is the ultimate safety net, much like journaling is in ext3.

If you think that applying the settings via dbus and then saving them is a compromise then its clear that you do not really understand what dbus is for. It seems like all the beryl devs originally misunderstood dbus and the original decision not to use it was based on 'gentoo users' and 'some people might not like dbus'. This is not a compromise, dbus is just a communication medium it has nothing to do with how the settings are stored.

Dbus is specifically designed to be run off-line and it has a facility to start your app if it is not running. All we need is a cut down version of compiz and we have everything.

Also has libbs been renamed to compiz-utilibrary or something?

Its sad that nobody has noticed that the more you 'integrate' libbs, the less relevant it becomes. Thats probably why it keeps changing its scope and seems to be taking forever to 'port'

[wfarr]

The problem is simply solved:

1. If Compiz is detected in the list of current DBus items, then the settings manager will use that.

2. If Compiz is not detected in the list of current DBus items, then the settings manager will launch its own DBus service that'll allow for the exporting of settings.


Sounds like a simple idea. ;)

[RYX]

2. If Compiz is not detected in the list of current DBus items, then the settings manager will launch its own DBus service that'll allow for the exporting of settings
I'd say if compiz is not listed on dbus, the app should simply use another backend from the compizutil-library (like an ini-based backend which writes directly to files or a gconf-based backend which saves to gconf-keys). I think that is the best and most extensible way to approach the "compiz-not-running"-issue.

[onestone]

What you describe is the libbs (new libberylsettings) system

[RYX]

I thought libbs is an alternative for dbus? From what I heard, libbs is some additional plugin, isn't it? The compizutil-library I thought of would allow using libbs as another communication-backend from python-programs ... Compizutil is written in python.

Or have I a wrong image of libbs? Maybe you can briefly describe how a compiz-plugin can be similar to the settings-manager I described ... (no offense here, just curious)

:)

[onestone]

libbs provides its own representation of the compiz options structures. It has its own storage backends (currently dbus,ini,kconfig). There is a plugin "bset" that uses libbs to initialize options in compiz. There will also be python bindings and different configuration tools (comman line, full auto generated with all options, ...). The mail goal of libbs is that it works without a running compiz.

[wfarr]

2. If Compiz is not detected in the list of current DBus items, then the settings manager will launch its own DBus service that'll allow for the exporting of settings
I'd say if compiz is not listed on dbus, the app should simply use another backend from the compizutil-library (like an ini-based backend which writes directly to files or a gconf-based backend which saves to gconf-keys). I think that is the best and most extensible way to approach the "compiz-not-running"-issue.

That could certainly work too. :D

[RYX]

libbs provides its own representation of the compiz options structures. It has its own storage backends (currently dbus,ini,kconfig). There is a plugin "bset" that uses libbs to initialize options in compiz. There will also be python bindings and different configuration tools (comman line, full auto generated with all options, ...). The mail goal of libbs is that it works without a running compiz.
I see, thanks for the explanation (the name is not very descriptive :)) - but isn't it a useless overhead to create a separate binary library only for that? It can all be done in pure python which is much easier to maintain and develop and offers a wider range of people to participate in its development. It seems like entirely duplicate effort to have a library that does the same thing as dbus/fuse/*-interface together with ini/gconf/kconfig/*-backends ... Excuse me if I am a little bit skeptical but I don't really see the advantages of doing that in C.

[maniac]

but isn't it a useless overhead to create a separate binary library only for that? It can all be done in pure python which is much easier to maintain and develop and offers a wider range of people to participate in its development. It seems like entirely duplicate effort to have a library that does the same thing as dbus/fuse/*-interface together with ini/gconf/kconfig/*-backends ... Excuse me if I am a little bit skeptical but I don't really see the advantages of doing that in C.
libbs (yeah, the name is really not that descriptive ;) ) provides more features than you can achieve with such a bridge: As onestone already said, you can run it without compiz running at all (for example to cover cases where Compiz is misconfigured and doesn't start up at all). Also, there is support for different settings profiles.

And didn't you suggest a libcompizutil after all? libbs is almost exactly what you suggested here (http://forum.compiz.org/viewtopic.php?p=7564#7564) ;)

[Spillaz]

I thought libbs is an alternative for dbus? From what I heard, libbs is some additional plugin, isn't it? The compizutil-library I thought of would allow using libbs as another communication-backend from python-programs ... Compizutil is written in python.

Or have I a wrong image of libbs? Maybe you can briefly describe how a compiz-plugin can be similar to the settings-manager I described ... (no offense here, just curious)

:)

LibCCS (Compiz-Community-Settings) is actually the backend which is going to handle everything to do with settings storage and what not. It is essentially beryls version of libcompiz-util. IMO it should be modified to support DBUS and fuse. Heres why ;

-inotify has problems atm. Settings have to be refreshed every single time something changes. And sometimes this doesnt work and you need to restart compiz every time you want your settings to be chnaged
-By sending these chnages straight to compiz you are eliminating the overhead of changing the settings files and watching the settings files for chnages then parsing them then refreshing all settings.
-The combination of DBUS and LibCCS would be brilliant because when compiz is running you send your options straight to compiz THEN write them to the settings file so they can be loaded LATER. When compiz is not running you write it to the settings file so that when compiz loads it loads the options you changed. This eliminates the overhead of the steps required for LibCCS and the non-utility of DBUS when it is not running

[delfick]

methinks the frontend should be seperated from the backend so you can choose what interface you want...

i.e. slab
bsm
my mockup
gconf
whatever else type of interface there is..

......i love configurability :D

Delfick, Its clear that your mockup >> everything else. If there is anything good about slab then we will put it into your mockup

lol :D

[franzrogar]

(Hi delfik :) )

libbs provides its own representation of the compiz options structures. It has its own storage backends (currently dbus,ini,kconfig). There is a plugin "bset" that uses libbs to initialize options in compiz. There will also be python bindings and different configuration tools (comman line, full auto generated with all options, ...). The mail goal of libbs is that it works without a running compiz.
I see, thanks for the explanation (the name is not very descriptive :)) - but isn't it a useless overhead to create a separate binary library only for that? It can all be done in pure python which is much easier to maintain and develop and offers a wider range of people to participate in its development. It seems like entirely duplicate effort to have a library that does the same thing as dbus/fuse/*-interface together with ini/gconf/kconfig/*-backends ... Excuse me if I am a little bit skeptical but I don't really see the advantages of doing that in C.
Just my thoughts:

As now, LSB 3.1 doesn't have any Python onto spec, so I think having both python & C could be the best option.

As you can see in [1], Python is intended to be included on LSB 3.2 (Q2? 2007) but for now, it isn't. So, to avoid issues when installing on a "perfect" LSB distro, you have libbs and in the others, you can "choose" (one of the liberties :) )

[1] http://www.linux-foundation.org/en/LSB_Roadmap

[Sorcerer]

Though LSB 3.1 doesn't include Python, almost all of the major distros install it by default. It is highly unlikely that anyone would attempt installing Compiz on a distro without Python.

[RYX]

I really agree. E.g. any system that has gnome installed will definetly have python by default. I don't know of any distribution that doesn't offer at least python in form of additonal packages. Python is the official Linux-desktop language ... half of the modern Linux desktop is already written in python.

Concerning the libbs (or libccs which still is kinda cryptic :)) - I still think there is a useless overhead in creating a binary library which does exactly the same thing as a couple of lines in python can do already. Due to the different backend-classes the compizutil-library can easily save settings while compiz is not running and also offers functions to export/import profiles to/from XML (and I bet that is a real pain in C). If a new backend/communication-interface is implemented into compiz it will take one day and there will be a new CompBackend-class available to utilize the new backend. In C it will take some talented developer who has nothing more important to do ... (which happens as often as eastern and christmas are one the same day).

The python-based compizutil-library does exactly the same as libbs, but it is object-oriented, portable and most likely only 10% of LOC ... Also libbs only encourages more people to write GUI-apps in C - which is truly masochistic and the _major_ reason for the lack of config-tools we are facing today.

However, I guess I'll have a look at libbs to see how it works and maybe find some advantages - so nobody can say I am not willing to understand/accept other opinons ;) ...

:)

[RYX]

-By sending these chnages straight to compiz you are eliminating the overhead of changing the settings files and watching the settings files for chnages then parsing them then refreshing all settings.
-The combination of DBUS and LibCCS would be brilliant because when compiz is running you send your options straight to compiz THEN write them to the settings file so they can be loaded LATER. When compiz is not running you write it to the settings file so that when compiz loads it loads the options you changed. This eliminates the overhead of the steps required for LibCCS and the non-utility of DBUS when it is not running
Exactly this can be easily done without libbs - where is the reason to create python-bindings for libbs and use libbs from python, if I can achieve the same things easier, better maintainable and with less code if I write it in pure python?

[delfick]

(Hi delfik :) )

hello :D

tell me, did you like my mockup or the actual bsm better in the end ?? :D

(for those who don't know, franzrogar made the mockup both my mockup and the bsm was based on....(if my memory serves me right :P))

[maniac]

Concerning the libbs (or libccs which still is kinda cryptic :)) - I still think there is a useless overhead in creating a binary library which does exactly the same thing as a couple of lines in python can do already. Due to the different backend-classes the compizutil-library can easily save settings while compiz is not running and also offers functions to export/import profiles to/from XML (and I bet that is a real pain in C). If a new backend/communication-interface is implemented into compiz it will take one day and there will be a new CompBackend-class available to utilize the new backend. In C it will take some talented developer who has nothing more important to do ... (which happens as often as eastern and christmas are one the same day).

The python-based compizutil-library does exactly the same as libbs, but it is object-oriented, portable and most likely only 10% of LOC ... Also libbs only encourages more people to write GUI-apps in C - which is truly masochistic and the _major_ reason for the lack of config-tools we are facing today.

Only drawback I see here: The compizutil library doesn't exist in code yet ;)
And libbs is supposed to get Python language bindings pretty soon ... the plan is that the actual settings manager is written in Python.


However, I guess I'll have a look at libbs to see how it works and maybe find some advantages - so nobody can say I am not willing to understand/accept other opinons ;) ...

That's nice :)

[RYX]

Concerning the libbs (or libccs which still is kinda cryptic :)) - I still think there is a useless overhead in creating a binary library which does exactly the same thing as a couple of lines in python can do already. Due to the different backend-classes the compizutil-library can easily save settings while compiz is not running and also offers functions to export/import profiles to/from XML (and I bet that is a real pain in C). If a new backend/communication-interface is implemented into compiz it will take one day and there will be a new CompBackend-class available to utilize the new backend. In C it will take some talented developer who has nothing more important to do ... (which happens as often as eastern and christmas are one the same day).

The python-based compizutil-library does exactly the same as libbs, but it is object-oriented, portable and most likely only 10% of LOC ... Also libbs only encourages more people to write GUI-apps in C - which is truly masochistic and the _major_ reason for the lack of config-tools we are facing today.

Only drawback I see here: The compizutil library doesn't exist in code yet ;)
And libbs is supposed to get Python language bindings pretty soon ... the plan is that the actual settings manager is written in Python.
So if that's the only drawback :D ... The compizutil-library is only half-finished yet (mmmh - maybe only 30% :)) because I didn't want to decide about it's layout only from my personal point of view (and would like others to participate in this). For the beginning I mainly based it on what compiz-settings requires because I initially started a very small python-version of compiz-settings. The only available backend is Dbus right now (yes it's no real backend - with backend I mean the way the lib gets the settings into/from compiz) - but gconf, fuse and ini would likely make sense as additional backends.

[franzrogar]

(Hi delfik :) )

hello :D

tell me, did you like my mockup or the actual bsm better in the end ?? :D

(for those who don't know, franzrogar made the mockup both my mockup and the bsm was based on....(if my memory serves me right :P))

Your memory serves you right :) Mine is a bit in-its-way ;) I forgot completely to mockup each plugin conf and send them to you as I promised... SORRY! :oops:

I like both of them. Probably, yours one could be added as another option and, as RYX? or mikedee? suggested to be implemented on ActionScript 3.0 on Linux-free ;) or maybe added as CSS & javascript to cws. :)

I really agree. E.g. any system that has gnome installed will definetly have python by default. I don't know of any distribution that doesn't offer at least python in form of additonal packages. Python is the official Linux-desktop language ... half of the modern Linux desktop is already written in python.

And into the main chit-chat, RYX you're right but what about the other half of them? :) Anyway, when LSB 3.2 gets out, evry distro will have python :) even if DE don't need it. So, the only option I've is that "it's another option you can choose" ;)

Anyway, I want them all :)

[delfick]

I forgot completely to mockup each plugin conf and send them to you as I promised... SORRY! :oops:

and the profile manager thingo :P :D

but it doesn't really matter :D