Re: [Interest] Guide me through the Qt offerings for GUIs

[Vlad Stelmahovsky]

On Tue, Apr 20, 2021 at 3:13 PM Roland Hughes 
wrote:

>
> On 4/20/2021 5:00 AM, Giuseppe D'Angelo wrote:
>
> On 18/04/2021 14:50, Roland Hughes wrote:
>
> It's completely true. That tiny subset on the Web site doesn't scratch the
> surface. It certainly doesn't encompass my customer base and I haven't
> heard anyone pipe up on here using QML for anything non-significant that
> wasn't phones or John Deere. Even the one medical device we have been told
> about on this list has said you can't do anything in QML, only painting.
>

its not true. f.ex all Volvo cars from 2015 until this year using QML-based
apps in their infotainment system


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

Re: [Interest] Qt 5.6 Qt labs controls porting to QtQuick2 controls

[Ramakanth Kesireddy]

Thanks for your mail. It helps.

As mentioned in
https://doc.qt.io/archives/qt-5.6/qt-labs-controls-qmlmodule.html, Types in
the Qt.labs module are not guaranteed to remain compatible in future
versions.

Does it means the Qt Labs Controls may/maynot be compatible with latest Qt
Quick2 controls?

Best Regards,
Ramakanth


On Thu, Apr 15, 2021 at 1:22 PM Mitch Curtis  wrote:

> > -Original Message-
> > From: Ramakanth Kesireddy 
> > Sent: Thursday, 15 April 2021 6:33 AM
> > To: Mitch Curtis 
> > Cc: Qt Interest 
> > Subject: Re: [Interest] Qt 5.6 Qt labs controls porting to QtQuick2
> controls
> >
> > Thanks for your response.
> >
> > Though there is no Qt documentation, can it be ported from Qt labs
> controls
> > to QtQuick2 controls and vice-versa?
>
> Yes, it should be. Qt Quick Controls 2 is the continuation (aka renaming)
> of Qt Labs Controls.
>
> > Best Regards,
> > Ramakanth
> >
> >
> > On Tue, 6 Apr, 2021, 12:38 Mitch Curtis,  >  > wrote:
> >
> >
> >   > -Original Message-
> >   > From: Interest  interest-
> > boun...@qt-project.org> > On Behalf Of Ramakanth
> >   > Kesireddy
> >   > Sent: Thursday, 1 April 2021 3:10 AM
> >   > To: Qt Interest mailto:interest@qt-
> > project.org> >
> >   > Subject: [Interest] Qt 5.6 Qt labs controls porting to QtQuick2
> > controls
> >   >
> >   > Hi,
> >   >
> >   > As we used Qt 5.6 Qt labs controls 1.0 in our Qml application and
> > would like to
> >   > port to QtQuick2 controls in Qt 5.15, could you please let me
> know
> > if there is
> >   > a Qt documentation to port the labs controls to QtQuick2 controls
> > and
> >   > compatibility or known issues if any?
> >   >
> >   > Please suggest in this regard.
> >   >
> >   > Best Regards,
> >   > Ramakanth
> >   >
> >
> >   We have porting documentation for Qt Quick Controls 1 to 2, but not
> > from Labs Controls to Qt Quick Controls 2.
> >
> >   The closest thing would be to check the change log for each minor
> > version up to the version you want to use:
> >
> >   https://code.qt.io/cgit/qt/qtquickcontrols2.git/tree/dist
> >
> >   The "Important Behavior Changes" section is the most relevant here.
> >
>
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Interest Digest, Vol 115, Issue 17

[Giuseppe D'Angelo via Interest]

On 20/04/2021 23:55, Roland Hughes wrote:


On 4/20/2021 4:35 PM, Giuseppe D'Angelo wrote:

On 20/04/2021 15:10, Roland Hughes wrote:

On 4/20/2021 5:00 AM, Giuseppe D'Angelo wrote:

On 18/04/2021 14:50, Roland Hughes wrote:

I guess QML is more present in embedded? Or maybe some entreprise stuff
we don't know about...
Just phones and John Deere.

This is false, as a quick walk through the customer showcase on TQC's
website will show.

It's completely true. That tiny subset on the Web site doesn't scratch
the surface.

So there's even*MORE*  QML used in embedded than what's advertised on
TQC's website? That's great news!

I know it is difficult for you, but don't be an ass.



Or how about plain English? I'll put it in a better format:

ORIGINAL QUESTION:

"I guess QML is more present in embedded? Or maybe some entreprise stuff
we don't know about..."

YOUR answer:

"Just phones and John Deere."

MY answer:

"This is false, as a quick walk through the customer showcase on TQC's
website will show."

YOUR answer:

"It's completely true. That tiny subset on the Web site doesn't scratch
the surface"


Conclusions from YOUR answer: there's many more people using QML than
the tiny subset of customers represented on TQC's website. "That tiny
subset on the Web site doesn't scratch the surface".

Which not only is what I was saying before; but it's also true, and it's
also in direct contradiction with "Just phones and John Deere.".



This is also false. SXs have never been defective CPUs.

You need to actually learn processor history or at least do some
research before you speak.

The 486SX was a marketing quirk. Intel had a high failure rate (low
yield) on the FPU. When a CPU passed DX testing it was sold as a 486DX.
When it failed testing it went down another line where they "cut some
pins" so the chip couldn't communicate with the bad FPU, put an SX on it
and sold scrap at a discount.
This has widely been debunked.

The SXs were introduced to the market_years_  after the introduction of
the DXs. Intel didn't start to have massive production problems all of a
sudden and thus decided to pull this stunt. The SXs were_designed_  to
have the FPU disabled, and their FPU was for this reason ever tested.
The only reason for the introduction of the SX was market segmentation
to compete against AMD.

Here's some links for you, given you seem to able to Google "486 sx
defective" (and leave it in the URLs that you link), but somehow
conveniently IGNORING the first couple of results, even if they include
first-hand accounts of Intel engineers who worked on the 486 that
disprove the whole defective story:

http://www.os2museum.com/wp/lies-damn-lies-and-wikipedia/

By the way, did you notice that the Wikipedia page that YOU linked
doesn't talk about those chips being "defective" DXs?
Because that's a lie, as discussed in the talk page:

https://en.wikipedia.org/wiki/Talk:Intel_80486SX

Nothing in your links debunks anything, 



Yeah, right, don't read them, don't even quote sentences from them, and
try to disprove them.

except your ability to do 
research.


Yay, personal insults, let's go!

I was at Digital Equipment Corporation when they were 
designing their 486 "Dandy" The Digital Tandy and that is __exactly__ 
what Intel told the engineers. It took more than a year of DX "low 
yield" before there was enough chips to make setting up a line to "fix" 
them worth while.



Ah ok. Thanks for NOT mentioning it before before dumping all the Google
results (well, all except the ones that disproved your thesis).

So, who should we believe?


On your left, witness A: an Intel engineer who claims to have directly
worked on the project. Now we can't easily verify that (and I don't want
to bother the person by writing directly). Witness A brings the
following evidence:

* The SX had been introduced 2 years after the DX, signalling no
production problems whatsoever (which if anything should've appeared
earlier in the process).

* The FPU had simply been disabled via a pin in the package. Technically
noone knows if they were _actually_ defective because they were not
tested at all, since the dies were built from the start to be SXs.

* The silicon process makes it very unlikely to get "just" a defective
FPU and not also affect the rest of the chip. And even if you get "just"
a defective FPU, a constant error in the fabrication process is not
something you would be fine with (the source of the defect may spread to
other components).

* The driving factor was offering a cheaper product in order to fight
competition from AMD (simple fact given the market shape at the time).



On your right: witness B, found to be lying multiple times in the past
(I like your selective quoting, by the way). Witness B says there's some
hearsay about this, back in the day, from someone at Intel. Now we can't
verify this either -- even in the crazy hypothesis of admitting hearsay
in court. But no other evidence is brought forward, nor any reasoning
about 

Re: [Interest] Guide me through the Qt offerings for GUIs

[Roland Hughes]

On 4/20/2021 4:35 PM, Kyle Edwards wrote:

On 4/20/21 10:18 AM, Matthew Woehlke wrote:

It's well known that you*have*  to highlight the whole file, at least
to the current position, for accurate ("perfect") highlighting.

If I understand correctly, you have to*analyze*  the whole file, but not
necessarily*highlight*  it. (Though, once you've completed the analysis,
highlighting it is a relatively trivial step, and skipping it for
non-visible parts of the file may not yield a whole lot of savings.)


Mostly correct Kyle.

With the structure/design of QPlainTextEdit you have to *analyze* in the 
single-thread-i-ness main event loop. So, when someone opens and editor 
with 4-7 large source files opened in tabs, the one you really need, the 
last one, is jammed up in the single-thread-i-ness main event loop 
behind the other tabs you cannot see because they were in first load order.


QPlainTextEdit forces you to *highlight* during *analyze* using regular 
expressions . . . assuming you use it as designed.


As Matthew has pointed out, KATE doesn't do this. Last I looked at the 
code it creates worker threads for everything.


One note though. KATE (or katepart as Mathew prefers) has to be using 
more than just regular expressions because it actually highlighted the 
initializer list correctly.


Thanks for participating in the conversation.

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

https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://lesedi.us
https://johnsmith-book.com
https://logikalblog.com
https://interestingauthors.com/blog

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

Re: [Interest] Interest Digest, Vol 115, Issue 17

[Roland Hughes]

On 4/20/2021 4:35 PM, Giuseppe D'Angelo wrote:

On 20/04/2021 15:10, Roland Hughes wrote:

On 4/20/2021 5:00 AM, Giuseppe D'Angelo wrote:

On 18/04/2021 14:50, Roland Hughes wrote:

I guess QML is more present in embedded? Or maybe some entreprise stuff
we don't know about...
Just phones and John Deere.

This is false, as a quick walk through the customer showcase on TQC's
website will show.

It's completely true. That tiny subset on the Web site doesn't scratch
the surface.

So there's even*MORE*  QML used in embedded than what's advertised on
TQC's website? That's great news!

I know it is difficult for you, but don't be an ass.

This is also false. SXs have never been defective CPUs.

You need to actually learn processor history or at least do some
research before you speak.

The 486SX was a marketing quirk. Intel had a high failure rate (low
yield) on the FPU. When a CPU passed DX testing it was sold as a 486DX.
When it failed testing it went down another line where they "cut some
pins" so the chip couldn't communicate with the bad FPU, put an SX on it
and sold scrap at a discount.
This has widely been debunked.

The SXs were introduced to the market_years_  after the introduction of
the DXs. Intel didn't start to have massive production problems all of a
sudden and thus decided to pull this stunt. The SXs were_designed_  to
have the FPU disabled, and their FPU was for this reason ever tested.
The only reason for the introduction of the SX was market segmentation
to compete against AMD.

Here's some links for you, given you seem to able to Google "486 sx
defective" (and leave it in the URLs that you link), but somehow
conveniently IGNORING the first couple of results, even if they include
first-hand accounts of Intel engineers who worked on the 486 that
disprove the whole defective story:

http://www.os2museum.com/wp/lies-damn-lies-and-wikipedia/

By the way, did you notice that the Wikipedia page that YOU linked
doesn't talk about those chips being "defective" DXs?
Because that's a lie, as discussed in the talk page:

https://en.wikipedia.org/wiki/Talk:Intel_80486SX

Nothing in your links debunks anything, except your ability to do 
research. I was at Digital Equipment Corporation when they were 
designing their 486 "Dandy" The Digital Tandy and that is __exactly__ 
what Intel told the engineers. It took more than a year of DX "low 
yield" before there was enough chips to make setting up a line to "fix" 
them worth while.


**Later** there was a 486SX designed without FPU.

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

https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://lesedi.us
https://johnsmith-book.com
https://logikalblog.com
https://interestingauthors.com/blog

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

Re: [Interest] Guide me through the Qt offerings for GUIs

[Roland Hughes]

On 4/20/2021 3:53 PM, Matthew Woehlke wrote:
TL;DR: We agree that QPlainTextEdit is "bad" (see below for definition 
of "bad"). We (apparently) disagree on what's required to correctly 
parse a file for syntax highlighting.


On 20/04/2021 15.03, Roland Hughes wrote:

On 4/20/21 9:18 AM, Matthew Woehlke wrote:

On 20/04/2021 09.10, Roland Hughes wrote:
Close on the heels of that "Why are they highlighting the whole 
thing?" when you only need the currently visible lines and possibly 
a screen up/down. Open up a 10,000 line source file in editors 
using Scintilla or the Electron JavaScript based things, or even 
GUI Emacs even on an i5-gen3 and you are almost instantly taken to 
the line you were on with perfect syntax highlighting.


Frankly, I am skeptical. At best I think you are misrepresenting the 
problem.


It's well known that you *have* to highlight the whole file, at 
least to the current position, for accurate ("perfect") 
highlighting. At least in the general case. There may be some files 
and/or syntaxes for which that it not the case, but vim has had 
partial highlighting for almost forever, and I've seen it drop the 
ball on plenty of occasions, because something earlier in the file 
changes correct highlighting for the visible part.


No, it's not well known or even accurate. IF one is taking a student 
type approach and attempting to use regular expressions all mushed 
together as one nasty bundle, the statement is true.


Let's look at three editors that seem to do it right.

KATE


Well, I find it ironic you include Kate (which really means katepart, 
i.e. Kate, KWrite, KDevelop and maybe others), since AFAIK that *does* 
highlight the whole file. It also *definitely* uses regular 
expressions (and Qt's RE engine, AFAIK), although it also uses a mix 
of other stuff optimized for common cases.


But maybe we're talking about different things. When I say 
"highlight", what I really mean is "syntax parse". Trying to *render* 
the entirety of a large file is, indeed, madness.


Yes. It isn't *highlighted* until it is *rendered*.



...and see my previous comments; QPlainTextEdit was never meant for 
that. Frankly, if you are using QPlainTextEdit to hold more than 
~16KiB of text... stop that.


There are a lot of little editors out there using QPlainTextEdit and one 
big mass of regular expressions where each line of the regular 
expression requires yet another pass through the text.




Of course, this may all be happening in a separate thread, and it 
isn't using QPlainTextEdit; katepart I'm almost certain has its own 
structures for managing state and keeping track of breaking the text 
into highlighted chunks.

Last I looked at KATE source, everything is happening in worker threads.



Text isn't a stream.


Katepart would disagree. Although the way of *expressing* how to 
handle line ends is different from handling other tokens, they are, at 
the end of the day, handled almost exactly the same as any other 
token. The difference is mainly that the rule to detect a newline is 
built-in and uses different syntax to express how said rule should 
modify the context stack.


No. Line endings are not "just another token." Linux always gets in 
trouble thinking like that. They are the record terminators on platforms 
intelligent enough to understand records. You have to get above the x86 
to experience that.





There is no magic that allows you to begin parsing in the middle of a 
file. If you do that, you will get something that is *wrong*. 
(Admittedly, not always, but sometimes, and vim is proof.)


Moreover, if you insist on expecting "text" to be structured in nice, 
neat records delimited by "line breaks", you are going to be in for a 
rude awakening when someone decides to try to open a "condensed" XML, 
JS, or whatnot. (Katepart *mostly* handles these gracefully. By 
default, it gives up at IIRC 1024 characters and forces a line break. 
You can raise that limit... admittedly, at your own peril. In a sense, 
katepart can get bogged down due to taking the approach you are 
*recommending*.)



It's the correct approach.

Despite what people say, it's almost always LF CR in a file.


This is trivially disproven by `unix2dos`. Or looking at most text 
files created on a Windows machine.

Not really, no.


 $ echo 'Hello, world!' | unix2dos | od -t x1
 000 48 65 6c 6c 6f 2c 20 77 6f 72 6c 64 21 0d 0a

That's a CR (0x0d, '\r') followed by a LF (0x0a, '\n').

Again, the ASCII world was much larger than the 
x86-wanna-be-a-real-computer-one-day-when-I-grow-up universe. Most early 
DOS versions, in particular the version of DOS shipping stock on the AST 
Premium 286, actually wrote LF CR. Some software wrote what you posted 
above, but not most of it. The error was introduced by people saying 
"carriage return linefeed" and developers not knowing any better. Most 
DOS (and GUI DOS) applications got modified to only require the two 
characters, accepting them in any order. The reason, if 

Re: [Interest] Guide me through the Qt offerings for GUIs

[Matthew Woehlke]

TL;DR: We agree that QPlainTextEdit is "bad" (see below for definition 
of "bad"). We (apparently) disagree on what's required to correctly 
parse a file for syntax highlighting.


On 20/04/2021 15.03, Roland Hughes wrote:

On 4/20/21 9:18 AM, Matthew Woehlke wrote:

On 20/04/2021 09.10, Roland Hughes wrote:
Close on the heels of that "Why are they highlighting the whole 
thing?" when you only need the currently visible lines and possibly a 
screen up/down. Open up a 10,000 line source file in editors using 
Scintilla or the Electron JavaScript based things, or even GUI Emacs 
even on an i5-gen3 and you are almost instantly taken to the line you 
were on with perfect syntax highlighting.


Frankly, I am skeptical. At best I think you are misrepresenting the 
problem.


It's well known that you *have* to highlight the whole file, at least 
to the current position, for accurate ("perfect") highlighting. At 
least in the general case. There may be some files and/or syntaxes for 
which that it not the case, but vim has had partial highlighting for 
almost forever, and I've seen it drop the ball on plenty of occasions, 
because something earlier in the file changes correct highlighting for 
the visible part.


No, it's not well known or even accurate. IF one is taking a student 
type approach and attempting to use regular expressions all mushed 
together as one nasty bundle, the statement is true.


Let's look at three editors that seem to do it right.

KATE


Well, I find it ironic you include Kate (which really means katepart, 
i.e. Kate, KWrite, KDevelop and maybe others), since AFAIK that *does* 
highlight the whole file. It also *definitely* uses regular expressions 
(and Qt's RE engine, AFAIK), although it also uses a mix of other stuff 
optimized for common cases.


But maybe we're talking about different things. When I say "highlight", 
what I really mean is "syntax parse". Trying to *render* the entirety of 
a large file is, indeed, madness.


...and see my previous comments; QPlainTextEdit was never meant for 
that. Frankly, if you are using QPlainTextEdit to hold more than ~16KiB 
of text... stop that.



Now lets pick on Featherpad trying to do it "the Qt way"


I'm not sure what you consider "the Qt way". IMHO, katepart *is* "the Qt 
way". It's the way (well, *a* way, anyway) any sane person using Qt 
would implement a text editor that's intended to be usable with large 
documents.


To highlight only the visible subset one simply needs to know the outer 
most enclosing boundaries.


Well... yes. And no. The problem is, in order to know those boundaries, 
you have to look at *everything* in them. You can't just, for instance, 
see a '{' and decide you can skip everything until the next '}', because 
that brace might be inside a string literal.


I haven't looked at katepart's guts enough to know how they work or if 
they try to employ any clever optimizations. I *have* written 
highlighters for katepart, however, and knowing what those look like, 
I'm far from convinced that any such optimizations are implemented, or 
indeed, even possible. Katepart's highlighting is based on a context 
stack, with each detection rule potentially altering that stack. You 
can't just skip rules, because doing so means the wrong rule might end 
up gobbling some token, which will lead you into a wrong stack state, 
and things will just get worse from there.


Of course, this may all be happening in a separate thread, and it isn't 
using QPlainTextEdit; katepart I'm almost certain has its own structures 
for managing state and keeping track of breaking the text into 
highlighted chunks.



Text isn't a stream.


Katepart would disagree. Although the way of *expressing* how to handle 
line ends is different from handling other tokens, they are, at the end 
of the day, handled almost exactly the same as any other token. The 
difference is mainly that the rule to detect a newline is built-in and 
uses different syntax to express how said rule should modify the context 
stack.


There is no magic that allows you to begin parsing in the middle of a 
file. If you do that, you will get something that is *wrong*. 
(Admittedly, not always, but sometimes, and vim is proof.)


Moreover, if you insist on expecting "text" to be structured in nice, 
neat records delimited by "line breaks", you are going to be in for a 
rude awakening when someone decides to try to open a "condensed" XML, 
JS, or whatnot. (Katepart *mostly* handles these gracefully. By default, 
it gives up at IIRC 1024 characters and forces a line break. You can 
raise that limit... admittedly, at your own peril. In a sense, katepart 
can get bogged down due to taking the approach you are *recommending*.)



Despite what people say, it's almost always LF CR in a file.


This is trivially disproven by `unix2dos`. Or looking at most text files 
created on a Windows machine.


  $ echo 'Hello, world!' | unix2dos | od -t x1
  000 48 65 6c 6c 6f 2c 20 77 6f 72 6c 64 

Re: [Interest] Guide me through the Qt offerings for GUIs

[Roland Hughes]

On 4/20/21 9:18 AM, Matthew Woehlke wrote:

On 20/04/2021 09.10, Roland Hughes wrote:
Close on the heels of that "Why are they highlighting the whole 
thing?" when you only need the currently visible lines and possibly a 
screen up/down. Open up a 10,000 line source file in editors using 
Scintilla or the Electron JavaScript based things, or even GUI Emacs 
even on an i5-gen3 and you are almost instantly taken to the line you 
were on with perfect syntax highlighting.


Frankly, I am skeptical. At best I think you are misrepresenting the 
problem.


It's well known that you *have* to highlight the whole file, at least 
to the current position, for accurate ("perfect") highlighting. At 
least in the general case. There may be some files and/or syntaxes for 
which that it not the case, but vim has had partial highlighting for 
almost forever, and I've seen it drop the ball on plenty of occasions, 
because something earlier in the file changes correct highlighting for 
the visible part.


No, it's not well known or even accurate. IF one is taking a student 
type approach and attempting to use regular expressions all mushed 
together as one nasty bundle, the statement is true.


Let's look at three editors that seem to do it right.

Emacs

https://www.logikalsolutions.com/wordpress/wp-content/uploads/2021/04/emacs-cpp.png
https://www.logikalsolutions.com/wordpress/wp-content/uploads/2021/04/emacs-h.png

Sublime

https://www.logikalsolutions.com/wordpress/wp-content/uploads/2021/04/sublime-cpp.png
https://www.logikalsolutions.com/wordpress/wp-content/uploads/2021/04/sublime-h.png

KATE

https://www.logikalsolutions.com/wordpress/wp-content/uploads/2021/04/kate-cpp.png
https://www.logikalsolutions.com/wordpress/wp-content/uploads/2021/04/kate-h.png

While some may/may not know about Qt classes, they all know about 
initializer lists.


Now lets pick on Featherpad trying to do it "the Qt way"

Featherpad

https://www.logikalsolutions.com/wordpress/wp-content/uploads/2021/04/featherpad-cpp.png
https://www.logikalsolutions.com/wordpress/wp-content/uploads/2021/04/featherpad-h.png

Obviously not right. Probably passable for many, but as language syntax 
increases in complexity both accuracy and performance degrade.


To highlight only the visible subset one simply needs to know the outer 
most enclosing boundaries. We had to do this stuff back when I was 
working on a Masters in the 1980s. Instructor for compiler design made 
us do this stuff in both Assembler and Algol (don't ask!)


There are multiple architectural problems with QPlainTextEdit. Most 
notably, it completely abandoned "plain text." Instead we have graphics 
components wedged in with private classes one can't get to and in 
general trying to stuff everything into a single class with much of it 
locked away. Adding insult to injury is the single-thread-i-ness of main 
event loop.


Text isn't a stream. It isn't a blob and it isn't a byte array. A text 
file is a sequence of variable length text records. Each record has an 
end-of-record marker depending on the OS and disk storage method. Some 
will have 0x0A (linefeed); others 0x0A 0X0D (linefeed carriage return); 
a very rare few will have 0x0D 0x0A (Carriage return linefeed) [Despite 
what people say, it's almost always LF CR in a file. The CR LF sequence 
was used almost exclusively for transmission to remote line printers 
without flow control because you needed to buy time for the print head 
to get to the left margin.]


The last rarity on the original ASCII systems is just 0x0D. I forget 
where that got used most often. (EBCDIC is a completely different can of 
worms)


At any rate, to successfully syntax highlight a narrow window all you 
really need to know is the outermost enclosing scope which gets 
determined during load and stored in a structure.


Well, anyway, QPlainTextEdit tried to mush everything down into one 
layer, at least everything that mattered. The single-thread-i-ness of 
the main event loop causes everything to monkey pile in the event queue 
all waiting their turn to paint.


For a couple hundred lines on a fast machine it is close enough for hand 
grenades. For editing anything of any significance, no.


I feel what's-his-name's pain with Featherpad. Trying to speed things up 
by tweaking the regular expression stuff, always hitting a performance 
wall. Thank God he is only doing a small handful of colors instead of 
the robust syntax highlighting found in Sublime and Emacs. He could be 
looking at ten minute file loads.


At the core of the class is the wrong object. The needed higher level 
objects also aren't there.


A text editor, even a GUI one, is still a line editor.

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

Re: [Interest] Guide me through the Qt offerings for GUIs

[Giuseppe D'Angelo via Interest]

On 20/04/2021 15:10, Roland Hughes wrote:


On 4/20/2021 5:00 AM, Giuseppe D'Angelo wrote:

On 18/04/2021 14:50, Roland Hughes wrote:

I guess QML is more present in embedded? Or maybe some entreprise stuff
we don't know about...
Just phones and John Deere.

This is false, as a quick walk through the customer showcase on TQC's
website will show.
It's completely true. That tiny subset on the Web site doesn't scratch 
the surface.


So there's even *MORE* QML used in embedded than what's advertised on 
TQC's website? That's great news!



It certainly doesn't encompass my customer base and I 
haven't heard anyone pipe up on here using QML for anything 
non-significant that wasn't phones or John Deere. 


Ah ok, since *you* never saw QML used on embedded projects, then it 
doesn't exist. How silly of me assuming otherwise.




QML was a bad idea trying to get around a legacy problem without
actually fixing the legacy problem. The legacy problem is the single
thread-i-ness of Qt. Back when Intel was selling 486 chips with a
manufacturing defect as SX

This is also false. SXs have never been defective CPUs.


You need to actually learn processor history or at least do some 
research before you speak.


You need to learn to use Google before you speak.

Or actually, better not: last time you used Google you fell for *two* 
April fools' blog posts, claiming they were true. For that, we haven't 
received apologies yet. So who tells us that it's different this time?



https://lists.qt-project.org/pipermail/interest/2019-December/034255.html




The 486SX was a marketing quirk. Intel had a high failure rate (low 
yield) on the FPU. When a CPU passed DX testing it was sold as a 486DX. 
When it failed testing it went down another line where they "cut some 
pins" so the chip couldn't communicate with the bad FPU, put an SX on it 
and sold scrap at a discount.


This has widely been debunked.

The SXs were introduced to the market _years_ after the introduction of 
the DXs. Intel didn't start to have massive production problems all of a 
sudden and thus decided to pull this stunt. The SXs were _designed_ to 
have the FPU disabled, and their FPU was for this reason ever tested. 
The only reason for the introduction of the SX was market segmentation 
to compete against AMD.


Here's some links for you, given you seem to able to Google "486 sx 
defective" (and leave it in the URLs that you link), but somehow 
conveniently IGNORING the first couple of results, even if they include 
first-hand accounts of Intel engineers who worked on the 486 that 
disprove the whole defective story:


http://www.os2museum.com/wp/lies-damn-lies-and-wikipedia/

By the way, did you notice that the Wikipedia page that YOU linked 
doesn't talk about those chips being "defective" DXs?

Because that's a lie, as discussed in the talk page:

https://en.wikipedia.org/wiki/Talk:Intel_80486SX




All of this is why I'm so excited to read about the Vulkan stuff going
on with the CsPaint library and the Vulkan links I sent you earlier. On
the surface it seems like someone talked to people who write software on
big computers before work started. Need to dig deeper to be really
certain, but you communicate with a "loader" that can support many revs
of the API.

Are you aware that Qt has had Vulkan integration classes since 5.12 (?),
and Vulkan can be used as a Qt Quick backend in Qt 6?

The ability of painting from multiple threads (or better, to build
command buffers from multiple threads) doesn't magically solve the
problem of manipulating data structures safely from multiple threads.
The single threaded CPU-based_painting_  of the syntax highlighting has
hardly ever been an issue; its_generation_  has, as it involves
modifying a shared data structure (while also the user is modifying it)
without races and without locking against the GUI thread. QTextDocument
design is unlikely to fit the bill here; a different design sounds
anything but easy, but the underlying graphics API has very little to do
with this.


The API has a ___lot___ to do with this as the dude putting out 
featherpad is learning the hard way and every editor developer 
attempting to use Qt and only Qt before them. The single-thread-i-ness 
hits a hard wall. That's the biggest issue.


That is followed by all of the "why would anyone have done __that__" issues:

like burying the selection active inside a private internal class and 
basing it on the difference of cursor position thus making it physically 
impossible to follow numerous time honored editor traditions of Mark> . Unless you gut the class and redevelop from scratch 
you can't have an N-key key sequence for begin mark and have the editor 
class understand a selection has been enabled even though there is zero 
cursor difference.


Close on the heels of that "Why are they highlighting the whole thing?" 
when you only need the currently visible lines and possibly a screen 
up/down. Open up a 10,000 line source file in editors 

Re: [Interest] Guide me through the Qt offerings for GUIs

[Kyle Edwards via Interest]

On 4/20/21 10:18 AM, Matthew Woehlke wrote:
It's well known that you *have* to highlight the whole file, at least 
to the current position, for accurate ("perfect") highlighting.


If I understand correctly, you have to *analyze* the whole file, but not 
necessarily *highlight* it. (Though, once you've completed the analysis, 
highlighting it is a relatively trivial step, and skipping it for 
non-visible parts of the file may not yield a whole lot of savings.)


Kyle

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

Re: [Interest] Guide me through the Qt offerings for GUIs

[Matthew Woehlke]

On 20/04/2021 09.10, Roland Hughes wrote:
Close on the heels of that "Why are they highlighting the whole thing?" 
when you only need the currently visible lines and possibly a screen 
up/down. Open up a 10,000 line source file in editors using Scintilla or 
the Electron JavaScript based things, or even GUI Emacs even on an 
i5-gen3 and you are almost instantly taken to the line you were on with 
perfect syntax highlighting.


Frankly, I am skeptical. At best I think you are misrepresenting the 
problem.


It's well known that you *have* to highlight the whole file, at least to 
the current position, for accurate ("perfect") highlighting. At least in 
the general case. There may be some files and/or syntaxes for which that 
it not the case, but vim has had partial highlighting for almost 
forever, and I've seen it drop the ball on plenty of occasions, because 
something earlier in the file changes correct highlighting for the 
visible part.


That said, Qt definitely does not have a widget that can do a reasonable 
job of syntax highlighting a large file. Katepart, which does a pretty 
good job, is very much its own implementation of a text editor with very 
little high level Qt code involved. (At least that used to be the case; 
I think some of the actual text parsing may have moved *into* Qt *from* 
katepart. Back when I was involved with it, however, it used Qt for text 
rendering and low level input, but I believe all the higher level logic 
for input handling and layouting was reimplemented.)


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

Re: [Interest] Guide me through the Qt offerings for GUIs

[Alexey Rusakov]

Am I the only one to feel that Roland monopolises the mailing list again,
after a couple of years?

On Tue, 20 Apr 2021 at 15:11, Roland Hughes 
wrote:

>
> On 4/20/2021 5:00 AM, Giuseppe D'Angelo wrote:
>
> On 18/04/2021 14:50, Roland Hughes wrote:
>
> I guess QML is more present in embedded? Or maybe some entreprise stuff
> we don't know about...
> Just phones and John Deere.
>
> This is false, as a quick walk through the customer showcase on TQC's
> website will show.
>
> It's completely true. That tiny subset on the Web site doesn't scratch the
> surface. It certainly doesn't encompass my customer base and I haven't
> heard anyone pipe up on here using QML for anything non-significant that
> wasn't phones or John Deere. Even the one medical device we have been told
> about on this list has said you can't do anything in QML, only painting.
>
>  QML was a bad idea trying to get around a legacy problem without
> actually fixing the legacy problem. The legacy problem is the single
> thread-i-ness of Qt. Back when Intel was selling 486 chips with a
> manufacturing defect as SX
>
> This is also false. SXs have never been defective CPUs.
>
> You need to actually learn processor history or at least do some research
> before you speak.
>
> https://arstechnica.com/civis/viewtopic.php?t=390388
>
>
> https://books.google.com/books?id=AoKUhNoOys4C=PP19=486sx+defective+fpu=en=X=2ahUKEwj2tL_s6IzwAhXQQc0KHYFnBj8Q6AEwAHoECAAQAg#v=onepage=486sx%20defective%20fpu=false
>
>
> https://www.google.com/books/edition/Blackie_s_Dictionary_of_Computer_Science/P2EtDAAAQBAJ?hl=en=1=486sx+defective+fpu=PR34=frontcover
>
>
> https://www.google.com/books/edition/The_Art_of_Computer_Virus_Research_and_D/XE-ddYF6uhYC?hl=en=1=486sx+defective+fpu=PT296=frontcover
>
>
> https://www.google.com/books/edition/Upgrading_and_Repairing_PCs/E1p2FDL7P5QC?hl=en=1=486sx+defective+fpu=PA123=frontcover
>
> The 486SX was a marketing quirk. Intel had a high failure rate (low yield)
> on the FPU. When a CPU passed DX testing it was sold as a 486DX. When it
> failed testing it went down another line where they "cut some pins" so the
> chip couldn't communicate with the bad FPU, put an SX on it and sold scrap
> at a discount.
>
> The 386SX was a different design. The 486SX was simply unloading 486DX
> junk.
>
>  All of this is why I'm so excited to read about the Vulkan stuff going
> on with the CsPaint library and the Vulkan links I sent you earlier. On
> the surface it seems like someone talked to people who write software on
> big computers before work started. Need to dig deeper to be really
> certain, but you communicate with a "loader" that can support many revs
> of the API.
>
> Are you aware that Qt has had Vulkan integration classes since 5.12 (?),
> and Vulkan can be used as a Qt Quick backend in Qt 6?
>
> The ability of painting from multiple threads (or better, to build
> command buffers from multiple threads) doesn't magically solve the
> problem of manipulating data structures safely from multiple threads.
> The single threaded CPU-based _painting_ of the syntax highlighting has
> hardly ever been an issue; its _generation_ has, as it involves
> modifying a shared data structure (while also the user is modifying it)
> without races and without locking against the GUI thread. QTextDocument
> design is unlikely to fit the bill here; a different design sounds
> anything but easy, but the underlying graphics API has very little to do
> with this.
>
> The API has a ___lot___ to do with this as the dude putting out featherpad
> is learning the hard way and every editor developer attempting to use Qt
> and only Qt before them. The single-thread-i-ness hits a hard wall. That's
> the biggest issue.
>
> That is followed by all of the "why would anyone have done __that__"
> issues:
>
> like burying the selection active inside a private internal class and
> basing it on the difference of cursor position thus making it physically
> impossible to follow numerous time honored editor traditions of  Mark> . Unless you gut the class and redevelop from scratch you
> can't have an N-key key sequence for begin mark and have the editor class
> understand a selection has been enabled even though there is zero cursor
> difference.
>
> Close on the heels of that "Why are they highlighting the whole thing?"
> when you only need the currently visible lines and possibly a screen
> up/down. Open up a 10,000 line source file in editors using Scintilla or
> the Electron JavaScript based things, or even GUI Emacs even on an i5-gen3
> and you are almost instantly taken to the line you were on with perfect
> syntax highlighting. Because QPlainTextEdit has to do everything in the
> main event loop and appears not to understand scope of visibility, it
> starts at the top and works its way down. Bad enough with one file, but try
> having three tabs open all with large files all using regular expressions
> for highlighting in the main event loop.
>
> The underlying graphics API 

[Interest] Qt virtual keyboard Qt 5.6.3 Qml plugin

[Ramakanth Kesireddy]

Hi,

Can we use Qt 5.6.3 virtual keyboard module in QML application for
production codebase or it is recommended to use latest Qt 5.15.3 version
which comes along with the module by default?

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

Re: [Interest] Guide me through the Qt offerings for GUIs

[Roland Hughes]

On 4/20/2021 5:00 AM, Giuseppe D'Angelo wrote:

On 18/04/2021 14:50, Roland Hughes wrote:

I guess QML is more present in embedded? Or maybe some entreprise stuff
we don't know about...
Just phones and John Deere.

This is false, as a quick walk through the customer showcase on TQC's
website will show.
It's completely true. That tiny subset on the Web site doesn't scratch 
the surface. It certainly doesn't encompass my customer base and I 
haven't heard anyone pipe up on here using QML for anything 
non-significant that wasn't phones or John Deere. Even the one medical 
device we have been told about on this list has said you can't do 
anything in QML, only painting.



QML was a bad idea trying to get around a legacy problem without
actually fixing the legacy problem. The legacy problem is the single
thread-i-ness of Qt. Back when Intel was selling 486 chips with a
manufacturing defect as SX

This is also false. SXs have never been defective CPUs.


You need to actually learn processor history or at least do some 
research before you speak.


https://arstechnica.com/civis/viewtopic.php?t=390388

https://books.google.com/books?id=AoKUhNoOys4C=PP19=486sx+defective+fpu=en=X=2ahUKEwj2tL_s6IzwAhXQQc0KHYFnBj8Q6AEwAHoECAAQAg#v=onepage=486sx%20defective%20fpu=false

https://www.google.com/books/edition/Blackie_s_Dictionary_of_Computer_Science/P2EtDAAAQBAJ?hl=en=1=486sx+defective+fpu=PR34=frontcover

https://www.google.com/books/edition/The_Art_of_Computer_Virus_Research_and_D/XE-ddYF6uhYC?hl=en=1=486sx+defective+fpu=PT296=frontcover

https://www.google.com/books/edition/Upgrading_and_Repairing_PCs/E1p2FDL7P5QC?hl=en=1=486sx+defective+fpu=PA123=frontcover

The 486SX was a marketing quirk. Intel had a high failure rate (low 
yield) on the FPU. When a CPU passed DX testing it was sold as a 486DX. 
When it failed testing it went down another line where they "cut some 
pins" so the chip couldn't communicate with the bad FPU, put an SX on it 
and sold scrap at a discount.


The 386SX was a different design. The 486SX was simply unloading 486DX junk.




All of this is why I'm so excited to read about the Vulkan stuff going
on with the CsPaint library and the Vulkan links I sent you earlier. On
the surface it seems like someone talked to people who write software on
big computers before work started. Need to dig deeper to be really
certain, but you communicate with a "loader" that can support many revs
of the API.

Are you aware that Qt has had Vulkan integration classes since 5.12 (?),
and Vulkan can be used as a Qt Quick backend in Qt 6?

The ability of painting from multiple threads (or better, to build
command buffers from multiple threads) doesn't magically solve the
problem of manipulating data structures safely from multiple threads.
The single threaded CPU-based_painting_  of the syntax highlighting has
hardly ever been an issue; its_generation_  has, as it involves
modifying a shared data structure (while also the user is modifying it)
without races and without locking against the GUI thread. QTextDocument
design is unlikely to fit the bill here; a different design sounds
anything but easy, but the underlying graphics API has very little to do
with this.


The API has a ___lot___ to do with this as the dude putting out 
featherpad is learning the hard way and every editor developer 
attempting to use Qt and only Qt before them. The single-thread-i-ness 
hits a hard wall. That's the biggest issue.


That is followed by all of the "why would anyone have done __that__" issues:

like burying the selection active inside a private internal class and 
basing it on the difference of cursor position thus making it physically 
impossible to follow numerous time honored editor traditions of Mark> . Unless you gut the class and redevelop from scratch 
you can't have an N-key key sequence for begin mark and have the editor 
class understand a selection has been enabled even though there is zero 
cursor difference.


Close on the heels of that "Why are they highlighting the whole thing?" 
when you only need the currently visible lines and possibly a screen 
up/down. Open up a 10,000 line source file in editors using Scintilla or 
the Electron JavaScript based things, or even GUI Emacs even on an 
i5-gen3 and you are almost instantly taken to the line you were on with 
perfect syntax highlighting. Because QPlainTextEdit has to do everything 
in the main event loop and appears not to understand scope of 
visibility, it starts at the top and works its way down. Bad enough with 
one file, but try having three tabs open all with large files all using 
regular expressions for highlighting in the main event loop.


The underlying graphics API contributes to the single-thread-i-ness 
which really drops the 6-bottom plow in behind the lawn mower.


Integration isn't service. During the era of the 286 and OS/2 Integration made 
sense. Today you need a stand alone service having a limited physical 
communication API that can handle 

Re: [Interest] Squish for open source

[Michal Lazo]

Hello
If you are looking for something for qt widgets application there is
alternative for example this
https://github.com/cisco-open-source/qtwebdriver

Best regards
Michal Lazo

On Mon, Apr 19, 2021 at 3:20 PM Vadim Peretokin  wrote:
>
> Following the news that Qt has acquired the excellent UI-based testing 
> software Squish (https://www.qt.io/blog/quality-assurance-tools), could that 
> offering be extended to open source projects by QtC?
>
> There's no real alternatives that I know of that can do UI-based testing for 
> Qt Widgets projects - or if I haven't looked hard enough, happy to hear 
> suggestions.
>
> Best regards,
> Vadim.
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest