How difficult to make a .NET VM?
Locked
 
|
Hi [Apologies if this has been addressed before or elsewhere; my Google attempts didn't turn up anything that seemed relevant.] Has anyone tried packaging the Squeak VM as a .NET class? (...if that's a sensible way to ask the question) For the past couple of years I've been using and hacking the Squeak/.NET bridge, created by John Pierce and Ben Schroeder, mainly so I can create and control IE-like Web browser views within the Squeak desktop (see, for example, http://km.meme.hokudai.ac.jp/people/aran/papers/UIST06-LunzerHornbaek.pdf). While this has been successful to the degree needed to be a platform for HCI research, the setup is still - frankly - an untidy and fragile hack. The main challenge has been how to combine the .NET views with the Squeak desktop. Originally we made them children of the Squeak window, but this gave us a nasty, intermittent thread-based deadlock. We worked around this by keeping the .NET views independent but making them hover in front of the Squeak window in the Windows Z order; some tweaks to the handling of focus-change messages in the Squeak VM allow us to ensure - most of the time - that the combination shares the desktop nicely with other Windows applications. However, as I say, it's pretty fragile. So we're wondering whether there's a clean way to make the .NET views be children of the Squeak window, only without running into the COM vs. .NET threading issue that hit us before. In particular, unless we can crack this issue it seems unlikely that we can get the Squeak+.NET combination to behave acceptably when embedded within a Web browser. I suspect that if we could package the Squeak desktop itself as a .NET Form we could then make the other views be proper children of that desktop, and the window management problems would all go away. I also imagine that we could then go the extra step of packaging this .NET-based VM as a browser plugin. If it all works, the result would be a pretty useful (though Windows-specific) Squeak+.NET environment. So: can anyone shed some light on how complex this is likely to be? Has anyone already tried it? ...or would we be better off just looking for another way to get Web pages rendered? A Squeak-native approach such as Scamper seems doomed to lag the state of the art by years; has anyone looked into packaging a library such as Gecko for use within Squeak? Thanks for any thoughts - Aran -- Aran Lunzer Hokkaido University, Japan http://km.meme.hokudai.ac.jp/people/aran/ |
Re: How difficult to make a .NET VM?
|
|
Sounds nasty. One thing to experiment with the -browserWindow: command line argument. Originally, it was designed to "get Squeak into a browser" but of course, as long as your .NET form has a HWND handle you can get Squeak inside it by passing the handle along with -browserWindow:. Other than that I have zero experience with what makes .NET form a .NET form and how to get anything to behave properly inside it. Cheers, - Andreas Aran Lunzer wrote: > > Hi > > [Apologies if this has been addressed before or elsewhere; my Google > attempts didn't turn up anything that seemed relevant.] > > Has anyone tried packaging the Squeak VM as a .NET class? (...if that's a > sensible way to ask the question) > > For the past couple of years I've been using and hacking the Squeak/.NET > bridge, created by John Pierce and Ben Schroeder, mainly so I can create > and control IE-like Web browser views within the Squeak desktop (see, for > example, > http://km.meme.hokudai.ac.jp/people/aran/papers/UIST06-LunzerHornbaek.pdf). > > While this has been successful to the degree needed to be a platform for > HCI research, the setup is still - frankly - an untidy and fragile hack. > > The main challenge has been how to combine the .NET views with the Squeak > desktop. Originally we made them children of the Squeak window, but this > gave us a nasty, intermittent thread-based deadlock. We worked around > this by keeping the .NET views independent but making them hover in front > of the Squeak window in the Windows Z order; some tweaks to the handling > of focus-change messages in the Squeak VM allow us to ensure - most of the > time - that the combination shares the desktop nicely with other Windows > applications. > > However, as I say, it's pretty fragile. So we're wondering whether > there's a clean way to make the .NET views be children of the Squeak > window, only without running into the COM vs. .NET threading issue that > hit us before. In particular, unless we can crack this issue it seems > unlikely that we can get the Squeak+.NET combination to behave acceptably > when embedded within a Web browser. > > I suspect that if we could package the Squeak desktop itself as a .NET > Form we could then make the other views be proper children of that > desktop, and the window management problems would all go away. I also > imagine that we could then go the extra step of packaging this .NET-based > VM as a browser plugin. If it all works, the result would be a pretty > useful (though Windows-specific) Squeak+.NET environment. > > So: can anyone shed some light on how complex this is likely to be? Has > anyone already tried it? > > ...or would we be better off just looking for another way to get Web pages > rendered? A Squeak-native approach such as Scamper seems doomed to lag > the state of the art by years; has anyone looked into packaging a library > such as Gecko for use within Squeak? > > > Thanks for any thoughts - > > Aran > -- > Aran Lunzer > Hokkaido University, Japan > http://km.meme.hokudai.ac.jp/people/aran/ > > |
Re: How difficult to make a .NET VM?
|
|
In reply to this post by Aran Lunzer
Hi Andreas > One thing to experiment with the -browserWindow: > command line argument. Originally, it was designed to "get Squeak > into a browser" but of course, as long as your .NET form has a > HWND handle you can get Squeak inside it by passing the handle > along with -browserWindow:. Well, b*gger me. If I'd known this (uhh, perhaps if I'd asked this) a year ago... Anyway - thank you. It seems to work: Squeak will happily run inside a .NET form. Next challenge: I want to tell that .NET form (call it the substrate) to be the owner of other forms created within the application - because that way they'll be guaranteed (in theory) to stay in front of the Squeak window. But to be able to talk to the substrate at all, the Squeak VM must be in the same process as it. How do you launch Squeak in the same process as the form? Well... remarkably enough, the following seems to work: 1. start Squeak 2. in Squeak, crank up the .NET bridge 3. use the bridge to create a free-standing, Squeak-desktop-sized .NET form 4. tell the VM to use that form as its browserWindow ...but I'm not yet confident that this approach would fly for the case of a plugin within a real browser. I'll have a go. And meanwhile I have another question: Is there a standard way of sending messages between the VM and Squeak code? For the time being I've hacked together a simple shared-data link using the GWL_USERDATA value of the Squeak window, as well as a one-way signal from VM to Squeak using some custom UI-event types. My next thought for talking to the VM was to try posting custom messages to the Squeak window's queue. Any other mechanisms? Thanks again Aran -- Aran Lunzer Hokkaido University |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |