well you can't just stop supporting codesets over night, well the english specking country’s wont mind, there are few old and new programs that will have bit of problem displaying UTF8 special symbols aka €,ØÆÅ,ø,æ,å and and all the letters of other nationality’s.
I bet there are few people are using TurboCalc and AmigaWriter, Wordworth, FinalWriter.
people are going to be bit desperate, when they do not see or can use programs as they used to.
Quote:
the method is unintuitive
I remember back in Workbench 1.2 it used to be a simple command in S:Startup-sequence.
Setmap n.
I think codeset's was introduced to support, non European countries.
I think it is more logical if the codeset was linked to the keyboard.
As it is now I need to select two different setting, that has to match whit each other.
Now in Locales you have multiple language option for one Language whit different codesets, expecting the user to know what a codeset is. (if what I say makes sense)
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
This is another area where UTF-8 would really help, as the user wouldn't need to select a character set. As already indicated, the method is unintuitive, however the process shouldn't be needed at all.
But the user doesn't need to select a character set, they set a language and the primaray language sets the character set. It's only under rare circumstances that they need to care what the character set is.
[edit] Also note the character set in use is displayed in the name of the primary language eg: bulgarian_Amiga-1251 except when it's the default od iso-8859-1.
So when choosing a keyboard map for a language with a choice of character sets you can choose the one that matches you language.
Note that ofcourse the keyboard map must actually match the *keyboard* for example if you are using Englsh-Britsih-ISO-8859-15 but have a french keyboard you need to use the French-ISO-8859-15 keyboardmap.
Even if you used utf-8 codes you *still* need to choose a keyboard map [/edit]
Edited by broadblues on 2014/3/7 19:49:15 Edited by broadblues on 2014/3/7 19:50:38
I think it is more logical if the codeset was linked to the keyboard.
No the codeset *must* be set to the main language else you may not be able to read an gadgets / menus etc etc.
If the 8bit codeset was set by my UK keyboard then I would never be able to view languages which used other characters (like just now hen I switch to bulgarian as a random test to check if the codeset was including in the language name. ).
Note that ofcourse the keyboard map must actually match the *keyboard* for example if you are using Englsh-Britsih-ISO-8859-15 but have a french keyboard you need to use the French-ISO-8859-15 keyboardmap.
Even if you used utf-8 codes you *still* need to choose a keyboard map
True, but you wouldn't need to pick between UK_ISO-8859-1 and UK_ISO-8859-15, because everything would be UTF-8 so the distinction would be irrelevant (bar a few different characters). You could even have characters supported that don't exist in either of those character sets (like ŷ, which is useful for Welsh, and I had to copy'n'paste because even though I have a ^ dead key, it doesn't work with y as that character doesn't exist in the character set I'm using for my keyboard)
@All: I agree with Broadblues here in that the Keyboard map is for the physcal device.
My understanding is that different systems have different "default" codesets and the safest option would actually be UTF-8.
At least I am working on UTF-8 strings being translated from the basic ISO-Latin-1 "RAWKEY" and "EXTENDEDRAWKEY" InputEvents.
I am putting my own InputHandler() in front of Intuition but after commodities.
Which actually makes you need to consider the following as always true "The keyboard has no relation to the coding of characters beyond the keymap".
Honestly I don't understand where this "I set Key*map* X therefore I am using Codeset Y" logic comes from.
the Keymap is only specific to the keyboard, character encoding of glyphs after that point can be entirely dissassociated from the keyboard after that point.
my own Perception-IME project is specifically setting up where any given key on a keyboard may have a glyph selection from two, three or more fully independent mappings that have no relation to each other at all.
The only consistency will be what is fed to Intuition once the specific extensions for InputMethodEditing to UTF-8 is worked out.
And I am in two minds as to whether to provide a 7bit safe URLencoded form or go with a more raw binary encoding.
My understanding is that different systems have different "default" codesets and the safest option would actually be UTF-8.
Old programs does not support it, so you will need to support codesets and UTF8 at the same time.
Quote:
Honestly I don't understand where this "I set Key*map* X therefore I am using Codeset Y" logic comes from.
Lett say you have your keymap as Bulgarian, but your code set is another language, then you want be able to see correct symbols, even if you configured the keyboard correct.
But if you use let say English language in your programs, then this should work because its 7bit, despite the codeset. That's way it makes more sense, if codeset was linked to keymap not the Language option.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
ett say you have your keymap as Bulgarian, but your code set is another language, then you want be able to see correct symbols, even if you configured the keyboard correct.
But if you use let say English language in your programs, then this should work because its 7bit, despite the codeset. That's way it makes more sense, if codeset was linked to keymap not the Language option.
No it doesn't. The language option needs to define the correct charset, otherwise the characters needed for that language won't be available.
The keymap charset is secondary. If you type using a different charset then you might see the wrong characters (however the keymap knows which charset it is, so it should probably have a go at converting, but I'm not sure it does?)
edit I just had a go with the aforementioned Welsh keymap. If I try to type ŷ it just comes out as y rather than some other random character, so it is coping properly with character set differences.
Now, the question I'm interested in, is can some software get keyboard input through MapRawKeys() without it being munged into the system default charset?
Now, the question I'm interested in, is can some software get keyboard input through MapRawKeys() without it being munged into the system default charset?
Yes I believe so, Its mostly games that does that, or else you need to handel all Upper/Lower case and so on your self, Shift keys, Caps Lock.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
So if the charset is tied with the particular locale (language), and the user doesn't need to care about it, wouldn't it be wiser to remove the charset column from the Locale prefs editor alltogether, and make the interface less confusing?
It can't when the codeset used can't hold two different Glyph values for a ASCII code, The only Language that works whit almost all keymaps is English, because its 7bit. Anyway if my 8bit kaymap some how was converted into 7bit ASCII (look alike symbols), then my current configuration want be possible for me.
Edited by LiveForIt on 2014/3/8 11:30:08
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
Now, the question I'm interested in, is can some software get keyboard input through MapRawKeys() without it being munged into the system default charset?
Fram the IKeyboard->MapRawKey() autodoc.
This console function converts input events of type IECLASS_RAWKEY to ANSI bytes, based on the keyMap, and places the result into the buffer.
The MapRawKey function does not 'Munge to the system' Codeset at all, it converts to the codes specified in the keymap.
edit I just had a go with the aforementioned Welsh keymap. If I try to type ? it just comes out as y rather than some other random character, so it is coping properly with character set differences.
Does your weslh keymap suport the euro sysmbol? If so then it's likely mapping to the y to avoid the fact that y with circumflex ŷ was replaced with another symbol in iso-8859-15
(see joerg's earlier wikipedia link)
edit got confused with y with diaresis ÿ I've no idea what 8bit character set might contain that ŷ symbol.
BTW you said you cut and paste earlier never heard of character refs in HTML ? ŷ (hopes I got that right ...)
Edited by broadblues on 2014/3/8 12:08:31 Edited by broadblues on 2014/3/8 12:09:17
So if the charset is tied with the particular locale (language), and the user doesn't need to care about it, wouldn't it be wiser to remove the charset column from the Locale prefs editor alltogether, and make the interface less confusing?
No because, *most* of the time they don't need to care, but occasionally they do (especially if they are developers or translaters as well as users). I supppose you could hide it in a advanced option but why go that effort? It doesn't do any harm at all to know that codesets exists.
The MapRawKey function does not 'Munge to the system' Codeset at all, it converts to the codes specified in the keymap.
That's not my experience. I'll explain a bit further.
I'm running in English ISO-8859-15 Locale. I have a keymap I made ages ago (I'm using it for this test because I know roughly what the character differences are), which is in ISO-8859-14. If I try to type a character that doesn't exist in ISO-8859-15 I get a non-accented version. I'm not sure if keymap.library is intelligently saying "here's another character that'll do", or if it's picking the character with no modifiers. But it must be able to determine that the character is not valid for ISO-8859-15 as if it was blindly selecting it I'd get "þ" printed.
You can try a similar test by selecting ISO-8859-1 as the system charset, an ISO-8859-15 keymap, and then trying to type € in the test box...
Quote:
edit got confused with y with diaresis ÿ I've no idea what 8bit character set might contain that ŷ symbol.
ISO-8859-14.
Quote:
BTW you said you cut and paste earlier never heard of character refs in HTML ? ŷ (hopes I got that right ...)
Yes, but (a) I didn't realise the forum would accept them and (b) I'd still have to look them up so I may as well just copy'n'paste whilst I'm there
You can try a similar test by selecting ISO-8859-1 as the system charset, an ISO-8859-15 keymap, and then trying to type € in the test box...
Hmm I got a ? when pressing alt-3 instead of a € and not ¤ which is what should be at position A4 in iso-8859-1
Investigating the keymaps I see some are encoded in utf-8 (inlcuding the gb_iso-8859-15 one). So I suspect then that iconv (or equiv) is being used with the option to substitute the next best option when using an incompatable keymap.
There are quite a few functions in keymap.library for access keymap info other than through MapRawKey() but I couldn't begine to suggest how to use them the docs look line line noise to me!
There are quite a few functions in keymap.library for access keymap info other than through MapRawKey() but I couldn't begine to suggest how to use them the docs look line line noise to me!
I know what you mean. I think MapRawKeyUTF8() can be added to the list of "things that might be quite useful".
I don't know way want to encode it so early on, you might just keep it in 32bit uni code format, and let the programer decide what format it should be encoded into, UTF8/UTF16. Its not like your saving space, anyway. (UFT8 takes up 6 bytes, and you need to encode and decode it)
MapRawKeyUTF32() should be easy to do already by doing some thing like.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
