Hi Ian, David,
I think you're the experts for Squeak X window handling ... What would be needed to modify the Unix VM to not open a window until the beDisplay() primitive is called? That's how the Mac and Acorn VMs handle things, making headless operation controllable from the image.
David, I guess this would be similar to how your XDisplayControl plugin works?
Secondly, what's your estimate of making the host window support work? It is implemented on Win and Mac VMs but not X11 yet. It basically is just some primitives to open, close, resize, and move windows, and display bits, plus the event reporting to the image needs to set a window index field.
For OLPC I need the ability to have multiple top-level windows, and I need to know their XID from the image. I only ever need to draw and handle events in the top-most window since all windows are full- screen (*). That means the full host window plugin support isn't actually needed, but I think it still makes sense because OLPC development continues on Mac and Win, too. If at all sensible I'd like to avoid OLPC-specific bits in the VM. Besides, more folks seem to be interested in multiple window support.
Anyway, what's the best way to approach this? Anybody taking it on? Or at least lending me a hand? ;)
- Bert -
(*) I tried to convince the OLPC folks to support multiple activity instances (**) sharing a single X window but so far I failed. In the mean time I'll just fake multiple X windows ...
(**) If anybody is interested: http://wiki.laptop.org/go/ Activity_DBus_API
On Thu, May 31, 2007 at 12:27:41PM +0200, Bert Freudenberg wrote:
Hi Ian, David,
I think you're the experts for Squeak X window handling ... What would be needed to modify the Unix VM to not open a window until the beDisplay() primitive is called? That's how the Mac and Acorn VMs handle things, making headless operation controllable from the image.
It's not hard. I actually did this once before, change set attached. I don't have time to look at it right now to see if it still works (probably not since I did it in 1999), but it should not be hard to bring it up to date.
Secondly, what's your estimate of making the host window support work? It is implemented on Win and Mac VMs but not X11 yet. It basically is just some primitives to open, close, resize, and move windows, and display bits, plus the event reporting to the image needs to set a window index field.
It's probably not hard to implement something similar to XDisplayControlPlugin for this. When do you need to have it done?
Dave
On May 31, 2007, at 13:33 , David T. Lewis wrote:
On Thu, May 31, 2007 at 12:27:41PM +0200, Bert Freudenberg wrote:
Hi Ian, David,
I think you're the experts for Squeak X window handling ... What would be needed to modify the Unix VM to not open a window until the beDisplay() primitive is called? That's how the Mac and Acorn VMs handle things, making headless operation controllable from the image.
It's not hard. I actually did this once before, change set attached. I don't have time to look at it right now to see if it still works (probably not since I did it in 1999), but it should not be hard to bring it up to date.
That changeset doesn't have much to do with the VM, right? And the other VMs do this without changes to the interpreter if I am not mistaken.
Secondly, what's your estimate of making the host window support work? It is implemented on Win and Mac VMs but not X11 yet. It basically is just some primitives to open, close, resize, and move windows, and display bits, plus the event reporting to the image needs to set a window index field.
It's probably not hard to implement something similar to XDisplayControlPlugin for this. When do you need to have it done?
Oh, as soon as possible of course ... I'm working on making Squeak a native DBus activity and this is holding me back. I have an FFI-based hack to continue my work but FFI is not in the actual OLPC image.
- Bert -
http://wiki.squeak.org/squeak/3862 may be helpful
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Mommy! The cursor's winking at me!
On Thu, May 31, 2007 at 08:19:14AM -0700, tim Rowledge wrote:
http://wiki.squeak.org/squeak/3862 may be helpful
Where are the HostWindowProxy and sUnit tests? I'm looking at the plugin (in VMMaker) but I don't know where to find the rest.
Thanks,
Dave
On Jun 2, 2007, at 16:49 , David T. Lewis wrote:
On Thu, May 31, 2007 at 08:19:14AM -0700, tim Rowledge wrote:
http://wiki.squeak.org/squeak/3862 may be helpful
Where are the HostWindowProxy and sUnit tests? I'm looking at the plugin (in VMMaker) but I don't know where to find the rest.
The Ffenestri changesets are on John McIntosh's idisk in the experimental/Ffenestri folder:
http://homepage.mac.com/johnmci/FileSharing.html
and these are what I intend to use for OLPC (which has a changeset update stream).
There are MC packages at
http://source.impara.de/HostWindows.html
but I'm not sure which Squeak version these are based on (they include some system changes).
- Bert -
On Jan 15th I sent a revised host window and mac menu support for 3.10 to edgardec2001@yahoo.com.ar for inclusion in 3.10
check 3.10, and/or then ask the 3.10 team
On Jun 2, 2007, at 9:14 AM, Bert Freudenberg wrote:
Ffenestri
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
According to HostWindowsTest>>testOne, setting the window title to a "very long" string is supposed to raise an error:
self should: [hwindow windowTitle:'A Very long String.' , (String new:300)] raise: Error.
How long is too long? What kind of error should it raise?
Setting an X window title to a long string does not cause a problem, so this must be a platform-specific thing.
Thanks,
Dave
Ah, well on os-x carbon it's a string > 255 bytes.
On Jun 9, 2007, at 8:41 AM, David T. Lewis wrote:
According to HostWindowsTest>>testOne, setting the window title to a "very long" string is supposed to raise an error:
self should: [hwindow windowTitle:'A Very long String.' , (String new:300)] raise: Error.
How long is too long? What kind of error should it raise?
Setting an X window title to a long string does not cause a problem, so this must be a platform-specific thing.
Thanks,
Dave
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
vm-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
David T. Lewis -
John M McIntosh -
tim Rowledge