Recent Posts

Pages: [1] 2 3 4 ... 10
1
what do you put in the art field?

it accepts http:// link on the internet pointing to png or jpg file.
2
I'm really excited to use this thing, been looking all over for a card generator that has the old style frames.  Everything seems to work except the art, what gives?
3
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« Last post by sdothum on April 17, 2018, 05:17:44 AM »
So when I define the layers, if I want a separate Shift layer, will it effectively be a duplicate in most cases? eg if g and G happen to be on the same key, then we say that base layer and shift layer both send KC_G ?

Depends on how you define the keycode on the Shift layer. If the Shift layer uses a Shift modifier (and there are many types of shift key actions -- conventional, one shot, down position of a key that otherwise outputs a character, etc.) then yes, if pressed without a modifier enabled. But you could define the key position with a macro definition "S(KC_G)" to output shift "G" without need of the Shift modifier.

I use 2 Shift layers precisely that way to split the keyboard so each thumb hand holding its designated Shift key (which is not a real modifier but a layer invoking key) can type special symbols (like a keypad) while the opposite hand types shifted characters.

Layers free you from being limited to just a set of modifiers as you can see from the example link I posted earlier. The current limit is 32 layers. I probably use more layers than most and haven't come close to that.

Hope this further clarifies how one approaches QMK.
4
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« Last post by sdothum on April 16, 2018, 05:50:21 PM »
I can see for example how to send KC_CIRCUMFLEX, but for example KC_G sends both g and G .... or is it actually sending the scancode from an ANSI keyboard for G? ie <AC05> = 43  (lifted from //usr/share/X11/xkb/keycode/ibm  scancodes file) or somesuch?

Like I said, I was expecting QMK to specify that the key in row 3 column 6 sends AC05, and then in /usr/share/X11/xkb/symbols/us

I would have something like key <AC05> { [         g,          G,     copyright, dead_doubleacute ] }; But I suppose XKB is only set up for Shift, AltGr and ShiftAltGr, and QMK allows for other fancy tricks.

So when I define the layers, if I want a separate Shift layer, will it effectively be a duplicate in most cases? eg if g and G happen to be on the same key, then we say that base layer and shift layer both send KC_G ?

Each layer defines a single keycode for each key position. So, if you define a key location with "KC_G", if pressed, it will output lower case "g". If you define a modifier key on that layer (it can inherit this keycode from the calling layer so you don't have to define positional modifiers that you want to exist across layers), say "KC_LSFT", if held down, will cause "KC_G" to output upper case "G".

You can define a key with a macro keycode, such as "S(KC_G)", which if pressed, will output upper case "G" so you don't need to hold down a modifier -- you can even define chained modifier keycodes, e.g. "LCTL(S(KC_G))". And you can define chained modifiers that, when held down (or tapped, one shot, etc.), operate on all the defined keycodes of that layer. You can create complex and convenient key values this way.

So a layer defines a default keycode for the key position, and any modifier alters the ANSI output value.

Now, you also have the ability within QMK to trap the keystroke stream and do what you want to with any of your defined keycodes -- extend QMK macro functionality, manage layers beyond what QMK has macros for, write a calculator, etc. The latter would be over the top but you get the picture. I have extended and added a lot of layer functionality to suit my own workflow. But the QMK library probably fills the needs way beyond what most people would use with its extensive set of key actions, such as one shot modifiers/layers, toggle keys/layers, tap dance, etc.

So, in your above example, you probably need 3 layers: "g" on one with a modifier to produce "G", and separate layers to produce the special characters (unless a modifier would suffice on one of the 2 symbols -- though, I would imagine using two or more layers would make for a much more flexible organization of symbols).

Hope this helps.
5
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« Last post by iandoug on April 16, 2018, 02:37:38 PM »
To map a different key to a "shifted" key or other modifier (or any other designated key for that matter), you can use layers, effectively defining a layer that is raised by the designated "shift" key. The manner in which the layer is raised -- held down, toggled, one shot, multiple taps, etc. -- is up to you. Thus, any key can issue any specific keycode on a particular layer.

A single key can be responsible for many layers. And layers can require multiple keys. Layers can beget layers. It sounds crazy but there are use cases.

I can see for example how to send KC_CIRCUMFLEX, but for example KC_G sends both g and G .... or is it actually sending the scancode from an ANSI keyboard for G? ie
<AC05> = 43  (lifted from //usr/share/X11/xkb/keycode/ibm  scancodes file)
 or somesuch?

Like I said, I was expecting QMK to specify that the key in row 3 column 6 sends AC05, and then in
/usr/share/X11/xkb/symbols/us

I would have something like
 key <AC05> { [         g,          G,     copyright, dead_doubleacute ] };

Trying to wrap my head around this, bearing in mind Windows works differently to Linux, I'm guessing Mac works similarly to Linux here, but has their own keyboard layout description files.

But I suppose XKB is only set up for Shift, AltGr and ShiftAltGr, and QMK allows for other fancy tricks.

So when I define the layers, if I want a separate Shift layer, will it effectively be a duplicate in most cases? eg if g and G happen to be on the same key, then we say that base layer and shift layer both send KC_G ?

Which seems somewhat counter-intuitive :-)

Confused, Ian


6
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« Last post by iandoug on April 16, 2018, 12:52:50 AM »
To illustrate http://thedarnedestthing.com/split%20redux. Unrelated to this topic but I have since migrated to this BEAKL mashup for the better finger rolls and the least same finger usage http://www.keyboard-layout-editor.com/#/gists/e0c628a2707117813c46611d37dee43e for anyone scrutinizing the layout in the link.

Thanks, will study.

Cheers, Ian
7
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« Last post by mstacker on April 15, 2018, 05:17:02 PM »
To illustrate http://thedarnedestthing.com/split%20redux. Unrelated to this topic but I have since migrated to this BEAKL mashup for the better finger rolls and the least same finger usage http://www.keyboard-layout-editor.com/#/gists/e0c628a2707117813c46611d37dee43e for anyone scrutinizing the layout in the link.

Nice website and explanation.

Matt
8
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« Last post by sdothum on April 15, 2018, 04:33:28 PM »
I was expecting (based on what I've seen of XKB config files) that QMK would send "Scancode A1" being first key in top row, and then rely on the PC operating system to decide what to do with it. That would seem the obvious way to do it to me. But no. Possibly this is also related to all the layers/one-shot modifiers/etc/etc/ that QMK supports.

In QMK the standard modifier keycodes (shift, ctrl, etc.) when held down will issue the standard keycode for the following key presses. Similarly, the built in macros like S(keycode) will issue the ANSI shift value e.g. S("/") == "?".

To map a different key to a "shifted" key or other modifier (or any other designated key for that matter), you can use layers, effectively defining a layer that is raised by the designated "shift" key. The manner in which the layer is raised -- held down, toggled, one shot, multiple taps, etc. -- is up to you. Thus, any key can issue any specific keycode on a particular layer.

A single key can be responsible for many layers. And layers can require multiple keys. Layers can beget layers. It sounds crazy but there are use cases.

To illustrate http://thedarnedestthing.com/split%20redux. Unrelated to this topic but I have since migrated to this BEAKL mashup for the better finger rolls and the least same finger usage http://www.keyboard-layout-editor.com/#/gists/e0c628a2707117813c46611d37dee43e for anyone scrutinizing the layout in the link.

For me, ANSI output yields the most portable solution. Just plug the keyboard into any computer and I am never without my layout.

Hope this helps.

9
Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« Last post by philippe.quesnel on April 15, 2018, 09:30:03 AM »
...  and there is a large assumption that "a" and "A" (or 4 and $) will be on the same key, which is not the case these days.

I was expecting (based on what I've seen of XKB config files) that QMK would send "Scancode A1" being first key in top row, and then rely on the PC operating system to decide what to do with it. That would seem the obvious way to do it to me. But no. Possibly this is also related to all the layers/one-shot modifiers/etc/etc/ that QMK supports.
I don't know QMK, can't help there, sorry.
I did have a similar problem about Aa /? etc when trying to program my SmartYaos : I can tell it which USB HID code a key sends ... and, well, these codes are defined in the standard so that for eg. code 7 is for both d and D

http://www.usb.org/developers/hidpage/Hut1_12v2.pdf

I ended up programing a QWERTY base / ref and doing the actual layout w. AutoHotkey, which means no Linux for now.

So now it looks like I have to define that a key is sending "/", but no, it's not sending "?" as well. It's a different key that's sending that.
strange, not sure I understand how that works, but as long as you do ;-)
Go for it, get that puppy going!!

Very glad to hear that your wrist is doing much better
10
Keyboards and Other Interfaces / Re: not good
« Last post by iandoug on April 15, 2018, 08:27:44 AM »
How is your wrist doing these days brother?

:-) Thanks for asking. It's improved, not back to how it was before though. Some bends are tight (flexion position), one causes pain (tension position), and the supination position (ie palm up) is still not horizontal ... can get it almost horizontal if I twist it with right hand. My age also means things heal slower than when I was a kid. But getting there. :-)

I can type etc okay, just some stretches a little sore.
Got a bit distracted with Forex stuff, but getting back into keyboard issues again too.

Pages: [1] 2 3 4 ... 10