Adds a new action to pin images from the film roll in the 2nd window and support for D&D.

[masterpiga]

This adds the ability to pin an image directly from the thumbtable, which makes it possible to show different images in the 2nd window while keeping the same image in the main window.

It adds a context menu to the images in the thumbtable, which for the moment contains only this one action.

It also fixes a bug that may cause darktable to crash when the 2nd window is toggled off and on very quickly, which may try to recreate the window while the previous one has not finished clearing up yet.

@TurboGit This is another follow up to #19963.

[TurboGit]

@masterpiga : I'm not sure about this one because it introduces for the first time a contextual menu on the lighttable and why pin an image on the lighttable while the second window is actionable only on the darkroom.

[wpferguson]

My first thought was this would be like Pandora's box mating with Frankenstein.

My thoughts about why we shouldn't

• shortcut is much faster and almost no code. A menu requires a click to open, then reading until the correct item is found, then clicking again and all of the code to support that.
• we can also use actions on selected image(s)
• if we have a context menu, then whatever keystroke is used to trigger it is lost as a shortcut (unless the menu is shortcut enabled)
• more work for the translators
• some translations may not work well with a menu (i.e. the problem we just had with Italian translations)
• if we open this door, then the next one will be in darkroom
• we will get bombarded with feature requests to add whatever to the context menu (see above mating reference)
• we have to support it, not just the code but the user expectations ("the menu should work like this and not like that...")
• it's one more thing we'll have to port to GTK 4
• if we decide to merge we need to come up with a standard spelling out what's acceptable in the menu and what's not (and stick to it). Preferably before we merge so that we're ready for the storm. My expectation is users will want to run darktable almost entirely (or as much as possible) from the right click menu.

All of the above is just quickly off the top of my head.

[masterpiga]

Thanks for your feedback, @TurboGit and @wpferguson! Please find my responses below.

@TurboGit:

I'm not sure about this one because it introduces for the first time a contextual menu on the lighttable and why pin an image on the lighttable while the second window is actionable only on the darkroom.

This adds a contextual menu to the thumbtable in the darkroom, it has no effect on the lighttable. Maybe I didn't understand what you mean?

@wpferguson:

• we can also use actions on selected image(s)

Fair point, even though it is way less discoverable.

if we have a context menu, then whatever keystroke is used to trigger it is lost as a shortcut (unless the menu is shortcut enabled)

Not sure I understand this. Shortcuts can be assigned to trigger directly the individual actions AND to opening the menu, if so we desire.

more work for the translators

Every new feature, unless it is completely hidden from the user, entails some of that. In this case we are talking about one single short string, which is as little as it gets.

• we will get bombarded with feature requests to add whatever to the context menu (see above mating reference)

The context menu is a consolidated UX paradigm that users of all platforms are familiar with, and it has the great advantage of being discoverable. It is a good place to put actions that affect the object under the cursor. Requests to add to it should be screened based on the value that they provide for the user.

• we have to support it, not just the code but the user expectations ("the menu should work like this and not like that...")

This applies to everything. The question should be if the functionality provided is worth it. In this case, I would argue that it is, as it makes the 2nd window a much more valuable asset.

• it's one more thing we'll have to port to GTK 4

Code footprint of the menu is ~20 LOC, it does not seem a huge commitment.

• if we decide to merge we need to come up with a standard spelling out what's acceptable in the menu and what's not (and stick to it). Preferably before we merge so that we're ready for the storm. My expectation is users will want to run darktable almost entirely (or as much as possible) from the right click menu.

Agreed, but there is a good reason for that: context menus are easy to use and to understand.

I see where your objections come from. I am happy to drop the context menu in favor of another paradigm that is as discoverable and easy to use.

Defining an action is an option, but it is way less discoverable (you have to know that the action exist, unless it is mapped to some UI element).

A few possible alternatives that come to mind:

1. Add an overlay 'pin' icon to the images in the thumbtable (TT). Pros: most discoverable, easy. Cons: an overlay to render on each image in the TT.
2. Add a way to navigate images to the 2nd window, i.e., another TT or directional arrows. Pros: provide the functionality right where it makes sense. Cons: more bloat; less flexible than a context menu; clunkier (if you have to navigate images sequentially); redundant.
3. Drag and drop images from the TT onto the 2nd window. Pros: same functionality; Cons: less discoverable; less ergonomic, especially in a multi-display setting in which one would have to drag the image all the way across two screens.

IMHO, none of this is as good as the context menu, which checks all the boxes:

1. Standard UX paradigm
2. Discoverable (people right click on stuff when they want to do something with it)
3. Small code footprint
4. Easy to maintain, no funky code
5. Puts the action where it is needed
6. Each menu entry can easily be associated with an action and triggered via a direct shortcut

[TurboGit]

This adds a contextual menu to the thumbtable in the darkroom, it has no effect on the lighttable. Maybe I didn't understand what you mean?

Ah, that's the filmstrip :) Just a confusing use of thumbtable, sorry.

The context menu is a consolidated UX paradigm that users of all platforms are familiar with

Sure, expect on Darktable where we have avoided this as much as possible.

Yes, 3 (drag&drop) seems more Darktable like. I had the same idea and was about to propose this. @wpferguson would that work for you too?

We also need an action to do that with shortcut (if not already done in this PR - no review yet).

[masterpiga]

The context menu is a consolidated UX paradigm that users of all platforms are familiar with

Sure, expect on Darktable where we have avoided this as much as possible.

Can I ask why? It is a consolidated UX abstraction that people are used to and expect. I totally understand that they have the tendency to become bloated, but they are also excellent tools when used properly and with restraint.

In this context, one could decide that the context menu is only, e.g., for sending the current image to other parts of the UI.

Yes, 3 (drag&drop) seems more Darktable like. I had the same idea and was about to propose this. @wpferguson would that work for you too?

We also need an action to do that with shortcut (if not already done in this PR - no review yet).

D&D has the problem that it would be tedious across screens, which is probably the main use case for this feature (whenever I use composite, even on the same screen, I always find the D&D part tedious).

What about using some overloaded click instead? E.g., ctrl+click, or right click, or whatever click is not used already in the filmstrip?

We also need an action to do that with shortcut (if not already done in this PR - no review yet).

Sure, I will add that.

[TurboGit]

What about using some overloaded click instead? E.g., ctrl+click, or right click, or whatever click is not used already in the filmstrip?

That's what the action is for. We don't need to map this to some keyboard shortcut for now and let users decide is this is needed or not. Better do that as this action won't be widely used.

[masterpiga]

@TurboGit, so you suggest to just define the action and not assign it any default shortcut? This is fine with me, but it's a big obstacle to discoverability. Only if you know that the action exists you can decide to map it.

[TurboGit]

My proposal would be:

• An action with no default shortcut
• A drag&drop support

[masterpiga]

All done, new action + drag & drop, dropped the context menu:

Screen.Recording.2026-02-25.at.16.16.06.mp4

@TurboGit @wpferguson PTAL

[wpferguson]

Now that I've had a night to think about the context menu, here's my thoughts

The lack of a context menu was a deliberate design decision. I believe the reasoning was that darktable is an image processing application and the images should always be at the forefront. If we have context menus, then the images get hidden behind the menus breaking the focus on the images. I think I read this or something similar years ago in a post, blog, or issue.

When I first used darktable there were times I thought "this would be better with a context menu". After about 6 months of using darktable I no longer missed the context menu, and that was before InputNG which made the shortcut system infinitely more powerful.

---

Are we doing users a disservice by trying to make things "easier"?

When I started doing photography again after laying off for 10 years I got a Canon 7D at half price because the Mark II had come out. I didn't have any money so I had to use my 10+ year old EF lenses. I often thought if I could by "this" equipment it would solve my issues. Instead I had to grow as a photographer and use better techniques and knowledge to solve my issues.

When I started using Lua I would think "if only I had this widget" or "I need this function". Instead I had to think, learn, and problem solve. What I found was that I could solve every widget issue with what was already there. At this point I marvel at the way Lua is embedded in darktable. There is enough there to do almost anything you want, but it's not bloated with useless features.

In both of the above cases I had to grow because there wasn't a easy way to achieve what I wanted. If there had been an easy way, then I wouldn't be any smarter than I was back then.

If there is not a reason to think, then there is no growth. Therefore, if we make darktable too easy, then users can just point and click their way to mediocrity.

Just a thought...

[masterpiga]

@wpferguson Thanks for the context, I appreciate that.

Even though this is probably not the right space to have this conversation, I cannot not reply :)

There are very well established principles of good UX design. Ignoring them deliberately does not seem a very good idea to me, because it is inevitably a source of user friction. This friction is evident on pixls, where most complaints are about confusing/arbitrary decisions.

One of the main issues with darktable's UI is that it's not discoverable, and context menus are an established way to make functions that apply to the object under the cursor discoverable. Users are familiar with this pattern. If every software on the planet uses them it's not because programmers are lazy. It's because it works, and if used properly it's an excellent tool.

One can decide to do without them if one wants to, but then one would have to provide an equally valid way to discover what features are available. The alternatives offered by darktable are (1) going through the list of actions in the shortcuts window, or (2) reading the manual. (1) is clearly not ergonomic, and (2) is wrong because you should really not have to read a manual to understand what you can or cannot do with a software. So, in my humble opinion these alternatives are not a valid alternative to well established UX patterns.

All of the above is more general than this little feature of mine. In the specific case it's okay to do without the context menu, but also in this simple case you can already see that there is a loss of discoverability. With the menu, the user could discover this feature without leaving the darkroom view. Without, they have to know that the feature is there or they will never be able to use it. I am sorry but this is the contrary of how usable interfaces are built.

I understand that darktable does not have a dedicated UX department, it's perfectly fine and understandable that suboptimal decisions have been made at any point. But keeping making the same mistake because it was already made in the past doesn't strike me as the wisest strategy.

All that said, I implemented the requested changes, and the context menus are gone.

[wpferguson]

but they are also excellent tools when used properly and with restraint.

Requests to add to it should be screened based on the value that they provide for the user.

Every user that submits a request for a menu item absolutely "nnnnneeeeeeeeeeeeeeddddddsssss" it and can't live without it 😄

How do we decide what goes in and what doesn't? Who decides?

If we decide to do a context menu we need at least a set of guidelines and preferably a set of rules that spell out what goes in and what doesn't so that we can justify why some get accepted and some don't and it needs to be in place before a context menu gets merged.

Not sure I understand this.

I meant if you hard coded the context menu to right click

it makes the 2nd window a much more valuable asset

What percentage of darktable users use 2 monitors? I would guess it's a pretty small percentage.

understandable that suboptimal decisions have been made

The decision was thought out and consciously chosen to meet the goals of the program as determined by the authors.

I wonder if context menus were created to cut down on support requests and not to help the users. To really "use" a program you have to dig much deeper than the context menus. But, how many users never get past them and so only use a small percentage of what the program is capable of? So effectively context menus have served to dumb down the users. 😄

If we decide to use context menus, it needs to be thought out and planned before it's implemented.

---

I tried to look at the video above, but I keep getting network errors. I know my Internet company is doing maintenance today, so that could be the issue. I'll keep trying.

[masterpiga]

How do we decide what goes in and what doesn't?

As a general rule, actions that (1) apply to the item under the cursor and (2) are not otherwise easily discoverable.

Who decides?

Whoever in the dev team is recognized as the UX overlord.

tried to look at the video above, but I keep getting network errors.

It's a pity, it's a great video.

[TurboGit]

If you drag&drop the dragged thumbs is always the one from the currently edited image. Not sure if this is due to this PR or not, but clearly something to fix.

Can you have a look? TIA.

[MStraeten]

regarding UX: yes indeed, users are comfortable with context menus - and with several other UI features not yet in darktable.
But adding a couple of such ‚well introduced‘ stuff without an overall consistent UX redesign just results in a more messy User experience. Because users will ask, why a context menu in one place but not at another feature …
A consistent UX is a result of a good design before implementation, not a result of arbitrary fragmented implementations

[masterpiga]

But adding a couple of such ‚well introduced‘ stuff without an overall consistent UX redesign just results in a more messy User experience. Because users will ask, why a context menu in one place but not at another feature …
A consistent UX is a result of a good design before implementation, not a result of arbitrary fragmented implementations

Yes, totally agreed. Even though for a large FOSS project like this it is difficult to imagine sweeping changes happening at once. If some UX decisions were to be reconsidered, I imagine that the transition would be a gradual process, with an inevitable interim in which there is a bit of both worlds. But yes, the UX principles guiding the transition would have to be established beforehand, not improvised on the spot.

[masterpiga]

@TurboGit I cannot reproduce. This is Fedora on Wayland, it WAI for me:

Screen.Recording.2026-02-26.at.09.15.14.mp4

What does happen is that if there are multiple images selected in the filmstrip (which is easy to do unwillingly) you will get a generic icon, because of this:

darktable/src/dtgtk/thumbtable.c

Line 2343 in a433d9d

// if we are dragging a single image -> use the thumbnail of that image

[TurboGit]

@TurboGit I cannot reproduce. This is Fedora on Wayland, it WAI for me:

That's strange, on my side (Wayland - GNOME Shell) I always get the currently edited image in the drag thumb except for clones where I get the original as the thumb.

I see anyway that this is also broken on current master so not an issue with this PR. I'll merge and we will sort out this bug after.

[TurboGit]

Thanks!

[masterpiga]

Thanks, @TurboGit! I suspect that the issue that you describe depends on some transient initial conditions that affect or delay thumbnail caching. I have seen the issue once, I restarted and it was gone, and then I could not reproduce it anymore.