Declarative contribution of custom explorers (based on tree models) #12163
Comments
|
I'm finding a lot of trouble understanding how the jump from declarative contribution of custom explorers (based on tree models) to Expose API to create a custom explorer viewlet happened. Even how the initial story title even came to be. It is my strong belief that we should not allow extensions to create new viewlets. I'll go through each of the related issues, one by one:
In essence, the whole thing seems to be only about symbols tree, so why not just focus on that problem? A symbols tree view is seldom used for anything other than navigation. Putting it in a viewlet is a preference of few, but likely just wasted space for most. Having it in quick open fashion is what solves it for 90% of the situations: a way to quickly navigate to another type. We already have this in Quick Open, albeit as a flat list. So, let's allow quick open to show items as a tree. Still want a persistent view? Write an extension which renders it in an editor pane and place that on the side of your editor. Want it in the viewlet pane? Let's make the explorer explore more than files. But one doesn't simply open the door to our UI kingdom. On to my closing arguments: Throughout this project, the most interesting question that I always seem to go back to is: what differentiates Code from its competition? Following that train of thought I ask myself in what way does an editor differentiate from an IDE? Where can we draw that line? Is Code either or a bit of both? I come to the conclusion that it's been our ability and willingness to responsibly say no to certain feature requests, while obviously providing acceptable alternative solutions, that has made us grow Code successfully. cc @Microsoft/vscode for team input |
|
I fully agree on growing existing principles and concepts over introducing new ones. It's clearly harder but IMO yields in a better product. We should keep up the "art of saying 'no'". Or better put in this HN comment:
|
|
So long as you can add whatever content you like into the viewlet, it should be fine. Personally I want to add icon buttons to a custom viewlet, that can be user/workspace configurable to run terminal commands. |
|
@joaomoreno Regarding your question: "what differentiates Code from its competition", I would have to disagree with your proposed answer. In my view the answer is:
While "saying no to certain feature requests" is definitely an important factor in the development of any product, including VSCode, I don't think it's even a minor differentiating factor for VSCode. In fact, in my view, saying no to feature requests is much more about triaging what should be done now, and what later, not about what should and should never be done. Saying "never" to any feature by extension alienates groups of developers, who wish for certain functionality. Say: "not now, there are more important things to do now!" instead! But that's just my humble opinion, maybe I'm wrong. :) You do what you must, cause you're still the best OSS team in my book. 🐝 |
|
My two cents here: Basically I agree with @joaomoreno 's concern about allowing users to create custom viewlets. The first time I heard about this plan, the first idea came to my mind is
which has nothing to do with the original feature request: Symbols Tree View or Outline View. To some extent, this give people freedom to customize Code and always cultivates creativity but this makes me worried about whether we are doing too much and maybe we should just focus on improving Symbols/Outline navigation. Secondly, we do have symbols navigation builtin but it took me a long time to find that feature: I was attempt to open files by pressing |
|
There are a few different issues covered in the comments above. So, let me try to fiddle them apart and shed some light on them.
|
Tyriar
changed the title
|
I clarified the title and issue description, I was leaving it up to an investigate whether it would be an API or contribution (since contributions are part of the API). |
|
I'd like to point out that my original request was for facilitating custom buttons on the activity bar (#10709). That was closed in favor of exposing the activity bar api (#8511) which was then closed in favor of this feature-request. Now this is down as "custom explorer"... so either this issue should be "Custom viewlet (any content)" or please reopen #8511 or #10709. |
|
If your case is This way you can also add |
|
That is just an example. The idea is to allow users to do rudimentary customization of the UI to add command of their choosing to simplify their workflow. You mentioned in the other issue that this api would facilitate a) a custom button on the left activity bar that b) opens up a fully customisable viewport on the sidebar. With that that I could create an extension to create a viewport that had cli buttons and information for say Angular-2, Aurelia or React. Aurelia, for example has a cli to add components, converters and custom attributes to a project. Buttons for those could be added with a truly customisable viewport. |
|
@MeirionHughes please don't derail the conversation, I went over in depth why we would not allow arbitrary commands through activity bar buttons in #10709 (comment) |
|
I'm not derailing anything; I'm merely stating what I would do with this feature if it does what #8511 implied (customisable viewports opened by an activity-bar button), which is relevant here as you closed #8511 in favor of this. So to clarify, does this issue facilitate adding an activity-bar item, which when clicked will open a custom viewport (like the debug viewport), the content of which is customisable by the extension author to be, and do, whatever they like? |
|
@MeirionHughes examples of what you would be able to implement are in the top issue description; a new button on the activity bar which is linked to a new viewlet (sidebar) that has some tree structure in it. The main thing clarified so far from the discussion is the way in which extensions would register the viewlet (contribution vs API call). |
|
VS Code is all about supporting the inner development loop of edit, compile, debug & release. Features which are not in that inner loop should IMO not be added to VS Code 'main window', even not as an extension. The only feature I currently miss in that inner loop is testing and this would require another kind of view. A database explorer is IMO like a Azure storage explorer and for me doesn't belong into the inner loop. And I believe a good database explorer doesn't stop with a 'Explorer' view. It needs a special editor a REPL, ... So instead of allowing extension to contribute to the 'main window' we should allow them to open a second render window 'on the same workspace' and support some kind of state sharing between them. An example is propagating the active selection so that a database explorer could evaluate a 'Selected' SQL statement. I know that this is a lot more work to do (we need a common widget set to get homogenous UI, we need a communication mechanism, ....) then allow contributing a explorer view but it will allow for better extension UI without opening too many doors in the VS Code main window itself. |
|
I second what @dbaeumer is saying but would like to add that imho such a tool that opens in a new window should just be a standalone application that I can run even when VS Code is not running or not installed. If I decide to have both VS Code and this tool installed at the same time, then I do believe that both should share a set of services for reuse and some kind of UI integration. E.g. it makes sense to have an action in VS Code when editing a SQL script to show a preview of the script in the other tool that was designed for presenting table data. Overall I would like these apps to have a consistent look and feel. If I look at Office applications, they decided to not put everything into a single application but instead create a brand and set of applications that all share a common look and feel. It seems natural to me that such a concept would also work nicely with developer tools. |
|
@dbaeumer that is just one example of something one could do with such an API, Outline view is just one example that is clearly within the edit portion of your inner development loop. This is also about extensions contributions, so any such viewlet would be opt-in by a user who wants it. The main downside I see in this is that it demands we commit to and maintain the API which may slow development and/or our mobility when it comes to changing the UX. |
|
With this feature do you think it possible to extend current explorer? Such as git explorer extend to support SVN. Instead of separate tab |
|
@dbaeumer I think vscode concept of But the point is, the code that we want to grab for For example. I wish I could open vscode and explore my azure functions. Open and edit run.csx, press compile button from vscode to send compile command to azure. Debug in vscode from azure TCP remote debugger. And release my function by right click on azure explorer in vscode Actually there is whole lot of possibility that the code we want to develop maybe need a custom way to explored. Both on the cloud or deep down in the code Actually I have one idea and need to use custom explorer and virtual file editor. I want to make extension to edit javascript in html file (It still not support in vscode) Your limit of freedom block me from |
|
The use case I want to see, which nobody has mentioned yet, is being able to manage the contents of an F# project file. In C#, file order in the .csproj file doesn't matter, but in F#, the .fsproj file needs to specify the source files in dependency order. If you have Model.fs, ViewModel.fs, and View.fs, and View depends on ViewModel which depends on Model, then you must specify Model.fs first in the file, ViewModel.fs second, and View.fs third. Currently when I add a new file to the project, or if I create a new dependency that requires re-ordering the .fsproj file order, I have to edit the .fsproj file myself. This works, but I would far rather be able to just click on the project tree view, right-click on the project icon, and choose "Add new file to project" from a popup menu. Or to reorder a file, I'd like to click on that file in the project tree view and hit Alt+Up or Alt+Down. I don't want to have to edit the .fsproj file, with its ugly XML syntax, by hand -- I'd like the Ionide plugin to be able to provide tools to do it for me. In order to provide those tools, Ionide will need VS Code to support an arbitrary tree view so it can display a tree representation of the .fsproj file. |
|
#14048 has landed on Insider. Doc is coming soon. |
|
@octref how about those docs? Are they somewhere? I'd love to add a new Viewlet on the sidebar(activity bar) but I really don't know how. I tried looking for the code that adds those default 5 items, but could not find it. Could you at least point me to it? |
|
@capaj check out the sample extension here https://github.com/Microsoft/vscode-extension-samples/tree/master/tree-explorer-sample Take note of the |
|
@Tyriar awesome sample. I am a little bit confused as to how can I put any arbitrary content in there-so far it seems to be only made for tree explorers-seems weird that you would not allow any arbitrary DOM there. That would be something I'd like to do. This seems overly limiting.
|
|
@capaj
|
|
@octref thanks for a link. Did not read that before. This is definitely safer approach. Even if it is quite limiting. |
Allowing extensions to contribute a file explorer-like viewlet would enable some interesting features such as:
Related issues:
The text was updated successfully, but these errors were encountered: