Announcing Pegasus Frontend

[fluffypillow]

@EctoOne Actually Pegasus is flexible enough to add support for both Skraper and RetroArch thumbnails and keeping the current media layout. (Never used RetroArch's dowloader though, will need to look into that first.) There could also be some cross-platform program or script that converts from one format to another and back.

tinymediamanager

Yes, a proper metadata and asset editor would certainly come handy. Might as well take a look into that after the metadata format changes :)

[EctoOne]

@fluffypillow Awesome. Oh and RetroArchs just downloads pre-made packages for the available systems. Can't find the actual package links right now but the github page is here: https://github.com/libretro/libretro-thumbnails

[fluffypillow]

[Weekly update] This week was a bit busy for me, so there are only just a few bugfixes:

• Fixed Android navigation issues
• Increased the delay before the videos load in the main theme, hopefully this fixes the Steam issues on Windows
• Updated the Flixnet theme

As for other issues:

@SephirothX2004 about the WikiPad issue from a few days ago, could you send me the log file of a failing launch? The full file, and if possible also your collection files, eg. zipped together uploaded somewhere?

@EctoOne @Purg-Derren I've confirmed the ES, Flixnet and 9999999 themes should show the correct system names. Could you check if the issues still happen after updating them? If yes, could you also zip+upload your log and collection files (that cause the issue)?

@PlayingKarrde about some of the logos are appearing black, can you show me a fixed one? I'd be interested what exactly causes the issue (eg. it's something in the file or a bug in the renderer).

[herb_fargus]

@fluffypillow >some of the logos are appearing black,

I'm almost positive it's a rendering thing. The megadrive logo is one of the worst offenders, probably due to the gradient on it. Because emulation station used an older renderer people drew the svgs in a particular way to get them to render properly.

[PlayingKarrde]

@herb_fargus it is a rendering thing for sure but I think it's a Qt issue. When I get back to my PC I'll share a before and after svg.

[fluffypillow]

Ok so here are the metadata/theme-api breaking changes I'm planning.
First, the metadata format:

• The format of collections.txt and metadata.txt would be united, so only one of them will be enough.
• The relevant part of the documentation would be replaced with this draft.
• The two major points are:
  • A clean difference between text values and file lists in the format
  • Games can consist of more than one file, and as such game entries are defined by their title (game:), and not a filename.
• Individual files can have custom properties, like name or special launch command, if needed. On the UI side, this would mean you could select the file to launch when starting a game with multiple files. The dialog would be themeable.

As for themes, this is a bit more experimental, as I'll need to do some implementation tests first. Plans are:

• The game- and collection list will be optimized so it could appear in multiple locations at the same time. For example, a recently played list and a regular game list on the same screen.
• An interface for getting the list of all available games (independent of collections) will be added.
• The shortcuts api.currentCollection and api.currentGame will be removed
• Due to technical reasons, <game>.play() will likely be removed. Instead, games will likely have an id field, and there would be something like api.launchGame(gameId) to use. [This part still needs some experimenting]
• api.launchGame(gameId) would open a file launch dialog mentioned at the metadata part (if needed for the game). There would be something like api.launchGameFile(...) in case you want to implement your own launch dialog.
• For sorting and filtering, you could expect something like this (well, if everything works fine, exactly that).

As for theme options, that's even more experimental. I'm torn between two options, the "let you save anything but require you to write a GUI panel" and the "define the possible options and let Pegasus show them in a common menu". The second option would be more themer friendly I think, but of course that's more work for me :)

If that wins though, the options would be defined in the theme.cfg, something like this:

option: Toggle Gadget X
type: switch
default: off

option: Alignment of That
type: select
options:
  Left
  Right
  Center
default: Left

option: UI Color
type: color
default: #abc

Well at least these are the plans. As always, comments are welcome!

[Purg.Derren]

@fluffypillow

 could you also zip+upload your log and collection files (that cause the issue)?

That was a hint! ^^ ... i had a (copy pasted) typo in the psx collections.txt (and psp one) -.-"

The new build of pegasus i can't really test yet ...my anti virus (it periodically do it, with some of your builds) blocks the alpha 10-3 ...even if i put it to exception, it really lags as hell (and i think thats why the anti virus sees a malware there) ...video playback seems not to start at all etc.

[Purg.Derren]

@fluffypillow that sounds really great! :)
Theme options and unified "gamelist"-file (and multi-disc/multiple-files - yay!)

[PlayingKarrde]

Some thoughts after using it extensively for a few weeks now and in multiple different scenarios:

While I like the changes to collections and gamelists, I am not convinced this is the necessary step to take. Right now I would say the number one issue that's holding the launcher back from being open the a mass audience is adding games. Currently, my flow to add a game is add the rom file to my folder, scrape the entire folder again (which takes sometimes as long as 45 minutes on large collections - it has to scrape everything each time due to Pegasus using it's own media file structure), run a script I had to write to organize the media, take the gamelist file the scraper made and drop it in the conversion tool, then replace the metadata.txt with this new info (and if I've made any changes to specific games those will get overwritten unless I'm very careful). This is just to add one game.

The only reason willing to do all that work is because I really see the potential in the launcher and think it will be the best launcher hands down when all said and done.

So combining the collection and metadata sounds good when looking at it in a bubble, but if anything it will make it more difficult with the current workflow. The same goes for multi-disc games - fantastic addition but unless the workflow is made more streamlined it will potentially get in the way more than it currently does (if it were to read .m3u files that might be more convenient).

I guess what I'm getting at is if you have a roadmap for features, working on how users add games should be a top priority. If these changes are necessary in order to reach that goal then great, but ultimately having users manually edit text files should be an absolute last resort for any usable piece of software in my opinion.

[PlayingKarrde]

@fluffypillow regarding theme options, I don't mind either way to be honest. I think if there was a template example then many theme creators could just hack that together to create something pretty easily. Having a unified one might be nicer for the launcher overall, but I think if theme makers are able to learn qml (which isn't that hard) they can put together a settings screen fairly easily. My comment about usability doesn't apply so much to theme creators as much really.

[herb_fargus]

I think everyone will have their own opinion on how to organise things. Personally I'm all for simplicity so if things can be consolidated the more the better. I've personally never cared for collections so it's not as much of a priority for me.

[PlayingKarrde]

@herb_fargus simplicity is king. But the concept of collections are necessary otherwise how would you know if you are selecting a snes game vs a mame game for example.

[herb_fargus]

@PlayingKarrde

otherwise how would you know if you are selecting a snes game vs a mame game for example

I sort by console. Not Mario games.

[PlayingKarrde]

@herb_fargus Right, and in this case that's what collections do.

[fluffypillow]

@PlayingKarrde I agree the workflow being less than optimal at the moment. However, the reason I prioritize format updates is exactly because it'd be more difficult to add changes after people start making tools, videos or guides that would depend on some stability. I can also start making, say, a metadata editor program more easily when the planned changes don't loom over my head.

As for what Skraper does and supports, that's not something I can control. When I run on just ~600 NES games and said over 5 hours left, you bet that really made me want to write a scraper too. That said, support for its assets can be added, and will likely come this week. Also looks like it can export metadata in a frontend-independent way too, which might be usable. But if a use case requires you to convert between different file formats of incompatible programs, you'll always need some manual interaction.

[PlayingKarrde]

@fluffypillow Yep, totally understand. I think maybe my comment came off a bit more confrontational than I intended. I think I'm just trying to explain the potential I see but the main thing still holding it back. Long term if it was as easy to use as, say Plex, it could potentially be the most popular launcher out there.

But it sounds like you are thinking long term so I'm on board with the changes you mentioned. I agree with everything else you say.

[fluffypillow]

@PlayingKarrde No worries, I do appreciate your concerns about the future of Pegasus. Hope I can show its full potential eventually!

---

On another topic, for yesterday's theme Api changes, forgot to mention that the key handling will change too, after I finally implement the key modifier (Ctrl, Shift, etc.) support. When checking keys, instead of passing the key code (eg. api.keys.isAccept(event.key)) you'd pass the whole event as parameter. The returned array types of keys.accept()and co. will also change.

Other than themes, because the modifiers modify regular keys, setting Ctrl and such "alone" will no longer work. The change will also require a one-time reset of the key settings, due to changes in the way keys are stored in the settings file. This update will come in one of the weekly releases (maybe the next one?) so don't worry about randomly loosing settings.

[PlayingKarrde]

@fluffypillow said in Announcing Pegasus Frontend:

after I finally implement the key modifier (Ctrl, Shift, etc.)

Just out of curiosity, what do you see the modifiers being used for? I'm assuming this was discussed/requested above but I didn't see it.

[fluffypillow]

@PlayingKarrde It was initially requested as a workaround for C64 keyboard issues, around here. Other than that, it'd also allow setting possibly more intuitive bindings, like Ctrl+F for searching or Ctrl+Left/Right to change collections.

[PlayingKarrde]

@fluffypillow Ah I see. So it's just for bindings then? (ie not giving new functions through modifiers).

I have a quick question that I can't seem to find the answer for: do you know of any way to properly format text from the metadata? I'm noticing that double line breaks (or paragraphs) aren't being accounted for at all.