This looks great, but red is hard to see. How about making it bold instead?

Unfortunately there isn't an obvious control for that (I'm using QTabBar::setTabTextColor(int index, QColor color)) - OTOH: whether it is something that can be hacked around with via style-sheets is another matter (with the QTabBar::tab selector but it is not obvious how to index into the particular tab and whether it would require specify all the styling attributes for the whole QTabBar instance - which could be nasty depending on whether it is possible to get what the current system applied style is)...

Of course a modified marker - a * appended temporarily to the tab name - is another possibility, but since the text is used programmatically it would have to be disregarded where it is used!

I think we can make it bold! I prefer that over an asterisk. If we give the tabs object names, we could address them in css:

🤕 I can't get style sheets to work on tab widgets using the #tab-text selection mechanism as in trying to used QTabBar::setStylesheet(...) with something like:

QTabBar::tab#profile2Name { background-color: red } QTabBar::tab#profile1Name { background-color: green }

I can style the tabs with other QSS(?) selection mechanisms, e.g. :selected / :!selected / :hover but the only way to pick out particular tabs is the #TabText one and I cannot get it to work. Given that the text that gets shown is automatically made into a short-cut if it contains a & I think it would be informative to see how the tabs are identified when run under gammaray - but I do not currently have a build of that to hand.

Sadly there is another problem with using StyleSheets on Tab-bars in Qt 5.9.2 - 10.0 beta1 (at least) - see QTBUG-63696: {macOS} Regression: setting stylesheet on QTabWidget::pane hides the close graphic on tab - which says that the close button (that we use!) on the tabs disappears on macOs platforms when a style-sheet is applied...!

Oh, we cannot give the tabs object names, they are not exposed in a suitable manner from the QTabBar container...

The above commit might help - it adds an icon as well as changing the colour and it does so for some local actions that change the contents of the main console as well as for when text comes in from the Mud Server. The latter does have priority though...

I have made the tab text a little larger - so the tabs are a little bigger which is okay I think as it stops the icons from being too small!

I've research it further (even build a small test case application) and I am pretty much convinced that it is not possible to apply styling to specific tabs based on their index or text. 👎

That won't work - having read Dynamic Properties and Stylesheets and looking at the 5.10.0 source code I can see that the individual tabs are not Q_OBJECTs and thus can not have dynamic properties added to them. 🙁

However that code has suggested checking trying QMovableTabWidget as an identifier in the style sheet QString...

... nope, that doesn't work.

I just tried to inspect a QTabBar with dumbObjectTree() and that confirmed that the only sub-objects it contains is the two QToolButtons used to scroll the tabs if they overflow the width available to them - no trace of the tabs themselves.

I had a look at the latest - still not a fan. Trying out various things myself too.

Given the current state of things I'd be tempted to drop the colour and rely solely on icons...

This solution seems to work: http://lists.qt-project.org/pipermail/interest/2018-April/029734.html

Could you adapt it?

Yes - but it took me a while to get my head around it as it targeted QTabWidget whereas we need/use QTabBar. Anyhow it is now in and I have taken the icons out. I've changed the use of red to magenta for those profiles that have received text from the MUD servers (but retained blue for the lower priority of text that has been generated by a local source - I don't know if I have caught all cases of the latter, I probably haven't) - but both cases use the bold effect now....

I would like to differentiate between the two cases though (local and remote) and cover the corner case where all the tabs are bolded by an application or user's system wide style settings - do you have an alternative (am I going to have to include provisions to underline or italicize as well)? I mean blue works well for me but red is not so, um, hot - so I thought magenta seemed a reasonable choice as it seems more urgent than blue (do you want a user choice?)

I think that's overengineering. Let's keep it simple for the first pass and if people request that feature, we can still add it in.

Ah @keneanung - just the person I ought to drag into this - do you have any advice on (and do you still have those steel-lined rubber gauntlets 😉 to work with) the current AppVeyor troubles? I have located the newer home for zziplib on Github (which downloads much more reliably) but although the source tarball for the 0.13.62 version is almost the same as the SF one (some extra ancillaries to do with MSVC and a symbian port) that I have changed to herein it is not building and even updating to the current version 0.13.68 is failing in the same manner with a:

Error executing command: mingw32-make
At C:\projects\mudlet\CI\appveyor.install.ps1:50 char:5
+     throw $errorMessage
+     ~~~~~~~~~~~~~~~~~~~
   + CategoryInfo          : OperationStopped: (Error executing command: mingw32-make:String) [], RuntimeException
   + FullyQualifiedErrorId : Error executing command: mingw32-make

Command exited with code 1

Help!

I agree with #1589 (comment)

So, apart from the AppVeyor support changes that haven't worked (and which I have just reverted) is there anything wrong with this now? Actually - once the changes have been pushed out to a new class the changes in the existing code looks quite clean to me now - I guess I start to see the advantages to encapsulation/inheritance/what-have-you in C++ with dropping in a TTabBar where there was a QTabBar and which appears to just add some extra public methods in, i.e. setTab{Bold|Italic|Underline(const {QString&|int}, const bool) and tab{Bold|Italic|Underline(const {QString&|int}) compared to the existing ones like setTabText(int, const QString&), setTabTextColor(int, const QColor&), tabText(int) and tabTextColor(int) ...! 🤓

Yes - #1589 (comment) please 😃

vadi2 I'm not sure I understand - are you saying that it is not suitable as it is now because you think it is still too complicated? 😕

I think it is okay - there may be methods that are not currently used (some of the state getters) but together there is a complete set of getters and setters for three separate but related font effects (bold, italic and underline) that are based on tab index (how the underlying Qt methods do other aspects of individual tab configuration) and on tab text (i.e. context - which is more reliable when the texts are not changeable - which matches our current usage - but the tabs may be reordered by the user - which I got the idea was the case or was requested - ah, it is still the subject of recent issue #1456).

Oh, as a side effect of increasing the tab text font size from 6 to 8, I think this PR will also address another recent issue and closes #1542 ! Edited so that GitHub will spot the linkage and auto-close the linked to issue when this is merged!

It may be that not all local things that change the contents of the main console for a non-active profile are yet detected but that is one thing I am happy to fix later as things show up (it would likely just need an emit signal_newDataAlert(profile name, false); at a point where it is missing - which I suppose could be something that you want/are happy to defer to another PR - and in that I would agree.

About using colours and differentiating local vs server changes - me & keneanung gravitate towards just bold, no colouring, and no differentiation.

We can add the differentiation later on if people are keen but I don't think it's a feature that'll really be appreciated and adding colours is problematic for aesthetic reasons.

👍 will test

I had already taken out the colouration!

I must confess bolding the tab text does not catch my eye so much as it might for some - but I have removed the underline (which did work for me).

Ah - I may have miss-interpreted the removal of differentiation of the source of the change - so try this commit instead....