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] MIME type support in Qt5
Hi David, I have come to understand that QtCreator is maintaining a local MIME database that is completely independent from the system MIME database, and is built from scratch from XML files that are part of the QtCreator distribution. Yes but it doesn't have to stay that way! It was done this way because, well, there was no code for accessing the system MIME database. Someone (who I understood to be from the Qt Creator development team) said on this list earlier that Qt Creator could and should use the system database once qmime exists. I didn't feel ready to make such design decisions on them. ;-) I wanted to preserve their existing functionality and their way to fill their MIME database. 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
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] declarative - quick
Hi Girish, Den 08. okt. 2011 08:17, skrev ext Girish Ramakrishnan: Hi, Is there a plan to rename declarative module to quick? I would prefer saying QT += quick or QT += quick2 instead of QT += declarative. Isn't declarative more like a programming style? The idea is to move the graphical parts of declarative (e.g. scenegraph items) into a quick or quick2 library, and keep the core declarative stuff in the existing library. Coincidentially, this makes the .pro file's QT += qtquick correspond to the import QtQuick that you do in qml. It also means you'll need to add both in your .pro file (e.g. QT += declarative qtquick), unless we automagically add declarative when qtquick is added (not a fan of that). Regards, Kent ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] JSON (was Re: Some parts of LibQxt in Qt)
On Fri, Oct 7, 2011 at 4:30 PM, Jedrzej Nowacki jedrzej.nowa...@nokia.comwrote: ** On Wednesday 5. October 2011 15.51.23 you wrote: Hi Jedrzej, On Tue, Oct 4, 2011 at 12:50 PM, Jedrzej Nowacki jedrzej.nowa...@nokia.com wrote: Hi, As Thiago already pointed out, we have few (too many) competing implementation of JSON parsers, and two different environments (C++ and JS/QML) in which they should work. We should have only one implementation mainly because we can't allow behavior differences and because of general maintenance costs (testing, performance improvements, etc.). Currently, I do not see obvious winner. For QML, V8 implementation may be preferred, as it creates a native JS object, which can be used directly from a QML application. On other hand from C++ point of view it would be an overkill to start full JS environment to parse a tiny json file. But of course everyone will use QML, so it is not a problem, right :-)? What I do not like about qjsonparser mentioned by Girish, is that it uses QVariant as a type for object storage. It won't be fast, ever. QVariant is a type safe replacement for void*, and nothing more. I think it is misuse to treat it as a correct object representation. In Qt, we already have two classes, which takes that responsibilities; QObject and QJSValue. The first should be known to everyone, second represents a JS object. Another issue related to QVariant is that it always needs to be converted to something, in a common case you need to iterate over QVariantMap to create an useful representation. Right, we are sort of reusing QVariant to store the entire json structure since it incidentally happens to support all the types that appear in json :) So, maybe we can make the return value be JsonObject. You can then say: JsonObject map = obj.map(foo); int someInt = obj.intValue(bar); JsonArray arr = obj.array(baz); Yes, something like that would be generic and have chance to be fast :-). On top of it, we may create additional convenience function without much overhead (like QJSValue or QVariantMap conversion). I think we need more benchmarks, before we can make the right decision. I can benchmark my implementation against the others, if the owners can first tell me that it is completely standards compliant (encoding detection etc). I have benchmarked against qjson and it's way faster. The benchmark results are in the qjsonparser repo. I tried to benchmark it against v8 json parser. The benchmark is rather a smoke test, then proper scientific measurement, but it seems that V8 is significantly faster. Result and test in attachment. Important benchmark would be to replace v8 json parser by a custom one and see if it doesn't hit performance of QML. Cheers, Jędrek Don't know if this is of much help but V8 has a C++ JSON parser : http://www.google.com/codesearch#W9JxUuHYyMg/trunk/src/json-parser.ccq=json%20package:http://v8%5C.googlecode%5C.comtype=cs Or that's what i think it is judging by the file name and the things it does.. ___ 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] MIME type support in Qt5
On Monday 10 October 2011 09:08:31 Wolf-Michael Bolle wrote: Hi David, I have come to understand that QtCreator is maintaining a local MIME database that is completely independent from the system MIME database, and is built from scratch from XML files that are part of the QtCreator distribution. Yes but it doesn't have to stay that way! It was done this way because, well, there was no code for accessing the system MIME database. Someone (who I understood to be from the Qt Creator development team) said on this list earlier that Qt Creator could and should use the system database once qmime exists. I didn't feel ready to make such design decisions on them. ;-) I wanted to preserve their existing functionality and their way to fill their MIME database. Why don't we let the Qt creator guys do the port to QMimeType once it's ready, then? I don't understand all this rush in hacking on Qt creator mimetype stuff before qmime.git is ready, and without any re-thinking of how qt creator should handle it. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.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
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] declarative - quick
On Monday, 10 de October de 2011 10:23:19 Kent Hansen wrote: It also means you'll need to add both in your .pro file (e.g. QT += declarative qtquick), unless we automagically add declarative when qtquick is added (not a fan of that). If A depends publicly on B and you do: QT += A Then B is also automatically imported. It has to because by construction B's classes are used in A, so you have to use B to use A. -- 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] declarative - quick
On Monday, October 10, 2011 01:31:47 PM ext Thiago Macieira wrote: On Monday, 10 de October de 2011 10:23:19 Kent Hansen wrote: It also means you'll need to add both in your .pro file (e.g. QT += declarative qtquick), unless we automagically add declarative when qtquick is added (not a fan of that). If A depends publicly on B and you do: QT += A Then B is also automatically imported. It has to because by construction B's classes are used in A, so you have to use B to use A. Not quite, it doesn't mean that you can do #include ClassFromB if you do QT += A. Simon ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
[Qt5-feedback] Creating hybrid apps with WebView, where should I look?
I'd like to review the support Qt5 has for Hybrid application (i.e. webview that can call out to exposed QObjects, and QObjects that can modify the DOM in webview). Where should I look? ___ 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] declarative - quick
On Monday, 10 de October de 2011 13:34:21 Simon Hausmann wrote: It has to because by construction B's classes are used in A, so you have to use B to use A. Not quite, it doesn't mean that you can do #include ClassFromB if you do QT += A. But shouldn't it? If I have: #include ClassFromA which in turn has: #include B/ClassFromB Then I am using that class from B. More importantly, if I use that class from B, then my application has to link to B *directly*, so the buildsystem must know this dependency. -- 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] Creating hybrid apps with WebView, where should I look?
Hi, On Mon, Oct 10, 2011 at 8:35 AM, Ville M. Vainio vivai...@gmail.com wrote: I'd like to review the support Qt5 has for Hybrid application (i.e. webview that can call out to exposed QObjects, and QObjects that can modify the DOM in webview). Where should I look? The webkit trunk repo. It's a work in progress, we have a QML element for desktop use case and one for touch use case (and the C++ API that comes with it). The hybrid case is something we are still researching for WebKit2 architecture. Nothing really settled there for now. In any case for old school people who don't want to change anything the old QWebView and friends are still sitting in the repo. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback -- Alexis Menard (darktears) Software Engineer INdT Recife Brazil ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] declarative - quick
On Mon, Oct 10, 2011 at 1:53 PM, Kent Hansen kent.han...@nokia.com wrote: Hi Girish, Den 08. okt. 2011 08:17, skrev ext Girish Ramakrishnan: Hi, Is there a plan to rename declarative module to quick? I would prefer saying QT += quick or QT += quick2 instead of QT += declarative. Isn't declarative more like a programming style? The idea is to move the graphical parts of declarative (e.g. scenegraph items) into a quick or quick2 library, and keep the core declarative stuff in the existing library. Coincidentially, this makes the .pro file's QT += qtquick correspond to the import QtQuick that you do in qml. It also means you'll need to add both in your .pro file (e.g. QT += declarative qtquick), unless we automagically add declarative when qtquick is added (not a fan of that). I really like the idea of separating the graphical parts to separate library. Still, please do consider renaming 'declarative' in QT += declarative to something else. QT += qml or quickcore or something? We should take the whole Quick terminology to heart and use it all over :-) Girish ___ 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] Regular expression libraries for QRegExp
On Mon, Oct 10, 2011 at 9:03 PM, Olivier Goffart oliv...@woboq.com wrote: On Monday 10 October 2011 11:52:37 Mark wrote: Hi, Some time ago I've read something here about replacing Qt't QRegExp backend with a existing library to get rid of the maintenance burden. One other conclusion was not to touch QRegExp, meaning keeping compatibility. And those that need powerfull regexp can use the library and syntax they want. (Notice that in C++11, there is std::regex) Wouldn't this prevent a nicer tight integration with other Qt classes like QString, QVariant etc? That is to say it would be nice if we could use a more powerful regexp with these classes. Girish ___ 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] Regular expression libraries for QRegExp
On Mon, Oct 10, 2011 at 6:28 PM, Thiago Macieira thi...@kde.org wrote: On Monday, 10 de October de 2011 18:13:47 Giuseppe D'Angelo wrote: If a solution doesn't come up in time for 5.0, could QRegExp still be moved into a separate module so that it's possible to put a replacement inside qtbase somewhere in the 5.x lifetime? Unknown. We need to figure out how to do that without breaking QString. Can't there be a QRegExp2 that is made with the regex engine? QRegExp2 should then be used for stock Qt classes (QString and what else is using it). QRegExp should be deprecated and dropped in Qt 6 ..? I'm also guessing that using std::regex is not an option since not all compilers that Qt support have std::regex support. Just some brainstorming... ___ 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] declarative - quick
On 10/10/2011 09:31 PM, ext Thiago Macieira wrote: On Monday, 10 de October de 2011 10:23:19 Kent Hansen wrote: It also means you'll need to add both in your .pro file (e.g. QT += declarative qtquick), unless we automagically add declarative when qtquick is added (not a fan of that). If A depends publicly on B and you do: QT += A Then B is also automatically imported. In theory, yes. In practice, no. This definitely breaks on Windows and possibly in other situations too. For a practical example, you can't do: QT = core declarative It does seem to work fine on Linux but not on Windows. Since declarative depends on gui you must explicitly list it: QT = core gui declarative -- Lincoln Ramsay - Senior Software Engineer Qt Development Frameworks, Nokia - http://qt.nokia.com/ ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
