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