Bug 504957

Confirmed. I tried using ‘git bisect’ to see where the bug was introduced, but, surprisingly, it seems to happen even with older versions (at least back to 2023). But the behaviour is new, so I expect it’s caused by a change in Qt.

Or has the ‘open on Ctrl + click’ behaviour always been there, and I’m confusing it with the ‘Shift + click‘ behaviour (to select a range of files *without opening them*). Anyway, the automatic switch to open files behaviour bug seems to have been introduced in this commit:

commit 053fb00b5ec5d26e3e42be5039b2e3e8291a5597
Author: Finley Watson <fin-w@tutanota.com>
Date:   Mon Feb 24 00:57:28 2025 +0000

    Port from QMdiSubWindows
    
    **Visual changes:**
    - Tabs no longer stretch to accommodate as much space as possible in the tab bar.
    - The border around the tab pages (https://invent.kde.org/sdk/lokalize/-/merge_requests/141), between the tab pages and the main window, is now gone: this is a positive change.
    - Tabs have icons, building on the work from !197 and !200 (fd0b044a74be85efc213977187f4832e1ef101b4 and 0bbe7e90029b9bcbfe0b8382bfd7223ddee77c3f).
    
    **Functionality changes:**
    - An editor tab containing unsaved changes will use the save icon instead of the default icon. This functionality is similar to Kate's file tabs.
    - When closing an editor tab page that has unsaved changes when the page is not activated, the page is activated prior to the Save / Cancel popup showing, so it's clear which document is prompting you to save / discard its changes.
    - When there are no open tabs, the welcome screen shows. This is similar to KWrite's welcome screen. Previously the welcome screen only showed within the Project Overview tab page, when the user selected "Close project" from the menu.
    
    **Code changes:**
    - All tab pages are now ported from QMdiSubWindows to a common base class (`LokalizeTabPageBase`) which for now is a KXMLGUIClient / KMainWindow.
    - The logic open / close / activate a tab is more explicit and dedicated methods for these actions exist.
    
    **Preserved functionality:**
    - Ctrl+Tab and Ctrl+Shift+Tab cycle between tabs.
    - Ctrl+[ toggles between the last two tabs activated.
    - Ctrl+W closes a tab.
    - Changing active tab page changes the contents of the menu-, tool- and status bars.
    - Only the keyboard shortcuts for the currently active tab page function.
    
    This merge request is step towards a larger fix relating to bug 424024 and bug 477704 but does not actually fix them.

 src/editortab.cpp                |  45 +-----
 src/editortab.h                  |  25 ++--
 src/filesearch/filesearchtab.cpp |   1 -
 src/lokalizemainwindow.cpp       | 573 ++++++++++++++++++++++++++++++++++++++++++------------------------------
 src/lokalizemainwindow.h         | 113 ++++++++++-----
 src/lokalizesubwindowbase.h      |   1 +
 src/project/projecttab.cpp       |   1 -
 src/project/projecttab.h         |   1 -
 src/tm/tmtab.cpp                 |   1 -
 9 files changed, 432 insertions(+), 329 deletions(-)

hmmm, can you please post a screenshot of where this is supposed to not be working?

Because it works fine for me if it is where i think it is

Created attachment 182131 [details]
Multiple files selection in Project Overview

The selection is preserved as it switches to the new tab.

I am confused, what does "The selection is preserved as it switches to the new tab." have to do with "Unable to open multiple files from project overview" you are describing?

(In reply to Albert Astals Cid from comment #5)
> I am confused, what does "The selection is preserved as it switches to the
> new tab." have to do with "Unable to open multiple files from project
> overview" you are describing?

As you can see in the attached image, the selected files in the Project Overview are highlighted when the CTRL key is pressed. However, instead of staying on the Project Overview tab, Lokalize switches to a new tab.

Hmmm, you mean that a single click in the project overview will open the corresponding file?

(In reply to Albert Astals Cid from comment #7)
> Hmmm, you mean that a single click in the project overview will open the
> corresponding file?

Yes, I do, even if the CTRL key is held while clicking.

Interesting, single click does not open the files for me, i have to double click, i guess if it's following global settings like "Single click for opening stuff in Dolphin".

We should probably force double click for opening?

(In reply to Albert Astals Cid from comment #9)
> Interesting, single click does not open the files for me, i have to double
> click, i guess if it's following global settings like "Single click for
> opening stuff in Dolphin".

Confirmed. It follows Dolphin's single or double click behavior.
I kept using single-click to open files over the years, and up until version 25.04.1, it was very fast for me to search for several files by typing a few letters in the Project Overview's quick search and open them in their respective tabs without switching focus to them.

> We should probably force double click for opening?

I'm not a UX expert, but enforcing the double-click might improve the current behavior.

Can you explain how did it work before for you?

Single click would open a file?

Single click + Control would not open the file and select it?

Then how would you open the selected files, with the context menu?

What happened when you Single clicked a file (without control) if you had already (Single click + Control) selected other files?

(In reply to Albert Astals Cid from comment #11)
> Can you explain how did it work before for you?
> 
> Single click would open a file?

A single click on a tree item would open the file in a new tab, and focus would switch to that tab. 
Since version 25.04.1, this behavior is the same whether or not you press CTRL.

> Single click + Control would not open the file and select it?

CTRL + click on a tree item opened the file in a new tab. Focus still on Project Overview.

> Then how would you open the selected files, with the context menu?

No context menu. In both cases a new tab would open, but the focused element was different.

> What happened when you Single clicked a file (without control) if you had
> already (Single click + Control) selected other files?

If I'm not mistaken, only the last item clicked would open in a new, focused tab.

I hope I explained it more clearly.

>> We should probably force double click for opening?
>
> I'm not a UX expert, but enforcing the double-click might improve the current behavior.

My personal opinion: This would be bad UX and bad for accessibility (some people have set single click for opening files because they have difficulty in double-clicking).

Note that the single/double click behaviour is not specific to Dolphin; it is a *global* Plasma setting.

As a single-click user, this is what I would expect and prefer in Lokalize (when using single-click as the global option):

Single-click will open a file.
Ctrl + click will select a file without opening it.

Note that this is not the same as the old behaviour, but I think the old behaviour, where Ctrl + click opened a file in a background tab, should be considered a bug. In *all other applications*, Ctrl + click only selects stuff. Lokalize should behave like other applications.

Besides, the ‘open in a background tab’ behaviour was actually quite annoying, as it takes time to open a PO file, so the UI became somewhat unresponsive (i.e., it was slow to select multiple files).

Ctrl + Left Mouse sounds like browser behaviour, opening tabs in the background, so there is a precedent for this already. Perhaps it's not appropriate here though.

If there's some consensus on what is wanted / expected behaviour, I'm happy to implement it. I would expect either Ctrl + Left Mouse to open in background tab, or else only select the file and after finishing choosing then Enter to open them?

(In reply to Finley Watson from comment #14)
> Ctrl + Left Mouse sounds like browser behaviour, opening tabs in the
> background, so there is a precedent for this already. Perhaps it's not
> appropriate here though.
> 
> If there's some consensus on what is wanted / expected behaviour, I'm happy
> to implement it. I would expect either Ctrl + Left Mouse to open in
> background tab, or else only select the file and after finishing choosing
> then Enter to open them?

I've never encountered the unresponsiveness issue Karl mentioned with the "open in a background tab" approach, even with large projects, so I wasn't aware of it.
If performance with that approach isn't optimal, then any alternative would likely be better than the current behavior.

A possibly relevant merge request was started @ https://invent.kde.org/sdk/lokalize/-/merge_requests/249

I'm going to merge my fix and cherry-pick ready for 24.08, see how you like it and report back if you want changes.

The behaviour after this merge request is:
Activate (Left-click, press Enter etc) WITH Ctrl key pressed:  Open editor tab for file represented by activated item. Item selection in the Project Overview tab page does nothing, and means nothing, so I have disabled multiple file selection using Ctrl. 
Activate WITHOUT Ctrl key pressed: Open editor tab for file represented by activated item, and switch focus to that new tab page.
If the editor tab for the file is already open when the item is activated, then regardless of Ctrl being pressed or not, the tab page is focused.

I've gone for this behaviour because the code is already written in a way that expects this behaviour so it represents an improvement / fixes the regression. If people want something different, I can implement Ctrl + Activate to build a selection (as well as Shift + Activate to add a ranged selection) and then Enter to confirm selected files and open them all, focusing the last selected item. Otherwise, propose some sensible alternative and I'll see what I can do.

Git commit f16a697148e7e790b93e2b5ced5d627562811f06 by Finley Watson.
Committed on 10/07/2025 at 17:59.
Pushed by finw into branch 'master'.

Open editor tab in background when Control key pressed

When the user left-clicks / presses Enter on a Project Overview item 
(item in ProjectWidget, which inherits QTreeView), open the file 
associated with the item in a new editor view. If the Control key is 
also pressed, do NOT focus the tab page (i.e. open editor tab in the
background, like internet browser behaviour) and instead remain on 
the Project Overview tab page.

I've also removed some qOverloads that were unnecessary because they
were applied to methods with no overloads.

M  +4    -14   src/lokalizemainwindow.cpp
M  +4    -1    src/project/projectwidget.cpp

https://invent.kde.org/sdk/lokalize/-/commit/f16a697148e7e790b93e2b5ced5d627562811f06

Built from your latest commit and it works like a charm.
Thank you Finley.

Git commit 90e0d95010a7ec349d95b1a46eb12f525afe75ad by Finley Watson.
Committed on 12/07/2025 at 00:36.
Pushed by finw into branch 'release/25.08'.

Open editor tab in background when Control key pressed

When the user left-clicks / presses Enter on a Project Overview item
(item in ProjectWidget, which inherits QTreeView), open the file
associated with the item in a new editor view. If the Control key is
also pressed, do NOT focus the tab page (i.e. open editor tab in the
background, like internet browser behaviour) and instead remain on
the Project Overview tab page.

I've also removed some qOverloads that were unnecessary because they
were applied to methods with no overloads.
(cherry picked from commit f16a697148e7e790b93e2b5ced5d627562811f06)

M  +4    -14   src/lokalizemainwindow.cpp
M  +4    -1    src/project/projectwidget.cpp

https://invent.kde.org/sdk/lokalize/-/commit/90e0d95010a7ec349d95b1a46eb12f525afe75ad