------=_Part_39183_6284926.1175312897201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sweet, sounds great except for the delay. A half second for you could be many agonizing seconds for someone on a slow dial-up connection. Prioritized parallel prefetching would, I imagine, be a more user friendly. Prioritized, obviously, based upon what'll be shown first :) Actually, instead of blocking, maybe a little loading graphic, ala flash, would be more user friendly. After all, we're all used to seeing that for flash (and other similar web apps) already. Maybe just load an animated gi= f to display while it blocks even? Or if you'd like some sort of animation to run in its own separate thread until dismissed, I could always write one for you (I don't mind throwing together little tiny things like that ;) On 3/27/07, Josef Spillner wrote: > > Am Montag, 26. M=E4rz 2007 20:03 schrieb Mike Dean: > > It would be really nice if KNewStuff did prefetching, to avoid the > annoying > > lag, and caching of already retrieved information. Either getting rid > of > > displaying the progress dialog, or integrating it into the KNewStuff UI > > would be a very welcome improvement as well. Making these small > changes, > > IMHO, would give KNewStuff a much more polished look and feel. If > you've > > already done this, sorry, and kudos! > > It does that already, indeed (*). > We don't remove the cache yet and so your HDD will fill up over time. Suc= h > changes are > April 2. > > Even in KDE 3.5 there shouldn't be progress dialogs anymore, I've modifie= d > all > KIO calls AFAICR. > > Josef > > (*) ok, let me become a bit more technical since we're already at it. It > currently saves each entry into a file on its own. Loading them all in a > row > and deserialising the information takes long enough to let the dialog > appear > blocking for half a second or so. Since space isn't so much an issue, > there > could be a more efficient mapping (if mmap is enabled), but we can also d= o > the loading in parallel (use threading). Either of the two will happen > eventually, patches are welcome. > ------=_Part_39183_6284926.1175312897201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sweet, sounds great except for the delay.  A half second for you could= be many agonizing seconds for someone on a slow dial-up connection.  = Prioritized parallel prefetching would, I imagine, be a more user friendly.=   Prioritized, obviously, based upon what'll be shown first :)

Actually, instead of blocking, maybe a little loading graphic, ala = flash, would be more user friendly.  After all, we're all used to = seeing that for flash (and other similar web apps) already.  Maybe jus= t load an animated gif to display while it blocks even?
Or if you'd like some sort of animation to run in its own separate = thread until dismissed, I could always write one for you (I don't mind = throwing together little tiny things like that ;)


On 3/27/07, Josef Spillner <spillner@kde.org> wrote: Am Montag, 26. M=E4rz 2007 20:03 schrieb Mike Dean:
> It would be rea= lly nice if KNewStuff did prefetching, to avoid the annoying
> lag, a= nd caching of already retrieved information.  Either getting rid = of
> displaying the progress dialog, or integrating it into the KNewS= tuff UI
> would be a very welcome improvement as well.  Making the= se small changes,
> IMHO, would give KNewStuff a much more polished l= ook and feel.  If you've
> already done this, sorry, an= d kudos!

It does that already, indeed (*).
We don't remove the cache yet and = so your HDD will fill up over time. Such
changes are > April 2.
Even in KDE 3.5 there shouldn't be progress dialogs anymore, I've= modified all
KIO calls AFAICR.

Josef

(*) ok, let me become a bit more = technical since we're already at it. It
currently saves each entry i= nto a file on its own. Loading them all in a row
and deserialising the i= nformation takes long enough to let the dialog appear
blocking for half a second or so. Since space isn't so much an issu= e, there
could be a more efficient mapping (if mmap is enabled), but we = can also do
the loading in parallel (use threading). Either of the two w= ill happen
eventually, patches are welcome.

------=_Part_39183_6284926.1175312897201--