On 29/09/18 23:35, Roland Hughes wrote:
Syllogism, nice word. For those who did not wish to look it up
[snip]Thank you, but I assume that people reading this mailing list are smart enough to look up the words that they don't know, or ask me directly for an explanation.
Logic A form of deductive reasoning consisting of a major premise, a minor premise, and a conclusion; for example, All humans are mortal, the major premise, I am a human, the minor premise, therefore, I am mortal, the conclusion. Well, you may not care about such a discussion nor wish to have it, but, since your ENTIRE second point is based on: This major premise has not been established in this community. We will be doing a bit of that in a moment. As to point one.
[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.
However, this is so blatant I can't just let it go:
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.
I need to point out a recent statement from Alex
Alex has a last name, by the way.
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...
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.
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.
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.
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".
(No, I won't go further offtopic with a discussion about bugfixing in Qt.)
Qt is an incredibly heavy massive footprint. It gets heavier and more massive every day. You won't be porting "just a GUI." CAN-BUS, Serial I/O, SQL database, timers, yet another thread class, the absolutely worthless QML (which pretty much means you will need to port JavaScript as well.) Ah yes! In order to claim you have "ported Qt" you will also need to port WebEngine and all of the other Web stuff.This is another blatant false statement, because you can port just the parts of Qt that you need, and even those can be further trimmed down using the feature system. (That's actually how you would do a port in the first place.) There are already many parts of Qt that run only on a subset of all the platforms Qt has been ported upon, and there is no such thing as a "minimum set of things to support to say that Qt runs on a given platform". My 2 c,Here we walk smack dab into one of the many many many many reasons a SAD (or SAS if you prefer) is required for true software engineering. It is also one of the reasons Qt is starting to get such a bad reputation with developers. A System Architecture Document specifies the minimum system requirements and minimal installation for a system or framework. This is one of the many reasons I believe there is no SAD for this product. I've certainly never found on. If you really honestly believe there is no definition of a minimum system allowed to call itself Qt that is like saying Microsoft can call Windows Linux if the port the ls command.
No, they cannot, because Linux is a registered trademark in the US.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).
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 are supported on that platform:
https://doc.qt.io/qt-5/supported-platforms.html
https://doc.qt.io/qt-5/qtmodules.html
And congratulations on "committing" on a project without using True Software Engineering methods that would've immediately showed the flaw in the required tooling.
Every cross platform tool set I have encountered in my 30+ years in IT has made two horrific mistakes before disappearing from the marketplace. 1) Not specifying and enforcing a minimum set of features/functionality before it could be claimed the tool set existed on a platform.
Which is not the case for Qt; those are called the Essential modules and are supported by every platform, as clearly stated in the links above.
2) Started adding things to a developers "favorite" platform then never porting them to other platforms.
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!
The software battlefield is strewn with the corpses of products which made these two mistakes. The same mistakes you appear to be championing. You want to know why Zinc went under/got eaten?
[snip]No, I don't want to know why. This is not the mailing list for "let's share our software development stories". It's off-topic.
You think the QObject example too extreme? How about no WebEngine or perhaps no database or insert-major-component-here.
WebEngine is NOT an essential module, as clearly listed in the documentation page. Specifically, it does not work on the iOS or Android ports of Qt, and likely also on other architectures (e.g. Qt on Linux/MIPS).
As to "just the parts of Qt you need" I will let the P.S. from Uwe Rathmann answer that. === PS: would be nice to have a feature to get rid of all QML related members/ interfaces of QQuickItem/QQuickWindow === It's almost impossible to port "just the parts you need" in a post QML world. It's certainly not economically viable.
It's more than possible because you may be totally good living without QML/QtQuick. And the "not economically viable" is another unwarranted, unproven statement. Stop going offtopic, and stop making false or unproven statements.
-- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
