International text input on X11

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
127 messages Options
1234567
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: International text input on X11

Eliot Miranda-2
Hi Yoshiki,

> On May 11, 2016, at 1:20 PM, Eliot Miranda <[hidden email]> wrote:
>
> Hi Yoshiki,
>
>>> On May 11, 2016, at 11:52 AM, Yoshiki Ohshima <[hidden email]> wrote:
>>>
>>>> On Tue, May 10, 2016 at 7:37 AM, Bert Freudenberg <[hidden email]> wrote:
>>>> On 10.05.2016, at 02:23, Yoshiki Ohshima <[hidden email]> wrote:
>>>>
>>>> On Mon, May 9, 2016 at 10:35 AM, Yoshiki Ohshima
>>>> <[hidden email]> wrote:
>>>>> The VM still does not display anything in the white window after I did
>>>>> apt-get dist-upgrade, and copy the .sources file to the same directly.
>>>>> (But I did not have an egg this morning).  I'll try some display
>>>>> options.  But also, it appears that the source code for the Cog seems
>>>>> to have the part I wrote for the composition input.  The goal may be
>>>>> nearer than I originally thought.
>>>>
>>>> It may not as closer than I thought, however.  The world evolved to
>>>> use ibus; we'd need to add some more stuff, such as DBus...  I'll
>>>> report more tomorrow.
>>>
>>> Doesn’t ibus generate “old” X events, too? The README suggests this should work:
>>>
>>>       XMODIFIERS="@im=ibus" squeak
>>>
>>> ... which we could put in the startup script.
>>
>> This does not quite work.  And also Abe-san says that I'd better make
>> it work with scim first so I am taking that path now.
>>
>> BTW, I have a long standing question of the development process.  I
>> create a VM by doing ./mvm, which creates display drivers and VM in
>> one way or another, and installs them to products directory somewhere
>> upthere.  I have trouble seeing my changes to code gets reflected
>> sometimes.  (Say, I change a printf message somehwere in sqUnixX11.c,
>> run mvm and invoke the squeak shell script in
>> products/cogspurlinuxhtARM/ but it seems to pick up a different binary
>> from somewhere else.
>
> It shouldn't.  That's where the resulting binary gets installed (or a debug build in products/debug/cogspurlinuxhtARM etc).
>
>>
>> What do people do to make the debug cycle go faster on Linux?
>
> That's what I've been using, and I find it unsatisfactory too.  I don't like the automake system and want to replace the whole thing with Gnu make makefiles (as is used in the win32 and MacOS builds) which would result in more sharing between the production, assert and debug builds plus accurate dependency information for reliable compilation, and the possibility of making a valid cogspurlinuxhtARM directory tree in the build directory and hence (again as I do in the win32 and MacOS builds) running the executable in the build directory instead of from products.

And I forgot to say that indeed sqUnixX11.c is one of the files that suffers from inaccurate dependency info because it includes sqUnixEvent.c and sqUnixXdnd.c but the dependency isn't reflected in the makefiles :-(

>
>> -- Yoshiki
>
> _,,,^..^,,,_ (phone)

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: International text input on X11

Yoshiki Ohshima-3
I am slowly working my way up.  Most of the problems was about getting
the right environment variables for right processes, including the X
Server and Squeak.  I now get vanilla UTF32 values for characters I
type into the scim preedit window on Squeak.

The big question now is on the image side.  We used to have
StrikeFontSet as the default font and it was tad easier to just load
language specific fonts into the image.

At the same time, the clients' need here for me this time around
(i.e., make Squeak on raspi support Japanese input, I'd side step all
regular Squeak stuff and minimum changes.  I am inclined to take this
path now.

Tim, is there a repo of the NuScratch that is used in the NuScratch image?

On Wed, May 11, 2016 at 1:24 PM, Eliot Miranda <[hidden email]> wrote:

> Hi Yoshiki,
>
>> On May 11, 2016, at 1:20 PM, Eliot Miranda <[hidden email]> wrote:
>>
>> Hi Yoshiki,
>>
>>>> On May 11, 2016, at 11:52 AM, Yoshiki Ohshima <[hidden email]> wrote:
>>>>
>>>>> On Tue, May 10, 2016 at 7:37 AM, Bert Freudenberg <[hidden email]> wrote:
>>>>> On 10.05.2016, at 02:23, Yoshiki Ohshima <[hidden email]> wrote:
>>>>>
>>>>> On Mon, May 9, 2016 at 10:35 AM, Yoshiki Ohshima
>>>>> <[hidden email]> wrote:
>>>>>> The VM still does not display anything in the white window after I did
>>>>>> apt-get dist-upgrade, and copy the .sources file to the same directly.
>>>>>> (But I did not have an egg this morning).  I'll try some display
>>>>>> options.  But also, it appears that the source code for the Cog seems
>>>>>> to have the part I wrote for the composition input.  The goal may be
>>>>>> nearer than I originally thought.
>>>>>
>>>>> It may not as closer than I thought, however.  The world evolved to
>>>>> use ibus; we'd need to add some more stuff, such as DBus...  I'll
>>>>> report more tomorrow.
>>>>
>>>> Doesn’t ibus generate “old” X events, too? The README suggests this should work:
>>>>
>>>>       XMODIFIERS="@im=ibus" squeak
>>>>
>>>> ... which we could put in the startup script.
>>>
>>> This does not quite work.  And also Abe-san says that I'd better make
>>> it work with scim first so I am taking that path now.
>>>
>>> BTW, I have a long standing question of the development process.  I
>>> create a VM by doing ./mvm, which creates display drivers and VM in
>>> one way or another, and installs them to products directory somewhere
>>> upthere.  I have trouble seeing my changes to code gets reflected
>>> sometimes.  (Say, I change a printf message somehwere in sqUnixX11.c,
>>> run mvm and invoke the squeak shell script in
>>> products/cogspurlinuxhtARM/ but it seems to pick up a different binary
>>> from somewhere else.
>>
>> It shouldn't.  That's where the resulting binary gets installed (or a debug build in products/debug/cogspurlinuxhtARM etc).
>>
>>>
>>> What do people do to make the debug cycle go faster on Linux?
>>
>> That's what I've been using, and I find it unsatisfactory too.  I don't like the automake system and want to replace the whole thing with Gnu make makefiles (as is used in the win32 and MacOS builds) which would result in more sharing between the production, assert and debug builds plus accurate dependency information for reliable compilation, and the possibility of making a valid cogspurlinuxhtARM directory tree in the build directory and hence (again as I do in the win32 and MacOS builds) running the executable in the build directory instead of from products.
>
> And I forgot to say that indeed sqUnixX11.c is one of the files that suffers from inaccurate dependency info because it includes sqUnixEvent.c and sqUnixXdnd.c but the dependency isn't reflected in the makefiles :-(
>
>>
>>> -- Yoshiki
>>
>> _,,,^..^,,,_ (phone)
>



--
-- Yoshiki

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: International text input on X11

Yoshiki Ohshima-3
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.

On Fri, May 13, 2016 at 3:57 PM, Yoshiki Ohshima
<[hidden email]> wrote:

> I am slowly working my way up.  Most of the problems was about getting
> the right environment variables for right processes, including the X
> Server and Squeak.  I now get vanilla UTF32 values for characters I
> type into the scim preedit window on Squeak.
>
> The big question now is on the image side.  We used to have
> StrikeFontSet as the default font and it was tad easier to just load
> language specific fonts into the image.
>
> At the same time, the clients' need here for me this time around
> (i.e., make Squeak on raspi support Japanese input, I'd side step all
> regular Squeak stuff and minimum changes.  I am inclined to take this
> path now.
>
> Tim, is there a repo of the NuScratch that is used in the NuScratch image?
>
> On Wed, May 11, 2016 at 1:24 PM, Eliot Miranda <[hidden email]> wrote:
>> Hi Yoshiki,
>>
>>> On May 11, 2016, at 1:20 PM, Eliot Miranda <[hidden email]> wrote:
>>>
>>> Hi Yoshiki,
>>>
>>>>> On May 11, 2016, at 11:52 AM, Yoshiki Ohshima <[hidden email]> wrote:
>>>>>
>>>>>> On Tue, May 10, 2016 at 7:37 AM, Bert Freudenberg <[hidden email]> wrote:
>>>>>> On 10.05.2016, at 02:23, Yoshiki Ohshima <[hidden email]> wrote:
>>>>>>
>>>>>> On Mon, May 9, 2016 at 10:35 AM, Yoshiki Ohshima
>>>>>> <[hidden email]> wrote:
>>>>>>> The VM still does not display anything in the white window after I did
>>>>>>> apt-get dist-upgrade, and copy the .sources file to the same directly.
>>>>>>> (But I did not have an egg this morning).  I'll try some display
>>>>>>> options.  But also, it appears that the source code for the Cog seems
>>>>>>> to have the part I wrote for the composition input.  The goal may be
>>>>>>> nearer than I originally thought.
>>>>>>
>>>>>> It may not as closer than I thought, however.  The world evolved to
>>>>>> use ibus; we'd need to add some more stuff, such as DBus...  I'll
>>>>>> report more tomorrow.
>>>>>
>>>>> Doesn’t ibus generate “old” X events, too? The README suggests this should work:
>>>>>
>>>>>       XMODIFIERS="@im=ibus" squeak
>>>>>
>>>>> ... which we could put in the startup script.
>>>>
>>>> This does not quite work.  And also Abe-san says that I'd better make
>>>> it work with scim first so I am taking that path now.
>>>>
>>>> BTW, I have a long standing question of the development process.  I
>>>> create a VM by doing ./mvm, which creates display drivers and VM in
>>>> one way or another, and installs them to products directory somewhere
>>>> upthere.  I have trouble seeing my changes to code gets reflected
>>>> sometimes.  (Say, I change a printf message somehwere in sqUnixX11.c,
>>>> run mvm and invoke the squeak shell script in
>>>> products/cogspurlinuxhtARM/ but it seems to pick up a different binary
>>>> from somewhere else.
>>>
>>> It shouldn't.  That's where the resulting binary gets installed (or a debug build in products/debug/cogspurlinuxhtARM etc).
>>>
>>>>
>>>> What do people do to make the debug cycle go faster on Linux?
>>>
>>> That's what I've been using, and I find it unsatisfactory too.  I don't like the automake system and want to replace the whole thing with Gnu make makefiles (as is used in the win32 and MacOS builds) which would result in more sharing between the production, assert and debug builds plus accurate dependency information for reliable compilation, and the possibility of making a valid cogspurlinuxhtARM directory tree in the build directory and hence (again as I do in the win32 and MacOS builds) running the executable in the build directory instead of from products.
>>
>> And I forgot to say that indeed sqUnixX11.c is one of the files that suffers from inaccurate dependency info because it includes sqUnixEvent.c and sqUnixXdnd.c but the dependency isn't reflected in the makefiles :-(
>>
>>>
>>>> -- Yoshiki
>>>
>>> _,,,^..^,,,_ (phone)
>>
>
>
>
> --
> -- Yoshiki



--
-- Yoshiki

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: International text input on X11

Eliot Miranda-2


On Fri, May 13, 2016 at 4:48 PM, Yoshiki Ohshima <[hidden email]> 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 :-)

On Fri, May 13, 2016 at 3:57 PM, Yoshiki Ohshima
<[hidden email]> wrote:
> I am slowly working my way up.  Most of the problems was about getting
> the right environment variables for right processes, including the X
> Server and Squeak.  I now get vanilla UTF32 values for characters I
> type into the scim preedit window on Squeak.
>
> The big question now is on the image side.  We used to have
> StrikeFontSet as the default font and it was tad easier to just load
> language specific fonts into the image.
>
> At the same time, the clients' need here for me this time around
> (i.e., make Squeak on raspi support Japanese input, I'd side step all
> regular Squeak stuff and minimum changes.  I am inclined to take this
> path now.
>
> Tim, is there a repo of the NuScratch that is used in the NuScratch image?
>
> On Wed, May 11, 2016 at 1:24 PM, Eliot Miranda <[hidden email]> wrote:
>> Hi Yoshiki,
>>
>>> On May 11, 2016, at 1:20 PM, Eliot Miranda <[hidden email]> wrote:
>>>
>>> Hi Yoshiki,
>>>
>>>>> On May 11, 2016, at 11:52 AM, Yoshiki Ohshima <[hidden email]> wrote:
>>>>>
>>>>>> On Tue, May 10, 2016 at 7:37 AM, Bert Freudenberg <[hidden email]> wrote:
>>>>>> On 10.05.2016, at 02:23, Yoshiki Ohshima <[hidden email]> wrote:
>>>>>>
>>>>>> On Mon, May 9, 2016 at 10:35 AM, Yoshiki Ohshima
>>>>>> <[hidden email]> wrote:
>>>>>>> The VM still does not display anything in the white window after I did
>>>>>>> apt-get dist-upgrade, and copy the .sources file to the same directly.
>>>>>>> (But I did not have an egg this morning).  I'll try some display
>>>>>>> options.  But also, it appears that the source code for the Cog seems
>>>>>>> to have the part I wrote for the composition input.  The goal may be
>>>>>>> nearer than I originally thought.
>>>>>>
>>>>>> It may not as closer than I thought, however.  The world evolved to
>>>>>> use ibus; we'd need to add some more stuff, such as DBus...  I'll
>>>>>> report more tomorrow.
>>>>>
>>>>> Doesn’t ibus generate “old” X events, too? The README suggests this should work:
>>>>>
>>>>>       XMODIFIERS="@im=ibus" squeak
>>>>>
>>>>> ... which we could put in the startup script.
>>>>
>>>> This does not quite work.  And also Abe-san says that I'd better make
>>>> it work with scim first so I am taking that path now.
>>>>
>>>> BTW, I have a long standing question of the development process.  I
>>>> create a VM by doing ./mvm, which creates display drivers and VM in
>>>> one way or another, and installs them to products directory somewhere
>>>> upthere.  I have trouble seeing my changes to code gets reflected
>>>> sometimes.  (Say, I change a printf message somehwere in sqUnixX11.c,
>>>> run mvm and invoke the squeak shell script in
>>>> products/cogspurlinuxhtARM/ but it seems to pick up a different binary
>>>> from somewhere else.
>>>
>>> It shouldn't.  That's where the resulting binary gets installed (or a debug build in products/debug/cogspurlinuxhtARM etc).
>>>
>>>>
>>>> What do people do to make the debug cycle go faster on Linux?
>>>
>>> That's what I've been using, and I find it unsatisfactory too.  I don't like the automake system and want to replace the whole thing with Gnu make makefiles (as is used in the win32 and MacOS builds) which would result in more sharing between the production, assert and debug builds plus accurate dependency information for reliable compilation, and the possibility of making a valid cogspurlinuxhtARM directory tree in the build directory and hence (again as I do in the win32 and MacOS builds) running the executable in the build directory instead of from products.
>>
>> And I forgot to say that indeed sqUnixX11.c is one of the files that suffers from inaccurate dependency info because it includes sqUnixEvent.c and sqUnixXdnd.c but the dependency isn't reflected in the makefiles :-(
>>
>>>
>>>> -- Yoshiki
>>>
>>> _,,,^..^,,,_ (phone)
>>
>
>
>
> --
> -- Yoshiki



--
-- Yoshiki




--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: International text input on X11

Yoshiki Ohshima-3
On Fri, May 13, 2016 at 5:22 PM, Eliot Miranda <[hidden email]> wrote:

>
>
> On Fri, May 13, 2016 at 4:48 PM, Yoshiki Ohshima <[hidden email]>
> 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?

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: International text input on X11

David T. Lewis
In reply to this post by Eliot Miranda-2
On Fri, May 13, 2016 at 05:22:59PM -0700, Eliot Miranda wrote:

> On Fri, May 13, 2016 at 4:48 PM, Yoshiki Ohshima <[hidden email]>
> 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 :-)
>

That sounds right to me also.

Yoshiki,

I have some changes to HostWindowPlugin that makes it work for the
latest Squeak trunk. I do not think that this will conflict with any
of your changes, and I will post the updates as soon as I can (but
maybe not for a couple of days).

I do not know if primSetCompositionWindowPosition should better be
in ImmX11Plugin or in HostWindowPlugin, but I see no reason to worry
about it now. If someone finds a reason to change it, they can do
that later.

Eliot,

The SqDisplayVersionMinor in oscog is 5, and in trunk it is 2. Adding
the Qwaq enhancements needed for HostWindowPlugin would make trunk
go from 2 -> 3, and the actual implementations in oscog seem to imply
we should be at 3 there also. Maybe there were other Qwaq enhancements
(that are not relevant here?) that moved the version number to 5.

Yoshiki's interface enhancement should probably bump the minor version
up by one, making it either 3 -> 4 or 5 -> 6.

I'm inclined to think that we should just declare the current minor
version to be 5 (as in oscog now) and chalk up the difference to missing
Qwaq features, and then let Yoshiki's enhancement be SqDisplayVersionMinor
be 6.

Does that sound right?

Dave


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: International text input on X11

David T. Lewis
In reply to this post by Yoshiki Ohshima-3
On Fri, May 13, 2016 at 07:31:07PM -0700, Yoshiki Ohshima wrote:

> On Fri, May 13, 2016 at 5:22 PM, Eliot Miranda <[hidden email]> wrote:
> >
> >
> > On Fri, May 13, 2016 at 4:48 PM, Yoshiki Ohshima <[hidden email]>
> > 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: International text input on X11

Yoshiki Ohshima-3
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?

On Fri, May 13, 2016 at 8:05 PM, David T. Lewis <[hidden email]> 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 <[hidden email]> wrote:
>> >
>> >
>> > On Fri, May 13, 2016 at 4:48 PM, Yoshiki Ohshima <[hidden email]>
>> > 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: International text input on X11

David T. Lewis
On Fri, May 13, 2016 at 09:04:08PM -0700, Yoshiki Ohshima 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?

I think that is right. I just tried generating source for ImmX11Plugin
from my VMMaker. It seems to compile without problems (but probably it
would have unresolved references). The generated ImmX11Plugin.c calls the
function declared as extern int setCompositionWindowPosition(int, int).

So I think that what may be needed is to create a new source file
platforms/unix/plugins/ImmX11Plugin/sqUnixImmX11Plugin.c
and this source file would call the function in the VM display module.

I see now that I do not know enough about the ImmX11Plugin, so I
am not sure if I fully understand what needs to be done.

But it works for HostWindowPlugin, so I think that we can make it
work for ImmX11Plugin in a similar way.

Dave

>
> On Fri, May 13, 2016 at 8:05 PM, David T. Lewis <[hidden email]> 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 <[hidden email]> wrote:
> >> >
> >> >
> >> > On Fri, May 13, 2016 at 4:48 PM, Yoshiki Ohshima <[hidden email]>
> >> > 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: International text input on X11

Eliot Miranda-2
In reply to this post by Yoshiki Ohshima-3
Hi Yoshiki,

> On May 13, 2016, at 9:04 PM, Yoshiki Ohshima <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>>
>>>>
>>>> On Fri, May 13, 2016 at 4:48 PM, Yoshiki Ohshima <[hidden email]>
>>>> 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)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: International text input on X11

Eliot Miranda-2
In reply to this post by David T. Lewis
Hi Dave,

> On May 13, 2016, at 7:31 PM, David T. Lewis <[hidden email]> wrote:
>
>> On Fri, May 13, 2016 at 05:22:59PM -0700, Eliot Miranda wrote:
>> On Fri, May 13, 2016 at 4:48 PM, Yoshiki Ohshima <[hidden email]>
>> 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 :-)
>
> That sounds right to me also.
>
> Yoshiki,
>
> I have some changes to HostWindowPlugin that makes it work for the
> latest Squeak trunk. I do not think that this will conflict with any
> of your changes, and I will post the updates as soon as I can (but
> maybe not for a couple of days).
>
> I do not know if primSetCompositionWindowPosition should better be
> in ImmX11Plugin or in HostWindowPlugin, but I see no reason to worry
> about it now. If someone finds a reason to change it, they can do
> that later.
>
> Eliot,
>
> The SqDisplayVersionMinor in oscog is 5, and in trunk it is 2. Adding
> the Qwaq enhancements needed for HostWindowPlugin would make trunk
> go from 2 -> 3, and the actual implementations in oscog seem to imply
> we should be at 3 there also. Maybe there were other Qwaq enhancements
> (that are not relevant here?) that moved the version number to 5.

I made at least two changes after Qwaq.  I can check, but they fixed deficiencies, perhaps with sound, perhaps with dnd.  I'll figure it out and post.  But 5 is meaningful, not arbitrary :-).

>
> Yoshiki's interface enhancement should probably bump the minor version
> up by one, making it either 3 -> 4 or 5 -> 6.
>
> I'm inclined to think that we should just declare the current minor
> version to be 5 (as in oscog now) and chalk up the difference to missing
> Qwaq features, and then let Yoshiki's enhancement be SqDisplayVersionMinor
> be 6.
>
> Does that sound right?

Yes, spot on.

> Dave

Cheers, both!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: International text input on X11

David T. Lewis
In reply to this post by Eliot Miranda-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
> >>>>
> >>>>
> >>>> On Fri, May 13, 2016 at 4:48 PM, Yoshiki Ohshima <[hidden email]>
> >>>> 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)

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: International text input on X11

Yoshiki Ohshima-3
(if you see this twice but with a difference, I'm sorry.)

Hi, David,

At Sun, 15 May 2016 00:58:34 -0400,
David T. Lewis wrote:

>
> 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 <[hidden email]> 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.
It indeed was to my surprise to find out that ImmX11Plugin was in the
distribution!  It even has more than two primitives I wrote while ago.

I can confirm that many things are working; but it still does require
some code change in the VM and in the image.

Mr Hachisuka worked on a similar change and mentioned this:

http://www2.asu.ac.jp/hachi/v3/scratch14ime.html

Effectively, his change to recordPendingKeys() takes UTF8 string but
cook them into UTF32 in there.  Without this change, the image
receives those octets separately, and the way things are set up
currently, they are interpreted as individual characters.

We used to have a theory that this might be a job on
the image side, but I'd be willing to go along with the idea that the
VM does it in recordPendingKeys().  (Attached patch for now has an
ifdef, but once it is accepted as a main stream patch, it'd not have
to be there.)

Then on the image side, we need to fix ImmX11>>keyboardFocusForMorph:
to support non-TextMorphs.  My feeble attempt involves to test whether
the given morph understand #paragraph and make it read:

-------------------
keyboardFocusForAMorph: aMorph

        aMorph ifNil: [^ self].
        [
                | left bottom pos height |
                pos := aMorph preferredKeyboardPosition.
                left := (pos x min: Display width max: 0) asInteger.
                (aMorph respondsTo: #paragraph) ifTrue: [
                        height := (aMorph paragraph
                                characterBlockForIndex: aMorph editor selectionInterval first) height
                ] ifFalse: [
                        height := 0].
                bottom := (pos y min: Display height max: 0) asInteger
                         + height.
                self setCompositionWindowPositionX: left y: bottom asInteger
        ] on: Error
        do: [:ex |].

-------------------
(#asInteger is sent so that the primitive does not get floats.)

and then to use it StringFieldMorph (and possible a few other classes)
need its #keyboardFocusChange: to read:

-------------------
keyboardFocusChange: t1
        (t1
                        and: [isKeyboardFocus not])
                ifTrue: [lastContents := stringMorph contents].
        (isKeyboardFocus
                        and: [t1 not])
                ifTrue: [lastContents := nil.
                        isNumeric
                                ifTrue: [self contents: stringMorph contents asNumberNoError printStringNoExponent].
                        acceptWhenFocusLost
                                ifTrue: [self acceptEdits]].
        isKeyboardFocus := t1.
        isKeyboardFocus
                ifTrue: [selectionStart := 0.
                        selectionEnd := stringMorph contents size].
        "This line below"
        isKeyboardFocus ifTrue: [ActiveHand compositionWindowManager keyboardFocusForAMorph: self].
        self changed
-------------------

The result is that when the input method is enabled, and the user
tries to type into a field, the preedit window shows up right there
where you are typing in.

The prerequite for this is to have all the right environment variables
for the X Server and Squeak VM and then the good old -vm-display-X11
-compositioninput is passed in to invoke the VM.

Thank you everybody for all the help!  We'll need to fold these
changes and I'll test a few more configurations so that a novice user
invoking Scratch on Raspbian sees everything al right, but it is
getting there!

-- Yoshiki




diff.diff (4K) Download Attachment
preedit.png (71K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: International text input on X11

timrowledge

> On 15-05-2016, at 1:29 PM, Yoshiki Ohshima <[hidden email]> wrote:
>
> Thank you everybody for all the help!  We'll need to fold these
> changes and I'll test a few more configurations so that a novice user
> invoking Scratch on Raspbian sees everything al right, but it is
> getting there!

I wish I could have offered something but unix non-anglo character input is so far outside my area I probably can’t even spell it correctly…
but once you’ve got it working to your satisfaction I can certainly make sure it gets into the next available Pi release.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Always responds to "Make Money Fast" postings on the Net.



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: International text input on X11

Yoshiki Ohshima-3
On Sun, May 15, 2016 at 1:32 PM, tim Rowledge <[hidden email]> wrote:

>
>> On 15-05-2016, at 1:29 PM, Yoshiki Ohshima <[hidden email]> wrote:
>>
>> Thank you everybody for all the help!  We'll need to fold these
>> changes and I'll test a few more configurations so that a novice user
>> invoking Scratch on Raspbian sees everything al right, but it is
>> getting there!
>
> I wish I could have offered something but unix non-anglo character input is so far outside my area I probably can’t even spell it correctly…
> but once you’ve got it working to your satisfaction I can certainly make sure it gets into the next available Pi release.

Great.  One thing I just started poking around was how Scratch
actually gets executed when you choose it from the menu.  What would
have to happen is that the script executed from there (I presume
/usr/bin/scratch) checks the LANG environment variable (or call the
locale command, and when the result is either ja, ko, or cn (or
actually the value of XMODIFIERS has @im), it invokes the VM with
"-vm-display-X11 -compositioninput".

Then to the image, two changes to ImmX11>> keyboardFocusForMorph and
StringFieldMorph>> keyboardFocusChange.  There are some others that
implement #keyboardFocusChange: but I have not all understood which
ones are relevant to Scratch, and keyboard text input.

With those, and the change to recordPendingKeys(), it will be in good shape.

--
-- Yoshiki

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: International text input on X11

David T. Lewis
On Sun, May 15, 2016 at 02:16:17PM -0700, Yoshiki Ohshima wrote:

> On Sun, May 15, 2016 at 1:32 PM, tim Rowledge <[hidden email]> wrote:
> >
> >> On 15-05-2016, at 1:29 PM, Yoshiki Ohshima <[hidden email]> wrote:
> >>
> >> Thank you everybody for all the help!  We'll need to fold these
> >> changes and I'll test a few more configurations so that a novice user
> >> invoking Scratch on Raspbian sees everything al right, but it is
> >> getting there!
> >
> > I wish I could have offered something but unix non-anglo character input is so far outside my area I probably can???t even spell it correctly???
> > but once you???ve got it working to your satisfaction I can certainly make sure it gets into the next available Pi release.
>
> Great.  One thing I just started poking around was how Scratch
> actually gets executed when you choose it from the menu.  What would
> have to happen is that the script executed from there (I presume
> /usr/bin/scratch) checks the LANG environment variable (or call the
> locale command, and when the result is either ja, ko, or cn (or
> actually the value of XMODIFIERS has @im), it invokes the VM with
> "-vm-display-X11 -compositioninput".
>
> Then to the image, two changes to ImmX11>> keyboardFocusForMorph and
> StringFieldMorph>> keyboardFocusChange.  There are some others that
> implement #keyboardFocusChange: but I have not all understood which
> ones are relevant to Scratch, and keyboard text input.
>
> With those, and the change to recordPendingKeys(), it will be in good shape.
>
> --
> -- Yoshiki

If I understand correctly, here is what we need to do:

1) Apply the changes of Mr Hachisuka to the VM.
 - The diff is in the earlier email from Yoshiki:
      http://lists.squeakfoundation.org/pipermail/squeak-dev/2016-May/189599.html
      http://www2.asu.ac.jp/hachi/v3/scratch14ime.html
 - Test updated VM to make sure the changes do not cause problems. Make sure
   it works without problems for Squeak trunk and for Scratch.
 - Apply the update in SVN for both oscog and trunk. I can help here.
 - Test the VM. Tim, I need help on this. I do not currently have a working
   Cog build environment (Unbuntu/autotools/gcc version issues). Can you
   apply the patch from Yoshiki's email and see if your resulting Cog VM
   continues to work for you as expected on Pi with Scratch?
 - Yoshiki, we should give credit to Mr Hachisuka for his contribution. Can
   you please give his full name for the commit notice? I assume the patch
   is MIT licensed.

2) Make updates to the image.
 - Start with Yoshiki's recommendations.
 - Make sure that it works in Scratch, and that all updates are also in
   Squeak trunk.

3) Make updates to the scripts that call Scratch from the menu (see above,
   this email).

4) Confirm that Scratch users around the world are happy :-)

Dave


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: International text input on X11

Yoshiki Ohshima-3
At Sun, 15 May 2016 22:27:13 -0400,
David T. Lewis wrote:

>
> On Sun, May 15, 2016 at 02:16:17PM -0700, Yoshiki Ohshima wrote:
> > On Sun, May 15, 2016 at 1:32 PM, tim Rowledge <[hidden email]> wrote:
> > >
> > >> On 15-05-2016, at 1:29 PM, Yoshiki Ohshima <[hidden email]> wrote:
> > >>
> > >> Thank you everybody for all the help!  We'll need to fold these
> > >> changes and I'll test a few more configurations so that a novice user
> > >> invoking Scratch on Raspbian sees everything al right, but it is
> > >> getting there!
> > >
> > > I wish I could have offered something but unix non-anglo character input is so far outside my area I probably can???t even spell it correctly???
> > > but once you???ve got it working to your satisfaction I can certainly make sure it gets into the next available Pi release.
> >
> > Great.  One thing I just started poking around was how Scratch
> > actually gets executed when you choose it from the menu.  What would
> > have to happen is that the script executed from there (I presume
> > /usr/bin/scratch) checks the LANG environment variable (or call the
> > locale command, and when the result is either ja, ko, or cn (or
> > actually the value of XMODIFIERS has @im), it invokes the VM with
> > "-vm-display-X11 -compositioninput".
> >
> > Then to the image, two changes to ImmX11>> keyboardFocusForMorph and
> > StringFieldMorph>> keyboardFocusChange.  There are some others that
> > implement #keyboardFocusChange: but I have not all understood which
> > ones are relevant to Scratch, and keyboard text input.
> >
> > With those, and the change to recordPendingKeys(), it will be in good shape.
> >
> > --
> > -- Yoshiki
>
> If I understand correctly, here is what we need to do:
>
> 1) Apply the changes of Mr Hachisuka to the VM.
>  - The diff is in the earlier email from Yoshiki:
>       http://lists.squeakfoundation.org/pipermail/squeak-dev/2016-May/189599.html

Yes, the attachment to my email is basically a reformatted version of
Mr. Hachisuka's patch (with an ifdef)

>       http://www2.asu.ac.jp/hachi/v3/scratch14ime.html
>  - Test updated VM to make sure the changes do not cause problems. Make sure
>    it works without problems for Squeak trunk and for Scratch.

Yes.  One potential problem I think is that there is an assumption
that the code delivered to the pendingKeys is UTF-8.  On a platform
this assumption is not correct, we would need an additional mechanism.

>  - Apply the update in SVN for both oscog and trunk. I can help
>  - here.

Thanks!

>  - Test the VM. Tim, I need help on this. I do not currently have a working
>    Cog build environment (Unbuntu/autotools/gcc version issues). Can you
>    apply the patch from Yoshiki's email and see if your resulting Cog VM
>    continues to work for you as expected on Pi with Scratch?

And more testing would be nice.

>  - Yoshiki, we should give credit to Mr Hachisuka for his contribution. Can
>    you please give his full name for the commit notice? I assume the patch
>    is MIT licensed.

I'll ask him about the license.

> 2) Make updates to the image.
>  - Start with Yoshiki's recommendations.
>  - Make sure that it works in Scratch, and that all updates are also in
>    Squeak trunk.
>
> 3) Make updates to the scripts that call Scratch from the menu (see above,
>    this email).

I'll work on the script (I think) today.

> 4) Confirm that Scratch users around the world are happy :-)

Thank you!

-- Yoshiki

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: International text input on X11

timrowledge
Forgive me if I’m being hopelessly naive here, but does this text input mechanism work for other languages too? Would it, for example, be usable as an on-screen keyboard for theRaspberry Pi lcd touchscreen?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Sona si Latine loqueris = Honk if you speak Latin.



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: International text input on X11

Yoshiki Ohshima-3
On Mon, May 16, 2016 at 10:04 AM, tim Rowledge <[hidden email]> wrote:
> Forgive me if I’m being hopelessly naive here, but does this text input mechanism work for other languages too? Would it, for example, be usable as an on-screen keyboard for theRaspberry Pi lcd touchscreen?

It should work for any other languages that ibus or scim can handle.
Yes, it will be usable with the on-screen keyboard.


--
-- Yoshiki

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: International text input on X11

Yoshiki Ohshima-3
On Mon, May 16, 2016 at 10:06 AM, Yoshiki Ohshima
<[hidden email]> wrote:
> On Mon, May 16, 2016 at 10:04 AM, tim Rowledge <[hidden email]> wrote:
>> Forgive me if I’m being hopelessly naive here, but does this text input mechanism work for other languages too? Would it, for example, be usable as an on-screen keyboard for theRaspberry Pi lcd touchscreen?
>
> It should work for any other languages that ibus or scim can handle.
> Yes, it will be usable with the on-screen keyboard.

So I wrote about two possible options on changes to /usr/bin/scratch;
I think that the option that uses the XMODIFIERS environment variable,
or some other ways to tell that there is an input method running, is
more suitable for this purpose.


--
-- Yoshiki

1234567
Loading...