Re: [Development] QtQuick Call for Maintainer
On Wed, Mar 9, 2016 at 1:56 AM, Frederik Gladhorn <frederik.gladh...@theqtcompany.com> wrote: > We are in the luxury position of having two great candidates. > I briefly talked to both Robin and Shawn yesterday and one option would be to > have a shared maintainership. This seems to have worked nicely for Qt > Networking and dividing the responsibilty will lessen the burden. I agree they would both be great candidates. I have enjoyed working with both on Qt Quick in the past. They also have complementary interests, with Shawn driving key input functionality and Robin looking at the full stack performance. Individually or together, +1 from me. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QtQuick Call for Maintainer
Hi all, I have been drawn away from Qt Quick at work the past several months, for even I do not write back-end services with Qt Quick. Consequently I have not had time to fulfill the responsibilities of Qt Quick Maintainership and will have to pass the mantle onto someone new. Accepting the unfortunate nature of reality means that I must resign from the QtQuick maintainership position. Accordingly I have removed my name from the maintainers wiki page. Everyone on gerrit knows I'm not getting to my reviews anymore, so I can no longer hold a module maintainer position. It would be great if someone else could step up and take over, as I still believe QtQuick is a key component of the premier native GUI framework. Any volunteers? -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML import versions
On Thu, Sep 24, 2015 at 9:04 AM, Attila Csipa <q...@csipa.in.rs> wrote:
> On 9/21/2015 10:51 PM, Alan Alpert wrote:
>>
>> I found part of the previous discussion, see my essay from 2012 which
>> explains the versioning system:http://alan.imagin-itis.net/?p=322
>
>
> Not a new discussion, indeed :)
>>
>> Now in the next minor version of Qt, say we add a QQmlFlange class to
>> QtQml. A application built against the current version of Qt, but
>> linking to system libraries, will continue to work fine. The name
>> resolution happened at the linker stage and so a new symbol in the
>> shared library doesn't affect the behavior of the compiled binary.
>> "flange" will still be an instance of the local QQmlFlange and you
>> won't hit the name conflict until you try to compile against the new
>> Qt version.
>>
>> Contrast to the example I gave Robin, where the QML name resolution
>> happens at runtime, and you can see why #include is so much
>> safer than import QtQml.
>
>
> This is a red herring - given MOC and QObject properties, there is no
> guarantee (other a statistical "we add less properites to C++ classes than
> to QML, so there is less change of namespace overlap"). At best, this would
> indicate differences of defaults, but not versioning enforcement.
>
> Here's an example:
>
> QScreen* scr = qApp->screens().at(0);
>
> qDebug() << scr->property("devicePixelRatio");
> qDebug() << scr->setProperty("devicePixelRatio", 100);
> qDebug() << scr->property("devicePixelRatio");
>
> On Qt5.3, this gives
>
> //QVariant(Invalid)
> //false
> //QVariant(int, 100)
>
> On Qt5.5, this gives
>
> //QVariant(double, 1)
> //false
> //QVariant(double, 1)
>
> It's clear that there will be no compile time difference, but given the
> different *runtime* outcomes, the app behavior can be altered completely
> transparently to the developer. That's why it feels that the QML versioning
> *enforcement* is pretty arbitrary, as both C++ and QML can be written in
> both static and dynamic manners. Even if we say that "well Qt on the C++
> side doesn't use properties that often", it doesn't take into account 3rd
> party code, or how much it (doesn't) rely on either QML or C++ properties in
> it's own classes.
The point of versioning isn't to prevent different runtime outcomes,
that's not possible as you have showed. But there's an implicit
compile step when you run a QML file at program startup, and the
versioning system prevents that from failing.
Getting different values is a problem, yes. But those lines still ran,
and you could theoretically use runtime error handling code. If there
suddenly appears a type conflict in a QML file, the compilation stage
*fails* and the QML code never reaches its own "runtime" to experience
the different outcomes (we are in the runtime of the C++ application,
but bailed on compilation of the QML files).
If QML was untyped you could probably let it slide, as different
values at runtime is a much harder problem to solve. But when you can
change the type of a variable in a binding and then the file will
simply fail to compile, that's guaranteed application breaking.
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML import versions
On Mon, Sep 21, 2015 at 3:36 AM, Hausmann Simon <simon.hausm...@theqtcompany.com> wrote: > Hi, > > > I agree that something "new" needs to be put on the table in order to solve > this. And "this" expands unfortunately to a few issues at the same time. > > > I think that it would be a mistake of "import QtQuick" - without any version > tag - would always import the latest available > version on the system. If we look into other development communities with > package based environments such as Python (pip) > or Go, then we can see that the approach of automatically always importing > the latest version is known to cause more headaches > than do good. Very quickly the users want to be able to _pin_ to a certain > version and be themselves in control when to "upgrade" > to newer API. > > I think that we should learn from this and this is why I think generally > applying a version to the QML APIs is a good thing. I believe that what > we are missing is the convenience of making the conscious step of changing > the of QtQuick 2.4 to 2.5 - it is incredibly tedious at this > point as it requires touching every single file. I still don't know why people feel they need to do this. Touch the files that you want to use new features in, and if the others are importing a different minor version that's okay. Then the work is only marginally bigger than the actual new feature work in your application. A big point of the QML versioning system is that multiple imports of the same module can co-exist happily in the same engine. > > Therefore I think that we should introduce the notion of configuration files > that apply to an entire project. For QML modules that configuration > file is the qmldir file, although I'd prefer something different. For > applications - the primary target audience in this thread - we are lacking a > central place where we could say that > > > import QtQuick > > > should resolve to exactly version 2.4. > > In other words: I think we should allow application developers to use just > "import QtQuick" in their qml files - without a version. But all that > should mean is that when the engine encounters a version-less import, it > should look for the project configuration file to pick the version the > developer would like to choose. Since we don't have an existing central place for where to look, I think this connection isn't obvious in the code (where it should be easily readable). I like the concept though, maybe it could be "import QtQuick from Project" or "import QtQuick from ../project.qmldir" to give a direct link to the program configuration file. An explicit file link would also help with modules, which presumably need to package their import versions and use them instead of the application settings. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML import versions
I found part of the previous discussion, see my essay from 2012 which
explains the versioning system: http://alan.imagin-itis.net/?p=322
It even has an answer for "Why not just use Qt versions?" (but it's a
little out-of-date).
Additional answers to Attila's questions inline below.
On Mon, Sep 21, 2015 at 11:58 AM, Attila Csipa <q...@csipa.in.rs> wrote:
> On 9/21/2015 6:51 PM, Alan Alpert wrote:
>> On Mon, Sep 21, 2015 at 3:36 AM, Hausmann Simon
>> <simon.hausm...@theqtcompany.com> wrote:
>>> or Go, then we can see that the approach of automatically always importing
>>> the latest version is known to cause more headaches
>>> than do good. Very quickly the users want to be able to _pin_ to a certain
>>> version and be themselves in control when to "upgrade"
>>> to newer API.
>
> Let me put it this way. If we trust ourselves enough not to have
>
> QT_REQUIRE_VERSION(arc, argv, "5.4.0")
>
> ...in every single .cpp file, why do we think QML absolutely must have
> it? In other words, why is
>
> #include
>
> so much safer than
>
> import QtQml
>
> ?
Here's a scenario corresponding to the one I gave Robin as to why QML
needs minor versions.
#include
class QQmlFlange {
};
flange = new QQmlFlange()
Now in the next minor version of Qt, say we add a QQmlFlange class to
QtQml. A application built against the current version of Qt, but
linking to system libraries, will continue to work fine. The name
resolution happened at the linker stage and so a new symbol in the
shared library doesn't affect the behavior of the compiled binary.
"flange" will still be an instance of the local QQmlFlange and you
won't hit the name conflict until you try to compile against the new
Qt version.
Contrast to the example I gave Robin, where the QML name resolution
happens at runtime, and you can see why #include is so much
safer than import QtQml.
> Finally, no matter how you pin, you will be getting the new
> implementation - is there an example that Qt actually retained a
> different implementation for older imports, not counting QtQuick1 vs
> QtQuick2?
Yes, QtQuick.Window 2.0 is implemented using the QQuickWindow class,
in QtQuick.Window 2.1 we moved it to QQuickWindowImpl. Not an entirely
separate implementation, and the differences are deliberately minor
(because it's a minor version) but if we added a QtQuick.Window 3.0
any time soon we'd keep these two classes around.
If you aren't counting QtQuick 1 vs QtQuick 2 (and presumably aren't
counting Qt.labs.*), you're currently left with no major version bumps
within Qt Essentials modules and so no "older imports" exist at all.
>>> I still don't know why people feel they need to do this. Touch the
>>> files that you want
>>> to use new features in, and if the others are importing a different
>>> minor version that's
>>> okay. Then the work is only marginally bigger than the actual new
>>> feature work in your
>>> application. A big point of the QML versioning system is that multiple
>>> imports of the
>>> same module can co-exist happily in the same engine.
>
> Because your import will, in practice, match your latest Qt version used
> for development, not the *API level* required. If you touch a property
> that doesn't exist, again, you will be bumping to the latest version,
> not the version that introduced the feature (as there is no simple way
> of figuring out what the "required" version would be). At some point you
> just stop fighting it and say "okay, latest it is" (or go back to
> whatever old Qt you wish to target).
Okay, so you bump to the latest version instead of the strict minimum
required whenever you touch a property that doesn't exist. You still
don't need to update files that aren't using any "new" features.
>>> import QtQuick
>>>
>>>
>>> should resolve to exactly version 2.4.
>>>
>>> In other words: I think we should allow application developers to use just
>>> "import QtQuick" in their qml files - without a version. But all that
>>> should mean is that when the engine encounters a version-less import, it
>>> should look for the project configuration file to pick the version the
>>> developer would like to choose.
>> Since we don't have an existing central place for where to look, I
>> think this connection isn't obvious in the code (where it should be
>> easily readable). I like the concept though, maybe it could be "import
>> QtQuick from Project" or "import QtQuick from ../project.qmldir" to
>> give a direct link to the program configuration file.
>>
>
> This is fine - ju
Re: [Development] QML import versions
ent error message: admittedly it might be a less descriptive one -
> you'd get told that the type/property didn't exist, as opposed to module
> version foobar is not available - but this is also the case with C++
> usage now!).
>
> Or am I missing some other value offered by minor version numbers?
Here is the scenario:
import QtQuick 2
Item {
property bool scrollGestureEnabled: false
MouseArea {
onClicked: console.log(scrollGestureEnabled)
}
}
In QtQuick 2.4 that would get the scrollGestureEnabled off of the
Item, in QtQuick 2.5 it resolves to the new MouseArea property. So
code like this will inexplicably break at run time when the system Qt
updates :( .
By using "import QtQuick 2.4" explicitly, that can't happen. That is
the value offered by minor version numbers. It is the mechanism by
which we achieve "Code written for older versions will Just Work on
newer versions".
The QML versioning is different to the C++ versioning because QML is
an interpreted langauge and C++ is not. C++ links to symbols at
compile time meaning that whatever you complied it against pretty much
works (so long as we maintain binary compatibility). QML versioning
aims to give that same behavior with an interpreted language, so that
whatever you developed it against still works out in production
environments with updates, but it needs language level features (the
versioning system) to do it.
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML import versions
On Sun, Sep 20, 2015 at 4:55 AM, Filippo Cucchetto <filippocucche...@gmail.com> wrote: > I'm no troll, but i don't see any way to solve this without putting > something new to the table > > 1) What about extending the a little bit the QML language itself. > Something like > import QtQuick as in 5.5 > import QtQuick.Controls as in 5.5 > > so a way to specify to import a module at version when a specific Qt version > was released. > Obviusly this doesn't disable the option for specifying a particular > version. > So this should be fine > import QtQuick as in 5.5 > import QtQuick.Controls 1.4 Yes, this sort of thing could work (probably use the keyword "from" instead of "as in", or some other reserved word). I think last time this was put forward we considered implementing it with "metamodules" that are just lists so that we could have a qml/Qt5/qmldir that looks like <...> QtQuick 2.4 since 5.4 QtQuick 2.5 since 5.5 QtQuick.Particles 2.0 since 5.0 <..> And that would be a file that the mapping comes from and is parsed by the engine when it sees a "QtQuick from Qt 5.5". It would also be generic enough so that module bundles other than Qt essentials could use it. The pitfall last time was that it's language work no-one has time for :( . > 2) Another option is automatically use the latest version of a module if the > version number > is not specified. So: > import QtQuick // Automatically imported with the latest version installed > import QtQuick.Controls // Automatically imported with the latest version > installed > If you don't break from the name resolution case, you'll break when the major version updates and things are expected to break. Could work if you statically link Qt into your application, but if you're using system libraries you're doomed. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML import versions
> - rev 3 in QtQuick 2.3 > - rev 6 in QtQuick 2.6 > > Now, mix meta revisions with inheritance and it gets interesting... > > Therefore, I'm throwing in this proposal to > 1) make all Qt Essentials QML modules follow the Qt version number, and > 2) revision new properties using the minor version of Qt. > > Then Qt users have some clue what to import and what Qt version their app > depends on, and Qt developers can instantly see when certain properties and > methods were introduced while browsing the header files. > > Is this something that would be possible to implement already in Qt 5, or is > this Qt 6 material? Does someone strongly oppose the idea? How often do we > release new major versions of QML modules? I don't see why QML modules > couldn't follow the same practices than the rest of Qt follows. Ironically, > we've been working on this thing called Qt Quick Controls 2.0... :P So what's not possible is the conceptual conflict between arbitrary and semantic version numbers. With QtQml.Particles still at 2.0 in Qt 5.6 you know that it hasn't gained any new features and so your particles scenes from 5.4 can be easily brought back to 5.2 if needed for another deployment. With QtQuick at 2.6 you'd need to check you aren't using any new features. But if QtQuick goes to 2.7 in 5.7 you can either A) keep importing 2.6 and it works fine B) import 2.7 and see if you have a name collision with a new feature. Since it didn't bump the major version, you know all the existing features will keep working as before (save for bug fixes) but at 3.0 all bets are off. With the QtQuick module specifically, we probably can match the Qt version just fine. The development pace of that module follows the development pace of Qt. But the other modules tend to be developed slower, leading to the following potential breaches of semantic versioning: -Bumping QtQuick.Particles to 2.7 and raising everyone's hopes that there was a new feature. Also in the current implementation of QML versions this would require a code change to QtQuick.Particles specific for 2.7 (and so another change every minor version...). Because it requires a change for every valid minor version, if we just did it for 2.7 then import QtQuick.Particles 2.6 would fail, but import QtQuick.Particles 2.7 would not. -Bumping QtQml to 3.0/6.0 at Qt 6 time, even though there probably will NOT be any breaking changes at the core language elements level. By saying "yeah, switch to 3.0 and nothing's changed" we've ruined the semantic meaning of a major version change. In the current implementation of QML you would need to duplicate all qmlRegister* calls in order to do this. -Not being able to bump QtQuick.Window to 3.0 before QtQuick, as Robin explained. So either we delay development of that module or we have a "minor" version bump which breaks existing elements (again, ruining semantic versioning). I think it's technically possible to do that with the current implementation, but it's a real pain because you'd have to replace every single type, some with an uncreateable type saying "not available anymore". The other thing to consider is that QML versioning is not intended to keep up with Qt version number *within an application*. So let's imagine a scenario where every QML module in Qt essentials used the Qt release version number since the dawn of time. You'd still have code looking like this inside an application: import QtQuick 5.5 import QtQuick.Particles 5.3 import QtQml.Models 5.3 It could be running against 6.1, but was developed against 5.6 most recently. Since they aren't using QtQuick features added in 5.6, there's no need to change the import, the most recent features they used from QtQuick came from 5.5. They originally developed it against 5.3, and haven't used anything new from QtQuick.Particles or QtQml.Models since. This is the sort of thing we'd be seeing if QtCreator from Qt 5.3 could automatically pick the most recent import for you when creating a project. It would be nice to have an easy way to find out which module versions are in which release. I think qmltypes is a better way of doing that, because the semantic versioning is both valuable and deeply integrated into the current system. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QtCS] QtRemoteObjects Session Summary
On Thu, Jun 18, 2015 at 11:48 PM, Simon Hausmann simon.hausm...@theqtcompany.com wrote: On Thursday, June 11, 2015 02:21:22 AM Stottlemyer, Brett wrote: Hi Alan. Hi Simon. On 6/10/15, 4:23 PM, Alan Alpert 4163654...@gmail.com wrote: On Wed, Jun 10, 2015 at 6:52 AM, Simon Hausmann simon.hausm...@theqtcompany.com wrote: On Tuesday, June 09, 2015 01:23:29 PM Alan Alpert wrote: A brief overview of planned features: -QML API -Protocol Layer Adapters -Investigate merge with QWebChannel (sounds similar, of course no-one working on QWebChannel was present to confirm). After it is established with those features and solid quality, it could be considered to promote it to an add-on module. I¹m the one who talked about QtRO (it was named Replicant at the time) at last year¹s Contributors Summit and requested the playground. I definitely like the idea of making it an add-on module, but are you suggesting it needs protocol layer adapters as a prerequisite? The additional QML API piece would be welcome, and I¹m open to see if there is benefit to merge/code share with QWebChannel. I¹ve always been resistant to try to make QtRO play nice with other languages, though. Of course that would be fantastic! No argument there. But you¹ve already mentioned one of the difficulties - exported abstractitemmodels. That is a very Qt specific implementation, with support for QVariant types and specific roles. And concrete signals/slots. It isn¹t a matter of simply passing data to another language (although that is hard enough when it comes to all the types Qt supports marshaling for already). Even if you could pass the data to python or java effectively, how would the receiver be expected to display the results? Very good point. Many of our concepts in Qt map well to concepts in other languages - for example signals/slots across threads and go channels. However the more complex the concept the harder it becomes to map and that perhaps isn't worth the effort. (this just as an observation, not in response to your concrete implementation of QtRO :) I feel that mistake is made over and over again in many similar designs. It is perhaps one area where the web development is doing better. It's my (perhaps incorrect?) impression that web services tend to be accessed using more explicit code instead of using transparent method calls or property access. The XMLHttpRequest API is one example here, and the promises based fetch() API makes this even better IMHO. This is attempted to be addressed (at least from the QML API) by having explicit node objects. It can have error handling and state communication (still to be designed), and fall-back mechanisms like default values. I agree error handling shouldn't be hidden entirely, but I would also say that it's still an area where we want to make developer's lives easier with pre-built common-case logic. This is how it is currently addressed in C++ as well, although we need to expose the errors as signals and enhance this area. I feel error handling is something that's really getting better over time in programming. I really like thrift's new error handling and I admit I'm also a fan of go's put-the-error-in-your-face approach - controversial I admit :). But what this shows in my opinion is that particularly robust designs don't just _offer_ error handling to the developer, they really place it right in front of them when writing and reading code. I feel we haven't done that in the design of the Qt APIs, yet. We already have the XMLHttpRequest API for distributed systems. The point of QRO, as I see it, is something more convenient and more pre-made by comparison. Indeed. QtRO makes it trivial to create a Replica of a Qt object in another process or on another device. You interact with the Replica just as you would the original object. It doesn¹t hide errors, but also doesn¹t require overhead for nominal/happy-path behavior. And this is where I think Qt is best off providing functionality that makes it trivial to interact with other processes or devices under the rather likely assumption that they are not written in Qt. A current or future scenario these days is that you have mobile devices, processes on stationary computers, small computers on big industrial machines. The software in question may very well be written in Qt and C++, but it's also likely that in the same software scenario there's a frontend that's running in a web browser using JavaScript. This software may talk to a service, which is likely written not in C++ but rather Haskell, Go, Java or perhaps NodeJS - running perhaps on some instance in Amazon's cloud. For a variety of reasons I suppose, including the availability of efficient green threads or simply due to expertise on the job market. And those services then may talk to backend services, unlikely to be written with Qt in my opinion. There's
Re: [Development] Avoid overloading of 'error'
On Tue, Jun 16, 2015 at 4:50 AM, Sze Howe Koh szehowe@gmail.com wrote: On 16 June 2015 at 19:28, Kurt Pattyn pattyn.k...@gmail.com wrote: Well, you can also think of “on” + event, like in: onWindowClosed, onMouseClicked, onBytesReceived, … In the same analogy, you could have onErrorOccurred. Seems very intuitive to me. It depends if you want to react to a state or to the event causing that state. The QML spec says on + signal, not state: http://doc.qt.io/qt-5/qtqml-syntax-signals.html#receiving-signals-with-signal-handlers You can call connect() on the thing after on: http://doc.qt.io/qt-5/qtqml-syntax-signals.html#connecting-signals-to-methods-and-signals The thing after on is also exposed to C++ as a signal; it can be passed to QObject::connect() in the SIGNAL() macro. So, we need to use signal names (which are past tense verbs). Yes, these are the same things as the signal names. We don't want to implement some magical difference for QML which doesn't yet exist. So if we're migrating (slowly) to errorOccurred() as the standard signal name (which I still think is more trouble than it's worth) then classes exposed to QML will migrate (slowly) to onErrorOccurred, and that's fine. It would be an additional layer of confusion and implementation to make QML diverge in order to still have onError in Qt 6. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Avoid overloading of 'error'
On Sat, Jun 13, 2015 at 12:42 PM, Lorn Potter lorn.pot...@gmail.com wrote: On 11/06/2015 12:36 am, Samuel Gaist wrote: failed doesn't always mean there was an error with a direct relation. I was going to say this, but you beat me to it. Also, errored is just wrong, error is also past tense. I consulted a linguist. She said that if you wanted to use error as a verb (it's not normally one), errored would be the past tense. But that it's probably not the best choice of word. She also said to link to this comic: http://smbc-comics.com/index.php?id=3761 -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Avoid overloading of 'error'
On Thu, Jun 11, 2015 at 7:11 AM, Hausmann Simon simon.hausm...@theqtcompany.com wrote: Hi, I agree about the inconsistency in tense, that is a good argument against error(), although it is similarly unfortunate that the inconsistency in tense is more widespread than assumed. I'm not sure onErred or onErrored is any better, to be honest. I think it's more likely to result in a typo than the most basic form of the word - error - instead of some conjugation. In the light of that I think I'd prefer onFailed or onFailure - but I think it would perhaps be a mistake to make our existing APIs more inconsistent than necessary. It seems like an unfortunate choice, but I think it's better to stick to error() than to have some QML types have onError and some have onFailure. I strongly advocate against replacing onError with onFailure. The issue as I see it is a conflict between classic (perhaps BASIC derived?) convention of handlers being on + state noun versus our convention of on + past tense verb. Failure, Error (and success, completion etc.) are all the old convention so it's not worth moving from Error just to another word in the same convention that we're trying to escape from. I also don't like to conceptually pin error to failure, because in rare cases you can still have a partial success despite an error condition. Since there is this other convention that uses onError a lot (at least in XMLHttpRequest), I can see how a similar (but past tense) word would be confusing to many developers. So now we're weighing the cost of confusing both new and old developers just to make the refactoring support work better. I'm no longer convinced it's worthwhile, so I'm with Simon on that it's better to stick to error() for now. At least for the QML exposed APIs. If I break out the thesaurus, then we also have errorBefell If we want to sound fancy, we can use an obscure language and then it can be shorter too: tokFeil . Also solves the problem of looking like other APIs, as they limited themselves to English. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QtCS] QtRemoteObjects Session Summary
On Wed, Jun 10, 2015 at 7:21 PM, Stottlemyer, Brett (B.S.) bstot...@ford.com wrote: Hi Alan. Hi Simon. On 6/10/15, 4:23 PM, Alan Alpert 4163654...@gmail.com wrote: On Wed, Jun 10, 2015 at 6:52 AM, Simon Hausmann simon.hausm...@theqtcompany.com wrote: On Tuesday, June 09, 2015 01:23:29 PM Alan Alpert wrote: A brief overview of planned features: -QML API -Protocol Layer Adapters -Investigate merge with QWebChannel (sounds similar, of course no-one working on QWebChannel was present to confirm). After it is established with those features and solid quality, it could be considered to promote it to an add-on module. I¹m the one who talked about QtRO (it was named Replicant at the time) at last year¹s Contributors Summit and requested the playground. I definitely like the idea of making it an add-on module, but are you suggesting it needs protocol layer adapters as a prerequisite? That was the impression I got from the session. Really it's just that the developers want it ready before submitting it as an add-on module, and supporting a second usecase (like QWebChannel) is a strong sign of that. It sounded like QWebChannel needed the protocol adapters before they could jump in. There's a strong argument for making it an add-on module if we have three separate use-cases served (Ford, BlackBerry, QWebChannel). That demonstrates at least some level of value beyond a specific use-case. The additional QML API piece would be welcome, and I¹m open to see if there is benefit to merge/code share with QWebChannel. I¹ve always been resistant to try to make QtRO play nice with other languages, though. Of course that would be fantastic! No argument there. But you¹ve already mentioned one of the difficulties - exported abstractitemmodels. That is a very Qt specific implementation, with support for QVariant types and specific roles. And concrete signals/slots. It isn¹t a matter of simply passing data to another language (although that is hard enough when it comes to all the types Qt supports marshaling for already). Even if you could pass the data to python or java effectively, how would the receiver be expected to display the results? They have their own modules on their side. One of the sessions you missed included a demo with Meteor.js talking to QML applications using a somewhat similar approach. It had custom logic that mapped Meteor's wire protocol into QObject like structures so that QML could use it. Or at least that's how I assume it worked, given that I have a similar case myself with a specific node.js server at work (all this travel and 5.5.0 release and I haven't had a chance to checkout Attila's code yet). It would *NOT* be a generic Java to C++ level adapter, it's specific FW (Qt) to specific FW (e.g. Meteor.js) assuming they have QObject compatible semantics. QtRO also supports ³dynamic² objects, where the method, signal and property signatures are sent over the wire to allow a dynamic metaobject to be created. IIRC, even protocol buffers need to be compiled on all sides, at least in C/C++. Would this be a feature you would intend to support in an adapter? Do you have a good way of doing this without either a) duplicating a lot of functionality interspersed throughout Qt, or b) adding a tremendous burden to QtRO? Again, I like the idea, I just worry about the implementation cost. Then I'll start working on the implementation, because my idea of it was that the cost would be low. I'll add you to the change on gerrit when I have a draft ready. The idea with protocol adapters is that currently it only sends QDataStream output over the wire. I want to send more accessible JSON-RPC (like) data over the wire for working with node, and Attila had a demo of getting object data from Meteor (although that was custom hacked for demo purposes). Protocol adapters will allow you to serialize it in these other forms, and that is the mechanism by which we gain compatibility with other languages/frameworks without them needing explicit QRO support - We'll talk their language if there exists compatible semantics. They'll probably remain separate from the transport adapters, but we'll see how the implementation develops. I'll start looking into the implementation this month. I look forward to seeing what you propose. I feel that mistake is made over and over again in many similar designs. It is perhaps one area where the web development is doing better. It's my (perhaps incorrect?) impression that web services tend to be accessed using more explicit code instead of using transparent method calls or property access. The XMLHttpRequest API is one example here, and the promises based fetch() API makes this even better IMHO. This is attempted to be addressed (at least from the QML API) by having explicit node objects. It can have error handling and state communication (still to be designed), and fall-back mechanisms like default values. I agree error
[Development] Qt 5.5.0 QML Revision Check
I have run qmlRevCheck between the 5.4 and 5.5.0 branches, for the imports in qtdeclarative/src/imports. Results are attached. Results come from generating and parsing new qmltypes files from each branch, and comparing them with the qmlRevCheck tool (https://codereview.qt-project.org/#/c/114038/ is the updated version to build these days). I won't have time to properly look through the results until tomorrow, but there is one key thing to note in the output. qmlplugindump -builtins will spit out QtQuick types in 5.4, but in 5.5 it's a separate file (from qmplugindump -nonrelocatable QtQuick 2.5). I compared the 5.4 file to each of the two 5.5 files separately in the two output files. But it's a lot of noise, and I'm not quite awake enough to filter it out right now. -- Alan Alpert folderlistmodel.out Description: Binary data localstorage.out Description: Binary data models.out Description: Binary data particles.out Description: Binary data qtquick2.out Description: Binary data qtquick2.out2 Description: Binary data settings.out Description: Binary data statemachine.out Description: Binary data window.out Description: Binary data ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QtCS] QtRemoteObjects Session Summary
On Wed, Jun 10, 2015 at 6:52 AM, Simon Hausmann simon.hausm...@theqtcompany.com wrote: On Tuesday, June 09, 2015 01:23:29 PM Alan Alpert wrote: There was late-scheduled session on QtRemoteObjects at QtCS on Saturday. QtRemoteObjects is a playground module for object remoting of QObjects, and can be found at http://code.qt.io/cgit/playground/qtremoteobjects.git/ . A brief overview of the existing features: -Exports QObjects remotely, creates a replicant on the client side you can interface with -Network nodes can serve as a registry to allow lookup by name. -Transport Layer Adapters -Bjoern is currently working on exporting of QAbstractItemModels A brief overview of planned features: -QML API -Protocol Layer Adapters -Investigate merge with QWebChannel (sounds similar, of course no-one working on QWebChannel was present to confirm). After it is established with those features and solid quality, it could be considered to promote it to an add-on module. The idea with protocol adapters is that currently it only sends QDataStream output over the wire. I want to send more accessible JSON-RPC (like) data over the wire for working with node, and Attila had a demo of getting object data from Meteor (although that was custom hacked for demo purposes). Protocol adapters will allow you to serialize it in these other forms, and that is the mechanism by which we gain compatibility with other languages/frameworks without them needing explicit QRO support - We'll talk their language if there exists compatible semantics. They'll probably remain separate from the transport adapters, but we'll see how the implementation develops. I'll start looking into the implementation this month. The question was raised How is this not CORBA?. I'm not that familiar with CORBA (just read the wikipedia article today), but my suspicion is that we've cut out a lot of the boiler-plate by leveraging existing Qt Meta-object information. I don't suspect that this is the CORBA criticism. I mean, it's a fair point that you often do end up with boiler plate translating type systems, but that's mostly a matter of good IDL bindings. No, the criticism I would have regarding CORBA or at least the way you may quickly end up using it is that it hides something that shouldn't be hidden: Failures. When working with remote services things _will_ go wrong. There will be issues with your connection, there will be issues with the remote side not responding (having crashed for example), there will be many such issues. You don't see them when developing the system, but during real world deployment you run into them, and then it's too late. During development you haven't encountered those issues, so your code that calls methods and reads/writes properties is written as if it works locally, because it did during your testing. Systems like CORBA encourage developers to write code as if the method calls were local, completely ignoring the nature of unreliable transports and services. I feel that mistake is made over and over again in many similar designs. It is perhaps one area where the web development is doing better. It's my (perhaps incorrect?) impression that web services tend to be accessed using more explicit code instead of using transparent method calls or property access. The XMLHttpRequest API is one example here, and the promises based fetch() API makes this even better IMHO. This is attempted to be addressed (at least from the QML API) by having explicit node objects. It can have error handling and state communication (still to be designed), and fall-back mechanisms like default values. I agree error handling shouldn't be hidden entirely, but I would also say that it's still an area where we want to make developer's lives easier with pre-built common-case logic. We already have the XMLHttpRequest API for distributed systems. The point of QRO, as I see it, is something more convenient and more pre-made by comparison. The other aspect that I think is crucial in a distributed system is compatibility. This is why systems like thrift and protocol buffers exist: They provide type safety (!) and make it really easy to maintain wire compatibility. JSON is also okay with this, but it has the huge disadvantage that usually json formats are untyped. Anything you think our transport and protocol layer adapters is missing in this respect? Even if we first have to write a protocol layer adapter for each piece of compatibility we want, I imagine we could eventually hit upon a suitably general (yet performant) protocol adapter which can become standard. In my opinion a system that we promote to Qt developers should learn from these mistakes in the past: The API should encourage developers to write fault tolerant code (because distributed systems _do_ fail) and it should be easy to maintain wire compatibility (just like we do maintain binary compatibility). I'll try to remember to add you
Re: [Development] Avoid overloading of 'error'
On Wed, Jun 10, 2015 at 8:14 AM, Hausmann Simon simon.hausm...@theqtcompany.com wrote: Hi, I think renaming the getter to lastError is nice! I however do like error as signal name and it looks good in qml as onError:... I disagree that it looks good in QML as onError, almost all other signal handlers are past tense so it is visibly odd. But it's nice to be so short, so maybe a direct past-tense-ify of onErrored? If you don't like using error as a verb, we can use a similar (yet shorter) verb: onErred. Not that I really mind the exact name of the new signal. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 QML Revision Check
On Wed, Jun 10, 2015 at 1:04 AM, Alan Alpert 4163654...@gmail.com wrote: I have run qmlRevCheck between the 5.4 and 5.5.0 branches, for the imports in qtdeclarative/src/imports. Results are attached. Results come from generating and parsing new qmltypes files from each branch, and comparing them with the qmlRevCheck tool (https://codereview.qt-project.org/#/c/114038/ is the updated version to build these days). I won't have time to properly look through the results until tomorrow, but there is one key thing to note in the output. qmlplugindump -builtins will spit out QtQuick types in 5.4, but in 5.5 it's a separate file (from qmplugindump -nonrelocatable QtQuick 2.5). I compared the 5.4 file to each of the two 5.5 files separately in the two output files. But it's a lot of noise, and I'm not quite awake enough to filter it out right now. Okay, the analysis of the qmltypes diff shows the following issues: 1) c07f5b801bd6a94fe862073eb1f1965115a56385 (qtbase) adds a transitionType property to QAbstractTransition without versioning it. 2) 44ab79012f1662a4efa7c506b6ebc4466c50b3e9 (qtdeclarative) adds scrollGestureEnabled property to MouseArea without versioning it. Fixes for these should probably be rushed in to 5.5.0 if we still can, given they will probably miss the RC. I can help draft those. 3) 40f394ef2e06a6466445e4df54735250939084f0 (qtdeclarative) adds width/height properties to the Window attached object without versioning it 4) dad48f0e9cca10528fcaab7ec7d08f678e81b1a9 (qtdeclarative) adds getDataAsArrayBuffer method to DropEvent without versioning it. It probably isn't worth rushing the fix in for these, since there's no real way to collide with new names on attached properties or event types. Consider yourselves chastised and we'll move on. 5) qmlplugindump is acting up as explained before on the builtins. I'm inclined to just leave it for 5.5.0. I prefer the new behavior, but sorting out the differences in the qmltypes file isn't something to rush through. I advocate splitting QtQuick out into a new qmltypes file, we can get that done for 5.5.1 or even 5.5.2 so long as it's ready to check cleanly for 5.5 - 5.6. Also detected: the new Shortcut type in QtQuick is properly versioned, hurrah! Well done JP. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt5.5.0-RC snapshot available
On Tue, Jun 9, 2015 at 11:45 PM, Blasche Alexander alexander.blas...@theqtcompany.com wrote: I just went through the git log to confirm. There is nothing of interest to put in the changelog for QtQuick1 or QtScript (I'd be surprised if I found otherwise). Do you really need an empty file there? I'd say yes. It is information for our customers. No file doesn't tell the difference between no difference worthwhile mentioning and we forgot to provide the information. Unfotunately our track record would be an indication for the latter. I suggest to add a changelog with the usual header and as actual content No changes or sth similar. I don't think we've done that before. QtScript has had no changelog since 5.1.1. QtQuick1 has had one changelog (5.3.0, fixed an important bug it seems) since 5.1.1. Given the status of those modules, our track record is indicating the former (at least to me). -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 QML Revision Check
On Wed, Jun 10, 2015 at 2:19 PM, Alan Alpert 4163654...@gmail.com wrote: On Wed, Jun 10, 2015 at 1:04 AM, Alan Alpert 4163654...@gmail.com wrote: I have run qmlRevCheck between the 5.4 and 5.5.0 branches, for the imports in qtdeclarative/src/imports. Results are attached. Results come from generating and parsing new qmltypes files from each branch, and comparing them with the qmlRevCheck tool (https://codereview.qt-project.org/#/c/114038/ is the updated version to build these days). I won't have time to properly look through the results until tomorrow, but there is one key thing to note in the output. qmlplugindump -builtins will spit out QtQuick types in 5.4, but in 5.5 it's a separate file (from qmplugindump -nonrelocatable QtQuick 2.5). I compared the 5.4 file to each of the two 5.5 files separately in the two output files. But it's a lot of noise, and I'm not quite awake enough to filter it out right now. Okay, the analysis of the qmltypes diff shows the following issues: 1) c07f5b801bd6a94fe862073eb1f1965115a56385 (qtbase) adds a transitionType property to QAbstractTransition without versioning it. 2) 44ab79012f1662a4efa7c506b6ebc4466c50b3e9 (qtdeclarative) adds scrollGestureEnabled property to MouseArea without versioning it. Fixes for these should probably be rushed in to 5.5.0 if we still can, given they will probably miss the RC. I can help draft those. 1) https://codereview.qt-project.org/#/c/114141/ 2) https://codereview.qt-project.org/#/c/114140/ These are the necessary changes. If they can't get into 5.5.0 we may as well just cancel them, the damage will have been done by then. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] [QtCS] QtRemoteObjects Session Summary
There was late-scheduled session on QtRemoteObjects at QtCS on
Saturday. QtRemoteObjects is a playground module for object remoting
of QObjects, and can be found at
http://code.qt.io/cgit/playground/qtremoteobjects.git/ .
A brief overview of the existing features:
-Exports QObjects remotely, creates a replicant on the client side you
can interface with
-Network nodes can serve as a registry to allow lookup by name.
-Transport Layer Adapters
-Bjoern is currently working on exporting of QAbstractItemModels
A brief overview of planned features:
-QML API
-Protocol Layer Adapters
-Investigate merge with QWebChannel (sounds similar, of course no-one
working on QWebChannel was present to confirm).
After it is established with those features and solid quality, it
could be considered to promote it to an add-on module.
The idea with protocol adapters is that currently it only sends
QDataStream output over the wire. I want to send more accessible
JSON-RPC (like) data over the wire for working with node, and Attila
had a demo of getting object data from Meteor (although that was
custom hacked for demo purposes). Protocol adapters will allow you to
serialize it in these other forms, and that is the mechanism by which
we gain compatibility with other languages/frameworks without them
needing explicit QRO support - We'll talk their language if there
exists compatible semantics. They'll probably remain separate from the
transport adapters, but we'll see how the implementation develops.
I'll start looking into the implementation this month.
The question was raised How is this not CORBA?. I'm not that
familiar with CORBA (just read the wikipedia article today), but my
suspicion is that we've cut out a lot of the boiler-plate by
leveraging existing Qt Meta-object information. We have a base case
where we aren't a generic anything to anything layer. We have a very
specific Qt to Qt layer which is far easier to use, and it can be
extended to be Anything to Anything but you'll probably end up doing
as much or more work as CORBA if Qt isn't on either side (side note:
I'm expecting Qt to JS/JSON to be another simplified case by
comparison). The convenience of just being able to hook up objects
remotely in QML - without having to write an extra IDL beforehand (it
comes from moc data) - seems transformative. We may even be able to
write a CORBA protocol adapter that would allow it to interoperate
with CORBA on the other side, although it would probably be a lot of
work that no-one wants and would have worse performance.
I was prototyping my own remote objects in QML until I talked to KDAB
at QtCS - my implementation is nascent and will be silently discarded
in favor of contributing to QtRemoteObjects. But to start the QML API
draft, here's what I had in my separate implementation:
QtObject {
id: testCase
property int test: 1
}
RemotingServer {
id: server
target: testCase //This object will be remoted
//Note that URL scheme (http here) selects
transport/protocol adapter
url: http://localhost:3071/; //This is the location it is served at
onRunningChanged: console.log(Server running on + url);
//running property is true iff successfully remoted
}
RemotingClient {
id: client
url: server.url //This is the location of the remote instance
property int test: 99 //This is a property on the remote
instance we want to listen to. Until the remote connection is made, it
will have a default value of 99
//See below description
objectName: client
promotable: true
//Note it's its own target when not promoted
}
The objectName and promotable properties combine to support a specific
use-case I was thinking of. If you expose a QObject from C++ to QML
it's usually exposed like
engine.rootContext()-setContextProperty(app, appInstance). If you
use remoting to serve appInstance from another node, you can export
the remote object in the same place (just on the root context) and
leave the UI code unchanged. All you need is a shell around it that
looks like {RemotingClient{promotable:true} MyRealUI {}} when
launching it on the remote host. The way I implemented it so far it
actually checks that property in the root context first, so that you
can have a RemotingClient{} on the local version which just does
nothing and doesn't get in the way (the URL ended up being left unset
in my example, so it didn't even try to start network communications).
Sharing objectName with QObject is primarily a hack for convenience, I
don't like the promotable name so when someone thinks of a better
name we can use something like betterNameName.
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 header diff: QtDeclarative.diff
I started working on something that would diff QML API changes a while ago: https://codereview.qt-project.org/#/c/52625/ It's a little tricky, but it basically is just diffing the plugins.qmltypes files. After regenerating them and having old full copies because of the manual editing that occurs sometimes. And you need to diff the parsed tree because the order of lines changes sometimes. But I suppose the biggest hurdle to getting that tool in is that I wanted it to run as an autotest and fail if new symbols appear which aren't properly versioned (a little more work than just listing changes). -- Alan Alpert On Sat, Jun 6, 2015 at 2:23 AM, Liang Qi cavendish...@gmail.com wrote: On 6 June 2015 at 10:52, Allan Sandfeld Jensen k...@carewolf.com wrote: On Friday 05 June 2015, Frederik Gladhorn wrote: Would there be any way to generate diffs or changes for QML APIs? Perhaps a diff for all plugins.qmltypes files? But I guess that not all were updated yet. -- http://www.qiliang.net ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] [QtCS] QML Runtime Session Summary
The QML runtime session explained the existence and rationale for the
QML runtime (qtdeclarative/tools/qml). The rationale is that it is
more generic than just qmlscene, yet is configurable to have the same
level of convenience for QtQuick (among others). It has a runtime
configuration file which can identfy a partial QtQuick scene and wrap
it in a simple Window, actually part of the sources and bundled via
QRC. The configuration file could be extended for other partial
scenes, such as if Qt3D wants to wrap a simple viewport/canvas around
any Item3D{} partial scene. As it's loaded at runtime, this would not
add any dependencies on Qt3D for the qml binary.
Given the rationale, there was talk of fully replacing qmlscene to
avoid duplicated maintenence. This would require at least
-Fixing all the docs that still point to qmlscene (everywhere)
-Using qml instead of qmlscene in QtCreator
Anything else need to be done before we can deprecate/replace qmlscene?
There is discussion of extending the QML runtime configuration file to
include configuring options. The concept is that you could use this to
have a custom -help if your running your own executable, or that you
could remap the arguments so that qmlscene could be a specially
configured invocation of the QML runtime (while maintaining
compatibility with all CLI arguments).
There were also some questions about whether certain arguments really
belonged there. It might be possible to hide them, maybe even with a
developer configuration file, but others (especially the ones we
didn't implement from qmlviewer) could be implemented via a shell
QML application. An example of such an application might be useful to
add to the examples directory.
A final point about the configuration file, is that we'll need an easy
way to extend it (especially if we use it to customize options in
certain invocations). The idea I have so far (thought up after the
session) is that the configuration file, or individual types in it,
gain a supplemental property. If that is set on the file, then it
will continue the search for configuration files (in the same order as
dfined already) and add their configurations as well. Common case for
that would be a custom config file which wants the built-in as well,
perhaps even built-in + user settings. That still leaves the problem
that wrappers with custom options will need to have a path to a
deployed conf.qml file which has supplemental set on it, so they can
pass that to -f in their #! line.
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Future of Qt Quick 1 in Qt 5
On Fri, May 8, 2015 at 12:33 PM, Thiago Macieira thiago.macie...@intel.com wrote: On Friday 08 May 2015 16:10:27 Hausmann Simon wrote: Hi, Compilation wise I agree, it's low effort. But the situation is different in Jira IMO. Can we declare the module in Deprecated state and keep bug compatibility with previous versions? If people are using it to transition from Qt 4, it should retain as much of Qt 4's behaviour as possible. That includes buggy behaviour that applications have most likely already worked around. We should fix only security issues, severe crashes and any issue resulting with loading both Qt Quick 1 and 2 into memory. That's what I thought the status was already, and it seems the right level of support for the Qt 5 lifetime. https://codereview.qt-project.org/#/q/status:merged+project:qt/qtquick1,n,z isn't showing a huge burden, Simon said the issue was just JIRA. So maybe rename Declarative (QML1/QtQuick1) to Declarative (2010 ed.) to give the right impression? -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: RAII for property changes
On Wed, Apr 15, 2015 at 8:08 AM, Matthew Woehlke
mw_tr...@users.sourceforge.net wrote:
On 2015-04-15 10:43, Marc Mutz wrote:
On Wednesday 15 April 2015 11:49:56 André Somers wrote:
void MyClass::setFoo(QString value)
{
PropertyGuard guard(this, foo); //foo is the name of the Q_PROPERTY
Q_UNUSED(guard);
m_foo = value;
}
This is an interesting idea, though I don't think I have encountered the
problems with which you motivate PropertyGuard.
I have, it comes up a lot in objects used as an interface to QML
(where every fooChanged signal will probably trigger binding
re-evaluation or JS blocks). I don't think it's that hard to manage,
but PropertyGuard does look easier and saves some boilerplate code.
For use in a library, though, I fear the string-based mechanism is too
inefficient. For use within QtWidgets, say, I'd suggest a mechanism that
works
on the member data directly.
I think it's fine to tie it to the property system, since conceptually
it needs a both a read and a notify on the datum.
For performance, allow passing in a metaproperty index instead of a
property name string. It will still invoke the getter, but they're
rarely that complicated (and when they are, you need to go off the
getter value*).
FWIW I had the same thought; also, I'm not a fan of needing the
Q_UNUSED, or using a macro to 'hide' it.
What about something like this?
QPropertyGuard g{this};
g.addProperty(a); // use QObject::property
g.addProperty(b, m_b); // take value member by reference
g.addProperty(m_c, cChanged); // ...and also slot address
It's slightly redundant because declaring the guard and adding a
property are separate, but there is no unused object, and you can use
the same guard for multiple properties.
The common case is one property I think, so keep that case to one
line. I'd envision using it in all my basic setters to save code at
the start of a project, and then when the features start to creep in
it's easier to add complexity into the setters.
Still, you could always leave in a convenience constructor or just
wrap it in a macro as before.
* Example of when you need to go off getter value instead of member is
usually sometime like implicit width, where the getter looks like
getWidth() {
if (m_width == -1)
return m_implicitWidth;
return m_width;
}
In this case, if you have m_width = 80, m_implicitWidth = 80, and call
setWidth(-1), then you actually don't want to emit widthChanged even
though m_width is updated.
That was just an example, not how implicit width actually is
implemented in QtQuick.
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Is QML Item design deliberately hindering C++ interaction?
On Mon, Feb 2, 2015 at 3:43 PM, Alex Montgomery apmontgom...@gmail.com wrote: Is it a design goal of QML/Quick to discourage C++ interaction? I ask because every DevDays talk I attend includes some version of the phrase any reasonably complex QML application will have C++ doing its back-end work, but yet I keep running into QML classes that hide important Qt C++ classes / data in their private implementation. I honestly am just trying to figure out if the philosophy of Qt Quick is to facilitate C++ interaction or discourage it. The strangest example of this push-pull is how Qt Quick handles drag and drop. If you derive from QQuickItem to handle drags, you get the classic Qt C++ API that uses classes like QDragEnterEvent and QDropEvent. Awesome. If you instead want to handle drops in QML, you get the Frankenstein class DragEvent, known in C++ as QQuickDropEvent. This class is a strange mix of C++ only and C++ hostile. If a drop has urls in its mime, you must use the urllist property, which is complete opaque/unusable to QML, so must be handled in C++ (See https://bugreports.qt.io/browse/QTBUG-42277 ). However, if you want to access the mime type directly and read custom mimetypes in C++, you can't, because QQuickDropEvent does not expose (but does keep internally) the actual QDropEvent that it encapsulates. So if you want to make custom mime data with bytearray-style blobs, you have to rely on its invokable function getDataAsString which may or may not mangle your binary data. I honestly can't tell. If I do a toLatin1() on it, will I get back the exact data in the mime type? I'm skeptical at best. TLDR: Are QML classes supposed to rely on C++ interactions or are they supposed to abstract them out of C++'s reach and force programmers to handle events in QML? I really want to know, because the answer right now seems to be both and it makes good architecture nearly impossible. The good architecture, which is conveniently supposed to be enforced by our inflexibility, is for QML to be the front-end/UI layer and C++ to be the back-end/business layer. So abstract data is supposed to be easy to pass between the two, but UI classes (like QDragEnterEvent) are not. The custom Items case goes against this intended split. Custom QQuickItems is not the C++ interaction that we commonly expect in QML applications, and having to create your own custom QML items in C++ should be far, far rarer than creating your own custom QWidgets was. If you are creating custom items you are going to hit some rough spots due to the UI layer trying to stay contained from the C++ back-end. In general we prefer to extend the functionality of the QtQuick elements and the QML language to remove the need for custom QQuickItems. That said, we still want custom items to be possible and not too hard - the need is lessened compared to widgets but certainly not gone. Binary data handling is something that we don't currently support in QML well, and until we do custom QQuickItems seems like a reasonable solution. This specific case is just a defect in our handling of drag and drop (one of the more immature parts of QtQuick, I'll admit). It should certainly be possible in theory to do custom binary mime data from a custom QQuickItem, and it sounds like the current implementation doesn't support that as well as it should. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Requesting a break in behavior in QML Text element
/12/opening-a-file-in-qml.html just to be able to read a file. And I/O should be more agnostic about local and remote resources, as long as the fact that you are doing I/O is explicit rather than unintended. Sometimes you want network access to be really easy. Other times you want to avoid security problems that come from unintentional network or filesystem access. So we need to make it easy to go either direction, and enforce it consistently. On this point, I'm hoping that we can make QML more flexible. Depending on how your configure your QQmlEngine, it could be as locked down as HTML or as open as native C. Which I currently imagine to be implemented mainly by import restrictions and easy local file I/O would go in a separate QtQml.* import (like how creating new windows goes in a separate QtQuick.Window import). That's the goal, and makes it easy in both directions, but it does mean local I/O should be handled differently in order to be consistent down the line. Until then we need to maintain the current behavior where a custom QNetworkAccessManager can intelligently deny most requests, routing through QNAM is why I/O is remote focused right now. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Modifying QQmlFileSelector selector at runtime without Loader or Component
On Fri, Dec 12, 2014 at 8:29 PM, achart...@fastmail.fm wrote:
Hello,
I would like to modify the extraSelectors of QQmlFileSelector at runtime
and have QML load the new QML file from the appropriate selector folder.
I have gotten this to work by calling setExtraSelectors() from a C++
object I have exposed to QML and then forcing a re-evaluation of the
Loader's source property:
Loader {
id: myLoader
source: Qt.resolvedUrl(MyItem.qml)
}
Connections {
target: myCppObject
onSelectorChanged: myLoader.source = Qt.resolvedUrl(MyItem.qml)
}
Now, for my use case I really need the ability to achieve the same
behavior without using Loader or Component. I essentially want something
like this:
MyItem { }
Connections {
target: myCppObject
onSelectorChanged: // when selector changes, the MyItem instance
above is automatically resolved to the MyItem definition in the
appropriate selector folder.
How can this be accomplished?
This cannot be accomplished (I actually tried last year). The problem
is that you have an actual instance of MyItem there, and there's no
way to magically map it into another instance. You have to destroy
that instance and bring up a new one - which basically means Loader.
What you probably want is to have certain parts of the instance shift,
but not destroy the whole instance. For that I recommend using QtQuick
States. You can have a base state, and then a list of property changes
to things within the instance in a sub state and use transitions to
animate it. That shifts the parts of the instance that need to,
without destroying the whole thing. Or save state in another object
(such as in a QtObject{} on the Loader) and bind your internal state
to that so that you can use the Loader approach to recreate whole
instances.
PS: Moving to qt-interest since you didn't seem to be offering to
develop this feature as a part of Qt.
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] bundle support in QML
On Tue, Dec 2, 2014 at 5:27 PM, Chris Adams chris.ad...@qinetic.com.au wrote: Sure. I think there are advantages to be had from bundling, obviously, but those don't really exist right now. +1 from me. I'm of the same opinion. Can't defend keeping it, if it's not actually providing any value right now. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML and UUID
On Mon, Aug 18, 2014 at 4:59 PM, Thiago Macieira
thiago.macie...@intel.com wrote:
On Tuesday 19 August 2014 01:36:54 Renaud wrote:
Hi all,
I am running into issue when I try to use QQuickImageProvider and
QUUID.toString().
I store my images into mapQString,QPixmap. The key is the uuid
(stored as QString) from instances of my custom class.
So, stored keys in the map are like this:
{22715e73-e6ca-4cca-a77d-fe68746b9f79}, but when my QML component asks
to the provider, the provider receives this kind of key:
%7B22715e73-e6ca-4cca-a77d-fe68746b9f79%7D.
It can not find any match. Is There a way to prevent the modification
in QML world ?
Of course, I can implement some workarounds, such as remove curly
braces or use other kind of key. But it will be really painful.
That's a URL transformation.
How did the string come from QML world? Did you pass it to a function that
expects a URL?
Yes, QtQuick image providers look like this in the QML file: Image {
source: image://myimageprovider/key } . The URL gets broken down and
the key gets sent to the appropriate QQuickImageProvider.
The idea is that the key should be something human readable, but if
you need to pass through machine-readable UUIDs then probably just use
the URL decoding functions on it.
See also: http://qt-project.org/doc/qt-5/qquickimageprovider.html,
http://qt-project.org/doc/qt-5/qurl.html#fromPercentEncoding
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt6, Qt7 roadmap?
On Sat, Aug 9, 2014 at 7:21 AM, charleyb123 . charleyb...@gmail.com wrote: Just a silly question related to the Qt roadmap (I don't want to distract this weekend's Qt5.4 freeze-activity): Qt6 (and even Qt7) has been mentioned on this list in the past year, and I was curious if there were a 30,000-mile-high-view of what might be on-deck for consideration. A web-search or qt-project.org search doesn't really show much discussion: https://qt-project.org/search/tag/roadmap A Jira Road Map report doesn't really show much: https://bugreports.qt-project.org/browse/QTBUG#selectedTab=com.atlassian.jira.plugin.system.project:roadmap-panel For example, Qt5 might be summarized something like (I'm sure I'm missing some): *- New modularized-library infrastructure *- C++11, function-pointers for signals/slots *- QML as solid dev/deploy platform *- Balanced focus on both desktop and mobile *- Connectivity/Networking improvements *- Big investments in OpenGL, Qt3D *- Deployment of new Qt Platform Abstraction *- Mobile deployment, App-store deployment *- New platforms, (e.g., Android, iOS, Win8, WinRT, BB10, ...) *- Transition from QtWebKit to QtWebEngine *- Start of rework on QtPrinter *- etc. IMHO, that's a pretty fantastic list (and I'm sure I've missed some). When you throw in tremendous advances in QtCreator, embedded-device and Boot-to-Qt support, and work on QBS, and new features like Enginio (web/cloud), it speaks a very compelling story. Possible future items might be something like: *- ?? C++14/17 support (recall that the C++ Standards committee is looking at speculative work to support modules and possibly runtime-reflection, and I know Thiago has been looking at how that might be relevant to Qt/signals-slots/role-of-moc) *- ?? Qt3D advances *- ?? QML packaging/plugins/deployment work *- ?? Cross-process signals/slots (pretty please? ;-)) *- ?? New modules *- ?? As Robert mentioned, Qt 6 break would be for breaking current features, not adding new ones. Odds are it's going to be driven from the QtQuick/QtQml side, as that's the part with the most stuff we want to break. So when we want to switch to QtQuick 3 and version 3 of the QML language, that's when I expect we'll start planning a Qt 6. We're not there yet, but there are some things in QtQuick which are already scheduled for QtQuick 3 (when we get around to it). In particular the Window type needs to be broken out to be a QML-only wrapper type, based on QQuickItem, instead of exposing QQuickWindow directly. A bunch of properties also where we might want to change the default value, but that's just breaking stuff so it depends on how much of a break we want QtQuick 3 to be. We already know that we want it to be less of a break than QtQuick 1-2; since we don't expect to replace SceneGraph that could mean that QtQuick 3 and QtQuick 2 elements could co-exist on the same scene. It's also expected that the new ModelViews would replace the current ModelViews in QtQuick 3. Given how we haven't even completed the research phase of the new ModelViews, you can see that QtQuick 3 is likely still years away. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] How does QML versioning work?
On Sun, Jul 27, 2014 at 11:59 PM, Koehne Kai kai.koe...@digia.com wrote: -Original Message- From: development-bounces+kai.koehne=digia@qt-project.org Subject: [Development] How does QML versioning work? Hi all, We have a very clearly defined policy on what changes are allowed new versions of Qt: - Patch release: Source binary compatible bug fixes only - Minor release: Source binary compatible bug fixes and new features - Major release: Incompatible changes allowed What about QML modules? I couldn't find a similar policy outlined anywhere; does one exist? No separate policy exists. It's the exact same policy for Qt QML APIs as Qt C++ APIs. At least, it is at the high level described above. See http://qt-project.org/doc/qt-5/qtqml-cppintegration-definetypes.html#type-revisions-and-versions for how this gets implemented in QML versions. The only difference is that QML modules are using divergent version numbers to Qt (which was originally something that C++ modules were going to do as well, but I don't think they are right now). So those rules need to be applied to the QML module version, not the Qt version. QML modules all move at different rates and the maintainers can choose to advance faster or slower than Qt if needed. Speaking as QtQuick maintainer, we are not moving faster or slower than Qt for the forseeable future. So since QtQuick is at v2.3 in Qt v5.3, we'll be at v2.4 in Qt v5.4, under the above Minor release constraints. Same policy, different numbers, different implementation. I'm not sure it's written down anywhere. Anyhow, that's how _I_ understand the policy so far: - The major number is bumped for rewritings (e.g. API is removed, or altered). - The minor number is bumped for new API. - Fixes that do not introduce new API (behavioral changes) do not require a version change. Qt Quick modules have to keep the source/binary compatibility promises of Qt, but are otherwise versioned independently. That is, - All import versions have to be supported until a new Qt major release. - Qt minor releases might contain new imports, and new import versions. - Qt patch releases might contain new import versions, too [1]. - Import versions do not need to be bumped in a Qt release. This is all correct, although I prefer my explanation ;) . Regards Kai [1]: There's precedence for this in Qt 4.x times, and actually one of the reasons why a separate scheme for e.g. QtQuick was introduced. Anyhow, it's IMO something best to be avoided. It is best to be avoided, but there are cases, like in Qt 4.7.4, where it's the lesser of two evils. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] How to have equivalent of function over-riding in Qml
On Wed, Jul 9, 2014 at 8:41 PM, travik ravikiran.tallapa...@wipro.com wrote:
Thanks for the very quick reply.
Thank you for clarifying my understanding of correct derivation in Qml
Regards,
R.kiran
Hi In continuation of the previous post - I now got it working to invoke
the base class / derived class implementations correctly from extenal
place.
Now the question is: Can I have my derived class, call the base class
implementation as part of its functionality?
C++ equivalent would be something like this:
class Base
{
public:
void method1()
{
std::cout Base::method1().. std::endl;
}
};
class Derived: public Base
{
public:
void method1()
{
std::cout Derived::method1()..pre.. std::endl;
// Derived class uses the base class implementation fully
// and does something extra on its own.. true case of extending the
// functionality, if I may say so!
Base::method1();
std::cout Derived::method1()..post.. std::endl;
}
};
Qml Equivalent would be (to the extent I have figured out)
Base.qml
Item
{
function method1()
{
console.log(Base::method1()...)
}
}
Derived.qml (in the same folder as Base.qml)
---
Base
{
function method1()
{
console.log(Derived::method1()...)
}
}
I tried this, it ended up in recursive loop, obviously!!
Derived.qml
---
Base
{
id: myBase
function method1()
{
console.log(Derived::method1()...pre)
// myBase.method1() // --- calls the same method recursively
// Base.method1() // --- this line gives undefined object,
naturally!
console.log(Derived::method1()...post)
}
}
This is not currently possible. I think a mechanism for it was
proposed at QtCS (can't find the notes) but is not yet implemented.
As a workaround, you can do something like the following
Base.qml
--
QtObject {
property var method1: __method1
function __method1() {}
}
Derived.qml
--
QtObject {
method1: __method2
function __method2() {__method1();}
}
Then, in other files where you call method1(), it uses the JS var
(pointing to the function) which had its valued changed in the derived
class.
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] QtQuick QtCS Sessions
Here are the results and brief summaries of the 3 QtQuick related sessions, where we came up with some suggested new properties and types for QtQuick. Touch and Gestures: http://qt-project.org/groups/qt-contributors-summit-2014/wiki/QtCS14TouchAndGestures No real solution other than handling Mouse, Touch, and Gestures (system gestures, no gesture manager). Also looking into new grab transfer mechanisms in QtQuick, such as a MouseArea.priority property for automatic transfer. QtQuick: http://qt-project.org/groups/qt-contributors-summit-2014/wiki/QtCS14QtQuick Proposed new module, QtQmlGui (working title), which exposes non-core stuff to QML but can be shared between QtQuick and other modules (like Qt3D). Proposed new types, PolarPositioner, MouseRegion, TextContainer. Declarative QML: http://qt-project.org/groups/qt-contributors-summit-2014/wiki/QtCs14MoreDeclarative Proposed new property, deferredLoading, on Item, to solve the less dynamic uses of Loader. Proposed new element, StateChange, to allow more declarative state changing. Big solutions of pull bindings and a pragma strictly-declarative are a lot of work, unlikely to occur soon. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt 5.3 qmltypes update
If your module has QML types, and you provide a qmltypes file, you still need to update those manually each release. Until we have an automated tool for this (I started work on one in 5.2, but it doesn't work anymore), a manual inspection of the qmltypes file diffs can also help identify any QML type revisioning errors (or accidentally exposed members). I recommend you do this if your module has QML types. I've done it for qtdeclarative just now (apologies for being a bit late in the release process), it resulted in two changes; one for qtbase and one for qtdeclarative: https://codereview.qt-project.org/#change,84465 https://codereview.qt-project.org/#change,84468 Mostly just people forgetting to revision new signals, but one lucky guy got his code into 5.3 when he clearly wasn't expecting it to make it until 5.4 ;) . Ideally when we have an automated process for updating qmltypes, it can do some replacement logic to pick the minor version for new features instead of people having to guess. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Perceptions/Understandings of the QML language [was: Question about Qt's future]
On Tue, Apr 29, 2014 at 11:32 PM, Rutledge Shawn
shawn.rutle...@digia.com wrote:
On 29 Apr 2014, at 7:51 PM, Alan Alpert wrote:
(3) Document that accessing ids from other .qml files without any interface
(just relying on the fact that they are in the context) creates hard to
maintain QML code.
Agreed (honestly, it should already be there, I guess
https://bugreports.qt-project.org/browse/QTBUG-20453 was never
finished...).
Again, we have some rough plans for a .pragma strict. Which should ban
this.
What exactly do you want to ban and what are the best alternatives? Without
any interface implies there is a right way to share.
Correct answer: Define an interface. Probably best explained via the
attached examples: Bad has no interface defined for the object
reference, Good does.
Runner up: Singletons. When you can't or don't want to pass references
to individual object instances, you can pass it to a shared interface
instance and use that. Which is QML singletons, and is fairly
convenient already (though there are known issues like QTBUG-34418
which can make it less convenient than it should).
Workaround: Shared JS file. Does most of the same stuff as the
singleton (biggest exception: QTBUG-21844 ), and is available in
earlier versions. Should singletons be available, use them instead as
they have the declarative and typed interface benefits.
In practice I'm often not sure about the scoping rules, so when something
that I think should be accessible is not, I'm often not sure if that is a bug
but just start looking for another way to do it (which sometimes can be
clumsy).
If an id is not in file scope, then it's either a bug or an ugly
hidden feature that we keep around for convenience but you aren't
supposed to use ;) .
--
Alan Alpert
import QtQuick 2.1
MouseArea {
onClicked: anItem.color = blue
}
import QtQuick 2.1
MouseArea {
property Rectangle target
onClicked: target.color = blue
}
import QtQuick 2.1
Rectangle {
id: anItem
color: red
width: 200
height: 200
BadUser {
anchors.fill: parent
}
}
import QtQuick 2.1
Rectangle {
id: anItem
color: red
width: 200
height: 200
GoodUser {
target: anItem
anchors.fill: parent
}
}
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Perceptions/Understandings of the QML language [was: Question about Qt's future]
On Wed, Apr 30, 2014 at 6:33 AM, Simon Hausmann simon.hausm...@digia.com wrote: On Wednesday 30. April 2014 15.25.35 Hartmann Thomas wrote: Hi, the original idea was to get rid of the need to write Java Script to change a state (state = newState) and find a declarative way to change states. The rest then came naturally. Right. While we're on the state property: It's publically accessible through setProperty/property. Does anyone know a reason as to why the setState/state setters/getters aren't public API in QQuickItem itself? (but Q_PRIVATE_PROPERTY) The QString state property and setState/state setters/getters are public API in my checkout of QQuickItem (release branch). -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Perceptions/Understandings of the QML language [was: Question about Qt's future]
On Tue, Apr 29, 2014 at 12:43 AM, Hartmann Thomas thomas.hartm...@digia.com wrote: Hi, On Mon, Apr 28, 2014 at 2:34 PM, André Pönitz apoen...@t-online.de wrote: I think at least three modifications are inavoidable: For one, things that could be written in a declarative way but which currently are only possible using JavaScript, a declarative way should be added. Second, it should be stressed in the documentation (including the examples), that using inline imperative code is naughty. This can be supported by e.g. the QML Designer refusing to operate on such files. People can still do that, but would be on their own. And finally, and that's also acting as a proof that the first two items actually have been done, the JavaScript dependency should be _optional_. Can we turn this into action points we _all_ agree on? My personal favorites are (In no strict order): (1) Identify non declarative parts of Qt Quick and add declarative API (e.g. setting states) Agreed. This is my personal favorite ;) . (2) Document that inline Java Script and mixing declarative and imperative code in one file has its pitfalls in big projects and creates issues for tooling. Explain the difference between pure declarative QML and QMLJS and the impact on tooling. Agreed. While I think that mixing declarative and imperative code in one file has it's advantages in small projects, there should be a clear line between pure declarative and toolable vs you're on your own. I'd like to see something like .pragma declarative which defines this line, such that if you add .pragma declarative un-toolable JS blocks or bindings become compile errors. (3) Document that accessing ids from other .qml files without any interface (just relying on the fact that they are in the context) creates hard to maintain QML code. Agreed (honestly, it should already be there, I guess https://bugreports.qt-project.org/browse/QTBUG-20453 was never finished...). Again, we have some rough plans for a .pragma strict. Which should ban this. (4) Writing (more) QML(JS) static analyzers that can check/enforce a proper strict mode for QML. Agreed, see .pragma strict comments. Speaking of which, this idea has been around for a while: https://bugreports.qt-project.org/browse/QTBUG-30069 (5) Write refactoring tools that help to clean up existing code. Kinda agree. If we have the two .pragma's mentioned then this is purely a convenience step (because they can find all cases by using the .pragmas). It's probably not worth writing a full refactoring tool that can turn anything into a .pragma declarative/strict file. Just do what's convenient to tool and users can do the rest (if they wish). (6) Fix/cleanup existing demos and examples. Agreed. This is probably a good step to do in conjunction with (1), so as to ensure that the added declarative APIs make sense. In most cases, the added declarative APIs should make more sense even for the primitive (non-tool) users and we can verify it here. (7) Investigate how we can improve the interplay of QML and C++. Especially in C++/backend heavy projects. Agreed. Known issues: https://bugreports.qt-project.org/browse/QTBUG-33233 https://bugreports.qt-project.org/browse/QTBUG-23052 https://bugreports.qt-project.org/browse/QTBUG-19212 Can't find task: More powerful QJSEngine API so that C++ value-type-like objects can be exposed as JS objects when you want more control at the cost of convenience https://bugreports.qt-project.org/browse/QTBUG-21844 (in conjunction with above) But there's probably some additional research to be done too. As a second step the actual work has to be done of course. Yeah, that's always the biggest issue... Every time these discussions come up there's no major theoretical point of contention. It's just that the work still hasn't been done and we all like arguing. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Perceptions/Understandings of the QML language [was: Question about Qt's future]
]. It also feels like API reviews for QML are less rigorous than for C++, [5] but that topic is for another day. Same as in C++, those both depend on the individual reviewer. There's just less general consensus available for QML, because it's so new, so I'd recommended adding more reviewers for QML doc/API reviews (and giving longer for comments before merging) compared to C++ reviews. But that again depends more on the individual contributor and how big a rush they feel they're in. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Perceptions/Understandings of the QML language [was: Question about Qt's future]
On Mon, Apr 28, 2014 at 12:16 PM, Bubke Marco marco.bu...@digia.com wrote: Alan Alpert: That said, part of the path from becoming a trailblazer to being the dominant force ruling the world is IDE and tooling support. We want to improve tooling capabilities wherever we can do so (without compromising the 'untooled' developer experience - I know they Hmm, again a hard code programmer who is writing his code in CLAY with his own fingertips. Sometimes he thinks about using this new tool Stick but that would be uncool. ;-) I want Clay, Stick and Pen (a mythical future development, the likes of which we cannot even imagine!) developers all supported. Just because I'm set in my ways doesn't mean that I should force them on others, or be shunned because I'm different. The path of the idealist is hard, but ultimately rewarding. frequently clash, and the direct dev exp. takes precedence IMHO). This may require fresh new trailblazing tools, but that's just the nature of progress. So we waiting that you writing this fresh new trailblazing tools! But maybe you like more to stick with your fingers in CLAY. ;-) I'm happy with my current tool set. My point here was more that we *may* need to innovate on the visual tools, and not end up with a clone of Qt Designer. But since I don't use the visual tools, I'm not the authority here. I just want us to consider that both sides, the tooling and the tool-ability, are flexible so they may both grow to meet in the middle (conceptually grow, in terms of implementation you've obviously grown the QML tooling a lot already). -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Perceptions/Understandings of the QML language [was: Question about Qt's future]
On Mon, Apr 28, 2014 at 2:34 PM, André Pönitz apoen...@t-online.de wrote: On Mon, Apr 28, 2014 at 11:12:47AM -0700, Alan Alpert wrote: Yes, I agree that more rigorous and agreed definitions would be helpful. It also takes time, and impedes innovation, so I'm not sure if we're quite mature enough to nail down QML just yet. Should be soon though, in the next few years. To get this straight: After five years of development the Maintainer of the Qt Declarative module is neither able nor willing to give a simple definition of what QML is. Able, yes. Willing, no. The totality of the experience can and should depend on the reader at this stage. To put it another way, if I just say what QML should be it will be sufficiently divorced from reality as to be useless. For example, QtQuick and QML should have a good C++ API, and good tooling which both supports writing the QML/JS/C++ code faster and visually designing (in strict mode) components made from all three languages, while always maintaining a live preview on device. That one sentence requires years of work to implement, and doesn't even touch upon the primary goal of QtQuick (that skilled developer-designers can create custom user experiences efficiently). Note that the primary goal of QML is to support QtQuick in this endeavor. Until the ideal world is in sight, it's an expedient method to take a reasonable current state and iterate on it based on user feedback. Hopefully when we redo this discussion for Qt 6 and QML V3.0, we'll be where we can look at the gap to the ideal state and cut it into manageable chunks. I'm willing to give this a try at the contributor summit, but I still think we're too far away for that to be more productive than targeting current user pain points directly. PS: Despite the near infinite gulf to perfection I still think we're closer than any other UI Framework ;) . -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.3 header diff: QtQuick
On Wed, Apr 23, 2014 at 3:56 AM, Simon Hausmann simon.hausm...@digia.com wrote: On Tuesday 22. April 2014 16.37.50 Thiago Macieira wrote: Em ter 22 abr 2014, às 14:12:46, Thiago Macieira escreveu: http://macieira.org/~thiago/qt-5.3/QtQuick.diff Looks fine from the C++ side. I have no clue what those Q_REVISION changes do to QML. I don't think we need them actually, but they won't hurt :) I don't think there's any way to revision the added RESET signal. But since it's a bool, code that tried to assign undefined wouldn't have compiled before anyways. The Q_REVISIONs look like they're on new signals, in which case they are actually needed. But this means the changes look fine from the QML side :) . -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changelogs for 5.3.0
On Tue, Apr 22, 2014 at 3:13 PM, Thiago Macieira thiago.macie...@intel.com wrote: Please find attached the raw logs for each of the modules that had any [ChangeLog] in the v5.2.1..origin/release range. I'm taking responsibility of editing the one for qtbase. For all other modules, I'd like someone to reply to this email saying they'll be the editor. Otherwise, there will be no changelog for the module at all, because I won't do it. I'll edit qtquick1. First draft at https://codereview.qt-project.org/#change,83982 (and it's just one item... probably ready to go). Also qtdeclarative, which I didn't see in the attachments, but running the script and adding the output to the existing changelog gives another 'first' draft: https://codereview.qt-project.org/#change,83983 -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QScreen API
On Thu, Apr 17, 2014 at 7:54 AM, Aleix Pol aleix...@kde.org wrote: Hi, Yesterday I was trying to figure out a problem I've been having on some code that keeps track of screen management changes on my system. After some investigation I came to the conclusion that my problem was in Qt [1]. I'm sending this e-mail to know what's the status on the subject, if this is something we'd like to fix or we have to adopt a solution specific for the project (actually we already have a libkscreen, that would work). Still the current state doesn't look good and we probably want to have it fixed in Qt. That bug sounds like it's in the xcb platform plugin and should be fixed there. Furthermore, we realized that there's some API we're lacking as well, at least we'd need to have a QGuiApplication::primaryScreenChanged signal and probably a QGuiApplication::screenRemoved signal as well (this way we wouldn't have to connect to QObject::destroyed on the screens). Those signals both make a lot of sense. It also makes it sound like we might want some sort of Screen manager abstraction in Qt 6, which could do all this change handling plus be aware of virtual desktops and stuff. TL;DR, what do the maintainers think of the screen management API we have? Is anybody working on it? Is it documented anywhere why it was designed this way? Am I missing something? I am not too happy with the screen management API we have. Here's a short rant: It doesn't work conveniently cross-platform (or reliably across all platforms). You can technically do most of what you need about hardware screens, but it's confusing when virtual desktops span screens (and it sounds like it's missing some APIs for that as well). I've been looking into QML abstractions to make it easier for QtQuick, but the QScreen APIs work on so few platforms that I've given up for now. The one case where the API does work is when plugging an HDMI output into a BB10 device. So the mobile/embedded usecase of a completely separate screen works on one platform, but isn't easy (presumably a lot of QNX cases would work too, but the embedded world doesn't talk that much). I don't know whether app developers want to think about one virtual desktop or multiple physical screens in most cases. Think about a cross-platform app written for mobile which might just want another window instead when on desktop. Or a desktop app might want to use a secondary screen when available on mobile but doesn't care about the existence of two physical screens on one virtual desktop. These cases are quite a pain to implement right now, if at all possible (I haven't tried, but I assume something could be hacked together which no-one would be proud of). -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QWindow::setScreen() and QQuickWindow
On Wed, Apr 16, 2014 at 6:18 AM, Rafael Roquetto rafael.roque...@kdab.com wrote: On Wed, Apr 16, 2014 at 02:47:03PM +0200, Friedemann Kleint wrote: Hi, actually re-creating the window is a bit wasteful given that the screens are part of a larger virtual desktop in most cases. A move() would be sufficient. The QWindow/QScreen logic as it is is somehow not well suited for virtual desktops in which the screen is determined by the geometry. I see your point, but in practice, specially in embedded systems, the larger virtual desktop premise is not valid. BlackBerry phones have an extra HDMI port apart from their own display that behaves idependently. Also, the way I came accross this bug was on an embedded system with two independent screens. I just wanted to let you know the context. So maybe we should go the documentation way? It's best for now to just add the documentation over changing behavior. At some point we need to harmonize the multi-screen APIs so that it works consistently on desktop, embedded and mobile (because currently it only works right on BlackBerry phones). But I believe that's scheduled for after we harmonize the multi-window APIs to work consistently on mobile (i.e. Android). -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QWindow::setScreen() and QQuickWindow
On Fri, Apr 11, 2014 at 12:56 PM, Rafael Roquetto
rafael.roque...@kdab.com wrote:
Hello,
I have been investigating an interesting bug (using QNX as the platform for
Qt). Here is a brief summary:
(all code inside main() and before app.exec())
QQuickView v;
v.setScreen(someSecondScreen);
v.show(); // works as expected
but
QQuickView v;
v.show();
v.setScreen(someSecondScreen); // window is never shown
Is this the expected behavior?
Yes. setScreen expects to destroy the backing window and recreate it,
so it passes onto users the expectation that they will have to reset
all window properties afterwards.
I'm not sure what QQuickView should do, but in the declarative case
where you might have a Window { visible: true; visibility:
Window.FullScreen } it would be expected to reset all the properties
to what's in QML. I doubt it does that yet, and that's a bug ;) .
The reason this happens is because
QWindow::setScreen() calls destroy(), which triggers setVisible(false).
Afterwards, it calls create() but create() never bothers to display the window
again. In other words, it does
QWindow::setVisible(true) //coming from show();
QWindow::setVisible(false) //coming from setScreen() - destroy()
For some reason beyond my knowledge, QtWidgets do not suffer for this bug,
i.e.:
QWidget w;
w.setScreen(secondScreen);
w.show(); // works!
and
QWidget w;
w.show();
w.setScreen(secondScreen); // also works
I digged a bit inside the QWidget code and it also follows the pattern of
having setVisible(true) followed by setVisible(false) called, just like in the
QQuickWindow case. However, something is happening that in spite of that the
widget is being shown regardlessy.
Any thoughts? Comments?
Last time I was playing around with multiwindow support (about a year
ago), QNX was the only platform where setScreen worked reliably. So
the strange stuff happening could be related to the platform
implementation, as we have no other platforms to compare it with. It
also makes it hard to determine the correct multi-screen API, when
there's no clear picture of how it would work on the majority of
platforms.
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML testing
On Mon, Mar 3, 2014 at 3:39 PM, Joshua Kolden jos...@crackcreative.com wrote: Sorry, one other thing. It would also be great if the qml test framework could understand javascript .map files so as to point to the correct source file lines. (http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/) You should file a suggestion on bugreports.qt-project.org . That sounds like an interesting feature, which could benefit Qt Creator's JS debugger as well, but it might be worth waiting until it's standardized before adding it to QML. On Mar 3, 2014, at 3:34 PM, Joshua Kolden jos...@crackcreative.com wrote: I've done a buch of work with TDD and qml now, and built a very nice test framework in coffeescript with before each after each; nice spec style 'it has a feature`, signal handling, color coded output the whole bit. There are, however, two remaining big frustrations that make continuous testing during development very challenging. One is the tendency for the test runner to pull focus, for longer running tests it makes it nearly impossible to leave the test system running while coding. Every time you save a watched file focus is pulled away from the text editor and may or may not ever come back. If one is working in full screen mode on a mac then the entire screen is shifted to a different desktop even if no actually GUI pops up. Is there any way to keep this from happening? I'd like to know this too, because there's the same problem with the QtDeclarative tests. As far as I know, if you're testing window focus it's just not avoidable. The second issue is the hard stop on test failure. Actually there is even a hard stop if a SignalSpy.wait() doesn't receive it's signal. It may not be an error for a signal not to fire, so I don't agree with the behavior that SignalSpy.wait() fails hard. However, even the test conditions shouldn't stop code execution. It makes it very hard to predictably reset the environment for the next test. I can't do things like after each test dump the LocalStorage, or prior to each test ask my web service if a test object still exists (wait for signal from XMLHttpRequest) and call the server's delete api if it does, and move on to the test either way. I'd love to be able to wait for either success or fail signals at the same time so I can jump right to debugging the issue instead of simply getting a uninformative failure because a success signal did not fire, but as it is I can only include SignalSpy.wait if it is exactly the only thing I expect to happen. I can call wait() a nd then look at each spy's count, but that makes the test very difficult to read, and starts spinning off into absurd complexity in every individual test to handle just a few conditional signals. I think the call wait and check case is what you're expected to do here. Couldn't you just write your own wrapper over that to prevent the complexity skyrocketing in your tests? I haven't seen testing of conditional signals much though, so I could be misunderstanding how they're being used. So I'd like to know if there is any way to alter these two behaviors as it stands now now. I'm hard pressed to understand a reason to fail hard when a test condition fails, is this deliberate behavior? Yes, a general premise in QtTest is that test failures are blocking. If you hit a case where the test fails then the state is presumed to be invalid and the test case is not continued. The alternative is to have the possibility of confusing run-on failures. I don't know how it works with TDD, but at least when you write the tests second then every test failure should be fixed - so you may as well fix it and then re-run the tests for the next bit. Also, I'd like to ask whoever is working on the QML test case stuff if these are features that could be included in the near future (perhaps even as the default behavior). If you find a way to change keyboard focus inside the window without changing the window focus, I would love to see a patch submitted for that on gerrit. As always, the best chance of seeing it included in the near future is to submit a patch. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Ameliorate API Reviewing (Was: On the effectiveness of time based releases)
On Tue, Feb 25, 2014 at 7:45 AM, Friedemann Kleint friedemann.kle...@digia.com wrote: Hi, - Have an API review board, and for A review board would indeed be a good thing to have, not necessarily restricted to API reviews only. The problem also currently is that reviewers are distracted by a lot of mundane things (check for compilation, compiler warnings, check indentation style, style issues, check for potential performance issues, messages, spelling, functionality smoke testing, checking autotests...), potentially over quite a few review rounds. Actually, my thought about the API review board is that those reviewers, when pulled in, are looking only at the API. They can ignore all that other stuff, leaving it for someone else to review, and just leave their +1 if the API is good. Or a +2 if another developer already checked the implementation part. If there was a review board (supported by more automated testing) making sure each change passes all those criteria before a developer gets to see it, it would be a lot easier to focus on the API. One thing's for sure, if we have a review board we need a clear policy on whether to call them in first or second. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Ameliorate API Reviewing (Was: On the effectiveness of time based releases)
On Mon, Feb 24, 2014 at 10:22 AM, Thiago Macieira thiago.macie...@intel.com wrote: Em seg 24 fev 2014, às 19:00:28, Frederik Gladhorn escreveu: Some of those features then either caused regressions (... ok, that's what betas are for, although it may also be a symptom of poor testing in order to get the feature in), or are highly debatable from an API / technical point of view (which is even worse, because we can't change APIs or behaviour once we release). Yes, I feel we haven't reviewed new public API in a sensible way. Any suggestions how to make this work? In the Nokia days (and earlier of course) there were long long sessions discussing API and perfecting it. In a sense it's really hard to achieve the same over IRC and mail, but maybe we should come up with a better way of dealing with this. I agree with the rest of what Frederik said, so I'm deleting it and focusing on the part above: API reviews. Yes, that needs work. Which I think is mostly independent of the branching/releasing discussion (on which, my opinion is that the release team can decide - if I learned dev/stable/release at their request I can learn anything ;) ). From our release guidelines, alpha means we're releasing something for which the functionality will be reviewed. So API reviews done before an Alpha are to guarantee minimum alignment with Qt API guidelines. I've done several of those and I've seen others do the same, so it seems like we are doing it. However, since the point of an Alpha is to gather feedback on the functionality and API, it's not frozen in time. There's a lot of opportunity left to review it and modify the API. So a second round of comprehensive API review on any new things should be done after the alpha. Of course, this all depends on the size and complexity of the API. For smaller things, there probably won't be any controversy. For bigger things, stakeholder input is required even before merging into dev -- that was the case, for example, for QFileSelector. Finally, note that alpha is not a review of the *implementation*. That's what the beta is for. But even if that is done at the beta release, we still need to have good implementations. Sloppy code won't be accepted. So why can't we do the same for the API? Unlike code, the problem is less about it being sloppy and more about it being imperfect. A lot of less-than-perfect code is accepted because it meets all requirements, and that's fine. I'd like to aim higher with APIs, where we try to meet all requirements and also excel at them. That's easiest to do with a concerted collaborative effort which has become... difficult. With QFileSelector, I had a hard time nailing down the interested reviewers and had no opportunity, as I had in Nokia, to trap them in a meeting room until I saw the understanding exuding from their eyeballs. Without an in-depth discussion, it's hard to tell if I hit upon the perfect API (unlikely) or what the weaknesses are in the current proposed API which keeps people from getting interested. Mailing list hasn't worked too well, if only because of my inherent tendency to write long paragraphs. We don't want my Qt APIs to suffer just because I moonlight as a novelist ;) . Just brainstorming; here are some ideas on ways we could improve API reviews: - Have an API review board, and for substantial new APIs (e.g., a new class) everyone from the review board should comment on the gerrit patch (even if it's just +1). This wouldn't help in finding the interested parties, but a well rounded review board would at least look at the API from several angles. For example, I could be on that list to review new APIs from a QML perspective. - Require a combined score of +6 for new APIs on gerrit. That ensures that at around 3 people have reviewed it, (either 3 reviewing thoroughly, or one thoroughly and 5 partially). Could get confusing because it would be the first time that the numbers interact arithmetically. - Have IRC meetings (or audio/video conferences) after each minor version alpha release, giving a further review to all new APIs in that release and honing it for beta. While the real time chat can be nice, it does automatically preclude certain timezones so keep that drawback in mind. - Amend the commit policy to require real-world examples (not necessarily as new examples in the qt repo) for all new APIs, so that no API is added without at least one user-visible usecase being fully worked through. Depending on how far you take real world, this could be a lot of work... Any of these sound good to anyone? Does anyone have another idea on how to improve API reviews in a distributed manner? -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtQuick: Drag pixmap
On Wed, Jan 22, 2014 at 10:42 AM, Mark Gaiser mark...@gmail.com wrote: On Wed, Jan 22, 2014 at 12:11 AM, Fabien Castan fabcas...@gmail.com wrote: Hi, Qt 5.2 adds the possibility to use dragdrop from/to external applications. To allows to drag an item from QML to an external application, we can't simply set a target item, because we want to see this item ouside of the qml window. In Qt, we could set a pixmap on drag events: http://qt-project.org/doc/qt-4.8/qdrag.html#setPixmap I don't see something like that in QtQuick (Qt 5.2): http://qt-project.org/doc/qt-5/qml-qtquick-drag.html Is there a solution to do such thing in pure QML? Regards, Fabien While browsing through the code (qquickdrag.cpp) i found these two commented lines: // TODO: how to handle drag image? // drag-setPixmap(iconPixmap); Along with that no more function for setPixmap that is exposed to QML. That makes me fear that the setPixmap property is not there anymore. Odd, since it would be an API break which i can't really imagine from Qt. I hope someone else more knowledgeable in this area can chime in? Use of direct QPixmaps in QML is discouraged, because there's no real way to manage the memory of the pointer. If there were a QObject or QJSValue wrapper around QPixmap then a setPixmap could be added, similar to the setPixmap in QDrag (although not actually accepting a QPixmap type). So without a good solution handy, that part has been left for later. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 2D Graphics Roadmap?
On Sat, Jan 25, 2014 at 12:10 PM, Steve Gold steveg2...@gmail.com wrote: I'm relatively new to Qt (3-4 months now) and have learned a lot. However, I've been experimenting with developing apps with QML/JavaScript and Canvas/Context2D but have received suggestions to look at Scene Graph or Graphics View, both of which seem to require developing C++ classes. Is this correct? QML appears to be a more efficient and productive approach from a development point of view but C++ seems to be more powerful and expressive. The examples for Graphics View that I've looked at are the most extensive while the examples for Scene Graph and Canvas seem more simplistic. As an example, I found Graphics View demos called elasticnodes (moveable nodes/arc) and diagramscene (select/place items onto a palette) but nothing remotely similar for the other graphics technologies. I've created several posts in the forums and even sent one email but haven't received any significant responses. Before I spend much more time, possibly in the wrong direction, can someone address the future of Canvas, Graphics View and Scene Graph with respect to Qt and Qt Creator? A comparison would be especially useful. GraphicsView is a more mature framework, pretty much marked done, which is why it has the most examples. It's not going anywhere, which probably also means don't expect big changes in performance or underlying implementation. SceneGraph is fairly new, and Canvas is even newer, depends on the level of maturity you prefer to work on. I'd expect SceneGraph, and probably Canvas too, to mature more over the life of Qt 5 (both are new in 5.0). GraphicsView and SceneGraph are both usable via QML or C++. You can use C++ for complex custom elements, and compose simple ones out of Rectangles or Images in QML. Note that all the QtQuick elements, even Canvas, are implemented with SceneGraph, so you can mix and match them freely. QtQuick 1, primarily available for compatibility reasons, uses GraphicsView. The current recommended approach is to use the new frameworks, build your app in QML with QtQuick and use Canvas anywhere you need custom 2D rendering (possibly re-writing that element with SG C++ if it's performance critical). Thanks. Steve BTW, I'm also posting this in the Qt forums If you linked to that post, I could have easily checked it for possible overlap. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtQuick: Drag pixmap
On Tue, Jan 28, 2014 at 1:25 PM, Mark Gaiser mark...@gmail.com wrote:
On Tue, Jan 28, 2014 at 8:28 PM, Alan Alpert 4163654...@gmail.com wrote:
On Wed, Jan 22, 2014 at 10:42 AM, Mark Gaiser mark...@gmail.com wrote:
On Wed, Jan 22, 2014 at 12:11 AM, Fabien Castan fabcas...@gmail.com wrote:
Hi,
Qt 5.2 adds the possibility to use dragdrop from/to external applications.
To allows to drag an item from QML to an external application, we can't
simply set a target item, because we want to see this item ouside of the
qml
window.
In Qt, we could set a pixmap on drag events:
http://qt-project.org/doc/qt-4.8/qdrag.html#setPixmap
I don't see something like that in QtQuick (Qt 5.2):
http://qt-project.org/doc/qt-5/qml-qtquick-drag.html
Is there a solution to do such thing in pure QML?
Regards,
Fabien
While browsing through the code (qquickdrag.cpp) i found these two
commented lines:
// TODO: how to handle drag image?
// drag-setPixmap(iconPixmap);
Along with that no more function for setPixmap that is exposed to QML.
That makes me fear that the setPixmap property is not there anymore.
Odd, since it would be an API break which i can't really imagine from Qt.
I hope someone else more knowledgeable in this area can chime in?
Use of direct QPixmaps in QML is discouraged, because there's no real
way to manage the memory of the pointer. If there were a QObject or
QJSValue wrapper around QPixmap then a setPixmap could be added,
similar to the setPixmap in QDrag (although not actually accepting a
QPixmap type).
So without a good solution handy, that part has been left for later.
Alan, would it be possible to use a Image{...} item as pixmap?
Yes, right now it's not possible, but just as an idea for a workable
implementation.
Not really. The Image element contains much more than just the pixmap,
such as positioning and rendering hints, so it's both too heavy and
most of the properties would be lost. We'd ideally like a lightweight
JS wrapper which just takes a URL (possibly one from an image
provider), so long as it can be used declaratively.
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 2D Graphics Roadmap?
On Tue, Jan 28, 2014 at 1:54 PM, Steve Gold steveg2...@gmail.com wrote: Alan, Thank you for your very informative response. Please see my comments below. Steve -Original Message- From: Alan Alpert Sent: Tuesday, January 28, 2014 2:43 PM To: Steve Gold Cc: Qt Development Group Subject: Re: [Development] 2D Graphics Roadmap? On Sat, Jan 25, 2014 at 12:10 PM, Steve Gold steveg2...@gmail.com wrote: I'm relatively new to Qt (3-4 months now) and have learned a lot. However, I've been experimenting with developing apps with QML/JavaScript and Canvas/Context2D but have received suggestions to look at Scene Graph or Graphics View, both of which seem to require developing C++ classes. Is this correct? QML appears to be a more efficient and productive approach from a development point of view but C++ seems to be more powerful and expressive. The examples for Graphics View that I've looked at are the most extensive while the examples for Scene Graph and Canvas seem more simplistic. As an example, I found Graphics View demos called elasticnodes (moveable nodes/arc) and diagramscene (select/place items onto a palette) but nothing remotely similar for the other graphics technologies. I've created several posts in the forums and even sent one email but haven't received any significant responses. Before I spend much more time, possibly in the wrong direction, can someone address the future of Canvas, Graphics View and Scene Graph with respect to Qt and Qt Creator? A comparison would be especially useful. GraphicsView is a more mature framework, pretty much marked done, which is why it has the most examples. It's not going anywhere, which probably also means don't expect big changes in performance or underlying implementation. SceneGraph is fairly new, and Canvas is even newer, depends on the level of maturity you prefer to work on. I'd expect SceneGraph, and probably Canvas too, to mature more over the life of Qt 5 (both are new in 5.0). ** Are there any roadmaps for Scene Graph or Canvas that discuss planned features or improvements? Does saying ... probably Canvas too ... mean that there is no definitive plan for the enhancement and evolution of Canvas? GraphicsView and SceneGraph are both usable via QML or C++. You can use C++ for complex custom elements, and compose simple ones out of Rectangles or Images in QML. ** Scene Graph looks like it allows the creation of a set of backend C++ QQuickItem subclasses that can be referenced in QML but there don't appear to be many QML Scene Graph types that can be directly used within QML, except for ShaderEffect, Gradient and a few others . Creating Scene Graph C++ classes also looks to me like they take a lot of time and code to write compared to what I would expect from creating QML types. Please correct me if I'm wrong. Note that all the QtQuick elements, even Canvas, are implemented with SceneGraph, so you can mix and match them freely. QtQuick 1, primarily available for compatibility reasons, uses GraphicsView. ** You state ... even Canvas, are implemented with SceneGraph ... but context2d.h and context2d.cpp use QPainter class Context2D : public QObject . . . QPainter m_painter; QPainterPath m_path; . . . The post located at http://qt-project.org/forums/viewthread/37605/ states Qt Quick 2 makes use of a dedicated scene graph based on OpenGL ES 2.0 or OpenGL 2.0 for its rendering. Using a scene graph for graphics rather than the traditional imperative painting systems (QPainter and similar), means the scene to be rendered can be retained between frames and the complete set of primitives to render is known before rendering starts. Can you please clarify this apparent discrepancy? The current recommended approach is to use the new frameworks, build your app in QML with QtQuick and use Canvas anywhere you need custom 2D rendering (possibly re-writing that element with SG C++ if it's performance critical). ** It would be an achievement if Qt enabled users to write QML types for Canvas that used Scene Graph under the covers and did not require any rewriting in C++. ** Will Qt use Scene Graph for 3D graphics? Is anything in this area on the horizon for QML? Thanks. Steve BTW, I'm also posting this in the Qt forums If you linked to that post, I could have easily checked it for possible overlap. ** The post is located at http://qt-project.org/forums/viewthread/37605/ I responded there, it's probably a more appropriate place for the discussion and I'll stop duplicating it here. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtQuick: Drag pixmap
On Tue, Jan 28, 2014 at 3:02 PM, Mark Gaiser mark...@gmail.com wrote:
On Tue, Jan 28, 2014 at 11:32 PM, Alan Alpert 4163654...@gmail.com wrote:
On Tue, Jan 28, 2014 at 1:25 PM, Mark Gaiser mark...@gmail.com wrote:
On Tue, Jan 28, 2014 at 8:28 PM, Alan Alpert 4163654...@gmail.com wrote:
On Wed, Jan 22, 2014 at 10:42 AM, Mark Gaiser mark...@gmail.com wrote:
On Wed, Jan 22, 2014 at 12:11 AM, Fabien Castan fabcas...@gmail.com
wrote:
Hi,
Qt 5.2 adds the possibility to use dragdrop from/to external
applications.
To allows to drag an item from QML to an external application, we can't
simply set a target item, because we want to see this item ouside of the
qml
window.
In Qt, we could set a pixmap on drag events:
http://qt-project.org/doc/qt-4.8/qdrag.html#setPixmap
I don't see something like that in QtQuick (Qt 5.2):
http://qt-project.org/doc/qt-5/qml-qtquick-drag.html
Is there a solution to do such thing in pure QML?
Regards,
Fabien
While browsing through the code (qquickdrag.cpp) i found these two
commented lines:
// TODO: how to handle drag image?
// drag-setPixmap(iconPixmap);
Along with that no more function for setPixmap that is exposed to QML.
That makes me fear that the setPixmap property is not there anymore.
Odd, since it would be an API break which i can't really imagine from Qt.
I hope someone else more knowledgeable in this area can chime in?
Use of direct QPixmaps in QML is discouraged, because there's no real
way to manage the memory of the pointer. If there were a QObject or
QJSValue wrapper around QPixmap then a setPixmap could be added,
similar to the setPixmap in QDrag (although not actually accepting a
QPixmap type).
So without a good solution handy, that part has been left for later.
Alan, would it be possible to use a Image{...} item as pixmap?
Yes, right now it's not possible, but just as an idea for a workable
implementation.
Not really. The Image element contains much more than just the pixmap,
such as positioning and rendering hints, so it's both too heavy and
most of the properties would be lost. We'd ideally like a lightweight
JS wrapper which just takes a URL (possibly one from an image
provider), so long as it can be used declaratively.
Ahh, didn't know that.
So if we continue that idea, would it make sense to re-create the
Image{} component in two parts? One for representing the actual image
data, one for representing is's place in the QML app.
Lets call the one just representing the image data ImageData {}. It
only knows how to represent a image based from an url or image
provider.
The Image{} component that inherits from ImageData{} and adds whatever
it needs to be on par with the current Image{} component.
Would an approach like that make sense?
just thinking out loud now :)
Thinking out loud, I'd do something more like the Sprite classes.
There's a Sprite{} which encapsulates logical data, a SpriteSequence{}
for playing and transitioning between sprites, and a convenience
AnimatedSprite{} which is like a Sprite that draws itself (with some
rendering options added). So Image{} would stay the same, inherit from
ImageData{} in a conceptual sense, but there would be a more basic
ImageData{} which is used by other elements.
Assuming that there's enough complexity in ImageData to be worth a
QObject type (Sprite has a lot of properties:
https://qt-project.org/doc/qt-5/qml-qtquick-sprite.html ) , Otherwise
we should just add a basic type with a (possibly implicit) URL
constructor, as long as it's JS reference counted.
The other thing I'm thinking of is that a C++ API would actually be
useful here. Dropping down to C++ isn't the real problem here, that's
pretty easy to do with QML. Except that you can't take an existing QML
scene and just pass in the pixmap from C++, because it can't go
through QML for the above reference reasons. The most convenient way
then would be to get the QML item reference and pass the pixmap wholly
in C++, but we can't currently add public C++ API to QtQuick elements.
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] thoughts about a shared models module, and models in general (was Re: Would a (QML) model aggregator class a welcome addition?)
On Fri, Jan 17, 2014 at 7:01 AM, Alberto Mardegan ma...@users.sourceforge.net wrote: On 01/15/2014 10:48 PM, Alan Alpert wrote: This approach could also apply to the original suggestion by Alberto, in the absence of a separate add on module (which Sean couldn't use because of the QtQuick.Controls dependency). Just requires a higher bar for code review/quality, but I'm currently leaning in favor of extra models convenience classes. It's a decent hold over measure since the new model/views have been taking so long. That's good to know. :-) I've got a question on the implementation side: when writing convenience classes which proxy (part of) the contents of a source model (or many), is it fine to code the source model type as a QAbstractItemModel? If so, what will happen if people try to set QML string lists (or lists of objects) as source property for the proxy model? Will the QML engine do the wrapping into a QAIM, or will this simply not work? If it doesn't work, do we care? I don't think it matters too much, so if it doesn't work then don't worry about it. But if you want this to work, you can make the source for the proxy model work like the views (accepts QQmlInstance models and can turn numbers, lists and QAIMs into a QQmlDelegate model). QQmlInstanceModel and QQmlDelegate model are private API, but if you're going to stick it in QtQml.Models that is not a problem. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] thoughts about a shared models module, and models in general (was Re: Would a (QML) model aggregator class a welcome addition?)
On Wed, Jan 15, 2014 at 12:48 AM, Rutledge Shawn
shawn.rutle...@digia.com wrote:
On 10 Dec 2013, at 11:43 PM, Alan Alpert wrote:
On Tue, Dec 10, 2013 at 12:32 PM, Alberto Mardegan
ma...@users.sourceforge.net wrote:
Hi all!
For one of my projects, I found the need to merge several models into
a single model. I wrote a class for it, and I think it's generic enough
to be useful for other people, and I wonder if it could be put into Qt
itself:
https://gitlab.com/mardy/mappero/blob/directions/lib/Mappero/model-aggregator.h
Note that the thing is not complete (especially the implementation),
it's just in a state where I can use it in my application; it needs a
bit of more work before being ready for the generic use.
I'm wondering if I should make this extra effort or not. :-)
If the answer is yes, should it be added to QtCore or QtDeclarative?
Right now it's using QQmlListProperty so that the source models can be
declared inline,
ModelAggregator {
Model1 { ... }
Model2 { ... }
...
}
but that could be removed and substituted by a simple QList of models if
desired.
This doesn't sound core enough to really benefit from going into
QtDeclarative (please stop developing for QtQuick 1 :P ; but I know
you meant qtdeclarative the repo) or QtCore (no QML types can go into
QtCore, because QtCore cannot depend on QtQml).
Maybe we should have an add-on repository like qt-qml-extras which
contains small but useful QML modules. Candidate content being this
model aggregator, Qt.labs.folderlistmodel, (and I have a couple
imports at home that I could clean up and contribute too) maybe even
QtQuick.XmlListModel or Qt.GraphicalEffects? Some of the add-on level
imports, like Qt.GraphicalEffects, are large enough for their own
repo. And some, like QtQuick.XmlListModel, feel core enough to go in
qtdeclarative as an essential. But there's scope for a lot of small
but useful QML modules, like ModelAggregator and
Qt.labs.folderlistmodel, where a shared and non-essential repository
would make more sense. The alternative is telling each of these little
modules to get their own github/gitorious/playground repo and then
we'd have to organize them with something like inqlude...
Anyone else want a qml-extras repository for collecting small QML imports?
And should it be qt-labs, playground, or qt (add on, not essential!)?
I like the idea, but the trouble with models is you typically want to create
and populate them from C++, which means you need the collection to be in a
library which you can link with. The QML modules that get installed e.g.
under qml/QtQml/Models aren't used that way because everything under qml is
meant to be instantiated only from QML. But it would be nice if these models
could be instantiated both ways. The C++ interface is more urgent IMO,
because so far the choices seem to be
http://qt-project.org/doc/qt-5.1/qtquick/qtquick-modelviewsdata-cppmodels.html
subclass QAbstractItemModel yourself (that requires some overhead, mostly
boring code being rewritten each time); use a QStringList (but only for one
column and only strings); use a QList of QObjects, which at least is quite
flexible (but then each row has all the QObject overhead); or use one of the
models that you can only instantiate from QML, and then you will have to
write more Javascript to populate it. I started writing
https://codereview.qt-project.org/#change,74986 and then realized I can't
link with it.
Like several QtQml and QtQuick classes, you can have types in a module
as well as available in C++. Ideally any C++ public classes relating
to the QtQuick* imports will be in libQt5Quick.so, and ditto for
QtQml.* and libQt5Qml.so. We have these two C++ libraries relating to
QML already.
So this module would have to be installed under lib I suppose? and then just
because it's a separate, optional module, there would be an objection to
depending on that module in any Qt essential module, such as Qt Quick
Controls. I want to use such a model for the shortcuts in the
next-generation FileDialog (which will be using QtQuick.Controls, and
therefore lives in the same git repository now), and we have another
potential use case for font families for the font dialog, so it has to be OK
for Controls to depend on it, wherever it goes. The easy solution (and also
the one which doesn't encourage reuse) is to put this model in
QtQuick.Dialogs.Private because that's where I need it. If someone else
wants it, they can always copy the code. It's not much code anyway, hardly
worth worrying about. But altogether we could end up with a worthwhile
collection of models if various people have various ideas.
Maybe it should rather be a static library to have one less runtime
dependency? Another advantage would be that a typical application might only
need one of the models from the lib, so the memory cost would be lower if the
linker was free
Re: [Development] Qt.vector3d() and friends
On Wed, Jan 8, 2014 at 5:31 AM, Sebastian Lehmann q...@leemes.de wrote: Hi, I'd find it natural if there was something like a QtCore plugin. Then, QtQuick and Qt3D (and other stuff) could depend on it; i.e. something analogous to the existing Qt modules dependency, but in the QML world. I already encountered situations in which I wanted to use QtQuick stuff without the QtQuick *visual* items: Timer, Component, NumberAnimation etc. Why not separating QtQuick in non-visual and visual parts? Repeating Kai a bit... Timer, Component and others have already undergone this. They are available in the QtQml import (as well QtQuick, for convenience and compatibility with QtQuick 1.0) allowing you to use them without a QGuiApplication. Animations are tied into QtQuick a little deeper though, and only Timer is available in the QtQml import. The QtQml import already exists, and provides that core plugin of types. However it can only depend on QtCore so if Qt3D stuff pulls in QtGui or needs a QGuiApplication then it has to go in QtQuick (at least). Of course, when importing QtQuick x.y, this should automatically resolve the dependency and also import QtCore x.y. This indeed seems so naturally to me that I can't believe that nobody else has ever thought of that before, so I guess there is a reason why it's not organized like that? We've thought of it (especially for the brief period where there was a bug, and if you imported QtQuick.Particles without first importing QtQuick then it would crash :P ), the problem is that this leads to hidden imports. It's easy to forget you depend on those extra imports. But the main problem is about the rest of the statement import QtFoo x.y as Name. A dependency from QtFoo-QtBar is fairly straight forward, it gets complex when you add the version numbers (because it will be compatible with any minor versions) and it gets ugly when you realize that you can't import it in a namespace anymore. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtQml maintainer nomination
On Thu, Jan 9, 2014 at 12:24 PM, Knoll Lars lars.kn...@digia.com wrote: Hi, I'd like to continue on filling gaps in our maintainer list and thus want to propose Simon Hausmann as the new maintainer for QtQml. Guess I don't need to say a whole lot more about the nomination... ;-) +1 from me. Aside from his immense contribution to the engine re-write, he's been doing a lot of cleanup on the JIRA tasks recently: the gritty, realistic side of maintainer-ship. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding Enginio (qtenginio) to the Qt release
On Mon, Jan 6, 2014 at 9:41 AM, Qi Liang liang...@digia.com wrote: What is qt modularization for? We want to have different release cycles for different qt modules. As I recall, that means we want to be able to have different release/versioning cycles, but there will still be a regular Qt release package containing some version of all essential modules (and compatible with some version of all addon modules) even if some haven't bumped their version. Then +1 for that. For offline installer, I suggest, a separate installer for it, but it should based on installed qt directory. It is compatible with 5.2.0 release in this way. For online installer, every module is an option, then not much difference there. Isn't this the distinction between addon modules and essential modules? Is Frederik asking for enginio to become a Qt Essential module? Or am I a little behind in my terminology? -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QPA maintainer
On Tue, Dec 17, 2013 at 3:42 AM, Knoll Lars lars.kn...@digia.com wrote: Hi, I’d like to nominate Paul Tvete as the formal maintainer of the QPA architecture. He’s the original architect behind it anyway, and I don’t think there are many people out there who know it better :) +1 from me. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtest-qml osx
On Mon, Dec 16, 2013 at 3:47 AM, Chao Caroline caroline.c...@digia.com wrote: Hi, Qt Quick Test is part of Qt (in the qtdeclarative repo). I think the problem here is that you are trying to run a test using qmlscene directly. QML TestCases should be launched via a C++ harness: http://qt-project.org/doc/qt-5/qtquick-qtquicktest.html The other alternative is the qmltestrunner utility. qmlscene is not expected to work, nor planned to, but ideally support will be added to the new qml utility (such support is not currently in place but wouldn't be too hard to add). -- Alan Alpert From: development-bounces+caroline.chao=digia@qt-project.org [development-bounces+caroline.chao=digia@qt-project.org] on behalf of Joshua Kolden [jos...@studiopyxis.com] Sent: Sunday, December 15, 2013 11:18 PM To: development@qt-project.org Subject: [Development] qtest-qml osx We have a fairly large qml project, and with 5.2 we are trying to switch to TDD for all components (c++, js (coffescript), QML). Qt Creator and qmlscene in 5.2 both seem to have the same issue that files are missing: qmlscene test1.qml file:///x/d/qt/testDrivenQML/test1.qml:25 Type TestCase unavailable file:///Users/joshua/Qt5.2.0/5.2.0/clang_64/qml/QtTest/TestCase.qml:45 module Qt.test.qtestroot is not installed qt-labs/qtest-qml has a merge request under ‘review’ from 2 years ago!! It refers to a problem with OSX installation (OSX is our primary development environment). I have not been able to test this issue on other platforms, but noticing that both the merge request and the README install directions for qtest-qml are both very dated I thought it might be better just to ask here if this is dead, or is it supposed to work in 5.2 / OSX? Docs for TestCase in 5.2 imply that it’ll work the same as any QML Type. Also in a separate note, the new Qt Creator crashes consistently when trying to create a new qt quick project through the interface. Thanks for the hard work! Best, j ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Would a (QML) model aggregator class a welcome addition?
On Tue, Dec 10, 2013 at 12:32 PM, Alberto Mardegan
ma...@users.sourceforge.net wrote:
Hi all!
For one of my projects, I found the need to merge several models into
a single model. I wrote a class for it, and I think it's generic enough
to be useful for other people, and I wonder if it could be put into Qt
itself:
https://gitlab.com/mardy/mappero/blob/directions/lib/Mappero/model-aggregator.h
Note that the thing is not complete (especially the implementation),
it's just in a state where I can use it in my application; it needs a
bit of more work before being ready for the generic use.
I'm wondering if I should make this extra effort or not. :-)
If the answer is yes, should it be added to QtCore or QtDeclarative?
Right now it's using QQmlListProperty so that the source models can be
declared inline,
ModelAggregator {
Model1 { ... }
Model2 { ... }
...
}
but that could be removed and substituted by a simple QList of models if
desired.
This doesn't sound core enough to really benefit from going into
QtDeclarative (please stop developing for QtQuick 1 :P ; but I know
you meant qtdeclarative the repo) or QtCore (no QML types can go into
QtCore, because QtCore cannot depend on QtQml).
Maybe we should have an add-on repository like qt-qml-extras which
contains small but useful QML modules. Candidate content being this
model aggregator, Qt.labs.folderlistmodel, (and I have a couple
imports at home that I could clean up and contribute too) maybe even
QtQuick.XmlListModel or Qt.GraphicalEffects? Some of the add-on level
imports, like Qt.GraphicalEffects, are large enough for their own
repo. And some, like QtQuick.XmlListModel, feel core enough to go in
qtdeclarative as an essential. But there's scope for a lot of small
but useful QML modules, like ModelAggregator and
Qt.labs.folderlistmodel, where a shared and non-essential repository
would make more sense. The alternative is telling each of these little
modules to get their own github/gitorious/playground repo and then
we'd have to organize them with something like inqlude...
Anyone else want a qml-extras repository for collecting small QML imports?
And should it be qt-labs, playground, or qt (add on, not essential!)?
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Namespacing QML context properties
On Sun, Dec 8, 2013 at 11:28 PM, Alberto Mardegan
ma...@users.sourceforge.net wrote:
On 12/09/2013 12:54 AM, Alan Alpert wrote:
On Sun, Dec 8, 2013 at 5:38 AM, Alberto Mardegan
ma...@users.sourceforge.net wrote:
[...]
What do you mean current context? The problem you seem to be hitting
is that there is another symbol in the current context that you want
to avoid, so that it finds a symbol higher up the tree. That would
mean something like engine.rootContext(), but I don't think that would
make sense in QML.
I don't really want the engine.rootContext(), but actually
engine.contextForObject(this). Please have a look at this example, and
suppose that I want to use this as a delegate in a ListView, in order to
provide a different delegate for each element in the list, depending on
some property in the model:
Item {
ListView {
model: ...
delegate: loader
}
Component {
id: delegate1
Rectangle { color: model.color; ... }
}
Component {
id: delegate2
Text { text: model.text; ... }
}
Loader {
id: loader
// property variant model: model
sourceComponent: model.someProperty ? delegate1 : delegate2
}
}
Now, if I don't remove the comment, the actual delegates loaded by the
Loader (delegate1 and delegate2) won't see the model property; but if
I uncomment the line, it won't work either, because inside the Loader's
definition the property named model will obscure the context property
having the same name.
How would you solve this (without of course renaming variables or moving
components around: suppose that I have no control over the listview or
delegates' code)?
And another simpler case, this:
Item {
ListView {
model: ...
delegate: ComboBox {
text: model.displayName
}
}
}
And suppose that a certain point the authors of the ComboBox element
change it by adding a model property to it. That would break the code
above, because model wouldn't refer anymore to the model injected by
the ListView, but to the new ComboBox property!
But if you had a way to select your local context with some prefix, no
breakage could ever happen:
Item {
ListView {
model: ...
delegate: ComboBox {
text: qmlContext.model.displayName
}
}
}
I hope that the question is now clearer. :-)
Question does seem a bit clearer. But I think the answer is the same -
ListView shouldn't be using context properties anymore. Well, it's
worthwhile for the convenience here but maybe add an attached property
reference as well for those cases needing more precision:
Item {
ListView {
model: 3
delegate: ComboBox {
text: ListView.modelData.displayName //unambiguous*
}
}
}
*not enforced by the language to be unambiguous like Singletons, but
the conflicting case is left as an exercise to the reader ;)
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Namespacing QML context properties
On Sun, Dec 8, 2013 at 5:38 AM, Alberto Mardegan
ma...@users.sourceforge.net wrote:
Hi all!
One of the issues that has most bothered me when developing in QML is
dealing with the same variable name in item properties and context
properties. For example:
// model is a context property
Loader {
property variant model: model
sourceComponent: someComponent
}
The code above will not work. And I cannot find a way to make the
model context property available to the loader source component. For
reference:
http://qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-loader.html#using-a-loader-within-a-view-delegate
See especially the last code snippet there. Notice how the variable name
had to be changed from index to modelIndex, in order to workaround
the issue I described above.
However, renaming properties is not always desirable.
Are there some tricks I'm not aware of? If not, what about introducing a
reserved word (maybe qmlContext), and let it refer to the current context?
So, one could write qmlContext.variableName to avoid ambiguity with
properties names variableName, and my example above would change like
this:
What do you mean current context? The problem you seem to be hitting
is that there is another symbol in the current context that you want
to avoid, so that it finds a symbol higher up the tree. That would
mean something like engine.rootContext(), but I don't think that would
make sense in QML.
Loader {
property variant model: qmlContext.model
sourceComponent: someComponent
}
Thoughts?
Context properties are there as a light-weight option for applications
- i.e. for cases where you don't mind renaming, or giving long names
like pleaseDontConflictModel. For a reliable API with good naming, you
should be using a singleton API instead of context properties.
The history is that context properties arrived in Qt 4 and singleton
APIs arrived in Qt 5 as a better approach (albeit with some
differences that make automated porting impossible). If we had
singleton APIs to start with, we probably wouldn't have provided
context properties at all. If it weren't for the convenience context
properties offer, I'd recommend all context property usage be migrated
to use singleton APIs. As it is, I only recommend that for all module
APIs (basically, if you used setContextProperty inside
initializeEngine you should probably use singleton APIs now instead).
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Can the hidden QML properties please be documented?
On Mon, Dec 2, 2013 at 1:06 AM, Smith Martin martin.sm...@digia.com wrote: For a QML type in a .qml file, qdoc reports an error if it sees a QML property it thinks should be in the public API for that QML type and there is no \qmlproperty comment immediately preceding that property in the .qml file. But for a QML type that is represented by a C++ class, qdoc doesn't know which C++ properties are meant to be be documented as QML properties, so it can't report an error if a C++ property is not documented as a QML property. Maybe we should change this policy and tell qdoc to require a \qmlproperty for every C++ property that has a \property ? If it's been associated with a QML type, yes. There is the situation of a C++ type with C++ properties which is not exposed to QML - don't want to document that. But if we have a \qmltype which \instantiates it, then any C++ properties need to be considered QML properties as well (it helps if \internal works with \qmlproperty for the ones that are meant to be hidden ;) ). -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Can the hidden QML properties please be documented?
On Sun, Dec 1, 2013 at 4:25 AM, Mark Gaiser mark...@gmail.com wrote: On Sun, Dec 1, 2013 at 11:09 AM, Nurmi J-P jpnu...@digia.com wrote: On 01 Dec 2013, at 00:42, Mark Gaiser mark...@gmail.com wrote: Hi, Recently i was searching for a way to influence the dragDistance in QML. The documentation (i even looked at dev snapshot docs) didn't provide any clue, but the code did. Turns out there is a hidden property: drag.threshold (it is underlined in red in QtCreator, but works just fine!). Perhaps you're reading Qt 5.1.x docs? MouseArea::drag::threshold is a new property that was added in September. The documentation is there in the latest snapshot: http://doc-snapshot.qt-project.org/qt5-release/qml-qtquick-mousearea.html For font rendering there is the hidden property: renderType Which works just fine, but is nowhere to be found in the Qt documentation. QQuickText::renderType was indeed missing from the docs. It has been fixed in Qt 5.2.0: - https://bugreports.qt-project.org/browse/QTBUG-35018 - https://codereview.qt-project.org/#change,72391 -- J-P Nurmi That's awesome! It still makes me wonder, how many more are hidden? I hope none :) I hope so too, as it's usually a doc bug. Feel free to file further issues like this on bugreports.qt-project.org . -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] isValid() as a property
On Fri, Nov 29, 2013 at 3:03 PM, Tony Van Eerd tvane...@blackberry.com wrote: On Fri, 29 Nov 2013, Tony Van Eerd wrote: in the cases I am looking at, if isValid() == false, then all the other properties are invalid, and return , -1, etc. It really does mean the whole object is invalid. (except maybe an 'id', in the case of, say, a Battery object - the id telling you which battery, and then isValid() saying that battery doesn't (currently) exist.) Why not use exists, present, active or something like it? 'present' was in fact my first choice (for battery at least). But since the behaviour seems to match that of isValid(), why not isValid()? If we could (ie if we didn't care about compatibility), would we rename all the other isValid() functions on existing Qt classes? If not, what is the difference? If there is a difference, and a clear rule when to use isValid() and when not to, I'd be quite happy. But I want to understand the difference first. As I understand it, we want to use isValid in all those cases where the behavior matches exactly - this makes the Qt APIs more memorable and more guessable (used a previous class with this behavior? Just try isValid, see if it compiles ;) ). But a C++ object for a physical object that does not exist... why is it there in the first place? Essentially because we don't throw exceptions in constructors. BatteryInfo battery(5); // the 5th battery. if (battery.exists()) If you start on a QML API, a similar issue occurs. Because there's no way to handle construction exceptions gracefully, you'd need to be able to declare an object and then for error handling (which could mean no backing object could be created) then they bind to a property like this. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Integration of qt5.git
On Fri, Nov 29, 2013 at 12:50 PM, André Pönitz andre.poen...@mathematik.tu-chemnitz.de wrote: On Fri, Nov 29, 2013 at 05:16:31PM +, Gladhorn Frederik wrote: Hello all, [...] Since we lose the test runs for all modules at the same time I'd like to have a second and new job in Jenkins that runs nightly and builds and runs all tests of all modules (according to qt5.git state). This job doesn't mean anything for the integration and doesn't block but simply sends mail to this list whenever any test fails. I actually expect it to fail regularily since we have quite a few unstable unit tests that every once in a while fail. I hope that this approach gives actually more visibility to failing auto tests than what we currently have. Regular emails from a bot broadcast to devel when the break could be anywhere in qt5.git's submodules... I'm not sure that will be effective for getting it fixed. Despite the recent marketing blitz, people only really step up to fix someone else's tests when it's blocking their integration. Is it possible to have a more targeted approach, like it emailing the relevant maintainer(s) instead (or a QA team, if we still have one)? [...] Since the main use of qt5.git is to _release_ stuff, its setup and policies should cater to exactly that need first. If it works for other use cases that's fine, but in no way essential. I concur. The only time I hear about qt5.git is around release time and I'd rather not hear about it at all (that is to say, the process should work so smoothly and well that it never comes up ;) ). Do what you feel is necessary. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ChangeLog updated for 5.2.0
On Mon, Nov 25, 2013 at 7:49 AM, Thiago Macieira thiago.macie...@intel.com wrote: On segunda-feira, 25 de novembro de 2013 12:49:11, Marc Mutz wrote: I have found that significantly more than 50% of commits that touched qtbase/src/widgets since v5.1.0 end up in the change log. It could be a comment unless a Task-number is also present, in which case the bot could -1 the change. Your sampling is likely very biased. QtWidgets is in a state that almost every change going in is a bugfix to something important. That does not translate to other libraries. Thiago is quite right. Let's look at the other end of the spectrum: qtdeclarative repo has had around 3016 commits since v5.1.0, and has about 9 changelog entries. That's around 0.3% of commits. Given that overriding the sanity bot has been made a deliberately user-unfriendly experience, I'd rather not add it to ~99% of commits. The qtdeclarative repo is of course biased to the other extreme. Both QtQml and QtQuick are in a state that most changes going in are reworking the internals, and fixing any regressions caused by such work. It's probably also missing some changelog entries, I still haven't gone through those 3016 commits yet to check ;) . -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ChangeLog updated for 5.2.0
On Mon, Nov 25, 2013 at 10:47 AM, Marc Mutz marc.m...@kdab.com wrote: On Monday, November 25, 2013 06:26:38 PM Alan Alpert wrote: On Mon, Nov 25, 2013 at 7:49 AM, Thiago Macieira thiago.macie...@intel.com wrote: On segunda-feira, 25 de novembro de 2013 12:49:11, Marc Mutz wrote: I have found that significantly more than 50% of commits that touched qtbase/src/widgets since v5.1.0 end up in the change log. It could be a comment unless a Task-number is also present, in which case the bot could -1 the change. Your sampling is likely very biased. QtWidgets is in a state that almost every change going in is a bugfix to something important. That does not translate to other libraries. Thiago is quite right. Let's look at the other end of the spectrum: qtdeclarative repo has had around 3016 commits since v5.1.0, and has about 9 changelog entries. That's around 0.3% of commits. Given that overriding the sanity bot has been made a deliberately user-unfriendly experience, I'd rather not add it to ~99% of commits. The qtdeclarative repo is of course biased to the other extreme. Both QtQml and QtQuick are in a state that most changes going in are reworking the internals, and fixing any regressions caused by such work. It's probably also missing some changelog entries, I still haven't gone through those 3016 commits yet to check ;) . And no-one ever will, so we don't know and never will know how much ChangeLog entries these should have generated. For QtWidgets, we're talking O(256) commits, and it's already exhausting to create a changelog ex post facto. For declarative, it looks impossible. Well, I just did the impossible ;) . I don't see a contradiction to what I was proposing: -1 if task-number is present, too, otherwise just warn. -1 is annoying (deliberately, as overriding -1's is supposed to be rare). I'm happy to have it warn though. That's +0, and a comment along the lines of ChangeLog: Commit message references a task but does not include a ChangeLog message. If the task is =P2 and affected previous versions, please add a ChangeLog entry(I'm not hung up on the wording, that's just what I'd write). -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ChangeLog updated for 5.2.0
On Mon, Nov 25, 2013 at 11:43 AM, Thiago Macieira thiago.macie...@intel.com wrote: On segunda-feira, 25 de novembro de 2013 07:49:03, Thiago Macieira wrote: On segunda-feira, 25 de novembro de 2013 12:49:11, Marc Mutz wrote: I have found that significantly more than 50% of commits that touched qtbase/src/widgets since v5.1.0 end up in the change log. It could be a comment unless a Task-number is also present, in which case the bot could -1 the change. Your sampling is likely very biased. QtWidgets is in a state that almost every change going in is a bugfix to something important. That does not translate to other libraries. Stats for QtCore: - 510 commits - 21 commits had [ChangeLog] - I added 37 after my second pass That's just 11% of the commits requiring changelogs. Stats for qtdeclarative (whole repo): -2944 commits (since v5.1.1, previous number was since v5.1.0 which was incorrect). -3 commits had [ChangeLog]* -I added 25 after my second pass. That's just 1.1% of the commits requiring changelogs. Seems to vary a lot by module... or by maintainer. For comparison, my changelog threshold was =P2 bug affecting a previous version (or feature) and my manual check was on just the commit logs since v5.1.1 (assisted by my particle-powered tool from the last changelog discussion ;) ). Another thing to note, about half the commits were from the v4 branch/repo merge, none of which are changelog eligible. The continued work on v4 is also a large part of that commit number, in case you're wondering where all those commits are going. The * is for some interesting things I noticed. Of the 3 usages, 2 of them were after Thiago's original email. Which means that if he had run the script on QtDeclarative as well, he'd have gotten only 1 hit. 2 of them had the wrong module name, and 1 of them was arguably ineligible (but I'm still following that up). So there's still quite the manual pass needed, even if [ChangeLog] adoption picks up. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ChangeLog updated for 5.2.0
On Mon, Nov 25, 2013 at 2:29 PM, Thiago Macieira thiago.macie...@intel.com wrote: On segunda-feira, 25 de novembro de 2013 13:21:15, Alan Alpert wrote: The * is for some interesting things I noticed. Of the 3 usages, 2 of them were after Thiago's original email. Which means that if he had run the script on QtDeclarative as well, he'd have gotten only 1 hit. 2 of them had the wrong module name, and 1 of them was arguably ineligible (but I'm still following that up). So there's still quite the manual pass needed, even if [ChangeLog] adoption picks up. I ran the script on all submodules of qt5.git that produced any listing for git rev-list v5.1.1..origin/release. That is: the module had to be tagged for 5.1.1. That means the script did not catch modules that are getting the first release now. My apologies, I did not notice. That raises two questions: 1) Should the qtbase changelog contain all changes from essential modules, or just the ones in the qtbase repository? i.e. should I merge the qtdeclarative changelog into it once that gets approved. 2) What to do about that one which was integrated? Remove since it's now duplicated in the qtdeclarative changelog, or fix that it is under the wrong module? -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Fabian Bumberger for Approver Status
On Tue, Nov 19, 2013 at 4:46 AM, Rafael Roquetto rafael.roque...@kdab.com wrote: +1 On Tue, Nov 19, 2013 at 12:48:07PM +0100, Thomas McGuire wrote: Hi, On Tuesday 19 November 2013 11:41:52 Blasche Alexander wrote: I'd like to nominate Fabian Bumberger for approver status in the Qt Project. Fabian has been contributing to QtNfc, QtBluetooth, QtLocation and many more Blackberry specific topics such as the platform plug-ins. His track record can be found under: https://codereview.qt-project.org/#q,owner:fbumberger,n,z https://codereview.qt-project.org/#q,reviewer:fbumberger,n,z From my perspective QtBluetooth and QtNfc wouldn't be the same without his help. I am convinced he will make en excellent approver. I support this. I have worked together with Fabian on the QNX QPA plugin, where he did good work. +1 from me. He also makes good QML games to show off all that code ;) . -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Javascript exceptions from QML plugin
On Sat, Nov 16, 2013 at 7:15 AM, Pattyn, Kurt kurt.pat...@barco.com wrote: Hi, is there a way to emit Javascript exceptions from a C++ QML plugin or more general: what is the best way to indicate errors to QML from within a QML plugin? The reason I ask, is because I am implementing the W3C WebSocket API (see http://www.w3.org/TR/websockets). In several circumstances, the standard says to throw javascript exceptions. Maybe an elegant solution could be to just expose an exception signal, and use that instead. JS Exceptions would be nice, at least in this case for spec compliance. However I don't think you can currently do that in QJSEngine, another one of those limitations we'd like to fix in the long term. For now I recommend having an Error status and an invokable function to get the error string (or a string property), just like QQmlComponent. That works well with QML, even though it does diverge from the WebSocket spec. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML and JavaScript extensions
On Tue, Nov 19, 2013 at 11:17 AM, André Pönitz andre.poen...@mathematik.tu-chemnitz.de wrote: On Fri, Nov 15, 2013 at 03:07:41PM -0800, Alan Alpert wrote: On Fri, Nov 15, 2013 at 1:58 PM, Richard Moore r...@kde.org wrote: The idea that QML deprecates ui files is frankly utter rubbish. UI files offer many advantages over QML - decent widgets, keyboard navigation, stability, faster coding for the common case in non-mobile applications (to name just a few of them). You've lost me. I thought the set of widgets available in QML was the same as in .ui files - all of them. Tree views? Yes. Because in this instance we're talking about using QtWidgets in QML using something like https://github.com/KDAB/DeclarativeWidgets . -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML and JavaScript extensions
On Fri, Nov 15, 2013 at 2:00 AM, Kevin Krammer kevin.kram...@kdab.com wrote:
On Thursday, 2013-11-14, 21:20:25, Topi Mäenpää wrote:
But that's a long term plan, v4vm isn't even released yet (new in 5.2
remember) and there's still tons of work to do. Until v4vm is ready to
take over from QtScript, which will still be a while, I believe the
recommendation is to keep using QtScript. It's deprecated and done
because we've reallocated development priorities, but until we've
finished its replacement it is your best option. Even though it means
using old or no QML, it sounds like the JS support is more important
for you.
I considered the options carefully before switching to Qt5. I talked to
Digia engineers and they told me the same you are telling now: QtScript
will be deprecated and definitely not accessible from QML. Therefore, it
was completely out of question. I don't think building anything serious
on a deprecated API is a good idea anyway.
That could have been a miscommunication. What they probably meant was that the
standard QtQuick module would not have a QML type for QScriptEngine.
QScriptEngine can certainly be accessed from QML. Sure evaluate is currently
neither a slot nor a Q_INVOKABLE, but that would easily added and/or worked
around by a simple subclass or wrapper.
Remember that any default constructible QObject class can be instantiated by
QML, its slots, signals, properties and Q_INVOKABLEs becoming available.
QML is just the glue between object instances, it doesn't care what those
objects do internally.
I think he's talking about JS integration into QML. It's the difference between
MyObject {
prop: Math.min(alpha.foo, beta.bar);
}
and
MyObject {
prop: Math.min(alpha.foo, beta.bar);
}
Sure, you can do the latter. Maybe even query the QQmlContext for
evaluating unrecognized symbols such as alpha.foo. Then you start to
reimplement binding logic and you start asking yourself why am I
doing this again?.
So you can use QScriptEngine from QML in 5.2 just like you could use
QScriptEngine in Qt 4.6 (before QML). But you're missing out on a lot
of progress, and you aren't getting the value out of QML anymore,
which is why I'm asking whether you need QML in your application (yes,
every application would benefit from QML but I'm not going to claim
every application *needs* it ;) ).
Qt is heading to a JavaScript-based future. Widgets are deprecated and
replaced by QML. In this situation, a good extension interface to the
JavaScript engine that runs QML is a really important feature.
I have to disagree with a couple of items here.
Qt has already had JavaScript based scripting support for ages, so it is not
heading into using it. As for JS in QML, any sensibly designed application
will avoid doing business logic process in the UI. That was already not a good
idea when using C++, no need to continue bad practise when the new UI
technology hands you a nice way to correct that.
I also wouldn't consider widgets to be deprecated, at least not yet. And
nicely use QML with widgets as the UI elements, it is not replacing one with
the other either (though you probably meant QtQuick when you wrote QML there).
Yeah, QML doesn't deprecate widgets - it deprecates .ui files because
now you can construct your widget UIs in QML :D . Long ago we
discussed deprecating widgets because Nokia wanted to reallocate those
development resources to QML/QtQuick, but thankfully open governance
swooped in and saved the day.
Assuming you meant QtQuick there: Qt Quick-based development, even
Components IMHO, is expected to take over for future *style* of UIs
(I'd say mobile, but then take a look at Windows 8...). I expect
Classic style UIs will continue to use widgets until Qt 6 at the
earliest.
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML and JavaScript extensions
On Fri, Nov 15, 2013 at 11:51 AM, Topi Mäenpää topi.maen...@intopii.com wrote: I think the existence of JavaScript context in QML should be considered a feature of QML, not of Qt or the application itself. Sure, as far as the Qt application is not a QML application. If you run the app with qmlscene, the Qt application is a pure QML application. Ah, well if you're running the app with qmlscene that's not supported anyways :P . But have a look at the new qml runtime in 5.2. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML and JavaScript extensions
On Fri, Nov 15, 2013 at 1:04 PM, Topi Mäenpää topi.maen...@intopii.com wrote: [...] In Qt4, widgets were still the main UI technology. Nowadays, widgets are deprecated. (I'm putting quotes due to the comments to my last post, but it is really not hard to see where the development is heading.) Prior to QML apps, JavaScript has been a tool to provide scripting support for C++ applications, but applications were not based on it. Now, the situation has turned around: JavaScript/QML app, C++ extensions. Therefore, I'm sticking to my statement: a good extension interface is an important feature. We're not quite there with the JS/QML app, C++ extensions story. It's the direction we're heading, and once we're there the extension interface becomes a top priority. But it sounds like you're a bit ahead of us here - until 5.2 comes out, the only officially supported route is a C++ app which loads a QML UI. There still are a lot of important features to work on until I would suggest JS/QML app with C++ extensions for the majority of app developers (stick to C++ app with QML UI for now). -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML and JavaScript extensions
On Fri, Nov 15, 2013 at 1:58 PM, Richard Moore r...@kde.org wrote: On 15 November 2013 19:51, Alan Alpert 4163654...@gmail.com wrote: On Fri, Nov 15, 2013 at 2:00 AM, Kevin Krammer kevin.kram...@kdab.com wrote: On Thursday, 2013-11-14, 21:20:25, Topi Mäenpää wrote: I also wouldn't consider widgets to be deprecated, at least not yet. And nicely use QML with widgets as the UI elements, it is not replacing one with the other either (though you probably meant QtQuick when you wrote QML there). Yeah, QML doesn't deprecate widgets - it deprecates .ui files because now you can construct your widget UIs in QML :D . Long ago we discussed deprecating widgets because Nokia wanted to reallocate those development resources to QML/QtQuick, but thankfully open governance swooped in and saved the day. The idea that QML deprecates ui files is frankly utter rubbish. UI files offer many advantages over QML - decent widgets, keyboard navigation, stability, faster coding for the common case in non-mobile applications (to name just a few of them). You've lost me. I thought the set of widgets available in QML was the same as in .ui files - all of them. I also didn't know that XML had better keyboard navigation than QML, but maybe that's because I use vim for both? The .ui format is an XML based file format, QML is our own language that's more readable than XML. When I say QML deprecates .ui files, I mean that the QML-based format is better for defining your Qt GUIs than the XML-based format and it's what our tools are starting to use. Irrespective of whether you are using QtWidgets or QtQuick, irrespective of whether you created it in designer/creator or by hand. If you meant QtQuick doesn't deprecate QtWidgets, then you're correct (and we already covered that side more than enough). But please be more careful with your terminology. QML, at least in Qt 5, is conceptually distinct from QtQuick even though they make an awesome pair. .ui files might also be miffed at being mixed up with the widgets you typically use inside them ;) . There's nothing wrong with QML, there's also nothing wrong with UI files, they just serve different use cases. QML was originally commissioned to replace .ui files. We over-reached our mandate for sure, but we haven't lost sight of it ;) . -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML and JavaScript extensions
On Fri, Nov 15, 2013 at 2:17 PM, Kevin Krammer kevin.kram...@kdab.com wrote: [...] Quoting your latest post: I can understand that you'd like to have the same script engine evaluate both types of script, but since the decision was to make an optimized version for QML, you can either try to shoehorn your code into that limited engine or use what you already have. The engine that runs QML implements the ECMAScript standard and it must have all the necessary tools for extending JS with C++. Otherwise, it could be used to implement neither QML, the extensions QML already has added to ECMAScript nor ECMAScript itself. The lack of a public API to these features is the only reason I need to do the shoehorning every time the engine is changed. True. If QJSEngine is defined to be fully ECMA compatible then that is of course possible. I was primarily working under the impression that while QJSEngine was intended to replace QtScriptEngine, the need for V4 made that less likely. V4VM is intended to be a fully ECMAScript compatible JS engine (I think it's there already even, for the first release!). The special needs of QML are either in performance profile, or only in the QML parts of QML/JS. AFAIK, the plan (no more long-term than when we were using V8 ;) ) is still for QJSEngine to expose a full ECMAScript compliant JS engine for application scripting, similar to QtScript but QML integrated and avoiding running a second JS engine. Qt is heading to a JavaScript-based future. Widgets are deprecated and replaced by QML. In this situation, a good extension interface to the JavaScript engine that runs QML is a really important feature. I have to disagree with a couple of items here. Qt has already had JavaScript based scripting support for ages, so it is not heading into using it. As for JS in QML, any sensibly designed application will avoid doing business logic process in the UI. That was already not a good idea when using C++, no need to continue bad practise when the new UI technology hands you a nice way to correct that. In Qt4, widgets were still the main UI technology. Nowadays, widgets are deprecated. (I'm putting quotes due to the comments to my last post, but it is really not hard to see where the development is heading.) Prior to QML apps, JavaScript has been a tool to provide scripting support for C++ applications, but applications were not based on it. Now, the situation has turned around: JavaScript/QML app, C++ extensions. Therefore, I'm sticking to my statement: a good extension interface is an important feature. We will have to disagree there. I consider the UI to be replacable, as free of application logic as possible. In that model QML instantiates objects and connects/binds them. I understand that there is a different approach, basically creating applications like webapps. Do all processing in the UI, only use components for visualization and platform integration. It's more complex than that, because the split between UI logic and application logic can be hard sometimes, especially when the multiple UIs aren't exposing the exact same functionality. (Obviously they expose the same core functionality, but maybe the enterprise edition has more cowbell?) The intended approach, for a JS/QML app with C++ extensions, is that the UI and UI logic are in JS/QML, the application logic is still in C++, but it's exposed through reusable modules. So some stuff that's on the edge moves from application logic to ui logic. As an example, take storing high scores in SameGame. Current model is that it's application logic (NB, samegame has the app logic in JS) but with a HighScores module encapsulating that logic, it could move out of the JS files and start using that module from QML directly as passing the score to the logic module is UI logic. The advantage here is that new UIs can bring in modular secondary functionality easily, like web highscores or time-decay highscores, without needing to touch the application logic. Sorry I don't have a very clear example/story here, as I said we're not up to this point for realistically sized apps ;) . -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML and JavaScript extensions
On Thu, Nov 14, 2013 at 8:01 AM, Topi Mäenpää topi.maen...@intopii.com wrote: On 11/14/2013 04:43 PM, Robin Burchell wrote: On Thu, Nov 14, 2013 at 3:08 PM, Topi Mäenpää topi.maen...@intopii.com wrote: Or rather could, if the interface wasn't a moving target. If an interface is a moving target, that means that trying to promise compatibility for it is generally a bad idea. I don't quite get this. Can you elaborate? I was trying to say that the stuff I'm trying to do is doable in principle as proven by the couple of different implementations made so far. But every new release of Qt makes me hold my breath because I know I have used features that aren't promised to be available. Once something is made public, you're stuck with it. For a very long time, and maybe even forever if people get too attached to it. You can't go back on that, so you need to be very, very sure you'll be happy with it. As evidenced by the v8 to v4vm change, we aren't there yet. And once we do expose it, we tie our hands from making future changes that might be in our benefit. This is true, but also a common excuse. I have seen it being used to block quite a few feature requests in many projects. Now, however, we already have a pretty good API definition: QScriptEngine already provided just about everything that was needed. All those things are doable in v8, and I bet also in v4vm. It is just a matter of writing a few interface classes that hide the implementation details. That would free extension developers from the burden. Pick the wrong interface classes, like QtScript did, and you suffer in the long term. That's why we aren't committing to anything more than the overly basic QJSEngine API just yet. As I understand it, the long term plan is to extend the QJSEngine APIs and drop QtScript (and add QtWebEngine). Then for application scripting purposes you can use QML/JS for QObject integrated scripts or generic JS and it will work for the cases previously fulfilled by QtScript (and use QtWebEngine for HTML5/JS scripts). V4 integrates better with Qt than V8 did, so as an application scripting addition to the Qt framework it does have better potential (and QtWebEngine will have access to the platform browser's JS engine if you need something for big scripts with no or minimal application integration). Ways it integrates better includes: Faster for jumping in and out of JS, faster when dealing with Qt types, runs on all platforms Qt does, potential for better Qt Creator debugging and of course tighter QML integration. So providing a JS engine for application scripting is less of an afterthought and more of a second stage once we finish the QML engine rewrite. But that's a long term plan, v4vm isn't even released yet (new in 5.2 remember) and there's still tons of work to do. Until v4vm is ready to take over from QtScript, which will still be a while, I believe the recommendation is to keep using QtScript. It's deprecated and done because we've reallocated development priorities, but until we've finished its replacement it is your best option. Even though it means using old or no QML, it sounds like the JS support is more important for you. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML and JavaScript extensions
On Thu, Nov 14, 2013 at 9:31 AM, Thiago Macieira thiago.macie...@intel.com wrote: On quinta-feira, 14 de novembro de 2013 17:25:08, Tony Van Eerd wrote: But that's a long term plan, v4vm isn't even released yet (new in 5.2 remember) and there's still tons of work to do. Until v4vm is ready to take over from QtScript, which will still be a while, I believe the recommendation is to keep using QtScript. It's deprecated and done because we've reallocated development priorities, but until we've finished its replacement it is your best option. Even though it means using old or no QML, it sounds like the JS support is more important for you. Where do value-types (ie non-QObject, copyable, etc) fit into the plan? Definitely in the plan. The long-term plan, it's not yet on the radar for exactly when it might happen. But we've needed it internally a lot already for good APIs, and so we know it's needed (and we know the internal APIs aren't good enough yet ;) ). The example I like is how the particle system can expose individual particles for manipulation in JS without the insane overhead of creating thousands of extra QObjects. Since QtQuick.Particles is obviously not a built-in language feature, it demonstrates that 3rd party modules need this API but alas we currently only have the private APIs (quite risky to use if you aren't inside the qtdeclarative repository). I find that forcing classes to be QObjects just to make them QML accessible really denigrates some API designs. Any advice? Value-type classes need adaptation to work in QML. Make them sharable, copyable, whatever is needed, then we need to figure out how to make QML understand them. The metatype system is a start, since it can manage those types' lifetime. I think it can even compare them for equality these days. Using QObjects is certainly the easiest path, and will probably continue to be the only path for some of the more advanced QML-only usecases (grouped properties and attached properties come to mind). But there are cases where it's worth filling out an adapter to avoid having to subclass QObject, especially since the adapter should have no per-instance cost. So *long-term* I would expect a public value type API, which would probably work with straight JS as well as QML/JS. Unless QObject becomes free per-instance ;) . PS: One feature on the list for the qml runtime is to just run straight JS files in v4: https://bugreports.qt-project.org/browse/QTBUG-34852 . Missed the 5.2 timeframe though. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML and JavaScript extensions
On Thu, Nov 14, 2013 at 11:20 AM, Topi Mäenpää topi.maen...@intopii.com wrote: Pick the wrong interface classes, like QtScript did, and you suffer in the long term. That's why we aren't committing to anything more than the overly basic QJSEngine API just yet. This is true for all new features. Fearing mistakes however means no innovation and no progress. But of course all new features need to be planned well and priorized. What I'm trying to achieve is to explain why this is an important issue and hopefully raise its priority so that it will be implemented soon. Find the JIRA task and vote ;) . As I understand it, the long term plan is to extend the QJSEngine APIs and drop QtScript (and add QtWebEngine). Then for application scripting purposes you can use QML/JS for QObject integrated scripts or generic JS and it will work for the cases previously fulfilled by QtScript (and use QtWebEngine for HTML5/JS scripts). V4 integrates better with Qt than V8 did, so as an application scripting addition to the Qt framework it does have better potential (and QtWebEngine will have access to the platform browser's JS engine if you need something for big scripts with no or minimal application integration). Ways it integrates better includes: Faster for jumping in and out of JS, faster when dealing with Qt types, runs on all platforms Qt does, potential for better Qt Creator debugging and of course tighter QML integration. So providing a JS engine for application scripting is less of an afterthought and more of a second stage once we finish the QML engine rewrite. I haven't been following the long term plans closely, but I believe this holds true for v4vm. In the current v8 implementation, however, QJSEngine is practically useless. It cannot be extended, and it even makes references to QML in the source code. But that's a long term plan, v4vm isn't even released yet (new in 5.2 remember) and there's still tons of work to do. Until v4vm is ready to take over from QtScript, which will still be a while, I believe the recommendation is to keep using QtScript. It's deprecated and done because we've reallocated development priorities, but until we've finished its replacement it is your best option. Even though it means using old or no QML, it sounds like the JS support is more important for you. I considered the options carefully before switching to Qt5. I talked to Digia engineers and they told me the same you are telling now: QtScript will be deprecated and definitely not accessible from QML. Therefore, it was completely out of question. I don't think building anything serious on a deprecated API is a good idea anyway. Qt is heading to a JavaScript-based future. Widgets are deprecated and replaced by QML. In this situation, a good extension interface to the JavaScript engine that runs QML is a really important feature. Otherwise, it is difficult to extend the functionality of UI applications. Since Qt is a UI toolkit after all, I believe most Qt applications have an UI. Anyhow, I understand that your resources are limited and this isn't going to be implemented this week. But can I count on v4vm being the script engine used for the foreseeable future? If yes, is there an API documentation so that I could familiarize myself to the internals? The v8 interface was pretty straightforward stuff so I believe porting the code to v4vm isn't a huge deal either. But without documentation it'll take a lot longer. v4vm is better documented than v8 (still not really documented though), and will probably be in use until Qt 6 (if only because I expect we'd bump the major version if we switched again :P ). While I do expect v4vm to be used for the foreseeable future it's still young, and immature, and that means change. Especially since we have total control and we need to take advantage of that lack of public API as much as possible ;) . But at least the creators are still around, unlike the other engines. Hopefully they'll add some insight when they wake up, and you can always ask questions in #qt-v4vm on freenode (CET hours at least). -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] the need to add a Task-Number in the release branch ...
On Wed, Nov 13, 2013 at 4:38 AM, Oswald Buddenhagen oswald.buddenha...@digia.com wrote: moin, in http://lists.qt-project.org/pipermail/development/2013-June/011610.html thiago proposed that all changes pushed for release need to come with a task-number footer. the proposal met moderate approval. little surprisingly, thiago seems to be the only person (i noticed) who is actually enforcing this rule. and causing a lot of unnecessary churn, imo. creating jira tasks just for the sake of being able to reference them in the commit messages does not improve the quality of the git history. the only purpose of the exercise is convincing the reviewers (and the release team who stages the change, and possibly also yourself) that the change actually does belong into the release branch. as this pertains only to the review/integration process, i think it's sufficient if all related activity is limited to the relevant tool: gerrit. so my counter-proposal is this: - you don't *need* to create a task just for the sake of it (of course you should still do it if it really helps you). as an alternative to actually creating and prioritizing a task, you can do it as a thought exercise (and possibly mention your priority estimate in the commit message). - you need to convince the reviewer that the change is necessary to start with. you do that in the commit message. obviously, you should be doing that *anyway*, but maybe put a bit more emphasis on it in release times. and keep it later on. ;) - if the urgency of the change is not obvious to the reviewer, they'll say that in a comment. you may now need to amend the commit message (if some key information is missing, e.g., that the change causes incompatibility). other than that, the obvious recourse is doing the convincing in followup comments. you may even write a comment pre-emptively. or to put is a bit concisely, the proposal is to simply pay attention to the existing rules consistently instead of creating an entirely unnecessary paper trail. The paper trail is necessary for history and for communicating with others and what I'm seeing here is that you want to be able to have it entirely in gerrit (you haven't asked for any relevant content to be dropped, just moved to review comments). Gerrit is the wrong tool for that, review comments are not easily searchable. Even git is not always that great, especially since we tell people that JIRA is where we track issues and so that's the first place people will look. I'm fine with the enhanced scrutiny on release branch when theoretically *all* commits should have a JIRA task associated (even though everyone agrees that it's not worth bothering with that for most work). My only problem is that resubmitting the patches can be a problem (needs to be at a workstation set up for development, then needs to be re-approved). I'd recommend (and have kind of been doing) that it's okay to just add the JIRA task number as a comment on gerrit. Then you don't get the automatic JIRA source integration, but it's easy enough to put in a comment with the link to the codereview change (mitigating the 'searchable' problem) or filling out the changes field yourself (ah, that takes me back ;) ). -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.2 header diff
On Fri, Nov 8, 2013 at 4:59 AM, Heikkinen Jani jani.heikki...@digia.com wrote: Hi all, What is the situation with reviews especially potential fixes? Is all needed now done and so on can we start merge on Monday morning? https://codereview.qt-project.org/#change,70479 still needs to merge. It should be ready, and all the dependent changes have already merged, but it hasn't quite yet. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt 5.2 qmltypes update
Similar to the header diffs, each minor version the .qmltypes files for QML plugins gets updated and that diff (https://codereview.qt-project.org/#change,70479) should show everything that snuck into public QML APIs. I put my comments on gerrit, it's better for inline review of code diffs. But it raised two questions: A) Would the ML like to see these? I can start the process for all the modules which expose QML imports and post them to devel same as Thiago's header diffs. Eventually the process of updating the APIs should include updating the qmltypes file in the same commit, but diffs could still be posted then. B) It hit a few known issues (QTBUG-30309, QTBUG-33179 and QTBUG-34602) with the QML versioning. They're mostly low priority, due to it not having any practical impact on the runtime. But it shows up in the .qmltypes files, so I'm wondering if we should prioritize them for more accurate auto-completion? -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.2 header diff: QtDeclarative
In case anyone's wondering why a deprecated module had a header change, it was just a backport of removing a compiler warning (VS2010 specific). No new functionality here. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Qt-components] Propose new Qt Quick component
On Sat, Nov 2, 2013 at 6:02 PM, Alessandro Mommo alessandro.mo...@gmail.com wrote: Helo, this is my first post and i don't now if this is the right place. However, I would like to propose two items for the Qt Quick Controls module, ideal, but not only, for mobile application running on touch devices. One is a Spinner like that in the Qt 4.8 qml examples with some enhancement in the presentation and in the usability. Another is a Combobox, similar to the one already existing but with a customizable delegate that, unlike the current one, lets visualize virtually any model the user wants as well as a more attractive look. Another thing missing in the current one, but available in my implementation, is the ability to increase the height of the rows in the ListView, which greatly limits its usability on touch devices. What should I do to propose the components in such a way as they can be taken into consideration for inclusion in future release? 2 things to do. 1) Email the development(cc'd) or qt-interest list. The qt-components list is defunct and should have been shut down by now. Then you can see what other people think of the idea. I like the idea of the touch spinner (which could just be a touch-variant of the SpinBox). But the customizable delegate combobox is either already there, hidden behind the Styles API, or so custom that they may as well write the combobox part as well as the fully custom delegate. 2) To be even more considered, show some code on gerrit (or github or similar, if you've already written versions of these components that you want to share as an example). -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Maintainership of QtNetwork
On Mon, Nov 4, 2013 at 11:58 AM, André Pönitz andre.poen...@mathematik.tu-chemnitz.de wrote: On Mon, Nov 04, 2013 at 04:25:26PM +, Koehne Kai wrote: -Original Message- From: development-bounces+kai.koehne=digia@qt-project.org [mailto:development-bounces+kai.koehne=digia@qt-project.org] On Behalf Of Richard Moore Sent: Monday, November 04, 2013 1:32 PM To: development@qt-project.org Subject: [Development] Maintainership of QtNetwork Hi All, As some of you may know, Shane has a new job and therefore has a lot less time to spend on QtNetwork. He, Peter and I have discussed how we should maintain the module in the future. What we're proposing is that Peter and I take over as joint maintainers since neither of us has the time to keep on top of things alone. Anyone looking to help out in this area should feel free to drop us a mail. This isn't a veto or anything, but having two 'equal' maintainers for the same area sounds odd to me. I mean, it's perfectly fine that you split up the workload, but the point of having a nominal maintainer is to have _one_ person to go to, and _one_ person who can decide if there's need ... It doesn't mean that the maintainer can't delegate his work though, up to the point that whomever he trusts can act as a de-facto decision maker, too. Well, I am pretty much in the other camp. I see no problem here, neither of the setup in general (better bus factor, less chance of overload, something that rather should be encouraged...) nor with Rich and Peter in particular. You're missing the point of having a hierarchy, which is to deliberately assign clear bottlenecks for responsibility (and they shouldn't be used that often). Maintainer isn't that different from approver, there shouldn't be any more bus factor or overload because the real work is split between the approvers/contributors in that area already (PS: Everyone is welcome to fix QtQuick bugs for 5.2 :D ). If a contributor want a definite maintainer answer he puts both co-maintainers on the reviewer list. Something will happen. I'd like to limit the set of possible somethings, for a theoretically simpler structure. Back from the general to the specific, I'm definitely happy with Richard and Peter stepping up if Shane no longer has time. It's better to have too many good maintainers for a module than too few. Since I think it'll be a long time until we hit a situation where the designated tie breaker rule will be needed, I'd suggest we vote them both in first and then tackle the general question of shared maintainerships separately. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5 regression with PathView (or I am missing something?)
On Fri, Nov 1, 2013 at 7:38 AM, Felipe Crochik qt-proj...@b2-4ac.com wrote: I just filled a bug report (https://bugreports.qt-project.org/browse/QTBUG-34520) but since I am seeing other cases where my application crashes due to ASSERT statements on the scenegraph\coreapi\qsgbatchrenderer.cpp I started wondering if I am missing something. A new Scenegraph renderer was integrated for 5.2, and it's has caused a few asserts. Thanks for testing the beta, we've squashed a lot of those already and so you should retry with the RC when it comes out. On my bug report you will find two cases (with attached code) and I have already found another one. I may be wrong about this but it seems that the behavior of PathView on QtQuick 2 is different than the one on QtQuick 1 (qt4.8) without any apparent obvious reason. I haven't managed to create a way to reproduce but it seems that changing the currentIndex by code doesn't actually change the currentIndex immediately (maybe just actually changes the value after the animation) That's just a bug in Qt :) . As a workaround in most situations, set highlightRangeMode: PathView.ApplyRange . p.s. My application is quite simple, 100% qml/javascript using only plain qml components and used to work just fine on Qt 4.8 Technically there is no behavior compatibility guarantee between QtQuick 1 and QtQuick 2, but we tried to keep the differences short and document them all here: http://qt-project.org/doc/qt-5.0/qtquick/qtquick-porting-qt5.html . If something's missing on that page, it should be added. Not sure if bugs qualify though, I'd rather just fix them than amend the docs. PS: inter...@qt-project.org is probably a better list for asking about bugs and behavior, I recommend using that list next time. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML, Widgets, and setParent
On Sat, Nov 2, 2013 at 5:06 AM, Kevin Krammer kevin.kram...@kdab.com wrote:
On Saturday, 2013-11-02, 11:25:07, Konrad Rosenbaum wrote:
Hi,
On Saturday 02 November 2013, Kevin Krammer wrote:
On Thursday, 2013-10-31, 20:17:43, Konrad Rosenbaum wrote:
I've got it running
for trivial QML files, however as soon as there are child widgets the
running program aborts.
The abort is caused by QObject::setParent, which contains this little
gem: Q_ASSERT(!d-isWidget);
Hmm. The same code is in Qt4. I think it works for me/us because we are
building against our distribution's Qt packages which are release builds
and thus doesn't have the Q_ASSERT.
No, it works for you because the Qt4 QML code (qqmlvme.cpp) contains special
code to handle Widgets - in Qt5 it was deactivated to remove the dependency
on the QtWidget module.
The Qt4 code does not call setParent if the object is a widget and the parent
is not, e.g. if the parent is a layout. Still seems to work quite well.
Maybe it would still work if the Qt5 code did something like this:
if (!o-isWidgetType)
QQml_setParent_noEvent(o, parent);
The code of QObject::setParent itself is absolutely identical (I didn't
check all the lines of QObjectPrivate::setParent_helper though). Qt4
contains the same Q_ASSERT.
Sure, what I was saying is that maybe it works for me because I am using a
release built Qt4. Q_ASSERT is not part of release build object code.
I kind of ran out of ideas on how to solve this. Should I consider
setParent, qqmlvme or the direct use of QWidgets as a bug?
I agree with Alan on setParent() being in error, the problem is some
other areas rely on that. E.g. QWidget::parentWidget() does a
static_cast of parent() to QWidget*
Upon reading the code of QWidget a bit more I must conclude that this was
done deliberately (both in Qt4 and Qt5). If widgets are supposed to be able
to have non-widget parents, then this is one hell of a design bug that can't
be easily fixed inside a single minor release.
The thing is that the widgets wouldn't have non-Widget parents, at least not
in DeclarativeWidgets. The parent is either a widget or, most of the times, a
layout. The layouts' addWidget methods reparent to their parent widget.
Therefore one option might be to just not call set parent on widget objects
and let the list property code deal with reparenting.
I'm surprised this works. There's implicit QObject parenting built
into the language, for example:
QtObject {
id: foo
property Widget bar: Widget{}
}
Will automatically make foo the qobject parent of bar.
I'm not certain, but I think this happens before it gets assigned to
the property which might make any declarative widgets example using
layouts crash in debug builds...
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML, Widgets, and setParent
I'd argue that it's setParent with the bug. It's conceptually valid to have a QWidget with a QObject parent but no QWidget parent, but it won't really show up until you try to use them in QML. If you do this with non-QML QWidgets, then it won't show up on screen so the user will think they've made an error (but with QML there's an intermediate state it goes through even in a correct usage case). QML as a language requires that you can set the QObject::parent on instances of QML types, so if that QObject assert is valid it means you can't use widgets in QML without hacks (specifically, that exact hack you found already which doesn't allow intermingling). -- Alan Alpert On Thu, Oct 31, 2013 at 12:17 PM, Konrad Rosenbaum kon...@silmor.de wrote: Hi, I'm trying to port KDAB's DeclarativeWidgets[1] to Qt5. I've got it running for trivial QML files, however as soon as there are child widgets the running program aborts. The abort is caused by QObject::setParent, which contains this little gem: Q_ASSERT(!d-isWidget); Apart from not understanding why there is a significant difference between QObjects and QWidgets in regards to parenting... There used to be code that handled this in qqmlvme.cpp[2], but it has been disabled by an #if 0 . Apparently to remove dependencies on QtWidgets from QtQml. I kind of ran out of ideas on how to solve this. Should I consider setParent, qqmlvme or the direct use of QWidgets as a bug? Konrad [1] It enables you to create widget based GUIs using QML. git://github.com/KDAB/DeclarativeWidgets [2] In 5.2 beta this is line 627 in qqmlvme.cpp. It's Halloween. Go ahead, look at scary code! ;-) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Topi Reiniö (topi.rei...@digia.com) as approver
On Tue, Oct 22, 2013 at 7:45 AM, Thiago Macieira thiago.macie...@intel.com wrote: On terça-feira, 22 de outubro de 2013 14:08:28, Martin Smith wrote: actually, I think that he shouldn't go through this process since he was a Nokia employee before Open Governance was in place, so he should have been added before the Open Governance launch. If that was not the case, then it was a mistake. I think that might apply to everyone on the doc team. +1 to Topi. +1 for Topi, I've liked his work on the qtdeclarative examples and docs. Anyone who has been working in those two years probably deserves to be an approver with the current rules, without having to resort to the old grandfathering. Otherwise, if in those two years someone has not participated in the Qt Project, the grandfathering should really not be used. +1, we have a good process and it seems to be working fine in this case. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Codifying the .qml License Header Exemption
On Mon, Oct 21, 2013 at 1:37 AM, Mitch Curtis mitch.cur...@digia.com wrote: On 09/21/2013 12:15 AM, Alan Alpert wrote: A while ago it came up that the rules for license headers in QML files isn't clearly defined. Here's my suggestion for how to define it, and if the project likes the idea we can get a legal check and then fix up the infrastructure to follow (sanity bot and license-check test). Current rule is roughly can be skipped in tests. It's that way for a reason, QML unit tests necessarily involve lots of trivially simple QML files to test just one specific part of the language. We have separate tests for comment parsing, we don't need to extend the CI runs with a ton of double-checking here ;) . Since I'm pretty sure the concept is supposed to be only bothering for non-trivial code (because bothering to add headers to trivial code is useless, boring, and depressing) adding a size limit would be the easiest way to make this automatable. Looking at the file sizes, I recommend excluding QML files under tests from requiring a license header if they have =15 LoC. If those few lines are really ingenious contributors are recommended to add a header anyways and there's nothing wrong with adding the headers. But if you don't add a header for such a small file in tests (and the reviewer agrees the files are trivial), then you don't get blocked. Note that the abundance of tiny, trivial QML files is a tests specific problem and so I think this exemption should only apply to the tests subdir. All doc/example code should still have license headers checked. If this sounds good to people, I'll prepare patches to update the system. Not patches that add/remove license headers to existing tests. For reference, this recent patch got a ton of bogus warnings: https://codereview.qt-project.org/#change,63591 And this patch is blocked because the current exemption is tests/auto specific: https://codereview.qt-project.org/#change,64331 when tests/benchmarks is obviously in the same boat (and test manual is on the fence, so should be left to human judgement). Appendix A: Graphs of data (LoC in .qml files after removing all headers) which informed this suggestion: QML file size under tests Inline image 1 Same data, zoomed in to see that spike in better res. 15 seems like the sweet spot in the data (while still being a fairly trivial amount of formatted QML code). Inline image 2 Length of .qml files in the examples sub-tree for comparision (same x-axis scale as the 1st graph): Inline image 3 With a 40 line license header, and looking at those graphs, I think we're looking at 60kB of license headers on trivial files if we force all the =15 LoC test files to have licenses. If nothing else, think of the poor people on dialup ;) because that's above the large file warning the bot hands out so freely. -- Alan Alpert Are you still interested in doing this, Alan? Yeah, just lost track of it in the travel hullabaloo. Here's the initial implementation attempt: tst_license.pl: https://codereview.qt-project.org/#change,68767 sanitize-commit: https://codereview.qt-project.org/#change,68770 (warns at = 20 LoC, since people seemed amenable to a bit above 15). -- Alan Alpert. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Codifying the .qml License Header Exemption
A while ago it came up that the rules for license headers in QML files isn't clearly defined. Here's my suggestion for how to define it, and if the project likes the idea we can get a legal check and then fix up the infrastructure to follow (sanity bot and license-check test). Current rule is roughly can be skipped in tests. It's that way for a reason, QML unit tests necessarily involve lots of trivially simple QML files to test just one specific part of the language. We have separate tests for comment parsing, we don't need to extend the CI runs with a ton of double-checking here ;) . Since I'm pretty sure the concept is supposed to be only bothering for non-trivial code (because bothering to add headers to trivial code is useless, boring, and depressing) adding a size limit would be the easiest way to make this automatable. Looking at the file sizes, I recommend excluding QML files under tests from requiring a license header if they have =15 LoC. If those few lines are really ingenious contributors are recommended to add a header anyways and there's nothing wrong with adding the headers. But if you don't add a header for such a small file in tests (and the reviewer agrees the files are trivial), then you don't get blocked. Note that the abundance of tiny, trivial QML files is a tests specific problem and so I think this exemption should only apply to the tests subdir. All doc/example code should still have license headers checked. If this sounds good to people, I'll prepare patches to update the system. Not patches that add/remove license headers to existing tests. For reference, this recent patch got a ton of bogus warnings: https://codereview.qt-project.org/#change,63591 And this patch is blocked because the current exemption is tests/auto specific: https://codereview.qt-project.org/#change,64331 when tests/benchmarks is obviously in the same boat (and test manual is on the fence, so should be left to human judgement). Appendix A: Graphs of data (LoC in .qml files after removing all headers) which informed this suggestion: QML file size under tests [image: Inline image 1] Same data, zoomed in to see that spike in better res. 15 seems like the sweet spot in the data (while still being a fairly trivial amount of formatted QML code). [image: Inline image 2] Length of .qml files in the examples sub-tree for comparision (same x-axis scale as the 1st graph): [image: Inline image 3] With a 40 line license header, and looking at those graphs, I think we're looking at 60kB of license headers on trivial files if we force all the =15 LoC test files to have licenses. If nothing else, think of the poor people on dialup ;) because that's above the large file warning the bot hands out so freely. -- Alan Alpert auto-example.pngauto-all-small.pngauto-all-all.png___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtQuick ML
On Tue, Aug 27, 2013 at 12:46 PM, André Pönitz andre.poen...@mathematik.tu-chemnitz.de wrote: On Tue, Aug 27, 2013 at 03:48:18PM +0200, Juergen Bocklage-Ryannel wrote: On 24.07.13 5:41 PM, Alan Alpert wrote: Since I can't seem to get them to speak up, I guess they don't care that much after all. I'll withdraw the suggestion again. See you in six months :P Sorry haven't seen this thread. I'm working in several customer projects now using purely QML/JS. Some other developers do the C++ parts. When we work with customers we have a similar split: Frontend Developers do the QML/JS code and Backend Developers do the C++ code. We work with frontend developers who don't have a great understanding of C++ and also are not interested in it. They are interested into ui elements / animations / javascript / concepts / recipies, etc... A mailing list where people speak about Qt/C++ mixed with some QML/JS would just confuse them. Those frontend developers are surely not overly interested in the _development of Qt_, more of it's use, for which there's already inter...@qt-project.org. I think there is a great need to have an open forum / mailing list for QML/JS users. Not sure if a Qt mailinglist is the right place for people, but better than a mixed mailing list. Maybe for _users_ of QML and JavaScript. And if so, this should be clear in the naming of the list, e.g. by calling it qtquick-us...@project.org. André is correct that it's a separate issue, but it sounds like one worth pursuing. +1 from me on the creation of a qml-inter...@qt-project.org list to match the C++ (and hybrid use-case) qt-interest list. As for forum, it already exists: http://qt-project.org/forums/viewforum/12/ . But MLs and forums attract different sorts of people, so I think there's value in having both. Personally I think there needs to be greater interaction between QtQuick developers and QtQuick users. One of Qt's great strengths before was that the developers were also the target audience, we wrote the very APIs that we'd want to use (and it worked so well that all our seasoned experts have left to become full-time Qt users ;) ). But Qt is C++ and primarily crewed by C++ developers, so this declarative/scripting thing targets a different audience than ourselves. I think that means we need to work harder to remain close to our users and ensure that our APIs truly provide value. So I would recommend all persons developing QML/QtQuick to join the users ML too, and that API discussions involve the users list sometimes. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New JIRA type 'Feature'? (was RE: FW: Proposal for RFC like feature process)
On Wed, Aug 14, 2013 at 12:03 AM, Koehne Kai kai.koe...@digia.com wrote: Alright, discussion about a new JIRA type 'Feature' went on at https://bugreports.qt-project.org/browse/QTJIRA-233 with two different ideas: 1) That we already have too many issue types in JIRA, and adding another one makes things just worse, since the line between different types is blurry anyway 2) that a separate 'Feature' type that's can only be created by approvers, and follows stricter standards, is a good thing to let roadmap / important features stand out I personally think it's useful, but also think it only makes sense if the type is really used by at least the majority of maintainers ... So, I'd like to ask specifically you, the maintainers: Would you use a separate 'Feature' type? This is meant to describe things that typically would show up on a roadmap release blog, or that you'd want to discuss with stakeholders ... Regards Kai -Original Message- From: Blasche Alexander Sent: Tuesday, August 13, 2013 1:32 PM To: Koehne Kai; Koehne Kai; Alan Alpert; Bubke Marco Cc: development@qt-project.org Subject: RE: [Development] FW: Proposal for RFC like feature process Creating an issue type is very easy. What's not easy is to commonly agree on what each type means and to consistently apply them. That's something where no admin can help as the community has to agree upon it. For what is is worth I am very much in favor of such a feature type. -- Alex rant Unless a benevolent dictator comes around my experience tells me that there won't be an agreement any time soon(10 years of issue tracking inside Qt seem to have gotten the better of me). /rant Alex's argument is entirely correct here (rant esp.). So I'm only in favor of a new feature type if we can agree on the meaning and then have a realistic expectation that we'll apply it consistently. Specific questions I have about the feature type are A) Do we have a clear distinction between Feature and Suggestion (also Feature and Task)? B) Can contributors create Tasks? If not, would using Task again help? Since it's already there we can start using it while having the discussion of what it means, call it an advanced feasibility use-case trial. C) Isn't a roadmap in an open governance project now defined by what tasks people are working on? So wouldn't in progress state on high priority suggestions/tasks/bugs be more appropriate as the roadmap? Why are contributors who are working on such items any different from approvers? I would also not expect stakeholder discussions to be easier or more fruitful if they could happen in JIRA instead. Which some possibly should already have done, so my ability to consistently communicate through JIRA may not be high enough to handle a new issue type ;) . -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Enabling -Werror developer builds
On Mon, Aug 19, 2013 at 3:14 PM, Thiago Macieira thiago.macie...@intel.com wrote: Hello Commit ebfd85a499a4382ace09d443b1f35cd6b1848af6 adds support for -Werror, but it hasn't been acted on yet. The commit says: This is enabled only for -developer-builds and only for certain compiler-version combinations that are in a whitelist. It also requires each library, plugin or tool to declare whether it is supposedly clean of warnings. When most targets are clean, we can consider inverting. So, expanding: 1) -Werror is opt-in for regular builds (pass -warnings-are-errors to configure), and opt-out for developer builds (pass -no-warnings-are-errors). 2) -Werror is enabled only for certain compiler versions. I'll update the whitelist to have an upper range too. For example, right now it enables - Werror for GCC 4.6 and above. I'm going to introduce an upper limit because we don't know what new warnings our code triggers with newer versions of GCC. That means we'll need to first clean up the warnings before expanding the whitelist. How is this clean up to be managed? The scenario I'm envisioning is that warnings are cleaned up inside qtbase, allowing the change to pass CI, while a new warning appears in another module which is then broken by the qtbase change. We might need to integrate qt5.git merging into the whitelist expansion test somehow, or provide another solution so that all modules are checked before updating the whitelist. Other than this future concern, setting -Werror like this sounds good to me. Some people build with it already so I've received bugs before when public headers don't compile with -Werror. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] AplicationWindow, QQuickWindow, contentRotation and setting width and height of contentItem
On Fri, Aug 2, 2013 at 11:49 AM, Tomasz Olszak olszak.tom...@gmail.com wrote: You should also be able to work around it inside your ApplicationWindow by hiding the parent property on your content item. Something like property Item parent: null should make it look like the root of the tree. It's not great, but you actually want to pretend to be the root of the tree (it's not just a ModalPopupBehavior hack). Right it solves more issues, but modals are most common. Unfortunately i will not work. When I declared such property I got: Cannot override FINAL property The other workaround that comes to mind is to define your ApplicationWindow in C++ by subclassing QQuickWindow.h and implementing your own contentItem which does include the rotation behavior. I very would like to use ApplicationWindow from QtQuick.Controls module so I would rather not to do that. Would either approach be sufficient for your needs? Because of above, either ApplicationWindow will be moved to C++ or another solution will be found or idea of reusing ApplicationWindow dropped. Didn't you consider such case that certain Item could be declared as quasi root of the tree? From the QtQuick.Window side, no. Root items don't really matter from QML because they shouldn't be traversing the tree and there's no point otherwise (because children can go outside their parent, you can't properly use the bounding box for example). So if the controls want to have a quasi-root item, they should probably provide it and make it manageable. It sounds to me like ApplicationWindow would benefit from a configurable Item topLevelItem property for stuff like modal dialogs or other content which needs to be on a different layer to the 'main scene'. This could then be used like its own contentItem, but a little more customizable. Another possibility would be to drop the FINAL from contentItem, While parent is used enough that FINAL is very valuable, contentItem is just for workarounds so dropping FINAL should be fine. Then the controls ApplicationWindow could use the contentItem property directly for modals and such, and you'd be able to intercept it. -- Alan Alpert PS: Sorry for the delay, I forgot about this draft :( ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Enabling -Werror developer builds
On Mon, Aug 19, 2013 at 4:47 PM, Thiago Macieira thiago.macie...@intel.com wrote: On segunda-feira, 19 de agosto de 2013 15:40:06, Alan Alpert wrote: 2) -Werror is enabled only for certain compiler versions. I'll update the whitelist to have an upper range too. For example, right now it enables - Werror for GCC 4.6 and above. I'm going to introduce an upper limit because we don't know what new warnings our code triggers with newer versions of GCC. That means we'll need to first clean up the warnings before expanding the whitelist. How is this clean up to be managed? The scenario I'm envisioning is that warnings are cleaned up inside qtbase, allowing the change to pass CI, while a new warning appears in another module which is then broken by the qtbase change. We might need to integrate qt5.git merging into the whitelist expansion test somehow, or provide another solution so that all modules are checked before updating the whitelist. Someone or a group of people fixes all the warnings with a given new compiler version in all modules. Once all changes are in, past the CI and possibly past a qt5.git integration, we expand the whitelist in qtbase. Worst case scenario, there's a race condition with new code that introduces a new warning. Given how long CI integrations can take I would not be surprised to see such a race condition occur. But so long as all modules is explicitly in the process (and we can't think of a good automated test for it) I can accept that risk. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Controlling a QtQuick ListView using its contentY shall be supported or not?
On Tue, May 21, 2013 at 10:32 AM, Albert Astals Cid albert.ast...@canonical.com wrote: TLDR: Controlling a ListView using its contentY doesn't work and we have a use case that needs it. I am volunteering to code the solution to make it work but the question is what solution the Qt project wants :-) What I want to see is a better abstraction. ListView is complicated enough already, and doesn't fit in well with the primitives goal of QtQuick. So given infinite time, I'd go back to researching a better abstraction so that you can just create your own ListView for custom behavior - as easily as you'd create your own Button. Practically, I think we'll have to compromise on that right now :( . THE PROBLEM Our design team wants a ListView with Header that behaves in a different way than the current Header component of ListView does. They want that if you scroll up when the Header is hidden the first thing that happens is that the header shows and then when the Header has been totally shown the list scrolling happens. THE SOLUTION A Flickable that controls the contentY of a ListView and the height of the Header flickable_control_listview_without_sections.qml And it works :-) but... THE PROBLEM #2 We want to have section headers in that listview and adding section headers makes lots of things go weird, you can see the problem in flickable_control_listview.qml either by scrolling up when the list is at the top or by scrolling to the bottom and then pressing 1 to scroll up. The contentY of the list will not be at its expected location. THE SOLUTION #2 I can workaround this by doing crazy things like on the listview onContentYChanged check if it is changing to the value I set it and if not fixing it (fixes the jittering going up from the top) and by remembering the last originY when pressing the 1 to go to the top flickable_control_listview_workaround.qml I consider the changes between flickable_control_listview_workaround.qml and flickable_control_listview.qml a huge hack and something that should not be needed, but we could live with that THE PROBLEM #3 We also want to have items with different sizes in the listview flickable_control_listview_workaround_different_sizes.qml If you go to the end and then press 1 to scrol to the top you'll see that my workaround for the baseOriginY fails THE PROBLEM #4 We also want to have problems if the list view contains complex loaders, haven't had time to create a simple test case for it THE REAL SOLUTION? We would like the code from flickable_control_listview_without_sections.qml to work on all the cases (sections, differently sized items, loader, etc) but we have been told that Using contentY to control a listview is unsupported We are hoping that this use case may make you change your opinion on that statement and accept patches that makes the code in flickable_control_listview_without_sections.qml (or something along the lines) work in all the other situations. In case you keep the statement that noone should use contentY to control listviews (why not make it read-only?) we see two solutions: It's not read-only because it's known to be needed to hack things together. It's what I'd call sub-optimal. Even if we add better support for dealing with contentX/Y manipulations, it would sill be unsupported because that's not how ListView is supposed to be used. It's supposed to just work the right way already, and you don't mess with it (not a good answer for platform components, I know). 1) Add to ListView a enum that switches between the current Header hiding/showing behaviour and the one we want. Would you guys be interested in that feature to be merged upstream? My concern here is the maintenance burden on an already massive class. Conceptually I don't think adding this feature is an issue, but the class is already hard-to-maintain so we need to keep a firm hand on feature creep. I'd be happy to see a patch merged adding this if it's really good quality and doesn't require major changes to ListView internals. If you've got a patch already, I'd like to see it. 2) Reimplement our own ListView based on a Flickable so that it has the features we need. This is the solution we prefer the least since it would involve a lot of code duplication This is supposed to be the correct solution for custom components with QtQuick. You reimplement your own item with the behavior you want, there's a little code duplication but it's all in QML and so easy that it doesn't really matter. But I can see how that approach just isn't working with the view classes just yet. So what's your opinion, how should we implement the wanted behaviour with the current QtQuick items? Don't stick to the current ones. Add new QtQuick items that are better at this ;) . -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo
