Please do not post a support request without first reading and following the advice in

Announcing Pegasus Frontend

  • @PlayingKarrde actually at the moment none of my themes use custom sorting, they just use the default by-name order (yeah, I should really fix the filter panel in the default theme). Unlike graphical things though, sorting shouldn't be a performance bottleneck, so you can use it wherever you'd like to, eg. in the same file where you'd display a list of games is fine too.
    In practice when you have a model of which you want to have a sorted or filtered version, eg. api.allGames, instead of using it directly you'd create a SortFilterProxyModel, set the api.allGames as its input, and use this new object as the model of say, ListView. Here's a short example for using SortFilterProxyModel here:, and you can find the theme update commits around the bottom part of this comment.

    As for the current selection, in my themes the collections and games are often managed in different files (eg. a system selector bar), so yes, in these case I had to route the collection (or its index) from one file to another. To do this, you can use the fact that propertyes of an item are accessible in its parent, and so can be set up as parameters for other objects.
    In the ES2 theme for example, the Collection screen has a currentCollection property that is updated when the collection changes. This property is accessible in its parent, ie. theme.qml, where then it is set (bound) as the value of the Details screen's similarly named property, here. So whenever the collection changes on the Collection screen, the Details screen's property is updated accordingly.
    For the reverse direction (changing the collection from the Details screen), I emit signals where I ask the Collection screen to select the next/prev collection. These are also handled in theme.qml, cause the Collection screen to change the current collection property, and in turn update the Details screen too. This also keeps the two screens in sync.

    Now this is just one way to do it, managing top-level index properties in theme.qml is also certainly a possibility (and I think I've used it in one of the themes). You can do whichever fits your use case or theme structure better.

    I did notice that it isn't pulling the year from the metadata

    Hm could you explain that a bit? Does it fails to read the release date from the metadata files?

  • @fluffypillow Yep I handled all my collection and game selection handling at the theme.qml level and either passed them down through bindings or used signals coming up to affect them. To be honest I think this way is actually a lot cleaner as now there's only one place I need to worry about controlling this information, although I've definitely had to get creative with naming haha.

    I actually haven't looked into sorting too much yet but will likely take a look at this today. It definitely seems very powerful. Would you liken it to doing a SQL request? If so there are definitely some cool things I'd like to try.

    Hm could you explain that a bit? Does it fails to read the release date from the metadata files?

    Year, month and day don't seem to pull anything back when called. I just get an undefined value. Release works so I guess I could just format that, but just wanted to let you know.

  • @PlayingKarrde

    Would you liken it to doing a SQL request?

    In terms of sorting and filtering a selection, yes, kind of like that. Nothing to JOIN though :)

    Year, month and day don't seem to pull anything back when called.

    Ah yes, they got renamed to releaseYear, etc. a few releases ago, then forgot to update the docs. But considering that these can be queried with simple JS calls too, it might be better to just remove them altogether.

  • @fluffypillow Ah perfect I'll just use the JS call instead thanks.

    BTW, do you happen to know how to get a gridview to automatically scroll to the correct index if it's loading from memory? The correct item is selected but the view won't switch to it unless I change the index first.

  • @PlayingKarrde I think it should scroll there if the index is changed after the view is initialized, ie. in Component.onCompleted or later, like here. If that doesn't seem to work, you can also scroll there manually with positionViewAtIndex.

  • Weekly update: the metadata changes are now complete and tested, now I'm in the middle of updating the third-party data sources and cleaning things up. This shouldn't take long. What's left is updating the documentation and adding a way to convert to the new format from the old files. This one may take a bit of time. After all these are done, the changes can finally land so you can expect a megapost in one of these weeks.

  • @fluffypillow I'm trying to implement the sorting but getting this error when importing the SortFilterProxyModel.

    module "SortFilterProxyModel" is not installed

  • @PlayingKarrde should be fixed now, thanks!

  • @fluffypillow Thanks.

    Also I'll move future discussion to the theme thread instead since I realise I've been clogging up this one with all these questions that would only be applicable to theme makers... Whoops sorry!

  • Phew, all right, the metadata changes are finally here! There are still a few missing things, but the file format part is done and the rest will come as follow-up patches. This is a breaking change, so feel free to remain on an older version if you don't want to mess with the update right now. The previous-latest version (up until yesterday) for all platforms is also still available here.

    Here's what changed:

    • The format of collections.txt and metadata.txt is now united
      • You can now define both collections and games in the same file and only one of them is enough to be present in a directory.
      • Pegasus will try to open collections.pegasus.txt, metadata.pegasus.txt, collections.txt and metadata.txt(in this order) and stops at the first file it founds. (I've put collections first so at least your collections will be found after the update. I'll move metadata first in the next, more stable release.)
    • Metadata file format changes
      • Haven't finished the documentation yet, but a draft is available here.
      • Games can now consist of more than one file, and as such game entries are defined by their title (game:), and not a filename.
      • A cleaner difference between text values and lists
      • Empty lines now have to be marked with a single dot. This makes the multiline texts, like long descriptions continuous, avoiding the "text flying in the middle of nowhere" kind of effect. It also makes the format closer to the Debian config format (on which it is based on in the first place).
    • Updated the format converter tool
      • It's available here
      • You can now convert between the old ("alpha 10") and the new format
      • Fixed some minor bugs as well

    Here's what's still missing:

    • Documentation
    • Actual launching support for games with multiple files
    • Custom names and properties for the individual files
    • Theme support for accessing the launchable entries

    Now these changes involved changing quite a large part of the internal code; I've tried to test most of the things, but there might be still bugs lurking around (including the converter page). Testing would be much appreciated!

    Developers: the commit before this change is 9f38c2b.

  • @fluffypillow I noticed builds are still meant for the pi2. Will building specifically for the pi3 offer any performance benefits?

  • @Darksavior actually it may! In addition an update to Qt also comes out next month, which might bring some performance improvements, so I do plan to do some experimenting with additional build targets then.

  • I know this is a huge task so really just curious about this right now, but do you have any plans to integrate adding/modifying etc collections or roms into Pegasus itself at some point?

    It's still alpha I know but I have to assume that ease of adding systems and roms would be one of the huge main wants from the majority of users. Needing extensive documentation for creating game lists surely isn't sustainable long term so just wondering what your thoughts are on this.

  • @fluffypillow
    forgive me for asking maybe a bit of a stupid question.
    I'm a Retropie user, running Pegasus from my RPi.

    Pegasus is awesome for me, therefore I'm reluctant to update to newest version, since these last many updates have been regarding metadata and pc/android things that I don't understand. I was glad to have the launch menu with "favorites" toggle, and the pageup/pagedown functionality (week 67 'ish)... Since then I don't think I have updated Pegasus.

    If you compare the metadata of EmulationStation (my games are all scraped so they work in ES also) and these new metadata for Pegasus, what will the difference/benefits be?

    I'm not interested in manually adding metadata to thousands of games..

    I'm just trying to ask; what am I missing out on, if I don't use these new metadata possibilities?

  • @fluffypillow
    By the way; did anyone else ever have issues getting into the runcommand launch menu? (buttonpress after launch image).
    I can't enter these menus to save my life, so I have to use emulationstation to test other emulators etc. Very frustrating.

  • @PlayingKarrde well that's an interesting topic; personally I'd prefer the "one program does one thing" kind of approach, but I do see that'd be uncomfortable in a frontend's case (similarly to the lack of built-in scraper). So in the long term, yes, it'd be a feature nice to have, but at the moment I still see several areas in our current state which could be improved before then.

    Creating a small management tool sounds like a fun project though, so I'll likely start with that first. Then, if it turns out well, it could be also merged into Pegasus itself eventually.

    @AndersHP yeah I was trying to group a bunch of breaking changes together this time between Alpha 10 and the next, Alpha 11 to get them done (with Android TV being a small extra). With this many changes I certainly plan to write a summary page before the stable release as well.

    Most of the last update changes only a few points of the existing format's text style. The major difference however is that Pegasus' metadata format now support multiple files per game. If you have lots of multi-disc games for example, you can make them appear only once, as a single game, then select the actual disc on launch. It could be used for other creative things, like listing arcade clones under one main game too.

    There are still a few missing bits though, so no need to hurry. You also don't need to write files manually from scratch, you can use the format converter tool linked above to help converting between the formats. Pegasus' format is kind of like ES' systems config and gamelist in one file, but local to a particular directory.


    I'm afraid I can't test it this weekend, but I can take a look next week.

  • @fluffypillow said in Announcing Pegasus Frontend:

    Creating a small management tool sounds like a fun project though, so I'll likely start with that first.

    I think that would be ideal. I sort of agree with your philosophy of one program does one thing well, but I'm mainly thinking about the people who run this from Pis or Android devices where having another tool isn't really possible. An external tool would be fantastic for me personally though.

  • No updates this week because I've got cold :/

  • @AndersHP sorry for the late reply, runcommand seems to work fine for me, using Pi3 + Logitech F310. The button layout was slightly off though, but that's probably fixable.

  • No updates this week either, but likely there'll be in the next one! I've also started experimenting with the new Qt release, the builds are complete but I'll want to test them on real hardware before pushing an update.

    On a related note, I also plan to make some maintenance-related changes:

    • Raspberry: Debian Wheezy reached its end-of-life last year, and thus it's no longer supported (did that even work?). By "not supported" I mean the official builds will likely not run out of the box there, but you can still build it manually if you wish. Jessie may continued to be supported on ARM.
    • Desktop Linux: Ubuntu 14.04 reaches its end-of-life soon, and it's no longer supported (16.04 still is). For other desktop distros: the Linux release now requires C++14 support (GCC 5.1+ or Clang 3.4+). Shouldn't be a problem in 2019, but do tell me if it's an issue.
    • Maintainers: In the future, Qt 5.12 will become the minimal required Qt version for Pegasus. (If you aren't building Pegasus from source, this doesn't affect you)

Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.

Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.