This week in Discover, part 10

This week saw many positive changes for Discover, and I feel that it’s really coming into its own. Discover rumbles inexorably along toward the finish line of becoming the most-loved Linux app store! Take a look at this week’s improvements:

New Features

  • Discover can now sort apps by last release date in the browse lists and search results (KDE bug 391668, implemented in KDE Plasma 5.13, authored by Aleix Pol)

Bugfixes

  • Fixed a bug that could cause Flatpak apps to stop being available (KDE bug 391126, fixed in KDE Plasma 5.12.4, authored by Aleix Pol)
  • Fixed a bug that could cause Discover to fail to download Plasma or Application addons (KDE bug 390236, fixed in KDE Plasma 5.12.4, authored by Aleix Pol)
  • Fixed a bug causing Plasma and Application addons to not display large screenshots (KDE bug 391190, fixed in KDE Plasma 5.13.0, authored by Aleix Pol)
  • Fixed a bug that could cause Discover to not open properly when invoked from from its context menu’s “Updates” item (KDE bug 391801, Fixed in KDE Plasma 5.12.4, authored by Aleix Pol)
  • Fixed a bug causing Addons to not be sorted by release data correctly (KDE bug D11387, fixed in KDE Plasma 5.13.0, authored by Dan Leinir))
  • Fixed a bug causing all Addon screenshots to be inappropriately rendered as square (KDE bug 391792, fixed right now, authored by Dan Leinir):

UI polish & improvements

  • On the Updates page, the selection text can no longer overlap with the Update button (KDE bug 391632, fixed in KDE Plasma 5.13.0, authored by me, Nate Graham):
  • Increased the width of the “Add Source” dialog, so the URL is less likely to get cut off (KDE Phabricator revision D11219, fixed in KDE Plasma 5.13, authored by me, Nate Graham):
  • Discover now uses a more intuitive and obvious UI for choosing which source to install an app from (KDE bug 390464, fixed in KDE Plasma 5.13, authored by Aleix Pol):

    (We’re aware of the visual papercuts in the above screenshot, and will be working to resolve them in the coming days and weeks)
  • Improved the app page by removing the redundant second copy of the app’s name (KDE Phabricator revision D11364, fixed in KDE Plasma 5.13.0, authored by me, Nate Graham) and fixed the top padding (KDE Phabricator revision D11362, fixed in KDE Frameworks 5.45, authored by me, Nate Graham):
  • Discover now shows a more obvious and less transient page when asked to open an invalid appstream://URL (KDE bug 391756, fixed in KDE Plasma 5.13, authored by Aleix Pol):

Just take a look at these screenshots! Isn’t discover looking really good these days? We’ve chewed through most of our backlog of architectural issues and are working hard on adding much-requested features and polishing the UI.

If my efforts to do, guide, and document this work seem useful and you’d like to see more of them, then consider becoming a patron on Patreon, LiberaPay, or PayPal.

Become a patron Donate using Liberapay donate with PayPal

Advertisements

12 thoughts on “This week in Discover, part 10

  1. I am curious if Discover can show software coming from places that don’t have appstream metadata, such as PPAs? Ubuntu has made the decision to *not* support PPAs for gnome-software, meaning that things from PPAs can’t even be found in gnome-software. I understand that snap and flatpak are the “future” but until everyone is firmly there I would hope that software centers would at least have the ability to install all the software a user may need or want, even if it isn’t “pretty” due to not appstream metadata.

    Thanks again for everyone’s great work: I am starting to believe the hype that Discover may become the premier software center for Linux 🙂

    Like

    1. I’m afraid our design decision to only show packages with AppStream metadata puts us at the mercy of packagers and their decisions regarding what metadata to expose. There are other tools such as Apper and Muon that aim to be general-purpose package managers, but that’s not what we’re shooting for with Discover. We think the best way to provide a good user experience is to push developers and packagers to ship with the kind of metadata that users need to be able to make informed choices.

      Like

      1. Understood. The real problem here is of course Ubuntu, who has abandoned Launchpad too early (they have been very clear they will not do the work to have Launchpad PPAs generate AppStream metadata).

        Like

  2. One other question is if Discover would support running “without an internet connection” (offline). You may find this to be a strange question, but in our part of the world (developing countries) we use a customized “app” (not much more than zenity and bash scripting) to take cached updates from one computer and add them to a USB which is then used to distribute to others in an offline fashion: https://sites.google.com/site/wastalinux/wasta-applications/wasta-offline We need the frontend that the user will use to install to be able to function offline (in this case, basically the user’s /etc/apt/sources.list only points to the USB stick, with online repos disabled)

    Like

    1. Discover does allow you to disable repos on the Settings page, but at the moment , we don’t allow you do add new ones for PackageKit (i.e. apt) repos. If I’m understanding you correctly, what yuo’d like to be able to do is to add a new repo in Discover that points at /dev/sdb (or whatever), right?

      Like

      1. Thanks for the reply. Actually our utility (wasta-offline) sets up all the apt sources, and then when setup it opens a “wasta-offline is running” zenity prompt (at this point, if in “offline only mode” the user’s /etc/apt/sources.list ONLY has the USB drive as a source and /etc/apt/sources.list.d is moved so is empty. If in “hybrid mode” the user’s sources.list.d remains and at the TOP of their sources.list the USB is listed).

        The user then proceeds to use normal package managers or terminal to install or update applications. So the software manager doesn’t need to edit or add sources, it just needs to be able to proceed installing without doing an internet check (this is what seemed to block the old Ubuntu Software Center: it did some sort of internet check when launching and if it didn’t pass the check it would not function).

        Like

        1. Sorry didn’t finish my summary of wasta-offline: after the user completes any updates or new installs, they close the zenity dialog window, and their sources.list (and sources.list.d if they were running in offline-only mode) are restored. So again there isn’t any need for the software manager to add, remove, enable, or disable sources. Only be able to install from a local repository without an active internet connection.

          Like

          1. I know for a fact that Discover can function without an internet connection (I often work on it from the a train with large wifi dead zones). Why don’t you give it a whirl and report back? We’ll be happy to take a look at any issues you discover.

            Like

  3. Manjaro doesn’t come with Discover so I never used it and from what I saw on my tests in the past, it had lot of issues.
    I discovered this blog and it made me interest in Discover. I got use to Octopi which is much more versatile then Discover but many Linux beginners need such app stores like Discover so I’m interested in its progress.

    I installed it and I was pleasantly surprised. From slow, clunky app it became very fast and functional software center. Awesome job! Also the newest features that will show in Plasma 4.13 should make it really, really good. Can’t wait! After boring LTS release, finally some new goodies :D.

    There are few things that doesn’t feel right thou. Updating is counter intuitive. I expect to have some progress bars for each stages of update. In terminal each package is downloaded one by one and then updated one by one and it feels right and clean. Sadly, currently clicking on Update in Discover makes only “update” button gray and…. nothing more happens. When I tested it on virtualbox on neon not so long ago, I was frustrated. Did it errored out? Did it froze? Should I wait? Does it do something?
    It turned out it did start update by downloading hundreds of packages at once and since there was so much of it, seeing even 1% progress bar for each of them took a long time. This is very, very bad display of the process.
    Having simple progress bar and then “more details” with terminal output would be much nicer or am I too traditional? Current update behavior was very confusing. I hoped that on Arch based system I will get behavior more in line with what pamac does. Also showing available updates in panel took too long after system is already updated by other means (terminal or Octopi) so update icons hangs and hangs in the panel although there is nothing to update.
    Another thing with updates: Discover found some theme updates. I updated them and next time I launched it, the same updates where shown so nothing happened. I should know, because one of the themes it tries to update is my own and I certainly didn’t post any update to it. So there is definitely some bug here. It may be possible that I messed something with themes in my system, hence the issue ;P.

    The updates is the biggest flaw. Rest are just cosmetics and Discovers really becomes something special. Your enthusiasm isn’t misguided. Also the whole blog is AWESOME! I really can’t wait for more exciting updates and I never felt so in touch with Plasma development. This blog should be one of main places to visit for Plasma news and it deserves much more subscriptions. Keep up good work and thanks your enthusiasm – it’s contagious 😀

    Like

    1. Thanks! I appreciate your willingness to give Discover another try. I believe we have an open bug for an improvement that would address your frustration with the update progress: https://bugs.kde.org/show_bug.cgi?id=390911 If that looks right, please feel free to leave a brief, positive, supportive comment in there.

      For the theme update issue, could you file a bug?

      Like

  4. Just noticed something weird and wondering if it’s even a bug :

    – Update Notification Plasmoid – as usual – shows there’s updates avaliable ( sometimes… it’s even right ) .
    – This time it shows there’s 3 updates avaliable, so i click, Discover opens and i see this :

    – Now… i have second thoughts… and decide to update my system ( KDE Neon ) through a terminal emulator .

    Funny thing: updating through the terminal doesn’t show any new package needing to be updated.

    – Back to the Update Notification Plasmoid … once again, those 3 updates from my screencap. Click on “update” … and apparently it updates everything properly.

    Afterwards… the notification plasmoid is still stuck on “updates avaliable” and if i open Discover it keeps showing an “event calendar” update ( this has been happening since a couple weeks already, when i tried & removed the event calendar plasmoid ) .

    Questions:

    1) How come those 2 system updates wouldn’t show when i tried to update through the terminal ?
    2) Any bug related to Discover receiving updates for removed plasmoids ? Searched for it and found nothing so far :/ … still not daring to file a bug if i’m not 100% sure i searched properly for it.

    Thanks a ton !

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s