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 <[email protected]> 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 > > [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 > <https://www.redhat.com> > > *_______________________________________________* > cockpit-devel mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > > > _______________________________________________ > cockpit-devel mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > -- Kyrylo Gliebov Software Engineer Red Hat Czech
_______________________________________________ cockpit-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
