Skip to content
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

Closed
wants to merge 42 commits into from

Conversation

meisenzahl
Copy link
Member

Closes #172

@meisenzahl meisenzahl marked this pull request as ready for review January 26, 2021 19:38
@meisenzahl
Copy link
Member Author

Current state

Peek 2021-01-26 20-30

I am so bad at doing layouts 🙈

@cassidyjames I could use some help 🙏

Copy link
Contributor

@cassidyjames cassidyjames left a 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):

Screenshot from 2021-01-26 13 39 03 Screenshot from 2021-01-26 14-01-48 Screenshot from 2021-01-26 13-39-12

@meisenzahl
Copy link
Member Author

@cassidyjames layout-wise like this?

Peek 2021-01-26 22-04

@cassidyjames
Copy link
Contributor

@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)?

@meisenzahl
Copy link
Member Author

Copy link
Contributor

@cassidyjames cassidyjames left a 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

src/Views/FirmwareReleaseView.vala Outdated Show resolved Hide resolved
src/Views/FirmwareReleaseView.vala Outdated Show resolved Hide resolved
src/Views/FirmwareReleaseView.vala Outdated Show resolved Hide resolved
meisenzahl and others added 6 commits January 26, 2021 22:41
* 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
@meisenzahl
Copy link
Member Author

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.

@cassidyjames I refactored the code to use GLib.format_size to pretty print Bytes. But I could not find a function to pretty print time.

Regarding XML: I could add libxml2-dev as a dependency. Is there anything against it?

Copy link
Member

@danirabbit danirabbit left a 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

src/Views/FirmwareView.vala Outdated Show resolved Hide resolved
@meisenzahl
Copy link
Member Author

meisenzahl commented Feb 9, 2021

Current state

TODO

  • Add placeholder for devices without releases in FirmwareReleaseView
  • Hide button in header_box if not upgradable or latest release is installed

Bildschirmfoto von 2021-02-09 06 54 07

@meisenzahl
Copy link
Member Author

Peek.2021-02-15.15-33.mp4

Should all be working now 😀

@danirabbit
Copy link
Member

I think I would prefer if we merged #202 first so that we're not making it harder to port to libfwupd

@danirabbit
Copy link
Member

We have fwupd docs now on Valadoc :) https://valadoc.org/fwupd/Fwupd.html

@meisenzahl
Copy link
Member Author

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.

Copy link
Member

@danirabbit danirabbit left a 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 ();
Copy link
Member

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:

Suggested change
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";
Copy link
Member

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:

Suggested change
content.visible_child_name = "placeholder";
content.visible_child = placeholder;

Comment on lines +203 to +210
firmware_release_view.update.connect ((device, release) => {
on_update_start (device);

update.begin (device, release, (obj, res) => {
update.end (res);
on_update_end ();
});
});
Copy link
Member

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

Comment on lines +161 to +162
progress_alert_view.title = _("“%s” is being updated").printf (device.get_name ());
visible_child = progress_view;
Copy link
Member

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?

Comment on lines +26 to +30
public bool is_updatable {
get {
return release != null && device.get_version () != release.get_version ();
}
}
Copy link
Member

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

Copy link
Member

@danirabbit danirabbit left a 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

@meisenzahl
Copy link
Member Author

@danrabbit sure let's break this up into separate PRs 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add detail page for firmware releases
4 participants