Way is there 3 prefs programs for Language settings?
I see just one (Locale), what are your three?
Quote:
Locale prefs has a Time Zone tab, so way is it a Timezone prefs program?
Really can't work out what you are saying here, is your question:
Why is there a seperate Timezone prefs?
Don't know, maybe there Timezone prefs is the result of a merged contribution that had a seperate prefs rpgram (speculation.)
or
Why is there time zone info in Locale?
Timezone is clearly related to where you are thus 'Locale' related.
Quote:
And also it bit strange to me that I find Language in Local prefs, but the code page settings in the Input prefs..
Look again, the code page settings are in Locale (they are set by choosing the language) the *keyboard mapping* is set in input prefs, which is clearly an input related datum.
And way does, Time prefs have settings for Time server, and stuff when there is TimeZone prefs.
It might make sense to merge TimeZone in Time but doesn't make sense to take time server out of Time and put it in TimeZone, as the server sets the Time. There aren't any TimeZone settings in the time server setting, you can just apply an arbitrary offset to GMT should you need to for some reason.
No the Language settings under local does not set the codepage, it sets the Language your program displays.
In other words if I wan to change langauge from English to Norwegian.
I first need to change the Keyboard codepage, in Input prefs. Then I need to change the local language settings in Local prefs.
In other words I need to change open and close two different prefs programs to change my language settings.
And to change back to English, will need to make two changes again, one in Local prefs and one in Input prefs.
It is not extremely convenient, beside the Input prefs has icon looking like a mouse, you can tell by just by looking at it that this controls the code page settings.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
It be better if the Input prefs was called mouse prefs, and code page stuff was moved to local.
It may be true that setting the keyboard ultimately affects the code page in use, but primrarialy you are setting the keyboard map, which is why it's in input prefs. You can have many keyboard maps with the same code page / language.
Copying IFF based Prefs files can be a potential problem under AmigaOS. If the files are not correct version.
IFF file nodes use "Struct" if this "Struct" are extended whit additional parameters in the IFF nodes, the size of struct increases, so when reading a old files the wrong data is read from the Prefs file, IPrefs crashes at startup sequence, and I be spending days trying to fix a issue, because of system upgrade from AmigaUpdate.
Considering the problems whit IFF files, AmigaOS should be thinking about adapting JSON format.
IFF file nodes use "Struct" if this "Struct" are extended whit additional parameters in the IFF nodes, the size of struct increases, so when reading a old files the wrong data is read from the Prefs file,
Your IFF reading code is seriously flawed if that is the case!. The size of any given chunk is specified in the file, so it's impossible to make this mistake with sane code.
Extra data is usually added in new chucks or occasionally if the chucnk description changes then versioning is used to switch between the different loading routines.
Quote:
IPrefs crashes at startup sequence, and I be spending days trying to fix a issue, because of system upgrade from AmigaUpdate.
IPrefs might crash from a corrupt file, but not from an old but valid prefs file. If you have a real case of that happening a bug report needs to be raised.
There is no difference between what Gazzelle is suggesting and a GUI theme except in this case it's a 'language theme'.
The size of any given chunk is specified in the file, so it's impossible to make this mistake with sane code.
All I see is a Casting from sp->sp_Data to (struct InputPrefs *) or some other prefs struct.
The example I'm seeing here does not verify the size of the struct whit the sp->sp_Data.
Quote:
Extra data is usually added in new chucks or occasionally if the chucnk description changes then versioning is used to switch between the different loading routines.
If that is the case then its not a problem.
Edited by LiveForIt on 2014/3/3 15:48:09
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
If you're not happy with the copy solution (and iprefs), you can also use the prefs programs (which should understand all of its own versions). They normaly have a template like "FROM,USE/S,SAVE/S,EDIT/S":
SYS:Prefs/Locale FROM myLocalePrefsFile USE SYS:Prefs/Input FROM myInputPrefsFile USE
The example I'm seeing here does not verify the size of the struct whit the sp->sp_Data.
It's a basic example that just prints out values. The Stored Property does have a size emeber which you should compare again sizeof(struct FooPrefs) before copying data or you are asking for trouble.
struct StoredProperty { LONG sp_Size; APTR sp_Data; };
And I think new prefs files are more likely to destroy old (bad) code as they tend to grow in size not shrink.
what I was really looking for some way to find codepage encoding, so I can use it whit iconv_open(), as I did not find a native Amiga API for encoding.
That's when I spend a lot of time googling and looking around, and did not find what I was looking for.
And then I expected language stuff to be in locals and did not find it there, next day I remembered it was in Input prefs
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
what I was really looking for some way to find codepage encoding, so I can use it whit iconv_open(), as I did not find a native Amiga API for encoding.
Actually I was looking for Environment variable for it, back in the old days it was as simple as listing the files in ENVARC: now some of the Environment variables are hidden.
PrintEnv only show local shell variables. GetEnv can only show one environment at a time. NvGetVar only list and gets UBOOT or CFE variables.
EDIT:
Silly me I was looking in ENVARC: not ENV:
EDIT:
And also Ranger does not display all the Env: variables, I guess I found a BUG!
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
Another solution that should work would be to use IDiskfont->GetDiskFontCtrl() with DFCTRL_CHARSET to get the IANA codeset number and then use this with IDiskfont->ObtainCharsetInfo() to get the name of the codeset.
as I did not find a native Amiga API for encoding.
AFAIK there are no other functions than the iconv ones, but for converting from/to unicode you can use the DFCS_MAPTABLE from IDiskFont->ObtainCharsetInfo().
Another solution that should work would be to use IDiskfont->GetDiskFontCtrl()
NOTES [...] This function should never be called by the average user. Its sole purpose is to provide the font preferences editor with data about the current diskfont settings. It should not be called for other purposes.
No the Language settings under local does not set the codepage, it sets the Language your program displays.
It sets the codepage as well, the one from the first language is used. To change the codepage you have to clear all selected languages, only if the list is empty the codepages are displayed for the languages, and use one with the codepage you want as the first one.
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
Donate
