--===============1301941153==
Content-Type: multipart/signed;
  boundary="nextPart1259008.vTvSfTPYGv";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1259008.vTvSfTPYGv
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

> [: Andriy Rysin :]
> well I was thinking about some sort of engine of this kind, the question
> is time and effort:=20
> currently I have prently todos for kxkb even for 4 layouts/groups, so I
> am just trying to plan ahead and not to overdesign the switcher.

It seems to me that the multi-rotation feature is "orthogonal" to basic=20
layout switching, so that you can just proceed with keeping it in the back=
=20
of the mind. Not to do something in the code that would prevent it as a=20
possibility...

Though, a sanity check: am I correct that, on the technical level (ie. not=
=20
thinking about the GUI to support it), it would indeed not be difficult?=20
In the sense that, if to set basic layout switching you need some=20
equivalent of setxkbmap -layout "..." -variant "..." etc., then supporting=
=20
several rotations would mean only making these group-setup calls on=20
rotation switch?

> [...] I think in this case assigning a shortcut to layout would help,
> e.g. Ctrl+Alt+F8 to RU e.g. Ctrl+Alt+F9

While it may be improvement from rotating, I'm not sure it's that good.=20
Prior to turning, I was trying to use these for some half a year in=20
Windows, and it was a pain and till the end I couldn't save myself from=20
frequent mishits.

=46or me it is much more relaxing with 2 layouts in the rotation, so that I=
=20
don't have to think at all, it's always the same combo to go back and=20
forth. And a shorter one at that, Ctrl+Alt+Fn is (I'd say) disastrous for=20
quick switching.

It is a pity that there are little usability guidelines regarding this. You=
=20
certainly recall that thread on kde-core-devel, where there was a big fuss=
=20
about switching shortcuts, and people more involved in usability claimed=20
that three key mod+mod+letter is a "consistent" way to go, that=20
modifier-only shortcuts are "evil", etc. (there I found about this=20
Alt+Space as a compromise). While I certainly wouldn't second guess their=20
opinion in general, I think it's not valid in the very special case of=20
layout switching for non-Latin users. I guess that most usability studies=20
are done by native-Latin researchers with native-Latin users, so that this=
=20
issue rarely pops up.

> Also sticky switching may be tricky to do properly with groups so it
> may be changed or just go away - this depends on implementation
> complexity, as far as I know some people use sticky switching but most
> of them are not too excited about it.

I agree. It is somewhat helpful, but I could also live with only 2 layouts=
=20
in the rotation (I mostly use US/Serbian Cyrillic, and Serbian Latin=20
rarely). Especially if it is reasonable to hope for multi-rotation=20
feature :)

=2D-=20
Chusslove Illich (=D0=A7=D0=B0=D1=81=D0=BB=D0=B0=D0=B2 =D0=98=D0=BB=D0=B8=
=D1=9B)

--nextPart1259008.vTvSfTPYGv
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBF5WhDMSGXgigGr3ERAvneAKCOcmOQmr408JERgxtiJv1zz0PAJgCfTdtw
YNK7lPUlMhVz2coaokGwCiw=
=ozLb
-----END PGP SIGNATURE-----

--nextPart1259008.vTvSfTPYGv--

--===============1301941153==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

--===============1301941153==--