[PD] Re: [PD-dev] Draft Templates for PD reference Files

[B. Bogart]

Hey Krzysztof,

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
interpreter?

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
that file.
       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.

B.

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
> "http://localhost:<port-of-pddpserver>/whatever.notapatch".
>
> 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.
>
> Krzysztof
>
> ...
>
>> * HTML / PDF documents Locally
>> * HTML / PDF documents Remotely
>> * PD files (all_about & -help & -example patches)
>
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20050517/a71f4caf/attachment.pgp>