Conversion from PyGTK to PyGObject (and Gtk+ 2 to 3). Steps taken include:

1. Automatic rename using pygi-convert.sh to do basic find and replace between PyGTK and PyGObject syntax.
2. Fixed some additional Python 3 compatibility cleanups with ez_setup and the tests
3. Completed manual updates to finish the conversion, including the largest update which was to replace the scroll adjustment signals to inherit from Gtk.Scrollable

All tests pass with both Python 2.7.15 and 3.7.0.

PR Type

What kind of change does this PR introduce?

• [ ] Bugfix
• [X] Feature
• [ ] Code style update (formatting, local variables)
• [ ] Refactoring (no functional changes, no api changes)
• [ ] Documentation content changes

What is the current behavior?

Drawing of complex (diagrams) is relatively slow, especially on platforms like macOS. Although the GtkView already uses a back-buffer, it still needs to draw() all elements when the widget is repainted. Worst case it needs to redraw it multiple times: once for bounding box calculation and any number of times to refresh the back buffer.

Issue Number: N/A

What is the new behavior?

This PR contains a couple of improvements:

• When items are painted for bounding box calculation, the resulting drawing (a cairo surface) is cached, so subsequent drawing operations can reuse this effort.
• A special painter, RenderedItemPainter, can be used to draw items previously rendered.
• The view is now automatically redrawn if the view's matrix has changed.
• Update handling has been simplified. There are no matrix-updates anymore.

Does this PR introduce a breaking change?

• [X] Yes
• [ ] No

• update API

Other information

Since items were already drawn with the right offset (done by ItemPainter), it makes no sense to have a separate matrix-update. Such an update will result in a redraw anyway.

As a result all matrix-update logic has been removed from GtkView, which resulted in a simpler interface. A nice bonus.

I also considered putting a cache in ItemPainter. It is not easy to pass on data on which item needs updating and which items are removed. Therefore it seemed more logical to keep this data in the view and instead create a separate renderer (RenderedItemPainter), that takes a rendered surface from the view and draws that instead.

BoundingBoxPainter is not needed anymore. It's kept in for now to ease the transition to the new drawing model.

It looks like drawing is considerably slower when the demo app is in full screen. Small windows are fast, bigger ones are slow.

To do

• [x] There's still an issue where attached elements are not properly redrawn

Is it intended/desired that during a resize operation of the GtkView, the canvas is not drawn, i.e. only the background color is visible?

Our canvas is nested in (several) Gtk.Paned and resides next to a Gtk.Revealer. Thus, in three situations, no state machine now shown:

• the panes are resized
• the revealer slides up
• the window is resized

Personally, I would want the canvas to be drawn in all these situations.

Hello,

I have updated the README of Gaphas. I have reviewed and edited the file for :

1. Spelling and grammar
2. Edited the hyperlinks for virtual env

I do have comments on this line-- The constraint solver can also be used to keep constraints contained within the item true, for example, to make sure a box maintains its rectangular shape. (the word "true" is confusing).

First, I wish to thank you for your work on gaphas!

Gaphas has been a real delight to use. The code is of excellent quality, very readable and well documented. I love that gaphas has minimal dependencies, is written in pure Python and successfully abstracts away the more painful parts of using a gtk.DrawingArea as a canvas. Gaphas is quite wonderful, thank you!

I've been working on a prototype project using gaphas to implement something like the Blender node editor. This project is currently in a private repository but I hope to make it public very soon.

My main concern with gaphas is that the last public commit is from July 2012. Is development still active? Are you accepting pull requests? While learning gaphas, I have made several improvements that I would like to contribute back. Some suggestions that I would be happy to submit as a series of pull requests:

• Multiple typo fixes.
• Deletion of trailing whitespace.
• Possible addition of a .gitignore to the gaphas repository.
• Deletion of code that has been commented out (only a few instances of this).
• Wrapping docstrings to 80 characters (mostly good already, but a few places could do with better wrapping).
• A few other more technical ideas if you are interested!

Please do tell me if you are interested in accepting these sorts of PRs!

With the change from simplegeneric to singledispatch, gaphas is no longer backward compatible with code that registers custom types, as you now need to call register instead of when_type.

This is fine, as you increase the minor version.

I was just wondering, whether you think there is an easy way for other software not requiring any code changes. Maybe somehow monkeypatching singledispatch? Doesn't sound like the best solution :-D

Hello Dan,

As discussed earlier, here are my review comments on Gaphas docs. I hope you find them useful. If you find anything that is not clear, please do ask. Also, ignore if I did any mistakes.

The latter part of my document you will find just the grammatical correction on the content. I hope you find the corrections.

Thanks! Janet Gaphas.docx

This issue goes along with https://github.com/gaphor/gaphor/issues/61. GitHub supports displaying the license on the repository overview. It only supports licenses from choose a license, which includes the LGPL 2.1, but not 2.0.

The main changes are rewording Library to Lesser, and adding another option for using a shared library mechanism: b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with.

We are also considering moving to Apache instead of the LGPL, the summary of differences are:

• LGPL requires that derivative works must be licensed using the LGPL as well
• LGPL requires that source code must be disclosed with distribution, Apache does not
• Apache requires an express grant of patent rights for contributions, LGPL v2.1 does not (v3 does)
• Apache is more compatible, so we could include MIT or BSD software in our project, but we need to ensure that there is no other LGPL libraries that exist within the current software.

Any other thoughts on upgrading to a newer version of the LGPL or to Apache?

• [X] @danyeaw
• [x] @amolenaar
• [x] @wrobell
• [X] @jlstevens - verified only removed whitespace and changed width of text
• [X] @adrianboguszewski - no commits remain in current code base
• [X] @franzlst

This change is to fix segmentation faults when trying to test Gaphas on Travis CI. These faults aren't reproducible locally, so this PR is to test the code using the CI.

Signed-off-by: Dan Yeaw [email protected]

Is your feature request related to a problem?

Currently, when implementing Item.draw(), you have to take into account speed: every time a canvas is redrawn, this method is called.

Rendering is relatively slow, esp. on macOS.

I did some trails with cairo.RecordingSurface, but that's probably not what we need: to render a surface it has to be applied as a pattern on the target surface. For our purposes it would be enough to just replay any drawing operation on the target surface. My assumption is that that will also be faster.

Describe the solution you'd like

When an item is drawn (the first time this happens is when the bounding box is calculated), the drawing operations should be recorded. On subsequent draws, the recorded items should be replayed. This ensures that:

1. we always draw the same thing, until the item requires an update (keeps bounding box consistent)
2. the concern of draw() being fast is less strict

Solution to be determined still. See alternatives.

Describe alternatives you've considered

• Create a custom DrawingContext for Gaphas. Instead of calling DrawingContext.cairo methods, expose all required methods through DrawingContext directly. This should also expose methods for rendering Pango Layouts and SVG images (librsvg).
• Use RecordingSurface. For one, @danyeaw got artifacts in the diagram. Secondly it's applied via patterns, where it's more logical for us to just just replay the recorded events on a surface.
• Maybe add a bit of C/Cython) code that hooks into cairo and provides the required capabilities (e.g. expose RecordingSurface.replay or expose the surface observer code).

Additional context

We should handle SVG and Pango layouts as well. They render to a cairo.Context directly. Do we want to keep that interface, or provide a Gaphas specific way to render those?

PR Type

What kind of change does this PR introduce?

• [ ] Bugfix
• [X] Feature
• [ ] Code style update (formatting, local variables)
• [ ] Refactoring (no functional changes, no api changes)
• [ ] Documentation content changes

The change

Gaphas works for GTK+ 3. This PR adds support for GTK 4 -- without breaking backwards compatibility.

Where there are incompatibilities between the GTK 3 and 4 api, a check for Gtk.get_major_version() == 3 is done.

Tests can be executed with GTK 4 by running TEST_GTK_VERSION=4.0 pytest.

Issue Number: https://github.com/gaphor/gaphor/issues/618

Does this PR introduce a breaking change?

• [ ] Yes
• [X] No

Other information

In GTK 4, the canvas is a lot more responsive, on macOS at least.

Many tools have an option to route lines, or at least create lines in a way that avoids other objects.

Sources

To create some sort of auto-layout thingy on top of this we'll need something like COLA (Constraint Layout)(https://www.adaptagrams.org/)

• LibAvoid looks also very promising

Javascript implementation: https://ialab.it.monash.edu/webcola/ (github: https://github.com/tgdwyer/WebCola)

PR Type

What kind of change does this PR introduce?

• [ ] Bugfix
• [X] Feature
• [ ] Code style update (formatting, local variables)
• [ ] Refactoring (no functional changes, no api changes)
• [ ] Documentation content changes

What is the current behavior?

Lines are just straight.

Issue Number: #360

What is the new behavior?

Gaphas has code that support object avoidance in the canvas.

• [X] When a new line is drawn, the line tries to avoid obstacles
• [ ] When an element is moved, the lines should move aside
• [ ] When an element is moved, connected lines should reroute
• [x] Avoidance for normal lines
• [x] Avoidance for orthogonal lines
• [ ] Sometimes the routing algorithm "hangs". Esp. when the paths are more complicated.

Does this PR introduce a breaking change?

• [X] Yes
• [ ] No

Other information

Try examples/demo.py. The (experimental) collision avoidance code is activated there.