Overall the direction sounds good.

I think the main focus for Flatpak/Flathub should be:

- Ensure any application on Flathub works as intended, with all functionality the user would expect to see working, without issues. If that isn't the case, use whatever 'temporary' solutions are necessary to make it so until better long term solutions are in place. No one is going to want to use Flathub to download applications if they experience too many occasions of applications not working due to mishandled sandboxing. Prioritising 'Everything must be sandboxed!' at the expense of functionality, is prioritising ideals over users, which will result in less/no growth over time.

- "Developers, developers, developers!"... laugh if you want, but Palmer was right when he said that. If you want to make a platform successful, make developers happy. It should not be assumed that developers will just 'figure it out', if you leave the pieces on the floor for them to pick up and assemble a solution. There should be a very straight forward 'hand holding' process for getting apps onto Flathub, and enough documentation that even a non-programmer can easily figure out how to get an app on Flathub.

- Finish the permissions system, and by that I mean, do the other 50% of the 'Android on Desktop' like permission system Flathub/Flatpak has started. Add APIs for apps to check if they have permissions they want, add APIs for apps to request permissions, list what permissions app are asking for before install, if permissions change with an app then list the changes, make it easy to grant/revoke permissions, notify the user when something is blocked by a lack of permissions (nothing is a greater source of user frustration than something failing silently without explanation), etc etc.

View this comment - View article - View full comments

Sounds like a great idea. There's room for free/open source stuff alongside 'pay what you want' stuff, and paid/subscription based commercial software, it all has it's place on Linux in my opinion and the more developers are encouraged to engage with Flatpak, Flathub and the Linux ecosystem, the better.

View this comment - View article - View full comments

Incredible numbers.. 83,000 new customers a day? Insane.

View this comment - View article - View full comments

Awesome work, hopefully it gets merged into DXVK one day.

View this comment - View article - View full comments

Quoting: Kimyrielle

Quoting: mr-victoryBut did they remove the necessity of the workaround for the Linux desktop? If they didn't but instead added fixes for Steam Deck, that's hilarious😂

I would not surprised seeing devs supporting Deck in the future, and still not caring about Linux, even when it's almost the same thing. Deck is "dev-friendly", because it's a defined system with known hardware and a known OS and it made mainsteam media, so it exists in their world.

Linux is still that "nerd operating system" that's hard to support because no two systems are the same, and people using don't want to spend money on software, anyway. Or so...

But hey, I expect issues like this one to be the exception rather than the norm, so it's all good.

I wonder if it would help to put together a 'Linux game development SDK' that includes documentation, build tools, tutorials, compile-able demos, debugging tools, and more, in a similar to fashion to how there is a Vulkan SDK.

View this comment - View article - View full comments

One year later, I've gone from whimpering like a puppy each time I see one online thinking I'll never have one because I live in Australia, to having owned one for about 4 to 5 months now. And in conclusion I'd say... Yes my whimpering like a puppy was totally justified because it's the coolest thing I own.

View this comment - View article - View full comments

I love this thing. Very cool. Love the idea of just bundling a game with everything it needs, emulator/compat tools/etc, and getting just a single exec file you can just run with a double click.

View this comment - View article - View full comments

In theory there's no reason why games couldn't use a new steamworks API that allows games to tell steamworks "These are the graphics settings we have and the options available".

Heck in most games, most games have the same graphics options. So all the API would need to do is specify which of those graphics options are available.

Basically an API call saying, "Hey Steamworks, so we have the following graphics options: Resolution, Frame Rate Limit, Draw Distance, Antialiasing, Texture Resolution, etc... And a couple of custom settings called 'Bell Sizes' and 'Number of Whistles' and here's the custom information about those options."

Then all which would be needed is some kind of API which allows a game to be told by Steamworks "Set your graphic settings to these values".

Then Valve could store graphics settings information with the performance profile when they're changed, shared, and apply them when switching profiles.

Obviously out of the box most games wouldn't support that, they'd have to add support for that, but there's no reason why they can't over time progressively get that feature in more and more games, just like Steam Input.

View this comment - View article - View full comments

Valve has certainly been doing a lot of bug fixes lately, which is good to see, there's no point having 'features' if you don't have a stable experience with those features. I hope once they've gotten through all the bug fixing, we see some additional features. Particularly for the onscreen keyboard, it could do with improvements.

View this comment - View article - View full comments

Maybe AMD could use Bink for Windows to translate from OpenGL to Vulkan too. Given how slow OpenGL is on AMD/Windows, I doubt Bink could be any slower.

View this comment - View article - View full comments