How'd y'all, (I will try to keep this short, since I find I really don't read beyond a couple of paragraphs when people start writing long treatises...)
1. Miller I am happy you spent some time looking into this. It is IMO an important direction we have to all consider for the project's future. 2. (Please don't take this personally.) I am a little disappointed that many initial responses to Millers mail were more "you should have done it this way" as opposed to "wow, we are super happy you are interested in this and also spend time making a preliminary tech demonstration". 3. Comparisons are useful but Pd is not SuperCollider. That being said, there are definitely technical solutions to consider form SC but I wouldn't want that to overshadow the discussion and turn into "lets redo Pd core into SC core." ;) 3. IOhannes + Giulio etc did a bunch of work with the refactor but can we admit that has stalled? Perhaps a different approach is warranted? 4. I think Miller's demo code is pretty compact... and probably easy to modify to prove an alternate technical approach. ;) As I have long seen, there can be lots of noise on pd-list but little outcome. I'd rather not see it again here on pd-dev. 5. IHMO I'd also like people to consider libpd. In a dream going way back to PdCon 2026 in NYC, I imagined a future where Pd vanilla and various forks all shared the same Pd core through libpd with GUI handling, customization, etc implemented in some modular way. The dream was that we could *all* leverage the work across various places to benefit everyone and make all of this more sustainable. (ie. I'd rather make work *with* Pd than have Pd my *work*). 6. I think we need a video call on this soon! --- And now to confuse the thread even more, I will to chime in here: > On Sep 30, 2024, at 3:16 PM, pd-dev-requ...@lists.iem.at wrote: > > Suppose we replace "draw X, Y,Z" with "draw button". I think this then > spins out in either of two possible ways: > > (1) the "button" widget on the GUI side now takes care of mouse-hit > detection and making itself flash (and eventually widgets with text can > grab focus, handle copy/paste, etc). In this case the GUI widget has to > maintain a connection with its corresponding object in Pd. This gets > very complicated when, for instance, changing text causes inlets or > outlets to appear, which perhaps on the Pd side the text is getting > hammered by messages from elsewhere at the same time. Distributed > database management, anyone? This is actually how Pd Party and Pd Droid Party work... we intercept the messages sent to the widget via send/receive names and simple respond to accordingly. In this case, there is a separate GUI tree of a sort, but it works fine without sending any actual input messages to the core. Visuals are implemented via CoreGraphics calls: https://github.com/danomatika/PdParty/tree/master/src/gui Honestly, the situation on iOS is *very* easy since the UIKit layout engine handles views within views and hit testing for you. Same for AppKit on macOS. In fact, pretty much *all* modern UI frameworks do this and using it builds down to implementing a callback for mouse enter/exit, move, clicked, etc. Same for touch events (which would be a *very* good idea to add handling of to Pd. -------- Dan Wilcox danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>
--- pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/YMD7DVZFUMXO7I4QM4OWVYHM42S5JEIK/
