Add console

[ctrlcctrlv]

@eliheuer suggested I make some issues so people know my plans.

Pressing : should open a console, similar to Yakuake and Vim. You type a command, like :selectall or :set CLEAR_COLOR 0xff_000000, pressing enter executes command.

Qglif will not have menus, it will only have hotkeys and a console.

[ctrlcctrlv]

@eliheuer This is what I was trying to explain a few days ago. I just pushed f08c3ea, which has three commands: :vpoffset, :vpfactor, and :q (quits Qglif).

I foresee the in-app console as the main way users are going to be interacting with Qglif, not menus. Obviously I'm adding a lot of functions, and there will simply be more functions than keyboard keys quicker than one thinks :-)

So, before :vpfactor 0.5

After

Of course, this can be done with the zoom tool, this is just a simple example. More remains to be done: receiving commands from the console's stdin, outputting messages to the user from commands:

https://github.com/mfeq/Qglif/blob/f08c3ea68b77f78a25e7e8842a1d044d3b795694/src/events/console/commands.rs#L15-L45

I want to ask people what they think about this. I plan to have :w save, and to have commands for getting and setting almost all variables, including colors et cetera.

Furthermore, I'm going to add a --prelude switch, which will take a file formatted e.g. like this:

:set BACKGROUND_COLOR 0xff_000000
:set OUTLINE_FILL 0xff_ffffff
:set OUTLINE_STROKE 0xff_aaaaaa

That will execute the commands immediately when Qglif launches, and might also solve #7.

I wonder what you, and others, think about using Qglif via in-app commands and not menus. This is what I meant by keyboard-driven.

Of course, many common commands will have keyboard shortcuts. And I might even add run-time configurable hotkeys someday tied to commands, but that's not a 1.0 feature.

cc @arrowtype @bghryct @skef @iwsfutcmd

[skef]

My only strong opinion is that if you're going in the console direction for a design tool you should keep the console stuff "one-handed" (as it were). And given that there's no obvious reason for a "modal" console (in vi and derivatives the reason is to allow for "normal" typing combined with maximally expressive commands) you might consider abandoning the console idea in favor of just "keyboard commands".

More specifically, given your skia-based direction, probably multi-key commands where either the first key brings up an overlay on the portion of the screen, or some key or button toggles the overlay. Then you can show the letters of the command as they're typed, other relevant feedback (such as a mapping between subsequently typed letters and option) or both.

Any system that involves constantly moving one's hand back and forth between the keyboard and mouse seems like a big loose. If PC gaming has taught us anything it's taught us that.

[ctrlcctrlv]

I like the idea of multi key commands, but what about arguments?

[skef]

For truly general text arguments like point names you'd presumably just switch to typing. But in this domain those are fairly modest and rarely-used: filenames, font names, point names. Glyph names might come up more often, not just for entry but for references and searching, so it might be worth putting some thought into alternatives.

But in many cases -- certainly those conceptually equivalent to menus rather than dialogs -- you don't need the whole keyboard or any modality. Those are mostly what I'm talking about. Replacing menus with something like vim command mode seems like a mismatch. Replacing them with half-keyboard directives similar to PC games seems like a much better match. (And just as one can pick FF palette tools from the menu one should also be able to do so from the keyboard.)

Given your other implementation choices there's an opportunity for a translucent overlay interface, which the user could leave on as a beginner and turn off once they know the commands (or briefly to glance at the glyph without distraction).

[ctrlcctrlv]

Yes, they aren't currently labeled but the four tools are selectable with equal default hotkeys as the ones in FontForge.

[arrowtype]

Qglif will not have menus, it will only have hotkeys and a console.

My first reaction is that this sounds really cool, but also rings the alarm bells in my designer brain.

A high-level question:

1. Who is this app for? To me, the biggest advantage of an open, cross-platform font editor is that it would open up the field to more newcomers, especially folks like high school students who don’t have tons of cash for mac computers. But, if this becomes a vim-like experience, that would immediately, dramatically limit the accessibility to newcomers. The cross section of people who are die-hard key-command enthusiasts AND who like visual expression enough to be into fonts is probably fairly small, and probably skews a bit older. I love an app that is highly efficient for pros, but I also think it is pretty critical to have an easy on-ramp for new users.

And two low-level questions:

1. How are commands and functions discoverable? Two things that come to mind are: tooltips for palette tools (similar to Photoshop et al), and the VS Code command palette. But, in the case of the command palette, it is still helpful to newcomers that it is available from a menu (along with a reminder of the hotkey). If users have to consult documentation for all functionality, I worry that the vast majority might give up before getting very far.
2. If/when there are user-made scripts & extensions, how can these be accessed and activated? Menus are very handy, as they allow a large palette of additions, and don’t force the user to A) remember the naming and B) assign key commands ... for every additional function.

[arrowtype]

Sort of adding to the last question above...

Menus & UI allow a dramatic expansion of user capabilities.

Admittedly, I am not really a vim user. I basically know three commands so I can handle it with Git: insert, write, quit.

I use VS Code daily, and though the command palette is super nice, I maybe only remember about 10 commands in it.

I use RoboFont daily, and thanks to menus plus UI like the inspector or UI in extensions, I regularly use dozens and dozens of functions. RoboFont definitely isn’t the ideal UX in many ways, but it (along with its associated extensions) does a lot of things really well. Making a font or font family is a necessarily complex process, and I can’t really imagine it being feasible for people to learn it without UI.

Of course, my knowledge is super limited in the wide scheme of applications. I know I have briefly encountered CAD apps that rely heavily on commands, though I forget which apps, and I forget whether they had menus/UI as backups to these commands (I suspect probably so). There are probably some really complex apps that do rely on a vim-like approach, but which I am not aware of.

But, my perspective is that a command palette is an excellent enhancement to an app, but not a feasible substitute for menus & UI.

[ctrlcctrlv]

Discoverability is certainly an issue. Clearly some kind of overlay is needed to list all the commands along with short descriptions and quickly fill them in. If the command takes no arguments, that overlay can also just run the command. I see what @skef is getting at, and think I can merge the ideas.

If you've looked at the code, you notice that I am dealing a lot with correcting for factor and offset when drawing constant UI elements. I finally figured out a way to be able to push/pop transform matrices on the SkCanvas, see https://github.com/aclysma/skulpin/issues/66#issuecomment-693529243. So, it's going to be a lot easier for me to draw overlays. In fact, I might even be able to retire ImGui and replace it with iced now that I can reset the transform matrix without changing what I've already drawn. Let's see about that though, cf. #14 & https://github.com/hecrj/iced/issues/520.

[ctrlcctrlv]

As far as "who is this for?", primarily myself, but I do want to make it usable by "normal people". But, it's definitely a tool for hackers, I plan on having HACKING.md as a big part of the documentation explaining how users can change Qglif itself and my implementation choices, walking through adding a feature, etc.

However, having just a console with no way to know what to write in it isn't ideal, so I will add an overlay listing all commands. It's a good thing we're thinking about this now before I add a ton of commands.

[arrowtype]

Good point on the overlay, though I do wonder how scalable it is. Once you have enough functions, won't you need to categorize them in the overlay? And then, maybe you'd want to make some categories collapsible, to avoid too much clutter at once? And then, it might be nice if those category headers could be persistent, to avoid the need for an overlay to clutter the view, and probably these should be up top to be easily accessible but out of the way... 🙃

Menus are a pretty useful UI pattern. Then, if things are hackable, all the better!

But, I may be bringing in a lot of assumptions about what a font editor should be. If this is more of hack project for you or for coders hoping to fix/tweak existing fonts than a product for a wide range of users to build new type, that is also very cool and probably a needed tool, though I probably can't offer much insight/commentary in that direction.

[ctrlcctrlv]

It's essentially a different sort of menu, yes, primarily meant to be keyboard driven and not mouse driven, but in many ways a menu. I think what I'm getting at is that I don't want right-click menus or long nested menus that require aiming the mouse and can overflow the window as drawing outside the window is not possible with the way I've chosen to go about writing this (to my knowledge).

In FontForge, for example, a common thing I do is hold down alt, press v, then u then p. That walks through the menu «View→Number Points→PostScript». In fact, I use these "alt-commands" a lot. Instead of seeing them as an anti-pattern, I guess I agree with @skef and think for Qglif I want them to be center stage and not an after-thought.

So I actually think @arrowtype when I say "Qglif won't have menus" I don't really mean that. It won't have traditional right-click or top-bar menus, but it will have a literal menu of commands you bring up with a key, and the first time it runs I can tell the user about that key. 🤔

[ctrlcctrlv]

By the way, this aversion to traditional menus might be related to my disability, a long time ago I wrote a program I called QMouseKeys to move the mouse around with the keyboard, it essentially implemented the Windows 10 "mouse keys" accessibility feature for GNU/Linux. I don't think I ever made a release but I used it on and off when I was using Linux daily, and in all programs I take advantage of the alt keys.

I don't play PC games because I have terrible hand-eye coordination; if I don't like "aiming" at menus which is something most computer users don't give a second thought, you can imagine how bad I am at Quake. 😉

[arrowtype]

Thanks for explaining this a bit further! What you are describing sounds really useful, and something I would be / will be really interested in trying out at some point.

I am definitely all for making apps 100% navigable & controllable from the keyboard, and I don’t particularly enjoy clicking through long menus. I try to avoid it wherever possible, and set up shortcuts for anything I use frequently. But, I also think that good design software makes things easy for people with cognitive differences to use (whether that is permanent or just being new, tired, forgetful, etc).

So long as the features are A) expandable and B) possible to access via presented categories rather than requiring memory / constant Googling, I think that it’ll work well.

[arrowtype]

Thanks also for explaining your specific reasons for wanting to make something command-based first, without relying on UI as much. I wasn’t aware of that aspect to the motivations around this editor, but it makes this project even more necessary and useful. A lot of my comments around wanting things to be easy to learn is motivated by the feeling that often, people who are good programmers can seem to forget what it feels like for most others to encounter technical/programmery things (i.e. intimidating). But, I am realizing that my instinct to prioritize this concern above others like physical accessibility is a limited view. An approach that could meet both objectives would be truly good design, and perhaps prioritizing physical usage here is more important precisely because it’s not as much what most apps focus on. Thanks for your patience in spelling that out a bit more, and thanks for being welcoming of commentary from myself & others on this project.

It really is a project that seems to have a lot of potential, and I hope that there it can be an editor to serve a wider range of uses & users than the current apps do!

[alerque]

A couple of thoughts in no particular order:

1. I'm 100% for keyboard driven UIs (I'm writing this GitHub comment in VIM using a keyboard driven browser). That being said I think for a tool that is for visual design work, a UI even as a second class citizen will probably be a must.

2. Don't fall for the trap of using un-intuitive keys just for the sake of getting them all an the left hand or whatever. I use a combination of Dvorak & Turkish F keyboards and there is nothing more obnoxious than key commands like "CTRL+T" for "prinT" because somebody thought it would handy to have of the left hand instead of the right. It's harder to remember and harder for me to get to. Loose loose. Going with the most memorable mnemonic keys and commands and allow users to remap from there.

3. I'm not sure a modal commands make sense, just a keyboard driven UI is probably fine (remember die hard VIM user here, I use modal editors, modal command prompt input, modal window manager controls, etc.) But there has to be a use case for multiple modes to use modal commands, so far I only see a use for one mode.

4. If you have a console, make it a real scriptable thing using Lua or Python or something and don't mess around with creating your own language, only an API that an established scripting language can use. JavaScript in the browser console would be an example to draw from, or LISP in AutoCAD (circa early 2000's), or Lua in NeoVIM (and many games).

[arrowtype]

Those seem like solid design principles for key commands / keyboard interaction.

Python may be a good choice for an interactive console ... if people are working with this as part of a modular flow, they will also likely be using FontTools, FontMake, & FontParts.world to manipulate fonts. So, if they could use the Python and perhaps the FontParts API, it would seem to be a really natural approach.

As a relative beginner at code and someone not familiar with Rust, one of my worries in this project is that I would have to learn a new language in order to work with this. But, if it used Python as an interactive layer, then presumably many more of my existing workflows could probably be ported over ... is that correct?

[skef]

If the design winds up being "mouse for spline manipulation, full keyboard for command and tool choice" the resulting system will be niche at best. That's neither beginner friendly (because a console will be alien to many users) nor expert friendly (because having to constantly move one's hand back and forth will get old very fast).

[ctrlcctrlv]

Is it hard for you guys to move your left hand to the right side of the keyboard?

This is hard because I don't use computer the normal way :-|

So if your right hand is on mouse, and you have to key in sequence (let's say) Tab-v-p to show point numbers, (Tab show command menu, v View commands, p :pointnumbers, no arguments so runs immediately), do you need to use your right hand to key p?

[skef]

In my experience touch-typists are at least strongly biased towards using the "correct" hand even in mixed mouse/keyboard scenarios. At some point it becomes slower to move one hand around the entire keyboard than to move one's dominant hand back and forth.

That said I'm the wrong guy to ask this personally because I use a Kinesis Advantage (2) which is close to impossible to use in the way you describe. (Anyone with a split keyboard would have trouble but the Advantage is at the extreme end of that trouble.)

I'm also under the impression that one-handed use of the whole keyboard involves much more l/r wrist flexion and therefore a higher risk of carpal tunnel syndrome (https://www.muirortho.com/orthopedic-blog/2013/december/preventing-wrist-injuries-from-computer-work/).

[arrowtype]

I kind of work in two main "modes":

1. Drawing / mouse mode. Here, I have my left hand mostly on the modified & number keys. My right hand moves between the mouse, the numpad, and the arrow keys. A thing I love about RoboFont is that it sets the tools to the number keys: Select is 1, Pen is 2, Slice is 3, measure is 4, Scaling Edit is 5, etc, and ` is to show a black/white glyph fill preview. I also like Glyphs, but it sucks to go between them because Glyphs uses V for select, P for Pen, etc.
2. Typing / Coding mode, for code, terminal stuff, typing spacing strings, GitHub issues, etc.

Is it hard for you guys to move your left hand to the right side of the keyboard?

Basically, yes. Not actually hard in a real sense, but inconvenient. I pretty much always have to aim for the P key, whether I hit it with my right or left hand.

[skef]

As a counterpoint there are longstanding one-hand keyboard layouts, although these tend to be used by people who (for one reason or another) don't have any choice: http://www.onehandkeyboard.org/one-hand-typing/#:~:text=One%2DHand%20Dvorak%20is%20a,is%20a%20great%20keyboard%20layout.

[ctrlcctrlv]

Thanks for the input guys, I'll try to keep key sequences on the left hand side.

I'll also consider changing the palette tools to the numbers. Right now I have P set to pen like in FontForge by default.

[arrowtype]

Ha, I just tried drawing in RoboFont to check on this, and yes, I definitely just end up moving my right hand between the mouse and keyboard a lot. I end up using it to switch between glyphs (j, then typing the glyph name), in addition to using arrow keys for nudging a lot. It’s pretty automatic for me to go between the mouse and "home row".

I have previously gotten very used to the Glyphs or FontForge-style hotkeys in the past, and just did it last week for a lettering project in Glyphs. Intellectually, I think that V & P are "correct" in that they are more familiar to people used to Illustrator, Sketch, Figma, FontForge, etc etc. But, while drawing I do prefer the number keys for frequently-used tools, and it really messes with my head to change between systems, so it would be awesome for those hotkeys to be remappable.

[skef]

I'm enthusiastic about the potential for a 2-4 layer hierarchy (think Menubar/menu/submenu) where typing one key goes down a level until a "terminal" key picks a command or tool. More commonly used stuff could be placed "shallower" in the hierarchy. Even with 8 or 9 top-level elements you still have a bunch of keys left over for one-key mappings. The potential choices in each sub-layer could be displayed in an overlay, and beginners could have the option of switching the top-level overlay on and off with a single key (or triggering it once for the initial choice). If there's a palate the overlay could display those hotkeys over the icons as well.

It doesn't take long to type a few keys (especially without control sequences). Once you got muscle memory for the more common commands this seems like it would be very efficient. A system like this seems like an expert-friendly replacement for a mouse-menu-driven architecture that's still discover-able enough for beginners (with a little encouragement). I've never encountered such a tool, however.

If you make the overall mapping configurable and have someplace to accumulate contributed mappings that more or less deals with the keyboard difference problem.

[skef]

Just to add some context to my part of this discussion:

Most design software is built the same way as other common software. You have a main working area that differs, but is surrounded by menus and other standard window decorations, with menus being the main access to "extended" functionality. Palettes were somewhat unique to the domain of design but have migrated to other areas in the form of the "ribbon" (at least in Microsoft products).

This is by far the safest route to general acceptance of a piece of software. FontForge mostly follows this template but is still frequently seen as "alien" to the extent it diverges from it. (The choices of menu positions are definitely strange -- @davelab6 is right about that.) Most users will be put off by something that isn't basically familiar; it's best not to have illusions about that.

Therefore all of my input here is relative to the vi comparison. The vi command-mode approach is a classic example of expert-friendly software. I take it that there is interest in doing something analogous in this tool. I think that's an interesting idea, and that design software could benefit from some of that kind of thinking. My main feedback is that command-mode in particular isn't well matched to the domain.

PC gaming is (strangely?) a somewhat better model, although games try to keep "commands" to a minimum. The difficulty of following that model is deciding how to extend it. I think what I'm arguing for is something like an "inverted menu" that puts keyboard priority above mouse priority. (Thinking about it that way, one could also support mouse interactions with the overlay. That's more or less how a normal menu works anyway -- it displays on top of the content. So there could at least be a mode or option for mouse selection.) Why not have a menu designed to be keyboard driven primarily with mouse driving as an afterthought, rather than the other way around?

[ctrlcctrlv]

Why not have a menu designed to be keyboard driven primarily with mouse driving as an afterthought, rather than the other way around?

Exactly, that's my thought here. 👍

Today I'm mostly working on history and the arrow tool (see https://github.com/mfeq/Qglif/issues/6#issuecomment-693689444), but I'll be implementing the overlay soon, hopefully this week. 642e30d makes it much easier.

[alerque]

Is it hard for you guys to move your left hand to the right side of the keyboard?

Yes. In fact it is virtually impossible for me. I use a split & sculpted keyboard, and the printed keycaps do not match the mapping I use. They have QWERTY keycaps, but I never use QWERTY. My respective right and left hand fingers know exactly where to find any key in both Dvorak and Turkish F, but trying to swap hands and peck out keys on the opposite side I have no idea what to press.

I'll also consider changing the palette tools to the numbers.

Please no. Numbers are even less accessible that letters. I use Programmer's Dvorak which has symbols at the top level and numbers relegated to SHIFT chord combinations. Additionally odd numbers are on my left, even on the right so any attempt at artificial "handedness" is going to fail badly for me.

Don't try to be too fancy:

1. Use the most obvious mnemonic alpha keys by default.
2. Make key shortcuts configurable.

Anything else will backfire and make the experience worse for some people.

[arrowtype]

Don't try to be too fancy: Use the most obvious mnemonic alpha keys by default. Make key shortcuts configurable.

Yes to this because it makes the system easy to learn. If I can change tool shortcuts to numbers, I'll be very happy. But, it's probably still more important to make the system learnable than to allow number shortcuts (as much as I like them).

[davelab6]

Been some twitter chats about this

https://twitter.com/davelab6/status/1391720857307856896

https://twitter.com/davelab6/status/1391768397239705600