Is there a way to have Ukelele show layouts on a grid key layout instead of a standard staggered one?

[julian]

Hi,

Is there a way to have Ukelele show layouts on a grid key layout instead of a standard staggered one?

I'm learning Workman-Dead (slightly customized using Ukelele) and use screen-captures of the possible states of the keyboard as a reference when I practice.  However, I practice using a Kinesis Advantage, which has a grid key layout, not staggered the way it appears in Ukelele.  When I look at the screen-captures to locate a key, I find that mentally translating between positions on the Kinesis grid layout to the staggered ones in the screen-captures and back again slows me down considerably.

Thanks!

Julian

[John Brownie]

Short answer: not at present.

Longer answer: Apple, from the early days of the Mac on, defined a
resource format (KCAP) which described the layout of a hardware keyboard
layout. They included descriptions of all Apple keyboards, but not of
any third-party keyboards. The KCAP resources disappeared at some point
in the last few years, but I don't know what has replaced them (a
research project at some point soon). Currently, Ukelele uses an
internal data file which has versions of these resources, and can only
display one of those. To get another keyboard design, I'd need a version
of a KCAP resource for that, which is unlikely to happen, as it's a
binary file format, not easy for a human to read. Further down the
track, it may be possible to add a way to define a keyboard through a
different mechanism, possibly a text file or even a graphical editor,
but that's a bigger task.

John
--
John Brownie, john_b...@sil.org or j.br...@sil.org.pg
Summer Institute of Linguistics, Ukarumpa, Eastern Highlands Province,
Papua New Guinea
Mussau-Emira language, Mussau Island, New Ireland Province, Papua New Guinea

[julian abiodun]

Ah, ok. Thanks anyway.

--
You received this message because you are subscribed to a topic in the Google Groups "Ukelele Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ukelele-users/1wXNa8OWMbA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ukelele-user...@googlegroups.com.
To post to this group, send email to ukelel...@googlegroups.com.
Visit this group at https://groups.google.com/group/ukelele-users.
For more options, visit https://groups.google.com/d/optout.

[Crash Coredump]

Why not open up the source? This functionality is extremely useful and open source community would've made a patch in a matter of days.

[Carl Smith]

On Wednesday, 19 April 2017 07:49:46 UTC+1, Crash Coredump wrote:

Why not open up the source? This functionality is extremely useful and open source community would've made a patch in a matter of days.

I would personally feel much more comfortable promoting and contributing to an open source project. Like many, it makes me nervous installing software that is gratis, but proprietary. I'll do it on my personal computer, but not on a system where security is a serious concern.

This isn't an accusation. I like Ukelele, am grateful for it and don't suspect anything untoward here. I'm just generalising about freeware.

[Gé van Gasteren]

Dear Carl,

John Brownie, the only developer involved with Ukelele as far as I know, works for SIL and basically created Ukelele to help him with his work.

That he has made it free is just his courtesy to the community.

I’m pretty sure he’ll send you the source if he thinks that may help, or just to make you comfortable, but to have more people work on the program would create much more overhead to keep things bugfree and coherent, and I don’t think John is eager to do that in his spare time...

--
You received this message because you are subscribed to the Google Groups "Ukelele Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ukelele-users+unsubscribe@googlegroups.com.

[Aural Architect]

Thank you for that explanation!  That's too bad that it's not simpler/more accessible.

I've started using some other tools to re-purpose extra 'special' keys (that I don't/can't use) on my kbd so they produce text.  Editing them with Ukelele was cumbersome and prone to crashing since it involves changing the keyboard map between ANSI, ISO & JIS (it's common for Ukelele to crash if I change the keyboard map- I'm sure it has nothing to do with Ukelele & everything to do with my quirky, extremely customized configurations!  I like to tinker & customize.  A lot...  until I get things "just right".  It's fun & has its rewards- but it comes as a cost sometimes- mainly stability).  So, I've found it easier to just make the changes to the keylayout file in a text editor- it's just 4 keys.


In any case, I wanted to share this site I'm excited about that I recently discovered!  It's pretty awesome.  Just the sort of thing I enjoy.  I was thinking that maybe it could potentially be a helpful resource, or may even be used as a tool to design customized graphical keyboard layout maps to be imported & used in Ukelele?   Just a thought...  Depending on the format & data contained in the export file, it might be able to facilitate expediting the addition of this feature without too much work at some point.

Stay safe!  Cheers!!!

[John Brownie]

Aural Architect wrote:

I've started using some other tools to re-purpose extra 'special' keys (that I don't/can't use) on my kbd so they produce text.  Editing them with Ukelele was cumbersome and prone to crashing since it involves changing the keyboard map between ANSI, ISO & JIS (it's common for Ukelele to crash if I change the keyboard map- I'm sure it has nothing to do with Ukelele & everything to do with my quirky, extremely customized configurations!  I like to tinker & customize.  A lot...  until I get things "just right".  It's fun & has its rewards- but it comes as a cost sometimes- mainly stability).  So, I've found it easier to just make the changes to the keylayout file in a text editor- it's just 4 keys.

Nevertheless, please do send in crash reports. Any program crash is a sign of a bug of some sort, as any expected failure should be handled more gracefully.

In any case, I wanted to share this site I'm excited about that I recently discovered!  It's pretty awesome.  Just the sort of thing I enjoy.  I was thinking that maybe it could potentially be a helpful resource, or may even be used as a tool to design customized graphical keyboard layout maps to be imported & used in Ukelele?   Just a thought...  Depending on the format & data contained in the export file, it might be able to facilitate expediting the addition of this feature without too much work at some point.

Interesting indeed. I'll have to look at that and see if it's a feasible addition.

John

--
John Brownie
In Australia on furlough from SIL Papua New Guinea

[Aural Architect]

I've had a chance to play around with the keyboard-layout-editor (referenced above).  It is quite a useful tool.  It is also still being actively developed, although the developer doesn't seem to post much (if anything) on the forum.  At first I thought it was abandoned because of all the open issues going back over a year with no response, but when looking at the closed issues I saw that he was been making consistent updates.  Users have reported a number of glitches/issues which he doesn't seem to find important (and has ignored), as well as feature requests handled similarly.
The main thing that I would imagine that would need to be added (which has been requested and ignored) is the integration of key codes/scan codes- not just the character output.  But I was thinking that perhaps if someone was creating a physical layout to be used in Ukelele, you could specify that the corresponding key code must be added to a particular field.  I was also thinking that it might even be possible to create a basic .keylayout file from the "raw data" created by the app.  However, users would have to strictly conform to a preset mapping of the various fields to modifier key maps.  The keylayout would be rudimentary and possibly incomplete if any dead keys were required.
I have no idea how the physical maps are defined by the KCAP resource—what data is contained, etc.— or how that information is extracted & used by Ukelele to generate the on-screen layouts.  And ultimately I have no clue how feasible it would be (and how much work would be required) to utilize an additional, new source (in a completely different format) to generate the on screen keyboard.
And while it would be nice to have this feature in Ukelele it is certainly not urgent, and there are already existing issues that I'd imagine are more important for you to work on.  Plus, adding a new feature means more code to maintain!

In any case, it is a fun tool, and it is open sourced- which is great if you did ever decide to do something with it.