Proper tabs for open files #224
Comments
|
+1 Would it be possible to add tabs through a custom extension? I quickly looked at the docs but didn't seem possible to add that type of functionality with the current API |
No, this is currently not possible from an extension (see also http://code.visualstudio.com/docs/extensions/our-approach) |
|
+1 |
|
👍 |
|
👍 |
|
+1 Tabs are the default way to work even in Visual Studio, to not mention other text editors such as sublime. |
|
For those that are missing tabs, have you tried using |
|
Yes. But the file remains in the |
|
@snehilmodani right, would it help if the list was showing only what you have in the working files section of the explorer? can you work with the working files list at least? |
|
That would be great! On a side note: Isn't a layout with file names as tabs more user friendly. It is extensible to having one or more sections of tabs each with their own set of opened files. (Again i am taking Sublime Text as reference here) |
|
I think having tabs or not is independent from having sections. Today you can open up to 3 editors side by side in VS Code and thus we do have sections. Since we do not have tabs, we do not add multiple files into these sections and you can also not have empty sections (which is a separate UX discussion). Coming back to Ctrl+Tab: We in the team have always worked without tabs from day one and actually we did not even have the working files view for a long time and in fact not so many people in the team are using it. We found that for us it does not matter that much which file you had open or closed. Our minds are rather thinking about the chronological order of which file we edited last. So when I bring up Ctrl+Tab it will typically show me those files I was in last. I am not really looking at the number of files in there, I am only interested in the Top 5 ones at max. The advantage of this model is that you do not have to manage layouts and tabs at all. The management happens naturally while you navigate between files. We can add a file picker for working files, but it would be interesting to hear if people can be convinced to use Ctrl+Tab as it is today and learn what the issues are. |
|
@bpasero I'll give By the way, regardless of whether one can get by / used to |
|
Yes, |
|
Regarding Tabs and multiple files in each sections: Even in Sublime Text we can open 3 editors side by side but they still offer a sectional tabbed layout. I agree with you on the clutter and managing the layout of the editor would be quite a task but people are used to that anyways. |
Well I am sure we can find more UX examples where we used to be used to something and then we got used to something a lot better :). Think mobile phone keyboard vs smartphone touch interaction.
Yes I think we will need to do something like this 2016. @stevencl fyi |
I agree on an option to allow for more stable sections so that we can have empty sections, but being able to see tabs in this section is just a visual representation of the files in there which in most cases grows so much that you end up not seeing anything. I do not think tabs are a good way to show the list of open files unless you manage these things actively and close them. |
Some people actually manage them and for others there is close tabs to the right. |
|
Thanks very much for the feedback. We have an issue on our UX backlog (#1133) to improve workspace management (managing open files, history etc) which this would be a piece of. Our intention is to improve the experience such that managing the list of open and recent files is straightforward and easy and allows the user to focus on their code, without having to pay any undue attention to the VS Code UI. Our hypothesis is that the current system has some rough edges (e.g., closing an editor actually closes the editor, but we think that perhaps it should instead show the file that was previously open in that same editor) and that smoothing out these rough edges will help create a far better experience. We do UX studies on the product on a very regular basis. In fact, that's how we design a lot of the UX in the product. We iterate over our designs based on real feedback making sure that we use a great understanding of what people do and want to do with the product to inform our designs. If you would like to participate in these studies in the future (we won't be running any again until mid January at the earliest) let me know and I will add your name to the list. |
Sign me up! |
Tab management is an unconscious and uninhibiting part of my development. VS-proper has small discreet tabs, which are unintrusive (vscode already has the filename taking up space where the tab would otherwise be). I do agree that runaway tab spam is a problem, it might be nice to innovate and address this, but I'd say that's lower priority than having tabs at all. VSCode needs to reach a minimum working state. Right now, I find it's getting very close, but I can't quite work productively yet. Starting with established patterns would probably get us working sooner. It's worth keeping in mind that not everyone is a web developer, I find that patterns and workflow tends to be slightly different for different languages and styles of application. As a native developer, it is common to have a set of associated files visible; Right now for example, I'm trying to refactor and simplify some legacy code; my current working set of files is... component.cpp, component.h, component.inl, componentimpl.cpp, componentimpl.h, icomponent.h. That's 6 files! And I can't escape from the occasional tweak of some other files on the periphery. I use ctrl-tab liberally when I'm working on that style of project (flipping between 2 files), but in this context/codebase, I simply can't work without tabs. Refactoring and maintaining legacy code has a very different workflow from writing new code (which I imagine you guys are doing, and using mostly as a guideline for UX design). My point here is; there's a modern desire to reinvent everything, and we have seen huge strides in UX design in recent years; vscode already presents some of these, but be careful and apply good judgement when deciding to change the way people have been working for decades. Many established designs are established because they are good and efficient, not because they are old and need updating to be more trendy :) I would appreciate the opportunity to be part of these focus studies! |
It's the case for me. Actually i can't work without tabs. I'm working with tabs system since years, and without them, i'm really lost. This is one of the reason i'm not using Code actually.
👍 |
|
So far I have not yet heard a good reason for tabs compared to having just a list of "working files" somewhere. Being able to take a file and drag it out into a new window is clearly not a benefit of a tab system, it is a feature which you can have without tabs. Is it that people really want to open files in tabs, move them around and close them eventually? Is this because you are so used to it or is there actually a value in doing so? Is the value being able to set an active working file set that you later on dismiss to start something new? I wonder what is so good in having tabs that you cannot achieve with another way of representation. And I am not accepting the argument that everyone is used to tabs :). A lot of people are used to saving files and still there are editors with auto save capability and people seem to like it. |
|
Even if it is not by default, giving the user the choice to activate the tabs feature through some option would be almost as good for me. For example, what about letting the user move/drag the "working Files" section to the top (converting them into tabs lets say). Again, the user may choose how he wants to work and I think that is great! |
|
For me it's not so much the appearance of tabs as the behavior of them that I miss. (For example, you can get Sublime Text to look kind of like VS Code in that you can hide the tab bar and show the open files in the sidebar instead...but they still behave exactly like the tabs do.) The first thing I ever do with VS Code is swap its close file and close active editor keyboard shortcuts, so that ctrl+W actually closes a file when I press it, rather than still leaving it in working files and cluttering up ctrl+tab. But even then, every time I close a file, I am greeted with a blank screen and have to ctrl+tab just to show the most recent still-open working file (heck, when it's the last one, I seem to also need to hit enter after ctrl+tab; not sure what that's about). In any other editor, I'd immediately be greeted by either the most recent or adjacent open file (tab) upon closing the current one. Additionally, ctrl+tab between working files appears to work in most-recent order, as opposed to tabs which usually operate in the order they appear or are arranged. (I've seen some editors support both.) I don't use split windows, so if any of these behavioral differences have anything to do with that, it's lost on me. Maybe I'd understand it better if I understood it from that angle, but wouldn't no-split still be the most common use case? At any rate, it's small but frequent bits of friction like these that keep me away from VS Code and going back to other editors. Yes, you could say it's that VS Code operates differently from what I'm used to. But when what I'm used to works, and VS Code operating differently causes friction that I'd sooner use a different editor to avoid having to deal with, it's kind of a big deal. |
|
Yes, I can see a model where the editor area behaves similar to tabs without showing tabs. We want to explore this next year. Btw there is an extension that - once you close an editor - opens the next one from working files. If you combine that with changing the keybinding as @kfranqueiro suggests, you get pretty close imho. |
|
+1 |
1 similar comment
|
+1 |
|
👎 |
|
Whats going on here, why do you resist giving us an option to use tabs? 😕 |
|
@aminroosta Seriously... can't you read? are you blind? Funny thing is you're asking what's going on here... and then go on and assume they actually decline it or in your own words "resist" when in fact they confirmed tabs are coming and working on implementing it! Some people in this world! unbelievable! |
|
@eyalsk Sorry about that. |
|
We cannot blame microsoft R&D to try to inovate. Tabs system has cons. UI design is like all form of design. 90% making what user wait for, 10% making new things, trying to create a new revolutionnary and user friendly system. all user friendly system seen as must have in new text editor today has been experimented and controversial before. |
|
@aminroosta I'll give you a tip, when you're reading a long post, read the original post and then to get the latest updates spend a min or so on scrolling from the bottom to the top. |
|
That's a good suggestion as this a VERY long feed. On Sun, Jun 5, 2016 at 10:42 AM Eyal Solnik notifications@github.com
|
|
Personally I like the Ctrl+Tab approach. From my personal experience, tabs can get messy quickly if you have 10+ of them open at the same time. I'd say remove the "working files" or at least leave it as an option. I don't use it and it adds confusion for me. I'll use Ctrl+Tab from here on thanks! |
|
@adred Both |
|
Can you please lock this thread and open a new one with the important bits of this one copied into it? There are still comments coming in daily from people who can't read it all (should tell you it's too long), and asking the same question over and over again, and once the release of tabs hits the public builds we're going to see even more spam in this thread. I want to stay up-to-date on tab-related happenings, and this thread is currently the place to do that, but it's super annoying to get spammy emails multiple times a day for the same comments over and over again. Apologies for tone & thanks. |
|
There are so many +1s that it is a bit much. On Mon, Jun 6, 2016 at 2:16 AM -0700, "anyong" notifications@github.com wrote: Can you please lock this thread and open a new one with the important bits of this one copied into it? There are still comments coming in daily from people who can't read it all (should tell you it's too long), and asking the same question over and over again, and once the release of tabs hits the public builds we're going to see even more spam in this thread. I want to stay up-to-date on tab-related happenings, and this thread is currently the place to do that, but it's super annoying to get spammy emails multiple times a day for the same comments over and over again. Apologies for tone & thanks. You are receiving this because you commented. |
|
Just a comment on the update text @ https://code.visualstudio.com/updates#_workbench The text was unclear to me and I actually thought that the updated stacks were already here (and that tabs would come later). After updating I didn't see the updated stacks and had to re-read the text a few times. To me it says that Tabs will take more iterations (so no tabs in this update), but that in May you made great progress on how to manage stacks of editors (so despite there being no tabs, updated stacks are in this update?) and that there is more work to be done for the June release branch (to improve stacks even further?). So to anyone who may have been confused like I was.. looks like updated stacks are not actually in this update. I guess it's just a preview of both tabs and stacks to come. |
|
I agree with @RyanEwen. I really appriciate the open development and amount of communication, but these announcements being part of the official "Release Notes" is really confusing. Maybe this can be split up into actual release notes, and 'what we're working on right now' or something. |
|
Linking this issue in the Roadmap has not been a good idea because if you read it from the first time you will not get a clear idea of the current status ( more than the Milestone). There's still job to be done but the current state is okayish 👍 |
|
Yeah, they should summarize issues and then have links to these summaries so people would know the current plan after it was discussed. Linking to discussions is bad because they tend to be lengthy and people can't get the idea without reading almost everything but dunno maybe it's not possible for them to do it otherwise. |
|
When I started reading the release notes for 1.2, the first thing I looked for was the Tab Feature. I appreciate that they put the current status there. But I also got confused. At first I thought it landed, than I realized it didn't, but a lot of progress was made. In that case it really feels like that item should be at the bottom of the release notes with a link to the discussion or a milestone (they both prove the progress on the feature) along with a small note saying something like "Check out the progress towards Tabs implementation". Regardless of this minor thing. Great job on the release. VS Code is a great product with amazing development cycle. |
|
VSCode just updated to 1.3.0-insider. Recent files seems to be gone. Is there a way to do that now? |
|
Thanks for the feedback on the release notes and sorry for the confusion. I've made modifications to the doc to make it clear the work is not in Stable, but that you can preview the tab work in the Insiders Release. Having a section towards the end where we talk about work accomplished but not in the stable build is a good idea and we'll do that next month if we have more work that fits into that bucket. |
|
@JoshClose please open a new issue for this as I will be locking this issue shortly in favor of individual issues instead of this single thread. thx. |
|
First, let me thank everyone one more time for your thoughts, likes, and dislikes about tabs. The feedback we have seen in this thread (both positive and negative) really shows how passionate people are about the future of VS Code. I think everyone can agree that we've exhausted the utility of this issue and as a result I am going to lock the conversation. We will leave this issue open until we ship with an option for tabs/no tabs, which we plan to do by the end of the June 2016 iteration. While the VS Code team may post updates in this issue, you should expect that we will create new issues for additional tab designs or discussions. We will mark issues with the Thanks again, now go and install the Insiders Release! |
|
#6605 documents all the added or changed command identifiers to use with keybindings. Because the stacks model is such a large change to the UI of VS Code, we decided to revisit all commands that relate to editors or groups. |
|
We are happy to announce that you can now enable tabs in our nightly insider builds (http://code.visualstudio.com/Download#insiders). The related setting is
There is still some work planned in this area until the end of the month (and probably beyond) so we are happy to gather feedback from insiders. Feel free to open issues as you find them while using tabs. Thanks! |
|
As @bpasero has mentioned you can now enable tabs in our nightly insider builds. If you have tried this and can spare 30 minutes to share your feedback, please sign up for a chat here: https://calendly.com/stevencl/vs-code-tabs/ Unfortunately I can only offer time slots during the day my time (I am in Edinburgh, Scotland) Monday and Tuesday next week. |
|
tl;dr; enable tabs in VS Code insiders build with We are closing for the June milestone during this week with our usual endgame testing. Tabs are on the test plan (#7854) and will get some coverage during the week. We still expect to do fixing on tabs for June and possibly refinements based on feedback post June. The majority of the work is done though, so I will close this issue. From the description of this work item, @TurkeyMan asks for having tabs and a way to move a tab out of the workbench to open inside a new window. I have extracted the latter into #8171 since it is not related to the tabs work we did. Please continue to file issues on tabs as you see them while trying them out. Thanks for helping in testing the insiders build! |
and others
I really miss proper tabs for open files (like VS proper), and the ability to rip a tab out into its own window.
The text was updated successfully, but these errors were encountered: