The build instructions are not that interesting, it's a toss-up
between CC0 and BSD-2, but because other CMake bits are BSD-2-Clause,
apply that to more CMakeLists. The copyright date isn't all that
accurate, but these are just inconsequential files.
While here, tidy up and get rid of some useless intermediates.
The .ui files are all GPL-3.0-or-later style, but it's
slightly difficult to keep licensing information in them:
it's XML, so an XML comment might work, but there's no
guarantee that safe/load will preserve them.
Put the SPDX tags in the <author> tag, so that it's visible
in Qt Designer.
The TODO said it was unused: it **is** used, but only in
a very limited scope. Drop it from jobs where it wasn't
useful (e.g. those that just return prettyName(), outside
of the partition module).
- Give classes a virtual destructor that need them
- Remove spurious ;
- Refactor addJobs() because that doesn't need to be in a class
- Remove redundant intermediate base-classes
- If the 'no tracking' box is checked, then the way to uncheck
it is to tick some **other** box.
- It doesn't make sense to unselect 'none' and then have .. none
selected.
KDE neon does not do this kind of tracking -- although it was originally
requested by KDE neon, no server roll-out was done once the
privacy policy was thought out.
- give the on-some-checkbox-state-changed slots better names
- while here, refactor is-any-actual-tracking-option-checked
- improve other debug messages, to be a whole sentence
- The Radio's are replaced by CheckBoxes and some logic, so
that different tracking styles can be enabled independently.
None of the settings end up in the Config yet, though.
- All the configuration lives in the Config object (or the
tracking objects that it exposes).
- Get data from the config object for the jobs; TODO: give the
jobs a less-clunky interface.
The UI isn't hooked up to the Config object yet, though.
- a single tracking type can be enabled for configuration in the
config file; each must have a policy URL. Class TrackingStyleConfig
is a base class for that kind of configuration.
- Let's just have one header definining export- and visibility-
macros for Calamares. They are still selected based on the
export flags (*_PRO), just defined in one header instead of two.
