Closed evertvorster closed 7 months ago
The log looks fine. The App loads the profile correctly into memory and should update the graph that shows the profile.
The graph is drawn with cairo and the code tries to get the colors from the active theme so it looks nicely. However, the API used for receiving the colors was recently deprecated and was more a workaround than a robust solution anyway. This means that the graph could appear invisible on your device due to foreground and background having the same color.
I've just merged PR #47 to introduce a new mechanism for receiving the colors. Let me know whether this fixed your problem.
Hi there! I created a tailor-gui-git package in AUR that tracks the master branch, so it's easy to test changes in Arch. Unfortunately the fix did not work. I tried with breeze light and breeze dark color schemes to see if that would make a difference. Here is a screenshot of the breeze dark fan control:
If I click and drag in the window, I can see numbers, so it does look like the interface is working, but on my system you can't see what you are doing... I'll continue to poke at color schemes to see if I can make the graph show up.
That's interesting. I thought the new mechanism should be quite robust for selecting colors, but maybe that's not the problem in the first place. You could try changing the color to RGBA::RED
here to make sure it's not the color causing the problem.
Otherwise, you might use the inspector (Ctrl+Shift+D
) to look at the DrawingArea
and change its properties to find out whether it's properly displayed.
Unfortunately I am not a coder, much less in Rust, so the first suggestion I really don't know how to do.
With the second suggestion, it's also the first time I tried something like that, and I was unable to find a DrawingArea, much less modify it.
With the second suggestion, it's also the first time I tried something like that, and I was unable to find a DrawingArea, much less modify it.
You could try the following:
Ctrl+Shift+D
Another thing you could try would be to use CSS to change the background color of all widgets.
widget {
background: red;
}
Hi there!
Thanks for trying to help. When selecting magnifier, there is no graph displayed, and when turning the background red, this is what I get:
I started into X11 mode, and I see some graphical corruption on the tailor-gui... but also the graph!
On my system, at least, this issue seems related to Wayland.
No idea why I am getting the graphical corruption either, it's only on the tailor_gui, and the other applications I have tested seem fine.
Just FYI, when running in Wayland mode, I have nvidia_drm.modeset=1 as a kernel parameter. In order for X11 to work, I have to disable that.
Adding a bit more info here, I have fractional scaling of 120% on both of my monitors.
I am wondering if this could be an issue with Relm/GTK... :thinking:
@SimonBrandner I assume it's a GTK issue because Relm4 does not add any drawing code and just uses GTK widgets. Do you also have the issue?
Yes, I do have it (assuming since I am on Wayland - do we have anyone not seeing this on Wayland/seeing this on X11?) - I temporarily solved it by doing GDK_BACKEND=x11 tailor_gui
It works for me on Wayland without problems (just rebuilt everything with the release profile to make it sure it still works). It used to work as native installation as well on Fedora. Maybe NixOS has a different GTK version? You could also try to install it as flatpak from source (using GNOME Builder or Flatpak VSCode plugin).
So the weird thing is that when running the locally built version, it defaults to x11
, so the issue is not present, but when I run it with GDK_BACKEND=wayland ./result/bin/tailor_gui
, the issue is present
How are you starting it?
I just run it without any relevant environment variables (you can read the config from the flatpak manifest) so it defaults to wayland. I wonder why it defaults to X11 on your system when GTK prefers wayland for quite some time now AFAIK. What are other GTK apps choosing on your system?
I'd like to test the behavior of Flatpak on my system but I have trouble getting it to run... Do you perhaps have an idea of what's going on? There doesn't seem to be any org.freedesktop.Sdk.Extension.rust-stable/x86_64/45
flatpak package...
❯ flatpak install org.gnome.Sdk//45 org.freedesktop.Sdk.Extension.rust-stable//22.08 org.gnome.Platform//45 runtime/org.freedesktop.Sdk.Extension.llvm15//22.08
flatpak-builder --user flatpak_app tailor_gui/build-aux/com.github.aaronerhardt.Tailor.json
Note that the directories
'/var/lib/flatpak/exports/share'
'/home/simon/.local/share/flatpak/exports/share'
are not in the search path set by the XDG_DATA_DIRS environment variable, so
applications installed by Flatpak may not appear on your desktop until the
session is restarted.
Looking for matches…
Skipping: org.gnome.Sdk/x86_64/45 is already installed
Skipping: org.freedesktop.Sdk.Extension.rust-stable/x86_64/22.08 is already installed
Skipping: org.gnome.Platform/x86_64/45 is already installed
Skipping: org.freedesktop.Sdk.Extension.llvm15/x86_64/22.08 is already installed
Downloading sources
Initializing build dir
error: Requested extension org.freedesktop.Sdk.Extension.rust-stable/x86_64/45 not installed
Error: Child process exited with code 1
PS: Have you perhaps considered making a Discord Server/Matrix Room or Space for tuxedo-rs? I think it might be a little better for real-time discussions than GH...
In my experience, flatpak-builder is not the greatest tool to build flatpaks. GNOME Builder and VSCode with the Flatpak extension work like a charm though, you basically just need to click a button and it builds and runs the app.
I mean, I get one step further with flatpak-builder, but then it complains that Cargo.toml is missing...
Im running Nixos 23.11 with gtk scaling and experience the same problem on infinity book 14. Running GDK_SCALE=1 tailor_gui solves this for me.
Thanks for the hint. It actually seems to be related to monitoring scaling and I was able to replicate it (I only use 100% usually, so it never happened to me before). Once I find the cause, I'll try to come up with a patch.
I've now identified and fixed the cause. The bug was actually caused by the scaling of the window. One part of the code took the scaling into account and doubled the size of the canvas where the plot is drawn, but also added scaling to the canvas, so that the actual coordinates stayed identical. Another part of the code was not aware of the scaling and thought it needed twice as large coordinates. The code therefore created coordinates twice as large as they should have been, mostly drawing outside of the visible canvas.
You can already try out the fix in #60. I will merge the PR in the coming days and issue a new release of tuxedo-rs soon as well :)
Hi there!
I just tried version 0.2.4 of the tailor gui. I can confirm that with no scaling I now see the graph in fan control.
Unfortunately, if I scale my monitors the way I like them, the graph again does not show up.
I am running Wayland and KDE, and have one monitor scaled to 150% and the other to 120% (One monitor is QHD, and the other 4K)
However, it also does not show up when I set the two monitors to the same scaling, only when scaling is completely disabled.
If there is a newer version than 0.2.4 in the works, please feel free to close this report again.
I'm fairly new to this software, but in trying it out there seems to be a pretty bad bug on my system.
The GUI elements are missing in fan control.
Here are some screenshots:
About my system:
This is the log in the terminal, hopefully it provides some clue as to why the GUI elements are missing.