Name of the extra modifier (Fn/Meta/Sym/...)

Which name do you prefer?


  • Total voters
    63

I'm saying on the Pyra compared to a normal, full sized keyboard.

Since I'm obviously not able to read and understand your layout I'm just going to create an example. This is just an example, I don't know how exactly it applies to your layout because your layout is sufficiently confusing that I can't seem to figure out which key combination actually produces which symbol even when reading it directly, so please see it as only an example and substitute in whatever is more appropriate when you read this:

Consider the semi-colon, the key directly to the left of the "L" on a regular keyboard. For lack of keys it has been decided that it will be an alternate character, let's say AltGr-K. What happens when you press AltGr-K? Are the keycodes "Alt" and "K" produced, or is it just ";"?
 
When you say "my layout" what do you mean. The norwegian locale, my german physical layout, or the one (which?) i made for the pyra"

; is only to the right of L on US keyboard, on german its to the right of M , ;

When i type AltGr+LetterToTheRightOfL   (which is an ø usually, or ö in german) i understand it this way:

I press AltGr down, this changes the shift layer to the third one. Same as shift changes it to the second. Regular presses being first (dedicated)

Now that my ø key has a different value, i press it and get a dead key, press something else and its +(a) á   (+e) é

That is some euro type stuff thats ok to have i suppose, along with the ^ key, if you want.

How i envisioned it is if you press ctrl+alt+any number or the keys to the left and right of space, you get the hidden dead-keys.
 
Your layout, your Pyra layout, the keyboard layout that you have been promoting for inclusion on the Pyra. We are talking about the function of the AltGr on the Pyra, this being a Pyra thread and all.
 
What exactly is the problem with 4 alt-keys?
The same problem as with having 3 shift-keys. They can't all be different and distinguished.

For example, in your layout, you have R1 and R2 both Alt (one of them an R_Alt which is AltGr, the other an L_Alt which is regular Alt)...
Although I prefer the moniker Fn over AltGr, I'm not entirely sure R_Alt is AltGr, in all platforms, after reading this: http://blog.andrewbeacock.com/2007/06/getting-right-alt-key-alt-gr-to-work-in.html

I'll leave it up to others to extrapolate whatever they can from this. 
There are three phases to getting from AltGr keypress to Iso_Level_3_Shift event being put out to an X application:

  1. Keyboard specific signal being interpreted by keyboard driver as the key labeled AltGr
  2. Keyboard driver outputs KEY_RIGHTALT event as specified in linux/input.h
  3. X interprets that driver event into a Iso_Level_3_Shift event
The point everyone keeps trying to make is the second part. There's no AltGr key event in input.h. Hence to distinguish the second AltGr you'd need to output some other key event entirely, like meta, and merely interperet it as third level shift in X. Otherwise you could never tell the difference between which altgr or right alt key is being pressed by looking at the key codes.

The link you provided only deals with the third phase.  The problem is in the second.
 
Last edited by a moderator:
What exactly is the problem with 4 alt-keys?
The same problem as with having 3 shift-keys. They can't all be different and distinguished.

For example, in your layout, you have R1 and R2 both Alt (one of them an R_Alt which is AltGr, the other an L_Alt which is regular Alt)...
Although I prefer the moniker Fn over AltGr, I'm not entirely sure R_Alt is AltGr, in all platforms, after reading this: http://blog.andrewbeacock.com/2007/06/getting-right-alt-key-alt-gr-to-work-in.html

I'll leave it up to others to extrapolate whatever they can from this. 
There are three phases to getting from AltGr keypress to Iso_Level_3_Shift event being put out to an X application:

  1. Keyboard specific signal being interpreted by keyboard driver as the key labeled AltGr
  2. Keyboard driver outputs KEY_RIGHTALT event as specified in linux/input.h
  3. X interprets that driver event into a Iso_Level_3_Shift event
The point everyone keeps trying to make is the second part. There's no AltGr key event in input.h. Hence to distinguish the second AltGr you'd need to output some other key event entirely, like meta, and merely interperet it as third level shift in X. Otherwise you could never tell the difference between which altgr or right alt key is being pressed by looking at the key codes.

The link you provided only deals with the third phase.  The problem is in the second.
Thank you.  :)

Line 463 then "#define KEY_UNKNOWN" or better still, as you've acknowledged, Meta L and R at 342 and 343. 
 
Last edited by a moderator:
I thought keycodes were arbitrary to the controller, guess not.

Thats one level of abstraction less. I assume its easier to get things to work by default that way.

How about #define BTN_MODE 0x13c

Its right below

#define BTN_SELECT 0x13a and  #define BTN_START 0x13b

It looked to me as if Meta could sometimes be interpreted as Alt.

Hyper doesnt seem to have the same connotation, so that could be used for "button that does F-keys"
 
Last edited by a moderator:
Thread is called "Name of the extra modifier"


Alternatives include AltGr. AltGr isnt extra. AltGr is as standard as it gets.


There is nothing non-AltGr about putting an arbitrary symbol on third position on a layout, thats what makes them different, and they all do it.


There is something non-keyboard about putting symbols on letterkeys they dont belong at, and then pretending meta+ only is ok because AltGr would supposedly break something.


What exactly is the problem with 4 alt-keys?  Or, to not confuse the matter dedicated LAlt and RAlt  which some keyboards have,  and 


duplicated 2x AltGr. Dont know if the latter comes in right or left versions.


Its no more confusing than two shifts, or did i just uncover something you hadnt factored in?


Shift and AltGr works exactly "as expected". You would be wrong to think the same is true for a key called Meta doing half of what AltGr does.  Thats the part thats broken at both ends.


However if you want to make AltGr into Meta, then you have two problems.


First of all AltGr isnt Meta, second of all, Meta isnt a shiftmod.  Stop saying the word standard when what you mean isnt just not a standard, but activly breaking said standard.


Sidenote, do you know if those proposed schemes actually work on users?


ÆØÅ arent extra symbols, they are either default letters, or they arent.


I am not the one trying to get things "my way", unless you consider how a keyboard works to be mine in some sense. The highly arbitrary "wb's" way, which he doesnt defend, nor explains, is the part thats subjective.


I agree 100% with your concerns, but I am the one trying to do something about it. Please show both layouts to these average users. Then report back. In my experience, AltGr still fails, and Meta only works for otakus.


I only see rationality in arguments. "My way" is just a label. The problem isnt wb having a layout, the problem is on this particular layout, he has included a key which isnt standard, sporting functionality not seen anywhere but on toy keyboards.


His argument against implementing the standard AltGr key, that more people know how to use, and does more things, is that it conflicts with his already implemented meta. Which is as much of a circular argument as it is ironic.


Yes, you wont get F-keys with shoulders, but then again considering the nature of the argument, average users dont use, nor buy, devices with, F-keys.


You can have a perfectly functional keyboard, like the one im typing on, without super. At the point where you are adding that, but taking away AltGr, it no longer works as expected.


Wb re-designed the layout I consider to be the one i can make that is most closely aligned with the wishes of all parties in the explanation thread. I then answered to all the things i thought to be worse, and all the things i thought to have improved. We are waiting for a reply.


Its either that or implement my concerns in the matrix thread. You'd have to say no to a long list of things to stick to the same guns.


Its our layout, because we all base it off eachother and improve through feedback. And i certainly hope it can be in the end the layout of the average person.
I am not trying to have a debate/argument.  I don't have time for this either.  If you dislike what I have to say then ignore it.  I was just trying to inform you of potential issues, including those related to what is expected on some regional layouts.  AltGr is not seen in some places.  Throwing 4 Alts on it will confuse some people.  You can discuss or disagree all you want, it won't change that.  Maybe I uncovered something you hadn't factored in.  There are regions of the world where AltGr is rare.


If you are saying that renaming _wb_'s Meta that I was talking about will work as an AltGr, which you said would not, convince him, but that results in him doing it your way, which is a larger problem than you may understand.  Good luck either way, he has his own ideas.  In case I haven't made it clear, I personally don't care what it/they are called.  Make the layout work right and I will use whatever is chosen.


To avoid future problems everyone should pretend "standard" is actually the word "typical" in relation to places where those things apply.  I really can't believe this needs to be said.  Everyone needs to stop getting hung up on individual words when it is obvious what someone means by looking at context.


People don't need to defend their choices.  Be critical all you want, they can choose to explain or not.  The man with the money is the one making the final call.  It is helpful to point out the good and bad for a layout, it is not helpful to waste the time of others who are trying to come up with something that they think will work well for everyone by having massive posts that are constantly changing and bugging them until they respond how you want, give the answer you want, or make the changes you want.


I have attempted to get people to look at proposed Pyra keyboard layouts.  They nearly immediately don't care, and none have bothered to spend long enough to make a decision.  If they were going to use a Pyra they may find out too late that a layout that looks clean or seems to have everything they need is actually terrible in real use.


As for Super (or the Windows key), it has been on every keyboard I have used in at least the last 2 decades.  That tells me it is more "standard" than AltGr, which has only been on maybe 2 keyboards I have used, on those were not mine and on the other side of the planet from me.  If your problem is with Meta, I have worked (professionally) on computers with keyboards that featured it.  AltGr is not removed, it is present in right Alt.  Not every keyboard has it listed or functioning as AltGr.  Nearly every modern full keyboard includes Super/Windows key.

It is the little comments like "it only works for otakus" that are what I was trying to bring to light.  Stuff like that and repeating yourself endlessly, demanding explanations, ignoring explanations, saying things that are different than you would do don't make sense (most of the time they only don't to you), etc. that I mean when I say you are trying to force your way on others.  When you harass people because you disagree with their choices it might get the changes YOU want, but that does not mean it is better for everyone, just better in your opinion.  Let other ideas develop.  By having a bunch of different layouts that all work well in their own way we are more likely to get a great layout.

Every keyboard on anything more than a mobile device, which often don't have physical keyboards now, that I have used or seen seriously used by others includes F keys.  Since a big part of the Pyra as the computer it is, as well as emulating computers that may have them, and playing games that make use of them, I feel that they are very important.  The Pyra is for games and emulation first.  You can take or leave that.

I am taking a break from the keyboard layouts for at least a few weeks.  They waste too much of my time to keep up with, and even more when I am trying to comment.  I really want to have the best keyboard for Pyra we can get.  I don't have much free time right now but I would like to give feedback, so if anyone wants my thoughts feel free to send me very brief messages.  I hope I return to some amazing keyboards and can help out.
 
Ok, to sum up. In matters confusion, yes, AltGr fails, some of the time, but not not as much as meta being semi-AltGr. And the latter has less functions.

If that were to change we'd need some insight into the matter, but its left at that.

So we are looking at known to fail in way A vs fails potentially in way X.

If you want to decide between things, its no use pretending one is better because the other is bad. So i asked wb anout the potentials, since hes better at it.

I dont know what im talking about, because i thought linux had AltGr in the same sense it has L_alt and R_alt.

"only for otakus" is a figure of speech borrowed from nintendo, an incidious joke perhaps, but not at all meant as harassment. We all know the arguments, so its better to not expand on everything.

Typical is a very good way to describe the behavior of the AltGr i have been talking about, i realize now its not standard. With two hoops to jump through under the hood.

You might have more luck if you say something like "these are keyboards meant to be easy to use" then i think people feel more authorative than just considering layouts generally, which is quite aparte.

Num lock is also on keyboards, but its not what makes it one. For case of argument you could do without super, and its the basis that matters. I think you are skipping basic and implementing superficial by going with super over typical AltGr. If i dont back up what i say, its always because i think so. As is the nature of things that dont hold more water.

Keyboards using meta isnt a problem. I understand that when they do, they use it as a non-shift modificator. Which apart from the standard functionality on not known buttons, is where i fall off.

As was mentioned, AltGr fails for americans, but its not only about them, making it so would fail for a bigger audience.

I do help in developing where i can, and i wouldnt have a layout to call my own if it wasnt for all the help and feedback from others. But i firmly believe in rational reasoning, rather than assumptions and artistery.

It is a keyboard afterall.

Having someone to point out flaws really helps if you want it to.

With the F-keys the options that stem from thirdLevelShiftMeta vs typical AltGr is that you dont get them on shoulderbuttons.

Furthermore, its a decision between where to put them, and what that conflicts with.

Its a visual thing, which ties into the whole. Implementing them is not something that makes for much incompability, I can only think of troubles with having F11 and F12 at p+2 because you then cant reinstate the prints with meta+ and shift+meta+  if you decide to swap them for regional things primarily. (to type language with full keyboard/all letters)

its very much always a compromize considering the F-keys can never be visually "correct".

For me, it looks like a decision between two

A: Have a button that only does F-keys and shoulderbuttons. Confused mess with vias in the mapping.

vs

B: Have a button that does those two, and thirdLevelShift   but _not_ at the same keys. At best it means that much less functionality.

But, if you go with no printed 3rdlevel on numbers, then you really need other places to put symbols. 

You then have the choices of having more letterbuttons, which still isnt enough(but it does help with the ones you can offload there, like the german ones), so you are left with:

  1. Symbols on letterkeys, visually and functionally confusing.
  2. Symbols on buttonclusterkeys, same, and also problematic because with that being their only placement, you cant use them ingame then.
  3. Symbols on modifiers, not ideal, not pretty.
  4. Symbols in places of modifiers that in turn are moved to top row.  Sometimes it fits (esc) sometimes it doesnt (tab)

I'll keep you updated with the lowdown on the progress. Thank you for all help :)
 
Last edited by a moderator:
So many walls of text, but I have the feeling we don't really understand one another.

Let me try to explain one last time.

The Pandora has an Fn modifier, which is a hardware modifier (actually not really microcontroller-level hardware, just very low level software, but for our purposes let's ignore that distinction). This has advantages and disadvantages. The advantage is that if you type e.g. Fn+Z to get /, the software does not see the Fn or the Z, it just looks as if you pressed 'the slash key'. The disadvantages are the following: the Fn key itself cannot be mapped to anything else in software, since software does not even see it. In particular, if we would want to have Fn as a shoulder button, then that shoulder button would be invisible to software, which would be a fatal problem for games.

So in the Pyra, we want to have a software modifier, that is, a modifier with key events that can be seen by software. That way we can have it on a shoulder button and still use the shoulder button in games. Let's call the Pyra modifier FOOBAR for now.

Now what I want is to still get the advantages of an Fn modifier, but not the disadvantages. If for example / is at FOOBAR+Z, then what I want to happen when you press FOOBAR+Z, is the following sequence of key events: [FOOBAR PRESSED] [sLASH PRESSED] [sLASH RELEASED] [FOOBAR RELEASED]. Software that knows about FOOBAR can see the FOOBAR events, software that doesn't know about it will simply ignore it and still work fine.

Is this the same as AltGr (also known as ISO Level3 Shift)? No, it isn't. AltGr gives you extra symbols if you already have a full keyboard. For example, in the US-International keyboard mapping, these are the AltGr symbols (in blue):

1000px-KB_US-International.svg.png


there are AltGr symbols on many keys: e.g. AltGr+M gives µ, AltGr+5 gives €, AltGr+slash gives ¿, AltGr+, gives ç, AltGr+Shift+, gives Ç, AltGr+" (so AltGr+Shift+') gives dead umlaut, and so on.

Not everyone needs AltGr. Many people don't even know it exists or how it works. But my point is: it's an additional layer of symbols (or actions), on top of the normal full keyboard. There can be AltGr symbols on letters, numbers, punctuation symbols, space, and even on the other keys if you want that. But first you need a normal full keyboard.

So yes, we could call FOOBAR "AltGr" if we want to. But that would be confusing and limiting in many ways. Since AltGr is just the RightAlt key on normal keyboards, it would be very strange to have two normal Alt keys and two AltGr keys, for a total of four Alt keys. We would have to apply weird tricks to even make that work and still be able to distinguish those four keys. But more importantly: if we already use the AltGr (ISO_Level3_Shift) mechanism for all the keys that are missing on the Pyra keyboard as dedicated keys (F1-F12 and a bunch of punctuation symbols, typically), then someone who wants to have a "real" AltGr key, e.g. one that allows him/her to turn the Pyra keyboard into a US-International keyboard, will find out that this has become impossible: a lot of the Pyra keys will already have an 'AltGr' label (but not the correct one), and a lot of normal-keyboard keys will be 'AltGr' keys on the Pyra keyboard (so they can't get a 'real' AltGr label either).

After all, if we put two different keys (e.g. Z and slash) on the same physical key on the Pyra, then if we want to have the same power as a full keyboard, then there have to be potentially 8 different symbols on that one key (even if most users will only use three of them: z Z /). Let's take the example of US-International again:

Z produces z

Shift-Z produces Z

AltGr-Z produces æ

Shift-AltGr-Z produces Æ

slash produces /

Shift-slash produces ?

AltGr-slash produces ¿

Shift-AltGr-slash produces dead hook above, an obscure diacritic used in Vietnamese (unlabeled in the image above, but that's what it does on my keyboard)

so I would expect that if you configure your Pyra keyboard to the setting US-International (assuming it has slash on FOOBAR+Z), then the RightAlt key becomes an AltGr and you get:

Z produces z

Shift-Z produces Z

AltGr-Z produces æ

Shift-AltGr-Z produces Æ

FOOBAR-Z produces /

Shift-FOOBAR-Z produces ?

AltGr-FOOBAR-Z produces ¿

Shift-AltGr-FOOBAR-Z produces dead hook above

This is why I think we should call FOOBAR something else than "AltGr". It could be "Meta", it could be "Hyper", it could be something completely new, I don't really care. Maybe "Meta" does potentially cause some confusion as well (e.g. for Emacs users), so maybe it's not the best choice either. The advantage of "Meta" and "Hyper", "Front" ("Greek") and "Top" is that they are actual modifiers that historically existed on some keyboards in the past, but they currently do not exist anymore. So it has some "retro value" to use one of those names. Now "Front" and "Top" would be a bit weird since we don't have big square keys like on a Space-cadet keyboard, with enough room to put labels on the front of the key or above the main label; most likely our FOOBAR-labels would be to the right of the main label. So that leaves "Meta" and "Hyper". I like the sound of "Meta" (it's a bit philosophical and Greek, which fits well with the geeky Greek-mythology name 'Pyra') and it has a nice symbol which would look well when using color-coding (since it's a nice solid lump of color). "Hyper" is also nice, it's also Greek, etymologically it is the same word as "Super" by the way (both originate from ὑπέρ). Hyper doesn't have a standard symbol though, so we would have to invent our own. Maybe the upwards arrow with double arrowhead that comradekingu proposed would be a good symbol (), though it might look a bit too much like regular Shift (). If the FOOBAR/Meta/Hyper labels are systematically on the right hand side of the keys, then perhaps something like this: could work. Anyway, the symbol does not matter that much, the color-coding would do most of the work.
 
This AltGr stuff seems very weird, especially on my keyboard here primed with the gb layout.  On here æ is on AltGr+A, and Z produces « or < with or without shift.

The weird thing is it depends if you hit shift or alt first.  If you hit shift first it seems to act as a dead key that swallows most subsequent presses silently.  I have accidentally found out though that if you press:

Shift+AltGr+Z, AltGr+Shift+Z you get Ž.  But that can't be the best way to get that character, so I suspect my AltGr is a little broken.
 
Levi, thats perfectly normal. Shift+AltGr is just 4th level whereas AltGr is third.

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

Wb:

Why is it "very strange" to have AltGr two places, and Alt two places?

The level of advancement you imply by even considering the shoulders, is one not required for using keyboard-only. Where both regular Alt and typical AltGr are to be found.

Come to think of it, it would be best if the keyboard alt and AltGr was L_alt and R_alt, then all hackery would be internal to the shoulders.

I agree about the tricks, but this is where i fell of.

"if we _already_ use the AltGr (ISO_Level3_Shift) mechanism for all the keys that are missing on the Pyra keyboard"  Why would we _already_ be doing that?  Consider the options instead.

"if we put two different keys (e.g. Z and slash) on the same physical key"

I thought this was the type of confusion we wanted to avoid. Most notably because:

"Shift-Z produces Z" "Shift-slash produces ?"

I dont see it that way, to me its key does something, shift+key does something, AltGr+key does something  Shift+AltGr does something.

Functionality produces results, not concept produces result. "slash produces /" is alien to me. Could be im just misinformed, or not a US only-keyboard user, but so is a lot of other people, which is problematic.  I think its better to have similar functionality   . : on the same key, instead of arbitrary pairs . > as a result of not having an additional key.

As for AltGr, i think we should arrange so that it makes sense  . : / makes sense to me because  . and / are typed in succession a lot.

Third level shift behind something that isnt a shift type key (meta) (to do things that arent shift type things(?) i think of F-keys as functionality keys,) atleast its different from how its done on keyboards that dont have dedicated F-row. 60% etc.

Then you are inventing something nobody knows about, and its more limited. And you also imply the confusion inherent in moving the symbols that could have been on third level print numberrow.

The reason to do mixing of thirdlevelshift and F-keys with one mod is F-keys with shoulderpresses, (or hacking in F-keys per user option on typical altGr shoulder+letterkeys you dont use AltGr for)

Then there is the assumption the user changes to US international. I dont understand that. You _would_ need a full keyboard to use the default keyboardmappings...

If we make one custom keymap, with our shift+mods and AltGr+mods, why would it be one where you could switch to US-international? Lets see the disadvantages before we deal with how to reinstate that functionality:

Ok, so in US intl mode the right alt becomes R_alt. This changes the whole concept of the default provided keyboard. And is confusing because:

A: If you had just one Alt on keyboard and one on shoulder, you no longer have one of the alts on your keyboard.

B: If you had two alts on both shoulders and keyboard. 

1. There is an alt on the keyboard, (there is also either an AltGr or a us R_alt on keyboard,)  /  There is one alt shoulder (and either AltGr or a R_alt shoulder)

Which means you are back to the old, "there is no full set of keys on the keyboard part only.

or

2. For people who use it, you still dont have an AltGr

So instead of bringing in this US international R_alt functionality to a key, we can have a sequence to do the same.  

Ctrl+alt is the default second option on a US international keyboard. Whether that will work or not i dont know.

Is it possible to use Alt+AltGr? Consider this.   If we put AltGr bottom on the column-row, you get at least 3 combo AltGr-typical presses on number row, which is good.

But what if you got the same Middle columnrow+bottom coloumnrow+5 6 7 for hot-keycombo combopress to dead-keys.  Only now its not ctrl+alt, but instead  alt+AltGr.

I think alt+AltGr makes sense because since the AltGr is thirdlevelshift, the alternate option to having it be that, is having US international functionality.

The drawback is not being able to do hidden dead-keys when you are in games that occupy the start-button.
 
Last edited by a moderator:
Non-commutative modifiers (Shift-AltGr doing something different than AltGr-Shift) are technically possible but I don't like that. However, allowing non-commutative modifiers increases the number of symbols per key from 2^K to e*K! (rounded down) if there are K modifiers, which is quite a big increase.

E.g. if you have 6 modifiers (Shift, Ctrl, Alt, AltGr, Meta, Super), then there are 2^6 = 64 possible actions per key if modifiers are commutative, but you got e*6! = 1957 possible actions per key if the modifiers can behave non-commutatively. One more modifier, and the difference grows even bigger: 128 versus 13700.

But despite the enormous gain in possibilities, I don't like it because I think it's counter-intuitive. I like to think about modifiers as flags, bits, not in terms of ordered key events. Modifier combinations are chords, not arpeggios.

Well it confused me that the order in which I press the modifiers is significant.  Is that what people are proposing for the Pyra too?
No, I don't think anyone is proposing that.
 
Last edited by a moderator:
Why not just put an « alt_L » and « alt_R » and give the choice to the user to turn the « alt_R » to « ISO_Level3_Shift » if needed ?

Many, if not all european keyboard, have « altGr - ISO_Level3_Shift » instead of « alt_R » and we have no difficulty to type, move or resize windows, use shortcuts, etc…

An « FN » key would be a huge mistake since it's an hardware modifier with not possibility to remap anything easily.

« Meta » should be OK for diacritics, dead keys and symbol keys.

What about using tab as « dual-role key » to handle every 3rd level symbol ?
 
Same reason meta isnt AltGr in terms of diactrics, dead-keys and symbol keys. Foreign concept when a more typical expected behavior is possible.


Both alt and AltGr functionality for thirdlevelshift can be had on both keyboard and shoulders.


I'd much rather it was the dead-key R_alt stuff that was a hack, because that isnt as simple anyway.


And the deviation is pressing something else to invoke it, no big changes in how it works.
 
Last edited by a moderator:
Why not just put an « alt_L » and « alt_R » and give the choice to the user to turn the « alt_R » to « ISO_Level3_Shift » if needed ?
That's exactly what most proposals do. E.g. my proposal has Left Alt at START (like on the Pandora), and Right Alt at R2. If you want to have an ISO_Level3_Shift (AltGr), the default thing to do would be to put it on the Right Alt, which means you get an efficient shoulder-button modifier as AltGr, at the price of no longer having an efficient Alt (but you still have the Left Alt which was the only Alt on the Pandora; not ideal, but it certainly works).

The user could turn other keys into an ISO_Level3_Shift too, if they still want to keep the shoulder button Shift/Ctrl/Alt/Meta. For example you could also make Left Alt (START) an AltGr, or Left Ctrl (SELECT), or the keyboard Shift or Meta (if you're using the shoulder buttons anyway for those).

What about using tab as « dual-role key » to handle every 3rd level symbol ?
What do you mean by this? Let tab be a modifier? Sounds weird to me.
 
For example you could also make Left Alt (START) an AltGr, or Left Ctrl (SELECT), or the keyboard Shift or Meta (if you're using the shoulder buttons anyway for those)
Or go the Window's way and use chorded Ctrl+Alt. Very easy to mash whether using the keyboard or the shoulder buttons.
 
@_wb _ tab as a modifier but only if we press another key.

Let's say we want to use tab/altGr as a dual-role key.

If you press « Tab » alone, you've got what you expect => tab

if you press « tab » + « key » it will act as a « altGr » + « key »

we may use the same with space/meta or any other combination.

https://gitlab.com/at-home-modifier/at-home-modifier-evdev/wikis/home

@WizardStan, that's comradekingu proposal http://boards.openpandora.org/topic/17881-its-the-keyboard-layout/?p=381780/URL]
 
Last edited by a moderator:
@_wb _ tab as a modifier but only if we press another key.

Let's say we want to use tab/altGr as a dual-role key.

If you press « Tab » alone, you've got what you expect => tab

if you press « tab » + « key » it will act as a « altGr » + « key »

we may use the same with space/meta or any other combination.

https://gitlab.com/at-home-modifier/at-home-modifier-evdev/wikis/home
I have proposed a similar thing with the shoulder buttons (optionally), to make them behave as mouse clicks when tapped and as modifiers when used with other keys.

There are indeed possibilities for 'overloading' like that, but personally I prefer to keep things conceptually clean. I'm not very comfortable with using tab or space as a modifier key. I'm fine with using modifier taps as keys though, like Ubuntu uses Super taps for the Dash Home and Alt taps for the HUD while still having both of them as modifiers too.
 
Back
Top