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

List:       kfm-devel
Subject:    Re: Progress widgets vs. kget and konqueror ( Was: Re: kiolib and little .. )
From:       Matthias Welk <welk () fokus ! gmd ! de>
Date:       1999-03-19 15:33:56
[Download RAW message or body]

On Fri, 19 Mar 1999, Matt Koss wrote:
>On Št, 18 mar 1999, Matthias Welk wrote:
>>On Thu, 18 Mar 1999, Matt Koss wrote:
>>>Hello,
>>>
>>>here are some of my thoughts about how the things should be in the future.
>>>
>>>It covers progress widgets vs kget + konqueror integration and subscribing to
>>>the pages ( active bookmarks ).
>>>
>>>Displaying of progress :
>>>-------------------
>>>KDE is network transparent and thus allow people to work with files in kfm as
>>>if they were on the local disk. Users click on some GIF file and kview pops up
>>>together with a progress dialog for a copy operation.
>>>This is useful also for many other file types ( e.g. text files ). Progress
>>>dialog for this operation usually has a short life ( I know that it depends on
>>>the speed of connection and the size of this file ).
>>>
>>>However, the same progress dialog appears when user copies / downloads
>>> some file from the remote site. This progress dialog will probably have
>>>longer life then the previous ( again it depends on the size and speed ).
>>>
>>>My idea is, that we should make a big difference between showing progress for
>>>these two types of transfers.
>>
>>Why should we do that ?
>>Downloading/copying via nfs may take a long time too. As you already said, it
>>depends on the size and speed. Just imagine you have a slow file system and a
>>very fast internet access, then it may happen that the life time of the process
>>dialogs are nearly the same.
>
>You are right, but my reasons for making a difference are not only lengths of
>life of these progress dialogs.
>The main reason is the KDE way of network transparency.
>Let's imagine kview getting some file from remote site :
>1. User clicks on some image file in the kfm
>2. kview pops up
>3. IO operation is started and progress dialog is opened.
>   This operation will copy this image file to some temporary location - e.g.
>   /tmp/gajhgdadgqwdh
>
>Users who have a fast Inet connection probably will not care too much about
>this.
>But how about the other ones using dial-up ? ( I am one of them actually )

I'm one of the lucky guys that have an callback at home and a fast internet
access at work ;-)

>This way of transparency is maybe fine for a small pictures and text files, 
>but I can't imagine starting a kghostview that will download a 4Mb ps fileover  
>the net. 
>Instead, user will usually copy this file to some local place and then open a
>kghostview with this file.
>
>So far it seams, that this transparency is definitely meant for a quick view on
>the file and later user can decide whether save this file or not.
>
>I understand that people with a fast connection will probably think totally
>differently. They might want just the way the transparency is implemented right
>now.
>
>On the other side, for these files are most functions that kget offers useless.
>Again imagine kview getting file over the net. It's definitely not reasonable
>to stop this transfer and later resume it ( e.g. root can erase tmp directory
>and files get lost )
>The only reasonable operation for this transfer seems to me the cancellation.
>That's why my idea of stop button for all such apps.
>I' am not saying that this button has to be in the toolbar of this app and
>confuse users. It could be a part of the little progress widget in some way.
>I would even say, why not simply close the app's window. What would it be good
>for after stopping the transfer anyway.
>

Ok, I understand your intention.
How about an option, that let you specify if you have and dial-up network or
not. If you choose this option, then all remote files that would normaly
downloaded temporarly should be stored in a user defined directory.
May be the user could specify file extensions that should be stored in this
directory and all other file would be downloaded temporarly.

>>
>>>
>>>As for the first case, I have suggested already creation of the little progress
>>>widget that could be embedded in the statusbar of the app. This little progress
>>>widget would be used also in konqueror when loading the HTML page.
>>>For konqueror it will be a combined widget that shows progress as a total
>>>number for all text + pictures + applets + whatever gets loaded for one HTML
>>>page ( this means many files in the one widget ).
>>>For other applications this little progress widget would be used probably only 
>>>for one file.
>>>Applications that allow network transparent access should all contain a stop
>>>button as in the konqueror. This would solve problem when user wants to stop 
>>>loading of the file from a remote site.
>>
>>But it's really strange if kedit would have a stop button. What would it be
>>good for - stop typing text (from the user point of view) ?
>>If the application uses kget to get the file, then you can cancel the request
>>in kget. IMO there is no need for an extra button, especially because kget
>>gives you the possibility to open its own progress dialog for every new
>>copy/download.
>
>See the above explanation.
>
>I don't like your idea about use of individual progress dialogs for such
>things.
>Let's imagine what user would have to do :
>1. click on some picture file in kfm
>2. wait for kview to start
>3. wait for the transfer to be registered in kget window

Kview could specify that the download progress should have its own dialog
(controlled by kget).

>4. find the line with the picture name
>5. click on it to open individual progress dialog.
>

[...]

>I really want to see KDE as a nice, coherent desktop that allows an
>intuitive control.
>

That's 100% my opinion.

Greetings, Matthias.
--
---------------------------------------------------------------
From: Matthias Welk                   voice: +49-30-3463-7272
      GMD Fokus                       fax  : +49-30-3463-8272
      Kaiserin-Augusta-Allee 31       email: welk@fokus.gmd.de
      10589 Berlin
----------------------------------------------------------------

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