Re: [Interest] Odd behaviour when organizing .qml files into folders

2019-02-19 Thread Christian Kandeler
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

2019-02-19 Thread maitai

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

2019-02-19 Thread Vlad Stelmahovsky
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

2019-02-19 Thread René Hansen
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

2019-02-19 Thread Konstantin Tokarev


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

2019-02-19 Thread Jason H

> 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

2019-02-19 Thread Jason H
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

2019-02-19 Thread Christopher Probst
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

2019-02-19 Thread Jereme Givens- Lamothe
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

2019-02-19 Thread Jason H
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

2019-02-19 Thread Denis Golovkov
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

2019-02-19 Thread Giuseppe D'Angelo via Interest

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

2019-02-19 Thread Bernhard B
> 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

2019-02-19 Thread 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


Re: [Interest] Publish Qt app to fdroid

2019-02-19 Thread 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


Re: [Interest] vs. Flutter

2019-02-19 Thread Bernhard B
> 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

2019-02-19 Thread Bernhard B
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

2019-02-19 Thread Paolo Angelelli
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

2019-02-19 Thread Jason H
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

2019-02-19 Thread Sylvain Pointeau
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

2019-02-19 Thread maitai
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

2019-02-19 Thread Jason H

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

2019-02-19 Thread 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@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

2019-02-19 Thread ich
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

2019-02-19 Thread 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 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

2019-02-19 Thread ich
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

2019-02-19 Thread Jason H

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

2019-02-19 Thread Jason H
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, ich  a é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

2019-02-19 Thread Christoph Feck

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

2019-02-19 Thread Henry Skoglund

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

2019-02-19 Thread Sylvain Pointeau
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

2019-02-19 Thread Fabio Giovagnini
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

2019-02-19 Thread Jason H
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

2019-02-19 Thread Jason H
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 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



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


Re: [Interest] vs. Flutter

2019-02-19 Thread Jason H

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 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



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


Re: [Interest] vs. Flutter

2019-02-19 Thread Jason H

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 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)
___
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

2019-02-19 Thread Sze Howe Koh
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

2019-02-19 Thread Lorne Sturtevant

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

2019-02-19 Thread Jérôme Godbout
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

2019-02-19 Thread Jason H
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

2019-02-19 Thread maitai
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