Re: [gnome-network]downman description

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

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

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]