Pinned Tabs: Now and Future
-
@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. :-)
-
@Alan-Kilborn said in Pinned Tabs: Now and Future:
Heresy! :-)
I’m evil that way. :-)
I just would hate to see so much whizbangery that it in essence starts to slow and complicate the application. :shrug:
I mean, look at the problem I encountered just changing my background color, that ended up affecting my Smart Highlighting coloring. Too many moving parts creates more potential for problems. I’m not against improvements, just not for the sake of improvement at the costs of simplicity. -
The pinning is a nice function, but i dont understand why the pins scrolling left out if i have opend many tabs and use the left/right button at the tab bar?
I think a pin was at the left site a fixed position for fast access. If the pins are no more visible, they are useless -
@rrmoch said in Pinned Tabs: Now and Future:
The pinning is a nice function, but i dont understand why the pins scrolling left out if i have opend many tabs and use the left/right button at the tab bar?
I think a pin was at the left site a fixed position for fast access. If the pins are no more visible, they are uselessGood point. For now, all you can do is enable Tab Bar: Multi-line; but if you have that enabled, pinning doesn’t do anything you couldn’t do with a mouse drag.
What do you think should happen if a user pins so many tabs that they fill or overfill the space, leaving no room for unpinned tabs? (My suggestion would be that when you run out of space, multi-line mode is forced for the pinned tabs only, leaving the bottom row of tabs with room for at least two unpinned tabs, which can still be scrolled.)
I have to admit, pinning tabs strikes me as something that sounds good when it’s envisioned as a simple feature, but as soon as you add it there are a lot of details that crop up, and when it’s not so simple anymore, it’s unclear to me if it’s even worth the effort. I could honestly see leaving it as it is and figuring: it’s clunky and incomplete, but if it helps somebody, fine, if you don’t like it you can turn it off, and it just isn’t important enough to justify all the time and effort that would be required to polish it to a high gloss.
-
@rrmoch said:
The pinning is a nice function, but i dont understand why the pins scrolling left out if i have opend many tabs and use the left/right button at the tab bar?
I think a pin was at the left site a fixed position for fast access. If the pins are no more visible, they are uselessI don’t think you’ll see a change to the software for such a circumstance.
It’s sort of implied that “multiline” is used with the pinning feature, although it doesn’t go so far as to be a requirement (i.e., the software doesn’t prevent the pinned tab feature being enabled if multiline is not enabled).It’s sort of like if the tab bar is set to hidden; pinned tabs aren’t of maximal usefulness there, either. Presumably, in such a case the user uses the “document list” feature (the pinned tabs would be shown first in the window for that, but aren’t identified separately from the unpinned tabs).
