-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Active file tab in editor gets moved to the right when tab bar is wider than editor pane #5459
Comments
This behavior was asked by several users in the past, so we changed how the Editor tab scrolls to fit it. |
@ccordoba12 I think this is a duplicate of Issue #1170, which should have been fixed by @rlaverde in PR #4607. However, I can confirm that I can reproduce the undesired behavior now on the master branch. |
@ccordoba12 I was wrong. Issue #1170 and PR #4607 seems to relate to the undesired behaviour when selecting tabs, not when editing the corresponding file. |
@rlaverde, what do you think about this one? |
I can confirm this issue too, is different to #1170 (but It's related) This is caused because when writing a file,the test of the tab change (file--->file*),and that update cause the scrolling,but I don't know how It could be fixed (#4607 only fixes when selecting the tabs, avoiding the unnecessary update of the tabtext 725c015) |
@rlaverde, any way to fix this one? |
@ccordoba12 I've looked a little bit into it and I think this is going to be hard to fix. This is occurring in private methods on the Qt side and I haven't found a way to prevent this undesired behavior. I would say this is a Qt bug per se... but if we wait for this to be fixed on the Qt side, we may wait for a long time. I'll take a look again in case I've missed something on my first try. It's probably possible to go around it, but this is going to be some kind of a hack. |
No, I don't know how it could be fixed, sorry 😞, as @jnsebgosselin says It looks like a Qt issue, I fixed the other one (#1170) with a workaround (not updating the tab title) but that workaround is not possible in this case 😕 |
Ok, thanks for the info @jnsebgosselin and @rlaverde. I'm closing this one for now. @jnsebgosselin, please reopen it if you find a workaround. |
This was irritating me today. It is very difficult to work on two documents with the tabs moving around so I looked up some options. I seems to happen whenever the title of the tab changes. This is the worst when adding or removing the "*" on changing or saving the document. Option 1I thought we could see if changing the text color would force a redraw. Yellow for modified, red for read only Option 2Notepadqq changes icons in the tabs and the tabs don't move. Should be smaller. Could be a dot. |
Option 3Let it move and move it back. Can we control the view at all? |
@jnsebgosselin, we could use your input here. What do you think about @bcolsen's ideas? |
I agree this is irritating for me too. I will take a look at it again with a fresh eye and see if I can find a solution. |
And if I can't find a solution, I think option 2 is the one I prefer. |
It seems not much to do in that area https://code.woboq.org/qt5/qtbase/src/widgets/widgets/qtabbar.cpp.html#_ZN14QTabBarPrivate7refreshEv void QTabBarPrivate::refresh()
--
{
Q_Q(QTabBar);
// be safe in case a subclass is also handling move with the tabs
if (pressedIndex != -1
&& movable
&& QGuiApplication::mouseButtons() == Qt::NoButton) {
moveTabFinished(pressedIndex);
if (!validIndex(pressedIndex))
pressedIndex = -1;
}
if (!q->isVisible()) {
layoutDirty = true;
} else {
layoutTabs();
makeVisible(currentIndex);
q->update();
q->updateGeometry();
}
}
|
I think we can;t... :-\ |
For the sake of documenting this Issue, here are some relevant links: |
The more I think about it adding the ""s actually the the work around for gui tool kits that don't allow icons on their tabs. I think that a simple small colored dot icon could convey as much meaning as a "" |
This is awesome news @jnsebgosselin ! Could you post a version for the dark theme to see how it looks? |
Ok, I've looked into this issue (again) and unless I am missing something, we would have to basically rewrite almost the whole What do you think @ccordoba12? It seems like going that route would be a lot of work and would add a lot of maintenance overhead in order to fix a, relatively speaking, minor UX inconvenience that should, imho, truly be fixed on the Qt side instead. Maybe this is already or is going to be fixed in Qt6, there seems to be a lot of refactoring going on lately with the QTabBar class. Even if its not fixed in Qt6, in PyQt6, it seems like For Qt5 and PyQt5 though, I think our best option is to either do nothing or add an option to add an icon like I did in #5459 (comment), even though this makes the tabs wider. |
Any update on this? This important problem has persisted for 6 years. |
This bug is more a Qt than a Spyder bug per se and we have not been able to reach consensus to work around this issue in Spyder. However, I think this annoying behavior was fixed in Qt 6.5. See : |
Changing tab icon/text color when content changes seems to be a good and simple solution. |
The option to add an icon makes the tabs substantially larger and was not accepted because of that. The option to simply change the text color was not accepted for accessibility reason I think. |
What if you add these features as optional? Then users can choose to activate/deactivate these features. |
In PR #21276 I added our own close button for tabs in the editor and IPython console. With that we'll be able to implement the same UI as VSCode, i.e. showing a filled circle instead of an |
This worked for me. Red and black were not good choices for the dark theme IMO. I went with something closer to orange. Here is the code I used:
It sounds like Qt 6 might finally fix this issue. If not, another good workaround I think would be to add an option on right-click or in the "Options" on the right side of the tab bar to send the tab left. The reposition doesn't happen if the tab bar is all the way on the left. I will often manually move all of my most active tabs to the left to avoid the repositioning. Being able to right-click and "Move Left" would make this less painful. Being able to do it on on the inactive tabs would be great as well, so you wouldn't have to "Move Left" and then scroll back right to move the next one left. Of course, now I think this color thing is going to be fine for me. |
Changing the tab text color has been the temporary solution for me as well. I have a bash script that updates Spyder and runs this code at the end:
|
Description of your problem
Take the situation when you have lots of files open in the editor so that their tabs don't fit the width of the editor pane and you get those two arrows on the right side next to the tab bar with which you can scroll left or right through your open files.
If you now take any file that is not on the right side and edit it the whole tab bar scrolls horizontally to push the active tab to the right rim of the editor or as far as possible.
Is there a good reason for this? Personally I find this behaviour quite annoying.
What is the expected output?
I don't want to tab bar to scroll on its own only because I'm editing one of the files.
Versions and main components
Dependencies
IPython >=4.0 : 6.2.1 (OK)
cython >=0.21 : 0.26.1 (OK)
jedi >=0.9.0 : 0.10.2 (OK)
nbconvert >=4.0 : 5.3.1 (OK)
numpy >=1.7 : 1.13.1 (OK)
pandas >=0.13.1 : 0.20.3 (OK)
pycodestyle >=2.3: 2.3.1 (OK)
pyflakes >=0.6.0 : 1.5.0 (OK)
pygments >=2.0 : 2.2.0 (OK)
pylint >=0.25 : 1.7.2 (OK)
qtconsole >=4.2.0: 4.3.1 (OK)
rope >=0.9.4 : 0.10.5 (OK)
sphinx >=0.6.6 : 1.6.3 (OK)
sympy >=0.7.3 : 1.1.1 (OK)
The text was updated successfully, but these errors were encountered: