LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||
DevelopmentKDE moves forward on FrameworksThe KDE Project recently got together for a sprint called Platform 11 in Randa, Switzerland. One of the major decisions coming out of that gathering is to start work on the next KDE Frameworks — a set of high-level components for applications to use — immediately following KDE 4.7. What does this mean for the community? This time around, KDE won't be dragging users or application developers through the "big change" phase of underlying technologies for KDE. The KDE Software Collection (KSC), what was once known simply as the K Desktop Environment, comprises everything from the KDE Developer Platform and the KDE Workspaces (such as the desktop and netbook workspaces) to KDE's applications. In the past, this entire collection has moved forward together — or tried to, at any rate. KDE developer Aaron Seigo describes major release cycles as "that 'big change' phase" that included applications, desktop, and pretty much everything else. That worked well enough when KDE was a smaller and less complex beast and "the overlap between 'people who work on kdelibs' and 'people who work on applications' was very high." As has been noted by many, however, that worked less well when work began on KDE 4: Application developers either started porting "too" early or "too" late. Some jumped on the 4.x bandwagon quickly and suffered constant API drift, while others waited until "it" (whatever that meant) was stable (whatever that meant). Our users, in the meantime, drummed their fingers waiting for applications and workspace that they could use to be released. The need to get releases of applications out to users put unnecessary pressure on the library development process as well as the workspaces. They were all "welded together" in terms of release management. This reflected how we generally thought of the KDE codebase in general. At Platform 11, KDE folks started thinking that having a "welded together" platform was not the best course of action. Putting application development on hold while doing library development seems a bad idea. It also happens that some libraries offered by KDE may not in fact be of use only to KDE applications. In a discussion over Skype, Seigo noted that the KDE Project wants to allow developers to choose KDE components — such as the Solid Hardware Library — without having to pull in all of the KDE libraries. The trigger for this decision? As Sebastian Kügler wrote during Platform 11, the impetus to begin working on KDE's Frameworks starts with Qt 5. As Kügler notes, the fact that Qt 5 has a change in its binary interface, "is a good point in time to introduce some changes to our frameworks that are only possible if we change the ABI -- which Qt 5 will do for us anyway." The decision has been made to start working on the next generation of KDE Frameworks following KDE 4.7 but not applications or workspaces. What are Frameworks? That's what is currently referred to as kdelibs, kde-runtime, kdepimlibs, kdepim-runtime, and kdesupport — essentially the core libraries for KDE user interface elements that are not provided by Qt. These are the libraries used by major KDE applications like the KDE Addressbook, KMail, and Dolphin. Kügler also says that this will not only make it easier for developers to use KDE Frameworks, but also lower the barrier for contributions to KDE, as well as making Frameworks more suitable for mobile devices. Seigo also emphasized the benefits for using KDE Frameworks on mobile devices such as phones, tablets, and set-top devices: "We want to make it possible that an application developer can use [just one component like Solid] a la carte with a clear set of dependencies." What Frameworks will beAccording to Kevin Ottens, the libraries will be sorted in two categories: the Framework type and into Tiers based on the level of dependencies. The Framework types will be Solutions, OS integration, and functional Qt Addons. Solutions would include a full technology like the Akonadi personal information manager (PIM) or KIO, which provides access to files stored locally or remotely. Solutions would also have libraries and mandatory runtime dependencies. OS integration Addons would either use a built-in feature for an OS or implement it directly. The example given by Ottens is libkdatetime which watches ktimezoned for time zone changes on Linux, but might use the Windows APIs directly. Finally, the functional Addons have no runtime dependencies at all. These would include new libraries like libkcore, which Ottens says "will contain the job classes, handling of command line arguments, text handling classes, file locking, and not much more." ![[Frameworks
dependencies]](/images/2011/kde-frameworks-dependencies-sm.png)
The Frameworks will also be split into Tiers, with the first Tier depending only on Qt itself, Tier 2 depending on Tier 1 frameworks, and Tier 3 having dependencies on Tier 1, 2 and other Tier 3 Frameworks. So, for example, Ottens says that window management would be a Tier 2, OS integration Framework: "The window management features of kdeui will be split out into their own library. It will depend on libkgui and Qt, granting it the Tier 2 label. As it provides integration with the OS which in particular might require a runtime payload (although not in that particular case), it is granted the OS Integration label." Ottens also provides a graph (small version at right, click for a larger version) that visualizes the organization of existing KDE components. The Frameworks plan also comes with new rules, or at least more explicit rules, that codify (as Ottens says) "changes to our habits which already happened a while ago during the Qt 3 to Qt 4 port." This includes following the license policy, following a consistent coding standard (preferably the kdelibs standard — but that's not required), meeting the criteria of the Tier and Framework type, and maintaining binary compatibility until the next major release of KDE Frameworks. Next stepsThe next steps for the Frameworks plan is to keep working on libraries until KDE 4.7 is branched, as well as trying to contribute to Qt 5. Seigo says that contributions to Qt 5 are going well so far, and that the Qt open governance process is working out satisfactorily. Though there is still work to be done and "lots of details left unresolved" he says that there have already been examples of pushing development upstream to Qt rather than trying to implement or fix things in KDE. Seigo gave the example of a problem with keyboard shortcuts due to a limitation of Qt, and says that he pushed to fix it in in Qt rather than KDE: "in two weeks it was done and in Qt." After the 4.7 branch has been created, David Faure says the plan is to create a new branch in kdelibs for the work on splitting kdelibs. This will still continue based on Qt 4, says Faure, because "we don't need Qt 5 to reorganize our own code." At the same time, application developers will continue working in master with the kdelibs frozen. How long will this go on? Seigo said that it will likely be at least two KDE releases before moving to Qt 5 and the new KDE Frameworks:
As we
get to the point that we modularize, and Qt 5 becomes a reasonable target,
and we switch to Qt 5 as a dependency, at that point we'll start bringing
applications over [...] at least two more 4.x releases while changes
happen.
At the same time, KDE will continue bugfixes and features in kdelibs, but there will be no major changes. When the time comes for applications to be ported to the new Frameworks, Seigo says that the application developers will find "a cleaner API and a much better dependencies story" and users will see performance gains — but there won't be a lot of changes due to Frameworks themselves. Seigo also says that it will mean dramatic improvements for "those using free software on tablets, set-top boxes" and a next-generation UI for mobile devices on top of Qt 5. Naturally, mobile is another driver for the project re-thinking how it handles Frameworks. Seigo says that mobile and cross-platform development is very important for the KDE project and there will be a great deal of focus on Android and MeeGo for KDE. Given the pain that users and application developers went through with the early releases of 4.x, this plan does seem to make a lot of sense for the project. Though it will take some time for it to come to fruition, there should be few downsides for application developers or users while other KDE developers focus on KDE Frameworks.
Brief items Quotes of the week
Why don't we bring up IPv4 and just wait for IPv6 to happen in the
background? That's a great question; I'm glad I asked it. First,
it requires some small changes in NetworkManager's D-Bus interface
to add connected states for both IPv4 and IPv6 simultaneously so
that applications can listen for when each stack's connectivity is
available. That's trivial. It could be done tomorrow. It's not a
technical problem at all.
-- Dan
Williams on why NetworkManager got slower
But second, it requires applications to be smarter about what resources they require and to do smart things when those resources aren't available. And that apparently happens when solid gold pigs start dropping out of the sky. I hope you have falling-gold-pig insurance for your car. But app authors often don't make their applications smarter and more network aware because hey, that's more work for them, and hey, people haven't requested this yet, and hey, that's one more D-Bus API I need to depend on and I don't know what else.
Apache is a charity conceived and constructed to provide code to
the world. We believe the best way to provide that code to
*everybody* is to do so under a permissive license. If we can
create a release of OOo, then we have performed our mission.
-- Greg Stein
Our charitable status specifically precludes us from competition. But would not want to compete, regardless. We will produce the best OOo we can. If yours is better, then we believe that is just fine. If you are able to use some portion of our code to make your job easier, then even better.
There comes a point with every shell script project where you
realise it would have been easier to use a real programming
language from the start. In this case, doing it in PHP with
pcntl_fork(), pcntl_exec() and pcntl_wait() would be a reasonable
solution. In my experience, you can't ask the question "how do I do
X in shell script" and expect to like the answer.
-- Tim Starling (thanks to Sumana
Harihareswara)
Apache traffic server v3.0.0 releasedThe Apache Software Foundation has announced the release of Apache traffic server v3.0.0. "Apache Traffic Server is a Cloud Computing 'edge' service, able to handle requests in and out of the Cloud, both by serving static content (images, JavaScript, CSS, and HTML files), and routing requests for dynamic content to a Web server (such as the Apache HTTP Server)." New features include better 64-bit support, better IPv6 support, web cache communication protocol (WCCP) support, a better plug-in API, and a number of performance improvements.
Apache votes to accept OpenOffice.org for incubationApache held a vote over the weekend to decide whether to accept OpenOffice.org as an Apache incubator project. The result was overwhelmingly in favor of the proposal, so the project will move ahead under the Apache Software Foundation. It will presumably be several months (or perhaps quite a bit more) before the project can get on its feet and potentially be considered for top-level project status.
The Document Foundation's advisory boardThe Document Foundation has announced the corporate members of its advisory board: Google, SUSE, Red Hat, Freies Office Deutschland e.V., Software in the Public Interest, and the Free Software Foundation. "The body represents The Document Foundation's sponsors, with each sponsor having the right to one representative. They will provide the future Board of Directors with advice, guidance and proposals, and will consult regularly on the further development of the Foundation and its associated projects."
Results from the GNOME Foundation board electionThe preliminary results of the 2011 GNOME Foundation board election have been posted. The upcoming board will consist of Shaun McCance, Emmanuele Bassi, Stormy Peters, Bastien Nocera, Brian Cameron, Germán Póo-Caamaño, and Ryan Lortie.
Kontact Suite 4.6 releasedThe KDE project has announced the release of version 4.6 of the Kontact Suite. "Among the most noticable improvements are faster email notifications, vastly improved performance for IMAP email accounts, and improved interoperability with other applications that consume contacts, calendars and other groupware-related information."
PathScale EKOPath 4 compiler suite open-sourcedPathScale has announced that its EKOPath 4 compiler suite will be turned into an open-source project. "This release includes documentation and the complete development stack, including compiler, debugger, assembler, runtimes and standard libraries. EKOPath is the product of years of ongoing development, representing one of the industries highest performance Intel 64 and AMD C, C++ and Fortran compilers." All that's missing is an actual link to the source; it appears to be showing up on github; the license seems to be GPLv3.
SeaMonkey 2.1 releasedVersion 2.1 of the SeaMonkey browser (and more) is out. "Building on the same Mozilla platform as Firefox 4, it delivers the latest developments in web technologies such as HTML5, hardware acceleration and improved JavaScript speed." Also included are cross-device synchronization, "personas," a new unified personal data manager, better plugin handling, and more; see the release notes for details.
Upstart 1.3 releasedUpstart 1.3 is out; it includes a number of enhancements developed for the Ubuntu "natty" release and more. This is the first release under the maintainership of James Hunt, who has implemented a new review policy aimed at, among other things, ensuring that copyrights for contributions have been appropriately assigned to Canonical.
Newsletters and articles Development newsletters from the last week
Taylor: Benchmarking compositor performanceOn his blog, Owen Taylor investigates compositor performance. "Now, this immediately gets us to a sticky problem: there are no mechanisms to throttle application frame rate to the compositor frame rate on the X desktop. Any app that is doing animations or video, or anything else, is just throwing frames out there and hoping for the best. Really, doing compositor benchmarks before we fix that problem is just pointless. Luckily, there's a workaround that we can use to get some numbers out in the short term — the same damage extension that compositors use to find out when a window has been redrawn and has to be recomposited to the screen can also be used to monitor the changes that the compositor is making to the screen. (Screen-scraping VNC servers like Vino use this technique to find out what they need to send out over the wire.) So, our benchmark application can draw a frame, and then look for damage events on the root window to see when the drawing they've done has taken effect."
Page editor: Jonathan Corbet |
|||||||||||||