Tag: Branch: Tree: 5ec61ba1c9

wilder

wilder-5.14

wilder-5.17

wilder-5.18

wilder-5.19

wilder-5.22

wilder-5.24

wilder-5.25

wilder-5.26

wilder-5.26-rebase

wilder-broken-krunner

wilder-portage

wilder-portage-prov

Branches Tags

${ item.name }

Create tag ${ searchTerm }

Create branch ${ searchTerm }

from '5ec61ba1c9'

${ noResults }

Commit Graph

1 Commits (5ec61ba1c9a4e656ae320e0bbc19e1f13c46239a)

Author	SHA1	Message	Date
Harald Sitter	0043576005	refactor translations system into a single model ... in the hopes of increasing code clarity. previously we had three distinct models. the model of languages, the subset model of available languages (!selected), and the inverse model of selected languages (!available). this does make a lot of sense conceptually but also complicated the code a whole lot because data needs to be shuffled and shared between the three models. this lead to partial duplication in the data() function, as well as the need for excess book keeping of the lists. the new design takes a different approach: there is a single model of all translations now. in the UI it gets filtered into the visual incarnations: available and selected - these simply sort and filter as necessary. the actual languages are now objects to encapsulate their newly found statefulness with the new languagecompleter tech. this also allows us to move the actual mutation logic into the language itself. to on-demand complete a language by installing missing packages one now calls complete() on the language which in turn internally defers to the various abstraction systems. one unfortunate aspect is that the requirements for selected languages is kind of divergent from available languages. for selected languages their *configured* order matters. to enable this there is a secondary list of languages purely for establishing the selection and selection preference (i.e. order of use). this is a bit awkward but considering this very minor divergent in requirements I didn't see justification to make selected languages a completely separate model. the refactor also, rather by accident, repairs the handling of missing languages which probably broke at some point because of the excessive book keeping work (the missing languages never showed up in the model) the visualization of missing languages is also streamlined now by not treating them as part of the model but rather a secondary list of codes that are configured but not actually available on the system. this reduces the visual presentation a bit (not that it was particularly useful since you can't do anything with a missing language anyway) but has the advantage that it means we can consider the base model of languages const (Language instance are loaded at startup only) and also removes some cruft from the qml code that purely existed to visualize missing languages. to be clear: the languages are still listed in a warning, but no longer displayed in the listview.	5 years ago