tel8618217223380 / sagetv-addons

Automatically exported from code.google.com/p/sagetv-addons
0 stars 0 forks source link

Various task queue display issues #175

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
First, it seems more natural to me to display the task queue as a table.  So 
when you first click on "Show Task Queue" then you'll get something like this:

QID   TASKID   CREATED                STATE
=================================================
22    COMSKIP  2010-10-22 16:45:00    WAITING
25    ARCHIVE  2010-10-22 17:11:32    RUNNING

The text colour of state could be red for waiting, green for running and yellow 
for returned.

Then clicking a row would present the view that you currently have.

For that view, I'd make the following changes:

* Remove RMI port, server host and server port.  Those are internal values only 
and will never change (i.e. the server is always going to be the SageTV server 
the user's STV is connected to - it has to be.  Those values are in support of 
the case where there are multiple Sage servers that a task client can talk to, 
such as a testing env).

* I'd move Queue ID to the top of the list above state or even better I'd make 
the left hand button a concatenation of QID + "-" + TaskId so you'd end up with 
some like 127-COMSKIP.

* Started/Completed: If null then display anything other than "null" :)

* Date values: Reminder that all three date values are read only

* Client: If the client is null then I'd display "None" or something instead of 
just a blank.

* Metadata: ServerClient.getMetadataForTask(QueuedTask) has been made available 
for the next build to allow you to query the metadata for QueuedTasks.  I 
assume clicking that button will popup a display of the returned map?

Original issue reported on code.google.com by de...@battams.ca on 27 Oct 2010 at 3:28

GoogleCodeExporter commented 9 years ago
Addressed in the next build, with the following comments:

Regarding the first issue on the format of the menu.  You have two votes and I 
have one on this project :)  My vote goes to keeping it as is for the following 
reasons.

1. Consistency with the other SJQ menus.  I think the more consistency between 
menus (i.e. similar formats and functions) the better.
2. Consistency with the rest of the default STV.  Same idea as above, by using 
the same menus layouts the "look and feel" of SJQ stays consistent with the 
default STV.

I have no ego so if you want me to change it I will, this is your baby :)

Regarding the idea of using the QueuedID as part of the left-most column.  I 
like the idea but QueueID is a long.  I think you were thinking about the 
TaskID which is a String?

Original comment by tom.mira...@gmail.com on 30 Oct 2010 at 6:21

GoogleCodeExporter commented 9 years ago
We can leave the format as is for now.  I think we'll have to wait and see what 
user feedback is on this when we get to public beta.

I would like to see the QID put together with the TaskId for something like 
this on the left side:

10-COMSKIP

QID is a long, but Long.toString(long) will convert it. :)  The only reason I 
mention this is because without the QID you're going to end up with 10 
different tasks named "COMSKIP", each one represents a different recording, but 
there's no way to tell them apart other than through the QID and the metadata.

On the same topic, I think I'm going to add a special metadata key that can be 
optionally set that allows a description of what the task is doing.  For 
example, a COMSKIP task might set this special value to "Comskipping 'The Daily 
Show With Jon Stewart'" or whatever.  And then we can incorporate that into the 
STV screens.  Haven't put much thought into it yet, but that's my initial 
thinking because there's currently no way to know what object a task is working 
on (other than looking at the metadata).

Original comment by de...@battams.ca on 30 Oct 2010 at 6:46

GoogleCodeExporter commented 9 years ago

Original comment by de...@battams.ca on 9 Apr 2013 at 2:12