-
-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add detail page for firmware releases #182
Conversation
Current stateI am so bad at doing layouts 🙈 @cassidyjames I could use some help 🙏 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The actual contents of the detail page looks close, and I can probably do any small layout cleanup once we're closer. I have a couple of thoughts though:
Formatter seems interesting; I would think some if not all of these would be built into GLib or something and not require manual handling here. Dealing with bytes and seconds and XML all seem pretty common. 😛 So that might be worth looking into instead of reinventing it here.
Layout-wise, as I mentioned in Slack, ideally the detail page would be in a Hdy.Deck and within the same container as the list (so styled with the white background and border and everything); this way it feels like a page within that list, instead of not really having a clear container. See the Installer and Initial Setup lists where we use Hdy.Deck for an example of that (the right half of this view):
![]() |
![]() |
![]() |
---|
@cassidyjames layout-wise like this? |
@meisenzahl yeah that's much closer! Looks like we might need a style class or something on that top bar (see: Installer/Initial Setup to match)? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a couple of style things to better match the other places we use this type of layout
Co-authored-by: Cassidy James Blaede <[email protected]>
Co-authored-by: Cassidy James Blaede <[email protected]>
Co-authored-by: Cassidy James Blaede <[email protected]>
* FirmwareReleaseView: Layout tweaks * Revert whitespace change * Tweak content spacing * Tweak margin * More spacing tweaks * Center up the key/vals in their own grid * De-prioritize key/vals
@cassidyjames I refactored the code to use Regarding XML: I could add |
…ementary/switchboard-plug-about into add-detail-page-for-firmware-releases
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't read through all the code yet, but noticed this thing
Peek.2021-02-15.15-33.mp4Should all be working now 😀 |
I think I would prefer if we merged #202 first so that we're not making it harder to port to libfwupd |
We have fwupd docs now on Valadoc :) https://valadoc.org/fwupd/Fwupd.html |
The way libfwupd's logic works, no release information is now displayed after a updatable device is updated to it's latest release... Compare with my last video for Unifying Receiver. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just stuff I noticed on a first pass here
add (content); | ||
|
||
back_button.clicked.connect (() => { | ||
back (); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the deck is an ancestor of this, we can use Gtk.Widget.get_ancestor
and avoid sending signals up:
back (); | |
var deck = (Hdy.Deck) get_ancestor (typeof (Hdy.Deck)); | |
deck.navigate (Hdy.NavigationDirection.BACK); |
placeholder.icon_name = icons.data[0]; | ||
} | ||
|
||
content.visible_child_name = "placeholder"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's faster to compare refs than strings and placeholder
is already available so better to do:
content.visible_child_name = "placeholder"; | |
content.visible_child = placeholder; |
firmware_release_view.update.connect ((device, release) => { | ||
on_update_start (device); | ||
|
||
update.begin (device, release, (obj, res) => { | ||
update.end (res); | ||
on_update_end (); | ||
}); | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be connected when the firmware release view is constructed, otherwise you're creating a new signal connection every time the release view is shown
progress_alert_view.title = _("“%s” is being updated").printf (device.get_name ()); | ||
visible_child = progress_view; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like you created a function for this, but then didn't use it here?
public bool is_updatable { | ||
get { | ||
return release != null && device.get_version () != release.get_version (); | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why was this done? We already check this on construct, this change means we have to run this comparison every time this property is used
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a lot going on here with so many things moving up into the FirmwareView, I wonder if it would make sense to split this into two PRs: one dealing with only the refactoring of the update logic and a separate one for adding the release view
@danrabbit sure let's break this up into separate PRs 👍 |
Closes #172