Shifted drop-down menus in darktable 4.6


A picture is worth a thousand words. Dt 4.6 has the drop-down menus shifted to the left and up.
OS: Arch Linux (ArcoLinux and Garuda - 6.6-LTS & 6.7-zen kernels respectively)
WM: Hyprland (Wayland)
CPU: AMD Ryzen 9 5950X & AMD Ryzen 7 7840U
GPU: AMD RX6750XT & 7840U APU
Mem: 64GB

Does this happen on X11?

I could not tell you as I do not run X11.

Well we aren’t really supporting Wayland, so knowing if this is a Wayland problem or not is the first step in troubleshooting. I certainly don’t see this with x11/i3wm.

That is a strange attitude to have as X11 is officially in hospice care. All of the X11 devs have been pulled to Wayland or defunded. Seeing as everyone is going Wayland, shouldn’t you address this issue? Fedora 40 will be Wayland by default, Cinnamon 6.0 has Wayland support, KDE is Wayland by default, and the list goes on. I realize that Wayland lacks a feature you would like to keep from X11, but deflecting these bugs as “Wayland issues” will make people look for software that works properly in their environment. The overall technical skill level of the average Linux user is declining as the popularity of the OS increases and the mainstream uses it more and more.

The issue is that (as I understand it) color management is problematic under Wayland. No keen photographer is going to move to something with even potential colour issues, as I see it.

Yes, that would be an issue for “keen photographers” as you say. However, letting dt degenerate because the platform isn’t up to snuff will not attract “keen photographers”. Who is working on color calibration in Wayland? Pull them into the conversation and get the ball rolling.

I don’t know - I actually run Windows for day-to-day work due to a couple of reasons, mostly outside of my photography hobby.
I run Debian on my old laptop though for my more experimental stuff. Anyway. Off topic, just wanted to clarify my position.
There’s a couple of long threads here on the subject.

Wayland color management - #618 by hatsnp

and

I have had the impression that the Wayland devs are not very interested in the finer points of color management, regardless of the fact that it’s a vital component. But I’m only going off hearsay so don’t take my word for it. I’m in no way qualified to judge!

1 Like

You see hospice care, i see feature complete and stable. There is a set of features that darktable needs from a display protocol, and wayland isn’t there. You can go on for as long as you want about how it is the future, and you’d be right. But it isn’t the present. I’ve had this exactly conversation way too many times. Wayland is not ready for applications that demand color mangement. I hope it is ready sooner rather than later. But it isn’t ready right now.

You can open a bug report on github if you’d like to participate in a fix.

And again, none of those softwares will have a full color management stack. So?

I asked you to do some troubleshooting, as you’re the one experiencing issues. I did not deflect, I tried to start the troubleshooting process but you declined to participate. That is on you, not on me.

And people can do whatever they’d like, if they’re looking for an open source raw editor that is working on wayland then they won’t find any.

There is absolutely no way to prove that one way or the other, I’m not even sure how its relevant here.

We’re not even sure if this is a dt issue or not. There are several layers that dt uses that are likelly to be the problem: xwayland, gtk3, or even the hyprland compositor. You have this pegged as a dt issues, but have done nothing to actually prove that.

We already had the conversation like six years ago, it was not pleasant, and that’s a large part of the reason why we are where we are. So pull in the wayland devs wont’ do anything because they don’t listen. They have started on HDR support and the spec for color management is close to getting merged into the specification. Sadly, unless there is some huge change to the pace of development, we’re likely several years off from wayland + working color management + the apps to actually do the color management + the apps that need color management all working together.

The wayland proponent’s attitude of “well you all better get on board” is really old and grates on many nerves. There are features necessary for color manged apps to function correctly and doing the work to get on a platform which doesn’t have the necessary features seems like a titanic waste of time. I am not sure why that is so difficult to understand.

4 Likes

I did not “decline to help you troubleshoot” I simply don’t have any X11 based Linux systems. I will have to spin up a virtual machine to accommodate you. Now that I am done for the day with all the stuff I have to do, I will do so and report back here.

2 Likes
  • I installed ArcoLinux+Cinnamon in a VM and can report that issue is not present in X11.
  • The reason the Wayland proponents say those grating things is because of the inertia surrounding X11. The main supporters of X11 development and maintenance (Redhat and Canonical) have ceased support for X11 (beyond emergency security fixes) and are dedicating themselves to push the ecosystem forward to Wayland.
  • A color-managed workflow is unimportant to computer nerds so they need to be educated as to why it is important.
  • There is a bug already opened for this on Github and I have added my $0.02 to the fray.

I repeat, darktable devs taking a 'we don’t support Wayland" attitude will not engender any love from the Wayland devs. It also doesn’t help that this nonsense is what keeps non-computer nerd photographers away from Linux as a platform.

We don’t need love from them, we need working color management.

I agree, not having the necessary features for a professional style workflow is a complete non starter for Wayland. If color management does come, it’ll probably be. a cluster fuck since Wayland makes every compositor handle it on their own. So gnome with have different issues.from plasma that’ll be different from wlroots. AWESOME.

2 Likes

Based on what I have seen on the PR thread, they are more concerned with implementing HDR as that is desired by gamers and media buffs which is a far larger audience than Linux Photographers. TBH, the way things are going, I am going to have to save up money for an M3 Mac Studio.

I have a hard time believing that red hat will let all the blender boxes just dangle… But there is probably still 5 years before those types of workstations upgrade to anything that has Wayland.

Just tried on Fedora 39 fully updated. Radeon RX 6600. Darktable built from latest branch 4.6.x. Could not reproduce on XFCE, Gnome X11, Gnome Wayland. Menus look just fine.

2 Likes

But why is it hard to support Wayland to work with DT, even without the color management?

I mean working like being stable with OpenCL and everything. It doesn’t need to be 100% feature complete (it’s not, obviously), but DT should start supporting it, working on stability and speed fixes.

As of now, wherever someone says DT on Wayland the first line that comes from the devs is “we don’t support W”.

I suspect it’s just that no devs are motivated to work on it because they don’t use it, because colour management doesn’t work. Contributions are always welcome from developers who want to add such fixes.

Remember code contributions are made by volunteers and we don’t have any “obligations” to our “customers”

3 Likes

“We don’t support ” doesn’t mean there’s no work done on preparing such support, only that you cannot expect any in case of problems.

And it’s not enough that darktable itself is changed to work with wayland, underlying libraries/subsystems like GTK also have to work under wayland.

I’m not familiar with Gnome and GTK. Will GTK work under Wayland soon? If so, GTK3 or GTK4? I know it’s a long way for DT to support gtk4.

Plasma 6 that’s out in February will treat W as default.

Gtk4 already works with Wayland. Or rather, mutter, the window manager is a Wayland compositor.

Doesn’t matter to darktable.