Hey Hans,

Thanks for taking a look at the templates, I was very much looking forward to your feedback. Ok so comments inline...

Hans-Christoph Steiner wrote:

How about a standard subpatch called something like [pd PDDP_META_DATA]? Then the CATEGORY and KEYWORDS comments would go in there.

GREAT IDEA! Since this part is largely for software parsing we should give it a short simple name [pd META] A logical place for meta-data of the future to go (if there is a future for patches as documents!).

I think they should be as tight as possible so that the help take up as little screen space as possible while keeping the important content there. So for example, get rid of the "HELP: float" line, and just have the [float] line there instead.

Ok, I'm working on template-6 with [pd META] and removed the top line.

We should also come up with standard links/subpatches. For example, I don't know whether each help patch needs a [pd Related Objects] subpatch. The all_about_* patches could have that info. I think that the [pd More Info] subpatch is definitely not necessary, that would be in the all_about_* patch. I think a better standard link to have would be float-examples.pd, with -examples being a standard extension. There could then be an index of -examples.pd patches.

Yes, Actually I realized that the "hyperlink" that Krzysztof is working on should cover the whole idea of "linking" rather than GOP abstractions with arguments. If for no better reason to reduce clutter and the 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 to link to: (Should I put up a wiki page for this?)

• HTML / PDF documents Locally
• HTML / PDF documents Remotely
• PD files (all_about & -help & -example patches)

What do you think Krzysztof?

To make the connection between the -help, -example and all_about (how about -about? Same bonus of sorting) A structure for all_abouts is required, so the links are not all over the place. In the worst case each patch to link to all others. For example I thought float should link to "all_about_data-types" but all_about_math or all_about_numbers, even all_about_guis could be as important (more?). So I propose three extensions for "doc" patches:

*-help.pd for reference patches *-example.pd for example patches *-about.pd for all_about patches.

My vote is for 4 or 5. I think 4 is a bit tighter, but 5 will have more room to link to other patches.

Ok, I've based template-6 on template-5. Seemed the fav of those (few) who commented.

As for all_about_ patches, I think it should be a different format. The current two column format works pretty well, I think, with some fine tuning.

I agree that the format should be different, but similar. I'll get on this after a good start for -help patches. I agree that two columns is the way to go, using some ques from the -help template.

Ok, I'm going to wiki some of this and put up template-6

B>

.hc

On May 9, 2005, at 1:18 PM, B. Bogart wrote:

...

Hey all,

I've added a 4th template to the wiki for PD reference files:

http://puredata.org/Members/bbogart/DraftReferenceDesigns

"Template 4" is an altered version of Template 3 incorporating the comments from the gridflow folks.

Please take a visit and post your comments!

B> _______________________________________________ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev

---

---

              ¡El pueblo unido jamás será vencido!

---

---

PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev

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

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

On May 20, 2005, at 6:15 AM, Krzysztof Czaja wrote:

Hans-Christoph Steiner wrote: ...

...

...

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?

yes, it would make customizing of pd-gui much easier, and it could somewhat improve robustness of gui externals. If the purpose of such a directory is customizing and extending locally (per user or per site), it will never be overwritten with new Pd installs.

If people want to make their own extensions, then we'd need to have a
-path config option for this location as well, so that the user could
specify one.

Another thing is splitting pd.tk, which is already too big, and it might not survive adding more features by random patching. This is a typical case of a permanently makeshift code... perhaps, time to decide one way or the other about Tk, after all these years?

There are definitely a number of things that need to be cleaned up in
pd.tk. In particular, I've been wanted to redo the whole menu/key
commands system for a while. It would greatly simplify tailoring Pd to
be as native as possible on each platform.

...

...

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

might even work passing 0 to "socket", although I vaguely remember reading about an os where this causes troubles. So, it currently starts from 8080, and goes on incrementing until there is a free port. I think, the range of well-knowns is 0-1023, registered range is up to 49151, should we start from 49152, then? ...

Sounds good.

...

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

sadly, I have never used osx... so I wonder, does it support running multiple Pd instances? Is the association made by your installer, or by (each user's) hand?

The tcl-mac people have handled this quite well. With the AppMain.tcl
method of building a Mac OS X .app. A .app is a directory layout for
an encapsulated application, everything is included in a folder
ApplicationName.app, which then appears as a double-clickable
application. Mac OS X reads a property list from within each .app to
see which file types that .app supports, what its application and file
icons are, the name, version, etc. etc.

All that you have to do is copy a .app to your computer, and Mac OS X
will register that information from that .app's property list. That
means you can have as many copies of Pd running as you have copies of
Pd on your hard drive. But it automatically prevents you from starting
a copy of the same .app.

This is why building the Pd.app was so worth all of the effort. Pd now
behaves very much like a native Mac OS X app.

.hc

                         http://at.or.at/hans/

Hey,

I like the idea of the pd.tk sourceing from a directory for tcl/tk code. Great idea HC. I've not taken a good look at pd.tk in some time, but I can't recall it being easy to go through. Any counter arguments to doing this?

pd.tk also sounds like it would need to be done eventually. Is anyone working on this? Design ideas?

As for the toolkit thing I'm curious how other toolkits relate in terms of widget types and so on. I know tk can be used by other languages, but can tcl bind with other toolkits?

I'm imagining that tk specific calls could be wrapped by PD functions. If we change the toolkit then one would only need to change the implimentation in these functions but the higher-level stuff would be left intact. That is IF there is enough similarity between toolkits.

Based on IX's posts it seems to me that tk is finally starting to move in the right direction... (the GL acceleration is particularly interesting)

B.

Krzysztof Czaja wrote:

yes, it would make customizing of pd-gui much easier, and it could somewhat improve robustness of gui externals. If the purpose of such a directory is customizing and extending locally (per user or per site), it will never be overwritten with new Pd installs.

Another thing is splitting pd.tk, which is already too big, and it might not survive adding more features by random patching. This is a typical case of a permanently makeshift code... perhaps, time to decide one way or the other about Tk, after all these years?

Krzysztof

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list