I don't know if I mentioned this before, but most of the PDDP patches are a work in progress. I have just been joting down notes as I think of them. There are a couple good examples. all_about_hid.pd is a good example of what I think an "all_about" patch should look like. But basically, I have put in little effort into formatting them nicely because I wanted to define the styles first.
If anyone is interested, it'd be great if we could work together to create the style guides. The way I currently see it there are two kinds of patches "all_about_" which has lots of text and examples, and the basic help patch, which should be a reference with a link to the relevant "all_about_" pages. float-help.pd from PDDP is a decent example of a reference patch.
As usual, the cross-platform font issue is a bitch. Ideally, we'd reduce the Mac OS X font size, so that it'd be closer to the other platforms.
.hc ________________________________________________________________________ ____
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
As usual, the cross-platform font issue is a bitch. Ideally, we'd reduce the Mac OS X font size, so that it'd be closer to the other platforms.
Your font size is perfect on (my) Linux/X, too, so it's "just" Windows, that's out of proportion.
Ciao
On Apr 29, 2005, at 10:01 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
As usual, the cross-platform font issue is a bitch. Ideally, we'd reduce the Mac OS X font size, so that it'd be closer to the other platforms.
Your font size is perfect on (my) Linux/X, too, so it's "just" Windows, that's out of proportion.
IIRC, the font is different on each platform. On Windows its too small, on XWindows, its just right, on MacOS X, its too big. Try "4.fft.examples/05.sheepgoat.pd, Here's an screenshot from MacOSX
https://puredata.org/Members/hans/downloads/05.sheepgoat.pd-MacOSX.png
.hc
________________________________________________________________________ ____
"[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
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
IIRC, the font is different on each platform. On Windows its too small, on XWindows, its just right, on MacOS X, its too big. Try "4.fft.examples/05.sheepgoat.pd, Here's an screenshot from MacOSX
https://puredata.org/Members/hans/downloads/05.sheepgoat.pd-MacOSX.png
Hm, time to switch to "Bitstream Vera Sans Mono" in Pd. ;)
Ciao
Hey HC,
you are right that they are all different. Seems to me that OSX and Linux are quite similar, whereas windows is quite a bit further off. I did not even notice the difference netween linux and OSX without staring!
Ok, what is the solution to this? (which sure sticks for PDDP templates, as the float-help.pd "current" template is a mess on OSX. :(
B>
Hans-Christoph Steiner wrote:
On Apr 29, 2005, at 10:01 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
As usual, the cross-platform font issue is a bitch. Ideally, we'd reduce the Mac OS X font size, so that it'd be closer to the other platforms.
Your font size is perfect on (my) Linux/X, too, so it's "just" Windows, that's out of proportion.
IIRC, the font is different on each platform. On Windows its too small, on XWindows, its just right, on MacOS X, its too big. Try "4.fft.examples/05.sheepgoat.pd, Here's an screenshot from MacOSX
https://puredata.org/Members/hans/downloads/05.sheepgoat.pd-MacOSX.png
.hc
"[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
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Yeah I agree, it is windows that is the odd one out, patches look fine between linux and OSX.
I'll tinker with PDDP style sometime today I think...
B>
Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
As usual, the cross-platform font issue is a bitch. Ideally, we'd reduce the Mac OS X font size, so that it'd be closer to the other platforms.
Your font size is perfect on (my) Linux/X, too, so it's "just" Windows, that's out of proportion.
Ciao
Hans-Christoph Steiner hans@eds.org writes:
If anyone is interested, it'd be great if we could work together to create the style guides. The way I currently see it there are two kinds of patches "all_about_" which has lots of text and examples, and the basic help patch, which should be a reference with a link to the relevant "all_about_" pages. float-help.pd from PDDP is a decent example of a reference patch.
I have volunteered to work on the pddp project some years ago and have subsequently sort of fell out of the loop... But I want to redeem myself and get back on board. I could continue the work i started then, which is documenting MIDI related externs. The float-help.pd style is indeed what has been decided at some point. i have in fact update some of the MIDI help files to the new style, I have them on my computer that they don't seem to be in the CVS. Perhaps i have never submitted them?
Anyways, I'm in.
./MiS
On Apr 30, 2005, at 11:25 AM, Michal Seta wrote:
Hans-Christoph Steiner hans@eds.org writes:
If anyone is interested, it'd be great if we could work together to create the style guides. The way I currently see it there are two kinds of patches "all_about_" which has lots of text and examples, and the basic help patch, which should be a reference with a link to the relevant "all_about_" pages. float-help.pd from PDDP is a decent example of a reference patch.
I have volunteered to work on the pddp project some years ago and have subsequently sort of fell out of the loop... But I want to redeem myself and get back on board. I could continue the work i started then, which is documenting MIDI related externs. The float-help.pd style is indeed what has been decided at some point. i have in fact update some of the MIDI help files to the new style, I have them on my computer that they don't seem to be in the CVS. Perhaps i have never submitted them?
Anyways, I'm in.
Yeay! The more, the merrier. Please submit any patches that you have to CVS (doc/pddp).
.hc
./MiS
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
"If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it."
- Thomas Jefferson
Hans-Christoph Steiner hans@eds.org writes:
Yeay! The more, the merrier. Please submit any patches that you have to CVS (doc/pddp).
The only thing that I have is a few of the MIDI help patches reformatted according to the float-help.pd model. Otherwise everything else (prior to deciding on the new format) is already in the CVS (AFAIK). I suppose I would need some access rights to the CVS tree?
./MiS
On May 2, 2005, at 12:04 AM, Michal Seta wrote:
Hans-Christoph Steiner hans@eds.org writes:
Yeay! The more, the merrier. Please submit any patches that you have to CVS (doc/pddp).
The only thing that I have is a few of the MIDI help patches reformatted according to the float-help.pd model. Otherwise everything else (prior to deciding on the new format) is already in the CVS (AFAIK). I suppose I would need some access rights to the CVS tree?
Ok, I just announced your desire to join the CVS. I doubt anyone will have any objections.
Then I can add you to the SourceForge project. More MIDI patches sound quite good, they are definitely needed.
.hc
________________________________________________________________________ ____
"Computer science is no more related to the computer than astronomy is related to the telescope." -Edsger Dykstra
hi Hans-Christoph,
firstly -- I am very grateful for yours and Dave's work.
Secondly, imho it is better to rethink pddp now, before adding new contents. The original idea was that pddp should provide a consistent framework for at least three kinds of media: patches, html, and ps/pdf. The choice then was to either base it on docbook, or to design a very simple custom format. The latter never materialized, and certainly never will. Hardly being a docbook fan myself, I do not see any alternative...
Anyway, the worst thing that could happen, would be having all the reference pages, and ``more info'' propaganda embedded in Pd comments. There would be no other way of putting those on other media, than many days of hard manual work. The likely result of which would be forking of the pddp source.
Let us use patches as patches, and comments as comments.
A tricky part, besides tailoring docbook styles, is deciding about a mechanism for opening patches in Pd by invoking links in a html browser. The easiest way is including a simple httpd server in pd-gui. There is a ready to use 250-liner at http://cvs.sourceforge.net/viewcvs.py/tclhttpd/tclhttpd/bin/mini/
Krzysztof
Hans-Christoph Steiner wrote: ...
If anyone is interested, it'd be great if we could work together to create the style guides. The way I currently see it there are two kinds of patches "all_about_" which has lots of text and examples, and the basic help patch, which should be a reference with a link to the relevant "all_about_" pages. float-help.pd from PDDP is a decent example of a reference patch.
And I am totally grateful for the large amount of coding that you have done. And toxy totally changed the way I thought of Pd, from application to programming platform.
As for HTML docs, I don't understand why you want to separate the patches from the text. Yes, the text formatting abilities of Pd are pretty limited, but I think its very helpful to have the text right next to the running examples, instead of having to switch back and forth between applications. The SuperCollider docs are a great example of that. With a little more work on the [comment] object, I think we could have all of the text formatting capabilities that we'd really need to make very nice, linked help patches with texts, all within Pd.
Something like Miller's book, which goes much more into the theory behind what one does with Pd, is a good example of something that works much better in a proper text format.
.hc
On Apr 30, 2005, at 11:30 AM, Krzysztof Czaja wrote:
hi Hans-Christoph,
firstly -- I am very grateful for yours and Dave's work.
Secondly, imho it is better to rethink pddp now, before adding new contents. The original idea was that pddp should provide a consistent framework for at least three kinds of media: patches, html, and ps/pdf. The choice then was to either base it on docbook, or to design a very simple custom format. The latter never materialized, and certainly never will. Hardly being a docbook fan myself, I do not see any alternative...
Anyway, the worst thing that could happen, would be having all the reference pages, and ``more info'' propaganda embedded in Pd comments. There would be no other way of putting those on other media, than many days of hard manual work. The likely result of which would be forking of the pddp source.
Let us use patches as patches, and comments as comments.
A tricky part, besides tailoring docbook styles, is deciding about a mechanism for opening patches in Pd by invoking links in a html browser. The easiest way is including a simple httpd server in pd-gui. There is a ready to use 250-liner at http://cvs.sourceforge.net/viewcvs.py/tclhttpd/tclhttpd/bin/mini/
Krzysztof
Hans-Christoph Steiner wrote: ...
If anyone is interested, it'd be great if we could work together to create the style guides. The way I currently see it there are two kinds of patches "all_about_" which has lots of text and examples, and the basic help patch, which should be a reference with a link to the relevant "all_about_" pages. float-help.pd from PDDP is a decent example of a reference patch.
________________________________________________________________________ ____
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
hi again,
Hans-Christoph Steiner wrote: ...
As for HTML docs, I don't understand why you want to separate the patches from the text. Yes, the text formatting abilities of Pd are
but you want them separate too... a reference page should be kept in a separate window anyway, so what is wrong about that window being controlled by another application?
However, my point is not about using a web browser, but about storing a reference page as a single parsable resource, instead of breaking it into several unparsable comments (same goes for any other type of longer self-contained text).
The way it is displayed is quite another matter. I am proposing the external browser, as the easiest, and the most old-fashioned-Pdish way to do it. Another option is including some kind of a browser widget in pd-gui, which you seem proposing:
...
of that. With a little more work on the [comment] object, I think we could have all of the text formatting capabilities that we'd really need to make very nice, linked help patches with texts, all within Pd.
Krzysztof
On May 1, 2005, at 6:43 AM, Krzysztof Czaja wrote:
hi again,
Hans-Christoph Steiner wrote: ...
As for HTML docs, I don't understand why you want to separate the patches from the text. Yes, the text formatting abilities of Pd are
but you want them separate too... a reference page should be kept in a separate window anyway, so what is wrong about that window being controlled by another application?
If we can do it in Pd, why not do it in Pd? The example patches that go with the text would need to be opened from the browser (or whatever). There are a number of problems with launching .pd files from other applications, many of which are platform-specific and browser-specific. For example, on MacOSX, if you double-click a .pd file and Pd is not running, it loads the .pd file first, before loading the .pdrc or the prefs. So it'll the patch will throw errors if it needs anything from a non-standard path or a lib. This might affect other platforms too.
Plus, I think MacOSX is the only platform that automatically gets the file associations set up by Pd. On GNU/Linux and Windows, you need to manually create the file associations. That means for newbies, we'd have a lot of requests on the lists of how to do that. And each OS and each browser does it differently. Plus GNOME and KDE do it differently as well. If we write the references in Pd, we don't need to do anything to have the example patches launch in Pd.
However, my point is not about using a web browser, but about storing a reference page as a single parsable resource, instead of breaking it into several unparsable comments (same goes for any other type of longer self-contained text).
I am not sure what you mean by "unparsable comments". Using a multi-line regexp, you can grab all chunks that start with '#X text [0-9-]* [0-9-]*' and ends with a non-escaped ';'. The '#X text [0-9-]* [0-9-]*' would be equivalent to an HTML <p> and ';' to a </p> Start that comment with a keyword, they its quite easy to assign that text to that keyword in a hash or whatever. The regexps could be used in Tcl to be cross-platform. I don't think it'd be any harder to parse a .pd file than it would be to parse a .html file for our uses.
.hc
The way it is displayed is quite another matter. I am proposing the external browser, as the easiest, and the most old-fashioned-Pdish way to do it. Another option is including some kind of a browser widget in pd-gui, which you seem proposing:
...
of that. With a little more work on the [comment] object, I think we could have all of the text formatting capabilities that we'd really need to make very nice, linked help patches with texts, all within Pd.
Krzysztof
________________________________________________________________________ ____
Hans-Christoph Steiner wrote: ...
If we can do it in Pd, why not do it in Pd? The example patches that
we cannot, unless after developing a browser widget. Using it would be perfectly ok, once it is available.
go with the text would need to be opened from the browser (or whatever). There are a number of problems with launching .pd files from other applications, many of which are platform-specific and
no, it is much simpler -- when "pddpserver" receives a GET request for a path, it might do just this:
if {[string equal [file extension $path] .pd] && [otherconditions]} { pd [concat pd open [file tail $path] [file dirname $path] ;] set path [htmlpageof $path] } #... carry on serving
...
I am not sure what you mean by "unparsable comments". Using a multi-line regexp, you can grab all chunks that start with '#X text
parse-and-pray...
[0-9-]* [0-9-]*' and ends with a non-escaped ';'. The '#X text [0-9-]* [0-9-]*' would be equivalent to an HTML <p> and ';' to a </p>
html is docbook's output, not source...
Krzysztof
The idea of an HTML PDDP sounds great. It will require a TclTK browser widget in Pd, a pddpserver, and a Pd reference done in Docbook. None of these exist and AFAIK, no one is working on these things. HTML/Docbook would undoubtedly produce more flexibility in formatting, but we can make a decently formatted reference with what we have now with all of the functionality (except for maybe clickable URLs in Pd, but that shouldn't be too hard to implement, right?).
It would not take much work to make some PDDP templates (reference/-help.pd, examples, and all_about_) and reformat the content that we have now, and we'd have the beginnings of a very functional help/reference for Pd.
I know what I propose is not the ideal solution, but it is a realistic one, and one that is already underway. The idea for PDDP started in 2002, its obviously not moving fast. So I think it makes a lot of sense to have a less than perfect system now rather than wait years more for a perfect one. And then we can learn from the first experience how to better implement the perfect system. Who was it that said you have to implement the program in order to know how to implement it?
.hc
On May 1, 2005, at 12:30 PM, Krzysztof Czaja wrote:
Hans-Christoph Steiner wrote: ...
If we can do it in Pd, why not do it in Pd? The example patches that
we cannot, unless after developing a browser widget. Using it would be perfectly ok, once it is available.
go with the text would need to be opened from the browser (or whatever). There are a number of problems with launching .pd files from other applications, many of which are platform-specific and
no, it is much simpler -- when "pddpserver" receives a GET request for a path, it might do just this:
if {[string equal [file extension $path] .pd] && [otherconditions]} { pd [concat pd open [file tail $path] [file dirname $path] ;] set path [htmlpageof $path] } #... carry on serving
...
I am not sure what you mean by "unparsable comments". Using a multi-line regexp, you can grab all chunks that start with '#X text
parse-and-pray...
[0-9-]* [0-9-]*' and ends with a non-escaped ';'. The '#X text [0-9-]* [0-9-]*' would be equivalent to an HTML <p> and ';' to a </p>
html is docbook's output, not source...
Krzysztof
________________________________________________________________________ ____
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
Hans-Christoph Steiner wrote:
The idea of an HTML PDDP sounds great. It will require a TclTK browser widget in Pd, a pddpserver, and a Pd reference done in Docbook. None of these exist and AFAIK, no one is working on these things.
1. there is no need for a browser widget when using pddpserver: it is either a widget, or a server, or a mime association (the most tricky one)
2. pddserver is almost ready, I have a working prototype
3. customizing docbook does not seem too hard (I might be wrong, though, never tried it...)
However, I think now that writing a helper script and 20-30 hours of typing should suffice for transferring 100 pages of reference from .pd to .xml. So, if you are happy with pd comment editor as authoring tool, it is not a big deal, anyway.
Krzysztof
for sc fans: openjade outputs rtf, so .xml gives pddp an extra bonus of being one symlink away from using supercollider as its help browser...
Krzysztof Czaja wrote: ...
no, it is much simpler -- when "pddpserver" receives a GET request for a path, it might do just this:
if {[string equal [file extension $path] .pd] && [otherconditions]} { pd [concat pd open [file tail $path] [file dirname $path] ;] set path [htmlpageof $path] }
- set path [htmlpageof $path] + respondwithstatus 204 + return
Krzysztof
Hello,
Krzysztof Czaja wrote:
but you want them separate too... a reference page should be kept in a separate window anyway, so what is wrong about that window being controlled by another application?
I don't see where we're proposing to keep them separate?
However, my point is not about using a web browser, but about storing a reference page as a single parsable resource, instead of breaking it into several unparsable comments (same goes for any other type of longer self-contained text).
The problem with a specialized file for reference is that it has to be edited independantly of the patches themselves. The -help patches ARE the major source of documentation in PD. It is much easier for the developer to conform to a documentation standard in a help-patch and then get access to all the searching functions and so on, than it is for the developer to remember to edit the damn references file. (It will simply fall out of date.) It seems hard enough for developers to keep their help patches in sync with external source, let alone them doing it again in another file.
The way it is displayed is quite another matter. I am proposing the external browser, as the easiest, and the most old-fashioned-Pdish way to do it. Another option is including some kind of a browser widget in pd-gui, which you seem proposing:
Again I don't see enough difficiencies in the patching format for documentation to warrent this move. Where does the content for this html thing come from? All recreated from scratch from all the existing patch-based documentation?
b.
hi Ben,
I feel we do not understand each other. I totally agree that the main entry point to the documentation is the help patch. I am trying to tell, that if we want pddp to become a real ``documentation project'', there will be more in it than just patches.
If we agreed about that (I am not sure we actually do?), then we should also agree, perhaps, that at the core of pddp would need to be a framework, that would allow patches to link to non-patches, and non-patches to link back to patches, in a transparent and robust way.
If, still *if*, we agreed about that too, then we might start thinking about pddp structure. If not, I do not care.
About help patches: I prefer them to contain only a short description (standard Pd comments), basic use cases (commented likewise), and links to a related documentation.
Those links should directly point to a detailed description (aka reference page, which may actually span several pages), and a ``more info'' story (which may contain math formulae, figures, etc.) The story would link back to various example patches and tutorials.
It is probably only a dream...
Anyway, I feel sorry jumping in the middle of your discussion like some kind of a troll... I was just staring at the main screen of float-help.pd (seemingly an attempt at mimicking Max reference pages by the ``uglier-but-smarter sister''), extrapolating it into xeq-help.pd, and feeling uneasy about:
struggling with an unsuitable editor
representing my content as Pd global symbols and floats
storing my content as an unstructured set of bits and pieces
giving my screen an ugly look
not being able to print my content in any reasonable way
not being able to publish my content on a web page
...
Krzysztof
Hi Krzysztof,
Perhaps I am missing your mark. Ok so we agree on the centralization of the PD help patch.
So you see PDDP as a way or organizing multiple types of documents in a somewhat unified way. Ok.
If we think of a patch as just a patch that is all that it will ever be. A patch could be a document as well though. The main problem I see with having the documentation in different types of media is this linking back and forth part. Abstract concepts, theory, could be more easily represented as a large text-document. I'm not sure if this is the case though, since I personally think theory is best expressed through concrete real-world examples - patches. It is true that things like formulae don't work in PD too elegantly, expr being the most clear representation of an equation, but not all types.
Its the switching back and forth part that makes me wonder about that approach. With examples embeded in the document the way the person reads the document leads back and forth between example and theory, without a mode switch. I can see your idea of linking to static document types work in the case of extra supplimentry information, details on a lower level. Stuff that would scare the novice user.
I guess what I'm thinking is that the ideas are expressed more by example and by experience of the user (as they look at multiple patches) than by a text. This could be off-base. I may just be getting too confused between the tutorial workshop project vs the help system.
Ok I'm going to comment inline for the specific issues...
Krzysztof Czaja wrote:
hi Ben,
<snip>
Those links should directly point to a detailed description (aka reference page, which may actually span several pages), and a ``more info'' story (which may contain math formulae, figures, etc.) The story would link back to various example patches and tutorials.
It is probably only a dream...
Anyway, I feel sorry jumping in the middle of your discussion like some kind of a troll... I was just staring at the main screen of float-help.pd (seemingly an attempt at mimicking Max reference pages by the ``uglier-but-smarter sister''), extrapolating it into xeq-help.pd, and feeling uneasy about:
struggling with an unsuitable editor
Unsuitable in terms of text-editing or editing in general? I think any improvements made to make text-editing easier would also improve the general patching process?
representing my content as Pd global symbols and floats
I see two things, the active content bing the PD patch and its messages, also a text block that is a light overview of theory, not a huge amount of text. I figure it would be half-and-half, text and patch.
storing my content as an unstructured set of bits and pieces
Yes this is true. It is interesting that the talk about comments prepended are actually an effort to structure the comments. What if this went further? I confess I'm not sure how...
giving my screen an ugly look
It does take a bit more effort to make a PD patch look good, but canvases, indentation (using duplicate), and spacing really do help.
not being able to print my content in any reasonable way
"file -> print" not reasonable enough? What if there was a script that converted a folder of patches into a single multi-page PDF?
not being able to publish my content on a web page
About the same anser as above, unless you see a big issue with putting PDFs on web-pages.
I guess I've made it obvious that I think having the text and example integrated into once process (document) is the more advantageous. It is much easier to extend the PD patch format to make nicer documents than it is to make html and PDFs make nice interactive examples.
I'm thinking the final result would be a combination of both ways, with links to supplimentry information as html/pdf/etc documents but the most pertinent information being presented in the patch itself. The latter being easier and most valuable I would say we start with that and go from there.
Should the "hyperlink" object be a toxy widget or an external or an internal? Should it just be part of the [comment] or some new [text] object? hyperlinks inline with comments/text would be pretty familiar to people.
What do we all think?
B.
B. Bogart wrote: ...
Should the "hyperlink" object be a toxy widget or an external or an internal? Should it just be part of the [comment] or some new [text] object? hyperlinks inline with comments/text would be pretty familiar to
ideally, bulk of the code would be included in pd.tk, driven by a simple comment-like internal class. Until that happens, the pd-gui code would have to be sourced into pd-gui by a simple comment-like external class, instantiated [pddplink mypage.html] or [pddplink mypatch.pd], but presenting itself as an active text, not an object box.
I have the client/server part ready for testing, will try to make the Pd object part during this weekend.
Krzysztof
The URL object should probably also support normal http requests over the internet also (just passing the URL to the browser, using exec?) I think this would be much more useful than making it a PDDP only object. Actually as an object it would be handy to have:
* Inlet to dynamically change URL from a patch * An inactive mode where an outlet could be connected to a symbol to send the URL to other objects.
Ah just some ideas anyhow (the first point being much more useful than the second!)
I think we did agree on the html viewer being important for some information. I don't recall us discussing what works better in one form compared to the other.
Had a chance to look at the PDDP templates I put up on the wiki?
B?>
Krzysztof Czaja wrote:
B. Bogart wrote: ...
Should the "hyperlink" object be a toxy widget or an external or an internal? Should it just be part of the [comment] or some new [text] object? hyperlinks inline with comments/text would be pretty familiar to
ideally, bulk of the code would be included in pd.tk, driven by a simple comment-like internal class. Until that happens, the pd-gui code would have to be sourced into pd-gui by a simple comment-like external class, instantiated [pddplink mypage.html] or [pddplink mypatch.pd], but presenting itself as an active text, not an object box.
I have the client/server part ready for testing, will try to make the Pd object part during this weekend.
Krzysztof
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hi Krzysztof,
Indeed PDDP is a great resource, and I'm exited to contribute to it.
I also agree that we should discuss PDDP before jumping in with new content, this means having templates and working on the style-guide.
I don't see why both html and ps/pdf were chosen here, since they are both fairly equal when it comes to formatting text on a page. PDFs can be generated from HTML as well PDFs could be generated from PD help patches via the "print" feature and a little ghostscript (Mathieu mentioned making a stand-alone script that generated PS files directly from patches.)
I can't agree that having the bulk of PD content (documentation) in the PD patch format is a bad idea. What are the limitations/problems with the format that makes this a bad idea? I see two:
1. The inconsistant fonts over different platforms 2. limitations in controlling the look of "comments" or text in general in a PD patch. If comments could justified, change fonts, and change the wrapping width it would work pretty well for documentation. Or comment could stay as-is and a new form of [text] could be created.
As for 1, I don't know how to fix this, but it makes consistant documentation a real pain, this needs to be resolved. Once #1 is fixed I don't think 2. is really needed, as PDDP templates would simply conform to the width of comment boxes. #2 is probably much more work than #1.
As I have said above I don't think there are any real significant issues with "printing" PD patches as PS and distributing as PDF.
From a teaching point-of-view an interactive patch will get the idea accross much faster than an html document explaining a certain concept in words.
Personally I think time would be better spent making PD patches work as good documentation (the patcher is just a vector layout anyway), than embedding html/pdf reading facilities into PD. The benifits (to a person learning PD) of a patch as documentation outweigh the benifits of having the ability to load html files along-side patches in PD.
Thats my opinion anyhow.
b<
Krzysztof Czaja wrote:
hi Hans-Christoph,
firstly -- I am very grateful for yours and Dave's work.
Secondly, imho it is better to rethink pddp now, before adding new contents. The original idea was that pddp should provide a consistent framework for at least three kinds of media: patches, html, and ps/pdf. The choice then was to either base it on docbook, or to design a very simple custom format. The latter never materialized, and certainly never will. Hardly being a docbook fan myself, I do not see any alternative...
Anyway, the worst thing that could happen, would be having all the reference pages, and ``more info'' propaganda embedded in Pd comments. There would be no other way of putting those on other media, than many days of hard manual work. The likely result of which would be forking of the pddp source.
Let us use patches as patches, and comments as comments.
A tricky part, besides tailoring docbook styles, is deciding about a mechanism for opening patches in Pd by invoking links in a html browser. The easiest way is including a simple httpd server in pd-gui. There is a ready to use 250-liner at http://cvs.sourceforge.net/viewcvs.py/tclhttpd/tclhttpd/bin/mini/
Krzysztof
Hans-Christoph Steiner wrote: ...
If anyone is interested, it'd be great if we could work together to create the style guides. The way I currently see it there are two kinds of patches "all_about_" which has lots of text and examples, and the basic help patch, which should be a reference with a link to the relevant "all_about_" pages. float-help.pd from PDDP is a decent example of a reference patch.
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
I think #1 (fonts) is solvable without too much work. Nobody taken a stab at it in the recent past AFAIK.
#2 (comment formatting) already exists in two formats: the fixed width PDDP style using Pd "text" objects, and Krzysztof's [comment] from cyclone. If [comment] had a bit more interface polish, it'd be quite usable for PDDP.
.hc
On May 4, 2005, at 3:24 PM, B. Bogart wrote:
Hi Krzysztof,
Indeed PDDP is a great resource, and I'm exited to contribute to it.
I also agree that we should discuss PDDP before jumping in with new content, this means having templates and working on the style-guide.
I don't see why both html and ps/pdf were chosen here, since they are both fairly equal when it comes to formatting text on a page. PDFs can be generated from HTML as well PDFs could be generated from PD help patches via the "print" feature and a little ghostscript (Mathieu mentioned making a stand-alone script that generated PS files directly from patches.)
I can't agree that having the bulk of PD content (documentation) in the PD patch format is a bad idea. What are the limitations/problems with the format that makes this a bad idea? I see two:
- The inconsistant fonts over different platforms
- limitations in controlling the look of "comments" or text in general
in a PD patch. If comments could justified, change fonts, and change the wrapping width it would work pretty well for documentation. Or comment could stay as-is and a new form of [text] could be created.
As for 1, I don't know how to fix this, but it makes consistant documentation a real pain, this needs to be resolved. Once #1 is fixed I don't think 2. is really needed, as PDDP templates would simply conform to the width of comment boxes. #2 is probably much more work than #1.
As I have said above I don't think there are any real significant issues with "printing" PD patches as PS and distributing as PDF.
From a teaching point-of-view an interactive patch will get the idea accross much faster than an html document explaining a certain concept in words.
Personally I think time would be better spent making PD patches work as good documentation (the patcher is just a vector layout anyway), than embedding html/pdf reading facilities into PD. The benifits (to a person learning PD) of a patch as documentation outweigh the benifits of having the ability to load html files along-side patches in PD.
Thats my opinion anyhow.
b<
Krzysztof Czaja wrote:
hi Hans-Christoph,
firstly -- I am very grateful for yours and Dave's work.
Secondly, imho it is better to rethink pddp now, before adding new contents. The original idea was that pddp should provide a consistent framework for at least three kinds of media: patches, html, and ps/pdf. The choice then was to either base it on docbook, or to design a very simple custom format. The latter never materialized, and certainly never will. Hardly being a docbook fan myself, I do not see any alternative...
Anyway, the worst thing that could happen, would be having all the reference pages, and ``more info'' propaganda embedded in Pd comments. There would be no other way of putting those on other media, than many days of hard manual work. The likely result of which would be forking of the pddp source.
Let us use patches as patches, and comments as comments.
A tricky part, besides tailoring docbook styles, is deciding about a mechanism for opening patches in Pd by invoking links in a html browser. The easiest way is including a simple httpd server in pd-gui. There is a ready to use 250-liner at http://cvs.sourceforge.net/viewcvs.py/tclhttpd/tclhttpd/bin/mini/
Krzysztof
Hans-Christoph Steiner wrote: ...
If anyone is interested, it'd be great if we could work together to create the style guides. The way I currently see it there are two kinds of patches "all_about_" which has lots of text and examples, and the basic help patch, which should be a reference with a link to the relevant "all_about_" pages. float-help.pd from PDDP is a decent example of a reference patch.
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
"Information wants to be free." -Stewart Brand
Hi HC,
Nice to hear confidence about #1. I'm still a little unclear about the problem, is it that font size "12" on platform A is many more pixels high than font size "12" on platform B? In which case can we do some math so that the font size "12" is actually "13" on platform B so that it matches platform A?
#2: The comment width is only as fixed as the font width correct? So the paragraph grows wider depending on platform, and I guess the biggest font wins and the smallest loses. I did see Krzysztof's comment which does look quite nice (non-courier!) I see this issue as being somewhat separate from the documentation issue. #2 does not help, but it just need a little polish. Somehow I don't see it being fixed anytime soon. I have not looked at the tk commands for text on canvases, not sure things like a wrapping box can be specified. I'll have to peek at Krzysztof's source to see how he got it working (embeded entry widget?).
B.
Hans-Christoph Steiner wrote:
I think #1 (fonts) is solvable without too much work. Nobody taken a stab at it in the recent past AFAIK.
#2 (comment formatting) already exists in two formats: the fixed width PDDP style using Pd "text" objects, and Krzysztof's [comment] from cyclone. If [comment] had a bit more interface polish, it'd be quite usable for PDDP.
.hc
On May 4, 2005, at 3:24 PM, B. Bogart wrote:
Hi Krzysztof,
Indeed PDDP is a great resource, and I'm exited to contribute to it.
I also agree that we should discuss PDDP before jumping in with new content, this means having templates and working on the style-guide.
I don't see why both html and ps/pdf were chosen here, since they are both fairly equal when it comes to formatting text on a page. PDFs can be generated from HTML as well PDFs could be generated from PD help patches via the "print" feature and a little ghostscript (Mathieu mentioned making a stand-alone script that generated PS files directly from patches.)
I can't agree that having the bulk of PD content (documentation) in the PD patch format is a bad idea. What are the limitations/problems with the format that makes this a bad idea? I see two:
- The inconsistant fonts over different platforms
- limitations in controlling the look of "comments" or text in general
in a PD patch. If comments could justified, change fonts, and change the wrapping width it would work pretty well for documentation. Or comment could stay as-is and a new form of [text] could be created.
As for 1, I don't know how to fix this, but it makes consistant documentation a real pain, this needs to be resolved. Once #1 is fixed I don't think 2. is really needed, as PDDP templates would simply conform to the width of comment boxes. #2 is probably much more work than #1.
As I have said above I don't think there are any real significant issues with "printing" PD patches as PS and distributing as PDF.
From a teaching point-of-view an interactive patch will get the idea accross much faster than an html document explaining a certain concept in words.
Personally I think time would be better spent making PD patches work as good documentation (the patcher is just a vector layout anyway), than embedding html/pdf reading facilities into PD. The benifits (to a person learning PD) of a patch as documentation outweigh the benifits of having the ability to load html files along-side patches in PD.
Thats my opinion anyhow.
b<
Krzysztof Czaja wrote:
hi Hans-Christoph,
firstly -- I am very grateful for yours and Dave's work.
Secondly, imho it is better to rethink pddp now, before adding new contents. The original idea was that pddp should provide a consistent framework for at least three kinds of media: patches, html, and ps/pdf. The choice then was to either base it on docbook, or to design a very simple custom format. The latter never materialized, and certainly never will. Hardly being a docbook fan myself, I do not see any alternative...
Anyway, the worst thing that could happen, would be having all the reference pages, and ``more info'' propaganda embedded in Pd comments. There would be no other way of putting those on other media, than many days of hard manual work. The likely result of which would be forking of the pddp source.
Let us use patches as patches, and comments as comments.
A tricky part, besides tailoring docbook styles, is deciding about a mechanism for opening patches in Pd by invoking links in a html browser. The easiest way is including a simple httpd server in pd-gui. There is a ready to use 250-liner at http://cvs.sourceforge.net/viewcvs.py/tclhttpd/tclhttpd/bin/mini/
Krzysztof
Hans-Christoph Steiner wrote: ...
If anyone is interested, it'd be great if we could work together to create the style guides. The way I currently see it there are two kinds of patches "all_about_" which has lots of text and examples, and the basic help patch, which should be a reference with a link to the relevant "all_about_" pages. float-help.pd from PDDP is a decent example of a reference patch.
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
"Information wants to be free." -Stewart Brand
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-
B. Bogart -
Frank Barknecht -
Hans-Christoph Steiner -
Krzysztof Czaja -
Michal Seta