On 05/20/2017 01:02 AM, André Pönitz wrote:
I would neither call part of a 'philosophy' around Qt, that'd be
probably something with 'cross platform', 'ease of use'.
It's a philosophy. I have worked with many "cross platform" toolkits
over my 3+ decades. Up until Qt ZAF was the most successful/complete of
the toolkits. Successful enough I wrote several books on the package.
You can find one here
<https://books.google.com/books?id=cdx_nLaqMn0C&printsec=frontcover&dq=%22Roland+Hughes%22&hl=en&sa=X&ved=0ahUKEwi7_eTh8_7TAhVs9IMKHempDgEQ6AEIJzAA#v=onepage&q=%22Roland%20Hughes%22&f=false>
thanks to the world's largest copyright infringer.
Moc is there because it provides functionality that is not easily
available in C++, qmake/.pro is the build system that happens to be used
for Qt itself currently. While moc is kind of mandatory to use for Qt
application development for technical reasons, qmake is not, and it is
completely reasonable for an IDE to support, or even to focus on, other
build systems.
Creating make files for embedded targets which use serial ports and
other devices "could" be done by hand, but, the documentation one needs
to sift through identifying which library contains what classes and
features would be daunting for projects going much beyond "Hello World."
While it is completely within the rights of whatever IDE team to focus
on whatever language and build environment they wish it is also within
the rights of those developers working with tools that don't quite
cleanly fit within said IDEs to declare said IDEs unusable for
development. My professional view is that if you have to hack a script
so an IDE can identify/utilize one or more of the required tools it is
unusable.
I've been at this game a loooong time. Started out with BASIC then BASIC
PLUS on PDP 11/70 running RSTS/E. When moving to BASIC, COBOL and
FORTRAN on the VAX platform we moved to command line compiled languages.
Still just a raw text editor on a green screen without any syntax
highlighting or language sensitive help and no code management systems
other than being really careful about what directory things got copied
to and coordinating said copying within teams exceeding 40 developers.
One thing was common within this universe. We had an extremely limited
set of libraries to keep track of. Most of those libraries were things
we wrote ourselves.
True IDEs became necessary when both compiler developers and third
parties started providing massive numbers of libraries. In truth the IDE
movement started with Borland's Turbo Pascal and Turbo C products
because Borland provided a (for the time) large number of non-standard
libraries. (We barely had a PASCAL standard and the C standards
committee had yet to be formed.) This lead to other compiler vendors in
the PC and mainframe space to develop complete IDEs which did not
require developers to hack configuration scripts or leave the
environment. Microsoft finally figured it all out with Programmer's
Workbench under DOS which they promptly abandoned for their Windows only
IDE. Watcom created a pretty incredible IDE which run under OS/2,
Windows and several other platforms. IBM came out with flavors of their
Visual Age product line which let developers have a full IDE integrated
to the mainframe so they could test and develop from PC then check-in
and deploy on mainframe. Their BASIC
<http://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/0/897/ENUS296-420/index.html&lang=en_US&request_locale=en>
product died though.
In order to be called an IDE for whatever language/toolset a developer
should not have to hack custom scripts to give the tool access. A
develop needs to be able to perform all forms design, coding, debugging
and project deployment from within the IDE.
Using that definition QtCreator is truly and IDE for Qt. So are/were
QDevelop, Monkey Studio and the Eclipse plug-in. KDevelop is just a high
end editor when it comes to Qt. Perhaps when it comes to all of its
supported languages. While I did not do an extensive search I did not
see anything resembling built in support for any kind of forms design,
just coding, compiling and debugging.
Please allow me to put this in perspective.
I own a multi-machine license for UltraEdit <http://www.ultraedit.com/>.
I use it whenever I'm working on a project which does not allow for KDE
desktop that would give me KATE natively. (Installing KATE on non-KDE
desktops tends to install a fair chunk of KDE which does not get tested
in conjunction with other desktops on most distros. One of the few
reasons I stuck with SuSE so long was the fact they installed ALL
desktops together so everything was tested together.) UltraEdit can do
many many things. When you get the full UltraEditStudio it integrates
debugging via many different debuggers and has this massive UltraCompare
tool which I never really figured out though I own a license for as
well. (I've always found Meld simple and robust enough for my needs. UC
is complex and meant to do comparisons far more involved than I should
ever need to do.)
Having painted this picture for the UltraEdit product line I will state
this. No flavor of it is an IDE. Yes you can code. Yes you can compile.
Yes you can debug, but, there is no forms capability of any kind. It is
just a high end editor which can only be considered and IDE for someone
who is 100% back-end/batch job developer of applications with no user
interface. Back in the days of DOS many of our IDEs had forms designers
for BOTH screen and report. They all had quirks and issues, but they
were huge benefits. I remember Pro-C (not to be confused with the Oracle
product Pro*C) which had huge promise and too little funding behind it.
Lotus Approach had even better forms for both screens and reports,
ushering in the era of RAD (Rapid Application Development) and the mish
mash of tools which came and mostly went from that era (though
PowerBuilder is still around for some inexplicable reason.)
What I've been seeing lately are many people confusing high end editors
with IDEs but the two are notably different. There have been various
attempts <https://ncreportsoftware.com/> at extending QtCreator
<https://forum.qt.io/topic/38291/reporting-tool-with-qt-creator/4> or
just Qt to also include report creation
<https://www.kdab.com/development-resources/qt-tools/kd-reports/>. While
the phone app world might not care much about report creation, both the
desktop and embedded world care a great deal. Most stand alone embedded
designs need to send email reports on status and reading summaries. Many
systems which should be standalone end up having to also develop a
central server which receives data packets, chews on them, then spits
out a report creating unnecessary maintenance and support issues.
--
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
