Provide Task Runner viewlet

dbaeumer commented 7 years ago

We did a Task 2.0 deep dive today and this issue collects the combined feedback received.

Task Properties

echo should be true by default so that users get a better idea of the task executed
we should support flattening the JSON properties as we do with other settings (e.g "terminal.echo": true instead of "terminal": { "echo": true }
we should better separate task declaration from task customization. Currently both happens in the tasks array property and the differentiating element is the customize property.

Task Picker

The task picker should support a decription / detail message to better explain what the task does. We also discussed whether the task picker should support MRU which would automatically move the most used tasks up to the top without customization. If we provide a task panel (see below) such a MRU list could be useful there as well.

Task Customization

The task customization is currently instance based where the task instance is identified by a task id, which can be quite 'cryptic'. An alternative way would be to identify a task based on a type and a key that is defined by the type and therefore can vary from task runner to task runner. So instead of having something like:

    {
        "customize": "vscode.npm.run build",    
        "taskName": "npm: run build"
    }

a customization would look like this

    {
        "customize": {
            "type": "npm",
            "file": "${workspaceRoot}/package.json",
            "script": "build"
        },
        "problemMatcher": ["$tsc"]
    }

where the structure of the identifying attribute is defined by the extension providing the runner support. In the example above the fact that a npm script is identified by the location of the package.json file and the script name comes from the npm extension. This might look different for task contributed by gulp of TypeScript

Problem Matchers

For task that execute a target of a task runner (e.g. gulp, npm, grunt) VS Code can't decide which problem matchers to attach. Since picking the right problem matcher currently requires editing the tasks.json file we should better support the user with this. We discussed the following ideas:

always attach all known problem matchers if a task has no problem matchers. This might result in false positives and might require us to support removing problem matchers via a configuration mechanism.
we could help the user attaching a problem matcher by generically scanning the output for problems and suggest problem matchers that exactly match these. If selected we update the tasks.json file for the user.

Task panel

It was suggested to run tasks in its own panel instead of reusing the terminal panel. They should still be executed using the terminal to get ANSI control character support and other nice terminal features (e.g. Ctrl+C). The panel could offer additional features like:

a task summary (execution time, exit code, ...)
the output of a task could be folded (like travis does for example)
allow for in place customization of a task (for example attach a problem matcher) without the user being forced to edit a tasks.json file.

We also discussed the need of a task viewlet but decided that this will not add any big additional value over the task picker and a separate panel.

Top Level Menu

We were also discussing whether the tasks deserve a top level menu. In general this was consider a good idea. However such a menu should be semantically not technical. So instead of naming it Tools or Tasks it would be better to offer top level menus like Build, Rebuild All, Clean, Run Tests. The downside of such an approach is that such a menu looks out of place if none of these entries trigger any meaningful action in the workspace (e.g. if a simple JS project is open at lease Build, Rebuild All and Clean don't make any sense)

Better Selfhosting

Would be great if we can improve the self hosting coverage of tasks. This is currently hard to do due to the fact how we build. But @dbaeumer will tweak our tasks.json to support more tasks currently run in the terminal (e.g run tests, linting, ...)

dbaeumer commented 7 years ago

@Microsoft/vscode please read. Feedback and corrections welcome.

Tyriar commented 7 years ago

We also discussed the need of a task viewlet but decided that this will not add any big additional value over the task picker and a separate panel.

@Lixire and @aefernandes are currently looking into this I believe.

Tyriar commented 7 years ago

Most of this is In response to:

It was suggested to run tasks in its own panel instead of reusing the terminal panel.

First off, it definitely looks like these sorts of improvements will make tasks more useful and usable. I just wonder if this is the right direction we should be taking:

We already have output, debug console and terminal which are all very similar.
We don't deal with overflowed panel actions too well right now, this will make the panel less usable on small monitors and/or high scale/zoom settings. This is what the panel looks like right now on my 13" laptop screen. A new panel may start to squash the panel actions off screen with this window position:
Are tasks generally useful enough to warrant their own panel? Personally I've found little benefit over shell scripts, particularly if you want the project to be portable as tasks are only usable in VS Code.
Perhaps time invested in tasks would be better spent bringing some of these sorts of features to the terminal, namely https://github.com/Microsoft/vscode/issues/20676 + https://github.com/sourcelair/xterm.js/issues/576 which could lead to exit code marking, folding of terminal commands and clever problem matching (leveraging settings system for definitions).

Technical details

On the implementation side, this is definitely technically possible. It will put a permanent halt on moving tasks to an extension, I think that effort has fizzled out anyway though.

TerminalInstance is fairly generic right now and it wouldn't require that much tweaking to get working inside another panel. It doesn't have a dependency on TerminalService and communicates with it via events. The main problems you will run into are how terminal keybindings and the terminal context keys interact with the new tasks system:

terminalTextSelected is fairly easy, this could be changed to be if text is selected in tasks/terminal and that panel is active.
terminalFocus is a little trickier as making this apply to both task panel focus and terminal panel focus would cause issues with my keybindings, for example:
```
{ "key": "ctrl+`", "command": "workbench.action.terminal.focus",
                 "when": "!terminalFocus" }
```

I don't think too much of TerminalService can be reused if we make a tasks panel.

Some alternative ideas:

We implement terminal tabs and each task gets its own tab https://github.com/Microsoft/vscode/issues/10546
We embed TerminalInstances (ie. xterm.js) within the output panel, disabling stdin by default, then move tasks back to output?
Refocus effort on tasks on improving the terminal

dbaeumer commented 7 years ago

See #28351 for the echo feedback.

capture

dbaeumer commented 7 years ago

Added support for MRU list:

capture

alexdima commented 7 years ago

@Tyriar I don't think the idea of having a Task panel competes with your mentioned improvements for Terminal. If there is a UX path where Tasks and Terminal can fit in the same panel, that would also be great.

Some reasons why IMHO a Task panel would help:

It would be nice to see somewhere, in the form of a list, the current running tasks and some sort of history with past ran tasks. From the list, it would be nice to be able to expand output for a task in case there is a problem (sort of like travis).
Such a list would be especially helpful for managing background tasks
A panel might help with task discoverability. At this time, there is no obvious UI path to go launch a task or configure a task from a terminal. There is no mention of tasks or the possibility of gathering errors from a task in the UI.

And what would also be very nice:

It would be nice that typing in the terminal auto-completes with information from the task providers. e.g. typing "gulp c" should complete with the gulp tasks that start with letter c.
It would be nice that running a command in a terminal can be configured into a task via a one-click. e.g. it would be nice if, when someone runs gcc in the terminal (without a task configured) that we can detect that this would be a prime candidate for a task and we would guide the user into creating a task. I think many folks don't know that a command they run in the terminal can be "lifted" to be even more integrated into VS Code.

bpasero commented 7 years ago

I would still want us to explore the possibility of a panel for tasks, I think UX scalability as reason to not do it is not very fair, we need to solve the panel overflow no matter what in the same way we solved it for the activity bar (being able to show/hide panels, reorder them, see a "..." overflow menu when space is too little).

I do agree though there is some overlap in Debug Console, Integrated Terminal, Output and Tasks, however I am not sure if it would make sense to put them all into one. There is very specific scenarios for each of the panels:

output: after tasks moved to terminal I would argue output is only ever being used as a way to see diagnostics (I wonder if we should make output less prominent)
debug console: has rich functionality when debugging, but otherwise is quite useless (maybe we should only show it when you are in a debug session?)
terminal: this is where I execute shell commands. nothing in here is related to VS Code, it is just convenient to not have to leave VS Code to use it
tasks: this is VS Code specific: I execute potentially multiple long running tasks, each with output and progress and possible error conditions (markers)

Here is a mockup for the Tasks panel:

We can provide an explicit configure action per task which would guide users to configure problem matchers. We can make all tasks discoverable from here by having a dropdown to show all tasks that can be executed.

/cc @stevencl

dbaeumer commented 7 years ago

@bpasero thanks for the nice mockup.

jrieken commented 7 years ago

Any new ideas wrt task customisation and referencing (contributed) tasks by an id or something else? I think from the API POV that is a thing to tackle.

chrmarti commented 7 years ago

Not being an active task user myself, I wonder if the suggested Tasks panel could also show processes run from the Terminal. That could then open a path to offer problem matchers for tools run in the Terminal.

roblourens commented 7 years ago

The mockup omits the problems panel. I wonder whether that could be rolled into the tasks panel to save space?

debug console: has rich functionality when debugging, but otherwise is quite useless (maybe we should only show it when you are in a debug session?)

Hiding it when a debug session hasn't been run would be useful. After a debug session completes, I still want to examine the contents of the console though.

rebornix commented 7 years ago

As I'm not an active task user but I'm also thinking about why I don't use Task too often

If no one sets up all the tasks in a project, I don't think I'll ever know this feature from daily use. To new users, you don't have an idea when the Task will get in the way. A task viewlet or panel can help with discoverability in this case.
I didn't know where to launch/kill the task until one day I happen to type task in the command palette. Task 2.0 uses Terminal which helps with the problem a little as I can kill the task the same way as a shell cmd.
Task 2 now uses Terminal for emitting output, the first time experience was not intuitive as it took over the Terminal even though I was using it. Besides it shares the same persistence problem as Terminal, after reloading the window I no longer have access to background tasks.

Speaking of debug and output panel

I'm not a fan of auto show/hide unless we make it correct. a. If we have a clean state of the workspace, launch debugger, the debug panel would show if there is no prelaunch task and no output. b. If we have a prelaunch task, the terminal shows up first as it provides the task info the users but after the task is executed successfully, the debug panel doesn't show up. c. I don't have a good reproduce of step a and b. I don't have a good expectation which will show up last. d. Last time I get the same confusion is the competence of Output panel and Debug panel

Lastly, do you think it make sense to emit output directly terminal instance the same way as Task 2? The only thing you can do in the output panel is view/copypaste/search and all of them are doable in Terminal, the discoverability won't be worse than current Task 2.

dbaeumer commented 7 years ago

@jrieken the initial description contains what we discussed in terms of how to reference a task (see Task Customization). I haven't started implementing anything. First need to see how feasible that is. Any comments to the proposal in terms of API feedback.

irekeri commented 7 years ago

As a heavy user of the task/debug infrastructure within Visual Studio Code, I felt that it might be worth it to document my observations with the existing system.

My development environment is heavily focused on testing which has caused a large number of test executables to be created along side the actual application being developed. Additionally, all code compilation as well as test executable execution happens remotely (Virtual Studio Code running on OS X, where as compilation / test executable happen on a Linux machine).

I have found tasks to be very flexible and with the most recent additions to the Insiders Build, building and executing tests with a few keystrokes has really streamlined my development environment. I have been able to augment the tasks I execute today with a simple SSH script used to bridge the gap between Virtual Studio Code and the remote machine where all of the compilation happens.

That being said, one thing I have noticed is that I find myself duplicating task and launch configurations to handle the number of executables I deal with on a day-to-day basis. Having both my tasks.json and launch.json filled with upwards of 30+ configurations only differing by the executable is a little cumbersome. Additionally, the test executables themselves take arguments relating to specific filters of which subtests to actually execute (which is very helpful in executables which contain hundreds of tests). This means having to open up and edit my tasks.json any time I want to execute a smaller subset of a test executable.

While it is not clear to me what belongs in an extension versus what belongs in the core functionality of the editor, some things I would like to see are:

The ability to use 1 task configuration as a template, and feed in an array variations on that same template to help curb the duplication of task configurations.
The ability to specify a command (i.e. ${command:getDynamicArgument}) to be used to prompt a user for additional arguments on a task (which would help make it more fluid in scenarios where the arguments to an executable are constantly changing). Additionally a history of recent inputs would really improve the user experience of it.
Something similar to pipeTransport within the cpptools C++ extension which would allow the remote execution of a task.

I understand that some of these items are (and I have solved them via script development) achievable via external scripts, but I see these as problems that numerous developers across all walks of life would run in to and most likely solve in very similar ways.

dbaeumer commented 7 years ago

We again discussed the tasks.json schema today and came to the following conclusion.

there shouldn't be a separate customization section. So everything goes below the tasks section
there should be a clear visual distinction between defined tasks and task customizations.

Below is a proposal how this will look in tasks.json

{
    "version": "2.0.0",
    "tasks": [
        // This is a custom task not contributed by an extension
        {
            "type": "custom",
            "name": "yeoman",
            "command": "yo",
            "runtime": "shell",
            "group": "build",
            "presentation": {
                "reveal": "always",
                "focus": false,
                "panel": "dedicated"
            }
        },
        // This is a configuration of the npm build script task. 
        {
            "type": "npm",
            "script": "build",
            "configure": {
                "problemMatcher": ["$tsc"]
            }
        },
        // P2: This is a npm script task which the extension needs to
        // resolve. It will execute the osx and the osx-min
        // script
        {
            "type": "gulp",
            "tasks": ["osx", "osx-min"]
        }
    ]
}

Ciantic commented 7 years ago

This has a weird title. But here is my Issue with v.2.0.0:

If you run a background task, and close the VSCode, the background task is left running. This is quiet annoying.

Using VSCode 1.13.1, in Windows 10.

Is this feedback issue meant for this kind of feedback? Thanks.

Ciantic commented 7 years ago

This is unrelated to my bug above, but I would like to see tasks having own tabs here:

tasks-as-tabs

If I could see e.g. "build" or "testwatch" as a tab there, it would be more accessible and easier to notice it's running those tasks. The dropdown is too subtle for me, but this is matter of taste.

How many tasks people have? I usually have 1 to 5, with this few tasks it would be easier to see them as tabs, than buried in dropdown.

P.S. updated the image. Maybe even Output tab can be removed since all output is from some task I gather.

Tyriar commented 7 years ago

@Ciantic terminal processes leaking tracked in https://github.com/Microsoft/vscode/issues/26807. See https://github.com/Microsoft/vscode/issues/28235#issuecomment-308374308 for proposal on a tasks tab.

aefernandes commented 7 years ago

Thoughts on what we (+ @Lixire) seem to expect from a task panel and current mockups. Feedback on brain dump and mockups welcome.

The panel should show a summary of each completed task, including execution time, exit code, and the foldable output if applicable. By default, we would show tasks in MRU order and prioritize tasks that are currently running. This would also include available/auto-detected tasks.
Allow user to start, stop, or (if already run) restart a task with one click.
I would expect the tasks panel to open from the newly-added Tasks menu and from the command palette. However, other panel items open from the View menu - we could include a Tasks option there as well.
We should provide guidance if tasks have not been configured and panel is open. Perhaps a link to the documentation, or a single button that configures a task.json.
Provide an explicit configure action for each task, and an action to configure problem matchers when viewing output.
A stretch goal could be to allow users to configure or make quick edits without ever touching JSON (about 40% of users interviewed indicated JSON configuration was a barrier to usage).
To support multi root workspaces, an option is to show a filepath next to each task name similar to the way debug works.

Example UI options:

A) Task list with output opening in sidebar task panel a

B) Task list in MRU order task panel c

C) Task list with groupings task panel b

Ciantic commented 7 years ago

I'd like to point out that in my opinion it's a mistake to advertise this as default option for VSCode stable (1.14.0), if even the termination of the tasks does not work. https://github.com/Microsoft/vscode/issues/26807

dbaeumer commented 7 years ago

Just to clarify things: the termination without leakage doesn't work for npm tasks. It does work for all others kind of tasks.

gep13 commented 7 years ago

@dbaeumer I have a question/suggestion about this new Task Window...

When in Visual Studio, using the Task Runner Explorer, it is possible to click on one or more of these configurable buttons:

These then append additional arguments onto the task that is being executed. Is it possible to do something similar here? In the screenshot above, I am selecting to add the Verbose flag onto the task so that additional information is added to the output log.

Jeyanthinath commented 7 years ago

It would be great if vscode would support pycharm style , task configure and task runner on the top right with run button,

Suppose user need to run multiple configuration file for same file , he can very well setup and need to go to command pannel for task running ,ther is no one click solution****

nonameolsson commented 7 years ago

Love this idea! I also like the screenshot https://github.com/Microsoft/vscode/issues/28235#issuecomment-316376605. This reminds me also how JetBrains manage their panels, with clickable buttons etc. You can see an idea of what I refer to here https://github.com/Microsoft/vscode-react-native/issues/481

So far VS Code shows text in the panels. Would it be possible to extend it with buttons, lists etc? That would make the panels more interactive.

rkeithhill commented 7 years ago

@gep13 - that's more or less what I'd like to see. Having Tasks show up in the Side Bar is where they belong in my opinion. It elevates the Tasks concept to the proper level. What should be displayed in the Output/Debug/Terminal area is task output from various task executions.

nonameolsson commented 7 years ago

So I have been thinking about how I would like it to be. As I already mentioned I like the solution from JetBrains and from Visual Studio.

Here is a suggestion. What do you think? Of course there are things I haven't figured out yet, but it's a first draft suggestion at least.

vscode tasks 2 0

rkeithhill commented 7 years ago

@nonameolsson I very much like the Tasks panel in the Side Bar. I'm not sure you really need the "RUNNING TASKS" view given that the Tasks panel in the Side Bar can indicate (via icon or text) which tasks are currently running. And selecting a task from there could switch the tasks output view to the output of the selected task. Everything else looks really good to me!

nonameolsson commented 7 years ago

@rkeithhill That is a good suggestion! I like it, that way the UI will be a lot cleaner. Maybe a checkbox in the task panel to filter only running tasks?

EDIT: Maybe not group the tasks by type, but instead group them by running, finished and available tasks, like in https://github.com/Microsoft/vscode/issues/28235#issuecomment-314216442

nonameolsson commented 7 years ago

Update based on suggestion by @rkeithhill in https://github.com/Microsoft/vscode/issues/28235#issuecomment-319429369

vscode tasks 2 0 version 2

dragonwolf83 commented 7 years ago

I agree, moving Tasks to Activity Bar is the perfect place for it to be.

With that change, I don't think you need a separate Task Panel. The Tasks can remain in Terminal Panel and work on Tabs for Terminal #10546 and Split Terminal #7504 to gain the same benefits while extending it to popular use cases.

gep13 commented 7 years ago

In the screenshot that I showed (https://github.com/Microsoft/vscode/issues/28235#issuecomment-316376605), the icons down the left hand side are not tasks, they are additional, optional, parameters that can be passed to the selected task. I would still like to see this ability included as well.

Jeyanthinath commented 7 years ago

Love @nonameolsson suggested UX

non ux suggession:

Adding peak memory usage for each task can be also added gives much controll over each task making the vscode to run smooth

nonameolsson commented 7 years ago

@Jeyanthinath Thanks!

@dragonwolf83 Great suggestions regarding tabs for terminal and split terminal also! That would be awesome! I would love to be able to see multiple running tasks at the same time in a split terminal.

@gep13 Are those icons general, or for each task? In other words: do you choose verbose for a task before starting it, or does it affect all tasks?

gep13 commented 7 years ago

@nonameolsson said... Are those icons general, or for each task? In other words: do you choose verbose for a task before starting it, or does it affect all tasks?

Not in a position to test just now, but I believe that once selected those buttons affect each task that is ran. i.e. you enable/disable them as required as you are executing tasks.

nonameolsson commented 7 years ago

Any update on this? I really think that improvements to the Task section could make VS Code better.

dbaeumer commented 7 years ago

No, our current focus it to support multi root for Tasks.

jeyanthimuthuram commented 6 years ago

Any Updates on this ? I hope now multi-roots are into stable build .

nonameolsson commented 6 years ago

What is the status of this?

dbaeumer commented 6 years ago

@nonameolsson the technical features for task 2.0.0 got implemented. However no work has started yet to build a special task UI. However we added proposed API for extensions to query and execute tasks, so that task providers can add special UI (for example npm can contribute actions to the package.json file to directly execute scripts from the explorer).

Guema commented 6 years ago

@bpasero @nonameolsson both your ideas seems really cool & mandatory to me.

I personnally need this feature, and Imo this is critical. What i lack is mostly an overview panel of running / available tasks. This list ui should stay visible when looking at a particular task log. It should be like tabs/folds you can click to see each one details. Terminal dropdown is not so good at it.

Ciantic commented 6 years ago

I like the @nonameolsson GUI, however I would add it that running tasks should be shown as tabs in the panel so that toggling between the outputs is faster.

tasks-with-tabs

My assumption is that there is very few running tasks and tabs are easy way to distinguish between the running task outputs.

Also, I don't like keeping a sidebar open at all times, seeing what the output is about is easy from the tabs alone.

gulshan commented 6 years ago

I had a simple proposal for task discovery- show configured tasks under "Task" menu. #47172

nonameolsson commented 6 years ago

I really would like to see some improvements to the task session. However, I'm really used to use the terminal for all that now. And being able to split into two terminals at the same time in VS Code has been a big help for me.

With the latest update there is now a NPM explorer, https://code.visualstudio.com/updates/v1_23#_npm-script-running.

I think it could be improved, but it is a really good start!

dbaeumer commented 6 years ago

I will rename the issue since the major item left in the issue discussed is the task runner viewlet / UI.

Note that with the new API this might be implementable by an extension (see the npm script runner viewlet)

connorshea commented 5 years ago

🙏 I'd love to see a sidebar like this in VS Code. Currently I forget about Tasks a lot of the time and just end up running them in a separate terminal.

It'd be possible to implement as an extension if we had #32352, maybe there are other alternatives as well? (You could probably make your own tasks.json parser but that would only get local tasks, and also that'd be a pretty annoying thing to maintain).

heartacker commented 3 years ago

please give us viewlet

microsoft / vscode