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 > > [1] https://github.com/xtermjs/xterm.js > [2] https://github.com/chjj/term.js > [3] https://github.com/cockpit-project/term.js/commits/master > [4] > https://github.com/cockpit-project/term.js/commit/2eecc46a9657e0dbcdad5e9b1968c54f04e1f531> > [5] https://github.com/patternfly/patternfly-react > > -- > *Marek Libra* > senior software engineer > Red Hat Czech [1] > > _________________________________________________ > cockpit-devel mailing list -- [email protected] > To unsubscribe send an email to cockpit-devel- > [email protected] Links: 1. https://www.redhat.com
_______________________________________________ cockpit-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
