Explore how to indicated read-only and deleted files open in editors more effectively

[miguelsolorio]

Summary

Currently when you open a file and it has been deleted or you open a read-only file, we append the text to the editor tab to indicate this:

This can get busy when you have a lot of tabs open, especially with long names. This issue aims to explore a few different ways that we can visualize this.

Concepts

Option A

One idea is to try and use different seti file icons for this and show the information via tooltip:

Alternatively, we could use codicons to display instead of seti:

Option B

We could use our info icon for read-only and error for deleted:

Option C

Or we simply rely on the decorators to indicate it, we'd need to figure out how to show read-only:

cc @bpasero

[bpasero]

👍 , one interesting aspect of this is that a tab can indicate both readonly and deleted at the same time.

[miguelsolorio]

@mjbvz let me know what the use case is for custom editors and if the "read only" state would still apply or if you're looking for an alternate version

[miguelsolorio]

I'm leaning towards leveraging the existing git decorators and using our custom hovers to display this information (as opposed to the native ones) and swapping to codicons for easier discoverability:

@bpasero thoughts?

[bpasero]

leveraging the existing git decorators

but the decorators are not using red for deletion it seems, probably because that is reserved for showing problems:

Are you suggesting to change decorator color for deletes to show like problems?

Also, are you suggesting to add a new decoration R for the readonly case?

and swapping to codicons for easier discoverability

To clarify, you mean to show an additional icon to the left of the label for conveying the information that the file is deleted or replacing the file icon with it? Also note that user can disable icons.

using our custom hovers to display this

Can you elaborate why this better than the native hover where the same information is displayed?

[miguelsolorio]

but the decorators are not using red for deletion it seems, probably because that is reserved for showing problems:

I think currently this depends on whether you have any warnings/errors:

So I'm suggesting for Deleted & Read Only to have an elevated hierarchy to the warnings/errors because when a file is deleted, the warnings/problems don't mean anything because the file is now gone. For Read only, you can't edit the file so the warnings/errors mean less.

Also, are you suggesting to add a new decoration R for the readonly case?

Yes, since decorators already show a D for deleted, it made sense to add R for read only, though I don't know if there is a similar concept in git for it. My suggestion was to keep them consistent.

To clarify, you mean to show an additional icon to the left of the label for conveying the information that the file is deleted or replacing the file icon with it? Also note that user can disable icons.

Suggestion is to replace the file icon with our codicons and yes there are also other states that will hide all of these indicators like:

Can you elaborate why this better than the native hover where the same information is displayed?

Because our custom hovers can appear much quicker than native. I'd love it if we switched all hovers to it but understand the challenge in doing so.

[miguelsolorio]

I brought this up in our design-wide critique for some feedback and here's the suggestions:

• Showing codicons as status icons (like the trash icons) can be a bit confusing, is it a status or an action?
• People associate the the filename w/ the file icon so replacing the file icons can cause additional overhead for the user
• Everyone liked the strikethrough for deleted files
• Additional indicators like tab background color could be another option to explore
• There was a preference for using the git decorators for the status (even though read only isn't a git status, but is a decorator)
  

[bpasero]

I have pushed a change to enforce the strikethrough decoration. Fun fact, the decoration would have worked, but we had a CSS rule to disable text decorations in tabs, not sure why.

With SCM

Without SCM

The fact that a file is readonly only shows up in the hover and not as a decoration because I think showing R is misleading: SCM uses that to indicate a file was moved.

Because our custom hovers can appear much quicker than native.

That is a user setting tough right? And by default we try to match OS defaults.

[bpasero]

Btw one issue with using decorations to convey this information is that I cannot really limit the decoration to tabs only, so we would end up potentially having 2 decorations for "deleted" (one from SCM and one from the the new location) across all UI pieces that support decorations...

[miguelsolorio]

I see, so then we need to explore alternate options that don’t rely on decorations?

[miguelsolorio]

Visual Studio uses a lock icon for read only:

So if Deleted uses the strikethrough, I wonder if we can append a lock icon for read only that way each can work independently without icons/decorators?

[silkfire]

Maybe it's just me, but if a file has been deleted, then I no longer care whether it was read-only or not.

[bpasero]

I went ahead and fully embraced decorations for this:

It is possible that multiple decorations apply, e.g. in git case, but I think that still looks fine:

[bpasero]

Related hover indicator:

[miguelsolorio]

Looks good!

[bpasero]

@misolori feedback from the standup was to maybe use a different icon since we use the lock already for locked groups. Not sure we would have anything else in the cards. I personally do like the lock icon though.

[gjsjohnmurray]

I also like the lock, but understand the scope for confusion. Could the eye codicon represent a view-only document?

[miguelsolorio]

yea we could use eyes as an alternate that would still work well with locked groups:

But we do use the lock icon in multiple areas (notebooks locked cells, output scrolling, ports privacy) and we add the lock icon to the tab and not the group so I personally still think it's fine to use: