Wrong bottom bar height about nyxt HOT 50 CLOSED

Confirming it fixes it on my system.

from nyxt.

Tried

(define-configuration status-buffer
  ((height 40)))

and got

WARN - Warning: Error on separate thread: Cannot find class or structure STATUS-BUFFER

from nyxt.

Thanks for reporting. #3170 addresses this issue.

@jmercouris, friendly ping on reviewing the PR.

from nyxt.

hi there i am having same issue on my laptop using X11 and scaling issues cause similar ui problem @jmercouris please have a look at the PR if it resolve this issue thanks :)

from nyxt.

I, too, am experiencing this same issue on versions 3.9.0 and 3.9.1. I'm also on Arch.

from nyxt.

Sorry for the problem, I'll look at it hopefully on Monday :-)

from nyxt.

I have mentioned that #3170 addresses this issue but, on second thoughts, I don't think that's the case.

@ST-Saint, @apsinthium can you reproduce the issue when starting Nyxt via nyxt --failsafe? What about env GDK_SCALE=1 nyxt --failsafe or env GDK_SCALE=2 nyxt --failsafe?

@Aneeqasif are you also on Arch?

I can't reproduce the issue on Guix or Flatpak. It could be related to the fact that you're running WebKitGTK 2.42.1 on Arch, while both Flatpak and Guix are still using previous versions.

from nyxt.

@aadcg I can reproduce with all three of the suggestions you listed.

from nyxt.

@apsinthium thanks! I'm afraid I'll have to wait until I'm able to reproduce the issue.

I remind that only the Flatpak and Guix are official means of distributions curated by the team, which explains why this issue escaped the radar.

from nyxt.

Updating to note that this also happens with the flatpak version on Arch.

from nyxt.

@apsinthium that's really surprising. I can't reproduce it with flatpak.

Can you run flatpak update? Then try to reproduce the issue by issuing flatpak run engineer.atlas.Nyxt --failsafe. If you can reproduce, please share the output of flatpak run engineer.atlas.Nyxt --system-information.

from nyxt.

@aadcg The flatpak was already up-to-date, but I ran the update check anyway. flatpak run engineer.atlas.Nyxt --failsafe still had the issue. The output you requested is here:

Gtk-Message: 11:15:52.811: Failed to load module "xapp-gtk3-module"
Gtk-Message: 11:15:52.811: Failed to load module "canberra-gtk-module"
Nyxt version: 3.9.1
Renderer: GI-GTK
Operating system kernel: Linux 6.5.9-arch2-1
Lisp implementation: SBCL 2.3.9 (Dynamic space size: 3221225472)
Features: (:NYXT-GI-GTK :NYXT-GTK :NYXT-GI-GTK :NYXT-GTK :NYXT-3.9 :NYXT-3 :NYXT-3.9.1
 :CLIPBOARD-CONTENT-METHOD :SWANK :SLYNK :PLUMP-UTF-32 :PARENSCRIPT :NSYMBOLS
 :FSET-EXT-STRINGS :SBCL+SAFE-STANDARD-READTABLE :NAMED-READTABLES :FLATPAK
 :GLOBAL-VARS :CL-FAD :LPARALLEL :21BIT-CHARS :CUSTOM-HASH-TABLE-NATIVE
 :CL-PPCRE-UNICODE :CL-UNICODE :CL-JSON-DOUBLE-FLOAT-IS-SUBSUMED
 :CL-JSON-SINGLE-FLOAT-IS-SUBSUMED :CHUNGA :FLEXI-STREAMS :CL-PPCRE :WEBKIT2
 :WEBKIT-2.42.0 :WEBKIT-2.42 :WEBKIT-2 :WEBKIT2-CORS-ALLOWLIST
 :WEBKIT2-PASTE-PLAINTEXT :WEBKIT2-TRACKING :WEBKIT2-MUTE :WEBKIT2-EMOJI
 :WEBKIT2-MEDIA :WEBKIT2-SANDBOXING :GTK-3-22 :GTK-3-20 :GTK-3-18 :GTK-3-16
 :GTK-3-14 :GTK-3-12 :GTK-3-10 :GTK-3-8 :GTK-3-6 :GTK-3-4 :GTK :GDK-3-22
 :GDK-3-20 :GDK-3-18 :GDK-3-16 :GDK-3-14 :GDK-3-12 :GDK-3-10 :GDK-3-8 :GDK-3-6
 :GDK-3-4 :CAIRO-1-10 :CAIRO-1-12 :GDK-PIXBUF :CLOSER-MOP :GLIB-2-30 :GLIB-2-32
 :GLIB-2-34 :GLIB-2-36 :GLIB-2-38 :GLIB-2-40 :GLIB-2-42 :GLIB-2-44 :GLIB-2-46
 :GLIB-2-48 :GLIB-2-50 :GLIB-2-52 :GLIB-2-54 :GLIB-2-56 :GLIB-2-58 :GLIB
 :BORDEAUX-THREADS :LPARALLEL.WITH-CLTL2 :LPARALLEL.WITH-CAS
 :LPARALLEL.WITH-STEALING-SCHEDULER :SPLIT-SEQUENCE
 CFFI-FEATURES:FLAT-NAMESPACE CFFI-FEATURES:X86-64 CFFI-FEATURES:UNIX :CFFI
 CFFI-SYS::FLAT-NAMESPACE ALEXANDRIA::SEQUENCE-EMPTYP :FAST-IO-SV :FAST-IO
 :CL-JSON-CLOS :CL-JSON :SBCL-USES-SB-ROTATE-BYTE CHIPZ-SYSTEM:GRAY-STREAMS
 :THREAD-SUPPORT :ASDF3.3 :ASDF3.2 :ASDF3.1 :ASDF3 :ASDF2 :ASDF :OS-UNIX
 :NON-BASE-CHARS-EXIST-P :ASDF-UNICODE :ARENA-ALLOCATOR :X86-64 :GENCGC :64-BIT
 :ANSI-CL :COMMON-LISP :ELF :IEEE-FLOATING-POINT :LINUX :LITTLE-ENDIAN
 :PACKAGE-LOCAL-NICKNAMES :SB-LDB :SB-PACKAGE-LOCKS :SB-THREAD :SB-UNICODE
 :SBCL :UNIX)

ASDF version: 3.3.1
ASDF registries: (NYXT-SOURCE-REGISTRY ENVIRONMENT-SOURCE-REGISTRY)
Critical dependencies: (/run/build/nyxt/_build/cl-cffi-gtk/gtk/cl-cffi-gtk.asd
 /run/build/nyxt/_build/cl-gobject-introspection/cl-gobject-introspection.asd
 /run/build/nyxt/_build/cl-webkit/webkit2/cl-webkit2.asd)

from nyxt.

@apsinthium I've asked to run flatpak update since updating the Nyxt flatpak is different from updating Flatpak.

Apart from the fact that we're running different Linux kernel versions, I'm inclined to think that this might be due to graphics. Which window manager or desktop environment are you running? Xorg or Wayland? What's the output of env | grep SCALE?

from nyxt.

@aadcg My apologies. I don't use Flatpak anymore, so I had just installed it and it was the latest version. However, I ran the command again just to double-check. There were no updates for Flatpak itself.

I am running i3-wm on Xorg. There was no output for the requested command.

from nyxt.

Thanks again @apsinthium!

@jmercouris can you reproduce it on Flatpak?

from nyxt.

Yes, I can:

GDK_DPI_SCALE=2 flatpak run engineer.atlas.Nyxt

from nyxt.

I think the issue is this one: #1388

from nyxt.

@jmercouris, I see. I thought no one was using GDK_DPI_SCALE since that scales the text size alone, while GDK_SCALE scales everything.

@apsinthium does starting via GDK_DPI_SCALE=1 GDK_SCALE=2 nyxt (or GDK_DPI_SCALE=1 GDK_SCALE=2 flatpak run engineer.atlas.Nyxt) fix it for you? If not, it may be because you're scaling the display via xrandr.

from nyxt.

@aadcg Unfortunately, I uninstalled Flatpak since I still had the issue there. However, running the commands you listed for the arch package still has the same issue.

I do have to scale my screen because I have a high resolution display and everything is too tiny to see if I do not. Strangely, I didn't have this issue before 3.9.0.

from nyxt.

@apsinthium thanks for the feedback. Things start to make sense then. It doesn't seems directly related to Nyxt, while it is true that the UI should handle arbitrary display settings (hence #3170).

I think that probably Arch updated some dependency library and the same display config now results in a different behavior. I.e. it is not related to the release of 3.9.0.

It would be great if you could tell me exactly what display config is responsible for this issue. Also, could you try to run Nyxt from master? I believe that Arch provided such a package. Does it solve this issue? Thanks.

from nyxt.

1. It would be great if you could tell me exactly what display config is responsible for this issue.

Here's my xrandr output:

Screen 0: minimum 320 x 200, current 2560 x 1600, maximum 16384 x 16384
eDP-1 connected primary 2560x1600+0+0 (normal left inverted right x axis y axis) 344mm x 215mm
2560x1600 165.00*+ 60.00 + 59.99 59.97
2560x1440 59.99 59.99 59.96 59.95
2048x1536 85.00 75.00 60.00
1920x1440 85.00 75.00 60.00
1856x1392 75.00 60.01
1792x1344 75.00 60.01
2048x1152 59.99 59.98 59.90 59.91
1920x1200 59.88 59.95
1920x1080 60.01 59.97 59.96 59.93
1600x1200 85.00 75.00 70.00 65.00 60.00
1680x1050 59.95 59.88
1400x1050 74.76 59.98
1600x900 59.99 59.94 59.95 59.82
1280x1024 85.02 75.02 60.02
1400x900 59.96 59.88
1280x960 85.00 60.00
1440x810 60.00 59.97
1368x768 59.88 59.85
1280x800 59.99 59.97 59.81 59.91
1152x864 75.00
1280x720 60.00 59.99 59.86 59.74
1024x768 85.00 75.05 60.04 85.00 75.03 70.07 60.00
1024x768i 86.96
960x720 85.00 75.00 60.00
928x696 75.00 60.05
896x672 75.05 60.01
1024x576 59.95 59.96 59.90 59.82
960x600 59.93 60.00
832x624 74.55
960x540 59.96 59.99 59.63 59.82
800x600 85.00 75.00 70.00 65.00 60.00 85.14 72.19 75.00 60.32 56.25
840x525 60.01 59.88
864x486 59.92 59.57
700x525 74.76 59.98
800x450 59.95 59.82
640x512 85.02 75.02 60.02
700x450 59.96 59.88
640x480 85.09 60.00 85.01 72.81 75.00 59.94
720x405 59.51 58.99
720x400 85.04
684x384 59.88 59.85
640x400 59.88 59.98 85.08
576x432 75.00
640x360 59.86 59.83 59.84 59.32
640x350 85.08
512x384 85.00 75.03 70.07 60.00
512x384i 87.06
512x288 60.00 59.92
416x312 74.66
480x270 59.63 59.82
400x300 85.27 72.19 75.12 60.32 56.34
432x243 59.92 59.57
320x240 85.18 72.81 75.00 60.05
360x202 59.51 59.13
360x200 85.04
320x200 85.27
320x180 59.84 59.32
320x175 85.27
HDMI-1 disconnected (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
DP-3 disconnected (normal left inverted right x axis y axis)
DP-4 disconnected (normal left inverted right x axis y axis)
DP-1-0 disconnected (normal left inverted right x axis y axis)
DP-1-1 disconnected (normal left inverted right x axis y axis)
HDMI-1-0 disconnected (normal left inverted right x axis y axis)
DP-1-2 disconnected (normal left inverted right x axis y axis)
DP-1-3 disconnected (normal left inverted right x axis y axis)

And my .xinitrc just sets:

Xft.dpi: 192

Let me know if you need more information or if this isn't what you wanted.

2. Also, could you try to run Nyxt from master? I believe that Arch provided such a package.

I only see one package in the Arch repository. How would I go about running Nyxt from master?

from nyxt.

Xft.dpi: 192

My understanding is that GTK started treating this piece of config differently for some unknown reason. I expect that you'd set it to 96 and then start Nyxt via GDK_SCALE=2 nyxt, then it would be scaled properly.

I only see one package in the Arch repository. How would I go about running Nyxt from master?

I don't know much about Arch, but my understanding is that installing this package would install Nyxt from the tip of the master branch - https://aur.archlinux.org/packages/nyxt-git.

from nyxt.

@aadcg The nyxt-git package does, in fact, fix the status bar issue albeit the scaling is still off for fonts, but you've mentioned what you believe the issue is for that. Unfortunately, if I change my Xft.dpi then all of my other applications will be negatively affected.

from nyxt.

I don't think any further steps should be taken from our our side to mitigate this issue as of today.

Maybe we could ignore custom Xft.dpi values via https://docs.gtk.org/gtk4/property.Settings.gtk-xft-dpi.html, but it's a rather premature decision for now. The issue seems to impact Arch users alone and the root cause seems to be rather obscure. Waiting for more pieces of information.

if I change my Xft.dpi then all of my other applications will be negatively affected.

This is not related to Nyxt, but rather a piece of advice. For Qt and GTK apps, you may consider setting GDK_SCALE and QT_SCALE_FACTOR to 2.

from nyxt.

This is not only an arch issue as I'm having the same problem on nixos.

from nyxt.

@idrisr do you also set Xft.dpi?

from nyxt.

Yes, I set Xft.dpi=267. I rebuilt my configuration without that line and when I launched nyxt the entire window including the status bar was visible. Unfortunately I can't keep it that way as all UI elements on my screen are too small to read without me setting the Xft.dpi. I'm happy to help test possible solutions. Thanks!

from nyxt.

@idrisr although this has nothing to do with Nyxt, I repeat the advice I shared above

For Qt and GTK apps, you may consider setting GDK_SCALE and QT_SCALE_FACTOR to 2. (This way you may not need to rely on setting DPI).

If you're able to compile from master, you could test it. @apsinthium reported but it fixes the issue, but not completely. The font size will likely still look off.

from nyxt.

Just a question: why do other Qt/GTK apps scale properly without running the GDK_SCALE/QT_SCALE_FACTOR?

from nyxt.

@apsinthium I think that you're asking the right question.

What is a complete mystery to me is that, as far as I understand, you were always setting the DPI to a value higher than 96 and the status buffer was properly rendered.

Then you observed the issue and assumed that it was related to an updated Nyxt version.

Is that so?

from nyxt.

you were always setting the DPI to a value higher than 96 and the status buffer was properly rendered.

Yes, I was.

Then you observed the issue and assumed that it was related to an updated Nyxt version.

As I remember, the status bar was fine prior to 2.9.0. But, as I said, other Qt applications such as QtBrowser and Gqrx render properly. I don't use many GTK applications anymore, but GIMP and gThumb both have correct font sizes. That's the only reason I attributed it to an update.

from nyxt.

I think I will try to reproduce with different versions. Perhaps the CSS changes I made from em to px are considered in GTK sizing.

from nyxt.

@jmercouris I remind you that commit 5cd7bee, to which I think you're referring to, has never landed on any of the 3-series releases. In other words, it is completely unrelated.

If you mean that you'd like to tweak the CSS of the status buffer such that GDK_DPI_SCALE=2 nyxt will be rendered properly, then the stage is yours.

from nyxt.

I did mean that commit, yes. In that case, I have no more ideas. Will investigate later. This is not a high priority for me right now.

from nyxt.

I'll backport the changes from PR #3170 to mitigate this issue in the next 3-series release. The issue will persist nonetheless.

Not a priority at the moment.

from nyxt.

Also observed on openSUSE TW with Nyxt 3.9.2, resulting in a slight cut similar to the screenshot in #3244 (comment).

Using:

• i3wm
• Xft.dpi: 240 (17.3" laptop 4K panel)
• GDK_DPI_SCALE=0.5 GDK_SCALE=2

from nyxt.

EDIT: with Xft.dpi: 192, the bottom bar has the correct height.
So there is some kind of conflict between GTK 2x scaling specified with GDK_DPI_SCALE=0.5 GDK_SCALE=2 and 2.5x Xft font scaling specified with Xft.dpi: 240 (240 = 96 x 2.5). This does not cause a problem in other GTK programs.
The font scale should be taken into account to measure the height of the bottom bar.

from nyxt.

Why do you need to set Xft.dpi, GDK_DPI_SCALE and GDK_SCALE?

I think you should either the first one alone, or the third one alone.

from nyxt.

Because on my laptop panel screen (4K at 17.3") I need system-wide font scaling at 2.5x for them be comfortable to read (they are slightly too small at 2x). That panel physical dpi is 253 ppi and I opted for 240 as it correspond to 2.5x scaling which result in fonts whose size is very close to what they would be on a 1080p panel of the same size with no scaling.
GTK only supports scaling at 2x, hence GDK_DPI_SCALE=0.5 GDK_SCALE=2, which is fine as I can live with a 2x scaled UI (but not fonts!).

from nyxt.

Also Xft.dpi is system-wide and required for some other apps to scale properly, starting with i3wm, emacs and more.

from nyxt.

Release 3.10.0 may mitigate this issue.

from nyxt.

Please re-open in case the issue persists. Thanks.

from nyxt.

Just noting that the issue still persists on Arch.

from nyxt.

Are you running the latest version on Arch? With the fix applied?

from nyxt.

@jmercouris I'm on version 3.10.0 which was released in the Arch repository yesterday, so I believe it is the latest version.

from nyxt.

Interesting.

Let's try to understand what differs in the setup of @bubbleguuum and @apsinthium. Both set Xft.dpi.

To gather more information, share a screenshot of how the status buffer looks like when starting nyxt 3.10.0 via GDK_DPI_SCALE=1 GDK_SCALE=1 nyxt.

from nyxt.

Note that I get correct scaling with GDK_DPI_SCALE=0.5 GDK_SCALE=2, which is what I use for all my GTK apps for proper 2x UI scaling (in a non GNOME setup), in conjunction with Xft.dpi: 240 (2.5x font scaling). With GDK_DPI_SCALE=1 GDK_SCALE=1 the bottom bar scaling is indeed incorrect.

from nyxt.

Interesting.

Let's try to understand what differs in the setup of @bubbleguuum and @apsinthium. Both set Xft.dpi.

To gather more information, share a screenshot of how the status buffer looks like when starting nyxt 3.10.0 via GDK_DPI_SCALE=1 GDK_SCALE=1 nyxt.

I get correct scaling with GDK_DPI_SCALE=0.5 GDK_SCALE=2

@bubbleguuum's settings definitely look better on my screen. Again, the only reason I bring this to attention is none of my other GTK apps require starting this way so perhaps, one day, we could get to place where scaling is performed at automatically by Nyxt?

from nyxt.

Update: apologies, I forgot the issue at hand was the bottom bar being cut off/cutting off the input. The bar is positioned correctly. My issue is about scaling which is another topic. Sorry about that!

from nyxt.

the only reason I bring this to attention is none of my other GTK apps require starting this way so perhaps, one day, we could get to place where scaling is performed at automatically by Nyxt?

I understand your point and agree - this would certainly be desirable.

Right now, given the amount of more pressing issues, I find that fiddling with these GTK env variables is good enough. Thanks for understanding.

If someone knows how to fix it in a more robust way, PRs are certainly welcomed!

from nyxt.