Re: [Development] Build system for Qt 6
Having had the pleasure to use QBS quite extensively (and successfully) in the past, I would like to thank the QBS team and contributors for showing us what a sane, modern build system could look like. So long! On Mon, 29 Oct 2018 at 13:17 Lars Knoll wrote: > Hi all, > > As you will probably remember, there have been lively discussions around > what kind of build tool to use for Qt 6 both during Qt Contributor Summits > as well as on this mailing list. > > There has been a strong consent that we should move away from qmake as our > build tool for Qt due to many shortcomings and the burden we have > maintaining the system. > > Thiago wrote a set of relatively strict requirements for such a build tool > in his mail in July. While some of the requirements had a bit of a Linux > specific background, they have been a good basis. > > There have been rather lively discussions around alternatives, but most > focused around two possible choices for us: Qbs and cmake. > > Qbs is something that has been developed almost exclusively by The Qt > Company. As such, TQtC had to also look at it from a business perspective > and how it fits into the larger picture of making Qt successful. To make a > long story short, while Qbs is pretty cool and interesting technology, it > doesn’t really help us expand the Qt ecosystem and usage. > > To make Qbs really successful would require a rather large effort and > investment in promoting it towards the larger C++ ecosystem as a new build > tool. At the same time it has to be an open source product to stand any > chance in the market. Together this makes it challenging for TQtC to see > how to recover that investment. Thus this investment would be at the > expense of other things we’d like to do, like improving our IDE, working on > rearchitecting and cleaning up our core frameworks for Qt 6 or the design > tooling we are currently investing into. The Qt Company believes that those > other investments are more important for the future of Qt than our choice > of build tool. > > As such, we were left with the question on whether we need Qbs as the > build system for Qt 6 or whether cmake (as the other alternative) would be > up to the task. > > Given that background, we’ve done some more research on using both Qbs and > cmake to build Qt. Both projects did give us good results but we were > actually surprised on how far we got with cmake in a rather limited period > of time. > > In addition, cmake has the advantage of being very widely used in the C++ > ecosystem (amongst many others by KDE), has a very wide support in many > IDEs and other tools (e.g. VCPkg, Conan etc.), and there’s a lot of > knowledge about the build system available in the ecosystem. Using it with > Qt 6 would also mean that we can focus our support on two build systems for > our users (qmake and cmake) and we would not have to add a third one to the > mix. > > Given that we are confident we can build Qt 6 with cmake, I believe that > it makes most sense to follow down that route. In case you’re interested, > you can have a look at the cmake prototype code for qtbase on Gerrit in the > wip/cmake branch. Please also let us know if you’re interested in helping > with the effort of porting Qt’s build system over to cmake. > > We have been developing Qbs over the last years, and as such are committed > to it for some more time. We are planning on another feature release in the > first quarter of next year and will support it in Qt Creator for at least > another year. Qbs is open source and if someone wants to take over and > develop it further let us know as well. I’d also like to use this place to > thank Christian and Jörg for all their great work on Qbs (and of course > also anybody else who contributed to it). > > Cheers, > Lars > ___ > 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] QHash iteration vs std::unordered_map
Here is a solution using range-v3 https://github.com/cor3ntin/qt-iterate-over-associative-containers/blob/master/main.cpp - there is of course room for improvement :) 2017-04-20 19:28 GMT+02:00 Matthew Woehlke : > On 2017-04-20 13:18, Sergio Martins wrote: > > On 2017-04-20 18:06, Matthew Woehlke wrote: > >> for (auto i : qtEnumerate(my_hash)) > >> do_stuff(i.key(), i.value()); > > > > That doesn't work with temporaries, does it ? > > No. Neither does std::add_const / qAsConst. > > > Maybe something to fix in the C++ language, since the usual > > lifetime-extension tricks don't help in this case. > > There has been talk, but TTBOMK no concrete proposals yet. (IIRC the > `register` proposal was published but the author decided not to present > it yet.) > > -- > Matthew > ___ > 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] How to include Standard Library headers from Qt ones?
I think that part of the issue is that the way the STL should be treated is a bit of a polarizing issue. Of course, there are technical considerations, such as some STL implementations being lacking on older platforms, but mostly Qt and the STL have some overlaps, and people can't agree on how to handle said overlaps. I personally consider that the STL is as much part of C++ than the core language and any api should therefore be as much compatible with it as possible. Redundant algorithms & utilities ( mutex, shared pointer, etc ), should probably not exist at all at this point, though they used to make sense. As such, Qt containers should work properly with any STL types, and Qt types should work well with the STL constructs, containers, types and algorithms. Most people use Qt as a framework and play by Qt's rules, but for others Qt may just be the UI layer, an other library in the stack. Both use cases should be catered to. More on point: * You don't actually need to include anything from the STL to implement std::hash. * For qHash, maybe one or more qt_stl.h headers that would include the required stl headers. Forward declare when possible ( probably not often, sadly ). Compilations times may, for the time being, be an issue but I don't think Qt can or should work around them. I would also prefer a solution that is independent of the order of the includes. Since the flurry of last years' microoptimizations in the QString and > algorithm area had measurably negative impact on me (like time I had to > spend to work around SC breakages), but no measurable positive impact > (should I have witnessed any performance gains?) I reserve the right to > be sceptical here, unless something resembling a proof of the opposite > shows up. > Micro-optimizations on such low level classes are always worth it. > Andre' > ___ > 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] QHash iteration vs std::unordered_map
Qt wasn't initially designed with STL compatibility in mind ( in the early
2000, STL support was poor on most platforms and Qt actually predates c++98
- though QMap do not, I think). - I would argue that STL compatibility is
still an issue more often than not, but it's another discussion :)
As for a change in Qt6... It would result in *a lot* of hard-to-track
source breakages, so I hope not ( one solution would be to offer a powerful
refactoring tool).
Le dim. 16 avr. 2017 à 17:06, Mark Gaiser a écrit :
> On Sun, Apr 16, 2017 at 4:44 PM, Corentin
> wrote:
> > Funny, a friend at kdab asked me about that exact question a few minutes
> > ago.
> > The reason for the difference is most certainly an historical one ( and
> > can't be changed because it would break quite a bit of code ).
> >
> > If you want the same behavior, you can create a proxy for your
> associative
> > container instance, with a custom iterator whose operator*() returns a
> std
> > pair ( or a QPair ) - quite a bit of boilterplate code.
>
> It probably does come down to historic reasons, but that would be
> strange as well.
> I doubt that the C++ committee changed what is returned by operator*()
> (correct me if i'm wrong) so i'm inclined to think that the
> std:: stuff is returning it as an std::pair for quite a
> while now.
> That again makes me wonder, why did Qt diverge from that?
>
> And... if Qt plans to change it in Qt6?
>
> >
> >
> >
> >
> > Le dim. 16 avr. 2017 à 15:57, Mark Gaiser a écrit :
> >>
> >> Hi,
> >>
> >> Take this simple example:
> >>
> >> QHash test = {
> >> {10, "aaa"},
> >> {20, "bbb"},
> >> {30, "ccc"}
> >> };
> >>
> >> for (const auto &entry: qAsConst(test)) {
> >> qDebug() << entry;
> >> }
> >>
> >> It returns:
> >> "aaa"
> >> "ccc"
> >> "bbb"
> >>
> >> and the std::unordered_map version:
> >> std::unordered_map test = {
> >> {10, "aaa"},
> >> {20, "bbb"},
> >> {30, "ccc"}
> >> };
> >>
> >> for (const auto &entry: test) {
> >> qDebug() << entry;
> >> }
> >>
> >> it returns:
> >> std::pair(30,"ccc")
> >> std::pair(10,"aaa")
> >> std::pair(20,"bbb")
> >>
> >> As you can see, the QHash iteration directly returns the value. The
> >> std::unordered_map returns a std::par with the key and value for the
> >> current iteration (in it's respective first and second members). Both
> >> approaches probably have arguments in favor and against. What i'm
> >> curious about is why there is a difference at all?
> >>
> >> I'm curious because the behavior is a bit unexpected when compared to
> >> std::unordered_map. I would have guessed QHash to follow the same
> >> logic as std::unordered_map, only with a Qt syntax. So for instance a
> >> return of QPair(...), not the value directly.
> >>
> >> Thanks,
> >> Mark
> >> ___
> >> 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 mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QHash iteration vs std::unordered_map
Funny, a friend at kdab asked me about that exact question a few minutes
ago.
The reason for the difference is most certainly an historical one ( and
can't be changed because it would break quite a bit of code ).
If you want the same behavior, you can create a proxy for your associative
container instance, with a custom iterator whose operator*() returns a std
pair ( or a QPair ) - quite a bit of boilterplate code.
Le dim. 16 avr. 2017 à 15:57, Mark Gaiser a écrit :
> Hi,
>
> Take this simple example:
>
> QHash test = {
> {10, "aaa"},
> {20, "bbb"},
> {30, "ccc"}
> };
>
> for (const auto &entry: qAsConst(test)) {
> qDebug() << entry;
> }
>
> It returns:
> "aaa"
> "ccc"
> "bbb"
>
> and the std::unordered_map version:
> std::unordered_map test = {
> {10, "aaa"},
> {20, "bbb"},
> {30, "ccc"}
> };
>
> for (const auto &entry: test) {
> qDebug() << entry;
> }
>
> it returns:
> std::pair(30,"ccc")
> std::pair(10,"aaa")
> std::pair(20,"bbb")
>
> As you can see, the QHash iteration directly returns the value. The
> std::unordered_map returns a std::par with the key and value for the
> current iteration (in it's respective first and second members). Both
> approaches probably have arguments in favor and against. What i'm
> curious about is why there is a difference at all?
>
> I'm curious because the behavior is a bit unexpected when compared to
> std::unordered_map. I would have guessed QHash to follow the same
> logic as std::unordered_map, only with a Qt syntax. So for instance a
> return of QPair(...), not the value directly.
>
> Thanks,
> Mark
> ___
> 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] RFC: Containers member functions for algorithm
Is std::algo(std::begin(container), std::end(container) ... ) troublesome
enough that it warrants a wrapper ?
I have a few concerns:
* There is a large momentum behind the range proposal, and, if it wont
be in the standard before 2-4 years, I would expect the TS to be usable
long before that. For simple iterator abstractions like sort, find, etc,
range-v3 is certainly already pretty stable from an api standpoint.
* C++17 bring parallel version of some algorithms. I haven't look what
the requirements for a containers are to be compatible with those parallel
algorithms are, but I would prefer Qt to focus on that.
* I'm afraid it won't be a popular opinion, but I wouldn't mind seing
constBegin() / constEnd() deprecated, as they are redundant
Your last example is simplified by the Library Fundamentals TS
https://rawgit.com/cplusplus/fundamentals-ts/v2/fundamentals-ts.html#container.erasure
erase_if(std::begin(myList), std::end(myList), [&](const auto &elem) {
elem.field > someValue; });
If we fast forward to say, 5 years in the future, people will be confused
as to whether use std2::sort or Qt::sort (and if Qt::sort do not relies on
concept, it won't be as trivial to use )
If there is an immediate urgent need, a solution would be to have an api
that matches as close as possible the range TS, so that the migration path
can be as simple as changing "Qt" by "std2"
Le jeu. 23 mars 2017 à 08:32, Olivier Goffart a écrit :
> Hi everyone,
>
> I have been wondering if we should enhance Qt container with member
> functions
> to help using some of the standard algorithm.
> a peace of code is better than many words. We would be able to do:
>
> myList.sort();
> //or
> myList.sort([](auto &a, auto &b){ return a.member < b.member; });
>
> if (myList.contains([&value](const auto &elem){ return elem.id == value;
> }))
>doSomething();
>
> myList.removeIf([&](const auto &elem) { elem.field > someValue; })
>
>
> And these are a tad more convenient than using the standard library
> directly.
> Compare to:
> myList.erase(std::remove_if(myList.begin(), myList.end(),
> [&](const auto &elem) { elem.field > someValue; }),
> myList.end());
>
> Of course, myList can be a QList, a QVector, or a QVarLenghtArray
>
> Here is an overview in how this could be implemented, should we want this:
> https://codereview.qt-project.org/#/c/189313/
>
>
> Anyway, before I continue working on this patch, I want to know if this is
> even something what the Qt Project wants.
>
> The reason we would want it are obvious: convenience.
>
> In the mean time, the standard is working on the so called range library.
> So
> in C++20, you could maybe just write std::sort(myList).
> But that's in the far future, and I want to be able to use it now.
> There are already convenient range libraries that makes things convenient
> available on github, but that's another dependency and the compatibility
> guarantee are not the same.
>
>
> The reason we would not want this is because this makes our containers too
> convenient. The implementation of QVector is inferior to the one of
> std::vector. (for example, it cannot contains move-only types).
> Right now, it is quite easy to replace QVector by std::vector. But adding
> nice
> feature to QVector may mean a reason to keep QVector longer in Qt6 instead
> of
> changing to standard containers.
>
> Marc already expressed his opinion on the gerrit change, pointing out that
> we
> deprecated qSort and the qt algorithm for a reason: the quality of the std
> algorithm was better than the naive implementation in Qt. However this is
> just
> a helper around the std algorithm implementation.
>
>
> Why did we not added these function already in Qt 4.0? I was not there
> yet,
> but I believe this might have been for technical reason: MSVC 6 was still
> supported until Qt 4.5, which mans no template member functions.
> Also sort needs an operator<, and non-template function might be
> instantiated
> even if not used.
>
> So with this mail I would like to know what you think. If you think this
> is a
> good idea or a terrible one.
>
>
> Once we agreed the general idea is good, we can go into the details of the
> API
> or implementation.
>
> On this WIP patch, I only took the algorithm that were most used within Qt
> and
> QtCreator. I realize that QtCreator already has helper functions:
> https://code.woboq.org/qt5/qt-creator/src/libs/utils/algorithm.h.html
> That's I think one proof that shows that this would be useful.
>
> I am wondering if findIf shoud return a pointer or an iterator.
> Returning a pointer allow things like
> if (auto *elem = myContainer.findIf([&](const auto &elem)
> { return elem.foo == bar; }))
> elem->plop = myPlop;
>
> But does not work well if you want to find-then-remove:
> auto it = std::find(myContainer.begin(), myContainer.end(),
> [&](const auto &elem) { return elem.foo == bar; });
Re: [Development] syncqt.pl in C++
JSC is pretty slow to build compared to V4. I think It's an inconvenient. And it would negate the efforts to get rid out of QtScript/JSC in Qt. It may be wishful thinking, but it would be great if QBS and Qml could use the exact same engine that would only be build once. Le mer. 8 mars 2017 à 21:10, Jake Petroules a écrit : > I'm working on the qbs bootstrapping. The requirements will be: a C++11 > compiler. End of requirements. Seriously. Not even bash, if you don't mind > typing a couple commands manually. > > Right now we depend on JSC via QtScript (not V4) but that will change at > some point. We're not entirely sure of the solution yet; newer JSC vs V8 vs > V4 or another solution. > > JSC supports ES2017 nowadays so I somewhat favor that. > > Qt could then include a tiny bootstrap script which downloads and > bootstraps qbs, then builds Qt (but the normal use case would be that you > already have qbs installed). > > -- > Jake Petroules - jake.petrou...@qt.io > The Qt Company - Silicon Valley > Qbs build tool evangelist - qbs.io > > -- > *From:* Development qt...@qt-project.org> on behalf of Sune Vuorela > *Sent:* Wednesday, March 8, 2017 11:53:17 AM > *To:* development@qt-project.org > > *Subject:* Re: [Development] syncqt.pl in C++ > On 2017-03-07, Lars Knoll wrote: > > This also makes qbs a natural choice to also use for Qt itself, and I > belie= > > ve all the people that have worked and maintained Qt's build system over > th= > > e last few years are supporting this. Of course this requires that we > can s= > > how that qbs can be used to build Qt. > > I expect this also includes "Can be bootstrapped" and "Does not require > a qbs executable obtained from elsewhere with all dependencies". And > maybe even "Can be built on platforms where v4 isn't yet > ported." > > /Sune > > > ___ > 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 mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] syncqt.pl in C++
For what it's worth, as a Qt user, QBS was, last time I checked missing some features, like non-transitive compilatuons flags, platform support and documentation. That being said, in the past few years, I wrote some makefiles, some cmake projects. I've used WAF, qmake... QBS is the best C++ build system I've used. By far. The syntax is straightforward, logical, well thought out. For the most part, it is neither too verbose nor too little. I have managed to use it to generate intermediary files. (Maybe it still need better extensibility for that) I like that it works without stupid hardcoded paths, that it can be used to great effects for non-qt projects. Yes, it is yet another wheel, but it's a well engineered one. It fits nicely in the Qt ecosystem and if you are a little familiar with QML the learning curve is almost non existant. I've made the risky decision to use it on large-ish production software and I never regretted it. Porting existing librairies to qbs is straight forward. One could wish automatic conversion/import of cmake-base project but I have no idea if it's doable. I hardly see the need to import Qt-based libs in non-qt based projects so I don't see not using the headaches-inducing cmake as an issue. Le mar. 7 mars 2017 à 22:22, Lars Knoll a écrit : > > > On 7 Mar 2017, at 21:54, Thiago Macieira > wrote: > > > > Em terça-feira, 7 de março de 2017, às 21:37:46 CET, Richard Moore > escreveu: > >>> The Qt Company has now very recently made a decision to now go and > invest > >>> the man power required to turn qbs into a product we can fully support > in > >>> the future. This decision comes from the fact that we see that build > >>> systems are a very integral part of the developer experience, and it's > one > >>> of the areas where we see that there still is a large potential for > >>> improvement. qbs is promising to bring that improvement to us and our > >>> users. > >> Pretty depressing since the discussions at the developer summit seemed > to > >> conclude the exact opposite. I wish those developers were working on > >> something more useful than a new wheel. > > The discussions there were afai remember inconclusive. But the people that > do the actual work on the build system were mostly positive towards qbs. > > > > Same here, though I have also to concede that breaking the status quo (to > > quote Jake's tweet) is sometimes a good idea. Teambuilder -- to name > another > > Trolltech project that had nothing to do with qt -- was a couple of > orders of > > magnitude better than the tools that existed at the time (distcc). > Icecream/ > > icecc came about only because TB wasn't open source, but every now and > then I > > miss TB2 features that icecc doesn't have. TB3 would have been even > better. > > > > Maybe qbs will be another such leapfrog. I can't fault TQtC for trying. > > That's what we believe. > > When we did the first version of Creator, everybody also thought we were > nuts, and that we should rather integrate with Eclipse ;-) > > Cheers, > Lars > > > > > But as I said, I agree with Richard and I can't help but feel that the > effort > > could have been turned into making cmake even better, especially > considering > > everyone[*] (including Microsoft!) is using it. > > > > [*] for some reason, the other project I work with (IoTivity) chose > Scons. > > Ugh... > > -- > > Thiago Macieira - thiago.macieira (AT) intel.com > > Software Architect - Intel Open Source Technology Center > > > > ___ > > 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 mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The missing pieces of QJSEngine
WIP patch to add QJSEngine::newQMetaObject https://codereview.qt-project.org/160759 Le sam. 28 mai 2016 à 11:42, Corentin a écrit : > Hello. > I'm once again trying to cut dependencies on Qt Script. > > QJSEngine still lacks some features to do so. > > >- The ability to call a function from JS to C++. I found a work in >that direction. https://codereview.qt-project.org/#/c/108871/2 . I am >told the api was probably abandoned over threading consideration. >- The ability to construct a QObject from JS. QtScript had >newQMetaObject for that. > > I have see a lot of people requesting the ability to call a c++ function > from JS. One classic usage I have in mind is the implementation of the PAC > standard[1] > > As for creating QObject from JS, there are tons of use cases. It is my > understanding that QBS > depends on this feature a lot. > > > I don't think that QJSEngine can really pretend to be a replacement for > QScriptEngine without those features > > > So, I have a few questions > >- Is anyone working on these features ? >- If not, is there an interest for these api ? > > > > [1] > https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Necko/Proxy_Auto-Configuration_(PAC)_file > > Regards, > Corentin > > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] The missing pieces of QJSEngine
Hello. I'm once again trying to cut dependencies on Qt Script. QJSEngine still lacks some features to do so. - The ability to call a function from JS to C++. I found a work in that direction. https://codereview.qt-project.org/#/c/108871/2 . I am told the api was probably abandoned over threading consideration. - The ability to construct a QObject from JS. QtScript had newQMetaObject for that. I have see a lot of people requesting the ability to call a c++ function from JS. One classic usage I have in mind is the implementation of the PAC standard[1] As for creating QObject from JS, there are tons of use cases. It is my understanding that QBS depends on this feature a lot. I don't think that QJSEngine can really pretend to be a replacement for QScriptEngine without those features So, I have a few questions - Is anyone working on these features ? - If not, is there an interest for these api ? [1] https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Necko/Proxy_Auto-Configuration_(PAC)_file Regards, Corentin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] What kind of airplane we want to build?
First of, it should be ensured future planes fit on the tarmac and that people now how to fly these things. Major breakage are a huge pain. Unavoidable minor breakage are painful enough, we always seem to underestimate the cost of any stack change. The plane metaphor still holds. You need to rebuild your production line, teach your staff, assert the damn thing and then you spend the next tens year working all the kinks. It's easier for Qt, but still a cost. That being said... The Qt framework, the whole KDE environment and all the app using Qt are a massive part of the C++ ecosystem. And yet there is this great divide between Qt and the rest of the C++ world. It funnily goes both ways. It would be great if the Qt community was more involved with C++, whether by participating in the standardization process, conferences and such. And maybe that would in turn help the greater C++ community have a better understanding of Qt ? A few days ago I learned KDAB was a member of the vulkan group. how cool is that ? But when I think about it, it's nothing but the logical move. Then, there is moc. I observed C++ devs outside of the Qt community will often use moc as an argument in favor of not using Qt. It seems more of an ideological argument that anything else. Whereas where I stand, moc is what make Qt great. Of course I which moc was more flexible and more easily integrated with a foreign build system but still. I don't think C++ will ever have half of the introspection Qt provides. And don't even get me started on CopperSpice. Ugh. On the other hand, qmake should probably not be recommended way to build a Qt app in the future. I cannot point to specific apis or pain points because again, I value a smooth / pragmatic evolution. Take QSharedPointer. it really do not have a reason to be beside the fact removing it will do nothing but cost thousands of hours to get rid of across the industry. Overall, the current approach of allowing idiomatic C++ apis when doable is quite good. Qt do age quite well. Maybe using the std in example/snippets more ? The Standard has great engines. Qt has comfy seats. Lets have a plane with great engines and comfy seats. 2016-01-20 20:16 GMT+01:00 charleyb123 . : > Thiago sayeth: > > >> So no, I don't think we risk becoming irrelevant against other airplane >> makers >> anytime soon. Our competitor are those transatlantic heavyweight ships >> (HTML5). >> > , > > LOL!!! > > That's actually a very good point (in addition to the fact that I really > did Laugh-Out-Loud). > > C++ is growing, and native-client apps are growing (mobile, embedded, > desktop, cloud). > > The Qt value-proposition gets you native on that platform better than > anything else, including the C++ Standard (which is merely a language > standard, and not a technology platform). > > We would likely get quite a few blank stares when walking into a bar for > programmers (do those exist?) and shouting, "C++ is easily approachable!" > However, we'd get many nods-of-agreement saying the same about Qt. > > --charley > > > ___ > 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] High-DPI 5.6 beta update
Having stumbled upon this issue very recently, here are my 2 cents.
- Svg images should be devicePixelRatio aware without having to set a
source size
- Likewise, QQuickImageProvider should know about devicePixelRation,
without having to set a source size.
- I would absolutely love an icon format, but I'm not a fan
of QTBUG-49820 proposal. As mentioned, it basically requires a full scan of
the directory. The performance implications are quite scary. I see a few
solutions:
- Use a list of files ( sources : [f1, f2, f3] ) or a list of sizes
- Use some sort of pattern string : source : "foo-{32x32,64x64}.png"
(with @x detected automatically )
- Accept .ico/icns files. The limitation is that these formats do not
distinguish size and density (I quite like the idea of these too things
being independent, but I don't think it will be used that often)
- Use some sort of icon-descriptor file. But this solution feels a
bit cumbersome
- In any case, I feel that the extension should always be specified.
( source = "path/to/foo" really does feel TOO magical )
If we are only speaking about size/density (and not other features of QIcon
like modes and states), I think extending the Image item would be more
beneficial than adding a new type.
2015-12-16 11:29 GMT+01:00 Sorvig Morten :
>
> > On 15 Dec 2015, at 20:25, rpzrpz...@gmail.com wrote:
> >
> > Instead of worrying about @2x and @3x and trying to generate artwork in
> all of the sizes, would it not be advantageous
> > to only use SVG vector format and allow the svg plugin to generate and
> scale at run-time a single svg file in the QRC file instead of having to
> pre-generate files.
> >
> > Your thoughts on projects that use ONLY SVG image resources and not
> PNG/JPEG?
>
> I think using SVG only is fine if that works for your project, and we want
> to support it.
>
> But Qt _enforcing_ SVG only? We can’t really make that decision for our
> users.
>
> Morten
>
>
>
> ___
> 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] Deprecating modules with 5.5
2015-03-18 11:00 GMT+01:00 Simon Hausmann :
> On Tuesday 17. March 2015 15.04.19 Corentin Jabot wrote:
> > Regarding QJSEngine, some things are unclear to me.
> >
> > Let's say I have a QObject-derived class. how do I create an instance of
> > that class from a script ?
> >
> > c++ : class Foo : public QObject { Q_OBJECT }; js : var foo = new
> Foo()
>
> Yes, custom constructor functions are not supported at the moment. I think
> it would be fairly easy to implement this, the meta-object system supports
> dynamic construction. If you mark a constructor as Q_INVOKABLE, then you
> can
> do
>
> QObject *instance = metaObject.newInstance(parameters)
>
> So for QObject sub-classes with invokable constructors, we could expose
> these
> as JavaScript constructor functions. Due to the requirement to place
> Q_INVOKABLE, it becomes an op-in feature.
>
That's a fair requirement.
>
> Would you be interested in trying to implement that in QJSEngine? :)
>
Sorry, I already taken too many engagements for the time being. I home
someone else do it though !
>
> > How do I call a c++ function from a js script ? That use case seems not
> > supported at all, I'm I right ?
>
> If it is a member function, then it is callable. It can be a member
> function
> of a QObject or a gadget
I was specifically speaking about free functions. Skimming my code, I use
them to define utilities like print,
as well as supporting the PAC specification.
For some use case, I guess you could do something like : var foo =
object.foo (where foo is a function), but it doesn't solve
every use case, notably, functions like print can take an arbitrary number
of arguments. QtScript solves that by registering functions
taking a "context" object, holding the parameters as well as other useful
info, like the value of this.
Will that sort of thing be supported in the future ?
>
> Simon
>
> > Those two features seems essential to me for QJSEngine to ever replace
> > QScriptEngine. They also are pretty basic.
> >
> >
> > I understand one will have to heavily modify the C++ code to port to
> > QJSEngine, but, I find the fact that the port will break the scripts...
> > worrisome
> >
> >
> > I think QJSEngine should aim to be compatible with any script that worked
> > with QScriptEngine (provided the C++ code is modified accordingly)
> >
> >
> >
> > Regards,
> > Corentin Jabot
> >
> > 2015-02-10 4:30 GMT+01:00 Thiago Macieira :
> > > On Monday 09 February 2015 22:52:34 Kevin Kofler wrote:
> > > > Guido Seifert wrote:
> > > > > Did something like that happen before?
> > > >
> > > > Yes, RHEL has never shipped QtWebKit, as far as I know because of
> > > > support
> > > > (especially with security updates) concerns. (They're likely to also
> not
> > > > ship QtWebEngine, but that will be a topic for RHEL 8. QtWebEngine
> did
> > >
> > > not
> > >
> > > > exist yet when RHEL 7 was released.) They also ship kdelibs with
> > > > Plasma::WebView patched out, kdepim without KMail (because it
> depends on
> > > > QtWebKit), Qt Assistant built against QTextBrowser, and similar such
> > >
> > > feature
> > >
> > > > removals/degradation throughout KDE.
> > > >
> > > > If all that stuff moves to QtWebEngine, we will likely end up with
> > > > Fedora
> > > > and Debian getting similarly crippled. :-(
> > >
> > > You'll probably have to provide a repository for packages supported
> less
> > > thoroughly. There are just too many requirements for Web parsing.
> > >
> > > --
> > > Thiago Macieira - thiago.macieira (AT) intel.com
> > >
> > > Software Architect - Intel Open Source Technology Center
> > >
> > > ___
> > > 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] Deprecating modules with 5.5
Regarding QJSEngine, some things are unclear to me.
Let's say I have a QObject-derived class. how do I create an instance of
that class from a script ?
c++ : class Foo : public QObject { Q_OBJECT }; js : var foo = new Foo()
How do I call a c++ function from a js script ? That use case seems not
supported at all, I'm I right ?
Those two features seems essential to me for QJSEngine to ever replace
QScriptEngine. They also are pretty basic.
I understand one will have to heavily modify the C++ code to port to
QJSEngine, but, I find the fact that the port will break the scripts...
worrisome
I think QJSEngine should aim to be compatible with any script that worked
with QScriptEngine (provided the C++ code is modified accordingly)
Regards,
Corentin Jabot
2015-02-10 4:30 GMT+01:00 Thiago Macieira :
> On Monday 09 February 2015 22:52:34 Kevin Kofler wrote:
> > Guido Seifert wrote:
> > > Did something like that happen before?
> >
> > Yes, RHEL has never shipped QtWebKit, as far as I know because of support
> > (especially with security updates) concerns. (They're likely to also not
> > ship QtWebEngine, but that will be a topic for RHEL 8. QtWebEngine did
> not
> > exist yet when RHEL 7 was released.) They also ship kdelibs with
> > Plasma::WebView patched out, kdepim without KMail (because it depends on
> > QtWebKit), Qt Assistant built against QTextBrowser, and similar such
> feature
> > removals/degradation throughout KDE.
> >
> > If all that stuff moves to QtWebEngine, we will likely end up with Fedora
> > and Debian getting similarly crippled. :-(
>
> You'll probably have to provide a repository for packages supported less
> thoroughly. There are just too many requirements for Web parsing.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
> ___
> 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] Cake and eating it too for qDebug printing to system log - https://codereview.qt-project.org/89357
Looks like there are many different uses cases and point of views, we may not reach an agreement. I agree that the default settings should be as unified as possible, but, on the other and, each platform having different capabilities, it make sense to set the default behavior on a platform-per-platform basis; there are only 2 or 3 possible choices after-all. II the documentation states explicitly what the behavior is on each platform and that the behavior is to be expected on that platform, I don't think people will get confused. I really think we need a way to override the log output in the application with an api such as Denis proposed, in addition to the existing environment variable. Having a global or per-application file may be to much, things should be kept simple. I still don't think qt creator should read the output from the journal when it can avoid it. Reading the system log + stdout, merging both in a sane way ( which means qt creator will have to time stamp the output from stdout) looks overly complicated to me. The extra information the journal provide will be lost anyway since Qt Creator's output is very basic (but, sufficient most of the time). And if the order in which each line is displayed is inaccurate, it could make the debugging much harder. The extra work of reading the journal may also create a delay in the output, which is annoying when debugging. The debugging with an other IDE should also work out-of-the-box. It's not that debugging should be handled specifically, more like debugging should not be handled differently, compared to any another application, and the burden should not be put on the IDE. That being said, if it comes to this, I have no problem with Qt creator setting QT_LOGGING_TO_CONSOLE by default. As for attaching windows applications to their parent's console automatically, that would be really neat. 2014-07-11 11:25 GMT+02:00 Robin Burchell : > On Fri, Jul 11, 2014 at 11:13 AM, Hunger Tobias > wrote: > > I see why you would want journal data in your output, but I do see a > > problems making that work for remote debugging/running. Even sailfish is > > apparently forcing output to stderr when starting applications on-device > > via Qt Creator. > > Don't let our existing solution limit you. There may be better > solutions, we were time-constrained, and now resource-constrained > (i.e. we have to pick and choose what we put effort into..) so we > haven't looked into changing this any more, as far as I know. > ___ > 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] Cake and eating it too for qDebug printing to system log - https://codereview.qt-project.org/89357
I feel the urge to give my two cents on that. At least on unix desktop platforms, I expect to get stderr output on the console. So, detecting its presence is certainly a good approach. When there is no console, I probably don't care about the logs at all. I *may* care about error/warning messages, granted that the application manages its outputs diligently, which is often not the case. One argument is that the system logging offers better rotating & search facilities, which is true, but the logs would still be cluttered by probably useless messages. There are tons of signal/slot missing throughout KDE applications, as a end user what can I possibly do about it ? I do not have a huge ~/.xsession-error file, but for those who have, I think it's a problem for distributions to solve, not Qt. On the other end, I usually have a large /home partition and relatively small root partition, so, of to evil, I would prefer my home to be cluttered. I think that's true for most Linux installations; Depending on its features or importance to the system or to the user an application is either important, in which case some log should be conserved or unimportant logs should certainly be dropped. A think an application should be assumed to be unimportant ( not to log to the system's journal) by default. The choice should be given both to the developer ( with an api) and maintainers/end user (environment variable) to modify this behavior. As for Qt Creator, my opinion is that the logs of an in-development application become irrelevant the second you press the rebuild button and so its output should always go to stderr only. For platforms which offer no or poor console support, not-in-development applications logs should arguably go to the system journal to be forever forgotten : I don't expect end-users to know how access those logs, even less to provide the developers with them when something goes wrong. Corentin 2014-07-10 1:20 GMT+02:00 Thiago Macieira : > On Wednesday 09 July 2014 14:43:36 Thiago Macieira wrote: > > Current Linux desktops with journald: > > - default stderr: captured into ~/.xsession-errors > > - system logging available: available > > - is stderr useful: yes, for launching from terminal > > [when Linux desktops start using user-mode systemd, it will be as below] > > Note: if journald is writing to volatile storage, regular users can't read > the > log. Therefore, system logging is *not* available. > > Linux distributions should not enable journald logging unless regular users > can read the output. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > 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] [Feature] Q_INFO: Annotations for classes, methods, properties and enums
>2013/9/11 Olivier Goffart :
>> Alright guys, let's try to complete the feature. As I heard from sides
>> now that you want a key-value store, I'll do it that way.
>>
>> Feature list:
>> 1. Q_INFO is a new macro (which expands to nothing):
>>#define Q_INFO(key, value)
>
> Since we have Q_CLASSINFO for classes.
> maybe we should call it Q_METHODINFO and apply it only for method.
For the sake of clarity, I think the number of keyword/terms should
be kept to a minimum.
Q_INFO(key, value) could be, for classes, a drop-in replacement for
Q_CLASSINFO(Key, value)
Q_CLASSINFO, could be somehow deprecated in a distant future and new
code advised to use Q_INFO instead.
methods would then also use Q_INFO
OR, Q_ANNOTATE, which sounds indeed better.
class, methods, enums and properties can have annotations.
That sounds simpler than having a specific mechanism for each object
type moc supports.
QMetaObject, QMetaProperty and QMetaMethods would have the following
new methods:
annotation()
annotationCount();
annotationOffset();
indexOfAnnotation()
QMetaObject would keep these methods as alias for compatibility purposes:
classInfo()
classInfoCount(),
classInfoOffset(),
indexOfClassInfo()
QMetaAnnotation could be an alias of QMetaClassInfo until 6.x
QMetaMethod::tag() could be dropped in 6.x, tags being irrelevant when having
annotations, and the #define stuff was too hacky.
> Then, for Q_PROPERTY, use a INFO as a keyword within the Q_PROPERTY syntax.
> I think it is easier to read.
> Let us compare again:
>
> Q_INFO("foo", "bar")
> Q_PROPERTY(int bar READ bar)
> Q_INFO("foo", "baz")
> Q_PROPERTY(int baz READ baz)
>
>
> Q_PROPERTY(int bar READ bar INFO "foo" = "bar")
> Q_PROPERTY(int baz READ baz INFO "foo" = "baz")
>
> You see the property name (more important) before the info. and everything is
> together.
>
It gets complicated if you want several annotations, and, it's not unified.
Again, an universal syntax for annotation is simpler than having a
syntax for class,
one for methods, and one for properties/enums
The "it's too verbose" argument makes little sense to me, I'd prefer
something a bit more verbose
but less confusing.
>
> Then for enums, we can have
>
> Q_ENUMS(MyEnum MyOtherEnum INFO "foo" = "bar")
>
annotations for enums sounds overkill.
Q_ANNOTATE("foo", "bar")
Q_ENUMS(MyEnum)
In both case, it's sounds insane to allow annotation in a Q_ENUMS /
Q_FLAGS containing
several items
Corentin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] White space / coding style patches welcome?
2013/3/12 Oswald Buddenhagen : > somebody attempted this just a few days ago, but gave up when the scope > of the undertaking became clear. i can't find the change now ... https://codereview.qt-project.org/#change,48150 I indeed gave up, or at least I was trying to think of a good solution for the tab replacement issue. Doing it by hand is at least extremely boring. It need indeed more work that a simple regexp, as we want to keep a specific alignment in some places. Also your comment was not motivating :) The first patch set that remove just the trailing spaces is okay, the others are just crap. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Evolving Qt's multithreading API
> Yes, very much like that, but updated to also support the Qt5 like way > of connecting. >> Yes, that could work. To make it truly optional though, the main >> parallel function would have to be pre-bound by the programmer (e.g. >> using https://codereview.qt-project.org/#change,45294), since the >> argument list is variable-size. >> >> QFuture runFunction(QFunction main, QFunction then = >> NullFunction); >> >> Would the extra binding step nullify the convenience of not requiring >> a signalling object? > It would not quite, but it would be a bit of a let-down. There still is > the benefit of not having to worry about race conditions. However, if we > modify the syntax a little bit, I think we can avoid the additional > binding step: > > QFuture runFunction(QFunction then, QFunction main); > QFuture runFunction(QFuntion then, QFuntion main); > QFuture runFunction(QFunction main); > I'm gonna sound crazy but... An important part of the QtConcurrent code do that implicit biding, and if we were to duplicate those calls for different usages, it's a lot of boilerplate code. Also, as said above, it limit the api in the sens that all the require parameters must be put before the actual function and its parameters. Both issues make it harder to maintain and evolve the api. So, what about let the users make the binding part themselves ? The syntax could be like runFunction(QFunction::bind(myFunction, arg1, arg2)); assuming the biding part is done using a bunch of functions, it could be simplified to runFunction(qBind(myFunction, arg1, arg2)) instead of the actual QtConcurrent::run(myFunction, arg1, arg2) It's arguably less straight forward for the user, but on the other hand, as we will need extra parameters, putting the options/flags/callback/signals before the function and its parameter could be even more confusing. we could then have: runFunction(QFunction function, Options, callback) > (Copying your use of QFunction, a quick look at the WIP you mentioned > doesn't quite reveal to me how it is supposed to work, and I probably > use it wrong. QFunction is somehow like std::function, but has support for c++98. It's actually something between std::function and std::bind ( but does not support placeholders ) >The then argument could be lambda function, a QObject* and > a slot signature, a pointer to an object and a member function pointer, > or perhaps even a plain function pointer. It would be nice if the > argument for these could be either no argument at all, or of the type T > so it can just receive the value from the method.) Agree >> It's such a shame that template classes can't be meta-objects... >> otherwise we could emit the return value directly. That would truly be >> event-driven C++! > Yeah, that is a very unfortunate artifact of the way Qt implements > signals and slots. However, it is what it is... Would that even be possible ? It sure would be nice Corentin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Evolving Qt's multithreading API
2013/2/22 André Somers > If only QFuture allowed you to connect... Unfortunately, it is not a > QObject Oh yeah, I almost forgot that bit. And somehow it looks like the core issue. I wonder why by the way: We could have something like QObject <- QFutureBase (with all requiered signals/slots) <- QFuture or is there something I'm not seeing ? Of course now its too late, but we could introduce something new, like QFutureObject ? Corentin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Evolving Qt's multithreading API
QThread keeps its current purpose of exclusively handling thread. (Or we could add another class or namespace, like QAsynchronous, reusing QtConcurrent would meant keeping c++03 compat and its suppose we will still return QFuture) About returning QThread* : what about the function return value ? That should be accessible, easily. It's one of the reason I prefer QFuture over QThread* Regards, Corentin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Evolving Qt's multithreading API
Hi. I'm the one Olivier mentioned :p
I didn't have time to pursue further the work I started, but I intend
to, someday.
The plan, as suggested by thiago was to have a QThread::run(functor)
method acting exactly like QtConcurrent::run, but using a new QThead.
A similar QThreadPool::run function would call a functor in a thread
allocated in its pool.
Those function return QFuture and do not require event loop so this
silly snippet work:
int main() {
auto future = QThread::run( []() { qDebug() << "Hello world" ; } );
future.waitForFinished();
}
My goal was to make it as simple as I could.
Anyway, I don't think we should returns a QThread*. the underlying
implementation does not mater and shouldn't mater.
What would you do with a QThread* you can't do with a QFuture ?
The Thread is started right-away, you can't really interrupt the
function until its done, etc but you could delete the thread while
it's running, so yeah, I'd rather not a return a pointer to the
thread.
I find the signature "QThread::run(function)", quite straightforward,
there is no confusion about what it does.
I don't think the fact there is also the "static void run()" method is
confusing, but maybe that's just me.
That said, there is no real reason to put these functions in QThread,
except the name.
These functions could be put elsewhere, I actually started to work
with a bunch of free functions before integrated them to QThread
The implementation use the same sort of generator that QtConcurrent.
Thiago suggested making this feature only compatible C++11, which
would make it easier to maintain. I actually envisaged to send a mail
about that particular issue.
Can c++03 really be dropped for that particular feature ?
Also, I we were to make a c++11 only feature, what would be the
benefits over std::async ?
---
About running QObject* methods on a separate thread, it can become
quite complex.
Which slot is called when the thread start ? Which signal makes the
thread quit ? Should the object be deleted afterwards ? Moved back to
its original thread ?
Considering the number of scenario, I'm not sure we would benefit from
a function - the only factorizable part is
QThread* t = new QThread();
obj->moveToThread(t);
connect(t, SIGNAL(finished()), t, SLOT(deleteLater()));
Maybe we should first agree on how QThread sould work before trying to
add yet-another-way.
Regards,
Corentin
2013/2/20 Sze Howe Koh :
> On 21 February 2013 00:02, Rutledge Shawn wrote:
>> On 20 Feb 2013, at 4:57 PM, Olivier Goffart wrote:
>>
>>> On Wednesday 20 February 2013 22:45:21 Sze Howe Koh wrote:
>>>> Hi all,
>>>>
>>>> Some time ago there was some talk about improving Qt's multithreading
>>>> API. I'm summarizing them here to stop them from fading into
>>>> obscurity, and to see if there's any interest in following them up.
>>>>
>>>> Here are the tasks mentioned:
>>>> - Replace/Rewrite QtConcurrent [2]
>>>> - Create/Find a good API to replace QtConcurrent::run() for "one-shot"
>>>> tasks
>>>> [1] - Find a third-party solution for high-level multithreading [2]
>>>> - Find more uses for QFuture, outside of QtConcurrent [3]
>>>> - Influence C++1y by creating a nice multithreading API [4]
>>>>
>>>> Some suggestions were raised:
>>>> - Put a Qt-ish wrapper around TBB [1]
>>>> - Integrate ThreadWeaver back into Qt? [2]
>>>>
>>>> Separately, someone was experimenting with ways to spawn a QObject in
>>>> a secondary thread, without first constructing it in the current
>>>> thread [5]
>>>>
>>>>
>>>> Do you think any of these avenues are worth pursuing?
>>>>
>>>> I've had a quick look at TBB vs. ThreadWeaver. The latter specializes
>>>> in task-oriented programming, while TBB is a more swiss-army-knife
>>>> toolkit, which includes container-based operations similar to
>>>> QtConcurrent. So, if we're to integrate 3rd-party option into Qt, TBB
>>>> would be more worth it (although it'd involve more work too)
>>>
>>>
>>> Someone has already been working of some feature such as:
>>> static QThread::run(QRunable*)
>>> static QThread::run(Function)
>>> static QThreadPool::run(Function)
>>> https://codereview.qt-project.org/#/t/65/
>>
>> There is also this bug about fixing the examples to show the best practice
>> instead of inheriting from QThread:
>>
>> https://bugreports.qt-project.org/browse/QTBUG-29059
>>
>> It sounds like the preferred way w
Re: [Development] Common base class for all socket types
The following changes enable the connection of qlocalsocket &
qabstractsocket by QIODevice::open(), making (a little) easier to mix
them.
https://codereview.qt-project.org/#change,39371
https://codereview.qt-project.org/#change,40592
The documentation certainly needs rework.
Hopefully, they will be integrated in 5.1.
They add setters for the parameters usually passed to
connectToSocket/Server methods.
But, I did not add properties. The reason is there is not properties
in other QIODevice subclass.
I'm not sure properties are needed, but, if we want add them, we
should also add some in QFile and other QIODevice in a consistent
manner.
I don't think much more can be done to ease the mix of different
sockets type before 6.0.
2012/11/9 d3fault :
> On 11/8/12, Corentin Jabot wrote:
>> so one could do
>> QLocalSocket socket("foo_pipe"); // or QTcpSocket("localhost", 42)
>> socket.open();
>> ...
>> socket.close();
>>
>
> I agree that the actual connectToHost() impl should live in open() so
> we can control it additionally using a QList, but I think
> we should keep connectToHost() around to keep the API intuitive. It
> will seem confusing from a _user_ perspective to call open() and then
> waitForConnected(). Same with
> disconnectFromHost/close/waitForDisconnected.
>
>
> Extra reading:
> QIODevice vs. QAbstractSocket
> A QIODevice is generally only alive/active in between the calls to
> open/close (there are exceptions)... and typically only allows one
> 'client' to IO to the device or else you'll [possibly/probably] face
> syncrhonization issues. Constrast this with QAbstractSocket, where the
> 'service' is alive before and after calls to open/close
> (connect/disconnect)... and it can/does handle multiple 'clients'
> regularly. Again, to restate: you CAN communicate with a 'server'
> (usually referred to as a daemon when used like this) through a
> process/file (iodevices), but this is generally not the case.
>
> Making QLocalSocket inherit from QAbstractSocket gives the _user_ a
> simple and intuitive way to have a server that can communicate with
> local peers (different thread (different process on same machine) and
> remote peers (LAN, WAN) using the same client/server implementation.
> The clients and servers don't need to care where their peers live. The
> current design (making you utilize QIODevice as the base class) means
> the client implementation has to know what kind of socket it is
> communicating over (glue code, see:
> http://lists.qt-project.org/pipermail/development/2012-November/007769.html
> ), you cannot simply call open() (or connectToHost()) and not worry
> about it. Separation of concerns.
>
> Current QIODevice base: "client" impl can't cleanly/easily
> connect/disconnect at will (it has to know the sub type)
> Revised QAbstractDevice base: "client" impl can't cleanly/easily
> INSTANTIATE (done once) at will, but CAN connect/disconnect (as many
> times as he wants) at will without knowing the socket type
>
>
> Pretty sure my subconscious came up with all this while I was sleeping,
> d3fault
> ___
> 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] Common base class for all socket types
I agree with d3fault/oswald.
Adding some setters/properties for the connection parameters of
QLocalSocket/QAbstractSocket and a generic "connect" method would make
the api somehow more usable.
Maybe a connectToHost() method - connectToPeer may be a little less generic.
QLocalSocket and QAbstractSocket already have getters so it would also
make the api more consistent - and similar to the QFile api
We could also ensure that the open/close methods of
QLocalSocket/QAbstractSocket actually connect/disconnect it (it is
currently the other way around)
so one could do
QLocalSocket socket("foo_pipe"); // or QTcpSocket("localhost", 42)
socket.open();
...
socket.close();
of course, QLocalSocket would still need to inherit from
QAbstractSocket for methods suchs socketType(), error(), state() and
waitForConnected/Disconnected()
2012/11/8 Thiago Macieira :
> On quinta-feira, 8 de novembro de 2012 15.48.29, shane.kea...@accenture.com
> wrote:
>> I think most of the issues can be solved by connecting the socket first,
>> then using QIODevice as your base class pointer. When you call
>> QIODevice::close() that will disconnect the socket.
>
> QNAM proves that it is possible. The put() and post() methods taking a
> QIODevice pointer operate on any class deriving from QIODevice. The
> QNetworkReply test tests QFile, QBuffer, QTcpSocket, QSslSocket, QProcess and
> QNetworkReply itself.
>
> The only thing is that it requires two implementations: the random-access one
> (QFile, QBuffer) and the sequential one (all the rest).
>
>> I'd like to see non blocking (or asynchronous) IO for files as well.
>
> Would be interesting.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
> ___
> 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] Common base class for all socket types
2012/11/7 Thiago Macieira : > On quarta-feira, 7 de novembro de 2012 00.07.41, Corentin Jabot wrote: >> The following seems like a good subset of the QAbstractSocket >> interfaces that also makes sense for QLocalSocket > > I don't want you to list functions that are common. I can do that by myself. > > I want you to explain *why* you need those. And while you're at it, let us > know whether they should be shared with QProcess and QNetworkReply too. > >> >> void abort () >> void disconnectFromHost () > > No for disconnectFromHost so long as connectToHost() isn't common. You'll have > to make do with close(). Makes sense >> SocketError error () const > > I'd have liked to replace this with a QtNetwork-wide error enum, the one in > QNetworkReply. Would be neat ! >> bool flush () >> bool isValid () const > > Explain why you need isValid and why isOpen or others don't suffice. Well if that method is useful in both QLocalSocket & QAbstractSocket, i guess it should be common. But if isOpen() do the trick, then... maybe that method is not useful in the first place, should it be deprecated. or the doc should state "see also isOpen()" ? > >> qint64 readBufferSize () const >> void setReadBufferSize ( qint64 size ) > > I completely agree with those two. They should be in QIODevice itself. Should flush() be in QIODevice too ? I think there could be other use-case for it > >> bool setSocketDescriptor ( int socketDescriptor, SocketState >> socketState = ConnectedState, OpenMode openMode = ReadWrite ) > > No on this one. I don't think that replacing an existing socket makes sense in > the common base. You usually need to know that the socket type is compatible > with the class that you're using. Therefore, this does not need to be common. Agree, It depends indeed to much of the implementation > >> int socketDescriptor () const > > Yes on this one. You said disconnect should not be common if connect is not, and, I tend to agree. Isn't that the same for socketDescriptor/setSocketDescriptor ? > >> SocketType socketType () const > > Yes and QLocalSocket needs to differentiate a local socket and an abstract > local socket. > >> SocketState state () const > > Makes sense. > >> bool waitForConnected ( int msecs = 3 ) >> bool waitForDisconnected ( int msecs = 3 ) > > No on both of those: connecting is specific on the type, therefore > waitForConnected is specific too. If disconnectFromHost isn't common either, > then waitForDisconnected shouldn't be either. > >> The SocketError & SocketState enums have already similar values in both >> class >> >> SocketType should be in TcpSocket, UdpSocket, LocalSocket - ( could >> also be NamedPipeSocket ? ) > > It should differentiate based on the implementation in the backend. There's > also the NonceTcpSocket possibility for QLocalSocket. I agree we need it. > >> The following signals could also be common (again, it's about using >> the same enums): >> void connected () >> void disconnected () >> void error ( QAbstractSocket::SocketError socketError ) >> void stateChanged ( QAbstractSocket::SocketState socketState ) >> >> I dont see how the connectTo* methods could be shared, and I don't >> think it would be a good idea to try to do so. > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > 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] Common base class for all socket types
The following seems like a good subset of the QAbstractSocket interfaces that also makes sense for QLocalSocket void abort () void disconnectFromHost () SocketError error () const bool flush () bool isValid () const qint64 readBufferSize () const void setReadBufferSize ( qint64 size ) bool setSocketDescriptor ( int socketDescriptor, SocketState socketState = ConnectedState, OpenMode openMode = ReadWrite ) int socketDescriptor () const SocketType socketType () const SocketState state () const bool waitForConnected ( int msecs = 3 ) bool waitForDisconnected ( int msecs = 3 ) The SocketError & SocketState enums have already similar values in both class SocketType should be in TcpSocket, UdpSocket, LocalSocket - ( could also be NamedPipeSocket ? ) The following signals could also be common (again, it's about using the same enums): void connected () void disconnected () void error ( QAbstractSocket::SocketError socketError ) void stateChanged ( QAbstractSocket::SocketState socketState ) I dont see how the connectTo* methods could be shared, and I don't think it would be a good idea to try to do so. Regards, Corentin. 2012/11/6 Thiago Macieira : > On terça-feira, 6 de novembro de 2012 11.49.40, Alfonso Chartier wrote: >> Someone below asked what the motivation is behind having a common abstract >> socket base class for all concrete socket types. The reason for this is it >> can significantly clean up client code. Currently if I want to handle >> different sockets generically (e.g., TCP vs. local), I have to jump through >> several hurdles: create my own wrapper class abstraction, maintain separate >> lists of objects, etc. A single, common base class would allow client code >> to use polymorphism to manage and use socket objects very easily. For >> instance, I could then have client code that defines a >> QList and is able to connect, disconnect, write, read, >> etc. from the socket without having to know the concrete class type. >> >> I hope this helps explain why it would be very useful to have a common base >> socket class. > > It's very clear why you'd want to have a common base class, but you were not > concrete on the details. I want to know what methods from QAbstractSocket > and/or QLocalSocket would you like to see in this common base class, methods > that aren't in QIODevice. > > Or, asked from another angle: why you can't use QList in your > case above? You said disconnect, read, write, all of which you can do with > QIODevice (close() is virtual, the signals are in QIODevice). > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > 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] [Qt-creator] No headers in Mac frameworks?
Hi. When building qt5 on OS X (10.7), the headers are not installed along the libraries, that seems to concern all modules. I try to build using ./build, make module-qtxxx, and make install in each module, and in each case, I got the issue. I configured that way : ./configure -release -opensource -confirm-license -fast -nomake demos -nomake examples -qt-pcre -qt-libpng -no-dbus -prefix /Users/cjabot/dev/qt5beta/release -platform macx-clang-libc++ Some specifics headers are copied though : QGenericPlugin and QGenericPluginFactory. Does I am the only one to still have that issue ? Thanks, Corentin Jabot 2012/7/10 Stephen Chu > On 7/10/12 9:28 AM, eike.zil...@nokia.com wrote: > > > > On 10 Jul 2012, at 15:19, ext Stephen Chu wrote: > > > >> On 7/10/12 5:41 AM, Stephen Kelly wrote: > >>> On Monday, July 09, 2012 18:11:30 Stephen Chu wrote: > >>>> On 7/9/12 6:03 PM, Shawn Rutledge wrote: > >>>>> On 9 July 2012 22:25, Stephen Chu wrote: > >>>>>> On 7/9/12 3:53 PM, Stephen Chu wrote: > >>>>>>> On 7/9/12 3:18 PM, Stephen Chu wrote: > >>>>>>>> I built Qt 5 from git on Mac with -developer-build option and find > >>>>>>>> there's no link to headers in the resulted frameworks. There are > >>>>>>>> only > >>>>>>>> symlinks to the libs but not headers like in Qt 4.8. > >>>>>>>> > >>>>>>>> Qt Creator editor has trouble finding the headers with this setup. > >>>>>>>> This makes finding definitions of Qt types almost impossible. > >>>>>>>> > >>>>>>>> It still compiles and builds fine. Just the editor failing to find > >>>>>>>> them.>>> > >>>>>>> OK. I removed and re-add Qt5 install to Creator and now it finds > the > >>>>>>> headers. Don't know what happened. :) > >>>>>> > >>>>>> Scrap that. It still doesn't work. I hit one of the framework which > I > >>>>>> manually added a symlink to the include folder. > >>>>>> > >>>>>> Sorry for the back and forth. I believe it's an issue in Qt 5 build > >>>>>> script.> > >>>>> I've seen an issue like that a month or so ago, but then it got > fixed. > >>>>> > >>>>>Which module is it? > >>>> > >>>> Er. All of them. > >>>> > >>> > >>> Ossi is (hopefully :)) working on generating the includes in the build > dir > >>> instead of the source dir. That might fix your issue too. > >>> > >>> thread.gmane.org/gmane.comp.lib.qt.devel/4855/focus=4926 > >> > >> Thanks. I will watch for the fix. But that issue seems to focus on > >> non-qtbase modules. What I have is none of the frameworks has any header > >> installed within them. Not even QtCore. > > > > This sounds like the same issue as in the thread "Creator doesn't like > my local Qt 5 build?" on the qt-creator mailing list, where Ossi claims > that it should be fixed in Qt Creator master? > > > > Br, > > > > Just pulled and built Creator from git. Still doesn't work without the > symlinks in the frameworks. > > ___ > 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] Proposal: Remove QML from Qt's code base (OR: Should it be a requirement that Qt Modules are interoperable?)
I do not want participate to some not constructive discussion Still, Last time I checked ( a month ago), each module that provide a QML plugin had to be build against QML. (system, multimedia kit, etc) So you can not build Qt without building QML ( and QML it self depends on several modules) I think there should be a --no-qml option to disable the build of qml plugins and broke the dependence between all the Qt modules and QML, in order to simplify and speed up the build of Qt for those of us who do not need QML. Or the plugins could have their own modules, but I guess that solution could become quite unmanageable and slow the evolution of QML Corentin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Quick2 and Directx11 backend (Angle)
So, There is the patch. * First, checkout and build ANGLE as explain here http://code.google.com/p/angleproject/wiki/DevSetup ( require directx sdk & visual studio ) * Then, edit qtbase/mkspecs/features/win32/opengl.prf and change the include and library path of angle ( or just build angle in C:\\angle) * Run configure.exe with the option "-opengl es2" * Build qtbase, it should works fine. * Build and test some examples. examples\opengl\hellowindow work just fine. The others do not : black screen, crash, etc. I'm not so sure where the problem really is, that is why I seek help How does it work ? When configured with -opengl es2, the windows QPA will use an EGL contexts and surfaces instead of opengl. the EGL calls are converted transparently by ANGLE into directx calls. Remaining work : * Try and fixes the black screen, crashes, and others issues ( like ui unresponsiveness) * Clean the code * Integrate nicely with QSurfaceFormat and find optimal options. * Ensure QtDeclarative and other modules works fine on top of angle Limitations: * I thought of including ANGLE in the Qt sources, so it can automatically be build via some configure option, but sadly ANGLE is not designed to compile with MINGW. * ANGLE provide an OpenGL ES 2.0 API, not an Opengl API. So examples, applications or features that specifically require a full opengl api are not supposed to work. I'm convinced that this kind of work is really important for QML adoption since a lot of final Windows users do not have a working opengl support - mostly because they use outdated drivers, and they can be hard to update, especially on laptops. The ultimate solution would be to use ANGLE as a fallback if the initialization of a classic opengl context fail, but that seems a really laborious task. Also, Thiago mentioned a cpu-rasterization project, I guess that would make ANGLE useless, but I'm not sure there is people working on that. And the performance of such solution wouldn't be so great. Please note that patch is very unstable and experimental. The patch is quite ugly, I put some code in place it does not belong (see QEGLPlatformContext constructor ) and added a lot of logs to figure what go wrong. angle.patch Description: Binary data ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Quick2 and Directx11 backend (Angle)
Hi. It just happen I worked on the ANGLE integration few weeks ago. ANGLE offer an OpenGL-ES 2.0 api on top of DirectX 9. I manage to get Qt compiling with ANGLE and some (one actually) examples are working. But, for the the others example, I just got a black surface or crashes. Sadly, I do not have enough experience with OpenGL(ES) and Qt internals to resolve the remaining issues. What I'm going to do is cleaning my code today and publish the patch on this thread, so other people can step on to get something working. It's seems really doable, so there should be only a little work to get something running. (As the integration mostly consist of an EGL surface for the windows QPA plugin. ) I need to clean 2012/5/20 qtnext : > Hi, > > Is there any plan or work in progress to port Quick2 to DirectX11 (I > suppose the best option is Angle project). I wants to develop > application for digital signage and it's sure that Quick2 is the best > options for that .. The only big problem is that I need hardware > acceleration to play movie on very low end computer (atom, or amd g > fusion).. It seems that for digital signage, embedded platform have > better driver support for Windows than for Linux ... and the only option > on Windows to have hardware acceleration is to use dxva that is DirectX > only : so we have magic Quick2 Opengl Only, and on the other side the > only way to have hardware decoding video is DirectX ! > I suppose the same problem will happens with Windows Metro 8 application > where it seems that Opengl is forbidden . > > ___ > 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] Speaking about Icons.
Hi. The methods setWindowIcon are not yet implemented in Qt5. That concerns QWindow, QWidget and QApplication. I guess the reason for that is that QIcon is part of QtWidget and not QtGui. QIcon seems not movable, it use a lot of QWidget styles stuffs For that reason the not-implemented QWindow::setWindowIcon ( as well as QPlatformWindow::setWindowIcon) take a QImage as parameter. So it will only use one image for all sizes the system required, and icon will certainly look ugly as they are upscale/downscale too much. For that reason I think we need something like a QWindowIcon or a QApplicationIcon to stores a different QImage for different size. It's a sub-optimal solution, because the setWindowIcon will have different signature in QtGui and QtWidget. So .. Can you think of something better ? What should be the features & api of QWindow Icon. ? Is it still time for this change in 5.0 ? or should we wait 5.1 ? I think in both case, we have to start using it privately if we want keep QWidget::setWindowIcon working. This change is mostly required for linux, since windows will use the icon provided by the RC file and Mac using the one declared by Info.plist. I worked on a small ugly change about this issue https://codereview.qt-project.org/#change,25373 , just to see what would need to be done. Sincerely, Corentin Jabot. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Dynamic QtServiceFramework backend.
I made the change here https://codereview.qt-project.org/#change,25091
As suggested, I simplified the enum like that.
enum QService::InterProcessMethod {
Native,
LocalSocket,
}
The only thinks that changes are 2 new constructors
QServiceManager(QService::Scope scope, QService::InterProcessMethod
ipcMethod, QObject *parent = 0);
QRemoteServiceRegister(QService::InterProcessMethod ipcMethod,
QObject* parent = 0);
Due to the implementation of QRemoteServiceRegister, it is not
possible to use a setter, so I use the same construct for both
classes.
It makes more sens anyway, since we can not change the value once the
service is initialized.
In order to work, the service and the client must use the same value.
The default value is "Native", ie QDBus on where it's available and
LocalSocket everywhere else.
If a wrong value is given, it fallback on local socket - but perhaps
the other way around would have made more sens
The change should be both binary and source compatible.
Also, as it my first contribution to Qt I'm not so sure about the naming rules
Corentin Jabot.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] Dynamic QtServiceFramework backend.
Hi.
I'm working with QtServiceFramework for remote services on Linux. It
use QDbus as a backend and it's great.
But I find more convenient to use the QLocalSocket implementation for
development and debugging purposes since it's easier to deploy and
test - the service process has it output redirected, etc.
Also it ensure a behavior exactly identical everywhere.
Currently the backend is determined when QtServiceFramwork is build,
so you have to hack the pro file to force the use of an implementation
or another.
My proposal is to compile each available backend (currently
QLocalSocket and QDBus) and add a method to QServiceManager to choose
which backend use at runtime.
bool QServiceManager::setInterProcessMethod(QService::InterProcessMethod);
enum QService::InterProcessMethod {
Native,
LocalSocket,
DBus
}
The default value would be Native, corresponding on DBus where DBus is
available.
The library overhead should be minimal and this will not add
additional dependency anywhere.
It will also made easier the add of potential future implementations,
like COM on windows or things like that.
If someone think this change should be made, I'm willing to work on a patch.
Like it seems a little late for 5.0, it could be add in 5.1.
What do you think ?
Corentin Jabot,
Software Developer at Ankama, France.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
