Re: [gnome-network]downman description

[Rodney Dawes <dobey free fr>]

Il lun, 2003-09-22 alle 14:52, Manuel Clos ha scritto:
> Rodney Dawes wrote:
> > I don't like this idea, actually. It makes for a very complicated UI,
> > and then you will need a complicated API to support it. "I have to
> > create a /project/ to download a file?"
> 
> No. As I said in the description mail, when you start downmand for the 
> first time ever it will create a default project, so you can start working.
> 
> Also:
> 	- You can't delete the last project from the GUI
> 	- If you manually remove the .downman dir (so this mean the default 
> project), it will be recreated.
> 
> So there is not such complicated UI, just show tabs when you have more 
> than one project. And there is no such complicated API to support it.
> 
> Downman has been written to be user friendly :)

Looking at the screenshot(s), it seemed to be quite overly complicated.
You also have two buttons in the toolbar with the exact same icon. And
another icon is scaled up from a smaller version to fit the toolbar's
icon sizing. The HIG also recommends very strongly against the use of
tabs. As "Projects" stand, I don't see how the terminology makes any
sense to be associated with transferring files. It would probably be
much more useful to group things by server in a treeview, rather than
having a bunch of tabs, automatically.

> > As emphetamine stands, it has absolutely no need to be able to do
> > something like this where you would connect to either a local or remote
> > backend. You simply just do the necessary stuff, and with the file
> > chooser that it's using from libelysiumui, you can just browse to other
> > machines, and use ssh, ftp, http, smb, or some similar method to just
> > save the file to the other machine, rather than your own. I've tested
> > it quite a bit by downloading most of ftp.gnu.org this way, and it
> > worked great. The only problems came when gnome-vfs would trip over it's
> > own feet.
> 
> Umh, it is not a matter of browsing other machines. You connect to the 
> daemon running on another machine, so you should see what the daemon can 
> see and not what your local user can see. This is one of the reasons I 
> didn't started to implement it. I don't know if it is worth it.

Uhm. I highly doubt you are going to be running a daemon on a remote
webdav or ftp store. You certainly aren't going to be running one on
mac.com. I think you missed the entire point of my paragraph, which was
to say that you can transparently transfer things from one remote box,
to another. It has nothing to do with a daemon on a remote machine,
other than the fact that it completely removes the need for such a
thing.

> > Right. We will need to handle multiple display cases though, so that
> > we can have per-display daemons, so that everything works happily.
> 
> I don't agree here. I have a list of downloads. I want to see the *same* 
> list of downloads no matter from where I'm logging as far as I login as 
> the same user. Have I misunderstood you here?

But you need to handle the fact that the display is not the same. It is
very easy to shove the list of downloads in an xml file, and have some
watch set on that file so that whenever it changes, all running daemons
get the updates. It's basically the same way a cache system works.

> > Emphetamine doesn't do this currently, but it has been planned for some
> > time. I just have not had much time to do work on emphetamine and finish
> > getting it ported to gnome2 and adding such features.
> 
> Wouldn't you switch to help if I do the gnome-vfs and bonobo stuff?

But I've already done 90% of the gnome-vfs and bonobo stuff? Why should
I "switch" and let you do it all again from scratch, when you clearly
don't have the experience with gnome-vfs and maybe bonobo needed to do
it right? Switching to gnome-vfs is NOT EASY. I can't stress that
enough. Managing queues and dealing with the async API and lots of stuff
is just not fun. There is the other problem of the fact that the async
vfs API is not cancellable, afaik. I'm also not sure about the resume
abilities of gnome-vfs. This is nominally why emphetamine does neither
of these correctly yet. It kind of does cancelling, but it frequently
breaks.

> I'm currently working on downman, polishing it and adding features. So 
> there is no problem doing the same work inside gnome-network.

And what exactly is the problem with something else being done inside
gnome-network? There are many download manager to choose from. Is there
some particular disgust you have with mine?

> > The UI is the trivial part, and most if not all download managers, have
> > roughly the same UI.
> 
> I didn't think so. I have put lots of love and time in the UI. And I 
> still need to switch from a list to a tree to be able to display the 
> threads along the download. You also need some way to keep synchronized 
> with the daemon without feeling sluggish.

Comparitavely speaking, from experience, the UI is definately the easy
part of a download manager. If you don't want to be sluggish, then the
communication needs to be asynchronous.

-- dobey