lottanzb team mailing list archive

[Sander Tuit <avirulence@xxxxxxxxx>]

I really like the infobar. And I'd like an invitation to Google Wave ;-)

I'm not sure I'd like the finished downloads to be separated from the
queued items, but I'll think about that.. Some more constructive
criticism coming soon!

On Wed, Oct 7, 2009 at 21:14, Severin Heiniger
<severinheiniger@xxxxxxxxx> wrote:
> 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?
>
> _______________________________________________
> Mailing list: https://launchpad.net/~lottanzb
> Post to     : lottanzb@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~lottanzb
> More help   : https://help.launchpad.net/ListHelp
>