New web-based ROOT GUI classes

Hello devs,
I have read that ROOT is ‘migrating’ its X95 GUI classes to a new web based and modern looking approach, whereas the old ones will be kept more or less in a frozen state. For the moment, I am still using the old GUI classes, but this change raises some questions to me that I thought might be also popping up in others heads (at least of GUI developers using ROOT), thus I ask them here in the forum. Asking them would help me to decide whether or when I would think of migrating to these new more modern classes.

  1. I have a C++ program using ROOT Gui classes (I create a window via a TApplication, etc.). If I were to migrate to web-based classes, would this mean that my window would now run on a web browser? Or could it still be standalone?
  2. Does web-based mean that the GUI-part of my program will no longer be written in C++. Something like what QML is to Qt ? Do I need to learn HTML or Javascript to use those?
  3. My application is very performance-critical, as it is used for data acquisition. Any delay in the responsiveness of the GUI window could affect the data intake, even if they are already in separate threads (they need to communicate between them at least once in a while). Are there any benchmark whether the performance is better in the old or in the new classes? Startup performance is also important, as I believe that starting a browser causes more delays than starting an old window. Memory usage is also of concern, as I am always scared at how much RAM memory just Firefox is consuming by opening four or five tabs.
  4. Concerning stability, is it expected to be similar, better or worse? What happens if the web browser ‘hangs’, which happens sometimes when you open too many other tabs, etc. What if it crashes?
  5. Concerning debugging, I use valgrind for memory leaks and helgrind for race conditions, which are prone to happen when you design GUI interfaces. If one uses web based classes, would this mean that the debugging would be more complex, as it is not within the C++ environment, but there is a part running in the web browser, that has probably a separate debugger?
  6. Is there a timeframe envisioned for when the new classes will be production-ready?
  7. Will there be a more or less one-to-one equivalence? And guidelines on how to migrate? Or will it require a completely new rewriting?
  8. Is there a timeframe envisioned for when the Users Guide WritingGUI chater, tests and/or tutorials will be migrated to the new GUI model?

Thanks in advance for your attention and your work!

Hi @ferhue; I am sure @linev can provide some guidance here.

Cheers,
J.

Hi,

Really a lot of questions.

  1. Both variants are possible - GUI can run in normal browser or in apllication-managed windows. In last case one uses chrome-based libraries: CEF or QWebEngine

  2. Visual part of web-based GUI will be written with HTML/JavaScript. We do not plan to develop something like QML of Qt - it would be too complicated for us. We advise to use openui5 framework, but any kind of framework (like bootstrap) can be used.

  3. Typical latency between client and server is between 1 and 20 ms - when working on local machine. There is special application in tutorials/webgui/ping/ which let test such latency with different settings. Typical startup time of the browser is few seconds. From other side, already running browser application can be reused - opening new browser tab is much faster. I hope, nowadays memory usage should not be an issue.

  4. Concerning stability. Server part if fully decoupled from GUI. If browser hangs - one just close/kill hanging instance and start new one. From that point of view such approach much more robust compare to classical approach.

  5. Debugging in such approach splits in two parts. With normal debugger one can check server-side C++ code. For debugging of client parts one can use standard browser-based tools, starting from browser console.

  6. RWebWindow is central class on C+±side. Its interface “stable” since some years.
    Just look on webgui/webwindow/ tutorial - it does not change since three years. I expect only cosmetic changes here - if any at all. I would say that current API is very close to final state.

  7. No, we do not plan to provide support of TG... - like classes for web-based GUI. It will produce too much overhead.

  8. Some tests and tutorials already there; also minimal user guide. But of course, much more examples can be provided. If you have some particular questions - one can provide examples for them.

Sorry for very short replies.

Regards,
Sergey

1 Like

Prince & The Revolution - Purple Rain (Live 1985) [Official Video] - YouTube

me, the person is sx95

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.