lottanzb team mailing list archive

[Severin Heiniger <severinheiniger@xxxxxxxxx>]

On Sat, Oct 3, 2009 at 2:13 AM, eran cohen <shush6@xxxxxxxxx> wrote:
>
>> > SABnzbd indeed offers only warnings through the API - but those
>> > messages are what the user is interested in anyway, so we can still
>> > have the message log window that simply mashes LottaNZB's and
>> > SABnzbd's messages up chronologically.
>
> Yeah, the warnings are the only thing matter for the user... Maybe there
> should be indication that a new warning has arrived on the main window?
> Of course, the indication should be small.

Warnings should definitely be brought to the attention of the user
somehow. Nobody will notice them if they just silently appear in the
message log window. There are two major problems though.

- SABnzbd just offers the raw and translated log message through the
API. So, it's hard for LottaNZB to know what's going on, make a
connection between messages and what they're about. Trying to parse
the messages with fancy regex won't do the trick, as they may be
translated. For example, if the server password is wrong, it would be
cool to have a link that opens the server window or if articles are
missing from a download, one would want to display that directly
within the download etc.  There are tons of examples. I already talked
to Shypike about this and while he agreed with me, he said that it
would be much work to extend SABnzbd so that warnings would be more
meaningful for (non-human) clients. Basically, each warning type would
need an identifier string like "error-server-info-invalid". It should
be accessible through the API along with a timestamp and additional
key-value pairs like "server-name" -> "myserver.com". Something like
that would be incredibly useful!
- We'll need to implement our own indication bar. GTK 2.18 comes with
a shiny built-in infobar class, but this is too new for us. It's
doable though.

However, we probably don't need that right now. Some problem can be
detected by LottaNZB on its own, like if there are no servers.

>> >> == Infobar ==
>> Agree with almost everything except the diskspace item. I'm not sure
>> if it's relevant to be shown in the main window, as SABnzbd should
>> handle it. Just had a talk with one of the devs and he said SABnzbd
>> supports to stop at a certain threshold, say 2GB. It it could be
>>  potentially retrieved from SABnzbd's API. But such info isn't available
>>  through the API as of yet. _IF_ it gets implemented though, LottaNZB could
>>  just give a message or something that downloading and/or processing has
>>  stopped because of low diskspace.
>
> Right now I'm using sabnzbd with Plush UI, and since I'm always out of space,
> it's very comfortable for me to see if the stuff I got in the queue takes more
> space than my current free space. Also, if it queue size is bigger than the
> free space, the indication change it's color and I know I have to free some
> space for the download to complete. I know sabnzbd will pause because of low
> diskspace, but I think it would be great if we help the user avoid this
> situation.
> As it's easy to get the free diskspace and queue size from sabnzbd it won't be
> hard to implement it. If you guys aren't interested in showing it on the main
> window, maybe we can have a dialog letting the user know the queue size is
> bigger than the free space?

I get your point. I'm not sure if it needs to be there all the time.
What about displaying it when the the queue is bigger than the
remaining free diskspace or if 95% of the disk is full? Additionally,
it might not be a bad idea to display a warning dialog/hint (only
once) when the user adds an NZB to the queue and the size of the queue
exeeds the remaining free space.

>> >> == Download list ==
>> Definitely a +1 for the "Details" window. It should have tabs though,
>> like "Files", "Information" and "NFO".
> +2   :)

@Marcel: Want to create an initial version of this window using Glade?
You could use it as a mockup and later on directly for its
implementation. Free your creativity! :-)

>> >> == History ==
>> > That would indeed be a solution. I'm not so sure about the "below
>> > download listview" idea though. While waiting in the queue, a download
>> > gradually moves to the top of the queue and is then downloaded. But it
>> > will move to the middle/bottom of the application window after that.
>  I'll try to create a mockup with glade tomorror to better explain what I
> mean. for now, I'll try to draw it with text. imagine this is the main window:
> --------------------------------------------------------------------
> =========== Toolbar ===========
>
> ===QUEUE - title ================
> download 1 -----              progress bar--  more info
> download 2 -----              info    ---      info
> download 3 -----              info    ---      info
> download 4 -----              info    ---      info
>
> ===Complete Download - title ========
> completed downlaod 1  --- relevant info ---  more info
> completed downlaod 2 --- relevant info ---  more info
> completed downlaod 3  --- relevant info ---  more info
> completed downlaod 4  --- relevant info ---  more info
> completed downlaod 5  --- relevant info ---  more info
> ------------------------------------------  link to complete records
> ============================
>
> Finished downloads moves from the top of the queue to the top of the completed
> download list. the advantage of this is that the active download is always on
> the top of the queue. Also, since we use two different listviews we can show
> different info on the queue listview and on the complete download listview.

While it's probably not the best solution, this is probably the best
idea we have right now. I realized that we really don't need to copy
Transmission's look. First, it's not perfect at all and second, it
would require lots of low-level GTK code. I still think that we could
make the download list a little prettier. For example, we can remove
the progress bar from queued downloads. I might try to create a mockup
too.

>> > If a complete download contains a single video file, one could make it
>> > easy to launch the video directly from within LottaNZB (may be in
>> > future versions).
> We can start with giving the user the option to open the finished download
> directory. I mean, not the global download directory but the actual directory
> of the finished download.

+1.

Regards,
Severin

PS: I've still got two invitations to Google Wave to give away. :-)
Anyone interested?