Pyract: a new way of writing Gtk+ applications

learntemail.sam.today

152 points·fmoralesc··9 comments

So this recreates the entire scene graph whenever the UI needs to be re-rendered? What happens when you use this in a complex application with lots of different nodes that needs to be updated frequently? Think a midi tracker / DAW / video editor, where it's common to have a vertical bar that moves across the screen indicating the current section of audio/video being played. Is this still suitable for that sort of application? I get that it's doing diffs and not actually re-rendering everything, but how heavy is the call to create each node?

The Node class (used in render) is just a tuple, so it is very fast. It riffs it to ensure minimal changes.

This is similar to what React.js or Vue.js does on the browser. I always thought of this, very nice to see it running. I worry about the following.. 1. How we do complex objects like Trees and Tables? 2. How efficient are these Native nodes over DOM nodes in Browser?

I always wonder between Native vs DOM.

For a quite similar approach of observing/binding variables to GUI objects, have a look at Qt/QML.

GObject/GTK also have GBinding's, which are exposed in PyGObject. Most of the remaining problems stem from things like List/Tree components that use complex models, though providing a derived model class that is backed by a reactive data store would handle that nicely.

Certainly much nicer than the traditional way of doing this :)

This is great! Is there anything similar for developing macOS apps?

I'd investigate something cross-platform like the awesome Toga: http://pybee.org/project/projects/libraries/toga/

Will take a look, thanks!

Reply on news.ycombinator.com