New modules...

[John Sutherland]

I went ahead and created a FileBrowser controller. I ended up having
to also create a "DynamicMenu" class, instead of use the current menu
class. The reason why is that I dind't want to have to build the
entire tree ahead of time, since that can get a bit intensive.. I also
added a new AppLauncher Controller, and add the ability to launch an
app with a file (Application must be AppleScript-able..)

This answers the call for a VLC launcher.. In fact thats what I used
to make this..

I'll add an actual pkg file for it in a bit here.

--John

[Jon Christopher]

John,

Cool, I'll check this out. I've posted my EyeTV plugin on google code
at http://code.google.com/p/pyetv/,
with due credit, of course, and the SVN for PyeTV uses PyFR as an
external repository.

I made some changes to the MenuController class so that it will
optionally display text at the right side of the menu, which I use
to display the count of recordings for a given series. One of the
outstanding issues with this is that if a recording is deleted, the
count text doesn't change since Front Row doesn't call the function to
request the item text again. Perhaps some technique you
have developed for your DynamicMenu class will help with this.

I've still been pounding my head against the problem of getting Front
Row to go back to where I started after launching an app.

I want this so badly b/c the main "play a recording" option dialog has
options like:

Play
Restart
Delete

and the most natural thing in the world after playing a TV recording
is to want to delete it. Pressing "pause" while a recording is
playing *should* return you to this dialog.

I've tried several variations, but I run into the problem of not being
able to find a valid controller stack when in the FRWasShown
callback in a subclass of WaitController. Before hiding FR,
WaitController.stack() is valid, but after hiding FR,
WaitController.stack()
is none.

Any ideas?

Cheers,
Jon

with the EyeTV plugin is that when a recording is deleted

[John Sutherland]

> Cool, I'll check this out. I've posted my EyeTV plugin on google code
> at http://code.google.com/p/pyetv/,
> with due credit, of course, and the SVN for PyeTV uses PyFR as an
> external repository.

Cool, I'll add a reference on the front page for ya.

> I made some changes to the MenuController class so that it will
> optionally display text at the right side of the menu, which I use
> to display the count of recordings for a given series. One of the
> outstanding issues with this is that if a recording is deleted, the
> count text doesn't change since Front Row doesn't call the function to
> request the item text again. Perhaps some technique you
> have developed for your DynamicMenu class will help with this.

Yeah, its a bit easier to do dynamic stuff.. More or less, I just
added a flag onto the MenuItem that says its a 'folder'.. And when we
get the selectedItem, I check that to see how I want to handle it..
the other nice thing I do is that I pass the MenuItem selected,
instead of just some data. This way, you can store whatever you want/
need in the MenuItem, and it'll all get passed along..

>
>
> I've still been pounding my head against the problem of getting Front
> Row to go back to where I started after launching an app.

I haven't tried anything yet.. I've been thinking about improving the
FrontVLC stuff, so that it has more menus (settings, multiple
directories, etc.), so something like this might be useful..

>
>
> I want this so badly b/c the main "play a recording" option dialog has
> options like:
>
> Play
> Restart
> Delete
>
> and the most natural thing in the world after playing a TV recording
> is to want to delete it. Pressing "pause" while a recording is
> playing *should* return you to this dialog.
>
> I've tried several variations, but I run into the problem of not being
> able to find a valid controller stack when in the FRWasShown
> callback in a subclass of WaitController. Before hiding FR,
> WaitController.stack() is valid, but after hiding FR,
> WaitController.stack()
> is none.
>
>
> Any ideas?

The only think I can think of right now is to save a copy of the stack
before we hide FR, and then "replay the stack", pushing each
controller once we come back.. But we might lose the state of the
controller or something inbetween, so I'm not sure how that would work.

--John

[Jon Christopher]

On Jan 20, 2008 4:20 PM, John Sutherland <gari...@gmail.com> wrote:

 

The only think I can think of right now is to save a copy of the stack
before we hide FR, and then "replay the stack", pushing each
controller once we come back.. But we might lose the state of the
controller or something inbetween, so I'm not sure how that would work.

I've tried that.  At first, I thought the stack items I had saved were no longer valid. 
I'm not sure if _hideFrontRow actually pops them off the stack, and if it does if
that means that they get garbage collected/otherwise freed.  (I don't really grok objc yet,
so I'm fumbling around in the dark quite a bit).

Now I'm not so sure that was the problem at all, as I've realized that I can't figure out how
to get a valid BRControllerStack to push controllers on to.  Apparently _hideFrontRow is
not only popping the stack, but also deleting the stack itself.

WaitController is itself a controller, and the FRWasShown function is defined in this controller,
so you'd think self.stack() would return a stack.  It does before hiding front row, but not after
it's shown again.

So when the FRWasShown function is called, I don't know which controller is currently at the top of
the current controller stack, or how to get a valid stack to operate on.  If I had a stack, I could
push the appropriate controllers onto it.

[John Sutherland]

I got bored at work today, and played a little bit with some "new"
ideas, in an effort to get around all this.. Its not complete, but I
think I'm close..

Instead of using the hide/unhide functions, I switched to something
else I stumbled on:

displayManager = BRDisplayManager.singleton()
displayManager.releaseAllDisplays()
displayManager.fadeOutDisplay()

and

displayManager = BRDisplayManager.singleton()
displayManager.captureAllDisplays()
displayManager.fadeInDisplay()

This -almost- works... I happen to run 2 screens (MBP w/ external
monitor).. What normally happens is that FR takes over both
displays... With this code in place, when I launch the app, it
releases my non-primary display, but keeps my WaitController active on
the primary.. And it puts the VLC app in focus, but *behind* the
WaitController... I can press keys that are active in VLC, and they
take affect.. I just can't see it.. When I exit VLC with apple-Q, it
returns back to taking over both screens, and sits at the
WaitController, until I hit exit..

So this means, if we can figure out how to hide that WaitController, I
think we'll have it licked.. It'll come back right to where you left
off..

I'll try to do some more experimenting tonight, and over the next few
days.. The wif is out of town, so I have some extra time :)

--John

On Jan 21, 2008, at 12:50 AM, Jon Christopher wrote:

> I've tried that. At first, I thought the stack items I had saved
> were no longer valid.
> I'm not sure if _hideFrontRow actually pops them off the stack, and
> if it does if
> that means that they get garbage collected/otherwise freed. (I
> don't really grok objc yet,
> so I'm fumbling around in the dark quite a bit).
>
> Now I'm not so sure that was the problem at all, as I've realized
> that I can't figure out how
> to get a valid BRControllerStack to push controllers on to.
> Apparently _hideFrontRow is
> not only popping the stack, but also deleting the stack itself.
>
> WaitController is itself a controller, and the FRWasShown function
> is defined in this controller,
> so you'd think self.stack() would return a stack. It does before
> hiding front row, but not after
> it's shown again.
>
> So when the FRWasShown function is called, I don't know which
> controller is currently at the top of
> the current controller stack, or how to get a valid stack to operate
> on. If I had a stack, I could
> push the appropriate controllers onto it.

--John

[Jon Christopher]

I tried something simliar and got about the same results;  however in the experiments I did,
the control of the remote still remained with FR, from what I could tell, so that's another issue to consider.

One thing which may be instructive is using EnableObjcLogger in Debugging.py.  When this is enabled, it looks for a file /tmp/FRLOG,
and if/while it finds that file it writes out *all* objective c messages sent to a file in /tmp/msgSends-<PID>.

I generally do something like:

  touch /tmp/FRLOG; sleep 2; rm /tmp/FRLOG.

and then activate the command I want to see with the remote.  With this, you can see everything _HideFrontRow does, but there is a *lot* of output!

-Jon

[John Sutherland]

I added some extra code to my Ultilies class (not checked in yet..)
that gives finer control over capturing what we need:

def enableObjCCapture(self):
objc.loadBundleFunctions(Foundation.__bundle__, globals(),
[('instrumentObjcMessageSends', objc._C_VOID + objc._C_NSBOOL)])
instrumentObjcMessageSends(True)

def disableObjCCapture(self):
objc.loadBundleFunctions(Foundation.__bundle__, globals(),
[('instrumentObjcMessageSends', objc._C_VOID + objc._C_NSBOOL)])
instrumentObjcMessageSends(False)

It brought the capture down to about 1000 lines or so, which isn't
overly bad to parse through.

--John

--John

[Jon Christopher]

Ah, yes,  and you enable/disable just around the call you want (HideFrontRow), I presume.
Nice.

One caveat; since all the logging for a given process goes into the same file,
you really need to kill FR before trying to log something else.

And, of course, with this method, you need to know exactly which call you want to log. 
Doesn't help if you're trying to figure out how some random menu action elsewhere in FR works.