Re: [Interest] Fwd: vs. Flutter

[Tuukka Turunen]

Hi,

I focused mainly in the tooling and cross-platform features in the roadmap blog 
post. There are other items done as well – more than what reasonably fits into 
a post. Mobile is an area where we are making constant development, just like 
we do on desktop and embedded.

Currently the biggest new investment goes towards tooling and 3D – both of 
which have some benefits for mobile as well. This of course eats some 
development capacity away from other things, but it does not mean nothing else 
would be done.

Many of our desktop and embedded users also address mobile – in addition to 
those who address mobile only (or start with mobile). That is the beauty of the 
cross-platform, with a growing number of users deploying to mobile.

Yours,

Tuukka

From: Interest  on behalf of Bernhard B 

Date: Friday, 22 February 2019 at 14.28
To: "interestqt-project. org" 
Subject: Re: [Interest] Fwd: vs. Flutter

Many thanks to Tuukka for the Qt Roadmap 2019 blog post 
(https://blog.qt.io/blog/2019/02/22/qt-roadmap-2019/) - very much appreciated!

As the mobile part was not explicitly mentioned, I assume that it won't be a 
focusing area for 2019 then? :/

Jean-Michaël Celerier 
mailto:jeanmichael.celer...@gmail.com>> schrieb 
am Fr., 22. Feb. 2019, 12:09:
> They even included, scripts to build the app. I'm not sure you have to go 
> quite that far to be compliant, but awesome nevertheless.

You explicitely have to:

LGPLv3 4. e): Provide Installation Information, but only if you would otherwise 
be required to provide such information under section 6 of the GNU GPL, and 
only to the extent that such information is necessary to install and execute a 
modified version of the Combined Work produced by recombining or relinking the 
Application with a modified version of the Linked Version. (If you use option 
4d0, the Installation Information must accompany the Minimal Corresponding 
Source and Corresponding Application Code. If you use option 4d1, you must 
provide the Installation Information in the manner specified by section 6 of 
the GNU GPL for conveying Corresponding Source.)

And the corresponding GPL part (section 6, emphasis mine) :

The “Corresponding Source” for a work in object code form means all the source 
code needed to generate, install, and (for an executable work) run the object 
code and to modify the work, including scripts to control those activities. 
However, it does not include the work's System Libraries, or general-purpose 
tools or generally available free programs which are used unmodified in 
performing those activities but which are not part of the work.



On Fri, Feb 22, 2019 at 11:55 AM René Hansen 
mailto:ren...@gmail.com>> wrote:

On Fri, 22 Feb 2019, 13:47 Jean-Michaël Celerier, 
mailto:jeanmichael.celer...@gmail.com>> wrote:
Cisco did it with an app that uses gstreamer (which is under LGPL) : 
https://itunes.apple.com/ua/app/cisco-jabber/id467192391?mt=8.
They send it on request, with the proprietary part in a static lib (see at the 
end here :
https://github.com/GStreamer/gst-plugins-good/blob/master/README.static-linking
)

That is really cool. They even included, scripts to build the app. I'm not sure 
you have to go quite that far to be compliant, but awesome nevertheless. Maybe 
someone can clarify this further. I.e. Are you responsible for providing a, or 
instructions for creating a, working build environment, in order to be LGPL 
compliant.


Best,
Jean-Michaël

On Thu, Feb 21, 2019 at 6:07 PM Sylvain Pointeau 
mailto:sylvain.point...@gmail.com>> wrote:
Do you have one example of someone who put a LGPL app in the app store and 
provided the binary object files?

On Thu, Feb 21, 2019 at 3:58 PM Julius Bullinger 
mailto:julius.bullin...@gmail.com>> wrote:
On 21.02.2019 15:44, Christian Gagneraud wrote:
> Qt is free (on mobile), free as in liberty, as long as your
> application is free, as in liberty.
> That's basic (L)GPL rules.
>
> Now there's the business rules:
> If you want your (mobile) app to be non-free (as in proprietary), then
> you'll have to pay the Qt company for that. Disregarding the fact that
> you want to make money or not.

Please do not spread this misinformation! As long as you adhere to the
terms of LGPL, you can create non-free, proprietary and closed apps with
Qt (or any other LGPL library for that matter). You only need to make
sure that the user can replace all LGPL parts with their own builds.

The fact that the mobile OS's and app stores make it exceptionally hard
to do that is not an issue with the license terms. If you find a way
that enables the user to replace LGPL parts (for example by dynamic
linking or by making all object files and linking instructions available
on request), that's perfectly valid and legal.

_That_ is a basic LGPL rule.

https://tldrlegal.com/license/gnu-lesser-general-public-license-v2.1-(lgpl-2.1)

https://tldrlegal.com/license/gnu-lesser-general-public-license-v3-(lgpl-3)

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

[Christian Kandeler]

On Fri, 22 Feb 2019 18:59:16 +0100
m...@herrdiel.de wrote:

> Am 18.02.2019 um 09:29 schrieb Christian Kandeler:
> > I suggest the opposite: Don't have a qrc file at all, but let qmake
> > auto-generate it by adding the qml files directly to RESOURCES.
> 
> Wow, that's interesting! I've tried that out for starters.
> 
> This excerpt from my .pro file shows what I do:

[...]

> That leads to this project tree:

There are no images in this email, but I assume you are referring to the fact 
that the QML files don't show up in your project tree initially, while the 
generated qrc file does. This is in my opinion a combination of two bugs: One 
in Qt (resources.prf "steals" the source file so it can't be shown directly by 
Qt Creator), and one in Qt Creator (the generated qrc file should not be shown 
unless "Hide generated files" is unchecked. We have patches for both on gerrit.


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

[Interest] Mailing list archives

[Andy]

Are the mailing list archives not updating again?

  https://lists.qt-project.org/pipermail/releasing/2019-February/thread.html

There are no messages since 14 Feb:

   "Archived on: Thu Feb 14 12:20:15 CET 2019"

There was supposed to be a meeting on "Tue 19th February 2019 16:00 CET" -
did it happen?

---
Andy Maloney  //  https://asmaloney.com
twitter ~ @asmaloney 
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Fwd: vs. Flutter

[Jason H]

Tukka, 

 

I don't think that there is a single Mobile user that finds your reply adequate.

 

It sounds like you're dragging Mobile users along. We need a specific mobile effort to add those mobile specific APIs the platform should have.  Without these APIs, my organization will not be able to justify continued usage of Qt. I have to continually defend our selection of Qt. I've never spoken to someone who was happy to have to use Qt. Xamarin, Flutter, and ReactNative are what other developers want to use. I cannot expect to continue to win this fight as Qt falls behind.

 

 

I'm not the only one. I'm just the Squeakiest wheel. I can't really justify another $1000/yr (1. that's just Indie, not Enerprise, 2. No transparent pricing) after spending $3000 on Qt. 

 

I'm begging you to add mobile APIs for:

- Device Hardware Control

-- Device Button Integration (volume, etc)

-- Display Brightness

-- Volume Control

-- Screen Control (Full Screen/ Nav Buttons, Wake Lock)

- Notifications (Push & Local, Desktop?) (Probably the dingle biggest pain point)

- iOS NFC (starts at iPhone 7, iOS 10)

 

These all might seem "not that hard", until you consider I have to do it for 3 platforms: OSX, iOS, Android, each with their own tech stack. (ObjC, JNI, Java) This is a huge pain point, considering that is the fundamental problem that Qt claims solve. Except it doesn't... on Mobile. It's not like I'm asking for bleeding edge APIs. Qt started supporting iOS & Android 12th Dec 2013 with Qt 5.2. In the 5 years since, none of the above have made it in and those are pretty basic features. Since that time there were some early iOS accessibilty additions and Android service capabilty. That's it. 

 

I'm not asking for every possible mobile API to be supported, just a 80/20. Other developers have their own needs, and I'm in favor of us together coming up with that list, and having Qt commit to the top item(s) each release. That's what I mean when I say I want a transparent roadmap for mobile.

 

 

 



Sent: Monday, February 25, 2019 at 3:20 AM
From: "Tuukka Turunen" 
To: "Bernhard B" , "interestqt-project. org" 
Subject: Re: [Interest] Fwd: vs. Flutter




Hi,

 

I focused mainly in the tooling and cross-platform features in the roadmap blog post. There are other items done as well – more than what reasonably fits into a post. Mobile is an area where we are making constant development, just like we do on desktop and embedded. 

 

Currently the biggest new investment goes towards tooling and 3D – both of which have some benefits for mobile as well. This of course eats some development capacity away from other things, but it does not mean nothing else would be done. 

 

Many of our desktop and embedded users also address mobile – in addition to those who address mobile only (or start with mobile). That is the beauty of the cross-platform, with a growing number of users deploying to mobile. 

 

Yours,

 

    Tuukka

 


From: Interest  on behalf of Bernhard B 
Date: Friday, 22 February 2019 at 14.28
To: "interestqt-project. org" 
Subject: Re: [Interest] Fwd: vs. Flutter



 



Many thanks to Tuukka for the Qt Roadmap 2019 blog post (https://blog.qt.io/blog/2019/02/22/qt-roadmap-2019/) - very much appreciated! 


 



As the mobile part was not explicitly mentioned, I assume that it won't be a focusing area for 2019 then? :/



 



Jean-Michaël Celerier  schrieb am Fr., 22. Feb. 2019, 12:09:





> They even included, scripts to build the app. I'm not sure you have to go quite that far to be compliant, but awesome nevertheless.



 



You explicitely have to:



 



LGPLv3 4. e): Provide Installation Information, but only if you would otherwise be required to provide such information under section 6 of the GNU GPL, and only to the extent that such information is necessary to install and execute a modified version of the Combined Work produced by recombining or relinking the Application with a modified version of the Linked Version. (If you use option 4d0, the Installation Information must accompany the Minimal Corresponding Source and Corresponding Application Code. If you use option 4d1, you must provide the Installation Information in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.)



 



And the corresponding GPL part (section 6, emphasis mine) :



The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work.





 




 


 



On Fri, Feb 22, 2019 at 11:55 AM René Hansen  wrote:



 



On Fri, 22 Feb 2019, 13:47 Jean-Michaël Cele

Re: [Interest] Replacement for Qt4 QMatrix4x4?

[Jason H]

> Sent: Friday, February 22, 2019 at 4:27 AM
> From: "Christian Gagneraud" 
> Would you consider making arm v8 the minimum requirement for Qt6?

You might anger the raspberry pi people who still use ARM11 in the Pi Zero, and 
other embedded users. I don't see 32bit arm cores going away any time soon, 
particularly in embedded designs. It may be acceptable to cap these at a Qt5 
version. Since ARM v8 is only 7 years old (about the same age of Qt5), I would 
hesitate to leave 32-bit arm out.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Animating viewable rect of QGraphicsView

[Patrick Stinson]

How can I animate the viewable scene rect of a QGraphicsView using screen 
coordinates? This means animating both center pos and scale. This is similar to 
Google Earth where the map scrolls and zooms smoothly from one point to 
another. I have searched for an answer for this several times in the last 
couple of years with little success.

The use case is that I use QGraphicsView::fitInView to show the bounding rect 
of all visible items. Then some items are hidden and I want to animate 
zooming/scrolling to fit the new bounding rect of all the items.

Simply setting up one animation to periodically call QGraphicsView::centerOn() 
and another to call QGraphicsView::scale() doesn't work because calling one 
displaces the values of the other as the interpolation progresses.

Thoughts? This seems like a pretty essential use case for QGraphicsView.

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

[Interest] QtLocation MapPolyLine and MapPolyGon style

[maitai]

Hi,

I may be wrong since it seems incredible, but it seems there is no way 
to draw a MapPolyLine dashed or dotlined, and similarly I didn't find a 
way to fill a MapPolygon with a pattern.


If that is the case, what in your opinion would be the best way to 
implement this?


I found QTBUG-46651 which recommends to use an empty mapboxgl layer 
instead of my current itemsoverlay map, would that cover the needs since 
I have plenty of other mapItems and need to manage z values for each of 
them?


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

[Interest] QNetworkReply::AuthenticationRequiredError "Host requires authentication"

[Nuno Santos]

Hi,

I’m developing a application that interacts with an API. The api url is 
https:// 

On Mac OSX desktop I can access the API. However, with the exact same code and 
user on iOS and Android I’m getting:

QNetworkReply::AuthenticationRequiredError "Host requires authentication”

Is there any obvious reason I’m missing out?

Thanks!

Nuno

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

Re: [Interest] Fwd: vs. Flutter

[Bernhard B]

definitely a +1 from my side.

I totally get that there are limited resources and therefore management has
to focus on some parts, but if I just look at the Qt mobile functionality
(and blend away everything else), I have to agree with Jason. Fortunately I
am in a position where I do not "depend" on Qt in any way - I am just a
hobby developer that likes to tinker around. So, if it turns out that the
mobile development halts, I'll probably migrate my apps away from Qt at
some point and/or use a different framework for new projects. But I guess
that's a bit more difficult for developers that earn a living with their Qt
apps - porting away from Qt then will be a huge pain (and most often not
worth it from a business point of view, unless it gets unbearable).

The main reason, why I am still with Qt on mobile is, that I know most of
Qt's quirks and that I really LOVE QML. Another huge plus is, that I've
grown a pretty solid set of
device dependend helper tools/functionalities over the years. Namely:

- Notifications (GCM)
- Hardware buttons
- Vibration
- Sensors (Accelerometer)
- Screen Control (keep screen on)
- Keystore/Keychain integration to store credentials
- Access to media gallery on android (I have to check, but I _think_ that
functionality is now part of Qt 5.13; at least according to
https://wiki.qt.io/New_Features_in_Qt_5.13)

If I wouldn't have those ready at my fingertips, I am not really sure
whether I would choose Qt again...
I also found it pretty hard (I would almost say impossible) to convince my
friends to give Qt a shot. No matter how good Qt's declarative language is,
there are certain functionalities that every mobile app developer expects
from a framework and unfortunately, Qt's missing quite a few of them :/

Cheers,
Bernhard

Am Mo., 25. Feb. 2019 um 17:06 Uhr schrieb Jason H :

> Tukka,
>
> I don't think that there is a single Mobile user that finds your reply
> adequate.
>
> It sounds like you're dragging Mobile users along. We need a specific
> mobile effort to add those mobile specific APIs the platform should have.
> Without these APIs, my organization will not be able to justify continued
> usage of Qt. I have to continually defend our selection of Qt. I've never
> spoken to someone who was happy to have to use Qt. Xamarin, Flutter, and
> ReactNative are what other developers want to use. I cannot expect to
> continue to win this fight as Qt falls behind.
>
>
> I'm not the only one. I'm just the Squeakiest wheel. I can't really
> justify another $1000/yr (1. that's just Indie, not Enerprise, 2. No
> transparent pricing) after spending $3000 on Qt.
>
> I'm begging you to add mobile APIs for:
> - Device Hardware Control
> -- Device Button Integration (volume, etc)
> -- Display Brightness
> -- Volume Control
> -- Screen Control (Full Screen/ Nav Buttons, Wake Lock)
> - Notifications (Push & Local, Desktop?) (Probably the dingle biggest pain
> point)
> - iOS NFC (starts at iPhone 7, iOS 10)
>
> These all might seem "not that hard", until you consider I have to do it
> for 3 platforms: OSX, iOS, Android, each with their own tech stack. (ObjC,
> JNI, Java) This is a huge pain point, considering that is the fundamental
> problem that Qt claims solve. Except it doesn't... on Mobile. It's not like
> I'm asking for bleeding edge APIs. Qt started supporting iOS & Android 12th
> Dec 2013 with Qt 5.2. In the 5 years since, none of the above have made it
> in and those are pretty basic features. Since that time there were some
> early iOS accessibilty additions and Android service capabilty. That's it.
>
> I'm not asking for every possible mobile API to be supported, just a
> 80/20. Other developers have their own needs, and I'm in favor of us
> together coming up with that list, and having Qt commit to the top item(s)
> each release. That's what I mean when I say I want a transparent roadmap
> for mobile.
>
>
>
> *Sent:* Monday, February 25, 2019 at 3:20 AM
> *From:* "Tuukka Turunen" 
> *To:* "Bernhard B" , "interestqt-project. org" <
> interest@qt-project.org>
> *Subject:* Re: [Interest] Fwd: vs. Flutter
>
> Hi,
>
>
>
> I focused mainly in the tooling and cross-platform features in the roadmap
> blog post. There are other items done as well – more than what reasonably
> fits into a post. Mobile is an area where we are making constant
> development, just like we do on desktop and embedded.
>
>
>
> Currently the biggest new investment goes towards tooling and 3D – both of
> which have some benefits for mobile as well. This of course eats some
> development capacity away from other things, but it does not mean nothing
> else would be done.
>
>
>
> Many of our desktop and embedded users also address mobile – in addition
> to those who address mobile only (or start with mobile). That is the beauty
> of the cross-platform, with a growing number of users deploying to mobile.
>
>
>
> Yours,
>
>
>
> Tuukka
>
>
>
> *From: *Interest  on behalf of Bernhard
> B 
> *Date: *Friday, 22 Febr

Re: [Interest] Fwd: vs. Flutter

[Jason H]

 

1. "Access to media gallery on android" ? If you're taking pictures in Qt and want them to appear in the gallery, you currently have to save them to the gallery and reboot the device. Or implement a Broadcast message to tell Android to scan/add the image.  Yet another thing Qt is missing on mobile...

 

2. Sensors (accelerometer) work. In fact I regularly use most of the sensors. 

 

3. Can you elaborate on your keychain needs?

 


Sent: Monday, February 25, 2019 at 2:48 PM
From: "Bernhard B" 
To: "Jason H" 
Cc: "Tuukka Turunen" , "interestqt-project. org" 
Subject: Re: [Interest] Fwd: vs. Flutter





definitely a +1 from my side.

 

I totally get that there are limited resources and therefore management has to focus on some parts, but if I just look at the Qt mobile functionality (and blend away everything else), I have to agree with Jason. Fortunately I am in a position where I do not "depend" on Qt in any way - I am just a hobby developer that likes to tinker around. So, if it turns out that the mobile development halts, I'll probably migrate my apps away from Qt at some point and/or use a different framework for new projects. But I guess that's a bit more difficult for developers that earn a living with their Qt apps - porting away from Qt then will be a huge pain (and most often not worth it from a business point of view, unless it gets unbearable).

 

The main reason, why I am still with Qt on mobile is, that I know most of Qt's quirks and that I really LOVE QML. Another huge plus is, that I've grown a pretty solid set of

device dependend helper tools/functionalities over the years. Namely:

 

- Notifications (GCM)

- Hardware buttons

- Vibration

- Sensors (Accelerometer)

- Screen Control (keep screen on)

- Keystore/Keychain integration to store credentials

- Access to media gallery on android (I have to check, but I _think_ that functionality is now part of Qt 5.13; at least according to https://wiki.qt.io/New_Features_in_Qt_5.13)

 

If I wouldn't have those ready at my fingertips, I am not really sure whether I would choose Qt again...

I also found it pretty hard (I would almost say impossible) to convince my friends to give Qt a shot. No matter how good Qt's declarative language is, there are certain functionalities that every mobile app developer expects from a framework and unfortunately, Qt's missing quite a few of them :/

 

Cheers,

Bernhard



 


Am Mo., 25. Feb. 2019 um 17:06 Uhr schrieb Jason H :




Tukka, 

 

I don't think that there is a single Mobile user that finds your reply adequate.

 

It sounds like you're dragging Mobile users along. We need a specific mobile effort to add those mobile specific APIs the platform should have.  Without these APIs, my organization will not be able to justify continued usage of Qt. I have to continually defend our selection of Qt. I've never spoken to someone who was happy to have to use Qt. Xamarin, Flutter, and ReactNative are what other developers want to use. I cannot expect to continue to win this fight as Qt falls behind.

 

 

I'm not the only one. I'm just the Squeakiest wheel. I can't really justify another $1000/yr (1. that's just Indie, not Enerprise, 2. No transparent pricing) after spending $3000 on Qt. 

 

I'm begging you to add mobile APIs for:

- Device Hardware Control

-- Device Button Integration (volume, etc)

-- Display Brightness

-- Volume Control

-- Screen Control (Full Screen/ Nav Buttons, Wake Lock)

- Notifications (Push & Local, Desktop?) (Probably the dingle biggest pain point)

- iOS NFC (starts at iPhone 7, iOS 10)

 

These all might seem "not that hard", until you consider I have to do it for 3 platforms: OSX, iOS, Android, each with their own tech stack. (ObjC, JNI, Java) This is a huge pain point, considering that is the fundamental problem that Qt claims solve. Except it doesn't... on Mobile. It's not like I'm asking for bleeding edge APIs. Qt started supporting iOS & Android 12th Dec 2013 with Qt 5.2. In the 5 years since, none of the above have made it in and those are pretty basic features. Since that time there were some early iOS accessibilty additions and Android service capabilty. That's it. 

 

I'm not asking for every possible mobile API to be supported, just a 80/20. Other developers have their own needs, and I'm in favor of us together coming up with that list, and having Qt commit to the top item(s) each release. That's what I mean when I say I want a transparent roadmap for mobile.

 

 

 



Sent: Monday, February 25, 2019 at 3:20 AM
From: "Tuukka Turunen" 
To: "Bernhard B" , "interestqt-project. org" 
Subject: Re: [Interest] Fwd: vs. Flutter




Hi,

 

I focused mainly in the tooling and cross-platform features in the roadmap blog post. There are other items done as well – more than what reasonably fits into a post. Mobile is an area where we are making constant development, just like we do 

Re: [Interest] Fwd: vs. Flutter

[Bernhard B]

> 1. "Access to media gallery on android" ? If you're taking pictures in Qt
and want them to appear in the gallery, you currently have to save them to
the gallery and reboot the device. Or implement a Broadcast message to tell
Android to scan/add the image.  Yet another thing Qt is missing on
mobile...

Not only saving an image to the gallery, but also opening the native
android image gallery to select an image. I think I've implemented the
necessary JNI calls while working with Qt 5.9.x..so maybe newer Qt versions
have that already covered.

> Sensors (accelerometer) work. In fact I regularly use most of the
sensors.

thanks, wasn't aware of that!

>  Can you elaborate on your keychain needs?

I use the keychain primarily for storing sensitive data. e.q: If the user
authenticates itself against a web service, I store the returned access
token in the keystore (android) resp. keychain (iOs).


Am Mo., 25. Feb. 2019 um 22:44 Uhr schrieb Jason H :

>
> 1. "Access to media gallery on android" ? If you're taking pictures in Qt
> and want them to appear in the gallery, you currently have to save them to
> the gallery and reboot the device. Or implement a Broadcast message to tell
> Android to scan/add the image.  Yet another thing Qt is missing on mobile...
>
> 2. Sensors (accelerometer) work. In fact I regularly use most of the
> sensors.
>
> 3. Can you elaborate on your keychain needs?
>
> *Sent:* Monday, February 25, 2019 at 2:48 PM
> *From:* "Bernhard B" 
> *To:* "Jason H" 
> *Cc:* "Tuukka Turunen" , "interestqt-project. org" <
> interest@qt-project.org>
> *Subject:* Re: [Interest] Fwd: vs. Flutter
> definitely a +1 from my side.
>
> I totally get that there are limited resources and therefore management
> has to focus on some parts, but if I just look at the Qt mobile
> functionality (and blend away everything else), I have to agree with Jason.
> Fortunately I am in a position where I do not "depend" on Qt in any way - I
> am just a hobby developer that likes to tinker around. So, if it turns out
> that the mobile development halts, I'll probably migrate my apps away from
> Qt at some point and/or use a different framework for new projects. But I
> guess that's a bit more difficult for developers that earn a living with
> their Qt apps - porting away from Qt then will be a huge pain (and most
> often not worth it from a business point of view, unless it gets
> unbearable).
>
> The main reason, why I am still with Qt on mobile is, that I know most of
> Qt's quirks and that I really LOVE QML. Another huge plus is, that I've
> grown a pretty solid set of
> device dependend helper tools/functionalities over the years. Namely:
>
> - Notifications (GCM)
> - Hardware buttons
> - Vibration
> - Sensors (Accelerometer)
> - Screen Control (keep screen on)
> - Keystore/Keychain integration to store credentials
> - Access to media gallery on android (I have to check, but I _think_ that
> functionality is now part of Qt 5.13; at least according to
> https://wiki.qt.io/New_Features_in_Qt_5.13)
>
> If I wouldn't have those ready at my fingertips, I am not really sure
> whether I would choose Qt again...
> I also found it pretty hard (I would almost say impossible) to convince my
> friends to give Qt a shot. No matter how good Qt's declarative language is,
> there are certain functionalities that every mobile app developer expects
> from a framework and unfortunately, Qt's missing quite a few of them :/
>
> Cheers,
> Bernhard
>
> Am Mo., 25. Feb. 2019 um 17:06 Uhr schrieb Jason H :
>
>> Tukka,
>>
>> I don't think that there is a single Mobile user that finds your reply
>> adequate.
>>
>> It sounds like you're dragging Mobile users along. We need a specific
>> mobile effort to add those mobile specific APIs the platform should have.
>> Without these APIs, my organization will not be able to justify continued
>> usage of Qt. I have to continually defend our selection of Qt. I've never
>> spoken to someone who was happy to have to use Qt. Xamarin, Flutter, and
>> ReactNative are what other developers want to use. I cannot expect to
>> continue to win this fight as Qt falls behind.
>>
>>
>> I'm not the only one. I'm just the Squeakiest wheel. I can't really
>> justify another $1000/yr (1. that's just Indie, not Enerprise, 2. No
>> transparent pricing) after spending $3000 on Qt.
>>
>> I'm begging you to add mobile APIs for:
>> - Device Hardware Control
>> -- Device Button Integration (volume, etc)
>> -- Display Brightness
>> -- Volume Control
>> -- Screen Control (Full Screen/ Nav Buttons, Wake Lock)
>> - Notifications (Push & Local, Desktop?) (Probably the dingle biggest
>> pain point)
>> - iOS NFC (starts at iPhone 7, iOS 10)
>>
>> These all might seem "not that hard", until you consider I have to do it
>> for 3 platforms: OSX, iOS, Android, each with their own tech stack. (ObjC,
>> JNI, Java) This is a huge pain point, considering that is the fundamental
>> problem that Qt claims solve. Except it doesn't... on Mobile. It's n

Re: [Interest] Scaling out of SVG in QGraphicsScene background

[Christian Gagneraud]

On Mon, 25 Feb 2019 at 19:18, Felix Rubio Dalmau via Interest
 wrote:
>
> Hi all,
>
> I am trying to paint a SVG I have on a file on the background of a 
> QGraphicsScene, and I am facing some issues: if I subclass QGraphicsScene and 
> in the __init__ method I add:
>
> self.target = QtSvg.QGraphicsSvgItem(target)
> rect = self.target.boundingRect()
> self.target.setPos(-rect.width()/2, -rect.height()/2)
> self.addItem(self.target)
>
> So that then in my main window I set the QGraphicsView to do a 
> fitInView (the size of the widget is 500x500), via
>
> self.ui.targetView.fitInView(self.scene.sceneRect(), 
> QtCore.Qt.KeepAspectRatio)
>
> The result is what expected: a nice, smooth image.
>
> However, if I try to draw the SVG on the background of the 
> QGraphicsScene, via:
>
> self.renderer = QtSvg.QSvgRenderer(target)
> rect = self.renderer.defaultSize()
> self.image = QtGui.QImage(rect, QtGui.QImage.Format_ARGB32)
> self.painter = QtGui.QPainter(self.image)
> self.renderer.render(self.painter)
> self.setBackgroundBrush(QtGui.QBrush(self.image))
> self.setSceneRect(QtCore.QRectF(QtCore.QPointF(0, 0), 
> QtCore.QSizeF(self.image.size(
>
> Without doing the scaling the picture looks OK, but after doing the 
> scaling the picture looks pixelized. How can I fix that?
> Also, I have observed that I have to set the scene rectangle, while I 
> understood that the scene itself would take care of that?

Maybe you have a caching issue, see
https://doc.qt.io/qt-5/qgraphicsview.html#cacheMode-prop
Maybe as well https://doc.qt.io/qt-5/qgraphicsscene.html#invalidate could help

Chris

>
> Thank you for your help!
> Felix
>
> PS: for reference, the picture is 
> https://upload.wikimedia.org/wikipedia/commons/1/17/WA_80_cm_archery_target.svg
>
>
> ___
> 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] Replacement for Qt4 QMatrix4x4?

[Christian Gagneraud]

On Tue, 26 Feb 2019 at 05:37, Jason H  wrote:
>
> > Sent: Friday, February 22, 2019 at 4:27 AM
> > From: "Christian Gagneraud" 
> > Would you consider making arm v8 the minimum requirement for Qt6?
>
> You might anger the raspberry pi people who still use ARM11 in the Pi Zero, 
> and other embedded users. I don't see 32bit arm cores going away any time 
> soon, particularly in embedded designs. It may be acceptable to cap these at 
> a Qt5 version. Since ARM v8 is only 7 years old (about the same age of Qt5), 
> I would hesitate to leave 32-bit arm out.

It was more a question than a suggestion. The rational is that
qreal=float only make sense on low-end/old processors, so if ARMv8 is
the minimum required, you can completely get rid of qreal.
Our code base is built with qreal=float on ARM and qreal=double on x86
Linux/Windows. It's actually a pain if you enable certain
-Wconversion.
How to you assign a literal to a qreal? You cannot, there's no qreal
literal, only float and double.
This code:
qreal a = 0.1f;
qreal b = 0.1;
Will cause a warning in both cases:
qreal=double: implicit conversion of a increases floating-point precision
qreal=float: implicit conversion of b looses floating-point precision

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

Re: [Interest] vs. Flutter

[Vlad Stelmahovsky]

if you guys already did some code for mobiles, why dont just contribute 
back?


On 2/20/19 3:32 AM, Jason H wrote:
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
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest