[example app] Add minimal trace-viewer example app, similar to RCP?

[marcdumais-work]

The example app in this repo is quite feature-full, supporting C/C++ and having the open-vsx integration that permits adding VS Code extensions at runtime. Nothing wrong with that - a portion of eventual adopters of the trace extension would use it in such an application.

However it could also be useful to have a single-purpose application, dedicated to trace viewing with no extra clutter/features. I guess that one could fulfill a similar use-case as the Trace Compass RCP. I think this application could be "pure Theia" and would not require VS Code extensions support.

[ebugden]

@bhufmann @tahini This thought has been at the back of my head for a while now: I think the default trace viewer Theia application should build with just the trace viewing features (no debugging, no vs code extensions, no editors).

My understanding is that most open-source users (vs. internal extenders) would only use this tool for trace analysis (rather than as an IDE). The IDE features are unnecessary clutter for these users.

To cover the the active community's use case, I assume we could also have a compilation option for building the trace viewer application as a fleshed out IDE (as it is now), but I don't think this should be the default.

---

CC: @MatthewKhouzam @mirsky-work @ssmagula

[bhufmann]

I agree that providing a application that users can download/install and use for trace analysis. GitPod is good for demoing purposes, but users cannot use it with their own supplied traces. It should be straight forward to define such an application using a package.json definition. Maybe provide the Electron version only. This application could be deployed in this repository for now.

Alternatively, the VsCode plug-in could be deployed instead and users install it from the VsCode marketplace. This of course requires that the VsCode plug-in is ready to be used.

In both cases, a corresponding trace server needs to be provided as well. Ideally, it would be done for the user during installation of the deployed trace viewer.

[ebugden]

After chatting with @tahini, we think it's best to implement the open-source Trace Viewer MVP as a dedicated trace viewing application (no IDE features) instead of a VS Code extension. What are your thoughts?

• The open-source MVP would be a stripped down version of the full IDE Theia application (without debugging, version management, etc).
• The VS Code extension would be put to the side for now until integration with IDE features becomes relevant

Reasons:

• Integration with code development isn't urgent for open-source users: Open-source users don't currently require the code development features that certain implementations may need.
• Simpler UX design problem: Starting with a dedicated trace viewer with just visualisations (no source code) makes it easier to iterate towards an elegant complex tool. Good integration with code development is a whole other set of more complex UX design problems.
• Stays close to the community's dev goals (compared to VS Code extension): Currently, most of the active dev power is working towards the Theia-based IDE. By making the open-source MVP a stripped down version of the full IDE (instead of a VS Code extension), the open-source version can still use all this work.
• Full features and implementation flexibility of main Theia application: Ex. Automatic server management, main menu changes. VS Code has many limitations on how an extension can change the UI.

---

Deciding on a dedicated trace viewer app is enough direction for now, but this topic links back to core ⭐existential questions⭐ for the open-source tool:

• What is the open-source tool's niche? (Tool: Trace Server Analyses + Trace Viewer) What unmet need does it fill?
• Who are our intended open-source users? What do they need?

It's important that we define initial answers to these questions soon because it will help us understand our goals (and the differences with certain implementation's goals) and allow for more focused design decisions. @tahini @MatthewKhouzam @bhufmann we had briefly discussed these questions in the autumn, but @ssmagula and I will be looking at them more seriously in the near future.

[bhufmann]

Deciding on a dedicated trace viewer app is enough direction for now, but this topic links back to core starexistential questionsstar for the open-source tool:

* **What is the open-source tool's niche?** What unmet need does it fill?

This open-source tool capabilities are really defined by the trace server that is used for trace analysis. Using this tool with the Trace Compass trace server, then it provides a rich set of features for analyzing traces coming from LTTng Kernel and UST tracers. So, deployment with the Trace Compass servers will serve such user base in analyzing performance and other reliability issues.

You second part of the question is two fold. On one hand, providing the standalone application with the Trace Compass server won't have much "unmet needs" for the users that are already using original Trace Compass RCP. Hopefully, with better UX eventually. On the other hand, the new architecture, i.e. client-server architecture, modular design, opens new opportunities that the original Trace Compass RCP can't provide, to name a few:

• Integration with other web-based services and dashboards (e.g. CI)
• Distributed analysis on the server side to allow for higher scalability than a pure desktop application
• Integration with modern web-based IDEs and workspace management systems

* **Who are our intended open-source users?** What do they need?

My answer above applies here too. The Trace Server will determine the user base, i.e. when using the Trace Compass server then it's the same user base and similar needs. Higher scalability when distributed server is available, might be interesting for some.

[ebugden]

I didn't frame the existential questions sufficiently to get the kind of information I was hoping for. I was off topic for this issue so I'll come back to these questions after discussing with @ssmagula and collecting some more information from prospective users.

Thank you for this context!