kbswitch update

[Hans-Peter Diettrich]

Hi all,
I'm just digging into kbswitch and have several questions (later).

The major issue: kbswitch affects all windows at once, while it should 
change the input language only for the current (focused) window.

I assume that kbswitch must preserve the active window, so that it can 
know where to apply changes, and to re-activate that window when done. 
As I don't know what's already implemented, I wrote a simple test 
program, using
GetForegroundWindow() to determine the active window (hwnd),
GetWindowThreadProcessId() to get the related process handle, and
GetKeyboardLayout() to get the keyboard/language handle (hkl).

Tested on WinXP and ReactOS, the output looks correct. The hkl seems to 
be composed of two words (hi: language and low: layout), which are 
always the same on ReactOS. On XP a different keyboard layout can be 
used for a language, but I cannot decipher the resulting encoding of the 
layout. As soon as I try to change the layout for a language on ReactOS, 
kbswitch shows the *layout* name, not the *language* name.

Q: Can somebody try to find out how to convert a HKL into language and 
layout id's and/or names? (see GetLayoutIDByHkl)

Q: Is kbswitch notified of focus changes, and if so: how?
Then above sequence can be used to identify the related thread's 
setting, and update the tray icon and menu accordingly.

Q: Is every process/thread already assigned a *private* hkl?
If not, this feature must be implemented before further updates.

So much for now
DoDi

[Richard Campbell]

Hello!

Haven't been paying too much these days to ROS (wife, kids, job), but fyi i
know your email ended up in spam.  Gmail says this:

*Why is this message in Spam?* It has a from address in aol.com but has
failed aol.com's required tests for authentication.

On Fri, Dec 4, 2015 at 1:03 AM, Hans-Peter Diettrich [e-mail]
wrote:
> Hi all,
> I'm just digging into kbswitch and have several questions (later).
>
> The major issue: kbswitch affects all windows at once, while it should
> change the input language only for the current (focused) window.
>
> I assume that kbswitch must preserve the active window, so that it can
> know where to apply changes, and to re-activate that window when done. As I
> don't know what's already implemented, I wrote a simple test program, using
> GetForegroundWindow() to determine the active window (hwnd),
> GetWindowThreadProcessId() to get the related process handle, and
> GetKeyboardLayout() to get the keyboard/language handle (hkl).
>
> Tested on WinXP and ReactOS, the output looks correct. The hkl seems to be
> composed of two words (hi: language and low: layout), which are always the
> same on ReactOS. On XP a different keyboard layout can be used for a
> language, but I cannot decipher the resulting encoding of the layout. As
> soon as I try to change the layout for a language on ReactOS, kbswitch
> shows the *layout* name, not the *language* name.
>
> Q: Can somebody try to find out how to convert a HKL into language and
> layout id's and/or names? (see GetLayoutIDByHkl)
>
> Q: Is kbswitch notified of focus changes, and if so: how?
> Then above sequence can be used to identify the related thread's setting,
> and update the tray icon and menu accordingly.
>
> Q: Is every process/thread already assigned a *private* hkl?
> If not, this feature must be implemented before further updates.
>
> So much for now
> DoDi
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Hans-Peter Diettrich]

Richard Campbell schrieb:
> Hello!
>
> Haven't been paying too much these days to ROS (wife, kids, job), but 
> fyi i know your email ended up in spam.  Gmail says this:
>
> *Why is this message in Spam?* It has a from address in aol.com 
> http://aol.com but has failed aol.com http://aol.com's required 
> tests for authentication.

Thanks for the hint. When I don't get further answers, I'll have to 
switch to a gmx account.

DoDi

[Sylvain Petreolle]

I didn't get this message at all. Kind regards, Sylvain Petreolle
      De : Richard Campbell [e-mail]
 À : ReactOS Development List [e-mail] 
 Envoyé le : Vendredi 4 décembre 2015 8h57
 Objet : Re: [ros-dev] kbswitch update

Hello!
Haven't been paying too much these days to ROS (wife, kids, job), but fyi i know your email ended up in spam.  Gmail says this:
Why is this message in Spam? It has a from address in aol.com but has failed aol.com's required tests for authentication.

On Fri, Dec 4, 2015 at 1:03 AM, Hans-Peter Diettrich [e-mail] wrote:

Hi all,
I'm just digging into kbswitch and have several questions (later).

The major issue: kbswitch affects all windows at once, while it should change the input language only for the current (focused) window.

I assume that kbswitch must preserve the active window, so that it can know where to apply changes, and to re-activate that window when done. As I don't know what's already implemented, I wrote a simple test program, using
GetForegroundWindow() to determine the active window (hwnd),
GetWindowThreadProcessId() to get the related process handle, and
GetKeyboardLayout() to get the keyboard/language handle (hkl).

Tested on WinXP and ReactOS, the output looks correct. The hkl seems to be composed of two words (hi: language and low: layout), which are always the same on ReactOS. On XP a different keyboard layout can be used for a language, but I cannot decipher the resulting encoding of the layout. As soon as I try to change the layout for a language on ReactOS, kbswitch shows the *layout* name, not the *language* name.

Q: Can somebody try to find out how to convert a HKL into language and layout id's and/or names? (see GetLayoutIDByHkl)

Q: Is kbswitch notified of focus changes, and if so: how?
Then above sequence can be used to identify the related thread's setting, and update the tray icon and menu accordingly.

Q: Is every process/thread already assigned a *private* hkl?
If not, this feature must be implemented before further updates.

So much for now
DoDi

_______________________________________________
Ros-dev mailing list
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-dev

_______________________________________________
Ros-dev mailing list
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-dev

[Javier Agustìn Fernàndez Arroyo]

nor did i

but its better to be warned :)

On Sun, Dec 6, 2015 at 4:58 PM, Sylvain Petreolle [e-mail]
wrote:
> I didn't get this message at all.
>
> Kind regards, Sylvain Petreolle
>
> *De :* Richard Campbell [e-mail]
> *À :* ReactOS Development List [e-mail]
> *Envoyé le :* Vendredi 4 décembre 2015 8h57
> *Objet :* Re: [ros-dev] kbswitch update
>
> Hello!
>
> Haven't been paying too much these days to ROS (wife, kids, job), but fyi
> i know your email ended up in spam.  Gmail says this:
>
> *Why is this message in Spam?* It has a from address in aol.com but has
> failed aol.com's required tests for authentication.
>
> On Fri, Dec 4, 2015 at 1:03 AM, Hans-Peter Diettrich <[e-mail]
> > wrote:
>
> Hi all,
> I'm just digging into kbswitch and have several questions (later).
>
> The major issue: kbswitch affects all windows at once, while it should
> change the input language only for the current (focused) window.
>
> I assume that kbswitch must preserve the active window, so that it can
> know where to apply changes, and to re-activate that window when done. As I
> don't know what's already implemented, I wrote a simple test program, using
> GetForegroundWindow() to determine the active window (hwnd),
> GetWindowThreadProcessId() to get the related process handle, and
> GetKeyboardLayout() to get the keyboard/language handle (hkl).
>
> Tested on WinXP and ReactOS, the output looks correct. The hkl seems to be
> composed of two words (hi: language and low: layout), which are always the
> same on ReactOS. On XP a different keyboard layout can be used for a
> language, but I cannot decipher the resulting encoding of the layout. As
> soon as I try to change the layout for a language on ReactOS, kbswitch
> shows the *layout* name, not the *language* name.
>
> Q: Can somebody try to find out how to convert a HKL into language and
> layout id's and/or names? (see GetLayoutIDByHkl)
>
> Q: Is kbswitch notified of focus changes, and if so: how?
> Then above sequence can be used to identify the related thread's setting,
> and update the tray icon and menu accordingly.
>
> Q: Is every process/thread already assigned a *private* hkl?
> If not, this feature must be implemented before further updates.
>
> So much for now
> DoDi
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Colin Finck]

Hi,

Let me at least answer one of your questions before these get lost in
the discussion.

Am 03.12.2015 um 23:03 schrieb Hans-Peter Diettrich:
> Q: Is kbswitch notified of focus changes, and if so: how?

As you have already found out, kbswitch has been implemented as a
system-wide keyboard layout switcher and not a per-application one.
Therefore, it doesn't care about focus at all.

A proper per-application keyboard layout switcher as part of the
Language Bar should also be implemented as a shell extension instead of
a tray icon to be as flexible as the Windows original.
To get notified of focus changes, an application should probably hook
the EVENT_SYSTEM_FOREGROUND event using the SetWinEventHook API. The
rest can be done using calls to GetForegroundWindow,
GetWindowThreadProcessId and GetKeyboardLayout as you already suggested.

Unfortunately, I lack deeper experience with keyboard layout internals,
so this is all I can tell you for now.
You may find someone in #reactos or #reactos-dev on IRC with more
expertise on this.

Cheers,

Colin

[Hans-Peter Diettrich]

Colin Finck schrieb:
> Hi,
>
> Let me at least answer one of your questions before these get lost in
> the discussion.
>
> Am 03.12.2015 um 23:03 schrieb Hans-Peter Diettrich:
> > Q: Is kbswitch notified of focus changes, and if so: how?
>
> As you have already found out, kbswitch has been implemented as a
> system-wide keyboard layout switcher and not a per-application one.
> Therefore, it doesn't care about focus at all.

At a first glance I've been happy with that global switcher, but then 
found it unreliable and lacking a persistent (machine/user) specific 
default. Because I want to use a German keyboard in an otherwise English 
installation, the persistence of that choice is essential to me. But as 
this setting is subject to the control panel; and not yet implemented 
there; I started digging into kbswitch. Perhaps I should dig into the 
control panel dialog instead, but that's another topic.
> A proper per-application keyboard layout switcher as part of the
> Language Bar should also be implemented as a shell extension instead of
> a tray icon to be as flexible as the Windows original.
> To get notified of focus changes, an application should probably hook
> the EVENT_SYSTEM_FOREGROUND event using the SetWinEventHook API. The
> rest can be done using calls to GetForegroundWindow,
> GetWindowThreadProcessId and GetKeyboardLayout as you already suggested.
>
> Unfortunately, I lack deeper experience with keyboard layout internals,
> so this is all I can tell you for now.

Unfortunately I'm not familiar with Shell and COM and the Language Bar, 
just found out that the latter exists at all. I've learned about Windows 
internals for Win3.1, so that I can assist only in "lower level" 
functionality. In fact I have no real use for the bloated Windows 
versions past XP, I prefer using the older versions in virtual machines 
on my desktop or laptop instead.
> You may find someone in #reactos or #reactos-dev on IRC with more
> expertise on this.

For a first glance on the control panel settings I'd need a 
link/filename of the language related dialogs. Otherwise I only can jump 
in where somebody else implemented a related framework, hunting bugs or 
implementing extensions.

Thanks for the new keywords :-)
DoDi

[Hermès BÉLUSCA - MAÏTO]

Hi, my question is inline the previous mail.

-----Message d'origine-----
De : Ros-dev [mailto:[e-mail]] De la part de Colin Finck
Envoyé : lundi 7 décembre 2015 04:48
À : [e-mail]
Objet : Re: [ros-dev] kbswitch update
> A proper per-application keyboard layout switcher as part of the Language

Bar should also be implemented as a shell extension instead of a tray icon
to be as flexible as the Windows original.
> To get notified of focus changes, an application should probably hook the

EVENT_SYSTEM_FOREGROUND event using the SetWinEventHook API. The rest can be
done using calls to GetForegroundWindow, GetWindowThreadProcessId and
GetKeyboardLayout as you already suggested.

Shell extension?! Are you completely sure? On windows 2000 and 2003 this is
usually done by an external application, called internat.exe on windows
2000, and ctfmon.exe on windows 2003.
- on windows 2000, internat.exe uses imm32.dll and shell32.dll (the latter
is used to create the language icon in the traybar);
- on windows 2003, ctfmon.exe loads msctf.dll and msutb.dll, having the
effect of creating the toolbar (when it is in floating mode, if you kill
ctfmon.exe you'll see it disappear; however, if it is anchored in the
explorer taskbar, then it'll remain alive until you kill and restart
explorer.exe . Note to myself: it appears explorer.exe loads on demand those
dlls also so that the language bar can be redisplayed if you force-click on
the "Language bar" menu item in the taskbar property menu). On Windows
Vista+, I don't know how it works (but we don't copy vista+ up to now). They
have a language service stuff...

In any case, our current architecture regarding the language bar/icon is
more similar to the one of windows 2000 (but our language app is called
kbswitch.exe instead of internat.exe). But on windows 2000 (contrary to
reactos, and similarly to win2k3), if you select e.g. a german keyboard for
taskmgr while your default keyboard was English, then when you focus on
taskmgr you get the german keyboard and when you focus elsewhere (or open a
new app), you get English (or the other language for that other app), i.e.
as Hans-Peter wants. That's IME stuff, it looks working together with GUI
threads; this needs also some cooperation with user32.dll / win32k.sys;
however the IMM/IME code in win32k is partly broken.

Cheers,
Hermès.