• You are not logged in.

3 months in

  • Started by stratacast1
  • 33 Replies:
  • Reputation: 23
  • From: Belgium
  • Registered: 26-Feb-2008
  • Posts: 480

Actually, in my experience the xkeyboard-config project (that manages the keyboard layouts for X.org) is fairly indulgent in accepting alternative layouts – if they are NOT mere personal hobby projects that have just one or a few users.  That is, they typically ask some references to the layout that "prove" actual use and thus justify inclusion.

Offline
  • 0
  • Reputation: 210
  • From: Viken, Norway
  • Registered: 13-Dec-2006
  • Posts: 5,343

Maybe you can teach me how to submit stuff, GHen? The proper format for rules files and suchlike. And do I fork/pull-request something or what?

Or, if there is a clear guide somewhere, point me to it.

Last edited by DreymaR (15-Oct-2018 14:34:03)

*** Learn Colemak in 2–5 steps with Tarmak! ***
*** Check out my Big Bag of Keyboard Tricks for Win/Linux/TMK... ***

Offline
  • 0
  • Reputation: 23
  • From: Belgium
  • Registered: 26-Feb-2008
  • Posts: 480
Offline
  • 1
  • Reputation: 210
  • From: Viken, Norway
  • Registered: 13-Dec-2006
  • Posts: 5,343

Thanks a lot. But what I don't know is where to get for instance rules/base.lists.part instead of the compiled one, and exactly how to compile the parts into the finished files for use.

Okay, I found this xkeyboard-config download. Time to peek inside... but there's about 45 rules/ files and I'm still quite confused. Not easy to just read a makefile... Well, I think I know how to compile but not yet where to put my various rules changes.

Last edited by DreymaR (18-Oct-2018 09:26:31)

*** Learn Colemak in 2–5 steps with Tarmak! ***
*** Check out my Big Bag of Keyboard Tricks for Win/Linux/TMK... ***

Offline
  • 0
  • Reputation: 23
  • From: Belgium
  • Registered: 26-Feb-2008
  • Posts: 480

It's easier to just clone the git repo, so you can diff and commit etc locally.

To build, you'll first have to run ./autogen.sh and ./configure --bla to generate the various Makefiles.  You may have to install some extra build dependencies iteratively until this succeeds.

The "build" process will be mostly about packaging and putting stuff together, there is no real compilation involved.

There are some README files in the repository (particularly in the docs/ directory), and some general guidelines in the Rules document on the website, but other than that, the documentation is quite sparse unfortunately.

Offline
  • 0
  • Reputation: 23
  • From: Belgium
  • Registered: 26-Feb-2008
  • Posts: 480

Just ran the complete build procedure here; it merely generates the rules/base, base.xml, base.extras.xml, evdev, ..., and the manpage.
But that's what you were looking for?

Offline
  • 0
  • Reputation: 210
  • From: Viken, Norway
  • Registered: 13-Dec-2006
  • Posts: 5,343

Yes, for use. But what I'm really looking for now is how to reverse this in terms of my changes. I've just written my changes directly into the files (evdev, evdev.lst, evdev.xml) and while that works for the end user it's obviously the wrong way to treat the repo! So I need to find out where all those changes should really go. I've found the following in the rules Makefile:

base.xml.in → base.xml
(same for extras.xml)

Plain files and lists are way more confusing, e.g. [some line breaks edited out]:
evdev_parts = base.hdr.part base.lists.part \ evdev.lists.part \
HDR evdev.m_k.part \ HDR base.l1_k.part \ HDR base.l_k.part  \ HDR \
HDR base.ml_g.part \ HDR base.m_g.part \ HDR base.mlv_s.part \ HDR base.ml_s.part  \
HDR base.ml1_s.part \ HDR \ HDR base.ml2_s.part  \ HDR base.ml3_s.part  \ HDR base.ml4_s.part  \ HDR \ HDR \ HDR \
HDR evdev.m_s.part \ HDR \ HDR \ HDR \ HDR \ HDR \ HDR \ HDR base.ml_c.part \ HDR base.ml1_c.part \ HDR base.m_t.part \ HDR \
HDR base.l1o_s.part \ HDR base.l2o_s.part \ HDR base.l3o_s.part \ HDR base.l4o_s.part \
HDR base.o_s.part \ HDR base.o_c.part \ HDR base.o_t.part

So... what's base.l2o_s.part then for instance? Is there an overview of what the different parts do somewhere? And are the .lst files generated completely, with xml2lst.pl?

Last edited by DreymaR (19-Oct-2018 13:29:47)

*** Learn Colemak in 2–5 steps with Tarmak! ***
*** Check out my Big Bag of Keyboard Tricks for Win/Linux/TMK... ***

Offline
  • 0
  • Reputation: 0
  • Registered: 13-Jan-2018
  • Posts: 19
ghen said:
stratacast1 said:

I've seen vanilla Colemak on macOS, OpenBSD and NetBSD and Linux...shakes fist at FreeBSD, maybe I should be the one to do a pull request.

Colemak has been included in FreeBSD wscons since 2008, and should be available in X.org as well via xkeyboard-layout, since at least as long.

Sure enough, must have slipped by me.

stevep99 said:

I'd say this is because now you are using a much better layout, you notice the difference. It's general point about whenever you switch to using something of better quality: it makes you more discerning.

Completely agree, and those moments I have to return to QWERTY I just notice it's all around uncomfortable. Most of my typing feels smooth to say the least.

stevep99 said:

Maybe there should be some sort of effort to get Extend included as a built-in option in some operating systems?

I think there should be for the variants of Colemak. We have how many different Dvorak options, but only vanilla Colemak? It would be great to see Colemak derivatives. I'm sure these could be easily seen in the Linux and BSD operating systems.

My bad for not responding guys, spent some weeks away from the computer for some RnR :D

Offline
  • 0
  • Reputation: 210
  • From: Viken, Norway
  • Registered: 13-Dec-2006
  • Posts: 5,343

Extend isn't even a layout variant but a layout addition. It should play equally well with QWERTY as with Colemak-CAW.

*** Learn Colemak in 2–5 steps with Tarmak! ***
*** Check out my Big Bag of Keyboard Tricks for Win/Linux/TMK... ***

Offline
  • 0