[Interest] Apologies on the "bloat" thread (a.k.a yes Windows is still important)

[Scott Aron Bloom]

Thank you for your honest and open reply.

Do you have a specification for what the perl script is required to do?

Is there a way for a non Qt developer, ie not one of you guys, one of us :), to setup their qt environment into the bootstrap world.

Ie, build the tool so it could be built the same time qmake is built.. With "qt" but not "full qt"  Please please please don't say I have to write it without any Qt :)

I am definitely willing to look into what it would take to implement.
Scott

-----Original Message-----
From: interest-bounces+scott.bloom=onshorecs.com at qt-project.org [mailto:interest-bounces+scott.bloom=onshorecs.com at qt-project.org] On Behalf Of Thiago Macieira
Sent: Wednesday, April 10, 2013 3:50 PM
To: interest at qt-project.org
Subject: [Interest] Apologies on the "bloat" thread (a.k.a yes Windows is still important)

First of all, let me apologise for my behaviour in the thread on "dependency bloat". I've re-read my first reply and it was clearly out of line. And the number of off-ML messages I got also indicates that.

So, my deepest apologies for letting my personal feelings and frustrations with Windows get in the way of being professional. So let's sort things out:

	* Qt and Windows:
	(this is supposed to be objective)

Windows has been and continues to be the biggest addressable market for Qt, even after years of Nokia strongly pushing mobile. There are many users who choose Qt for their Windows-only applications, with no intention of ever doing cross-platform development. They do that because the Qt API is good and the documentation is well-written.

And, I now realise, also because it's easy to build. I feel dumb for not realising this before, especially when a month or two ago I tried to build some other Unix-originated libraries on Windows and thought to myself, "gosh, this is so much easier with Qt".

Rest assured that the Qt Project remains attentive to Windows. Windows remains one of the reference platforms for the project, which means all new features that make sense on Windows must be implemented on Windows before they are accepted. Any changes made anywhere must not break the build on Windows either.

We're not out to try and make Windows developers lives harder. Quite to the contrary, which is why Qt exists in the first place and why Windows is supported.

The requirement for Perl was a conscious decision, one that we took after analysing what our objectives were, to wit:

1) the overwhelming majority of Windows downloads are of the pre-compiled 
   binaries and have been for as long as I can remember, so we will continue 
   to invest time to make that better, easier, more efficient
   That's why we're now going to ship an MSVC2012 64-bit build, a non-ANGLE 
   build, and we've worked with the MinGW community to come up with a decent
   distribution of theirs that can produce good-performance code.

2) lower the barrier of contributing to the Qt Project, lower our own 
    maintenance costs (time spent). That's why we decided to make the source 
    releases closer to the repository contents. I hope you can understand and 
    appreciate how this gets accomplished and the value to you.

3) verifiability: sources are cryptographically verifiable (goal not yet
    achieved)

We assumed that requiring Perl was acceptable. It was already required on Windows if you decided to do an out-of-source build, which most people didn't. 
We assumed that Perl, being such an industry old-timer, would be an easy requirement, unlike other tools we have to ship, like GNU flex.

Maybe we assumed wrong. To still achieve all those goals, maybe we should really give the binary replacement tool a try. I am currently swamped with other work, so I can't do it, but I do volunteer to mentor anyone who wishes to do it.

And by the way, also remember that Linux distributors often hate us for doing things the Windows way, like bundling libpng, libjpeg, zlib, sqlite, not using autoconf, not using gettext. We're trying to be a great cross-platform tool, which unfortunately means compromising here and there.


	* Feelings about Windows and bias:
	(this is subjective!)

I get extremely frustrated every time I have to develop using Windows. 
Compared to the ease of development I have when using my Linux machine, I'm nowhere near as efficient. Tools that I take for granted, like shell scripting, AWK, Perl, sed, strace, valgrind, as well as SQLite, ICU, libpng, libjpeg, zlib are missing.

And as I said to summarise in one word: valgrind. It's one of the most awesome tools a developer could hope to have, to the point that I recommend people have a Linux VM just in case they need it (note: there are commercial alternatives for Windows; if you can't use Linux, make sure you get one of those).

So my biased conclusion is that no developer with half a mind would willingly choose to use Windows. I said that in one of my emails.

And that is clearly biased. It is so because it's the environment in which I am the most efficient. When I first started dabbling with development, in 1995, I did use Windows, but no compilers were freely available. The one freely- available compiler of that era for Windows was the Java one -- and some of you may remember what Java 1.0 was like. Soon after, I discovered Linux, with source code available and a decent (albeit much to be improved) compiler available with just the flick of a switch -- that was GCC 2.7.2.

So I've "grown up" as a developer on the Unix world, with the tools familiar with that world.

Objectively speaking, I have to say that there are many advantages with the environment I use: having readily accessible tools to look into low-level events, system-wide debugging, access to the source code of the libraries that I use, rapid script development, etc. But if I speak objectively, I have to also recognise that Microsoft Visual Studio is an awesome tool, as long as you don't have to go beyond its boundaries.

And therein lies the big difference: the philosophy of those two worlds. In the Windows / MSVC world, developers are expecting their tools to be self- contained. They use Visual Studio and everything is inside there. They don't have to go poking for third-party software. That's why the Qt Visual Studio Add-in exists and that's actually the type of experience that Qt Creator is trying to duplicate.

It's just not how I work.

So, apologies for being out of line.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center