Diskusjon om forbedring av hotkey-regime

[havremunken]

Har den siste tiden brukt det lille jeg har fått gjort med RUSK på et hotkey-regime. Dette for å ha dette klart til å få ferdig settings-UI som drar ut noe grusomt. Nok om det (her).

Nytt regime pinlig enkelt oppsummert:

Når en extmod blir initialisert, må den returnere et objekt (foreløpig kalt RUSKUI) eller null hvis den ikke har noen generelle UI-elementer den vil legge til. Akkurat nå er RUSKUI kun hotkeys. Tanken min er at denne også vil inneholde CSS modulen vil legge inn på RBKweb, samt noen andre ting som kommer snart (menyvalg i menyen til venstre f.eks.).

Det er definert en haug med nye klasser for å få hotkey-regimet til å gi mening. Et par steder er ting gjort litt klønete for å takle context-hopp mellom background og content_script. Den viktigste prosessen består i at extmod definerer sine hotkeys som en del av configSpec, spesifikt WithHotkey()-metoden på builderen. Det kan se ut sånn:

.WithHotkey(hk =>
    hk
        .WithHotkeyName('NextItem')
        .WithLabel('Hurtigtast for å gå til neste forum/tråd/innlegg osv.')
        .WithKeyCombos(['J', '.'])
        .WithPageTypes([RBKwebPageType.RBKweb_FORUM_FORUMLIST, RBKwebPageType.RBKweb_FORUM_TOPICLIST, RBKwebPageType.RBKweb_FORUM_POSTLIST])
)

I dette eksemplet er hurtigtastene enkelttaster, men de kunne da vært angitt som f.eks. "Shift J" eller "Ctrl Alt G" - en ny klasse KeyCombo sørger for at dette er noenlunde lett.

Så leverer man inn sine hotkeys til RUSK omtrent sånn:

let ui = new RUSKUI();
ui.ExtractHotkeys(cfg);

Hvor cfg selvfølgelig er ModuleConfiguration man får levert til init()-metoden.

Hotkeys i ModuleConfiguration er separat fra andre settings, men tanken er da at de skal dukke opp sammen med disse i settings UI.

Hotkeys har i tillegg til tastene page types; Dette fordi ikke nødvendigvis alle hurtigtaster skal virke på alle sider som modulen kjører på. Min nye EM_KeyboardNavigation-modul kjører på absolutt ALLE sider på RBKweb (det er noen globale hotkeys jeg gjerne vil ha), så det er greit at individuelle hotkeys kan begrenses.

Når så en hotkey trykkes av brukeren, vil den nye HotkeyManager-klassen sjekke om den har noen matchende taster. Har den det vil den kalle opp den korrekte extmod sin nye invoke-funksjon med navnet på hotkey'en som et parameter. Opprinnelig hadde jeg lyst til å ha en funksjon definert direkte på hotkey-objektet men det var dette med context da...

Etter å ha gjort greia si må invoke returnere en boolean som informerer om vi skal kjøre preventDefault på keyboard-eventet eller ikke. Dette er spesifikt gjort for å forsøke å fungere bedre sammen med QuickReply-modulen. Konkret eksempel: j / k for å navigere til forrige/neste melding i lista, så Shift+R for en quickreply. Focus er nå på contenteditable, og hvis jeg vil skrive "juks!" er det fint om vi ikke ender opp med kun "us!" - så KeyNav-modulen sjekker om contenteditable har fokus for en del av hotkeyene inne i invoke. Dette er også grunnen til at invoke får være med på å bestemme preventDefault og føles meget skittent. Her er jeg helt sikker på at det er mulig å gjøre det på en mer fornuftig måte, men nå er det langt på overtid å få dette over til github.

Selv om dette blir sjekket inn på master nå, anser jeg det ikke for klart til å slippes løs på brukere helt ennå - det funker greit nok hos meg, men det er så mange endringer at jeg ikke er helt trygg. Det er ikke alle hotkeys som er flyttet over til nytt regime ennå, det skal jeg se på etterhvert - f.eks. EnhancePosting har jeg ikke tatt ennå, eller Ctrl-Enter i QuickReply.

Men det jeg veldig gjerne vil ha er et ekstra sett med øyne på dette regimet, sånn at vi kan luke ut en del brain farts som jeg utvilsomt har laget. :)