If you do a tutorial, I’m happy to be your commenting guinea pig / test student.
A basic one can use pdgui_vmess but advanced stuff that stores data on the tk side (like your pic and both my objects) will need to stick to sys_vgui, according to claude.ai - now that is an unreliable source but hey, it says that to keep access to actual TK (arrays, textures, pictures, etc) we need to stay in the dirty land of sys_vgui
So tutorial in 2 parts: make an easy gui (button or a clickable label like in SC) are good contenders; then how to poweruse TK (like your pic object which has a rect with a filler file loaded once and not every redraw but needs to be aware to scale/redraw/delete etc)
In all cases, I’m a good critical student :) send along and I’ll let you know everything I don’t understand.
On 22 Aug 2025, at 18:32, Alexandre Torres Porres porres@gmail.com wrote:
I'm up for writing a tutorial, which could be an appendix for the manual. Only problem is I'm not really knowledgeable :) I'm still struggling in getting GUI objects right and I've come a long way since that last preliminary [pad] object. The one I'm really working on is [knob], which became a monster. It's a big priority of mine to finally get all my GUI objects really done, with properties and everything. I've been working a lot on [button] recently, which is still much simpler than [knob]. It's a good time for me to get to the bottom of this. Let me know if I can help testing the issue with my objects. I'd be glad to inject a lot of comments on them so they become a good template model.
But to be honest, one thing I'm still not really sure is about managing the canvas and glist. I think I'm doing silly things and I was working on getting it right quite recently.
Anyway, one thing I learned the hard way is that it's best to not completely erase and redraw the object when messing with it. Not sure if that's what I do with [pad], but if so, I should change it! It's just better to adapt and resize/configure the object accordingly. Then only erase and draw at the "vis" method. I know I was doing that before because it just seemed simpler.
I need to find a similar tutorial to move away from the deprecated ‘sys_vgui’ towards 'pdgui_vmess()’…
Oh yeah, and I also have to work on the code to completely move towards 'pdgui_vmess'. I've started that already. I think I'm getting a good gist of it.
cheers
Em qui., 21 de ago. de 2025 às 03:48, Pierre Alexandre Tremblay <tremblap@gmail.com mailto:tremblap@gmail.com> escreveu:
Thanks for coming back at me Alexandre… I know what you do, I learnt from your code :)
I was just surprised to not be able to get a clear state. What I do is delete stuff when it is not printed. I get bugs of trying to delete stuff that doesn’t exist if the flags are not accurate (that was a bug sent by a user - it might happen with your object too, or not, I didn’t recompile your [pad] to read its flags but I don’t see you updating them. Maybe I should compile pad to see the flag status when a subpatch window is opened at load time - if your flags differ from mine, I’d doing something wrong…
I’ll see if I can find a single GUI to compile with no dependencies, that is the tutorial I dream of, a following to the very streamlined tutorial in the vanilla distribution
p
On 21 Aug 2025, at 01:34, Alexandre Torres Porres <porres@gmail.com mailto:porres@gmail.com> wrote:
Not sure what you're facing, but when I need to update a GUI I just check for both and do things when both flags are true... but I never bothered to go deeper, it just works for me. What exactly is your problem?
cheers
Em qua., 20 de ago. de 2025 às 08:49, Pierre Alexandre Tremblay <tremblap@gmail.com mailto:tremblap@gmail.com> escreveu:
… which makes me think that I need to find a similar tutorial to move away from the deprecated ‘sys_vgui’ towards 'pdgui_vmess()’… yet as I use arrays and other data structures in the TK, I feel it might require a full refactor...
Again pointers welcome again
On 20 Aug 2025, at 13:34, Pierre Alexandre Tremblay <tremblap@gmail.com mailto:tremblap@gmail.com> wrote:
Hello
Thanks for this. Sadly, that flag stays 1 when the [pd] subpatch window containing my GUI is closed. I must be missing something.
What is the simplest GUI source code I can read, ideally with loads of comments, to see the best practices? At the moment, when the subpatcher window is closed its ‘pdtk_canvas' is destroyed ("pd -d 5” helped a lot to understand the ‘dance’)…
To reiterate:
- glist_isvisible() is 0 when subpatcher is opened
- gobj_shouldvis() is always on, subpatcher opened or not
Thanks all and sorry for the newb questions!
On 20 Aug 2025, at 00:13, Miller Puckette via Pd-list <pd-list@lists.iem.at mailto:pd-list@lists.iem.at> wrote:
It's my belief that gobj_shouldvis() is true if the object should be visible on the screen, and that glist_isvisible() is on if the glist has actually been drawn (which is not yet true while the glist is first being drawn). So I think you should check gobj_shouldvis() and not glist_isvisible().
cheers Miller
On 8/19/25 12:06 PM, Pierre Alexandre Tremblay wrote: > Hello > > I am struggling with a real understanding of when to redraw my 2 flucoma GUI objects. At the moment, I get them to behave most of the time… > > Tldr: why is glist_isvisible 0 when a window hosting my gui is in the background at load time? > > Any help/good practice/tutorial welcome. > > p > > === > > The long read: > > At the moment I check the status of glist_isvisible && gobj_shouldvis and print when both are on (&& vis flag of my own object) > > It works all the time, except: > > 1. When I load the patch saved with a [pd patcher] with the gui on (that window opens, but the gui doesn’t draw, by opposition to native ones) > > 2. When I close that subpatch window and reopen it, it is not drawn. > > 3. When I zoom in/out > > In both cases it calls my _draw method but the flag glist_isvisible is 0 (with the added ‘fun’ of calling the draw function twice when I zoom in or out, once with the flag 1 and right after with the flag 0 > > What have I done wrong? The source code is online, I can send a link…. > > > > --- > pd-list@lists.iem.at mailto:pd-list@lists.iem.at - the Pure Data mailinglist > https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-list@lis... > > To unsubscribe send an email to pd-list-leave@lists.iem.at mailto:pd-list-leave@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> https://urldefense.com/v3/__https://lists.iem.at/__;!!Mih3wA!BBIsbtoRUuYYTra...
pd-list@lists.iem.at mailto:pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/LPJGGHQ7PH...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailto:pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
pd-list@lists.iem.at mailto:pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/ZU5OPWAWD5...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailto:pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
pd-list@lists.iem.at mailto:pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/4BJPTZYAE4...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailto:pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/