X window handling

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

X window handling

Bert Freudenberg
 
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
Reply | Threaded
Open this post in threaded view
|

Re: X window handling

David T. Lewis
 
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
Reply | Threaded
Open this post in threaded view
|

Re: X window handling

Bert Freudenberg
 

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 -


Reply | Threaded
Open this post in threaded view
|

Re: Re: X window handling

timrowledge
 
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!


Reply | Threaded
Open this post in threaded view
|

Re: Re: X window handling

David T. Lewis
 
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

Reply | Threaded
Open this post in threaded view
|

Re: Re: X window handling

Bert Freudenberg
 

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 -


Reply | Threaded
Open this post in threaded view
|

Re: Re: X window handling

johnmci
 
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
========================================================================
===


Reply | Threaded
Open this post in threaded view
|

Ffenestri HostWindowTests question (was: Re: X window handling)

David T. Lewis
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

Reply | Threaded
Open this post in threaded view
|

Re: Ffenestri HostWindowTests question (was: Re: X window handling)

johnmci
 
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
========================================================================
===