Feature suggestion: Colored tabs

Marcel S.
  • Marcel S.

    Marcel S. - 2013-12-19

    Hello, dear Notepad++ maker :)

    I have a little feature suggestion for Notepad++: It would be very helpful, if we could give tabs colors. It would help to keep the overview when many tabs are opened.
    The standard color should be grey as currently. If I right click on a tab, the tab context menu could contain a menu item "Tab color", and then a submenu with 5 (or so) predefined colors - red, green and so on. No color picker please, as this would take more time, I think.

    Or semi-automatic: If I open files from a specific folder (and its subfolders), the tab could automatically have a predefined color. This should also work with FTP folders.

    Example usecase: When I work on my website (via FTP connection), I make all changes on a test installation at first. Typically I have 3 to 8 files involved. Then, if everything works, I make the changes on the live installation. I open the same files from a different folder (the live installation). Now I need to be attentive not to mix up the test files and live files. Therefor colored tabs would be useful. I would give all test files - lets say - green tabs, and the live files yellow tabs.

    That would be a great thing!

    Thank you for Notepad++


    THEVENOT Guy - 2013-12-19

    Hi Marcel S.,

    Like you, and Franck, I think that this would be an interesting feature.

    The possibility to automatically attribute a colour, depending on a parameter as file extension, containing folder or even file encoding would, of course, be useful and help to class all the opened files !

    The possibility to sort by colour, in the N++ Windows Manager would be nice too :-)

    But, I'm NOT an N++ developer too (-: and we must be rather patient as it looks like a complete project :-)

    Best Regards,


    Last edit: THEVENOT Guy 2013-12-19
  • Eustace

    Eustace - 2013-12-22

    I would be satisfied if they would change the font color of the selected tab title to the system default. I like to use white on dark color schemes, and the black selected tab title is unreadable. Since the selected tab background uses the Windows menu background, is should also use the menu foreground, not assume that it is black.

    Of course colored tabs would also solve this issue, as long as one they use the appropriate foreground.


  • cchris

    cchris - 2013-12-23

    If we keep the concept of an overriding active tab colour scheme (should we? perhape the top bar is enough and could be made permanent), determining how a tab should be shown should apply to inactive tabs only.

    Currently, the background colour for inactive tab is held in a static, protected class variable, initialised once at startup and updated when the appropriate global style is modified (btw I still hold that changing the background shouldn't change the foreground text, and that this is a bug). As a result, if the code is kept as is, a plugin cannot directly interfere with this, so it has to plug into the message processing loop.

    Since the drawing is done by processing the WM_DRAWITEM message, what a plugin could do is to
    subclass the tab bar controls
    catch and process WM_DRAWITEM when tab is not active (you need to send NPPM_INTERNAL_ISFOCUSEDTAB to cater for the case when the tab is active on the other view, hence drawn differently)
    draw inactive tab according to rules involving either
    the document name: easier, since this is in the tab item structure which needs to be fetched anyway to check tab state
    the full path: then the plugin needs to exchange a bit more info with N++, ie send NPPM_GETBUFFERIDFROMPOS to retrieve target buffer ID and then sending NPPM_GETFULLPATHFROMBUFFERID (twice) to get the associated full path.
    This involves duplicating most of TabBarPlus::drawitem()'s code.

    Subclassing the control needs to be done very cleanly, specially for a 32-bit app running on both 32- and 64-bit systems.

    I won't cover the fun part about handling drag and drop. The transitional image needs not apply the colour rules, so this may be a non-issue. Nor will I cover how to use regular expressions on the document name/path - simplest could be to create a permanent, private, hidden Scintilla, setting its text to the name/path and calling its engine. For using PCRE, I don't know how to do it without the dll redundantly linking with pcre.



Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks