-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On May 17, 2005, at 7:01 AM, 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.
Works as promised. Very nice.
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.
How about if there was a directory like "lib", where every .tcl or .tk file in there would be sourced by Pd at 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.
First a quick comment: 8080 is a commonly used port. How about we use a high 5-digit port number? That would prevent conflicts. It could be something like your birthday (maybe). I used 10473 and 42773 as port numbers, both birthdays. Ideally it would be something that nothing else uses by default.
Also, mime associations work well with the Pd.app on Mac OS X so file:// links would work no problem on Mac OS X. I use them all of the time now. There is only one bug in it AFAIK: if Pd is not running when you open a .pd file, that .pd file will be loaded before any externals libraries.
pddplink got me thinking. It would be really nice to have inline links in text in a Pd patch. So if [pddplink] and [comment] were combined, then we could have formattable text with inline links. Brackets could make the links to Pd patches, since that's already a de facto standard for Pd. Any URI would be handed to the browser. Probably not a simple task, but a worthy goal I think.
.hc
Krzysztof
...
- HTML / PDF documents Locally
- HTML / PDF documents Remotely
- PD files (all_about & -help & -example patches)
________________________________________________________________________ ____
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore