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

> From: Mathieu Bouchard <ma...@artengine.ca>
> To: Jonathan Wilkes <jancs...@yahoo.com>
> Cc: Roman Haefeli <reduz...@gmail.com>; "pd-list@iem.at" <pd-list@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
> 

_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Reply via email to