Christof Ressi wrote: > As I outlined in a previous mail OK, I get the point. Sorry I didn't read this part of your message in detail before.
Miller Puckette wrote: > either of two possible ways: My feeling goes towards (1). > causes inlets or outlets to appear > on the Pd side the text is getting hammered by messages from elsewhere at the > same time I'm sure solutions can be found... > this noisome one: "GUI externals" such as the knob now have to load dynamic > libraries into two programs About this: the new GUI layer of pdlua is just awesome, and IMO something to take into account for future GUI dev of Pd. It's a very powerful and elegant way to design custom GUIs. Le lun. 30 sept. 2024 à 14:37, Miller Puckette <mpucke...@cloud.ucsd.edu> a écrit : > > going back to an earlier question, which I think is a (or the) central > one... > > On 9/30/24 10:30 AM, Christof Ressi wrote: > > On 30.09.2024 09:43, Miller Puckette wrote: > > > >> Well, to quote out of order: > >> > >> "... for all built-in objects the core shouldn't have to tell the > >> GUI how to draw it." > >> > >> Well, I think that is a fundamental point on which you and I > >> disagree. I tried once with Max/FTS (19890-1994 or so) to do > >> precisely that and the problems of keeping the graphical layer and > >> the real-time layer in sync ended up overwhelming. In particular, > >> the graphcal layer had to wait while the real-time layer verified > >> whether object creation succeeded or not which made the loading of a > >> patch from file impossibly slow, unless the GUI layer had its own > >> instance of Pd running right inside it in parallel with the real > >> one. And that - keeping parallel copies of the same complex data > >> structure in sync as it was changed from both sides - was also too > >> much to manage. > > > > I'm not sure I understand. Why would you need to wait for the UI to be > > in sync? What is the difference between > > > > a. sending "draw X, Y, Z" to the UI > > > > b. send "draw W" to the UI, which in turns draws "X, Y, Z" > > > > You just shift the responsibility, but there is no fundamental > > difference. Please have a look at the linked draft PR form IOhannes! > > I've already linked the example for "bang" > > (https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/1765/files*diff-08294559d6a971f74472cc2fca7cce724cdd9e055ac46f6e38c4633b27a97bcbR25-R33__;Iw!!Mih3wA!CWqblkk1v8fW-0zvFNxIHZDgxp4Gw-Wlvsuq4ZecKIr2BkkCSPYf7y4Tu5tSXJ5bYkyjSzbKVHNGWg$ > > ). Look at how many drawing commands we're currently sending to the UI > > for such a simple object! With the draft PR we would only send 1/10th > > of the commands even for the most simple objects. For more complex > > objects, like VU meter, it can be orders of magnitude. > > > > But it's not only about the drawing commands itself. Sending commands > > like "draw a line", etc., mandates that the object is constructed of > > individual primitives on a canvas. But in a framework like Qt a > > built-in Pd object can just be a single widget (which knows how to > > draw itself). Of course, having one widget in a canvas is much more > > efficient than having dozens of individual geometric primitives! > > > 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? > > (2) it's just a drawing with a tag, not an active widget; perhaps mouse > hit detection is done in the GUI but everything else in Pd. In this case > it's not a big enough change to make much difference, except for this > noisome one: "GUI externals" such as the knob now have to load dynamic > libraries into two programs, instead of just one. > > Depending on which scenario we want to consider (or perhaps this is > somehow a false choice) we can go into more detail about this... > > cheers > > M > > > > --- > pd-dev@lists.iem.at - the Pd developers' mailinglist > https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/6WFFUCOQCFNEKCVI2QTY6XYZN6QAPFZY/ --- pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/W2CDJQSS3KU73N5T3UB7BVOPRY3XALVB/
