[racket] Controlling where help desk, universe canvas open

[Mitchell Wand]

Hi all,

I'm running Racket 5.0 on a Vista box w/ an auxiliary display using "extend my desktop onto this display".  The auxiliary display gets plugged into a projector, which displays on the big screen.

This is convenient for running Powerpoint presentations (stop sniggering!) because the presentation runs on the big screen while my laptop screen shows a timer, notes, etc.

It's also useful for doing codewalks because I can run the Racket window on the big display and keep other stuff that I don't want folks to see on the laptop screen.

This all works fine except for 2 things:

1.  The first time I right-click on a symbol and select "Search for XXX in Help Desk", a new Firefox window opens up, but it's on my small screen, not on the extended screen near the racket window.    My workaround is to drag the FF window over to the auxiliary screen. After that, the Help Desk window usually (but not always) opens up on the auxiliary display as desired.  Anybody got any better ideas?

2. When I open up a new world using big-bang, the new world (labelled "World") opens up on the small screen, not  on the auxiliary screen as desired.  Is there any way to control where the World opens?  Could it be made to open near the position of the interaction window?  (Yes, I know that there might not be any interaction window.  That doesn't help me, though.)  Any ideas?

--Mitch

[Matthew Flatt]

I don't have any good workarounds to offer in the current version.

We're in the process of re-implementing the GUI library. When that's in
place, we should be in a position to improve the second issue, at
least.

For the Firefox issues, though, I'm not aware of a way to tell a web
browser which screen to use.

_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/users

[Robby Findler]

On Thu, Aug 5, 2010 at 7:43 AM, Matthew Flatt <mfl...@cs.utah.edu> wrote:
> I don't have any good workarounds to offer in the current version.
>
> We're in the process of re-implementing the GUI library. When that's in
> place, we should be in a position to improve the second issue, at
> least.

The current version already lets us do a little bit better
(remembering the position of the window from the last time it was
moved), no?

Robby