Compiling error: ‘class ads::CDockManager’ has no member named ‘addContainer’;
jingyuewang opened this issue · comments
I was trying to compile DomTerm 2.9 with Qt-Advanced-Docking-System. I have built the QT_ADS library and set the lib path to ./configure. However g++ can not compile browsermainwindow.cpp. The error message is shown below:
browsermainwindow.cpp: In constructor ‘BrowserMainWindow::BrowserMainWindow(BrowserApplication*, const QString&,
QSharedDataPointer<ProcessOptions>, QWidget*, Qt::WindowFlags)’:
browsermainwindow.cpp:124:91: error: ‘class ads::CDockManager’ has no member named ‘addContainer’; did you mean ‘
dockContainers’?
124 | ads::CDockContainerWidget* container = BrowserApplication::instance()->dockManager()->addContainer(this);
| ^~~~~~~~~~~~
| dockContainers
I went back to check the the code of Qt-Advanced-Docking-System and didn't find the addContainer member function in the definition of the CDockManager class. Is it because I'm using a newer version of Qt-Advanced-Docking-System that has changed its interface?
Jingyue
Did you use my fork as in the instructions? The Qt_ADS support will probably stay in its current experimental state unless my pull request is merged.
I expect I will stick with GoldenLayout as the preferred windowing system, especially now it is being actively developed again. (Though I do want to take another look at Theia at some point.) I have not yet ported DomTerm to GoldenLayout version 2, but hopefully soon.
Indeed, I used the donwloaded zip file from the original repository. I'll try to use your fork and report the result. Thank you for your prompt answer! I also tried the electron.js version with GoldenLayout and it runs smoothly. But as you have pointed out, the QT version has its own advantages.
The new GoldenLayout maintainers have expressed interest in supporting dragging betwen top-level windows.Since I haven't yet tied out GL 2.x I don't know how close they are - but that would remove the main benefit of Qt-ADS or kddockwidgets. Warning: The DomTerm support for either of the latter is more proof-of-concept than something you'd want to use (quite a bit of polish needed) - but as always, patches welcome.
Yes, if GoldenLayout could provide similar features in the future, there is no need to use the Qt front ends for me. I cloned your fork this morning and compiled the two Qt front ends, just for the sake of completeness :) It appears to me the electron front end is more stable than the two Qt front ends. The ADS front end crashed when I clicked the "Detach Group" button to "undock" a window (This problem also occurs in their own demo programs compiled from their own repository, so it is not a DomTerm problem). The KDDockWidget front end did not have this issue but when I tried to show an image in a Julia REPL, the terminal window hung. The electron front end is stable enough to survive both tests. DomTerm is truely amazing. Is there any plan to support displaying LaTeX equations? I'm excited about the potential of using DomTerm as my Julia REPL console. It can be much easier to use than the current Jupyter+IJulia approach (and feels better too). I guess I need to load the MathJax library somewhere to be able to show rendered LaTex equations, but can't figure out how to do it...
"It appears to me the electron front end is more stable than the two Qt front ends."
In case you don't realize it, the GoldenLayout functionality does not depend on Electron. GoldenLayout is used for the "normal" Qt front-end, browser front-ends, and webview front-ends.
"Is there any plan to support displaying LaTeX equations?"
Not directly, However, if you can emit HTML (including SVG) you can wrap that in the appropriate escape sequence. Like how the GnuPlot support works. MathML can be used if the browser supports it acceptably. (Firefox and WebKit-based browser seem to work; Chrome-based browsers including Electron do not.)
You might also find the Python tips page useful for ideas. The tips shown do not depend on modifying Python (and I was alble to implement them with very limited Python experience), so you might be able to do something similar for Julia. The key idea is some mechanism to override the Print part of the REPL. Even better if Julia has a "convert-value-to-html" function that the Print function can use.
I've thought about supporting some kind of plug-in framework, but it doesn't seem needed for this usecase.
Ahh I see, the Qt front-end is also wrapping up a chromium engine so GoldenLayout can be used too. I was actually referring to the one using ADS or KDDockWidgets in saying "Qt front end" previously. For displaying math formula, as you said, I can hook into Julia's IO module to emit HTML for output in DomTerm. The problem is, suppose I'm using the Electron front-end, it does not support MathML so I have to use a library like MathJax which directly renders LaTeX into HTML/CSS. I was wondering is there a clean way to load such librarys (MathJax, KaTeX, ...) in DomTerm?
"the Qt front-end is also wrapping up a chromium engine so GoldenLayout can be used too."
GoldenLayout does not depend on the Chromium engine - it just needs a reasonably modern JS/CSS support. Firefox and Safari/WebKit also support GoldenLayout just fine. However, there is no embedding for Firefox, so you have to use a full Web browser, which has some minor annoyances/limitation. There is embedding support for WebKit - but the easiest-to-use (webview) while it works reasonably well has some limitations of its own.
If you can general MathML, you might consider using --webview. However, I just notoced tha DomTerm rejects MathML, so I need to fix that...
""I have to use a library like MathJax which directly renders LaTeX into HTML/CSS. I was wondering is there a clean way to load such librarys (MathJax, KaTeX, ...) in DomTerm?"_
I don't know how MathJax does its thing. The issue from my point of view is how Julia invokes MathJax - once understand that, feeding it to DomTerm is easier.
I just checked in a fix to allow MathML elements. Try the following in a DomTerm terminal started with either --firefox or (on Linux/Gnome or MacOS) --webview (which uses webkit):
wget -q -O - https://webkit.org/demos/mathml/MathMLDemo.xhtml | domterm hcat
On Chrome-based browsers it doesn't really work.
Looks like there is a new effort to (re-)implement MathML in Chrome. However, it doesn't look like it will be solid before the end of 2021, at the earliest. If the MathML support support in Firefox and WebKit is acceptable, I suggest focusing on that for now.
"I don't know how MathJax does its thing. The issue from my point of view is how Julia invokes MathJax - once understand that, feeding it to DomTerm is easier."
MathJax is a JavaScript library that can be imported in a HTML file. One can write LaTeX directly in the HTML file. When the page is loaded, MathJax renders the LaTeX code into HTML+CSS which will be displayed by the browser. I was thinking if the Electron DomTerm could provide a mechanism to load user JavaScript code at startup. If I understand it correctly, DomTerm displays a HTML requested from a HTTP server, so maybe there is a way to config the HTTP server to do it? Or it would be great if this can be done via a plug-in framework. Another possibility is I can use MathJax in a node application and let Julia call the node application to process LaTeX, then send the resulting HTML to DomTerm.
"I just checked in a fix to allow MathML elements. Try the following in a DomTerm terminal started with either --firefox or (on Linux/Gnome or MacOS) --webview (which uses webkit):"
Thanks! it works very well on my firefox. For some unknown reason my dt-webview (built from your latest commit) crashed at startup, the error message is
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_M_construct null not valid
Aborted
"I was thinking if the Electron DomTerm could provide a mechanism to load user JavaScript code at startup."
Actually, the DomTerm Electron frontend (like the plain Qt frontend) doesn't do much interesting except create windows and menus (unless you're using the experimental electron-nodepty). The "server" logic is in the C++ backend in the lws-term directory. This server create the start-up HTML file, which just loads a much of JS and CSS. It should be easy enough to add a configuation setting to load extra JavaScript modules in the startup HTML file. (More difficult to do it dynamically, after the terminal window has started up, but that is probably also feasible to do.)
However, just loading some JavaScript isn't enough. We would also need to define some "hooks" (or "triggers") so that requested JavaScript functions are called as needed. This is also doable, but it depends on how Julia "emits" the Latex code - it seems some kind of magic escape sequence.
"Another possibility is I can use MathJax in a node application and let Julia call the node application to process LaTeX, then send the resulting HTML to DomTerm."
That should be possible without DomTerm changes - but which would be the nicer Julia/REPL experience?
"For some unknown reason my dt-webview (built from your latest commit) crashed at startup"
On which platform? I mostly run on Fedora Linux, but I can test on Mac and Windows/WSL. I could try updating from WebView git.
Thanks for the explanation on the lws-term backend. I think the firefox+MathML works well enough for me to start working on the Julia part: write a package to make Julia aware of DomTerm and send HTML to it as output (maybe call it DomTerm.jl?). Since the full support for MathML in chrome seems not in a near future, it still helps a lot if you could add something to support MathJax running in a front-end. Using MathJax is actually very simple and straightforward. It deals with TeX/LaTeX directly so we can just write TeX in the HTML body. If the page is static, nothing except loading it needs to be done. If the page is dynamic (as in DomTerm), once the DOM tree is modified, calling MathJax.typeset() is enough to render the new math content on page. There are more sophisticated APIs that I have not tried yet. Their document says MathJax keeps track of all the math it has typeset within the page, so I guess the speed of MathJax.typeset() should be enough fast. But supporting it indeed needs a bit extension of the magic escape sequence interface of DomTerm, at least DomTerm should provide the user a way to call the MathJax.typeset() function and notify the user when it receives math content. Or DomTerm can "build-in" the support for MathJax if you think the feature is relevant enough. I welcome either way.
"hat should be possible without DomTerm changes - but which would be the nicer Julia/REPL experience?"
I'll test it. It seems to me this approach might not be very economic.
"On which platform? I mostly run on Fedora Linux, but I can test on Mac and Windows/WSL. I could try updating from WebView git."
I'm using a pretty old Ubuntu 16.04 LTS at home. I have some Ubuntu 20.04 machines in office, I can also test dt-webview there. I think the relevant package is libwebkit2gtk-4.0-dev which I get
$ apt-cache policy libwebkit2gtk-4.0-dev
libwebkit2gtk-4.0-dev:
Installed: 2.20.5-0ubuntu0.16.04.1
Candidate: 2.20.5-0ubuntu0.16.04.1
Let me know if more information is needed.
"send HTML to it as output "
See the documentation for how to emit HTML. Specifically escape sequence 72 (and maybe 721).
"f the page is dynamic (as in DomTerm), once the DOM tree is modified, calling MathJax.typeset() is enough to render the new math content on page."
I think we want some more control - a more specific trigger, that affects a local section of the DOM tree, and does not have to search the whole page (which includes the entire scroll-buffer).
One idea is if you can have Julia emit something like <mathjax>2/3</mathjax> or <span load-trigger="mathjax">2/3</span> (inside the escape sequence mentioned above). Then the custom JavaScript can register a trigger that recognizes the keyword mathjax. When triggered, a suitable mathjax function is called called to do the desired transformation.
One possibility is to have a trigger or escape sequence that calls MathJax.HTML.Element.
"One idea is if you can have Julia emit something like 2/3 or 2/3 (inside the escape sequence mentioned above). Then the custom JavaScript can register a trigger that recognizes the keyword mathjax. When triggered, a suitable mathjax function is called called to do the desired transformation."
Yes this is a nice design. The Julia program (or any program running in DomTerm) can query if the current DomTerm front-end supports MathML maybe with a magic escape sequence, then based on the return, either directly emit MathML or emit a tag with a keyword to trigger custom functions. Would you like to do it this way? It seems like you will have to add a plug-in system to DomTerm to let users register their extension functions. This could give DomTerm a lot of potentials, not just displaying math, of course it has security risk too. I like this way more than a "built-in-MathJax" solution. It does look cleaner.
You probably want to restrict the user functions to only doing transformations from a part of DOM to another form, instead of running arbitrary JavaScript code to avoid risk. I have little JavaScript programming skills, maybe this is not easy. Some other terminals allow plug-ins. I tried Hyper.js before. It is fancy, has a plugin system, but not too much useful to me. If I understand correctly it is based on xterm.js that works like a traditional terminal (drawing on a HTML canvas, fast but DOM is lost).
"The Julia program (or any program running in DomTerm) can query if the current DomTerm front-end supports MathML maybe with a magic escape sequence, then based on the return, either directly emit MathML or emit a tag with a keyword to trigger custom functions. Would you like to do it this way?"
If "directly emit MathML" is one of the desired options, why not start with that? Figure out how to hook into Julia so it emits MathML (surrounded by the appropriate escape sequences), and see how well that works in terms of a nice user interface, running on Fedora or WebView. That shouldn't require any DomTerm changes.
I'll think about how to add plugins. I'm leaning towards defining a new setting where you can specify extra JavaScript files (and maybe CSS files) that get loaded when a new terminal is started. That should be fairly simple. I would probably restrict it to local files, for simplicity (and slightly better security). I.e. MathJax would have to be downloaded into a directory on your local computer, and you'd have to edit your settings.ini to specify the file/directory.
The harder problem is defining a public DomTerm API that this user-loaded JavaScript can call into. However, this can be done incrementally as use-cases suggest themselves.
"If "directly emit MathML" is one of the desired options, why not start with that?"
I am working on that :). Honestly I did not pay much attention to MathML before as I use chromium-based browser most of the time. Your previous link makes me think maybe finally all browsers will support MathML, then it should be a good target. At present, MathJax can take MathML as input so chromium-based browser can use this approach, of course that is after you have defined the way for users to call MathJax.