Keyboard shortcuts and easier URL selection

[adam3smith]

Coming out of #76 two suggestions to reduce clicking around:

1. Assign keyboard shortcuts to doWeb doDetect and (not mentioned in that thread but IMO also useful) save

2. Allow for easier opening of test URLs in browser (to prevent the cumbersome "select URL in test, copy to browser" steps.) I could see an elegant being just a dropdown on the right of the URL bar in the browser tab making all test URLs accessible, but there are obviously other ways of doing the same.

[zuphilip]

To 1: We can add the parameter accesskey to the toolbar buttons, e.g. in

scaffold/src/chrome/content/scaffold/scaffold.xul

Line 73 in 594ea06

<toolbarbutton id="tb-doWeb" tooltiptext="&scaffold.toolbar.doWeb.label;" oncommand="Scaffold.run('doWeb')" />

add accesskey="R" which then can be invoked by pressing Alt+R on my Windows machine. Would that be the way to go?

We could use:

• Alt+R for "Run doWeb"
• Alt+D for "Run detectWeb"
• Alt+S for "Save"

However, this then only focus on the web translators and let the e.g. import translators not supported by keyboard shortcuts. Is that okay?

After playing around a little with such keyboard shortcuts my impression is that I will click the buttons again, because that as fast as pressing two keys and easier to memorize.

To 2: That is an interesting idea with the dropdown. We will have to look what is (easily) possible to implement.

[dstillman]

No, we don't want Alt. We can use <key> with accel, which will use Ctrl or Cmd as appropriate for the platform. The key can invoke a given <command>, which can also be called by a <menuitem> that communicates the key. (We'll need something else post-XUL, but a JS-based option would have to change anyway, so might as well just use what's easy.) See standalone.xul for an example of keys, commands, and menu items together.

[dstillman]

However, this then only focus on the web translators and let the e.g. import translators not supported by keyboard shortcuts. Is that okay?

I forget — do we have translators that are both import and web? If not, it could just be context dependent. Or even if we do have some with both, it could still prioritize *Web if they exist and otherwise run *Import.

[zuphilip]

Okay, that seems to work. Now, I see that CTRL+D is used in ACE for deleting a line. How about CTRL+T for deTection?

No, there are currently no import+web translators, see grep '"translatorType": 5' *.js. Prioritizing should work.

[dstillman]

How about CTRL+T for deTection?

Fine with me.

[zuphilip]

I have a almost finished solution for the second point with an editable menulist:

However, during browsing we need to update the browser url, which does not work anymore:

scaffold/src/chrome/content/scaffold/scaffold.js

Line 1137 in 594ea06

document.querySelectorAll("textbox.browser-url").forEach(elem => elem.value = doc.location.href);

My guess is that value is different here, but also label does not work. Any ideas how to fix this?

[dstillman]

Can I see it on a branch?

[zuphilip]

Sure, see #79.

[dstillman]

Oh, it's just that it's using textbox.browser-url for the selector, but it's no longer a textbox — it's now a menulist. Changing it to just .browser-url would work.

[zuphilip]

Yes! Thank you! Now the PR is updated and ready.

(I tried similar things before, but with setAttribute...)

[zuphilip]

@adam3smith Both points here are now implemented and I build a new beta release for you:

scaffold-beta-2018-03-13.xpi.TXT (You have to delete the TXT file ending again.)

Can we close this issue?

I opened another issue #80 for copying to clipboard resp. (real) browser.

[zuphilip]

Everything from this issue should be implemented in v3.3.2.