Grip-3.6.3, possibly other versions:
The track list window is not rendered quite correctly. A little too much width is allocated to the track list, while the 'Rip' column is barely wide enough to accommodate the checkbix itself, leaving the 'Rip' column heading mostly obscured and unreadable. The minimum display width of the Rip column needs to be increased to at least the width of its heading, not the checkbox.
This is a mostly cosmetic defect that does not actually affect functionality, but it could confuse users unfamiliar with the application, and ... what can I say, I sweat the details and it bothers me. :)
I've looked through the source code trying to figure out a patch myself, but I've so far failed to find where in the code this column width is actually set.
Just FYI: Still present in 4.0.0.
And I don't know how to fix it…
But thank you for the update. :-)
Ah well, maybe someone else will be able to figure it out and offer a patch. :)
The recent UI overhaul DID fix all of the other UI glitches that I was aware of.
(Now if only I knew a way to fix the issue of SATA CD/DVD/BD drives on Linux often requiring 'eject' to be hit twice or more before they actually open... but that's not a Grip bug, it's a system-level problem.)
If you could point me at where in the code the UI layout is set up, I'd be glad to look at it and see if I can figure out the problem.
I just revisited this again and THIS TIME I found where the interface is set up. And the patch is stupidly simple, it is literally a one-line change to a numeric constant.
Good catch!
But does the increased width need to be that much?
Would 30 or 35 be enouch?
Also, on my physical system I don't see this behaviour.
It dynamically adjusts the sizes inside the program window dependent on the translation, and I dont know why it does.
I do remember on older systems I ran it did do just what you describe.
On 2/10/22 06:07, Solbu wrote:
I tried 50 first and it wasn't quite there. 75 seems just about right
... on a 4K display.
Could it be dependent upon the versions of some dependencies?
--
Phil Stracchino
Babylon Communications
phils@caerllewys.net
phil@co.ordinate.org
Landline: +1.603.293.8485
Mobile: +1.603.998.6958
Well, here is a link to screenshots of how it looks on my 1920x1080 screen resolution.
https://www.solbu.net/bilder/screenshoots/grip/
As t dependencies, I run Mageia 7 which came out in 2019.
I have attached a list of the dependencies and versions my build VM wanted to install (as a result of «sudo urpmi --buildrequires SPECS/grip.spec») when I was recompiling grip earlier today.
On 2/10/22 10:09, Solbu wrote:
These are corresponding screenshots on my 4K display:
https://www.caerllewys.net/public/grip-unpatched.png
https://www.caerllewys.net/public/grip-patched.png
I notice you're running GTK+ 2.24.32 and Wayland. I have 2.24.33 and
vanilla xorg-server-21.1.3 without Wayland. This doesn't strike me as a
Wayland problem though. Possibly only occurs on high-resolution displays?
depgraph output isn't getting along well with markup even when marked as code, so here's a link instead: https://www.caerllewys.net/public/grip-depgraph.txt
Last edit: Phil Stracchino 2022-02-10
I don't have Gnome installed, if that's what you're implying. I run the KDE/Plasma desktop in Mageia 7.
I only have the GTK development packages, and the packages needed for Grip to run. Grip was originally made specifically for Gnome, back in the day.
What would be interesting to know is if your 4K display would render it properly if you ran it in KDE/Plasma.
Neither do I. :) I run fvwm2.
I wasn't implying anything about desktop environment. I wouldn't THINK that the environment is going to have any impact on rendering inside the application window, but I've been wrong before.