[PD] Re: [PD-dev] Draft Templates for PD reference Files
ben at ekran.org
Tue May 17 20:51:07 CEST 2005
I took a look at the prototype in CVS. This is an amazing start.
The compile worked fine on OSX, though I could only get pddplink to open
.pd files. Do the tcl scripts need to be sourced into the PD tcl
When using a URL OR a PDF or image file as an argument I get the error:
pddpclient: open sh -c open http://www.ekran.org
Error in pddpclient: Usage: open [-e] [-a <appname>] [filenames]
Help: Open opens files from a shell.
By default, opens each file using the default application for
If the file is in the form of a URL, the file will be open
"open http://www.ekran.org" works in the terminal, but "open sh -c open
http://www.ekran.org" seems very badly interpreted "no such file '~/-c' "
Personally I think this system would be fine to be included by default
in PD. What is the benifit of it being optional?
I could start working on the visual appearance of the link, if you would
like a hand. Plain tcl/tk should be fine?
Funny you did all this a week ago, nice to know our thoughts are inline!
Let me know if you could like a contribution of visual tk code to the link.
Krzysztof Czaja wrote:
> hi Ben,
> B. Bogart wrote:
>> screen-space the links take up. Krzysztof where are you in terms of the
>> design of the hyperlink? I see a few different things it would be great
> I have already committed a prototype to cvs (source in miXed/pddp,
> test stuff in miXed/test/pddp). That was a week ago (have not
> looked at it since then, though).
> The external, pddplink, seems to work here after plain "make" in
> miXed/pddp. Either "miXed/bin" should be a part of the Pd path,
> or, if the dll is to be `installed' to some other place, the three
> tcl scripts: pddpboot.tcl, pddpclient.tcl, and pddpserver.tcl,
> will have to go there as well.
> Eventually, the proper place for those scripts would need to be
> pd.tk, or, even better, they would make a separate package
> required or sourced at Pd startup.
> The pddplink may be instantiated as [pddplink localpatch.pd].
> When clicked at, it will directly open localpatch.pd in a new
> window. Until it is clicked at, there is no localpatch in memory.
> It may be instantiated as [pddplink whatever.notapatch]. When
> clicked at, it will pass to a web browser the local link
> It may be instantiated as [pddplink anyscheme://whatever.notapatch].
> When clicked at, it will pass to a web browser the link, global
> or local, "anyscheme://whatever.notapatch".
> By default, the object has no inlet and no outlet. What remains
> to be done, is designing its default appearance: no selector, no
> box, distinct color, another color when pointed at, mouse pointer
> shape, etc.
> It may be instantiated with a second argument (possibly more in
> future), which controls the object's appearance. Currently,
> the only recognized value is "box". A boxed pddplink has one
> inlet and one outlet.
> Since back-linking from html to pd is handled by pddpserver, it
> works only for local patches, and only through the
> "http://localhost:<port>", not through the "file://" (no way,
> until Pd is mime association-friendly, which it probably never
> will be). The main drawback is that for back-links to work,
> a user has to start browsing from Pd.
>> * HTML / PDF documents Locally
>> * HTML / PDF documents Remotely
>> * PD files (all_about & -help & -example patches)
> PD-dev mailing list
> PD-dev at iem.at
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 256 bytes
Desc: OpenPGP digital signature
More information about the Pd-dev