Home Artists Posts Import Register
The Offical Matrix Groupchat is online! >>CLICK HERE<<

Content

Hello everyone!

I have another summary of what's been happening with Playnite 11 since my last update post.

Web views

I finally decided what to do with web views that I mentioned in previous dev post. I ended up using library that mostly works fine and is multiplatform. Although that multiplatform support is currently limited to Windows and Mac, no Linux yet (there is some progress being made on that front). That's obviously not ideal into the future if I decide to do Linux port (which is more likely than Mac port), but it's the best solution right now for Playnite. One other option was commercial web view component that does support Linux (and generally looks way more polished than CefGlue one) but would cost $4700 per year for me to be able to use it in Playnite and I can't currently justify spending so much on a single component.


Description and notes

One of the planned changes to descriptions and notes was switching from HTML to Markdown. Markdown is way easier to work with when doing manual editing and while it doesn't provide as many formatting options as HTML, it is, in my opinion, perfectly usable for descriptions and notes in Playnite. Especially since store descriptions usually don't utilize advanced HTML formatting anyways (by looking at Steam, GOG and other stores). One problem with supporting Makdown only was what to do with existing HTML descriptions from P10 and metadata plugins that only provide HTML. I decided to support both in P11, with some limitations.

As usual, big issue presented itself: how do I render these HTMLs and Markdowns in P11 using Avalonia. In P10, we are using HTML rendering control (not a full fat web view) that's no longer being developed (for years now and Playnite actually uses my custom fork with some changes) but it was ported to Avalonia. Unfortunately, all the limitations that were there in WPF version are still present in Avalonia version. Mainly not so great performance with large documents and practically no way to add custom elements into the document (this is mainly an issue if I wanted to add support for videos in future). So that was not a real option. There is 3rd party Markdown rendering control for Avalonia, which also supports rendering of HTML (surprisingly), has ok performance, but has one major drawback, you can't select text in rendered document. This wouldn't be a big issue in description, but it is major issues for notes fields. So right now I'm exploring other options with making custom control that will be able to render Markdown and limited HTML.

Update: Before posting this I checked and literarily yesterday they released experimental build with selection support in Markdown control I mentioned. So current the plan is to use that instead of custom implementation unless I come across other issues with it.


Emulation support rework, again

It the previous post I mentioned my plan to reverse from doing emulation support completely as a separate plugin and going back to more extendable built-in feature. After couple experimental versions, I decided to go back to the original plan and make emulation support as external plugin instead. For one, emulation games incredibly complicates the entire code base, you need to have exceptions and special branches everywhere if a game is emulated due to more complex configuration and startup procedure. This was really demotivating me after rewriting everything in more maintainable/clean way during switch to .NET 8. The other issue is that planned expandability with their own "plugins" would be additional major effort during addon database rework.


Having this as an external plugin will not only make core code based way more nicer to work with, but will have other advantages:

  • I realized that doing emulation support "extensions" will be probably way more effort on people's side compared to just making pull request to an existing plugin with updated profiles or some small code change.

  • Dogfooding of the SDK. 1) This will force me to use the SDK even more than previously which should help me to identify usability issues sooner than it goes out there to plugin devs. 2) To have emulation support usable as an external plugin will require additional features added to the SDK that will benefit other plugins as well. As an example, there will have to be a way to transfer data between plugins since Playnite itself will no longer store or provide info about assigned ROMs.


Some thoughts about Avalonia and UI framework switch in P11

Working with Avalonia for some time now, I realized one thing, I'm not having "fun" when working with it. It's very hard for me to get into the zone and just work on Playnite with it. I still find myself quite often stopping and having to deal with random things that don't work as expected, are missing (compared to WPF) or have non-existent documentation. There's a lot of things they do very well compared to WPF (performance and better styling system for example), but almost two decades of improvements to WPF shows in comparison how Avalonia is still missing a lot of things that would make it real joy to work with. Not even talking about missing components that I have to reimplement or work around, but I already mentioned some of those in previous posts.


Don't get me wrong, I don't expect two decades of polish from Avalonia right now, but developer experience still has ton of space for improvements. What I also realized  however is that I'm not the only person that has to interact with Avalonia in relation to this project, all plugin and theme developers will have too. Which brings me to big issue: if I personally, relatively experienced developer and person already familiar with Avalonia, is not having much fun with it, it will be even worse for hobbyists that make extensions for Playnite. Which I'm afraid might discourage people from making these extensions or at least not supporting them very well.


For that reason I spent some time refactoring Playnite's code base to be more UI framework agnostic and I'm kind of considering switching back to WPF if things don't improve on Avalonia's side (mainly in tooling and documentation space). Obviously releasing P11 with WPF would have big negative impact into the future, mainly because Avalonia switch later (which has to happen, it's just a matter of when) would mean another breaking release to all plugins and themes. Which again circles back to trying to make working on Playnite extensions good experience problem, because most people won't find reworking their extensions again to be fun, probably.


What would help with Avalonia experience would be making custom tools for Playnite theming (there's nothing like Blend for Avalonia right now) and improving their documentation (which is open for contributions), but I not very keen on working on UI library instead of working on Playnite.


So yeah, undecided right now about what to do. Keep using WPF and pay the price later on with another extension breaking release. Or switch to Avalonia now and pay with bad extension developer experience on P11 release.


Alpha release plan

Here's the plan for first version you should be able to try out. It will be alpha release that will come with Desktop mode only. The reason being that Fullscreen mode is still in complicated situation when it comes to features available in Avalonia. For example, things like keyboard navigation are unusable and I really don't want to implement custom input system from scratch (there's test version of Avalonia that apparently has some improvements to this, but I haven't tried it out yet). The other problematic thing is that I want plugin devs to be able to make controller friendly views in Fullscreen mode and that's been more complex than I originally thought.


This alpha will also probably not include theming system at first as well, so it will be mainly to get feedback for general feature changes and to get feedback on reworked plugin SDK.
Don't know release date for this alpha yet, mainly because I haven't decided whether to keep WPF or not yet, but I would really like to have it available in less than two months from now.

P10 state

I also made another look at P10 to see if I can port back some changes done in P11 (I don't want Playnite to like dead project since there's no activity on P10 front), but sadly the fact that P10 is stuck on old version of .NET makes any backporting without making breaking changes to the SDK very difficult.

I could probably port some features that explicitly only add new functionality and don't change anything existing, like achievements support, but I don't think it would be worth the time spent on it since it would be ton of effort since I would have to rewrite quite a lot for code to make it run on old .NET that's used in P10.

Closing thoughts

I'm once again sorry that I'm not bringing more positive news (mainly related to WPF vs Avalonia stuff), but this switch to new .NET runtime together with switch to new UI framework has been really challenging for me. Hopefully the next update will be more positive and have alpha build for you to try out.

As always, thank you very much for continued support and patience!

Josef

Comments

Kyle

Excited to read about progress that might get Playnite closer to a linux version. Playnite is likely to be the frontend of choice for the Steam Deck.

shakeyourbunny

Yes, I cannot wait for that. Currently, my installation runs in a KVM box and I tried the whole day to devise a way to remotely execute (on the linux host) a game from within Playnite, but to no avail.

ram

Thanks for sharing the various trials and considerations you're making while developing P11. It's unfortunate you can't backport features to P10, but totally makes sense why you wouldn't want to put the time necessary into it. If/when Playnite gets a Linux port, I'll be moving my system to Linux as well. This is definitely a must-have software for me. As far as Avalonia goes, sucks to hear the tooling just isn't there yet. The apps I've seen switch to Avalonia result in a much cleaner and faster experience, so I do really hope that it's feasible for P11. If not though, I'll just have to look forward to when it *does* become feasible.

Roman Pleteñ

Thanks for the update🤗 I think it's better to make a switch earlier since it's inevitable. Also, I don't think that it make sense to backport features to P10 when the development of P11 is already started and we are patiently wait any new of it :) It's better to focus all the affords on P11 at this point. The thing worth mentioning that Fullscreen mode is what separates the Playnite from the rest of the similar software because it's a must have for the handhelds which are on the rise right now.

Tvgold

Thanks for the info, nice update, hope this makes supporting other platforms easier if you want to down the line :)

Jason Ericson

I know this is super late but I just want to encourage you, Playnite is one of my favorite gaming-related tools *ever*, and you’re killing it. Personally, while I completely understand your thinking about WPF vs Avalonia (it’s extremely important for a developer to think about quality of life!) I really hope you stick with it - I know that I’ll be one of, I’m sure, many who is ready to pitch in on linux support once Playnite is built on a more cross-platform base. 🙂

Jason Ericson

Oh also wanted to add, your frustrations about Avalonia made me laugh a little bit cause that’s how I felt about WPF ~15 years ago. 😂 Glad to hear WPF has gotten better, I was not sure it ever would! But hey, good sign I guess that there’s hope for Avalonia one day.

shakeyourbunny

If anything that proves both Avalonia and WPF are a dead end, is there a consideration to port Playnite to QT?

playnite

QT doesn't have production ready mature C# support. Avalonia or WPF are the only realistic choices for this project.