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

new Hets GUI based on Python interface #2109

Open
tillmo opened this issue Sep 21, 2022 · 3 comments
Open

new Hets GUI based on Python interface #2109

tillmo opened this issue Sep 21, 2022 · 3 comments

Comments

@tillmo
Copy link
Contributor

tillmo commented Sep 21, 2022

develop a new GUI, replacing the old one based on uDrawGraph.

  • It could be based on the Python interface Python interface #2108 and a suitable graph drawing tool, which preferably should support incremental graph drawing. The GUI should work as standalone application that calls a Hets that is possibly contained in a docker container. Hence, inside the docker container, a Python wrapper is needed, which is then called by the GUI.
  • The communication could be via sockets, or a RESTful API, or ...
@b-gehrke
Copy link
Collaborator

b-gehrke commented Sep 28, 2022

One possibility is to create native python bindings and build a GUI based on these. Then, put hets and the GUI inside a docker container. For this to work, the host needs an X-Server running. Many linux distributions ship with disyplay managers that rely on X directly or suppotr X applications on wayland with Xwayland. The same goes for mac. For windows there are many X servers available [1].

hets-arch-1

Another way could be for the hets server to provide the core features via a REST API. Then, build a python REST client providing hets features in python. A GUI can than be build upon this library. The server could then be hosted on a local machine (e.g. using docker) or even on a remote server.

hets-arch-2

The first approach has the benefits of creating native python bindings which will be more performant than a REST client. But it requires the development with these bindings to be inside a docker container or native linux environment.

The second approach simplifies development but relies on HTTP requests. However, this could be beneficial as we could host such a server.

Of cause, the two approaches are not mutually exclusive.

@tillmo
Copy link
Contributor Author

tillmo commented Sep 28, 2022

@fabianneuhaus could you please try on your Mac whether remote ssh with an X11 GUI works?

@b-gehrke
Copy link
Collaborator

You can check this for example by starting an ubuntu docker container

$ docker run --rm -it -e "DISPLAY=$DISPLAY" --net host ubuntu

and install and run some x application in it

# apt update && apt install -y x11-apps && xeyes

On ubuntu I also have to allow connections to my running X server with xhost +local:docker

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

No branches or pull requests

2 participants