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

List:       kfm-devel
Subject:    Re: Save as ( was Re: popup menus )
From:       Matt Koss <koss () napri ! sk>
Date:       1999-04-15 17:01:18
[Download RAW message or body]

On Št, 15 apr 1999, Simon Hausmann wrote:
>> 
>> 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)

My point is that in Netscape these two functions are different.
The main difference is that "Save as" is meant for a stuff that already has
been downloaded ( e.g. the HTML page that we are viewing is already displayed
together with all the images etc. )
While "Save link as" will start saving stuff that is NOT already downloaded and
thus Netscape has to start new transfer for this.
This applies also to the RMB popup menus. When you right click on some image
fin the HTML page and this image is also link to some file ( usually in some
galleries, maybe some HOT stuff :-)) ) , you will get popup menu which will
contain also two items - "Save image as" and "Save link as".
The first one will simply save the image, while the latter will save the file
that the link is pointing to. Do you follow ?

That's for Netscape view on these two functions.

For konqueror we could merge these two things, but I still think that we should
keep them separate. Why ?

Imagine the above situation - you right click on some image in the HTML
page, which is also a link to some file.
You will get RMB menu with item "Save as". But what do we want to save ?
a.) image
b.) file that this link is pointing to
c.) HTML Source of the page

I suggest to create these items :

1.  Save document source + Save frameset
     - these two would be only in the main menu

2. Save as - this would be in the RMB popup menu when we right click on
                   something that can be saved ( except the link )              
           function : save what we are on ( usually some image on the         
                       HTML page, no idea what else could this be )

3. Save link as - this would be in the RMB popup menu when we right click on
                   some link        
           function : save what the link is pointing to ( 22Mb .tgz file :-)) )

StarOffice adds also function "Save background" - this saves the background
image from the page.

BTW I really like the central gallery in StarOffice. IMO there are some really
good ideas in this desktop suite.


>
>> 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) ?

Exactly.
Konqy could popup file dialog also before caitoo does it, but this would
supress some features of caitoo ( e.g. default directories, expert mode ).

>> 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?

Well I am not yet engrossed in open parts yet :-)
Did you see how I did it in caitoo, while testing ?
BTW I send some mail a while ago explaining these progress widgets.

It still needs some tweaking, e.g when there are several html pages loading in
one konqy window, widget will have to be shared between these and display
only progress for the active view.

But don't worry, I will not add it tomorrow. Have some things to do .... :-)

> 
>> Though these two weeks I am kind of REALLY BUSY with my master thesis.
>
>Good luck with it!

Thanks

		Matt

--
Matej Koss	e-mail: koss@napri.sk
Kosice		ICQ#  : 19344305
Slovakia

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