-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add console #4
Comments
@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 :-) 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: I want to ask people what they think about this. I plan to have Furthermore, I'm going to add a
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. |
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. |
I like the idea of multi key commands, but what about arguments? |
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). |
Yes, they aren't currently labeled but the four tools are selectable with equal default hotkeys as the ones in FontForge. |
My first reaction is that this sounds really cool, but also rings the alarm bells in my designer brain. A high-level question:
And two low-level questions:
|
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. |
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 |
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. |
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. |
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. 🤔 |
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. 😉 |
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. |
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! |
A couple of thoughts in no particular order:
|
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? |
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). |
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 |
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/). |
I kind of work in two main "modes":
Basically, yes. Not actually hard in a real sense, but inconvenient. I pretty much always have to aim for the |
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. |
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 |
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 ( 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. |
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. If you make the overall mapping configurable and have someplace to accumulate contributed mappings that more or less deals with the keyboard difference problem. |
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. |
Exactly, that's my thought here. 👍 Today I'm mostly working on history and the arrow tool (see #6 (comment)), but I'll be implementing the overlay soon, hopefully this week. 642e30d makes it much easier. |
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.
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:
Anything else will backfire and make the experience worse for some people. |
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). |
Been some twitter chats about this |
@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.
The text was updated successfully, but these errors were encountered: