"Shachar Shemesh" <wine-patches(a)shemesh.biz> wrote:
* Add sample text characters for Symbol, Japanese, Greek, Turkish, Arabic, Baltic, Vietnamese, Russian, East European and Thai codepages.
Why to not add them into resources? That would simplify locale handling a lot, and make our translators actually notice that strings as well. -- Dmitry.
Dmitry Timoshkov wrote:
"Shachar Shemesh" <wine-patches(a)shemesh.biz> wrote:
* Add sample text characters for Symbol, Japanese, Greek, Turkish, Arabic, Baltic, Vietnamese, Russian, East European and Thai codepages.
Why to not add them into resources? That would simplify locale handling a lot, and make our translators actually notice that strings as well.
The main reason is that they are loaded based on encoding, rather than language. This has several implications that caused me not to go that route: 1. The mapping between encoding and charcter encoding is not a straightforward one. The reverse mapping is even less so. 2. The mapping is based on the selected locale, and does not care about the current language. These two mean that placing the sample text in a resource will only server to confuse the issue. The first point is even harder - what if you want different sample text for Chinese BIG-5 and the other Chinese encoding? Which language should I try to load for centeral Europe? French? German? I can only load one. In short, doing that through resources seems like an unnecessary complication to me. Add to that the fact that you still need the mapping table, and you get "ain't worth the hassle". Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/ The opinions expressed in this mail are my own, and do not necessarily represent the opinions of my employer. Wait! I am self employed! Hmm...
"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote:
The main reason is that they are loaded based on encoding, rather than language. This has several implications that caused me not to go that route: 1. The mapping between encoding and charcter encoding is not a straightforward one. The reverse mapping is even less so.
Well, GetTextCharset() does exactly what you want.
2. The mapping is based on the selected locale, and does not care about the current language.
The mapping should be based on the font charset, and actually has nothing to do with current language or locale.
These two mean that placing the sample text in a resource will only server to confuse the issue. The first point is even harder - what if you want different sample text for Chinese BIG-5 and the other Chinese encoding? Which language should I try to load for centeral Europe? French? German? I can only load one.
Exactly. GetTextCharset() is your friend here. Just have different strings for different charsets in the resources and load them at appropriate time.
In short, doing that through resources seems like an unnecessary complication to me. Add to that the fact that you still need the mapping table, and you get "ain't worth the hassle".
I hope you will reconsider. -- Dmitry.
How can this API be implemented so it does not have to use ReleaseThunkLock and RestoreThunkLock (at least the Win32 version)? DWORD WINAPI timeGetTime(void) { /* FIXME: releasing the win16 lock here is a temporary hack (I hope) * that lets mciavi.drv run correctly */ DWORD count; ReleaseThunkLock(&count); RestoreThunkLock(count); TIME_MMTimeStart(); return WINMM_IData->mmSysTimeMS; }
Casper Hornstrup wrote:
How can this API be implemented so it does not have to use ReleaseThunkLock and RestoreThunkLock (at least the Win32 version)?
DWORD WINAPI timeGetTime(void) { /* FIXME: releasing the win16 lock here is a temporary hack (I hope) * that lets mciavi.drv run correctly */ DWORD count; ReleaseThunkLock(&count); RestoreThunkLock(count); TIME_MMTimeStart(); return WINMM_IData->mmSysTimeMS; }
I see two ways of doing it: - either use a function pointer to ReleaseThunkLock & RestoreThunkLock which will be initialized if mmsystem is loaded (as we do for most of the 16 bit functions we need) - or load by hand these two function with GetProcAddress, and handle the case where they are not defined. I'd vote for the first one. A+ -- Eric Pouech
-----Oprindelig meddelelse----- Fra: Eric Pouech [mailto:pouech-eric(a)wanadoo.fr] Sendt: 30. november 2003 16:39 Til: Casper Hornstrup Cc: wine-devel(a)winehq.com Emne: Re: Mmsystem API timeGetTime
I see two ways of doing it: - either use a function pointer to ReleaseThunkLock & RestoreThunkLock which will be initialized if mmsystem is loaded (as we do for most of the 16 bit functions we need) - or load by hand these two function with GetProcAddress, and handle the case where they are not defined. I'd vote for the first one.
ReleaseThunkLock and RestoreThunkLock need only be called in mmsystem.dll? How about this patch?
Casper Hornstrup wrote:
-----Oprindelig meddelelse----- Fra: Eric Pouech [mailto:pouech-eric(a)wanadoo.fr] Sendt: 30. november 2003 16:39 Til: Casper Hornstrup Cc: wine-devel(a)winehq.com Emne: Re: Mmsystem API timeGetTime
I see two ways of doing it: - either use a function pointer to ReleaseThunkLock & RestoreThunkLock which will be initialized if mmsystem is loaded (as we do for most of the 16 bit functions we need) - or load by hand these two function with GetProcAddress, and handle the case where they are not defined. I'd vote for the first one.
ReleaseThunkLock and RestoreThunkLock need only be called in mmsystem.dll? How about this patch?
not exactly, they need to be called when 16 bit support has been added to winmm, not only when called from 16 bit (we also need it if called from 32 bit with 16 bit support loaded). this patch should take care of it. A+ -- Eric Pouech Name: mm16p2 ChangeLog: - move usage of 16 bit specific functions (MapSL) in 16 bit code only License: X11 GenDate: 2003/11/30 20:04:40 UTC ModifiedFiles: dlls/winmm/winemm.h dlls/winmm/mmsystem.c dlls/winmm/time.c =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/dlls/winmm/winemm.h,v retrieving revision 1.48 diff -u -u -r1.48 winemm.h --- dlls/winmm/winemm.h 9 Nov 2003 01:19:58 -0000 1.48 +++ dlls/winmm/winemm.h 30 Nov 2003 20:00:13 -0000 @@ -305,7 +305,7 @@ extern LRESULT (*pFnCallMMDrvFunc16)(DWORD /* in fact FARPROC16 */,WORD,WORD,LONG,LONG,LONG); extern unsigned (*pFnLoadMMDrvFunc16)(LPCSTR,LPWINE_DRIVER, LPWINE_MM_DRIVER); extern LRESULT (*pFnMmioCallback16)(DWORD,LPMMIOINFO,UINT,LPARAM,LPARAM); - +extern void (*pFnYield16)(void); /* GetDriverFlags() returned bits is not documented (nor the call itself) * Here are Wine only definitions of the bits */ Index: dlls/winmm/mmsystem.c =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/dlls/winmm/mmsystem.c,v retrieving revision 1.101 diff -u -u -r1.101 mmsystem.c --- dlls/winmm/mmsystem.c 9 Nov 2003 01:19:58 -0000 1.101 +++ dlls/winmm/mmsystem.c 30 Nov 2003 20:01:50 -0000 @@ -53,6 +53,12 @@ static LRESULT DRIVER_SendMessage16(HDRVR16, UINT, LPARAM, LPARAM); static LRESULT MMIO_Callback16(SEGPTR, LPMMIOINFO, UINT, LPARAM, LPARAM); +static void MMSYSTEM_Yield(void) +{ + DWORD count; + ReleaseThunkLock(&count); + RestoreThunkLock(count); +} /* ################################################### * # LIBRARY # @@ -87,6 +93,7 @@ pFnCloseDriver16 = DRIVER_CloseDriver16; pFnSendMessage16 = DRIVER_SendMessage16; pFnMmioCallback16 = MMIO_Callback16; + pFnYield16 = MMSYSTEM_Yield; MMDRV_Init16(); break; case DLL_PROCESS_DETACH: Index: dlls/winmm/time.c =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/dlls/winmm/time.c,v retrieving revision 1.22 diff -u -u -r1.22 time.c --- dlls/winmm/time.c 9 Nov 2003 01:19:58 -0000 1.22 +++ dlls/winmm/time.c 30 Nov 2003 20:04:12 -0000 @@ -348,6 +348,8 @@ return 0; } +void (*pFnYield16)(void) /* = NULL */; + /************************************************************************** * timeGetTime [MMSYSTEM.607] * timeGetTime [WINMM.@] @@ -357,9 +359,7 @@ /* FIXME: releasing the win16 lock here is a temporary hack (I hope) * that lets mciavi.drv run correctly */ - DWORD count; - ReleaseThunkLock(&count); - RestoreThunkLock(count); + if (pFnYield16) pFnYield16(); TIME_MMTimeStart(); return WINMM_IData->mmSysTimeMS; }
On Sun, 30 Nov 2003 21:48:47 +0800, you wrote:
table, and you get "ain't worth the hassle".
I hope you will reconsider.
This discussion did not answer the question that I was thinking of at your first remark: do these strings depend on the local language? It would be inclined to think the would depend only on the character encoding of the font and need no translation (what is the translation of AaBb?) Rein. -- Rein Klazes rklazes(a)xs4all.nl
Dmitry Timoshkov wrote:
"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote:
The main reason is that they are loaded based on encoding, rather than language. This has several implications that caused me not to go that route: 1. The mapping between encoding and charcter encoding is not a straightforward one. The reverse mapping is even less so.
Well, GetTextCharset() does exactly what you want.
I seem to have been totally misunderstood, possibly because of the wrong use of "locale" instead of "charset" in my previous mail. The situation is this: We have a font. This font supports several charsets. (Almost) each charset is used by several locales, but that is besides the point. We need to know which characters to use as a sample text demonstrating each charset. We need some kind of a table. This table does not depend on the current locale. You suggest resource. I say that this seems like the wrong tool for the job, as the resource information seems based on locale, and the locale does not play a role here. Maybe I misunderstood what you meant. Please explain: 1. What kind of a resource should I use, in your opinion? 2. How should I select which resource to load, given a specific locale? 3. What is the advantage of this mechanism?
These two mean that placing the sample text in a resource will only server to confuse the issue. The first point is even harder - what if you want different sample text for Chinese BIG-5 and the other Chinese encoding? Which language should I try to load for centeral Europe? French? German? I can only load one.
Exactly. GetTextCharset() is your friend here. Just have different strings for different charsets in the resources and load them at appropriate time.
You lost me there. How does GetTextCharset help me, in any way? I'll just remind you that thing I have given is the charset, and what I'm searching for is the text.
In short, doing that through resources seems like an unnecessary complication to me. Add to that the fact that you still need the mapping table, and you get "ain't worth the hassle".
I hope you will reconsider.
I'll be happy to. Just let's try and understand the implications. Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/ The opinions expressed in this mail are my own, and do not necessarily represent the opinions of my employer. Wait! I am self employed! Hmm...
Shachar Shemesh wrote: I can't believe it. I did it again.
Please explain: 1. What kind of a resource should I use, in your opinion? 2. How should I select which resource to load, given a specific locale?
Make that: "How should I select which resource to load, given a specific charset?"
3. What is the advantage of this mechanism?
Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/ The opinions expressed in this mail are my own, and do not necessarily represent the opinions of my employer. Wait! I am self employed! Hmm...
"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote:
Please explain: 1. What kind of a resource should I use, in your opinion?
String resources.
2. How should I select which resource to load, given a specific locale?
Font charsets doesn't depend on the current user locale. So, just create LANG_NEUTRAL resource with strings for each charset you want and IDs something like: #define CHARSET_BASE 1000 STRINGTABLE { ANSI_CHARSET+CHARSET_BASE "AaBbYyZz" DEFAULT_CHARSET+CHARSET_BASE "AaBbYyZz" SYMBOL_CHARSET+CHARSET_BASE "Symbol" ... } and load them when you need to display sample text: char sample[256]; hfont = CreateFontIndirectA(...) SelectObject(hdc, hfont); charset = GetTextCharset(hdc); LoadStringW(hinst_comdlg32, CHARSET_BASE + charset, sample, 256); DrawTextW(hdc, sample);
Make that: "How should I select which resource to load, given a specific charset?"
3. What is the advantage of this mechanism?
I mentioned at least one already: make it easily available for translators. You could always have a look at the traces produced by native comdlg32, since it uses an approach described above, and learn how it's done there. -- Dmitry.
Dmitry Timoshkov wrote:
"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote:
Please explain: 1. What kind of a resource should I use, in your opinion?
String resources.
2. How should I select which resource to load, given a specific locale?
Font charsets doesn't depend on the current user locale. So, just create LANG_NEUTRAL resource with strings for each charset you want and IDs something like:
#define CHARSET_BASE 1000
STRINGTABLE { ANSI_CHARSET+CHARSET_BASE "AaBbYyZz" DEFAULT_CHARSET+CHARSET_BASE "AaBbYyZz" SYMBOL_CHARSET+CHARSET_BASE "Symbol" ... }
How do I put Unicode there? I need to put in characters that, by definition, are taken from very varied parts of the unicode charset table. If that problem is *easilly* solveable, I'll glady do the change. Note, however, that this is no reason not to commit the patch I sent, as the scheme currently used has been in place since February. All the current patch did was enhance the sample text for more charsets. Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/ The opinions expressed in this mail are my own, and do not necessarily represent the opinions of my employer. Wait! I am self employed! Hmm...
"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote:
How do I put Unicode there? I need to put in characters that, by definition, are taken from very varied parts of the unicode charset table. If that problem is *easilly* solveable, I'll glady do the change.
Have a look at one of unicode only locale .nls files from dlls/kernel, for instance dlls/kernel/nls/guj.nls. That should be quite straightforward.
Note, however, that this is no reason not to commit the patch I sent, as the scheme currently used has been in place since February. All the current patch did was enhance the sample text for more charsets.
Sure. I agree. -- Dmitry.
participants (5)
-
Casper Hornstrup -
Dmitry Timoshkov -
Eric Pouech -
Rein Klazes -
Shachar Shemesh