[gpodder-devel] Changing downloads tab to actions tab?
- From: thp at perli.net (Thomas Perl)
- Date: Thu, 31 Jan 2008 11:43:03 +0100
Hello, Daniel!
On Wed, 2008-01-30 at 11:57 -0500, Daniel Finnie wrote:
> I've been using gPodder for a few weeks now and it is definitely the
> best podcast client I've used on Linux, but that's not to say the
> software is without flaws. The biggest thing about gPodder that I
> would like to see improved is the modal feed checking, file
> downloading, and file transfers to an MP3 player. I don't see a
> technical reason why the application can't transfer an episode to my
> MP3 player while I click around to find other episodes to transfer.
I can see some reasons:
* Delete episodes in the GUI while they are being transferred
* Selecting episodes in the GUI, then lose the selection, because
the tree model is updated as a result of a feed cache update
Also, downloading isn't modal and never was - you can close the episode
dialog and the download continues in the background.
> Much like the downloads are handled now, I would add options to select
> how many concurrent transfers are allowed and how many concurrent feed
> updates are allowed. Possibly, a "total concurrent actions" option
> could be implemented.
I don't see the point in "total concurrent actions", because limits are
there to make up for bandwidth and processing restrictions (only one
download because of small bandwidth, only one transfer, because the
bottleneck is the USB device's storage, not the copy algorithm).
I see the point for a "total concurrent downloads" if we decide to make
the channel feed update parallel (something that is planned for the
April 2008 release). Do we really need to transfer episodes in parallel?
> I see this as a huge benefit as it allows:
> - Users with fast Internet connections to update multiple feeds at
> once.
Sure, updating the feed cache in parallel is something I wanted to
implement for some time now (and has also been requested), but due to
lack of time, there has not been an implementation yet. Also, I thought
about not displaying the feed update in the "Downloads" tab but directly
in the channel navigator (the left panel), maybe with an animation or
the "refresh" icon as emblem on the channel cover, just as we do now
with the "played" and "locked" status on episode icons.
> - Users would be able to pick one file to transfer to an MP3 player
> and have it transfer while browsing around for another file to
> transfer.
The code can get much more complicated and buggy, because we have to
make sure to avoid race conditions, such as the one mentioned above
(sync A, B, and C; while A is still syncing, delete B in GUI; what does
the sync process do?). The "Ctrl+S" sync mode automatically syncs all
your unplayed episodes (if you have configured it do to so) to your
player without having to manually select which episodes to transfer.
> The only drawback I can see is the additional coding required, however
> I don't think it is too intensive. When the user requests a feed
> update, it will add itself to the queue and start executing if the
> max. concurrent feed updates has not been reached. When a feed update
> completes, it another feed update so long as there is one to update.
>
> In addition, threads will probably have to be used if they are not
> already. Because gPodder is not cross-platform, I don't think this
> will be too much of a problem.
Threads are already used for some parts of the code. As much as
possible, I want to avoid threading, as it brings in many nasty problems
and invisible bugs.
I don't know if a possible buggy and hard-to-debug gPodder is not a too
high price to pay for small things like non-modal MP3 player sync.
> So, finally, if I wrote up the code that implemented the above
> suggestion, would it get merged into the gPodder trunk? Or is there a
> reason that this was not done already?
If the implementation is nice and clean, and if you keep sending the
patches while you are developing, why not? Best would be if you could
send your changes step by step, so that we can review it and give some
comments and maybe partially merge it into the codebase.
If you develop three weeks or so behind closed doors and then come up
with a huge patch, it is a PITA to apply and merge the patch, because
it probably grew huge in the meantime.
Please, feel free to try to implement the features you requested (apart
from the "total concurrent actions" feature for reasons mentioned above)
and send in patches. I'd really love to see this in gPodder! :)
Thomas
Other related posts:
