4 ms·
Pyract: a new way of writing Gtk+ applications
- stuaxo 10y agoCertainly much nicer than the traditional way of doing this :)
- wallacoloo 10y agoSo 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?
- samtoday 10y agoThe Node class (used in render) is just a tuple, so it is very fast. It riffs it to ensure minimal changes.
- xenonite 10y agoFor a quite similar approach of observing/binding variables to GUI objects, have a look at Qt/QML.
- snuxoll 10y agoGObject/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.
- bgdkbtv 10y agoThis is great! Is there anything similar for developing macOS apps?
- netforay 10y agoThis 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.