Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve UI #1

Open
Zalastax opened this issue Oct 13, 2017 · 4 comments
Open

Improve UI #1

Zalastax opened this issue Oct 13, 2017 · 4 comments
Assignees

Comments

@Zalastax
Copy link
Owner

@chuckdries let's iterate on ideas for the UI. We could do that here or on gitter.
I'd like shortcuts to move in the tree even if the tree window is not focused.
I'd also like the window to be less in the way, possibly by doing a window-split.
Mouse interaction would be nice as well.

@chuckdries
Copy link
Collaborator

Hey sorry I haven't responded, I've been swamped with homework.

I like the idea of doing a window split, I'm not immediately familiar with how VSCode handles creating windows, but I've seen extensions create and open new tabs in a split, I've also seen what appear to be custom windows displayed in the current active tab. I'm thinking like whatever https://marketplace.visualstudio.com/items?itemName=donjayamanne.githistory is doing. It's clear, interactive, easy to read, and allows you (though it takes a few clips) to view older states of the file.

Based on knowing that vscode is javascript and absolutely nothing else, I'm going to assume that we can draw HTML in a panel, which will allow us to enable mouse support and such.

I'm going to sit down and pore over what you have written and vscode's dev documentation this weekend, sorry again for my ignorance!

@Zalastax
Copy link
Owner Author

Zalastax commented Oct 14, 2017

Hey, school is always more important! I'm in the same situation for two more weeks.

This is how gitHistory does their split: https://github.com/DonJayamanne/gitHistoryVSCode/blob/9039041523aa371a55360e316869b6af6a765e9a/src/commands/fileHistory.ts#L162-L172. The VSCode API is not unrestricted so it's possible that splitting the window has limitations.
We can use HTML, but do we want to? Can you draw nice lines in any way? Perhaps SVG gives us both control and free mouse + tabIndex. Implementing interactivity in the canvas should be easy too.

@chuckdries chuckdries self-assigned this Oct 18, 2017
@Zalastax
Copy link
Owner Author

Ah, it's fairly easy to create a custom preview!
Combining a custom URI with a custom content provider lets us render our canvas in a preview pane, replacing the call to addOverlayWidget in historyTree.ts.

BTW how should we handle keeping the fork up to date? I like doing rebase to keep the changes clean, but that won't work well when we both make commits. Or maybe it's fine if I just alert you on gitter?

@Zalastax
Copy link
Owner Author

I looked into it a bit more and it's not as easy as I thought. registerTextDocumentContentProvider comes from the workbench which you're not allowed to access from vs/editor/contrib.
There is also no communication channel into previewHTML so you need to set up your own websocket. The best solution in my opinion is to migrate the rendering into an internal extension using the vscode API.

Then the problem of providing an API that extensions can use. If we don't do this step then we need to have the renderer live in vs/workbench and VSCodeVim won't get an API they can use. Adding to the API is not too difficult, but there's several steps. This is my plan:
First edit vscode.d.ts and modify the interface for TextEditor. I think we should expose at least moveTo, getHistory, and onHistoryChanged. onHistoryChanged might already be covered by the events in onDidChangeTextEditorSelection, but onHistoryChanged is easier for me to think about so I'd rather expose a duplicate for now.
Modifying vscode.d.ts will cause errors, especially for ExtHostTextEditor in extHostTextEditor.ts. Add the missing methods to the class but implement them as dummy functions.
ExtHostTextEditor has a property _proxy that is used to send messages. We need to add properties to the MainThreadEditorsShape to communicate with the backend model,allowing us to implement the functions we added to ExtHostTextEditor.
After adding the properties we can again follow the errors, leading us to MainThreadEditors where we add the functions that communicate. From MainThreadEditors we can get hold of the editor model and reach the history API by following my snippet.

const editor = this._documentsAndEditors.getEditor(id);
		
if (!editor) {
	return TPromise.wrapError<ILineChange[]>(new Error('No such TextEditor'));
}
editor.getModel().getHistory();

@chuckdries do you want to work on the API or on making an internal extension (like extensions/git)?
I started making the extension and then realized getHistory etc are not exposed and wrote this report up. Both tasks should be fairly straight forward and fun. If you want to work on the internal extension I'll send you the code I have so far, and for implementing the API I hope my plan makes the task clear.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants