I don’t think ESC is mapped to anything. I really only took a quick look so I could have easily missed it… Then next part would be deciding what you could map that to to give you a consistent outcome in multiple situations where you might be looking to cancel our step back…
I no longer need any solution for this issue for myself. I will remember what to do. However, I think that it’s worth resolving it for other newcomers to darktable.
I think that a possible solution could be:
- Create an action that makes reappear the user interface no matter what the current mode is.
- Map the escape key to that action by default.
But this is just one idea.
A lot of stockholming¹ going on when working with software. 
And some even defend it because they have forgotten how it felt when they were new.
The sad problem with opensource software developed by a dynamic team is the multitude of product managers. And that is by far not a problem of darktable alone. A project needs a benevolent dictator that really understands how good design is the one thing that holds the software together and really pushes every little decision towards that vision.
¹) you get used to bad stuff.
2 Likes
I agree that in general “full screen” modes should have obvious ways out. Tab is a common one though so it was a good choice by darktable folks. ESC is another one.
I do think it’s a fairly common user question for other complex software such as dtp and cad. Over my years as a user of such software I’ve seen many people trying to get their panels back. The thing is a more experience user will be really annoyed by say an icon on top of their work, I know I would be, thats probably the reason people loose their panels with some frequency.
I just tried F11 in Firefox and there are no easy ways out of that one either.
The problem here seems to be several fold:
- You’ve used a common computer UI term, “full screen”, which did not adequately describe your issue, nor did you really clarify or describe what happened until several posts later.
- You purposefully disabled the visual buttons that would have made your panels reappear. Its pretty obvious if you have the arrows enabled to click them if the panel is gone. Disabling the arrow button is beyond “new user” behavior, IMO.
- H key to display available hotkeys would’ve been fine if you knew what the thing you wanted was called. I don’t think darktable uses any special language that is much different from other complex software in this regard.
The proposed solution, of “track all my UI interactions and give me a global hotkey to toggle the last behavior” would be a ton of work for not a lot of pay off, I think. Is there any software that actually does this?
It seems you mashed some random keys on your keyboard or something, perhaps some midi controller like a loupedeck would be better if you can not keep track of what keys you’re pressing. We do have support for a bunch of hardware to use as input.
The Firefox full screen mode is critically more user friendly. Enabling it shows a warning that explains how to go back. (This warning can be disabled explicitly by the user.)
Even when the warning has been disabled:
- Moving the mouse pointer up makes UI elements reappear.
- Using the usual window manager key to “unmaximize” a window quits full screen mode as well.
- It is possible to quit the program with the usual key combination (or simply through the window manager). After restarting it comes back in usual mode.
So I think that the situation with darktable is not quite the same.
There are many possible ways to make hidden panes reappear without annoying seasoned users. For example, even if the “arrows” have been disabled, moving the mouse to a border could make them reappear.
Dear @paperdigits, once I had found a solution to my immediate problem (with some prompt help from this friendly forum), I only tried to help with improving darktable by pointing to what I genuinely think is a usability problem.
I am an author of free software myself. I value constructive criticism as a matter of principle.
There is no need to track anything. It’s enough to go back to the basic way any mode (like lightable or darkroom). I do not know the internals of darktable’s code base, but this sounds like potentially useful functionality.
I can think of other ways to mitigate the problem. For example, the panel collapsing controls (“arrows”) could be shown for a collapsed pane whenever the mouse pointer is moved to the border of the screen.
But identifying a concrete solution is a second step. Imagine a new user who fires up darktable for the first time, with no customization (the “arrows” are visible). Then, In lighttable mode, the user mistypes and presses “W” (shift-w) and finds himself stuck in a mode with all the UI gone, and no apparent way to go back. Pressing esc does not help, nor pressing “q”, nor moving or clicking the mouse, nor unmaximizing the window. The user has to know that he needs to press “w” again.
The first step would be to acknowledge that this UI design has potential for improvement.
Do you really think that someone pressing Shift + W and not knowing they did is a likely scenario?
Someone who touch types can easily press a wrong key. It happens to me.
But there are other possibilities to shoot in one’s foot. Disabling the pane controls is not such a difficult thing. I found this functionality quite easily by reading the shortcut help, and then I forgot about it. (Someone could also press “b” accidentally, there’s a reason why firefox doesn’t allow to assign shortcuts without modifiers for example [I do not advocate for this restriction for darktable]).
Then, with the pane controls disabled, accidentally pressing tab is not a thing out of this world.
1 Like
Well here are some notes I give my students about keyboard shortcuts. This might help new users.
Setting up keyboard shortcuts
DT offers several keyboard shortcuts; however, you may be used to specific keyboard shortcuts from other programs, and it is possible to reassign DT keyboard shorts to match what you already know.
- In the preferences go to shortcuts and find the shortcut you which to alter
- Double click on it and follow the prompts to reassign keys to the shortcut
Pressing the letter H will reveal the list of keyboard short cuts. If you then press Alt the panel will stay active.
Shortcuts affecting screen real estate
Ctrl-Shift-H reveals or hides histogram.
Ctrl-F reveals or hides film strip
Ctrl-H reveals or hides the top header menu tabs
B reveals or hides the borders with arrows
Ctrl-Shift-R reveals or hides the right panel
Ctrl-Shift- L reveals or hides the left panel
Ctrl-Shift- T reveals or hides the top panel
Ctrl-Shift- B reveals or hides the bottom panel
Lighttable shortcuts
W previews a single image while the button is held down
Alt-W previews a single image in persistent view. Hitting W key will return lighttable to grid view.
Ctrl-W previews a single image with focus detection shown.
Mouse wheel scrolling will move previews through the collection
Ctrl-mouse wheel scroll allows zooming of the image being previewed
Compare view (culling) in lighttable
Select image you want to compare and then hit CTRL-X
Ctrl-mouse wheel zooms all displayed images
Ctrl-shift-mouse wheel zooms only the image where the curser hovers over
Click & drag pans all displayed images and can cause then to be positioned out of view
Click-shift & drag pans only the image that the curser hovers over
Zoom and pan functions work with a maximum of 4 images
Copying Image Settings from one image to others
Shift-Ctrl-C allows you to select what settings will be copied. By default, WB is not copied so choosing it here may be important for a series of images.
Ctrl-V pastes the copied settings to the selected image or multiple images.
1 Like
I appreciate that, but I don’t see what tripped you up as troubling a lot of people and question whether taking developer time to do so is worth the investment. Of course if you feel strongly about it, you should open an issue on github, and if a developer feels the same then it’ll happen.
darktable’s UI has a lot of state.
Unless you mean resetting all or most of the UI preferences, then there isn’t really a universal basic state. Further I’d think what each user considers the “basic state” is quite different.
I still don’t understand how pressing W again isn’t obvious. It’d be the first thing I try. Otherwise they have the arrows to click, which are pretty obvious when the panel is collapsed.
Do you use darktable with your hands in proper touch typing position? That seems like it would make it hard to use the mouse. I have one hand on the mouse and the other hand hovering on the last hotkey I used.
I don’t know if this will help, but I use a higher display scale (150%) so I can see things better. There are a few apps that appear to be in full screen, or their buttons / menus are just not there. But I use escape and change my display scale and their options work the next time I use them.
It is a panicky situation for sure, wondering how to get out of it.
On Windows Ctrl key plus the Delete key should Force Quit a program (since you don’t have task bar or other menu options.
This is indeed an issue to consider - not only “confusing”, but to the complete novice really a totally panicking experience where one tries, to no avail, every usual trick in the bag to get out of a (to a new user) completely unexpected an understandable situation. Remember, such people may have no prior experience with software where getting into full screen mode is wanted/usual, (like myself in spite of actually first operating a computer more than 50 years back and storing my first program on punch cards …). Yeah, I definitely was there a couple of times in the beginning of my long and slow learning experience with dt – sweat breaking out and becoming so confused that I didn’t perceive those small triangles that might possibly have been there for a remedy – unless I already had also involuntarily typed a “b” prior to the Tab, that is …
(As my own private, and regrettably slow, possible FOSS project contribution I work on a draft “The Complete Beginner’s Introduction to Image Processing with darktable”, (i.a. trying to gather and structure many of the useful info bits that passes in the discussions here in pixls’ forum along the line of a non-techie newbee’s progression route). Seeking to prevent any such panicking experience – that has the potential to turn a curious person and prospective future user away from darktable before they really have begun – I’ve treated the involuntary Tab/b issue right up front before even the words “module” or “import” has been mentioned …)
For a complete novice not yet being trained in in many basic aspects of darktable – and grappling with a manual that is very good and steadily improving in many respects, but still not structured according to a newbee’s needs – but anyhow trying to get to grips with this wonderful beast, I can assure you that hardly anything is “obvious”.
“mouse”???
Once again, our situations and outsets may differ so much. For my own part I mostly use dt on my laptop while on the move where I have no mouse, but rather use the touchpad and keyboard only. From my natural position of fingers (from previous 50+ years of computer use) in basic touchtype position, lots of involuntary things may happen – both on the keyboard and on that much too sensitive touchpad …
4 Likes
And it won’t be. Its not an introductory text, its a user manual. It’s structured the way most user manuals are structured. It describes the way the application functions and assumes you have basic domain knowledge.
Yes, I’ve finally realized that some time ago (-- but I anyhow do appreciate the new proposed introduction in the manual to processing strategy).
And that is precisely why (besides some other reasons related to repeated serious illnesses) I didn’t follow up on a previous indication to come up with some suggestions for improvements to the manual. So now I’m rather working on a document that could more likely cater for the non-techie newbee’s (not only with dt, but with image processing in general) needs.
Some main editorial aspects where such an introduction should deviate from the dt manual:
- Forgetting the underlying technical/module structure and the perspective of developers, and rather focus on users’ needs - as they develop along a progression in increasing understanding and competency. Starting with simple but very effective stuff where it initially doesn’t matter much whether the user is working with jpgs or raw. (I used dt for quite some initial time just for exposure, cropping and resizing of jpgs …).
- Providing the reader with more explanatory stuff on underlying concepts and technology issues to facilitate understanding.
- Still, seeking to, as quick as possible, to introduce the new user to functions where dt shows its strengths, like local processing – typically using (simple ways of) masks in exposure and retouch to tidy up an image.
- Not aiming to treat all aspects of a function/module in one place, but rather addressing stuff along a line of such more naturally progressing needs, difficulty and complexity. So there will e.g. be some distance from initial cropping to color grading, and e.g. exposure will be treated several places along the way.
- Not addressing at all some less used and complicating stuff (-- it’s an “introduction”)
Most of this is available around in different places, the challenge is to gather and structure it. I once tried to argue that we could use a couple of edited threads her in pixls’ forum to try to collect/structure relevant (links to) info that is put forward in postings and elsewhere, (one thread for the actual info and one for discussions on what to include), but have come to think that we should probably create a separate document for this purpose – and I seek to come up with a draft at some stage.
Maybe, we can think that with v. 4.2, with its new sigmoid and HLR tools, we can se the transition to scene referred processing slowing down somewhat (with a scene referred color zone module as the dark horse?) and there can be some more “fixed” points to relate such an introduction to (?).
So perhaps a more “complete” draft about next summer …
3 Likes
Sounds great, looking forward to checking it out.
“Full screen” can mean “maximize window” and/or “hide UI elements”. Often both things are combined.
Since darktable is a program that is commonly used with a maximized window, to me the term “full screen” in this context quite naturally describes a view where the preview image fills the whole window. Heck, even darktable itself by default binds the “f” key to “sticky preview” mode. Where does this “f” come from?
I also wrote that it was “like pressing shift-w”.
When I touch-type (for example right now), I do not look at the keyboard. Some of my keyboards are worn, the little markings on the F and J buttons are not so easy to sense anymore. Although I try to use the same keyboard model everywhere, I also have to switch between desktops and laptops which necessary have somewhat different layouts.
This is my situation, other people are in a different situation, but it’s a fact of life that it can happen from time to time that a user presses a key that he or she did not intend to press, without even knowing what key they pressed.
It’s not totally strange to press tab instead of caps lock for example (I have configured caps lock as an easy-to-reach modifier), or w instead of e. Or something else.
Yesterday, when it happened to me with darktable, after many hours of use, I was exactly in this situation. I did not even know what key I had pressed.
Now perhaps there are no darktable developers who have time to work on fixing such usability problems, but we should all be able to agree that the UI behavior of darktable has room for improvement. The problems that I have described in this thread are not the consequence of an efficient UI for power users. They could be mitigated without any negative effects for them.
I could have saved myself a lot of time by not continuing this discussion, but I think that fresh impressions of new users can be valuable. Myself, I am so used to the idiosyncrasies of the libraries that I develop, that whenever I talk to a new user, I urge him or her to share with me their honest impressions and let me know what surprised them.
There are other clear usability problems with darktable. For example, when I activate the “color picker” to pick, say, the white point, I sometimes forget to deactivate it. Then, it sometimes happens that I zoom in by pressing the middle mouse button. By now I have forgotten that the color picker is still active, and since I zoomed in, there is no visual cue to that except the little icon on the border of the screen.
Darktable is capable to change mouse pointers. It would be useful to signal that the color picker is active by changing the mouse pointer accordingly. And in addition, one could consider desactivating color picker mode after the user performs some other UI action like zooming in.
Yes of course. I always type in the proper touch-typing position, that’s the whole point of it. When I use the mouse, I move my right hand, but the left one stays where it is.
Thanks for your work, I think that this is a good initiative.
However, I would like to stress one final time that I honestly believe the the UI issues of darktable discussed in this thread are not features but bugs, and that explaining them in documentation is not a substitute to fixing them in the first place.
I think that a little more focus on usability could go a long way in attracting and keeping new users.
Yes I totally agree, and I’ve been listening to new users and providing support for darktable and other applications here for over 7 years. I’ve spent approximately 1,300 hours of my life doing that. I’d like to think I have some idea of what the common issues are. Maybe I’m wrong, I don’t know.
Yes, of course. I never said there weren’t. By many accounts of the internet, the UI/UX of darktable is “horrible” and “unintuitive.”
This one seems reasonable, you should file a feature request for it.
But we know that that is shorthand for “not what I’m used to” 
1 Like