Of course now that GNOME are starting to use C++ through Qt, the pedantic argument that has previously prevented any KDE technology from being adopted by GNOME could finally go away. * KDE doesn’t care to port a C++ implementation to C, just because GNOME are being silly * GNOME refuses to use the C++ implementation, KDE uses * GNOME solution is not good enough for KDE The suggestion of merging configuration backends have been suggested before, and the result was: KConfig is an order of magnitude faster than QSettings, and a couple of orders of magnitude faster than DConf. If this can be done, I see absolutely no problem with it, even if a “better” solution is to be introduced later on. Maybe that’s exactly what you meant by extending KConfig to allow using a dconf backend? 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? 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. Hopefully that is not what Shuttleworth is actually suggesting and it will be clarified. Any even somewhat competent developer can tell you that. 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.Īdding a DConfConfig class to Qt and asking all app developers to add support for it is totally backwards. So the solution is not to add yet another class for dconf support. KDE has a separate class that adds more features, called KConfig.
#Sourcetree ubuntu mac#
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. So the general problem here is different settings backends.
#Sourcetree ubuntu how to#
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. 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. Why is that not a valid approach? What does KDE have to lose if Qt devs implement dconf suport? I used to not be a fan of using Qt application in a Gtk+ environment and vice versa, but I think that with enough polishing and backend integration, it should be possible maintain the nice and consistent feel of a strict Gtk+ or a strict Qt environment. “I think it’s entirely plausible that dconf, once it has great Qt bindings, be considered by the KDE community ,” he explains, “Nevertheless, should a KDE app learn to talk dconf in addition to the standard KDE mechanisms, which should be straightforward, it would be a candidate for the Ubuntu default install.”Īs far as I’m concerned, this is great news. He hopes these dconf bindings will also find their way to KDE applications. “To address this, Canonical is driving the development of dconf bindings for Qt, so that it is possible to write a Qt app that uses the same settings framework as everything else in Ubuntu,” he writes, “We’ve contracted with Ryan Lortie, who obviously knows dconf very well, and he’ll work with some folks at Canonical who have been using Qt for custom development work for customers.” On his blog, Mark Shuttleworth has announced that starting with the release after Natty Narwhal, Ubuntu is going to start evaluating Qt applications for inclusion in Ubuntu’s default installation.Īccording to Shuttleworth, the major issue that needs to be overcome is that Qt applications use a different settings backend than the rest of GNOME.
Ubuntu has always had a Gtk+-policy (well, Firefox and OpenOffice were the exceptions), but today, that has changed. Mark Shuttleworth announced the policy change on his blog today. After years of focussing entirely on Gtk+ and GNOME, Ubuntu will finally start evaluating Qt applications for inclusion in the defaukt Ubuntu installation.
0 kommentar(er)
