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)
- 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)

Seems largely unnecessary to me.

I also still dislike the tree idea.


I'd much prefer a SLAB-based interface.

[RYX]

I remember that ...

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.

[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

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