How should we implement dictionary order changing through strokes?

[Ted Morin]

Hi everyone,

Achim and Mirabai at the Plover Aviary brought up two features that I'm currently weighing for implementation.

Here are the features in user story format:

• As a stenographer who types in multiple domains, I'd like to be able to switch dictionaries using only strokes so that I don't have to use the GUI.
• As a stenographer who is building a dictionary, I want to be able to disable specific dictionaries so that it's easier to tell when a stroke isn't defined in my new dictionary.

Are these viable features? How might you use them? What's more important to you: enabling and disabling dictionaries, or switching their order?

I won't go into how I have thought of how to solve this issue -- I'll let everyone brainstorm. I wouldn't shoot down any ideas at this point, let's just flesh this out. If possible, it might be good to include what kind of user you are and why the feature in question would be useful to you.

For example: I use Plover on Windows and Mac -- I'd like my Eclipse-specific commands to change as I change OS, and switching dictionaries on the fly would help me with that.

Thanks,

Ted

[Achim Siebert]

How about a {PLOVER:Remove_Dict"path/to/the/dict.json"} and {PLOVER:Add_Dict "path/to/newdict.json"}? Both are already available, but only from the GUI.

Both use cases could be handled by this, assuming that adding a dictionary puts it in the "first", i.e. highest priority, position. So to switch two dictionaries, you remove them and then add them again with the new order. If those commands would allow for more than one path in the definition, it could even be done in two strokes (or even just one if there were something like {PLOVER:Switch_Dicts"path/to/the/olddict.json""path/to/newdict.json"}).

Since this would be a feature for advanced users, it would even be feasible to allow for a more complex definition as {PLOVER:ADDREMOVEDICTS ["list of", "paths for dicts", "to remove"]:["list of paths of", "dicts to add"]}, where again the last dictionary added will be the one with highest priority. This would allow for all cases that come to mind (empty lists must be allowed of course for just adding or just removing dictionaries). Requiring Python style lists might make parsing easier.

All this could make use of existing code for adding and removing dictionaries. I'd probably just ignore invalid paths - the user can check if his entry works as expected by looking at the Plover config window after stroking it. And just do nothing if there's a syntax error.

If possible, it would be nice to change the mouse cursor to the spinning wheel while all this removing and loading is going on - or some other visual feedback so we see when Plover is ready again.

Best, Achim.

[Di]

Hi Ted,

To add to your first story, as a programmer, I want to declare collections of dictionaries, so I can quickly switch between stacks, not just individual dictionaries. 

For example, at work I use a rails stack (eg, ruby, haml, postgres), and at home, a python stack. Equivalent concepts are stroked in the same way across languages. If I'm working from home, I'd like to easily switch between the two stacks.

I would prefer to manage these as "profiles" where "work profile" contains a list of rails dictionaries, and "home profile" contains python dictionaries, and both profiles include shared dictionaries, such as for navigation and command line tools. I would then add briefs for switching to each profile. 

I also sync my dictionaries across devices with Dropbox, so if I updated a profile on one device, it would be excellent for it to load up correctly on another. 

Enabling and disabling dictionaries feels more useful to me, but enabling and disabling a defined profile could capture ordering as well. 

In an ideal world, Plover would be context aware and switch dictionaries based on apps (or even syntax of the current file) or let you define briefs for specific apps. Maybe one day?

-Di

[Hantuchblau]

Hey everyone,

I almost feel like certain predefined setups are more generally useful than micromanaging which ones are activated. Otherwise you get problems where you need to take care of the current active ones before doing your actual selection which'd make automation more difficult.

It does mean that you might get significantly more stroke combination depending on how many setups you want. I generally'd use English + Commands as default, English + Language Specific Stuff + Commands for programming, possibly some special case stuff for things like normal mode vim and Other Language + Commands or Other Language + English + Commands if I ever get around to trying that out.

Ideally there would be some sort of ipc interface to automatically switch everything applicable for you, like changing programs, modes or files. A special stroke that forces something like 'next word is from dictionary x' would be very cool as well but I am not sure about the edge cases that might cause.

Anyway, quick and dirty version is actually super easy. ~10 lines of code -  I also changed the DictionaryLoadingManager around slightly so that it keeps currently unused dictionaries cached so changes are basically instant after the dictionaries are loaded for the first time.

2015-10-26 13:12:42,243 INFO: Stroke(H- T-)
2015-10-26 13:12:42,246 INFO: Translation((u'TH',) : this)
2015-10-26 13:12:47,595 INFO: Stroke(* -B -U -G -E -T K- T-)
2015-10-26 13:12:47,595 INFO: Translation((u'TK*EUBGT',) : {PLOVER:CHANGE_DICT commands.json})
2015-10-26 13:12:48,651 INFO: Stroke(H- T-)
2015-10-26 13:12:48,651 INFO: Translation((u'TH',) : None)
2015-10-26 13:12:52,051 INFO: Stroke(* -B -U -G -E -T K- T- -D)
2015-10-26 13:12:52,052 INFO: Translation((u'TK*EUBGTD',) : {PLOVER:CHANGE_DICT commands.json main.json})
2015-10-26 13:12:53,089 INFO: Stroke(H- T-)
2015-10-26 13:12:53,092 INFO: Translation((u'TH',) : this)

Doesn't do anything like updating the UI yet, though. An 'make default' button probably would be a good idea as well.

[Theodore Morin]

How would you guys feel about changing the ordering of the Plover dictionaries? As in, when you add a dictionary to Plover, instead of it going to the bottom of the list, it goes to the top, and strokes in your top dictionary override strokes from your bottom dictionaries?

This fits my mental model better. We could even add numbering to make it clear which dictionary is more "important". The main disadvantage of this change would be that any old discussions around the Google Group and friends would be no longer true.

I'm also curious if there was a reason that dictionaries were ordered that way in the first place.

--
You received this message because you are subscribed to the Google Groups "Plover" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ploversteno...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mirabai Knight]

I'm fine with this. I don't believe there was any particular reason for the bottom-most dictionary to have priority. Pretty sure it was just an arbitrary choice.

--

Mirabai Knight, CCP, RDR
StenoKnight CART Services
917 576 4989
m...@stenoknight.com
http://stenoknight.com

[Theodore Morin]

Hantuchblau, I had a similar inclination.

My idea was to do two meta commands: "PLOVER:DICT_TOP", "PLOVER:DICT_BOTTOM", and in each one you could give a list of dictionaries that, in that order, would find themselves on the top/bottom of your list. So in my case I was never "disabling" dictionaries, but just shuffling them around.

E.g. "{PLOVER:DICT_TOP:user.json;mydicts/python.json;mirabaisdicts/python.json}"

Also shows how you could use some paths in the case of having two "python.json"s.

My hesitation with disabled dictionaries comes from the representation in the user interface, but it can be done...

[Di]

Odd, I find the current ordering fits my mental model better than your suggested. I wonder if that means a heading indicating the model/ordering would be useful (even with numbering), eg:

Dictionary priority

1. important-personalised-dict.json

2. general-dict.json

3. original-dict.json

vs

Dictionary overrides

1. original-dict.json

2. general-dict.json

3. important-personalised-dict.json

Anyway, how would you implement that? As a cosmetic change in how you display the list? That is, if I grab the latest Plover and the order of my dictionaries has appeared to change and now has numbering, would my dictionaries behave exactly as before without me needing to swap them all around? If there are no breaking changes, then I think new, clearly indicated ordering could address any confusion from new users reading old discussions.

[Glen Warner]

Nobody asked me, but whichever way you go, I think there should be a way for the user to be able to select a given order of their choice.

Most of the CAT software I've used are set up the way Plover is now when it comes to dictionary management, so I'm used to doing it that way. I don't mind a change in how that's done, as long as I have the choice to either go with the new way, or stick with the old way, if that makes sense.

--gdw

[Achim Siebert]

If other CAT software does it like Plover does now, then I think we should leave it as is, i.e. have the lowermost dictionary take precedence, and newly created entries go to that one. It's something you can get used to, and IMHO Plover should not stray too far from other steno software so that people coming from those don't have too steep a learning curve.

As Di said already: it's mostly a matter of the way the dictionary list is being displayed.

To make things clearer, we could simply let the dictionary with highest priority have some sort of highlighting, e.g. just a different color.

Best, Achim.

[Theodore Morin]

In most cases I'm not a fan of offering more options rather than the "right" options, but I think this is a clear exception.

This is only a user interface change, so I could probably implement it such that it's easy to switch between the two and it looks something like what Di proposed. Tonight when I'm off work I'll make a quick wire frame and you can let me know what you think.

[Theodore Morin]

Okay... took some big decisions while making this... how would you think this compares to the current dictionary tab?

Added enabled flag, bolded default dictionary, and show disabled by italics (would probably just gray it out slightly in real life).

Movement buttons are now by which dictionary is selected (dictionaries are displayed in a grid and can hold focus).

What would you do?

[Glen Warner]

Hi, Ted.

If I understand what I'm seeing there with the dictionaries, I'm curious as to whether or not the Stroke Suggestion window would display entries from the de-selected dictionaries.

That would come in handy if you have the dictionary for the theory you learned as your main dictionary, and, say, the Magnum Steno theory dictionary in the list but not selected, so that you could glean suggestions from it, which you can then add to your own dictionary.

Hope that makes sense ... there's not a lot of caffeine in this ice cream!

--gdw

[Di]

That would certainly make moving dictionaries up and down easier! 

The trash can suggests that you are deleting the dictionary file, rather than removing from the list, which is possibly why it is a minus currently. The "Add dictionary" button could be a plus sign in the same group. 

What do dictionary editor and quick lookup do there?

I still find the interface a little unclear in indicating the order of dictionaries. If you said the list was ordered by date with the default bolded, I still wouldn't know if the bolded item was oldest or newest. Wording might help like "preference", "highest priority", or "lookup order" to differentiate from the functional way it's currently sorted, which is more like cascade, overrides, or loading order. 

[Achim Siebert]

This is a great layout! I think the order of precedence and the default dictionary are presented much better than before.

But I agree with Di in that the trashcan icon might lead to confusion - better have a (-) icon there (or a row on the right of the table with minus icons for each dictionary). Find a suggestion below.

How would a selected dictionary look like? As it looks now, one might assume that both main.json and custom.json are selected because of the gray background.

[Theodore Morin]

I like the plus and minus buttons, but I'd have to make sure to provide hover text to describe what they do.

For the currently selected dictionary: Maybe we could use radio buttons to the left of the list? The alternative is me trying to make this into a grid, at which point the selected row would be blue, think Excel.

Di, dictionary editor is a GUI tool made by Mike that lets you view and edit all your dictionaries without any exposure to JSON or RTF. It's quite nice. Lets you filter by stroke and definition, also shows all dictionaries' entries, and lets you edit them in the spot. It still requires a little work, because you can't move a stroke from dictionary to dictionary, but I don't think that that will be too hard to do.

The lookup tool is just a box you type into that provides a list of all strokes matching that stroke. It's kind of like typing in the translation field of the "Add Translation" dialogue, except that the lookup tool is not limited in the space that it can display strokes.

[Hantuchblau]

 Quite like that layout!

Is there a functional difference between disabling a dictionary and removing it from the list or is that just a nicer way to toggle quickly?

[Theodore Morin]

Yeah, the idea is that you could quickly enable and disable dictionaries with strokes, too, in case that's your thing.

On Oct 28, 2015 6:34 PM, "Hantuchblau" <fahlenbo...@gmail.com> wrote:

 Quite like that layout!

Is there a functional difference between disabling a dictionary and removing it from the list or is that just a nicer way to toggle quickly?

[Hantuchblau]

Would it make sense to do away with adding/removing dictionaries completely, then, and just add all .json and .rtf file that lie under the config dir?

Anyway,  never really thought about this but I generally always would use the same order with activating/deactivating the ones not needed. Might be tricky when using two language dictionaries at the same time, though?

[Mirabai Knight]

A lot of people like to keep their dictionaries on a flash drive or in a Dropbox folder, so I don't think we should require them to be placed in the config directory.

On Oct 29, 2015 4:09 AM, "Hantuchblau" <fahlenbo...@gmail.com> wrote:

Would it make sense to do away with adding/removing dictionaries completely, then, and just add all .json and .rtf file that lie under the config dir?

Anyway,  never really thought about this but I generally always would use the same order with activating/deactivating the ones not needed. Might be tricky when using two language dictionaries at the same time, though?

--

[Achim Siebert]

I agree – I'm loading my dictionaries from iCloud so that they stay synced whether I'm at work or at home. Requiring to have links in the config directory wouldn't be really user friendly.

Best, Achim.

[Di]

Wow, looking forward to being able to use all these!

[Di]

Ditto, I have dictionaries split across folders too.

[Karl Hegbloom]

I have a fork of 'autokey' in my github repository, and I've begun reading it's source. It lets you define keyboard macros that can either execute Python programs or insert a phrase. For example, if I enter :jd it expands to Judge: or kh@gm it expands to karl.h...@gmail.com, and :isodate execute a Python script that inserts the ISO-8601 date. It has a nice configuration window, and minimizes to the system tray.

The configuration window lets you add new phrases and scripts, and to bind them to menu items from the system tray icon's drop down menu, or to keyboard keystrokes. Perhaps a new configuration tab could be added to Plover that allows the definition of Python scripts in a similar fashion, and then a syntax defined for the Plover dictionary right-hand-side that can call one of those scripts? Inside a script, it can import any Python modules you need, and then do whatever you want. So for dictionary switching, you'd import that module and call on it's published API functions to do what you need.

I think that the script is wrapped by an implicit "main()". I don't know what it's inputs are, if any... Thing at point? But that implies something like an input method extension (IME) as in Android or ibus, that can be made aware of the contents of the edit buffer. Plover as it sits does not have that capacity. ie, if you move the cursor to the previous or next paragraph, Plover presently can not see the text around `point' (using Emacs parlance, as in "thingatpt.el".) Ibus and Android IME have the capability to be context-aware. That's how the Google Voice typing IME can underline phrases and let you pick a choice from a drop-down.

I like the "minimize to system tray" thing for Plover, as a configurable option.

I like the ibus context awareness and possibility for a dynamic stroke-suggestions pop-up. To see what that's like, install ibus-table and the ibus-table-compose or ibus-table-latex input methods, add them, and try them out. You can set your IM to "compose" then type << and >> to get guillimotes, or to LaTeX and type \Sigma to get an uppercase greek sigma. After you press the \ key and the first letter after it, a pop-up menu is displayed that narrows as you continue to type, showing possible completions. Ibus-table is also used for some chinese input methods, including pinyin... and looking at the internals of it is very interesting wrt comparison with Plover. I think that a subclass of ibus-table would be doable as a Stenographic input method.

Ibus-table has a utility program run during the build process that turns a specially-headered text file into a database that is used at runtime for the dictionary table lookups during input. It also has provision for adding new entries, offering multiple choices that match given input with a quick means of selecting an item, the items are ordered by use frequency, and pushing the input accept key (usually spacebar or enter) selects the default or top item. It also supports a configuration interface that's worth a look at.

I wish I had full-time to dedicate to this. It is very interesting to me... however, I'm presently embroiled in a set of lawsuits (child custody and civil rights complaints), and have to stop myself from spending too much time escaping from those stresses by digging into Plover, ibus, autokey, TeXmacs, and Juris-M. With any luck, I'll win some money with the settlement, and then I'll be able to take much more time and allocate it to the things I'd rather be doing than trying to be my own lawyer and law firm.

[Karl Hegbloom]

PS: autokey also has the ability to enable certain keystroke expansions only in certain windows on the desktop, using "window filters". For example, when I click on "Set" for window filter, I get a dialog with a blank for a regexp, and a button for detect window properties. Entire subsets of phrases or scripts can be set to be active only for certain windows...

When I type things in TeXmacs, or in whatever editor entering LaTeX, perhaps I'd want some things to be transformed differently upon entry; escaping certain spaces, like after the period of an abbreviation, but not after the period at the end of a sentence... and movement and editting command sets could change depending on whether the specific application uses Emacs, vi, or CUA style keybindings.

For each item in autokey, you can set abbrevs, a hot-key, and a window filter.

[Karl Hegbloom]

There needs to be a brief explanation of what the ordering or stacking means right there next to where you configure it. That way, the old discussions are still valid, in terms of what it means to have one dictionary shadow or override entries from another, and it will be clear what the ordering or stacking shown in the GUI means.

I like the one on top to shadow or override the ones below, like a stack.