feat(gui): add live log panel

[kakra]

Summary

Organize the main vkShade window into tabs and add an integrated live-log viewer.

• move the existing effect controls into an Effects tab
• retain up to 2,000 recent messages in the thread-safe logger
• add a Log tab without polling or reopening the configured log file
• provide Pause, and Follow controls
• keep the log scrollable while new messages arrive
• color complete log rows by severity using restrained, theme-relative colors
• de-emphasize trace and debug output while keeping warnings and errors easy to scan

Testing

• rebased onto the current main
• release build with meson compile -C build
• git diff --check
• the live-log controls, and level coloring were smoke-tested under ETS2 via Proton/XWayland
• the configured Meson build currently contains no test targets

[ralgar]

Hey! I'd still like to get this merged, but with the log colorization included as well - I didn't realize it was separate from these two commits.

However this is going to conflict slightly with a refactor I've been planning on the GUI code, so I'll give you a choice in how you want to approach it.

1. Either we merge this mostly as-is and I'll hop in after and do the refactor.
2. I do the refactor first and give you a clean base to rebase this PR on top of.

It likely won't make a huge difference either way in practice, so it's your call. I'm somewhat leaning towards just merging it now, since I'd like to make a release after I get the file watching merged and it would be cool to have this one merged as well.

[kakra]

Yes, let me add the colorization, then we can get this merged.

[kakra]

since I'd like to make a release after I get the file watching merged

Should I rebase my mouse fixes, too? It's not yet tested for wayland and should not touch any existing wayland functionality. But it improves mouse handling with X11 which is still the default in official Proton.

[kakra]

Would you like to add "effects enable control" (#75), too? Then I can cherry-pick it into this PR...

[ralgar]

since I'd like to make a release after I get the file watching merged

Should I rebase my mouse fixes, too? It's not yet tested for wayland and should not touch any existing wayland functionality. But it improves mouse handling with X11 which is still the default in official Proton.

I'd rather the input backends move in lockstep for releases. So, for the v0.0.13 release, if one backend has mouse wheel support, then all of them should.

So I will probably leave that PR open for now. If it's complete, I'll merge it after the v0.0.13 release. If you're not set up to do the Wayland side, just let me know and I'll open a separate PR after we merge the X11 side. That's not a problem.

[kakra]

If you're not set up to do the Wayland side, ...

Sure, it can wait. I'll keep relevant PRs rebased if needed. Let me see if I can properly test wayland wheel handling here, if yes, I'll amend the PR.

But the mouse wheel patch isn't the bigger mouse capture change, that's still queued locally here. I'll push a draft PR after next release is done, it will most likely cause rebase conflicts with your refactoring.

[ralgar]

Would you like to add "effects enable control" (#75), too? Then I can cherry-pick it into this PR...

I'm gonna say leave this one for now too. I only took a quick look at it, but the commit itself needs rebasing anyway and I would also want to change how the state is stored.

I mostly just want to get this in-GUI logging merged in for now. Along with the preset and file watcher it'll make for a pretty drastic increase in usability. Then v0.0.14 will add more of the front end work and polish.

[ralgar]

Sure, it can wait. I'll keep relevant PRs rebased if needed. Let me see if I can properly test wayland wheel handling here, if yes, I'll amend the PR.

I'm not sure what your desktop setup is like, but if you're running a Wayland compositor then I find vkcube to be convenient and adequate for basic testing. It supports all 3 input backends using the --wsi <xcb|xlib|wayland> argument. It wouldn't be adequate for your mouse capture patch, but for the mouse wheel testing it would be fine.

But the mouse wheel patch isn't the bigger mouse capture change, that's still queued locally here. I'll push a draft PR after next release is done, it will most likely cause rebase conflicts with your refactoring.

Sounds good. If there are conflicts they should be minimal, I'm not planning to mess with the input plumbing. That may not be true actually, but any changes there should be minimally invasive at least. =D

[kakra]

I'm not sure what your desktop setup is like, but if you're running a Wayland compositor

I'm running KDE Plasma on Gentoo with most Xorg elements of the system removed (first of all, the classic Xorg server and session are gone). Of course, Xwayland still exists. Testing with vkcube actually looks like a good idea, at least for the simple things. For mouse capture, I would test with a selection of different games:

• ETS2 because it has very strange and difficult mouse grab and mouse capture semantics
• Hogward's Legacy because it moves the OS cursor even outside the game window using the controller
• Elite Dangerous because I know its full screen, capture/grab and focus quirks well
• Maybe another game

For testing backends, the thing is: I'm not using a wayland-enabled Proton build here. I tried once some months ago and it didn't work properly. So I'm waiting for official support from Proton - it will probably be aroud Q1 2027.

Of course, I can more easily test SDL backend using native games. But we should take care that these are not just another wine-like wrapper around the native Windows version like the Feral titles.

So currently I'm just testing Xwayland on kwin when using Proton.

[kakra]

Maybe I understood wrong but didn't you want to merge this for v0.13, before we add more GUI work for v0.14. Or did you plan to merge this only for v0.14 anyways?

[ralgar]

Hi, sorry. You're correct, that is what I had intended. I reviewed these changes previously and thought they were ready to merge as-is, but on a second review I realized there were a few things that still needed work. For example, the Copy button on the log tab doesn't do anything yet because we don't have the system keyboard input plumbing in place.

I decided to go ahead and push v0.0.13 right away because of the huge usability boost it brings.

There were a couple of architectural considerations as well, and I realized it would be easier to do a small, general GUI refactor first and then build this feature on top of that. I've already got most of that cooked up, so I'm actively following up on this rather than shelving it.

I'll definitely credit you for doing this exploratory work, though. It was useful for figuring out the direction I want to take it.

Just a heads up as well: I already have the mipmap work and the COLOR_BUFFER_BIT_DEPTH work in my own patch queue from a while ago, so I'll probably prioritize those simply because it's easier for me to work through changes I've already got locally than to review someone else's work. Once I get caught up with everything, I'll get you to rebase your other ReShade texture commits, and we'll work through those. Hopefully it shouldn't take too long, I can see it all coming together finally.

[kakra]

Thanks for the update. :-) There's no problem with rebases on my side, so please proceed according to your plans. For now, we can use my PRs to track which upstream work is already done or which of my commits have been already replaced by your queued and upstreamed commits. From the conflicts that show up, I can also check which functional differences remain and what I should recheck on my side. So all is good. We probably have a similar workflow keeping multiple different commits in an integration branch for testing, then cherry-picking commit series from it for publishing.

I think sometimes it's just useful to have someone indicating that your own work is actually used to get things going again. I know this from my own projects. :-)

Really looking forward to your mipmap and color depth changes, then rebasing my work onto it.

Let's get things moving. \o/

[ralgar]

We probably have a similar workflow keeping multiple different commits in an integration branch for testing, then cherry-picking commit series from it for publishing.

Yeah, this sounds pretty similar to what I do. I use a lot of stashes as well.

I think sometimes it's just useful to have someone indicating that your own work is actually used to get things going again. I know this from my own projects. :-)

Very true, a little motivation goes a long way. I definitely appreciate your enthusiasm towards the project! Part of my problem was also burn-out - too much computer time in general, plus I worked vkShade for months straight to get it this far.

Feels like the ball is rolling again though. =)

[kakra]

Part of my problem was also burn-out

Yeah, I can feel that. Please value your health, don't feel rushed. Just leave a note that you may need more time to review or evaluate my proposed changes.

plus I worked vkShade for months straight to get it this far

Yes, and that effort shows. I chose your project because it looked well planned, does the proper plumbing before the features, and most important: It had recent commits and seemed active. I previously used vkBasalt, back when it has been new, but never used it much (mostly because it lacked support for many shaders). And now that I had an actual use case (ETS2), vkBasalt looked completely stale and outdated.

Great work, very appreciated. And I think, your community (which hopefully will grow with the new changes) will feel the same. Maybe put a ko-fi link somewhere. For xpadneo, that has been very helpful: I got donations to buy different Xbox controller models or third-party clones to implement support for it, and one or another thankful coffee. :-)

[ralgar]

Please value your health, don't feel rushed.

No worries, I am feeling much better after my time away! I'm pretty eager to get vkShade up to v0.1.

Yes, and that effort shows. I chose your project because it looked well planned, does the proper plumbing before the features, and most important: It had recent commits and seemed active. Great work, very appreciated.

Thank you for the kind words. I actually started this project about 2.5 years ago originally, as a vkBasalt fork, but I abandoned it after a short while because I realized it wasn't going to work out how I wanted. Ever since, I've been working on a custom game engine to better learn systems and graphics programming.

It feels good to know all that effort's paid off, and I can contribute something cool to the Linux gaming scene!

Maybe put a ko-fi link somewhere.

I may look into that. I do this purely for the love of the game, but I'm not opposed to accepting tips. :)

[ralgar]

Closing this now that #92 is merged