Xylight

• design: use common components for administration pages
• design: use common styles for vote buttons
• impr: add proper pageination to messages page, fix diffing desync
• feat: add autosubmit to URL autofill
• design: use Materials for highlights in comments
• fix: piefed poll vote api schema changes
• fix: markdown tables re-enable
• feat: add custom thumbnail option to PostForm
• feat: add piefed metadata generation
• design: redesign the profile block pages to not look awful
• fix: post polls causing a scroll to top
• feat: make comment guide borders clickable to collapse (like reddit)
• misc: skip client validation for linked instances
• feat: make command palette more obvious with a button in profile picture (ctrl + k guys) (or right click/hold on photon logo)

Full Changelog: https://github.com/Xyphyn/photon/compare/v2.2.1...v2.2.2

How do browser reading modes determine what is the main page content? They use different approaches and there’s no defined standard.

TLDR: after/if this is finished, Photon will support no-javascript usage a lot better with authentication and settings respected. It'll be more suitable as a default interface for Lemmy instances.

Photon currently is a client-side only app, with optional guest SSR. This works great as a web app, but not for SEO. While you can enable SSR for SEO, it is not authenticated and will lead to a flash of content from a guest user instead of your profile--making things clunky for actual users.

this pr aims to do the following:

• Rewrite app-side data to use a unified userHost object that can be filled with either data from a cookie, or localStorage.
• this will allow for a hybrid mode, where you can either use server-side user data or client-side user data.
• userHost data is stored in a JSON state, but can be loaded into reactive classes for the client/rendering.
• Instead of using global state in the form of profile or settings objects, use Svelte's getContext and setContext to access this data.
• Maintain a near-identical user experience for client-side instances, such as at phtn.app.

This will be relatively difficult, as I'll have to rewrite every instance of those globals being used, and I'll have to update all API calls to go through the server.

I'm using Arch currently and the following issues have been present on every install of Steam I've had:

• Controller inputs break constantly. If I use big picture mode, the games will be in some quasi state where it both detects my controller and doesn't.
• The menus take like 3 seconds to open.
• The right click menu in the system tray does not work 30% of the time.
• Worst of all, when I close a game, steam will not detect that it closes. Once this happens, no other page will load, no menus will open, and i have to killall steam -s SIGKILL, since no other signal works. It's also survived SIGKILL multiple times. How?
• In game, the shift+tab menu does not work; half the buttons are unresponsive and the game will crash upon closing shift+tab

The arch wiki had nothing on this.

Flatpak and native installs have the same problem, reinstallation does nothing, steam --reset does nothing.

These issues occur across multiple games with different engines.

It's very strange since I have a very generic system and most people seem to have great experiences.

Curious on the usage statistics.

Should I make a full survey asking about granularity so that app devs can see what to focus on?

Interesting article shared with me about the way Wi-Fi location services work.

Google has announced it is building a new way for 'experienced users' to install Android apps that haven't been verified.

test

Benchmarks look pretty good, even better than some of the text only models, make sure to take them with a grain of salt tho

Benchmarks

Qwen3 VL 30b a3b (No Thinking)

Visual benchmarks for Qwen3 VL 235 A22B (Thinking)