[Interest] qmake and IDEs

Sat May 20 19:32:34 CEST 2017

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20170520/8f55811f/attachment.html>