Announcing Pegasus Frontend

[msheehan79]

@fluffypillow Ok no worries! Just glad you could replicate the issue your end so I know it's not just some goofy issue with my specific setup. I'll keep an eye on your git updates and can retest once you do have time to implement a fix.

Thanks for looking into this!

[PlayingKarrde]

@jerzeeloon do you mind sharing your settings for the shield?

Also, plus one here for proper Shield support. It really is an amazing emulator machine. I test all my changes for my theme on it but haven't spent any time getting the actual launching of games going. It's definitely a pain launching it from the sideload launcher too (I haven't even figured out how to get a shortcut on the home screen yet haha).

If quitting games goes back to the home screen rather than the launcher that kind sucks though :( I was considering moving my main emulation platform over to it but may have to stick with PC if that's the case.

[jerzeeloon]

@PlayingKarrde I hear you my current scenario is that I have a potato laptop and shield is my only avenue for retro gaming for the moment, until I can save up to build a gaming PC. This frontend suits my needs but I would like to find a way to return to frontend on emulator exit and use external storage rom paths. Cheers to you for the great theme it's what I'm currently using. My current setup is quick and dirty as I just copied a few systems over from my external for testing and I'm actually using paid for standalone .emu apps for launching snes, Genesis and the free MupenFZ from the play store for N64 cause it was less parameters then retroarch but I plan on trying retroarch launching soon. Anyways here's the settings I'm currently using

collection: snes
extension: sfc,smc
launch: am start --user 0 -a android.intent.action.VIEW -n
com.explusalpha.Snes9xPlus/com.imagine.BaseActivity
-d "file://{file.path}"

collection: N64
extension: v64,z64,n64
launch: am start --user 0 -a android.intent.action.VIEW -n org.mupen64plusae.v3.fzurita/paulscode.android.mupen64plusae.SplashActivity -d "file://{file.path}"

collection: Genesis
extension: gen,md
launch: am start --user 0 -a android.intent.action.VIEW -n com.explusalpha.MdEmu/com.imagine.BaseActivity -d "file://{file.path}"

[fluffypillow]

Weekly update!

• In progress
  • Initial implementation of the metadata changes is done, I'll write tests and finish what's left the next week (or two)
• Android TV improvements
  • Pegasus is now a proper TV app and should no longer require sideloading (however it wasn't tested on actual hardware, so feel free to report if something doesn't work)
  • Added higher resolution launch icons for devices with huge screen resolutions

[jerzeeloon]

@fluffypillow Thank you so much for adding proper Android TV support. This is already imo the best frontend on Android and the fact that it's still considered alpha and your dedication to continuous improvement is relentless. I can only fathom how great it will be in the future. Thank you.

[PlayingKarrde]

@fluffypillow I'm having another go at updating my theme but due to the scale I'm still struggling a bit. I'm just wondering, now that there's no concept of a current collection or current game you're doing the sorting and getting of those manually. I'm just wondering how you're handling that. Are you doing it all at the theme.qml level and sending those IDs down to each of your subsequent pages? Handling all game and collection management at the top level then? I mean that seems like the most efficient way but I just want to make sure before I go too far down that rabbit hole. I only have short bursts of time to spend on the theme these days so I'm not able to commit enough of a chunk of time to figure it out completely on my own.

-edit- no matter. I went ahead with this method anyway and I've gotten it all updated. Now I can look into implementing some of these new features I was badgering you about haha

I did notice that it isn't pulling the year from the metadata. Is this part of your current updates?

[fluffypillow]

@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: http://pegasus-frontend.org/docs/themes/api/#sorting-and-filtering, 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?

[PlayingKarrde]

@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.

[fluffypillow]

@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.

[PlayingKarrde]

@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.

[fluffypillow]

@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.

[fluffypillow]

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.

[PlayingKarrde]

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

module "SortFilterProxyModel" is not installed

[fluffypillow]

@PlayingKarrde should be fixed now, thanks!

[PlayingKarrde]

@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!

[fluffypillow]

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.

[Darksavior]

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

[fluffypillow]

@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.

[PlayingKarrde]

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.

[AndersHP]

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