<p dir="ltr">hi,<br></p>
<p dir="ltr">On Apr 10, 2013 5:50 PM, "Thiago Macieira" <<a href="mailto:thiago.macieira@intel.com">thiago.macieira@intel.com</a>> wrote:<br>
><br>
> First of all, let me apologise for my behaviour in the thread on "dependency<br>
> bloat". I've re-read my first reply and it was clearly out of line. And the<br>
> number of off-ML messages I got also indicates that.<br></p>
<p dir="ltr">same.</p>
<p dir="ltr">> So, my deepest apologies for letting my personal feelings and frustrations<br>
> with Windows get in the way of being professional. So let's sort things out:</p>
<p dir="ltr">its been a rough patch for me and I sometimes cause collateral damage when the right spark hits. </p>
<p dir="ltr">>         * Qt and Windows:<br>
>         (this is supposed to be objective)<br>
><br>
> Windows has been and continues to be the biggest addressable market for Qt,<br>
> even after years of Nokia strongly pushing mobile. There are many users who<br>
> choose Qt for their Windows-only applications, with no intention of ever doing<br>
> cross-platform development. </p>
<p dir="ltr">a really nice aspect is that when done 'right' proper c++/boost and qt, then one barely even needs to care about cross platforn dev because its already cross platform. this is the largest appeal of all of the above to me.</p>

<p dir="ltr">> They do that because the Qt API is good and the<br>
> documentation is well-written.</p>
<p dir="ltr">good documentation++. </p>
<p dir="ltr">> And, I now realise, also because it's easy to build. I feel dumb for not<br>
> realising this before, especially when a month or two ago I tried to build<br>
> some other Unix-originated libraries on Windows and thought<br>
> Rest assured that the Qt Project remains attentive to Windows. Windows remains<br>
> one of the reference platforms for the project, which means all new features<br>
> that make sense on Windows must be implemented on Windows before they are<br>
> accepted. Any changes made >anywhere must not break the build >on Windows</p>
<p dir="ltr">please accept this criticism as earnest, heartfelt and with the best intentions: whomever(s) QAs the wibdows build process needs a kick in the rear. when I built 5.0 it became quite obcious many of the configuration options hadnt been tested or tested in some time.<br>
</p>
<p dir="ltr">>    That's why we're now going to >ship an MSVC2012 64-bit build, a >non-ANGLE<br>
>    build, </p>
<p dir="ltr">♡♡♡♡♡ tyvm.</p>
<p dir="ltr">>and we've worked with the MinGW >community to come up with a decent<br>
>    distribution of theirs that can >produce good-performance code.<br>
 <br>
thats awesome to hear, I would greatly encourage the mingw team to review the differences in terms of security that msvc provides, theres just no comparison.  (id est does anyone have even a first gen safeseh for c++ exception handling? nm sehop and so on).</p>

<p dir="ltr">its a volunteer project, IMHFO thats the best kind,  but we do ourselves a disservice if we ever believe that can rwally compete with the millions of dollars and hours that microsoft research has put into their products, is there even an oss/fs set of static analysis tools that compete with prefix et al?</p>

<p dir="ltr">for Windows, for me,  anythjng other than MSVC feels like im taking liberties with my users machines. </p>
<p dir="ltr">><br>
> We assumed that requiring Perl was acceptable. It was already required on<br>
> Windows if you decided to do an out-of-source build, which most people didn't.</p>
<p dir="ltr">totally not me complaining there.</p>
<p dir="ltr">> We assumed that Perl, being such an industry old-timer, would be an easy<br>
> requirement, unlike other tools we have to ship, like GNU flex.</p>
<p dir="ltr">id probably ship it akin to flex et al. I dont know thw license reqs and how much of a pain that is but apparently adding perl makes it over the top for many.</p>
<p dir="ltr">><br>
> And by the way, also remember that Linux distributors often hate us for doing<br>
> things the Windows way, like bundling libpng, libjpeg, zlib, sqlite, not using<br>
> autoconf, not using gettext. We're trying to be a great cross-platform tool,<br>
> which unfortunately means compromising here and there.</p>
<p dir="ltr">excellent point... I've sorta shunned myself from the geek world the last few years, horrible culture in areas I dont need encouragement in, and tend to forget how zealotted it can be.<br></p>
<p dir="ltr">><br>
>         * Feelings about Windows and bias:<br>
>         (this is subjective!)<br>
><br>
> I get extremely frustrated every time I have to develop using Windows.<br>
> Compared to the ease of development I have when using my Linux machine, I'm<br>
> nowhere near as efficient. Tools that I take for granted, like shell scripting,<br>
> AWK, Perl, sed, strace, valgrind, as well as SQLite, ICU, libpng, libjpeg,<br>
> zlib are missing.</p>
<p dir="ltr">I remember and empathize with that, generally speaking ive found when I just started using the msft way when on msft,  that I didnt need most of those tools.. I dont ship complete products often enough to worry much about the build process which is where most of that comes in. im pretty simple there a nmake file suffices but im finding more and more I hate basically al build processes so take my sentiments there with a grain of salt.</p>

<p dir="ltr">> And as I said to summarise in one word: valgrind. It's one of the most awesome<br>
> tools a developer could hope to have, to the point that I recommend people<br>
> have a Linux VM just in case they need it (note: there are commercial<br>
> alternatives for Windows; if you can't use Linux, make sure you get one of<br>
> those).</p>
<p dir="ltr">I actually keep a specific older laptop around just for linux  I owe everything I know abour computers to OSS/FS;  self taught, so dont get me wrong there. for lack of better phrasing and very much a personal subjective viewpoint,  programming on the unices feels like painting with crayons. CreateRemoteThread is a favorite example there. </p>

<p dir="ltr">><br>
> So my biased conclusion is that no developer with half a mind would willingly<br>
> choose to use Windows. I said that in one of my emails.</p>
<p dir="ltr">we are all entitled to our opinions,  even the wrong ones /ducks )</p>
<p dir="ltr">> And that is clearly biased. It is so because it's the environment in which I<br>
> am the most efficient. When I first started dabbling with development, in 1995, I<br>
> did use Windows, but no compilers were freely available. The one freely-<br>
> available compiler of that era for Windows was the Java one -- and some of you<br>
> may remember what Java 1.0 was like. Soon after, I discovered Linux, with<br>
> source code available and a decent (albeit much to be improved) compiler<br>
> available with just the flick of a switch -- that was GCC 2.7.2.</p>
<p dir="ltr">I started inversely and was on linux about 6 months into using computers because I heard its what  real hackers used and more of my professional career than not is super linux-centric. </p>
<p dir="ltr">> So I've "grown up" as a developer on the Unix world, with the tools familiar<br>
> with that world.</p>
<p dir="ltr">its a big paradigm shift, but I cant fathom going back fulltime now. I sometimes sit in vi for a moment having typed "re" waiting for the "ad " and prototype to pop up. hardly the best of explanations or rationales, but yeah windows spoiled me.</p>

<p dir="ltr">> Objectively speaking, I have to say that there are many advantages with the<br>
> environment I use: having readily accessible tools to look into low-level<br>
> events, system-wide debugging, access to the source code of the libraries that<br>
> I use, rapid script development, etc. But if I speak objectively, I have to<br>
> also recognise that Microsoft Visual Studio is an awesome tool, as long as you<br>
> don't have to go beyond its boundaries.</p>
<p dir="ltr">what boubdaries? if we wanted to break it down the debugging apis in windows is generally waaay better, windbg is awesome for both userland and ring0 and doesnt blow up on threads and I end up losing so much time remembering the nuances of the scripting language in question that I can generally pump out c++ way faster, especially with the new standard and/or boost. I sometimes refer to it as being what I imagined shell scripting in tcsh to have been like before I tried it.<br>

><br>
> And therein lies the big difference: the philosophy of those two worlds. In the<br>
> Windows / MSVC world, developers are expecting their tools to be self-<br>
> contained. They use Visual Studio and everything is inside there. They don't<br>
> have to go poking for third-party software. That's why the Qt Visual Studio<br>
> Add-in exists and that's actually the type of experience that Qt Creator is<br>
> trying to duplicate.</p>
<p dir="ltr">without argument, just when in Rome its painful to speak Greek. </p>
<p dir="ltr">> It's just not how I work</p>
<p dir="ltr">and IMHFO it doesn't have to be, nor mine vice versa. </p>
<p dir="ltr">> So, apologies for being out of line.</p>
<p dir="ltr">my sincerest apologies for the red hot private emails. </p>
<p dir="ltr">jf</p>