(forwarding to pd-dev :)
in Pd it's everything the drag-rectangle touches. This might not be an issue for other people.
That's what QGraphicsScene does by default! I just double checked with my level editor. Don't underestimate modern UI frameworks ;-)
-------- Forwarded Message -------- Subject: Re: [PD-dev] Re: Fwd: Re: gtk front end for Pd? Date: Mon, 30 Sep 2024 21:55:54 +0200 From: Miller Puckette mpuckette@cloud.ucsd.edu To: Christof Ressi info@christofressi.com
The specific thing I hate is that only things entirely inside the drag-rectangle get selected - in Pd it's everything the drag-rectangle touches. This might not be an issue for other people.
cheers
M
On 9/30/24 9:45 PM, Christof Ressi wrote:
I also hate the way every canvas I've seen does rectangle-selection. Maybe you know of one I won't hate :)
And... every widget set I've seen thinks widgets live in rectangles. The second most important graphical item in Pd is the patch line. Giving it a widget-style selection method? Disaster. I don't think patch lines can be TK or GTK r QT or anyone's widgets - imagine how those bounding rectangles would fill th screen :)
Qt only uses bounding rectangles for the broad phase hit detection. The actual hit detection can then be further customized for each widget. The collision shape can be anything from a circle to an arbitrary polygon or even a bitmap. For example, a line item only receives a mouse event if you click on the actual line.
In case you're talkinga about the actual graphical representation of the selection: that's totally up to you. By default, QGraphicsScene only notifies the selected items; you can then decide to how to present the selection to the user. In the case of Pd, you would only change the appearance of the selected objects (i.e. make them blue), but not draw a bounding rectangle.
Another nice feature about Qt's selection mechanism is that you can use arbitrary selection shapes. For example, you can select items by drawing an arbitary path, similar to "free selection" mode in painting programs. That's actually a feature I've always wanted in Pd :)
Thanks to Antoine for mentioning pdlua! I will need to check it out. I have already seen people doing some very cool stuff with it. Maybe they already have the perfect solution :)
I'm also looking at pdlua, which might want to become the official way to make graphical externs AND to add scripting in a fundamental way to Pd :)
+1 for an official scripting language! :) (I love Lua, BTW.) And yes, it would make lots of sense to leverage the scripting language to implement custom UIs!
Christof
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
Em seg., 30 de set. de 2024 às 16:59, Christof Ressi info@christofressi.com escreveu:
Thanks to Antoine for mentioning pdlua! I will need to check it out. I have already seen people doing some very cool stuff with it. Maybe they already have the perfect solution :)
I'm also looking at pdlua, which might want to become the official way to make graphical externs AND to add scripting in a fundamental way to Pd :)
+1 for an official scripting language! :) (I love Lua, BTW.) And yes, it would make lots of sense to leverage the scripting language to implement custom UIs!
+1k
Yay, great to hear that! BTW, I remembered about this ticket we opened years ago inquiring about adding lua to Pd natively! https://github.com/pure-data/pure-data/issues/687
Now that Tim is doing great work for graphics, this would be even more awesome! And I wouldn't have to worry in shipping it in ELSE for some externals that already use it :)
cheers
Let me share Tim's thoughts he sent me via a chat about coding externals in lua, which I think are a perfect sell. Compared to C externals, lua externals:
- Encourages open-source, since the source code is the object - Works on every OS, architecture, pd floatsize, multi-instance, all without needing recompilation - You can easily modify objects if you want to - GUIs are now much easier to write with Lua than with C - Are guaranteed to keep working even if Pd's C API changes, or Pd changes GUI framework - Are guaranteed to work across Pd forks, as long as they correctly implement the lua API
Em ter., 1 de out. de 2024 às 15:36, Alexandre porres@gmail.com escreveu:
Em seg., 30 de set. de 2024 às 16:59, Christof Ressi < info@christofressi.com> escreveu:
Thanks to Antoine for mentioning pdlua! I will need to check it out. I have already seen people doing some very cool stuff with it. Maybe they already have the perfect solution :)
I'm also looking at pdlua, which might want to become the official way to make graphical externs AND to add scripting in a fundamental way to Pd :)
+1 for an official scripting language! :) (I love Lua, BTW.) And yes, it would make lots of sense to leverage the scripting language to implement custom UIs!
+1k
Yay, great to hear that! BTW, I remembered about this ticket we opened years ago inquiring about adding lua to Pd natively! https://github.com/pure-data/pure-data/issues/687
Now that Tim is doing great work for graphics, this would be even more awesome! And I wouldn't have to worry in shipping it in ELSE for some externals that already use it :)
cheers
-
Alexandre -
Christof Ressi