At least once in his lifetime, every programmer must have written some sort of image viewer. Long time ago, the challenge is to understand the magical combination of those VGA registers tweaks, the machinery behind decoding different complicated image formats, and other low-level related stuff. These days, especially using modern toolkits, an image viewer is like a tutorial project which would be completed in one or two hours. Hence, let us raise the bar a bit higher: what if the view should be able to display the images not only from local disks, but from somewhere out there? Apparently, using QNetworkAccessManager, a module available since Qt 4.4, it could be more easier.
svn checkout svn://labs.trolltech.com/svn/graphics/dojo/dragremote cd dragremote && qmake && make && ./dragremote
After the image viewer is launched (it will show the picture of a place in Paris), now you can open your favorite web browser, go to web sites which have photo gallery (say Flickr or Picasa Web Albums), and then drag the image there and drop it in this viewer. Basically, the viewer gets the URL and uses the above mentioned network access manager to download the image, and then finally displays it.
5 Responses to “Image viewer with remote URL drag-and-drop support”
Hello there. While learning Python, I did viewer conversion to Python/PyQt, maybe someone would be interested. 
http://my.opera.com/erechail/blog/2008/11/10/image-viewer-with-remote-url-drag-and-drop-support-pyqt-version
“it could be more easier.” “Easier” implies more easy
I jsut started working with QNetworkAccessManager this weekend, I had questions/comments:
Does it accept the “file” scheme? If not, why not?
I still hate that there is no static, blocking file retrieve function. like QByteArray QNetworkAccessManager::get(QString url);
Having blocking calls for post, put and delete would be great too. I realize that the trolls may cringe at blocking I/O but I work with multiple threads in my code, so the blocking is not a problem. I continually have to rely on Qxt’s QxtSignalWaiter class, and that is just silly. Qt should have its own signal waiting facility, and/or support these blocking functions. (To assume everyone is making this I/O calls in thier GUI thread is silly, there are plenty of people who use threads other than the GUI.)
Yes, the file:/ URI scheme is accepted to open local files. On Windows, you can use it to open SMB shares too. The protocols accepted by QNetworkAccessManager right now are: file, data, qrc (Qt Resource System), http/https, and ftp.
And the reason why we haven’t made a blocking method is because we can’t implement it safely without resorting to threads or to running the event loop again. Therefore, to avoid surprises, we make you write the event loop nesting code. It’s only a few lines of code (3, one more if you want to have a timeout), but at least you know what is happening.
Wow, I never knew. I’m consistently impressed even though I am vocal about things I’d like to see/have done differently. PLEASEPLEASEPLEASE Could we get those protocols mentioned in the class docs? I looked, could not find.
One thing I still don’t understand is why you’re adverse to running the event loop again? I ask because I do not understand why you are but I am not adverse to running the event loop. I’m afraid I’m missing something with that discrepancy. In a way, the SQL drivers should be the same way, where you can issue a query (network request) and asyncly get notified the querty results are coming back. I think we can so this now, but I believe it is only supported for PostgreSQL? I’d love to see it for Oracle.
Thanks.
@scorp1us: Here is the code…
QNetworkAccessManager *manager = …
QNetworkReply *reply = manager->get(QNetworkRequest(QUrl(”http://www.qtcentre.org/index.php”)));
QEventLoop loop;
connect(reply, SIGNAL(finished()), &loop, SLOT(quit()));
loop.exec();
If you want timeout support, create a timer, set it to single shot, connect it to the loop quit() slot and start the timer with a timeout of your choice. Then it’s just a matter of checking what caused the loop to quit - the timer or the network reply.