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.
Harald Sitter
0043576005