Re: [gnome-network]downman description

[Manuel Clos <llanero eresmas net>]

Rodney Dawes wrote:
> 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

This needs fixing, because both are properties but apply to different 
"objects". It will be great if someone can provide a different icon, but 
then it won't be themeable. I was thinking to use PROPERTIES and 
PREFERENCES so that they are different.

> another icon is scaled up from a smaller version to fit the toolbar's

I will love the author to make a better one :)

> 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

Well, it make sense to me. I have seen it on others apps. Perhaps "List" 
is a better name?

> much more useful to group things by server in a treeview, rather than
> having a bunch of tabs, automatically.

Umh, I disagree here. Having a treeview with one branch for server is 
not really helpful. You don't need to have a bunch of tabs. I will 
repeat again that this is optional, that you are first presented with no 
tabs, this is, just the default project/list, tabs will appear if the 
user wants to separate downloads in different projects/lists.

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

Oh yes, I was thinking on having slow access to a machine that runs the 
daemon and has *real* bandwidth.

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

But why do you want to complicate it in that way? what's the problem of 
running just one daemon??  Or lets say, what are the benefits of running 
multiple daemons for the same user? Aren't you complicating it?

> 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

I was only offering you to help with the code. This also means helping 
with the gnome-vfs and bonobo stuff, since you said that you are moving 
code around and you have experience with it. You were rewriting / 
restructuring it, isn't it?

> 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

I will try it and see for myself :) At the beginning I didn't even know 
C! Then I learned GTK, ... What will stop me from learning gnome-vfs? I 
even have experience on dealing with http / ftp connections, so I can 
try to debug gnome-vfs if anything goes wrong, add missing features like 
being able to cancel, resume ...

I just wonder if you have such big experience with gnome-vfs why 
emphetamine has the problems you say. Don't blame gnome-vfs, fix it.

> 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

Well, if it doesn't support resume we can add it. It seems logical to me 
that gnome-network people fixes gnome-vfs network related stuff.

> of these correctly yet. It kind of does cancelling, but it frequently
> breaks.

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

No. It is just that downman + gnome-vfs + bonobo is more complete than 
emphetamine. You also need to port/move it to gnome-network. So why not 
move downman and get more features with the same pain?

Also, that recently you haven't dedicated much time to emphetamine 
development (as you said in a mail). And you said that you are currently 
very busy.

Have you any particular disgust with downman? :)

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

It isn't a matter of doing it asynchronous, I'm doing it asynchronous. 
But when a connection is slow, the daemon shouldn't send non-important 
data, and also the GUI should do some tricks while it gets the 
confirmation of some property being applied.

I also have speedups in the TreeView suggested by Kris and Owen that 
really help when you have more than 5 items on a list, because you are 
constantly refreshing the % done and the downloaded size. I have found 
bugs in the TreeView and helped to squash them. Look at bugzilla.

I wish every app dedicates lots of love to the GUI as Apple developers do.

Arging that I don't have experience with gnome-vfs isn't the way to go. 
I have been contributing to gnome for some time in lots of differents 
projects, learning different technologies.

Have you looked at downman? have you any problem not spotted by Rodrigo? 
If so, I will love to know.


--
Manuel Clos
llanero eresmas net
http://llanero.eresmas.net