[L2Ork-dev] gui port

[Jonathan Wilkes]

Btw-- with this particular issue, wouldn't it be best to just have a function in m_pd.h for opening an external doc?  That function could then just do a call to the gui (or do nothing if in nogui mode). 
That way Pd Vanilla could add the same functionality where they wrap a tcl call.
-Jonathan    On Thursday, June 23, 2016 11:32 AM, Jonathan Wilkes <jancsika at yahoo.com> wrote:
 

 > On Thursday, June 23, 2016 3:17 AM, Albert Graef <aggraef at gmail.com> wrote:
 



 > On Thu, Jun 23, 2016 at 12:23 AM, Jonathan Wilkes <jancsika at yahoo.com> > wrote:

Yes, but I'd rather not index the entire thing.

> Why not? You only need to index the *-help.pd patches. There are 2455 of > those in extra. If scanning these on every startup is too slow, the help > browser could have a button to only run the indexing on demand. 
It will certainly be slower, but we can easily cache the index.
The problem is that there two types of subdirectories inside "extra":a) external libraries, in the sense of most other programming languagesb) abandoned cloud storage of early Pd users that we keep to maintainbackwards compatibility
I don't want the cloud storage cruft to show up in the search results.  Or, if it does, I want it at the very bottom of the list.  Maybe a PDDP tag of "deprecated" can help with this.

I'd like to choose only those 
libs which are being actively (and sustainably) maintained to show up in 
the search results.

> My take on this is that if an external is included in the package then its > documentation should be accessible, no matter in what state it is. A bad help > patch is still better than none at all. Right now I have to search for the > external help patches with File/Open which is a workable solution but > inconvenient.
 

It might also be nice to have links to the manual and other popular starting 
points by default.


> Yes, that would be nice!
 

Once I'm in beta I'll get more rigorous about the debug messages.


> Ok, that's fair.
 

> Jonathan, does sys_vgui() let me execute JavaScript code in purr-data? 
No. sys_vgui can only print its old tcl string to the console.


> Ok, but surely there's a way to invoke exported functions from pdgui.js et al > from Pd's internals? Maybe that C routine could be exposed in m_pd.h until a > proper external GUI API is crafted?
Yes:https://git.purrdata.net/jwilkes/purr-data#gui-messaging-specification

You can use that API to talk to the GUI.  But just keep in mind that any of the js functions you call could change at will.


Well, right now I'm just cheating and adding specific code to pdgui.js for 
handling gui external classes like Scope~.  I'm leaving the external GUI 
API question for a later time.

> The JS routines I need are already there; external_doc_open is all I need. I > just need a way to invoke that routine from C code. If that's not possible then > I'll have to work around that somehow, but I really need that functionality in > my Pure and Faust externals.
The "public" functions all have the prefix "gui", but there is currently nothing technical that is stopping you from calling external_doc_open directly.
There is also gui_pddplink_open.  I could rename that and change the error message to generalize it.  Still, keep in mind it is unstable.
-Jonathan

 
Albert

-- 
Dr. Albert Gr"af
Computer Music Research Group, JGU Mainz, Germany
Email:  aggraef at gmail.com
WWW:    https://plus.google.com/+AlbertGraef

   

  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20160623/6d31fd0e/attachment-0001.html>