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++
I really like this idea. Especially if (later) some form of automatic assigning of the color could be done or you could assign the color with a plugin.
I am not an NPP core dev so I don't know how difficult it really is, but after a quick look at the SVN (line 51/55 and 336/359) it shows the control that is used to create the tabs supports changing the background color.
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 :-)
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.
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.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.