Future of QT and KDE

Gusar · 2011-09-07 15:58:58

zester wrote:

my suspecion on the Nvidia Binary Blob KMS GPL violation

There is no "suspicion" here. the KMS symbols are GPL, that's common knowledge. But why is this relevant?? Nvidia doesn't use KMS and KMS is not a requirement for Wayland. Currently it is, but there's nothing in Wayland's design that prevents it from using other modesetting solutions (Nvidia's, for example) in the future. I've said that three times already. If you want confirmation of that, here: http://phoronix.com/forums/showthread.p … post156155

Last edited by Gusar (2011-09-07 15:59:59)

zester · 2011-09-07 16:09:19

Gusar wrote:

zester wrote:
my suspecion on the Nvidia Binary Blob KMS GPL violation
There is no "suspicion" here. the KMS symbols are GPL, that's common knowledge. But why is this relevant?? Nvidia doesn't use KMS and KMS is not a requirement for Wayland. Currently it is, but there's nothing in Wayland's design that prevents it from using other modesetting solutions (Nvidia's, for example) in the future. I've said that three times already. If you want confirmation of that, here: http://phoronix.com/forums/showthread.p … post156155

I am not talking about 2 - 5- 10 years from now or what might happen I am talking about the current state of Qt5 and KDE5 development and there plans to offload everything to the GPU and how that is going to be a huge mistake in terms of "Games" dump everything to the GPU regardless if it is X or Wayland. It wont work.

Gusar · 2011-09-07 16:21:05

zester wrote:

I am not talking about 2 - 5- 10 years from now or what might happen I am talking about the current state of Qt5 and KDE5 development and there plans to offload everything to the GPU and how that is going to be a huge mistake in terms of "Games" dump everything to the GPU regardless if it is X or Wayland. It wont work.

I don't see why it wouldn't work. So what if the GUI runs on the GPU, it's resource usage is negligible compared to running high-end 3D apps. Proof of that is that a lot of the GUI *already* runs on the GPU. Cairo is xrender accelerated, for example. And how do you think xrender is accelerated? With the 3D engine of course, modern graphic cards don't even have a 2D engine anymore.

kokoko3k · 2011-09-07 16:34:14

I don't see why it wouldn't work too, but the example of today widgets using the gpu doesn't fit here.
Today, part of graphics are continuely bounced between system memory and graphic memory and that's the main reason because you cannot -say- have a smooth solid window resizing.
A good example is the Blender interface, which is entirely opengl and is VERY smooth in all operations because gui widgets are uploaded to video memory and stay there forever.
Proabably that's what qt5 aims to be.
-edit-
http://zrusin.blogspot.com/2010/11/2d-musings.html

Last edited by kokoko3k (2011-09-07 16:35:37)

zester · 2011-09-07 16:48:40

I hope it all works out I really really do. My fear is that it won't. But that should just go to show you that I am really truly dedicated to Qt.
I see such great potential and it has me on edge because I dont want them to blow it.

Sooo can we have a normal conversation now lol. I am sooo done with arguing.

Last edited by zester (2011-09-07 16:51:46)

lucak3 · 2011-09-09 15:26:17

What a huge shitstorm was raised! As if the one from the Qt Labs Blog wasn't enough...
From what i understand, open source video drivers (Intel, Radeon, Nouveau) use Linux KMS, which is an 'implementation' of the KMS 'concept'. Instead, Nvidia proprietary drivers use its own KMS 'implementation', not needing the Linux one. So far i see no problem...
With regard to Qt5, i surely am disappointed by needing to learn another language (QML and/or Javascript) just to make some programs (usually private ones). If they sincerely provide proofs that it will be at least as fast as Qt4 C++ GUI, i'll happily embark in the quest of spending my (little) free time in learning it. I saw the cool things that you can make with QML, but i'm so used to the QWidget style that i'm sure it will be painful for me to separate GUI look from GUI under-the-skin workings. Just hope they're redesigning the Qt MVC pattern, as i found it a real PITA. And, since we're already here, to make a Boost-like signal and slots system and permit boost::bind et similia in it.

mento · 2011-09-10 12:31:13

Since when isn’t QML/Javascript just another option, but a full replacement?

lucak3 · 2011-09-10 15:32:45

mento wrote:

Since when isn’t QML/Javascript just another option, but a full replacement?

QWidget-based GUI aren't going to be really the main thing in Qt5: sure, it won't be dropped (for now), but it's not going to receive as much support as of now.
The plea to keep QML 'just another option' is what mainly concerned people who commented on Qt5 announce blog...

zester · 2011-09-10 17:19:18

QML is fine on a limited scope, for things like Tablets, Phones and for some desktop applications. But for full GUI's and if
it came to be that QML is what you had to use for a GUI across the desktop. Performance might not be very good. I say
might because the situation "Might" improve but as it stands now in Qt 4.8 using QML across the desktop isn't possible
in terms of a QML Window Manager. And the performance really isn't that good.

Teho · 2011-09-10 17:30:00

If I have undestood correctly QML based interfaces with OpenGL scene graph are order of magnitude faster than anything we have now. If we get good theming API, all the widgets that are avaible now as QWidgets and easy interface to create GUIs with QML (are all planned if I'm not mistaken), what would we need QWidget for?

Last edited by Teho (2011-09-10 17:31:56)

zester · 2011-09-10 17:51:18

Teho wrote:

If I have undestood correctly QML based interfaces with OpenGL scene graph are order of magnitude faster than anything we have now. If we get good theming API, all the widgets that are avaible now as QWidgets and easy interface to create GUIs with QML (are all planned if I'm not mistaken), what would we need QWidget for?

I was referring to using QML across the board not a single application or singe instance of the Qt Declarative Module running multiple applications like you see on Tablets and Mobile Devices
But try running a handful of fairly resource intensive QML applications at the same time running there own instance of the Qt Declarative Module.

A really easy test that you can do to compare performance between QML and QWidget is using the QtWebKit Module.
Performance in QML is almost unusable in this case, even for a single application. If you extend it to a full Web Browser I doubt it would even be usable.

And regardless of QML, QtWebKit in QGraphicsView/QGraphicsScene performance is really bad. Which is what QML is based on.

At this stage QML is defiantly not faster than QWidgets. Theming Api? Ummm QML is that Themeing api. Almost all the Widgets are available but they only support Qt Themes
and Gtk themes and thats a side project being done by one of the Qt Devs not something that will be officially supported.

http://cdumez.blogspot.com/2010/12/ways … mance.html

Last edited by zester (2011-09-10 18:19:40)

Teho · 2011-09-10 18:15:21

zester wrote:

And regardless of QML, QtWebKit in QGraphicsView/QGraphicsScene performance is really bad. Which is what QML is.

Isn't that because they don't use OpenGL yet and the OpenGL port is quite broken atm? What I have understood by reading Planet KDE and Qt is that one of the bigest advantages of QML is performance but because I don't have any actual knowledge on how these things work I don't really "know". Therefor if you can explain why the performance is bad, please do

http://zrusin.blogspot.com/2010/11/2d-musings.html for one seems to praise the new model

zester · 2011-09-10 19:33:02

Teho wrote:

zester wrote:
And regardless of QML, QtWebKit in QGraphicsView/QGraphicsScene performance is really bad. Which is what QML is.
Isn't that because they don't use OpenGL yet and the OpenGL port is quite broken atm? What I have understood by reading Planet KDE and Qt is that one of the bigest advantages of QML is performance but because I don't have any actual knowledge on how these things work I don't really "know". Therefor if you can explain why the performance is bad, please do
http://zrusin.blogspot.com/2010/11/2d-musings.html for one seems to praise the new model

QML and OpenGL work for me. It was broken for awhile.

Umm the design and idea of it is great I would even go as far as to say revolutionary. I think the issue is with its implementation
there are to many levels of abstraction.

Last edited by zester (2011-09-10 22:59:41)

Gullible Jones · 2011-09-10 19:52:56

Wait a minute... Pardon my ignorance, but doesn't Windows Vista/7 in Aero mode render everything with the GPU? And it works fine for gaming, provided you have an expensive gaming-oriented graphics card (which you need for gaming these days anyway). Aero is a slow resource hog on low-powered graphics chipsets; but nobody does serious gaming with an Intel GPU anyway.

Mandatory disclaimer: I don't do 3D games at all. And as long as my computer can handle office stuff, audio/video playback, browsing, and compiling stuff - possibly all at once - without getting bogged down, I don't care if the desktop is 2D, 3D, or 4D with extra compacted dimensions. I am a definitely a Linux geek/hobbyist, but even so, the important thing IMO is that it's fast, usable, and works.

zester · 2011-09-10 22:53:58

Gullible Jones wrote:

Wait a minute... Pardon my ignorance, but doesn't Windows Vista/7 in Aero mode render everything with the GPU? And it works fine for gaming, provided you have an expensive gaming-oriented graphics card (which you need for gaming these days anyway). Aero is a slow resource hog on low-powered graphics chipsets; but nobody does serious gaming with an Intel GPU anyway.
Mandatory disclaimer: I don't do 3D games at all. And as long as my computer can handle office stuff, audio/video playback, browsing, and compiling stuff - possibly all at once - without getting bogged down, I don't care if the desktop is 2D, 3D, or 4D with extra compacted dimensions. I am a definitely a Linux geek/hobbyist, but even so, the important thing IMO is that it's fast, usable, and works.

I am not sure about what Windows Vista/7 graphics stack look,s like, but I can tell you that there defiantly not rendering via OpenGL, not using GLX and X, Wayland or Qt.
And they do have the full cooperation of the GPU vendors especially Nvidia being that they own 30% of the Nvidia stock.

I wasn't referring to OpenGL in general but Qt/KDE, didn't think I had to point that out being that this whole topic is about Qt5/KDE5.

Last edited by zester (2011-09-10 22:59:24)

MrCode · 2011-09-10 22:59:57

My 2¢:

Gullible Jones wrote:

Wait a minute... Pardon my ignorance, but doesn't Windows Vista/7 in Aero mode render everything with the GPU?

I'm not 100% sure either, but I would tend to think that most of the buffer contents (i.e. contents rendered in the windows) are rendered CPU-side, whereas the actual compositing work/effects are done GPU-side, very similar to how Compiz works (i.e. render window content to a buffer which is then copied to a texture to be mapped onto an OpenGL/DirectX surface). This probably depends on the application, though. I do know that in Compiz (at least with the NVIDIA binary driver; not sure about other GPU drivers ), when GPU-rendered content needs to be composited, it's just rendered to an offscreen pixmap and composited into the final image along with everything else. I'm not sure how Windows handles this…

From Wikipedia:

DWM uses DirectX 9 to perform the function of compositing and rendering in the GPU, freeing the CPU of the task of managing the rendering from the off-screen buffers to the display. However, it does not affect applications painting to the off-screen buffers; depending on the technologies used for that, it might still be CPU-bound. DWM-agnostic rendering techniques like GDI are redirected to the buffers by rendering the UI as bitmaps.

EDIT: I know virtually nothing about Qt here; I just thought I'd chime in with my view on the topic of GPU-based compositing. Please forgive me if this post is way off-topic.

Last edited by MrCode (2011-09-10 23:11:04)

lucak3 · 2011-09-11 10:12:33

From what i know: sure, OpenGL (and DirectX on WIn) is fast because of using the GPU which is certainly faster than CPU to render graphics, BUT there is a problem: to work with GPU, you need to upload textures and such to it, which set for a full-blown GUI toolkit like Qt is nor easy nor uber fast. From what i understand, QGraphicsView and successively QML are the way Qt designed to reduce the upload load to minimum: QGraphicsView has not been largely used (outside of KDE) because people still liked (like me) the QWidget system, which seemed easier. QML should be even easier, since the code is not C++ anymore, so even designers should be able to handle it. The problems that many (and I) have with this are that we don't know what happens to weak-CPU/weak-GPU systems and we don't want to learn another language for designer when we don't have designers.

Teho · 2011-09-13 12:00:10

Qt is taking a big step foward in Open Governance and vendor independence. The plan has taken quite sometime and is finally reaching it's climax:

http://labs.qt.nokia.com/2011/09/12/qt-project/

It’s taken a little longer than expected, but we are now very close to move hosting of Qt to a new domain: qt-project.org. The domain will be owned by a non-profit foundation whose only purpose is to host the infrastructure for the Qt project. -- All technical decisions, as well as decisions about the project direction, will be taken by the community of Contributors, Approvers and Maintainers. For example this means that people in Nokia working on Qt will start working with Qt as an upstream project. Everyone will be using the same infrastructure, including mailing lists and IRC.

http://blog.qt.nokia.com/2011/09/12/qt-project/

The Qt governance, roadmap and releases will be driven openly by the Qt Project – open to all the stakeholders willing to contribute. It will have an open governance model based on equal access to all discussions and tools, an open contribution process and meritocratic assignment of roles.

There are more interesting announcements to come like reworked CLA:

The CLA is going to look rather different than the one you see in your link. We have had lots of discussions with many of our core stakeholders (both companies as well as open source projects and individuals) trying to find a solution that works. Nokia does have some existing legal obligations concerning Qt, something that makes it impossible to completely remove the CLA.

zester · 2011-09-28 14:36:33

http://www.computerworld.com/s/article/ … nomyId=154
https://www.tizen.org/

Over the next couple of months, Intel will be working very hard to make sure that users of MeeGo can easily transition to Tizen, Sousou said, adding that he will be working even harder to make sure that developers of MeeGo can also transition to Tizen.
Since Nokia decided in February to choose Windows Phone over MeeGo, Intel has been without a major hardware partner, but with Tizen it has Samsung on its side. Intel and Samsung will lead the Tizen technical steering team, according to a blog post on the new Tizen website.

The MeeGo project is already encouraging its members to make the transition to Tizen, going so far as to say that it believes the “future belongs to HTML5-based applications, outside of a relatively small percentage of apps, and we are firmly convinced that our investment needs to shift toward HTML5.

Teho · 2011-09-29 07:58:26

http://online.wsj.com/article/SB1000142 … lenews_wsj

If true it's definetly a good news for both Linux and Qt. Now that MeeGo is dead Nokia has new plans on Linux based Qt phones.

This isn't the first time that Meltemi has been mentioned, http://www.theregister.co.uk/2011/04/27 … cuts_memo/

zester · 2011-09-29 11:35:47

Teho wrote:

http://online.wsj.com/article/SB1000142 … lenews_wsj
If true it's definetly a good news for both Linux and Qt. Now that MeeGo is dead Nokia has new plans on Linux based Qt phones.
This isn't the first time that Meltemi has been mentioned, http://www.theregister.co.uk/2011/04/27 … cuts_memo/

Take it from the horses mouth then.
http://appdeveloper.intel.com/en-us/blo … ntel-appup
http://developer.qt.nokia.com/forums/viewthread/10153/

Also Nokia will not be building any more Qt phones. The Nokia N9 was the last.

And there is no guarantee Tizen will even support Qt. I am betting its going to be based on Chrome or Firefox's Native
Client Sdk.

Last edited by zester (2011-09-29 11:36:36)

Teho · 2011-09-29 12:11:14

zester wrote:

Also Nokia will not be building any more Qt phones. The Nokia N9 was the last.

Eh? Any sources on such claim? They are still going to release Symbian phones and absolutely every single on them will use Qt. They really can't put Windows Phone on low end handsets so this is where Meltemi comes to play.

Tizen has nothing to do with Meltemi (well except that both use Linux I guess). Nokia has a lot of Qt developers so it would be downright idiotic not to use it in their own platform.

zester · 2011-09-29 12:28:19

Teho wrote:

zester wrote:
Also Nokia will not be building any more Qt phones. The Nokia N9 was the last.
Eh? Any sources on such claim? They are still going to release Symbian phones and absolutely every single on them will use Qt. They really can't put Windows Phone on low end handsets so this is where Meltemi comes to play.
Tizen has nothing to do with Meltemi (well except that both use Linux I guess). Nokia has a lot of Qt developers so it would be downright idiotic not to use it in their own platform.

I am just going off of what Nokia says on Qt Devnet and what is common knowledge.

On February 11, 2011, Nokia announced that it would migrate away from Symbian to Windows Phone 7.[8] In June 22, 2011 Nokia has made an agreement with Accenture as an outsourcing program. Accenture will provide Symbian based software development and support services to Nokia through 2016 and about 2,800 Nokia employees will be Accenture employees at early October 2011.[9]

http://en.wikipedia.org/wiki/Symbian#Ap … elopment_2

But then again

Information about Nokia's future OS Meltemi was leaked by Wall Street Journal today.
http://online.wsj.com/article/SB1000...googlenews_wsj
It's a new Linux based OS aimed at the low end market (S40 type)

It's behind the "Bringing Qt to the next billion".

My point was to show others that you can't count on a corp to have your best interest at heart. If you want a mobile phone or tablet , smart tv that is based on tech that you use
it best if you just assemble that hardware your self. (Beagle & Panda Board, Gumstix, Magictouch, Arduino, ...)

All of the Bad/Conflicting news we have been seeing hasn't effected me in the slightest.

Teho · 2011-09-29 13:09:44

zester wrote:

All of the Bad/Conflicting news we have been seeing hasn't effected me in the slightest.

I don't see how these news are conflicting. Nokia builds smartphones and handsets. Symbian, MeeGo and Windows Phone are all about smartphones. Windows Phone will replace Symbian and MeeGo but it won't be used in the low end hansets that account the most of the phones that Nokia sells. These phones are getting closer and closer to smartphones in terms of features and performance. Nokia sees that S30/40 isn't flexible engough and introduces new OS code named Meltemi to fill the gap. It's quite obvious that Nokia would use Qt on system like that:

1. They own Trolltech
2. They have previous experience with it
3. They have a lot of Qt developers on house
4. They have Linux OS that uses Qt (Maemo/MeeGo/Harmattan)

Now as long as Nokia doesn't confirm anything this is still only specualtion. I however have never heard that Nokia would be completely abandoning Qt so I'd say that it's hardly a "common knowledge".

Arch Linux

#51 2011-09-07 15:58:58

Re: Future of QT and KDE

#52 2011-09-07 16:09:19

Re: Future of QT and KDE

#53 2011-09-07 16:21:05

Re: Future of QT and KDE

#54 2011-09-07 16:34:14

Re: Future of QT and KDE

#55 2011-09-07 16:48:40

Re: Future of QT and KDE

#56 2011-09-09 15:26:17

Re: Future of QT and KDE

#57 2011-09-10 12:31:13

Re: Future of QT and KDE

#58 2011-09-10 15:32:45

Re: Future of QT and KDE

#59 2011-09-10 17:19:18

Re: Future of QT and KDE

#60 2011-09-10 17:30:00

Re: Future of QT and KDE

#61 2011-09-10 17:51:18

Re: Future of QT and KDE

#62 2011-09-10 18:15:21

Re: Future of QT and KDE

#63 2011-09-10 19:33:02

Re: Future of QT and KDE

#64 2011-09-10 19:52:56

Re: Future of QT and KDE

#65 2011-09-10 22:53:58

Re: Future of QT and KDE

#66 2011-09-10 22:59:57

Re: Future of QT and KDE

#67 2011-09-11 10:12:33

Re: Future of QT and KDE

#68 2011-09-13 12:00:10

Re: Future of QT and KDE

#69 2011-09-28 14:36:33

Re: Future of QT and KDE

#70 2011-09-29 07:58:26

Re: Future of QT and KDE

#71 2011-09-29 11:35:47

Re: Future of QT and KDE

#72 2011-09-29 12:11:14

Re: Future of QT and KDE

#73 2011-09-29 12:28:19

Re: Future of QT and KDE

#74 2011-09-29 13:09:44

Re: Future of QT and KDE

Board footer