I also was checking this out from the perspective of session recording and I did used xterm.js instead of term.js for our player, it worked, but there were problems with CSS and view, it was distorted.

On Mon, Jan 8, 2018 at 2:49 PM, Lars Karlitski <lars@karlitski.net> wrote:
Hi Marek,

Thanks for looking into this. Last time we looked into it, xterm.js was in the process of a complete rewrite to use canvas instead of the DOM. Their current branch was on very low-maintenance mode.

This is why we decided to stay with term.js for a while longer and I did a couple of patches to fix the roughest issues back in October.

I agree that xterm.js is the better alternative going forward for the reasons you stated, but I think we should wait for its new branch to stabilize a bit more. Also, it targets quite modern browsers, because its main contributors use it in electron apps.

Cheers
LarsĀ 

On Mon, Jan 8, 2018, at 14:35, Marek Libra wrote:
Hi,
I'm considering exposing the VM consoles we already have in Cockpit for their reuse by other projects, like ManageIQ or oVirt's VM Portal.

One way to do it is moving them under the patternfly-react library [5], partially involving the patternfly community in their later development (and probably even design).

The transition would be implemented step-by-step, starting with the serial console.
The idea is to externalize VM serial console and underlying Terminal component and "reuse" them back in Cockpit.
To do so, it makes sense to move from the term.js-cockpit fork to the maintained xterm.js [1], successor of [2].

Once this is done, other use of the term.js-cockpit will be similarly replaced to depend just on the single [1].

Benefits for Cockpit:
- use of upstream-maintained library
- leverage last (almost) 2 years of the xterm.js development
- be aligned with other related projects on the design level (and drive it!)

Disadvantages:
- quite a lot of work in backporting term.js-cockpit patches to xterm.js
- risks - bugs in already stabilized features might/will appear


I've already implemented POC proving this is feasible and the components can provide reasonable wrapping/API.

There's still a lot of work to be done, starting with porting of [3] to [1].

So, here's the question: is this something what makes sense even for Cockpit-maintainers?

If so, is there already any experience (good/bad) in merging some of the [3] into any successor of [2]? The most important and maybe debatable seems to be [4].

Thanks for opinion,
Marek

_______________________________________________
cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org
To unsubscribe send an email to cockpit-devel-leave@lists.fedorahosted.org


_______________________________________________
cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org
To unsubscribe send an email to cockpit-devel-leave@lists.fedorahosted.org




--
Kyrylo Gliebov
Software Engineer
Red Hat Czech