[Interest] QML vs Electron

[Bob Hood]

I'm starting to see more and more software being written in, or being ported 
to, Electron[1] (e.g., Skype's latest v8 update now uses Electron).  I know 
QML is supposed to be Qt's solution to cross-device development, so I'm 
wondering if anybody here has had opportunity to actually use both, and what 
insights they might have in terms of comparing QML's declarative design to 
Electron's HTML5 approach.


Full disclosure: I'm a hard-core Qt C++ developer, and I've made no secret of 
the fact that I'm not crazy about QML.  However, it's getting harder and 
harder to avoid having to be cross-device in my development, and while I know 
Qt Widgets can run on mobile devices, but it seems like a heavy weight and 
somewhat inelegant approach.  Something more designed for the task might be my 
only/better option.


On a related note, has anybody done a QML (e)book yet that is focused on its 
uses in cross-device development?  The last/only one I saw seemed to focus 
only using QML to create interfaces from scratch, and that just turned me off, 
coming from the widget-rich environment of Qt desktop.


[1] https://electronjs.org/
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML vs Electron

[Roland Hughes]

That definitely has the feel and order of slime.


On 02/21/2018 08:52 AM, Benjamin wrote:

Maybe I should have quoted the text just above: "An obligation to
share your Qt software code"
I'd like to see how many new comers will understand this as "an
obligation to share the modifications you have done to Qt"
vs "an obligation to share your own code that uses Qt".


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us/
http://onedollarcontentstore.com
 


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

Re: [Interest] QML vs Electron

[Sylvain Pointeau]

On Tue, 20 Feb 2018 at 12:58, René Hansen  wrote:

>
> Taxing big corporate use, while exempting smalltime adoption, even
> commercial, might be the way to go. This is just speculation on my part
> though, I have no idea how a licensing scheme like this would work in
> practice.
>

This was exactly my issue. I have an idea for a phone / tablet app and I
really wanted to go with Qt but ~500 euros per month was a no go (for all
people involved)

I have chosen react native instead. Microsoft has even developed a version
for desktop. they also developed ReactXP (xp meaning for x platforms) to
have a single source for all platforms (based on react native) and they use
it for skype.

I would have chosen Qt but the license is just not good. I guess only a
free access can make the community growing.

I also see that Qt is now more active on embedded system. Maybe the desktop
has no market anymore? even Oracle prefers to focus on microservices.

after all Qml is javascript based, because it was simpler and more
flexible. React Native also has the same principle, except that native
components are used at the end.

Flutter seems very similar to Qt, except that it compiles to native. I did
not like that there is no desktop and that we must instantiate different
component for ios or android.

and no, I did not choose react native because what-so-ever on javascript, I
chose it because of the rationale above, it was a compromise.

ps: and if the web is a preferred approach, it is not for all arguments I
have read, but for the simplicity of deployment and access control.

Best regards,
Sylvain
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML vs Electron

[Roland Hughes]

I feel your pain.

Let us not forget there is a __HUGE__ section of the industry which has 
a severe ethical problem with someone taking an OpenSource product, 
adding a tiny few things then trying to both license the __same__ 
product __and__ collect royalties in perpetuity.


Those who fail to learn from history are doomed to repeat it.

This is like watching WANG and Ashton Tate combined.

Even embedded systems have started moving away from Qt due to due to 
marketing always trying to force a license on people whether they need 
it or not.


U++ is getting attention.  https://www.ultimatepp.org

Even Zinc is starting to make a comeback after many years of being the 
UI library for WindRiver.


http://openzinc.com

Judging from recent postings on indeed.com, even CAT has abandoned Qt 
over licensing. They are now looking to replace all of their Qt people 
with html5 people to convert all existing embedded systems.  Too bad I 
cleaned out my sent mail folder this weekend, I had a scrape of the 
posting in a message I sent to friends. It stated they wanted html5 
developers skilled at porting Qt applications. I mean this is CAT. A 
household name. Quite possibly the last company on the planet with any 
WinCE and they've now officially turned their back on Qt, pretty much 
over licensing.


I guess the final nail in the coffin will be Ford. When they fired 
Microsoft over Sync it was the end of Microsoft having any presence in 
the embedded world. Grumblings from the below market rate Qt coders 
working there is that the days of Qt and sync are numbered. Again, 
licensing and royalties play a big role, but, the bigger issue there is 
they want to pay less than half of market rate for Qt talent and aren't 
finding enough takers (now that I know this about their embedded systems 
developers, I'm never buying a new Ford or any Ford with Sync in it.) 
They can get illegal aliens working with html5 for about $10/day.


When both CAT and Ford have kicked Qt to the curb due to costs, the 
dominoes will fall from there. That will be two of America's largest 
manufacturers. Many others follow their lead.


As you stated Nikos, the "You need a license no matter what"marketing 
approach is ensuring that no new development is occurring with Qt at 
small companies. Mega sized companies with enough lawyers to thread the 
licensing maze, yes, but not for long. They are going to get tired of 
dancing around the never ending royalties and bring in Zinc, U++ or html5.


The U++ group/fans/whatever have been targeting Qt for a while now.

https://www.ultimatepp.org/www$uppweb$vsqt$en-us.html

Actually targeting quite a few development tools.

https://www.ultimatepp.org/www$uppweb$comparison$en-us.html


On 08/04/2018 12:39 PM, Nikos Chantziaras wrote:

Taxing big corporate use, while exempting smalltime adoption, even
commercial, might be the way to go. This is just speculation on my part
though, I have no idea how a licensing scheme like this would work in
practice.


This was exactly my issue. I have an idea for a phone / tablet app and I
really wanted to go with Qt but ~500 euros per month was a no go (for all
people involved)


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us/
http://onedollarcontentstore.com

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

Re: [Interest] QML vs Electron

[ekke]

Am 04.08.18 um 19:23 schrieb Sylvain Pointeau:
> On Tue, 20 Feb 2018 at 12:58, René Hansen  > wrote:
>
>
> Taxing big corporate use, while exempting smalltime adoption, even
> commercial, might be the way to go. This is just speculation on my
> part though, I have no idea how a licensing scheme like this would
> work in practice.
>
>
> This was exactly my issue. I have an idea for a phone / tablet app and
> I really wanted to go with Qt but ~500 euros per month was a no go
> (for all people involved)

I'm doing all my mobile Apps (Android, iOS) with Qt (QtQuickControls2)
and really like Qt. (compared with Flutter, ReactNative, Xamarin, etc)

As a single developer (Freelancer) I'm using the Start-Up License
(99$/Month)

the info about the startup license is something hidden on the web sites:
https://www1.qt.io/start-up-plan/


presenting my apps to other devs at conferences or so there's always a
"wow" effect, because of UI/UX and performance of even very complex apps.

the problem is the license.

developers looking at Qt site always think they must pay ~500 EUR as
independent devs which is too much compared with other frameworks

even the Startup License isn't easy to do


this is frustrating: knowing that Qt is great for mobile apps, but
there's a license cost barriere


I'm really waiting for a 30 EUR or so Indiependent Dev License.

I know from discussions that in the past there already was such kind of
license with less success.

But in the past there were no QtQuickControls2 and HighDPI support.
(Both was the reason why I started developing mobile Apps with Qt)


-- 

ekke (ekkehard gentz)

independent software architect
international development native mobile business apps
Qt Mobile (Android, iOS)
workshops - trainings - bootcamps

*Qt Champion
BlackBerry Elite Developer
*

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

Re: [Interest] QML vs Electron

[Sylvain Pointeau]

On Mon, Aug 6, 2018 at 3:44 PM ekke  wrote:

> Am 04.08.18 um 19:23 schrieb Sylvain Pointeau:
>
> On Tue, 20 Feb 2018 at 12:58, René Hansen  wrote:
>
>>
>> Taxing big corporate use, while exempting smalltime adoption, even
>> commercial, might be the way to go. This is just speculation on my part
>> though, I have no idea how a licensing scheme like this would work in
>> practice.
>>
>
> This was exactly my issue. I have an idea for a phone / tablet app and I
> really wanted to go with Qt but ~500 euros per month was a no go (for all
> people involved)
>
> I'm doing all my mobile Apps (Android, iOS) with Qt (QtQuickControls2) and
> really like Qt. (compared with Flutter, ReactNative, Xamarin, etc)
>
> As a single developer (Freelancer) I'm using the Start-Up License
> (99$/Month)
>
> the info about the startup license is something hidden on the web sites:
> https://www1.qt.io/start-up-plan/
>
>
> presenting my apps to other devs at conferences or so there's always a
> "wow" effect, because of UI/UX and performance of even very complex apps.
>
> the problem is the license.
>
> developers looking at Qt site always think they must pay ~500 EUR as
> independent devs which is too much compared with other frameworks
>
> even the Startup License isn't easy to do
>
>
> this is frustrating: knowing that Qt is great for mobile apps, but there's
> a license cost barriere
>
>
> I'm really waiting for a 30 EUR or so Indiependent Dev License.
>
> I know from discussions that in the past there already was such kind of
> license with less success.
>
> But in the past there were no QtQuickControls2 and HighDPI support. (Both
> was the reason why I started developing mobile Apps with Qt)
>

I fully agree with you. I am fully convinced by Qt, I wanted to go with Qt,
but the price was too high.
On the website, it is not said anywhere the price for a startup. I
understood it gave only the right to develop until the go live (like an
extended demo version).

at 30 euros, I would not even think (and I would switch immediately).

Best regards,
Sylvain
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML vs Electron

[Giuseppe D'Angelo]

On Mon, 6 Aug 2018 at 23:46, Sylvain Pointeau
 wrote:
>
>
> On Mon, Aug 6, 2018 at 3:44 PM ekke  wrote:
>>
>>
>> I'm really waiting for a 30 EUR or so Indiependent Dev License.
>>
>> I know from discussions that in the past there already was such kind of 
>> license with less success.
>>
>> But in the past there were no QtQuickControls2 and HighDPI support. (Both 
>> was the reason why I started developing mobile Apps with Qt)
>
>
> I fully agree with you. I am fully convinced by Qt, I wanted to go with Qt, 
> but the price was too high.
> On the website, it is not said anywhere the price for a startup. I understood 
> it gave only the right to develop until the go live (like an extended demo 
> version).
>
> at 30 euros, I would not even think (and I would switch immediately).

Out of curiosity, what prevented you from going with LGPL Qt?

-- 
Giuseppe D'Angelo
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML vs Electron

[Sylvain Pointeau]

On Mon, Aug 6, 2018 at 11:56 PM Giuseppe D'Angelo 
wrote:

> On Mon, 6 Aug 2018 at 23:46, Sylvain Pointeau
>  wrote:
> >
> >
> > On Mon, Aug 6, 2018 at 3:44 PM ekke  wrote:
> >>
> >>
> >> I'm really waiting for a 30 EUR or so Indiependent Dev License.
> >>
> >> I know from discussions that in the past there already was such kind of
> license with less success.
> >>
> >> But in the past there were no QtQuickControls2 and HighDPI support.
> (Both was the reason why I started developing mobile Apps with Qt)
> >
> >
> > I fully agree with you. I am fully convinced by Qt, I wanted to go with
> Qt, but the price was too high.
> > On the website, it is not said anywhere the price for a startup. I
> understood it gave only the right to develop until the go live (like an
> extended demo version).
> >
> > at 30 euros, I would not even think (and I would switch immediately).
>
> Out of curiosity, what prevented you from going with LGPL Qt?
>
>
On desktop it is clear but on mobile, there was no clear statement if we
have the rights or not.
Seems like LGPL is not friendly with the various stores.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML vs Electron

[Roland Hughes]

On 08/06/2018 05:36 PM, ekke wrote:

this is frustrating: knowing that Qt is great for mobile apps, but
there's a license cost barriere

Don't forget about the royalties when you start offering things for sale.

--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us/
http://onedollarcontentstore.com

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

Re: [Interest] QML vs Electron

[Roland Hughes]

So, their demo is old. They aren't going to sit there and update it each 
time. It didn't look odd to me. I spent several years coding like that 
when Qt believed in multiple inheritance, then they wanted to reach out 
to the dying language of Java . . . Perhaps you weren't around during 
the Trolltech days?


You should also be aware that the version of U++ they did that with is 
extremely outdated. It's kind of like those Qt wiki pages which sit 
around for a decade or more. Especially the ones for cross compiling to 
Raspberry Pi which don't tell you they used a 32-bit host system to hide 
all of the errors. That was great fun.



On 08/06/2018 04:19 AM, André Pönitz wrote:

On Mon, Aug 06, 2018 at 08:01:32AM -0500, Roland Hughes wrote:

Even embedded systems have started moving away from Qt due to due to
marketing always trying to force a license on people whether they need it or
not.

U++ is getting attention.  https://www.ultimatepp.org

[...]

https://www.ultimatepp.org/www$uppweb$comparison$en-us.html


  "To compare Ultimate++ with Qt (R), we decided to reimplement Qt
   demonstration example "AddressBook". On the left side is U++ code,
   on the right side original Qt example."

   "Qt and the Qt logo are trademarks of Trolltech in Norway,
   the United States and other countries."

   "ABMainWindow::ABMainWindow()
 : QMainWindow( 0, "example addressbook application" ),
   filename( QString::null )"


In case this already looks odd to you, you may stop reading here.

Andre'



PS: Spoiler:































































  What is *not* shown there is the line

   " ** Copyright (C) 1992-2008 Trolltech ASA. "



--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us/
http://onedollarcontentstore.com

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

Re: [Interest] QML vs Electron

[Vincent Hui]

 Do the royalties apply for desktop and mobile applications too?
If I am right, the royalties do apply for only embedded devices. The
royalties are paid by buying Qt for Device Creation Distribution Licenses.


On 7 August 2018 at 06:57, Roland Hughes 
wrote:

>
>
> On 08/06/2018 05:36 PM, ekke wrote:
>
> this is frustrating: knowing that Qt is great for mobile apps, but
> there's a license cost barriere
>
> Don't forget about the royalties when you start offering things for sale.
>
> --
> Roland Hughes, President
> Logikal Solutions
> (630)-205-1593
> http://www.theminimumyouneedtoknow.comhttp://www.infiniteexposure.nethttp://www.johnsmith-book.comhttp://www.logikalblog.comhttp://www.interestingauthors.com/bloghttp://lesedi.us/http://onedollarcontentstore.com
>
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML vs Electron

[Maurice Kalinowski]

I would like to ask to you stop spreading this misinformed and misleading 
content.

There are two commercial products for Qt, Qt for Application Development and Qt 
for Device Creation. Creating a mobile or desktop app (Qt AD) does _not_ ask 
for runtimes for royalties.

If you have any further question, please get in touch with your sales 
representative directly and ask for details and/or an offer.

BR,
Maurice



From: Interest  On 
Behalf Of Roland Hughes
Sent: Tuesday, August 7, 2018 12:58 AM
To: interest@qt-project.org
Subject: Re: [Interest] QML vs Electron




On 08/06/2018 05:36 PM, ekke wrote:

this is frustrating: knowing that Qt is great for mobile apps, but

there's a license cost barriere
Don't forget about the royalties when you start offering things for sale.


--

Roland Hughes, President

Logikal Solutions

(630)-205-1593



http://www.theminimumyouneedtoknow.com

http://www.infiniteexposure.net

http://www.johnsmith-book.com

http://www.logikalblog.com

http://www.interestingauthors.com/blog

http://lesedi.us/

http://onedollarcontentstore.com
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML vs Electron

[ekke]

Am 06.08.18 um 23:46 schrieb Sylvain Pointeau:
> I fully agree with you. I am fully convinced by Qt, I wanted to go
> with Qt, but the price was too high.
> On the website, it is not said anywhere the price for a startup.

yes - it's something "hidden" - here's the original Qt Blog about
startup license:

http://blog.qt.io/blog/2016/03/08/qt-start-ups-awesome/

current prices are 99 $ / Month or 79 $ if payed per year

On this page https://www1.qt.io/start-up-plan/ hit "Apply Now"

Fill it out, explain your situation and submit

Then you'll get an answer by sales if you fit into the program

> I understood it gave only the right to develop until the go live (like
> an extended demo version).
has nothing to do with "go live" - is valid as long as you are a small
company / indiependent dev
... from the website:

/"What’s the catch? No catch and no strings attached. The extended
evaluation period contains all the same technical features as our
commercial licenses do. /

//

/The extended evaluation period is available for companies with an
annual revenue of less than $100.000"/


try it out - perhaps it will help you to grow with Qt

and: as Maurice wrote: there are NO runtime-royalties for mobile
Application Development

ekke

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

Re: [Interest] QML vs Electron

[Tomasz Siekierda]

> Especially the ones for cross compiling to Raspberry Pi which don't tell
you they used a 32-bit host system to hide all of the errors. That was
great fun.

Erm, what? Qt cross-compiles for Raspberry just fine from a 64 bit host.

On Tue, 7 Aug 2018 at 07:41, Maurice Kalinowski 
wrote:

> I would like to ask to you stop spreading this misinformed and misleading
> content.
>
>
>
> There are two commercial products for Qt, Qt for Application Development
> and Qt for Device Creation. Creating a mobile or desktop app (Qt AD) does _
> *not*_ ask for runtimes for royalties.
>
>
>
> If you have any further question, please get in touch with your sales
> representative directly and ask for details and/or an offer.
>
>
>
> BR,
>
> Maurice
>
>
>
>
>
>
>
> *From:* Interest 
> *On Behalf Of *Roland Hughes
> *Sent:* Tuesday, August 7, 2018 12:58 AM
> *To:* interest@qt-project.org
> *Subject:* Re: [Interest] QML vs Electron
>
>
>
>
>
>
>
> On 08/06/2018 05:36 PM, ekke wrote:
>
> this is frustrating: knowing that Qt is great for mobile apps, but
>
> there's a license cost barriere
>
> Don't forget about the royalties when you start offering things for sale.
>
> --
>
> Roland Hughes, President
>
> Logikal Solutions
>
> (630)-205-1593
>
>
>
> http://www.theminimumyouneedtoknow.com
>
> http://www.infiniteexposure.net
>
> http://www.johnsmith-book.com
>
> http://www.logikalblog.com
>
> http://www.interestingauthors.com/blog
>
> http://lesedi.us/
>
> http://onedollarcontentstore.com
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML vs Electron

[Vlad Stelmahovsky]

It seems Qt suffers from misunderstanding/misinformation and this is pure
Qt Company's fault
And yes, 100$/mo a bit too expensive for startupers, something like
25-30$/mo sounds more reasonable
Also, it would be nice to get clear FAQ what developers can and what they
cannot do under LGPL license with Qt

br,
Vlad

On Tue, Aug 7, 2018 at 10:23 AM ekke  wrote:

> Am 06.08.18 um 23:46 schrieb Sylvain Pointeau:
>
> I fully agree with you. I am fully convinced by Qt, I wanted to go with
> Qt, but the price was too high.
> On the website, it is not said anywhere the price for a startup.
>
> yes - it's something "hidden" - here's the original Qt Blog about startup
> license:
>
> http://blog.qt.io/blog/2016/03/08/qt-start-ups-awesome/
>
> current prices are 99 $ / Month or 79 $ if payed per year
>
> On this page https://www1.qt.io/start-up-plan/ hit "Apply Now"
>
> Fill it out, explain your situation and submit
>
> Then you'll get an answer by sales if you fit into the program
>
> I understood it gave only the right to develop until the go live (like an
> extended demo version).
>
> has nothing to do with "go live" - is valid as long as you are a small
> company / indiependent dev
> ... from the website:
>
> *"What’s the catch? No catch and no strings attached. The extended
> evaluation period contains all the same technical features as our
> commercial licenses do. *
>
> *The extended evaluation period is available for companies with an annual
> revenue of less than $100.000"*
>
>
> try it out - perhaps it will help you to grow with Qt
>
> and: as Maurice wrote: there are NO runtime-royalties for mobile
> Application Development
>
> ekke
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>


-- 
Best regards,
Vlad
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML vs Electron

[Christoph Keller]

Well in 2015 there was the Independent Dev License for $25/month which 
disappeared and was replaced with the $350/month one and last year they 
changed prices over night to $460/month (all prices seen from a 
mobile-only dev perspective). That's about $2000 more per year for a 
single developer! Also the perpetual license disappeared, so you're now 
forced to the subscription model. The startup license prices were 
removed from the website, also you have to get a coupon from the sales 
team now to get it. If you've got a Qt license in your business plan, 
you're screwed since there's no way to estimate the costs for new 
developers.


Not only that, they also changed 2.9 in the FAQ in January 2017: If you 
distribute your mobile app with a commercial license to an app store, it 
seems you have to remove it from the moment you stop paying your Qt 
license. Before, this was allowed 
(https://web.archive.org/web/20170118212739/https://www1.qt.io/faq/). 
The FAQ is not really clear about whether "distribute" means in fact 
"upload to the app store" or "distribute through the app store".


From my point of view the 2.9 line silently forces you to switch to 
LGPL or another framework especially if you're not using Qt for all of 
your projects, so smaller agencies and independent developers are out. 
Prices can change randomly and you're forced to pay or refactor years of 
work.


I'm a Qt fan and user for over 10 years now but I really think they're 
never gaining traction on mobile with this licensing model. It's 
absolutely worth $99/month but not $460/month or more in the future 
(still speaking about mobile-only here) :(



On 06.08.18 15:44, ekke wrote:

Am 04.08.18 um 19:23 schrieb Sylvain Pointeau:
On Tue, 20 Feb 2018 at 12:58, René Hansen > wrote:



Taxing big corporate use, while exempting smalltime adoption,
even commercial, might be the way to go. This is just speculation
on my part though, I have no idea how a licensing scheme like
this would work in practice.


This was exactly my issue. I have an idea for a phone / tablet app 
and I really wanted to go with Qt but ~500 euros per month was a no 
go (for all people involved)


I'm doing all my mobile Apps (Android, iOS) with Qt (QtQuickControls2) 
and really like Qt. (compared with Flutter, ReactNative, Xamarin, etc)


As a single developer (Freelancer) I'm using the Start-Up License 
(99$/Month)


the info about the startup license is something hidden on the web 
sites: https://www1.qt.io/start-up-plan/



presenting my apps to other devs at conferences or so there's always a 
"wow" effect, because of UI/UX and performance of even very complex apps.


the problem is the license.

developers looking at Qt site always think they must pay ~500 EUR as 
independent devs which is too much compared with other frameworks


even the Startup License isn't easy to do


this is frustrating: knowing that Qt is great for mobile apps, but 
there's a license cost barriere



I'm really waiting for a 30 EUR or so Indiependent Dev License.

I know from discussions that in the past there already was such kind 
of license with less success.


But in the past there were no QtQuickControls2 and HighDPI support. 
(Both was the reason why I started developing mobile Apps with Qt)



--

ekke (ekkehard gentz)

independent software architect
international development native mobile business apps
Qt Mobile (Android, iOS)
workshops - trainings - bootcamps

*Qt Champion
BlackBerry Elite Developer
*



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


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

Re: [Interest] QML vs Electron

[Jean-Michaël Celerier]

LGPL has not been a problem on app stores for a long time. There are plenty
of GPLv3 apps on the ios store, such as Dash for instance:
https://itunes.apple.com/us/app/dash-offline-api-docs/id1239167694?mt=8&pt=11l8808&ign-mpt=uo%3D4

See also https://opensource.stackexchange.com/a/6495/4349

Best,

---
Jean-Michaël Celerier
http://www.jcelerier.name


On Tue, Aug 7, 2018 at 1:09 PM Vlad Stelmahovsky 
wrote:

> It seems Qt suffers from misunderstanding/misinformation and this is pure
> Qt Company's fault
> And yes, 100$/mo a bit too expensive for startupers, something like
> 25-30$/mo sounds more reasonable
> Also, it would be nice to get clear FAQ what developers can and what they
> cannot do under LGPL license with Qt
>
> br,
> Vlad
>
> On Tue, Aug 7, 2018 at 10:23 AM ekke  wrote:
>
>> Am 06.08.18 um 23:46 schrieb Sylvain Pointeau:
>>
>> I fully agree with you. I am fully convinced by Qt, I wanted to go with
>> Qt, but the price was too high.
>> On the website, it is not said anywhere the price for a startup.
>>
>> yes - it's something "hidden" - here's the original Qt Blog about startup
>> license:
>>
>> http://blog.qt.io/blog/2016/03/08/qt-start-ups-awesome/
>>
>> current prices are 99 $ / Month or 79 $ if payed per year
>>
>> On this page https://www1.qt.io/start-up-plan/ hit "Apply Now"
>>
>> Fill it out, explain your situation and submit
>>
>> Then you'll get an answer by sales if you fit into the program
>>
>> I understood it gave only the right to develop until the go live (like an
>> extended demo version).
>>
>> has nothing to do with "go live" - is valid as long as you are a small
>> company / indiependent dev
>> ... from the website:
>>
>> *"What’s the catch? No catch and no strings attached. The extended
>> evaluation period contains all the same technical features as our
>> commercial licenses do. *
>>
>> *The extended evaluation period is available for companies with an annual
>> revenue of less than $100.000"*
>>
>>
>> try it out - perhaps it will help you to grow with Qt
>>
>> and: as Maurice wrote: there are NO runtime-royalties for mobile
>> Application Development
>>
>> ekke
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>>
>
>
> --
> Best regards,
> Vlad
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML vs Electron

[Nikos Chantziaras]

On 07/08/18 01:19, Sylvain Pointeau wrote:
On Mon, Aug 6, 2018 at 11:56 PM Giuseppe D'Angelo > wrote:

[...]
Out of curiosity, what prevented you from going with LGPL Qt?


On desktop it is clear but on mobile, there was no clear statement if we 
have the rights or not.

Seems like LGPL is not friendly with the various stores.


It's fine on Android, since Qt for Android uses dynamic linking by 
default. On iOS you only get static linking right now, and I'm not sure 
if you can build Qt for iOS yourself and configure it for dynamic 
linking, and whether Apple now allows dynamically linked iOS apps. The 
solution of making re-linkable object files available for iOS to comply 
with the LGPL is not suitable for everyone. And it's a useless solution 
anyway, unless people jailbreak their Apple devices so that they can 
sideload apps. Even though it satisfies LGPL requirements on your part, 
it doesn't on Apple's part. So you end up in a situation where people 
can claim that Apple does not have the right to distribute your 
application. And that would still apply even if you used dynamic linking.


But in any case, Android seems fine when using LGPL libraries, since a) 
Qt is linked to dynamically, and b) Android officially supports sideloading.


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

Re: [Interest] QML vs Electron

[alexander golks]

Am Tue, 7 Aug 2018 16:00:22 +0300
schrieb Nikos Chantziaras :

> On 07/08/18 01:19, Sylvain Pointeau wrote:
> > On Mon, Aug 6, 2018 at 11:56 PM Giuseppe D'Angelo  > > wrote:  
> >> [...]
> >> Out of curiosity, what prevented you from going with LGPL Qt?  
> > 
> > On desktop it is clear but on mobile, there was no clear statement if we 
> > have the rights or not.
> > Seems like LGPL is not friendly with the various stores.  
> 
> It's fine on Android, since Qt for Android uses dynamic linking by 
> default. On iOS you only get static linking right now, and I'm not sure 
> if you can build Qt for iOS yourself and configure it for dynamic 
> linking, and whether Apple now allows dynamically linked iOS apps. The 
> solution of making re-linkable object files available for iOS to comply 
> with the LGPL is not suitable for everyone. And it's a useless solution 
> anyway, unless people jailbreak their Apple devices so that they can 
> sideload apps. Even though it satisfies LGPL requirements on your part, 
> it doesn't on Apple's part. So you end up in a situation where people 
> can claim that Apple does not have the right to distribute your 
> application. And that would still apply even if you used dynamic linking.
> 
> But in any case, Android seems fine when using LGPL libraries, since a) 
> Qt is linked to dynamically, and b) Android officially supports sideloading.

One could also just deliver the closed source object files for relinking.
this satisfies LGPL, too, doesn't it?

-- 
/*
 *  printk(KERN_ERR "happy meal: Receiver BigMac ATTACK!");
 *linux-2.6.19/drivers/net/sunhme.c
 */


pgp2SdttDmwl1.pgp
Description: Digitale Signatur von OpenPGP
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML vs Electron

[Nikos Chantziaras]

On 07/08/18 16:04, alexander golks wrote:

Am Tue, 7 Aug 2018 16:00:22 +0300
schrieb Nikos Chantziaras :


On 07/08/18 01:19, Sylvain Pointeau wrote:

On Mon, Aug 6, 2018 at 11:56 PM Giuseppe D'Angelo mailto:dange...@gmail.com>> wrote:

[...]
Out of curiosity, what prevented you from going with LGPL Qt?


On desktop it is clear but on mobile, there was no clear statement if we
have the rights or not.
Seems like LGPL is not friendly with the various stores.


It's fine on Android, since Qt for Android uses dynamic linking by
default. On iOS you only get static linking right now, and I'm not sure
if you can build Qt for iOS yourself and configure it for dynamic
linking, and whether Apple now allows dynamically linked iOS apps. The
solution of making re-linkable object files available for iOS to comply
with the LGPL is not suitable for everyone. And it's a useless solution
anyway, unless people jailbreak their Apple devices so that they can
sideload apps. Even though it satisfies LGPL requirements on your part,
it doesn't on Apple's part. So you end up in a situation where people
can claim that Apple does not have the right to distribute your
application. And that would still apply even if you used dynamic linking.

But in any case, Android seems fine when using LGPL libraries, since a)
Qt is linked to dynamically, and b) Android officially supports sideloading.


One could also just deliver the closed source object files for relinking.
this satisfies LGPL, too, doesn't it?


It was already addressed in my post. It seems to satisfy LGPL 
requirements on your part, but not on Apple's part (because they don't 
allow the re-linked application to run due to their DRM.)


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

Re: [Interest] QML vs Electron

[Mike Krus via Interest]

> On 7 Aug 2018, at 14:31, Nikos Chantziaras  wrote:
> 
> On 07/08/18 16:04, alexander golks wrote:
>> Am Tue, 7 Aug 2018 16:00:22 +0300
>> schrieb Nikos Chantziaras :
>>> On 07/08/18 01:19, Sylvain Pointeau wrote:
 On Mon, Aug 6, 2018 at 11:56 PM Giuseppe D'Angelo >>> > wrote:
> [...]
> Out of curiosity, what prevented you from going with LGPL Qt?
 
 On desktop it is clear but on mobile, there was no clear statement if we
 have the rights or not.
 Seems like LGPL is not friendly with the various stores.
>>> 
>>> It's fine on Android, since Qt for Android uses dynamic linking by
>>> default. On iOS you only get static linking right now, and I'm not sure
>>> if you can build Qt for iOS yourself and configure it for dynamic
>>> linking, and whether Apple now allows dynamically linked iOS apps. The
>>> solution of making re-linkable object files available for iOS to comply
>>> with the LGPL is not suitable for everyone. And it's a useless solution
>>> anyway, unless people jailbreak their Apple devices so that they can
>>> sideload apps. Even though it satisfies LGPL requirements on your part,
>>> it doesn't on Apple's part. So you end up in a situation where people
>>> can claim that Apple does not have the right to distribute your
>>> application. And that would still apply even if you used dynamic linking.
>>> 
>>> But in any case, Android seems fine when using LGPL libraries, since a)
>>> Qt is linked to dynamically, and b) Android officially supports sideloading.
>> One could also just deliver the closed source object files for relinking.
>> this satisfies LGPL, too, doesn't it?
> 
> It was already addressed in my post. It seems to satisfy LGPL requirements on 
> your part, but not on Apple's part (because they don't allow the re-linked 
> application to run due to their DRM.)
given all the appropriate project setup and compiled object code (.o, .a, even 
shared lib files), a user signed up to the free Apple Developer should in 
theory be able to link another version of Qt into a final executable, codesign 
it and run it on his device. Would be a real pain to setup and maintain though.

> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

--
Mike Krus | mike.k...@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company
Tel: UK Office +44 1625 809908   Mobile +44 7833 491941
KDAB - The Qt Experts, C++, OpenGL Experts



smime.p7s
Description: S/MIME cryptographic signature
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML vs Electron

[alexander golks]

Am Tue, 7 Aug 2018 14:52:42 +0100
schrieb Mike Krus via Interest :

> > On 7 Aug 2018, at 14:31, Nikos Chantziaras  wrote:
> > 
> > On 07/08/18 16:04, alexander golks wrote:  
> >> Am Tue, 7 Aug 2018 16:00:22 +0300
> >> schrieb Nikos Chantziaras :  
> >>> On 07/08/18 01:19, Sylvain Pointeau wrote:  
>  On Mon, Aug 6, 2018 at 11:56 PM Giuseppe D'Angelo   > wrote:  
> > [...]
> > Out of curiosity, what prevented you from going with LGPL Qt?  
>  
>  On desktop it is clear but on mobile, there was no clear statement if we
>  have the rights or not.
>  Seems like LGPL is not friendly with the various stores.  
> >>> 
> >>> It's fine on Android, since Qt for Android uses dynamic linking by
> >>> default. On iOS you only get static linking right now, and I'm not sure
> >>> if you can build Qt for iOS yourself and configure it for dynamic
> >>> linking, and whether Apple now allows dynamically linked iOS apps. The
> >>> solution of making re-linkable object files available for iOS to comply
> >>> with the LGPL is not suitable for everyone. And it's a useless solution
> >>> anyway, unless people jailbreak their Apple devices so that they can
> >>> sideload apps. Even though it satisfies LGPL requirements on your part,
> >>> it doesn't on Apple's part. So you end up in a situation where people
> >>> can claim that Apple does not have the right to distribute your
> >>> application. And that would still apply even if you used dynamic linking.
> >>> 
> >>> But in any case, Android seems fine when using LGPL libraries, since a)
> >>> Qt is linked to dynamically, and b) Android officially supports 
> >>> sideloading.  
> >> One could also just deliver the closed source object files for relinking.
> >> this satisfies LGPL, too, doesn't it?  
> > 
> > It was already addressed in my post. It seems to satisfy LGPL requirements 
> > on your part, but not on Apple's part (because they don't allow the 
> > re-linked application to run due to their DRM.)  
> given all the appropriate project setup and compiled object code (.o, .a, 
> even shared lib files), a user signed up to the free Apple Developer should 
> in theory be able to link another version of Qt into a final executable, 
> codesign it and run it on his device. Would be a real pain to setup and 
> maintain though.

sorry, didn't want to offend someone, and perhaps i missed more sentences then 
i got, and i surely have no knowledge about apple (tm) things,
so i am listening to learn ;)
i though this whole rant was somehow related to the licensing problems with qt, 
so on this behalf i just wanted to state that one should be able to deliver 
closed source software using lgpl licensed qt.

that said, static linking should be possible, and this is what is needed for 
ios?
or what else is "apple's part"?
what else should i as a mobile ios app developer take care of?


pgpwwixUn_jab.pgp
Description: Digitale Signatur von OpenPGP
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML vs Electron

[Jean-Michaël Celerier]

I have never met anyone until then who read the qt page and had another 
interpretation than the ones provided by Benjamin.


> As a Free Software user you contribute or “pay”

it's not, "you should" or "you can" contribute / pay, it's "you 
contribute". That's imperative.


> That's just a misinterpretation. There's nothing factually wrong with 
the statement.


That's easy to say when the statement is so vague. What does "limited to 
GPL only" even mean ? But remember telling people a lot of time on 
various forums / IRC channels that no, they could entirely develop 
whatever code they wanted to with Qt Creator, and more than once they 
did not believe me because of this sentence. That's money that goes 
right to Microsoft and Jetbrains instead of having potential additional 
future contributors for QtC.


> You should choose the open source licence for open source code and 
you should buy the commercial licence for closed-source.


There's a lot of semantic difference between "the Open Source license is 
for people" (which implies that it isn't /for/ the other category of 
people) and "You should choose the open source licence"


Best,
Jean-Michaël
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML vs Electron

[ekke]

Am 07.08.18 um 15:52 schrieb Mike Krus via Interest:
>> It was already addressed in my post. It seems to satisfy LGPL requirements 
>> on your part, but not on Apple's part (because they don't allow the 
>> re-linked application to run due to their DRM.)
> given all the appropriate project setup and compiled object code (.o, .a, 
> even shared lib files), a user signed up to the free Apple Developer should 
> in theory be able to link another version of Qt into a final executable, 
> codesign it and run it on his device. Would be a real pain to setup and 
> maintain though.
>
yes - this should be possible - found a good description:
https://stackoverflow.com/a/39438539

but not every customer likes to publish the APK or iOS object files
outside the stores ;-)

it's reallly not easy to motivate other mobile app devs to switch over
to Qt with high license fees or complicated rules to satisfy LGPL

having a 25 EUR Independent app developer license would be better ;-)

ekke

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

Re: [Interest] QML vs Electron

[Sylvain Pointeau]

On Tue, 7 Aug 2018 at 17:25, ekke  wrote:

> Am 07.08.18 um 15:52 schrieb Mike Krus via Interest:
>
> It was already addressed in my post. It seems to satisfy LGPL requirements on 
> your part, but not on Apple's part (because they don't allow the re-linked 
> application to run due to their DRM.)
>
> given all the appropriate project setup and compiled object code (.o, .a, 
> even shared lib files), a user signed up to the free Apple Developer should 
> in theory be able to link another version of Qt into a final executable, 
> codesign it and run it on his device. Would be a real pain to setup and 
> maintain though.
>
>
> yes - this should be possible - found a good description:
> https://stackoverflow.com/a/39438539
>
> but not every customer likes to publish the APK or iOS object files
> outside the stores ;-)
>
> it's reallly not easy to motivate other mobile app devs to switch over to
> Qt with high license fees or complicated rules to satisfy LGPL
>
> having a 25 EUR Independent app developer license would be better ;-)
>

100% agree, for startup and independant developer. We don’t even think at
this price and it contributes to the development of Qt.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML vs Electron

[Guenter Schwann via Interest]

On Dienstag, 7. August 2018 15:00:22 CEST Nikos Chantziaras wrote:
> But in any case, Android seems fine when using LGPL libraries, since a)
> Qt is linked to dynamically, and b) Android officially supports sideloading.

Does this cover tivoization (as it's v3 of LGPL) for closed source apps (apk)?
>From the FAQ:
"The user of your application has to be able to re-link your application 
against a different or modified version of the Qt library. ..."

Guenter Schwann
http://www.vikingsoftware.com



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

Re: [Interest] QML vs Electron

[Nikos Chantziaras]

On 08/08/18 08:34, Guenter Schwann via Interest wrote:

On Dienstag, 7. August 2018 15:00:22 CEST Nikos Chantziaras wrote:

But in any case, Android seems fine when using LGPL libraries, since a)
Qt is linked to dynamically, and b) Android officially supports sideloading.


Does this cover tivoization (as it's v3 of LGPL) for closed source apps (apk)?
 From the FAQ:
"The user of your application has to be able to re-link your application
against a different or modified version of the Qt library. ..."


I don't see why not.

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

Re: [Interest] QML vs Electron

[Roland Hughes]

Rather interesting.

People making medical devices which save millions of lives each year 
have to pay royalties on each unit manufactured.


People writing apps which now kill more humans than drunk driving, 
aren't charged royalties.


https://www.bloomberg.com/news/articles/2017-10-17/smartphones-are-killing-americans-but-nobody-s-counting

https://www.thriveglobal.com/stories/15310-smartphones-are-leading-to-more-traffic-deaths-than-the-government-realizes

https://money.cnn.com/2017/03/30/technology/pedestrian-safety-smartphones/index.html

https://nypost.com/2016/06/18/our-cellphones-are-killing-us/

For them you stole a page from a gag commercial 95.5 WMET used to run in 
Chicago. It was for the Chicago School of Cab Driving.


"What's it cost? $25 a week for the rest of your life, you __can't__ get 
even."



It is difficult to keep up with the licensing products since sales never 
says the same thing which is on the Web site __AND__ the licensing 
changes roughly every 15 minutes.



Adding insult to injury is the SEVERE ETHICAL PROBLEM most have with 
taking an OpenSource product, adding just a tiny bit, then demanding 
licenses and royalties.




On 08/07/2018 12:40 AM, Maurice Kalinowski wrote:


I would like to ask to you stop spreading this misinformed and 
misleading content.


There are two commercial products for Qt, Qt for Application 
Development and Qt for Device Creation. Creating a mobile or desktop 
app (Qt AD) does _/not/_ ask for runtimes for royalties.


If you have any further question, please get in touch with your sales 
representative directly and ask for details and/or an offer.


BR,

Maurice

*From:*Interest 
 *On Behalf 
Of *Roland Hughes

*Sent:* Tuesday, August 7, 2018 12:58 AM
*To:* interest@qt-project.org
*Subject:* Re: [Interest] QML vs Electron

On 08/06/2018 05:36 PM, ekke wrote:

this is frustrating: knowing that Qt is great for mobile apps, but

there's a license cost barriere

Don't forget about the royalties when you start offering things for sale.

--
Roland Hughes, President
Logikal Solutions
(630)-205-1593
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us/
http://onedollarcontentstore.com


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us/
http://onedollarcontentstore.com

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

Re: [Interest] QML vs Electron

[Roland Hughes]

Now, perhaps.

The wiki was busted for many years. Complaints in here finally had 
someone from Qt file a bug report. I haven't tested what is on the wiki 
today. What was there previously didn't work at all.



On 08/07/2018 03:31 AM, Tomasz Siekierda wrote:
> Especially the ones for cross compiling to Raspberry Pi which don't 
tell you they used a 32-bit host system to hide all of the errors. 
That was great fun.


Erm, what? Qt cross-compiles for Raspberry just fine from a 64 bit host.

On Tue, 7 Aug 2018 at 07:41, Maurice Kalinowski 
mailto:maurice.kalinow...@qt.io>> wrote:


I would like to ask to you stop spreading this misinformed and
misleading content.

There are two commercial products for Qt, Qt for Application
Development and Qt for Device Creation. Creating a mobile or
desktop app (Qt AD) does _/not/_ ask for runtimes for royalties.

If you have any further question, please get in touch with your
sales representative directly and ask for details and/or an offer.

BR,

Maurice

*From:*Interest
mailto:qt...@qt-project.org>> *On Behalf Of *Roland Hughes
*Sent:* Tuesday, August 7, 2018 12:58 AM
*To:* interest@qt-project.org <mailto:interest@qt-project.org>
    *Subject:* Re: [Interest] QML vs Electron

On 08/06/2018 05:36 PM, ekke wrote:

this is frustrating: knowing that Qt is great for mobile apps, but

there's a license cost barriere

Don't forget about the royalties when you start offering things
for sale.

-- 


Roland Hughes, President

Logikal Solutions

(630)-205-1593

  


http://www.theminimumyouneedtoknow.com

http://www.infiniteexposure.net

http://www.johnsmith-book.com

http://www.logikalblog.com

http://www.interestingauthors.com/blog

http://lesedi.us/

http://onedollarcontentstore.com

___
Interest mailing list
Interest@qt-project.org <mailto:Interest@qt-project.org>
http://lists.qt-project.org/mailman/listinfo/interest



--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us/
http://onedollarcontentstore.com

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

Re: [Interest] QML vs Electron

[Jason H]

> Sent: Wednesday, February 14, 2018 at 8:45 PM
> From: "Bob Hood" 
> To: "Qt Interest" 
> Subject: [Interest] QML vs Electron
>
> I'm starting to see more and more software being written in, or being ported 
> to, Electron[1] (e.g., Skype's latest v8 update now uses Electron).  I know 
> QML is supposed to be Qt's solution to cross-device development, so I'm 
> wondering if anybody here has had opportunity to actually use both, and what 
> insights they might have in terms of comparing QML's declarative design to 
> Electron's HTML5 approach.

I cannot think of a worse programming paradigm. The problem it solves is there 
is a lot of HTML/CSS/JS "talent" out there. That's it. I reject DOM and CSS as 
the best way to do structure and presentation, and JS is a terrible language.

> Full disclosure: I'm a hard-core Qt C++ developer, and I've made no secret of 
> the fact that I'm not crazy about QML.  However, it's getting harder and 
> harder to avoid having to be cross-device in my development, and while I know 
> Qt Widgets can run on mobile devices, but it seems like a heavy weight and 
> somewhat inelegant approach.  Something more designed for the task might be 
> my 
> only/better option.

I don't see how having a web browser render everything isn't the most heavy 
weight approach imaginable.

> On a related note, has anybody done a QML (e)book yet that is focused on its 
> uses in cross-device development?  The last/only one I saw seemed to focus 
> only using QML to create interfaces from scratch, and that just turned me 
> off, 
> coming from the widget-rich environment of Qt desktop.

Widgets are nice, I love them still, but QML is hardware accelerated to the 
core with proper threading. It is unfortunate that QML's UI elements are so 
terrible at actually working and being rendered consistently, as widgets were. 
If we could do widgets in QML, that would be the way to go. The layouts were so 
choice. 

Having done X-Platform mobile in Android Native and Qt 2013-2017, it's 
sometimes just easier to just throw it all away and roll your own. The 
platforms have bog differences, there are no physical back buttons on iPhones, 
so you need UI space to compensate. On the good side, this is easy, on the bad 
side, it's not as simple as widgets were - where everyone had the same input 
hardware. On the good side, it is popular to have your own app UI, and there is 
no real platform standard UI layout like widgets had. I so wish I could throw 
something together like in the old days. But UI designers would not have jobs, 
even though the UIs are far less consistent than old. On the flip side, they 
look a hell of a lot better.

Anyway, you can lament it, but that ship has sailed. 
If you really want to know what I'm thinking, it would be to ditch JS entirely 
and use ChaiScript in QML. 

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

Re: [Interest] QML vs Electron

[Nikos Chantziaras]

They don't really compare. Electron forces you to write the entire 
application in JS. With QML you only have to write the UI in it. The 
rest stays C++.


For desktops, you should be using Widgets anyway though. QML just 
doesn't integrate well. It's made for phones, not desktops. It seems 
like it was developed in a period of time where everybody was out of 
their freaking mind about desktops either dying or all of them becoming 
glorified tablets. But we all saw how well Windows 8.0 was received...


Desktops aren't going anywhere anytime soon. And widgets are the 
*perfect* framework for them. QML is nice for mobile.



On 15/02/18 03:45, Bob Hood wrote:
I'm starting to see more and more software being written in, or being 
ported to, Electron[1] (e.g., Skype's latest v8 update now uses 
Electron).  I know QML is supposed to be Qt's solution to cross-device 
development, so I'm wondering if anybody here has had opportunity to 
actually use both, and what insights they might have in terms of 
comparing QML's declarative design to Electron's HTML5 approach.


Full disclosure: I'm a hard-core Qt C++ developer, and I've made no 
secret of the fact that I'm not crazy about QML.  However, it's getting 
harder and harder to avoid having to be cross-device in my development, 
and while I know Qt Widgets can run on mobile devices, but it seems like 
a heavy weight and somewhat inelegant approach.  Something more designed 
for the task might be my only/better option.


On a related note, has anybody done a QML (e)book yet that is focused on 
its uses in cross-device development?  The last/only one I saw seemed to 
focus only using QML to create interfaces from scratch, and that just 
turned me off, coming from the widget-rich environment of Qt desktop.


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

Re: [Interest] QML vs Electron

[Bob Hood]

On 2/14/2018 8:21 PM, Jason H wrote:



Sent: Wednesday, February 14, 2018 at 8:45 PM
From: "Bob Hood" 
To: "Qt Interest" 
Subject: [Interest] QML vs Electron

I'm starting to see more and more software being written in, or being ported
to, Electron[1] (e.g., Skype's latest v8 update now uses Electron).  I know
QML is supposed to be Qt's solution to cross-device development, so I'm
wondering if anybody here has had opportunity to actually use both, and what
insights they might have in terms of comparing QML's declarative design to
Electron's HTML5 approach.

I cannot think of a worse programming paradigm. The problem it solves is there is a lot 
of HTML/CSS/JS "talent" out there. That's it. I reject DOM and CSS as the best 
way to do structure and presentation, and JS is a terrible language.


Full disclosure: I'm a hard-core Qt C++ developer, and I've made no secret of
the fact that I'm not crazy about QML.  However, it's getting harder and
harder to avoid having to be cross-device in my development, and while I know
Qt Widgets can run on mobile devices, but it seems like a heavy weight and
somewhat inelegant approach.  Something more designed for the task might be my
only/better option.

I don't see how having a web browser render everything isn't the most heavy 
weight approach imaginable.


On a related note, has anybody done a QML (e)book yet that is focused on its
uses in cross-device development?  The last/only one I saw seemed to focus
only using QML to create interfaces from scratch, and that just turned me off,
coming from the widget-rich environment of Qt desktop.

Widgets are nice, I love them still, but QML is hardware accelerated to the 
core with proper threading. It is unfortunate that QML's UI elements are so 
terrible at actually working and being rendered consistently, as widgets were. 
If we could do widgets in QML, that would be the way to go. The layouts were so 
choice.

Having done X-Platform mobile in Android Native and Qt 2013-2017, it's 
sometimes just easier to just throw it all away and roll your own. The 
platforms have bog differences, there are no physical back buttons on iPhones, 
so you need UI space to compensate. On the good side, this is easy, on the bad 
side, it's not as simple as widgets were - where everyone had the same input 
hardware. On the good side, it is popular to have your own app UI, and there is 
no real platform standard UI layout like widgets had. I so wish I could throw 
something together like in the old days. But UI designers would not have jobs, 
even though the UIs are far less consistent than old. On the flip side, they 
look a hell of a lot better.

Anyway, you can lament it, but that ship has sailed.
If you really want to know what I'm thinking, it would be to ditch JS entirely 
and use ChaiScript in QML.



Thanks for the response, Jason.

If I understand your salient point here, you're advocating the "traditional" 
approach of just maintaining device-specific, not-necessarily-related code 
bases that duplicate the same application functionality?  So, use the 
per-platform accepted coding frameworks -- C# for Android, ObjC for iOS, Qt 
for dekstops, etc. -- and just develop the required expertise in each area?


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

Re: [Interest] QML vs Electron

[Jason H]

> > Anyway, you can lament it, but that ship has sailed.
> > If you really want to know what I'm thinking, it would be to ditch JS 
> > entirely and use ChaiScript in QML.
> 
> 
> Thanks for the response, Jason.
> 
> If I understand your salient point here, you're advocating the "traditional" 
> approach of just maintaining device-specific, not-necessarily-related code 
> bases that duplicate the same application functionality?  So, use the 
> per-platform accepted coding frameworks -- C# for Android, ObjC for iOS, Qt 
> for dekstops, etc. -- and just develop the required expertise in each area?

Not at all. Just the loftiness of Widgets everywhere is unlikely to ever be 
realized. Qt does a lot very well. I've heard lamenting that most people get 
QML wrong - that JS is not to be the application code, just the glue code. 
There certainly is appeal to that, C++ code is the most portable and most 
efficient, but in the end it is easier to just write JS instead of C++, though 
ChaiScript would bridge that gap. JS also bring in async issues and its own 
event loop. 

Anyway, at the end of the day, Qt is a success, and the intricacies of dealing 
with the various platforms is made manageable. I just assume there is no back 
button on the device. Android users never complain.

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

Re: [Interest] QML vs Electron

[Filip Piechocki]

Hi,
recently I was comparing animation performance on i.MX6 DualLite SoC
between QtQuick and HTML. I'm not an expert in HTML so do not know if I did
things best possible way, but I took Servo rendering benchmark (
https://youtu.be/u0hYIRQRiws there is a link in a description) an reduced
number of elements to 60 to get sane results on such weak ARM device I
have. Then I reimplemented this in QtQuick. So the results are 8fps for
HTML and 60fps for QtQuick.

QML/QtQuick is quite easy and sometimes you'll be surprised that you
could've create what you wanted in such few lines of code. But on the other
hand, there are things that are not obvious, Qt docs can be lacking some
details on something and you may come up with something that looks like
hack rather than proper solution.

Last but not least - QML is declarative and it is hard to switch from C++.
I saw qml files filled with walls of imperative JavaScript code, like some
filtering done by copying elements from one ListModel to the other instead
of proper proxy model in c++, state handling by ifs spaghetti and some
properties like "stateOne: 1" etc. I always suggest getting some
professional QtQuick training if that is possible to avoid common mistakes.

BR
Filip

On Feb 15, 2018 5:36 AM, "Jason H"  wrote:

> > > Anyway, you can lament it, but that ship has sailed.
> > > If you really want to know what I'm thinking, it would be to ditch JS
> entirely and use ChaiScript in QML.
> >
> >
> > Thanks for the response, Jason.
> >
> > If I understand your salient point here, you're advocating the
> "traditional"
> > approach of just maintaining device-specific, not-necessarily-related
> code
> > bases that duplicate the same application functionality?  So, use the
> > per-platform accepted coding frameworks -- C# for Android, ObjC for iOS,
> Qt
> > for dekstops, etc. -- and just develop the required expertise in each
> area?
>
> Not at all. Just the loftiness of Widgets everywhere is unlikely to ever
> be realized. Qt does a lot very well. I've heard lamenting that most people
> get QML wrong - that JS is not to be the application code, just the glue
> code. There certainly is appeal to that, C++ code is the most portable and
> most efficient, but in the end it is easier to just write JS instead of
> C++, though ChaiScript would bridge that gap. JS also bring in async issues
> and its own event loop.
>
> Anyway, at the end of the day, Qt is a success, and the intricacies of
> dealing with the various platforms is made manageable. I just assume there
> is no back button on the device. Android users never complain.
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML vs Electron

[Jean-Michaël Celerier]

> They don't really compare. Electron forces you to write the entire
application in JS. With QML you only have to write the UI in it. The rest
stays C++.

As much as I like C++, the company I work at has been doing pure QML apps
and they certainly have been developed faster that the equivalent in C++
would have, with no particular performance problems (but so much bugs
though... landmines and unimplemented features (looking at you QtMultimedia
and fonts!) under every step).

---
Jean-Michaël Celerier
http://www.jcelerier.name

On Thu, Feb 15, 2018 at 4:39 AM, Nikos Chantziaras  wrote:

> They don't really compare. Electron forces you to write the entire
> application in JS. With QML you only have to write the UI in it. The rest
> stays C++.
>
> For desktops, you should be using Widgets anyway though. QML just doesn't
> integrate well. It's made for phones, not desktops. It seems like it was
> developed in a period of time where everybody was out of their freaking
> mind about desktops either dying or all of them becoming glorified tablets.
> But we all saw how well Windows 8.0 was received...
>
> Desktops aren't going anywhere anytime soon. And widgets are the *perfect*
> framework for them. QML is nice for mobile.
>
>
> On 15/02/18 03:45, Bob Hood wrote:
>
>> I'm starting to see more and more software being written in, or being
>> ported to, Electron[1] (e.g., Skype's latest v8 update now uses Electron).
>> I know QML is supposed to be Qt's solution to cross-device development, so
>> I'm wondering if anybody here has had opportunity to actually use both, and
>> what insights they might have in terms of comparing QML's declarative
>> design to Electron's HTML5 approach.
>>
>> Full disclosure: I'm a hard-core Qt C++ developer, and I've made no
>> secret of the fact that I'm not crazy about QML.  However, it's getting
>> harder and harder to avoid having to be cross-device in my development, and
>> while I know Qt Widgets can run on mobile devices, but it seems like a
>> heavy weight and somewhat inelegant approach.  Something more designed for
>> the task might be my only/better option.
>>
>> On a related note, has anybody done a QML (e)book yet that is focused on
>> its uses in cross-device development?  The last/only one I saw seemed to
>> focus only using QML to create interfaces from scratch, and that just
>> turned me off, coming from the widget-rich environment of Qt desktop.
>>
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML vs Electron

[René Hansen]

In my opinion Qt, (as a company), is directly responsible for the mess that
is Electron and todays scape of the app-world. I worked for Nokia back in
2011, when they were trying to build, and miserably failed, the next-gen
phone os platform, entirely as a web-runtime. The switch to a Qt/QtQuick
approach on top of Meego was such an improvement in speed and overall
resource usage. Being able to natively bridge with ease, while still
keeping the door open for Javascript devs. was, and still is the single
most killer combo out there.

As an engineer, being witness to the rise of Electron based apps, has left
me completely baffled so many times. How could Qt have such a major head
start and still fail to position themselves, as the de facto cross platform
development framework. I mean, they even *had* Javascript, fer crying out
loud! I've never been able to come up with a good reason for this. I've
resorted to thinking that, either, A, Qt didn't *want* to be dominant in
that space, and has spent efforts expanding in other markets or B, they've
had one of the worst marketing divisions in modern tech history.

Imo building native apps completely on top of a web-runtime, will *never*
be a good idea. I don't care how much Javascript developers, are a dime a
dozen, it's just plain bad engineering and I weep a salty tear, when I see
something like Atom take a good 6 seconds to launch on my 2015 MacBook Pro,
while eating away 359MB of memory, before even opening the first file. (I'm
not an Atom user, this is just an example)

How can that be acceptable, in, any, way?

I know, QtQuick does ship a web-runtime in order to execute JS, but go and
try to open the "texteditor" example from QtCreator. It flies open even in
Debug mode, and consumes about 24MB on launch. It is an entirely different
beast!

How on earth could Qt drop the ball so hard on this one...

Every single time I have to run an Electron, or
insert-name-of-other-js-based-app, I get that sour grape taste in my mouth,
because it didn't have to come to this. I really do blame Qt.

Oh well, at least laptops with 16GB of ram are easy to come by these days,
and it being wintertime, I guess it's nice that all those wasted CPU cycles
at least help to keep me warm. /end-of-rant


/René

On Thu, 15 Feb 2018 at 07:37 Jean-Michaël Celerier <
jeanmichael.celer...@gmail.com> wrote:

> > They don't really compare. Electron forces you to write the entire
> application in JS. With QML you only have to write the UI in it. The rest
> stays C++.
>
> As much as I like C++, the company I work at has been doing pure QML apps
> and they certainly have been developed faster that the equivalent in C++
> would have, with no particular performance problems (but so much bugs
> though... landmines and unimplemented features (looking at you QtMultimedia
> and fonts!) under every step).
>
> ---
> Jean-Michaël Celerier
> http://www.jcelerier.name
>
> On Thu, Feb 15, 2018 at 4:39 AM, Nikos Chantziaras 
> wrote:
>
>> They don't really compare. Electron forces you to write the entire
>> application in JS. With QML you only have to write the UI in it. The rest
>> stays C++.
>>
>> For desktops, you should be using Widgets anyway though. QML just doesn't
>> integrate well. It's made for phones, not desktops. It seems like it was
>> developed in a period of time where everybody was out of their freaking
>> mind about desktops either dying or all of them becoming glorified tablets.
>> But we all saw how well Windows 8.0 was received...
>>
>> Desktops aren't going anywhere anytime soon. And widgets are the
>> *perfect* framework for them. QML is nice for mobile.
>>
>>
>> On 15/02/18 03:45, Bob Hood wrote:
>>
>>> I'm starting to see more and more software being written in, or being
>>> ported to, Electron[1] (e.g., Skype's latest v8 update now uses Electron).
>>> I know QML is supposed to be Qt's solution to cross-device development, so
>>> I'm wondering if anybody here has had opportunity to actually use both, and
>>> what insights they might have in terms of comparing QML's declarative
>>> design to Electron's HTML5 approach.
>>>
>>> Full disclosure: I'm a hard-core Qt C++ developer, and I've made no
>>> secret of the fact that I'm not crazy about QML.  However, it's getting
>>> harder and harder to avoid having to be cross-device in my development, and
>>> while I know Qt Widgets can run on mobile devices, but it seems like a
>>> heavy weight and somewhat inelegant approach.  Something more designed for
>>> the task might be my only/better option.
>>>
>>> On a related note, has anybody done a QML (e)book yet that is focused on
>>> its uses in cross-device development?  The last/only one I saw seemed to
>>> focus only using QML to create interfaces from scratch, and that just
>>> turned me off, coming from the widget-rich environment of Qt desktop.
>>>
>>
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> http://lists.qt-project.org/mailma

Re: [Interest] QML vs Electron

[Vlad Stelmahovsky]

Obviously its not a responsibility of Qt as a company (but, I suppose, they
can promote Qt even harder). The overall technical level of todays
developers gets lower, unfortunately. Business requires fast solutions and
doesnt care about any foreseeable future. This demand creates
low-skilled-developers proposition: "noone cares about resources today"

On Thu, Feb 15, 2018 at 12:23 PM, René Hansen  wrote:

> In my opinion Qt, (as a company), is directly responsible for the mess
> that is Electron and todays scape of the app-world. I worked for Nokia back
> in 2011, when they were trying to build, and miserably failed, the next-gen
> phone os platform, entirely as a web-runtime. The switch to a Qt/QtQuick
> approach on top of Meego was such an improvement in speed and overall
> resource usage. Being able to natively bridge with ease, while still
> keeping the door open for Javascript devs. was, and still is the single
> most killer combo out there.
>
> As an engineer, being witness to the rise of Electron based apps, has left
> me completely baffled so many times. How could Qt have such a major head
> start and still fail to position themselves, as the de facto cross platform
> development framework. I mean, they even *had* Javascript, fer crying out
> loud! I've never been able to come up with a good reason for this. I've
> resorted to thinking that, either, A, Qt didn't *want* to be dominant in
> that space, and has spent efforts expanding in other markets or B, they've
> had one of the worst marketing divisions in modern tech history.
>
> Imo building native apps completely on top of a web-runtime, will *never*
> be a good idea. I don't care how much Javascript developers, are a dime a
> dozen, it's just plain bad engineering and I weep a salty tear, when I see
> something like Atom take a good 6 seconds to launch on my 2015 MacBook Pro,
> while eating away 359MB of memory, before even opening the first file. (I'm
> not an Atom user, this is just an example)
>
> How can that be acceptable, in, any, way?
>
> I know, QtQuick does ship a web-runtime in order to execute JS, but go and
> try to open the "texteditor" example from QtCreator. It flies open even in
> Debug mode, and consumes about 24MB on launch. It is an entirely different
> beast!
>
> How on earth could Qt drop the ball so hard on this one...
>
> Every single time I have to run an Electron, or
> insert-name-of-other-js-based-app, I get that sour grape taste in my
> mouth, because it didn't have to come to this. I really do blame Qt.
>
> Oh well, at least laptops with 16GB of ram are easy to come by these days,
> and it being wintertime, I guess it's nice that all those wasted CPU cycles
> at least help to keep me warm. /end-of-rant
>
>
> /René
>
> On Thu, 15 Feb 2018 at 07:37 Jean-Michaël Celerier <
> jeanmichael.celer...@gmail.com> wrote:
>
>> > They don't really compare. Electron forces you to write the entire
>> application in JS. With QML you only have to write the UI in it. The rest
>> stays C++.
>>
>> As much as I like C++, the company I work at has been doing pure QML apps
>> and they certainly have been developed faster that the equivalent in C++
>> would have, with no particular performance problems (but so much bugs
>> though... landmines and unimplemented features (looking at you QtMultimedia
>> and fonts!) under every step).
>>
>> ---
>> Jean-Michaël Celerier
>> http://www.jcelerier.name
>>
>> On Thu, Feb 15, 2018 at 4:39 AM, Nikos Chantziaras 
>> wrote:
>>
>>> They don't really compare. Electron forces you to write the entire
>>> application in JS. With QML you only have to write the UI in it. The rest
>>> stays C++.
>>>
>>> For desktops, you should be using Widgets anyway though. QML just
>>> doesn't integrate well. It's made for phones, not desktops. It seems like
>>> it was developed in a period of time where everybody was out of their
>>> freaking mind about desktops either dying or all of them becoming glorified
>>> tablets. But we all saw how well Windows 8.0 was received...
>>>
>>> Desktops aren't going anywhere anytime soon. And widgets are the
>>> *perfect* framework for them. QML is nice for mobile.
>>>
>>>
>>> On 15/02/18 03:45, Bob Hood wrote:
>>>
 I'm starting to see more and more software being written in, or being
 ported to, Electron[1] (e.g., Skype's latest v8 update now uses Electron).
 I know QML is supposed to be Qt's solution to cross-device development, so
 I'm wondering if anybody here has had opportunity to actually use both, and
 what insights they might have in terms of comparing QML's declarative
 design to Electron's HTML5 approach.

 Full disclosure: I'm a hard-core Qt C++ developer, and I've made no
 secret of the fact that I'm not crazy about QML.  However, it's getting
 harder and harder to avoid having to be cross-device in my development, and
 while I know Qt Widgets can run on mobile devices, but it seems like a
 heavy weight and somewhat inelegant

Re: [Interest] QML vs Electron

[Shawn Rutledge]

> On 15 Feb 2018, at 12:23, René Hansen  wrote:
> 
> In my opinion Qt, (as a company), is directly responsible for the mess that 
> is Electron and todays scape of the app-world. I worked for Nokia back in 
> 2011, when they were trying to build, and miserably failed, the next-gen 
> phone os platform, entirely as a web-runtime. The switch to a Qt/QtQuick 
> approach on top of Meego was such an improvement in speed and overall 
> resource usage. Being able to natively bridge with ease, while still keeping 
> the door open for Javascript devs. was, and still is the single most killer 
> combo out there.

That phone can still be built, and it’s what I want too.  Ubuntu’s version 
looked promising until they dropped it.  Jolla did their version.  (Now if only 
they could ship their tablet, and refresh the phone hardware, and sell lots of 
them.)  Next puri.sm is up to bat.  Everyone is finding it hard to compete with 
the duopoly though, so far.

> As an engineer, being witness to the rise of Electron based apps, has left me 
> completely baffled so many times. How could Qt have such a major head start 
> and still fail to position themselves, as the de facto cross platform 
> development framework. I mean, they even *had* Javascript, fer crying out 
> loud! I've never been able to come up with a good reason for this. I've 
> resorted to thinking that, either, A, Qt didn't *want* to be dominant in that 
> space, and has spent efforts expanding in other markets or B, they've had one 
> of the worst marketing divisions in modern tech history.

OK, from your perspective are there a few small, achievable features we are 
still missing?  Or mostly just marketing focus?

> Imo building native apps completely on top of a web-runtime, will *never* be 
> a good idea. I don't care how much Javascript developers, are a dime a dozen, 
> it's just plain bad engineering and I weep a salty tear, when I see something 
> like Atom take a good 6 seconds to launch on my 2015 MacBook Pro, while 
> eating away 359MB of memory, before even opening the first file. (I'm not an 
> Atom user, this is just an example)
> 
> How can that be acceptable, in, any, way?

IMO it isn’t acceptable, and so far it’s still possible to pretend those apps 
don’t exist.  I hope that continues.

> I know, QtQuick does ship a web-runtime in order to execute JS, but go and 
> try to open the "texteditor" example from QtCreator. It flies open even in 
> Debug mode, and consumes about 24MB on launch. It is an entirely different 
> beast!
> 
> How on earth could Qt drop the ball so hard on this one…

OK so maybe you are kindof focused on text editors or apps that contain editors 
along with other stuff?

I think maybe a fancier editor (like Creator’s) should be available as a 
reusable component: as easy as importing it and using it in any QML app.  But 
management probably doesn’t expect us to make a lot more money by getting us 
ready for the 1980’s like that (even though text editing is still just as 
relevant as it was then).

> Every single time I have to run an Electron, or 
> insert-name-of-other-js-based-app, I get that sour grape taste in my mouth, 
> because it didn't have to come to this. I really do blame Qt.

Well the idea that the browser could be used to build applications goes way 
back… Active Desktop is about the earliest attempt I can remember.  I think the 
web needs re-architecting too, so having one efficient platform for 
applications regardless whether they are online or locally hosted is not 
impossible… but we’re too dependent on the existing web.  Incremental 
improvements are easier, but won't make it more elegant as long as every layer 
must remain, for backwards compatibility.  As long as the current web 
architecture continues, the temptation to make apps portable via browser-based 
UIs will continue.

You could also blame Java for not becoming the eternal universal platform.  In 
one way, that game was over way before Qt Quick got started.  And yet it lives 
on in Android, despite taking so long to get there, and no longer being “cool” 
by then.

(disclaimer: opinions are my own)

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

Re: [Interest] QML vs Electron

[Jason H]

[opinionated rant warning, trigger words possible]

It's not Qt's fault in any way. I was there when the internet arose,  was there at Qt 2, I saw attack ships on fire off the shoulder of Orion... The siutation has come about because the confluence and timing of several factors:

0. Multiple platforms

1. HTML, JS, CSS as the web platform (herein the 'web')

The web was incrementally by people who had no idea what they were building. That is not to blame them for incompetence, but they had no idea what they were really building up to. Considering all the resources were not local, and could not be trusted, I think they got a lot of the issues, save for a few: XSS, CORS, etc. right. Hindsight is 20/20 so naturally any approach that comes about after you can see the clusterF that was created will have an advanage. The Web though, it had a few key things that were superior to development at the time, it was far faster to make anything, the browser provided reasonable protections. 25 years later, we can clearly see the mistakes...

 

But it's incremental approach is like boiling a frog (urbal legend by the way), but the Web as succedded because it is the most open with lowest barrier to entry. You need a free browser and and text editor and your non-validating HTML wll be displayed somewhat appropriately (insert jab about IE.) and shared with the world population in milliseconds. It's an attractive platform for people who want to get into computers and don't have much experience. No dealing with compilers, etc. 

 

'Uncle Bob' Martin has observed that the number of software devs doubles ever 5 years. (My insight: This is why most code is bad - people have been trying to get software to work at all, not how to have it not fail). It takes time to develop, to have it fail, to see the requirements change and stragagize around that. Most of those people coming in are doing HTML, CSS, JS. With those warts and all. Our environment is not any better, C++ is not attractive syntax, compiler warnings, compiler inconsistencies. It is too discilpined for most wanting to get 'into development'.  This is why it is not Qt's fault.

 

Electron, ReactNative, are just those Web people taking the path of least resistance to a new platform from the one they already know.  If you have a hammer, you're looking for nails that your hammer can handle.

 

Where you may lay a valid complaint at Qt is it's licensing has not been as permissive as the web. It still isn't, (BSD would be best) but with the advent of LGPL option from Nokia, the main objections are no longer substantially relevant. 

 

Your focus on CPU cycles is misplaced. While clocks have flattened out and you might see this as pressure to be more perfomant per clock, cores have continued to increase. My phone as 8 cores. Also, as an edge case the memory bandwidth across mulitple cores can be higher than one core. Therefore, the proper approach is to focus on coding software that scales across cores, not clocks. 

 

I have other complaints about the Web (a lot of undisciplined engineers inventing a new framework every three months because the last one lacked 'a' feature they wanted). (But I guess it's good for their resumes?) None of the Web stuff properly supports inheritence either. (Maybe new JS classes)

 

I have been pushing for a web-ified version of Qt for a while now. I attempted mappng QPainter calls to a HTML5 Canvas (I called it 'Vaudeviile', GNOME called their 'Broadway') and got some promising results. There was some interest in it too, but I never got ti far enough for anyone to buy in. QPA was a new thing back then and undocumented and I couldn't find enough docs on QPA to make it a platform. Now, we have the WebGL plugin tech preview. I've been trying to steer it's development, but I don't have buy-in from Qt engineers.[1][2] There are architectural decisions that are being made today that I would like to change to make it possible and secure, and they are not being considered in scope. Imagine a QML web app server, serving QML apps over WebGL. The tech preview sounds like that, but it's just 1-socket-1-client-1-instance.  If we could properly adapt QML for web, we'd have a completely superior web development paradigm. But I don't know if Qt wants to enter that space? 

 

[1] https://codereview.qt-project.org/#/c/215908/

[2] https://bugreports.qt.io/browse/QTBUG-65241?focusedCommentId=387476&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-387476  <-- the right idea

 

 

 

 


Sent: Thursday, February 15, 2018 at 6:23 AM
From: "René Hansen" 
To: "Jean-Michaël Celerier" 
Cc: interest , "Nikos Chantziaras" 
Subject: Re: [Interest] QML vs Electron


In my opinion Qt, (as a company), is directly responsible for the mess that is Electron an

Re: [Interest] QML vs Electron

[René Hansen]

On Thu, 15 Feb 2018 at 13:40 Shawn Rutledge  wrote:

>
> > On 15 Feb 2018, at 12:23, René Hansen  wrote:
> >
> > In my opinion Qt, (as a company), is directly responsible for the mess
> that is Electron and todays scape of the app-world. I worked for Nokia back
> in 2011, when they were trying to build, and miserably failed, the next-gen
> phone os platform, entirely as a web-runtime. The switch to a Qt/QtQuick
> approach on top of Meego was such an improvement in speed and overall
> resource usage. Being able to natively bridge with ease, while still
> keeping the door open for Javascript devs. was, and still is the single
> most killer combo out there.
>
> That phone can still be built, and it’s what I want too.  Ubuntu’s version
> looked promising until they dropped it.  Jolla did their version.  (Now if
> only they could ship their tablet, and refresh the phone hardware, and sell
> lots of them.)  Next puri.sm is up to bat.  Everyone is finding it hard
> to compete with the duopoly though, so far.
>

It definitely can, but money flows where hype goes and I've yet to see a
big player rising to the task and succeeding at scale. Personally I think
Meego would have been the one, had it not been for the whole Windows Phone
pivot / disaster.


>
> > As an engineer, being witness to the rise of Electron based apps, has
> left me completely baffled so many times. How could Qt have such a major
> head start and still fail to position themselves, as the de facto cross
> platform development framework. I mean, they even *had* Javascript, fer
> crying out loud! I've never been able to come up with a good reason for
> this. I've resorted to thinking that, either, A, Qt didn't *want* to be
> dominant in that space, and has spent efforts expanding in other markets or
> B, they've had one of the worst marketing divisions in modern tech history.
>
> OK, from your perspective are there a few small, achievable features we
> are still missing?  Or mostly just marketing focus?
>

In my opinion it is both. It's about growing the ecosystem through
marketing and outreach, while lowering the bar of entry by building better
primitives and tooling for working with Qt. It is something that the JS
world has been exceedingly good at. Pretty much any obstacle you can run
into as a new JS developer, has been solved by someone else, who most
likely built a tool or framework to help you out. That is only the case,
because that person found it easy to build and share said tool or
framework. And so on and so forth.

Now, as an example, let's pick, (and pick on), NPM.

Fundamentally I think the way that NPM is being used to dump every little
code snippet is such a broken paradigm, that it's not even funny. It is,
however, very hard to overlook how much it has catapulted growth in the
community. I do think, that what is so deeply broken about NPM, is
something that can be solved by guidance and cultivation of a different
mindset though. Other package managers doesn't suffer this problem to the
same degree.

I know it's easy to look at all the completely ridiculous tendencies, that
*do* come from the JS community at large and balk at the whole notion of
using it as a driving example and you wouldn't be completely out of line.
Choosing *what* to learn from is important here. Paramount I'd say, is
their ability to *dumb* things down enough, that anyone, regardless of
skill level can start building applications from day one.

And yes, I do know that qpm exists. Last I checked though, it wasn't
officially endorsed by Qt; the last commit is ~ a year old and it currently
houses 105 packages. NPM has almost 600K... It would go a long way if
developers knew Qt officially supported an initiative like qpm, or
otherwise grandfathered something similar itself.

Another thing is UI toolkits. If you want to build apps with web
technologies today you can have your pick of the litter of Bootstrap,
Semantic UI, ZURB Foundation, etc., etc. and what they all have in common
is that they are incredibly comprehensive and just so easy to use. QtQuick
Controls 2 is a good start, but lacks so many of the ready made components
offered by other toolkits. It is still very much BYOB.

And what about testing? In JS, the landscape is very rich when it comes to
testing frameworks. Jasmine, Mocha, Sinon, Unexpected. The list goes on. In
e.g. Ruby you have something like RSpec, a personal favourite of mine.
Minitest, Cucumber, etc.. All very extensive frameworks with tons of
documentation and examples for every little corner case. There's even very
specific guidelines and best practices attached to most of these
frameworks, which not only works as examples for newcomers, but also as an
educative tool in learning how to write better tests.

Compare that to testing in QtQuick. It is quite frankly close to a zero
value offering by Qt. The entire QtTest module is comprised of three
classes and the reference documentation is this single page;
http://doc.qt.io/qt-5/qtquick-qtquic

Re: [Interest] QML vs Electron

[Morten W. J.]

On Thursday, February 15, 2018 5:10:38 PM CET René Hansen wrote:
>  [if they have had] Qt on the table when choosing a hybrid application 
architecture

This is where I'd say your chain of reasoning breaks.

Few projects I have heard of chose a hybrid application approach. They have a 
webclient and can easily wrap it in 0.5 Gb of electron and "Ta-da! Look, boss. 
A desktop application too!" (1) Since the boss and the developers has has more 
cpu, ram and cores than they know how to spend, the approach is approved.

That is nothing Qt could ever have fixed, expect if they had replaced the HTML 
web 20 years ago with a TrollTechNetwork. And it is in particular not anything 
we should blame neither Nokia or Digia.

Now I wanna go watch snowboard freestyle from Korea. 

Morten

1: I have been a part of a team that did just that a couple of times now.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML vs Electron

[Jason H]

> Sent: Thursday, February 15, 2018 at 11:29 AM
> From: "Morten W. J." 
> To: interest@qt-project.org
> Subject: Re: [Interest] QML vs Electron
>
> On Thursday, February 15, 2018 5:10:38 PM CET René Hansen wrote:
> >  [if they have had] Qt on the table when choosing a hybrid application 
> architecture
> 
> This is where I'd say your chain of reasoning breaks.
> 
> Few projects I have heard of chose a hybrid application approach. They have a 
> webclient and can easily wrap it in 0.5 Gb of electron and "Ta-da! Look, 
> boss. 
> A desktop application too!" (1) Since the boss and the developers has has 
> more 
> cpu, ram and cores than they know how to spend, the approach is approved.

This is as funny as it is sad. Let's take a platform designed around being 
limited so we can safely execute unsigned other people's untrusted code, wrap 
it in an environment with unrestricted user privileges, and deal with all the 
distribution and platform issues therein.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML vs Electron

[Bob Hood]

I want to thank all the respondents for such an interesting discussion.

I think René made some interesting observations regarding the massive 
community support for JS in term of package managers, frameworks and UI 
toolkits.  I think that is something that really presents a high bar of entry 
for QML, that everybody wanting to use it must basically roll their own.  As I 
pointed out, coming from a widget-rich environment to something where I must 
create my own has always kept me from adopting QML as my cross-device 
framework of choice.  I have to focus on writing the interface itself first 
before I can focus on writing my application logic.With widgets, I drop them 
in, and only focus on interface writing if I want to customize them.


Nikos pointed out:


Electron forces you to write the entire application in JS.


That kind of struck me.  All of JavaScript's flaws notwithstanding, how could 
writing your application in a single language for all target devices be a bad 
thing?  Couple that with the massive community and its support (as René 
observed) and I think it is one of the driving factors that are causing 
frameworks like Electron to rise, and QML to languish as an option.


It seems like the Qt Company had a great idea, but once it was realized, they 
expected that it would just pick up steam on its own without any further 
effort on their part.  Certainly, it has its supporters here, but I can't see 
it being a viable alternative to things like Electron unless it is /fostered/ 
by the Qt Company.  As René pointed out:


It's about growing the ecosystem through marketing and outreach, while 
lowering the bar of entry by building better primitives and tooling for 
working with Qt. It is something that the JS world has been exceedingly good at.


I would argue the same thing for "QML" if the Qt Company expects more adoption 
of it.  Otherwise, people are turning to easier-entry alternatives like Electron.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML vs Electron

[Jérôme Godbout]

It would be nice to have a Qml modules manager. I mean, where people could 
contribute to some common independent reusable modules. That would give good 
kick start to generate quickly some Qml application.

How many of us had to create a drawer Item with animation and self resize, an 
overlay box, a Qml Popup that can contain any Items into it...

Many of us made some great Qml Items or some JS controller that can easily 
manipulate dynamic objects that could be reused and help Qml in general (just 
like pip for Python, jQuery plugin listing, ...).


The manager would help to centralize and make the modules known by others 
people and even be improve by community if lucky. Also put the download and 
rating and you get something that could help give Qml more grip.


From: Interest  on behalf 
of Bob Hood 
Sent: Friday, February 16, 2018 9:53:27 AM
To: Qt Interest
Subject: Re: [Interest] QML vs Electron

I want to thank all the respondents for such an interesting discussion.

I think René made some interesting observations regarding the massive community 
support for JS in term of package managers, frameworks and UI toolkits.  I 
think that is something that really presents a high bar of entry for QML, that 
everybody wanting to use it must basically roll their own.  As I pointed out, 
coming from a widget-rich environment to something where I must create my own 
has always kept me from adopting QML as my cross-device framework of choice.  I 
have to focus on writing the interface itself first before I can focus on 
writing my application logic.  With widgets, I drop them in, and only focus on 
interface writing if I want to customize them.

Nikos pointed out:

Electron forces you to write the entire application in JS.

That kind of struck me.  All of JavaScript's flaws notwithstanding, how could 
writing your application in a single language for all target devices be a bad 
thing?  Couple that with the massive community and its support (as René 
observed) and I think it is one of the driving factors that are causing 
frameworks like Electron to rise, and QML to languish as an option.

It seems like the Qt Company had a great idea, but once it was realized, they 
expected that it would just pick up steam on its own without any further effort 
on their part.  Certainly, it has its supporters here, but I can't see it being 
a viable alternative to things like Electron unless it is fostered by the Qt 
Company.  As René pointed out:

It's about growing the ecosystem through marketing and outreach, while lowering 
the bar of entry by building better primitives and tooling for working with Qt. 
It is something that the JS world has been exceedingly good at.

I would argue the same thing for "QML" if the Qt Company expects more adoption 
of it.  Otherwise, people are turning to easier-entry alternatives like 
Electron.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML vs Electron

[Nikos Chantziaras]

On 16/02/18 16:53, Bob Hood wrote:

I want to thank all the respondents for such an interesting discussion.

I think René made some interesting observations regarding the massive 
community support for JS in term of package managers, frameworks and UI 
toolkits.  I think that is something that really presents a high bar of 
entry for QML, that everybody wanting to use it must basically roll 
their own.  As I pointed out, coming from a widget-rich environment to 
something where I must create my own has always kept me from adopting 
QML as my cross-device framework of choice.  I have to focus on writing 
the interface itself first before I can focus on writing my application 
logic.With widgets, I drop them in, and only focus on interface writing 
if I want to customize them.


Nikos pointed out:


Electron forces you to write the entire application in JS.


That kind of struck me.  All of JavaScript's flaws notwithstanding, how 
could writing your application in a single language for all target 
devices be a bad thing?
My application is not the most important thing in my user's life. Many 
developers think the app they ship is *THE* most important app for their 
users. So it's OK if it eats up half a GB of RAM more and burns CPU 
cycles for nothing, or runs like a pig on low-end or old computers, or 
looks alien on their desktop. The app is so important that these 
sacrifices are justified.


The "my app is a precious special little snowflake, so it's OK" attitude 
is what makes Electron popular.


The user's life doesn't revolve around my app. It's just one app out of 
dozens or hundreds they're using. If all applications were using 
Electron, then each one of them would eat up half a GB more RAM, burn 
CPU cycles for nothing and run like pigs on low-end computers, and 
computing would turn into a shit-show quickly.


Also, take off the developer hat and just view yourself as a user. Would 
you like it if *all* your applications were suddenly Electron apps? 
(With everything that entails, including their look&feel.) Great, huh?


And no, you don't get to say "but not all applications are Electon apps, 
just mine is, because it needs to." Your app *is not a precious little 
snowflake*.


So I wouldn't want to ship stuff that I wouldn't use myself, if I can 
help it. The only Electron apps I use are those where I can't find any 
viable alternatives. Surely that's not a good developer-user 
relationship to have, if your users are just waiting for the first 
opportunity to jump ship.


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

Re: [Interest] QML vs Electron

[Yuvraaj Kelkar]

You, I like you.
Value to user comes first!
Preach on brother!

On Fri, Feb 16, 2018 at 9:50 AM, Nikos Chantziaras  wrote:

> On 16/02/18 16:53, Bob Hood wrote:
>
>> I want to thank all the respondents for such an interesting discussion.
>>
>> I think René made some interesting observations regarding the massive
>> community support for JS in term of package managers, frameworks and UI
>> toolkits.  I think that is something that really presents a high bar of
>> entry for QML, that everybody wanting to use it must basically roll their
>> own.  As I pointed out, coming from a widget-rich environment to something
>> where I must create my own has always kept me from adopting QML as my
>> cross-device framework of choice.  I have to focus on writing the interface
>> itself first before I can focus on writing my application logic.With
>> widgets, I drop them in, and only focus on interface writing if I want to
>> customize them.
>>
>> Nikos pointed out:
>>
>> Electron forces you to write the entire application in JS.
>>>
>>
>> That kind of struck me.  All of JavaScript's flaws notwithstanding, how
>> could writing your application in a single language for all target devices
>> be a bad thing?
>>
> My application is not the most important thing in my user's life. Many
> developers think the app they ship is *THE* most important app for their
> users. So it's OK if it eats up half a GB of RAM more and burns CPU cycles
> for nothing, or runs like a pig on low-end or old computers, or looks alien
> on their desktop. The app is so important that these sacrifices are
> justified.
>
> The "my app is a precious special little snowflake, so it's OK" attitude
> is what makes Electron popular.
>
> The user's life doesn't revolve around my app. It's just one app out of
> dozens or hundreds they're using. If all applications were using Electron,
> then each one of them would eat up half a GB more RAM, burn CPU cycles for
> nothing and run like pigs on low-end computers, and computing would turn
> into a shit-show quickly.
>
> Also, take off the developer hat and just view yourself as a user. Would
> you like it if *all* your applications were suddenly Electron apps? (With
> everything that entails, including their look&feel.) Great, huh?
>
> And no, you don't get to say "but not all applications are Electon apps,
> just mine is, because it needs to." Your app *is not a precious little
> snowflake*.
>
> So I wouldn't want to ship stuff that I wouldn't use myself, if I can help
> it. The only Electron apps I use are those where I can't find any viable
> alternatives. Surely that's not a good developer-user relationship to have,
> if your users are just waiting for the first opportunity to jump ship.
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML vs Electron

[Jean-Michaël Celerier]

> It would be nice to have a Qml modules manager.

www.qpm.io



---
Jean-Michaël Celerier
http://www.jcelerier.name

On Fri, Feb 16, 2018 at 4:41 PM, Jérôme Godbout  wrote:

> It would be nice to have a Qml modules manager. I mean, where people could
> contribute to some common independent reusable modules. That would give
> good kick start to generate quickly some Qml application.
>
> How many of us had to create a drawer Item with animation and self resize,
> an overlay box, a Qml Popup that can contain any Items into it...
>
> Many of us made some great Qml Items or some JS controller that can
> easily manipulate dynamic objects that could be reused and help Qml in
> general (just like pip for Python, jQuery plugin listing, ...).
>
>
> The manager would help to centralize and make the modules known by others
> people and even be improve by community if lucky. Also put the download and
> rating and you get something that could help give Qml more grip.
> --
> *From:* Interest  on
> behalf of Bob Hood 
> *Sent:* Friday, February 16, 2018 9:53:27 AM
> *To:* Qt Interest
> *Subject:* Re: [Interest] QML vs Electron
>
> I want to thank all the respondents for such an interesting discussion.
>
> I think René made some interesting observations regarding the massive
> community support for JS in term of package managers, frameworks and UI
> toolkits.  I think that is something that really presents a high bar of
> entry for QML, that everybody wanting to use it must basically roll their
> own.  As I pointed out, coming from a widget-rich environment to something
> where I must create my own has always kept me from adopting QML as my
> cross-device framework of choice.  I have to focus on writing the interface
> itself first before I can focus on writing my application logic.  With
> widgets, I drop them in, and only focus on interface writing if I want to
> customize them.
>
> Nikos pointed out:
>
> Electron forces you to write the entire application in JS.
>
>
> That kind of struck me.  All of JavaScript's flaws notwithstanding, how
> could writing your application in a single language for all target devices
> be a bad thing?  Couple that with the massive community and its support (as
> René observed) and I think it is one of the driving factors that are
> causing frameworks like Electron to rise, and QML to languish as an option.
>
> It seems like the Qt Company had a great idea, but once it was realized,
> they expected that it would just pick up steam on its own without any
> further effort on their part.  Certainly, it has its supporters here, but I
> can't see it being a viable alternative to things like Electron unless it
> is *fostered* by the Qt Company.  As René pointed out:
>
> It's about growing the ecosystem through marketing and outreach, while
> lowering the bar of entry by building better primitives and tooling for
> working with Qt. It is something that the JS world has been exceedingly
> good at.
>
>
> I would argue the same thing for "QML" if the Qt Company expects more
> adoption of it.  Otherwise, people are turning to easier-entry
> alternatives like Electron.
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML vs Electron

[Benjamin TERRIER]

Hello everyone,

May I raise the subject of licensing when it comes to comparing QML vs
Electron popularity.

Electron and other javascript technologies (node, jquery, etc.) are
licensed under permissive (no copyleft) open source licenses like MIT.

Regarding Qt, even the most permissive license (LGPLv3) comes with a
lot of constraints.
Also having 3 license options (GPL, LGPL and commercial) can be a bit confusing.

We could also talk about the "lies" of The Qt Company about the
licensing options.
A few examples from the current https://www.qt.io/download:

> Open source usage of Qt is free as in “free speech”. As a Free Software user 
> you contribute or “pay” to our open source project by making your code 
> available to others – ensuring the end-users’ rights.

This would clearly make everyone think that if they use Qt under LGPL
they cannot develop a closed source software.

Also in the same page qmake, Qt Creator and Qt Designer are listed as
"limited to GPL only".
This make people think they cannot use any Qt tools if they use Qt
under LGPL license.

I have also heard The Qt Company employees, while giving a speech
about "choosing the right" license, say that
the Open Source license is for people who want to share their code...

I do understand that The Qt Company is doing most of the work on Qt
and they need money, so they need to sell licenses.
But I do not understand this urge to be dishonest. I do feel that they
want to scare new developers and force them to buy a license.
I also have the feeling, that since all Qt websites are under qt.io,
it is harder and harder to find clear information about Qt Open Source
nature.

How can we expect new developers to go for Qt and QML, when they have
to face (L)GPL vs MIT license issues ?
If they don't dig, they will meet all the communication of The Qt
Company explaining that the NEED to buy a license.
If they dig deeper, they will start to find mainly "ask your lawyer"
type of answers.
And so they will not buy a license, they will not ask their lawyer.
They will save thousands of euros on the license price or lawyer fees,
they will
save weeks of waiting for the lawyer response. They will just go with
the MIT license option and use Electron, NodeJS and other JS toys.

Regards,

Benjamin

PS: I am not saying that The Qt Company is malicious. The proof is
that on other parts of the qt.io one can find clear and unbiased info
about LGPL/GPL,
but in general the info seem a bit too much biased toward selling
commercial licenses.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML vs Electron

[Thiago Macieira]

On Monday, 19 February 2018 03:26:16 PST Benjamin TERRIER wrote:
> > Open source usage of Qt is free as in “free speech”. As a Free Software
> > user you contribute or “pay” to our open source project by making your
> > code available to others – ensuring the end-users’ rights.
> This would clearly make everyone think that if they use Qt under LGPL
> they cannot develop a closed source software.

This is how you "pay". But you don't have to do it in the first place, it's 
free.

The only thing weird here is "ensuring the end-users' rights".

> Also in the same page qmake, Qt Creator and Qt Designer are listed as
> "limited to GPL only".
> This make people think they cannot use any Qt tools if they use Qt
> under LGPL license.

That's just a misinterpretation. There's nothing factually wrong with the 
statement.

> I have also heard The Qt Company employees, while giving a speech
> about "choosing the right" license, say that
> the Open Source license is for people who want to share their code...

Nothing wrong with that. I actually fully support it. You should choose the 
open source licence for open source code and you should buy the commercial 
licence for closed-source.

But "should" is not the same as "is required to".

> I do understand that The Qt Company is doing most of the work on Qt
> and they need money, so they need to sell licenses.
> But I do not understand this urge to be dishonest. I do feel that they

Nothing you pointed out is dishonest. It's factually correct and suggests that 
you should pay for your use of Qt in some way. The effort of hundreds of 
people does not come cheap. You really want your frameworks to continue to 
exist, which means this needs to be win-win.

One way of doing that is by contributing to the Qt Project. Another is buying 
licences and support. Another is hiring consulting companies that do invest in 
Qt. Finally, you can also contribute by making your source code open so others 
can see it.

> want to scare new developers and force them to buy a license.
> I also have the feeling, that since all Qt websites are under qt.io,
> it is harder and harder to find clear information about Qt Open Source
> nature.

That is true.

> How can we expect new developers to go for Qt and QML, when they have
> to face (L)GPL vs MIT license issues ?

Because of the quality of the code and the results.

> If they don't dig, they will meet all the communication of The Qt
> Company explaining that the NEED to buy a license.
> If they dig deeper, they will start to find mainly "ask your lawyer"
> type of answers.
> And so they will not buy a license, they will not ask their lawyer.
> They will save thousands of euros on the license price or lawyer fees,
> they will
> save weeks of waiting for the lawyer response. They will just go with
> the MIT license option and use Electron, NodeJS and other JS toys.

True.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



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

Re: [Interest] QML vs Electron

[Benjamin TERRIER]

2018-02-19 18:52 GMT+01:00 Thiago Macieira :
> On Monday, 19 February 2018 03:26:16 PST Benjamin TERRIER wrote:
>> > Open source usage of Qt is free as in “free speech”. As a Free Software
>> > user you contribute or “pay” to our open source project by making your
>> > code available to others – ensuring the end-users’ rights.
>> This would clearly make everyone think that if they use Qt under LGPL
>> they cannot develop a closed source software.
>
> This is how you "pay". But you don't have to do it in the first place, it's
> free.
>
> The only thing weird here is "ensuring the end-users' rights".

Maybe I should have quoted the text just above: "An obligation to
share your Qt software code"
I'd like to see how many new comers will understand this as "an
obligation to share the modifications you have done to Qt"
vs "an obligation to share your own code that uses Qt".


>> Also in the same page qmake, Qt Creator and Qt Designer are listed as
>> "limited to GPL only".
>> This make people think they cannot use any Qt tools if they use Qt
>> under LGPL license.
>
> That's just a misinterpretation. There's nothing factually wrong with the
> statement.

Agreed.
But how many people will understand this as "the tools code itself is
under GPL" vs "you cannot use the tools at all if you use Qt under
LGPL"?
How relevant is it to show a warning sign about the tools being under
GPL? The same warning sign used to warn about GPL-only Qt modules
furthermore.
I am not sure a lot of Qt-newcomers first ask themselves about
redistributing Qt Creator.


>> I have also heard The Qt Company employees, while giving a speech
>> about "choosing the right" license, say that
>> the Open Source license is for people who want to share their code...
>
> Nothing wrong with that. I actually fully support it. You should choose the
> open source licence for open source code and you should buy the commercial
> licence for closed-source.
>
> But "should" is not the same as "is required to".
>

I agree with the should.
But many companies take it (wrongly) as a requirement (at least that
is what I have experienced so far).
Also the division between "Application Development" and "Device
Creation" and the fact that the Qt Company
only talks about LGPL under "Application Development" misguides people
into thinking you cannot use the LGPL
license to develop embedded software or devices.
That's clearly wrong if you know that the (L)GPL allows you to use the
licensed software for any purpose.
IMHO, it would be more correct to first divide between Open-Source vs
Commercial and then divide the Commercial License
between "Application" vs "Device". But I am starting to nitpick here.

> Nothing you pointed out is dishonest. It's factually correct and suggests that
> you should pay for your use of Qt in some way.

I have to agree that it is factually correct.
However, I keep thinking it is spreading doubt in a way that is
pushing people to buy a license
or get a lawyer.
I might be wrong, but it is my personal feeling that it is done on
purpose -at least to some extent.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML vs Electron

[René Hansen]

dd tinkerer and app maker, that
person might "bring Qt to work" on a future projects within said
organisation.

Taxing big corporate use, while exempting smalltime adoption, even
commercial, might be the way to go. This is just speculation on my part
though, I have no idea how a licensing scheme like this would work in
practice.


>
> Your focus on CPU cycles is misplaced. While clocks have flattened out and
> you might see this as pressure to be more perfomant per clock, cores have
> continued to increase. My phone as 8 cores. Also, as an edge case the
> memory bandwidth across mulitple cores can be higher than one core.
> Therefore, the proper approach is to focus on coding software that scales
> across cores, not clocks.
>
> I have other complaints about the Web (a lot of undisciplined engineers
> inventing a new framework every three months because the last one lacked
> 'a' feature they wanted). (But I guess it's good for their resumes?) None
> of the Web stuff properly supports inheritence either. (Maybe new JS
> classes)
>

Hear hear.


>
> I have been pushing for a web-ified version of Qt for a while now. I
> attempted mappng QPainter calls to a HTML5 Canvas (I called it
> 'Vaudeviile', GNOME called their 'Broadway') and got some promising
> results. There was some interest in it too, but I never got ti far enough
> for anyone to buy in. QPA was a new thing back then and undocumented and I
> couldn't find enough docs on QPA to make it a platform. Now, we have the
> WebGL plugin tech preview. I've been trying to steer it's development, but
> I don't have buy-in from Qt engineers.[1][2] There are architectural
> decisions that are being made today that I would like to change to make it
> possible and secure, and they are not being considered in scope. Imagine a
> QML web app server, serving QML apps over WebGL. The tech preview sounds
> like that, but it's just 1-socket-1-client-1-instance.  If we could
> properly adapt QML for web, we'd have a completely superior web development
> paradigm. But I don't know if Qt wants to enter that space?
>
> [1] https://codereview.qt-project.org/#/c/215908/
> [2]
> https://bugreports.qt.io/browse/QTBUG-65241?focusedCommentId=387476&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-387476
> <-- the right idea
>
>
>
>
> *Sent:* Thursday, February 15, 2018 at 6:23 AM
> *From:* "René Hansen" 
> *To:* "Jean-Michaël Celerier" 
> *Cc:* interest , "Nikos Chantziaras" <
> rea...@gmail.com>
> *Subject:* Re: [Interest] QML vs Electron
> In my opinion Qt, (as a company), is directly responsible for the mess
> that is Electron and todays scape of the app-world. I worked for Nokia back
> in 2011, when they were trying to build, and miserably failed, the next-gen
> phone os platform, entirely as a web-runtime. The switch to a Qt/QtQuick
> approach on top of Meego was such an improvement in speed and overall
> resource usage. Being able to natively bridge with ease, while still
> keeping the door open for Javascript devs. was, and still is the single
> most killer combo out there.
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML vs Electron

[René Hansen]

On Sat, 17 Feb 2018 at 17:35 Jean-Michaël Celerier <
jeanmichael.celer...@gmail.com> wrote:

> > It would be nice to have a Qml modules manager.
>
> www.qpm.io
>

Maybe my initial comment on qpm was drowned out. :)

> And yes, I do know that qpm exists. Last I checked though, it wasn't
officially endorsed by Qt; the last commit is ~ a year old and it currently
houses 105 packages. NPM has almost 600K... It would go a long way if
developers knew Qt officially supported an initiative like qpm, or
otherwise grandfathered something similar itself.


>
>
>
>
> ---
> Jean-Michaël Celerier
> http://www.jcelerier.name
>
> On Fri, Feb 16, 2018 at 4:41 PM, Jérôme Godbout 
> wrote:
>
>> It would be nice to have a Qml modules manager. I mean, where people
>> could contribute to some common independent reusable modules. That would
>> give good kick start to generate quickly some Qml application.
>>
>> How many of us had to create a drawer Item with animation and self
>> resize, an overlay box, a Qml Popup that can contain any Items into it...
>>
>> Many of us made some great Qml Items or some JS controller that can
>> easily manipulate dynamic objects that could be reused and help Qml in
>> general (just like pip for Python, jQuery plugin listing, ...).
>>
>>
>> The manager would help to centralize and make the modules known by others
>> people and even be improve by community if lucky. Also put the download and
>> rating and you get something that could help give Qml more grip.
>> ----------
>> *From:* Interest  on
>> behalf of Bob Hood 
>> *Sent:* Friday, February 16, 2018 9:53:27 AM
>> *To:* Qt Interest
>> *Subject:* Re: [Interest] QML vs Electron
>>
>> I want to thank all the respondents for such an interesting discussion.
>>
>> I think René made some interesting observations regarding the massive
>> community support for JS in term of package managers, frameworks and UI
>> toolkits.  I think that is something that really presents a high bar of
>> entry for QML, that everybody wanting to use it must basically roll their
>> own.  As I pointed out, coming from a widget-rich environment to something
>> where I must create my own has always kept me from adopting QML as my
>> cross-device framework of choice.  I have to focus on writing the interface
>> itself first before I can focus on writing my application logic.  With
>> widgets, I drop them in, and only focus on interface writing if I want to
>> customize them.
>>
>> Nikos pointed out:
>>
>> Electron forces you to write the entire application in JS.
>>
>>
>> That kind of struck me.  All of JavaScript's flaws notwithstanding, how
>> could writing your application in a single language for all target devices
>> be a bad thing?  Couple that with the massive community and its support (as
>> René observed) and I think it is one of the driving factors that are
>> causing frameworks like Electron to rise, and QML to languish as an option.
>>
>> It seems like the Qt Company had a great idea, but once it was realized,
>> they expected that it would just pick up steam on its own without any
>> further effort on their part.  Certainly, it has its supporters here, but I
>> can't see it being a viable alternative to things like Electron unless it
>> is *fostered* by the Qt Company.  As René pointed out:
>>
>> It's about growing the ecosystem through marketing and outreach, while
>> lowering the bar of entry by building better primitives and tooling for
>> working with Qt. It is something that the JS world has been exceedingly
>> good at.
>>
>>
>> I would argue the same thing for "QML" if the Qt Company expects more
>> adoption of it.  Otherwise, people are turning to easier-entry
>> alternatives like Electron.
>>
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>>
>>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest