| Summary: | If the view is currently focused, when opening a new tab, the new tab's view is not focused as intended | ||
|---|---|---|---|
| Product: | [Applications] dolphin | Reporter: | aldo.mateli |
| Component: | general | Assignee: | Dolphin Bug Assignee <dolphin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | elvis.angelaccio, nate |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/graphics/krita/commit/0499277cdd475705af9c41e45bb1b777eed737d1 | Version Fixed In: | 19.04.0 |
| Sentry Crash Report: | |||
|
Description
aldo.mateli
2018-12-08 20:49:18 UTC
Since opening a new tab creates a duplicate of the current view, I would expect that the very first thing you want to do it change the view some somewhere else, in which case having the keyboard focus on the search feels seems logical. Can you provide some background regarding what you want to do with the new tab that's a duplicate of the current one that requires immediate keyboard focus in the view itself? Why not just do whatever you were going to do in the original tab and not open a new one? Imagine a simple scenario where you want to open a new tab in order to work on a sub-directory of where you are currently browsing, but without navigating away from the current directory in this tab. E.g: Tab1 is at ~ and for the new tab we want to browse ~/Projects. Doing it without mouse input is very difficult right now(The arrow keys do not help you navigate). Also, there is no obvious way to focus the view, so I can type "P" then Enter in order to go to the "Projects" folder that I wanted to visit in the first place. If a user wants to focus the location bar, Ctrl+L is always there. This is not to be confused with the browser case where you open a new empty tab (so you need to input something on the location bar) to go into a different website. This is in the context of the same application with the contents already loaded in the new tab. When the URL navigator is in path mode, switching to the view is simple: just hit the tab key. However if it's in breadcrumbs mode, you need to hit the tab key many times, and in fact having keyboard focus on the breadcrumbs bar doesn't make a lot of sense anyway since it's not really very keyboard navigable. I'll submit a patch that moved keyboard focus to the view when opening a new tab if the URL Navigator is in breadcrumbs mode. Browsing the code, there seems to be a bug here. It appears that the intention was to retain focus on whatever widget was focused when the new tab was opened. However this does not work if the focused widget is within the old tab. For example if the view was focused, when a new tab is opened, it tries to set the focus on the old view, fails because the old view is not visible anymore since it's in an inactive tab, and the URL navigator gets focus as a fallback. Oops, misread the code. That's for a different type of tab creation. It looks like for this use case, it's feasible and reasonable to automatically set the focus on the view if the URL navigator is in breadcrumbs mode. Here's your patch: https://phabricator.kde.org/D17635 Git commit b7ceb51b44da394089689a2649cc8529c1f74669 by Nate Graham. Committed on 29/01/2019 at 13:33. Pushed by ngraham into branch 'master'. After opening and switching to a new tab, always focus the view Summary: When Dolphin opens a new tab and immediately switches to it, the URL navigator gets focus if it's editable. If it's not, the breadcrumbs bar gets keyboard focus, which is not very useful since it's not really intended for keyboard navigation. This patch changes that behavior so that the view always gets focus, which seems more useful and more consistent. FIXED-IN: 19.04.0 Test Plan: 1. Put the URL navigator into breadcrumbs mode 2. Open a new tab 3. Observe that the view gets keyboard focus 4. Put the URL navigator into editable mode 5. Open a new tab 6. Observe that the view still gets keyboard focus Reviewers: #dolphin, elvisangelaccio Reviewed By: #dolphin, elvisangelaccio Subscribers: emateli, elvisangelaccio, kfm-devel Tags: #dolphin Differential Revision: https://phabricator.kde.org/D17635 M +3 -7 src/dolphintabwidget.cpp https://commits.kde.org/dolphin/b7ceb51b44da394089689a2649cc8529c1f74669 Git commit 27a9cc22f76a9b9934f939ea2fb57e52bef8aa2a by L. E. Segovia, on behalf of Freya Lupen. Committed on 31/10/2022 at 21:48. Pushed by lsegovia into branch 'master'. Add .csv to list of mimetypes The reason Krita could not open .csv files was because it didn't recognize the format and tried to open them as plaintext files. M +5 -0 libs/koplugin/KisMimeDatabase.cpp https://invent.kde.org/graphics/krita/commit/27a9cc22f76a9b9934f939ea2fb57e52bef8aa2a Git commit 0499277cdd475705af9c41e45bb1b777eed737d1 by L. E. Segovia, on behalf of Freya Lupen. Committed on 31/10/2022 at 21:50. Pushed by lsegovia into branch 'krita/5.1'. Add .csv to list of mimetypes The reason Krita could not open .csv files was because it didn't recognize the format and tried to open them as plaintext files. (cherry picked from commit 27a9cc22f76a9b9934f939ea2fb57e52bef8aa2a) M +5 -0 libs/koplugin/KisMimeDatabase.cpp https://invent.kde.org/graphics/krita/commit/0499277cdd475705af9c41e45bb1b777eed737d1 |