David Lee Lambert wrote:
I don't agree. Mixing default codepages across simultaneously running
programs is not possible on Windows, and sounds horribly difficult to
implement. Clipboard handling and cross-file using are two examples of
things that are likely to go horribly wrong if we tried.
On Wed, Aug 04, 2004 at 11:20:57AM +0300, Shachar Shemesh wrote:
> David Lee Lambert wrote:
> >On Wed, Jul 28, 2004 at 10:13:15PM -0700, Alexandre Julliard wrote:
> >>"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes:
> >>I don't see how the settings would be different, surely LC_CTYPE is
> >>always g
David Lee Lambert wrote:
On Wed, Jul 28, 2004 at 10:13:15PM -0700, Alexandre Julliard wrote:
"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes:
I like the idea of moving that setting to the config file. We can't
use existing unix locale settings except LC_ALL and LANG because
every user's syste
On Wed, Jul 28, 2004 at 10:13:15PM -0700, Alexandre Julliard wrote:
> "Dmitry Timoshkov" <[EMAIL PROTECTED]> writes:
>
> > I like the idea of moving that setting to the config file. We can't
> > use existing unix locale settings except LC_ALL and LANG because
> > every user's system might have (an
"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes:
> "Alexandre Julliard" <[EMAIL PROTECTED]> wrote:
>
>> > FindResourceA
>> > FindResourceExA
>>
>> These ones have been well tested already.
>
> I don't see the tests for them in the CVS, especially part about LANGID
> preference order.
There's no au
"Alexandre Julliard" <[EMAIL PROTECTED]> wrote:
> > There is no need to test every API, but there are APIs we need to require
> > mandatory testing:
> >
> > GetSystemDefaultLCID
> > GetUserDefaultLCID
> > GetACP
>
> I don't see what you want to test here.
I want to test whether locale has really
"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes:
> There is no need to test every API, but there are APIs we need to require
> mandatory testing:
>
> GetSystemDefaultLCID
> GetUserDefaultLCID
> GetACP
I don't see what you want to test here.
> FindResourceA
> FindResourceExA
These ones have been w
"Alexandre Julliard" <[EMAIL PROTECTED]> wrote:
> The system locale defines the current codepages, so it affects
> MultiByteToWideChar and similar APIs. The user locale affects resource
> loading. It's likely that there are places in Wine that don't handle
> the distinction properly, but I don't t
--- Begin Message ---
Shachar Shemesh wrote:
[snip]
System locale affects all *A functions. I.e. - it affects all ANSI
functions. Aside from this affect:
Of course, I took it as fact that the Ansi code page is determined by
system locale and that means all *A functions are affected.
- String co
Filip Navara wrote:
Dmitry Timoshkov wrote:
We should not complicate things, especially since it's not clear at all
what APIs are affected by system/user locale differences.
System locale affects
System locale affects all *A functions. I.e. - it affects all ANSI
functions. Aside from this affect:
Shachar Shemesh <[EMAIL PROTECTED]> writes:
> Actually, that's a bug in Wine. User locale should not affect that. It
> should affect functions such as GetCurencyFormat, GetDateFormat
> etc. I'm now working on a fix to that problem.
That's not true, user locale definitely affects resource loading.
Dmitry Timoshkov wrote:
We should not complicate things, especially since it's not clear at all
what APIs are affected by system/user locale differences.
System locale affects
- String comparsions
(IntlStrEqWorker[AW], lstrcmp[AW], lstrcmpi[AW])
Uses system locale after trying thread locale (whic
Alexandre Julliard wrote:
The user locale affects resource
loading.
Actually, that's a bug in Wine. User locale should not affect that. It
should affect functions such as GetCurencyFormat, GetDateFormat etc. I'm
now working on a fix to that problem.
That, however, is unrelated to the system l
Dmitry Timoshkov wrote:
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:
Ignoring LC_CTYPE is as random as ignoring any other one. For the 100th
time, we are not ignoring LC_ALL and LANG. We are simply ALSO looking at
LC_CTYPE.
We were looking for LC_CTYPE before and it was removed from the l
"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes:
> I prefer not introduce potentially confusing things. I'm still
> waiting for the test cases and explanations what exactly APIs are
> affected by system/user locale in Windows and what users should
> expect when they have different system and user lo
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:
> Ignoring LC_CTYPE is as random as ignoring any other one. For the 100th
> time, we are not ignoring LC_ALL and LANG. We are simply ALSO looking at
> LC_CTYPE.
We were looking for LC_CTYPE before and it was removed from the list
of environment varia
Dmitry Timoshkov wrote:
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:
If the user's locale is broken, it's perfectly ok in my book for Wine to
be broken too. Picking a random environment variable and saying "We will
use this one and not that one" is utter nonsense. Just so things are
clear, pi
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:
> If the user's locale is broken, it's perfectly ok in my book for Wine to
> be broken too. Picking a random environment variable and saying "We will
> use this one and not that one" is utter nonsense. Just so things are
> clear, picking LC_ALL and L
Dmitry Timoshkov wrote:
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:
but they are saved as "?". In other words, Wine's behavior under the
case you mention exactly reflects the behavior Unix gives.
That's not a Wine problem, that's a problem of the broken user locale.
But that's exactly
"Alexandre Julliard" <[EMAIL PROTECTED]> wrote:
> I don't see how the settings would be different, surely LC_CTYPE is
> always going to control the ASCII->Unicode mapping on Unix, so why
> shouldn't it do that on Wine? If the issue is that users change their
> setup without understanding the resu
"David Lee Lambert" <[EMAIL PROTECTED]> wrote:
> I think it would be best to set the codepage for an app in the
> [AppDefaults] section. Codepages are deprecated in favor of full
> Unicode support, but specific apps might use ANSI APIs, and might even
> expect certain locales. For instance,
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:
> What happens on Unix with that setup? When I try setting LANG to he_IL
> and LC_CTYPE to en_US on unix, I can type Hebrew characters in kedit,
KDE does not use raw X11 protocol as Wine does. Run 'xev' and try
to enter hebrew characters with LC_CTYPE
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:
> > What happens on Unix with that setup? When I try setting LANG to he_IL
> > and LC_CTYPE to en_US on unix, I can type Hebrew characters in kedit,
> > but they are saved as "?". In other words, Wine's behavior under the
> > case you mention exactly
"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes:
> I like the idea of moving that setting to the config file. We can't
> use existing unix locale settings except LC_ALL and LANG because
> every user's system might have (and does have) very different locale
> settings, we can't assume that everyone o
Shachar Shemesh wrote:
What happens on Unix with that setup? When I try setting LANG to he_IL
and LC_CTYPE to en_US on unix, I can type Hebrew characters in kedit,
but they are saved as "?". In other words, Wine's behavior under the
case you mention exactly reflects the behavior Unix gives.
I t
Dmitry Timoshkov wrote:
"Alexandre Julliard" <[EMAIL PROTECTED]> wrote:
I'm afraid I still don't see what's wrong with the patch. Obviously
there can be different system and user locales on Windows, since there
are APIs for that, and LC_CTYPE looks like a pretty good match for
what the system lo
Dmitry Timoshkov wrote:
I still want your patch to be removed until you at least
write test cases showing what exactly APIs are affected
by system/user locale. Using LC_CTYPE for the system
default locale (current ANSI code page) is very dubious
choice as well. The whole purpose and the patch itsel
"Alexandre Julliard" <[EMAIL PROTECTED]> wrote:
> > We should not complicate things, especially since it's not clear at all
> > what APIs are affected by system/user locale differences.
>
> But the fact is that there are two different locales that can be
> configured independently on Windows, and
"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes:
> Yes, that's the reason why LC_CTYPE and LC_MESSAGES were removed from
> the list of environment variables controlling Wine locale.
I think the problem was more that we were setting both user and system
locales, and for that we can really only take
"Alexandre Julliard" <[EMAIL PROTECTED]> wrote:
> I'm still not clear on what you are objecting to. Changing the system
> locale is not going to affect keyboard input or resources. Keyboard
> input will be affected because we now set the Unix codepage from
> LC_CTYPE too, is that your main objecti
"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes:
> It breaks every user's setup where LANG and LC_CTYPE inadvertently point
> to different locales (like LC_CTYPE=en_US, LANG=ru_RU) and users in that
> case have completely not working Wine: neither keyboard input, not localized
> resources and everyt
"Alexandre Julliard" <[EMAIL PROTECTED]> wrote:
> I'm afraid I still don't see what's wrong with the patch. Obviously
> there can be different system and user locales on Windows, since there
> are APIs for that, and LC_CTYPE looks like a pretty good match for
> what the system locale does; I don't
Dmitry Timoshkov wrote:
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:
Just did:
GetUserDefaultLCID: 0409
GetSystemDefaultLCID: 040d
Ok, I have reproduced it now, my apologies for previous
misunderstanding. But still, it really changes nothing.
System default locale defines current ANSI c
"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes:
> I still want your patch to be removed until you at least
> write test cases showing what exactly APIs are affected
> by system/user locale. Using LC_CTYPE for the system
> default locale (current ANSI code page) is very dubious
> choice as well. The
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:
> >>Just did:
> >>GetUserDefaultLCID: 0409
> >>GetSystemDefaultLCID: 040d
Ok, I have reproduced it now, my apologies for previous
misunderstanding. But still, it really changes nothing.
System default locale defines current ANSI code page,
while user d
Dmitry Timoshkov wrote:
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:
You are trying to persuade yourself by taking into account only the look
of the Windows. Please write a test app how I did and see what data
GetSystemDefaultLCID and GetUserDefaultLCID return.
Just did:
GetUserDefaultLCI
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:
> >You are trying to persuade yourself by taking into account only the look
> >of the Windows. Please write a test app how I did and see what data
> >GetSystemDefaultLCID and GetUserDefaultLCID return.
> >
> >
> Just did:
> GetUserDefaultLCID: 0409
>
Dmitry Timoshkov wrote:
You are trying to persuade yourself by taking into account only the look
of the Windows. Please write a test app how I did and see what data
GetSystemDefaultLCID and GetUserDefaultLCID return.
Just did:
GetUserDefaultLCID: 0409
GetSystemDefaultLCID: 040d
Open the folder c
I think I found the source of our misunderstanding.
To me, this is the terminology (Windows 2000):
User locale (aka "User default locale"): the locale as appearing in the
"Regional options" as "Your locale (location)".
System locale: the locale as appearing in the "Regional options" as "Set
defau
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:
> Ok. Then please do the following experiment for me, will ya?
> 1. Hover the mouse over the clock. The date is displayed. Watch the date
> display language.
In the language of the system locale, russian for me.
> Now go to "Regional options", and ch
Dmitry Timoshkov wrote:
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:
In an attempt to get away from a possibly confusing subject line, and to
converge on an agreed behavior, here is an attempt to clear the desired
locale behavior Wine should have. Dmitry (and anyone else), please
comment on t
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:
> In an attempt to get away from a possibly confusing subject line, and to
> converge on an agreed behavior, here is an attempt to clear the desired
> locale behavior Wine should have. Dmitry (and anyone else), please
> comment on this table where yo
In an attempt to get away from a possibly confusing subject line, and
to converge on an agreed behavior, here is an attempt to clear the
desired locale behavior Wine should have. Dmitry (and anyone else),
please comment on this table where you think there are errors in it,
and say what should b
43 matches
Mail list logo
