Targets screen

[mondalaci]

Add a new Targets screen in the side menu below the LED Settings menu item.

Read targets according to UltimateHackingKeyboard/firmware#867 and render them according to the following mockup:

• Make the default user configuration only contain the right USB target in its first element, make its name "USB right", and make the rest of the elements empty.
• Make targets reorderable.
• Don't show empty targets.
• When hovering over a name column, make the cursor pointer style, and when clicking on it, make it a text input to be renamed. Enter confirms the name, and esc cancels renaming and restores the previous name.

[mhantsch]

I read through this and linked issues but I totally do not understand what you mean with Targets or what they should be used for. From an end user standpoint, I don't get it. Maybe 'Targets' is not a good phrase? I always think a UI should be as self-explanatory as possible. If I need to read up info in a manual, then the UI design or the phrasology wasn't good enough.

Why is the list orderable? What effect would this have? etc.

Maybe a better name would be "Connections"?

[mondalaci]

I can vaguely remember thinking about the "target" terminology. I considered "connection", but I think I came up with "target" because I felt that the left and right USB ports were not connections but targets to connect to. But "connection" is probably a better word. Should we use it, or do you have a better suggestion?

The order of connections is significant because:

• Upon bootup, the UHK will connect to the topmost (highest priority) connection.
• Agent will offer "switch to previous/next connection" actions, and the previous/next connection will be relative to the current connection according to the order of the connections.

[kareltucek]

I feel good about "target".
I feel confused about "connection".

I think "host" could also be good.

[mondalaci]

Target is more sensible when using the terminology of "switching to the next target" rather than "switching to the next connection." The latter is incorrect because the referenced "connection" doesn't exist; it must be established with the next target.

When I came up with the terminology, I had difficulty finding the best word, and I'm still unsure.

[mhantsch]

Let me sleep over this for a day or two. Now I understand better what the purpose is. It's the list of connections that this UHK shall remember to be able to switch to and from.

[mhantsch]

The difficulty I had was that within the Agent interface, you could read "target" (and maybe "connection" too) as the target device that this Agent should talk to (esp. when you have multiple UHKs connected. Imagine you have two UHKs with two Dongles plugged in plus maybe one USB connection to one of those UHKs. What is "target" now referring to?

I'll have a think.

[mhantsch]

And BTW, if you want to mark one of them as the default that should be used upon boot, then the UI should also use the same way as you do for keymaps.

So either the keymaps are also an orderable list and the first one is the default keymap. Then you should also offer switchKeymap next and switchKeymap previous commands.

Or the Targets/Connections/Ports list has a way to mark the default one, and it can be anywhere in the list, and it would get an asterisk or some mark to indicate it's the bootup default.

BTW, will it remember what it was connected to last, and try to restart that connection first? Would that then reorder the list automatically? Or move the "default mark"?

[mondalaci]

I wouldn't compare targets to keymaps when it comes to defaults. Keymaps are always available, and the default is always accessible. However, it may just happen that the first target is unavailable, and so is the second, so the third gets connected. Or none at all.

The firmware will not remember the last target, just as it doesn't remember the last keymap or any last setting. We'd have to dedicate a flash region and implement wear-leveling, which is not feasible due to the limited EEPROM of the UHK 60.

[mhantsch]

I see your point about remembering the last target. Yes, I understand you don't want to store it.
Side note: I'm surprised the flash controller doesn't do wear leveling.

[mhantsch]

My current thinking is to call the page Host connections (instead of Targets). Only one of them (or none) would be active at a time; maybe in the future Agent could visualise which one is currently active. (This of course needs Agent to be able to communicate via Dongle and Bluetooth, too.)

[mondalaci]

"Host connections" is quite a mouthful. I'm not sure if it's an improvement.

[kareltucek]

Why not simply "hosts"? I see that it is semantically imprecise, but sounds quite intuitive to me...

[mondalaci]

I'm fine with hosts. I also considered endpoints when brainstorming back in the day, but it's probably too vague and technical.

[kareltucek]

I find endpoints clear, but indeed a bit too technical.

[mhantsch]

Why not simply "hosts"? I see that it is semantically imprecise, but sounds quite intuitive to me...

You can reach the same host (PC) via different connections (USB, Dongle, Bluetooth..), and you can also reach more than one host. Thus, "Host connections". I don't think two words is a mouthful.

[mondalaci]

I can see why "targets" is not a great choice, as it's not very intuitive and rather abstract.

"Host connections" is a precise term, although a host would seldom be reached via multiple connections in practice.

Even though I find the suggested "connections" a bit imprecise, as I elaborated above, it's still the best word I can think of, and it's certainly not a mouthful. How about using "connections"?

[mhantsch]

"Host connections" is a precise term, although a host would seldom be reached via multiple connections in practice.

I disagree. I connect to my Laptop via a USB hub while I've got it docked at my desk; but while I am on the move I would use Bluetooth. Same host, two different connections.

How about using "connections"?

I'm good with that.