I haven’t mentioned confuse or deconf nor the deconf specification lately.
That’s mainly because at this moment I’m focusing myself on other things. In a few weeks I’ll have a long holiday, chances are high I’ll work on a few of my items in my growing to do list.
Amongst them are further improving codegen and deconf-desk, an implementation of this desktop configuration standard which I wrote a few weeks ago.
However. Since it’s a good practise and since it might help interested people in joining the efforts of implementing it, I created a UML Class diagram of what is current and of what the idea is. If you don’t know how to interpret a class diagram, you can of course use codegen to generate code from it.
You can find it here. It obviously uses the observer/observable pattern a lot. That’s because successful current configuration systems also use it (like gconf, you can view the desktop applications as the observers and the daemon as the observable). I’m also using the (remote) proxy pattern. You’ll notice that this “design pattern bla bla” is indeed just naming for something that is most likely trivial and something you most likely call different and already know. Yet it’s interesting to discover how they are being reused by programmers time after time and for totally different projects and scopes.
Anyway, as usual. This ain’t a promise that something usable will ever exist. I never make such promises for free software projects. And this one highly depends on the cooperation of an awful lot other people. In fact it’s nearly undoable to ever make this succeed. That’s mainly because the community of people that are attempting to build a free software desktop are very bad at actually agreeing on desktop standards and shared desktop components.
To the Microsofts of this world: If you want to make sure we will never succeed in selling our desktop, make sure we will for ever keep disagreeing like we are doing now. The strength of Microsoft as a desktop software builder is that they do have decision making leadership. Our failure is that we don’t. And that we can’t agree on the most simple and basic things. I’ll keep repeating this until I die or until we solve the problem. We aren’t solving the real problems at this moment.
Note that the kernel folks do have decision making leadership. And surprise surprise: they are successful at selling it. This is indeed why I asked these additional questions to the GNOME Foundation board candidates of this year. Perhaps now they’ll address this problem? I fear not. Sure it’s not the purpose of that board. Whatever, it’s all we have a.t.m..
No, I’m by far not satisfied by the achievements of the freedesktop.org movement. It’s, by far, not enough. Agreed it’s a small step in the right direction. And no, it’s not a big step for mankind. We need so much more. It’s unbelievable.
Note that if I was intelligent enough to have the solution, I’d propose it. I’m not. So yes, indeed, this is rant. I know.
Hey Phillip,
Glad to see you haven’t given up!
Its a shame freedesktop is such a dismal failure at the moment but what makes it even worse is the uncertainty around technologies like Dbus and whether KDE will adopt it. For me if they dont adopt Dbus it will be the kiss of death to freedesktop and just about all other areas of interoperability.
As for leaders – there are none. Gnome is a beaurocratic mess which slolwly evolves only on concensus – dont expect anything radical to happen there cause it only takes one dissenter to kill a bright idea. (Its tyranny by the minority!)
Asking people to choose one programming language, or asking one set of people to tell the other set of people which one to use, is like forcing them to use one indenting style. It doesn’t solve any real problem and it just upsets people unnecessarily. These little problems are rarely relevant to the big picture, and not worth losing half our developers.
We do proceed by consensus, and we try to get consensus on important stuff. You can do that too. If people don’t agree with you, or don’t understand you, the solution is not necessarily to force them to agree with you. That would be a sure way to destroy the community that got us this far.
We’ve had stuff like Bonobo imposed on us before we had this culture. It’s not a recipe for success.
Murray, I’m not trying to imposing a programming language nor indenting style nor bonobo nor d-bus nor …
I think you’re missing the point if that is what you see in my message ;-).
Philip,
it’s always easier to introduce new stuff or replace broken/unwanted things. Before gconf there was nothing similar, so it was adopted quickly. Bonobo wasn’t exactly the greatest success, dbus seems to do a better job in certain places, that’s why people are using it. Now, it seems the KDE folks have been happy with their IPC/component system for years. It’s self-evident that they won’t just throw it over because something new is available.
Rob: Which is exactly why we need decision making leadership. Getting the different desktop components working together requires this type of commitment. I already knew about that problem, Rob. I wrote in my blog entry that I’m not intelligent enough to have a solution.
I know it’s not simple. But telling people it ain’t simple doesn’t make a solution.
Federico summarises it here:
mail.gnome.org/archives/f…
Oh and Rob, about the different goals. Another problem is that an awful big amount of people share the same gaols, yet look in different directions. Making both solutions often unnecessary incompatible.
Now imagine we’d like to start integrating the many desktop components with each other. Yet we have an enormous amount of incompatible desktop components. This way will all developers, no matter whether they are sharing the sames goals or not, fail. Because doing a proper integration becomes impossible or at least extremely ugly and stupid.
So the "lets all look in all possible directions" method of many free software developers, fails. It simply doesn’t work.