feat: F6 Move functionaliteit aangepast
This commit is contained in:
kodi
@@ -0,0 +1,189 @@
|
||||
# UI_F6_PURE_MOVE_V1
|
||||
|
||||
## 1. Doel
|
||||
|
||||
`F6` moet in de UI een expliciete pure `Move`-actie worden.
|
||||
|
||||
Waarom:
|
||||
- `F2` heeft nu een eigen rename-flow
|
||||
- daarmee is de oorspronkelijke gecombineerde `Rename/Move`-semantiek in de UI niet meer nodig
|
||||
- een pure `Move`-flow maakt de functietoetsen voorspelbaarder:
|
||||
- `F2 = Rename`
|
||||
- `F6 = Move`
|
||||
- dit sluit beter aan op klassieke file-manager verwachtingen en vermindert cognitieve ruis in de popup-flow
|
||||
|
||||
Belangrijk bestaande context:
|
||||
- move-functionaliteit bestaat backendmatig al
|
||||
- move-functionaliteit bestaat UI-matig al
|
||||
- file move, directory move binnen huidige scope en batch move binnen huidige scope werken al
|
||||
- deze stap gaat dus niet over nieuwe move-capaciteit, maar over het vereenvoudigen van de UI-flow rond de bestaande move-actie
|
||||
|
||||
## 2. Scope
|
||||
|
||||
De pure `Move`-flow in v1 moet de bestaande move-scope UI-matig netjes afdekken voor zover die al ondersteund wordt.
|
||||
|
||||
In scope:
|
||||
- exact 1 file
|
||||
- exact 1 directory
|
||||
- meerdere files
|
||||
- meerdere directories
|
||||
- gemengde selectie van files + directories
|
||||
|
||||
Voorwaarde:
|
||||
- alleen binnen de bestaande huidige move-scope
|
||||
- alles wat backendmatig al geblokkeerd is, blijft geblokkeerd
|
||||
- de UI mag dat duidelijker presenteren, maar mag de scope niet verbreden
|
||||
|
||||
Niet in scope:
|
||||
- nieuwe backend move-capaciteit
|
||||
- nieuwe tasksemantiek
|
||||
- nieuwe batch-semantieken buiten de bestaande backend
|
||||
- rename binnen `F6`
|
||||
|
||||
## 3. Gewenst gedrag
|
||||
|
||||
`F6` en de `Move`-knop moeten exact dezelfde frontendflow gebruiken.
|
||||
|
||||
Kernregel:
|
||||
- `F6` keyboard shortcut = pure move-flow
|
||||
- `Move`-knop in functiebalk = exact dezelfde pure move-flow
|
||||
- beide gebruiken dezelfde centrale frontendhandler
|
||||
|
||||
Popupregel:
|
||||
- de bestaande move-popup wordt een pure move-popup
|
||||
- geen rename-invoerveld in deze flow
|
||||
- geen naamwijzigingssemantiek in deze flow
|
||||
- de popup richt zich alleen op doelpad of doelmap voor verplaatsen
|
||||
|
||||
Interactie:
|
||||
- `Enter` bevestigt
|
||||
- `Escape` annuleert
|
||||
- `X` sluit popup
|
||||
|
||||
Gedragslijn per context:
|
||||
- exact 1 item: popup toont expliciete move-context voor dat item
|
||||
- meerdere items: popup toont batch move-context
|
||||
- popuptekst en labels moeten spreken in termen van `Move`, niet `Rename/Move`
|
||||
|
||||
## 4. Relatie met bestaande move-scope
|
||||
|
||||
Wat al bestaat en alleen hergebruikt moet worden:
|
||||
- single file move
|
||||
- single directory move binnen de huidige scope
|
||||
- batch move binnen de huidige scope
|
||||
- task-based move
|
||||
- bestaande validaties en blokkades
|
||||
|
||||
Dat betekent:
|
||||
- de pure `Move`-popup hoeft geen nieuwe backendbeslissingen te nemen
|
||||
- de frontend mag alleen een duidelijkere presentatie en dispatchlaag geven
|
||||
- validatiefouten zoals cross-root blokkades, subtree-blokkades, mixed-root blokkades en bestaande destination-conflicten blijven door de bestaande backend en bestaande UI-validatie worden afgevangen
|
||||
|
||||
Pragmatische consequentie:
|
||||
- de move-popup moet vooral destination-gericht zijn
|
||||
- submit moet direct de bestaande move-logica aanroepen
|
||||
- geen impliciete keuze meer tussen rename en move in deze flow
|
||||
|
||||
## 5. Relatie met F2 Rename
|
||||
|
||||
Na invoering van pure `F6 Move` geldt:
|
||||
- `F2` blijft exclusief voor rename
|
||||
- `Rename`-knop blijft exclusief voor rename
|
||||
- `F6` wordt exclusief voor move
|
||||
- `Move`-knop wordt exclusief voor move
|
||||
|
||||
Belangrijk ontwerpprincipe:
|
||||
- geen gedeelde rename/move-popup meer
|
||||
- `F2` en `F6` krijgen elk een eigen, semantisch heldere popupflow
|
||||
- dit maakt toekomstige onderhoud en UX-consistentie eenvoudiger
|
||||
|
||||
## 6. UI-semantiek
|
||||
|
||||
### Welke contextinformatie is nuttig
|
||||
|
||||
Voor een pure move-popup is nuttig:
|
||||
- broninformatie: welk item of hoeveel items geselecteerd zijn
|
||||
- destination-informatie: waarheen wordt verplaatst
|
||||
- bij batch move: doelmap in plaats van volledig doelpad per item
|
||||
|
||||
### Default destination
|
||||
|
||||
Aanbevolen defaultvoorstel:
|
||||
- gebruik het current path van het inactieve paneel als destination-basis
|
||||
|
||||
Voor exact 1 item:
|
||||
- toon een destination pad of destination map duidelijk, afhankelijk van de bestaande implementatierichting
|
||||
- aanbevolen: toon volledig destination path, vooraf ingevuld op basis van het inactieve paneel + itemnaam
|
||||
- dit houdt aan bij de bestaande move-aanroepsemantiek voor single-item move
|
||||
|
||||
Voor batch move:
|
||||
- toon aantal geselecteerde items
|
||||
- toon doelmap = current path van het inactieve paneel
|
||||
- geen rename-achtige tekst of naamveld per item
|
||||
|
||||
### Foutmeldingen en blokkades
|
||||
|
||||
Compact tonen in de popup of bestaande errorzone:
|
||||
- destination exists
|
||||
- mixed roots not allowed
|
||||
- destination inside source not allowed
|
||||
- cross-root directory move not supported
|
||||
- andere bestaande backendfouten
|
||||
|
||||
Belangrijk:
|
||||
- foutmeldingen moeten move-gericht geformuleerd zijn
|
||||
- geen verwijzing naar rename of gecombineerde semantiek
|
||||
|
||||
## 7. Regressierisico
|
||||
|
||||
Belangrijkste risico's:
|
||||
- per ongeluk opnieuw bouwen van bestaande move-functionaliteit in plaats van die te hergebruiken
|
||||
- verwarring tussen oude gecombineerde popup en nieuwe pure move-popup
|
||||
- inconsistente keyboard- en knopwiring tussen `F6` en `Move`
|
||||
- onbedoelde impact op de al werkende `F2 Rename`-flow
|
||||
|
||||
Mitigatie:
|
||||
- `F6` en `Move` één centrale pure move-handler laten delen
|
||||
- bestaande backend move-calls intact laten
|
||||
- `F2` volledig gescheiden houden
|
||||
- popup-tekst en labels expliciet move-only maken
|
||||
- geen backendwijzigingen in deze stap
|
||||
|
||||
## 8. Teststrategie
|
||||
|
||||
UI smoke/regressietests:
|
||||
- functiebalk bevat `Move` met `F6`
|
||||
- `F6` wiring blijft aanwezig
|
||||
- `Move`-knop gebruikt dezelfde handler als `F6`
|
||||
- move-popupcontainer aanwezig en move-only geëtiketteerd
|
||||
- rename-popup blijft apart aanwezig voor `F2`
|
||||
|
||||
Handmatige validatie:
|
||||
- exact 1 file -> `F6` opent pure move-popup
|
||||
- exact 1 directory -> `F6` opent pure move-popup binnen huidige scope
|
||||
- meerdere files -> batch move-popup blijft logisch werken
|
||||
- meerdere directories -> batch move-popup blijft logisch werken binnen huidige scope
|
||||
- gemengde selectie -> bestaande batch move-scope en blokkades blijven correct
|
||||
- `F2 Rename` blijft volledig los en ongewijzigd
|
||||
|
||||
Bestaande regressies die bewaakt moeten blijven:
|
||||
- single file move same-root
|
||||
- single file move cross-root
|
||||
- single directory move binnen huidige scope
|
||||
- batch move file-only
|
||||
- batch move met directories binnen huidige scope
|
||||
- blokkades voor mixed roots, subtree en symlink source
|
||||
|
||||
## 9. Aanbeveling
|
||||
|
||||
Aanbevolen v1-richting met laag regressierisico:
|
||||
- maak `F6` en `Move` UI-semantisch puur move-only
|
||||
- verwijder rename-semantiek uit de `F6`-popupflow
|
||||
- behoud en hergebruik alle bestaande move-logica, validaties en backendcalls
|
||||
- houd `F2 Rename` volledig apart
|
||||
|
||||
Waarom dit de veiligste richting is:
|
||||
- maximale herbruik van bestaande backend en UI-logica
|
||||
- minimale semantische overlap tussen `Rename` en `Move`
|
||||
- duidelijkere functietoetsbetekenis
|
||||
- laag regressierisico omdat de verandering vooral UI-opschoning is, geen capability-uitbreiding
|
||||
Reference in New Issue
Block a user