[Interest] download a file form http

[Till Oliver Knoll]

Am 07.07.12 10:32, schrieb Sivan Greenberg:
> On Fri, Jul 6, 2012 at 5:44 PM, Till Oliver Knoll
> <till.oliver.knoll at gmail.com> wrote:
>> Sivan, it seems to me that you're stumbling over the most basic steps ...
> So, as stated before, I somewhat believed that Qt can be used even
> when when you just know parts of it and do not master all of its
> mechanics and internals .

That's true: me for my part never touched the database modules or the 
QML modules, nor any of the mobile APIs - simply because I don't need them.

However, as is the case with /any/ framework or language, you do need to 
understand the *basics* (or the "design philosophy") behind such a tool.

I'd say for Qt that certainly is the "Qt Object Model" ("how memory is 
managed by the parent-child paradigm"), "Signal and Slots" ("callbacks") 
and to some extend the "Qt Meta Information System" ("for more advanced 
topics such as properties and type-tests").

That's not rocket science, a day or two with the excellent (!) Qt 
documentation (e.g. 
http://qt-project.org/doc/qt-4.8/gettingstarted-develop.html) should get 
you started very quickly.

Once you have learned and understood these concepts, the rest is simply 
applying your knowledge from other frameworks to this one, or basically 
learning "what does the API offer me".

> I now realize that the MOC mandates this
> understanding.

Let me just say that in your daily work with Qt you won't actually 
realise that the Meta Object Compiler (MOC) actually exists! Once you 
have understood its purpose you can almost immediatelly forget about the 
moc and that it does it's work almost magically - assuming that you're 
either using a project based on qmake (*.pro and *.pri include files), 
or better yet, are using Qt Creator. There are also "integration tools" 
for MS Visual Studio and Eclipse which render the moc build step almost 
invisible!

So all you need to know in your daily work is that as soon as 
"properties" or "signals/slots" are involved in your class and/or you 
want to make use of the "Qt Meta Information System", you just need to 
make sure that you

1. Inherit from QObject
2. Have the Q_OBJECT macro in your class declaration

That's it! Honestly! It's that easy! qmake/Qt Creator/integration tools 
will make sure that the appropriate build steps are done automagially 
for you (which will create a moc_yourclass.cpp file and compile/link 
that with your project) and you can forget about them!

> QML and the Qt creator made me think I could actually
> drop that file download snippet "as is" and use as I do in Perl, C,
> Python- I now realize this is an unreal expectation.

I urge you to give Qt a second try ;) Especially since you mentioned C 
you will quickly learn that Qt offers you so much more power of abstration.

> [Lots of different projects and experience]
 > Given that, I mistakenly thought I could apply this over 12
> years of knowledge (including the creation of a soft float toolchain
> and debian based OS for MIPSel from scratch) when implementing this
> very simple file download. I was wrong and I apologize for the noise.

To be honest I am a bit surprised that you didn't succeed in building a 
simple file downloader in Qt, given all your experience! But I'd 
attribute that to you having wrong expectations of what the Qt framework is.

>> I am just saying that because you made the impression to me that you're
>> expecting a given toolkit to quickly make you a wizard - when you're not.
>>
> Do you imply that in order to achieve what should otherwise be a dead
> simple task [...] I must become a wizard
> first? Then I'm really on the wrong mailing list...:/

I said that to me you appeared to *expect* that a given toolkit *makes 
you* a wizard - concluding that you have to *be* a wizard in the first 
place would be wrong and that was by no means my intent to make such an 
impression.

Yes, you have to have experience in C++. And yes, you have to understand 
some design principles such as MVC. Plus more experience in design 
patterns is a plus if you want to understand why Qt implemented a given 
thing in some way (but really just a plus - you can always simply accept 
the fact how the API solves things for you and don't necessarily need to 
understand the design principle behind it). And having experience in 
another (GUI) framework certainly helps.

But given all that you will quickly realise how much *easier* Qt 
actually makes it for you to solve things quickly!

>> So you've asked how to download a file in a single line (or so I remember).
>> I'll give you a few more:
>>
>>   QNetworkAccessManager *manager = new QNetworkAccessManager(this);
>> ...

> Right, so attaching QFile to that did not come to mind.

Qt provides you with the *building blocks* to achieve your goals, not 
necessarily with "ready-made custom solutions for a concrete scenario".

I agree that "downloading from an URL into a file" might be a very 
common scenario, but some Qt applications might want to have greater 
control about that process, or prefer not to store the incoming data 
into a file, but into a memory buffer.

Qt provides you all with the necessary API, the "dots" - but it is still 
up to you to connect those dots (QNetworkAccessManager and QFile, in 
this case) with "lines", such that you get a meaningful application.

This philosophy might be different from your Python experience, but it 
is very much in line with other frameworks such as Java, Cocoa and 
probably .Net as well: they all provide powerful building blocks, but 
not a "ready-to-use" solution for every given scenario: that would end 
up in an unflexible and redundant API!

> More over,
> asking around more than several times some "expert qt wizards" did not
> yield one coherent answer showing this could be assisted by an stdlib
> function to handle. I'll see about connecting this with QFile, thanks
> for the tip.

Well, I can't talk for others obviously, but you should really be 
connecting the data coming from QNetworkAccessManager with QFile ;) Off 
course nothing would stop you from using the QByteArray coming from

   http://qt-project.org/doc/qt-4.8/qiodevice.html#readAll

(QNetworkReply is a QIODevice, after all) and store that into a stdlib 
file handle opened with fopen() or similar (can't even remember those 
stdlib APIs ;)). But since you're using Qt, you really should be using 
QFile as well (makes live easier ;)).

> I'll set to become a qmake expert before I attempt any further Qt
> development, but I am quite familiar with signal and slots as the
> previous code link would prove.

Again, these are just the *basics* - you're not expected to be a wizard 
to start writing meaningfull Qt applications. And yes, learing the 
syntax of QMake (or understand what it does, for that matter), certainly 
doesn't harm. E.g. by going through the QMake tutorial which should take 
not more than an hour or so (probably much much less):

  http://qt-project.org/doc/qt-4.8/qmake-tutorial.html


> I kind of feel myself welcome to ask anyways :) At least we have a
> nice community to compensate of confusing docs and API incompleteness
> ;)

Off course if you have any improvements or "Look, I really got stuck 
with this confusing tutorial here or class description there"-points, 
you really should help in at least reporting them! With the current Qt 
development process there are several dozen other ways how you can help 
improving Qt, the first one as I already mentioned being reporting 
errors in the Qt docs.

However rest assured that *many* developers I got to know here on the 
list usually agree that the Qt docs are one of the *best* documentations 
for any given toolkit! ;)

> ... but
> having API completeness. Network stack is severely low leveled  and
> limited in Qt and I have some Nokia experts vouching for that that I
> won't disclose their names :)

There is always room for improvement: but we have already seen in the 
course of this email conversation that it takes you about 20 lines of 
C++/Qt code to download the content of an URL into a file - that covers 
your use case 100%.

If you're looking for a one-method solution with two parameters: URL, 
file, then you're asking for something else: e.g. a "network library 
based *upon* Qt"!

Because you're absolutely correct that the Qt API is somewhat *supposed* 
to be low-level (I prefer the term "it just provides you with the 
*building blocks*) - because Qt is a *framework*! And it *has* to just 
provide building blocks, otherwise it would severily limit its 
flexibility (or duplicate functionality).

> That being said, I will not expect Qt to
> be my compiled Python anymore.

Since you've mentioned Python quite a few times, please allow me to rant 
over that a little bit as well ;)

By no means I have much experience in Python, other than implementing a 
little Plex (media player/library) plugin for "Instagram". While I do 
see that Python has some very interesting features, especially for 
"lists", I still don't get it why people cheer so much for untyped 
programming languages!

To give a concrete example:

http://dev.plexapp.com/docs/api/objectkit.html#containers

So the "Container" takes an undefined amount of arguments: **kwargs - 
but what are those? Let's see... "view_group: A string specifying..." So 
that one must be a string... "no_cache: a boolean ..." - so that's a 
boolean. But what is the "mesage" argument?

"message - The header and message attributes are used in conjunction. 
They instruct the client to display a message dialog on loading the 
container, where header is the message dialog’s title and message is the 
body." BUT WHAT IS IT? Most probably a string... you'll only find out at 
runtime! Hold your breath, ladies and gentlemen...

I mean, WTF! Each time you want to figure out what kind of parameters to 
pass you have to read the prosa of the documentation! Or you simply try 
it out and test how your code fails over and over again at runtime, 
until you have figured out what "type" to pass as parameter... in 
practise this probably only works so well because most APIs seem to only 
accept numbers, booleans and strings - and lists thereof. But dare you 
you start defining your own classes and want them to be passed as 
parameters to your own functions... honestly, Python people (and 
JavaScript and any other untyped script/language people, for that 
matter), what's so much fun about "parameter guessing"?!

;)

Cheers, Oliver