----- "Aaron J. Seigo" <ase...@kde.org> a écrit : > On Tuesday, December 21, 2010, François K. wrote: > > Is this a good solution ? I think I'm missing something because I'm > still > > downloading the file and, for what I understand, kioslaves should > allow me > > to avoid that. > > kio just provides access to data, with a uniform API for both the > local and > remote case. it doesn't provide a magic way to actually process data > on a > remote machine.
Allright, I understand. But I still think kio is kinda magic :P The question was how far the abstraction goes with kio. I guess I have my answer now :) > > Is there a way to load the file and build a QIcon without > > downloading it first ? > > kio operates locally; there is no server side to it. so, no. it needs > to > access the data (which in the remote case means sending it over the > network) > and then it can process it. you can do things to help, such as cache > the > results so they aren't re-downloaded every time the application > starts. at > least KIO is out-of-process so your application can do this async. OK, I've about the KPixmapCache and KImageCache classes. They seem very interesting for that case. I'll try to go on with one of these to see if it's what I need. > > What about performances if I have hundreds of files > > and load them from a remote source ? > > it'll take a while; nothing can short circuit the minimum amount of > work > involved in getting the information from point A to point B. the best > thing > you could probably do is to ensure that on the remote source there is > an > application which processes the files there and sends something > minimal > across. that's probably not an option, though :) This seems quite logic :) But it should be ok with the cache thing. And the QListView is already async, so it should be OK. Let me thank you again for your hints and help, I really really appreciate it :) -- François >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
