[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: Save as ( was Re: popup menus )
From:       Simon Hausmann <tronical () gmx ! net>
Date:       1999-04-15 12:35:25
[Download RAW message or body]

On Wed, 14 Apr 1999, Matt Koss wrote:

> On St, 14 apr 1999, Simon Hausmann wrote:
> >On Tue, 13 Apr 1999, Matt Koss wrote:
> >
> >> >
> >> 
> >> We should make a distinction between a.) "Save as "  and  b.) "Save link as"
> >> 
> >> a.) is meant for stuff that we are already viewing in konqy, like source of
> >>      HTML page or some picture on this page.
> >>      This function should then manipulate with cache and not do any transfer.
> >> 
> >> b.) this is a well known function from e.g. netscape and it should start the
> >>     transfer in konqy ( either start a slave or ask caitoo for doing it )
> >> 
> >> I am not saying that these two function could not be merged together into one
> >> "Save as" method.
> >> But IMO it would be probably good idea to keep these two separate.
> >
> >Hm, netscape goes like this, if I remember this correctly:
> >In both cases, a) and b) , the well known netscape-download dialog pops
> >up, and in both cases a cached version of the document/image/object is
> >used, if available.
> 
> Let me explain further :
> If the links points to some 22Mb .tgz file , how could Netscape get it from
> cache ? :-))

Well, ... :-)
 
> >
> >Or am I wrong?
> >
> >Nevertheless I think your distinction makes sense in somehow. Maybe you
> >have a nice idea how to implement it?
> >
> 
> I don't think that this requires some big idea.
> a.) Save as - konqy will look in to the html cache and save (actually move)
>       what we need ( image file or html source ).
>       I don't know how cache works for html source. Would this be possible ?
>       Netscape also has the feature called "Save frameset as" and this works
>       for html pages with frames.
> 
> b.) Save link as - konqy will start transfer via KIOJob
>             when we have working cooperation with caitoo, konqy would pass this
>             transfer automatically to caitoo.

Hm, khtml only caches images, no documents. These documents are cached by
KIOCache, and if I understood the comment in kio_cache correctly, then the
caching system will be improved to cache more stuff than just plain HTML
documents via HTTP.

So I wonder where the difference between "Save As..." ("Save Frameset...")
and "Save Link" is, since a) and b) should both use CachedIOJob in
somehow (and Netscape uses its cache for both transfer types as well,
perhaps except for 22Mb tgz's ;-)

I think we could do something tricky: Whenever a view (->the general way)
wants to save an object, referenced by an url, it tells the mainview about
this, but not via the newTransfer event directly, but instead via a
signal (or a different event?) . Then the mainview looks in libkio's
caching pool for the document and saves the document directly. Otherwise
it sends itself the newTransfer event which might either get filtered by
Caitoo or handled by Konqy itself, which then does a simply
KIOJob->copy() .

Or did I miss your point? (sorry, if so)

> Of course, both cases would first popup the file dialog asking for a save name
> ( except when b.) passed to caitoo, then it will depend on caitoo settings )

Hm, ah, you mean that if Caitoo handles the transfer, Caitoo is
responsible for the transfer destination, whereas if Konqy handles it, a
simple KFileDialog should pop up (like in the current implementation) ?

> >> 
> >> Regards
> >> 
> >> 		Matt
> >> 
> >
> >Ciao,
> >  Simon
> >
> >P.S.: I finished (more or less ;) ) the CORBA based transfer stuff in
> >      Caitoo, so it should work now for HTML documents in Konqy. But you
> >      have to either uncomment one line in konq_mainview.cc in order to
> >      fire up Caitoo on konqy startup or to start Caitoo after Konqy.
> 
> Good to hear. Thanks for cooperation.
> BTW when I find some time I will add that little progress widget to konqy
> statusbar and try to make it work :-)

Ah, cool! :-) But tell us when you start working on it, since it's
currently neither possible to embed a widget in an OPStatus nor in an
OPToolbar, and therefore needs further modification in OpenParts.

I have an idea how to do this: We could simply pass the widget's Window Id
over the OPStatusBarIf (OPToolBarIf) and let it then swallow the window
via QXEmbed.
But I'm not sure if this is a really clean solution, perhaps Torben has a
better idea?
 
> Though these two weeks I am kind of REALLY BUSY with my master thesis.

Good luck with it!
 
> 
> Ciao
> 
> 		Matt
 

Ciao,
  Simon

--    
Simon Hausmann       <hausmann@kde.org>
http://www.kde.org/  <tronical@gmx.net>

[prev in list] [next in list] [prev in thread] [next in thread]