eclipse-theia / theia

Eclipse Theia is a cloud & desktop IDE framework implemented in TypeScript.

Cloud & Desktop IDE Framework

Eclipse Theia is an extensible framework to develop full-fledged multi-language Cloud & Desktop IDEs and tools with state-of-the-art web technologies.

• Website
• Repositories
• Releases
• Scope
• Roadmap
• Getting Started
• Contributing
• Feedback
• Documentation
• License
• Trademark

Website

Visit the Eclipse Theia website for more information and the Theia documentation.

Repositories

This is the main repository for the Eclipse Theia project, containing the sources of the Theia Platform. Please open generic discussions, bug reports and feature requests about Theia on this repository. The Theia project also includes additional repositories, e.g. for the artifacts building the Theia IDE and the Theia website. Please also see the overview of all Theia project repositories.

Releases

• All available releases are available on GitHub including changelogs.
• Detailed release announcements are linked on the Theia website.
• Community Releases are listed on the Theia website.
• Visit the release website for more information.

Scope

• Support building browser-based and desktop IDEs and tools
• Provide a highly flexible architecture for adopters
• Support VS Code Extension protocol
• Develop under vendor-neutral open-source governance

More details on the project goals are available on the Theia website.

Roadmap

See our roadmap for an overview about the current project goals and the upcoming releases.

Getting Started

Here you can find guides and examples for common scenarios to adopt Theia:

• Get an overview of how to get started on the Theia website
• Develop a Theia application - your own IDE/Tool
• Learn about Theia's extension mechanisms
• Develop a VS Code like extension
• Develop a Theia extension
• Test a VS Code extension in Theia
• Package a desktop Theia application with Electron

Contributing

Read below to learn how to take part in improving Theia:

• Fork the repository and run the examples from source
• Get familiar with the development workflow, Coding Guidelines, Code of Conduct and sign the Eclipse contributor agreement
• Find an issue to work on and submit a pull request
  • First time contributing to open source? Pick a good first issue to get you familiar with GitHub contributing process.
  • First time contributing to Theia? Pick a beginner friendly issue to get you familiar with codebase and our contributing process.
  • Want to become a Committer? Solve an issue showing that you understand Theia objectives and architecture. Here is a good list to start. Further, have a look at our roadmap to align your contributions with the current project goals.
• Could not find an issue? Look for bugs, typos, and missing features.

Feedback

Read below how to engage with Theia community:

• Join the discussion on GitHub.
• Ask a question, request a new feature and file a bug with GitHub issues.
• Vote on existing GitHub issues by reacting with a 👍. We regularly check issues with votes!
• Star the repository to show your support.
• Follow Theia on Twitter.
• Join the weekly developer call

Documentation

• API Documentation
• General Documentation
• VS Code API Compatibility Report
• Useful Links:
  • Developing
  • Testing
  • Migration Guide
  • API Integration Testing
  • Coding Guidelines
  • Code Organization
  • Plugin and VSCode API

License

• Eclipse Public License 2.0
• 一 (Secondary) GNU General Public License, version 2 with the GNU Classpath Exception

Trademark

"Theia" is a trademark of the Eclipse Foundation https://www.eclipse.org/theia

theia's Issues

Restructure the repository to use separate extensions

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.

Renaming file should focus

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

[navigator] Support multi-selections

To support commands that can deal with multiple files

Status Bar

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

New file action creates files without confirmation

[navigator] hook up context menu

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.

[messaging] Support connection to different servers

File System Service

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)

Streamline scrollbars

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

[Example] Node/Browser Example

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

Editor Services

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

Abstract Editor API

Support storing frontend state

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

Opener Handler improvements

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

Dialog Issues

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

DockLayout broken after phosphor upgrade

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

[java] Provide JavaResource to handle jdt schema

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.

[releng] Add Travis CI

We should setup travis ci to automatically build and test

API Documentation

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!

[filesystem] Enhance the protocol to use stats

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

Clean up LS integration

• 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

Editor model is disposed error when programmatically closing the active editor

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

Make command handler contributions lazy

Shell

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

Command Palette

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.

[Example] Electron Example

Extension Mechanism

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.

[preferences] Preferences

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/

Allow client side language contributions

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

Review runtime dependencies

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

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

[filesystem] FS protocol

• 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.

UI Test Infrastructure

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

[communication] Json RPC connection

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.

Terminal Plugin

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

Selection Service

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.

[editor] peek definition / find references don't work through keybinding

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.

[testing] Research test framework

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

Clipboard Service

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

[monaco] Integrate with menus / commands

• 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

[editor] hovers stop working after context menu was shown first time

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

File Navigator

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.

Problems View

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

[extensions] Leverage VsCode's extension mechanism

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

Initial Project Setup

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.

Search within workspace files: Action / widget

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.

Change copy/delete/move on the FS API to accept `FileStat` instead of a resource URI

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.

Process Output Window / Console View

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

Keybinding Service

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

[file system] notify client about changes

add support to update navigator with changes in file system

Context Menus

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.