[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:       Matt Koss <koss () napri ! sk>
Date:       1999-03-19 7:38:17
[Download RAW message or body]

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 )
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 file over
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.

>
>>
>>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
4. find the line with the picture name
5. click on it to open individual progress dialog.

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

As I just said, I am opened to the other ideas.
I want to talk about these things and not just make my own decision.
I really want to see KDE as a nice, coherent desktop that allows an
intuitive control.

I am waiting again for comments and suggestions.

Kind regards

			Matt

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

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