-
-
Notifications
You must be signed in to change notification settings - Fork 104
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
Dinamically load icons if cache is being rebuilt (issue #2209) #2238
base: main
Are you sure you want to change the base?
Dinamically load icons if cache is being rebuilt (issue #2209) #2238
Conversation
…ith a borken icon. This also attmepts to load all available icons, including flatpak emote icons via priority according to freedekstop specs.
…rify cache existence). Also removing a not needed critical message
…d icon. Then, change it to the correct icon when you are sure its correspondent cahce remote has been updated properly. This happens aof Banner icons, ListPackageRowGrid icons, and AppInfoView Icons
blocking method. Also, ensure no spinner shows when an icon is not available (instead of failing to load icon)
I think it's a great solution, but I'm not sure if we should use |
So I implemented the I suppose the I also decided to blur and desaturate the default icon a bit via CSS, to avoid confusion if an actual icon cannot be found, so those use the normal default icons (at the moment some flatpaks that use remote icons only have no icon on the AppCenter because we are not dynamically downloading remote icons yet.) Here is the result: 2025-01-03.18-06-47.mp4Let me know what you think 👍 Edit: I made some change to removed using named |
I feel stupid for asking this, but how would it be best to test this out ? when testing this branch, deleting the appstream or flatpak, or both, folders in cache, it appears fully loaded, no temporary icon or anything. deleting io.elementary.appcenter only causes #2246 |
Hey @teamcons. So yeah, it's a bit annoying to test this. The "real test" is to, literally, wait for one hour after opening the AppCenter and closing it. The cache gets invalidated after one hour, so that's how you should test it "for real". But if you want to do the quick check, you can modify the You can put a small value, like 30, so the cache gets invalidated every 30 seconds or something like that (so you can test that a reload of the AppCenter should not trigger this behavior in between the invalidation timer because the cache is OK). You can also put 0, and it will always invalidate. In theory, both tests should yield the same results, as the only difference is the AppCenter Flatpak backend defined time for the cache to be invalid. If you have more questions, let me know 👍 |
I mean i cam retry, but that is also how ive proceeded a few times, waiting some time before reopening appcenter, and the behaviour is similar - probably it loads too fast ? |
What you mention can definitely happen, since the loading metadata happens on a separate async process there is a chance that it might happen faster and thus no need to wait to load icons. I suppose it depends on the machine in that case, but in any case, setting the |
works as intended. No regression noticed. Does indeed fix 2209 |
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.
Hey thanks for your patience on reviews!
It seems like there's a number of unrelated changes in this branch. I left some comments.
Do you think we can also break out the icon loading order changes in Package.vala to its own branch? That seems like a change that is worthy of being reviewed on its own and I'm noticing that it has introduced a bit of blurriness with some icons
src/Views/Homepage.vala
Outdated
@@ -428,6 +439,18 @@ public class AppCenter.Homepage : Adw.NavigationPage { | |||
}); | |||
} | |||
|
|||
private int get_app_scale_factor () { |
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.
every Gtk.Widget has access to scale_factor
: https://valadoc.org/gtk4/Gtk.Widget.scale_factor.html
So this function should be unnecessary
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.
Ah! Noted, I will remove this in Homepage.vala
I noted, however, that in Banner.vala
if I don't do a certain type check for this.scale_factor
, it will trigger this assertion.
(io.elementary.appcenter:153094): Gtk-CRITICAL **: 09:26:50.675: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed
This won't happen in Homepage.vala
, using this.scale_factor is enough. But on Banner.vala
, the assertion will trigger.
My solution for banner would be to do something like this:
var scale = (Gtk.Widget) this != null ? this.scale_factor : 1;
var pkg_icon = package.get_icon (128, scale);
But maybe I'm doing something wrong and should do something else. I could also just use this.scale_factor
and ignore the assertion. Not sure what you think about this.
src/Widgets/BackButton.vala
Outdated
@@ -24,7 +24,9 @@ public class AppCenter.BackButton : Gtk.Button { | |||
var current_page = (Adw.NavigationPage) get_ancestor (typeof (Adw.NavigationPage)); | |||
var navigation_view = (Adw.NavigationView) get_ancestor (typeof (Adw.NavigationView)); | |||
var previous_page = navigation_view.get_previous_page (current_page); | |||
label_widget.label = previous_page.title; | |||
if (previous_page != null) { |
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 seems unrelated to the icon loading, can this be in a separate branch?
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.
Ah, yes, this is indeed a commit I made because the Critical assertions were annoying me and wanted a clean log. But it is indeed not related to the actual PR. I will remove it to keep things clean and set a new PR focused on cleaning Critical assertions only.
src/Widgets/Banner.vala
Outdated
); | ||
} | ||
|
||
|
||
construct { | ||
var name_label = new Gtk.Label (app_name) { | ||
max_width_chars = 50, |
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.
Is there a reason why you removed the maximum label width? Seems unrelated to icon loading
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.
Ah! These Banner.vala
changes was me experimenting something else when using the spinner widget was a thing I believe. I might have been disorganized myself and let something that shouldn't.
Either way, they don't seem relevant at all. I will remove these since they don't have anything to do with the actual PR. Sorry about that.
src/Widgets/Banner.vala
Outdated
@@ -98,10 +116,10 @@ public class AppCenter.Widgets.Banner : Gtk.Button { | |||
inner_box.append (summary_label); | |||
inner_box.append (description_label); | |||
|
|||
var outer_box = new Gtk.Box (HORIZONTAL, 0) { | |||
var outer_box = new Gtk.Box (HORIZONTAL, 24) { |
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.
What's the reason for adding spacing here?
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.
Same as the previous comment about Banner.vala
. I will remove these unnecessary changes.
Short summary
This aims to fix #2209
What I've found is that are some methods that will temporarily erase the cached icons folder in order to repopulate. This happens:
The method in question is
preprocess_metadata
. This, for every user and system remote, delete s its cache folder, and checks for the integrity of everything before re-creating the folder icons symbolics links again.Given some discussion, the conclusion was that it was best to add a signal to detect as soon as possible that each remote manages to update itself and then update the corresponding icon accordingly. The aforementioned icons now use the default icon if it fails to
This PR also addresses the icon load procedure in
Package.vala
, in order to have priority on the recommended icons to load according to the AppStream API. The order in question is:Right now, we are not loading remote icons because of a blocking event when querying the URI. I think it's perfectly possible to dynamically load these, similarly to when the cache is being rebuilt. Worthy of a future PR. This change should be a basic preparation for that.
Tests
Here are some videos of the results. Note that I'm using for some of these fake cache times, just to show stuff.
This video tests loading icons for the first time. Then it reloads to show that, if cache is good, won't load them up again.
2025-01-02-01.13.16.723112574.mp4
This one shows that if you quickly go to the
AppInfoView
, the loading icon event can still be seen.2025-01-02-01.13.59.877832494.mp4
Additional info
Sorry about the commit history being a bit polluted, I was doing and undoing stuff. If you need me to squash some commits, I can do that.