International text input on X11
Locked
1234567
1234567
Re: International text input on X11
 
|
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) |
Re: International text input on X11
|
|
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 |
Re: International text input on X11
|
|
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 |
Re: International text input on X11
|
|
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, This is in struct SqDisplay in platforms/unix/vm/SqDisplay.h? Go for it :-)
_,,,^..^,,,_ best, Eliot |
Re: International text input on X11
|
|
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 |
Re: International text input on X11
|
|
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 |
Re: International text input on X11
|
|
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 |
Re: International text input on X11
|
|
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 |
Re: International text input on X11
|
|
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 |
Re: International text input on X11
|
|
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) |
Re: International text input on X11
|
|
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! |
Re: International text input on X11
|
|
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) |
Re: International text input on X11
|
|
(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. 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)
Re: International text input on X11
|
|
> 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. |
Re: International text input on X11
|
|
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 |
Re: International text input on X11
|
|
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 |
Re: International text input on X11
|
|
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 |
Re: International text input on X11
|
|
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. |
Re: International text input on X11
|
|
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 |
Re: International text input on X11
|
|
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 |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |