Better Settings Manager

[apokryphos]

This has been said in other threads around vaguely, but it's good to have a direct here for solely this issue, as I think it's a fairly large one.

Gconf is ok, but it's not really great, and it's off-putting to users. What's needed is (i) a more accessible manager with all the options, and (ii) a simplistic manager for more end-users (the one in SLED actually probably suffices.

[amgeex]

Have you checked the Gnome Compiz Manager out?

http://gandalfn.wordpress.com/gnome-compiz-manager/

Here are some screenies:

http://gandalfn.wordpress.com/gnome-compiz-manager/screenshot/

It is certainly a better app for new Compiz users, it is simpler and more intuitive.

[apokryphos]

Yes, that's the one in SLED. Nice and simple, indeed.

[mikedee]

I think zootreeves is also working on a settings manager. That should be released soonish.

[RYX]

I had thought about various possibilites to improve the settings before. One approach I'd really like would be adding all window-related settings to each window's right-click menu. That should go hand-in-hand with per-window-settings for individual effects (i.e. plugins) like animation ... For that approach, the settings-manager could utilize the state-plugin for realizing per-window-/per-app-settings.

Additonally, the settings-menu could offer small config-dialogs (realized with gtkdialog/bash or some scripting language) and some underlying action-system that allows assigning menu-entry/popup combinations to certain gconf-keys ...

So in short: a dynamically extensible menu which uses compact dialog-popups to create a end-user-friendly and logically structured way to configure _anything_ you like - and the advanced user can configure/extend this menu in _any_ way he can imagine ...

(Though I like all other approaches, too - I always am a friend of having something individual ... so maybe we should overthink the general idea of what is expected, to do something unique)

:)

[RYX]

Another good way of handling settings (at least from an advanved user's perspective) would be to have "good old" config-files (in modern XML-format). I'd like to have something like a libxmlsettings-plugin that offers one action: reload_settings. It should load its files (or best: only one config-file) from $HOME/.compiz/settings. The xml-files should be straight-forward and offer the ability to set any config-settings within the core and the plugins.

I know it could be implented as an alternative or addition to the current system, I only wanted to note it before I forget it (again) ...

[RAOF]

I had thought about various possibilites to improve the settings before. One approach I'd really like would be adding all window-related settings to each window's right-click menu. That should go hand-in-hand with per-window-settings for individual effects (i.e. plugins) like animation ... For that approach, the settings-manager could utilize the state-plugin for realizing per-window-/per-app-settings.
...

That sounds horribly like KDE's window context-menu, which is my poster-boy reason for not using KDE.

That said, many people (inexplicably) like KDE :).

[RAOF]

Another good way of handling settings (at least from an advanved user's perspective) would be to have "good old" config-files (in modern XML-format). I'd like to have something like a libxmlsettings-plugin that offers one action: reload_settings. It should load its files (or best: only one config-file) from $HOME/.compiz/settings. The xml-files should be straight-forward and offer the ability to set any config-settings within the core and the plugins.

Haven't you just described the gconf plugin? Except that it doesn't have a relaod_settings method, it just automatically does it anytime you change something :).

You can find gconf's plain-ol'-xml files in ~/.gconf/apps/compiz and subdirectories.

It might be nice to add profiles/themes support to the plugin (ie: save, name, and restore your whole compiz settings tree), but I'm pretty sure that can all be done in gconf.

[RYX]

That sounds horribly like KDE's window context-menu, which is my poster-boy reason for not using KDE.
I don't know KDE's window-menu, but maybe it is a little extreme to not use KDE because of a menu that is hidden under your windows' titlebar? There are dozens of other reasons why I don't like KDE, too - but you really don't like easily accessible configurability? I use gnome, but I simply disagree with that "treat-the-user-as-stupid"-behavior, gnome tends to have ... only because they think users may be confused by too many options, they strip out functionality ... KControl is great and I'd like to have a exact clone for gnome ...

Haven't you just described the gconf plugin? Except that it doesn't have a relaod_settings method, it just automatically does it anytime you change something :)
Yes, maybe - but the automatic changes whenever I do a change to a gconf-key are what I hate most. And I'd like to have all settings in one file, messing with the individual files in 20+ subfolders seems even more chaotic to me ... however, this idea wasn't meant as replacement for existing settings, more an addition ... (but it would allow profiles/settings-backup in a very easy way).

(One of my rethorical questions: Some things worked fine in the past, so why shouldn't they still be good for today? It's like when my girlfriend is highly surprised that you can make a pie without using an electrical mixer, by using a "good old" wooden spoon. I asked her what she thinks the people 200 years ago did when they wanted to make a pie ... Using an ox-driven mixer? No using a spoon and some manpower ...)

So RAOF,what's your personal favorite for a settings-system - since you apparently don't share my ideas?

:)

[Guest]

I'm trying to come up with a better UI for my settings manager, at the moment it looks something like this

http://qkos.com/Screenshot-1.png

I can still do a lot of cleaning up, but it's still going to look a bit of mess no matter what. I was thinking of trying to change it to something along these lines...

It's a ripoff of SLAB, i know, but i think it would work well. I've just edited a screenshot for the time being to make a mockup.
http://qkos.com/compiz-settings-manager.png

Basically you'd have all the plugins listed, with icons and a short description. Then when you click it comes up with something like this.
http://qkos.com/compiz-settings-manager2.png

Just wondering what everyone's thoughts are on this, do you think it's worth my time doing? Or should i just still with the current layout and get it released?

[RYX]

I think it looks really promising the way it is. Maybe you could replace (or extend) the checkboxes on the left with icons for the plugins (like in bsm), but its only for the look&feel ... I really like that approach. It would be good for new users to have a lower area in the right half where detailed information about each setting is displayed (but maybe you already planned that?).

Great work ... :)

[gandalfn]

I like much the slab concept, very nice ! ;) If you need some help ... ;)

gandalfn

[amgeex]

I like the slab 'version' a lot too. It looks way more organized and user-friendly. It would give compiz a better chance of attracting new users. The other version is looking too much like bsm though, me no like. My vote goes to the slap approach.

[RAOF]

It's extraordinarily difficult to expose that much configuration in a sane way. The SLAB idea seems like a really good start, though.

Maybe there could be another layer between the SLAB stuff and the bare-metal every-option screen? With just the really important options, and applying to all screens? So, for example, the first layer of Cube would have options such as "Skydome pic", "Top pic", a number of workspaces flipything box (you know, the one with the number and the up/down arrows). You could then have a "per-screen settings" button, and an "advanced settings" button. You do want to be able to get at all the functionality, but at the same time you want the most-used functionality to be easiest to get to :).

Oooh. It occurs to me that we pretty much already have "profiles" support in the gconf plugin - the option-per-screen stuff. Add the ability to give it a name, rather than "screen0", and the ability to switch the current "screen", and you're there. Cool.

[RYX]

I think the "slab"-version is nothing more than a nice looking replacement/frontend for the first approach's "menu" on the left. It gives a better first impression, but it is exactly the same ... So maybe the "slab"-version can easily be added as an extension to the first approach ...

If there would be some underlying XML/config-file(s) that allows creating groups or collections of settings, you could create a dropdown-list (or tab-panel) where people can select from something like "Basic Settings", "Advanced Settings", "All Settings" and could even create their own prefered "Setting-sets" ... That way you would leave it up to everyone which settings are available and people could share "settings-packages" to be added to the defaults (should solve a lot of problems before they are even discussed) ...

(And the program would suddenly become reusable for everything and be an "abstracted" settings-tool)

Just a thought ...

[RAOF]

...
If there would be some underlying XML/config-file(s) that allows creating groups or collections of settings, you could create a dropdown-list (or tab-panel) where people can select from something like "Basic Settings", "Advanced Settings", "All Settings" and could even create their own prefered "Setting-sets" ... That way you would leave it up to everyone which settings are available and people could share "settings-packages" to be added to the defaults (should solve a lot of problems before they are even discussed) ...
...

Hey, wouldn't that be a nice thing to integrate into the DBUS interface. Give the plugins an interface to provide richer metadata on the options (grouping options, the importance of an option, dependencies).

Ultimately, the easiest way to ensure that documentation matches actual usage is to have the documentation provided by the plugin itself :). Having a separate config file leaves you with the problem of needing to update it for each new plugin/plugin revision. Get the plugin writers to explain the options themselves!

[Guest]

Hey, wouldn't that be a nice thing to integrate into the DBUS interface. Give the plugins an interface to provide richer metadata on the options (grouping options, the importance of an option, dependencies).

Ultimately, the easiest way to ensure that documentation matches actual usage is to have the documentation provided by the plugin itself :). Having a separate config file leaves you with the problem of needing to update it for each new plugin/plugin revision. Get the plugin writers to explain the options themselves!

Yeah but the problem with that is if compiz is not running then it would be impossible to get any options. I though of a way round this by saving the last available configuration in an xml file and then using that if dbus is down. I was originally planning to do this, but at the moment dbus does not support metadata options (at least the patches are not included in git yet).

Btw here's the interface i have gone for (still WIP):
http://www.compiz.biz/Screenshot-3.png
http://www.compiz.biz/Screenshot-4.png

I would like to have kept support for the old interface as well, but the code was getting too bloated so I have removed it.

[nzjrs]

I like it. Whats is written in?

I think the approach you have gone with is a good mix of the first two options you posted.

[Guest]

It's written in C - 1st release http://forum.go-compiz.org/viewtopic.php?t=153