Closed GoogleCodeExporter closed 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
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
Original comment by de...@battams.ca
on 9 Apr 2013 at 2:12
Original issue reported on code.google.com by
de...@battams.ca
on 27 Oct 2010 at 3:28