Created attachment 6926 [details] [review]
Patch to test

Hi,

Here is my opinion, FWIW.  I do not like your patch
(without even testing it, will do later ;)) for
several reasons:
  * There is nothing specific to the French layout, so
    if Unicode mathematical symbols have to be added,
    they must be available for all layouts.  You put
    them into a seperate file, this is fine, but instead
    of adding new fr variants, you should add options
    into rules/base in the
      ! options = symbols
    section, something like
      keypad:unimath = +keypad(unimath)
      keypad:unimathrev = +keypad(unimathrev)
  * Why do you need keypad(comma2) and keypad(comma3)?
  * Why do you set key types to FOUR_LEVEL_ALPHABETIC instead
    of KEYPAD?
  * X resolution can no more be changed.

(In reply to comment #2)
> Hi,
> 
> Here is my opinion, FWIW.  I do not like your patch
> (without even testing it, will do later ;))

Testing is pretty much required to have a relevant opinion. I've actually
changed the patch before after testing.

> for several reasons:
>   * There is nothing specific to the French layout, so
>     if Unicode mathematical symbols have to be added,
>     they must be available for all layouts.

The defs are modularised so if another map needs them it can reference them.

It's not just a matter of changing the keypad def. Some of the symbols I added
to the keypad are available in the main area of fr-latin9 for example. So adding
them to the keypad opens up the possibility of liberating slots in the main area
and adding other characters people currently miss in fr-latin9 (I've had some
complaints about arrows)

I do need some input from laptop users if moving cartesian operators to the
keypad and replacing them with arrows is acceptable.

This change is in the agressive variant, I'm leaning towards putting it in
fr-latin9 proper now though.

>  You put them into a seperate file, this is fine, but instead
>     of adding new fr variants, you should add options
>     into rules/base in the
>       ! options = symbols
>     section, something like
>       keypad:unimath = +keypad(unimath)
>       keypad:unimathrev = +keypad(unimathrev)

I can add this too (is this actually working syntax ?). This should not stop
latin9 from using unimath or unimathrev by default though.

(also latin9 is actually a misleading name as a few characters are not in latin9
even today. Would it be possible or wise to rename the map, providing a legacy
alias ?)

>   * Why do you need keypad(comma2) and keypad(comma3)?

This is a comma-country problem. On one hand, in comma countries you do need
comma to write correct numbers. On the other hand, you still need the dot for
US-oriented apps and shell manipulation.

This is such a mess that in France for example macs have a comma keypad and PCs
a dot keypad.

The current "keypad(comma)" replaces dot by comma
"keypad(comma2)" replaces dot by comma if alt-gr is active
"keypad(comma3)" replaces dot by comma but lets users access dot via alt-gr

I think there are several maps in the database which use comma2 or comma3 like
constructs, they should probably reference one or the other instead.

(also, I'm not sure if it wouldn't be more useful to reference comma and dot
directly instead of the KP_foo defs which may be modified by locales)

>   * Why do you set key types to FOUR_LEVEL_ALPHABETIC instead
>     of KEYPAD?

I started by using FOUR_LEVEL_KEYPAD but it proved completely unintuitive. These
keys are not modified by num_lock right now, and after a few hours of testing I
found out it was much more natural to keep this behaviour and only let altgr and
shift change them

>   * X resolution can no more be changed.

I don't follow you there

>>   * There is nothing specific to the French layout, so
>>     if Unicode mathematical symbols have to be added,
>>     they must be available for all layouts.
> 
> The defs are modularised so if another map needs them it can
> reference them.

You are missing the point, we want layouts to be modular.  If we
modify fr(latin9), some users will complain that they prefer the
original layout.  We could of course provide fr(oldlatin9) for
compatibility, but we will end up with hundreds of variants to the
end.  Instead we want to minimize the total number of layouts, and
to provide options whenever possible so that users can customize
their layouts.  For instance, a keypad:unimath option could load
keypad(unimath), as told in the previous past.
If a layout includes it by default, there must be an option to
provide the original keypad behavior.

> It's not just a matter of changing the keypad def. Some of the
> symbols I added to the keypad are available in the main area of
> fr-latin9 for example.  So adding them to the keypad opens up the
> possibility of liberating slots in the main area and adding other
> characters people currently miss in fr-latin9 (I've had some
> complaints about arrows)

If you want to replace current symbols by arrows, it seems much more
logical to put them on the keypad, where such arrows are engraved.

[...]
>>   * Why do you set key types to FOUR_LEVEL_ALPHABETIC instead
>>     of KEYPAD?
> 
> I started by using FOUR_LEVEL_KEYPAD but it proved completely
> unintuitive.  These keys are not modified by num_lock right now,

They are.

> and after a few hours of testing I found out it was much more
> natural to keep this behaviour and only let altgr and shift
> change them

Digits and mathematical signs have then different modifiers,
this is not intuitive at all.

>>   * X resolution can no more be changed.
> 
> I don't follow you there

<Ctrl><Alt><+> and <Ctrl><Alt><-> allow switching between different
X modes, your settings break this well established convention.

(In reply to comment #4)
> Instead we want to minimize the total number of layouts, and
> to provide options whenever possible so that users can customize
> their layouts. 

If you want to minimize the number of layouts, that means you have to
aggressively prune "bad" layouts and only keep the best ones.

In our particular case that would make reverting to the old behaviour the
option, not moving to the new one (if we manage to make the new behaviour better)

> If a layout includes it by default, there must be an option to
> provide the original keypad behavior.

Sure, but where is the original keypad defined exactly ? I don't think it's
nicely modularised like mine

> > It's not just a matter of changing the keypad def. Some of the
> > symbols I added to the keypad are available in the main area of
> > fr-latin9 for example.  So adding them to the keypad opens up the
> > possibility of liberating slots in the main area and adding other
> > characters people currently miss in fr-latin9 (I've had some
> > complaints about arrows)
> 
> If you want to replace current symbols by arrows, it seems much more
> logical to put them on the keypad, where such arrows are engraved.
> 
> [...]

What's logical and what your fingers expect are two different things
Users do expect numbers when num lock is on, and a keypad otherwise.

The following behaviour might work :
− numbers if num lock is on
− keypad if off
− arrow symbols if altgr

but I don't think there is any predefine key type which works like this

> >>   * Why do you set key types to FOUR_LEVEL_ALPHABETIC instead
> >>     of KEYPAD?
> > 
> > I started by using FOUR_LEVEL_KEYPAD but it proved completely
> > unintuitive.  These keys are not modified by num_lock right now,
> 
> They are.

If /*- are modified by num lock now it's well hidden

> > and after a few hours of testing I found out it was much more
> > natural to keep this behaviour and only let altgr and shift
> > change them
> 
> Digits and mathematical signs have then different modifiers,
> this is not intuitive at all.

Just try it. I expected like you keeping num lock the only keypad modifier more
intuitive, but after actually using the thing it's not. It seems my brain
expects math operators to be gouped with other typographical characters (altgr)
and the digit∕keypad modifier to be orthogonal,

> >>   * X resolution can no more be changed.
> > 
> > I don't follow you there
> 
> <Ctrl><Alt><+> and <Ctrl><Alt><-> allow switching between different
> X modes, your settings break this well established convention.

Only need to define <Ctrl><Alt><−>, not a problem (but I had forgotten it)
As for altgr not being the same as left alt, that's a fact of life on european
keyboards

Will cook a new patch based on reactions so far

>> If a layout includes it by default, there must be an option to
>> provide the original keypad behavior.
> 
> Sure, but where is the original keypad defined exactly ? I don't think it's
> nicely modularised like mine

Right, this was a general remark.  The default keypad has to be modularized
too, I was planning to propose a patch when Mac layouts are in a good
shape, because Mac layouts could reuse the same keypad definitions.
No need to provide a patch for that.

[...]
> The following behaviour might work :
> − numbers if num lock is on
> − keypad if off
> − arrow symbols if altgr
> 
> but I don't think there is any predefine key type which works like this

This is what I had in mind, and can be achieved with FOUR_LEVEL_KEYPAD ;)

>>>>   * Why do you set key types to FOUR_LEVEL_ALPHABETIC instead
>>>>     of KEYPAD?
>>>
>>> I started by using FOUR_LEVEL_KEYPAD but it proved completely
>>> unintuitive.  These keys are not modified by num_lock right now,
>>
>> They are.
> 
> If /*- are modified by num lock now it's well hidden

Ok, I misunderstood your initial reply, sorry.

[...]
> Will cook a new patch based on reactions so far

BTW please only patch symbols/fr and symbols/keypad, other files can
be easily modified later on.

Created attachment 6952 [details] [review]
Reworked patch based on current round of feedback

1. Does not touch fr-latin9 anymore to help live comparison
2. Stuffs all the changes in fr-unicode (may be the future fr-latin9 or not)
3. Makes more complete keypad enhancements (operators + arrows)
4. Adds most requested fixes and characters to the main area

Created attachment 6953 [details]
View of current fr-latin9 map / Visuel de la carte fr-latin9 actuelle

Disposition actuelle de fr(latin9)

Created attachment 6954 [details]
Proposed changes / Modifications proposées

Nouvelle disposition en proposition

(In reply to comment #6)

> > Sure, but where is the original keypad defined exactly ? I don't think it's
> > nicely modularised like mine
> 
> Right, this was a general remark.  The default keypad has to be modularized
> too, 

A nice four-level definition like I did for uniarrow would be much nicer on
everyone ;)

> > The following behaviour might work :
> > − numbers if num lock is on
> > − keypad if off
> > − arrow symbols if altgr
> > 
> > but I don't think there is any predefine key type which works like this
> 
> This is what I had in mind, and can be achieved with FOUR_LEVEL_KEYPAD ;)

Nah, I had to add SIMPLE_FOUR_LEVEL_KEYPAD, as FOUR_LEVEL_KEYPAD is simply too
convoluted for a normal user (three modifiers with two acting in parallel but
not unsetting each other ? How confusing can you be ?)

> BTW please only patch symbols/fr and symbols/keypad, other files can
> be easily modified later on.

We can drop the other parts later, I need them to test the changes and so do
other testers

BTW, lots of discussion and input there :

https://linuxfr.org/2006/09/13/21322.html

Created attachment 6956 [details] [review]
Reworked patch based on current round of feedback / Patch à tester

Move Ubreve to tilde and group “” with «»

Created attachment 6957 [details]
Visual of proposed changes / Visuel des modifications proposées

(In reply to comment #13)
> Created an attachment (id=6957) [edit]
> Visual of proposed changes / Visuel des modifications proposées
> 

Salut,

Mon vocable typo est suffisament faible pour ne pas écrire en anglais, désolé.
Bravo pour ton initiative, depuis le passage de René Cougnenc, il y a de quoi faire.
Sauf erreur de ma part, je ne vois pas l'espace court, celui sensé précéder » et
suivre « par exemple, contrairement à nobreakspace qui est bien là.

Ensuite, si j'ai bien compris une possibilité de KDE, on peut choisir une
disposition de clavier par un simple clic sur un petit drapeau dans la taskbar.
 Le changement est alors global ou au choix propre à la fenêtre.  Je ne sais pas
pour GNOME ou autre WM, mais ce petit outil permet apparemment efficacement
d'affecter un layout "développement" à certaines fenêtres (pour les
conservateurs ;-)) et un layout plus litéraire à d'autres.  Deux layout plus ou
moins agressifs ont lieu d'être sans sourcilier AMHA.

Bon courage.
Sun Wukong

(In reply to comment #10)
>> BTW please only patch symbols/fr and symbols/keypad, other files can
>> be easily modified later on.
>
> We can drop the other parts later, I need them to test the changes and
> so do other testers

No, nobody needs them, these changes are useless.  You can run
  setxkbmap -model pc105 -layout fr -variant unicode -print |\
    xkbcomp -w0 - :0
from top-level directory, or if you installed modified files
into their final location, simply type
  setxkbmap -model pc105 -layout fr -variant unicode

More precisely, keymap/xfree86 is obsolete and does not even work
for a long time, and rules/compat/ is about compatibility for
previously existing layouts, variants and options, new definitions
are not added into these files.

About your new patch:
 * Sergey did not yet gave his opinion, but I am afraid that only
   one version of latin9/unicode will be accepted, so you need to
   choose one.  My understanding is that you provide both now so
   that people can compare them, but I wanted to make it clear.
 * keypad(unimath) prevents switching between X modes with
   <Ctrl><Alt><KPAD> and <Ctrl><Alt><KPSU>, this is a no-go for me.
 * There is IMO no need to add a SIMPLE_FOUR_LEVEL_KEYPAD type;
   if FOUR_LEVEL_KEYPAD is braindead it can be changed.  (But I
   see no need for it)
 * U2019 is rightsinglequotemark

(In reply to comment #15)
> (In reply to comment #10)
> >> BTW please only patch symbols/fr and symbols/keypad, other files can
> >> be easily modified later on.
> >
> > We can drop the other parts later, I need them to test the changes and
> > so do other testers
> 
> No, nobody needs them, these changes are useless.  You can run
>   setxkbmap -model pc105 -layout fr -variant unicode -print |\
>     xkbcomp -w0 - :0
> from top-level directory, or if you installed modified files
> into their final location, simply type
>   setxkbmap -model pc105 -layout fr -variant unicode
> 
> More precisely, keymap/xfree86 is obsolete and does not even work
> for a long time, and rules/compat/ is about compatibility for
> previously existing layouts, variants and options, new definitions
> are not added into these files.

To be honest, I just declared the new layout next to the old one everywhere,
I'll kill the keymap/xfree86 and rules/compat/ changes if the gnome keyboard
changing applet can work without them.

> About your new patch:
>  * Sergey did not yet gave his opinion, but I am afraid that only
>    one version of latin9/unicode will be accepted, so you need to
>    choose one.  My understanding is that you provide both now so
>    that people can compare them, but I wanted to make it clear.

Right now I provide both for comparison. If they do not diverge too much or the
changes/fixes are positively received by most reviewers, I'll keep only the new
one (renaming it to unicode as latin-9 won't be correct anymore, and providing
the legacy alias).

Otherwise there is a definite split risk.

>  * keypad(unimath) prevents switching between X modes with
>    <Ctrl><Alt><KPAD> and <Ctrl><Alt><KPSU>, this is a no-go for me.

Is it possible to declare these easily without adding a fifth ctrl+alt level ?
(for two keys ?!!!)

>  * There is IMO no need to add a SIMPLE_FOUR_LEVEL_KEYPAD type;
>    if FOUR_LEVEL_KEYPAD is braindead it can be changed.  (But I
>    see no need for it)

I'll tweak my keypad behaviour till it's the best one for french users, then if
you can track  FOUR_LEVEL_KEYPAD users we can propose to merge them, but I won't
use FOUR_LEVEL_KEYPAD just because it exists if my class of users feel it's
braindead.

>  * U2019 is rightsinglequotemark

Interesting, thanks

Created attachment 6980 [details] [review]
Patch to test / Patch à tester

1. Rework keypad behaviour / retravaille le comportement du pavé numérique
2. Fix mode-switch / Corrige le changement de mode
3. Regroup accented letters with their caps / regroupe les lettres accentuées
avec leurs majuscules
4. Add requested typographical glyphs / Ajoute les symboles typographiques
demandés
5. Remove arrows from main area / Retire les flèches de la zone principale

Created attachment 6981 [details]
Visual of proposed changes / Visuel des modifications proposées

On french keyboard, there is conflict with x modifier key.

Idefinied this :
xmodmap ~/.Xmodmap
and in .Xmodmap :
keycode 0x73 = Multi_key

compose + ' + e =>  é
compose + ` + e => `e instead of è
That's like a problem of interaction between compose and `

The usage of the ` + vowel is indispensable to type chinese pinyin (latin
translitération of chinese).

See this chapter of french wikipedia to understand :
http://fr.wikipedia.org/wiki/H%C3%A0ny%C7%94_p%C4%ABny%C4%ABn#Saisie_d.27.C3.A9criture_pinyin

I use :
   Driver  "kbd"
   Option  "XkbModel"   "pc105"
   Option  "XkbLayout"  "fr"

on x.org

(In reply to comment #19)
> On french keyboard, there is conflict with x modifier key.

> compose + ' + e =>  é
> compose + ` + e => `e instead of è

The proposed patches do not touch the è/7/` key. They do touch '/4/{, but you
say this key still work.

Created attachment 6987 [details] [review]
Patch to test / Patch à tester

Fix readme

FOUR_LEVEL_KEYPAD could be modified like this:
1. If you don`t press shift nor AltGr (right alt), the behaviour is the same as   
the standard keypad with Server Control
2. Pressing shift and/or AltGr ignores NumLock and yields extra symbols.
(I`m not smart enough to program these patches, so I`m just writing what should 
be in '/usr/share/X11/xkb/types/extra' file)

1. Si l`on ne touche ni shift ni AltGr (Alt droite), le clavier agit comme s`il 
était ordinaire (Server Contol inclus)
2. Si l`on touche shift où AltGr, des symboles supplémentaires seront genérés 
avec n`importe quel état de NumLock. (voici le contenu desiré du 
fichier '/usr/share/X11/xkb/types/extra')

partial default xkb_types "default" {
    type "SIX_LEVEL_KEYPAD" {
	modifiers = Shift+NumLock+LevelThree+Control+Alt;
	map[None] = Level1;
	map[Shift] = Level3;
	map[NumLock] = Level2;
	map[Shift+NumLock] = Level3;
	map[LevelThree] = Level4;
	map[Shift+LevelThree] = Level5;
	map[NumLock+LevelThree] = Level4;
	map[Shift+NumLock+LevelThree] = Level5;
	map[Control+Alt] = Level6;
        level_name[Level1] = "Base";
	level_name[Level2] = "Number";
	level_name[Level3] = "Shift";
	level_name[Level4] = "AltGr ";
	level_name[Level5] = "Shift AltGr";
        level_name[Level6] = "Ctrl+Alt";
    };
};

---------------

should it be possible to press shift+KP_Left for some programs to mark a region 
of text? If so, I could change the level assignment such that the keypad 
ignores any modifier (except for Ctrl+Alt) when NumLock is off.
'../symbols/pc' could look like this:

Est-ce qu`on a besoin de la possibilité de toucher shift+KP_Left afin de 
permettre aux logiciels de marquer une region de texte?
Moi, je pourrais modifier ce propos de sorte qu`on ne puisse générer des 
symboles supplémentaires qu`avec NumLock active.
Voici une possibilité de modifier le fichier '../symbols/pc':

key.type[Group1]="SIX_LEVEL_KEYPAD";
%modifiers to be pressed / modificateurs à toucher:
%             (-)     NumLock  Shift    AltGr Shift+AltGr Ctrl+Alt
key <KPDV> {[division,division,colon,   U2298,KP_Divide,  XF86_Ungrab]};
key  <KP9> {[KP_Prior,KP_9,    noSymbol,U2168,U2468,      noSymbol]};

This is not a desired key mapping, it only shows how to do it!
Ceux ne sont pas les symboles desirés, il s`agit du savoir-faire.

I could also include the modifiers rightControl and the Windows key if desired.
Je pourrais aussi introduire les modificateurs «Contrôle, selection de groupe» 
et la touche fenêtre si l`on en ait besoin.
Gruß, Fabian.

(In reply to comment #22)
> FOUR_LEVEL_KEYPAD could be modified like this:
> 1. If you don`t press shift nor AltGr (right alt), the behaviour is the same as   
> the standard keypad with Server Control
> 2. Pressing shift and/or AltGr ignores NumLock and yields extra symbols.

This is pretty much the behaviour of the latest patch. Only I only use
four-level maps (the trick is to realise keypad is not an uniform area, / * - +
are numlock-insensitive but ctrl+alt sensitive, while the other keys care about
numlock but not about ctrl+alt)

Created attachment 6988 [details] [review]
6987: Patch to test / Patch à tester

Does someone know wether programs or the X server can have a shortcut key 
combination of type Shift+[some Number] ?
I would rather think that only combinations with the editing section or 
direction keys or tab, enter, F1-F12 are possible because Shift+Number can only 
be pressed on the keypad on current keyboards, so programs would be stupid to 
put a shortcut on there.
If we are sure Shift+Number will never be used as shortcut we can safely map 
extra symbols on these keypresses.
In order to be able to press Shift+direction though, all modifiers should be 
deactivated if NumLock is off. (The NumLock key itself will only be used the 
way CapsLock works)
So this is my proposal:

partial default xkb_types "default" {
    type "FOUR_LEVEL_MIXED_KEYPAD" {
	modifiers = Shift+NumLock+LevelThree;
	map[None] = Level1;
	map[Shift] = Level1;
	map[LevelThree] = Level1;
	map[Shift+LevelThree] = Level1;
	map[NumLock] = Level2;
	map[Shift+NumLock] = Level3;
	map[LevelThree+NumLock] = Level4;
	map[Shift+LevelThree+NumLock] = Level5;
        level_name[Level1] = "Base";
	level_name[Level2] = "Number";
	level_name[Level3] = "Shift";
	level_name[Level4] = "AltGr ";
	level_name[Level5] = "Shift AltGr";
    };
};

By the way, the additional level could be filled with roman numbers U2160 up to 
U216B, fractions U2153 or circled Numbers.
Greetings, Fabian

Created attachment 7000 [details] [review]
Patch to test / Patch à tester

Add some ascii-art

Created attachment 7001 [details] [review]
Patch to test / Patch à tester

(In reply to comment #25)

> If we are sure Shift+Number will never be used as shortcut we can safely map 
> extra symbols on these keypresses.

Well, as I wrote before I'm not very keen on going five-level. However if other
people port ther in support of this proposition, and actually propose a good
symbol block for level five, I'll follow the consensus

(In reply to comment #25)

> If we are sure Shift+Number will never be used as shortcut we can safely map 
> extra symbols on these keypresses.

Well, as I wrote before I'm not very keen on going five-level. However if other
people post there in support of this proposition, and actually propose a good
symbol block for level five, I'll follow the consensus

Created attachment 7004 [details] [review]
Patch to test / Patch à tester

As requested by testers :
1. remove all the accented letters not used in French
2. add dead keys to access the removed symbols
3. remove some other symbols not present in the standard fr layout
4. use the space to reorganise more logically French ligatures and accented
letters
5. add a few requested symbols

Created attachment 7005 [details]
Visual of proposed changes / Visuel des modifications proposées

Created attachment 7006 [details]
View of the fr standard map / Visuel de la carte fr standard

Created attachment 7007 [details] [review]
Patch to test / Patch à tester

Fix stupid typo

Created attachment 7008 [details]
View of the proposed changes / Visuel des modifications proposées

Created attachment 7009 [details] [review]
Patch to test / Patch à tester

Another typo

Created attachment 7010 [details] [review]
Patch to test / Patch à tester

Kill sterling, add „

Created attachment 7011 [details]
View of the proposed changes / Visuel des modifications proposées

Matches attachement #7010

Created attachment 7013 [details] [review]
Patch to test / Patch à tester

Bienvenue en Catalogne

Created attachment 7015 [details]
View of the proposed changes / Visuel des modifications proposées

Matches attachment #7013 [details] [review]

Created attachment 7017 [details] [review]
Patch to test / Patch à tester

Comments prettification

Created attachment 7022 [details] [review]
Patch to test / Patch à tester

- Add nodeadkeys/Sundeadkeys/latin9 derivatives of the map
- Try to modularise the basic keypad

(In reply to comment #4)

> If a layout includes it by default, there must be an option to
> provide the original keypad behavior.

The last patch provides a madularised version of the basic standard keypad
Please test if it was what you had in mind

(In reply to comment #19)
> On french keyboard, there is conflict with x modifier key.

The latest patch should revert alternative map behaviour to the standard map one

The problem was there since 2003

Please test

Created attachment 7023 [details] [review]
Patch to test / Patch à tester

Kill trademark sign in latin9 variant

Created attachment 7024 [details] [review]
Patch to test / Patch à tester

Swap sterling and dead_caron, so sterling is back where it was in the beginning

Created attachment 7025 [details]
View of the proposed changes / Visuel des modifications proposées

View of attachement #7024

Created attachment 7026 [details] [review]
Patch to test / Patch à tester

Fix translation typo

Created attachment 7028 [details] [review]
Patch to test / Patch à tester

Typo #2

Nickolas, several important requests:
1. Please could you exclude translation (fr.po) from the patch - it is
distructing. You can just attach it as a separate patch (entire fr.po would be
great to have actually)
2. Could you please make ossmath XkbOptions, not parts of layouts? So I would be
able to use it with Russian, for example? And these options I would like to see
in a patch which would include nothing from symbols/fr. Just symbols/keypad or smth.
3. rules/base should never be patched directly. Could you please provide a patch
to rules/*.part files?

Thanks a lot for your help and your efforts.

Proposition of symbol block for level five:
- roman numbers U2160 (Ⅰ(one)) up to U2169 (Ⅹ)
- circled numbers U2460 (①) ~ U2469 (⑩), maybe U24EA instead for zero
- fractions: one, two, three etc. eighths (⅛¼⅜½⅝¾⅞), i.e. oneeighth, 
onequarter, threeeighths, onehalf, fiveeighths, U00BE, seveneighths
- exotic currencies: (these are maybe better on a fifth level of the alphabetic 
section since most of them are derived from characters of the alphabet and 
would be found easily if «$» would be on «S» and so on)
i.e. $, €, ¤, £ and everything at U20A0 ~ U20CF I think
- switching videomodes (superfluous since already on F1-F12)
i.e. XF86_Switch_VT_1...
Greetings, Fabian.

P.S. My Gimp program has a font named Sans. It seems to be the most complete 
unicode font on my system.

(In reply to comment #49)
> 1. Please could you exclude translation (fr.po) from the patch - it is
>    distructing. You can just attach it as a separate patch (entire fr.p
>    would be great to have actually)

Hey, I am usually taking care of fr translation ;)
Sergey, could you please send a POT file to the Translation-Robot,
so that translators can update their PO files?

>  3. rules/base should never be patched directly. Could you please provide
>     a patch to rules/*.part files?

Nicolas, xkeyboard-config CVS repository can be browsed online at
  http://cvsweb.freedesktop.org/xlibs/xkbdesc/
and checked out with
  cvs -d :pserver:anoncvs@cvs.freedesktop.org:/cvs/xlibs co xkbdesc

Sergey, please recode symbols/fr, this will tighten Nicolas' patches:
  iconv -f iso-8859-15 -t utf8 symbols/fr > foo && mv foo symbols/fr

> Hey, I am usually taking care of fr translation ;)
OK, I do not mind - all I wanted is get rid of translations from this patch:)

> Sergey, could you please send a POT file to the Translation-Robot,
> so that translators can update their PO files?
I sure will once I decide to prepare new release. I think it is a bit early for
it now.

> Sergey, please recode symbols/fr, this will tighten Nicolas' patches:
>   iconv -f iso-8859-15 -t utf8 symbols/fr > foo && mv foo symbols/fr
Done, committed.

(In reply to comment #49)
> Nickolas, several important requests:

> 3. rules/base should never be patched directly. Could you please provide a
patch to rules/*.part files?

The old layout is only referenced by name in compat/*part. Does this mean I
should not patch rules/base or rules/*.part at all ?

Created attachment 7053 [details] [review]
Keypad patch to test / Patch du pavé numérique à tester

Splitting out the keypad changes in a separate patch

Created attachment 7054 [details] [review]
fr.po patch / Patch de fr.po

Created attachment 7055 [details] [review]
Patch to test - needs #7053 / Patch à tester - demande #7053

This patch adds the new fr layout. It requires attachment #7053 [details] [review] and attachment
#7054 [details] [review]

Created attachment 7056 [details] [review]
Patch to test - needs #7053 / Patch à tester - demande #7053

I should really learn not to notice small mistakes after uploading

Created attachment 7057 [details]
View of the proposed changes / Visuel des modifications proposées

View of attachment #7053 [details] [review] + attachment #7056 [details] [review]

(In reply to comment #49)
> Nickolas, several important requests:
> 1. Please could you exclude translation (fr.po) from the patch - it is
> distructing.

Done as attachment #7054 [details] [review]

> 2. Could you please make ossmath XkbOptions, not parts of layouts? So I would be
> able to use it with Russian, for example? And these options I would like to see
> in a patch which would include nothing from symbols/fr. Just symbols/keypad or
smth.

Done as attachment #7053 [details] [review]
This one includes a modularisation of the legacy keypad as requested in comment
#6, and one of my layouts, the fr(oss_latin9), actually uses part of it, but I
made no attempt to kill the existing keypad definition or to convert other
layouts to it since I was way out of my depth there

> 3. rules/base should never be patched directly. Could you please provide a patch
> to rules/*.part files?

I think only keypad needs to patch these, so I integrated the changes in
attachment #7053 [details] [review]

The remaining changes (fr-specific) are in attachment #7056 [details] [review]

I didn't kill the old fr-latin9 in this patch as having both layouts is very
important during testing, I wouldn't object to kill it mid-term but I'd rather
have both layouts available for at least one widespread Xorg release so people
can test, report problems and prepare for the change

(I did flag the old layout as legacy to make plain it's going away)

> Thanks a lot for your help and your efforts.

I must say I don't understand a lot of the things I did (particularly the legacy
keypad modularization and the magic keywords to use before declaring a group) so
some review by people more knowledgeable than me would be nice.

> The old layout is only referenced by name in compat/*part. Does this mean I
> should not patch rules/base or rules/*.part at all ?

Well, may be in your particular case it would be better to patch parts of
rules/compat/* - but I suspect when you implement new XkbOption, you won't need
it at all.

(In reply to comment #50)
> Proposition of symbol block for level five:

Fabian,

I'm very sorry to report that while designing a latin-9 variant of my layout I
became convinced shift should have an effect on the first two keypad levels if I
wanted to be reasonably compatible with the keypad rules people are used to
(I've now narrowed my dislike of the current four-level keypad to the way
numlock state has an effect when isolevel3 is pressed). Several people have
actually written me to drive this point home in the last days.

This pretty much kills your level5 = shift idea for the base enhanced keypad.

Now if you really want to pursue your idea I see two options :

1. add a five-level keypad type with level5=shift only. I don't see it being
popular except among people desesperate for a fifth level

2. add a six-level keypad type where level5 = isolevel5 and level6 = isolevel5 +
shift. This one could actually be reallistic (for layouts already using
isolevel5 at least). The big cons is level5 = ctrlgr usually, and most users
have not learnt to gave up their right ctrl key the way they did for the alt
one. The big pro is → you can also add two level of symbols to all the main area
if your layout is only four-level now
 
> P.S. My Gimp program has a font named Sans. It seems to be the most complete 
> unicode font on my system.

Fabian, Sans is a default fontconfig alias to a synthetic font constructed from
all the sans-serif fonts installed on your system :)

(In reply to comment #60)
> > The old layout is only referenced by name in compat/*part. Does this mean I
> > should not patch rules/base or rules/*.part at all ?
> 
> Well, may be in your particular case it would be better to patch parts of
> rules/compat/* - but I suspect when you implement new XkbOption, you won't need
> it at all.

Anyway, I've now reached what I feel is a reasonable compromise. Please test the
patch series, and tell me what you think (the last fr patch may still move a
bit, but keypad have been stable for several days)

> Done as attachment #7054 [details] [review] [edit]
Patching .po file might be slighly problematic - so I will leave it up to Denis
- merging your patch to the .po file.

> Done as attachment #7053 [details] [review] [edit]
> This one includes a modularisation of the legacy keypad as requested in comment
> #6, and one of my layouts, the fr(oss_latin9), actually uses part of it, but I
> made no attempt to kill the existing keypad definition or to convert other
> layouts to it since I was way out of my depth there
ok, for a moment this will most probably do. Just a question - do you really
think all subparts of symbols/keypad should be made visible through the rules? I
would think only oss and legacy options should be publicly accessible, the rest
I'd mark as hidden.

> I think only keypad needs to patch these, so I integrated the changes in
> attachment #7053 [details] [review] [edit]
Exacly what I meant earlier.

> The remaining changes (fr-specific) are in attachment #7056 [details] [review] [edit]
Seems to be ok as well.

Denis, what's your opinion on these 3 patches, since you know more about French
layout than I do?

(In reply to comment #63)
> ok, for a moment this will most probably do. Just a question - do you really
> think all subparts of symbols/keypad should be made visible through the rules?
> I would think only oss and legacy options should be publicly accessible, the
> rest I'd mark as hidden.

Well I think the modularization work pretty much shows you have to separate the
operator/ctrl+alt keys from the number/num lock ones if you want to be clean (I
tried very crazy 5-6-level keypads before realising this). The oss_latin9
variant in particular shows you can reuse one of the two halves but not the other.

So the math and number bits should definitely be different groups IMHO.

Now should they be exposed as different options? I honestly don't know. My
thought was maybe other people would want to create other four-level cores, and
the users may want to mix and match math and number parts. The number area with
the arrows for example is a very naïve map — I basically added the two-line
arrow variants because I had no idea left.

Fabian Hombsch's posts certainly show other number areas could be designed.

But it's possible everyone will so fall in love with my four-level variant no
other will ever be contributed :)

I'll let you be the judge. I certainly have little use for these options myself,
since the new fr layout uses my four-level keypad by default 

Created attachment 7065 [details] [review]
Patch to test - needs #7053 / Patch à tester - demande #7053

Fix sterling key in layout unicode-art comment

Created attachment 7083 [details] [review]
Patch to test - needs #7053 / Patch à tester - demande #7053

Add öÖ, kill masculine and brokenbar, rearange symbols as a result

Created attachment 7084 [details]
View of the proposed changes / Visuel des modifications proposées

attachment #7053 [details] [review] + attachment #7083 [details] [review]

Hello,
I am willing to make a proposal for an extended keypad version.
But I have noticed a weird behaviour in the standard one
(I think, Nicolas, you have made your keypad compatible to the standard)
I typed “setxkbmap us” in the konsole. than I opened Kate and tried out the 
keypad and got the following:
No modifier -> movement
NumLock or Shift -> Numbers
NumLock+Shift -> movement marking a region of text.

This behaviour is not what I want.
The keypad should behave the same way the editing section does if NumLock is 
not active. I want it like this:
No modifier -> movement
Shift -> movement marking a region
NumLock -> Numbers
This is the way I am used to and I think it`s logical to use the numpad as an 
editing section when NumLock is off. I would not like to stick to such a 
standard.
So Nicolas, which behaviour has your keypad for the first two levels?
Greetings, Fabian

P.S. the standard keypad behaviour seems to be defined 
in “/usr/share/X11/xkb/types/basic” at the end;
“./numpad” looks more like the keypad I want it to be though my self made 
keypad already behaves like I want and doesn`t have a line 
saying “preserve[Shift]...”.

(In reply to comment #68)

> So Nicolas, which behaviour has your keypad for the first two levels?
> Greetings, Fabian

My first two levels have the same behaviour as the "KEYPAD" type :

Nothing : directions (level 1)
Numlock : digits (level2)
Shift : digits (level2)
Numlock+Shift : directions (level1)

In other words when shift is pressed numlock state is inverted.
I don't like it very much but as I understand it the reasonning behind this is
users hate numlock so they'll always let this key in some primary state, and use
shift to switch between level1 and 2

("KEYPAD" is defined in types/basic, though the instruction order does not make
it obvious at first sight that shift is a invert-numlock-state key)

(In reply to comment #68)
> Hello,
> I am willing to make a proposal for an extended keypad version.

Fabian, please make your keypad proposal in a separate bug (depending on this
one if you need to reuse some stuff from there). If you post a reference to this
new bug in a comment I'll be happy to follow the discussion there.

This proposal has pretty much stabilised so I'll probably demand inclusion soon,
which will lead to closing this particular issue

Right now I'm only waiting a grace period to make sure every reviewer had the
opportunity to comment on the last version. So far it seems no one has any
objection left

Nicolas, here are some more remarks, hope you do not mind ;)
  1. What does oss mean?
  2. Is it a good idea to deprecate fr(latin9) with a new variant?
     It seems more natural to me to first add this new variant,
     stabilize it, and after some time declare it stable and
     deprecate latin9.
  3. You added a new FOUR_LEVEL_MIXED_KEYPAD type because you
     dislike the existing one.  But users may prefer
     FOUR_LEVEL_KEYPAD, and you do not give them this choice.
     After more thinking, I would say that NumLock+Shift returns
     level1 in analogy with CapsLock.  There are options to alter
     this behavior (caps:*), so maybe you could keep
     FOUR_LEVEL_KEYPAD as is, but provide options to modify its
     behavior?  In this case, you cannot change the default
     behavior from within your variant, it can only be changed
     by end users.

(In reply to comment #72)
> Nicolas, here are some more remarks, hope you do not mind ;)
>   1. What does oss mean?

Open Source Software. Could have been linux, libre or FLOSS but I was afraid to
offend someone bsd-side

I'm dead tired or renaming this layout every time a new encoding norm appears,
so I wanted something encoding-neutral (and I have zip imagination).

Unicode looks like it'll stay some time, but it would have lead to strange
fr(unicode_latin9) variants

>   2. Is it a good idea to deprecate fr(latin9) with a new variant?
>      It seems more natural to me to first add this new variant,
>      stabilize it, and after some time declare it stable and
>      deprecate latin9.

This version is only being proposed after a big round of feedback (usenet,
historical fr-latin9 contributors, mailing lists, big discussion on the main
French Linux site). I was far less consensual last time - did last minute
adaptations before the XFRee86 inclusion and never received any feedback.

If I missed something, the clear fr-latin9 deprecation notice is here to incite
people to complain before fr-latin9 disappear. A softer approch will only mean
people will complain later.

You should remember however most French users only care deeply about a few
symbols (oe, ae, guillemots), as long as these are carefully placed they'll
accept any placement for the others (which also means there is room for minor
rearengements if needs call)

>   3. You added a new FOUR_LEVEL_MIXED_KEYPAD type because you
>      dislike the existing one.  But users may prefer
>      FOUR_LEVEL_KEYPAD, and you do not give them this choice.

I'm very much against FOUR_LEVEL_KEYPAD.
If someone wants to provide a patch later so FOUR_LEVEL_KEYPAD can be used, I
won't block it, but I won't ever make FOUR_LEVEL_KEYPAD this map default or
waste time trying to include it.

FOUR_LEVEL_KEYPAD pollutes the third and fourth levels with NumLock when :
1. they're not about numbers anymore
2. NumLock is badly placed for a modifier, especially if you want to use it with
other mods
3. it's such a bad mod it does not have any effect on half the keypad in
standard maps
4. people hate NumLock - it's only accepted because they leave it on all the
time on windows, so in practical terms it's not used. (and one of the major
complains about xorg is there's no easy way to get numlock on by default and
forget about it)

I've had several requests to make a numlock-insensitive keypad like on macs. I
compromised by keeping the usual xorg behaviour for the two first levels. KEYPAD
behaviour has the advantage of nominally keeping standard numlock behaviour
while enabling people to use shift instead to switch between the two first levels.

But I certainly won't pollute my two brand new levels with numlock. And
certainly not to blindly keep an analogy.

Now what I'd be interested in is a numlock-on-by-default option - that would be
included in the patch at once.

Ok, I've waited the publicly announced time and no one found any real problem
with the patch during the wait.

I declare this patch series finalised. Please apply

As I said, these patches are generally ok for me. Denis, are you happy?

Yes, fine by me.

Nicolas, I am committing this stuff. But I only put oss and legacy options into
base.o_s.part. Also, could you please provide a patch for base.xml.in for new
xkb options?

Created attachment 7152 [details] [review]
Declare the new options in base.xml.in

(In reply to comment #77)
> Also, could you please provide a patch for base.xml.in for new
> xkb options?

Done as attachment #7152 [details] [review] Hope you like it. If not, tell me what you need

Nicolas, your patch looks good to me. I might change some wording - but in
general it is ok.

Committed, slightly modified. Nicolas, thanks a lot for your patience and efforts.