When using local site, buildroot does not automatically apply patches.
The buildroot manual recommends using the POST_RSYNC hook to apply
patches if needed, so implement this to automatically apply patches.
Resolves#671
Seems like there's a weird Qt bug in the ProgressBar widget where giving
it padding means the white progress indicator doesn't actually start at
the left edge of the bar or extend to the right edge of the bar. So
just remove the padding from ProgressBar because it's not doing much.
- Update back to colour logo
- Change logo alignment and positioning to make it generally
left-aligned, have some nice padding above and below it, and to not
occupy the full window width.
This reverts commit 2fb58dc01c.
The original commit included an unexpected deletion of _all_
translations in certain languages. This was unintented, and appears to
have been a merging artefact.
This change will be re-submitted as a separate PR.
A long period of hand-editing caused these to fall out of sync with
what would have been generated from the source.
These were regnerated using the qt5_create_translation macro in the
root CMakeLists, and then using lconvert to merge the completely blank
translation files with the existing translations.
This patch carries a translation risk, as we change the default
progression button.
Remove the customisation button all together, and make the customisation
options something we offer as part of flashing an image that
has that capability.
While this adds an additional click to the flash sequence, it should
provide a steer to people who are flashing customisable images to make
use of this capability, potentially avoiding an additional pass through the
Imager.
This change adjusts the layout for the progress bar, write button and
cancellation buttons such that they are all placed on the same layout
'row', with the progress bar stacked as before, and the
write/cancel/cancel buttons stacked as a column.
This is not ideal, but probably as sensible as we can get inside this
layout paradigm.
1) Resize the window back to 680dip default widths. We don't need the
extra space now.
2) Reduce Row spacing within the grid layout. We need all the space we
can get.
3) Assign layouts to explicit cells, at least for selection options and
write. This layout isn't really scaling to the amount of data we want
to provide, but we'll make do for now.
4) Mark selection buttons as accessibility ignored when the hwpopup is
active.
Introduce 4 filtering types per device spec:
- "exclusive", which only includes OS' that match one of the specified
tags, and discards any OS that is untagged.
- "exclusive_prefix", which only includes OS' that prefix-match one of
the specified tags, discarding any OS that is untagged.
- "inclusive", which discards any OS that doesn't include one of the
specified tags, but includes untagged images.
- "inclusive_prefix", which discards any OS that doesn't prefix match
one of the specified tags, but includes untagged images.
Removed preferred widths for OS, device buttons, and set one for the
storage button. This allows the storage label (generally the longest)
to fit on the control face reliably.
Prior to this change, you could enter a submenu of the OS selector,
close the window, and then change device filter - presenting stale information
when you went back in to the OS selector.
Work around this by resetting the OS selector sequence when you close
the OS selector window.
Rather than a drop down dialog, which could present users with images
that may not run on their hardware, allow selection of Raspberry Pi as a
first stage. If users adopt this feature, they are presented with a
subset of images that we know will actually run on their hardware.
This is achieved by leveraging @maxnet's excellent OS filtering scheme.
Future work will attach image and description support to this OS list.
