Re: [Interest] Odd behaviour when organizing .qml files into folders
On Mon, 18 Feb 2019 15:01:47 -0500 Furkan Üzümcü wrote: > That is a great advice. I didn't know RESOURCES generated a qrc file. I can't > find anything in the documentation, it just shows that you add the qrc file > to RESOURCES. I came across an alternative to generate the qrc file with a > qmake rule though. > > Can you perhaps share an example? I'd love to adopt this approach as it makes > things more maintainable. Strangely, there does not seem to be any documentation for this. The patch that added the feature has some instructions: https://codereview.qt-project.org/#/c/110708/ Christian ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Qt Location custom osm plugin and high res tiles
Hello, Is it possible to use high res tiles with a custom osm plugin? In fact I created my own local server and would like to know if I can send high res tiles, for instance if devicePixelRatio is 2 I would send 512x512 tiles, expecting Qt Location to set the tile pixel ratio to 2. Thanks Philippe. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] vs. Flutter
QtMultimedia cant be less power than GStreamer, because QtMultimedia on linux uses gstreamer as backend :) However I'd like to see there something like custom pipeline provider to Gstreamer it would be really useful for different usecases br, Vlad On Mon, Feb 18, 2019 at 9:39 PM Christian Gagneraud wrote: > On Tue, 19 Feb 2019 at 02:57, Jason H wrote: > > > > Are there any good Qt vs Google Flutter comparisons? > > I took a brief look, it looked like a declarative JS framework. Usually > the difference with between Qt and the competition is Qt abstracts there > platform libraries (i.e. Gstreamer vs avfoundation vs directshow) > > OT: This is not always a good thing. QtMultimedia is less powerful > than Gstreamer for example. So if you target embedded Linux, you might > prefer to use gstreamer directly instead of using QtMultimedia. > > Chris > > > ___ > > Interest mailing list > > Interest@qt-project.org > > https://lists.qt-project.org/listinfo/interest > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > -- Best regards, Vlad ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] vs. Flutter
On Tue, 19 Feb 2019 at 06:58 Shawn Rutledge wrote: > On Feb 18, 2019, at 17:18, René Hansen wrote: > > On Mon, 18 Feb 2019 at 16:27 Shawn Rutledge wrote: > >> >> > On 18 Feb 2019, at 15:40, René Hansen wrote: >> > >> > Achitecturally it's similar to Qt, in that they've build a custom >> renderer on top of Skia, so the whole scene is basically just OpenGL, which >> makes it really fast. >> > >> > Component wise, their UI library offers bother Cupertino and Material >> design out of the box, and from initial impressions, looks to be closer to >> the original design guidelines than Qt Quick Controls for. e.g. Material. >> >> In what way? >> > > This might just be my own personal experience, but I've run into weird and > "finicky" behaviours with Qt Quick Controls, quite a number of times and so > far, from the admittedly smaller sample size, I've not seen the same issues > with widgets in Flutter. > > > That still sounds vague. I hope you will write up bugs with concrete > examples of what’s weird. > I've kind of given up reporting bugs, unless they're really big. Again, this is just my personal experience, but I've long felt that minor bug reports are just left to rot in the tracker, so why even bother. Here's one I did report though; about TextInput: https://bugreports.qt.io/browse/QTBUG-69625. That's an example of what I mean by weird. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] vs. Flutter
19.02.2019, 15:27, "Vlad Stelmahovsky" : > QtMultimedia cant be less power than GStreamer, because QtMultimedia on linux > uses gstreamer as backend :) It's less powerful because its API provides lowest common denominator of all media backends > However I'd like to see there something like custom pipeline provider to > Gstreamer it would be really useful for different usecases > > br, > Vlad > > On Mon, Feb 18, 2019 at 9:39 PM Christian Gagneraud wrote: >> On Tue, 19 Feb 2019 at 02:57, Jason H wrote: >>> >>> Are there any good Qt vs Google Flutter comparisons? >>> I took a brief look, it looked like a declarative JS framework. Usually the >>> difference with between Qt and the competition is Qt abstracts there >>> platform libraries (i.e. Gstreamer vs avfoundation vs directshow) >> >> OT: This is not always a good thing. QtMultimedia is less powerful >> than Gstreamer for example. So if you target embedded Linux, you might >> prefer to use gstreamer directly instead of using QtMultimedia. >> >> Chris >> >>> ___ >>> Interest mailing list >>> Interest@qt-project.org >>> https://lists.qt-project.org/listinfo/interest >> ___ >> Interest mailing list >> Interest@qt-project.org >> https://lists.qt-project.org/listinfo/interest > > -- > Best regards, > Vlad > , > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest -- Regards, Konstantin ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] vs. Flutter
> 19.02.2019, 15:27, "Vlad Stelmahovsky" : > > QtMultimedia cant be less power than GStreamer, because QtMultimedia on > > linux uses gstreamer as backend :) > > It's less powerful because its API provides lowest common denominator of all > media backends Well when dealing with x-platform apps a Pareto distribution is just fine for 80% of the people 80% of the time. I've been working with multimedia on Mobile and aside from non-parity on platforms, what Qt has offered in it's API has covered 100% of my usage. (By non-parity, I mean my commercial support agreement was used to being recording parameters to AVFoundation on iOS and most recently for 5.13, audioRoles in Android (iOS needs audio roles yet too)) All of these were relatively small additions to the code base but did not need API modification. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] vs. Flutter
Many thanks for all those who replied. > I've not come across any myself, and have only built a few small things with > it a bit for now. > > Initial reactions was that it is *leagues* ahead of Qt with regards to > developer experience. You're not locked to an IDE, like with QtCreator, and > the ui live updates across device, simulators, emulators etc. when you write > changes. No need to build and .apk and wait for a build+deploy. What if there was a way to stand up a QmlEngine, host it on a phone, then start the app and then ship the QML over to it, then when a new version is ready, reset the engine and reload? This doesn't seem like anything that would be really hard to add to Qt/QtCreator? > There's no JS involved. It's Dart all the way. It doesn't even ship with a > web runtime afaik. > > Achitecturally it's similar to Qt, in that they've build a custom renderer on > top of Skia, so the whole scene is basically just OpenGL, which makes it > really fast. > > Component wise, their UI library offers bother Cupertino and Material design > out of the box, and from initial impressions, looks to be closer to the > original design guidelines than Qt Quick Controls for. e.g. Material. This doesn't sound like anything we can't have either? > I haven't tried it out myself yet, but you should be able to reach into > native world by using platform channels: > > https://flutter.io/docs/development/platform-integration/platform-channels > > It's seems like it's quite a ways worse than with Qt though, so there's at > least that. Well, Qt on Mobile is relatively abysmal. There is a much higher lack of parity than anywhere else. The recent Developer Survey gave me some hope though: 10% embedded 20% mobile. This was suggested to being some much needed love to Mobile. I will say that my commercial support seems to trigger the fixing of those issues pretty quickly. So it's not being ignored. One of my chief frustrations with the Qt Project as a whole is lack of a roadmap. Things that need attention in 2015 (yeah long overdue) * Notifications API (Desktop, Mobile) * Multimedia platform parity with each other and desktop. * Device support APIs (display brightness, volume, etc) All those things still need attention in 2019. I don't know how flutter runs on Windows or embedded hardware though. Maybe all you need is ASOP? ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QSortFilterProxyModel
Thank you Nils. My question may have have been incomplete. I am looking to filter the model through a regular expression on data contained in the header. I am not sure the method you suggested is the appropriate one. But it will certainly help. Something that would ideally look like void setFilterKeyColumn(int column), where I have a column number that represents the vertical header. Thanks, Christopher On Tue, 19 Feb 2019 at 01:40, Nils Jeisecke wrote: > Hi, > > Am 18.02.2019 um 16:49 hat Christopher Probst geschrieben: > > Does anybody know if it Is possible to use QSortFilterProxy to filter > over > > data that is in vertical the header? > you mean QSortFilterProxyModel::filterAcceptsColumn? > > Nils > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] vs. Flutter
Does something like the (recently rebranded) Felgo address any of your concerns about mobile development w/ Qt? They used to call the product "V-Play", but wanted to market it for use in regular apps (non-games) as well. I haven't used it myself, but they seem to handle QML live-reload and notifications. https://felgo.com/qml-live-code-reload https://felgo.com/doc/apps-get-started-for-ios-developers/#how-do-i-set-up-push-notifications From: Interest on behalf of Jason H Sent: Tuesday, February 19, 2019 10:25 AM To: "René Hansen" Cc: inter...@lists.qt-project.org Subject: Re: [Interest] vs. Flutter Many thanks for all those who replied. > I've not come across any myself, and have only built a few small things with > it a bit for now. > > Initial reactions was that it is *leagues* ahead of Qt with regards to > developer experience. You're not locked to an IDE, like with QtCreator, and > the ui live updates across device, simulators, emulators etc. when you write > changes. No need to build and .apk and wait for a build+deploy. What if there was a way to stand up a QmlEngine, host it on a phone, then start the app and then ship the QML over to it, then when a new version is ready, reset the engine and reload? This doesn't seem like anything that would be really hard to add to Qt/QtCreator? > There's no JS involved. It's Dart all the way. It doesn't even ship with a > web runtime afaik. > > Achitecturally it's similar to Qt, in that they've build a custom renderer on > top of Skia, so the whole scene is basically just OpenGL, which makes it > really fast. > > Component wise, their UI library offers bother Cupertino and Material design > out of the box, and from initial impressions, looks to be closer to the > original design guidelines than Qt Quick Controls for. e.g. Material. This doesn't sound like anything we can't have either? > I haven't tried it out myself yet, but you should be able to reach into > native world by using platform channels: > > https://flutter.io/docs/development/platform-integration/platform-channels > > It's seems like it's quite a ways worse than with Qt though, so there's at > least that. Well, Qt on Mobile is relatively abysmal. There is a much higher lack of parity than anywhere else. The recent Developer Survey gave me some hope though: 10% embedded 20% mobile. This was suggested to being some much needed love to Mobile. I will say that my commercial support seems to trigger the fixing of those issues pretty quickly. So it's not being ignored. One of my chief frustrations with the Qt Project as a whole is lack of a roadmap. Things that need attention in 2015 (yeah long overdue) * Notifications API (Desktop, Mobile) * Multimedia platform parity with each other and desktop. * Device support APIs (display brightness, volume, etc) All those things still need attention in 2019. I don't know how flutter runs on Windows or embedded hardware though. Maybe all you need is ASOP? ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] vs. Flutter
Yes the V-Play peeps seem to have this nut cracked as well as other mobile efforts. But here's the rub: it should just be part of Qt and I shouldn't need to go two places. If V-Play (Felgo) can make a business out of these efforts, why isn't it the same for Qt proper? I keep rolling my eyes at all the 3D stuff going into Qt (which admittedly is *very cool*, but not what I need) but what I *need* is mobile to "just work". I don't even get why the Qt stuff is done, just use 3D to generate your 2D IVI animations and UI elements. If all the effort put into 3D was put into mobile, we'd have mobile done a few times over by now. I think Qt should to acquire Felgo to be a 1-stop shop. Also, FWIW, I don't know why PySide didn't take up Riverbank's PyQt. So now we have Mobile and Python fragmentation in Qt. I've never said this before, but I think Qt's days are numbered unless they get their ecosystem in order. With Google entering the x-platform marketplace about the hopes Qt has is to somehow deliver better than Google, or hope that Flutter is fleeting. Google has been a little ADHD with projects, so... maybe? > Sent: Tuesday, February 19, 2019 at 10:50 AM > From: "Jereme Givens- Lamothe" > To: "interest@qt-project.org" > Cc: "Jason H" > Subject: Re: [Interest] vs. Flutter > > Does something like the (recently rebranded) Felgo address any of your > concerns about mobile development w/ Qt? They used to call the product > "V-Play", but wanted to market it for use in regular apps (non-games) as > well. I haven't used it myself, but they seem to handle QML live-reload and > notifications. > > https://felgo.com/qml-live-code-reload > https://felgo.com/doc/apps-get-started-for-ios-developers/#how-do-i-set-up-push-notifications > > > From: Interest on behalf of Jason H > > Sent: Tuesday, February 19, 2019 10:25 AM > To: "René Hansen" > Cc: inter...@lists.qt-project.org > Subject: Re: [Interest] vs. Flutter > > Many thanks for all those who replied. > > > I've not come across any myself, and have only built a few small things > > with it a bit for now. > > > > Initial reactions was that it is *leagues* ahead of Qt with regards to > > developer experience. You're not locked to an IDE, like with QtCreator, and > > the ui live updates across device, simulators, emulators etc. when you > > write changes. No need to build and .apk and wait for a build+deploy. > > What if there was a way to stand up a QmlEngine, host it on a phone, then > start the app and then ship the QML over to it, then when a new version is > ready, reset the engine and reload? This doesn't seem like anything that > would be really hard to add to Qt/QtCreator? > > > There's no JS involved. It's Dart all the way. It doesn't even ship with a > > web runtime afaik. > > > > Achitecturally it's similar to Qt, in that they've build a custom renderer > > on top of Skia, so the whole scene is basically just OpenGL, which makes it > > really fast. > > > > Component wise, their UI library offers bother Cupertino and Material > > design out of the box, and from initial impressions, looks to be closer to > > the original design guidelines than Qt Quick Controls for. e.g. Material. > > This doesn't sound like anything we can't have either? > > > I haven't tried it out myself yet, but you should be able to reach into > > native world by using platform channels: > > > > https://flutter.io/docs/development/platform-integration/platform-channels > > > > It's seems like it's quite a ways worse than with Qt though, so there's at > > least that. > > Well, Qt on Mobile is relatively abysmal. There is a much higher lack of > parity than anywhere else. The recent Developer Survey gave me some hope > though: 10% embedded 20% mobile. This was suggested to being some much needed > love to Mobile. I will say that my commercial support seems to trigger the > fixing of those issues pretty quickly. So it's not being ignored. One of my > chief frustrations with the Qt Project as a whole is lack of a roadmap. > > Things that need attention in 2015 (yeah long overdue) > * Notifications API (Desktop, Mobile) > * Multimedia platform parity with each other and desktop. > * Device support APIs (display brightness, volume, etc) > > All those things still need attention in 2019. > > I don't know how flutter runs on Windows or embedded hardware though. Maybe > all you need is ASOP? > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] WatchOS app
I need to develop watchos application as addition to existing ios qt application. How to configure my project for this? Do I need to build qt with watchos platform for it? I found planets-3d example, but this is not what I am looking for, because ios part is fully writed in objc. In my case I need c++ qt ios app + swift or objc watchOS app. Is it possible? ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QSortFilterProxyModel
Il 19/02/19 16:48, Christopher Probst ha scritto: Thank you Nils. My question may have have been incomplete. I am looking to filter the model through a regular expression on data contained in the header. I am not sure the method you suggested is the appropriate one. But it will certainly help. Something that would ideally look like void setFilterKeyColumn(int column), where I have a column number that represents the vertical header. I'm not 100% sure I understood what you need, but here's an idea. Make your model return the header data you want to filter upon as some "hidden" role of come column. Then put a QSFPM on top, filtering on that column and that hidden role. If you can't modify the source model, place a QIdentityProxyModel in the middle with a custom data() override. HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] vs. Flutter
> I've never said this before, but I think Qt's days are numbered unless they get their ecosystem in order. With Google entering the x-platform marketplace about the hopes Qt has is to somehow deliver better than Google, or hope that Flutter is fleeting Not sure...Qt definitely has it's strengths. Google on the other hand has the reputation that they abandon stuff they don't need anymore, or change the API in a way that all community driven libraries become useless (looking at you, tensorflow). But what I am definitely missing, is a clear Qt roadmap. What are Qt's focusing areas for 2019 and beyond? Will it be mobile, embedded, IoT, desktop, 3D, ...? Am Di., 19. Feb. 2019, 17:33 hat Jason H geschrieben: > Yes the V-Play peeps seem to have this nut cracked as well as other mobile > efforts. But here's the rub: it should just be part of Qt and I shouldn't > need to go two places. If V-Play (Felgo) can make a business out of these > efforts, why isn't it the same for Qt proper? I keep rolling my eyes at all > the 3D stuff going into Qt (which admittedly is *very cool*, but not what I > need) but what I *need* is mobile to "just work". I don't even get why the > Qt stuff is done, just use 3D to generate your 2D IVI animations and UI > elements. > > If all the effort put into 3D was put into mobile, we'd have mobile done a > few times over by now. > > I think Qt should to acquire Felgo to be a 1-stop shop. Also, FWIW, I > don't know why PySide didn't take up Riverbank's PyQt. So now we have > Mobile and Python fragmentation in Qt. > > I've never said this before, but I think Qt's days are numbered unless > they get their ecosystem in order. With Google entering the x-platform > marketplace about the hopes Qt has is to somehow deliver better than > Google, or hope that Flutter is fleeting. Google has been a little ADHD > with projects, so... maybe? > > > > > Sent: Tuesday, February 19, 2019 at 10:50 AM > > From: "Jereme Givens- Lamothe" > > To: "interest@qt-project.org" > > Cc: "Jason H" > > Subject: Re: [Interest] vs. Flutter > > > > Does something like the (recently rebranded) Felgo address any of your > concerns about mobile development w/ Qt? They used to call the product > "V-Play", but wanted to market it for use in regular apps (non-games) as > well. I haven't used it myself, but they seem to handle QML live-reload and > notifications. > > > > https://felgo.com/qml-live-code-reload > > > https://felgo.com/doc/apps-get-started-for-ios-developers/#how-do-i-set-up-push-notifications > > > > > > From: Interest on behalf of Jason H < > jh...@gmx.com> > > Sent: Tuesday, February 19, 2019 10:25 AM > > To: "René Hansen" > > Cc: inter...@lists.qt-project.org > > Subject: Re: [Interest] vs. Flutter > > > > Many thanks for all those who replied. > > > > > I've not come across any myself, and have only built a few small > things with it a bit for now. > > > > > > Initial reactions was that it is *leagues* ahead of Qt with regards to > developer experience. You're not locked to an IDE, like with QtCreator, and > the ui live updates across device, simulators, emulators etc. when you > write changes. No need to build and .apk and wait for a build+deploy. > > > > What if there was a way to stand up a QmlEngine, host it on a phone, > then start the app and then ship the QML over to it, then when a new > version is ready, reset the engine and reload? This doesn't seem like > anything that would be really hard to add to Qt/QtCreator? > > > > > There's no JS involved. It's Dart all the way. It doesn't even ship > with a web runtime afaik. > > > > > > Achitecturally it's similar to Qt, in that they've build a custom > renderer on top of Skia, so the whole scene is basically just OpenGL, which > makes it really fast. > > > > > > Component wise, their UI library offers bother Cupertino and Material > design out of the box, and from initial impressions, looks to be closer to > the original design guidelines than Qt Quick Controls for. e.g. Material. > > > > This doesn't sound like anything we can't have either? > > > > > I haven't tried it out myself yet, but you should be able to reach > into native world by using platform channels: > > > > > > > https://flutter.io/docs/development/platform-integration/platform-channels > > > > > > It's seems like it's quite a ways worse than with Qt though, so > there's at least that. > > > > Well, Qt on Mobile is relatively abysmal. There is a much higher lack of > parity than anywhere else. The recent Developer Survey gave me some hope > though: 10% embedded 20% mobile. This was suggested to being some much > needed love to Mobile. I will say that my commercial support seems to > trigger the fixing of those issues pretty quickly. So it's not being > ignored. One of my chief frustrations with the Qt Project as a whole is > lack of a roadmap. > > > > Things that need attention in 2015 (yeah long overdue) > > * Notifications API (Desktop, Mobile) > > * Multimedia platform parity with
Re: [Interest] vs. Flutter
On 2/18/2019 7:40 AM, René Hansen wrote: I've not come across any myself, and have only built a few small things with it a bit for now. Initial reactions was that it is *leagues* ahead of Qt with regards to developer experience. You're not locked to an IDE, like with QtCreator, and the ui live updates across device, simulators, emulators etc. when you write changes. No need to build and .apk and wait for a build+deploy. There's no JS involved. It's Dart all the way. It doesn't even ship with a web runtime afaik. I've been studying it for a while now, and I've decided that it will likely be my mobile development language. I love Qt to death for desktop, but I've never been able to take to it's declarative approach. I know others swear by it, but it just never fit my brain waves for some reason. I saw somebody in this thread moan about it being yet another language to learn. Putting aside the fact that a robust developer should know more than one, Dart is quite familiar to anybody who has used a modern scripting language (e.g., Python). For me personally, Flutter's "feel" just fits mobile better in my mind than Qt. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Publish Qt app to fdroid
On Thu, 14 Feb 2019 at 15:25, Bernhard B wrote: > > Hello, > > I am wondering, if anyone of you has already published a Qt app to the fdroid > store? > > I did a bit of research and it seems that the fdroid guys have recently > removed Qt from their build environment (see: > https://gitlab.com/fdroid/fdroidserver/merge_requests/440). As the version > was already pretty old (I think they used Qt 5.7.x), it wouldn't have worked > for my app anyways, but I am wondering if there is anyone that has > successfully published a Qt app to fdroid or if anyone plans to publish their > app to fdroid soon? > > Any help is highly appreciated! Well, they seem to be installing the whole Qt, no wonder they get out of space quickly :-/ ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] vs. Flutter
> I've been studying it for a while now, and I've decided that it will likely be my mobile development language. I love Qt to death for desktop, but I've never been able to take to it's declarative approach. I know others swear by it, but it just never fit my brain waves for some reason. I guess I am one of those persons, who absolutely LOVE Qt's declarative language. I like QML so much, that I even started looking for QML -> HTML/CSS translators. While I really like QML, I absolutely hate HTML and CSS (never got used to its quirks). I mean there are some attempts like qmlcore (https://github.com/pureqml/qmlcore), but I haven't tried those yet. Am Di., 19. Feb. 2019 um 18:47 Uhr schrieb Bob Hood : > On 2/18/2019 7:40 AM, René Hansen wrote: > > I've not come across any myself, and have only built a few small things > with > > it a bit for now. > > > > Initial reactions was that it is *leagues* ahead of Qt with regards to > > developer experience. You're not locked to an IDE, like with QtCreator, > and > > the ui live updates across device, simulators, emulators etc. when you > write > > changes. No need to build and .apk and wait for a build+deploy. > > > > There's no JS involved. It's Dart all the way. It doesn't even ship with > a > > web runtime afaik. > > I've been studying it for a while now, and I've decided that it will > likely be > my mobile development language. I love Qt to death for desktop, but I've > never been able to take to it's declarative approach. I know others swear > by > it, but it just never fit my brain waves for some reason. > > I saw somebody in this thread moan about it being yet another language to > learn. Putting aside the fact that a robust developer should know more > than > one, Dart is quite familiar to anybody who has used a modern scripting > language (e.g., Python). > > For me personally, Flutter's "feel" just fits mobile better in my mind > than Qt. > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Publish Qt app to fdroid
fyi: I opened a ticket for discussionin in the fdroid repository a few days ago. see https://gitlab.com/fdroid/fdroidserver/issues/632 It looks like that it's possible to run docker containers within their virtual build environment. So, I am currently working on a Dockerfile that builds my app inside a docker container and then hands the resulting apk over to the host system for signing the app. Hope that works out. Cheers, Bernhard Am Di., 19. Feb. 2019 um 18:57 Uhr schrieb Lisandro Damián Nicanor Pérez Meyer : > On Thu, 14 Feb 2019 at 15:25, Bernhard B wrote: > > > > Hello, > > > > I am wondering, if anyone of you has already published a Qt app to the > fdroid store? > > > > I did a bit of research and it seems that the fdroid guys have recently > removed Qt from their build environment (see: > https://gitlab.com/fdroid/fdroidserver/merge_requests/440). As the > version was already pretty old (I think they used Qt 5.7.x), it wouldn't > have worked for my app anyways, but I am wondering if there is anyone that > has successfully published a Qt app to fdroid or if anyone plans to publish > their app to fdroid soon? > > > > Any help is highly appreciated! > > Well, they seem to be installing the whole Qt, no wonder they get out > of space quickly :-/ > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt Location custom osm plugin and high res tiles
Hi, yes it's easy. All you have to do is setting the appropriate QGeoCameraCapabilities for the map types you have high dpi tiles for. So in your case, set the tilesize to 256x256, so that you will have more data per logical pixel. hope it's clear enough. Or just check how it's done in either osm or here or mapbox plugins On Tue, 19 Feb 2019 09:51:30 +0100 maitai wrote: > Hello, > > Is it possible to use high res tiles with a custom osm plugin? > In fact I created my own local server and would like to know if I can > send high res tiles, for instance if devicePixelRatio is 2 I would send > 512x512 tiles, expecting Qt Location to set the tile pixel ratio to 2. > > Thanks > Philippe. > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] vs. Flutter
I'm in your offtopic camp. Everything is going Declarative. I really hate that web devevlopment requires the use of HTML/CSS/JS (that's just client side) and some Framework of the Month. The _javascript_ kiddies love inventing frameworks for fame and profit rather than picking one and making it better. Fragmentation is rampant. On top of that JS is slow to change, it just becomes a runtime that your flavor-of-the-month framework compiles down to, well until WebAssembly. Rene, I don't understand why you don't declare Flutter Declarative? From the Flutter home page: Widget build(BuildContext context) { return new Scaffold ( appBar: new AppBar ( title: new Text (widget.title), ), body: new Center ( child: new Text( "Button clicked" ... ), ), } Good luck typing 'new' and 'return' a lot. At least QML manages that for you. QML is the sleekest of all the declarative languages. Sent: Tuesday, February 19, 2019 at 12:55 PM From: "Bernhard B" To: "Bob Hood" Cc: "René Hansen" , "Jason H" , inter...@lists.qt-project.org Subject: Re: [Interest] vs. Flutter > I've been studying it for a while now, and I've decided that it will likely be my mobile development language. I love Qt to death for desktop, but I've never been able to take to it's declarative approach. I know others swear by it, but it just never fit my brain waves for some reason. I guess I am one of those persons, who absolutely LOVE Qt's declarative language. I like QML so much, that I even started looking for QML -> HTML/CSS translators. While I really like QML, I absolutely hate HTML and CSS (never got used to its quirks). I mean there are some attempts like qmlcore (https://github.com/pureqml/qmlcore), but I haven't tried those yet. Am Di., 19. Feb. 2019 um 18:47 Uhr schrieb Bob Hood: On 2/18/2019 7:40 AM, René Hansen wrote: > I've not come across any myself, and have only built a few small things with > it a bit for now. > > Initial reactions was that it is *leagues* ahead of Qt with regards to > developer experience. You're not locked to an IDE, like with QtCreator, and > the ui live updates across device, simulators, emulators etc. when you write > changes. No need to build and .apk and wait for a build+deploy. > > There's no JS involved. It's Dart all the way. It doesn't even ship with a > web runtime afaik. I've been studying it for a while now, and I've decided that it will likely be my mobile development language. I love Qt to death for desktop, but I've never been able to take to it's declarative approach. I know others swear by it, but it just never fit my brain waves for some reason. I saw somebody in this thread moan about it being yet another language to learn. Putting aside the fact that a robust developer should know more than one, Dart is quite familiar to anybody who has used a modern scripting language (e.g., Python). For me personally, Flutter's "feel" just fits mobile better in my mind than Qt. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Fwd: vs. Flutter
the "new" is now removed in dart 2.0 so you example is outdated. -- Message transféré - De : Jason H Date : mar. 19 févr. 2019 à 19:25 Objet : Re: [Interest] vs. Flutter À : Bernhard B CC : I'm in your offtopic camp. Everything is going Declarative. I really hate that web devevlopment requires the use of HTML/CSS/JS (that's just client side) and some Framework of the Month. The JavaScript kiddies love inventing frameworks for fame and profit rather than picking one and making it better. Fragmentation is rampant. On top of that JS is slow to change, it just becomes a runtime that your flavor-of-the-month framework compiles down to, well until WebAssembly. Rene, I don't understand why you don't declare Flutter Declarative? From the Flutter home page: Widget build(BuildContext context) { return new Scaffold ( appBar: new AppBar ( title: new Text (widget.title), ), body: new Center ( child: new Text( "Button clicked" ... ), ), } Good luck typing 'new' and 'return' a lot. At least QML manages that for you. QML is the sleekest of all the declarative languages. *Sent:* Tuesday, February 19, 2019 at 12:55 PM *From:* "Bernhard B" *To:* "Bob Hood" *Cc:* "René Hansen" , "Jason H" , inter...@lists.qt-project.org *Subject:* Re: [Interest] vs. Flutter > I've been studying it for a while now, and I've decided that it will likely be my mobile development language. I love Qt to death for desktop, but I've never been able to take to it's declarative approach. I know others swear by it, but it just never fit my brain waves for some reason. I guess I am one of those persons, who absolutely LOVE Qt's declarative language. I like QML so much, that I even started looking for QML -> HTML/CSS translators. While I really like QML, I absolutely hate HTML and CSS (never got used to its quirks). I mean there are some attempts like qmlcore (https://github.com/pureqml/qmlcore), but I haven't tried those yet. Am Di., 19. Feb. 2019 um 18:47 Uhr schrieb Bob Hood : > On 2/18/2019 7:40 AM, René Hansen wrote: > > I've not come across any myself, and have only built a few small things > with > > it a bit for now. > > > > Initial reactions was that it is *leagues* ahead of Qt with regards to > > developer experience. You're not locked to an IDE, like with QtCreator, > and > > the ui live updates across device, simulators, emulators etc. when you > write > > changes. No need to build and .apk and wait for a build+deploy. > > > > There's no JS involved. It's Dart all the way. It doesn't even ship with > a > > web runtime afaik. > > I've been studying it for a while now, and I've decided that it will > likely be > my mobile development language. I love Qt to death for desktop, but I've > never been able to take to it's declarative approach. I know others swear > by > it, but it just never fit my brain waves for some reason. > > I saw somebody in this thread moan about it being yet another language to > learn. Putting aside the fact that a robust developer should know more > than > one, Dart is quite familiar to anybody who has used a modern scripting > language (e.g., Python). > > For me personally, Flutter's "feel" just fits mobile better in my mind > than Qt. > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt Location custom osm plugin and high res tiles
Thanks I'll give it a try Message d'origine De : Paolo Angelelli Date : 19/02/2019 7:21 PM (GMT+01:00) À : interest@qt-project.org Objet : Re: [Interest] Qt Location custom osm plugin and high res tiles Hi, yes it's easy.All you have to do is setting the appropriate QGeoCameraCapabilities for the map types you have high dpi tiles for.So in your case, set the tilesize to 256x256, so that you will have more data per logical pixel.hope it's clear enough. Or just check how it's done in either osm or here or mapbox pluginsOn Tue, 19 Feb 2019 09:51:30 +0100maitai wrote:> Hello,> > Is it possible to use high res tiles with a custom osm plugin?> In fact I created my own local server and would like to know if I can > send high res tiles, for instance if devicePixelRatio is 2 I would send > 512x512 tiles, expecting Qt Location to set the tile pixel ratio to 2.> > Thanks> Philippe.> ___> Interest mailing list> Interest@qt-project.org> https://lists.qt-project.org/listinfo/interest___Interest mailing listInterest@qt-project.orghttps://lists.qt-project.org/listinfo/interest___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Fwd: vs. Flutter
It's still on the home page: https://flutter.io/ "Fast Development" I operate on the "read at least the first page" premise. That whatever they think is most important should be found there. But losing new doesn't really change my opinion of if it's declarative or not. Thanks for the update/correction though. Sent: Tuesday, February 19, 2019 at 1:34 PM From: "Sylvain Pointeau" To: "Qt Project" Subject: [Interest] Fwd: vs. Flutter the "new" is now removed in dart 2.0 so you example is outdated. -- Message transféré - De : Jason HDate : mar. 19 févr. 2019 à 19:25 Objet : Re: [Interest] vs. Flutter À : Bernhard B CC : I'm in your offtopic camp. Everything is going Declarative. I really hate that web devevlopment requires the use of HTML/CSS/JS (that's just client side) and some Framework of the Month. The _javascript_ kiddies love inventing frameworks for fame and profit rather than picking one and making it better. Fragmentation is rampant. On top of that JS is slow to change, it just becomes a runtime that your flavor-of-the-month framework compiles down to, well until WebAssembly. Rene, I don't understand why you don't declare Flutter Declarative? From the Flutter home page: Widget build(BuildContext context) { return new Scaffold ( appBar: new AppBar ( title: new Text (widget.title), ), body: new Center ( child: new Text( "Button clicked" ... ), ), } Good luck typing 'new' and 'return' a lot. At least QML manages that for you. QML is the sleekest of all the declarative languages. Sent: Tuesday, February 19, 2019 at 12:55 PM From: "Bernhard B" To: "Bob Hood" Cc: "René Hansen" , "Jason H" , inter...@lists.qt-project.org Subject: Re: [Interest] vs. Flutter > I've been studying it for a while now, and I've decided that it will likely be my mobile development language. I love Qt to death for desktop, but I've never been able to take to it's declarative approach. I know others swear by it, but it just never fit my brain waves for some reason. I guess I am one of those persons, who absolutely LOVE Qt's declarative language. I like QML so much, that I even started looking for QML -> HTML/CSS translators. While I really like QML, I absolutely hate HTML and CSS (never got used to its quirks). I mean there are some attempts like qmlcore (https://github.com/pureqml/qmlcore), but I haven't tried those yet. Am Di., 19. Feb. 2019 um 18:47 Uhr schrieb Bob Hood : On 2/18/2019 7:40 AM, René Hansen wrote: > I've not come across any myself, and have only built a few small things with > it a bit for now. > > Initial reactions was that it is *leagues* ahead of Qt with regards to > developer experience. You're not locked to an IDE, like with QtCreator, and > the ui live updates across device, simulators, emulators etc. when you write > changes. No need to build and .apk and wait for a build+deploy. > > There's no JS involved. It's Dart all the way. It doesn't even ship with a > web runtime afaik. I've been studying it for a while now, and I've decided that it will likely be my mobile development language. I love Qt to death for desktop, but I've never been able to take to it's declarative approach. I know others swear by it, but it just never fit my brain waves for some reason. I saw somebody in this thread moan about it being yet another language to learn. Putting aside the fact that a robust developer should know more than one, Dart is quite familiar to anybody who has used a modern scripting language (e.g., Python). For me personally, Flutter's "feel" just fits mobile better in my mind than Qt. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Fwd: vs. Flutter
I cannot get it copied in the email, but the code in the section get started has no "new" but I agree with you that it is not "declarative" The positive points about flutter is that it is free, and intellij (IDEA) is so great. However, it feels too young, and limited to mobile (some are saying that the desktop is coming, but nothing concrete yet) react native (via react xp) seems to be a better alternative for now. Best regards, Sylvain Le mar. 19 févr. 2019 à 19:43, Jason H a écrit : > It's still on the home page: https://flutter.io/ "Fast Development" > I operate on the "read at least the first page" premise. That whatever > they think is most important should be found there. > > But losing new doesn't really change my opinion of if it's declarative or > not. > > Thanks for the update/correction though. > > > *Sent:* Tuesday, February 19, 2019 at 1:34 PM > *From:* "Sylvain Pointeau" > *To:* "Qt Project" > *Subject:* [Interest] Fwd: vs. Flutter > the "new" is now removed in dart 2.0 so you example is outdated. > > > -- Message transféré - > De : Jason H > Date : mar. 19 févr. 2019 à 19:25 > Objet : Re: [Interest] vs. Flutter > À : Bernhard B > CC : > > I'm in your offtopic camp. > Everything is going Declarative. I really hate that web devevlopment > requires the use of HTML/CSS/JS (that's just client side) and some > Framework of the Month. The JavaScript kiddies love inventing frameworks > for fame and profit rather than picking one and making it better. > Fragmentation is rampant. On top of that JS is slow to change, it just > becomes a runtime that your flavor-of-the-month framework compiles down to, > well until WebAssembly. > > Rene, I don't understand why you don't declare Flutter Declarative? From > the Flutter home page: > Widget build(BuildContext context) { > return new Scaffold ( > appBar: new AppBar ( title: new Text (widget.title), ), > body: new Center ( > child: new Text( "Button clicked" ... > ), > ), > } > > Good luck typing 'new' and 'return' a lot. At least QML manages that for > you. QML is the sleekest of all the declarative languages. > > > *Sent:* Tuesday, February 19, 2019 at 12:55 PM > *From:* "Bernhard B" > *To:* "Bob Hood" > *Cc:* "René Hansen" , "Jason H" , > inter...@lists.qt-project.org > > *Subject:* Re: [Interest] vs. Flutter > > I've been studying it for a while now, and I've decided that it will > likely be > my mobile development language. I love Qt to death for desktop, but I've > never been able to take to it's declarative approach. I know others swear > by > it, but it just never fit my brain waves for some reason. > > > I guess I am one of those persons, who absolutely LOVE Qt's declarative > language. > I like QML so much, that I even started looking for QML -> HTML/CSS > translators. While I really like QML, > I absolutely hate HTML and CSS (never got used to its quirks). I mean > there are some attempts like > qmlcore (https://github.com/pureqml/qmlcore), but I haven't tried those > yet. > > > Am Di., 19. Feb. 2019 um 18:47 Uhr schrieb Bob Hood : > >> On 2/18/2019 7:40 AM, René Hansen wrote: >> > I've not come across any myself, and have only built a few small things >> with >> > it a bit for now. >> > >> > Initial reactions was that it is *leagues* ahead of Qt with regards to >> > developer experience. You're not locked to an IDE, like with QtCreator, >> and >> > the ui live updates across device, simulators, emulators etc. when you >> write >> > changes. No need to build and .apk and wait for a build+deploy. >> > >> > There's no JS involved. It's Dart all the way. It doesn't even ship >> with a >> > web runtime afaik. >> >> I've been studying it for a while now, and I've decided that it will >> likely be >> my mobile development language. I love Qt to death for desktop, but I've >> never been able to take to it's declarative approach. I know others >> swear by >> it, but it just never fit my brain waves for some reason. >> >> I saw somebody in this thread moan about it being yet another language to >> learn. Putting aside the fact that a robust developer should know more >> than >> one, Dart is quite familiar to anybody who has used a modern scripting >> language (e.g., Python). >> >> For me personally, Flutter's "feel" just fits mobile better in my mind >> than Qt. >> >> ___ >> Interest mailing list >> Interest@qt-project.org >> https://lists.qt-project.org/listinfo/interest > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list > Interest@qt-project.org https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Fwd: vs. Flutter
Qt is free, too. Am February 19, 2019 7:04:03 PM UTC schrieb Sylvain Pointeau : >I cannot get it copied in the email, but the code in the section get >started has no "new" but I agree with you that it is not "declarative" > >The positive points about flutter is that it is free, and intellij >(IDEA) >is so great. >However, it feels too young, and limited to mobile (some are saying >that >the desktop is coming, but nothing concrete yet) > >react native (via react xp) seems to be a better alternative for now. > >Best regards, >Sylvain > > >Le mar. 19 févr. 2019 à 19:43, Jason H a écrit : > >> It's still on the home page: https://flutter.io/ "Fast Development" >> I operate on the "read at least the first page" premise. That >whatever >> they think is most important should be found there. >> >> But losing new doesn't really change my opinion of if it's >declarative or >> not. >> >> Thanks for the update/correction though. >> >> >> *Sent:* Tuesday, February 19, 2019 at 1:34 PM >> *From:* "Sylvain Pointeau" >> *To:* "Qt Project" >> *Subject:* [Interest] Fwd: vs. Flutter >> the "new" is now removed in dart 2.0 so you example is outdated. >> >> >> -- Message transféré - >> De : Jason H >> Date : mar. 19 févr. 2019 à 19:25 >> Objet : Re: [Interest] vs. Flutter >> À : Bernhard B >> CC : >> >> I'm in your offtopic camp. >> Everything is going Declarative. I really hate that web devevlopment >> requires the use of HTML/CSS/JS (that's just client side) and some >> Framework of the Month. The JavaScript kiddies love inventing >frameworks >> for fame and profit rather than picking one and making it better. >> Fragmentation is rampant. On top of that JS is slow to change, it >just >> becomes a runtime that your flavor-of-the-month framework compiles >down to, >> well until WebAssembly. >> >> Rene, I don't understand why you don't declare Flutter Declarative? >From >> the Flutter home page: >> Widget build(BuildContext context) { >> return new Scaffold ( >> appBar: new AppBar ( title: new Text (widget.title), ), >> body: new Center ( >> child: new Text( "Button clicked" ... >> ), >> ), >> } >> >> Good luck typing 'new' and 'return' a lot. At least QML manages that >for >> you. QML is the sleekest of all the declarative languages. >> >> >> *Sent:* Tuesday, February 19, 2019 at 12:55 PM >> *From:* "Bernhard B" >> *To:* "Bob Hood" >> *Cc:* "René Hansen" , "Jason H" , >> inter...@lists.qt-project.org >> >> *Subject:* Re: [Interest] vs. Flutter >> > I've been studying it for a while now, and I've decided that it >will >> likely be >> my mobile development language. I love Qt to death for desktop, but >I've >> never been able to take to it's declarative approach. I know others >swear >> by >> it, but it just never fit my brain waves for some reason. >> >> >> I guess I am one of those persons, who absolutely LOVE Qt's >declarative >> language. >> I like QML so much, that I even started looking for QML -> HTML/CSS >> translators. While I really like QML, >> I absolutely hate HTML and CSS (never got used to its quirks). I mean >> there are some attempts like >> qmlcore (https://github.com/pureqml/qmlcore), but I haven't tried >those >> yet. >> >> >> Am Di., 19. Feb. 2019 um 18:47 Uhr schrieb Bob Hood >: >> >>> On 2/18/2019 7:40 AM, René Hansen wrote: >>> > I've not come across any myself, and have only built a few small >things >>> with >>> > it a bit for now. >>> > >>> > Initial reactions was that it is *leagues* ahead of Qt with >regards to >>> > developer experience. You're not locked to an IDE, like with >QtCreator, >>> and >>> > the ui live updates across device, simulators, emulators etc. when >you >>> write >>> > changes. No need to build and .apk and wait for a build+deploy. >>> > >>> > There's no JS involved. It's Dart all the way. It doesn't even >ship >>> with a >>> > web runtime afaik. >>> >>> I've been studying it for a while now, and I've decided that it will >>> likely be >>> my mobile development language. I love Qt to death for desktop, but >I've >>> never been able to take to it's declarative approach. I know others >>> swear by >>> it, but it just never fit my brain waves for some reason. >>> >>> I saw somebody in this thread moan about it being yet another >language to >>> learn. Putting aside the fact that a robust developer should know >more >>> than >>> one, Dart is quite familiar to anybody who has used a modern >scripting >>> language (e.g., Python). >>> >>> For me personally, Flutter's "feel" just fits mobile better in my >mind >>> than Qt. >>> >>> ___ >>> Interest mailing list >>> Interest@qt-project.org >>> https://lists.qt-project.org/listinfo/interest >> >> ___ >> Interest mailing list >> Interest@qt-project.org >> https://lists.qt-project.org/listinfo/interest >> ___ Interest mailing list >> Interest@q
Re: [Interest] Fwd: vs. Flutter
Qt is free on desktop, but it is not free on mobile, which is a real showstopper for me and many others. Le mar. 19 févr. 2019 à 20:12, ich a écrit : > Qt is free, too. > > Am February 19, 2019 7:04:03 PM UTC schrieb Sylvain Pointeau < > sylvain.point...@gmail.com>: >> >> I cannot get it copied in the email, but the code in the section get >> started has no "new" but I agree with you that it is not "declarative" >> >> The positive points about flutter is that it is free, and intellij (IDEA) >> is so great. >> However, it feels too young, and limited to mobile (some are saying that >> the desktop is coming, but nothing concrete yet) >> >> react native (via react xp) seems to be a better alternative for now. >> >> Best regards, >> Sylvain >> >> >> Le mar. 19 févr. 2019 à 19:43, Jason H a écrit : >> >>> It's still on the home page: https://flutter.io/ "Fast Development" >>> I operate on the "read at least the first page" premise. That whatever >>> they think is most important should be found there. >>> >>> But losing new doesn't really change my opinion of if it's declarative >>> or not. >>> >>> Thanks for the update/correction though. >>> >>> >>> *Sent:* Tuesday, February 19, 2019 at 1:34 PM >>> *From:* "Sylvain Pointeau" >>> *To:* "Qt Project" >>> *Subject:* [Interest] Fwd: vs. Flutter >>> the "new" is now removed in dart 2.0 so you example is outdated. >>> >>> >>> -- Message transféré - >>> De : Jason H >>> Date : mar. 19 févr. 2019 à 19:25 >>> Objet : Re: [Interest] vs. Flutter >>> À : Bernhard B >>> CC : >>> >>> I'm in your offtopic camp. >>> Everything is going Declarative. I really hate that web devevlopment >>> requires the use of HTML/CSS/JS (that's just client side) and some >>> Framework of the Month. The JavaScript kiddies love inventing frameworks >>> for fame and profit rather than picking one and making it better. >>> Fragmentation is rampant. On top of that JS is slow to change, it just >>> becomes a runtime that your flavor-of-the-month framework compiles down to, >>> well until WebAssembly. >>> >>> Rene, I don't understand why you don't declare Flutter Declarative? From >>> the Flutter home page: >>> Widget build(BuildContext context) { >>> return new Scaffold ( >>> appBar: new AppBar ( title: new Text (widget.title), ), >>> body: new Center ( >>> child: new Text( "Button clicked" ... >>> ), >>> ), >>> } >>> >>> Good luck typing 'new' and 'return' a lot. At least QML manages that for >>> you. QML is the sleekest of all the declarative languages. >>> >>> >>> *Sent:* Tuesday, February 19, 2019 at 12:55 PM >>> *From:* "Bernhard B" >>> *To:* "Bob Hood" >>> *Cc:* "René Hansen" , "Jason H" , >>> inter...@lists.qt-project.org >>> >>> *Subject:* Re: [Interest] vs. Flutter >>> > I've been studying it for a while now, and I've decided that it will >>> likely be >>> my mobile development language. I love Qt to death for desktop, but I've >>> never been able to take to it's declarative approach. I know others >>> swear by >>> it, but it just never fit my brain waves for some reason. >>> >>> >>> I guess I am one of those persons, who absolutely LOVE Qt's declarative >>> language. >>> I like QML so much, that I even started looking for QML -> HTML/CSS >>> translators. While I really like QML, >>> I absolutely hate HTML and CSS (never got used to its quirks). I mean >>> there are some attempts like >>> qmlcore (https://github.com/pureqml/qmlcore), but I haven't tried those >>> yet. >>> >>> >>> Am Di., 19. Feb. 2019 um 18:47 Uhr schrieb Bob Hood >> >: >>> On 2/18/2019 7:40 AM, René Hansen wrote: > I've not come across any myself, and have only built a few small things with > it a bit for now. > > Initial reactions was that it is *leagues* ahead of Qt with regards to > developer experience. You're not locked to an IDE, like with QtCreator, and > the ui live updates across device, simulators, emulators etc. when you write > changes. No need to build and .apk and wait for a build+deploy. > > There's no JS involved. It's Dart all the way. It doesn't even ship with a > web runtime afaik. I've been studying it for a while now, and I've decided that it will likely be my mobile development language. I love Qt to death for desktop, but I've never been able to take to it's declarative approach. I know others swear by it, but it just never fit my brain waves for some reason. I saw somebody in this thread moan about it being yet another language to learn. Putting aside the fact that a robust developer should know more than one, Dart is quite familiar to anybody who has used a modern scripting language (e.g., Python). For me personally, Flutter's "feel" just fits mobile better in my mind than Qt. ___ Interest mailing list In
Re: [Interest] Fwd: vs. Flutter
OK, i've no idea about how to deploy to mobile devices, but what makes you think its not free? Am February 19, 2019 7:30:23 PM UTC schrieb Sylvain Pointeau : >Qt is free on desktop, but it is not free on mobile, which is a real >showstopper for me and many others. > >Le mar. 19 févr. 2019 à 20:12, ich a écrit : > >> Qt is free, too. >> >> Am February 19, 2019 7:04:03 PM UTC schrieb Sylvain Pointeau < >> sylvain.point...@gmail.com>: >>> >>> I cannot get it copied in the email, but the code in the section get >>> started has no "new" but I agree with you that it is not >"declarative" >>> >>> The positive points about flutter is that it is free, and intellij >(IDEA) >>> is so great. >>> However, it feels too young, and limited to mobile (some are saying >that >>> the desktop is coming, but nothing concrete yet) >>> >>> react native (via react xp) seems to be a better alternative for >now. >>> >>> Best regards, >>> Sylvain >>> >>> >>> Le mar. 19 févr. 2019 à 19:43, Jason H a écrit : >>> It's still on the home page: https://flutter.io/ "Fast Development" I operate on the "read at least the first page" premise. That >whatever they think is most important should be found there. But losing new doesn't really change my opinion of if it's >declarative or not. Thanks for the update/correction though. *Sent:* Tuesday, February 19, 2019 at 1:34 PM *From:* "Sylvain Pointeau" *To:* "Qt Project" *Subject:* [Interest] Fwd: vs. Flutter the "new" is now removed in dart 2.0 so you example is outdated. -- Message transféré - De : Jason H Date : mar. 19 févr. 2019 à 19:25 Objet : Re: [Interest] vs. Flutter À : Bernhard B CC : I'm in your offtopic camp. Everything is going Declarative. I really hate that web >devevlopment requires the use of HTML/CSS/JS (that's just client side) and some Framework of the Month. The JavaScript kiddies love inventing >frameworks for fame and profit rather than picking one and making it better. Fragmentation is rampant. On top of that JS is slow to change, it >just becomes a runtime that your flavor-of-the-month framework compiles >down to, well until WebAssembly. Rene, I don't understand why you don't declare Flutter Declarative? >From the Flutter home page: Widget build(BuildContext context) { return new Scaffold ( appBar: new AppBar ( title: new Text (widget.title), ), body: new Center ( child: new Text( "Button clicked" ... ), ), } Good luck typing 'new' and 'return' a lot. At least QML manages >that for you. QML is the sleekest of all the declarative languages. *Sent:* Tuesday, February 19, 2019 at 12:55 PM *From:* "Bernhard B" *To:* "Bob Hood" *Cc:* "René Hansen" , "Jason H" , inter...@lists.qt-project.org *Subject:* Re: [Interest] vs. Flutter > I've been studying it for a while now, and I've decided that it >will likely be my mobile development language. I love Qt to death for desktop, >but I've never been able to take to it's declarative approach. I know >others swear by it, but it just never fit my brain waves for some reason. I guess I am one of those persons, who absolutely LOVE Qt's >declarative language. I like QML so much, that I even started looking for QML -> HTML/CSS translators. While I really like QML, I absolutely hate HTML and CSS (never got used to its quirks). I >mean there are some attempts like qmlcore (https://github.com/pureqml/qmlcore), but I haven't tried >those yet. Am Di., 19. Feb. 2019 um 18:47 Uhr schrieb Bob Hood >: > On 2/18/2019 7:40 AM, René Hansen wrote: > > I've not come across any myself, and have only built a few small > things with > > it a bit for now. > > > > Initial reactions was that it is *leagues* ahead of Qt with >regards to > > developer experience. You're not locked to an IDE, like with > QtCreator, and > > the ui live updates across device, simulators, emulators etc. >when > you write > > changes. No need to build and .apk and wait for a build+deploy. > > > > There's no JS involved. It's Dart all the way. It doesn't even >ship > with a > > web runtime afaik. > > I've been studying it for a while now, and I've decided that it >will > likely be > my mobile development language. I love Qt to death for desktop, >but > I've > never been able to take to it's declarative approach. I know >others > swear by > it, but it just never fit my brain waves for some reason. > > I saw somebody in this thread moan about it being yet another >language > to > learn. Putting aside the fact that a robust developer shoul
Re: [Interest] vs. Flutter
https://hub.packtpub.com/is-dart-programming-dead-already/ claims Dart is not Dead, just Mostly Dead and that Flutter will save the day... I don't want to learn yet another language to learn a toolkit. I know plenty already. C/C++, JS, Python, C#, Java, Obj-C, Perl, BASH, (Visual)BASIC, Lua, Ruby, Scala. (I'm not including SQL) I previously wrote that everything compiles to JS, and so does Dart, apparently LOL. Now everything is better than Perl, but yet another language? Given a list of those 12 languages they rejected them all and and declared they needed to make another one? It's got a NIH stench about it. What I've learned is that it's better to stand on the shoulders of giants than to rewrite the universe from scratch. I dream of a say where we can code things and everyone else regardless of platform can run it. I thought this was going to be .Net CLR, or Java VM, but corporate ownership initiatives derailed them (Much like the "You will" ATT ads of the 90s - we got it, but not from ATT). But C/C++ runs all more platforms/processors. Linux has come a long way in terms of bringing all CPUs a usable software ecosystem. And this though rather obtuse is one reason to pick Qt - that it'll support any system that can run a C++ compiler. You don't technically need to use QML, you can keep going with C++. Oh, looks like they are announcing relaunch for Dart, as of a year ago: https://sdtimes.com/webdev/google-announces-reboot-programming-language-dart/ Meanwhile they develop Tensorflow in Python? Android in Java and now Kotlin Where's Go[lang] And unit tests for it all? It's just too easy to invent a language or framework, and too hard to change an existing one. Dunning Kruger effect? Every time you create a new language or framework, you divide humanity into those who can benefit from your work and those who can't. Those who are using your platform or language against those who aren't. I'm not against experimenting, but asking other to devs to use your unique stuff should be a much bigger ask. Right now we've got Kotlin infecting Android/Java for a slightly different syntax than the languages above, no material gain. Meanwhile your veteran languages are getting infected with async stuff. Qt's Mobile problems are just a backlog of ancient mobile platform concepts not yet delivered. After that backlog is resolved the maintenance is rather light, as mobile devices aren't still moving. Sure FaceID is new, but it works the same as TouchId. But these non-delivered concepts are continual pain points for its users. It's very easy for these new toolkits to wrap platform APIs, but Qt remains the only one to successfully* abstract them. * platform parity issues persist. > Sent: Tuesday, February 19, 2019 at 6:42 PM > From: "Bob Hood" > To: "René Hansen" , "Jason H" > Cc: inter...@lists.qt-project.org > Subject: Re: [Interest] vs. Flutter > > On 2/18/2019 7:40 AM, René Hansen wrote: > > I've not come across any myself, and have only built a few small things > > with > > it a bit for now. > > > > Initial reactions was that it is *leagues* ahead of Qt with regards to > > developer experience. You're not locked to an IDE, like with QtCreator, and > > the ui live updates across device, simulators, emulators etc. when you > > write > > changes. No need to build and .apk and wait for a build+deploy. > > > > There's no JS involved. It's Dart all the way. It doesn't even ship with a > > web runtime afaik. > > I've been studying it for a while now, and I've decided that it will likely > be > my mobile development language. I love Qt to death for desktop, but I've > never been able to take to it's declarative approach. I know others swear by > it, but it just never fit my brain waves for some reason. > > I saw somebody in this thread moan about it being yet another language to > learn. Putting aside the fact that a robust developer should know more than > one, Dart is quite familiar to anybody who has used a modern scripting > language (e.g., Python). > > For me personally, Flutter's "feel" just fits mobile better in my mind than > Qt. > > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Fwd: vs. Flutter
Qt creator does it for you, just add whatever APIs you need (Android SDK, NDK) or xCode and select the plaftorm above the big Run button in QtCreator. Launch the Maintence tool, download Qt for the target platform AFAIK, it is free on Mobile. However... as I've repeatedly stated that I continually find bugs/parity issues between mobile platforms. Having a support contract really helps in this regard. The diffs are not large, but if you're new to a platform, you might not find it as friendly as you'd like. I routinely hack Obj-C and Java to make things work in Qt that should "just work". But getting clued into these foreign platforms can be frustrating. You've got to know a little "too much" about the target platform - For iOS it's your Application Delegate and Obj-C, on Android it's the Activity and JNI. But most simple apps are as easy as just changing the build target. When it doesn't work, I file a bug. Example: You can take pictures (Camera.capture()) on iOS without a VideoOutput, but you can't do that in Android so you create an invisible one as a work-around. https://bugreports.qt.io/browse/QTBUG-73237 Or that audioRoles are not implemented on the platform. https://bugreports.qt.io/browse/QTBUG-73316 (iOS) https://bugreports.qt.io/browse/QTBUG-73119 (FIXED, Android) (iOS has a global autio context, so this is less of an issue there, but Android does not, so it's a bigger issue) but the whole diff for Android was 445 lines which is not much. (and the bulk of those lines is enumerating the various audioRole mapping to/from Android) Sometimes it's just not possible (no iOS API for AmbientLight sensor) As long as you're not digging too much into the platform Qt *will* *just work*. :-) Sent: Tuesday, February 19, 2019 at 8:39 PM From: "ich" To: No recipient address Cc: interest@qt-project.org Subject: Re: [Interest] Fwd: vs. Flutter OK, i've no idea about how to deploy to mobile devices, but what makes you think its not free? Am February 19, 2019 7:30:23 PM UTC schrieb Sylvain Pointeau : Qt is free on desktop, but it is not free on mobile, which is a real showstopper for me and many others. Le mar. 19 févr. 2019 à 20:12, icha écrit : Qt is free, too. Am February 19, 2019 7:04:03 PM UTC schrieb Sylvain Pointeau : I cannot get it copied in the email, but the code in the section get started has no "new" but I agree with you that it is not "declarative" The positive points about flutter is that it is free, and intellij (IDEA) is so great. However, it feels too young, and limited to mobile (some are saying that the desktop is coming, but nothing concrete yet) react native (via react xp) seems to be a better alternative for now. Best regards, Sylvain Le mar. 19 févr. 2019 à 19:43, Jason H a écrit : It's still on the home page: https://flutter.io/ "Fast Development" I operate on the "read at least the first page" premise. That whatever they think is most important should be found there. But losing new doesn't really change my opinion of if it's declarative or not. Thanks for the update/correction though. Sent: Tuesday, February 19, 2019 at 1:34 PM From: "Sylvain Pointeau" To: "Qt Project" Subject: [Interest] Fwd: vs. Flutter the "new" is now removed in dart 2.0 so you example is outdated. -- Message transféré - De : Jason H Date : mar. 19 févr. 2019 à 19:25 Objet : Re: [Interest] vs. Flutter À : Bernhard B CC : I'm in your offtopic camp. Everything is going Declarative. I really hate that web devevlopment requires the use of HTML/CSS/JS (that's just client side) and some Framework of the Month. The _javascript_ kiddies love inventing frameworks for fame and profit rather than picking one and making it better. Fragmentation is rampant. On top of that JS is slow to change, it just becomes a runtime that your flavor-of-the-month framework compiles down to, well until WebAssembly. Rene, I don't understand why you don't declare Flutter Declarative? From the Flutter home page: Widget build(BuildContext context) { return new Scaffold ( appBar: new AppBar ( title: new Text (widget.title), ), body: new Center ( child: new Text( "Button clicked" ... ), ), } Good luck typing 'new' and 'return' a lot. At least QML manages that for you. QML is the sleekest of all the declarative languages. Sent: Tuesday, February 19, 2019 at 12:55 PM From: "Bernhard B" To: "Bob Hood" Cc: "René Hansen" , "Jason H" , inter...@lists.qt-project.org Subject: Re: [Interest] vs. Flutter > I've been studying it for a while now, and I've decided that it will likely be my mobile development
Re: [Interest] vs. Flutter
On 02/19/19 20:47, Jason H wrote: What I've learned is that it's better to stand on the shoulders of giants than to rewrite the universe from scratch. I dream of a say where we can code things and everyone else regardless of platform can run it. I thought this was going to be .Net CLR, or Java VM, but corporate ownership initiatives derailed them (Much like the "You will" ATT ads of the 90s - we got it, but not from ATT). But C/C++ runs all more platforms/processors. Linux has come a long way in terms of bringing all CPUs a usable software ecosystem. And this though rather obtuse is one reason to pick Qt - that it'll support any system that can run a C++ compiler. You don't technically need to use QML, you can keep going with C++. Once upon a time a mother of two curious boys called me, asking me to teach them programming. They have no clue what language to start with, so I suggested C as a base, to later learn Python, C++, Java (or C#). Then some "smart" student told one of the kids "JavaScript is da future of da Internetz". I stopped teaching them after it was suggested to stop the C course and swap it for a JavaScript course. C/C++ will be relevant in the future. All other languages will come and go (no pun intended). Whether Qt will be relevant in the future lies in the hands of its developers. Don't ruin it. Christoph Feck ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] vs. Flutter
Hi, totally agree C/C++ will outlive many of these new languages. It's also most likely Javascript will wane off sooner rather than later due to WebAssembly steadily improving. Been working/programming for 43 years now, while I fondly remember Pascal on CP/M from my youth (before C++ was invented), once I switched to C++ in the early 90's (Visual C++/MFC), C++ always felt as my "home". Also you could say that good and stable ecosystems for a language takes decades to arrive, at least one generation of programmers has to come and go I think. So the peak of C++ will be in the future :-) Rgrds Henry On 2019-02-19 21:13, Christoph Feck wrote: On 02/19/19 20:47, Jason H wrote: What I've learned is that it's better to stand on the shoulders of giants than to rewrite the universe from scratch. I dream of a say where we can code things and everyone else regardless of platform can run it. I thought this was going to be .Net CLR, or Java VM, but corporate ownership initiatives derailed them (Much like the "You will" ATT ads of the 90s - we got it, but not from ATT). But C/C++ runs all more platforms/processors. Linux has come a long way in terms of bringing all CPUs a usable software ecosystem. And this though rather obtuse is one reason to pick Qt - that it'll support any system that can run a C++ compiler. You don't technically need to use QML, you can keep going with C++. Once upon a time a mother of two curious boys called me, asking me to teach them programming. They have no clue what language to start with, so I suggested C as a base, to later learn Python, C++, Java (or C#). Then some "smart" student told one of the kids "JavaScript is da future of da Internetz". I stopped teaching them after it was suggested to stop the C course and swap it for a JavaScript course. C/C++ will be relevant in the future. All other languages will come and go (no pun intended). Whether Qt will be relevant in the future lies in the hands of its developers. Don't ruin it. Christoph Feck ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] vs. Flutter
I am personally not convinced yet about having a javascript VM. It seems to be a bottleneck. However I see the advantages it brings, but was it really necessary? Le mar. 19 févr. 2019 à 21:15, Christoph Feck a écrit : > On 02/19/19 20:47, Jason H wrote: > > What I've learned is that it's better to stand on the shoulders of > giants than to rewrite the universe from scratch. I dream of a say where we > can code things and everyone else regardless of platform can run it. I > thought this was going to be .Net CLR, or Java VM, but corporate ownership > initiatives derailed them (Much like the "You will" ATT ads of the 90s - we > got it, but not from ATT). But C/C++ runs all more platforms/processors. > Linux has come a long way in terms of bringing all CPUs a usable software > ecosystem. And this though rather obtuse is one reason to pick Qt - that > it'll support any system that can run a C++ compiler. You don't technically > need to use QML, you can keep going with C++. > > Once upon a time a mother of two curious boys called me, asking me to > teach them programming. They have no clue what language to start with, > so I suggested C as a base, to later learn Python, C++, Java (or C#). > Then some "smart" student told one of the kids "JavaScript is da future > of da Internetz". I stopped teaching them after it was suggested to > stop the C course and swap it for a JavaScript course. > > C/C++ will be relevant in the future. All other languages will come and > go (no pun intended). > > Whether Qt will be relevant in the future lies in the hands of its > developers. Don't ruin it. > > Christoph Feck > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] vs. Flutter
My two cents. The main topic is: a new language really has to give an answer to a real need. In my humble opinion when we talk about programming language, we cannot think to push artificial needs. The community of developers is not a commumitiy of fashion guys. They are professionals working to make money and innovate the market. The tools are not ideological matter but real tools to work, produce and make value. So, chancing for changing, only applying the logic "newer is better" is not always a winning choice. Best regards. Fabio Il giorno mar 19 feb 2019 21:58 Henry Skoglund ha scritto: > Hi, totally agree C/C++ will outlive many of these new languages. > It's also most likely Javascript will wane off sooner rather than later > due to WebAssembly steadily improving. > > Been working/programming for 43 years now, while I fondly remember > Pascal on CP/M from my youth (before C++ was invented), once I switched > to C++ in the early 90's (Visual C++/MFC), C++ always felt as my "home". > > Also you could say that good and stable ecosystems for a language takes > decades to arrive, at least one generation of programmers has to come > and go I think. So the peak of C++ will be in the future :-) > > Rgrds Henry > > On 2019-02-19 21:13, Christoph Feck wrote: > > On 02/19/19 20:47, Jason H wrote: > >> What I've learned is that it's better to stand on the shoulders of > >> giants than to rewrite the universe from scratch. I dream of a say > >> where we can code things and everyone else regardless of platform can > >> run it. I thought this was going to be .Net CLR, or Java VM, but > >> corporate ownership initiatives derailed them (Much like the "You > >> will" ATT ads of the 90s - we got it, but not from ATT). But C/C++ > >> runs all more platforms/processors. Linux has come a long way in terms > >> of bringing all CPUs a usable software ecosystem. And this though > >> rather obtuse is one reason to pick Qt - that it'll support any system > >> that can run a C++ compiler. You don't technically need to use QML, > >> you can keep going with C++. > > > > Once upon a time a mother of two curious boys called me, asking me to > > teach them programming. They have no clue what language to start with, > > so I suggested C as a base, to later learn Python, C++, Java (or C#). > > Then some "smart" student told one of the kids "JavaScript is da future > > of da Internetz". I stopped teaching them after it was suggested to > > stop the C course and swap it for a JavaScript course. > > > > C/C++ will be relevant in the future. All other languages will come and > > go (no pun intended). > > > > Whether Qt will be relevant in the future lies in the hands of its > > developers. Don't ruin it. > > > > Christoph Feck > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] vs. Flutter
I probably would have gone with Python, and avoid pointers, as many languages to their best to obfuscate them. But your C was not a bad decision. It is lingua franca. :-) Just remind them that JS was invented in 10 days back in 1992, and standardized by a committee that had no business standardizing it. That said, with everything targeting JS, it's not a bad decision either. I'm relatively [adjective] about the new C++ versions. On one hand C++ looks strange. The code to map/filter/transform looks nothing like I'd expect (transform): Actual: std::vector x = {1, 2, 3, 4, 5}; std::vector y; std::transform(x.begin(), x.end(), std::back_inserter(y), [](int elem){ return elem * elem; }); Expected: auto y = std::transform(std::vector {1, 2, 3, 4, 5}, [int elem] { return elem*elem }); But the new initializer syntax is a joy. SFINAE, etc. It creates pretty unreadable code. It takes me several minutes to parse a line of modern C++, which violates several software development principles in that it should be easy to understand, optimized for reading, OTHER Developers, DRY, DR's 10 times harder statement. I've learned that to grok C++, you must first realize that you're not writing a program that does something, instead you're telling the compiler how to build the program. "Doing what you want" is just a "side effect". I don't know how long C++ can exist with that mentality. The compiler should figure out what I mean. Const should be automatically applied where it can based on code paths. It's something I do, it's easy to determine, and having it auto applied would be just fine. Or maybe have a linter tell you/upgrade it to const. Qt is attractive because I "code less and create more". I rely on Qt to translate the C++ committee's/stdlib output into something usable by developers, not language nerds. (Reminder there's more languages than C++, I've got to learn Dart now, apparently) But the new initializer syntax is a joy, at least. > Sent: Tuesday, February 19, 2019 at 9:13 PM > From: "Christoph Feck" > To: inter...@lists.qt-project.org > Subject: Re: [Interest] vs. Flutter > > On 02/19/19 20:47, Jason H wrote: > > What I've learned is that it's better to stand on the shoulders of giants > > than to rewrite the universe from scratch. I dream of a say where we can > > code things and everyone else regardless of platform can run it. I thought > > this was going to be .Net CLR, or Java VM, but corporate ownership > > initiatives derailed them (Much like the "You will" ATT ads of the 90s - we > > got it, but not from ATT). But C/C++ runs all more platforms/processors. > > Linux has come a long way in terms of bringing all CPUs a usable software > > ecosystem. And this though rather obtuse is one reason to pick Qt - that > > it'll support any system that can run a C++ compiler. You don't technically > > need to use QML, you can keep going with C++. > > Once upon a time a mother of two curious boys called me, asking me to > teach them programming. They have no clue what language to start with, > so I suggested C as a base, to later learn Python, C++, Java (or C#). > Then some "smart" student told one of the kids "JavaScript is da future > of da Internetz". I stopped teaching them after it was suggested to > stop the C course and swap it for a JavaScript course. > > C/C++ will be relevant in the future. All other languages will come and > go (no pun intended). > > Whether Qt will be relevant in the future lies in the hands of its > developers. Don't ruin it. > > Christoph Feck > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] vs. Flutter
In 1992 it really, really was. The real issue nowadays is they only have one event loop forcing generators/async code. Though WebWorkers are a thing. Sent: Tuesday, February 19, 2019 at 10:03 PM From: "Sylvain Pointeau" To: "Christoph Feck" Cc: inter...@lists.qt-project.org Subject: Re: [Interest] vs. Flutter I am personally not convinced yet about having a _javascript_ VM. It seems to be a bottleneck. However I see the advantages it brings, but was it really necessary? Le mar. 19 févr. 2019 à 21:15, Christoph Fecka écrit : On 02/19/19 20:47, Jason H wrote: > What I've learned is that it's better to stand on the shoulders of giants than to rewrite the universe from scratch. I dream of a say where we can code things and everyone else regardless of platform can run it. I thought this was going to be .Net CLR, or Java VM, but corporate ownership initiatives derailed them (Much like the "You will" ATT ads of the 90s - we got it, but not from ATT). But C/C++ runs all more platforms/processors. Linux has come a long way in terms of bringing all CPUs a usable software ecosystem. And this though rather obtuse is one reason to pick Qt - that it'll support any system that can run a C++ compiler. You don't technically need to use QML, you can keep going with C++. Once upon a time a mother of two curious boys called me, asking me to teach them programming. They have no clue what language to start with, so I suggested C as a base, to later learn Python, C++, Java (or C#). Then some "smart" student told one of the kids "_javascript_ is da future of da Internetz". I stopped teaching them after it was suggested to stop the C course and swap it for a _javascript_ course. C/C++ will be relevant in the future. All other languages will come and go (no pun intended). Whether Qt will be relevant in the future lies in the hands of its developers. Don't ruin it. Christoph Feck ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] vs. Flutter
So I think that after all this chatter we have one really solid concrete finding: Findings #1: Qt is based on proven, stable technologies, whereas Flutter is based on Dart, a nacent technology with a very small past and a non-transparent future.* Furthermore, Dart does not seem to be any more adept at the needs of Flutter than any other language. I don't know if the "kids these days" will really be into that, as they are very into learning the "latest and greatest" (aka fads). * "non-transparent future" - while no one knows the future at least C++ has the 3 year release cycle. Qt's future is murky though without a dedicated roadmap. Sent: Tuesday, February 19, 2019 at 10:14 PM From: "Fabio Giovagnini" To: fro...@tungware.se Cc: Qt-interest Subject: Re: [Interest] vs. Flutter My two cents. The main topic is: a new language really has to give an answer to a real need. In my humble opinion when we talk about programming language, we cannot think to push artificial needs. The community of developers is not a commumitiy of fashion guys. They are professionals working to make money and innovate the market. The tools are not ideological matter but real tools to work, produce and make value. So, chancing for changing, only applying the logic "newer is better" is not always a winning choice. Best regards. Fabio Il giorno mar 19 feb 2019 21:58 Henry Skoglundha scritto: Hi, totally agree C/C++ will outlive many of these new languages. It's also most likely _javascript_ will wane off sooner rather than later due to WebAssembly steadily improving. Been working/programming for 43 years now, while I fondly remember Pascal on CP/M from my youth (before C++ was invented), once I switched to C++ in the early 90's (Visual C++/MFC), C++ always felt as my "home". Also you could say that good and stable ecosystems for a language takes decades to arrive, at least one generation of programmers has to come and go I think. So the peak of C++ will be in the future :-) Rgrds Henry On 2019-02-19 21:13, Christoph Feck wrote: > On 02/19/19 20:47, Jason H wrote: >> What I've learned is that it's better to stand on the shoulders of >> giants than to rewrite the universe from scratch. I dream of a say >> where we can code things and everyone else regardless of platform can >> run it. I thought this was going to be .Net CLR, or Java VM, but >> corporate ownership initiatives derailed them (Much like the "You >> will" ATT ads of the 90s - we got it, but not from ATT). But C/C++ >> runs all more platforms/processors. Linux has come a long way in terms >> of bringing all CPUs a usable software ecosystem. And this though >> rather obtuse is one reason to pick Qt - that it'll support any system >> that can run a C++ compiler. You don't technically need to use QML, >> you can keep going with C++. > > Once upon a time a mother of two curious boys called me, asking me to > teach them programming. They have no clue what language to start with, > so I suggested C as a base, to later learn Python, C++, Java (or C#). > Then some "smart" student told one of the kids "_javascript_ is da future > of da Internetz". I stopped teaching them after it was suggested to > stop the C course and swap it for a _javascript_ course. > > C/C++ will be relevant in the future. All other languages will come and > go (no pun intended). > > Whether Qt will be relevant in the future lies in the hands of its > developers. Don't ruin it. > > Christoph Feck ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] vs. Flutter
Was just reading the blog and it mentions live reloading: https://blog.qt.io/blog/2019/02/18/scaling-large-ui-development-projects-managing-complexities-reference-ui-neptune-3/ This Neptune3 thing, is that something we can use on the phones? Sent: Monday, February 18, 2019 at 3:40 PM From: "René Hansen" To: "Jason H" Cc: inter...@lists.qt-project.org Subject: Re: [Interest] vs. Flutter I've not come across any myself, and have only built a few small things with it a bit for now. Initial reactions was that it is *leagues* ahead of Qt with regards to developer experience. You're not locked to an IDE, like with QtCreator, and the ui live updates across device, simulators, emulators etc. when you write changes. No need to build and .apk and wait for a build+deploy. There's no JS involved. It's Dart all the way. It doesn't even ship with a web runtime afaik. Achitecturally it's similar to Qt, in that they've build a custom renderer on top of Skia, so the whole scene is basically just OpenGL, which makes it really fast. Component wise, their UI library offers bother Cupertino and Material design out of the box, and from initial impressions, looks to be closer to the original design guidelines than Qt Quick Controls for. e.g. Material. I haven't tried it out myself yet, but you should be able to reach into native world by using platform channels: https://flutter.io/docs/development/platform-integration/platform-channels It's seems like it's quite a ways worse than with Qt though, so there's at least that. /René On Mon, 18 Feb 2019 at 14:58 Jason Hwrote: Are there any good Qt vs Google Flutter comparisons? I took a brief look, it looked like a declarative JS framework. Usually the difference with between Qt and the competition is Qt abstracts there platform libraries (i.e. Gstreamer vs avfoundation vs directshow) ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] vs. Flutter
On Wed, 20 Feb 2019 at 00:33, Jason H wrote: > Also, FWIW, I don't know why PySide didn't take up Riverbank's PyQt. So now > we have Mobile and Python fragmentation in Qt. They did try, but couldn't reach an agreement with Riverbank: https://wiki.qt.io/PySide_FAQ (see "What About PyQt?") PyQt is Commercial/GPL only. Nokia (the then-owners of Qt) wanted LGPL. Regards, Sze-Howe ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] vs. Flutter
On 2019-02-19 3:22 p.m., Jason H wrote: Was just reading the blog and it mentions live reloading: https://blog.qt.io/blog/2019/02/18/scaling-large-ui-development-projects-managing-complexities-reference-ui-neptune-3/ This Neptune3 thing, is that something we can use on the phones? I've been following the discussion and it looks like a lot of features of flutter, such as the live reloading, push notification, etc, already exists in felgo (use to be vplay). I used vplay for awhile, but it got too expensive so I just redid what I was using from their work myself. Only took a couple of weeks. My main point is that Qt can do all of this stuff because the felgo people already did. It just has to be done by Qt and put into the core. -- Lorne Sturtevant Sum Ergo Cogito ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] vs. Flutter
I did try a bit V-Play, but I did not like the fact I was stuck at a particular Qt version (it was 5.6 when 5.10 was out, last time I checked). Does the new Felgo allow to be used on other versoin and with up to date Qt Creator? that was a real bummer to be stuck with old version. The project seem to be fine aside from that problems. The price is a hard pill to swallow, with Qt 3D I guess the V-Play was less future proof I guess. From: Interest On Behalf Of Lorne Sturtevant Sent: February 19, 2019 7:04 PM To: interest@qt-project.org Subject: Re: [Interest] vs. Flutter On 2019-02-19 3:22 p.m., Jason H wrote: Was just reading the blog and it mentions live reloading: https://blog.qt.io/blog/2019/02/18/scaling-large-ui-development-projects-managing-complexities-reference-ui-neptune-3/ This Neptune3 thing, is that something we can use on the phones? I've been following the discussion and it looks like a lot of features of flutter, such as the live reloading, push notification, etc, already exists in felgo (use to be vplay). I used vplay for awhile, but it got too expensive so I just redid what I was using from their work myself. Only took a couple of weeks. My main point is that Qt can do all of this stuff because the felgo people already did. It just has to be done by Qt and put into the core. -- Lorne Sturtevant Sum Ergo Cogito ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] vs. Flutter
There's not anything I haven't done on mobile in Qt. The problem is everytime I start an app, I copy the 75% from the previous project and it's janky slap-dash of code. I've got to to this 3x for every app, every time. It's iOS, Android, and OSX. What I have works, it's not Troll quality. It is unforunately commercial code. I don't have hot-reload, but notificatons - push and local were working with Firebase on Android and iOS. Yeah, it's a couple weeks to develop all of that, but we're dozens of programmers re-inventing the wheel time and time again. This is not "code less create more". A few weeks of a couple developers and this would be a completely different situation instead person-years are being wasted. Sent: Tuesday, February 19, 2019 at 8:09 PM From: "Jérôme Godbout" To: "Lorne Sturtevant" , "interest@qt-project.org" Subject: Re: [Interest] vs. Flutter I did try a bit V-Play, but I did not like the fact I was stuck at a particular Qt version (it was 5.6 when 5.10 was out, last time I checked). Does the new Felgo allow to be used on other versoin and with up to date Qt Creator? that was a real bummer to be stuck with old version. The project seem to be fine aside from that problems. The price is a hard pill to swallow, with Qt 3D I guess the V-Play was less future proof I guess. From: Interest On Behalf Of Lorne Sturtevant Sent: February 19, 2019 7:04 PM To: interest@qt-project.org Subject: Re: [Interest] vs. Flutter On 2019-02-19 3:22 p.m., Jason H wrote: Was just reading the blog and it mentions live reloading: https://blog.qt.io/blog/2019/02/18/scaling-large-ui-development-projects-managing-complexities-reference-ui-neptune-3/ This Neptune3 thing, is that something we can use on the phones? I've been following the discussion and it looks like a lot of features of flutter, such as the live reloading, push notification, etc, already exists in felgo (use to be vplay). I used vplay for awhile, but it got too expensive so I just redid what I was using from their work myself. Only took a couple of weeks. My main point is that Qt can do all of this stuff because the felgo people already did. It just has to be done by Qt and put into the core. -- Lorne Sturtevant Sum Ergo Cogito ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt Location custom osm plugin and high res tiles
Hi, Seems to me that QGeoCameraCapabilities is a private qt API? >From what I found on the net seems it would help a lot for customizing own map plugin or tile server, but it's not clear how I can access it. Philippe Le 19-02-2019 19:40, maitai a écrit : > Thanks I'll give it a try > > Message d'origine > De : Paolo Angelelli > Date : 19/02/2019 7:21 PM (GMT+01:00) > À : interest@qt-project.org > Objet : Re: [Interest] Qt Location custom osm plugin and high res tiles > > Hi, yes it's easy. > All you have to do is setting the appropriate QGeoCameraCapabilities for the > map types you have high dpi tiles for. > So in your case, set the tilesize to 256x256, so that you will have more data > per logical pixel. > > hope it's clear enough. Or just check how it's done in either osm or here or > mapbox plugins > > On Tue, 19 Feb 2019 09:51:30 +0100 > maitai wrote: > >> Hello, >> >> Is it possible to use high res tiles with a custom osm plugin? >> In fact I created my own local server and would like to know if I can >> send high res tiles, for instance if devicePixelRatio is 2 I would send >> 512x512 tiles, expecting Qt Location to set the tile pixel ratio to 2. >> >> Thanks >> Philippe. >> ___ >> Interest mailing list >> Interest@qt-project.org >> https://lists.qt-project.org/listinfo/interest > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest