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

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

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.

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

>
>Second case is downloading / copying some file in konqueror.
>Some people already suggested creation of the progress widget that would look
>like a list, and all transfers would be added to this list. This progress widget
>would then allow cancellation of these transfers etc.
>I don't want to discourage this idea, but isn't it what kget already does ?
>
>Kget displays a list of the transfers and allows not only cancellation but
>also, stopping and later resuming, scheduling etc. These feature could be added
>also to these special progress dialog, but why create a duplicate code instead
>of using app that has been here for some time and does exactly what we need ?
>
>So instead of creating another semi-functional progress widget, why not use
>kget for these transfers ?
>Kget uses the same kioslaves as konqueror and thus there is no difference in
>the IO operations. Kget has also docked widget and its window can be simply
>shown / hidden on the screen.
>There were already many suggestions for the close integration of kget and
>konqueror and that's why I think that this is the right way to go.
>
>My suggestions do not mean, that apps that allow network transparent access
>would not be able to use kget instead of the little progress widget in the
>statusbar.
>While right now I don't have idea for the app that could utilize it, but I
>agree that some could appear in the future.
>Kget will then work as a gate for the apps that need something to be
>downloaded  and could notify these apps that download has been finished.
>

Yes, I think that is the best.

>
>Subscribing to the pages ( Active bookmarks )
>---------------------------------
>You might know the program called kwebwatch.
>This program allows user to create a list of the websites that he want to watch
>for update.
>Kwebatch connects to these sites and checks, whether it was updated.
>
>I have already suggested to the author, that I would really like to see his
>program integrated very closely with konqueror.
>Instead of creation of the list, user could do something like subscribing to
>the site ( that's how it is called in IE, Netscape has a similar feature too ).
>
>IMO, it should be integrated with a current bookmarks. User would then select,
>whick bookmark he wants to have watched for an update.
>How exactly it should look I leave to the other users, I don't have any special
>idea ( maybe some marks / stars in the bookmark menu, or some indicator in the
>toolbar which would change when there is something new and by clicking on it
>user could select the bookmark from the list of bookmarks that changed )
>

That sounds very interesting.
Activating/deactivating watching could be done via the properties of the
bookmarks.

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]