Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

KWin Adds Support for QML Decorations

Unknown Lamer posted about a year and a half ago | from the emacs-strikes-back dept.

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


first fascist (-1)

Anonymous Coward | about a year and a half ago | (#40796165)

who is john galt ?

Re:first fascist (-1)

Anonymous Coward | about a year and a half ago | (#40796355)

Some peckerwood whose woman left him for Tyrone's big black dick?

go KDE (1, Interesting)

quantic_oscillation7 (973678) | about a year and a half ago | (#40796359)

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

Re:go KDE (5, Informative)

Anonymous Coward | about a year and a half ago | (#40796621)

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:go KDE (-1)

Anonymous Coward | about a year and a half ago | (#40798369)

You're a fag. Also, it's /.

Re:go KDE (1)

Anonymous Coward | about a year and a half ago | (#40798517)

@Anonymous Coward Thanks 4 the tips #newtoslashdot

Performance change? (1)

Anonymous Coward | about a year and a half ago | (#40796391)

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?

Re:Performance change? (2)

gbjbaanb (229885) | about a year and a half ago | (#40796487)

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. [qt-project.org]

Re:Performance change? (2)

Jurily (900488) | about a year and a half ago | (#40796657)

QML is essentially JavaScript, with all its costs.

Re:Performance change? (2)

Grishnakh (216268) | about a year and a half ago | (#40797433)

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.

Re:Performance change? (0, Insightful)

Anonymous Coward | about a year and a half ago | (#40797455)

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.

Re:Performance change? (3, Interesting)

Grishnakh (216268) | about a year and a half ago | (#40798791)

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.

Re:Performance change? (3, Informative)

FranTaylor (164577) | about a year and a half ago | (#40799159)


It does NOT slow down the user interface experience because JAVASCRIPT CODE IS NOT EXECUTED ON USER ACTIONS.

Re:Performance change? (1)

gbjbaanb (229885) | about a year and a half ago | (#40800847)

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.

Re:Performance change? (1)

Grishnakh (216268) | about a year and a half ago | (#40803893)

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.

Re:Performance change? (5, Informative)

slack_justyb (862874) | about a year and a half ago | (#40797623)

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 will run par or slightly beneath par with C++ in this respect.

While I don't entirely disagree with what you said, I believe it paints a picture that is not wholly consistent with what QML can and was intended to do. We are indeed at the early phases of this, but Qt has shown quite a lot of good in the limited amount of beta time it has had thus far in comparison to the track record that C++/XML has had. If results were consistently poor or consistently marginal I would say that you and I would be having quite a different conversation about QML inclusion to Qt.

Finally, I will leave you with a link [blogspot.com] to some information on improving QML in the next application in Qt that you may develop. As gbjbaanb pointed out in his post, Qt does try to handle QML intelligently, by passing many operations to systems that are better apt to handle them. However, with any tool (and you can find references to bad assumptions in the linked post) not fully understanding the way to make QML think like you think can degrade performance.

Thank you

Re:Performance change? (1)

Anonymous Coward | about a year and a half ago | (#40799565)

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.

Ignorance! (1)

FranTaylor (164577) | about a year and a half ago | (#40799147)



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???

Re:Performance change? (1)

gbjbaanb (229885) | about a year and a half ago | (#40800879)

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 :)

Can anyone else... (3, Insightful)

chispito (1870390) | about a year and a half ago | (#40796629)

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

Re:Can anyone else... (1)

ChunderDownunder (709234) | about a year and a half ago | (#40798645)

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.

KDE should drop c++ (-1)

Anonymous Coward | about a year and a half ago | (#40796653)

I have to give the c++ working group credit for all the new concepts they have put into c++, without breaking backwards compatibility. That backwards compatibility adds a lot of quirks to worry about. Maybe the KDE team can develop a new language, or adapt an existing one (D?) to use in future KDEs. Yes, that will result in losing lots of existing code, but I don't care much for KDE 4.

Re:KDE should drop c++ (0)

Anonymous Coward | about a year and a half ago | (#40796695)

What a retarded idea. *golf clap*

Re:KDE should drop c++ (1)

yahwotqa (817672) | about a year and a half ago | (#40800195)

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

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

The summary is just horrible... I mean seriously.. (-1)

Anonymous Coward | about a year and a half ago | (#40797545)

I'm a grad student taking courses with some of the top OS/middleware (and Hybrid & Embedded Systems) academics in the world ... I have no clue what the article is actually talking about from this summery...

Too much abbreviation, not enough "Context" , say "we streamlined our graphics engine , called BIG_LONG_RANDOM_LETTER_NAME, and it will now help with the API that developers will use when programming for KDE. The new API and graphics engine re-work was done to coincide with the newest version of QT5, the main programming tools for KDE, and QTQuick2, the (___whatever it is... i have no clue and the summery didn't tell me___ ) " Now how hard was it to write that?

Re:The summary is just horrible... I mean seriousl (2)

FranTaylor (164577) | about a year and a half ago | (#40799181)

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.

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account