[PD] <<Loaded>> virtual event

Jonathan Wilkes jancsika at yahoo.com
Tue Feb 21 01:10:06 CET 2012


----- Original Message -----

> From: Mathieu Bouchard <matju at artengine.ca>
> To: Jonathan Wilkes <jancsika at yahoo.com>
> Cc: Roman Haefeli <reduzent at gmail.com>; "pd-list at iem.at" <pd-list at iem.at>
> Sent: Monday, February 20, 2012 6:34 PM
> Subject: <<Loaded>> virtual event
> 
> Le 2012-02-20 à 13:54:00, Jonathan Wilkes a écrit :
> 
>>  And it doesn't quite work.  The <<Loaded>> virtual event 
> will trigger before Tk is actually finished drawing the patch window.
> 
> Well, there are four possible distinct meanings of « finished loading » that 
> could be helpful :
> 
> 1. the patch has finished loading in the «server»... the t_canvas objects have 
> been created, their subobjects have been loaded if they're stored in files, 
> the .x76543210 receive symbols exist, so Tk can send to them. [initbang] has 
> been run (some dynamic patching depends on it).
> 
> 2. [loadbang] has also finished running. This means that all the rest of the 
> load-time dynamic patching is done, and the patch's own init has all been 
> run, so that you can start using the patch for real.
> 
> 3. all the sys_queuegui() calls related to this toplevel canvas have been done, 
> and all sys_gui() calls have already gone through the sendbuf, the TCP 
> connection, and have been eval'd. This means that all the Tk Canvas Items 
> have been created, so that you can send to them, make stats about them, query 
> their info, etc.

Hm...
I could ameliorate the problem by setting a minimum value for the -wraplength of the 
tk label for the tooltip.  If I set it to be at least 150 pixels  then it would at least be 
guaranteed to be legible for loadbanged tooltips (if unnecessarily scrunched for longer 
tips).  This means that part of the tip could potentially be hidden in patches narrower 
than 150 pixels, but if your patch is narrower than 150 pixels chances are other things 
are hidden, too.  Not great but I can't think of another workaround.

-Jonathan

> 
> 4. All the stuff drawn in step 3 has appeared in the framebuffer of the 
> videocard. This means that it's read to use a screenshot tool such as [#in 
> x11] or gnome-screenshot.
> 
> I think that there are different uses for each of those levels. For my 
> patch_dans_patch picture series, I would have liked some kind of object that 
> would have told me that everything has been drawn on the screen, but this would 
> require a (very small) change to Tk itself, AFAIK.
> 
>>  If I send the message to create the tip manually, after the patch has 
> finished loading, it displays fine.
> 
> The fact that you wait for it to appear on the screen, makes it a level 4 
> notification.
> 
> What you need for the tooltip to work is probably a level 3 notification.
> 
> What is available now in pd43 is a level 2 notification, afaik.
> 
> I don't have examples of uses of level 1 notifications, but I feel like 
> there are. But I don't think that it's strictly necessary to implement 
> this level, because it's quite close to level 2. I think that levels 2,3,4 
> are much more useful.
> 
> ______________________________________________________________________
> | Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
> 



More information about the Pd-list mailing list