Re: [Qt5-feedback] Concern about removal of QWidget classes
Op 10-10-2011 22:58, Иван Комиссаров schreef: Am i correct, that it wouldn't be possible to integrate QDeclarativeView into widget-based app in qt5? I already used such approach, was quite pretty. As I understand it, that worked nicely with Quick 1 (based on QGraphicsView), but not with Quick 2 (based on scenegraph). André ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
The current Qt4 is as simple as changing the target in QtCreator and the application is compiled to the next OS without absolutely any change in your code. Perhaps, but with QWidget your app probably looks bad in mobile platforms making your cross-compatibility of little value for actual mobile users. (Maybe I'm wrong, again having links to your apps would help making more accurate judgments). Actually it looks pretty good. You can see the same code working in desktop and mobile device in a real and live project: http://www.darhon.com/book/screen-shots-drf Some windows are divided in 2 or 3 sections for the mobile version to fit properly in the screen. Then the user just show and hide the sections as convenience. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
2011/10/10 Thiago Macieira thi...@kde.org: ... (btw, did anyone say Kontact Touch is a complex app mixing QML and C++?) You mean this one? [Kde-mobile-users] Re: Maemo/N900: KMail Touch very slow and unresponsive [http://www.mail-archive.com/kde-mobile-users@kde.org/msg00122.html etc.] Sorry, but I honestly tried to find some info and screenshots googling KMail Touch, and the first 20 or so hits link to issues about performance. Maybe that little mail client is already too complex for QML, even in combination with C++? I don't want to know what happens when it comes to *real* desktop applications with regards to to resources usage and performance... p.s. Sorry, I know my above comment was a bit too cynical. But I saw it fit my main concerns towards the usage of JavaScript. And I'll come up with a separate thread, showing some hard evidence why I am not very convinced of the usage of JavaScript (and YES, you didn't see me type QML!) in a large scale application such as a video editing software (think Final Cut Pro), photo editor (think Gimp, think Photoshop, ...), or CAD/simulation software... ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
2011/10/11 lars.kn...@nokia.com On 10/11/11 8:18 AM, ext Andre Somers an...@familiesomers.nl wrote: Op 10-10-2011 22:58, Иван Комиссаров schreef: Am i correct, that it wouldn't be possible to integrate QDeclarativeView into widget-based app in qt5? I already used such approach, was quite pretty. As I understand it, that worked nicely with Quick 1 (based on QGraphicsView), but not with Quick 2 (based on scenegraph). Yes, it's not yet doable. But it mainly depends on someone doing the required work. I think it is an important feature to have to get more acceptance of QML on the desktop. I am interested in using QML to create specialized widgets, like more capable list views, but only if I know that I can use those widgets everywhere, also in existing, widget-based parts of the code. And sorry, I don't know enough about scenegraphs and openGL to do this work myself. Andre ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
2011/10/11 Иван Комиссаров abba...@gmail.com: As i said, i know that they are stay. I need bug fixes, not only for qml and webkit stuff, for whole Qt. All i know that 2 years ago my bugs were fixed, now they don't. You have what boils down to a few choices: - open source support: fix them yourself (which you don't seem to want to do) - commercial support: i.e. pay someone else to fix them, such as Digia (http://qt.digia.com), or one of the many other open source consultancies with Qt skills around, like basyskom, Collabora, Nomovok, ... There's no such thing as a free lunch. You either invest your time, or your money. (in the interests of full disclosure: I work for Collabora) ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
2011/10/11 Adriano Rezende adriano.reze...@openbossa.org: ... I'm working in a QML project for desktop that has more than 500 QML files (~ 43 K LOCs). Unfortunately it's under NDA so I cannot say much about it, but it proves that QML can scale if you know how to use your resources. If you know how to use your resources - Manage your boundaries - Plan your development - Industrialise the work to be done etc. Yep, I'll try to remember these ;) I don't think I'll hear them enough every week or so ;) Seriously, I didn't say it was not *possible* doing desktop development using QML! I just think the whole idea of outsourcing your GUI logic to JavaScript is... well... just not optimal for large GUI projects, for points that I already hinted at in another post here, but which I prefer to post into more detail into a separate thread for discussion) later on this week, when I'll have time to do some more research. So what was your experience? Does your UI look unusually different than if you had used the QWidget approach? What is the performance / memory consumption like? Why did you go for QML in the first place? Do you think you saved development time (substracting your learning effort, off course)? Why do you think you could not have achieved the same results with QWidgets? And most importantly: does your UI conform to the relevant OS look and feel? Would be interesting to know. Try to get some real information, or study more about it, before spreading fear and dispair. I already have most of the information I need to show my point and why I still think QWidgets should not only remain intact (yes, I know, they will remain), but even be actively be developed further (by whoever). Further why I think being able to integrate QML (sic!) with QWidgets would help both worlds and why I am not totally against the idea to design some custom widgets with QML (in the best case without any dependency on JavaScript). But again, I'll post that in a different thread, when the heat as gone a little bit... Cheers, Oliver ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On Tue, Oct 11, 2011 at 9:54 AM, Till Oliver Knoll till.oliver.kn...@gmail.com wrote: 2011/10/11 Adriano Rezende adriano.reze...@openbossa.org: ... I'm working in a QML project for desktop that has more than 500 QML files (~ 43 K LOCs). Unfortunately it's under NDA so I cannot say much about it, but it proves that QML can scale if you know how to use your resources. If you know how to use your resources - Manage your boundaries - Plan your development - Industrialise the work to be done etc. Yep, I'll try to remember these ;) I don't think I'll hear them enough every week or so ;) The meaning is really technical, it's not a management bullshit. You need to take care about performance penalties and memory consumption, since the kind of applications QML are designed to uses heavily anchor-layouts and rely on huge image datasets. Seriously, I didn't say it was not *possible* doing desktop development using QML! I just think the whole idea of outsourcing your GUI logic to JavaScript is... well... just not optimal for large GUI projects, for points that I already hinted at in another post here, but which I prefer to post into more detail into a separate thread for discussion) later on this week, when I'll have time to do some more research. To be fair I tend to use Javascript as minimal as possible, I don't like it either. I don't know why most of the discussions ends up in Javascript. The most important feature is the language itself, JS is just a helper. You will need to use in most of the cases just for property bindings, which basically ends up being optimized in the QML side, most of them are not even interpreted by the JS engine. So what was your experience? QML needs some improvements and optimizations, but currently it's the best way to address native lookfeel and custom applications IMO. Does your UI look unusually different than if you had used the QWidget approach? Yes, it's totally different. Full of animations and effects and a lot of fancy widgets. Basically it's a game oriented design applied to a custom application. What is the performance memory consumption like? It uses more memory than a custom QWidget based application just by the fact that it has a heavy image data set. Why did you go for QML in the first place? The client just wanted a beautiful application, full of animations and effects, which basically is almost a pre-requisite today. Implementing this kind of application using QWidget is out of question. Do you think you saved development time (substracting your learning effort, off course)? I work with QML before it was officially released, when its syntax was XML based. So I may be biased to say that its learning curve tends to zero. Regarding, the boost in development time, it's something already noticed by several developers. You need to experiment it in a real application to see the real benefits. Why do you think you could not have achieved the same results with QWidgets? Basically because QWidget is not up for the task and it was not designed for this kind of application. And most importantly: does your UI conform to the relevant OS look and feel? No it doesn't. I believe, this would be the common case for future applications. Most of the clients wants a customized application, even for desktop. Try to get some real information, or study more about it, before spreading fear and dispair. I already have most of the information I need to show my point and why I still think QWidgets should not only remain intact (yes, I know, they will remain), but even be actively be developed further (by whoever). Further why I think being able to integrate QML (sic!) with QWidgets would help both worlds and why I am not totally against the idea to design some custom widgets with QML (in the best case without any dependency on JavaScript). I'm not against integrating QML on top of QWidget, I'm against integrating QWidget on top of QML. I agree that the first approach would probably easy this transition from a bottom-up perspective. Also, even applications with native lookfeel uses fancy widgets sometimes. Br, Adriano ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
2011/10/12 Alexander Neundorf neund...@kde.org: On Monday 10 October 2011, Georg Rudoy wrote: But that's the only sane and feasible way of porting big QWidget-based applications to QML. Did I miss something ? Why would I want to do that ? I believe QML has the potential to cover a big part of QWidget usecases (and that's a wary formulation of my beliefs). At least, I believe it would someday make sense to port one of my apps to it :) -- Georg Rudoy LeechCraft — http://leechcraft.org ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
- Some of the UI in my case are created dynamically either at compile time or at runtime. The former depending on the target platform and the latter depending on the device screen resolution. I don't see this possibility with QML. Why is that? The fact that the UI is declarative in nature does not mean that it is static or that you have to declare everything beforehand. That is a misconception. It is far easier to change the UI dynamically than it ever was with QWidget and .ui files. Qt Quick is actually designed precicely to target multiple resolutions. Did you have a specific use case in mind? Regards, Jens Bache-Wiig I don't know about his usecases but because this discussion is really interesting for me i can send my usecases. I have an application. This application needs to control multiple objects (character rig in vfx, or rig for fluid simulation of flowline) I need now an ui that can, in certain circumstances reconfigure itself based on the existing and configured objects. That means as one example for each object we have some common states (enabled, disabled, animated or not, active, inactive, stopped, running, keyframe, ) and we want to have a dynamic ui that shows these objects in a grouped grid (see windows explorer) where the grouping can be changed at runtime and even created at runtime. Currently this is a nobrainer in qt widgets. i have eg an SysButton class that shows the name of the system, the state, some functionality. If i have 100 systems i just create 100 buttons, give them in their initialize function the name of the system, the button uses that name to find the system from a global class and connecting itself with it. For the 100 buttons i created my own layout class that can show them based on the screensize. The buttons are simply organized in groups, if the screensize is to small for the number of system buttons it will use automatic scale so that the non important buttons get smaller, it can scroll and reorder the buttons if necessary to show the Important ones (they red or orange ones) at top. This is just a simple example. We have much more complex Userinterfaces that need to be automatically created by the software based on the current scene or workflow step. Now i thought cool with qml this might be easier and we can have a cooler looking ui for all the artists. They can probably even modify that stuff for their own needs. Part of it is, i don't have to write my SysButton class in c++ and can easily change the visual style great. BUT ... how can i create 100 of them without extreme large development overhead ? I can't. In C++ it is only SysButton* newButton = new SysButton ( myUIContainer, sysName ); FINISHED ! I did not find a good way to do it in qml, show me one please. I tried to work with models but really ? Writing a modell for creating a list of sysbuttons ? Sorry this is just not real. It can't be because this would be just stupid. What is with layout ? i have no idea of how to create a real working dynamic layout in qml. It is just not working in real world situations. Yes it may be possible by using hacks and thousand of lines of javascript code, but this is just not practical. We thought in the end even about creating hundred of qml views in the end that are controlled by c++. How can i connect the QML SysButtons ? Only if i make all my systems accessible to qml (wich are in the end several thousand objects that i have to make accessible. And doing this IS a large overhead runtime and development wise) (Also here show me a good way instead of having a c++ initialize function that belongs to my widget, having a javascript function that belongs to my qml object) Yes i know exactly HERE qml COULD be better because of its runtime capabilities. But the truth is ... it is just not usable Because debugging IS a REAL nightmare. Whatever you say i can say from my metrics that using qml took as more than 12 times longer for the current tests than with qwidgets. And yes there is stuff like learning time. But the debugging is just real shit and i know why i say shit. It can be only worse if you have to use remote debugging on a ui application that only writes some traces every now and then and you do not have an debugger. The ui quality gets much worse than before, not because of missing features but because of the really bad separation of logic and ui. Whatever you say including javascript in files that are to be handled by designers was NOT a good idea and WILL NEVER be a good idea. We dont have ANY designer who can code. Yes they CAN hack some javascript yay. But that is exactly the SHIT that costs time. Because they can't code, they can only hack some stuff into it, That is untested, in many cases not working and just (if you need to integrate more complex functionality) way to much for them. So we realized we have to divide javascript functions and qml separately creating an
Re: [Qt5-feedback] Concern about removal of QWidget classes
On Mon, Oct 10, 2011 at 8:30 AM, Ganshorn Thomas maili...@novaimages.de wrote: An addition Try to draw some line diagrams in qml please. HTML5 Canvas no problem. QML ? Please write your own c++ class that you register at qml. two things to note here: #1: it's already been written for you (https://qt.gitorious.org/qt-labs/qmlcanvas) #2: canvas functionality is integrated into Qt Quick v2 (http://doc.qt.nokia.com/qt5-snapshot/qml-qtquick2-canvas.html) All the best, Robin ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
Try to draw some line diagrams in qml please.
HTML5 Canvas no problem.
QML ? Please write your own c++ class that you register at qml.
I had the same reaction last year. Which is why I created:
http://qt.gitorious.org/qt-labs/qmlcanvas
In Qt 5, html5 Canvas is part of the language.
BUT ... how can i create 100 of them without extreme large development overhead
?
I can't. In C++ it is only
SysButton* newButton = new SysButton ( myUIContainer, sysName );
FINISHED !
Depends on your use case. Sounds indeed like you could use a model. But if
that sounds
too heavy handed. You can use a Repeater:
Repeater {
model: 100
SysButton {}
onItemAadded: { initialize button }
}
And if you prefer something closer to C++, you create a button Component and
instantiate it:
var sysButton = buttoncomponent.createObject(conainer)
What is with layout ? i have no idea of how to create a real working dynamic
layout in qml.
It is just not working in real world situations. Yes it may be possible by
using hacks and thousand of lines of javascript code, but this is just not
practical.
We thought in the end even about creating hundred of qml views in the end that
are controlled by c++.
It is a bit hard to answer without seeing a picture of what you want to
achieve. In general you can get far with the built in layouts and anchoring. I
have written some layouts in javascript though. If there are valid use cases, I
certainly see that we might add more complex layouts in Qt Quick 2. Perhaps you
are making things a bit more difficult by avoiding the model and being explicit
about the buttons. A GridView sounded like a good fit for an explorer type
layout of icons or buttons. But I also wonder how you did the layout easily in
html5.
How can i connect the QML SysButtons ? Only if i make all my systems accessible
to qml (wich are in the end several thousand objects that i have to make
accessible.
And doing this IS a large overhead runtime and development wise)
I don't know enough about the use case or why these buttons are so complex. How
do you connect it in C++? Your button has an index. Can't you simply have a
buttonClicked(int) slot on the C++ side?
Because debugging IS a REAL nightmare.
Whatever you say i can say from my metrics that using qml took as more than 12
times longer for the current tests than with qwidgets.
And yes there is stuff like learning time. But the debugging is just real shit
and i know why i say shit.
Debugging can certainly get better. It is already a lot better than it was a
year ago if you use the tools available. I agree that a C++ application at the
moment feels more predictable.
We dont have ANY designer who can code. Yes they CAN hack some javascript yay.
But that is exactly the SHIT that costs time.
Because they can't code, they can only hack some stuff into it, That is
untested, in many cases not working and just (if you need to integrate more
complex functionality) way to much for them.
Regular designers should not have write code. Web designers with javascript
skills might have the skill set required. I personally find it a lot easier to
implement complex UI designs in QML than with C++ though. Our designers
usually just send us pretty pictures and tell us how they want it to work. And
if they ask me to tweak the margin a few pixels, I know it takes me 5 seconds
to try it out in Qt Quick without having to recompile the whole project. But
having a designer taking over the actual interface code is probably not a good
idea. You can keep all your code in .js files if you want to. Perhaps we should
introduce a flag in Qt Quick that enforces that as a policy. I think the
majority would prefer the convenience of being able to do a simple signal
emission inline though.
So we tried another approach ... we use javascript and html5 and what to say ?
it works better in our case because there is a separation between layout, look
and code.
I thought html5 was every bit as javascript enabled as Qt Quick. But it is
great that you found a technology that works for your project. Qt supports and
strongly encourages html5 hybrid development. In fact we are pushing it more
than ever. It is not the solution for everyone though. I don't think you could
do a full native looking UI with it for instance.
Regards,
Jens Bache-Wiig
___
Qt5-feedback mailing list
Qt5-feedback@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On Fri, Oct 7, 2011 at 9:13 PM, lars.kn...@nokia.com wrote: Putting QWidgets on top of/inside the scene graph is doable without performance regressions. We haven't done it though. Personally, I consider such an effort top priority if you want people to migrate from QtWidgets to Qt Quick 2. At kdegames, we have 40 applications which are nearly all based on QGraphicsView. Reality is that GUI and logic are not separated properly; the views, scenes and items contain most of the logic. It's simply not feasible to start porting these towards a scene-graph-based interface unless there is a way to embed the QGraphicsView into the chrome provided by Qt Quick 2. Greetings Stefan ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
10.10.2011, 13:39, Stefan Majewsky stefan.majew...@googlemail.com: On Fri, Oct 7, 2011 at 9:13 PM, lars.kn...@nokia.com wrote: Putting QWidgets on top of/inside the scene graph is doable without performance regressions. We haven't done it though. Personally, I consider such an effort top priority if you want people to migrate from QtWidgets to Qt Quick 2. Like what Apple is doing: to make people use something new one should make them feel that something old is less attractive than it was before... At kdegames, we have 40 applications which are nearly all based on QGraphicsView. Reality is that GUI and logic are not separated properly; the views, scenes and items contain most of the logic. However, I can see benefits of specifically QGraphicsView running on top of scene graph. -- Regards, Konstantin ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On Mon, Oct 10, 2011 at 2:17 PM, Alexis Menard alexis.men...@openbossa.org wrote: BTW, currently folks who need WebKit 2 are actually forced to use QML because no Qt/C++ API exists. This is bullshit based again on not checking out stuff. Dude, git clone WebKit trunk and look the h files are exported, the method public, and everything is there. What we promised is a good QML API but we let around the C++ (which is the one our QML plugin use also btw). By good API in QML I mean a property based one which in some cases is less convenient in C++ but *still there*. So you can use the Webkit C++ api directly in your Qt application? Is there a public example for this (like the plugin you mention)? ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On Mon, Oct 10, 2011 at 1:23 PM, Alexis Menard alexis.men...@openbossa.org wrote: I think this opens a pandora box just like QGraphicsProxyWidget. People will expect to put anything inside and hope that it will work and get angry when it doesn't (not knowing why it can't work). But if it's easier and less error prone that QGraphicsProxyWidget then yes perhaps it's a good step. QWidget-QGraphicsView is (or at least feels like) an entirely different porting story than QWidget+QGraphicsView-QtQuick for two reasons: 1. QGraphicsView and QtWidgets have blatantly different usecases (user interface vs. visualization), while QtQuick is a UI Construction Toolkit (the uick in Quick) just like QWidgets. 2. Porting QWidget to QGraphicsView can happen from inside to outside (usually single widgets with custom paintEvent() have been converted into a QGraphicsView) while, from what I can currently project, porting to Qt Quick while happen from the outside, starting at the mainwindow level, while leaving the contained QWidgets (or QGraphicsView) intact during the porting. QWidget-QML is not a trivial port though so at some point people will have to move the code from C++ to QML. That's why I want to do it step to step, and again, starting at the standardized chrome layer (mainwindow with menu, tool, and status bars) looks like the obvious direction, not only because this is the point where most needs to be changed in touch-friendly ports for mobile. Thing is that most of the logic could be written JS. I was wondering if that's better to have an intermediate solution rather than thinking if it could be worth to re-think the entire thing (for simple kdegames of course). We have a handful spare-time developers on a codebase of 260 KLOC, and you're asking to switch languages? No, thanks. As I said numerours times, I really like the idea behind Qt Quick and QML. And I agree that many things can be done in JavaScript very well. But we're talking about existing code here. So there must be a huge improvement if you want us to just consider using JS for the game logic. But there is no improvement: It's not faster, it's not simpler (just because of a direct port to JS), but on the other hand the bug will definitely introduce regressions. That hasn't to do with the quality of the involved technologies and/or people, it's simple math for N = 260 KLOC. My point is, you should stop wondering about people who have never used Qt Quick complaining about Qt Quick if you tell people to rewrite their business logic in JS. Of course these are not your exact words, but many people seem to take it like this, and in some way I understand them. Greetings Stefan ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On Monday 10 Oct 2011 8:17:19 AM Alexis Menard wrote: Beurk this thread is just about people ranting never tried to use QML or thought about using it as a real alternative or don't even let time for the technology to mature. I write down this date and we will see in 1-2 years when QML will spread a bit, when Qt Components will be mature and released. C++/QML lives very well together, you can almost do all your ugly hack in C++ that you have in your code. Custom painting - custom items that you export so you can use them in QML. 4 years ago you guys ranted about QGraphicsView, it matured, it's stable (It has its flaws for sure) and now many people use it, work on it and have stuff based on it. N9 UI, Plasma, and many more. Half of this thread is FUD. Of course if you don't want to change any of your code and expect to get Qt5 for free, this is not going to happen like almost any of major upgrades. Now for the ease of the move QWidget was let as a separate library which is good. You can move to QML when you feel QML is ready for your project. I want to change my code eventually. I just don't know how! Maybe the one thing that can help most the transition is if QtComponents were soon released and most if not all the QWidget/QGrapicsView based examples and demos were ported to QML. That would give the C++ people (such as myself) a clear idea of how something that is done in C++ can now be done in QML. -- Cheers! Kishore ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
Most of letters from nokia developers that says that QML is great technology mention mobile platforms. Guys, there is NO mobile platforms with Qt… ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On 10/10/2011 09:42 AM, ext Adriano Rezende wrote: On Sun, Oct 9, 2011 at 11:32 AM, Uwe Rathmannuwe.rathm...@tigertal.de wrote: On Sun, 09 Oct 2011 12:35:12 +0200, Peter Kümmel wrote: Maybe it isn't that bad in Qt because only the GUI is implemented in QML, business logic could still be C++. Yes and it looks like the idea of having different teams with different skills for these tasks ( something I don't believe in, because for non developers QML isn't easy enough ). I have to disagree, some designers are already using QML/JS for prototyping instead of Flex. In fact this designers and programmers working together meme was my first motivation to try Qt Quick myself instead of believing nice slides Henrik Hartz. ;) Now I'm designing functional and decent looking UIs without any prior (or current) C/C++ knowledge, and not even decent JS knowledge. I work with Michael Hasselman (also in this list) in http://miniature-chess.org , a mobile chess app. He is a real programmer while I'm not even a real designer. He takes care of the backend in C/C++ and I take care of the UI in QML, leaving some hooks in the code for each other. It's working very well! Before QML my chances of actually contributing any code were... very thin. Check http://flors.wordpress.com/2011/08/25/how-quick-i-got-started-with-qt-quick/ if you are interested in the full story. -- Quim ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On 10/10/2011 09:58 AM, ext Иван Комиссаров wrote: Most of letters from nokia developers that says that QML is great technology mention mobile platforms. Just in case you missed it, the opener of this thread expressed his concerns on QWidget vs QML in mobile platforms - and this is the topic of this thread: On 10/06/2011 10:14 PM, ext Daniel Mendizabal wrote: But what happen now when new mobile phones come with Qt5 without QWidget support? -- Quim ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
Qt is _not_ used for mobile development as i see. In fact, i agree that QWidgets are bad there. But main use-case for qt framework is desktop. Lot of arguments was about limitations of qwidgets and one of the example was mac style. First produce next billion devices (that would be sold), than let us your managers use nokia phones (Green still uses IPhone?), that we talk about mobile development. Not to be rude, i just don't share your optimism about mobile development with Qt. Development of new technologies is great, but do not break main and only place Qt works on - desktop platforms. 10.10.2011, в 21:12, Quim Gil написал(а): On 10/10/2011 09:58 AM, ext Иван Комиссаров wrote: Most of letters from nokia developers that says that QML is great technology mention mobile platforms. Just in case you missed it, the opener of this thread expressed his concerns on QWidget vs QML in mobile platforms - and this is the topic of this thread: On 10/06/2011 10:14 PM, ext Daniel Mendizabal wrote: But what happen now when new mobile phones come with Qt5 without QWidget support? -- Quim ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On Monday, 10 de October de 2011 20:58:11 Иван Комиссаров wrote: Most of letters from nokia developers that says that QML is great technology mention mobile platforms. Guys, there is NO mobile platforms with Qt… I think your definition of no platforms is quite a bit restrictive. I've just paid 4490 kr for a mobile with Qt. If you are right, the box I'll receive in the mail will be empty. You probably meant no platforms I care about. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
Be realist, people that get paid to work on Qt mostly get paid with the expectation that Qt will deliver on mobile. Expecting anyone to not care about mobile use cases is not going to fly here. On 10/10/11 8:27 PM Иван Комиссаров wrote: Qt is _not_ used for mobile development as i see. In fact, i agree that QWidgets are bad there. But main use-case for qt framework is desktop. Lot of arguments was about limitations of qwidgets and one of the example was mac style. First produce next billion devices (that would be sold), than let us your managers use nokia phones (Green still uses IPhone?), that we talk about mobile development. Not to be rude, i just don't share your optimism about mobile development with Qt. Development of new technologies is great, but do not break main and only place Qt works on - desktop platforms. 10.10.2011, в 21:12, Quim Gil написал(а): On 10/10/2011 09:58 AM, ext Иван Комиссаров wrote: Most of letters from nokia developers that says that QML is great technology mention mobile platforms. Just in case you missed it, the opener of this thread expressed his concerns on QWidget vs QML in mobile platforms - and this is the topic of this thread: On 10/06/2011 10:14 PM, ext Daniel Mendizabal wrote: But what happen now when new mobile phones come with Qt5 without QWidget support? -- Quim ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
2011/10/10 Adriano Rezende adriano.reze...@openbossa.org: On Mon, Oct 10, 2011 at 6:39 AM, Stefan Majewsky stefan.majew...@googlemail.com wrote: On Fri, Oct 7, 2011 at 9:13 PM, lars.kn...@nokia.com wrote: Putting QWidgets on top of/inside the scene graph is doable without performance regressions. We haven't done it though. Personally, I consider such an effort top priority if you want people to migrate from QtWidgets to Qt Quick 2. At kdegames, we have 40 applications which are nearly all based on QGraphicsView. Reality is that GUI and logic are not separated properly; the views, scenes and items contain most of the logic. It's simply not feasible to start porting these towards a scene-graph-based interface unless there is a way to embed the QGraphicsView into the chrome provided by Qt Quick 2. Supporting QWidget or QGV on top of QtQuick2 would be a huge mistake IMO. It would be a political movement that will not end up well in the long term. If one wants to use QML, they must use it in the right way, avoiding creating a Frankestein application. We already suffered with QGraphicsProxyWidget for no real gain. QtQuick2 needs to provide all features to support all the real use cases without creating a bridge/portal that could summon old demons. But that's the only sane and feasible way of porting big QWidget-based applications to QML. One would do it iteratively, for example, top-down, first putting the whole QMainWindow into QML context, then start rewriting different parts of it in QML. I guess it's quite obvious that this way is much better, much more manageable, doable by small opensource teams, feasible for more-or-less mature projects, and such. -- Georg Rudoy LeechCraft — http://leechcraft.org ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On Monday, 10 de October de 2011 21:27:42 Иван Комиссаров wrote: Qt is not used for mobile development as i see. In fact, i agree that QWidgets are bad there. But main use-case for qt framework is desktop. Lot of arguments was about limitations of qwidgets and one of the example was mac style. First produce next billion devices (that would be sold), than let us your managers use nokia phones (Green still uses IPhone?), that we talk about mobile development. Not to be rude, i just don't share your optimism about mobile development with Qt. Development of new technologies is great, but do not break main and only place Qt works on - desktop platforms. Once and for all: * QWIDGETS ARE NOT BEING REMOVED * WE WANT QML TO WORK ON THE DESKTOP, with desktop use-cases * You don't get to tell people what they work on. That's the principle of Open Source. That leads to: * If you want something to happen, convince someone to do it by arguments or do it yourself. The arguments don't seem to be convincing anyone. The people who have been developing QWidget for 15 years are telling you it's at its limit. They don't want to continue evolving it. This thread has gone on long enough. People's tempers are flared to the point that some emails have no sense at all. We're rehashing the same arguments over and over again. I will not reply to any more emails on it and hopefully the thread will eventually die. It's also going on KMail's auto-ignore feature. (btw, did anyone say Kontact Touch is a complex app mixing QML and C++?) -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
2011/10/10 Kishore Jonnalagadda kitts.mailingli...@gmail.com: On Monday 10 Oct 2011 8:17:19 AM Alexis Menard wrote: Beurk this thread is just about people ranting never tried to use QML or thought about using it as a real alternative or don't even let time for the technology to mature. I write down this date and we will see in 1-2 years when QML will spread a bit, when Qt Components will be mature and released. C++/QML lives very well together, you can almost do all your ugly hack in C++ that you have in your code. Custom painting - custom items that you export so you can use them in QML. 4 years ago you guys ranted about QGraphicsView, it matured, it's stable (It has its flaws for sure) and now many people use it, work on it and have stuff based on it. N9 UI, Plasma, and many more. Half of this thread is FUD. Of course if you don't want to change any of your code and expect to get Qt5 for free, this is not going to happen like almost any of major upgrades. Now for the ease of the move QWidget was let as a separate library which is good. You can move to QML when you feel QML is ready for your project. I want to change my code eventually. I just don't know how! Maybe the one thing that can help most the transition is if QtComponents were soon released and most if not all the QWidget/QGrapicsView based examples and demos were ported to QML. That would give the C++ people (such as myself) a clear idea of how something that is done in C++ can now be done in QML. I support this idea. Moreover, some documentation/tutorials/exampls regarding porting typical C++/QWidget-based code to QML would be very helpful. So would be something that describes general philosophy of QML for QWidget-users. Trolls' documentation was always excellent, it'd be nice if it'd be also the case with porting from old, mature and well-known technologies to newer ones like QML. -- Georg Rudoy LeechCraft — http://leechcraft.org ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On Mon, 10 Oct 2011 20:05:21 +0200, Иван Комиссаров abba...@gmail.com wrote: But i need bug fixes. Bugs that i reported to Qt bug tracker about TWO YEARS old, some of them with high priority. Even merge requests are waiting for weeks to be reviewed. This is something I think isn't good. At least the merge requests should be handled properly. Hopefully the contribution flow changes are going to clear the way for people to actively develop on QtWidgets. So please, stop developing that cool stuff for developing 100line applications and fix what you have already done. Don't tell them to stop looking forward. Even though the work on the old stuff has to be done, you still need to accept that Qt has to move forward and that takes work. This whole thread ended up with a lot of people venting frustration about everything and nothing. It all seems to boil down to something that is entirely not related to Qt5 -- people think the priorities are wrong. I do agree with Thiago that if you want something done, you need to do it yourself or get someone else to do it for you. If, however, the 'do it yourself'-part is done, but the results are ignored, there isn't much use in doing it yourself. Ah well, that's a different discussion I guess. Cheers, Frans ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On Mon, Oct 10, 2011 at 2:52 PM, Georg Rudoy 0xd34df...@gmail.com wrote: 2011/10/10 Adriano Rezende adriano.reze...@openbossa.org: Supporting QWidget or QGV on top of QtQuick2 would be a huge mistake IMO. It would be a political movement that will not end up well in the long term. If one wants to use QML, they must use it in the right way, avoiding creating a Frankestein application. We already suffered with QGraphicsProxyWidget for no real gain. QtQuick2 needs to provide all features to support all the real use cases without creating a bridge/portal that could summon old demons. But that's the only sane and feasible way of porting big QWidget-based applications to QML. One would do it iteratively, for example, top-down, first putting the whole QMainWindow into QML context, then start rewriting different parts of it in QML. I know that it would give you faster results but it would also lead to a very bad/ugly integration since both worlds have different ways to expose their features; a different architecture would also be required for a QtQuick application. If source quality must be preserved, a bottom-up approach would be better, since the critical parts resides in the development of the custom widgets that cannot be created using pure QML. Br, Adriano ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On Mon, Oct 10, 2011 at 4:06 PM, Uwe Rathmann uwe.rathm...@tigertal.de wrote: On Mon, 10 Oct 2011 13:42:11 -0300, Adriano Rezende wrote: I have to disagree, some designers are already using QML/JS for prototyping instead of Flex. Kudos to all of these designers. In my daily work ( http://www.fendt.com/us/tractors_variotronic.asp ) we are supported by a designer team who made a beautiful design concept. But they are artist - very far away from any programing. Yes, they are artists. They just need minimal programming skills to provide a good prototype. The quality of their source code is irrelevant since in a real product the final code would be reviewed/rewritten by real developers. The advantage here, is that they work with final technology and they are bounded to its limitation. Their widgets/screens could be used temporarily during the application development so the developers could focus on the critical parts letting the UI refinements/optimizations for later stage. On the Qwt support channels I see a completely different group of users with limited programming skills: engineers and scientist. Maybe QML would help them - but I'm not sure as they have to write the rest of the application in C++ anyway. I will try to offer an optional QML API for Qwt 7 ( even if the Qwt community will hit me for another major redesign ) and let them decide. I think a QML API for Qwt would be great. Recently I had to create QML widgets for Histograms and PieCharts in a desktop project. If a library was already provided I would use it. Br, Adriano ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On 10.10.2011 22:22, Frans Klaver wrote: people think the priorities are wrong. That's the point: Priority for Desktop is very low at Nokia. We all see it, feel it, any many old-school desktop develors don't like it. Peter ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
2011/10/11 Adriano Rezende adriano.reze...@openbossa.org: On Mon, Oct 10, 2011 at 2:52 PM, Georg Rudoy 0xd34df...@gmail.com wrote: 2011/10/10 Adriano Rezende adriano.reze...@openbossa.org: Supporting QWidget or QGV on top of QtQuick2 would be a huge mistake IMO. It would be a political movement that will not end up well in the long term. If one wants to use QML, they must use it in the right way, avoiding creating a Frankestein application. We already suffered with QGraphicsProxyWidget for no real gain. QtQuick2 needs to provide all features to support all the real use cases without creating a bridge/portal that could summon old demons. But that's the only sane and feasible way of porting big QWidget-based applications to QML. One would do it iteratively, for example, top-down, first putting the whole QMainWindow into QML context, then start rewriting different parts of it in QML. I know that it would give you faster results but it would also lead to a very bad/ugly integration since both worlds have different ways to expose their features; a different architecture would also be required for a QtQuick application. If source quality must be preserved, a bottom-up approach would be better, since the critical parts resides in the development of the custom widgets that cannot be created using pure QML. That's more of migration process details, I guess. Whether bottom-up or top-down, you'd still need to be able to have both QWidget-based stuff and QML-based stuff in your application. And, well, buggy/ugly integration is OK as long it is not a final result. I think there is just no way of porting a 200 kLOC application seamlessly, quickly and without much pain. Anyway, the more logic was separated from UI in the original app, the less changes should be made to the architecture. So one could split this into two parts: separate the logic and then change the UI to QML. -- Georg Rudoy LeechCraft — http://leechcraft.org ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
Op 10-10-2011 18:44, Adriano Rezende schreef: On Mon, Oct 10, 2011 at 6:39 AM, Stefan Majewsky stefan.majew...@googlemail.com wrote: On Fri, Oct 7, 2011 at 9:13 PM,lars.kn...@nokia.com wrote: Putting QWidgets on top of/inside the scene graph is doable without performance regressions. We haven't done it though. Personally, I consider such an effort top priority if you want people to migrate from QtWidgets to Qt Quick 2. At kdegames, we have 40 applications which are nearly all based on QGraphicsView. Reality is that GUI and logic are not separated properly; the views, scenes and items contain most of the logic. It's simply not feasible to start porting these towards a scene-graph-based interface unless there is a way to embed the QGraphicsView into the chrome provided by Qt Quick 2. Supporting QWidget or QGV on top of QtQuick2 would be a huge mistake IMO. It would be a political movement that will not end up well in the long term. If one wants to use QML, they must use it in the right way, avoiding creating a Frankestein application. We already suffered with QGraphicsProxyWidget for no real gain. QtQuick2 needs to provide all features to support all the real use cases without creating a bridge/portal that could summon old demons. I agree, QProxyWidget was a bit of a monster. But supporting the other route around: be able to seamlessly integrate Quick2 inside a QWidget based UI, so you can create custom widgets based on it. That would, IMHO, provide a feasable upgrade path. André ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
Hi, 2011/10/10 Иван Комиссаров abba...@gmail.com: But i need bug fixes. Bugs that i reported to Qt bug tracker about TWO YEARS old snip On Mon, Oct 10, 2011 at 10:31 PM, Peter Kümmel syntheti...@gmx.net wrote: We all see it, feel it, any many old-school desktop develors don't like it. Guys, you're preaching to the choir. The people participating in this mailing list, ahead of the open governance launch scheduled on October 17th. (http://labs.qt.nokia.com/2011/09/12/qt-project/) are just trying to help, and responses like these are *not* helping yourselves, your cause, or anyone else. Regarding Nokia's commitment to desktop support, it should be obvious by now that it is not a tremendous priority for them, but they do have some interest in keeping it working at least through projects like Creator - plus the larger developer community. This doesn't mean to say that you should rely on Nokia - you shouldn't. If you want a job done well, do it yourself, as the old adage goes. Regarding patches not getting review, and stuff - I know the frustration you're feeling, believe me, I do. I've been feeling it ever since I first joined #qt-labs and started following discussions/development, trying to get my own patches even remotely reviewed, let alone integrated. I've pretty much given up on that, for the time being waiting for October 17th. I've gotten so frustrated of all the crap, and all of the waiting that I've (privately) set up infrastructure with the intention of a community project forking Qt in past, but in the end, I went back to waiting, when things started to finally move along again. Hopefully the end to all this is coming, and we can look forward to the bright, happy days of patches being written and applied within the same year. ;) To get back to my point: Venting your frustrations on this list, to the software engineers working will not fix that for many reasons, which I'll omit for brevity at the moment, they'll simply discourage such talented folks from wanting to actively participate in this list, or worse still, in open governance itself - when it launches. These are *not* things we want to happen, the reasons for which should be obvious. Let's have a bit more patience and try keep it civil. All the best, Robin ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
Am i correct, that it wouldn't be possible to integrate QDeclarativeView into widget-based app in qt5? I already used such approach, was quite pretty. 11.10.2011, в 0:36, Andre Somers написал(а): Op 10-10-2011 18:44, Adriano Rezende schreef: On Mon, Oct 10, 2011 at 6:39 AM, Stefan Majewsky stefan.majew...@googlemail.com wrote: On Fri, Oct 7, 2011 at 9:13 PM,lars.kn...@nokia.com wrote: Putting QWidgets on top of/inside the scene graph is doable without performance regressions. We haven't done it though. Personally, I consider such an effort top priority if you want people to migrate from QtWidgets to Qt Quick 2. At kdegames, we have 40 applications which are nearly all based on QGraphicsView. Reality is that GUI and logic are not separated properly; the views, scenes and items contain most of the logic. It's simply not feasible to start porting these towards a scene-graph-based interface unless there is a way to embed the QGraphicsView into the chrome provided by Qt Quick 2. Supporting QWidget or QGV on top of QtQuick2 would be a huge mistake IMO. It would be a political movement that will not end up well in the long term. If one wants to use QML, they must use it in the right way, avoiding creating a Frankestein application. We already suffered with QGraphicsProxyWidget for no real gain. QtQuick2 needs to provide all features to support all the real use cases without creating a bridge/portal that could summon old demons. I agree, QProxyWidget was a bit of a monster. But supporting the other route around: be able to seamlessly integrate Quick2 inside a QWidget based UI, so you can create custom widgets based on it. That would, IMHO, provide a feasable upgrade path. André ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On Monday 10 October 2011 22:31:54 Peter Kümmel wrote: On 10.10.2011 22:22, Frans Klaver wrote: people think the priorities are wrong. That's the point: Priority for Desktop is very low at Nokia. We all see it, feel it, any many old-school desktop develors don't like it. I also see people who think QML is cool and productive, even on the desktop. So there. I think old-school developers will be surprised when they see that even the traditional desktop platforms kick into higher gear and start introducing new usage patterns that will feel strange for the old guard. Of course you can say Windows 8's Metro, Lion's gestures (and even touch interfaces in general) are gimmicks, but I guess then someone can also say C++ is a fad and real programmers use COBOL (this whole discussion reminds me of when I was migrating from DOS and was hitting walls with regard to graphics interfaces being seen as a fad - with similar arguments about performance and efficiency - and Clipper/DBase/FoxPro with Norton Commander said to be the only real way to use computers). Br, Attila___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On Mon, Oct 10, 2011 at 10:31 PM, Peter Kümmel syntheti...@gmx.net wrote: On 10.10.2011 22:22, Frans Klaver wrote: people think the priorities are wrong. That's the point: Priority for Desktop is very low at Nokia. We all see it, feel it, any many old-school desktop develors don't like it. Peter ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback That's why the OpenGovernance model is appealing to us. We can have people caring about the desktop, while Nokia isn't into it. And this someone can be you. Aleix ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On 08.10.2011 16:11, Thiago Macieira wrote: On Sunday, 9 de October de 2011 00:00:08 Daniel Mendizabal wrote: - Applications oriented to productivity, utilities, etc. with the only requirement to have the feel and look from the underlying OS and theme will also possibly need more complex routines and the classical approach (QWidget/C++) would be much more suitable. What data do you have to base your conclusion that QWidget / C++ is more suitable? Duck typing? Is there any mechanism in QML that guaranties that no run-time errors will happen when the QML script is interpreted? Qt5 will introduce static type checking for signal/slots-connects so no connect could fail at run-time. But with interpreting QML at run-time all the static checks of connects seems worthless when QML is used, because much more errors could be introduced by the QML script. Peter ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On Sunday, 9 de October de 2011 10:38:51 Peter Kümmel wrote: Duck typing? Is there any mechanism in QML that guaranties that no run-time errors will happen when the QML script is interpreted? Qt5 will introduce static type checking for signal/slots-connects so no connect could fail at run-time. But with interpreting QML at run-time all the static checks of connects seems worthless when QML is used, because much more errors could be introduced by the QML script. You seem to imply that any UI written in C++ will work out-of-the-box, regardless of the quality of the code written, just because the slot connections will error out at compile-time. I don't know, I think spending 30 minutes in the #qt channel on Freenode disproves that. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
Am Sonntag, 9. Oktober 2011, 11:31:30 schrieb Thiago Macieira: On Sunday, 9 de October de 2011 10:38:51 Peter Kümmel wrote: Duck typing? Is there any mechanism in QML that guaranties that no run-time errors will happen when the QML script is interpreted? Qt5 will introduce static type checking for signal/slots-connects so no connect could fail at run-time. But with interpreting QML at run-time all the static checks of connects seems worthless when QML is used, because much more errors could be introduced by the QML script. You seem to imply that any UI written in C++ will work out-of-the-box, regardless of the quality of the code written, just because the slot connections will error out at compile-time. That's not the point. The point here is that js is an interpreted language which means (as a simple example) a simple typo in the variable name can not be found until the project is actually executed. I spent a lot of time to throw a script language (tcl/tk) out of a project just to avoid this crap by replacing it with C++/Qt and now Qt introduce exactly the same... Christian Ehrlicher ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On 09.10.2011 11:31, Thiago Macieira wrote: On Sunday, 9 de October de 2011 10:38:51 Peter Kümmel wrote: Duck typing? Is there any mechanism in QML that guaranties that no run-time errors will happen when the QML script is interpreted? Qt5 will introduce static type checking for signal/slots-connects so no connect could fail at run-time. But with interpreting QML at run-time all the static checks of connects seems worthless when QML is used, because much more errors could be introduced by the QML script. You seem to imply that any UI written in C++ will work out-of-the-box, regardless of the quality of the code written, just because the slot connections will error out at compile-time. I never said that. Static connect only catches errors at compile times which apart from that would happen at run time. But I have the impression nobody wanna here any critic of QML. Seems all the Trolls have become SCRIPT-KIDDIES, which don't wanna see the advantage of static typed languages. But this already started with QVariant, with all the casting... Peter ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On 09.10.2011 12:16, Thiago Macieira wrote: On Sunday, 9 de October de 2011 11:49:48 Peter Kümmel wrote: But I have the impression nobody wanna here any critic of QML. Seems all the Trolls have become SCRIPT-KIDDIES, which don't wanna see the advantage of static typed languages. And it seems the critics here do not see the advantage of QML over C++. Back to my original question: Is it somehow possible to catch typos in QML variable names before running the app? Will QtCreator check it? Or is there already a tool? Both languages have their advantages and their disadvantages. Time will tell which one has the upper hand. Google already learned it. They plan to replace JS by Dart which will be a typed language. I assume most important is that such a language could be better optimized, but also for large projects such a language fits better. Maybe it isn't that bad in Qt because only the GUI is implemented in QML, business logic could still be C++. But it looks like Google has already learned the JS-lesson, and Nokia not. Peter My money is on the ease of making your UI in QML. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On 09.10.2011 11:41, Christian Ehrlicher wrote: Am Sonntag, 9. Oktober 2011, 11:31:30 schrieb Thiago Macieira: On Sunday, 9 de October de 2011 10:38:51 Peter Kümmel wrote: Duck typing? Is there any mechanism in QML that guaranties that no run-time errors will happen when the QML script is interpreted? Qt5 will introduce static type checking for signal/slots-connects so no connect could fail at run-time. But with interpreting QML at run-time all the static checks of connects seems worthless when QML is used, because much more errors could be introduced by the QML script. You seem to imply that any UI written in C++ will work out-of-the-box, regardless of the quality of the code written, just because the slot connections will error out at compile-time. That's not the point. The point here is that js is an interpreted language which means (as a simple example) a simple typo in the variable name can not be found until the project is actually executed. I spent a lot of time to That's exactly what I mean. throw a script language (tcl/tk) out of a project just to avoid this crap by replacing it with C++/Qt and now Qt introduce exactly the same... Christian Ehrlicher ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
It comes with a lot of tricky methods for something that was very simple before. And on top of the complexity there are some restrictions that I can foresee already: - Multi platform capability isn't as simple anymore: The inclusion of QML components for different platforms make that the source code needs to be changing to compile for MeeGo, Symbian, Linux, Windows or Mac platform every single time. The current Qt4 is as simple as changing the target in QtCreator and the application is compiled to the next OS without absolutely any change in your code. Are you saying that you usually deploy your C++ Qt desktop applications on mobile phones with no changes to the source code? And that you care about native look and feel? No ifdefs? Did you actually use the same .ui files? Qt never performed that magic and will not in the future. As for the desktop components. They will work and look just as native across the Mac, Windows and Linux desktop platforms. You can even use them on Symbian and Meego if you like. But combo box, group box, toolbars and tab widgets simply make no sense in that environment. If you are not willing to make any platform specific changes to your UI, you simply don't care about look and feel. - Some of the UI in my case are created dynamically either at compile time or at runtime. The former depending on the target platform and the latter depending on the device screen resolution. I don't see this possibility with QML. Why is that? The fact that the UI is declarative in nature does not mean that it is static or that you have to declare everything beforehand. That is a misconception. It is far easier to change the UI dynamically than it ever was with QWidget and .ui files. Qt Quick is actually designed precicely to target multiple resolutions. Did you have a specific use case in mind? Regards, Jens Bache-Wiig ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On Oct 9, 2011 4:12 PM, jens.bache-w...@nokia.com wrote: - Some of the UI in my case are created dynamically either at compile time or at runtime. The former depending on the target platform and the latter depending on the device screen resolution. I don't see this possibility with QML. Why is that? The fact that the UI is declarative in nature does not mean that it is static or that you have to declare everything beforehand. That is a misconception. It is far easier to change the UI dynamically than it ever was with QWidget and .ui files. Qt Quick is actually designed precicely to target multiple resolutions. Did you have a specific use case in mind? Just for my curiosity, how would a case like the following be handled in qml? My application in plugin based in which a pointer to a QWidget is returned by a factory in the plugin. The main program then adds the returned widget as a tab in a QTabWidget. About QML, I would like to see some ways to draw primitives like a dot, line, circle, spline etc. Cheers! Kishore Ps: I have no previous knowledge of interpreted languages and hence my question might just be a language related one. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On Sun, 9 Oct 2011 08:42:20 PM you wrote: It comes with a lot of tricky methods for something that was very simple before. And on top of the complexity there are some restrictions that I can foresee already: - Multi platform capability isn't as simple anymore: The inclusion of QML components for different platforms make that the source code needs to be changing to compile for MeeGo, Symbian, Linux, Windows or Mac platform every single time. The current Qt4 is as simple as changing the target in QtCreator and the application is compiled to the next OS without absolutely any change in your code. Are you saying that you usually deploy your C++ Qt desktop applications on mobile phones with no changes to the source code? And that you care about native look and feel? No ifdefs? Did you actually use the same .ui files? Qt never performed that magic and will not in the future. As for the desktop components. They will work and look just as native across the Mac, Windows and Linux desktop platforms. You can even use them on Symbian and Meego if you like. But combo box, group box, toolbars and tab widgets simply make no sense in that environment. If you are not willing to make any platform specific changes to your UI, you simply don't care about look and feel. - Some of the UI in my case are created dynamically either at compile time or at runtime. The former depending on the target platform and the latter depending on the device screen resolution. I don't see this possibility with QML. Why is that? The fact that the UI is declarative in nature does not mean that it is static or that you have to declare everything beforehand. That is a misconception. It is far easier to change the UI dynamically than it ever was with QWidget and .ui files. Qt Quick is actually designed precicely to target multiple resolutions. Did you have a specific use case in mind? The same code means just that, the same set of .cpp, .h and .ui files. No need to link to different libraries or make changes in my .pro. I have to use #ifdefs in the code to make the difference, but it is not a problem. I'm not expert in QML and I may be wrong in some comments, but instead of fighting back it would be more proactive to be guided to real examples for instance clarifying my doubts and possibly enforcing your point. As mentioned in my last email and to conclude this thread, I'm giving a real try to QML to develop a small and simple application using pure C++ so let's see how it works. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
Just one thing about autodesk they are releasing already their own version of qt which is NOT compatible with the standard version. I work for the big $$$ special fx industry and i can assure you we are all REALLY affraid Am 08.10.2011 02:42, schrieb craig.sc...@csiro.au: On 08/10/2011, at 6:07 AM, Harri Porten wrote: On Fri, 7 Oct 2011, craig.sc...@csiro.au wrote: Desktop apps won't be going away any time soon, and there are some rather big commercial companies who would likely make some noise if Qt on desktop was being neglected. Were and how will they make that noise? Remember that Nokia has freed themselves of the commercial Qt sales and support business. That freedom is now being used for experiments with new approaches. There are service providers for classic QWidget-based programming but when it comes to new developments the market still has to be established. Hi Harri, I understand why you might also have some interest in this area (we are one of your customers!). Since I have no affiliation with Autodesk, I don't want to speculate on any specifics here. My point is more that Autodesk obviously made a business decision to rewrite Maya to be based on Qt, specifically its QWidgets. They surveyed their community of plugin developers more than once to gauge interest before they did this and since they went ahead with it, one can assume they deemed it worth the effort. Should they encounter problems with Qt's QWidgets where those problems have a strong negative impact on their product, they will simply have to find a way to address them. Being a big company (hence more $$$ and manpower), they should have more options open to them than a smaller business might. Whether they would find working through Digia to be the most effective or whether they engage with the wider Qt development community more actively, my main point is that their n eed to keep their customers happy will drive them to find a solution. And they should have the means to do so. Currently, they rely on the LGPL version of Qt and they make available all their customisations on their website. Their community of plugin developers also rely on the LGPL version as a consequence. One would hope that the rest of the Qt community would benefit from any steps Autodesk found they had to take. I'm just using Autodesk as one example here, purely because I'm more familiar with them (we are part of the community of plugin developers for Maya). I don't want to distract from the main discussions on this list. I was more hoping to simply point out that there are plenty of companies that rely on Qt's current QWidget functionality. For those who can't or don't want to change from QWidget in the medium term, there will be a collective need to see the QWidget-based capabilities maintained at least at some modest level. Those with the deeper pockets are probably more likely to have more options. -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
Op 7-10-2011 10:47, Petr Vanek schreef: On Oct 7, 2011 (Friday), at 10:26 AM, Yves Bailly wrote: Hello all, Le 07/10/2011 09:49, Olivier Goffart a écrit : On Friday 07 October 2011 15:14:33 Daniel Mendizabal wrote: [...] The question is if it this is a good thing to spend time on QWidget. Another question - and sorry if it's stupid, my knowledge of QML is currently close to nothing: can QML handle highly dynamic interfaces? I mean, interfaces build dynamically at runtime. I have a pair of apps like this, in which almost everything is created by hand according to what is contained in a database. Almost nothing can be predefined at coding- or compile-time. Is QML suited in such cases? yes, I'd like to know it too. I tried to find some more complex QML application to see how there can be implemented something like we have in various applications (many-level-inheritance, DB populated widgets, custom painting using 3rd party libs etc.) but I found only simple one day to make apps (with all respect to authors). Some overview for large apps would be really appreciated now to reduce our fears... For one, some KDAB-ians made a Quick version of Kontact, the KDE suite of email, calendar and similar applications. That is not a trivial application at all. André ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
Note that you can keep your Qt backend intact and plug it to a QML UI with relative ease. This is probably a good idea for mobile apps based on Qt 4 already. I have been reading about using C++ with QML UI, but I don't find it straight forward at all. And the reason is simple, Qt project is focusing to change C++ to java in the future, so I assume that only a minimum effort will be invested in making C++ an alternative to code for QML. I chose Qt because of C++ centralization. I have no intention to change and use Java. Any improvement to the graphic system and the UI design should be also well supported for applications written in pure C++ without having to touch the QML file. Same as we were used to before with the .ui files which were created automatically by QtDesigner and I never had to bother changing anything inside or even opening the file to study the structure. Going forward, the procedure to use QML in C++ environment that I've been analyzing is: - Changing the inherited class QWidget to QDeclarativeView for each window and load the UI using setSource(file.qml). The latter would replace setupUI(this). - Act on the children of this window with: findChildQObject*(children)-setProperty(..) - Receive signals from the children of this windows connecting QML signals with handlers inside the C++ class. It comes with a lot of tricky methods for something that was very simple before. And on top of the complexity there are some restrictions that I can foresee already: - Multi platform capability isn't as simple anymore: The inclusion of QML components for different platforms make that the source code needs to be changing to compile for MeeGo, Symbian, Linux, Windows or Mac platform every single time. The current Qt4 is as simple as changing the target in QtCreator and the application is compiled to the next OS without absolutely any change in your code. - Some of the UI in my case are created dynamically either at compile time or at runtime. The former depending on the target platform and the latter depending on the device screen resolution. I don't see this possibility with QML. Conclusion: Many people think that making this change and moving to a declarative language will be a boost for the framework in the future. I don't want to stop the progress, but you need to understand that there are two type of applications: - Applications that need to maximize user experience with animation, colors booms and flash here and there to catch your interest. Which I agree would be difficult to develop with the classical approach and therefore the flexibility of QML is very welcome. However, it should be possible to use the QGraphics framework, but it is another story. - Applications oriented to productivity, utilities, etc. with the only requirement to have the feel and look from the underlying OS and theme will also possibly need more complex routines and the classical approach (QWidget/C++) would be much more suitable. - You don't have to tell me again, I know that Qt project isn't going to have QWidgets as part of the core modules. But fortunately they are still part of the add-on libraries for all desktop platforms. I just want to SCREAM OUT that are developers requiring this API also for mobile platforms (Symbian, MeeGo, Android,...) so if potential maintainers are subscribed in this mail-list be confident that you will have many followers. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On Sunday, 9 de October de 2011 00:00:08 Daniel Mendizabal wrote: - Applications oriented to productivity, utilities, etc. with the only requirement to have the feel and look from the underlying OS and theme will also possibly need more complex routines and the classical approach (QWidget/C++) would be much more suitable. What data do you have to base your conclusion that QWidget / C++ is more suitable? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On Sat, 08 Oct 2011 16:11:38 +0200, Thiago Macieira wrote: What data do you have to base your conclusion that QWidget / C++ is more suitable? I can follow the argumentation for using the scene graph instead of QWidget because of technical limitations. But introducing QML instead of C ++ is a completely unrelated decision and it's not valid to argue for QML because of the scene graph - like it is not valid to argue for QWidget because of C++. The question what programming language is more suitable is a matter of taste to a certain degree. Developers who are used to work with Qt/C++ will hate to learn/use something else ( read Olivers comments ) - others might love it, because they hope not having to invest in learning about C+ + or software development at all. Fighting about which group is the majority is IMHO pointless - both groups are relevant. And the success of Qt5 will depend on how far it will support both. Uwe ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On Friday 07 October 2011 15:14:33 Daniel Mendizabal wrote: To All, [...] Hi, But what happen now when new mobile phones come with Qt5 without QWidget support? I wonder how the message could have been given so wrong. I'm not speaking for the Qt team. But while Qt team thinks QML is the technology to use in the future for interface and will spend all its development power in it, they aknoweldge that is is currently not yet ready for all uses. That mean that QWidget is NOT going away. It is not removed. It will stay. It is just that it will stay in maintainence mode, and not get many new features. All existing projects based on this technology currently in OVI store or private clients will stop working from one day to the other? No, as stated, QWidget stays. When I started with Qt, I read about the promise to keep source and binary compatibility across the releases, what happen with this promise? The promise is between minor releases, Qt5 is a major release, there is no compatibility promise at all. Qt 4.0 was a massive source compatibility break to previous version. But in comparison, in Qt 5.0, the source compatibility changes will be limited to the minimum This promise was and still is reinforced by Nokia's marketing statement: Qt allows you to write advanced applications and UIs once, and deploy them across desktop and embedded operating systems without rewriting the source code saving time and development cost So it will be with QML I want to clarify that I'm not against QML/JavaScript, it could be an interesting approach to bring more (Java) developers into the pool. But I don't think, this is a fair and responsible decision from Qt's board to leave so many developers and current projects in the situation described above. I hope there is still room for changes and QWidgets classes are finally included for mobile platforms in Qt5. Because porting existing and complex applications with thousands of lines of code which have been optimized for so long with bug fixes and upgrades would be economically not interesting nor I could have the heart to re-do all my work again. Qt5 is opensource, and merge requests are accepted. And you might have seen Nokia's plan to open the develoment process even more. That means if you or anyone else still interrested in QWidget want to add feature, they still can. The question is if it this is a good thing to spend time on QWidget. On the other hand, what happen with the users who purchased these applications from OVI store? Will they loose them as soon as their devices are upgraded to Qt5...? The symbian devices are not going to be upgraded to Qt5. And if Qt5 comes on those devices, it will be in addition to Qt4. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
Hello all, Le 07/10/2011 09:49, Olivier Goffart a écrit : On Friday 07 October 2011 15:14:33 Daniel Mendizabal wrote: [...] The question is if it this is a good thing to spend time on QWidget. Another question - and sorry if it's stupid, my knowledge of QML is currently close to nothing: can QML handle highly dynamic interfaces? I mean, interfaces build dynamically at runtime. I have a pair of apps like this, in which almost everything is created by hand according to what is contained in a database. Almost nothing can be predefined at coding- or compile-time. Is QML suited in such cases? Regards, -- /- Yves Bailly - Software developper -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On Oct 7, 2011 (Friday), at 10:26 AM, Yves Bailly wrote: Hello all, Le 07/10/2011 09:49, Olivier Goffart a écrit : On Friday 07 October 2011 15:14:33 Daniel Mendizabal wrote: [...] The question is if it this is a good thing to spend time on QWidget. Another question - and sorry if it's stupid, my knowledge of QML is currently close to nothing: can QML handle highly dynamic interfaces? I mean, interfaces build dynamically at runtime. I have a pair of apps like this, in which almost everything is created by hand according to what is contained in a database. Almost nothing can be predefined at coding- or compile-time. Is QML suited in such cases? yes, I'd like to know it too. I tried to find some more complex QML application to see how there can be implemented something like we have in various applications (many-level-inheritance, DB populated widgets, custom painting using 3rd party libs etc.) but I found only simple one day to make apps (with all respect to authors). Some overview for large apps would be really appreciated now to reduce our fears... petr ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On 10/7/11 11:18 AM, ext Yves Bailly yves.bai...@sescoi.fr wrote: Le 07/10/2011 10:48, lars.kn...@nokia.com a écrit : On 10/7/11 10:26 AM, ext Yves Baillyyves.bai...@sescoi.fr wrote: [...] Is QML suited in such cases? It's most likely better suited for the task then QWidgets. Only problem could be if you need some functionality that we don't support in QML yet. Well, I need pretty everything QWidget-based classes provide, and a bit more... Combos, stacks and tabs, lists, tables and trees (model-based or not, some items may be full widgets), splitters, groups, some delegates here and there... even a checkbox or a label sometimes ;-) Not talking about layouts of course. All of this being build and filled dynamically at runtime. Now if QML is said to be better suited for such cases, then maybe I should find some hours (days?) to really learn it. Well, right now some of the functionality that you mention above is still missing. We'll get there eventually. But it is most likely easier to create a UI dynamically than with QWidgets. Cheers, Lars ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
[Accidentally sent in private to wrong recipient, so here again] 2011/10/7 Daniel Mendizabal dan...@darhon.com: ... But what happen now when new mobile phones come with Qt5 without QWidget support? So I want to give my opinion about the QWidget vs QML discussion as well. I already apologise for this lengthier post of mine, but I followed several discussions with great interest - and concern. For the actual question here: the answer has already been given: QWidgets won't disappear. Period. At least not in Qt 5. Your Qt 4 code will most likely compile on Qt 5 as before, as the promise is that the transition Qt 4 to Qt 5 is supposed to be much less painful than it was in some cases for Qt 3 to 4. And that's that. Now let me focus on some concerns of mine. A couple of months ago my impression was that QML will live happily in parallel to QWidgets. They are implemented in a separate module, they link to their own required libraries, but that wouldn't concern me at all as a QWidget desktop application programmer. I would still happily link to my QtGui which would sit on top of some low-level QPainter-based libraries, which might also be used or not by the QML stack. So I don't want to use it, I don't have to use it. But recently it turned out that the whole paint stack, the scene graph, will be completely rewritten, to favour the QML architecture. And it turns out that for all these fancy effects we now need OpenGL support to get any descent performance. And what's more, the whole QWidget implementation will sit on top of all that. So in the worst case I will have to link against all these JavaScript engine and what-not libraries, just to display a Hello World in a QLineEdit, implemented as some QML element in the background, interpreted by some JavaScript engine, rendered by some OpenGL stack... but nicely shaded maybe (which by the way I don't want at all, as I want my QLineEdit look exactly as the native one!). So QWidget has clearly become 2nd class and with regards to performance we have to take what's left for us! At least that is my impression from some discussions I followed. So here are some points I'd like to throw in: - I don't want to use any JavaScript in my code! I chose Qt as a C++ framework for a reason! If I wanted to use a non-native language I'd chosen .Net or Java. I don't understand why everyone shouts Hooray! Now we can code our GUI logic in JavaScript!. And don't use also implies I don't want to link against any JavaScript library which I don't use. Why? Because I want to be able to debug my whole GUI logic with the same tools I develop my business logic! I don't want any artificial wrapper objects which map JS values to C++ values and vice versa. And even if my QWidget based classes would sit on top of this whole QML stack, running JavaScript under the hood I'd still suffer from performance loss. For sure I would not gain any performance! - I want performance! I have tested one of my 4.7.3 Qt applications on a 10 year old HP laptop running Windows 2000 on a Pentium III 600 MHz, 512 MByte RAM. Just for the fun of it. And it ran perfectly! The main window resized smoothly and overall GUI performance was very snappy. I am happy with this! And that is the benchmark I will refer to when testing any QWidget application on top of Qt 5. But with the current requirement that even the QWidget based apps now need OpenGL support that means I cannot even run my apps in a virtual machine such as VirtualBox on a Mac in a decent way (and yes, I AM cross-developing a lot in VirtualBox, for both Windows and Linux)! But even from a user perspective (I'd accept the argument that as a developer I should be able to invest into proper hardware) that means I am burning battery power of my laptop/tablet/phone each time the GPU starts cooking, simply because I resize my main window! Oh and yes, I also do OpenGL based applications, and I'd hate it to see the widgets taking away valuable GPU cycles and introducing locks by GL context-switching, simply because that damn button needs to have its drop-shadow rendered nicely! (Yes, I am aware that OS X for instance does nothing else - but Qt would again render ON TOP of that with its own GL context etc.). - I want native widgets! I want my application to look as natively as possible! Native, native, native! Can't repeat that enough. Even better: Use native widgets wherever possible (e.g. push buttons, drop-down boxes etc.). No rounded corners, no drop shadow, no textures where the OS window manager would not render them anyway! - I for sure don't want to hand-code any XML-like GUI files! We have Qt Designer for a reason! Editing GUI in a text file is sooo late century, you know! And if I want to programmatically define the GUI, then I want it to be blazing fast, means compiled. With a well-documented API, simple to use. Oh, we already have that, it's called Qt... I wouldn't mind if the Qt Designer would create QML files under the hood. Much
Re: [Qt5-feedback] Concern about removal of QWidget classes
Feels good to vent it out sometimes, huh? ;) I have some sympathy with some of your points, but I'll restrict myself to a couple of specifics. On 07/10/2011, at 11:27 PM, Till Oliver Knoll wrote: But with the current requirement that even the QWidget based apps now need OpenGL support that means I cannot even run my apps in a virtual machine such as VirtualBox on a Mac in a decent way (and yes, I AM cross-developing a lot in VirtualBox, for both Windows and Linux)! You are not alone with that combination! Actually, VirtualBox is just about there for OpenGL. It claims to support OpenGL 2.1 now, which theoretically should be sufficient for what Qt5 is aiming for. There's a small number of omissions which have been reported in their bug tracker, so if someone wants to push to have that bug addressed, you will probably have a viable VirtualBox option for OpenGL by the time Qt5 comes out. The bug ticket can be found here: https://www.virtualbox.org/ticket/8275 I know at this point it's already too late I guess, the QML-ification of Qt is already progressed to far. At least that had been my expectation half a year ago... and who knows, maybe I AM one of the very few people left trying to stick to the good old working technology, and desktop apps as we know them are dying out. Every application will bring along its own look and feel and usability concepts and that's what people want (or the developers at least)... then so be it! Desktop apps won't be going away any time soon, and there are some rather big commercial companies who would likely make some noise if Qt on desktop was being neglected. Consider Autodesk - they rewrote their Maya package to use Qt for their 2011 release. I can't see them switching to QML any time soon just after expending all that effort, the cost in terms of time and additional development would be hard to justify. Maya is also very heavily dependent on OpenGL and being what it is, interactivity and overall performance are both crucial to its success. Now consider that Maya is THE package for film special effects in the movie industry (read: big $$$) and hopefully that will give you some reassurance that you have some relatively heavy hitters who should be sharing some of your concerns. ;) -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On Fri, 7 Oct 2011 10:51:35 PM you wrote: Desktop apps won't be going away any time soon, and there are some rather big commercial companies who would likely make some noise if Qt on desktop was being neglected. Consider Autodesk - they rewrote their Maya package to use Qt for their 2011 release. I can't see them switching to QML any time soon just after expending all that effort, the cost in terms of time and additional development would be hard to justify. Maya is also very heavily dependent on OpenGL and being what it is, interactivity and overall performance are both crucial to its success. Now consider that Maya is THE package for film special effects in the movie industry (read: big $$$) and hopefully that will give you some reassurance that you have some relatively heavy hitters who should be sharing some of your concerns. ;) This is a good news to rise some hopes. In any case, I don't see any woouuh having QML components in desktop applications, unless you are doing games or some specific fancy app for teenagers. But for the regular purposes and specially for productivity applications the end user is expecting a native look and feel according to its platform and the chosen theme. Any other approach would be even annoying and possibly frustrating. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
Hi, On Fri, Oct 7, 2011 at 3:44 PM, Daniel Mendizabal dan...@darhon.com wrote: But for the regular purposes and specially for productivity applications the end user is expecting a native look and feel according to its platform and the chosen theme. Any other approach would be even annoying and possibly frustrating. Which is precisely the approach desktop components take. (http://labs.qt.nokia.com/2011/03/10/qml-components-for-desktop/) ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
Hi Till I'm taking your email as a vent and as a rant. And as such things go, it's full of assumptions based on mistaken facts. Let me see if I can correct some of them. On Friday, 7 de October de 2011 14:27:20 Till Oliver Knoll wrote: A couple of months ago my impression was that QML will live happily in parallel to QWidgets. They are implemented in a separate module, they link to their own required libraries, but that wouldn't concern me at all as a QWidget desktop application programmer. I would still happily link to my QtGui which would sit on top of some low-level QPainter-based libraries, which might also be used or not by the QML stack. That's more or less right and still remains so. But recently it turned out that the whole paint stack, the scene graph, will be completely rewritten, to favour the QML architecture. The Qt Quick stack was rewritten. Instead of Graphics View, it sits now on top of the Scene Graph. The QWidget stack wasn't changed. And it turns out that for all these fancy effects we now need OpenGL support to get any descent performance. And what's more, the whole QWidget implementation will sit on top of all that. So in the worst That's where you got it wrong. The QWidget implementation does not sit on top of the QML-based Scene Graph. It still uses the old backing store, to the point that there is a class called QBackingStore. The QWidget architecture is mostly unchanged. That's good and that's bad: on the good side, it means what used to work will continue to work. It was much less painful to make the migration to Qt 5 this way. On the negative side, however, it means it got *none* of the performance improvements that are going into the scene graph-based technologies. So here are some points I'd like to throw in: - I don't want to use any JavaScript in my code! You don't have to if you don't want, not now and not in the future. But in the future it might become harder to avoid it. If you can code your UI entirely on top of the scene graph without using the Qt Quick engine, you can. I chose Qt as a C++ framework for a reason! If I wanted to use a non-native language I'd chosen .Net or Java. I don't understand why everyone shouts Hooray! Now we can code our GUI logic in JavaScript!. And don't use also implies I don't want to link against any JavaScript library which I don't use. Because it's easier to use? Because designers can design the UI, instead of engineers? There are many reasons to use it. The fact that technologies like Python exist prove that there is a need for a simpler way of developing things. And the fact that C and C++ continue to be used means there's a need for native, bare-metal performance in some cases. We're trying to marry both. - I want performance! Ok, then you want OpenGL. You said you wanted performance, therefore you want OpenGL for your UI. You *cannot* get better performance for graphical things than to ask the GPU to do it for you the way the GPU does it best. I have tested one of my 4.7.3 Qt applications on a 10 year old HP laptop running Windows 2000 on a Pentium III 600 MHz, 512 MByte RAM. Just for the fun of it. And it ran perfectly! The main window resized smoothly and overall GUI performance was very snappy. I am happy with this! And that is the benchmark I will refer to when testing any QWidget application on top of Qt 5. Try going back to 4.4, before all the performance improvements targeting mobile were in place. But the point is: we believe we have reached the limits to what can be optimised in that architecture. More improvements require OpenGL support and require doing it the OpenGL way (retained state, like in the Scene Graph), not by bolting it under an imperative painter. No wonder the raster engine in Qt 4 is better than the OpenGL engine... But even from a user perspective (I'd accept the argument that as a developer I should be able to invest into proper hardware) that means I am burning battery power of my laptop/tablet/phone each time the GPU starts cooking, simply because I resize my main window! Yes. Fortunately, your GPU will be burning less battery power than the equivalent operation on the CPU. So you have a net gain in battery consumption. Do you really think that we'd be targeting OpenGL if it consumed more power? Remember who is the main backer of the new architecture and what kind of devices they sell. - I want native widgets! I want my application to look as natively as possible! Native, native, native! Can't repeat that enough. Even better: Use native widgets wherever possible (e.g. push buttons, drop-down boxes etc.). No rounded corners, no drop shadow, no textures where the OS window manager would not render them anyway! You're calling for two separate things there. You want either native, or you want no drop shadows and no rounded corners. If the native widgets have them, asking not to have them means having non-native widgets.
Re: [Qt5-feedback] Concern about removal of QWidget classes
On Friday 07 October 2011 14:27:20 Till Oliver Knoll wrote: [...] But recently it turned out that the whole paint stack, the scene graph, will be completely rewritten, to favour the QML architecture. The scene graph is a technology that has been writen specifically for QML, If you want to use it, you indeed need QML. But QPainter and QWidget stays there, and are not that bad. (QWidget can't use the scene graph because it has been designed for imperative programming (the way QStyle works)) And it turns out that for all these fancy effects we now need OpenGL support to get any descent performance. And what's more, the whole QWidget implementation will sit on top of all that. I am not sure you are correct. Don't confuse lighthouse and scene graph. QWindow (the replacement for top level widget) may indeed require OpenGL (to simplify the implementation) So in the worst case I will have to link against all these JavaScript engine and what-not libraries, just to display a Hello World in a QLineEdit, implemented as some QML element in the background, interpreted by some JavaScript engine, rendered by some OpenGL stack... but nicely shaded maybe (which by the way I don't want at all, as I want my QLineEdit look exactly as the native one!). No, as you stated before, if you do not want Javascript or QML, you don't link to it. There was a huge thread before regarding moving V8 (the javascript engine) to QtCore. But the result of this discussion is that this will not happen. QtV8 stays a separate library, and you don't need to link to it to use your QWidgets So QWidget has clearly become 2nd class and with regards to performance we have to take what's left for us! At least that is my impression from some discussions I followed. QWidget has some performence limitations in their design that are not possible to solve. This is why the scenegraph has been developed. And that will not work for QPainter and it's imperative drawing. Now, QWidget do not loose anything, it just stays behind, where it was. So here are some points I'd like to throw in: - I don't want to use any JavaScript in my code! [...] Qt5 is not a problem here. - I want performance! I have tested one of my 4.7.3 Qt applications on a 10 year old HP laptop running Windows 2000 on a Pentium III 600 MHz, 512 MByte RAM. Just for the fun of it. And it ran perfectly! The main window resized smoothly and overall GUI performance was very snappy. I am happy with this! And that is the benchmark I will refer to when testing any QWidget application on top of Qt 5. Please try it with the current development branch of Qt5. I see no reason why it would not work anymore. But with the current requirement that even the QWidget based apps now need OpenGL support that means I cannot even run my apps in a virtual machine such as VirtualBox on a Mac in a decent way (and yes, I AM cross-developing a lot in VirtualBox, for both Windows and Linux)! You should be able to use software randering. (llvmpipe) If you still use the plain widget as before without fancy effect, it should not be slower than the current raster engine. http://labs.qt.nokia.com/2011/05/31/qml-scene-graph-in-master/ But even from a user perspective (I'd accept the argument that as a developer I should be able to invest into proper hardware) that means I am burning battery power of my laptop/tablet/phone each time the GPU starts cooking, simply because I resize my main window! The GPU is optimized to do draw, it may uses less power than the CPU. Oh and yes, I also do OpenGL based applications, and I'd hate it to see the widgets taking away valuable GPU cycles and introducing locks by GL context-switching, simply because that damn button needs to have its drop-shadow rendered nicely! (Yes, I am aware that OS X for instance does nothing else - but Qt would again render ON TOP of that with its own GL context etc.). I can't answer to that. - I want native widgets! I want my application to look as natively as possible! Native, native, native! Can't repeat that enough. Even better: Use native widgets wherever possible (e.g. push buttons, drop-down boxes etc.). No rounded corners, no drop shadow, no textures where the OS window manager would not render them anyway! Even with QML, there is some work in the desktop componenent to do exactly that. - I for sure don't want to hand-code any XML-like GUI files! We have Qt Designer for a reason! Editing GUI in a text file is sooo late century, you know! And if I want to programmatically define the GUI, then I want it to be blazing fast, means compiled. With a well-documented API, simple to use. Oh, we already have that, it's called Qt... I wouldn't mind if the Qt Designer would create QML files under the hood. Much the same way I don't care about the actual content of the current UI files. As long as I would interface against a compiled C++ class in my own code! And there's
Re: [Qt5-feedback] Concern about removal of QWidget classes
On Fri, 7 Oct 2011 05:49:36 PM you wrote: But what happen now when new mobile phones come with Qt5 without QWidget support? I wonder how the message could have been given so wrong. I'm not speaking for the Qt team. But while Qt team thinks QML is the technology to use in the future for interface and will spend all its development power in it, they aknoweldge that is is currently not yet ready for all uses. That mean that QWidget is NOT going away. It is not removed. It will stay. It is just that it will stay in maintainence mode, and not get many new features. I might have misunderstood the message, but if you read the Qt5 - Road map it clearly states that QWidgets module will be a Qt Add On only for desktop platforms. In any case, I hope you are right and it was just an error of interpretation. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
I agree with all points you listed here. It would be great if some core Qt developers can provide more informations or let's say edification about this all is QML stuff. What does it improve - I mean *really* improve. Now it seems it's just less-doing another syntax for widgets. Maybe accelerated over GPU. But enforcing GPU acceleration blocks (as it was said) various virtualization tools etc. Then imagine that we chose Qt as a GUI toolkit for our product using it with special language bindings (smoke, etc.) and those tools sometimes run over network (X11) from old solaris machine... OK, maybe I'm fearing some non-existing problems but definitely it needs more evangelization. Now I feel like hey, QML works, it can paint button, throw away qwidgets, let's move all to qml... On Oct 7, 2011 (Friday), at 2:27 PM, Till Oliver Knoll wrote: A couple of months ago my impression was that QML will live happily in parallel to QWidgets. They are implemented in a separate module, they link to their own required libraries, but that wouldn't concern me at all as a QWidget desktop application programmer. I would still ... this is what I thought - it will stay forever and QML can be used for some quick development (still I cannot imagine myself that coding QML can be quick). cheers, petr P.S.: I don't mean this message as a rude or an un-polite scream... ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On Fri, 07 Oct 2011 14:11:57 +, Uwe Rathmann wrote: We all remember what was wrong with how Qt4 was introduced and I honor, that the developers take care, that this ... Of course I wanted to write: ... won't happen again with Qt5. Sorry, Uwe ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On Friday, 7 de October de 2011 18:34:46 Konstantin Tokarev wrote: 07.10.2011, 17:48, Thiago Macieira: The Qt Quick stack was rewritten. Instead of Graphics View, it sits now on top of the Scene Graph. The QWidget stack wasn't changed. So it will be possible to run old faithful QWidgets without having OpenGL ES 2? Yes. QWidgets will continue to paint to the backing store, which is QPainter- driven and has the old raster engine. Then you upload that image to the windowing server (or share it via shared memory), which will then take care of uploading to the GPU. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
Hi, On Friday 07 October 2011 15:48:22 Thiago Macieira wrote: That's where you got it wrong. The QWidget implementation does not sit on top of the QML-based Scene Graph. It still uses the old backing store, to the point that there is a class called QBackingStore. The QWidget architecture is mostly unchanged. Aha, interesting, and good to know. http://labs.qt.nokia.com/2011/05/09/thoughts-about-qt-5/ said the difference: QWidgets will be layered on top of the scene graph, that is probably where the confusion came from. Olivier said QWindow might require OpenGL though. Is QWindow a core Lighthouse class or something plugin-specific? I hope plugin-specific, there are still embedded platforms without OpenGL (and without a GPU, even), and I imagine the llvm pipe trick will not be as fast as the raster painting that is done right now. OT: The scene graph for QML sounds quite interesting, are there any blogs that compare performance between QML 1 and 2 already? I am especially interested what happens if the target platform doesn't have a GPU. Regards, Thomas smime.p7s Description: S/MIME cryptographic signature ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
Hi, On Fri, Oct 7, 2011 at 4:43 PM, Thomas McGuire thomas.mcgu...@kdab.com wrote: OT: The scene graph for QML sounds quite interesting, are there any blogs that compare performance between QML 1 and 2 already? I am especially interested what happens if the target platform doesn't have a GPU. This is at least one metric: http://labs.qt.nokia.com/2011/05/31/qml-scene-graph-in-master/ specifically: http://labs.qt.nokia.com/wp-content/uploads/2011/05/numbers.png ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
Hi, On Friday 07 October 2011 16:49:40 Robin Burchell wrote: On Fri, Oct 7, 2011 at 4:43 PM, Thomas McGuire thomas.mcgu...@kdab.com wrote: OT: The scene graph for QML sounds quite interesting, are there any blogs that compare performance between QML 1 and 2 already? I am especially interested what happens if the target platform doesn't have a GPU. This is at least one metric: http://labs.qt.nokia.com/2011/05/31/qml-scene-graph-in-master/ specifically: http://labs.qt.nokia.com/wp-content/uploads/2011/05/numbers.png Thanks for the links! I am surprised llvm is better than raster, great work of the scene graph guys :) Regards, Thomas smime.p7s Description: S/MIME cryptographic signature ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
Hi Daniel, In short, QWidget has probably a long life in the desktop but in mobile it's fading away fast already in Qt 4.7/4.8 since Qt Quick is just a lot better to obtain a good user experience. We are talking about the UI frontend only, in the backend your Qt code is just as good for any form factor. On 10/06/2011 10:14 PM, ext Daniel Mendizabal wrote: But what happen now when new mobile phones come with Qt5 without QWidget support? All existing projects based on this technology currently in OVI store or private clients will stop working from one day to the other? First note that one thing is the Qt Project (deciding e.g. what is supported in Qt 5) and another thing is Nokia or any other vendor shipping Qt enabled products (deciding what Qt versions and support they have for their products). On the other hand, what happen with the users who purchased these applications from OVI store? Will they loose them as soon as their devices are upgraded to Qt5...? Symbian Belle and MeeGo 1.2 Harmattan are the last Nokia releases shipping Qt libraries. They are based on Qt 4 and afaik there haven't been any announcements on upgrading them to Qt 5. As a matter of fact Nokia Developer has been insisting on the use of Qt Quick for mobile apps for a while now. For instance, in the Nokia N9 QWidget is not supported already. Would you mind pointing to your Qt apps in the Nokia store? Just curious and interested in thinking their best upgrade path to Qt 5 enabled products. You say they have a bunch of code behind but is all of it QWidget UI? Note that you can keep your Qt backend intact and plug it to a QML UI with relative ease. This is probably a good idea for mobile apps based on Qt 4 already. -- Quim Gil ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On Fri, 2011-10-07 at 09:55 -0700, Quim Gil wrote: Hi Daniel, In short, QWidget has probably a long life in the desktop but in mobile it's fading away fast already in Qt 4.7/4.8 since Qt Quick is just a lot better to obtain a good user experience. We are talking about the UI frontend only, in the backend your Qt code is just as good for any form factor. If only. Traditional widget-based code seems to always gravitate to implement business logic within (derived) widgets themselves. It just seems to be the natural way. Your business logic then also starts to depend on widget-specific behaviour. Actually, one of Qt's portability promises was that you did not have to worry too much about splitting your QWidgets from the rest of your (Qt) code – it would still run on all supported platforms. It seems that cutting the QWidget dependency can be rather painful for established projects. regards, Michael ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
Hello Thiago, hello everyone, I read all messages so far to this subject, but will reply to Thiago's message only for now. It kind of sums it up anyway very nicely. 2011/10/7 Thiago Macieira thi...@kde.org: ... And it turns out that for all these fancy effects we now need OpenGL support to get any descent performance. And what's more, the whole QWidget implementation will sit on top of all that. So in the worst That's where you got it wrong. The QWidget implementation does not sit on top of the QML-based Scene Graph. It still uses the old backing store, to the point that there is a class called QBackingStore. The QWidget architecture is mostly unchanged. Okay then, glad I misinterpreted this. As Thomas already mentioned, I had exactly this article in mind: http://labs.qt.nokia.com/2011/05/09/thoughts-about-qt-5/ May I quote that specific paragraph: QPainter will still be available and is very useful for many things, but it won’t be used for the main user interface. Qt will require OpenGL (ES) 2.0 to work. QWidgets will be layered on top of the scene graph (not the scene graph on top of QWidgets as is currently done with Qt 4). Now you tell me that QWidgets won't sit on top of the scene graph (which requires OpenGL ES etc.) and I take your word for it. My interpretation was different and based on that assumption my impression was that in Qt 5 the QWidget stack would be merely put on top of the new scene graph, dropping the QPainter approach altogether - with all the necessary additional libraries. I chose Qt as a C++ framework for a reason! ... Because it's easier to use? Because designers can design the UI, instead of engineers? There are many reasons to use it. The fact that technologies like Python exist prove that there is a need for a simpler way of developing things. Yes. Might be true for small applications, weather apps and sort of. Ok, then you want OpenGL. You said you wanted performance, therefore you want OpenGL for your UI. No. I want OpenGL to render MY stuff, and not getting into my way when rendering the GUI. I already mentioned that I am fully aware that these days window managers such as on Mac OS X, Windows 7 (Vista) also use OpenGL. But first off that's on an OS level, that is highly optimised, whereas the OpenGL rendering of Qt would be on top of that, in application land. The window manager would have no influence on optimising that (which I hope it does when painting its own widgets). Well anyway, my point is that performance for drawing a few buttons and rectangles is way enough available these days! Heck, we're talking GIGAHertz these days, not Megahertz! And updating the GUI in Qt was never a bottleneck for me. Again, I am talking about plain old desktop applications, with the look and feel of the underlying OS. You *cannot* get better performance for graphical things than to ask the GPU to do it for you the way the GPU does it best. Well, agreed. My point was more that it is not necessary for my desktop application needs. I fully agree with you that if you want to do MORE effects with QML, then yes, it might be necessary to have OpenGL support. But let's not ride on the performance issue for too long, my objections against QML are based more from a programming point of view anyway. ... each time the GPU starts cooking, simply because I resize my main window! Yes. Fortunately, your GPU will be burning less battery power than the equivalent operation on the CPU. So you have a net gain in battery consumption. ... under the assumption that the CPU is using less or no power at all in the meantime. Besides graphic performance is accelerated since Window 3.1, for instance no CPU is wasting CPU cycles when drawing a rectangle or a line! That's all being handled by dedicated chips on the normal 2D graphic card, and the same argument with less power also applies there I guess. So no, I don't think that using your GPU would actually consume LESS power than the combination CPU/2D graphic card. But let's not count watts here either ;) - I want native widgets! I want my application to look as natively as possible! You're calling for two separate things there. You want either native, or you want no drop shadows and no rounded corners. If the native widgets have them, asking not to have them means having non-native widgets. No, my point is a different one: I want native look and feel! If the native window manager decides to draw a nice shadow around every dialog, then so be it! If the native window manager decides to draw rounded corners around my main window - so be it! So I was NOT asking for no, I don't want to have drop-shadows or rounded corners, I was asking to have widgets which EXACTLY (as closely as possible at least) behave like the underlying window manager/OS would do! (And you can extend this to anything beyond drop-shadows and rounded corners: colour schemes, click-behaviour etc.) I don't know how we're going to implement
Re: [Qt5-feedback] Concern about removal of QWidget classes
On 10/07/2011 06:28 PM, ext Иван Комиссаров wrote: By the way, what about OpenGL painter backend? Can i enable it painting widgets in qt5? (last time i tried to use it, it had some painting bugs) We realized that getting the OpenGL paint engine to render widgets was not going to succeed, in part due to rendering quality issues (less perfect antialiasing, incorrect line / polygon rasterization), and in part due to performance (the imperative QPainter API _is_ more ideal for a software based paint engine than an OpenGL based one). So the OpenGL based window surface that we experimented with in Qt 4 has gone away. The Qt Quick 2 scene graph is the way of getting the best performance out of OpenGL. -- Samuel ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On 10/07/2011 07:29 PM, ext Till Oliver Knoll wrote: Hello Thiago, hello everyone, I read all messages so far to this subject, but will reply to Thiago's message only for now. It kind of sums it up anyway very nicely. 2011/10/7 Thiago Macieirathi...@kde.org: ... And it turns out that for all these fancy effects we now need OpenGL support to get any descent performance. And what's more, the whole QWidget implementation will sit on top of all that. So in the worst That's where you got it wrong. The QWidget implementation does not sit on top of the QML-based Scene Graph. It still uses the old backing store, to the point that there is a class called QBackingStore. The QWidget architecture is mostly unchanged. Okay then, glad I misinterpreted this. As Thomas already mentioned, I had exactly this article in mind: http://labs.qt.nokia.com/2011/05/09/thoughts-about-qt-5/ May I quote that specific paragraph: QPainter will still be available and is very useful for many things, but it won’t be used for the main user interface. Qt will require OpenGL (ES) 2.0 to work. QWidgets will be layered on top of the scene graph (not the scene graph on top of QWidgets as is currently done with Qt 4). Now you tell me that QWidgets won't sit on top of the scene graph (which requires OpenGL ES etc.) and I take your word for it. My interpretation was different and based on that assumption my impression was that in Qt 5 the QWidget stack would be merely put on top of the new scene graph, dropping the QPainter approach altogether - with all the necessary additional libraries. Yep, we were considering different options. In the end QWindow supports both QPainter based rendering with QBackingStore and OpenGL based rendering with QOpenGLContext. I chose Qt as a C++ framework for a reason! ... Because it's easier to use? Because designers can design the UI, instead of engineers? There are many reasons to use it. The fact that technologies like Python exist prove that there is a need for a simpler way of developing things. Yes. Might be true for small applications, weather apps and sort of. Ok, then you want OpenGL. You said you wanted performance, therefore you want OpenGL for your UI. No. I want OpenGL to render MY stuff, and not getting into my way when rendering the GUI. I already mentioned that I am fully aware that these days window managers such as on Mac OS X, Windows 7 (Vista) also use OpenGL. But first off that's on an OS level, that is highly optimised, whereas the OpenGL rendering of Qt would be on top of that, in application land. The window manager would have no influence on optimising that (which I hope it does when painting its own widgets). Well anyway, my point is that performance for drawing a few buttons and rectangles is way enough available these days! Heck, we're talking GIGAHertz these days, not Megahertz! And updating the GUI in Qt was never a bottleneck for me. Again, I am talking about plain old desktop applications, with the look and feel of the underlying OS. QPainter on Linux is using Xlib and Xrender, which was probably still accelerated by the GPU to some degree (pixmap blits, text rendering, etc). It's just that a lot of operations weren't supported so we have to fall back to QImage and do an expensive pixmap / texture upload. Thus, both the CPU and GPU are not really being used in the most efficient manner. It turned out that Xlib and Xrender was lacking as an abstraction for what the GPU is capable of, which is why we moved toward doing most of the rendering to a QImage and instead doing controlled uploads of the dirty areas of the window surface in the end, faster than having to read back data from a pixmap, do the rendering to a QImage, and re-upload the QImage for blending for individual paint commands. Still, using OpenGL efficiently is better for CPU (not a lot of rendering done there) and GPU usage (not doing a lot of texture uploads all the time). That's what the scene graph enables us to do. OpenGL is becoming ubiquitous these days, it's time to take full advantage of it. Since scene graph is using the GPU in a better way than traditional widgets, I doubt it would steal any performance from your more demanding OpenGL applications. ... each time the GPU starts cooking, simply because I resize my main window! Yes. Fortunately, your GPU will be burning less battery power than the equivalent operation on the CPU. So you have a net gain in battery consumption. ... under the assumption that the CPU is using less or no power at all in the meantime. Besides graphic performance is accelerated since Window 3.1, for instance no CPU is wasting CPU cycles when drawing a rectangle or a line! That's all being handled by dedicated chips on the normal 2D graphic card, and the same argument with less power also applies there I guess. So no, I don't think that using your GPU would actually consume LESS power
Re: [Qt5-feedback] Concern about removal of QWidget classes
Hi Till, good to know there are others who are skeptical about QML. But the QWidget time is over at Nokia. Someone else has to care about. I assume at Nokia the briefing is we will not waste any time or money for QWidget like stuff, someone else should do. But we are accustomed to rely on Trolltech/Nokia for Qt development. But this will change with the new development model. And hey, maybe in QtWidget not only crashes will be fixed, when a active maintainer could be found. Peter You're getting it. Just remember that the bugfixes won't be to little glitches on Mac. More likely, they will be for crashes or really ugly issues. Well that's too bad then that QWidgets won't be fixed anymore! At least not from Nokia, as it seems. Unless someone wants to take over maintainership and drive again development. That's my hope anyway. Remember that whoever wants to do this will have to keep the stability, so maintainership can be revoked if too many regressions are introduced and not fixed. In essence: we don't recommend doing this. Well, that's true for pretty much every development, also new one. So no reason to scare away people in fixing stuff. I am talking about that they are now placed on TOP of the QML stack, That's a mistaken assumption. They are not. Your word in my ears! And don't be mad, I highly appreciate the work being done, but still I think this whole QML desktop research is a waste of time! There is nothing to gain except what we have already now! And I am HAPPY what we have now! That's really offensive to the people doing it. I apologize. My frustration about loosing a GREAT Qt API was just letting go I assume. Again, I am not saying to drop QML! As long as it lives in PARALLEL to QWidgets and I don't ever have to use it (unless I want to), then I am PERFECTLY fine! But re-inventing the wheel when trying to do desktop development with QML (not QML itself!), so to speak, to come up with something we already have, but just with more bads than goods (OpenGL dependency, interpreted language under the hood, clumsy data exchange with JavaScript, ...)., that is a waste of precious resources! I mean you already hinted above that once you get on the scene graph train there's hardly any way around dealing with JavaScript. And that alone is a HUGE drawback for me! But let's see, maybe I am wrong. Don't tell me that in the future it will be so much easier to animate my buttons, have rounded corners, glossy shiny effects... if the window manager doesn't render that, I don't WANT that! Oh, but you're forgetting that the UIs of the future will be like that because customers are demanding it and others are driving it! So you want to keep your UIs as they are... Let's say you had kept them as they were 14 years ago. Here's what it looked like: http://www.linux-kongress.org/1997/kde_desktop.gif So let me summarise: we cannot stop innovating. No we can't. But also remember that the trend in UI is now in the OTHER direction again, towards SIMPLER and MINIMALISTIC ways of drawing stuff, see Mac OS X! The time of Hey, KDE can draw wobbly wobbly dialogs (but requires OpenGL support to do so) is long time over! And Qt just performs fine (with QWidgets!) on todays hardware, so why worry? ... You've got it. But it will stay as it is. Look at that link above again. Now place yourself in your 2016 shoes and look at your UIs of today. There will be more individually looking apps and I will still want to kick those people's butt for making apps which look different than my Windows or Mac or KDE? Thanks for those who actually read until here, and apologise again to those who skipped reading long time ago. ;) Unfortunately, you lost time writing all of that based on mistaken assumptions. If you had just taken the time to clarify first... No, my point still stands: as long as I can code with Qt 5 without touching any JavaScript/QML if I don't want to, I am perfectly happy! I had reasons to believe that I would not be able to do so, but you said otherwise. I have to take your word for that. But I gave valid reasons why I don't want to use QML and fancy UI design for desktop applications, both as a developer and a user! I gave a concrete example - the Adobe Flex one - and maybe placed it a bit too pointy, but bottom line is the performance there sucked big time(1) and the user experience, well: it just didn't fit into my Mac! Luckily it was a one time usage only... (1) I am not saying that I am comparing Flex vs QML, but it is the same paradigm and the same misuse potential is there. Have a nice week-end all! Cheers, Oliver ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com
Re: [Qt5-feedback] Concern about removal of QWidget classes
Am Freitag, 7. Oktober 2011, 20:32:13 schrieb Peter Kümmel: Hi Till, good to know there are others who are skeptical about QML. But the QWidget time is over at Nokia. Someone else has to care about. I assume at Nokia the briefing is we will not waste any time or money for QWidget like stuff, someone else should do. But we are accustomed to rely on Trolltech/Nokia for Qt development. But this will change with the new development model. And hey, maybe in QtWidget not only crashes will be fixed, when a active maintainer could be found. I fully agree... :( Christian ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On Friday, 7 de October de 2011 20:08:55 Samuel Rødal wrote: Agreed, animating stuff, drawing custom widgets etc. is indeed much easier in QML. But to repeat: I don't want to animate, I don't want custom widgets (and I am talking about the ordinary and typical user interface elements such as buttons, comboboxes, not about custom widgets such as graphs, stock tickers or what not). So all this doesn't bring me any value. It's not necessarily about glaring animations, rather of subtle fading etc (which granted can be done with QWidgets as well, but in a way that's less easy to experiment with and tweak for a designer). See the YouTube video in this blog post to see the possibilities: http://labs.qt.nokia.com/2011/03/10/qml-components-for-desktop/ Till, I think Samuel's words here are the issue that you're missing. The main message of your email seemed to be I can do my UI today with Qt 4, therefore I will be able to do that for the next 5 years. That strikes me as rather naïve... You're assuming that either: a) the UIs of 5 years from now will be remarkably similar to today's, so the needs in the architecture won't be too different b) the architecture is so impressive that it will be able to handle the requirements of UIs 5 years from now or c) the architecture will evolve and will be able to support the new UI requirements My sending of a screenshot of a Qt-based KDE screenshot of 14 years ago is to show that UIs change quite a lot. The change is constant, it's not one major change at a fixed point in time. And even if we could predict when exactly a new architecture needs to be ready, we still need to research, test, mature and productise this architecture. That's what Qt Quick is supposed to be: the foundation of our needs for a long time. Maybe we're wrong, but this is our opinion based on our understanding of today. Please note what Samuel said: it's not about wobbly windows or drop shadows outside your window. It's about subtle animations, fading effects, transitions, proper anti-aliasing, etc. *inside* your window. And that's to match the native look and feel that you're looking for: if the native look and feel has them, so should Qt and then those technologies will be required. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
07.10.2011, 22:59, Thiago Macieira: My sending of a screenshot of a Qt-based KDE screenshot of 14 years ago is to show that UIs change quite a lot. The change is constant, it's not one major change at a fixed point in time. BTW, some people still use KDE 2 (OpenSUSE still packages it), and find it more usable than, say, KDE 4. Seems like changes are driven by trends, not regular user needs... -- Regards, Konstantin ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On 10/7/11 3:53 PM, ext Daniel Mendizabal dan...@darhon.com wrote: On Fri, 7 Oct 2011 05:49:36 PM you wrote: But what happen now when new mobile phones come with Qt5 without QWidget support? I wonder how the message could have been given so wrong. I'm not speaking for the Qt team. But while Qt team thinks QML is the technology to use in the future for interface and will spend all its development power in it, they aknoweldge that is is currently not yet ready for all uses. That mean that QWidget is NOT going away. It is not removed. It will stay. It is just that it will stay in maintainence mode, and not get many new features. I might have misunderstood the message, but if you read the Qt5 - Road map http://developer.qt.nokia.com/wiki/Qt_5.0 it clearly states that QWidgets module will be a Qt Add On only for desktop platforms. In any case, I hope you are right and it was just an error of interpretation. It's not going away. Whether an embedded device wants to ship it by default is another question, and up to the team doing the device. And yes, QWidgets do not make too much sense on small screen devices. On tablets they can probably work fine. But look at the iPad and tell me a QWidget based app would not look outdated in there. Cheers, Lars ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
Could be there are some bugs in that right now, but yes, that is a goal. Lars On 10/7/11 6:28 PM, ext Иван Комиссаров abba...@gmail.com wrote: By the way, what about OpenGL painter backend? Can i enable it painting widgets in qt5? (last time i tried to use it, it had some painting bugs) 07.10.2011, в 18:41, Thiago Macieira написал(а): On Friday, 7 de October de 2011 18:34:46 Konstantin Tokarev wrote: 07.10.2011, 17:48, Thiago Macieira: The Qt Quick stack was rewritten. Instead of Graphics View, it sits now on top of the Scene Graph. The QWidget stack wasn't changed. So it will be possible to run old faithful QWidgets without having OpenGL ES 2? Yes. QWidgets will continue to paint to the backing store, which is QPainter- driven and has the old raster engine. Then you upload that image to the windowing server (or share it via shared memory), which will then take care of uploading to the GPU. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On Oct 7, 2011 (Friday), at 9:13 PM, lars.kn...@nokia.com wrote: Hi Till, let me also add some of my comments here. What I'm seeing here is lots of fears that I don't believe are rooted in reality. Did you try to compile Qt5 and run the Qt5 Designer lately? I have done it what is the best repo to test it, please? ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On 10/7/11 7:29 PM, ext Till Oliver Knoll till.oliver.kn...@gmail.com wrote: Oh, but you're forgetting that the UIs of the future will be like that because customers are demanding it and others are driving it! So you want to keep your UIs as they are... Let's say you had kept them as they were 14 years ago. Here's what it looked like: http://www.linux-kongress.org/1997/kde_desktop.gif So let me summarise: we cannot stop innovating. No we can't. But also remember that the trend in UI is now in the OTHER direction again, towards SIMPLER and MINIMALISTIC ways of drawing stuff, see Mac OS X! The time of Hey, KDE can draw wobbly wobbly dialogs (but requires OpenGL support to do so) is long time over! You haven't looked close enough. Much of the simplicity is achieved through small and animations that guide the eye. They are very subtle but in many places. Implementing all of this in QWidgets is close to impossible. Have you looked ad QMainWindow and how it animates certain transitions when you try to insert a dock window? A great feature, but it required a man year to implement properly. Animating things properly in the item views is something we tried, but simply couldn't do. We've reached the limits of QWidgets. And Qt just performs fine (with QWidgets!) on todays hardware, so why worry? ... You've got it. But it will stay as it is. Look at that link above again. Now place yourself in your 2016 shoes and look at your UIs of today. There will be more individually looking apps and I will still want to kick those people's butt for making apps which look different than my Windows or Mac or KDE? So you're basically saying you know how a good UI should look like and everybody else is wrong? Cheers, Lars ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On 10/7/11 9:20 PM, ext Petr Vanek p...@scribus.info wrote: On Oct 7, 2011 (Friday), at 9:13 PM, lars.kn...@nokia.com wrote: Hi Till, let me also add some of my comments here. What I'm seeing here is lots of fears that I don't believe are rooted in reality. Did you try to compile Qt5 and run the Qt5 Designer lately? I have done it what is the best repo to test it, please? On X11 with the xcb backend (as that's furthest right now, the other platforms still have more problems). Compile qtbase, qtdeclarative (as some small part of qtools, not designer depends on it), then qttools. Cheers, Lars ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On 08/10/2011, at 6:07 AM, Harri Porten wrote: On Fri, 7 Oct 2011, craig.sc...@csiro.au wrote: Desktop apps won't be going away any time soon, and there are some rather big commercial companies who would likely make some noise if Qt on desktop was being neglected. Were and how will they make that noise? Remember that Nokia has freed themselves of the commercial Qt sales and support business. That freedom is now being used for experiments with new approaches. There are service providers for classic QWidget-based programming but when it comes to new developments the market still has to be established. Hi Harri, I understand why you might also have some interest in this area (we are one of your customers!). Since I have no affiliation with Autodesk, I don't want to speculate on any specifics here. My point is more that Autodesk obviously made a business decision to rewrite Maya to be based on Qt, specifically its QWidgets. They surveyed their community of plugin developers more than once to gauge interest before they did this and since they went ahead with it, one can assume they deemed it worth the effort. Should they encounter problems with Qt's QWidgets where those problems have a strong negative impact on their product, they will simply have to find a way to address them. Being a big company (hence more $$$ and manpower), they should have more options open to them than a smaller business might. Whether they would find working through Digia to be the most effective or whether they engage with the wider Qt development community more actively, my main point is that their n eed to keep their customers happy will drive them to find a solution. And they should have the means to do so. Currently, they rely on the LGPL version of Qt and they make available all their customisations on their website. Their community of plugin developers also rely on the LGPL version as a consequence. One would hope that the rest of the Qt community would benefit from any steps Autodesk found they had to take. I'm just using Autodesk as one example here, purely because I'm more familiar with them (we are part of the community of plugin developers for Maya). I don't want to distract from the main discussions on this list. I was more hoping to simply point out that there are plenty of companies that rely on Qt's current QWidget functionality. For those who can't or don't want to change from QWidget in the medium term, there will be a collective need to see the QWidget-based capabilities maintained at least at some modest level. Those with the deeper pockets are probably more likely to have more options. -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
