> I'm not sure of all of this. I think it over-emphasises the download > aspect in the file manager both in terms of the screen estate used and > in using animations to constantly bring your attention to something. Okay after long discussions on IRC with mpt, the gui guru i have been convinced it is Not A Good Thing, at least in part ;) > I agree that the current progress display in nautilus isn't all that > great. I'd prefer if all progress operations could be collected in one > dialog, and that you could easily hide it when you didn't need to see > it. But it should still somehow be easy to see the progress and bring it > back. It would be very nice if other applications could integrate with > this so that downloads in epiphany and firefox where visible too, and > other slow file operations that third party apps do. > Like mpt remarked the current dialog is awful, and the simple fact it is a dialog and not a window, is quite a problem, since you can't minimize it, you can't make the destiantion folder appear over it, things like that, is it done like that on purpose (window vs. dialog) ? If it's an easy fix, i might give it a shot to at least make it more bearable.. > I think a nice system would be if all slow file transfer operations in > the system (say longer than 3 seconds) showed up in a shared dialog that > pops up when each new download starts. You can see each current file > transfer, either in a collapsed state where you see estimated time left > only, or in a more detailed state where you see things like download > rate, current amount downloaded etc. If you hide/close the progress > window it shows up as an icon in the panel (similar to e.g. the > NetworkManager applet or the battery applet). You can tell from the icon > if its downloading or if its finished, and if you click on it you get > the progress window back. > > Actually, I'm not even sure such a progress dialog setup need to be > implemented in nautilus. Maybe nautilus is just a user of the progress > subsystem, just as epiphany is. In the comments of my blog post, someone talked about his project (or maybe it was someone else's project) http://gtask.sourceforge.net/ http://gtask.sourceforge.net/averti/averti.html It appear quite un-active, but it if more for the idea that i come up with this. Would it be generally accepted to have that sort of thing included with gnome desktop ? Let's say a library you can link against, containing simple hooks to add/remove/modify long-running tasks, with maybe a way to add retro-action, for example cancelling things . nautilus , and epiphany, and gaim file transfer, and others would be client of such a thing (it would be a dektop service listening on dbus for example, launched with the desktop). When a transfer starts, the window show up with all pending transfers, you wan hide it and it goes in your tray panel, allowing to come back to it if you need to. If you let it open, it's more or less like the actual progress window, except that it would stack acive and upcoming transfers in a single window. From a nautilus point of view, i suppose it would simply mean changing calls to gtk, to calls to that library, that internally would be transmitted via dbus to that daemon, that in turn would show it's window if any active download exist, or create a new one.. Now this thing can be gnome-specific (allowing nifty gnome features), or not (cross desktop, but i like that less) It can be simple , just showing a progress dialog like now, with total, current action, etc or it can become very complicated like they are doing, maybe just starting simple and add more things later if need be is preferable. This woudn't concern nautilus directly, but eventually would mean getting rid of the current progress dialog, so i ask here would that be acceptable desktop-wide notification of tasks, pluggable, etc. If yes, i want to invest some time to do that, and eventually provide patches to nautilus, epiphany and any other app that could use that. if not, well , there must be a serious reason :) > Having emblems for files being downloaded sounds nice, although I'm not > sure of the exact use case for this. However, I don't think animating > them or showing percentage on them makes a whole lot of sense. You don't > generally keep a whole filemanager window around scrolled to a specific > file just to see the progress of the download. Furthermore it introduces > lots of complexity and slowdown in the core file manager for a sort of > fringe "cool effect". Actually, maybe the download emblem will be sort > of confusing if not all forms of downloads/transfers will use it. For > instance, is it obvious to people that a file being downloaded from > epiphany is a "download", but not a slow copy of a file with nautilus > from an ftp site, or a slow usb flash memory? Concerning the emblems i didn't change my mind yet, even macosX has these, so it must be a Good Thing :) Animating them i wouldn't like it, but showing a simple progress, for example with 10 different steps would be very useful to have a direct feedback on download progress for a "single-file-i-want-to-view-now-but need-to-know-when-it's-done" Emblem aren't a good solution for this since the different progress emblems are presented to the user in the emblem chooser. What i would like to do is create special "hidden emblem" that i can use, or maybe integrating directly in nautilus an API for setting progress through FileInfo properties. I have seen in GTK 2.8 that they have a new cell renderer that does progress using a progress bar, maybe it can be used instead of an emblem ? Using a core nautilus API would allow to use it for regular, but slow, transfer that nautilus do, like you say when transfering from usb or network, beside pure downloads. Now if it's a srict no, maybe just adding a way to use hidden emblem would allow me to create a separate extension that either i package myself, or that is installed along with epiphany.. would that be accepted ? > About the epiphany:// stuff and using gnome-vfs/nautilus to do the > actual download. I don't see the point. Epiphany can do the download > fine itself. We just need an API where you can tell the nautilus about > the download state. Forget, that was crazy stuff, you're right !
Attachment:
signature.asc
Description: This is a digitally signed message part