Does anyone feel like writing a KDE configuration backend?

[RAOF]

I've had just about enough of people talking about Compiz's "Heavy Gnome dependencies" crap.

Sadly, I can't just say "No, you're totally wrong", I have to say "No, it's because no-one has been bothered to write a KDE configuration backend". I've looked at the gconf plugin, and it looks like it should be easy to do. However, I don't use KDE, and I don't know about whatever configuration system KDE uses. So, much as I'd like for there to be a KDE backend, it's not really something I'd do on my own.

Surely there's some developer here who uses KDE and who'd like to write, or help write, a backend?

[wfarr]

Similarly, someone should make a port of gnome-compiz-manager for QT.

[RYX]

I absolutely agree and support your idea. I'd like to help, but it most likely has to come from the KDE-users' side, because I don't know a thing about KDE and Qt.
The first person coming to my mind would be mikedee, but he seems pretty happy with gconf ... :)

(But I have to add that there are no "heavy gnome dependancies" at all ... gconf is the only one, isn't it? I guess KDE-users don't need to install any metacity-support or gtk-window-decorator ...)

:)

[RAOF]

...
(But I have to add that there are no "heavy gnome dependancies" at all ... gconf is the only one, isn't it? I guess KDE-users don't need to install any metacity-support or gtk-window-decorator ...)


That's right, and what I say.

It's still hard to recommend Compiz to, for example, KUbuntu users though. Gconf pulls in quite a lot of dependencies, and without it they don't get configuration.

[stjepan]

I asked David about a new configuration system and he just said:
The number of people who are interested in text-based configuration
support is very limited. Giving a few thousand SLED users a good user
experience has higher priority for me than implementing something that a
few users that hang out on the forum wants. I hope you can respect that.

There's nothing that stops someone else from implementing some
text-based storage of compiz options. If the dbus dependency is alright,
then it shouldn't take much more than an hour or two to write a simple
daemon that keeps a text file in sync with all options exported by
compiz.

- David

Anyway, what's wrong with gconf?

[gnumdk]

http://extragear.kde.org/apps/kconfigeditor/

This will let you modify gconf with a kde gui.

[RAOF]

The number of people who are interested in text-based configuration
support is very limited.
...


Emphasis mine.

I'm not talking about a text-based configuration system. My aim is to add the final piece of KDE integration necessary, so I can recommend Compiz to KDE users. It's even on the git's TODO list.

Anyway, what's wrong with gconf?

There's nothing wrong with gconf. It works extremely well, which is why writing a text-based config system is a large step backwards. However, it's not the way that KDE apps store their preferences, so it's a suboptimal solution for KDE users.

[mikedee]

Well your first post said

I've had just about enough of people talking about Compiz's "Heavy Gnome dependencies" crap.

I assume those people also choose Beryl because it has none of those dependencies, right? I can only assume that "heavy gnome dependencies" came right from them.

I hate this BS as much as you do but there is nothing that really can be done at the moment. Here is why I dont think anyone has written a KDE backend..

* KDE is in 3-4 flux at the moment and if I am correct the configuration system in 4 is different to 3. This will mean major support headaches and even more complaints.
* Compiz core is not finished yet, it could change a lot (including the config system) over the next year.

Personally I'd rather wait for KDE 4 and then see what happens.

There are still a few missing pieces of the puzzle before we can have many different backends (mainly small issues). Once we have them though, they will work very smoothly and will be supported well. At the moment it would be a nightmare to support >1 backend.

As for Gnome dependencies, Compiz itself has no gnome dependencies whatsoever. If you compile just the core without the gconf plugin then there are no dependencies. Beryl on the other hand has a core dependency on glib which is part of Gnome. This means that even if you use the ini backend on Beryl (which everyone does), you still require parts of Gnome. Just imagine the uproar if Compiz core depended on QT-core or glib.

I am more than happy to wait until all the surrounding infrastructure is in place before rushing ahead for 5% of the population. Personally I think all the anti-gconf attitude is something that has been spread into peoples minds by Beryl devs. What is the problem in installing it anyway? Surely you guys don't have 32Mb ram and a 2Gb hard drive?

Look at it this way, we have given up a KDE config system, but instead we have just received a fragment system (along with a fast blur plugin) and initial support for input redirection. I know which Id prefer.

BTW - I wouldnt pay too much attention to the current TODO in git, it seems a bit outdated, virtually everything under general is done.

[imnotpc]

I've written several Qt4's apps and the settings functions are pretty easy to use. I could probably do most of this if I has some help with the dbus stuff and icons. It would be better if someone else wrote this but I'll put it on my todo list and if nobody else picks it up I'll give it a shot.

[mikedee]

There are 2 distinct parts which we need

1. A kconfig plugin backend.
2. A KDE configuration app which integrates with KDE Control Center

Number 1 would need to be a plugin written in C++ which feeds data into compiz and changes the config file based on internal changes in compiz.

Number 2 could then change this file, which would trigger the backend to update compiz' internal state. Alternatively it could change the internal values with dbus which would then signal to the plugin to update the file. Dbus is preferred because it removes the tie between the config app and the backend, plus there are a few extra benefits like notification of newly available plugins.

There are examples of QT-Dbus use in kde-window-decorator, a configuration app would use the same code but different values passed to the functions.

[Amroth]

Hi everyone :) I'm a KDE user, and I've been lurking the Compiz forums from since the release of .3.6, in the pure hope I would see some volunteered KDE user giving the Compiz community a shiny new KConf plugin. Since then I've (we've?) got no luck. :(
Well. I've just started poking in QT/KDE development (with the KMess app); I've tried KConf, and it's really easy. A little searching taught me that 'real' DBus bindings only belong to QT 4.2+, so for us poor QT 3.x users that would be another problem; lucky us, there's a QT3 port for the DBUS bindings in the official DBUS site, along with docs. So I'm downloading that, too.
Moral of the story, I'll try to write a KConf+DBus backend. Hoping to succeed since my lack of experience :roll:

ps. about kde4, the >1 backends problem... well, that's not too much fuss needed, i can live with it to be able to use Compiz on KDE without Gnome deps.

[wfarr]

Good luck! :)

[mikedee]

I have just finished a flat file backend plugin for compiz. Its almost finished, when it is it will be in the official distribution.

[Amroth]

thanks :D it doesn't seem TOTALLY hard.. it won't take an huge amount of time :lol:
yay for the flat file backend! more possibilities for us compiz-addicted :)
Oh another thing, is there anything like a working compiz-settings app for QT written in something-not-requesting-7-billions-dependencies? like in C/C++?

[wfarr]

thanks :D it doesn't seem TOTALLY hard.. it won't take an huge amount of time :lol:
yay for the flat file backend! more possibilities for us compiz-addicted :)
Oh another thing, is there anything like a working compiz-settings app for QT written in something-not-requesting-7-billions-dependencies? like in C/C++?

All the existing ones are currently GTK AFAIK.

[RAOF]

And, just to poke my oar in, you're not after a program that doesn't have 7 billion dependencies, you're after a program that has dependencies that you've already filled. A program should have as many useful dependencies as possible :).

C & C++ are both awkward tools for writing a GUI. Since you generally couldn't tell if a settings frontend was running 100 times slower than the equivalent C code (as a hugely pessimistic exaggeration), you might as well make it easier to code!

[Amroth]

Well, with 3d desktop managers i ran into huge dependencies problems, something around the lines of "you need to configure stuff eh? here,change version of everything from glib and up, to older versions, install gnome too, and you're done" or "oh, you're using a version of QT too new, around only for what, an year? And you want us to make updated bindings for [insert scripted language name here]? You fool!" or "I won't compile. Fsck you. No, don't even try to fix me, try downgrading your interpreters". That was like in December so maybe things are changed on both compiz & beryl's side; but still, as a KDE user I feel a little left behind :(
That was only to say I would really like a configurator capable of needing only QT, maybe KDE, DBUS and of course Compiz to work, without installing bindings,libraries which I never heard of, et cetera.
Let me also point out that i'm not the integralist kind of linux user, it's just that i tried for weeks to get all every possible configurator working in my KDE-only box, and i found only one to work without a LOT of system packages messing, and it was hell of a limited one.
The enormous quantity of lost time made me think that maybe writing a KConfig backend & a QT C++ configuration tool could be worth the effort. But if is there anything like that already being developed, please tell me so I can try to contribute!

[imnotpc]

I've found that there are substantial dependencies to develop Qt4 apps although in current distros like openSUSE 10.2 there are pre-configured development groups you can select during installation which make this easy. As far as the client, you can compile static versions and avoid the Qt/KDE dependency issue.

[mikedee]

I think it should be fairly easy to write a gui which slots into the control panel. It would only need to use dbus to populate and change the options.

You could then use the ini backend, you would not need to do a kconfig backend until it was easier to distribute.

[Amroth]

Yep, it is, you can use almost only the gui editor since it does a lot of the 'hard' stuff needed in a tool like this.

But I still wanted to give the backend a try, since the KDE config system is really easy to implement stuff with. Oh, since I've always worked only with C++ programs, is there a way to insert peacefully a .cpp plugin in the existing Compiz build system? Or am I forced to make the plugin in a separate environment? I've also found there's no KDevelop template for shared libraries.
I could use an hand of help here :P