New FrontRow..

[John Sutherland]

Looks like today Apple released a new FrontRow version. I haven't
tesed fully yet, but at least my plugin still appears in the menu..

I also noticed a new class BRListAnimationDelegate.. Doesn't look
overly important. Thats the only diff I see between the old and new.

I'm really curious about the new AppleTV software.. Wonder how
compatible it'll be with the plugins that exist for the first gen
software. And how compatible with the stuff we're doing here.. And
finally, when are they going to make FrontRow look like the new
AppleTV software...

--John

[Jon Christopher]

Good to know things still work.

Do you have any hints for getting back to the same menu you were at
before hiding FR after showing FR?

BTW, I've committed several updates to PyFR over the last few days.

[John Sutherland]

I haven't had a chance much to play with things.. I might be able to
sneak a night or two in this week.. Definitely some time next week, as
the wif goes out of town for a couple days... A couple things I think
i'll work on.. A simple yes/no dialog (if you haven;t already), and
maybe a file browser (mm.. Maybe with QuickLook?).. I'll also see what
I can do about getting back to the same menu that you left..

--John

--John

[John Sutherland]

It looks like I had some time tonight.. I'm finally going over some of
the code you committed.. I really don't like the idea of importing
everything in the __init__.py.. It may be easier to code with, but it
could cause namespace issues later down the road.. Plus it'll include
more stuff than needed for modules, slowing start time... For example,
I really don't need the menu stuff in my Myth launcher.. I'd rather
import each piece individually.. Its more code, but more explicit..

I'm also going to re-work some of the OptionMenu stuff a bit.. I'm
going to make a OptionItem class, that'll contain the text and the
data together. I don't like trusting indexes to go into 2 different
vars (the text, and the userdata).. If you decide to re-order the
text, you would have to remember to re-order the userdata too.. I'd
rather keep them together..

I'll also take a look at the Menu controller.

--John

On Jan 15, 2008, at 3:12 PM, Jon Christopher wrote:

--John

[Jon Christopher]

John,

A yes/no dialog isn't as simple as that because there's no way to go
into the event loop to wait for a response.

At first I wanted a function:

PyFRYesNoPrompt("message")

but there seems no way to do that, since in order to wait for the
response you'd have to be able to call the event loop in order to
process events.

The closest I've been able to come is the OptionDialog class I checked
in. There are a list of option strings (which could be ["Yes",
"No"]),
and a list of result userdata to be passed to the handler function
(which could be [True, False]).

At first I thought I'd be able to wrap this in a function sort of like

GOT_YES=-1
def OptionDialogResultHandler(idx):
global GOT_YES
GOT_YES = idx==0

def PyFRYesNoPrompt(msg):
# create option dialog
dlg=OptionDialog.alloc().initWithTitle_Items_Handler_UserData_(msg,["Yes","No"]],testOptionDialogHandler,[True,
False])

# show dialog somehow
ShowDialog(dlg)

while GOT_YES==-1:
# wait for events
ProcessEvents()

return GOT_YES==1

but there doesn't seem to be a way to implement ProcessEvents() or
ShowDialog(), so instead I just re-factor
the code so that the action I would take on "yes" is inside the handler.

-Jon

[Jon Christopher]

I could be wrong, but doesn't __init__ only get called if you do:

import PyFR

and not if you do

import PyFR.OptionDialog

?

[Jon Christopher]

As far as OptionItem, you don't really even need a class.
OptionDialog could just expect a list of tuples:

OptionDialog.initWithTitle_Items_Handler("this is the title", [
("Item1", dat1), ("Item2", dat2) ], MyHandlerFunc)

[John Sutherland]

On Jan 15, 2008, at 8:51 PM, Jon Christopher wrote:

> A yes/no dialog isn't as simple as that because there's no way to go
> into the event loop to wait for a response.
>
> At first I wanted a function:
>
> PyFRYesNoPrompt("message")
>
> but there seems no way to do that, since in order to wait for the
> response you'd have to be able to call the event loop in order to
> process events.

With your idea, you could implement a timer, instead of a while loop..
Thats what I did in the launchApp method..

I have another idea though, but I need to play with it first.. No
looping needed if it works.. I'll let you know the results this
weekend... Not sure how much I like as it possibly involves screwing
with the Python stack (readonly)..

As for the other 2 message:

I was having problems when I had all the stuff in the __init__.py,
running my tests.. Blanking out __init__.py fixed it...

I know I could use a tuple, but decided against it, to keep more in
line on how we do menus.. Which I still need to look at...

--John

[Jon Christopher]

A timer is an interesting idea, but I still don't see how it would
work. The key feature modal dialog
like this is that control doesn't return to the caller until after a
response has been given:

if PromptYesNo("Delete all files?"):
DoDelete()

From what I've seen, in order to get user feedback (i.e. respond to
the remote) control has to
leave Python and return to the main FR event loop. In your app
launcher you're waiting for the
*system* to do something (start the app), not the user, so that works.

In every GUI toolkit I've ever seen, modal dialogs have to run an
internal event loop to respond
to events, and I don't know how run FR's event loop. A grep for
modal in the BR headers turns
up something (dev kit is in my home machine), but it didn't look promising.

I'd be more than happy to see pseudo code as to how you think a
timer-based system would work...

-Jon