Hey dobey,
You recently blogged:
|
I’ve been working on a specification for configuration infrastructure. Last weeks I’ve been discussing this with some of the key-players in the field of configuration management on the free desktop (including the authors of gconf, kconfig, the config system of openoffice.org and mozilla). I’m convinced that in order to get third party application developers on our side, we need to have a solid and consistent way of dealing with this type of application development obstacles. I will not yet publicise this work because I want it to be perfect first.
I have also been talking about the many problematic design flaws of the X11 clipboard (and I proposed a solution). And recently I mentioned the existence of openusability.org to the GNOME usability team. Both in blogs and on the mailing list. And I blogged about the importance of an infrastructure and/or standard for presence notification. I’ve also prepared the Python bindings for this infrastructure and I’m planning to (if nobody else is going to do it) adjust Gossip in such a way that it registers with Galago.
I also wrote this blog, just to make sure everybody is aware of my targets. I’m planning to put a lot of my free time in the targets you can extract from that document. Knowing I’m probably not going to succeed in any of them. Mainly because of the huge amounts of stop-energy we have in our communities.
These are only the recent actions that I’ve been taking. A few years ago I decided to help the Anjuta team because I was convinced that the GNOME environment lacked a good IDE. And that this was holding back third party developers (Face it. vim and emacs are not always what they want to use. Look at Visual Studio. This is often what they want. Yes really). I’m planning to rejoin them because their work on Anjuta2 is starting to look great. I specifically like the gnome-build stuff (they didn’t create this, the project Scaffold of Jeroen Zwartepoorte caused it to get written. But Anjuta2 is the first project to use it and they are, as far as I know, doing bugfixes for the component).
So what I’m basically trying to say: If you need somebody who is waiting to get in action to work on this type of jobs: I’m here. And I’m willing to put my (free)time on this. Regretfully there’s no leadership or committee steering this. Freedesktop.org already responded that they are not planning to be that leadership. So it’s very very hard. Also note that many of our social differences have made it very hard to talk to team members of the other teams in a constructive way (for me, that’s for example the KDE developers). It’s a very unpleasant obstacle. It’s yet another reason why I don’t yet want to publicise my work on the (protocol) specification for configuration infrastructure (so it’s not “dconf”, it’s a spec that a project like “dconf” would have to implement — Yes, I’m also trying to implement it. So this is not vaporware –). It needs to be perfect in every possible way first. There’s a lot stop-energy. Also in our very own team. It’s very very hard to “just do it”. And in my humble opinion are few people doing it nor are planning to do it.
"Regretfully there’s no leadership or committee steering this."
Leaders in open source are people who doing it, not committees who are telling others what to do.
You won’t get any stop-energy from me. Go go go! Initiative is great, action is even better!
Keep the creative juices flowing!
dconf-as-a-spec is the way to go, as it gives you liberty to implement it the way you like. If it is better than the others, then they will use it in the end, and won’t bomb you in the begining. Congrats.
I am really happy to see this working forward, and especially, to see you working with the KDE guys. They are not that bad. Seriously.
Cheers,
Carlos Woelz
A KDE user and contributor
Here is some one else who wants to replace gconf & co.
mail.gnome.org/archives/n…
Good luck!!!
I don’t know if your interest in the X11 clipboard is still current. A couple of comments on the proposal linked to in this article.
1) The problem of a clipboard manager having to save all the different formats a client can offer becomes simpler, at least in theory, when you consider that the client will normally only have one, occasionally two or three “native” clipboard formats, and that the others are formats which have been generated on the fly by the client. (Consider a web browser offering an image. The native formats are jpeg (say) for the image and text/utf8 (say) for the alternative image text. Other formats on offer are generated from these). So the manager only really needs to cache these native formats.
2) You discuss compatibility with the X11 clipboard and interaction with VMs and other systems on the network. In fact, you just need a dbus (say) based clipboard format which is friendly to proxies. Then proxies can be written for the X11 clipboard, remote machines and VMs. In fact, VMs usually implement some form of networking between host and guest, so the remote machine proxy should work for them too.
Read “dbus-based clipboard protocol”, not “format” above.