Sorry for the delayed response. I saved this in my inbox until I had the
time it required.
[snip]
It doesn't work like this. You are*now* trying to establish the
premises of the syllogism, despite multiple people telling you that the
minor premise was false and that the major premise is questionable and
argumentative.
As I have already announced, I won't even consider reading the argument.
The logical fallacy of using an unproven premise to derive a consequence
was already there.
The point stays, however: going off-topic; resorting to false
statements; and posting logical fallacies are all not acceptable on this
mailing list.
It does actually work like this. You are trying to present a complete
lack of IT industry knowledge as expertise. When you challenge something
in a logical discussion you actually have to listen to the logic behind
the position. You have to read what is written. Putting your fingers in
your ears and holding your breath until you turn blue doesn't make your
position a reality or a fact. Any discussion of Qt is on topic for this
list. Your position otherwise is a logical fallacy.
True software engineering
Leave "true" and "false" to philosophy and to hard sciences; software
engineering is neither. If you're describing specific engineering
models, have the courtesy of saying which ones you're talking about.
Speaking of blatant and lack of industry knowledge. Others pointed this
out later on, but, it needs clarification so you can have another temper
tantrum.
SOFTWARE ENGINEERING IS A HARD SCIENCE - it is not AGILE hacking on the
fly. It has one name "Software Engineering." All other software
development approaches attempting to use this term are committing
criminal fraud.
* "the systematic application of scientific and technological
knowledge, methods, and experience to the design, implementation,
testing, and documentation of software"—The Bureau of Labor
Statistics—IEEE <https://en.wikipedia.org/wiki/IEEE>/Systems and
software engineering - Vocabulary/
/Systems and software engineering - Vocabulary/,ISO
<https://en.wikipedia.org/wiki/ISO>/IEC
<https://en.wikipedia.org/wiki/International_Electrotechnical_Commission>/IEEE
<https://en.wikipedia.org/wiki/IEEE>std 24765:2010(E), 2010.
Here in America we also have the "Software Engineering Institute"
https://www.sei.cmu.edu
Register for classes, attend them, get a degree.
I need to point out a recent statement from Alex
Alex has a last name, by the way.
If Alex didn't like people using the name "Alex" to speak to/of him he
wouldn't sign with just that name. He would also pipe up about it.
True software engineering put a man on the moon and returned him safely
to earth when the only programming languages we had to work with were
Assembler and FORTRAN. We haven't done that in a post OOP - AGILE world.
Oh, I get it, so Agile is why we don't go to the Moon any more...
It's one of them. The primary one really.
As Alex stated in that same message "Qt is huge."
It has loooooong since passed the size and complexity of anything which
an reliably be developed and maintained without true software
engineering. The 32767 flavors of AGILE cannot keep it stable.
This is your opinion. You're entitled to have it, and I will defend your
right to have it. But don't try arguing that this opinion is actually a
fact.
It's a fact. See Software Engineering above and Krzysiek's post below
Did you not listen/read krzysiek.kawa's post?
===
I really hate to be "that guy" again, but I'd just like to know what's
going on.
Some time ago I complained about bugs not being resolved for many
major releases. I was then told my reports were P2 or lower and I
can't expect them to be taken care of. That sucks for me but I can
understand to some degree.
But now a new release is out and I still have three P1:Critical
issues, reported 3 or 4 releases ago, all being regressions btw, and
nothing is fixed. There's a next major release around the corner and
it doesn't seem to fix these either.
===
I have not looked at those specific bugs,
Neither have I, but at least I extend the common courtesy of not talking
about things I don't know.
Quite the contrary you have been spouting about software engineering
quite profusely more than painfully obvious you know nothing about it.
You should read up on the many discussions (one even
within the past week) about critical bugs which rot until they are
closed in typical OpenSource manner.
1) There's no such thing as "typical OpenSource manner". Would you
kindly stop generalizing?
Of course there is. One need only look as far as GitHub.
Of course there is NOT. Stop generalizing.
Not generalizing, OpenSource projects have a typical structure and
development cycle. It's a fact.
2) Qt is also a commercial product, with commercial support, and bugs
fixed and prioritized (also) according to the commercial needs; so this
statement is factually false.
No, it's not. It's factually correct. You just don't wish to believe it.
It's factually INCORRECT. Bugs*are* fixed. Maybe not the ones that you
care about, but the ones that other paying customers care about
(because, as I said, Qt is also a commercial product, where people
paying get a nice priority ticket).
Hence you can't_generalize_ that bugs "rot" in the tracker, nor that
they're "closed in an opensource manner".
It's not a generalization, I've worked at paying customers of Qt where
bugs were held for ransom. Buying a license doesn't get you squat when
it comes to priority in the bug list queue. Re-read Krzysiek's post above.
For Qt, it's the Qt Project that sanctions your platform as a supported
one ("supported" by the Qt Project, of course). You can say you've
ported QtCore / QtGui/ Widgets / whatever on your new platform, you
cannot say "Qt supports my platform" without the approval of the
project, nor you can take a random GUI library or a random subset of Qt
libraries and call it Qt (because Qt is also a registered trademark).
You don't have to say "Qt supports my platform" when you are allowed to
say "we've ported Qt to our platform" and you've only ported a tiny
subset. This is even sanctioned by the way Qt is doing business today
with major components not running on all platforms. WebEngine being
chosen as a major component and not running on Chromebook (and wherever
else it doesn't run) is a serious issue. Every time some hunk of Qt is
allowed to run on just a subset of the platforms it dramatically reduces
Qt's cross platform claim.
Picture yourself as a shiny new developer. You've just been hired to do
development for the Wizzy-Puffle OS. Don't worry there is a port of Qt
for this platform. You will use that to develop all of your
applications. Having never heard of Qt, you quickly do a Web search and
find the on-line documentation for the API. You see all of these
wonderful API calls and read and read. You go into your first planning
meeting with stars in your eyes. You must commit to developing a contact
manager for the OS which uses a database and has a nice GUI. They would
like it done in a week.
NO PROBLEM!
You commit to it.
No you go back and find that the only thing "ported" was QObject. This
is the entire "port" of Qt.
How do you feel?
This is an absolutely nonsensical example. The documentation clearly
states which platforms are supported by Qt and exactly which parts of Qt
This is __exactly__ what happens in the real world and most of those
developers won't come here for information. They will take to whatever
on-line haunts they like and spout about the false cross platform claims
of Qt.
Which is not the case for Qt. Qt has some minimal platform specific
bits, whose job is fill in the final gaps in order to make what's
otherwise a cross-platform app more integrated with the target OS.
There's no "favorite" platform amongst the Qt developers.
Stop generalizing!
Try using WebEngine on Chrome
--
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