Bug 400168 - Recheck tab repositioning for open files
Summary: Recheck tab repositioning for open files
Status: REOPENED
Alias: None
Product: kdevelop
Classification: Applications
Component: All editors (show other bugs)
Version: 5.2.4
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: kdevelop-bugs-null
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-10-22 21:24 UTC by Markus Elfring
Modified: 2024-05-21 18:27 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Elfring 2018-10-22 21:24:21 UTC
I am used keep a bunch of files open for my projects in the program “KDevelop 5.2.4-43.4”. One usual consequences is then than a tab list is presented by the editor widget on the top. I would like to switch quickly between tabs which fit on my screen width.

It can happen then that a file with a tab on the top right corner was active for a moment until I choose to switch to a file with a tab in the left area.
The simple change of a single character (or an explicit file storage action by the shortcut “Ctrl+s”) can move the tab which got my editing focus to the middle in the list. I find this software behaviour unpleasant. I would find it nicer if the selected file tab can stay at a known position instead.

If I would like to return to the previous file, I need to scroll some times which I would prefer to avoid often enough.
Comment 1 Justin Zobel 2022-12-02 01:22:54 UTC
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version?

If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Comment 2 Markus Elfring 2022-12-02 17:57:38 UTC
(In reply to Justin Zobel from comment #1)
I would appreciate a more helpful answer for my clarification request.
Comment 3 Igor Kushnir 2022-12-03 08:45:30 UTC
Have you tried hitting Ctrl+Tab, then pressing Tab until the document you need becomes selected? I think this feature is implemented by Most-Recently-Used Document Switcher plugin.
Comment 4 Markus Elfring 2022-12-03 12:28:04 UTC
(In reply to Igor Kushnir from comment #3)
I am unsure if the switcher plugin would really matter for the reported software behaviour.
Did you ever check if the scroll status would be automatically adjusted for the tab list in undesirable ways?
Comment 5 Sven Brauch 2022-12-03 12:36:10 UTC
Hi, as far as I understand the behaviour you describe is a consequence of the "modified" icon being added to the tab, causing the tab bar to recompute its layout and afterwards ensuring the selected tab is visible. In doing that, it doesn't take the previous tab position into account. That's certainly something that could be improved.

That said, both Kate and KDevelop have for years tried various concepts of tab bars and tab bar behaviours. IMO the main takeaway is that they don't really work any more as soon as the size of tabs exceeds the screen width. Stuff like quickopen and the Ctrl+Tab document switcher are simply superior navigation tools UX wise.