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 mpuckette@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... ). 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/6WFFUCOQCFN...