[Pharo-project] Unicode test II
Hi all, after some interesting adventures in Unicode land here's a second version of the unicode test image/app: http://impara.de/~michael/unicode-test.zip Things that I think should work: - unicode text input on all platforms including support of composing character sequences (.eg. US international keyboards) - unicode clipboard handling - text editor shortcuts on non Latin1 keyboards (e.g. Russian) (thinking about it, only tested on Windows so far) Mostly untested: - unicode filename handling Known not to work: - keyboard shortcuts in lists (e.g. browsers) on non Latin1 keyboards. That would take another major refactoring of handling shortcuts. Once I know this version works reasonable well I'll package everything up for inclusion in the updates. Right now it is pretty much a mess. Happy testing Michael
Hi Michael, On Tue, Mar 3, 2009 at 8:11 AM, Michael Rueger <m.rueger@acm.org> wrote:
after some interesting adventures in Unicode land here's a second version of the unicode test image/app:
this one works very well for me. I'm able to type "éà ôç" in Pharo directly and copy-paste "à óøÅüÅáÃðf悉" from a text editor into Pharo. The following two characters are not well displayed in the workspace, but that could easily be a missing glyph in the font: $Å and $ð. Thank you very much -- Damien Cassou http://damiencassou.seasidehosting.st
On Tue, Mar 3, 2009 at 8:11 AM, Michael Rueger <m.rueger@acm.org> wrote:
after some interesting adventures in Unicode land here's a second version of the unicode test image/app:
this one works very well for me. I'm able to type "éà ôç" in Pharo directly and copy-paste "à óøÅüÅáÃðf悉" from a text editor into Pharo. The following two characters are not well displayed in the workspace, but that could easily be a missing glyph in the font: $Å and $ð.
Works for me as well. Tested on debian squeeze in all-UTF8 setup, with a text that has most french accents (not tested: combined chars as shown by Damien, northern or central european diacritics). Direct typing works, so does cut&paste from system to squeak. The same test file viewed in or imported to a workspace from Filelist doesn't, though (I guess it's not directly related).
On Tue, Mar 3, 2009 at 10:10 AM, Damien Cassou <damien.cassou@gmail.com> wrote:
this one works very well for me. I'm able to type "éà ôç" in Pharo directly and copy-paste "à óøÅüÅáÃðf悉" from a text editor into Pharo. The following two characters are not well displayed in the workspace, but that could easily be a missing glyph in the font: $Å and $ð.
my configuration is: GNU/Linux Ubuntu 8.04 32bits Keyboard layout: USA international with Alt-Gr dead key -- Damien Cassou http://damiencassou.seasidehosting.st
my configuration is:
GNU/Linux Ubuntu 8.04 32bits Keyboard layout: USA international with Alt-Gr dead key
Since you mention it... :) Layout here is canadian french (traditional I think... it's a '94 vintage keyboard), QWERTY with accents and AltCar (AltGr). "Ã" and altCar-accute accent (dead key) next to the right shift. Using any font other than the default Accuny, the characters displayed perfectly match keyboard markings. (With Accuny the differences are minor, and only on a few rarely used symbols on the first row.)
At Mon, 02 Mar 2009 23:11:00 -0800, Michael Rueger wrote:
Hi all,
after some interesting adventures in Unicode land here's a second version of the unicode test image/app:
http://impara.de/~michael/unicode-test.zip
Things that I think should work: - unicode text input on all platforms including support of composing character sequences (.eg. US international keyboards) - unicode clipboard handling - text editor shortcuts on non Latin1 keyboards (e.g. Russian) (thinking about it, only tested on Windows so far)
Mostly untested: - unicode filename handling
Known not to work: - keyboard shortcuts in lists (e.g. browsers) on non Latin1 keyboards. That would take another major refactoring of handling shortcuts.
Once I know this version works reasonable well I'll package everything up for inclusion in the updates. Right now it is pretty much a mess.
On Windows Vista in Japanese, the system seems to get the unicode values from keyboard but doesn't display them correctly. For short cut keys, when MS IME is enabled and in the Roma-ji input mode, it does work. -- Yoshiki
Yoshiki Ohshima wrote:
On Windows Vista in Japanese, the system seems to get the unicode values from keyboard but doesn't display them correctly. For short
Any idea why? I'm pretty sure I'm going through the correct process for the leading char. Is there any glyph translation needed for the rendering or the font import? Michael
At Tue, 03 Mar 2009 15:50:47 -0800, Michael Rueger wrote:
Yoshiki Ohshima wrote:
On Windows Vista in Japanese, the system seems to get the unicode values from keyboard but doesn't display them correctly. For short
Any idea why? I'm pretty sure I'm going through the correct process for the leading char. Is there any glyph translation needed for the rendering or the font import?
- The char typed into the workspace doesn't have the leading char. - If I open the browser and go to JapaneseEnvironment class>>isBreakableAt:in: (possibly the only method with Japanese characters), it doesn't display characters, even though the result from #sourceCodeAt: does contain strings with leading chars. So I loaded the good old FontForJapaneseEnvironment.sar and the latter case it does display characters properly. -- Yoshiki
At Wed, 04 Mar 2009 10:24:48 -0800, Michael Rueger wrote:
Yoshiki Ohshima wrote:
So I loaded the good old FontForJapaneseEnvironment.sar and the latter case it does display characters properly.
do you have that anywhere available so I can check out what code it changes?
available at: http://metatoys.org/pub/FontJapaneseEnvironment.sar It is basically an equivalent of: http://map.squeak.org/package/5279e9cb-1a06-4ddb-8eca-48ca954790d3 ("Japanese Environment Installer") -- Yoshiki
Yoshiki Ohshima wrote:
At Tue, 03 Mar 2009 15:50:47 -0800, Michael Rueger wrote:
Yoshiki Ohshima wrote:
On Windows Vista in Japanese, the system seems to get the unicode values from keyboard but doesn't display them correctly. For short Any idea why? I'm pretty sure I'm going through the correct process for the leading char. Is there any glyph translation needed for the rendering or the font import?
- The char typed into the workspace doesn't have the leading char.
Could you try if the attached patch fixes this? Thanks! Michael
At Wed, 11 Mar 2009 11:24:39 -0700, Michael Rueger wrote:
[1 <text/plain; ISO-8859-1 (7bit)>] Yoshiki Ohshima wrote:
At Tue, 03 Mar 2009 15:50:47 -0800, Michael Rueger wrote:
Yoshiki Ohshima wrote:
On Windows Vista in Japanese, the system seems to get the unicode values from keyboard but doesn't display them correctly. For short Any idea why? I'm pretty sure I'm going through the correct process for the leading char. Is there any glyph translation needed for the rendering or the font import?
- The char typed into the workspace doesn't have the leading char.
Could you try if the attached patch fixes this?
If I manually call #determineCurrentLocale manually to set CurrentPlatform, its locale becomes ja-JP but knownEnvironments only contains key for "ja" and couldn't find it. -- Yoshiki
It doesn't work for me. I am using Ubuntu 8.04 with latin american distribution. I am trying yo type "é", "ú", and so on, but with no luck. The problem is: I open a workspace. I type "á" and works fine. I try to type "á" again and I have this error: "'subscript is out of bounds: -60'" It is very strange because only the first time work. Cheers, Mariano On Tue, Mar 3, 2009 at 9:17 PM, Yoshiki Ohshima <yoshiki@vpri.org> wrote:
At Mon, 02 Mar 2009 23:11:00 -0800, Michael Rueger wrote:
Hi all,
after some interesting adventures in Unicode land here's a second version of the unicode test image/app:
http://impara.de/~michael/unicode-test.zip<http://impara.de/%7Emichael/unicode-test.zip>
Things that I think should work: - unicode text input on all platforms including support of composing character sequences (.eg. US international keyboards) - unicode clipboard handling - text editor shortcuts on non Latin1 keyboards (e.g. Russian) (thinking about it, only tested on Windows so far)
Mostly untested: - unicode filename handling
Known not to work: - keyboard shortcuts in lists (e.g. browsers) on non Latin1 keyboards. That would take another major refactoring of handling shortcuts.
Once I know this version works reasonable well I'll package everything up for inclusion in the updates. Right now it is pretty much a mess.
On Windows Vista in Japanese, the system seems to get the unicode values from keyboard but doesn't display them correctly. For short cut keys, when MS IME is enabled and in the Roma-ji input mode, it does work.
-- Yoshiki
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Mariano Martinez Peck wrote:
It doesn't work for me. I am using Ubuntu 8.04 with latin american distribution. I am trying yo type "é", "ú", and so on, but with no luck.
The problem is: I open a workspace. I type "á" and works fine. I try to type "á" again and I have this error: "'subscript is out of bounds: -60'"
It is very strange because only the first time work.
What kind of keyboard are you using? I had to do an incredibly ugly hack because of the way the Linux VM deals with composing key sequences, so it could be that I messed up the normal keyboard input. Sigh... Michael
On Tue, Mar 3, 2009 at 10:24 PM, Michael Rueger <m.rueger@acm.org> wrote:
Mariano Martinez Peck wrote:
It doesn't work for me. I am using Ubuntu 8.04 with latin american distribution. I am trying yo type "é", "ú", and so on, but with no luck.
The problem is: I open a workspace. I type "á" and works fine. I try to type "á" again and I have this error: "'subscript is out of bounds: -60'"
It is very strange because only the first time work.
What kind of keyboard are you using?
I had to do an incredibly ugly hack because of the way the Linux VM deals with composing key sequences, so it could be that I messed up the normal keyboard input. Sigh...
Dell 101-key PC with Latin American Layout. cheers
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Long ago when I thought I was going to be writing Operating Systems in Assembly Language, I had a raw keyboard driver interpreting the key codes from various keyboards. TERRIBLE to debug (though not as bad as debugging a display driver). Is that what all this is like? Ugh... Do you use lookup tables for all the various keyboard types and operating systems? It seems like you almost need a matrix of all the supported systems vs. all the possible keyboards, with a table for each one...it could just be a file in the image directory and get loaded at startup. Then, if someone has some weird keyboard, they could just edit the file... But then, I probably have no idea what I'm talking about!!! Rob On Tue, Mar 3, 2009 at 7:27 PM, Mariano Martinez Peck <marianopeck@gmail.com
wrote:
On Tue, Mar 3, 2009 at 10:24 PM, Michael Rueger <m.rueger@acm.org> wrote:
Mariano Martinez Peck wrote:
It doesn't work for me. I am using Ubuntu 8.04 with latin american distribution. I am trying yo type "é", "ú", and so on, but with no luck.
The problem is: I open a workspace. I type "á" and works fine. I try to type "á" again and I have this error: "'subscript is out of bounds: -60'"
It is very strange because only the first time work.
What kind of keyboard are you using?
I had to do an incredibly ugly hack because of the way the Linux VM deals with composing key sequences, so it could be that I messed up the normal keyboard input. Sigh...
Dell 101-key PC with Latin American Layout.
cheers
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Rob Rothwell wrote:
Long ago when I thought I was going to be writing Operating Systems in Assembly Language, I had a raw keyboard driver interpreting the key codes from various keyboards.
TERRIBLE to debug (though not as bad as debugging a display driver).
Is that what all this is like?
Ugh...
Do you use lookup tables for all the various keyboard types and operating systems?
It seems like you almost need a matrix of all the supported systems vs. all the possible keyboards, with a table for each one...it could just be a file in the image directory and get loaded at startup.
Then, if someone has some weird keyboard, they could just edit the file...
But then, I probably have no idea what I'm talking about!!!
Well, at some level that is what the OS is doing. Fortunately the VMs can work on a slightly higher level. But... Although all VMs now deliver unicode values in slot 6 of the input event, getting composing keyboards and latin1 based shortcut keys to work is still tricky. And I still haven't tested all the important combinations of OS and keyboard layouts yet. The Windows VM does a good job delivering composed sequences, you get all the intermediate keys (e.g. " and u), but only one keystroke event for the composed character. The Linux VM however delivers keystrokes for the intermediate keys, so I need to figure out, if there is a single key or a composing sequence coming up. That's where the ugly hack comes in, peeking for the next event etc. Supporting Latin1 based shortcut keys (x c v cut copy paste etc) is so far only tested and probably only there working on Windows. It works by looking at the scancode of the key, which is only delivered on the key down and up events. Then, in dispatch, I need to look at the unicode value delivered, but also at the scan code and if a modifier is pressed. The problem is that dispatching of key commands is implemented differently all over the system and in no place used the event, but simply the character. I refactored it for paragraph editor, but not all the other places. In Sophie we got around that by hacking the Tweak widgets to use factored out lookup tables, so there was only one place to deal with that. Michael
Michael, i got an in MultiCompositionScanner. I can't mail out a bug report, because when doing it, i again get the same error. Can i send an image.zip to you, so you can take a look at it? 2009/3/4 Michael Rueger <m.rueger@acm.org>:
Rob Rothwell wrote:
Long ago when I thought I was going to be writing Operating Systems in Assembly Language, I had a raw keyboard driver interpreting the key codes from various keyboards.
TERRIBLE to debug (though not as bad as debugging a display driver).
Is that what all this is like?
Ugh...
Do you use lookup tables for all the various keyboard types and operating systems?
It seems like you almost need a matrix of all the supported systems vs. all the possible keyboards, with a table for each one...it could just be a file in the image directory and get loaded at startup.
Then, if someone has some weird keyboard, they could just edit the file...
But then, I probably have no idea what I'm talking about!!!
Well, at some level that is what the OS is doing. Fortunately the VMs can work on a slightly higher level. But...
Although all VMs now deliver unicode values in slot 6 of the input event, getting composing keyboards and latin1 based shortcut keys to work is still tricky. And I still haven't tested all the important combinations of OS and keyboard layouts yet.
The Windows VM does a good job delivering composed sequences, you get all the intermediate keys (e.g. " and u), but only one keystroke event for the composed character. The Linux VM however delivers keystrokes for the intermediate keys, so I need to figure out, if there is a single key or a composing sequence coming up. That's where the ugly hack comes in, peeking for the next event etc.
Supporting Latin1 based shortcut keys (x c v cut copy paste etc) is so far only tested and probably only there working on Windows. It works by looking at the scancode of the key, which is only delivered on the key down and up events. Then, in dispatch, I need to look at the unicode value delivered, but also at the scan code and if a modifier is pressed. The problem is that dispatching of key commands is implemented differently all over the system and in no place used the event, but simply the character. I refactored it for paragraph editor, but not all the other places.
In Sophie we got around that by hacking the Tweak widgets to use factored out lookup tables, so there was only one place to deal with that. - Show quoted text - Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
2009/3/4 Igor Stasenko <siguctua@gmail.com>:
Michael, i got an in MultiCompositionScanner. i mean error... :)
I can't mail out a bug report, because when doing it, i again get the same error.
Can i send an image.zip to you, so you can take a look at it?
2009/3/4 Michael Rueger <m.rueger@acm.org>: - Show quoted text -
Rob Rothwell wrote:
Long ago when I thought I was going to be writing Operating Systems in Assembly Language, I had a raw keyboard driver interpreting the key codes from various keyboards.
TERRIBLE to debug (though not as bad as debugging a display driver).
Is that what all this is like?
Ugh...
Do you use lookup tables for all the various keyboard types and operating systems?
It seems like you almost need a matrix of all the supported systems vs. all the possible keyboards, with a table for each one...it could just be a file in the image directory and get loaded at startup.
Then, if someone has some weird keyboard, they could just edit the file...
But then, I probably have no idea what I'm talking about!!!
Well, at some level that is what the OS is doing. Fortunately the VMs can work on a slightly higher level. But...
Although all VMs now deliver unicode values in slot 6 of the input event, getting composing keyboards and latin1 based shortcut keys to work is still tricky. And I still haven't tested all the important combinations of OS and keyboard layouts yet.
The Windows VM does a good job delivering composed sequences, you get all the intermediate keys (e.g. " and u), but only one keystroke event for the composed character. The Linux VM however delivers keystrokes for the intermediate keys, so I need to figure out, if there is a single key or a composing sequence coming up. That's where the ugly hack comes in, peeking for the next event etc.
Supporting Latin1 based shortcut keys (x c v cut copy paste etc) is so far only tested and probably only there working on Windows. It works by looking at the scancode of the key, which is only delivered on the key down and up events. Then, in dispatch, I need to look at the unicode value delivered, but also at the scan code and if a modifier is pressed. The problem is that dispatching of key commands is implemented differently all over the system and in no place used the event, but simply the character. I refactored it for paragraph editor, but not all the other places.
In Sophie we got around that by hacking the Tweak widgets to use factored out lookup tables, so there was only one place to deal with that. - Show quoted text - Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
- Show quoted text - -- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
Igor Stasenko wrote:
2009/3/4 Igor Stasenko <siguctua@gmail.com>:
Michael, i got an in MultiCompositionScanner. i mean error... :)
I can't mail out a bug report, because when doing it, i again get the same error.
bummer Hmm, shouldn't there be a SqueakDebug.log file though? at least the method in question and a brief description of what you did would help :-) Michael
2009/3/4 Michael Rueger <m.rueger@acm.org>:
Igor Stasenko wrote:
2009/3/4 Igor Stasenko <siguctua@gmail.com>:
Michael, i got an in MultiCompositionScanner. i mean error... :)
I can't mail out a bug report, because when doing it, i again get the same error.
bummer Hmm, shouldn't there be a SqueakDebug.log file though?
at least the method in question and a brief description of what you did would help :-)
i changed default font to Arial , to see russian letters while i typing.. then i typed some of them in transcript window.. then i tried to copy/paste text - it works well.. but then at some point it throws me an error subscript out of bounds: 1075 in scanMultiCharactersCombiningFrom: startIndex to: stopIndex in: sourceString rightX: rightX stopConditions: stops kern: kernDelta method near following statement: (encoding = 0 and: [(stopConditions at: charCode + 1) ~~ nil]) ifTrue: [ more precisely (stopConditions at: charCode + 1) okay, i closed debugger, closed transcript, opened a fresh new one, and tried again.. and was unable to reproduce the error. Then i decided to go to preferences and change the freetype hinting options.. once i clicked on it i got the same error. a transcript window contains following chars: ÑÑвÑÑ Ð²ÑÑ Ð²ÑÑ Ð²ÑÑ Ð¹Ñ ÑÑоÑйвÑÑÑÐ¾Ð²Ñ Ð¾ÑооÑйв йÑоÑоÑÑÑовÑÑвйÑовÑйÑоÑйÑовÑвйÑовÑйв
- Show quoted text - Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Igor Stasenko wrote:
2009/3/4 Michael Rueger <m.rueger@acm.org>:
scanMultiCharactersCombiningFrom: startIndex to: stopIndex in: sourceString rightX: rightX stopConditions: stops kern: kernDelta
method near following statement: (encoding = 0 and: [(stopConditions at: charCode + 1) ~~ nil]) ifTrue: [
hmm, could be that the encoding gets lost somewhere and so allows the code to enter the block. I think we rather need to test for charCode < 256 as the stopConditions are only of that size for any encoding AFAIK. Michael
Mariano Martinez Peck wrote:
On Tue, Mar 3, 2009 at 10:24 PM, Michael Rueger <m.rueger@acm.org <mailto:m.rueger@acm.org>> wrote:
Mariano Martinez Peck wrote: > It doesn't work for me. I am using Ubuntu 8.04 with latin american > distribution. I am trying yo type "é", "ú", and so on, but with no luck. > > The problem is: I open a workspace. I type "á" and works fine. I try to > type "á" again and I have this error: "'subscript is out of bounds: -60'" > > It is very strange because only the first time work.
I can't reproduce that problem (ubuntu 8 under virtual box, keyboard layout set to latin american default). Could you check if there is SqueakDebug.log file I could look at? Thanks Michael
2009/3/5 Michael Rueger <m.rueger@acm.org>:
Mariano Martinez Peck wrote:
On Tue, Mar 3, 2009 at 10:24 PM, Michael Rueger <m.rueger@acm.org <mailto:m.rueger@acm.org>> wrote:
  Mariano Martinez Peck wrote:    > It doesn't work for me. I am using Ubuntu 8.04 with latin american    > distribution. I am trying yo type "é", "ú", and so on, but with   no luck.    >    > The problem is: I open a workspace. I type "á" and works fine. I   try to    > type "á" again and I have this error: "'subscript is out of   bounds: -60'"    >    > It is very strange because only the first time work.
I can't reproduce that problem (ubuntu 8 under virtual box, keyboard layout set to latin american default). Could you check if there is SqueakDebug.log file I could look at?
i still can send you an image :)
Thanks - Show quoted text - Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
I send you the wallback: Thanks in advance, Mariano VM: unix - a SmalltalkImage Image: Pharo0.1 [Latest update: #10202] SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir /home/mariano/squeak/imagenes/unicode-test.app/Contents/Resources Trusted Dir /home/mariano/squeak/imagenes/unicode-test.app/Contents/Resources/secure Untrusted Dir /home/mariano/squeak/imagenes/unicode-test.app/Contents/Resources/My Squeak Array(Object)>>error: Receiver: #(Character value: 0 Character home Character value: 2 Character enter Character end Chara...etc... Arguments and temporary variables: aString: 'subscript is out of bounds: -60' Receiver's instance variables: #(Character value: 0 Character home Character value: 2 Character enter Character end Chara...etc... Array(Object)>>errorSubscriptBounds: Receiver: #(Character value: 0 Character home Character value: 2 Character enter Character end Chara...etc... Arguments and temporary variables: index: -60 Receiver's instance variables: #(Character value: 0 Character home Character value: 2 Character enter Character end Chara...etc... Array(Object)>>at: Receiver: #(Character value: 0 Character home Character value: 2 Character enter Character end Chara...etc... Arguments and temporary variables: index: -60 Receiver's instance variables: #(Character value: 0 Character home Character value: 2 Character enter Character end Chara...etc... Character class>>value: Receiver: Character Arguments and temporary variables: anInteger: -61 Receiver's instance variables: superclass: Magnitude methodDict: a MethodDictionary(#<->a CompiledMethod (3127) #=->a CompiledMethod...etc... format: 132 instanceVariables: #('value') organization: ('*packageinfo-base' escapeEntities) ('accessing' asciiValue char...etc... subclasses: nil name: #Character classPool: a Dictionary(#CharacterTable->#(Character value: 0 Character home Ch...etc... sharedPools: nil environment: Smalltalk category: #'Collections-Strings' traitComposition: nil localSelectors: nil --- The full stack --- Array(Object)>>error: Array(Object)>>errorSubscriptBounds: Array(Object)>>at: Character class>>value: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - SmallInteger(Integer)>>asCharacter TextMorphEditor>>dispatchOnKeyEvent:with: TextMorphEditor(ParagraphEditor)>>keystroke: TextMorphEditor>>keystroke: [] in TextMorphForEditView(TextMorph)>>keyStroke: {[editor keystroke: evt]} TextMorphForEditView(TextMorph)>>handleInteraction: TextMorphForEditView>>handleInteraction: TextMorphForEditView(TextMorph)>>keyStroke: TextMorphForEditView>>keyStroke: TextMorphForEditView(TextMorph)>>handleKeystroke: KeyboardEvent>>sentTo: TextMorphForEditView(Morph)>>handleEvent: TextMorphForEditView(Morph)>>handleFocusEvent: [] in HandMorph>>sendFocusEvent:to:clear: {[ActiveHand := self. ActiveEvent := anEvent. result := focusHolder han...]} [] in PasteUpMorph>>becomeActiveDuring: {[aBlock value]} BlockContext>>on:do: PasteUpMorph>>becomeActiveDuring: HandMorph>>sendFocusEvent:to:clear: HandMorph>>sendEvent:focus:clear: HandMorph>>sendKeyboardEvent: HandMorph>>handleEvent: HandMorph>>processEvents [] in WorldState>>doOneCycleNowFor: {[:h | ActiveHand := h. h processEvents. ActiveHand := nil]} Array(SequenceableCollection)>>do: WorldState>>handsDo: WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor: PasteUpMorph>>doOneCycle [] in Project class>>spawnNewProcess {[[World doOneCycle. Processor yield. false] whileFalse. nil]} [] in BlockContext>>newProcess {[self value. Processor terminateActive]} On Thu, Mar 5, 2009 at 12:16 AM, Michael Rueger <m.rueger@acm.org> wrote:
Mariano Martinez Peck wrote:
On Tue, Mar 3, 2009 at 10:24 PM, Michael Rueger <m.rueger@acm.org <mailto:m.rueger@acm.org>> wrote:
Mariano Martinez Peck wrote: > It doesn't work for me. I am using Ubuntu 8.04 with latin american > distribution. I am trying yo type "é", "ú", and so on, but with no luck. > > The problem is: I open a workspace. I type "á" and works fine. I try to > type "á" again and I have this error: "'subscript is out of bounds: -60'" > > It is very strange because only the first time work.
I can't reproduce that problem (ubuntu 8 under virtual box, keyboard layout set to latin american default). Could you check if there is SqueakDebug.log file I could look at?
Thanks
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Mariano Martinez Peck wrote:
I send you the wallback:
Character class>>value: Receiver: Character Arguments and temporary variables: anInteger: -61
OK, that can't work...
TextMorphEditor>>dispatchOnKeyEvent:with: TextMorphEditor(ParagraphEditor)>>keystroke:
Could you tell me the inst var values of the key event passed here? Especially interesting are keyValue charCode scanCode No idea yet why that value is negative... Thanks Michael
keyValue: -61 charCode: 225 scanCode: -61 greetings, Mariano On Tue, Mar 10, 2009 at 3:03 AM, Michael Rueger <m.rueger@acm.org> wrote:
Mariano Martinez Peck wrote:
I send you the wallback:
Character class>>value: Receiver: Character Arguments and temporary variables: anInteger: -61
OK, that can't work...
TextMorphEditor>>dispatchOnKeyEvent:with: TextMorphEditor(ParagraphEditor)>>keystroke:
Could you tell me the inst var values of the key event passed here?
Especially interesting are keyValue charCode scanCode
No idea yet why that value is negative...
Thanks
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Tue, Mar 10, 2009 at 3:45 AM, Michael Rueger <m.rueger@acm.org> wrote:
Mariano Martinez Peck wrote:
keyValue: -61 charCode: 225 scanCode: -61
Thanks!
OK, no idea (yet) how these values happen, but could you be so kind to file in the attached change and see if that works?
No :( Still having the same error. Any idea? let me know how can I help. Cheers, Mariano
Thanks
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Sorry for the bad news. But still doesn't work. The first time I type "á" when I open the image, works perfect. But after that, every time I type that, I have the detailed wallback. Thanks, Mariano On Wed, Mar 11, 2009 at 4:04 PM, Michael Rueger <m.rueger@acm.org> wrote:
Mariano Martinez Peck wrote:
No :( Still having the same error. Any idea? let me know how can I help.
OK, here's an additional patch (attached).
Thanks for testing!
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Mariano Martinez Peck wrote:
Sorry for the bad news. But still doesn't work. The first time I type "á" when I open the image, works perfect. But after that, every time I type that, I have the detailed wallback.
Hmm, if I could only reproduce it here... You said you are using the latin american keyboard. When you type á, do you first hit ' and then a? Thanks for testing, I just hope I can figure this out... Michael
On Fri, Mar 13, 2009 at 3:04 PM, Michael Rueger <m.rueger@acm.org> wrote:
Mariano Martinez Peck wrote:
Sorry for the bad news. But still doesn't work. The first time I type "á" when I open the image, works perfect. But after that, every time I type that, I have the detailed wallback.
Hmm, if I could only reproduce it here...
You said you are using the latin american keyboard. When you type á, do you first hit ' and then a?
Actually I type the key that has these three keys: "`", "[" and "^" and then "a".
Thanks for testing, I just hope I can figure this out...
No problem at all. I hope to help with my testing.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-61 mmm 0xFFFFFFC3 ? mmmm int utf32Code; /* UTF-32 unicode value */ mmmm does anyone consider the data coming back could be a 32bit value that is unsigned? mmmm value = positive32BitIntegerFor(value); oh details details... oh wait look we ask if the value is an integervalue, aka a SmallInteger, if it is then we pass it up, if it's not a SmallInteger, thus a Large Integer, we decide to pass it up as a Positive 32bit value. Ergo if the value was 0xFFFFFFC3 why then it would flow up as a negative SmallIInteger, like -61, then twist the mind of Michael? On Mon, Mar 9, 2009 at 10:03 PM, Michael Rueger <m.rueger@acm.org> wrote:
Mariano Martinez Peck wrote:
I send you the wallback:
Character class>>value:   Receiver: Character   Arguments and temporary variables:     anInteger:   -61
OK, that can't work...
TextMorphEditor>>dispatchOnKeyEvent:with: TextMorphEditor(ParagraphEditor)>>keystroke:
Could you tell me the inst var values of the key event passed here?
Especially interesting are keyValue charCode scanCode
No idea yet why that value is negative...
Thanks
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
John McIntosh wrote:
-61 mmm
Ergo if the value was 0xFFFFFFC3 why then it would flow up as a negative SmallIInteger, like -61, then twist the mind of Michael?
This is on Linux, if that makes a difference. Question is why that hasn't happened before. Could be the changes I made for dealing with the key scancode on Windows, thinking about it. Michael
Great, keyboard shortcuts now is working under russian keyboard layout in windoze! 2009/3/3 Michael Rueger <m.rueger@acm.org>:
Hi all,
after some interesting adventures in Unicode land here's a second version of the unicode test image/app:
http://impara.de/~michael/unicode-test.zip
Things that I think should work: - unicode text input on all platforms including support of composing character sequences (.eg. US international keyboards) - unicode clipboard handling - text editor shortcuts on non Latin1 keyboards (e.g. Russian) (thinking about it, only tested on Windows so far)
Mostly untested: - unicode filename handling
Known not to work: - keyboard shortcuts in lists (e.g. browsers) on non Latin1 keyboards. That would take another major refactoring of handling shortcuts.
Once I know this version works reasonable well I'll package everything up for inclusion in the updates. Right now it is pretty much a mess.
Happy testing
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On Tue, Mar 3, 2009 at 2:11 PM, Michael Rueger <m.rueger@acm.org> wrote:
Hi all,
after some interesting adventures in Unicode land here's a second version of the unicode test image/app:
http://impara.de/~michael/unicode-test.zip
Things that I think should work: - unicode text input on all platforms including support of composing character sequences (.eg. US international keyboards) - unicode clipboard handling - text editor shortcuts on non Latin1 keyboards (e.g. Russian) (thinking about it, only tested on Windows so far)
It seems to work with a french keyboard on Mac OS X. I try with a vietnamese keyboard but i think i need a vietnamese font. -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/
participants (9)
-
Alexis Parseghian -
Damien Cassou -
Igor Stasenko -
John McIntosh -
Mariano Martinez Peck -
Michael Rueger -
Rob Rothwell -
Serge Stinckwich -
Yoshiki Ohshima