Re: Nautilus epiphany integration & file transfers

[Michael Henson <mike axl net>]

On Mon, 2005-06-20 at 12:21 +0200, Alexander Larsson wrote:
> On Fri, 2005-06-17 at 14:04 +0200, Rapha�Slinckx wrote:
> > 
> > > 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.
> 
> RDF? Configuration? huge panel applet?
> 

I haven't worked on the project for quite some time and it was honestly
just a melting pot for ideas of how something like this might be done
generically.

I really do think that RDF is the way to go here. It is nice an
extensible which is perfect for storing extra pieces of metadata about a
task that might be useful in the final display of the task to the user.

The huge panel applet isn't totally necessary though. I happened to like
it as it gave a global overview of what was going on, but the system is
not dependent on it in any way. It just uses some widgets from averti
and reads its data from the sample daemon, so it could easily be
replaced with something that was much simpler.

I'd be totally open to suggestions for better/simpler ways of doing
this. In light of recent discussions I'd be interested in starting up
work on it again.

-- Michael