-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Split terminal widget(browser) logic #4518
Conversation
Signed-off-by: Oleksandr Andriienko <[email protected]>
Signed-off-by: Oleksandr Andriienko <[email protected]>
Signed-off-by: Oleksandr Andriienko <[email protected]>
Signed-off-by: Oleksandr Andriienko <[email protected]>
Signed-off-by: Oleksandr Andriienko <[email protected]>
Signed-off-by: Oleksandr Andriienko <[email protected]>
Signed-off-by: Oleksandr Andriienko <[email protected]>
Signed-off-by: Oleksandr Andriienko <[email protected]>
Signed-off-by: Oleksandr Andriienko <[email protected]>
Signed-off-by: Oleksandr Andriienko <[email protected]>
Signed-off-by: Oleksandr Andriienko <[email protected]>
Signed-off-by: Oleksandr Andriienko <[email protected]>
Signed-off-by: Oleksandr Andriienko <[email protected]>
Signed-off-by: Oleksandr Andriienko <[email protected]>
Signed-off-by: Oleksandr Andriienko <[email protected]>
Signed-off-by: Oleksandr Andriienko <[email protected]>
Signed-off-by: Oleksandr Andriienko <[email protected]>
Signed-off-by: Oleksandr Andriienko <[email protected]>
Signed-off-by: Oleksandr Andriienko <[email protected]>
Signed-off-by: Oleksandr Andriienko <[email protected]>
Signed-off-by: Oleksandr Andriienko <[email protected]>
Signed-off-by: Oleksandr Andriienko <[email protected]>
Signed-off-by: Oleksandr Andriienko <[email protected]>
Signed-off-by: Oleksandr Andriienko <[email protected]>
Signed-off-by: Oleksandr Andriienko <[email protected]>
Signed-off-by: Oleksandr Andriienko <[email protected]>
Signed-off-by: Oleksandr Andriienko <[email protected]>
Signed-off-by: Oleksandr Andriienko <[email protected]>
Don't you use xterm anymore? Why a new extension is created for it? It seems this PR is attempt to abstract away connection logic, not a concrete terminal implementation. I've never liked a separation between |
* @param cols - amount displayed columns in the output frame. | ||
* @param rows - amount displayed rows in the output frame. | ||
*/ | ||
resize(size: TerminalSize): Promise<void>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is never used in TerminalWidget
, why is it exposed?
/** | ||
* Kill backend process. | ||
*/ | ||
kill(): Promise<void>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's never used in TerminalWidget
. Why is it exposed?
} | ||
})); | ||
|
||
this.toDispose.push(this.widget.onTerminalResize(size => this.resize(size))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should not this code always be in TerminalWidget
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could You elaborate more information, please? You against dispose of resize subscription? Or Do you want that terminal widget call TerminalClient#resize?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant that https://github.com/theia-ide/theia/blob/7cea837f5cf9607c86cc2f65a6799e0742f4ba3b/packages/terminal/src/browser/default-terminal-client.ts#L80-L93 could stay in TerminalWidgetImpl
.
Could you elaborate on it? Do you want to connect to an alternative backend in Eclipse Che? |
For now in Eclipse Che there is a fork of the Theia terminal extension. (To have multi remote terminal access). The idea is to move some logic to be re-used so it can work with different endpoints like endpoint = host running theia or a different endpoint (all containers in Eclipse Che). |
If you against this changes, I could revert it. But for me it's not bad if somebody with minimal changes could integrate some another terminal widget #1204 . |
Yes, it's really "attempt" to split connection logic. And I didn't intergrate all wanted changes for better split, because for that I need change terminal restore logic, it's possible, but it could be buggy. So for this step I did minimal changes for split logic + moving xterm.js to the separated extension. |
We still want to use xterm.js. It's nice widget, and it become better and better. |
The point is that it should be done differently.
please make this PR about it and revert all other unnecessary changes |
Signed-off-by: Oleksandr Andriienko <[email protected]>
Signed-off-by: Oleksandr Andriienko <[email protected]>
Reverted xterm.js extension. Should I revert something else? #4518 (comment) sorry, apply more information, please, I didn't understood what did you mean. |
|
||
private terminalClient: TerminalClient; | ||
|
||
protected readonly _onTerminalDidClose = new Emitter<TerminalWidget>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove, renaming protected properties is a breaking change, please keep names there it is possible.
protected init(): void { | ||
this.toDispose.push(this.terminalWatcher.onTerminalError(({ terminalId, error }) => { | ||
if (terminalId === this.terminalId) { | ||
this.dispose(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
before it will always fire close event, the same for onTerminalExit
the change should be minimal as possible with minimal breaking changes. terminal is quite central thing to break it. |
* - resize backend output frame(in case if backend support it); | ||
*/ | ||
export const TerminalClient = Symbol('TerminalClient'); | ||
export interface TerminalClient extends Disposable { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not sure about naming, TerminalClient
is something which provide an access to a terminal, it is TerminalConnection
to me, or TerminalServer
/** | ||
* Terminal widget which is under TerminalClient control. | ||
*/ | ||
readonly widget: TerminalWidget; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that's very weird that there is a cycle dependency between TerminalClient
and TerminalWidget
I would try to see whether one can get rid of a dependency to a terminal widget from the terminal client by changing the interface and moving code from a client to a widget.
/** | ||
* Create new process and attach terminal widget to this process. | ||
*/ | ||
createAndAttach(): Promise<number>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i would call it launch
, similar to debugging
* @param createNewTerminalOnFaill - spawn new process in case if | ||
* target process was not found by terminalId or it's gone. NOTICE: False by default. | ||
*/ | ||
attach(terminalId: number, createNewTerminalOnFail?: boolean): Promise<number>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i would use an object as a second arg to provide extensible options
/* | ||
* Send event on terminal resize. | ||
*/ | ||
abstract onTerminalResize: Event<TerminalSize>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
on[Did/Will]Verb(Noun)?
is how events should be named
private terminalClient: TerminalClient; | ||
|
||
protected readonly _onTerminalDidClose = new Emitter<TerminalWidget>(); | ||
protected readonly _onUserInput = new Emitter<string | undefined>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also please study naming conventions, we use _
only in some cases
Close like to much outdated and some time ago it was canceled due priority. And VSCode already has such thing like we wanted https://github.com/microsoft/vscode/blob/master/src/vs/vscode.d.ts#L7518 |
Referenced issue:
#4523
eclipse-che/che#12609
Split terminal widget(browser) logic
Requested changes:
Split terminal widget logic into two components: TerminalWidget and TerminalClient:
Breaking stuff:
Depracate terminalWidget.start() method. This method has too tricky behavior. I think this methods does too much operations with too much cases. I propose to split this method onto two separated:
Benefits(or why do we need this...)
Notice for future: this pull request it's a first step: split logic. Second step(next pull request): introduce ability to create terminal widget with help plugin api.