KWin Adds Support for QML Decorations 30
As part of a KDE-wide effort to prepare for Qt 5/QtQuick2, and a push to improve the window manager, KWin now sports QML decoration support. Currently, the C++ API for decorators is "...not very Qt like and requires a strong understanding of how the window decoration in KWin works ... [and] seems to be too difficult to be used." This complexity increases maintenance burden: "In 4.9 we ship four window decorations: the Aurorae theme engine, Oxygen, Plastik, b2 and Laptop. Together they are 10 kSLOC of C++ code and 1 kSLOC QML code (Aurorae). Before Aurorae got ported to QML the size of the decorations was 13 kSLOC. Overall that is about 10 per cent of the KWin source base, which is rather large." Basing his work on the QML version of the Aurorae engine, Martin Gräßlin set out to port Plastik to QML (the C++ version has already bitrotted, and was slated for removal): "After one and a half days of work I’m proud to say that writing decorations in QML is possible. ... In the current state the decoration consists of 370 lines of QML code and I expect to need an additional 100 lines to finish the buttons (they are already functional, that is the close button closes the window) and add some of the configuration options. The same API in C++ consists of 1500 lines of code. So we do not only get fewer lines of code but also a more readable and easier to maintain codebase. For something like a window decoration a declarative approach is much better suited than the imperative C++ way of painting elements."
Re:go KDE (Score:5, Informative)
Hi! Welcome to Slashdot! It's good to see new people here, but I'd like to point out to you that we are not twitter. There is no unreasonably short limit on post lengths. Generally, Slashdot, abbreviated by the punctuation "./" by its community members, despise URL shortening services, since they serve to obfuscate where a link will take them, and allows for trolls to post abusive content without being noticed. Please don't use URL shortening services in the future! Thanks, and happy Slashdotting!
Re:Performance change? (Score:5, Informative)
QML is essentially JavaScript, with all its costs.
While not entirely untrue, your post is quite limited in scope. QML should first and foremost be used for the problem that it is addressing, user interfaces, not actions in those interfaces. Agreed that using JavaScript within QML is a quick way of getting things done at the cost of more cycles on your CPU, however, simple tasks should not be entirely excluded. The JS engine that powers QML is made for quick one off operations that affect the UI. Implementing your applications logic at the QML level is strongly discouraged.
That is the main focus one should keep with QML, UI centric. If a programmer finds themselves doing complex testing within the JS environment they should really consider allowing the logic to be implemented in C++. Doing so is quite easy so it should become the preferred method for logic in QML applications. Remember, and I cannot stress it enough, QML is UI centric.
That brings me to the point of why QML is what it is. Many people have for years developed Qt applications with the old UI XML format and then loaded said XML via C++ code. Loading the XML created a C++ tree of what you described and then the tree could be handled by your usual C++ methods. However, the XML format for UI did not lend itself to easy operations. The cost of code required to do any single thing was equal (in access terms) to everything else. The tree had to be access, widget pulled, methods called, and so on. Reference pointers usually would be created to common widgets in an application that had a lot of action on them. With the QML engine, some of those one off operations can be implemented into the QML itself, saving the back and forth with C++. That said, the point here is that with QML, yes you loose a little cycle time to the engine, but you gain in the cycles and memory with the reference pointers for one off tasks.
I know, I keep hammering this one off gong, I apologize for that. However, I think it is one of the strongest motivators for QML adoption, IMHO. QML allows more flexibility between UI and logic, makes code more readable and easier to maintain, and can allow less C++ savvy people who don't want to muck with UI code get to the point in implementing rich UIs. However, and I'll say it again, QML is UI centric and that's where people should keep it.
I think you would have a very valid point with people who may come into Qt development and think that "Oh Gee! JavaScript! Now I am hackerz!" and start coding up a storm in JS thinking their application will run just as smooth as any other. There is always going to be that crowd, but they alone should not reduce the merit of what QML is accomplishing here.
I won't sit here and try to sugar coat QML, it is what it is. For better or worst it is where Qt is heading and it has many pros and cons to evaluate when you code your next Qt application. The good thing here is that QML isn't being force upon new developers. UI access code APIs are still there for those that want to, and in some cases should, use them. I don't see QML as an end of the world or road for Qt, but as a tool that should be carefully considered when starting a new Qt project. It offers the ability to quickly develop UI code with C++ code driving the logic and could mean the difference between weeks shaved off development time in trade for a little more overhead; versus a project that dies in inertia and headache UI logic for some of the simplest of tasks. The article deals with KWin and it exposing the needed interface for "QMLing" it. I doubt, but I have not reviewed the code here so I could stand to be wrong, but I doubt that the developers for KWin have made gross assumptions on how those binding should interact with the underlying code that could render brain-dead stubs that increase the overhead by huge margins. Instead I think, nay feel, that the KWin developers are pretty confident that in most cases QML window widgets wil
Re:Performance change? (Score:4, Informative)
QML is an INTERFACE DESCRIPTION LANGUAGE used to SET UP THE USER INTERFACE
It does NOT slow down the user interface experience because JAVASCRIPT CODE IS NOT EXECUTED ON USER ACTIONS.