OSNews

Dammit, does nobody ever read the actual article before they start bashing Shuttleworth? Your answer is right in his blog post:

"In evaluating an app for the Ubuntu default install, we should ask:"..."is it accessible to people who cannot use a mouse, or keyboard?"

People, we are talking about the Ubuntu default install. He makes a difference between QT and KDE. He also even states that there is nothing preventing someone from installing a QT app on Ubuntu.

They just want to ensure that the best software in class is part of the default install and that it acts and looks like all of the other applications that are included by default.

That doesn't answer the OP's question.

The OP didn't ask a question

Collaboration is nice in theory, but design by committee is usually mediocre at best and disastrous at worst. If Shuttleworth's got a clear vision of what his OS should be and wants to drop the manpower into making it happen, more power to him.

Funny how aaron doesnt seem to agree with you.

Where do you get that idea from?



Edited 2011-01-18 22:52 UTC

Mainly because Aaron is not being acerbic and is open for collaboration. Nowhere does he says that this is like driving a wedge in the desktop world, for example.

You're reading this completely differently. He is advocating caution and already has some criticisms of how this is being presented:

"

Why is that not a valid approach? What does KDE have to lose if Qt devs implement dconf suport?

The power of Qt (and KDE to a lesser extent) is that the same developers interface will have different backends on different platforms, so the developer doesn't have to worry about it.

This is extremely powerful in allowing developers to concentrate on features in their applications, rather than worrying about exactly how to interface with the local libraries that perform task X on whatever platform they are on.

So the general problem here is different settings backends. Well Qt apps use QSettings that has different backends for different platforms, so on Windows it will use the registry, on Mac it will use plists, and on linux it will use .ini. KDE has a separate class that adds more features, called KConfig.

So the solution is not to add yet another class for dconf support. The correct answer is to work with KDE to either extend KConfig to allow using a dconf backend that will be transparent to the developers, or agree on a new interface that will support both backends.

Adding a DConfConfig class to Qt and asking all app developers to add support for it is totally backwards. Any even somewhat competent developer can tell you that. Hopefully that is not what Shuttleworth is actually suggesting and it will be clarified.

Edited 2011-01-18 23:19 UTC

I admit, I don't have any knowledge about the inner workings of QT/KDE/GNOME/GTK+/dconf, etc, so this may sound like a stupid question.. But If QT apps use QSettings, that itself has several different backends for different platforms, and the apps themselves work automagically with each backend, wouldn't it be easiest and best to simply create a dconf backend to QSettings?
Maybe that's exactly what you meant by extending KConfig to allow using a dconf backend?

If this can be done, I see absolutely no problem with it, even if a "better" solution is to be introduced later on.

> KDE has a separate class that adds more features, called KConfig.

Ubuntu is not targeting KDE apps, not at the moment at least. What they want to do instead, is to make Qt applications feel native on the Ubuntu desktop.

Qt apps use QSettings, not KConfig, hence modifying the latter would largely be irrelevant to Ubuntu goals.

I'm happy with this move (see http://www.osnews.com/permalink?446284). Qt is a extremely developer friendly toolkit, yet lacking in areas related to user experience. If Ubuntu can iron out some of these (relatively minor) wrinkles it will be a win-win game for all parties involved.

Why? It's not about KDE apps, its about QT apps. One could actually question why KDE is not using the existing QSettings stuff but instead went their own way.

That's an odd slant you've put on this. Qt developers haven't decided anything. You're rather jumping ahead of yourself here.

It won't be Qt developers implementing this. It's being done by someone, in a fork for the timebeing, in a way that has already been decided. I don't get the impression many people have been consulted. I suggest you read Mark's post. No one apart from Ubuntu has decided that dconf is even the right direction to go in.

Oh, and probably because it's the same approach Shuttleworth has generally used over the years, and he's always ended up being wrong and hurting everyone in the process? Shuttleworth, Canonical and Ubuntu don't exactly have a track record of being right.

Let's not be naive here. Shuttleworth and Ubuntu have been dragged kicking and screaming into accepting Qt. The only way this will work for them is if they end up with some applications they can use, and they don't get to decide that.

Writing a QSettings plugin is not creating a fork.

The admirable target of this move is to add more unification and consistence...

...what it would do in reality is adding more fragmentation, having just another API for a configuration system doesn't really add value but confusion.
Also, expecting developers to "write applications for Ubuntu" is not quite realistic. Most Qt-only applications are targeted to the most wide target platform (especially Windows and Mac in primis) so expecting them to target a specific Linux distribution (with the hope some other distributions will adopt it, but i wouldn't hold my breath) instead seems not realistic to me.

Now, writing it as a QSettings/KConfig backend is another story and makes more sense for sure, this is what i fully support (where the best case scenario is having a backend for both, with the KConfig one as the fully functional one, see below).

Now, probably QSettings itself is a bit too limited and I'm not sure it's possible to have a full support to dconf with its API.
Different discourse for KConfig, (that btw has good reasons to exist and to be sed in place of QSettings, we didn't write it just because we were bored) it adds things like better groups nesting support, system/user config fallback, type safety, change notifications..
all things that are necessary to represent 100% of dconf

In theory, technically nothing. But KDE is not simply a sum of all KDE software. It's a fairly open community willing to work with anyone on common standards. Mark's post is a little bit arrogant in that it suggests the adaptation of something they developed in-house, instead of really working together with the community to solve common problems. This might be actually a good strategy sometimes, but not in KDE/QT's case. Those are not difficult people to work with, KDE adopted and collaborated on dozens of freedestkop.org standards. Anyway, I really really recommend reading Aaron Seigo's blog. In is usual lucid style he very clearly highlights the "problem" That guy should be a PR expert or something (while Mark is obviously not )

http://aseigo.blogspot.com/2011/01/qt-acceptance-growing-next-colab...

I'm afraid that's a hugely misleading thing to say. Let's not misrepresent the huge dose of caution Aaron has thrown over this because of past experience.

Did you read the same blog posts I did? Because it sounds like you didn't.

"Mark suggests that Qt developers should start using Canonical's Qt add-on libraries for things like dconf so that Qt apps integrate properly with Ubuntu."

Basically, forking QT, leading to Ubuntu-only QT apps.

"To get applications working together as well as possible, the answer is not to start creating Ubuntu-targeted versions of Qt apps"

Collaborate, don't fork.

"Solving this means working together, not thinking that we are individually capable of coming up with the best ideas ever and that the world should simply bend to our whim of the day."

Which is what Shuttleworth is doing, by shoehorning DConf support into a Canonical fork of QT, instead of working together with QT and/or KDE devs to find a solution to the settings issue.

"As more groups warm to the beauty that is embodied in Qt, I hope that the message of working together (rather than dictating, for life or otherwise) also spreads."

Yes, and world peace will arrive tomorrow.

This is a very good solution, and is not a fork at al - that's a bunch of FUD bullshit. All this means is giving Qt devs the option of building dconf support into their applications. Said applications will still work fine in any Qt environment, and as such, really can't be called forks. He's not forcing anyone, he's not dictating anyone, he's just saying: look, we're hiring a few devs to work on allowing Qt devs to implement dconf support, and if Qt apps want to make use of that, fine. If not, also fine.

Jesus Christ the anti-Shuttleworth and anti-Ubuntu talk is reaching insane proportions around here.

Edited 2011-01-18 23:00 UTC

Hey, we gotta balance out the anti-Apple and anti-MS crowd.

Sorry, but I can only interpret this one way and it's the same message that Mark Shuttleworth has given for years that has always ended up in nothing of very much significance happening:

What this means is that if a foreign application does things the way that we want in a way that we've already decided then we'll be happy to dangle a carrot of inclusion into Ubuntu.

Not helpful, in other words, because whatever way you choose to see it that is dictation in any language - or at least attempting to dictate.

They've obviously now seen the error of their ways over the years with their development platform and path. How much do you want to bet that they end up being wrong over this shoehorned approach until they either change again or go bust?

And this is different to just about any other software collection, how, exactly? Are you telling me KDE doesn't have rules for inclusion? OpenSUSE? Fedora?

Come on dude, this sounds a lot like trolling just because you hate Ubuntu.

Most (succcessful) software projects formulate their direction for things by including the projects that they hope will buy in and working out the best direction to go in. Those that dictate tend to not be very successful, and Ubuntu doesn't have the best track record of thinking things through, dictating and convincing people that where they're going is the right path. They've only been dragged kicking and screaming into accepting Qt after seven years.

The only way they're going to make a success of this is by getting buy in from Qt and the developers of Qt-using applications, such as those in KDE, and he's not off to the best start.


Sorry sweetheart, no. Ubuntu just doesn't have track record of getting these things right, that's all.

I'd appreciate it if you could leave this kind of trolling out of this as well. It kind of makes it look like any criticism of Ubuntu is trolling against it, you know?

They've obviously now seen the error of their ways over the years with their development platform and path. How much do you want to bet that they end up being wrong over this shoehorned approach until they either change again or go bust?

I am not an Ubuntu fan or anything, but even I have to jump in here: your comments sound like nothing more than trolling. They are perfectly within their rights to only include applications that work well on their desktop. After all, Ubuntu IS aimed for the desktop and they want to maintain atleast a certain element of quality there. Thus it's perfectly reasonable to want to only include such Qt apps by default that fill their requirements.

After all, that's what EVERY single effing distro does.

You can view it in whatever way that you want, but after seven years of steadfastly being hung-up on one toolkit, people complaining that perfectly good applications were being shoved to one side and coming up with some rather strange and very familiar reasons as to why they won't even acknowledge any other toolkits.......the irony is not lost on those of us who've seen what's happened over the past seven years.


No, outright excluding applications and alternative toolkits in installations based on ill-advised technology preferences is not what every distro does. Only some.

You can view it in whatever way that you want, but after seven years of steadfastly being hung-up on one toolkit, people complaining that perfectly good applications were being shoved to one side and coming up with some rather strange and very familiar reasons as to why they won't even acknowledge any other toolkits

That's called "having differing viewpoints and wishes" and, well, they wanted to keep Ubuntu as a GTK+ oriented distro.

No, outright excluding applications and alternative toolkits in installations based on ill-advised technology preferences is not what every distro does. Only some.

I see lots of distros doing that. Some distros ship only Qt apps by default, some only GTK+ apps by default, some ship a selection of both..

Yes, and world peace will arrive tomorrow. This is a very good solution, and is not a fork at al - that's a bunch of FUD bullshit. All this means is giving Qt devs the option of building dconf support into their applications. Said applications will still work fine in any Qt environment, and as such, really can't be called forks. He's not forcing anyone, he's not dictating anyone, he's just saying: look, we're hiring a few devs to work on allowing Qt devs to implement dconf support, and if Qt apps want to make use of that, fine. If not, also fine. Jesus Christ the anti-Shuttleworth and anti-Ubuntu talk is reaching insane proportions around here. "

KDE desktops have pretty good support for GTK applications, including settings.

http://en.wikipedia.org/wiki/GTK-Qt

If Shuttleworth wants to integrate Qt and GTK applications on the one desktop, which is a perfectly reasonable aspiration, why not just use what already works?

That's a theme engine.

Read the article again. This is about the settings backend. A theme engine ain't gonna help you there.

It gets you a long way there (although I agree there must be more to it than just a theme engine). On my system, GTK applications look virtually identical to "native" KDE/Qt applications, in that they all use the same Window styles; widget styles; system, window and application fonts; colours; printer settings; language settings; currency formats; etc, etc. Some GTK applications will even support KDE-style dialog boxes.

Surely such an approach is already far less eclectic than some other desktops, such as Windows for example.

Since it already exists, why not just go with that?

Edited 2011-01-19 00:19 UTC

Yer, and? It's certainly a big help to desktop and application integration - and guess who wrote it? We'll just paint over that though.......


This is about integrating applications, not purely about some settings backend. A settings backend by itself certainly won't help you because you've got to agree a format with everyone as to what settings will be stored and how they will be used, and everyone has to buy into it for it to work. The article goes into no detail whatsoever there.

Stop telling people to read the article again when you don't understand the implications within it yourself and Mark Shuttleworth doesn't either.

KDE desktops have pretty good support for GTK applications, including settings.

http://en.wikipedia.org/wiki/GTK-Qt

If Shuttleworth wants to integrate Qt and GTK applications on the one desktop, which is a perfectly reasonable aspiration, why not just use what already works?

That would mean having KDE as the default desktop instead of GNOME, thus that is absolutely of no help here.

I'd like to find out why. Plasma is after all very "programmable" and configurable, and could probably be shipped in such a way as to look and behave almost exactly like the GNOME desktop you are used to.

Such a GNOME-mimicking KDE desktop would possibly be more like GNOME now than GNOME 3 and/or Unity desktop would be.

I'd like to find out why. Plasma is after all very "programmable" and configurable, and could probably be shipped in such a way as to look and behave almost exactly like the GNOME desktop you are used to.

That would be way more work than just implementing support for dconf. And it would require LOTS of work for everything to work like on GNOME.

the opposite is true as well, the default Qt build supports a theme that paints directly with the GTK engine.

Edited 2011-01-19 10:16 UTC

I think QGtkStyle still uses Qt for painting, Gtk is used to launch system dialogs and fetch the theme attributes & bitmaps for the painter.

That's the wrong way to be looking at it. It's really a question of what already works and who's actually done the work.

In reality though Qt now does a pretty good job of going in the reverse direction of taking on the Gnome and GTK environment.

Why not? Is there a religious reason agaisnt KDE? KDE with plasma could be made to look and feel just like Gnome if is that you want. Or a another type of GUI like Unity for instance.

Just because shuttleworth is letting Qt applications into Ubuntu, it doesnt mean its a good thing for intergration between desktops.

This is what exactly happened:
Qt is now far far ahead of GTK+.
Ubuntu wants to use Qt more.
They do the fastest and cheapest approach, which is also the one that has no cooperation with others.

What happens isnt very sad. We will probably see a few Qt applications which depend on something like libqdconf or something like that.

But the issue is, they could've done much more. They could've helped on a new standard on FD.o for managing settings. But they decided not to.

Please dont tell me that something designed by commite isnt going to work. FD.o standards have worked pretty awesome in the past few years. Its just that shuttleworth and ubuntu kids want FAST results. which isnt the best possible result.

And this is very very insulting:

You see, KDE people had KConfig which is a pluggable settings system for years. And they consider it as a superior technology. Then suddenly someone jumps inbetween and suggests them to use dconf so they could be more intergrated.

Edited 2011-01-19 09:36 UTC

Exactly. Rather than working within the existing communities (like fd.o), they are going their own way, doing their own thing, with a solution that benefits noone but themselves.

This Ubuntu bashing is petty.
Your mother never teach you not to look a gift horse in the mouth?
You do know there is like a gazillion other distros out there?
Guess its true, nobody hates you like your friends.

Nothing has to be done "their way or nothing"... The beauty of open source / free software is that if you like the idea you can use their software, and if you don't like it, you can use any of the alternatives that suits your preferences.

Canonical is just putting its money where its mouth is by sticking to a vision and implementing stuff based on it, rather than trying to draw conclusions from discussions at different forums that usually turn into endless (and often pointless) "religious wars". Whether the vision/idea is good will ultimately be decided by the users. (Unfortunately this doesn't prevent others from having endless and pointless religious wars related to Ubuntu.)

I'm sorry, but I'm chuckling at how ironic that statement actually is.

All (?) Linux distros have built Qt to use glib for event loop for years. That's the way to integrate with gnome stuff.


What is needed is *action*, not planning or discussing about planning. For whatever canonical is bashed for these days, you can at least trust that they are *doing*, not debating.

I don't think it's beyond the realms of sensibility that getting some buy-in from the developers of the software that you hope to use before hand would be a good idea for everyone.

Canonical has ended up 'doing' a lot of things over the years......and not being terribly successful at getting others to join in.

The beauty of open source development is it's largely an evolution rather than design. For it to work people need to let go of the notion that there's only one good way of doing things. We need to let people do what they think is the best to do, encourage them to do different thing.

So let Shuttleworth do his thing to Ubuntu. If you don't like it, you have 9071431 other distributions to choose from, pick the one you like.

Sure. Go ahead. Whatever. Away you go, and write a set of interface binding for Qt apps to be able to query dconf. Fill your boots.

Just don't expect authors of Qt programs to re-write all their applications (to call those bindings) just to satisfy the Ubuntu desktop.

As this thread title says ... talk about arrogance! Sheesh.

PS: I have an alternative proposal for Ubuntu ... re-write dconf for Ubuntu to set not only the dconf database but also to make synchronous, sympathetic changes to Qsettings. Integrate Qt applications without requiring any re-write by authors of said qt applications.

Edited 2011-01-19 02:55 UTC

Dude, are you even a developer? I mean, a real one?
if so, what do you do and in what languaje?

Just asking.

MYOBB.

So, you don't.

Then stop trolling about subjects you don't even understand.

I didn't say that ... I haven't done programming for some years now, as I have moved up the engineering structure somewhat since then.



Wrong guess. Entirely.

As I said, MYOBB.

So, you are not in the field, out of curiosity, have you ever programed professionaly in something more than Visual Basic 6?

Because that's an outright stupid and horrible idea. What next? A configuration merge engine which asks the user in toolkit-independent manner how differences in two supposedly simultaneously managed config backends should be merged?

Because that's an outright stupid and horrible idea. What next? A configuration merge engine which asks the user in toolkit-independent manner how differences in two supposedly simultaneously managed config backends should be merged? "

Yes, I have reconsidered ... a better approach is for Ubuntu to write a replacement for QSettings class and qtconfig, such the the replacement libraries run with the rest of Qt only when GNOME runs. This maintains the dconf database as the repository of all GNOME settings, and Qt applications running under GNOME would see those settings translated from the dconf database.

If one also installed KDE on the same machine (perhaps for different users to use as their preferred desktop), when KDE ran the exact same Qt applications they would see the KDE desktop settings for that user, since KDE would be running the default QSettings class and qtconfig settings.

So, I agree, doing it that way around is better.

However, either way is still better than what Shuttleworth proposes, requiring Qt applications to be re-written to run under a Ubuntu-unique version of GNOME.

KDE doesn't use QSettings.

Oh, wouldn't something as thoughtful as that be nice to work with? There just might be hope for humanity yet. Although, I wonder if any Canonical people read OSNews ...

The biggest problem with open-source development is that it's largely evolution rather than design.



Which is fine, so long as there is a vision of what the end product should look like. Re-doing things every 6 months because it doesn't work is no way to run a software project. There needs to be some kind of framework, plan, whatever, and not just "try X; fail; try Y; fail; Try Z; mostly works; Try Q; almost works; try A; works; try B; works better" ad nauseum.

Because design-by-committee has been time again shown to be slow and often substandard. Sometimes it works, sometimes not. It's true that this method rarely fails but it also rarely produces something innovative.

That's not even taking into account the typical knee-jerk reactions I would expect from the non-Ubuntu people in the open source world (which Ubuntu has plenty of experience with, by the way).

Arrogrant, bloody-minded, dictatorship (I'm purposely exaggerating) can be a good thing.

and never the less, without efforts like freedesktop (that admittely have its share of problems) we wouldn't even have the same storage for the start menu, the same hints for windows (a panel is a panel in all window managers that wasn't really true some years ago) we couldn't see notifications of applications written in the other toolkit...

(to not mention waay wider efforts like uhm, HTML anyone?)

Now, we have gained a significant amount of interoperability over those years, it would be a shame backpedal it.

Things like Ubuntu just proposed, are in the right direction, with the best intentions of the world.
What I say is, be careful of how something is pushed forward, a little "implementation detail", like it can be the choice of writing backends versus a new api, can have the consequence of having very good or very bad consequences.

And you know how all of this can be avoided? it's called "working together", and is what it's slowly starting to happen. We are talking with them and for this very reason I'm delaying any judging until this thing rolls down.
As collaboration with Ubuntu goes, in the history we have very sore points but very successful episodes as well (for instance the integration of our StatusNotifier protocol with their DBusMenu protocol was a quite good example of working together) so, we'll see.

What I can say, that from KDE we are always open for collaboration.

anyone tried it on trunk GNOME? seems to fail miserably on x86_64 (core dumps all the time.)

Not surprising. QT apps or not, Ubuntu will still be the crash happy Linux Distro that breaks on every update!

You don't appear to know what you're talking about.

My first thought was Nokia also but of Ovi's apps being QT based. Potentially, the same app I run on my phone may be natively available to run on a future Ubuntu release (assuming Ovi and/or Ubuntu last long enough).

So what was this Kubuntu thing about? This is not about "the right basis", but about "any basis". So far they've focused on building more-and-more user-friendly systems based on each "basis". Now they are starting to work on removing this "basis" barrier so that you can use applications with different toolkits in a single system consistently.

I'm not entirely sure what that claptrap is supposed to mean, but:

Which they've always been somewhat less than keen to do in the past, leaving it to other people to do in spite of them. Afterall, it's only taken them seven years.

Edited 2011-01-18 23:37 UTC

As far as I know, most people who work on Ubuntu are either Canonical employees, or volunteers who do it because they agree with Ubuntu's goals and enjoy working on it... I can only assume that by "other people" you are referring to the large number of volunteers, but I fail to see how that can be a bad thing.

It means "the decision has been made"

I don't know why Dutch expressions keep being used without any reason or explanation

Hey, I kind of enjoy the foreign idioms. I don't speak Dutch, so I turned to Google translate which says:

"The ball is cast"

There is an expression in English "The die is cast." An explanation for how this originated:

http://idioms.yourdictionary.com/die-is-cast-the

So, the decision is engraved in stone.

As for the decision itself, I'm OK with it. Anything that makes my Ubuntu desktop work a little better is a step forward.

Peace.

That's nice. After utterly ignoring Qt and KDE for many a year, suddenly, just for the sake of the Ubuntu default desktop, all authors of Qt applications must re-write parts of their application in order to be aware of qt-dconf settings, unique to Ubuntu?

I'm so glad you are OK with that. </sarcasm>

Yep, they must. All Qt programmers that do not use dconf will be arrested and executed.

Oh wait, the only downside to not implementing dconf is that you won't see your application installed by default on the Ubuntu live CD. So no, nobody must do anything.

All Canonical is doing is creating a new piece of software that allows Qt application to integrate better into GNOME and Ubuntu. Yes, not just Ubuntu, this will also benefit other distros that combine GNOME with Qt applications. And everybody is free to use or ignore it.

I don't get all these comments saying "I have wanted Qt apps in Ubuntu for years, and now they are doing it. Those bastards!"

Oh wait, the only downside to not implementing dconf is that you won't see your application installed by default on the Ubuntu live CD. So no, nobody must do anything.

Indeed. The library is already being written so an application which wishes to be part of the default installation only needs to add the library and to save/store its settings via that. Not really a big effort needed. And besides, not all apps are going to get on the default installation anyways.

I don't get all these comments saying "I have wanted Qt apps in Ubuntu for years, and now they are doing it. Those bastards!"

I suppose they were happier complaining than actually getting something. And still, Qt apps have been available in Ubuntu for years, the only difference now is that it's possible some Qt apps will be included by default.

I'm sorry you missed the sarcasm tag, I actually did put one right there in that post for you.

Anyway, my point is this ... why should authors of Qt applications be falling over themselves to re-write their apps just for the "honour" of being included on Mr Shuttleworth's Ubuntu default install CD?

Why would it be so hard for Mr Shuttleworth to arrange to do the work of integration, if he wants to include these best-of-class Qt applications on his default CD?

There are two methods which come to mind, neither of which would require Qt authors to leap to Mr Shuttleworth's bidding (for Mr Shuttleworth's benefit):

1. Ubuntu writes a replacement qtconfig
http://doc.qt.nokia.com/latest/qtconfig.html
The qtconfig tool allows users to customize the default settings for Qt applications on a per-user basis, enabling features such as the widget style to be changed without requiring applications to be recompiled.
and a replacement for QsettingsClass in the QtCore module, both of which integrate with dconf, all other parts of Qt remain untouched,

http://doc.qt.nokia.com/4.6.2/qsettings.html
Detailed Description

The QSettings class provides persistent platform-independent application settings.

Users normally expect an application to remember its settings (window sizes and positions, options, etc.) across sessions. This information is often stored in the system registry on Windows, and in XML preferences files on Mac OS X. On Unix systems, in the absence of a standard, many applications (including the KDE applications) use INI text files.

QSettings is an abstraction around these technologies, enabling you to save and restore application settings in a portable manner. It also supports custom storage formats.

QSettings's API is based on QVariant, allowing you to save most value-based types, such as QString, QRect, and QImage, with the minimum of effort.

or

2. Ubuntu writes an expanded dconf module which edits both the dconf database and the qtconfig and QsettingsClass storage.

Either way, it seems to me, suddenly Qt applications running on Ubuntu will see the same settings changes as dconf does, without any requirement for said Qt applications to be re-written or even re-compiled.

Surely this is an infinitely better solution for everybody, even for Mr Shuttleworth?

Edited 2011-01-19 09:24 UTC

dconf has technical advantages over flat-file storage, including notice of changes, and a quite fast retrieval/loading mechanism (as it is more likely that settings are read than written).

Having the author of dconf write bindings for Qt, so there is the choice of using it, is a good thing!

But only Qt applications which were re-written to explicitly call those bindings (probably making them a dependency, and also therefore bringing in dconf as a dependency) would be able to work.

However, modifying dconf to also provide a replacement QSettings class and a replacement qtconfig would provide the desired mechanisms for Qt applications running under Ubuntu's GNOME to use the dconf database WITHOUT having to modify said Qt applications!

Better for everybody!

Wait, I thought the sarcasm tag just applied to that last sentence you wrote. Are you saying it applied to your entire post? So this part:

was sarcastic as well? So you agree with me that it's not true that all Qt applications must be re-writen and that it will only work on Ubuntu?

Anyway, I think here is where your problem lies:



Seems to me you are just creating this problem in your head. There is no matter of "honour" here. Nobody is being forced to do anything. Here's how I see it for example:

For years people have been asking for the inclusion of Qt apps in the default Ubuntu install. Canonical didn't want to do this at first because of poor integration in GNOME. But now it seems they have some room in their budget for helping that integration, making Qt apps in the default install possible. Apart from being good for Ubuntu in the long run, this is a favor for those who wanted Qt apps in Ubuntu. For those that are not interested in this, *nothing* changes.

If you don't like their dconf solution, that's fine. Your solution with QSettings sounds good too. Perhaps you should collaborate with Canonical on it, or try to implement it yourself.

But as long as they are implementing something with their time/money - something which has no down-sides because it doesn't affect anybody that is not interested - than that can only be a good thing in my book. You can say it's not good enough, but I don't see how you can view this as a bad thing.

Qt applications must be re-writen under Mr Shuttleworth's proposed scheme in order to work in an integrated fashion ONLY on Ubuntu. Yes indeed, that is what I meant.



Your misunderstanding, not mine. Indeed nobody is being forced to do anything ... so nobody will do anything to make their Qt application depend on Ubuntu. That's crazy.



So why not simply do it in a way that Qt applications can run in an integrated fashion under Ubuntu without requiring changes to Qt applications? All it requires is for Ubuntu's GNOME desktop to replace a few small parts of Qt, in a very similar way that KDE desktops currently replace a few small parts of GTK in order to achieve the GTK integration. What exactly would be wrong with doing that? It is no more work for Ubuntu.



Canonical say they have already employed someone to do it the boneheaded wrong way. It won't work guys, it will fall in a heap for lack of Qt application authors willing to make their applications dependent on Ubuntu's GNOME.



It is not that so much as that I am making the observation that it could very simply, with a sensible approach, be made a very much better thing for everybody concerned.

Edited 2011-01-19 10:33 UTC

I am shocked at aggression and anger directed toward Ubuntu in so many of the comments in this discussion. It seems a small but very vocal minority is interpreting Canonical's actions in the most negative light possible, and sharing their negativity with the rest of us.

FOSS development, just like practically any field in which people-to-people cooperation is essential, requires people be -- at minimum -- civil and respectful of each other.

Unfortunately much of the discussion in the last day or two has been anything but civil.

I am shocked at aggression and anger directed toward Ubuntu in so many of the comments in this discussion. It seems a small but very vocal minority is interpreting Canonical's actions in the most negative light possible, and sharing their negativity with the rest of us. FOSS development, just like practically any field in which people-to-people cooperation is essential, requires people be -- at minimum -- civil and respectful of each other. Unfortunately much of the discussion in the last day or two has been anything but civil. "

I'm shocked as well. Utterly shocked to my core.

I'm shocked that no-one has bothered to answer the perfectly civil question ... "why should authors of Qt applications be falling over themselves to re-write their apps just for the "honour" of being included on Mr Shuttleworth's Ubuntu default install CD?".

There is no insult in the question, there are no angry words, no-one is accused of anything, and it is a perfectly valid quetion after all. Why should authors of Qt applications go to all the bother that Mr Shuttleworth is asking of them? What incentive is there?

Why shouldn't it be a vastly more preferable approach that Ubuntu itself is modified slightly instead, in order to better accomodate Qt applications as they already are?

Hmm?

Why can no-one answer these questions?

Edited 2011-01-20 03:16 UTC

It's a nice way of inserting a bit of sensationalism into the debate, but that's exactly what Shuttleworth is asking Qt application developers to do.


That's about the size of it, and probably what will happen.


It will get ignored by upstream, like many of the other things Ubuntu has done, because people are not going to rewrite their applications to support something that Ubuntu has suddenly come up with out of the blue.

Those of us actually debating something here are asking what it will take for what Mark Shuttleworth wants to be a success. Telling us that we can all ignore him is probably what will end up happening, but it's not terribly productive.


Well no. People have asked for better Qt aplication support for years, and got completely stonewalled by Ubuntu and then other people did the actual work.

It does a disservice to the people who've actually done work and written code on this front to claim that Ubuntu is now somehow starting this off.

Authors of QT applications would most likely continue using QSettings as they have always done. QT is nice and modular like that. Not like such facts will matter for the irrational anti-Ubuntu and anti-Shuttleworth brigades.

Correct. Exactly so. That is precisely what you would expect them to do.

However, when said Qt applications are installed on a default Ubuntu (with modified qtconfig and QSettings class, both now integrated with dconf) now, suddenly, when the Ubuntu user changes something like the system font (using dconf), suddenly any installed Qt applications will also see the same change.

Which is what you want.

Without requiring said authors of QT applications to change their code at all, or even have to recompile.



Puhlease, get real. What everybody wants is for it to work properly, without putting extra work on the authors of thousands of Qt applications.

This is not any kind of anti-Ubuntu campaign, this is simply a "if you want to integrate Qt applications, do it properly and everybody wins" campaign.

Edited 2011-01-19 09:33 UTC

It's about more than just creating a dconf settings backend. If you want proper application integration then all the applications have to pay attention to the settings they set and get from dconf. This is a mammoth task, will need to be some kind of Freedesktop specification and will require a lot of buy-in.


Hmmmm. I love how any percieved criticism of Ubuntu and what Mark Shuttleworth says is somehow, by default, anti-Ubuntu and ant-Shuttleworth trolling. As if the opinions of Ubuntu and Mark Shuttleworth trump everyone elses', including those of the upstream who they expect to buy into this, and can't be questioned. Interesting.

Edited 2011-01-19 15:13 UTC

Because I like adding a little bit of other languages than English to OSNews. It's also why I NEVER link to a Google Translate article.

Because I like adding a little bit of other languages than English to OSNews. It's also why I NEVER link to a Google Translate article.

But but but but.... Dutch is such an ugly language :<

I'd prefer latin instead tbh.

What about Finnish?


Gggnnnni gnnnn iitttiiiiitnnnnbb bmmmmttttiiii. Rrtttttnnniiiimmmee dddiiiiiinnnnooommmmmiii?

I'm sure that random collection of letters means SOMETHING in Finnish .

well, you are wrong, it does not mean anything

And ... putting the translation in () after the quote is hard because ... ?

I'm not Dutch, but we have the same expression. It literally means "the bullet went through the church". We say: "Die koel is deur die kerk".

Edited 2011-01-19 03:38 UTC

It is a dutch (and also south african, as it turns out) saying. Its origins lie in war. Warring parties did not fight in churches, out of respect. As soon as one of them violated that rule it meant that the church stopped being a safe haven.

Thanks, I always wondered. That is really useful.

That too would be a win for everybody.

As a bonus, they could change the default media player to something like Clementine (which is a Qt application)

http://www.clementine-player.org/

or VLC (which is a Qt application)

http://www.videolan.org/vlc/

or even SMPlayer (which is a Qt application)

http://smplayer.sourceforge.net/

... none of which require Mono.

Edited 2011-01-19 09:49 UTC

... none of which require Mono.

Neither does the default media player.

http://www.omgubuntu.co.uk/2010/10/banshee-becomes-ubuntu-11-04-def...

Banshee becomes Ubuntu 11.04 default music player

http://www.omgubuntu.co.uk/2010/10/banshee-becomes-ubuntu-11-04-def.....

Banshee becomes Ubuntu 11.04 default music player

Banshee is a music player. Not a media player. Replacing Banshee with VLC or similar as you suggested would be retarded.

Banshee is a music player. Not a media player. Replacing Banshee with VLC or similar as you suggested would be retarded. "

This says "media player".

http://en.wikipedia.org/wiki/Banshee_%28media_player%29

Replacing Banshee with Clementine seems quite OK though.

http://en.wikipedia.org/wiki/Clementine_%28software%29

Edited 2011-01-19 10:16 UTC

This says "media player".

http://en.wikipedia.org/wiki/Banshee_%28media_player%29

Yeah, it still is clearly a music player/manager, which you should have been able to tell even from the damn thumbnail image.

Replacing Banshee with Clementine seems quite OK though.

http://en.wikipedia.org/wiki/Clementine_%28software%29

That I don't take any stance on, I don't like either Qt or Mono apps.

No amount of theme engine is going to make Clementine look anything like a regular GNOME/Ubuntu app. Sure, it's powerful, but it's also a cluttered mess.

How is clementine cluttered? Serious question, not looking for flames. It's a simple two-pane layout with the library on one side and the playlist on the other. (Or have I configured it that way? Can't recall, it's been a couple months since I installed it; I just play music with it.)

[sarcasm]Because MONO is the Evil.[/sarcasm]

http://www.novell.com/products/monotools-for-visualstudio/

Novell (who have a patent agreement with Microsoft) even supply mono development tools to Visual Studio developers ... there is no way Microsoft are now going to start patent infrigments proceedings on Novell.

This Anti-MONO FUD is fuelled more by a hatred towards Microsoft than anything else.

You lack history. History tell you that something is strange. Visual Studio plugin was free and open source at one point. Why is it not now.

Novel MS patent agreement has to be renewed at end of this year. Not renewed no more patent coverage. With the sale of Novell MS might have no reason to renew. Due to the fact MS might become a part owner of all of Novell patents so unable to ever be attacked by them.

Also Mono has been systematically getting rid of GPL and LGPL from there source code base swaping to a license that does not legally contain any clauses to promise patent protection.

Lot of the mistrust comes from the Fat long filename patents. MS waited 8 year to spring those on companies. So waiting out a 5 year agreement is not outside MS known wait time to attack.

MS has used Submarine Patents. Once bitten twice shy here.

Really key reason to be rid of mono from default mono install is performance on a livecd. Simply it suxs.

Reason why it suxs is Linux is designed to pull of a few simple tricks. Native programs are mapped to memory. Something that is mapped to memory Linux kernel does not need to use swapspace for if runs low on memory. In fact never uses swapspace for.

Mono simply creates more on the fly data that must be sent to swap to free up ram in case of running out. So forcing up the min ram requirement when you don't have swapspace. Ie most key time of not having swapspace a Livecd.

Really Mono and Java should both be limited preferably to harddrive installs and never ever found on a Livecd due to the overhead of both.

Only possible exception for java is using gcj to product native binaries for the livecd.

O yes I am sick of every time I bring up the technical limitation of Mono of being accuses of being just a MS hater.

I bring up the technical limitation about Java and people don't dispute it. The technical limitation has nothing todo with my like or dislike of MS.

Simple fact here MS made .Net to compete with Java and in the process they copied the weaknesses.

yes and no. being standalone or not (that in the ends boils down to having or not a certain dependency) has big advantages and disadvantages. using another library means a whole lot of things you can do "for free" (well sort of) so decide what can be used inside a library or not is not an easy task.

however, we are now in a big effort in modularizing KDElibs more and more, making easy using even just any subset one wants (even providing builds with more or less features targeted for instance to mobile devices and what not) This year will be pretty important in this regard for the technical direction, so I can just say stay tuned

Anyone interested in this topic may want to look here

http://www.freedesktop.org/wiki/Specifications/config-spec

Which includes links to config systems and some description of what the requirements look like.

Short of going back to the text based world, no. You'll never get the entire Open Source world to converge on one grand unified interface or toolkit. You'll always have at least one guy who thinks the way things are done sucks and takes advantage of the freedom the ecosystem grants to build his own path. And thank $DEITY for that guy, because without him nothing interesting would ever happen.

Me, I just tune out the silly bickering and focus on what I want to do with my system.

Is your third movie worth watching?

We did have CDE.

So that is how you measure worthiness in "Linuxland"? That shouldn't be an obligation. You do what you do best, and i do what i do best. As long as it's free, who cares.


So what? It's not on the front page. Anyone that's interested can find out for themselves. http://www.ubuntu.com/project/about-ubuntu
I don't put my moms name on my shirt, so people know where i come from. If they're so interested, they can ask. Seriously.


Yes. And I like it. Good for me?

It's just an observation. Oracle gets bashed and derided for building off RHEL even though they contribute btrfs and yet Ubuntu gets a free pass and contributes nothing.


It says a lot about his true intentions. He wants to disassociate Linux from Ubuntu in the public's mind.

I don't really care but I'm surprised by how many in Linuxland are on board with him. If Ubuntu ever got anywhere with the public he would no doubt push some type of application lock-in. He would probably go the Google route of using a non-standard (but open source) API to discourage porting.

Fair enough. But in my mind oracle shouldn't have been bashed for that either.


Yes, you may be right. But here's food for thought: what if that is what is needed for linux to actually grow on the "average user". You can't argue with the stamp (many) people put on linux users today. But if you sneak in the backdoor, maybe they don't notice how nice it is until they are already using linux. See? Maybe he's doing it, intentionally, for a good purpose. But then again, maybe i'm too blue eyed.


Perhaps. But, he's obviously trying to go his own way, and that annoys people to no end. What's wrong with coming up with something more popular than the "upstream" product (especially if upstream refuses to even consider to merge it in), if people genuinely like it better?

Sure but how much time is he going to be given to attract average users? Linux desktop share hasn't changed since he showed up. Ubuntu has just become the de facto Gnome distro, Linux desktop share wouldn't drop if Ubuntu disappeared.



Shuttleworth has tried the Mac junior approach and it hasn't worked. If Linux is going to remain a niche desktop then you might as well go with the distro that is honest and not wrapped in marketing. I think Linux Mint is a better name anyways.

Given Linux's track record on desktop and consumer systems, can you blame them?

That is not the problem. What's wrong with Ubuntu is that they're not doing anything that others haven't tried before. It's nothing but logical that they're failing exactly like the others did.

Good luck with...

WPA (Windows Product Activation)
WGA (Windows Genuine Advantage)
OMGMCHAV (Oh my god my computer has a virus)
IH"L"W (I hate "Linux" words)
IFBH (Insert flame bait here)