Email or username:

Password:

Forgot your password?
12 posts total
Alice :neocat_trans_cute:‮

Okay, so I received the steam deck :3

Lots of impressions, both good and bad. Ofc one of my main goals is to run highscore on it, so it will be focused on that.

First yes, I did install bazzite instead of steamos - KDE is not very pleasant on a touchscreen, and well, I only read that it has steam+x shortcut for osk after I reinstalled it. It also doesn't have very well working portals - I failed to install firmware in highscore, file chooser just stops responding after a few invocations. Dark style also doesn't work, and inspector shows that it's just not supported, so there's no portal that provides it. Finally, GTK4 on X11 is rather glitchy...

Bazzite is fine after cleaning it up, so yeah. It has a lot of preinstalled crap (compared to steamos too btw), but well, it can be removed. At least now it runs GNOME and Wayland in desktop mode.

Third - gamepad support is confusing. It's a bit sad that Steam's own gamepad mapping system does not allow to map L4/L5/R4/R5 to unique button codes. You also cannot use the ... and Steam buttons, so well, there aren't enough buttons to use Highscore as a non-steam game in steam mode. Also, gamescope apparently doesn't support popups, so uhh - no menus.

I did manage to get it to sorta kinda work by mapping R5 to Esc - the game menu opens both on gamepad menu button and esc. So it's technically playable, but uhh, not well. Also the window opens letterboxed for some reason, until you open and close a game. Overall, not a very good experience. Some things can be fixed (e.g. if I detect gamescope and fullscreen the window right away), some can't (being unable to use the extra buttons).

In desktop mode however it mostly works, but needs tweaks.

First, Steam must not be running. Steam really wants to remap the gamepad and maps it to a keyboard layout basically. That's not a bad thing on its own, except ofc in highscore you want to use analog sticks, and you can't with this system.

If you hold the menu button for like a second, it will switch from desktop to gamepad layout, and now highscore can use it... except for, once again, the ..., steam and back buttons. So that's still a no.

It also autostarts steam, tho that can be prevented.

If you close steam entirely, it's still a desktop layout... But if you hold the menu button now, it will actually give the raw input, and now every button works. The catch? Touchpads stop working.

So - well, can't win. Maybe it's possible to extend libmanette to make use of the steam gamepad system and somehow get raw input while steam is running? I don't know, but otherwise you have to choose between working gamepad and working touchpad. ​:02_shrug:​

However, that caveat aside, it works really well. Everything runs, games work. There is an artifact with the NTSC shader, but it's probably a bug in my shader poer, I'm missing something like precision highp float. We'll see.

Fullscreen is horrible with touch as usual, but that's a GNOME design issue.

Meanwhile, for running steam games it ofc works perfectly, but that's to be expected ^^

Okay, so I received the steam deck :3

Lots of impressions, both good and bad. Ofc one of my main goals is to run highscore on it, so it will be focused on that.

First yes, I did install bazzite instead of steamos - KDE is not very pleasant on a touchscreen, and well, I only read that it has steam+x shortcut for osk after I reinstalled it. It also doesn't have very well working portals - I failed to install firmware in highscore, file chooser just stops responding after a few invocations. Dark style...

Screenshot of Highscore running on Steam Deck, showing a few Sega Genesis games
Screenshot of Highscore running on Steam Deck, showing the original Sonic the Hedgehog with NTSC+CRT filter
Alice :neocat_trans_cute:‮

haven't had any technical posts here in a while :3

I just released libadwaita 1.6.0, see the blog post for details: https://blogs.gnome.org/alicem/2024/09/13/libadwaita-1-6/

Alice :neocat_trans_cute:‮

A few more accent color things landed, e.g. settings illustrations can now follow it, calculator has dropped orange, new dialogs disambiguate suggested/destructive styles, while papers and sysprof properly redraw when accent changes now (and it's all in gnome os, incl. shell finally). So yeah, it's all in a fairly good shape now ^^ (other than blue folders)

GNOME with green wallpaper and accent color. It shows:

- Text editor with save dialog open
- Nautilus with open as dialog open
- Settings showing mouse settings
- Papers with text selection
- Sysprof with a graph and a column view
- Calculator
Same, but with a grey wallpaper and slate accent
Same, but dark, with a dark purple wallpaper and purple accent. Papers is in night mode
Same, but dark, with a dark red/purple wallpaper and red accent. Papers is in night mode
Alice :neocat_trans_cute:‮

Well, here we are :3

Everything shown here is merged as of today

Alice :neocat_trans_cute:‮

another teaser owo

This is actually showing a new thing compared to what we had a year ago and compared to @brainblasted@crab.garden's recent screenshots - treeview and about dialog links update properly, previously they didn't - this required a bunch of fixes in GTK and an awful workaround in libadwaita because I didn't want to deal with treeview code (it's deprecated anyway, one more reason to move away from it)

Alice :neocat_trans_cute:‮

I wrote a blog post about the recent work in GTK to modernize its CSS engine, and the implications for apps using GTK and libadwaita: https://blogs.gnome.org/alicem/2024/06/07/css-happenings/

- What got added
- What got deprecated
- What changed in libadwaita to make use of the new stuff
- What didn't make it tho I wish it did
- What to expect in future

Alice :neocat_trans_cute:‮

I present you: a floof ​:neocat_floof_cute:​

Photo of me while holding Nova
Alice :neocat_trans_cute:‮

So, CSS variable support has landed in GTK, and libadwaita now uses it. Note that it's super basic for now, it's just replacements for the old @colors. There will be more drastic changes in 2.0, but for now I need to keep backwards compatibility.

So, apps can now override them per widget, like on the screenshot (well, once the sdk updates, anyway)

And because why not, there are a few changes that variables enabled:

.error, .warning and .success style classes now also change the accent color respectively. For example, this means that a selectable label with .error style class will have a red selection as well, instead of blue.

The .opaque style class for buttons has been deprecated - instead, apps can simply use .suggested-action and override the accent color on it (or add .error/.warning/.success - that works too). This will also change the focus ring, and similarly, .destructive-action buttons have red focus rings now.

Apps are encouraged to migrate, but the old colors will keep working until 2.0. For example, @accent_color can be replaced with var(--accent-color) and so on, note the dashes in the names instead of underscores. See the docs for more info: https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/css-variables.html

So, CSS variable support has landed in GTK, and libadwaita now uses it. Note that it's super basic for now, it's just replacements for the old @colors. There will be more drastic changes in 2.0, but for now I need to keep backwards compatibility.

So, apps can now override them per widget, like on the screenshot (well, once the sdk updates, anyway)

And because why not, there are a few changes that variables enabled:

.error, .warning and .success style classes now also change the accent color respectively....

Screenshot of 2 switches in libadwaita demo, with one of them being purple instead of blue. Below is inspector, showing CSS tab, with the following css:

.alternate-row {
  --accent-bg-color: var(--purple-3);
}
Sergey Bugaev

@alice I'm guessing there's no public API to get a color variable's value for a widget programmatically, is there? Basically I'd want something like the existing Widget::get_color, but with a name argument.

Alice :neocat_trans_cute:‮

Well, the dialogs have landed ^^

There's a migration guide too:
https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/migrating-to-adaptive-dialogs.html

They aren't in the nightly SDK yet, but should be fairly soon.

Go Up