[Interest] WebEngineView on Android

[Charles-Élie Gentil]

Hello,

I'm working on a project using a Web interface. This project should be 
cross-platform. Currently, I use WebEngineView on Windows, Linux and Mac and I 
use WebView on Android.

Unfortunately, and unless I am mistaken, WebView in Android is very limited 
(does not save login / password, do not save the configuration, not use 
ressource files,  ...)

Do you think it will be possible one day perhaps, to have WebViewEngine on 
Android or not have these limitations with WebView?

Bye


Best regards,

Charlie

m...@jiyuusoft.net 
http://blog.jiyuusoft.net 



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

Re: [Interest] What you don't like about Qt

[Jason H]

That's some brutal stuff. Comments interjected.

> Sent: Friday, October 14, 2016 at 9:40 AM
> From: "Roland Hughes" 
> To: "Artem Sidyakin" 
> Cc: "interest@qt-project.org" 
> Subject: Re: [Interest] What you don't like about Qt
>
> On 09/23/2016 11:11 AM, Artem Sidyakin wrote:
> >> Digia
> >  From the 1st of May it’s The Qt Company now :)
> Thank you for that information.
> >
> >> NOBODY will pay royalties, period
> > Participating in calls and meetings with customers, I see a different 
> > picture.
> Having been in IT over 30 years now working as a consultant for I don't 
> even remember how many companies, both Fortune 50 and those with < 35 
> people, I have never encountered one. I have encountered thousands which 
> will spend "reasonable amounts" on toolkits which provide unlimited and 
> unrestricted use, but not one which would pay per-item royalties.
> 
> If one lives long enough you can see the same mistakes repeated at least 
> 3 times. This per item royalty notion got floated during the 
> mainframe/mid-range go-go days. Pretty much every company which floated 
> the notion died a quick and horrible death.
> 
> During the DOS and GUI-DOS (Windows 3.x and earlier were NOT operating 
> systems they were launched via C:\win) a whole rash of companies tried 
> this royalty thing. Developers had no problem paying huge (for the time) 
> dollars getting commercial grade compilers and tools, but would not pay 
> one red cent in royalties. I remember having spent big bucks on .RTLink 
> like many of my clients and most of the Fortune 100. .RTLink decided 
> none of us had paid enough so they tried to move to a royalty scheme. I 
> stress the word "tried." Almost overnight the industry switched to 
> Blinker. You know what? I did a Web search before writing this. Blinker 
> is _still_ being sold. Yes, people still do DOS development, I turned 
> down a contract for it less than a month ago. Various DOS flavors run an 
> awful lot of expensive embedded devices. Stuff which starts at 1/4 
> million dollars and goes up from there.
> 
> http://www.grafxsoft.com/2blinker.htm
> 
> Here is the only thing I could find on .RTLink after a 5 minute search 
> with multiple search engines.
> http://corphist.computerhistory.org/corphist/documents/doc-43e9481924779.pdf
> 
> The same story is true for pretty much every tool of the day which tried 
> the royalty path.
> >> arthritic dog running in deep snow called QML
> >> script kiddies
> > I find the concept of dividing the application to front-end (QML) and 
> > back-end (C++) very convenient and helpful. That was a truly brilliant idea 
> > to implement such concept in Qt.
> > I used same approach being .NET/ASP.MVC developer back in my days. But I 
> > guess, I’m just a script-kiddy, so it explains.
> It was an ill thought out disaster prone to catastrophe leaving massive 
> quantities of signals firing off into the mist and developers hoping 
> they don't kill the neighbor's dog. I'm at a client which is suffering 
> from just such a QML with Agile catastrophe. One developer (who is no 
> longer here, possibly not employed as a programmer anywhere now) drank 
> the QML Kool-aid and was making everything in the back end a property 
> with NOTIFY signals even if it had absolutely NOTHING to do with user 
> interaction.

You seem to confuse a bad developer, Agile, and QML. The fact is superfluous 
notify goes no where, so that's not the issue. I've used signals successfully 
on high availability HTTP[S] servers.  I don't see how Agile is an issue. A lot 
of older people (which you clearly are) have contempt for Agile. I've forcibly 
been dragged into Agile. I see it as valid, but not without shortcomings. But 
blaming agile for this is not appropriate. It's akin to an ad hominem attack or 
a strawman argument. 

> Various other developers have come along and tried to clean up this 
> monstrosity which fails spasticly in the field. (Agile _always_ produces 
> a catastrophe when used for any system of consequence.)

This isn't necessarily so. Below the layer of Agile, are standard software 
engineering practices. Agile is just a project management style, it does not 
dictate software engineering practices. It seems that the software engineering 
practices are to blame.

> Guess what? There is no text editor one can use or bag of dried chicken 
> bones one can shake to identify NOTIFY signals which are unused. One 
> developer made the mistake of trusting the IDE search. A lot of NOTIFY 
> signals which were actually in use went away.
> 
> Guess what? QML provides zero, count them zero methods of compile time 
> verification for signal connections. The _only_ way of identifying these 
> problems is to have a console connected to your embedded devices AND be 
> watching real close. Despite all of the efforts to provide compile time 
> diagnostics to the connect() statement, Qt went and added this rotted 
> fish of an interface called QML which provides _nothing_ to ass

Re: [Interest] What you don't like about Qt

[Roland Hughes]

On 09/23/2016 11:11 AM, Artem Sidyakin wrote:

Digia

 From the 1st of May it’s The Qt Company now :)

Thank you for that information.



NOBODY will pay royalties, period

Participating in calls and meetings with customers, I see a different picture.
Having been in IT over 30 years now working as a consultant for I don't 
even remember how many companies, both Fortune 50 and those with < 35 
people, I have never encountered one. I have encountered thousands which 
will spend "reasonable amounts" on toolkits which provide unlimited and 
unrestricted use, but not one which would pay per-item royalties.


If one lives long enough you can see the same mistakes repeated at least 
3 times. This per item royalty notion got floated during the 
mainframe/mid-range go-go days. Pretty much every company which floated 
the notion died a quick and horrible death.


During the DOS and GUI-DOS (Windows 3.x and earlier were NOT operating 
systems they were launched via C:\win) a whole rash of companies tried 
this royalty thing. Developers had no problem paying huge (for the time) 
dollars getting commercial grade compilers and tools, but would not pay 
one red cent in royalties. I remember having spent big bucks on .RTLink 
like many of my clients and most of the Fortune 100. .RTLink decided 
none of us had paid enough so they tried to move to a royalty scheme. I 
stress the word "tried." Almost overnight the industry switched to 
Blinker. You know what? I did a Web search before writing this. Blinker 
is _still_ being sold. Yes, people still do DOS development, I turned 
down a contract for it less than a month ago. Various DOS flavors run an 
awful lot of expensive embedded devices. Stuff which starts at 1/4 
million dollars and goes up from there.


http://www.grafxsoft.com/2blinker.htm

Here is the only thing I could find on .RTLink after a 5 minute search 
with multiple search engines.

http://corphist.computerhistory.org/corphist/documents/doc-43e9481924779.pdf

The same story is true for pretty much every tool of the day which tried 
the royalty path.

arthritic dog running in deep snow called QML
script kiddies

I find the concept of dividing the application to front-end (QML) and back-end 
(C++) very convenient and helpful. That was a truly brilliant idea to implement 
such concept in Qt.
I used same approach being .NET/ASP.MVC developer back in my days. But I guess, 
I’m just a script-kiddy, so it explains.
It was an ill thought out disaster prone to catastrophe leaving massive 
quantities of signals firing off into the mist and developers hoping 
they don't kill the neighbor's dog. I'm at a client which is suffering 
from just such a QML with Agile catastrophe. One developer (who is no 
longer here, possibly not employed as a programmer anywhere now) drank 
the QML Kool-aid and was making everything in the back end a property 
with NOTIFY signals even if it had absolutely NOTHING to do with user 
interaction.


Various other developers have come along and tried to clean up this 
monstrosity which fails spasticly in the field. (Agile _always_ produces 
a catastrophe when used for any system of consequence.)


Guess what? There is no text editor one can use or bag of dried chicken 
bones one can shake to identify NOTIFY signals which are unused. One 
developer made the mistake of trusting the IDE search. A lot of NOTIFY 
signals which were actually in use went away.


Guess what? QML provides zero, count them zero methods of compile time 
verification for signal connections. The _only_ way of identifying these 
problems is to have a console connected to your embedded devices AND be 
watching real close. Despite all of the efforts to provide compile time 
diagnostics to the connect() statement, Qt went and added this rotted 
fish of an interface called QML which provides _nothing_ to assist 
making stable systems lives quite literally depend on.



Just take a look at how badly QML runs on the Raspberry Pi with a quad core and 
Gig of RAM.
http://www.logikalsolutions.com/wordpress/information-technology/raspberry-qt-part-12-qml-blows-big-stinky-chunks/

Yeah, this link was here before. Author was asked back then, how about 
benchmarking Qt Quick Controls 2? But I don’t remember his answer to that.
I have a stock RPi 3 on my desk and I use it in my development with QML. Cannot 
really complain about anything.
Speaking as the author, his answer was the code was up on the site in a 
Zip file and those who wanted to try it on a Raspberry Pi using 
libraries not in the current Pi repos were welcome to run their own 
tests posting the results here. The resounding silence means they 
achieved the same sucky outcome.


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

___
Interest mailing list
Inter

[Interest] qmake path wrong in boot2qt on device

[心翔]

Hi,
I compiled boot2qt with qtbase-tools and also *-dev package, but when run
qmake -query ,the qmake environment variable points to the host, so I can't
use qmake in target.

Does anybody know how fix this problem?

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

Re: [Interest] Advise on setting up documentation for a project (Qt Help Framework or not)

[Lorenz Haas]

> Out of curiosity, have you tried doxyqml?

I had seen it, but did not use it. The reason was, that you have to
"install" it (also on our build servers etc. and I had no time for
that) and  I wanted to try qdoc anyway.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] TextField_QMLTYPE_16 QVariant(Invalid) QRect(0, 0 0x0)

[Alexandru Croitor]

Hi,

You can check if this patch will help remove the messages.

https://codereview.qt-project.org/#/c/172572/

Regards,

Alex.

On 28 Sep 2016, at 16:44, Alexandru Croitor 
mailto:alexandru.croi...@qt.io>> wrote:

You don't have to do anything with accessibility. It happens in qt internals, 
if Qt was compiled with accessibility support.

On 28 Sep 2016, at 16:38, Jason H mailto:jh...@gmx.com>> wrote:


Thanks for the pointer, but I'm not doing anything with accessibility. :-/

Previously when I have seen these messages, it had to do with some 
accessibility property on the quick item, might be the case for you as well.
I can't recall from the top of my head which one it was, but you can 
iteratively go through the TextField and ancestors QML files, and try to 
comment out anything to do with Accessibility.
The workaround was then to set that property in your own code.

On 28 Sep 2016, at 00:01, Jason H mailto:jh...@gmx.com>> wrote:

When I close my app, I get a lot of these dumped to the console. Why?
Sometimes the _16 is _19, etc.


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