Hi, I am hoping to learn how to better code with tcl/tk and GUI design and one of the things I would like to do is trying to make a PR so iemguis can be resized, like comments can.
I also wanna do that for my externals. But the mechanism I have there in an object like [else/scope~] and [else/note] is inherited from Cyclone and has a much different strategy, so it seems.
Could anyone help me figuring out Pd's code, where exactly to look and dive in, to understand how an object like comment is aware of when Pd gets into edit mode, so it changes its look to show a draggable sidebar. Also, how is it aware that when reaching that sidebar it must show a different double sided arrow cursor?
thanks
On 11/6/24 01:28, Alexandre Torres Porres wrote:
so it changes its look to show a draggable sidebar. Also, how is it aware that when reaching that sidebar it must show a different double sided arrow cursor?
honestly, i have no idea what you are talking about.
gmasdr IOhannes
Alex is talking about the "resize" cursor you get when hovering over the border of an object box.
On 06.11.2024 11:34, IOhannes m zmoelnig wrote:
On 11/6/24 01:28, Alexandre Torres Porres wrote:
so it changes its look to show a draggable sidebar. Also, how is it aware that when reaching that sidebar it must show a different double sided arrow cursor?
honestly, i have no idea what you are talking about.
gmasdr IOhannes
pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/X4C7PRUKKP6...
Em qua., 6 de nov. de 2024 às 09:46, Christof Ressi info@christofressi.com escreveu:
Alex is talking about the "resize" cursor you get when hovering over the border of an object box.
Yes, the cursor for resizing of all objects, the gui boxes (number/symbol/list) and comments (all but iemguis).
So the question is where in the code can I look and see how it is possible for Pd to be aware that it needs to change its cursor.
Not only that, but also how does the comment box know that it is in edit mode, so it displays a sidebar that represents its limit?
In order to know that Pd is in edit mode I do what I consider an ugly hack, which is listening to all canvas messages and filter the 'edit' message. I think it looks bad in the code and I wonder if there is a simpler way. Or if the way comment works is just something not exposed for externals. And I have the same inquiry for the cursor thing, if I can learn and apply the same mechanism for externals.
thanks
On 06.11.2024 11:34, IOhannes m zmoelnig wrote:
On 11/6/24 01:28, Alexandre Torres Porres wrote:
so it changes its look to show a draggable sidebar. Also, how is it aware that when reaching that sidebar it must show a different double sided arrow cursor?
honestly, i have no idea what you are talking about.
gmasdr IOhannes
pd-dev@lists.iem.at - the Pd developers' mailinglist
https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/X4C7PRUKKP6...
pd-dev@lists.iem.at - the Pd developers' mailinglist
https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/NQPF4AMLUGY...
Am 6. November 2024 17:56:32 MEZ schrieb Alexandre Torres Porres porres@gmail.com:
In order to know that Pd is in edit mode I do what I consider an ugly hack, which is listening to all canvas messages and filter the 'edit' message. I think it looks bad in the code and I wonder if there is a simpler way. Or if the way comment works is just something not exposed for externals. And I have the same inquiry for the cursor thing, if I can learn and apply the same mechanism for externals.
Getting the edit mode, should be easy enough: https://github.com/pure-data/pure-data/blob/c2d65103e5c068fa466260480b012ef03aed58a2/src/g_editor.c#L2254
But iirc, there's no proper way for an arbitrary object to receive mouse events while in edit mode. Everything you mentioned is hardcoded in Pd's editor itself.
And the "widgetbehaviour" API is really a prime example of bad design (with respect to extendibility), so it's not easy to change it to make more objects do something class-specific in edit mode, without cluttering rather unrelated code (g_editor), or - possibly - resorting to even uglier hacks
mfg.sfg.jfd IOhannes
Em qua., 6 de nov. de 2024 às 14:14, IOhannes m zmölnig zmoelnig@iem.at escreveu:
Getting the edit mode, should be easy enough: < https://github.com/pure-data/pure-data/blob/c2d65103e5c068fa466260480b012ef0...
hi, by printing on this code I see this can give me the edit status but not immediately when getting into edit mode. On the other hand, the comment box responds immediately to the edit status and shows the sidebar handle. This code does in fact listen to mouse events, so getting into edit mode via the keyboard shortcut is not enough, I have to move the mouse around and then I can see if it is in edit mode. Same is true for getting out of edit mode.
My 'hacky' way is to listen to canvas messages, and it works great, see [else/canvas.edit]. But I do wonder if there's a better way.
By the way, I'm always bothered by the fact that the cursor does not automatically change to a hand when getting into edit mode, we do need to move the mouse so it can be aware. I wonder if it's because it uses this 'canvas_doclick' function. Nonetheless, when getting out of edit mode, it goes back to the arrow cursor just fine. I will open an issue about this, I hope there is a way to listen to the edit status and make this transition better.
I now also remember and realize that the canvas window does report if it's in edit mode or not with "(edit)", I will try and see if I can find how this works in the code.
But iirc, there's no proper way for an arbitrary object to receive mouse events while in edit mode. Everything you mentioned is hardcoded in Pd's editor itself.
And the "widgetbehaviour" API is really a prime example of bad design (with respect to extendibility), so it's not easy to change it to make more objects do something class-specific in edit mode, without cluttering rather unrelated code (g_editor), or - possibly - resorting to even uglier hacks
I was just hoping to get the edit mode status really.
Other than that, I wanted to check how the comment box works and how all of it is coded on there.
I am actually able to do these things. See else/note for instance, but I wanted to be able to understand how this is done in Pd, maybe there is a better strategy.
thanks
I see that Pd changes its cursor to a straight up arrow when hovering with yout mouse over an object that takes clicks.
Is there a simple way for a GUI object to know if it's being hovered by a mouse?
I;m working on a GUI and it can also also show number values in different modes, I wonder if I can make it show a number when the mouse is on top of it.
thanks
Em sex., 8 de nov. de 2024 às 21:46, Alexandre Torres Porres < porres@gmail.com> escreveu:
Em qua., 6 de nov. de 2024 às 14:14, IOhannes m zmölnig zmoelnig@iem.at escreveu:
Getting the edit mode, should be easy enough: < https://github.com/pure-data/pure-data/blob/c2d65103e5c068fa466260480b012ef0...
hi, by printing on this code I see this can give me the edit status but not immediately when getting into edit mode. On the other hand, the comment box responds immediately to the edit status and shows the sidebar handle.
With the help of github's AI (copilot) and to the best of my knowledge, the *canvas_editmode* function in *g_editor.c* is what responds to the edit mode status change, and then it uses
text_drawborder(ob, x, rtext_gettag(y), rtext_width(y), rtext_height(y), 1);
to change how things are drawn if in edit mode or not.
I'm yet to better understand how setting cursor works, and I'm also thinking how to expanding this to iemguis, so they can also be resized in edit mode...
But first, I ask, could we have a simple function call to grab the edit status in external objects? My hacky to listen to canvas messages way works, but I was hoping for something better and easier, for everyone to use with externals. Something like a *"zoom"* message that we can receive.
What do you say?
cheers
Em qui., 19 de dez. de 2024 às 03:02, Alexandre Torres Porres < porres@gmail.com> escreveu:
I'm yet to better understand how setting cursor works, and I'm also thinking how to expanding this to iemguis, so they can also be resized in edit mode...
Ok, I see now this is taken care in canvas_doclick, which can set the cursor to "resize" in some cases. Things seem to be clearer now to me.
But I also see now that it's all quite hard coded into Pd and impossible to expand it to externals. A GUI external could benefit from setting another cursor, such as "bottom_side" for a custom dropmenu button, or "plus" to tell you that you can add a segment into an envelope generator, etc.
Using the *canvas_setcursor* function into a *w_clickfn* call doesn't work to override the cursor. I can't think of a simple solution like I did by suggesting a new "edit" message in my last email. Nonetheless, I think this would be a nice feature that it's worth discussing.
cheers
I see hcs/cursor is able to change and override the cursor. Will have a look at it...
Em qui., 19 de dez. de 2024 às 22:38, Alexandre Torres Porres < porres@gmail.com> escreveu:
Em qui., 19 de dez. de 2024 às 03:02, Alexandre Torres Porres < porres@gmail.com> escreveu:
I'm yet to better understand how setting cursor works, and I'm also thinking how to expanding this to iemguis, so they can also be resized in edit mode...
Ok, I see now this is taken care in canvas_doclick, which can set the cursor to "resize" in some cases. Things seem to be clearer now to me.
But I also see now that it's all quite hard coded into Pd and impossible to expand it to externals. A GUI external could benefit from setting another cursor, such as "bottom_side" for a custom dropmenu button, or "plus" to tell you that you can add a segment into an envelope generator, etc.
Using the *canvas_setcursor* function into a *w_clickfn* call doesn't work to override the cursor. I can't think of a simple solution like I did by suggesting a new "edit" message in my last email. Nonetheless, I think this would be a nice feature that it's worth discussing.
cheers
Em sex., 20 de dez. de 2024 às 14:26, Alexandre Torres Porres < porres@gmail.com> escreveu:
I see hcs/cursor is able to change and override the cursor. Will have a look at it...
The [cursor] object was a good way for me to investigate and find a solution, but it wasn't a solution in itself. It does change/overwrite the default cursors for Pd, but this strategy wasn't really working for me.
For the record, here is my finding: you can simply and easily change the cursor of a clickable GUI object by doing something like
pdgui_vmess(0, "^r rs", x->x_cv, "configure", "-cursor", "pirate");
in your "w_clickfn" function, where "x_cv" is the current canvas. By doing the above in my [knob] object, I get a cute pirate whenever I hover the mouse on top of it. As soon as the mouse button goes out of the knob area it restores to "normal" and it works as expected when hovering over a "bang" object or something. I wasn't expecting nothing this easy :)
With more sophistication, I think I can specify different cursors by checking the area that the mouse is hovering on, like being able to use a double horizontal arrow to resize the object. In Cyclone there was a much more complicated structure to do something like this for the old Scope~ object. We improved some things but the same structure was there and it involved creating a new "window" widget and... whatever... too complicated, I think I can simplify this much more now and will do the same for my ELSE objects. I will report back if I don't succeed or something.
As for the 'edit mode' status awareness, I have my old solution and haven't found any better new solution and I might open a feature request soon proposing an "edit" message (much like the "zoom" message) to send to objects. If you think I shouldn't bother with that suggestion for some reason, let me know.
cheers
Hence, Pd has hardcoded
Em qui., 19 de dez. de 2024 às 22:38, Alexandre Torres Porres < porres@gmail.com> escreveu:
Em qui., 19 de dez. de 2024 às 03:02, Alexandre Torres Porres < porres@gmail.com> escreveu:
I'm yet to better understand how setting cursor works, and I'm also thinking how to expanding this to iemguis, so they can also be resized in edit mode...
Ok, I see now this is taken care in canvas_doclick, which can set the cursor to "resize" in some cases. Things seem to be clearer now to me.
But I also see now that it's all quite hard coded into Pd and impossible to expand it to externals. A GUI external could benefit from setting another cursor, such as "bottom_side" for a custom dropmenu button, or "plus" to tell you that you can add a segment into an envelope generator, etc.
Using the *canvas_setcursor* function into a *w_clickfn* call doesn't work to override the cursor. I can't think of a simple solution like I did by suggesting a new "edit" message in my last email. Nonetheless, I think this would be a nice feature that it's worth discussing.
cheers
I spoke too soon...
What I described works great for clicking while in run mode, and I needed that for some cases indeed. On the other hand, something resizing requires "edit mode" and things don't work like that in this case :) w_clickfn is just for run mode... but I know that objects in Pd like comment and atom boxes are aware of where you're hovering the mouse in edit mode and this is my next step in my investigation journey...
Em sex., 20 de dez. de 2024 às 18:09, Alexandre Torres Porres < porres@gmail.com> escreveu:
Em sex., 20 de dez. de 2024 às 14:26, Alexandre Torres Porres < porres@gmail.com> escreveu:
I see hcs/cursor is able to change and override the cursor. Will have a look at it...
The [cursor] object was a good way for me to investigate and find a solution, but it wasn't a solution in itself. It does change/overwrite the default cursors for Pd, but this strategy wasn't really working for me.
For the record, here is my finding: you can simply and easily change the cursor of a clickable GUI object by doing something like
pdgui_vmess(0, "^r rs", x->x_cv, "configure", "-cursor", "pirate");in your "w_clickfn" function, where "x_cv" is the current canvas. By doing the above in my [knob] object, I get a cute pirate whenever I hover the mouse on top of it. As soon as the mouse button goes out of the knob area it restores to "normal" and it works as expected when hovering over a "bang" object or something. I wasn't expecting nothing this easy :)
With more sophistication, I think I can specify different cursors by checking the area that the mouse is hovering on, like being able to use a double horizontal arrow to resize the object. In Cyclone there was a much more complicated structure to do something like this for the old Scope~ object. We improved some things but the same structure was there and it involved creating a new "window" widget and... whatever... too complicated, I think I can simplify this much more now and will do the same for my ELSE objects. I will report back if I don't succeed or something.
As for the 'edit mode' status awareness, I have my old solution and haven't found any better new solution and I might open a feature request soon proposing an "edit" message (much like the "zoom" message) to send to objects. If you think I shouldn't bother with that suggestion for some reason, let me know.
cheers
Hence, Pd has hardcoded
Em qui., 19 de dez. de 2024 às 22:38, Alexandre Torres Porres < porres@gmail.com> escreveu:
Em qui., 19 de dez. de 2024 às 03:02, Alexandre Torres Porres < porres@gmail.com> escreveu:
I'm yet to better understand how setting cursor works, and I'm also thinking how to expanding this to iemguis, so they can also be resized in edit mode...
Ok, I see now this is taken care in canvas_doclick, which can set the cursor to "resize" in some cases. Things seem to be clearer now to me.
But I also see now that it's all quite hard coded into Pd and impossible to expand it to externals. A GUI external could benefit from setting another cursor, such as "bottom_side" for a custom dropmenu button, or "plus" to tell you that you can add a segment into an envelope generator, etc.
Using the *canvas_setcursor* function into a *w_clickfn* call doesn't work to override the cursor. I can't think of a simple solution like I did by suggesting a new "edit" message in my last email. Nonetheless, I think this would be a nice feature that it's worth discussing.
cheers
I can't say that I've read all the code involved, but with what I know of both of pd externals (somewhat, but I'm no expert) and programming in TCL (pushing on 30 years), the way I'd do this in terms of architecture would be too have most of the work being done in TCL, and only communicate the data back to pd at important save points - at least for pure rendering work. Obviously audio parameters need to be more tightly coupled, even in edit mode.
My point being, something like a widget resize most likely gets handled entirely on the TCL side. Certainly a lot of it *must* be handled in TCL, so you're really going to have to work it from that end to get to a good answer. PD really only knows what the TCL code tells it.
Just my $0.02 worth, but I have run into similar issues when I've wanted to make gui things happen. Show quoted text
On Fri, 20 Dec 2024, 21:25 Alexandre Torres Porres, porres@gmail.com wrote:
I spoke too soon...
What I described works great for clicking while in run mode, and I needed that for some cases indeed. On the other hand, something resizing requires "edit mode" and things don't work like that in this case :) w_clickfn is just for run mode... but I know that objects in Pd like comment and atom boxes are aware of where you're hovering the mouse in edit mode and this is my next step in my investigation journey...
Em sex., 20 de dez. de 2024 às 18:09, Alexandre Torres Porres < porres@gmail.com> escreveu:
Em sex., 20 de dez. de 2024 às 14:26, Alexandre Torres Porres < porres@gmail.com> escreveu:
I see hcs/cursor is able to change and override the cursor. Will have a look at it...
The [cursor] object was a good way for me to investigate and find a solution, but it wasn't a solution in itself. It does change/overwrite the default cursors for Pd, but this strategy wasn't really working for me.
For the record, here is my finding: you can simply and easily change the cursor of a clickable GUI object by doing something like
pdgui_vmess(0, "^r rs", x->x_cv, "configure", "-cursor", "pirate");in your "w_clickfn" function, where "x_cv" is the current canvas. By doing the above in my [knob] object, I get a cute pirate whenever I hover the mouse on top of it. As soon as the mouse button goes out of the knob area it restores to "normal" and it works as expected when hovering over a "bang" object or something. I wasn't expecting nothing this easy :)
With more sophistication, I think I can specify different cursors by checking the area that the mouse is hovering on, like being able to use a double horizontal arrow to resize the object. In Cyclone there was a much more complicated structure to do something like this for the old Scope~ object. We improved some things but the same structure was there and it involved creating a new "window" widget and... whatever... too complicated, I think I can simplify this much more now and will do the same for my ELSE objects. I will report back if I don't succeed or something.
As for the 'edit mode' status awareness, I have my old solution and haven't found any better new solution and I might open a feature request soon proposing an "edit" message (much like the "zoom" message) to send to objects. If you think I shouldn't bother with that suggestion for some reason, let me know.
cheers
Hence, Pd has hardcoded
Em qui., 19 de dez. de 2024 às 22:38, Alexandre Torres Porres < porres@gmail.com> escreveu:
Em qui., 19 de dez. de 2024 às 03:02, Alexandre Torres Porres < porres@gmail.com> escreveu:
I'm yet to better understand how setting cursor works, and I'm also thinking how to expanding this to iemguis, so they can also be resized in edit mode...
Ok, I see now this is taken care in canvas_doclick, which can set the cursor to "resize" in some cases. Things seem to be clearer now to me.
But I also see now that it's all quite hard coded into Pd and impossible to expand it to externals. A GUI external could benefit from setting another cursor, such as "bottom_side" for a custom dropmenu button, or "plus" to tell you that you can add a segment into an envelope generator, etc.
Using the *canvas_setcursor* function into a *w_clickfn* call doesn't work to override the cursor. I can't think of a simple solution like I did by suggesting a new "edit" message in my last email. Nonetheless, I think this would be a nice feature that it's worth discussing.
cheers
pd-dev@lists.iem.at - the Pd developers' mailinglist
https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/T24UL3LJQKX...
Em sex., 20 de dez. de 2024 às 18:54, Day Rush kumoyuki@gmail.com escreveu:
My point being, something like a widget resize most likely gets handled entirely on the TCL side. Certainly a lot of it *must* be handled in TCL, so you're really going to have to work it from that end to get to a good answer. PD really only knows what the TCL code tells it.
Oh, definitely, sure! And I know of a solution already for handling resizing in edit mode from Cyclone, as I pointed. I'm just now finally diving into tcl/tk and trying to better understand how to handle it in Pd and looking for better and easier solutions. I made progress already in handling cursor management in run mode, but I'm afraid it won't be easier than the Cyclone solution for edit mode though :/ again, this involves creating a new window widget that you can assign a cursor to.
Clicking on the object in edit mode and working with it is also happening in cyclone/comment by the way, and there's lot's of tcl/tk code in there, but managing cursor change for a resize operation does not seem trivial without creating a window so far. Certainly not as trivial as doing it for the run mode as I was able to find out.
anyway, thanks for the input
-
Alexandre Torres Porres -
Christof Ressi -
Day Rush -
IOhannes m zmoelnig -
IOhannes m zmölnig