Bug 3807 - hr_US seems to have been lost
Summary: hr_US seems to have been lost
Status: RESOLVED FIXED
Alias: None
Product: xkeyboard-config
Classification: Unclassified
Component: General (show other bugs)
Version: unspecified
Hardware: x86 (IA32) All
: high normal
Assignee: xkb
QA Contact:
URL: http://bugzilla.ubuntu.com/show_bug.c...
Whiteboard:
Keywords:
: 6335 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-07-18 19:39 UTC by Daniel Stone
Modified: 2006-03-24 05:10 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
hr (4.01 KB, application/octet-stream)
2005-09-13 13:37 UTC, Ante Karamatic
Details
new-hr (2.20 KB, text/plain)
2005-09-14 06:41 UTC, Ante Karamatic
Details
hr (2.13 KB, text/plain)
2005-09-14 08:29 UTC, Ante Karamatic
Details

Description Daniel Stone 2005-07-18 19:39:55 UTC
At https://bugzilla.ubuntu.com/show_bug.cgi?id=8264, a Croatian user has
reported that the keymap at the above URL has to be installed for keyboards to
expect like Croatian users expect them to.  I assume this is the case, but
that's just a guess because I don't live in Croatia ... but that's the one up at
linux.hr, in any case.
Comment 1 Sergey V. Udaltsov 2005-07-19 05:28:47 UTC
It seems the hr(us) keyboard is already in xkeyboard-config CVS. So I am closing
this one. Feel free to open if I am wrong.
Comment 2 Daniel Stone 2005-09-06 19:32:24 UTC
Hi Sergey,
I'm reopening; hr_US seems to have disappeared.  Is there any chance of getting
an hr(us-old) or such added, since the two seem to be rather different?  Cheers.
Comment 3 Ante Karamatic 2005-09-13 13:37:23 UTC
Created attachment 3257 [details]
hr

This is hr symbols with hr(alt) layout. This layout provieds us layout +
croatian letters (šđžčć and ŠĐŽČĆ) as a
combination of AltGr and []\;'.

Before this was hr_US layout. I suggest hr(alt) now, since there is one hr(us).
Comment 4 Sergey V. Udaltsov 2005-09-13 13:59:51 UTC
Ante, I am highly reluctant to include this layout. It contains two groups.
Could you please use shift levels instead - 3rd and 4th?
Comment 5 Ante Karamatic 2005-09-13 22:57:45 UTC
I understand you, but using shift only isn't an option. Symbols []\;' are
needed, but {}|:" are needed too. Other than that, we need to get 10 chars from
5 keys. This is layout for programers. Lossing []\;'{}|:" would make this layout
unusable.  AltGr+Shift isn't the best option, but I can't think of any other...
Comment 6 Danilo Segan 2005-09-14 05:10:26 UTC
Ante: AltGr can be set as third-level Shift, and that's what is commonly done
these days. Using levels is much better anyway, since we can have up to 64 shift
levels in each layout, and only 4 groups loaded at the same time.

Basically, a key definition would now be:
  key.type[Group1] = "FOUR_LEVEL";
  key <AD11> {   [ bracketleft,	braceleft, scaron, Scaron ]   };

And you'd also do

  include "level3(ralt_switch)"

to make right Alt a third level shift (to get you scaron and Alt+Shift for
Scaron: of course, you can put them on regular shift levels instead).  Also note
that new basic "hr" layout also includes all the programming symbols, just on a
bit "unusual" positions (unusual in the sense that that's where Windows puts
them on third/fourth level).
Comment 7 Ante Karamatic 2005-09-14 06:41:21 UTC
Created attachment 3263 [details]
new-hr

Oh... Sorry :)
Like this?
Comment 8 Danilo Segan 2005-09-14 07:04:26 UTC
Exactly :)  You also don't need <RALT> definition, since that's what
level3(ralt_switch) should give you, even though it is currently lacking
Multi_key in there.  I'll discuss this with Sergey independently of this bug,
since we many other layouts may need it, and there is currently no way to
combine both ISO_Level3_Shift and Multi_key without specifying them manually.

And there is one more caveat you may want to use (not really necessary, but I'd
say it will ease maintenance):

    key <AD01> { [	any,	any,	backslash	        ] };

means that first two keys are not redefined from what is currently there (i.e.
what 'include "us"' gives, and that's [q, Q]).  And you can also get proper
keypad symbols using

  include "keypad(comma)"

Also note that if you wish Lock (or "Caps Lock") key to work for eg. scaron,
Scaron on higher levels, you need to set key type to FOUR_LEVEL_ALPHABETIC (uhm,
Sergey, we may need another type for this one, since _SEMIALPHABETIC is
alphabetic only for the lower 2 levels, _ALPHABETIC is alphabetic for all
levels, and we need it now to be alphabetic only on higher 2 levels).

Also, please post any other comments you have on hr layouts as well. Thanks.
Comment 9 Ante Karamatic 2005-09-14 08:29:45 UTC
Created attachment 3265 [details]
hr

OK. This is final. Numeric is ok, so no need for inclusion.

Thanks for all the help!
Comment 10 Sergey V. Udaltsov 2005-12-30 13:05:29 UTC
Ante, just one quesion - is it a keyboard used by Croatians living in US - or
Croatians living in Croatia. I am asking because of the name. In one case, it
would be more appropriate as us(hr), in the other - as hr(us). Once I get clear
understanding of this - I'll commit the code.

Thanks.
Comment 11 Ante Karamatic 2005-12-30 17:13:59 UTC
It's used by all sane people :) Problem with official HR layout is that it's
crapy to use on UNIX. Too many Shifts and AltGrs for \ and /. Most of the people
that use UNIX/Linux in Croatia use us (some use gb) layout and then change to HR
for some chars. Cause of that HULK (Croatian Linux User Group) created hr_US
keymap for XFree. That keymap was commited and was part of XFree.

This keymap is the same as old hr_US used in XFree. So, you could say it's used
by Croats in Croatia. But, I'm sure lot's of Croats outside Croatia use it too.
Technicly, it's us(hr) cause it's US keymap + HR chars.
Comment 12 Sergey V. Udaltsov 2005-12-31 10:42:15 UTC
> This keymap is the same as old hr_US used in XFree. So, you could say it's used
> by Croats in Croatia. But, I'm sure lot's of Croats outside Croatia use it too.
> Technicly, it's us(hr) cause it's US keymap + HR chars.
OK, I see. Another question. There is already hr(us) layout which is essentially
same as cs(latynyz). So, should we replace existing one with your version - or
add new variant (us_old or smth). Sure, I'd prefer to keep one variant instead
of two (whichever is the right one).
http://cvs.freedesktop.org/xlibs/xkbdesc/symbols/hr?rev=1.11&view=markup
Comment 13 Ante Karamatic 2005-12-31 18:01:31 UTC
If that's ok with you, I would like to ask community what they think about that
and get back to you in few days...
Comment 14 Sergey V. Udaltsov 2006-01-01 00:14:31 UTC
Sure Ante, take your time..
Comment 15 Ante Karamatic 2006-02-15 02:22:31 UTC
Hi! So, it's ok to replace regular hr_us with this mapping. (sorry for late
response)
Comment 16 Sergey V. Udaltsov 2006-02-22 09:03:05 UTC
> Hi! So, it's ok to replace regular hr_us with this mapping. (sorry for late
> response)
No problem. I presume, you mean hr(us)?
Comment 17 Sergey V. Udaltsov 2006-02-22 09:12:32 UTC
committed as hr(us)
Comment 18 Ante Karamatic 2006-03-21 08:36:43 UTC
Hi!

CVS logs states: added hu(us), fixed b.fd.o#3807

It's hr(us), not hu(us).

Other thing is that new "hr" is missing "include "us"".

Instead of
[cut]
partial alphanumeric_keys 
xkb_symbols "us" {

    name[Group1]= "Croatia - US keyboard with Croatian letters";

    key <AD01> { [    any,    any,	backslash	        ] };
[cut]

it should be:
[cut]
partial alphanumeric_keys 
xkb_symbols "us" {

    name[Group1]= "Croatia - US keyboard with Croatian letters";

    include "us"

    key <AD01> { [    any,    any,	backslash	        ] };
[cut]
Comment 19 Sergey V. Udaltsov 2006-03-21 08:46:22 UTC
Thanks. fixed in ChangeLog and symbols/hr
Comment 20 Tollef Fog Heen 2006-03-25 00:10:36 UTC
*** Bug 6335 has been marked as a duplicate of this bug. ***


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.