Active file tab in editor gets moved to the right when tab bar is wider than editor pane

[Khris777]

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

• Spyder Version: 3.2.3
• Python Version: 3.6.3
• Qt Version: 5.6.2
• PyQt Version: 5.6
• Operating system: Windows 10

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)

[ccordoba12]

This behavior was asked by several users in the past, so we changed how the Editor tab scrolls to fit it.

[jnsebgosselin]

@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.

[jnsebgosselin]

@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.

[ccordoba12]

@rlaverde, what do you think about this one?

[rlaverde]

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 725c0159f6371787e51998ca808e8c2cc723f5be)

[ccordoba12]

@rlaverde, any way to fix this one?

[jnsebgosselin]

@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.

[rlaverde]

any way to fix this one?

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 😕

[ccordoba12]

Ok, thanks for the info @jnsebgosselin and @rlaverde.

I'm closing this one for now. @jnsebgosselin, please reopen it if you find a workaround.

[bcolsen]

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 1

I thought we could see if changing the text color would force a redraw. Yellow for modified, red for read only

Option 2

Notepadqq changes icons in the tabs and the tabs don't move.

Should be smaller. Could be a dot.

https://github.com/notepadqq/notepadqq/blob/c0efb1b275d2a260d18d172a1a739821ce134f80/src/ui/editortabwidget.cpp#L285-L291

[bcolsen]

Option 3

Let it move and move it back. Can we control the view at all?

[ccordoba12]

@jnsebgosselin, we could use your input here. What do you think about @bcolsen's ideas?

[jnsebgosselin]

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.

[jnsebgosselin]

And if I can't find a solution, I think option 2 is the one I prefer.

[goanpeca]

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();
}
}

makeVisible(currentIndex); is always called, and is private.

[goanpeca]

Let it move and move it back. Can we control the view at all?

I think we can;t... :-\

[jnsebgosselin]

For the sake of documenting this Issue, here are some relevant links: https://bugreports.qt.io/browse/QTBUG-2360 https://bugreports.qt.io/browse/QTBUG-45381 https://stackoverflow.com/questions/32211741/qtabbar-to-preserve-tab-position https://github.com/qutebrowser/qutebrowser/issues/3579

[bcolsen]

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 ""

[jnsebgosselin]

I thought we could see if changing the text color would force a redraw. Yellow for modified, red for read only

This would work and my vote goes to this option.

It also takes less horizontal space, so this is an additional benefit.

[goanpeca]

This is awesome news @jnsebgosselin !

Could you post a version for the dark theme to see how it looks?

[jnsebgosselin]

Ah well... of course it doesn't work for qdarkstyle.

It seems like QTabBar.setTabTextColor has no effect, probably because it is ignored by qdarkstyle during the painting.

[jnsebgosselin]

Ah well... of course it doesn't work for qdarkstyle.

It seems like QTabBar.setTabTextColor has no effect, probably because it is ignored by qdarkstyle during the painting.

@goanpeca Do you think this would be relevant to open an issue on qdarkstyle repo?

[goanpeca]

@goanpeca Do you think this would be relevant to open an issue on qdarkstyle repo?

I think we need to solve this on the Spyder side, but fear not, this is relatively easy, I know how to. Give me some minutes and I will add an example for you.

[jnsebgosselin]

Excellent! thanks

[goanpeca]

Ok, found an article that explains this @jnsebgosselin

https://wiki.qt.io/Dynamic_Properties_and_Stylesheets

We could define a property like 'dirty' or 'unsaved' and add this custom stylesheet and append to the normal stylesheet. We could then override the setTabTextColor to do the style()polish calls etc... if on darkstyle.

[jnsebgosselin]

Ok, found an article that explains this @jnsebgosselin

https://wiki.qt.io/Dynamic_Properties_and_Stylesheets

We could define a property like 'dirty' or 'unsaved' and add this custom stylesheet and append to the normal stylesheet. We could then override the setTabTextColor to do the style()polish calls etc... if on darkstyle.

Thank you, but I don't understand how we can apply this to each tab of the QTabBar individually. I don't see a way to access the tabs from the public API.

[goanpeca]

You are absolutely right, tabs are not widgets... internally structs that hold info so this will not work :-\

We should probably remove any Style that QdarkStyle applies to text color and see if that way we can still control the color with the method. Otherwise we would need to reimplement the paint method.

https://code.woboq.org/qt5/qtbase/src/widgets/widgets/qtabbar.cpp.html#_ZN7QTabBar10paintEventEP11QPaintEvent

or something like https://gist.github.com/eyllanesc/4a821d2956b5e2ee841f3eb156da078d

[jnsebgosselin]

We should probably remove any Style that QdarkStyle applies to text color and see if that way we can still control the color with the method.

I have try that already but failed. I will try harder and see if I can make it work lol

Otherwise we would need to reimplement the paint method.

That would be though though, especially since we support dragging and moving... I say we should try to avoid doing this if we can help it.

My favorite option would be to fix this upstream in qdarkstyle, but I don't know if this is possible.

[goanpeca]

I have try that already but failed. I will try harder and see if I can make it work lol

I can have a look at it too :-)

[jnsebgosselin]

I have try that already but failed. I will try harder and see if I can make it work lol

I can have a look at it too :-)

Oh yes, please do, that would be greatly appreciated, thanks.