Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Considerations for porting ESP to a new GUI framework. #356

Open
damellis opened this issue Aug 27, 2016 · 3 comments
Open

Considerations for porting ESP to a new GUI framework. #356

damellis opened this issue Aug 27, 2016 · 3 comments

Comments

@damellis
Copy link
Owner

How much support is there for custom plots / visualizations?
Does the ESP interface still need to be compiled against the ESP example?
How hard is it for others users to set up compilation against the GUI framework?

@nebgnahz
Copy link
Collaborator

nebgnahz commented Aug 28, 2016

Here is some quick information about Qt:

Porting existing ESP codebase to Qt shouldn't be too hard (although definitely time-consuming). In fact, there are a couple things are can directly re-use given it's still C++.

Regarding the integration with examples, compilation/linking, I think as long as we stick to C/C++ code, the example itself has to be compiled.

  1. Compile it together with the GUI.
  2. Only link it against the GUI application
  3. Compile it as a stand-alone application, but our framework provides a channel to get the data.

I think we all know option 1 and 2 reasonably well. I will elaborate a bit on option 3. Think of GDB or any debugger where the debugger runs in a separate process and talks to the running process. Our GUI application is simply a front-end that communicates with the back-end. In such a way, we could swap the front-end with web apps or other GUIs.

@damellis
Copy link
Owner Author

Another question is how we compile the example (i.e. what IDE and build process to use). Some options:

a. Continue using existing platform-specific IDEs (e.g. Xcode, Visual Studio, cmake).
b. Use a cross-platform IDE (e.g. Processing or Sublime?).
c. Edit and compile ESP examples from within the ESP interface. I think this requires us to use your option (3).

It's debatable how much (c) would get us over (b), as re-compiling the example code is probably going to reset much of the data in the other parts of the interface. Sticking with (b) would mean we could avoid having to build the front-end / back-end communication channel required for your option (3).

@damellis
Copy link
Owner Author

Let's defer this for now, as it's a big task and not the top priority.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants