Slashdot Mirror

← Back to Stories (view on slashdot.org)

KWin Adds Support for QML Decorations

Posted by Unknown on from the emacs-strikes-back dept.

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."

30 comments

  1. go KDE by quantic_oscillation7 · · Score: 1, Interesting

    is gnome dying? staring into the abyss — Swfblag http://goo.gl/6EZra

    1. Re:go KDE by Anonymous Coward · · 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!

    2. Re:go KDE by Anonymous Coward · · Score: 1

      @Anonymous Coward Thanks 4 the tips #newtoslashdot

    3. Re:go KDE by Tough+Love · · Score: 2

      is gnome dying?

      Netcraft confirms it.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
  2. Performance change? by Anonymous Coward · · Score: 1

    I'm not up on to speed on QML, does anyone know if there will be a change in performance with the move from C++? I think having smaller, more readable code is great and I'm wondering if we might also see a performance boost? Or perhaps a slight performance drop? Or will it all work out to be about the same when it's compiled?

    1. Re:Performance change? by gbjbaanb · · Score: 2

      I can't really answer that, though in my experience any declarative system has to be converted to old-fashioned native code and that always incurs some overhead. However, for a plain old GUI you're not going to see anything noticeable, and Qt quick has support for openGL and other 3d gfx that I would imagine just passes-through the relevant fast bits to the underlying system.

      There are QML tutorials available.

    2. Re:Performance change? by Jurily · · Score: 2

      QML is essentially JavaScript, with all its costs.

    3. Re:Performance change? by Grishnakh · · Score: 2

      I think the question is, is QML interpreted or compiled? Javascript is interpreted (actually it's just-in-time compiled IIRC), but it doesn't have to be, that's only because of the way it's used. There's nothing but effort and inertia keeping you from using Javascript as a high-level application language.

      If the QML is all compiled, then theoretically there may be no performance difference at all, depending on how good the compiler is.

    4. Re:Performance change? by Anonymous Coward · · Score: 0, Insightful

      There's nothing but effort and inertia keeping you from using Javascript as a high-level application language.

      Well other than it's a crappy language and has terrible performance characteristics. But, sure, if all you write are fart apps I'm sure it's a "great" choice.

    5. Re:Performance change? by slack_justyb · · 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

    6. Re:Performance change? by Grishnakh · · Score: 3, Interesting

      Oh please. "Crappy" is an opinion, nothing more; everyone says the exact same thing about every other language, whether it's C++, C#, Java, C, Python, Perl, VB, PHP, etc. They don't like C++ because it's too complex; they don't like Java because it's too verbose and doesn't have pointers, they don't like C because it's too low-level, they don't like Python because it doesn't have braces and uses whitespace, they don't like C-syntax languages because they do have braces and don't use whitespace, they don't like Perl because there's too many ways of doing the same thing, they don't like other languages because there aren't a million ways to do the same thing, etc. Javascript is an interesting language because it has some aspects of functional programming, which you don't see in most other mainstream languages. The main problem with it, for applications, is probably that it's limited in capabilities (namely I/O) because those aren't needed for something running inside a web browser, but those could be added on.

      Of course the performance isn't great; what do you expect from something you download in source form from a website and then compile on the spot before running? At least it isn't all interpreted like it used to be 10 years ago.

    7. Re:Performance change? by FranTaylor · · Score: 3, 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.

    8. Re:Performance change? by Anonymous Coward · · Score: 1

      Yea I've been writing QML for a living for almost 2 years now - there is VERY little difference between achieving some action in C++ and some action in the JS side of things in QML. I have been writing pure QML, no C++ with an embedded platform as a target - I can safely say that it handles large JS functions with very little issue and faster than I expect in a lot of cases.

      QML is constantly surprising me with what I can do on such limited hardware, so writing a bit for something as simple as decorating windows on what in the massive majority of cases will be running on desktop hardware will incur no performance penalty whatsoever.

    9. Re:Performance change? by gbjbaanb · · Score: 1

      uh? what?

      Sure QML is the definition langauge used for layout, but it is an integral part of Qt Quick, so when a user presses a button, a bit of javascript can be associated with that to perform some actions. Hence js IS executed on user actions using this system.

      I'm just reading the basic tutorial and it shows a bit of javascript associated with a mouse over event.

    10. Re:Performance change? by gbjbaanb · · Score: 1

      not really. QML is like HTML or XAML. Its a layout language that allows you to specify where things go and their properties.

      It then also allows you to add bit of code ("code behind" in WPF terms) that is written in javascript to perform activity. Using javascript for this is a good thing, its not particularly slow given that it isn't generally going to be used for anything other than simple stuff (you do not want to write your entire application in QML+js) and acts as a glue to call the underlying program logic that is written in C++. The fact that your QML-based controls look just like any other control to the underlying C++ program is really excellent.

      So, if you're coding WPF for example, you often see monolithic crappy apps where everything is stuffed into the UI layer simply because WPF allows you to put your C# logic underneath the XAML, with HTML you see the javascript put in the UI layer because you have little choice with a disconnected UI on the web, but with QtQuick you get the best of all worlds being able to write quick and easy glue with a properly defined UI back-end.

      And the UI layer is fast and doesn't have all the perf problems WPF has, so maybe MS should buy it to replace WPF for Metro - Nokia's selling everything else and it would be an excellent replacement :)

    11. Re:Performance change? by Grishnakh · · Score: 1

      That may be, but are you sure the Javascript is interpreted (or fed to a JIT compiler) when that happens, or is the whole thing compiled beforehand? Theoretically, there's nothing prevent Javascript, in a use case like this, from being compiled beforehand, and JS simply used because it's convenient and well-suited to UI programming. It isn't done with web sites because every web site can have different Javascript, so obviously that can't be compiled beforehand (you only get to download it when you visit that site); but with a UI, that's not going to change from the time you install the system on your computer, so it would make perfect sense for the distro to compile all that stuff when they do the build.

  3. Can anyone else... by chispito · · Score: 3, Insightful

    Get through the summary? Or have a general idea why we should read TFA?

    --
    The Daddy casts sleep on the Baby. The Baby resists!
    1. Re:Can anyone else... by ChunderDownunder · · Score: 1

      Well there are way too many irrelevant hyperlinks in the summary.

      But the blog post basically boils down to re-implementing Plastik in QML. That C++ theming is too complex for the average mortal, where a declarative markup language suffices instead.

  4. Re:KDE should drop c++ by Anonymous Coward · · Score: 0

    What a retarded idea. *golf clap*

  5. Ignorance! by FranTaylor · · Score: 1

    Javascript is used AS A DESCRIPTION LANGUAGE to DESCRIBE THE INTERFACE

    Have you EVER used a CONFIGURATION FILE???

    Have you ever WRITTEN A PARSER for a configuration file???

    Did you even stop to consider that perhaps Javascript is an EXCELLENT description language

    Can you PLEASE DESCRIBE how using a Javascript as a description language is SLOWER IN ANY WAY than writing a description language parser from scratch???

    1. Re:Ignorance! by sourcerror · · Score: 1

      Are you talking about JSON? Because full JS is not a description language.

  6. Re:The summary is just horrible... I mean seriousl by FranTaylor · · Score: 2

    There is PLENTY about this subject on the web.

    This is happening in Qt, look at their developer blog

    In a nutshell:

    Have you ever laid out a user interface using a GUI tool? Typically it writes an XML file or some such that describes the interface.

    The problem with XML is that it's not too good for representing algorithms and relationships. Modern GUIs have complex controls that change dynamically and interact with each other and that XML file is not rich enough to represent all the things you want to do.

    Enter Javascript. It's rich enough to describe all these relationships and dynamic behaviors.

    So instead of reading the UI from an XML file, it reads from a javascript file instead.

    Where people are SADLY MISTAKEN is they think that using Javascript in this manner imposes some sort of performance penalty. It should be plain from my description that there is NO performance penalty for doing it this way.

  7. Re:KDE should drop c++ by yahwotqa · · Score: 1

    They can call the language... wait for it... K++.

    Thank you, thank you, I'll be here all week.

  8. Meet 'twitter' by Anonymous Coward · · Score: 0

    Slashdot's favorite troll.