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

wxWidgets and Qt support #9

Open
jbohren opened this issue Apr 22, 2014 · 4 comments
Open

wxWidgets and Qt support #9

jbohren opened this issue Apr 22, 2014 · 4 comments

Comments

@jbohren
Copy link

jbohren commented Apr 22, 2014

@jrfonseca, we've been using Xdot for several years now with a wxWidgets-based fork and, more recently, a Qt-based fork. It'd be cool to unify them into a single library, and combine the common code.

Check them out here: https://github.com/jbohren/xdot/tree/indigo-devel/src/xdot

@ZedThree
Copy link
Contributor

Since #35 has been merged, all the GUI-related code is solely in xdot.ui, which should make unifying all the forks easier. Probably even more common code could be pulled out, leaving elements.py and window.py as the only two files which depend on the exact GUI library, possibly even just window.py.

I've been trying to get my head around how to do this sensibly, and I can see two different ways of doing it:

  1. Separate submodules as distinct packages on pypi, with a common xdot-base package. You would install xdot-<gui?, which would bring in xdot-base.
  2. Different GUI libraries as backends which could be swapped at runtime, as in matplotlib.

The first way would almost certainly be easier, but managing separate packages for each GUI might be difficult. The second way seems maybe cleaner, but I'm not even sure where to begin on that.

@Morwenn
Copy link

Morwenn commented Mar 22, 2018

I tried my hand at rebasing the Qt fork in the original question (with Python 3 and PyQt5) and the split is just short of being sufficient to abstract away the UI: in the Qt fork, Pen.dash has been updated to use the Qt attributes Qt.SolidLine and Qt.DashLine (and I added Qt.DotLine for dotted lines to complete the fork). However the assignment of a value to Pen.dash is done in the parser in handle_linestyle, making it depend on PyQt5.QtCore.Qt values in my case.

To avoid this problem, Parser.handle_linestyle should probably delegate to a Pen.handle_linestyle function so that the parser only has to forward the strings "solid", "dashed" and "dotted" to the Pen instance, and let the pen handle by itself how it inteprets those constants.

@Jo-Con-El
Copy link

@Morwenn, do you have your fork somewhere? It seems that you made all the work and you're just a pull request or two away from integrating it.

@Morwenn
Copy link

Morwenn commented Oct 22, 2018

It's probably somewhere on my work computer. We didn't use the library in the end, but LGPL says that I should share the improvements anyway. I will try to find it again once I'm back from holidays.

If I'm not mistaken I had only kept the code up to the widget, and not up to the window level.

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

5 participants