Upstream rebase

[isantop]

Upstream Appcenter has had many nice changes since the last time we synced up; this pulls in the latest updated code from AppCenter to bring these new developments into Pop_Shop.

Improvements Include:

• Improvements to asynchronous processing to improve performance and reduce UI blockages.
• Redesigned top-bar which improves use with narrow form factor windows and better highlights search functionality.
• Fixes for issues related to "Open" button for newly-installed Apps
• Reductions in changes from upstream, simplifying future maintenance.
• Status overlay to better communicate background progress

[isantop]

@maria-komarova One other point: I think that the term "Installed Software" is more appropriate than "Installed Apps" since there is also OS-level and under-the-hood runtime software in that page. I believe "Software" is inclusive enough to indicate "Apps".

Additionally, the width constraints are much more relaxed here because we aren't trying to fit as much stuff into the width of the window.

[maria-komarova]

Sure, software sounds good then if width is not a concern.

[hojjatabdollahi]

I am using the PopShop build from pop-shop 3.4.2pop0~1675897810~22.04~4194559 and it crashes a lot. Out of 40 tries, 8 of them segfaulted.

One time it crashed because I was changing the window size while it was refreshing the database:

io.elementary.appcenter: ../../../../src/cairo-region.c:428: cairo_region_destroy: Assertion `CAIRO_REFERENCE_COUNT_HAS_REFERENCE (&region->ref_count)' failed.
zsh: IOT instruction (core dumped)  io.elementary.appcenter

Once it crashed with:

malloc(): unaligned tcache chunk detected
zsh: IOT instruction (core dumped)  io.elementary.appcenter

The other 6 times it would not even show the window and only print this:

zsh: segmentation fault (core dumped)  io.elementary.appcenter

I couldn't find the exact place that it crashes but using gdb I found this:

Thread 13 "flatpak-worker" received signal SIGSEGV, Segmentation fault.

[jacobgkau]

Installing and removing both .debs and Flatpaks seem to be working for me now. Still testing for stability.

[isaac-8601]

This might be more for documentation purposes because we don't want to introduce large patches at the moment (it seems). It appears the consensus is forming on these points...

• "Installed Software" by itself is useful and needed, but may not need prominent placement. It could exist in the menu.
• "Updates" are very important and need prominent placement. Right now they are tied to installed apps but it's important to notify the user.

So far our options have those two tied together because separating them would be a bigger patch. I wonder if maybe there is a compromise? Can we have "Installed Software and Updates" in the menu, but keep an "Updates" button (or icon button) that takes you directly the updates. when applicable? I recognize that the two links would currently take you to the current page, but in the future maybe we consider another view that has exclusively updates?

[jacobgkau]

@isaac-8601 We notify the user about installed updates with the badge on the hamburger menu. (We also do have pop-upgrade send notifications for updates weekly by default, it just doesn't actually install them by default; those notifications should open the Pop!_Shop to the correct page.)

It sounds like having a button that just says Updates on the headerbar would also introduce some of the same drawbacks as one that just says Installed, since those words aren't very different in length.

but in the future maybe we consider another view that has exclusively updates?

I'm not sure how much value this would add (it does seem like it could be nice), but it seems like something we would consider if/when we replace the Pop!_Shop/AppCenter, rather than as a patch. @isantop can let me know if I'm wrong (I don't know how easy/difficult it would actually be to split those out.)

The decision to do that doesn't necessarily need to be tied to having a button in the headerbar or not, since the hamburger menu could easily contain separate Updates and Installed Software buttons (if those pages were to be separated out.)

[isantop]

Yeah, separating Updates from the Installed Apps list is not something that's feasible with the current codebase. There's a possibility to add a separate view which only lists available updates, but it would duplicate functionality already present in the Installed Apps view. Basically, because the installed apps view has the buttons to do the updates (and the updates are a pretty minimal UI on top of that page), I don't think that separating them makes a lot of sense. Basically you have the Installed Apps which is a list of installed apps, and then Updates which would be a list of Installed Apps that have updates available. It doesn't feel like a meaningful difference to me.

[jacobgkau]

I'm not seeing the hamburger badge and highlighted menu entry when I have an update available:

If I kill io.elementary.appcenter and restart it, then I do see those things:

Closing it again and launching with -s and re-opening, I don't have them anymore. @isantop Any idea what's going on with this?

It also sounded like we wanted the highlight to extend around the entire hamburger menu entry (including the keyboard shortcut), not just the text label, based on https://github.com/pop-os/shop/pull/401#issuecomment-1423293610. (Makes sense, since the entire row is clickable and has the highlight when hovering.)

[maria-komarova]

The more I look at it the more awkward the background behind the label looks. I wonder if it would be better (and possible) to have the badge not as an overlay but as content in place of the shortcut. I'm not sure how much value the keybinding offers compared to having good experience with the updates indicator that feel integral to the UI in general. It's not ideal but it would be better than the background behind the label. If that's not possible, then yes, extending it behind the shortcut is a touch better than having it just behind the label.

[isantop]

@maria-komarova I was able to add the badge as you had it in the earlier image:

Additionally, I was able to make it so that they can switch between the badge and the shortcut; the menubadge will be displayed whenever there are updates available, otherwise it will display the shortcut. I think this aids with discoverability for the shortcut while still prioritizing the menubadge whenever an update is available:

[maria-komarova]

Great! Thanks, I think it might be the best compromise under the circumstances.

[hojjatabdollahi]

Is this behavior intentional:

If you type 3 letters in the search box, it will show the results, if you press backspace and delete the last letter (now you have two letters in the search box) it will cancel everything, clear the box and take you back home.

[jacobgkau]

@hojjatabdollahi I can replicate this. Seems like it only happens when there are 2 characters left, no matter how many characters were typed first. Similarly, searches don't take effect until the third character is typed.

This seems semi-intentional, but it also seems quirky. However, the current Pop!_Shop also works like this, so it's not really a regression. (The change in behavior from the current version is that the search box now automatically searches when 3 characters have been typed; previously, you had to press Enter to search, and that did nothing if only 1 or 2 characters were typed.)

[hojjatabdollahi]

@jacobgkau Makes sense. It's not a big deal. BTW I can also replicate the issue you described here.

[isantop]

With less than 3 characters, the search results can be too large to prevent performance issues with Shop, so they're cut off below 3.

[jacobgkau]

The in-app update badge is still not working with the shop running as a daemon before opening the window. It works when the shop is launched without the daemon running.

Just wanted to clarify that's still happening. (Also, not sure if it would be possible to change the color of the in-dock badge to match the in-app badges-- it's okay if it's not.)

[isantop]

Also, not sure if it would be possible to change the color of the in-dock badge to match the in-app badges-- it's okay if it's not.

These are set by the Gnome Shell theme, so it's not possible to change them. We might be able to set our shell theme to hardcode an exception for Pop Shop, but I'm not particularly comfortable with that.

[isantop]

I can't seem to replicate the Daemon-Badge issue:

Testing methodology:

In Terminal 1:

killall io.elementary.appcenter # Ensure a clean testing environment
io.elementary.appcenter -s # Start daemon mode

In Terminal 2:

io.elementary.appcenter # Open the window

Results: The update badge appears correctly.

[13r0ck]

If we are doing the notification bubble as a bubble in the drop down too, then maybe just keeping the red universally is the right idea for consistency. A red indicator and a red button mean very different things, to me at least

[jacobgkau]

@isantop Thanks for the methodology. I narrowed the issue down further; apparently, it's not just about whether the shop is running in daemon mode or not, but whether the icon is used to launch it or not. After starting it in daemon mode, I get the badge when running io.elementary.appcenter from the terminal, but not when starting it from the icon.

Here is a video demonstrating this (from a fresh boot/login):

https://user-images.githubusercontent.com/7199422/219483780-010fe913-1439-4986-9966-bd0a1d4ac242.mp4

If I kill the daemon and then launch from the icon, then I do get the badge. So the steps to recreate are:

1. Ensure the shop has been started in daemon mode.
2. Open the shop window using the icon.

[isantop]

Alright, I'll take a look at it. So nice of it to have a problem that doesn't happen where I can see log output. 😛

[isantop]

After testing the stability of Pop Shop by running it 1000 times, I've observed a total of 45 crashes for an overall stability of 95.5%. While I think this could definitely be improved, I don't personally think this is low enough to be considered a major regression, and given the other benefits that this branch brings, I think it would be acceptable to merge this to start and improve the stability later.

I will need to look into the update notification issue first.

[isantop]

@jacobgkau It looks like the updates badge revealer was being triggered when the number of updates changes. On the problematic version, I believe opening Shop via the icon would allow the badge to show the first time it was opened, but as you noticed, subsequent opens will not show the badge.

This is fixed in f84643b by adding a change to the updates number property to the refresh method, which should then trigger the badge whenever there's a cache update and updates are available. This may cause the badge to briefly hide then reshow in certain circumstances, but I think that tradeoff is okay given that we want to ensure that the badge is always showed when updates are available.

[maria-komarova]

I've seen instances where red is used for the similar indicators for updates and the color didn't disturb me there. So I don't mind reverting back to red for the indicator. It definitely draws more attention.

[isantop]

This is where we're currently at (the specific red in the menu will update based on dark mode or light):

[jacobgkau]

Small regression. When clicking Show Details from the Applications menu if the Pop!_Shop is not already open, then the shop only opens to the Installed page, not to the application's page. It does open to the application's page if the shop was already open.

On the previous Pop!_Shop, the shop opened to the application's page when this button was clicked even if it wasn't already open.

[isantop]

Small regression. When clicking Show Details from the Applications menu if the Pop!_Shop is not already open, then the shop only opens to the Installed page, not to the application's page. It does open to the application's page if the shop was already open.

@jacobgkau I'm having a hard time replicating this issue. Even if I kill the Pop_Shop process first, when I use Show Details the shop correctly opens the app in the list. Running 4991fb9 installed via apt (through the upstream-rebase staging branch). Which app are you seeing issues with? There might be some other factor causing that problem.

[jacobgkau]

@isantop Sorry, I've narrowed it down to Flatpak apps. Kdenlive is an example app that is affected. To clarify, the process being started/stopped doesn't affect this; it's actually whether the window is open to the Installed page specifically that determines whether it works (if it's open on another page, the first attempt opens up the Installed page, similar to if the window was closed.) See below:

https://user-images.githubusercontent.com/7199422/223559971-aa3fe467-5513-420c-a1b3-a28cc3e3eff3.mp4

Some other Flatpak apps, such as VS Code or LibreOffice (when installed via Flatpak), do not work even if the window's already open. That is not a regression. But Flatpak apps that used to work (such as Kdenlive) should continue to work on the first try after the update.

[isantop]

So, I'm getting a slightly different problem in my testing:

kdenliv.webm

Shop reliably opens the App details for me. There is often a large delay between clicking on "Show Details" and opening Shop, though.

[jacobgkau]

@isantop I tried testing on a different system. I found that at first, clicking Show Details on Kdenlive (in the App Library or the App Library's search results) didn't recreate this issue. However, I went to Installed, closed the shop, and then the issue started occurring. It continues to occur even if I go back to Home, close, and try again. Can you try navigating to the Installed page before closing the window and then seeing if the issue occurs?

[isantop]

I think I figured out what was causing that. It should be fixed as of b4c91ae

[jacobgkau]

The Show Details bug is fixed. I see a slight delay sometimes, but I don't consider that blocking.

It does seem like a similar issue occurs with opening the shop using the icon, though. If I go to Installed, back to Home, close, and click the icon, it opens to Installed. Can the fix be applied to icon launching as well? (Even if this ends up making it so closing from Installed no longer opens it back to Installed, I still think defaulting to Home would be more reasonable behavior than defaulting to Installed after explicitly navigating back to Home.)

[isantop]

The Show Details bug is fixed. I see a slight delay sometimes, but I don't consider that blocking.

It does seem like a similar issue occurs with opening the shop using the icon, though. If I go to Installed, back to Home, close, and click the icon, it opens to Installed. Can the fix be applied to icon launching as well? (Even if this ends up making it so closing from Installed no longer opens it back to Installed, I still think defaulting to Home would be more reasonable behavior than defaulting to Installed after explicitly navigating back to Home.)

No, because the icon opening is handled exclusively with the activate() method, whereas opening to the Installed Page (which is how the update notification works) uses the show_updates_action (which the notification uses) calls as part of its usage.

I will point out that I've also occasionally seen that issue for years (typically after opening the updates page from the notification) so I'm not sure if that's a regression.

[jacobgkau]

I will point out that I've also occasionally seen that issue for years (typically after opening the updates page from the notification) so I'm not sure if that's a regression.

On the currently released Shop version, I can go to the Installed page, close, and open the Shop again, and it launches to Home. I can also go to Installed, back to Home, close, and open again, and it still launches to Home. So no, this is not pre-existing behavior; being able to recreate it this consistently, at least, is a regression.

Why is the shop now getting stuck opening to Installed after that page has been opened once? It seems like maybe the fix for Show Details was more of a workaround that didn't fix the underlying issue.

[isantop]

I believe the issue is due to underlying architecture changes with the new version of Pop Shop. Large parts of this class are very different from the current version.

[isantop]

76c2bbe includes a change which resets the flag telling Shop to open to the Installed page once the window is activated. It should still open to the Installed page when it's triggered for that, but afterwards it is reset so that it stays on the home page. There may still be isolated incidents where the window incorrectly presents the Installed page, but subsequent opening should resolve this (i.e. it won't get stuck opening to the Installed page anymore).

[jacobgkau]

76c2bbe is an improvement. The shop now always seems to open to Home. However, running io.elementary.appcenter -u or io.elementary.appcenter --show-updates only opens the Installed page if the shop's daemon was not already running. Should that work if the shop's already running in the background?

(Separately, the notifications from system-updater don't seem to open the Pop!_Shop at all; I have confirmed that is not a regression. But we still want the shop to have the ability to open to Installed so that can be fixed in system-updater later, if it's not a Pop!_Shop issue.)

I also seem to be getting more shop crashes now. It seems to happen a few seconds after opening the window sometimes. I just got a segfault, for example:

Mar 16 15:01:00 pop-os io.elementary.a[2880]: pango_layout_is_wrapped: assertion 'layout != NULL' failed
Mar 16 15:01:00 pop-os io.elementary.a[2880]: pango_layout_is_ellipsized: assertion 'layout != NULL' failed
Mar 16 15:01:00 pop-os io.elementary.a[2880]: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
Mar 16 15:01:00 pop-os io.elementary.a[2880]: pango_layout_get_extents: assertion 'layout != NULL' failed
Mar 16 15:01:00 pop-os kernel: show_signal_msg: 12 callbacks suppressed
Mar 16 15:01:00 pop-os kernel: io.elementary.a[2880]: segfault at 110 ip 00007f22f68a3d79 sp 00007fffb1d93b60 error 4 in libc.so.6[7f22f6828000+195000] likely on CPU 2 (core 1, socket 0)
Mar 16 15:01:00 pop-os kernel: Code: 3b 05 83 56 17 00 0f 83 91 03 00 00 48 8b 57 10 48 85 d2 0f 84 84 03 00 00 f6 c2 0f 0f 85 6f 06 00 00 64 8b 34 25 18 00 00 00 <48> 8b 42 10 85 f6 74 8f e9 c2 00 00 00 66 2e 0f 1f 84 00 00 00 00
Mar 16 15:01:00 pop-os PackageKit[1236]: resolve transaction /4741_eddabccd from uid 1000 finished with success after 260ms
Mar 16 15:01:01 pop-os systemd[2477]: app-gnome-io.elementary.appcenter\x2ddaemon-2880.scope: Consumed 39.688s CPU time.

I know the current version's already not entirely stable, but I wanted to mention this in case it's related to the most recent changes, since I hadn't noticed as much crashing before.