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@iem.at http://lists.puredata.info/listinfo/pd-dev