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.
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.
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 …
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 …
“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.
