Linux only question, may not be darktable specific: display full path in image information

Software darktable
1

Apologies if this is an operating system question, rather than a darktable application question - but somebody here is bound to know the answer:

I have ‘full path visible’ preference in the Image Information module set, but even with the left panel made as wide as possible part of the full path name is condensed to ‘…’. I expect that hovering over the path name should display it all - but it doesn’t (under Windows it does). Is this a setting in dt or do I have to dive into Mint 21 settings to ‘fix’ this?

P.S.: I find the same behaviour with the colour picker: hovering over the HLS data (for example) for a sample from a portrait image immediately gives me information about the ethnicity of the portrait subject - under Windows dt version 4.0.1, and under LMDE 5, with a master version 4.1.0 of dt - but not in dt 4.0.1 in Mint 21. Conclusion is that this looks like an issue with my instllation of Mint issue, and not with dt.

2

For me (opensuse leap 15.4), the full path name does show up when hovering (after a second or so). A quick look didn’t show me any settings defining this behaviour. The same for other fields showing the ellipsis.

Sorry, no idea where to look for this in Mint.

3

Probably more to do with Cinnamon than Mint itself.

I am using Mint 20.3 Cinnamon 5.2.7.

Image info expands properly when I hover.

4

Thanks for this. I haven’t yet seen any variable in my Cinnamon 5.4.12 settings which might change this behaviour - or am I missing something obvious ?

5

I don’t think it is something you can change. I only meant that the Cinnamon version was probably the important factor on how Darktable’s gui behaves.

6

This ‘feature’ in my Linux install of dt is analogous to ‘the princess and the pea’ fairy story: in practice it has almost zero effect on my ability to use dt on this install, but it is considerably irritating to have a function that doesn’t work, with no explanation of why.

So what I would like to ask this forum now is where else should I seek an explanation for mouse hover not working on this install of dt? I ask this because, even after extensive testing, I cannot determine if this is a hardware (principally motherboard), BIOS (which is UEFI), Linux Kernel, Mint, Cinnamon or dt-caused problem. Each of those categories has its own unique support system.

A quick overview of the problem:
hovering the mouse over the full path name field in the image information panel in lighttable does not result in the path name being fully expanded in a pop-up - on this specific installation of dt under linux.

History:
AFAIR the function did work on this system when using dt 4.0.1 and Mint 20.3 in October.
I first realised it was not working with dt 4.0.1 with Mint 21.0, and confirmed it with dt 4.2.0 on Mint 21.0 and Mint 21.1. Bruce Williams has kindly confirmed that the function works as expected with dt 4.2.0 and Mint 21 on his system.

In trying to understand what is causing the problem, I posted on forums.linuxmint.com but essentially drew a blank.

I have searched every known-to-me possible (and often improbable) settings in Cinnamon, which has upgraded to version 5.6.5 and to kernel 5.15.0-56-generic during this period, but with no effect on this behaviour.

I have tried using a wired mouse in place of my wireless one without changing the behaviour.

I have tried switching monitors, switching GPU, running with no GPU, running with Intel integrated graphics enabled - with varying amounts of memory - and completely disabled, with XHCI, XHCI Hand-off and EHCI Hand-off enabled and disabled. None of this has had any effect on the hover behaviour. The only hardware capability that I have not checked is memory - but I have never experienced a memory error in any application, even with a fully committed system while running VMware and VirtualBox.

So where should I go from here (the answer: ‘away’ is valid, but not productive…)?

7

Wayland vs Xorg?

8

Although it is not clear (to me, at least) that Cinnamon now supports or runs under Wayland, moving to that technology seems like an inadvisable risk for somebody with limited technical skills, such as myself. Moreover, others using Mint 21.1 Cinnamon with Xorg report that this ‘mouse hover’ functions correctly in both modules that I am aware of that use it (in image information module in lighttable and in colour picker module in darkroom), so it should not be necessary for me to switch to Wayland.

9

So you are saying you are using Xorg? This was not clear from your description of the problem.

10

Beg pardon; as you say, I did not make it clear if I was using Xorg, for the simple reason that I don’t know, beyond reasonable doubt, what the default display technology is for Mint Cinnamon. I had assumed it was/is Xorg on the basis that Xorg appears to be the default display server for the majority of Linux distros, and I have certainly never tried to change it, nor ever had the understanding to do so. So, yes, I am saying that the installation on which the function fails is running Xorg.

11

IIRC, Mint 21 is based on Ubuntu 22.04. Ubuntu defaulted to Wayland in 22.04. I ran into a problem with ART (yes, I know your problem is with dt) when installing its appimage on a clean install of Ubuntu 22.04, and switching to X solved it. The following is not my bug report, but it matched my symptoms and describes how to get back to X (on Ubuntu). Have a look for something similar on Mint.

12

For some of us (usually only me) the dawn of understanding arrives very slowly - often days later. At last, I realise that you were asking whether I am running Wayland or Xorg - I thought you were asking had I tried Wayand as part of my problem source identification efforts.

Thanks for not responding to my reply with expletives

I have now progressed a nanometre along the path of knowledge: I ran the command ‘echo $XDG_SESSION_TYPE’
Result: X11

13

Thanks for taking interest in my little drama. As I just replied to an earlier post, I ran ‘echo $XDG_SESSION_TYPE’ getting the result X11, so Wayland is innocent of causing this little local difficulty. And nobody else running Mint 21.0 or 21.1, under X11/Xorg, is reporting a problem, so we can eliminate the display server technology as being the cause.

14

I just re-read all the things you have tried to find the cause of the problem. The one place you don’t appear to have tried is within dt. It might be worthwhile to try renaming off your data.db and your darktablerc files so that dt creates fresh ones at startup. Then see if the problem goes away. This is not based on any knowledge on my part as to whether the behavior could be affected by something in either of these files, but it’s an easy test.

1 Like
15

Shocked. And delighted.
Having spent most of today going through the cycle of ‘choose installed application; make detailed note of name, version ID, re-load location; completely remove it; close dt; restart mint; open dt; test’ and having removed more than 30 apps, with no effect on the behaviour of dt, as a final test for today I followed your simple suggestion.
Problem immediately solved.
All that remains now is to reset preferences, reconfigure the collections preferences and re-install some of those apps.

Have you sold your soul to the devil to gain this insight? If so, where do I apply?

1 Like
16

Good to hear that this solved your problem.

You might want to compare your new and previous darktablerc to see if there are any differences that might be relevant. It would be good to do that to data.db as well, but would be more work. I totally get it if you don’t want to do that (after all, your problem is solved), but it might satisfy your curiosity a bit.

I might have sold my soul to the devil, but I still can’t play as well as Robert Johnson.

17

I immediately identify with this further suggestion from you: it is almost exactly what my brain had decided while I slept.

After all this work, much of which was based on the (uncertain) conviction that there was no functional defect in dt, I’m now not so sure about that conviction, so there could be benefit in raising an error report on GitHub (once I’ve more fully understood how to do that). I say that because the process I followed in implementing your suggestion involved the creation, by dt, of an entirely new instance of darktablerc - not a copy which might have propagated a faulty setting. A compare of the old and the new darktablerc files should establish beyond doubt if dt did, or did not, create a ‘faulty’ version. (I do have to allow for the differences in such fields as the naming patterns in session options in darktable preferences import section).

What fascinates me about this whole episode is that this faulty behaviour continued across an update (to data.db, I assume) when I moved from 4.0.1 to 4.2.0. This implies to me that,
if there is some form of data or consistency check of data.db (or darktablerc) (performed either at start-up or upon update), it is not sufficiently exacting to pick up what ever error existed in my system - and that could be a further reason to raise some report on GitHub.

I’m off now to joust against my ability to acquire new knowledge - namely about how to perform a textual and binary compare of 2 files.

Thank you for your continued support.

18

Hmmm. Not so easy as I thought. I used the diff command. Bearing in mind the old file is 52.1 kB while the new is 26.1 kB, and these are text files, the number of differences listed by diff is enormous - way, way beyond my attention span.

The real killer though is that I lost all my tagging (in which I invested over 3 weeks non-stop, in 2021) , all my styles are gone, lens correction presets are gone. The nett effect is that my dt install now is in need of more work than I can possibly do given the deadline (literally) I am working to. I’ll have to revert to the ‘faulty’ version and put up with it.

19

It’s a large haystack…fortunately there is probably only one needle to find. If you make copies of the new and old darktablerc, and sort the copies, it will reduce the work in searching. But I get it, you are up against a deadline.

20

If the problem is in darktablerc, why don’t you simply restore your old database and library files? That’s where your tags and styles live.