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 LazyDisplayInit.15Nov515pm.cs.gz (2K) Download Attachment |
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; [hidden email]; 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 [hidden email] 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 <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== === |
In reply to this post by timrowledge
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 <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== === |
Free forum by Nabble | Edit this page |