[squeak-dev] International text input on X11

David T. Lewis lewis at mail.msen.com
Sun May 15 04:58:34 UTC 2016


On Sat, May 14, 2016 at 07:44:29AM -0700, Eliot Miranda wrote:
> 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.
> 

Yoshiki,

I have done some additional testing, and I think that on Linux the ImmX11Plugin
will work without any code changes at all :-)

I was expecting that some code changes would be needed to enable the
primSetCompositionWindowPosition() function in ImmX11Plugin to call 
setCompositionWindowPosition() in the vm-display-X11 VM module. But I
tried compiling ImmX11Plugin as an external module, and running under
a gdb debugger. I can confirm that the ImmX11Plugin is calling the external
setCompositionWindowPosition() function successfully.

I cannot test this with Cog due to issues with gcc/autotools on the Ubuntu
system I am using now, but there should be no differences in doing this
on Cog. So I think that if you add ImmX11Plugin to plugins.ext as Eliot
describes, then the plugin probably will work for Raspbian without any
other changes.

Dave



> 
> > 
> >> 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)


More information about the Squeak-dev mailing list