Pinned Tabs: Now and Future
-
IMO pinned tabs should have special status (regarding, e.g., the closing behavior mentioned by @mkupper, and possibly some other behaviors as well).
Otherwise, the pinned tab feature isn’t needed at all!
Think about it, in 8.7.1 and earlier, here’s a good way for a user to (mock) pin a tab:
- manually move (click and drag) the tab all the way to the left (potentially joining other previously mock-pinned tabs there)
- (optionally) change the mock-pinned tab’s color (right-click tab, Apply Color to Tab > …) to match the user-chosen color for the other mock-pinned tabs
- regarding “meant to keep the tab in a location so it can’t move”, the user should just take care to NOT move a mock-pinned tab :-)
-
@Alan-Kilborn said in Pinned Tabs: Now and Future:
The one thing that isn’t on my list is the display of the pin icon on a file’s tab. I think that the visual component is rather core to the feature, and it is probably something that users might just have to live with (i.e., tabs being a little wider)
I pin tabs quite rarely, but then keep those tabs pinned and open for a very long time.
I would personally prefer only right-click menu to pin, rather than a pin icon on every tab forever that I would use only once in a blue moon. It feels too cluttered for my use case.My expectation was that pinned tab needed to be un-pinned to be closed. But perhaps that could be optional behavior?
I also prefer the width of the pinned tabs to be shrunk to a minimum to leave more space for labels for non-pinned tabs. I “know” what my handful of pinned tabs are as they are usually quite fixed.
-
@Alan-Kilborn said in Pinned Tabs: Now and Future:
The one thing that isn’t on my list is the display of the pin icon on a file’s tab. I think that the visual component is rather core to the feature, and it is probably something that users might just have to live with (i.e., tabs being a little wider).
If pinning is added to the right-click menu for tabs (presumably it would be a check-style item), is there any reason that function has to be available only when the feature is “enabled”? Or, to put it another way, is there any reason the feature shouldn’t be always enabled, with the Preferences option being whether or not to use up display space for the pinned status icon?
-
@mkupper said:
My first thought on enabling the feature was surprise that it added a blank area to every tab. It seems better to have added “Pin this tab” as a right click menu option. Only the pinned tabs would be a little bit wider and would show the pin.
@Coises said:
is there any reason the feature shouldn’t be always enabled, with the Preferences option being whether or not to use up display space for the pinned status icon?
Something like these may be the way it ends up going; IDK, I don’t have a crystal ball.
In the “Coises” case, there doesn’t seem to be a suggestion for what visually identifies a pinned tab; I think there has to be something: a special color for pinned tabs, or some sort of demarkation between the pinned tabs and the unpinned tabs (not sure what that would be), or etc.
-
@Alan-Kilborn said in Pinned Tabs: Now and Future:
In the “Coises” case, there doesn’t seem to be a suggestion for what visually identifies a pinned tab; I think there has to be something: a special color for pinned tabs, or some sort of demarkation between the pinned tabs and the unpinned tabs (not sure what that would be), or etc.
It would make sense to have an indication. Since all the pinned tabs are necessarily to the left of all the unpinned tabs, I should think a small gap — say, 1/3 the height of a tab — between the rightmost pinned tab and the leftmost unpinned tab would be clear enough, while requiring little screen space.
Then there could be a context menu item, and the Preference could just be about whether to display the icon (analogous to Close and the close icon — Close is available on the context menu for tabs whether you show the close button or not).
-
@Alan-Kilborn said in Pinned Tabs: Now and Future:
I think there has to be something: a special color for pinned tabs, or some sort of demarkation between the pinned tabs and the unpinned tabs (not sure what that would be), or etc.
There already is. The unpinned tab’s top is tilted to the right, and the pinned tab’s top is straight up.
Maybe someone needs to define what the heck the original purpose of the pinned document is, because it sounds like feature creep is taking place in real time.
As I understand the purpose of a pinned tab, it’s to keep it from moving when other tabs can be moved, rotated, slid to different positions, etc… , not to make it a super permanent unmovable object, which by the way, happens if you pin it and don’t close it, being it’s saved in the session file.
The simple act of changing the pinned status either by mouse click, right click selection or what not it is already doing what it is supposed to do, keep the tab pinned to the left side of the editor window. -
I said:
I think there has to be something: a special color for pinned tabs, or some sort of demarkation between the pinned tabs and the unpinned tabs (not sure what that would be), or etc.
@Lycan-Thrope said:
There already is. The unpinned tab’s top is tilted to the right, and the pinned tab’s top is straight up.
That’s off-base.
I was saying that if there is no pin icon on the tab whatsoever, there is no way to tell with a visual glance where any pinned tabs stop and unpinned tabs begin.
Maybe a workable solution to the “have the visual indication” but “not make tabs wider” problem is, as suggested before, to only have a pin icon on tabs that are pinned (and not the unpinned ones). Of course that means that to pin an unpinned tab there must be a command to do that, and it makes sense, also as suggested before, for that command to be on the tab right-click context menu.
While the “visuals” of the pins themselves (disregarding extra horizontal space they consume) in 8.7.2 is awesome, I’m starting to think that the pin icons should be removed entirely, and a pinned tab should be given a special background color. Obviously this then mandates a command in the form of a right-click-on-tab (and indeed, it appears that such a command and menu item is ON ITS WAY ).
-
@Alan-Kilborn said in Pinned Tabs: Now and Future:
That’s off-base.
I was saying that if there is no pin icon on the tab whatsoever, there is no way to tell with a visual glance where any pinned tabs stop and unpinned tabs begin.Not off base, just looking at it a different way. However, your follow-up suggestions in the rest of the message have merit solving the overall problem, perhaps… It would clean up real-estate, make the tab stick out, and demarc the rest of the non-tabbed tabs as well. A more complete view of a design decision. One more caveat though. If users end up being able to custom color tabs, couldn’t that possibly lead to additional confusion? In this case, the suggestion of the pinned tabs having the icon, would help clarify any color collisions that could come up.
-
@Alan-Kilborn said in Pinned Tabs: Now and Future:
While the “visuals” of the pins themselves (disregarding extra horizontal space they consume) in 8.7.2 is awesome, I’m starting to think that the pin icons should be removed entirely, and a pinned tab should be given a special background color.
Or a pinned tab could be shrunk to only show the pinned tab icon.
Visually this would mean that pinned tabs consumes minimal space while still using the excellent pin icon.
Pinned tabs could additionally be given a different (configurable?) color.
The mouse-over hover shows you the name and other tab relevant data. -
I would vote for the pin being invisible unless a tab is pinned, and making it so the user can only pin a tab by right-clicking and choosing a menu item. This conserves screen space and makes it difficult for the user to accidentally pin a tab. To be clear, a pinned tab could still be unpinned by clicking on the pin icon.
-
@Snabel42 said in Pinned Tabs: Now and Future:
Or a pinned tab could be shrunk to only show the pinned tab icon.
IMO this isn’t workable, even when considering:
The mouse-over hover shows you the name
Sorry, just my feeling about it.
-
-
@Snabel42 said in Pinned Tabs: Now and Future:
@Alan-Kilborn said in Pinned Tabs: Now and Future:
IMO this isn’t workable
Could you elaborate?
I’m not him… but if you’ve pinned more than one tab, you surely want to be able to see which is which at a glance. Perhaps there is some other use I haven’t grasped, but it seems to me the whole reason for wanting to pin tabs is to be able to access selected documents easily. Hiding the file name would defeat the purpose.
-
@Snabel42 said in Pinned Tabs: Now and Future:
Could you elaborate?
Say I have 5 or so important files, so I have them pinned.
If I see 5 identical looking tabs with only a pin icon on them, I’d either have to mentally memorize their order, or hover-pause-hover-pause-hover-… to find the one I’m looking for.
So I don’t think that is workable, but that’s just me.It could totally work if you had just 1 pinned tab, but in that case do you really need it pinned? (No, just move it leftmost and pretend it is pinned)
-
@Alan-Kilborn ,
Or you could just use a readily available feature of NPP, a View->DocumentList option, which allows you to see the name, the files, and select them as well, and they’re already ‘pinned’ on that list.
The pin tab is a redundant
neat UIfeature to me. It’s not useless, but giving it the ability to do what is already available is just redundancy for redundancy’s sake, it seems.
Perhaps the solution is to remove the clickable tabs, and force the user to use a Document View to manage their complex document tabs. -
If it were up to me (feel free to give thanks that it isn’t):
Show close button on each tab and Show pin button on each tab would be three-state check boxes. Cleared, the buttons don’t show. Checked, the buttons show. Grayed, no space is reserved for the buttons and they do not show until the mouse pointer is over the tab, at which time the buttons overlay the rightmost portion of the tab, with the part of the filename underneath the buttons being (temporarily) erased to avoid a conflicted visual appearance. (Alternatively, those remain simple check boxes and an additional Show tab buttons option is added with choices On all tabs, On active tab and Only on mouse-over; the first two reserve space while the third does not.)
Both Close and Pinned options would appear on the right-click menu for tabs and on the File menu (applying to the current tab) at all times. Pinned would be a toggle with a check mark indicating the current state.
Right-clicking a tab or clicking a pin or close tab should not change which tab is active. Right now, it looks like right-clicking activates the tab, clicking the close button does not, and clicking the pin button activates the tab if and only if it causes the tab to move.
Regardless of buttons, pinned tabs would be separated from ordinary tabs by a space about as wide as a third of the height of a tab. This space wouldn’t appear unless there is at least one pinned and one unpinned tab. When the space does appear, dragging a tab to a position on the other side of the space would automatically pin or unpin the tab.
-
@Coises said:
If it were up to me (feel free to give thanks that it isn’t)…
Definitely some wisdom in all the info in the post.
@Lycan-Thrope said:
the solution is to remove the clickable tabs, and force the user to use a Document View to manage their complex document tabs
Heresy! :-)
-
@Coises said:
pinned tabs would be separated from ordinary tabs by a space about as wide as a third of the height of a tab.
I wonder how feasible this is. I mean, sure, with software most things are possible, but that sounds like it might be a lot of customization to the tab container window thing to make it happen. If true, that would make it much less likely to be realized.
dragging a tab to a position on the other side of the space would automatically pin or unpin the tab
This makes me wonder if, even without the space, if the user attempts to drag an unpinned tab to a position in between two already-pinned tabs (or to the very left of the first pinned tab), if that tab should become pinned by that action – I’m thinking yes, it should. But perhaps the other way should be disallowed, as a pinned tab should have more protection from that sort of change than an unpinned tab.
-
@Coises said:
Right-clicking a tab or clicking a pin or close tab should not change which tab is active.
Right now, it looks like right-clicking activates the tab,
Are you inclined to make an “issue” of this?
I’ve noticed this behavior before and wondered about it myself.
Now I’m wondering if there is a good reason for it, i.e., would changing it mess with some other Notepad++ functionality?
I’m also wondering if a change in behavior would bother some of the scripts I’ve written and depend upon…clicking the close button does not,
This is true if the file is not modified; if modified, then the tab will be activated before the prompt-to-save box appears.
and clicking the pin button activates the tab if and only if it causes the tab to move.
This seems like a definite problem. First, it should be consistent. Second, it should IMO operate like the close button (for a saved-file); it shouldn’t activate the tab.
-
@Coises said in Pinned Tabs: Now and Future:
If it were up to me (feel free to give thanks that it isn’t):
Interesting suggestions, but a lot of work and moving parts to further confuse users? Just a thought, but it would be up to the developer if it’s to be implemented, I still like simple, though. :-)
