- follow branding settings, taking the panel-sides into account
- drop fixed width and height for QML parts
- give panels a minimum appropriate-dimension if they don't have one
This allows, for instance, putting both Widget sidebar and QML navigation
on the left-hand side of the window.
- Introduce an enum for panel-side
- Expose this to QML -- I can imagine that QML panels need to know
which side of the Calamares window they're on.
- Refactor loading the setting into a method that handles both
flavor and side
- There's no real reason to force the sidebar left and nav at the bottom,
certainly with QML supporting more layouts and being more flexible,
so document a mechanism to place the sidebar and navigation along
"edges" of the Calamares window.
- With an empty list, the question is meaningless
- .. and we called this with an empty list while constructing the
ViewManager; if quit-at-end is true, then this would terminate
Calamares immediately because the list was at the end.
- put signals in conventional place
- remove const int& parameter, that can just be int
- drop oddly-guarded code (that leaks memory); if the index (row)
being passed in, it's probably best to just crash
- remove unused signal warningMessageChanged
- Now the back button should be done by clients as well
- Refactor in CalamaresWindow to avoid leaking local button pointers
to surrounding code.
- Add macro UPDATE_BUTTON_PROPERTY for convenience in ViewManager
(ugh, macro) to change a value and emit corresponding update signal.
- add properties for the next button (enabled, label, icon...)
- update those properties as normal
- connect to the properties in the UI implementation
using Loader, can be reused for other widgets conversion
leave onClick example with full path, commneted out
title text for About is hardcoded, discuss option to make this configurable in welcome.conf
background color hardcoded, tested to work well in dark themes too
- since we've got two blocks of code copy-pasted, which both
decide to call one or the other of two member functions based
on a flavor value, turn that into a templated function.
- passing member functions looks a bit weird, and calling them
is syntactically surprising, but it cuts down the code a lot.
- the checker only collects and calls requirements; it has no
UI component, and only manages data (and a thread to do the
checking). Move it out of the UI library.
- this function lives in Module -- and is the only thing typing
Module to the ViewSteps and JobTypes. Split it out into its
own funciton. Nothing else in Module needs to befriend the
ViewSteps, so we move the friend declaration around a bit
as well.
- while here, apply coding style.
This is prep-work for moving module to libcalamares.
