Hi Yoshiki,

> On May 13, 2016, at 9:04 PM, Yoshiki Ohshima <Yoshiki.Ohshima at acm.org> wrote:
> 
> Thanks!  I don't have the environment right now, but I'll follow this.
> But adding ImmX11Plugin (back again) seems to be right thing to do.
> If I'm not mistaken, this does not actually involve the VMMaker?

Hopefully :-). The Cog build tree is designed to put control on the set of plugins to compile into the hands of a particular build.  Plugins are generated to src/plugins, and the idea is for VMMaker to generate as many of them as can be generated.  Then to specify what set of plugins to compile into a VM simply edit the plugins.int & plugins.ext in buildOSNNProc/flavour, eg build.linuxARM/squeak.cog.spur/{plugins.int,plugins.ext}.

So provided src/plugins/ImmX11Plugin/ImmX11Plugin.c exists (on my phone right now, will check soon) all you need to do is edit the relevant plugins.int & plugins.ext.


> 
>> On Fri, May 13, 2016 at 8:05 PM, David T. Lewis <lewis at mail.msen.com> wrote:
>>> On Fri, May 13, 2016 at 07:31:07PM -0700, Yoshiki Ohshima wrote:
>>>> On Fri, May 13, 2016 at 5:22 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>>> 
>>>> 
>>>> On Fri, May 13, 2016 at 4:48 PM, Yoshiki Ohshima <Yoshiki.Ohshima at acm.org>
>>>> wrote:
>>>>> 
>>>>> Iit appears that most bits and pieces are there.  For example,
>>>>> sqUnixX11.c does have two functions setCompositionFocus() and
>>>>> setCompositionWIndowPosition(), which used to be in a separated
>>>>> loadable VM plugin but now sitting in there without any caller (if I'm
>>>>> not mistaken).  And the NuSqueak image has calls to
>>>>> Hand>>compositionWindowManager, and miraculously, returns an instance
>>>>> of ImmX11.
>>>>> 
>>>>> In ImmX11, setCompositionWindowPositionX:y: has a primitive call into
>>>>> ImmX11Plugin; but it appears that all I have to do is to change it to
>>>>> call the above-mentioned function in sqUnixX11.c.
>>>>> 
>>>>> To make it right, I'd propose to add two more functions to the display
>>>>> module interface.  I see the implementation of those for X11 is there,
>>>>> and I remember writing something for Windows; but it can be an empty
>>>>> function.
>>>>> 
>>>>> So, if there is no opposition to add these to the display interface,
>>>>> I'd write a patch for it.  But one thing I don't know much about is
>>>>> the HostWindowPlugin.  If people think it makes sense to have them
>>>>> there for some reason, we can make that work, too.
>>>> 
>>>> 
>>>> This is in struct SqDisplay in platforms/unix/vm/SqDisplay.h?  Go for it :-)
>>> 
>>> Yes, SqDisplay.h is what would be changed.
>>> 
>>> What I wrote above has some confusion, and I am indeed confused by this:
>>> 
>>> - the display vm plugin mechanism has primitives that are numbered as
>>> well as primitives that are in plugins like HostWindowPlugin.  Is it
>>> possible to make then setCompositionFocus() and
>>> setCompositionWindowPosition() to be non-numbered yet make them be
>>> looked up from a plugin?  Wasn't there a way to say to load a
>>> primitive from the core VM itself?
>> 
>> Yes they can be non-numbered, and it is better for them to be named
>> primitives. And yes, a named primitive in the VM can be called directly,
>> but here is is better if you let them be named primitives in either
>> ImmX11Plugin or HostWindowPlugin.
>> 
>> To summarize with an example, #primitiveHostWindowPosition is called as a
>> named primitive:
>> 
>>   HostWindowProxy>>primitiveWindowPosition: id
>>        "Find the topleft corner of the window"
>>        <primitive: 'primitiveHostWindowPosition' module: 'HostWindowPlugin'>
>>        ^self windowProxyError: 'get position'
>> 
>> The primitive calls ioPositionOfWindow(windowIndex() in the unix support
>> code, declared in platforms/Cross/plugins/HostWindowPlugin.h, implemented in
>> platforms/unix/plugins/sqHostWindowPlugin.c.
>> 
>> The plugin implementation calls a function in whatever VM module has been
>> loaded for the display:
>>        dpy->hostWindowGetSize(windowIndex)
>> 
>> For unix/X11, the display module is implemented in sqUnixX11.c, and the
>> function in that loaded module is display_hostWindowGetSize().
>> 
>> You can follow exactly the same pattern for the two new methods that
>> you are adding. Your new primitives can be named primitives in either
>> ImmX11Plugin or HostWindowPlugin.
>> 
>> I do not know which plugin would be better to use, but either one will work.
>> 
>> Dave
>>> 
>>> In any case, what to be edited seems to be minimal on the image side
>>> and isolated in the ImmX11 class; so it looks like it is close.
>>> 
>>> -- Yoshiki
> 
> -- Yoshiki


_,,,^..^,,,_ (phone)