> 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.ascDescription: This is a digitally signed message part