eclipse-theia / theia Goto Github PK

We should go with json-schema based user preferences.

A plugin should be able to contribute a schema and read the actual preferences.
Different scopes would be good, too.

In addition to good textual support like in vscode, we could provide a graphical editor (similar to atom) as well. For that we could use http://jeremydorn.com/json-editor/

For our popup dialog service we need to solve the following issues

• the dialog should be modal, i.e. not allowing other interaction.
• the dialog should be always on top
• we don't want to have a visible, empty container widget added to the main area

A common service to access the clipboard.
Related : https://github.com/electron/electron/blob/master/docs/api/clipboard.md

Because npm link only creates a symlink instead of prepublishing and copying content, as npm install does, it is recommended to use file dependencies for local development: http://stackoverflow.com/questions/14381898/local-dependency-in-package-json

In addition we should make sure that theia prepublish script includes other resources as styles and example consumes them from lib folder not from src as now.

A quick access to available commands and other things should be provided.
I like how it can do more then just executing commands in VSCode.

In Electron we want to use native menus, while in browser we want to use the Phosphor ones.
We need to figure out how we can change the context menu in monaco (either disable or hook in through IEditorOverrideServices / IContextMenuService).
Also there needs to be a service that shows the menu according to a mennu-id, it should be used e.g. by the navigator, as well as on the tabs of editors/widgets.

We should try to enforce as less as possible runtime dependencies:

• to keep installation process easy
• to allow extension developers a choice

Happens when closing the active editor from code:

const editor = this.editorService.activeEditor;
if (editor) {
  editor.close();
}

Although the editor closes I can see this error in the console:

textModel.ts:70 Uncaught Error: Model is disposed!
    at Model.TextModel._assertNotDisposed (textModel.ts:70)
    at Model.TextModel.getValue (textModel.ts:361)
    at model-resolver-service.ts:52
TextModel._assertNotDisposed	@	textModel.ts:70
TextModel.getValue	@	textModel.ts:361
(anonymous)	@	model-resolver-service.ts:52

It can be used to display status and open some widgets as terminals and the debug consoles.

In editor try pressing 'SHIFT+F12' for find referenced or 'ALT+F12' for peek definition.
It doesn't work. The latter seems to open the widget for a short moment, but it gets closed again immediately.

We should have an example application for the Node/Browser architecture.
It will be a node process serving the browser application through http.

• The actions provided by monaco should be registered with our CommandRegistry.
• A context menu for monaco editors should be registered with MenuModelRegistry.
• monaco context menu should be deactivated and replaced with ours

A file system service should allow to navigate and operate on a served file system.

• For electron it needs to use electron's IPC communication to connect to the main process
• For node/electron it needs to use a websocket.

Let's look at BrowserFS (https://github.com/jvilk/BrowserFS)

We need a plugin that allows users to access the backend system through a terminal.
Xterm looks good for this https://github.com/sourcelair/xterm.js

For writing unit tests we should decide for a testing framework to use.
My requirements would be:

• short turnarounds / incremental test runs
• readability / little boiler-plate
• nice: native support in webstorm for debugging

• feature complete Workspace, first https://github.com/TypeFox/Theia/issues/39 should be done
• @svenefftinge's comments on https://github.com/TypeFox/Theia/pull/33

• don't use workspace root relative paths
• use file stats where it is possible instead of paths
• keep API minimal, functions which can be programmed by usage of the fs API should not belong to fs API but another service on the top of the fs API, like createName
• instead of just paths, we should return more metadata about file items, so we ca reduce the number of requests.

We want to be able to write UI integration tests using Selenium.

In a shell-dompackage we create and expose the shell, which is the root element for the UI.

Users need to search the workspace. A "Find In Path" Action should open a search widget in which I can type in text and hit search. The list of matches should be shown below in a tree like fashion.

• Top level - files
• Second level - matches within files
  Double click on an item should open and reveal the match.

The view should later allow to do replace as well and should offer some common options like regex, case-insensitivity, whole-word-match. But these additional things should be covered in extra tickets.

The feature will require a specific extension to the FileSystem API, as we obviously don't want to load the contents of the whole workspace into the frontend.

Anything not provided by language servers, like lexical syntax coloring, folding, snippets, etc.

open an editor verify that hover messages work.
Right-click to open the context menu.
Afterwards no hovers are shown anymore

A view that can display issues in a list, allowing to double click an item in order to open and reveal the element.

When renaming a file, the existing name should be set in the pop up dialog and be selected and focussed.

It should be possible to register keybindings to trigger command handlers, similarly to how the menu service does it.

Since TypeFox@467d3dd the tabs height is not computed correctly anymore.

Theia should be extendable in the following ways.

• Both the frontend and the backend should be extendable
• To allow maximum flexibility we will allow extensions to run in the main processes and access everything. Defining APIs and their lifecycle is a separate topic.
• a user should be able to install and uninstall an extension at runtime

At the core of Theia we use dependency injection (inversify) to contribute functionality to existing hooks and also to provide new hooks. A plugin should contribute an inversify module, that is then just added on start up.

Instead of just pathes, we should return more meta data about file items, so we ca reduce the amount of requests.

For long running processes as language servers, it would be nice to have a separate output window, similar to VS Code.

I depends on https://github.com/TypeFox/Theia/pull/53 and https://github.com/TypeFox/Theia/issues/54. See for impl details: https://github.com/redhat-developer/vscode-java/blob/master/src/extension.ts#L243.

An initial project setup should support the following parts:

• a node module for the ui (dom).
• a node module for the backend (node).

Development should allow for short turnarounds for both running tests and running the application.
Things like

• webpack
• typescript compilation (incl. sourcemaps)
• karma

should be configured.

We should setup travis ci to automatically build and test

We should provide a storage mechanism that allows any components to load and save their state UI.
HTML5 Local Storage seems appropriate.

Monaco comes with its own scrollbar. Native scrollbars should be styled similarily.

I would like to start thinking about how documentation will look like. The communication between the frontend and the backend will need to be documented, as well as (at the very least) the APIs that extensions will use.

To reduce overhead, at least in the beginning, I think that this doc should be embedded in the code. It should be possible to generate an HTML version of it for easier browsing.

I'll make some research about the existing and popular documentation systems for Typescript. If you already have some knowledge about that, please share!

A global selection service, should allow providers to emit selection events, listeners to register for such events and clients in general to ask for the current selection.

The form of a selection can vary so the type would be any.

The OpenerHandler should be enhanced in the following ways:

• OpenerOptions should provide information about where to open in the shell (main area, left, right, bottom dock)
• should provide and ID and a label, for 'open with'
• should have a canHandlemethod

VSCode runs 3rd party extensions in a separate node process. The provided extension API communicates with the main process through an IPC-based protocol.

We should look into supporting the protocol directly, so Theia users could install and run all extensions listed here:
https://marketplace.visualstudio.com/VSCode

Some references:

• https://github.com/Microsoft/vscode/tree/master/src/vs/workbench/node
• https://github.com/Microsoft/vscode/tree/master/src/vs/workbench/api/node

This task is a follow-up of #39.

We need to pass a FileStat instance instead of the resource URI (string) to be able to verify that the resource is in sync with the server state. Just like we do for setContent.

A widget that adds itself to the left area of a shell and connects to the file system.
It should allow browsing the served file system and opening an editor on double-click.

A general file open service should be exposed and internally open the given text file in a new widget using monaco.

add support to update navigator with changes in file system

To support commands that can deal with multiple files

Both the frontend and the backend need to have access to a communication endpoint to send and receive JSON RPC messages and notifications
For now we could go through a websocket connection on both electron and web/node.

The navigator should have a context menu, on which the following actions should be implemented.

• Delete
• Cut, Copy, Paste
• New File
• New Folder
• Rename

For rename, new file and new folder the label of an item should turn into an editable text field. The name should be applied on enter. On ESC the initial name should be used.