I'll implement any *clear* spec for multi-language help patches someone comes up with with the following constraints:
- it separates design from content.
- in only requires documentation writers to care about content.
- it does not pigeonhole help patches into having a single, ugly design
- documentation writers will be guaranteed that whatever they write, it won't
overlap patch content. 5. it is maintainable and scalable
Sounds like .html.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
I think multi-language patch “comments” is more difficult than multi-language “Help files”.
M-L-Help files can be done translating each help file and saving it with a name like “metro-help-ES.pd” or “metro-help-FR.pd” then telling pd to add the -ES or -XX to the english helpfile name.
This is a lot of work, but can/should be done by the community, I remember that something like this has been done in Pd-extended menus with an online infrastructure, everyone contributed with what was left to be done.
Of course this increases a lot the size of the package, there should be something like downloading only the extra language that you use and not all. Some folder somewhere.
Just a sketch. Mensaje telepatico asistido por maquinas.
From: danomatika@gmail.com Date: Fri, 26 Feb 2016 10:59:21 -0700 To: pd-list@lists.iem.at Subject: Re: [PD] multi-language help patches
I'll implement any *clear* spec for multi-language help patches someone comes up with with the following constraints:1. it separates design from content.2. in only requires documentation writers to care about content.3. it does not pigeonhole help patches into having a single, ugly design4. documentation writers will be guaranteed that whatever they write, it won't overlap patch content.5. it is maintainable and scalable
Sounds like .html.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
multi-language patch “comments” can be done without any modifications, simply using more area on the screen or in a sub patch.
Normally you provide comments in your native language and in english. Mensaje telepatico asistido por maquinas.
From: lucarda27@hotmail.com To: pd-list@lists.iem.at Date: Fri, 26 Feb 2016 18:46:59 +0000 Subject: Re: [PD] multi-language help patches
I think multi-language patch “comments” is more difficult than multi-language “Help files”.
M-L-Help files can be done translating each help file and saving it with a name like “metro-help-ES.pd” or “metro-help-FR.pd” then telling pd to add the -ES or -XX to the english helpfile name.
This is a lot of work, but can/should be done by the community, I remember that something like this has been done in Pd-extended menus with an online infrastructure, everyone contributed with what was left to be done.
Of course this increases a lot the size of the package, there should be something like downloading only the extra language that you use and not all. Some folder somewhere.
Just a sketch. Mensaje telepatico asistido por maquinas.
From: danomatika@gmail.com Date: Fri, 26 Feb 2016 10:59:21 -0700 To: pd-list@lists.iem.at Subject: Re: [PD] multi-language help patches
I'll implement any *clear* spec for multi-language help patches someone comes up with with the following constraints:1. it separates design from content.2. in only requires documentation writers to care about content.3. it does not pigeonhole help patches into having a single, ugly design4. documentation writers will be guaranteed that whatever they write, it won't overlap patch content.5. it is maintainable and scalable
Sounds like .html.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
M-L-Help files can be donetranslating each help file and saving it with a name like“metro-help-ES.pd” or “metro-help-FR.pd” then telling pd toadd the -ES or -XX to the english helpfile name.
That's not maintainable:1. Revisions to the demo part of the help patch would have to be applied manually, to as many patches as there are languages.2. In almost all cases the translater has to mess around with the positioning of objects to make sure that the comments don't overlap.3. Currently, Pd doesn't even give you a visual cue for the max width and height of a comment object at a particular font size, so the translater can't even know whether the comments they are manually positioning will in fact collide on someone else's system.4. Even if all the points above weren't an issue, the design becomes baked in and isn't user-friendly for people who want to zoom in to make the text bigger. I've notice this with the GUI port-- if you zoom in on a PDDP patch the help text extends past the window dimensions, causing vertical scrollbars which are the worst in terms of readability. So now you have to manually resize the window so that the zoomed text fits inside it. Not bad for reading a single patch, but try that 100 times esp. on one of those awful linux wm's that give you a 2x2 hotspot for resizing the window.
On Friday, February 26, 2016 2:30 PM, Lucas Cordiviola <lucarda27@hotmail.com> wrote:
#yiv5077710351 #yiv5077710351 --.yiv5077710351hmmessage P{margin:0px;padding:0px;}#yiv5077710351 body.yiv5077710351hmmessage{font-size:12pt;font-family:Calibri;}#yiv5077710351 multi-language patch“comments” can be done without any modifications, simply usingmore area on the screen or in a sub patch. Normally you providecomments in your native language and in english. Mensaje telepatico asistido por maquinas.
From: lucarda27@hotmail.com To: pd-list@lists.iem.at Date: Fri, 26 Feb 2016 18:46:59 +0000 Subject: Re: [PD] multi-language help patches
#yiv5077710351 #yiv5077710351 --.yiv5077710351ExternalClass .yiv5077710351ecxhmmessage P {padding:0px;}#yiv5077710351 .yiv5077710351ExternalClass body.yiv5077710351ecxhmmessage {font-size:12pt;font-family:Calibri;}#yiv5077710351 I think multi-languagepatch “comments” is more difficult than multi-language “Helpfiles”. M-L-Help files can be donetranslating each help file and saving it with a name like“metro-help-ES.pd” or “metro-help-FR.pd” then telling pd toadd the -ES or -XX to the english helpfile name. This is a lot of work, butcan/should be done by the community, I remember that something likethis has been done in Pd-extended menus with an onlineinfrastructure, everyone contributed with what was left to be done. Of course this increases alot the size of the package, there should be something likedownloading only the extra language that you use and not all. Somefolder somewhere. Just a sketch. Mensaje telepatico asistido por maquinas.
From: danomatika@gmail.com Date: Fri, 26 Feb 2016 10:59:21 -0700 To: pd-list@lists.iem.at Subject: Re: [PD] multi-language help patches
I'll implement any *clear* spec for multi-language help patches someone comes up with with the following constraints:1. it separates design from content.2. in only requires documentation writers to care about content.3. it does not pigeonhole help patches into having a single, ugly design4. documentation writers will be guaranteed that whatever they write, it won't overlap patch content.5. it is maintainable and scalable
Sounds like .html.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
_______________________________________________Pd-list@lists.iem.at mailing listUNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________Pd-list@lists.iem.at mailing listUNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
html could be leveraged, but I'm really looking for a spec for how Pd handles it. Is it a GUI widget? An abstraction? A canvas method? A new "#" directive? Do the translations get saved along with the help patch, or are they stored in a directory and fetched when needed? Etc. -Jonathan
On Friday, February 26, 2016 1:02 PM, Dan Wilcox <danomatika@gmail.com> wrote:
I'll implement any *clear* spec for multi-language help patches someone comes up with with the following constraints:1. it separates design from content.2. in only requires documentation writers to care about content.3. it does not pigeonhole help patches into having a single, ugly design4. documentation writers will be guaranteed that whatever they write, it won't overlap patch content.5. it is maintainable and scalable
Sounds like .html.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I think what implying is that maybe Pd *doesn’t* need to handle it. Simply, Pd could open a local webpage, similar to how the Processing “Find in reference” context menu option works when highlighting a function in the editor.
Not to say you/we can’t work out a file format/system to handle alot of this, but I’m thinking that html reference already works well for many other contexts an doesn’t require building new formats/systems to solve alot of the same problems.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Feb 26, 2016, at 2:08 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
html could be leveraged, but I'm really looking for a spec for how Pd handles it. Is it a GUI widget? An abstraction? A canvas method? A new "#" directive?
Do the translations get saved along with the help patch, or are they stored in a directory and fetched when needed? Etc.
-Jonathan
On Friday, February 26, 2016 1:02 PM, Dan Wilcox danomatika@gmail.com wrote:
I'll implement any *clear* spec for multi-language help patches someone comes up with with the following constraints:
- it separates design from content.
- in only requires documentation writers to care about content.
- it does not pigeonhole help patches into having a single, ugly design
- documentation writers will be guaranteed that whatever they write, it won't
overlap patch content. 5. it is maintainable and scalable
Sounds like .html.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
M-L-Help files can be done translating each help file and saving it with a name like “metro-help-ES.pd” or “metro-help-FR.pd” then telling pd to add the -ES or -XX to the english helpfile name.
That's not maintainable:
Revisions to the demo part of the help patch would have to be applied
manually, to as many patches as there are languages.
In almost all cases the translater has to mess around with the positioning
of objects to make sure that the comments don't overlap.
Currently, Pd doesn't even give you a visual cue for the max width and
height of a comment object at a particular font size, so the translater can't even know whether the comments they are manually positioning will in fact collide on
someone else's system.
These 3 points could be part of the job, once the comments have been translated to that patch you can download it and correct it, and upload.
Even if all the points above weren't an issue, the design becomes baked
in and isn't user-friendly for people who want to zoom in to make the text bigger.
I've notice this with the GUI port-- if you zoom in on a PDDP patch the help
text extends past the window dimensions, causing vertical scrollbars which are
the worst in terms of readability. So now you have to manually resize the
window so that the zoomed text fits inside it. Not bad for reading a single patch,
but try that 100 times esp. on one of those awful linux wm's that give you a
2x2 hotspot for resizing the window.
This point I have no idea.
I have nothing against html nor to the *help-xx.pd.
Also both will be much easier to implement as an online option. Mensaje telepatico asistido por maquinas.
From: danomatika@gmail.com Date: Fri, 26 Feb 2016 14:33:59 -0700 To: jancsika@yahoo.com CC: pd-list@lists.iem.at Subject: Re: [PD] multi-language help patches
I think what implying is that maybe Pd *doesn’t* need to handle it. Simply, Pd could open a local webpage, similar to how the Processing “Find in reference” context menu option works when highlighting a function in the editor. Not to say you/we can’t work out a file format/system to handle alot of this, but I’m thinking that html reference already works well for many other contexts an doesn’t require building new formats/systems to solve alot of the same problems.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Feb 26, 2016, at 2:08 PM, Jonathan Wilkes jancsika@yahoo.com wrote:html could be leveraged, but I'm really looking for a spec for how Pd handles it. Is it a GUI widget? An abstraction? A canvas method? A new "#" directive? Do the translations get saved along with the help patch, or are they stored in a directory and fetched when needed? Etc. -Jonathan
On Friday, February 26, 2016 1:02 PM, Dan Wilcox <danomatika@gmail.com> wrote:
I'll implement any *clear* spec for multi-language help patches someone comes up with with the following constraints:1. it separates design from content.2. in only requires documentation writers to care about content.3. it does not pigeonhole help patches into having a single, ugly design4. documentation writers will be guaranteed that whatever they write, it won't overlap patch content.5. it is maintainable and scalableSounds like .html. --------Dan Wilcox@danomatikadanomatika.comrobotcowboy.com _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Ok, so which html reference system should I leverage here? Where will the html files get stored, and how do we get from clicking the link in the help patch (I'm assuming we're still using the current help patches to show a simple demo of the object) to opening the html doc in the correct language? -Jonathan
On Friday, February 26, 2016 4:34 PM, Dan Wilcox <danomatika@gmail.com> wrote:
I think what implying is that maybe Pd *doesn’t* need to handle it. Simply, Pd could open a local webpage, similar to how the Processing “Find in reference” context menu option works when highlighting a function in the editor. Not to say you/we can’t work out a file format/system to handle alot of this, but I’m thinking that html reference already works well for many other contexts an doesn’t require building new formats/systems to solve alot of the same problems.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Feb 26, 2016, at 2:08 PM, Jonathan Wilkes jancsika@yahoo.com wrote: html could be leveraged, but I'm really looking for a spec for how Pd handles it. Is it a GUI widget? An abstraction? A canvas method? A new "#" directive? Do the translations get saved along with the help patch, or are they stored in a directory and fetched when needed? Etc. -Jonathan
On Friday, February 26, 2016 1:02 PM, Dan Wilcox <danomatika@gmail.com> wrote:
I'll implement any *clear* spec for multi-language help patches someone comes up with with the following constraints:1. it separates design from content.2. in only requires documentation writers to care about content.3. it does not pigeonhole help patches into having a single, ugly design4. documentation writers will be guaranteed that whatever they write, it won't overlap patch content.5. it is maintainable and scalable
Sounds like .html.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Ok, so which html reference system should I leverage here?
Probably something using css and an html template that make it easy for people to fill out. I’d say 1 main html file for each object to document w/ room for sub pages if needed. Different languages can live in different folders.
The nice thing about this approach is lots of people can edit html, there are plenty of designers, the files can be rendered by pretty much anything, etc. Another option is to have a templating system that uses Markdown, etc and just renders to html. It can then live in it’s own source repository for shared work and be used as a basis for online as well as distributed documentation.
Maybe a good start would be to look at the pure data object database/wiki that is around somewhere. I can’t find the link off the top of my head.
Where will the html files get stored, and how do we get from clicking the link in the help patch (I'm assuming we're still using the current help patches to show a simple demo of the object) to opening the html doc in the correct language?
Just like opening a help patch with a context menu option or maybe links we can open from the patch itself. Use the current help paths for searching and use tcl to launch the path in the system web browser if found.
I’d say the most useful thing would be add linking between patches and external files (html, etc) in general. I believe Hans had this in extended for the pd-doc stuff.
I’m suggesting this approach partially so you/we don’t end up reinventing the wheel. A custom, integrated system would be *nice* but I feel that will require too much backend work to build and them probably too much work to maintain/extend in the future. HTML+CSS has the option of being loaded into a web view within TK I imagine, so another option would be a side pane or extra window that can open up right in PD. I’d suggest staying away from building extra widgets etc to render a custom approach within the patch itself.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Feb 26, 2016, at 4:44 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
-Jonathan
On Friday, February 26, 2016 4:34 PM, Dan Wilcox danomatika@gmail.com wrote:
I think what implying is that maybe Pd *doesn’t* need to handle it. Simply, Pd could open a local webpage, similar to how the Processing “Find in reference” context menu option works when highlighting a function in the editor.
Not to say you/we can’t work out a file format/system to handle alot of this, but I’m thinking that html reference already works well for many other contexts an doesn’t require building new formats/systems to solve alot of the same problems.
Dan Wilcox @danomatika applewebdata://9A573E33-3C9E-4211-B71F-8EE2FC1E4AF8 danomatika.com applewebdata://9A573E33-3C9E-4211-B71F-8EE2FC1E4AF8 robotcowboy.com applewebdata://9A573E33-3C9E-4211-B71F-8EE2FC1E4AF8
On Feb 26, 2016, at 2:08 PM, Jonathan Wilkes <jancsika@yahoo.com applewebdata://9A573E33-3C9E-4211-B71F-8EE2FC1E4AF8> wrote:
html could be leveraged, but I'm really looking for a spec for how Pd handles it. Is it a GUI widget? An abstraction? A canvas method? A new "#" directive?
Do the translations get saved along with the help patch, or are they stored in a directory and fetched when needed? Etc.
-Jonathan
On Friday, February 26, 2016 1:02 PM, Dan Wilcox <danomatika@gmail.com applewebdata://9A573E33-3C9E-4211-B71F-8EE2FC1E4AF8> wrote:
I'll implement any *clear* spec for multi-language help patches someone comes up with with the following constraints:
- it separates design from content.
- in only requires documentation writers to care about content.
- it does not pigeonhole help patches into having a single, ugly design
- documentation writers will be guaranteed that whatever they write, it won't
overlap patch content. 5. it is maintainable and scalable
Sounds like .html.
Dan Wilcox @danomatika applewebdata://9A573E33-3C9E-4211-B71F-8EE2FC1E4AF8 danomatika.com applewebdata://9A573E33-3C9E-4211-B71F-8EE2FC1E4AF8 robotcowboy.com applewebdata://9A573E33-3C9E-4211-B71F-8EE2FC1E4AF8
Pd-list@lists.iem.at applewebdata://9A573E33-3C9E-4211-B71F-8EE2FC1E4AF8 mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list applewebdata://9A573E33-3C9E-4211-B71F-8EE2FC1E4AF8
Also, my thinking is going in this direction as we’re dealing with the same issues in the OpenFrameworks community. My uni department just hosted an OF DocSprint last weekend and we spent a good amount of time wrangling how best to integrate a Markdown + Doxygen generated reference system.
Of course pure data patch files and C++ source files are somewhat different, but I feel there are the same issues to solve such as what requires the most maintenance, works on all platforms, and is easy for non developer contributors to use. It’s one thing to build a custom system (we did) and quite another to get people to pitch in and fill the content in. I just wouldn’t want anyone to spend a lot of time making something admittedly cool and built into the canvas but, in the end, may not be leveraged by the community the same way a portable, easy to edit, cross platform standard might.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Feb 26, 2016, at 5:01 PM, Dan Wilcox danomatika@gmail.com wrote:
Ok, so which html reference system should I leverage here?
Probably something using css and an html template that make it easy for people to fill out. I’d say 1 main html file for each object to document w/ room for sub pages if needed. Different languages can live in different folders.
The nice thing about this approach is lots of people can edit html, there are plenty of designers, the files can be rendered by pretty much anything, etc. Another option is to have a templating system that uses Markdown, etc and just renders to html. It can then live in it’s own source repository for shared work and be used as a basis for online as well as distributed documentation.
Maybe a good start would be to look at the pure data object database/wiki that is around somewhere. I can’t find the link off the top of my head.
Where will the html files get stored, and how do we get from clicking the link in the help patch (I'm assuming we're still using the current help patches to show a simple demo of the object) to opening the html doc in the correct language?
Just like opening a help patch with a context menu option or maybe links we can open from the patch itself. Use the current help paths for searching and use tcl to launch the path in the system web browser if found.
I’d say the most useful thing would be add linking between patches and external files (html, etc) in general. I believe Hans had this in extended for the pd-doc stuff.
I’m suggesting this approach partially so you/we don’t end up reinventing the wheel. A custom, integrated system would be *nice* but I feel that will require too much backend work to build and them probably too much work to maintain/extend in the future. HTML+CSS has the option of being loaded into a web view within TK I imagine, so another option would be a side pane or extra window that can open up right in PD. I’d suggest staying away from building extra widgets etc to render a custom approach within the patch itself.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Feb 26, 2016, at 4:44 PM, Jonathan Wilkes <jancsika@yahoo.com mailto:jancsika@yahoo.com> wrote:
-Jonathan
On Friday, February 26, 2016 4:34 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote:
I think what implying is that maybe Pd *doesn’t* need to handle it. Simply, Pd could open a local webpage, similar to how the Processing “Find in reference” context menu option works when highlighting a function in the editor.
Not to say you/we can’t work out a file format/system to handle alot of this, but I’m thinking that html reference already works well for many other contexts an doesn’t require building new formats/systems to solve alot of the same problems.
Dan Wilcox @danomatika applewebdata://3B34BFF9-1ECA-43ED-939A-ED1F9AB1AA58 danomatika.com applewebdata://3B34BFF9-1ECA-43ED-939A-ED1F9AB1AA58 robotcowboy.com applewebdata://3B34BFF9-1ECA-43ED-939A-ED1F9AB1AA58
On Feb 26, 2016, at 2:08 PM, Jonathan Wilkes <jancsika@yahoo.com applewebdata://3B34BFF9-1ECA-43ED-939A-ED1F9AB1AA58> wrote:
html could be leveraged, but I'm really looking for a spec for how Pd handles it. Is it a GUI widget? An abstraction? A canvas method? A new "#" directive?
Do the translations get saved along with the help patch, or are they stored in a directory and fetched when needed? Etc.
-Jonathan
On Friday, February 26, 2016 1:02 PM, Dan Wilcox <danomatika@gmail.com applewebdata://3B34BFF9-1ECA-43ED-939A-ED1F9AB1AA58> wrote:
I'll implement any *clear* spec for multi-language help patches someone comes up with with the following constraints:
- it separates design from content.
- in only requires documentation writers to care about content.
- it does not pigeonhole help patches into having a single, ugly design
- documentation writers will be guaranteed that whatever they write, it won't
overlap patch content. 5. it is maintainable and scalable
Sounds like .html.
Dan Wilcox @danomatika applewebdata://3B34BFF9-1ECA-43ED-939A-ED1F9AB1AA58 danomatika.com applewebdata://3B34BFF9-1ECA-43ED-939A-ED1F9AB1AA58 robotcowboy.com applewebdata://3B34BFF9-1ECA-43ED-939A-ED1F9AB1AA58
Pd-list@lists.iem.at applewebdata://3B34BFF9-1ECA-43ED-939A-ED1F9AB1AA58 mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list applewebdata://3B34BFF9-1ECA-43ED-939A-ED1F9AB1AA58
Do you have a spec from that sprint?
On Friday, February 26, 2016 7:08 PM, Dan Wilcox <danomatika@gmail.com> wrote:
Also, my thinking is going in this direction as we’re dealing with the same issues in the OpenFrameworks community. My uni department just hosted an OF DocSprint last weekend and we spent a good amount of time wrangling how best to integrate a Markdown + Doxygen generated reference system. Of course pure data patch files and C++ source files are somewhat different, but I feel there are the same issues to solve such as what requires the most maintenance, works on all platforms, and is easy for non developer contributors to use. It’s one thing to build a custom system (we did) and quite another to get people to pitch in and fill the content in. I just wouldn’t want anyone to spend a lot of time making something admittedly cool and built into the canvas but, in the end, may not be leveraged by the community the same way a portable, easy to edit, cross platform standard might.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Feb 26, 2016, at 5:01 PM, Dan Wilcox danomatika@gmail.com wrote:
Ok, so which html reference system should I leverage here?
Probably something using css and an html template that make it easy for people to fill out. I’d say 1 main html file for each object to document w/ room for sub pages if needed. Different languages can live in different folders. The nice thing about this approach is lots of people can edit html, there are plenty of designers, the files can be rendered by pretty much anything, etc. Another option is to have a templating system that uses Markdown, etc and just renders to html. It can then live in it’s own source repository for shared work and be used as a basis for online as well as distributed documentation. Maybe a good start would be to look at the pure data object database/wiki that is around somewhere. I can’t find the link off the top of my head.
Where will the html files get stored, and how do we get from clicking the link in the help patch (I'm assuming we're still using the current help patches to show a simple demo of the object) to opening the html doc in the correct language?
Just like opening a help patch with a context menu option or maybe links we can open from the patch itself. Use the current help paths for searching and use tcl to launch the path in the system web browser if found. I’d say the most useful thing would be add linking between patches and external files (html, etc) in general. I believe Hans had this in extended for the pd-doc stuff. I’m suggesting this approach partially so you/we don’t end up reinventing the wheel. A custom, integrated system would be *nice* but I feel that will require too much backend work to build and them probably too much work to maintain/extend in the future. HTML+CSS has the option of being loaded into a web view within TK I imagine, so another option would be a side pane or extra window that can open up right in PD. I’d suggest staying away from building extra widgets etc to render a custom approach within the patch itself.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Feb 26, 2016, at 4:44 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
-Jonathan
On Friday, February 26, 2016 4:34 PM, Dan Wilcox <danomatika@gmail.com> wrote:
I think what implying is that maybe Pd *doesn’t* need to handle it. Simply, Pd could open a local webpage, similar to how the Processing “Find in reference” context menu option works when highlighting a function in the editor. Not to say you/we can’t work out a file format/system to handle alot of this, but I’m thinking that html reference already works well for many other contexts an doesn’t require building new formats/systems to solve alot of the same problems.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Feb 26, 2016, at 2:08 PM, Jonathan Wilkes jancsika@yahoo.com wrote: html could be leveraged, but I'm really looking for a spec for how Pd handles it. Is it a GUI widget? An abstraction? A canvas method? A new "#" directive? Do the translations get saved along with the help patch, or are they stored in a directory and fetched when needed? Etc. -Jonathan
On Friday, February 26, 2016 1:02 PM, Dan Wilcox <danomatika@gmail.com> wrote:
I'll implement any *clear* spec for multi-language help patches someone comes up with with the following constraints:1. it separates design from content.2. in only requires documentation writers to care about content.3. it does not pigeonhole help patches into having a single, ugly design4. documentation writers will be guaranteed that whatever they write, it won't overlap patch content.5. it is maintainable and scalable
Sounds like .html.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I'd look at how the processing team has put their site/reference together: https://github.com/processing/processing-docs https://github.com/processing/processing-docs
It's basically using a php engine with content written and parsed in xml. Each function/class to be documented has it's own file and each file starts form a template which the author then just needs to fill out. I'm not suggesting using xml, etc but I like the layout from an editing & parsing perspective.
And this is the processing reference, which I feel is a great model for a teaching/arts environment (aka good balance towards readability for beginners and the important info for pros). This section is also included when you download Processing and opened automatically via a link form the Processing IDE itself as well as contextual menu when hilghighting functions & classes in the editor:
https://processing.org/reference/ https://processing.org/reference/
Openframeworks has been going in that direction, but the codebase is a lot larger and the underlying C++ requires more details to explain, etc hence the recent DocSprint. So far, the examples have been refreshed and lots of useful snippets & longer form tutorials/books have been put together:
New Learning page from last weekend: http://openframeworks.cc/learning/ http://openframeworks.cc/learning/ Existing reference: http://openframeworks.cc/documentation/ http://openframeworks.cc/documentation/
Here's the current OF website using markdown parsing & generation: https://github.com/openframeworks/ofSite https://github.com/openframeworks/ofSite
And here's a new approach to generating the OF documentation as a work in progress: https://github.com/halfdanj/ofdocumentationgenerator https://github.com/halfdanj/ofdocumentationgenerator
Here's a couple docs and workflows that have come out of and/or been generated by the DocSprint work:
https://hackpad.com/API-Documentation-Overview-wCQ4J5hrBbW https://hackpad.com/API-Documentation-Overview-wCQ4J5hrBbW
https://github.com/openframeworks/openFrameworks/wiki/Examples-Contribution-... https://github.com/openframeworks/openFrameworks/wiki/Examples-Contribution-Process-Flow
I feel one of the best aspects of PD are the examples via help patches so maybe splitting things up outside of PD might work against that? However, this would allow for a place for larger scale information as well as images, embed, etc.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Feb 26, 2016, at 5:20 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
Do you have a spec from that sprint?
On Friday, February 26, 2016 7:08 PM, Dan Wilcox danomatika@gmail.com wrote:
Also, my thinking is going in this direction as we’re dealing with the same issues in the OpenFrameworks community. My uni department just hosted an OF DocSprint last weekend and we spent a good amount of time wrangling how best to integrate a Markdown + Doxygen generated reference system.
Of course pure data patch files and C++ source files are somewhat different, but I feel there are the same issues to solve such as what requires the most maintenance, works on all platforms, and is easy for non developer contributors to use. It’s one thing to build a custom system (we did) and quite another to get people to pitch in and fill the content in. I just wouldn’t want anyone to spend a lot of time making something admittedly cool and built into the canvas but, in the end, may not be leveraged by the community the same way a portable, easy to edit, cross platform standard might.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Feb 26, 2016, at 5:01 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote:
Ok, so which html reference system should I leverage here?
Probably something using css and an html template that make it easy for people to fill out. I’d say 1 main html file for each object to document w/ room for sub pages if needed. Different languages can live in different folders.
The nice thing about this approach is lots of people can edit html, there are plenty of designers, the files can be rendered by pretty much anything, etc. Another option is to have a templating system that uses Markdown, etc and just renders to html. It can then live in it’s own source repository for shared work and be used as a basis for online as well as distributed documentation.
Maybe a good start would be to look at the pure data object database/wiki that is around somewhere. I can’t find the link off the top of my head.
Where will the html files get stored, and how do we get from clicking the link in the help patch (I'm assuming we're still using the current help patches to show a simple demo of the object) to opening the html doc in the correct language?
Just like opening a help patch with a context menu option or maybe links we can open from the patch itself. Use the current help paths for searching and use tcl to launch the path in the system web browser if found.
I’d say the most useful thing would be add linking between patches and external files (html, etc) in general. I believe Hans had this in extended for the pd-doc stuff.
I’m suggesting this approach partially so you/we don’t end up reinventing the wheel. A custom, integrated system would be *nice* but I feel that will require too much backend work to build and them probably too much work to maintain/extend in the future. HTML+CSS has the option of being loaded into a web view within TK I imagine, so another option would be a side pane or extra window that can open up right in PD. I’d suggest staying away from building extra widgets etc to render a custom approach within the patch itself.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Feb 26, 2016, at 4:44 PM, Jonathan Wilkes <jancsika@yahoo.com mailto:jancsika@yahoo.com> wrote:
-Jonathan
On Friday, February 26, 2016 4:34 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote:
I think what implying is that maybe Pd *doesn’t* need to handle it. Simply, Pd could open a local webpage, similar to how the Processing “Find in reference” context menu option works when highlighting a function in the editor.
Not to say you/we can’t work out a file format/system to handle alot of this, but I’m thinking that html reference already works well for many other contexts an doesn’t require building new formats/systems to solve alot of the same problems.
Dan Wilcox @danomatika applewebdata://96F4F5D1-3E0A-4AD4-9631-E5166A5794FB danomatika.com applewebdata://96F4F5D1-3E0A-4AD4-9631-E5166A5794FB robotcowboy.com applewebdata://96F4F5D1-3E0A-4AD4-9631-E5166A5794FB
On Feb 26, 2016, at 2:08 PM, Jonathan Wilkes <jancsika@yahoo.com applewebdata://96F4F5D1-3E0A-4AD4-9631-E5166A5794FB> wrote:
html could be leveraged, but I'm really looking for a spec for how Pd handles it. Is it a GUI widget? An abstraction? A canvas method? A new "#" directive?
Do the translations get saved along with the help patch, or are they stored in a directory and fetched when needed? Etc.
-Jonathan
On Friday, February 26, 2016 1:02 PM, Dan Wilcox <danomatika@gmail.com applewebdata://96F4F5D1-3E0A-4AD4-9631-E5166A5794FB> wrote:
I'll implement any *clear* spec for multi-language help patches someone comes up with with the following constraints:
- it separates design from content.
- in only requires documentation writers to care about content.
- it does not pigeonhole help patches into having a single, ugly design
- documentation writers will be guaranteed that whatever they write, it won't
overlap patch content. 5. it is maintainable and scalable
Sounds like .html.
Dan Wilcox @danomatika applewebdata://96F4F5D1-3E0A-4AD4-9631-E5166A5794FB danomatika.com applewebdata://96F4F5D1-3E0A-4AD4-9631-E5166A5794FB robotcowboy.com applewebdata://96F4F5D1-3E0A-4AD4-9631-E5166A5794FB
Pd-list@lists.iem.at applewebdata://96F4F5D1-3E0A-4AD4-9631-E5166A5794FB mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list applewebdata://96F4F5D1-3E0A-4AD4-9631-E5166A5794FB
Can it be done with puredata.info?
Mensaje telepatico asistido por maquinas.
From: danomatika@gmail.com Date: Fri, 26 Feb 2016 17:35:58 -0700 To: jancsika@yahoo.com CC: pd-list@lists.iem.at Subject: Re: [PD] multi-language help patches
I'd look at how the processing team has put their site/reference together:https://github.com/processing/processing-docs It's basically using a php engine with content written and parsed in xml. Each function/class to be documented has it's own file and each file starts form a template which the author then just needs to fill out. I'm not suggesting using xml, etc but I like the layout from an editing & parsing perspective. And this is the processing reference, which I feel is a great model for a teaching/arts environment (aka good balance towards readability for beginners and the important info for pros). This section is also included when you download Processing and opened automatically via a link form the Processing IDE itself as well as contextual menu when hilghighting functions & classes in the editor: https://processing.org/reference/ Openframeworks has been going in that direction, but the codebase is a lot larger and the underlying C++ requires more details to explain, etc hence the recent DocSprint. So far, the examples have been refreshed and lots of useful snippets & longer form tutorials/books have been put together: New Learning page from last weekend: http://openframeworks.cc/learning/Existing reference: http://openframeworks.cc/documentation/ Here's the current OF website using markdown parsing & generation:https://github.com/openframeworks/ofSite And here's a new approach to generating the OF documentation as a work in progress:https://github.com/halfdanj/ofdocumentationgenerator Here's a couple docs and workflows that have come out of and/or been generated by the DocSprint work: https://hackpad.com/API-Documentation-Overview-wCQ4J5hrBbW https://github.com/openframeworks/openFrameworks/wiki/Examples-Contribution-... I feel one of the best aspects of PD are the examples via help patches so maybe splitting things up outside of PD might work against that? However, this would allow for a place for larger scale information as well as images, embed, etc.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Feb 26, 2016, at 5:20 PM, Jonathan Wilkes jancsika@yahoo.com wrote:Do you have a spec from that sprint?
On Friday, February 26, 2016 7:08 PM, Dan Wilcox <danomatika@gmail.com> wrote:
Also, my thinking is going in this direction as we’re dealing with the same issues in the OpenFrameworks community. My uni department just hosted an OF DocSprint last weekend and we spent a good amount of time wrangling how best to integrate a Markdown + Doxygen generated reference system.Of course pure data patch files and C++ source files are somewhat different, but I feel there are the same issues to solve such as what requires the most maintenance, works on all platforms, and is easy for non developer contributors to use. It’s one thing to build a custom system (we did) and quite another to get people to pitch in and fill the content in. I just wouldn’t want anyone to spend a lot of time making something admittedly cool and built into the canvas but, in the end, may not be leveraged by the community the same way a portable, easy to edit, cross platform standard might. --------Dan Wilcox@danomatikadanomatika.comrobotcowboy.com
On Feb 26, 2016, at 5:01 PM, Dan Wilcox danomatika@gmail.com wrote:Ok, so which html reference system should I leverage here?Probably something using css and an html template that make it easy for people to fill out. I’d say 1 main html file for each object to document w/ room for sub pages if needed. Different languages can live in different folders.The nice thing about this approach is lots of people can edit html, there are plenty of designers, the files can be rendered by pretty much anything, etc. Another option is to have a templating system that uses Markdown, etc and just renders to html. It can then live in it’s own source repository for shared work and be used as a basis for online as well as distributed documentation.Maybe a good start would be to look at the pure data object database/wiki that is around somewhere. I can’t find the link off the top of my head.Where will the html files get stored, and how do we get from clicking the link in the help patch (I'm assuming we're still using the current help patches to show a simple demo of the object) to opening the html doc in the correct language?Just like opening a help patch with a context menu option or maybe links we can open from the patch itself. Use the current help paths for searching and use tcl to launch the path in the system web browser if found.I’d say the most useful thing would be add linking between patches and external files (html, etc) in general. I believe Hans had this in extended for the pd-doc stuff.I’m suggesting this approach partially so you/we don’t end up reinventing the wheel. A custom, integrated system would be *nice* but I feel that will require too much backend work to build and them probably too much work to maintain/extend in the future. HTML+CSS has the option of being loaded into a web view within TK I imagine, so another option would be a side pane or extra window that can open up right in PD. I’d suggest staying away from building extra widgets etc to render a custom approach within the patch itself. --------Dan Wilcox@danomatikadanomatika.comrobotcowboy.com
On Feb 26, 2016, at 4:44 PM, Jonathan Wilkes jancsika@yahoo.com wrote:-Jonathan On Friday, February 26, 2016 4:34 PM, Dan Wilcox danomatika@gmail.com wrote: I think what implying is that maybe Pd *doesn’t* need to handle it. Simply, Pd could open a local webpage, similar to how the Processing “Find in reference” context menu option works when highlighting a function in the editor.Not to say you/we can’t work out a file format/system to handle alot of this, but I’m thinking that html reference already works well for many other contexts an doesn’t require building new formats/systems to solve alot of the same problems. --------Dan Wilcox@danomatikadanomatika.comrobotcowboy.com
On Feb 26, 2016, at 2:08 PM, Jonathan Wilkes jancsika@yahoo.com wrote:html could be leveraged, but I'm really looking for a spec for how Pd handles it. Is it a GUI widget? An abstraction? A canvas method? A new "#" directive?Do the translations get saved along with the help patch, or are they stored in a directory and fetched when needed? Etc.-Jonathan On Friday, February 26, 2016 1:02 PM, Dan Wilcox danomatika@gmail.com wrote: I'll implement any *clear* spec for multi-language help patches someone comes up with with the following constraints:1. it separates design from content.2. in only requires documentation writers to care about content.3. it does not pigeonhole help patches into having a single, ugly design4. documentation writers will be guaranteed that whatever they write, it won't overlap patch content.5. it is maintainable and scalableSounds like .html. --------Dan Wilcox@danomatikadanomatika.comrobotcowboy.com_______________________________________________Pd-list@lists.iem.at mailing listUNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I’m suggesting that both website docs AND local docs opened in/by Pd can be the same html+media.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Feb 26, 2016, at 6:09 PM, Lucas Cordiviola lucarda27@hotmail.com wrote:
Can it be done with puredata.info http://puredata.info/?
Mensaje telepatico asistido por maquinas.
From: danomatika@gmail.com Date: Fri, 26 Feb 2016 17:35:58 -0700 To: jancsika@yahoo.com CC: pd-list@lists.iem.at Subject: Re: [PD] multi-language help patches
I'd look at how the processing team has put their site/reference together: https://github.com/processing/processing-docs https://github.com/processing/processing-docs
It's basically using a php engine with content written and parsed in xml. Each function/class to be documented has it's own file and each file starts form a template which the author then just needs to fill out. I'm not suggesting using xml, etc but I like the layout from an editing & parsing perspective.
And this is the processing reference, which I feel is a great model for a teaching/arts environment (aka good balance towards readability for beginners and the important info for pros). This section is also included when you download Processing and opened automatically via a link form the Processing IDE itself as well as contextual menu when hilghighting functions & classes in the editor:
https://processing.org/reference/ https://processing.org/reference/
Openframeworks has been going in that direction, but the codebase is a lot larger and the underlying C++ requires more details to explain, etc hence the recent DocSprint. So far, the examples have been refreshed and lots of useful snippets & longer form tutorials/books have been put together:
New Learning page from last weekend: http://openframeworks.cc/learning/ http://openframeworks.cc/learning/ Existing reference: http://openframeworks.cc/documentation/ http://openframeworks.cc/documentation/
Here's the current OF website using markdown parsing & generation: https://github.com/openframeworks/ofSite https://github.com/openframeworks/ofSite
And here's a new approach to generating the OF documentation as a work in progress: https://github.com/halfdanj/ofdocumentationgenerator https://github.com/halfdanj/ofdocumentationgenerator
Here's a couple docs and workflows that have come out of and/or been generated by the DocSprint work:
https://hackpad.com/API-Documentation-Overview-wCQ4J5hrBbW https://hackpad.com/API-Documentation-Overview-wCQ4J5hrBbW
https://github.com/openframeworks/openFrameworks/wiki/Examples-Contribution-... https://github.com/openframeworks/openFrameworks/wiki/Examples-Contribution-Process-Flow
I feel one of the best aspects of PD are the examples via help patches so maybe splitting things up outside of PD might work against that? However, this would allow for a place for larger scale information as well as images, embed, etc.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/ On Feb 26, 2016, at 5:20 PM, Jonathan Wilkes <jancsika@yahoo.com mailto:jancsika@yahoo.com> wrote:
Do you have a spec from that sprint?
On Friday, February 26, 2016 7:08 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote:
Also, my thinking is going in this direction as we’re dealing with the same issues in the OpenFrameworks community. My uni department just hosted an OF DocSprint last weekend and we spent a good amount of time wrangling how best to integrate a Markdown + Doxygen generated reference system.
Of course pure data patch files and C++ source files are somewhat different, but I feel there are the same issues to solve such as what requires the most maintenance, works on all platforms, and is easy for non developer contributors to use. It’s one thing to build a custom system (we did) and quite another to get people to pitch in and fill the content in. I just wouldn’t want anyone to spend a lot of time making something admittedly cool and built into the canvas but, in the end, may not be leveraged by the community the same way a portable, easy to edit, cross platform standard might.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/ On Feb 26, 2016, at 5:01 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote:
Ok, so which html reference system should I leverage here?
Probably something using css and an html template that make it easy for people to fill out. I’d say 1 main html file for each object to document w/ room for sub pages if needed. Different languages can live in different folders.
The nice thing about this approach is lots of people can edit html, there are plenty of designers, the files can be rendered by pretty much anything, etc. Another option is to have a templating system that uses Markdown, etc and just renders to html. It can then live in it’s own source repository for shared work and be used as a basis for online as well as distributed documentation.
Maybe a good start would be to look at the pure data object database/wiki that is around somewhere. I can’t find the link off the top of my head.
Where will the html files get stored, and how do we get from clicking the link in the help patch (I'm assuming we're still using the current help patches to show a simple demo of the object) to opening the html doc in the correct language?
Just like opening a help patch with a context menu option or maybe links we can open from the patch itself. Use the current help paths for searching and use tcl to launch the path in the system web browser if found.
I’d say the most useful thing would be add linking between patches and external files (html, etc) in general. I believe Hans had this in extended for the pd-doc stuff.
I’m suggesting this approach partially so you/we don’t end up reinventing the wheel. A custom, integrated system would be *nice* but I feel that will require too much backend work to build and them probably too much work to maintain/extend in the future. HTML+CSS has the option of being loaded into a web view within TK I imagine, so another option would be a side pane or extra window that can open up right in PD. I’d suggest staying away from building extra widgets etc to render a custom approach within the patch itself.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/ On Feb 26, 2016, at 4:44 PM, Jonathan Wilkes <jancsika@yahoo.com mailto:jancsika@yahoo.com> wrote:
-Jonathan
On Friday, February 26, 2016 4:34 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote:
I think what implying is that maybe Pd *doesn’t* need to handle it. Simply, Pd could open a local webpage, similar to how the Processing “Find in reference” context menu option works when highlighting a function in the editor.
Not to say you/we can’t work out a file format/system to handle alot of this, but I’m thinking that html reference already works well for many other contexts an doesn’t require building new formats/systems to solve alot of the same problems.
Dan Wilcox @danomatika https:/ danomatika.com https:/ robotcowboy.com https:/ On Feb 26, 2016, at 2:08 PM, Jonathan Wilkes <jancsika@yahoo.com https:/> wrote:
html could be leveraged, but I'm really looking for a spec for how Pd handles it. Is it a GUI widget? An abstraction? A canvas method? A new "#" directive?
Do the translations get saved along with the help patch, or are they stored in a directory and fetched when needed? Etc.
-Jonathan
On Friday, February 26, 2016 1:02 PM, Dan Wilcox <danomatika@gmail.com https:/> wrote:
I'll implement any *clear* spec for multi-language help patches someone comes up with with the following constraints:
- it separates design from content.
- in only requires documentation writers to care about content.
- it does not pigeonhole help patches into having a single, ugly design
- documentation writers will be guaranteed that whatever they write, it won't
overlap patch content. 5. it is maintainable and scalable
Sounds like .html.
Dan Wilcox @danomatika https:/ danomatika.com https:/ robotcowboy.com https:/
Pd-list@lists.iem.at https:/ mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list https:/
_______________________________________________ Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
If you open the osc~ help patch there is a pdpedia link which points to http://wiki.puredata.info/en/osc~ that don't exist yet. Probably the html+media is the most posible html help file (multilingual) which is NOT an pd-help file. Also html could possible be a better help file. (css, font , zooming, multilingual, etc) Mensaje telepatico asistido por maquinas.
Subject: Re: [PD] multi-language help patches From: danomatika@gmail.com Date: Fri, 26 Feb 2016 18:25:18 -0700 CC: pd-list@lists.iem.at To: lucarda27@hotmail.com
I’m suggesting that both website docs AND local docs opened in/by Pd can be the same html+media.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Feb 26, 2016, at 6:09 PM, Lucas Cordiviola lucarda27@hotmail.com wrote:Can it be done with puredata.info?
Mensaje telepatico asistido por maquinas.
From: danomatika@gmail.com Date: Fri, 26 Feb 2016 17:35:58 -0700 To: jancsika@yahoo.com CC: pd-list@lists.iem.at Subject: Re: [PD] multi-language help patches
I'd look at how the processing team has put their site/reference together:https://github.com/processing/processing-docs It's basically using a php engine with content written and parsed in xml. Each function/class to be documented has it's own file and each file starts form a template which the author then just needs to fill out. I'm not suggesting using xml, etc but I like the layout from an editing & parsing perspective. And this is the processing reference, which I feel is a great model for a teaching/arts environment (aka good balance towards readability for beginners and the important info for pros). This section is also included when you download Processing and opened automatically via a link form the Processing IDE itself as well as contextual menu when hilghighting functions & classes in the editor: https://processing.org/reference/ Openframeworks has been going in that direction, but the codebase is a lot larger and the underlying C++ requires more details to explain, etc hence the recent DocSprint. So far, the examples have been refreshed and lots of useful snippets & longer form tutorials/books have been put together: New Learning page from last weekend: http://openframeworks.cc/learning/Existing reference: http://openframeworks.cc/documentation/ Here's the current OF website using markdown parsing & generation:https://github.com/openframeworks/ofSite And here's a new approach to generating the OF documentation as a work in progress:https://github.com/halfdanj/ofdocumentationgenerator Here's a couple docs and workflows that have come out of and/or been generated by the DocSprint work: https://hackpad.com/API-Documentation-Overview-wCQ4J5hrBbW https://github.com/openframeworks/openFrameworks/wiki/Examples-Contribution-... I feel one of the best aspects of PD are the examples via help patches so maybe splitting things up outside of PD might work against that? However, this would allow for a place for larger scale information as well as images, embed, etc.
Dan Wilcox @danomatika danomatika.com robotcowboy.com On Feb 26, 2016, at 5:20 PM, Jonathan Wilkes jancsika@yahoo.com wrote:Do you have a spec from that sprint?
On Friday, February 26, 2016 7:08 PM, Dan Wilcox danomatika@gmail.com wrote:
Also, my thinking is going in this direction as we’re dealing with the same issues in the OpenFrameworks community. My uni department just hosted an OF DocSprint last weekend and we spent a good amount of time wrangling how best to integrate a Markdown + Doxygen generated reference system.Of course pure data patch files and C++ source files are somewhat different, but I feel there are the same issues to solve such as what requires the most maintenance, works on all platforms, and is easy for non developer contributors to use. It’s one thing to build a custom system (we did) and quite another to get people to pitch in and fill the content in. I just wouldn’t want anyone to spend a lot of time making something admittedly cool and built into the canvas but, in the end, may not be leveraged by the community the same way a portable, easy to edit, cross platform standard might.--------Dan Wilcox@danomatikadanomatika.comrobotcowboy.comOn Feb 26, 2016, at 5:01 PM, Dan Wilcox danomatika@gmail.com wrote:Ok, so which html reference system should I leverage here?Probably something using css and an html template that make it easy for people to fill out. I’d say 1 main html file for each object to document w/ room for sub pages if needed. Different languages can live in different folders.The nice thing about this approach is lots of people can edit html, there are plenty of designers, the files can be rendered by pretty much anything, etc. Another option is to have a templating system that uses Markdown, etc and just renders to html. It can then live in it’s own source repository for shared work and be used as a basis for online as well as distributed documentation.Maybe a good start would be to look at the pure data object database/wiki that is around somewhere. I can’t find the link off the top of my head.Where will the html files get stored, and how do we get from clicking the link in the help patch (I'm assuming we're still using the current help patches to show a simple demo of the object) to opening the html doc in the correct language?Just like opening a help patch with a context menu option or maybe links we can open from the patch itself. Use the current help paths for searching and use tcl to launch the path in the system web browser if found.I’d say the most useful thing would be add linking between patches and external files (html, etc) in general. I believe Hans had this in extended for the pd-doc stuff.I’m suggesting this approach partially so you/we don’t end up reinventing the wheel. A custom, integrated system would be *nice* but I feel that will require too much backend work to build and them probably too much work to maintain/extend in the future. HTML+CSS has the option of being loaded into a web view within TK I imagine, so another option would be a side pane or extra window that can open up right in PD. I’d suggest staying away from building extra widgets etc to render a custom approach within the patch itself.--------Dan Wilcox@danomatikadanomatika.comrobotcowboy.comOn Feb 26, 2016, at 4:44 PM, Jonathan Wilkes jancsika@yahoo.com wrote:-JonathanOn Friday, February 26, 2016 4:34 PM, Dan Wilcox danomatika@gmail.com wrote:I think what implying is that maybe Pd *doesn’t* need to handle it. Simply, Pd could open a local webpage, similar to how the Processing “Find in reference” context menu option works when highlighting a function in the editor.Not to say you/we can’t work out a file format/system to handle alot of this, but I’m thinking that html reference already works well for many other contexts an doesn’t require building new formats/systems to solve alot of the same problems.--------Dan Wilcox@danomatikadanomatika.comrobotcowboy.comOn Feb 26, 2016, at 2:08 PM, Jonathan Wilkes jancsika@yahoo.com wrote:html could be leveraged, but I'm really looking for a spec for how Pd handles it. Is it a GUI widget? An abstraction? A canvas method? A new "#" directive?Do the translations get saved along with the help patch, or are they stored in a directory and fetched when needed? Etc.-JonathanOn Friday, February 26, 2016 1:02 PM, Dan Wilcox danomatika@gmail.com wrote:I'll implement any *clear* spec for multi-language help patches someone comes up with with the following constraints:1. it separates design from content.2. in only requires documentation writers to care about content.3. it does not pigeonhole help patches into having a single, ugly design4. documentation writers will be guaranteed that whatever they write, it won't overlap patch content.5. it is maintainable and scalableSounds like .html.--------Dan Wilcox@danomatikadanomatika.comrobotcowboy.com_______________________________________________Pd-list@lists.iem.at mailing listUNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 02/27/2016 03:21 AM, Lucas Cordiviola wrote:
link which points to http://wiki.puredata.info/en/osc~ that don't exist yet.
well, given that pdpedia died a couple of years ago, the "yet" is slightly euphemistic.
gfmards IOhannes
Sorry, I didn`t know it lived in the past, never use it. Could we use wikipedia for that and somehow guarantee longevity, ease of use for the community, and multilingual html help files? Mensaje telepatico asistido por maquinas.
To: pd-list@lists.iem.at From: zmoelnig@iem.at Date: Sat, 27 Feb 2016 16:38:32 +0100 Subject: Re: [PD] multi-language help patches
On 02/27/2016 03:21 AM, Lucas Cordiviola wrote:
link which points to http://wiki.puredata.info/en/osc~ that don't exist yet.
well, given that pdpedia died a couple of years ago, the "yet" is slightly euphemistic.
gfmards IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Sorry, I didn`t know it lived in the past, never use it. Could we use wikipedia for that and somehow guarantee longevity, ease of use for the community, and multilingual html help files? Mensaje telepatico asistido por maquinas.
To: pd-list@lists.iem.at From: zmoelnig@iem.at Date: Sat, 27 Feb 2016 16:38:32 +0100 Subject: Re: [PD] multi-language help patches
On 02/27/2016 03:21 AM, Lucas Cordiviola wrote:
link which points to http://wiki.puredata.info/en/osc~ that don't exist yet.
well, given that pdpedia died a couple of years ago, the "yet" is slightly euphemistic.
gfmards IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I feel one of the best aspects of PD are the examples via help patches so maybe splitting things up outside of PD might work against that?
That is definitely a great feature. If there's a way to keep that and add sane multi-language support, that would be the way to go. -Jonathan
On Friday, February 26, 2016 7:08 PM, Dan Wilcox <danomatika@gmail.com> wrote:
Also, my thinking is going in this direction as we’re dealing with the same issues in the OpenFrameworks community. My uni department just hosted an OF DocSprint last weekend and we spent a good amount of time wrangling how best to integrate a Markdown + Doxygen generated reference system. Of course pure data patch files and C++ source files are somewhat different, but I feel there are the same issues to solve such as what requires the most maintenance, works on all platforms, and is easy for non developer contributors to use. It’s one thing to build a custom system (we did) and quite another to get people to pitch in and fill the content in. I just wouldn’t want anyone to spend a lot of time making something admittedly cool and built into the canvas but, in the end, may not be leveraged by the community the same way a portable, easy to edit, cross platform standard might.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Feb 26, 2016, at 5:01 PM, Dan Wilcox danomatika@gmail.com wrote:
Ok, so which html reference system should I leverage here?
Probably something using css and an html template that make it easy for people to fill out. I’d say 1 main html file for each object to document w/ room for sub pages if needed. Different languages can live in different folders. The nice thing about this approach is lots of people can edit html, there are plenty of designers, the files can be rendered by pretty much anything, etc. Another option is to have a templating system that uses Markdown, etc and just renders to html. It can then live in it’s own source repository for shared work and be used as a basis for online as well as distributed documentation. Maybe a good start would be to look at the pure data object database/wiki that is around somewhere. I can’t find the link off the top of my head.
Where will the html files get stored, and how do we get from clicking the link in the help patch (I'm assuming we're still using the current help patches to show a simple demo of the object) to opening the html doc in the correct language?
Just like opening a help patch with a context menu option or maybe links we can open from the patch itself. Use the current help paths for searching and use tcl to launch the path in the system web browser if found. I’d say the most useful thing would be add linking between patches and external files (html, etc) in general. I believe Hans had this in extended for the pd-doc stuff. I’m suggesting this approach partially so you/we don’t end up reinventing the wheel. A custom, integrated system would be *nice* but I feel that will require too much backend work to build and them probably too much work to maintain/extend in the future. HTML+CSS has the option of being loaded into a web view within TK I imagine, so another option would be a side pane or extra window that can open up right in PD. I’d suggest staying away from building extra widgets etc to render a custom approach within the patch itself.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Feb 26, 2016, at 4:44 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
-Jonathan
On Friday, February 26, 2016 4:34 PM, Dan Wilcox <danomatika@gmail.com> wrote:
I think what implying is that maybe Pd *doesn’t* need to handle it. Simply, Pd could open a local webpage, similar to how the Processing “Find in reference” context menu option works when highlighting a function in the editor. Not to say you/we can’t work out a file format/system to handle alot of this, but I’m thinking that html reference already works well for many other contexts an doesn’t require building new formats/systems to solve alot of the same problems.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Feb 26, 2016, at 2:08 PM, Jonathan Wilkes jancsika@yahoo.com wrote: html could be leveraged, but I'm really looking for a spec for how Pd handles it. Is it a GUI widget? An abstraction? A canvas method? A new "#" directive? Do the translations get saved along with the help patch, or are they stored in a directory and fetched when needed? Etc. -Jonathan
On Friday, February 26, 2016 1:02 PM, Dan Wilcox <danomatika@gmail.com> wrote:
I'll implement any *clear* spec for multi-language help patches someone comes up with with the following constraints:1. it separates design from content.2. in only requires documentation writers to care about content.3. it does not pigeonhole help patches into having a single, ugly design4. documentation writers will be guaranteed that whatever they write, it won't overlap patch content.5. it is maintainable and scalable
Sounds like .html.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
As an sketch:
pd nameoftheobject @wikipedia.org
pd osc~ or with the underscore pd_osc~
https://en.wikipedia.org/wiki/pd_osc~
It will be slow to fill objects but...
I feel one of the best aspects of PD are the examples via help patches so maybe splitting things up outside of PD might work against that?
That is definitely a great feature. If there's a way to keep that and add sane multi-language support, that would be the way to go.
Totally agree with that but perhaps that is just for the international english default (the standard default help system). Other languages could be HELPED in html format.
I`ve also proposed the translation of just the comments in *-help.pd files, but that seems difficult and language packs... Mensaje telepatico asistido por maquinas.
Em sáb, 27 de fev de 2016 15:46, Lucas Cordiviola lucarda27@hotmail.com escreveu:
As an sketch:
pd nameoftheobject @wikipedia.org
pd osc~ or with the underscore pd_osc~
https://en.wikipedia.org/wiki/pd_osc~
It will be slow to fill objects but...
I feel one of the best aspects of PD are the examples via help patches
so maybe splitting things up outside of PD might work against that?
That is definitely a great feature. If there's a way to keep that and add sane multi-language support, that would be the way to go.
Totally agree with that but perhaps that is just for the international english default (the standard default help system). Other languages could be HELPED in html format.
I`ve also proposed the translation of just the comments in *-help.pd files, but that seems difficult and language packs...
I think a comment object with better features yet is a great feature, but the weighing the high development cost, this html solution for helps, can do the community more active once it documentation, maybe, can privilege the http://forum.pdpatchrepo.info for example to promote more organized collaboration of learning issues between pd community.
Mensaje telepatico asistido por maquinas.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Eventually the user can make his particularly language translated patch:
Or it can be obteined with some href and an Id, not sure if its posible:
pd_object@wikipedia.org
<code>
#N canvas 20 43 698 447 12; #X floatatom 524 338 0 0 0; #X floatatom 353 338 0 0 0; #X floatatom 298 338 0 0 0; #X floatatom 413 338 0 0 0; #X floatatom 467 338 0 0 0; #X obj 524 311 <; #X obj 298 262 r left; #X obj 540 267 r right; #X floatatom 71 335 0 0 0; #X floatatom 19 334 0 0 0; #X floatatom 119 335 0 0 0; #X floatatom 163 334 0 0 0; #X obj 16 45 &; #X obj 66 45 |; #X obj 118 45 &&; #X obj 169 45 ||; #X obj 19 307 &; #X obj 71 308 |; #X obj 119 308 &&; #X obj 163 307 ||; #X text 13 73 uoyhbqrevfg qrepfgvb; #X obj 19 266 r left; #X obj 218 266 r right; #X obj 12 118 >; #X obj 61 118 >=; #X obj 114 118 ==; #X obj 215 119 <=; #X obj 262 119 <; #X text 11 153 ouyhqergf eqwrvgupoyhb; #X obj 298 312 >; #X obj 353 312 >=; #X obj 413 312 ==; #X obj 467 312 <=; #X text 16 190 piuqgherfpgiuhqerfg qerpfgiuberpigureg erpiuybqepirugbqerg qerpiyhbqperiugbqerg qepriyhbqepirgb
piybqergipub iuqberifvuhq[iuerhgfv qifvubqe[riuh[uheqrg piubqrguh ; #X floatatom 410 65 0 0 0; #X obj 410 92 s left; #X floatatom 481 66 0 0 0; #X obj 481 94 t b f; #X obj 481 122 s left; #X obj 541 122 s right; #X obj 166 118 !=; #X text 377 42 ouyvqdev qewrpfgvy; #X floatatom 202 335 0 0 0; #X floatatom 246 334 0 0 0; #X obj 208 46 <<; #X obj 259 46 >>; #X obj 202 308 <<; #X obj 246 307 >>; #X text 421 383 ouyvqwerfhb version 0.32; #X connect 5 0 0 0; #X connect 6 0 29 0; #X connect 6 0 30 0; #X connect 6 0 31 0; #X connect 6 0 32 0; #X connect 6 0 5 0; #X connect 7 0 29 1; #X connect 7 0 30 1; #X connect 7 0 31 1; #X connect 7 0 32 1; #X connect 7 0 5 1; #X connect 16 0 9 0; #X connect 17 0 8 0; #X connect 18 0 10 0; #X connect 19 0 11 0; #X connect 21 0 16 0; #X connect 21 0 17 0; #X connect 21 0 18 0; #X connect 21 0 19 0; #X connect 21 0 46 0; #X connect 21 0 47 0; #X connect 22 0 19 1; #X connect 22 0 18 1; #X connect 22 0 17 1; #X connect 22 0 16 1; #X connect 22 0 47 1; #X connect 22 0 46 1; #X connect 29 0 2 0; #X connect 30 0 1 0; #X connect 31 0 3 0; #X connect 32 0 4 0; #X connect 34 0 35 0; #X connect 36 0 37 0; #X connect 37 0 38 0; #X connect 37 1 39 0; #X connect 46 0 42 0; #X connect 47 0 43 0;
</code> Mensaje telepatico asistido por maquinas.
From: emviveros@gmail.com Date: Sat, 27 Feb 2016 19:19:33 +0000 Subject: Re: [PD] multi-language help patches To: lucarda27@hotmail.com; pd-list@lists.iem.at
Em sáb, 27 de fev de 2016 15:46, Lucas Cordiviola lucarda27@hotmail.com escreveu:
As an sketch:
pd nameoftheobject @wikipedia.org
pd osc~ or with the underscore pd_osc~
https://en.wikipedia.org/wiki/pd_osc~
It will be slow to fill objects but...
I feel one of the best aspects of PD are the examples via help patches so maybe splitting things up outside of PD might work against that?
That is definitely a great feature. If there's a way to keep that and add sane multi-language support, that would be the way to go.
Totally agree with that but perhaps that is just for the international english default (the standard default help system). Other languages could be HELPED in html format.
I`ve also proposed the translation of just the comments in *-help.pd files, but that seems difficult and language packs... I think a comment object with better features yet is a great feature, but the weighing the high development cost, this html solution for helps, can do the community more active once it documentation, maybe, can privilege the http://forum.pdpatchrepo.info for example to promote more organized collaboration of learning issues between pd community.
Mensaje telepatico asistido por maquinas.
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Of course if we`re gonna use wikipedia.org as storage for encoded html information of a software we should tell them about it an ask for their permission.
Probably they say no.
So we will be looking for another server.
But... Mensaje telepatico asistido por maquinas.
From: lucarda27@hotmail.com To: pd-list@lists.iem.at Date: Sat, 27 Feb 2016 20:37:37 +0000 Subject: Re: [PD] multi-language help patches
Eventually the user can make his particularly language translated patch:
Or it can be obteined with some href and an Id, not sure if its posible:
pd_object@wikipedia.org
<code>
#N canvas 20 43 698 447 12; #X floatatom 524 338 0 0 0; #X floatatom 353 338 0 0 0; #X floatatom 298 338 0 0 0; #X floatatom 413 338 0 0 0; #X floatatom 467 338 0 0 0; #X obj 524 311 <; #X obj 298 262 r left; #X obj 540 267 r right; #X floatatom 71 335 0 0 0; #X floatatom 19 334 0 0 0; #X floatatom 119 335 0 0 0; #X floatatom 163 334 0 0 0; #X obj 16 45 &; #X obj 66 45 |; #X obj 118 45 &&; #X obj 169 45 ||; #X obj 19 307 &; #X obj 71 308 |; #X obj 119 308 &&; #X obj 163 307 ||; #X text 13 73 uoyhbqrevfg qrepfgvb; #X obj 19 266 r left; #X obj 218 266 r right; #X obj 12 118 >; #X obj 61 118 >=; #X obj 114 118 ==; #X obj 215 119 <=; #X obj 262 119 <; #X text 11 153 ouyhqergf eqwrvgupoyhb; #X obj 298 312 >; #X obj 353 312 >=; #X obj 413 312 ==; #X obj 467 312 <=; #X text 16 190 piuqgherfpgiuhqerfg qerpfgiuberpigureg erpiuybqepirugbqerg qerpiyhbqperiugbqerg qepriyhbqepirgb
piybqergipub iuqberifvuhq[iuerhgfv qifvubqe[riuh[uheqrg piubqrguh ; #X floatatom 410 65 0 0 0; #X obj 410 92 s left; #X floatatom 481 66 0 0 0; #X obj 481 94 t b f; #X obj 481 122 s left; #X obj 541 122 s right; #X obj 166 118 !=; #X text 377 42 ouyvqdev qewrpfgvy; #X floatatom 202 335 0 0 0; #X floatatom 246 334 0 0 0; #X obj 208 46 <<; #X obj 259 46 >>; #X obj 202 308 <<; #X obj 246 307 >>; #X text 421 383 ouyvqwerfhb version 0.32; #X connect 5 0 0 0; #X connect 6 0 29 0; #X connect 6 0 30 0; #X connect 6 0 31 0; #X connect 6 0 32 0; #X connect 6 0 5 0; #X connect 7 0 29 1; #X connect 7 0 30 1; #X connect 7 0 31 1; #X connect 7 0 32 1; #X connect 7 0 5 1; #X connect 16 0 9 0; #X connect 17 0 8 0; #X connect 18 0 10 0; #X connect 19 0 11 0; #X connect 21 0 16 0; #X connect 21 0 17 0; #X connect 21 0 18 0; #X connect 21 0 19 0; #X connect 21 0 46 0; #X connect 21 0 47 0; #X connect 22 0 19 1; #X connect 22 0 18 1; #X connect 22 0 17 1; #X connect 22 0 16 1; #X connect 22 0 47 1; #X connect 22 0 46 1; #X connect 29 0 2 0; #X connect 30 0 1 0; #X connect 31 0 3 0; #X connect 32 0 4 0; #X connect 34 0 35 0; #X connect 36 0 37 0; #X connect 37 0 38 0; #X connect 37 1 39 0; #X connect 46 0 42 0; #X connect 47 0 43 0;
</code> Mensaje telepatico asistido por maquinas.
From: emviveros@gmail.com Date: Sat, 27 Feb 2016 19:19:33 +0000 Subject: Re: [PD] multi-language help patches To: lucarda27@hotmail.com; pd-list@lists.iem.at
Em sáb, 27 de fev de 2016 15:46, Lucas Cordiviola lucarda27@hotmail.com escreveu:
As an sketch:
pd nameoftheobject @wikipedia.org
pd osc~ or with the underscore pd_osc~
https://en.wikipedia.org/wiki/pd_osc~
It will be slow to fill objects but...
I feel one of the best aspects of PD are the examples via help patches so maybe splitting things up outside of PD might work against that?
That is definitely a great feature. If there's a way to keep that and add sane multi-language support, that would be the way to go.
Totally agree with that but perhaps that is just for the international english default (the standard default help system). Other languages could be HELPED in html format.
I`ve also proposed the translation of just the comments in *-help.pd files, but that seems difficult and language packs... I think a comment object with better features yet is a great feature, but the weighing the high development cost, this html solution for helps, can do the community more active once it documentation, maybe, can privilege the http://forum.pdpatchrepo.info for example to promote more organized collaboration of learning issues between pd community.
Mensaje telepatico asistido por maquinas.
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
There are chances that we`re welcome at wikipedia.
Mensaje telepatico asistido por maquinas.
From: lucarda27@hotmail.com To: pd-list@lists.iem.at Date: Sat, 27 Feb 2016 21:18:01 +0000 Subject: Re: [PD] multi-language help patches
Of course if we`re gonna use wikipedia.org as storage for encoded html information of a software we should tell them about it an ask for their permission.
Probably they say no.
So we will be looking for another server.
But... Mensaje telepatico asistido por maquinas.
From: lucarda27@hotmail.com To: pd-list@lists.iem.at Date: Sat, 27 Feb 2016 20:37:37 +0000 Subject: Re: [PD] multi-language help patches
Eventually the user can make his particularly language translated patch:
Or it can be obteined with some href and an Id, not sure if its posible:
pd_object@wikipedia.org
<code>
#N canvas 20 43 698 447 12; #X floatatom 524 338 0 0 0; #X floatatom 353 338 0 0 0; #X floatatom 298 338 0 0 0; #X floatatom 413 338 0 0 0; #X floatatom 467 338 0 0 0; #X obj 524 311 <; #X obj 298 262 r left; #X obj 540 267 r right; #X floatatom 71 335 0 0 0; #X floatatom 19 334 0 0 0; #X floatatom 119 335 0 0 0; #X floatatom 163 334 0 0 0; #X obj 16 45 &; #X obj 66 45 |; #X obj 118 45 &&; #X obj 169 45 ||; #X obj 19 307 &; #X obj 71 308 |; #X obj 119 308 &&; #X obj 163 307 ||; #X text 13 73 uoyhbqrevfg qrepfgvb; #X obj 19 266 r left; #X obj 218 266 r right; #X obj 12 118 >; #X obj 61 118 >=; #X obj 114 118 ==; #X obj 215 119 <=; #X obj 262 119 <; #X text 11 153 ouyhqergf eqwrvgupoyhb; #X obj 298 312 >; #X obj 353 312 >=; #X obj 413 312 ==; #X obj 467 312 <=; #X text 16 190 piuqgherfpgiuhqerfg qerpfgiuberpigureg erpiuybqepirugbqerg qerpiyhbqperiugbqerg qepriyhbqepirgb
piybqergipub iuqberifvuhq[iuerhgfv qifvubqe[riuh[uheqrg piubqrguh ; #X floatatom 410 65 0 0 0; #X obj 410 92 s left; #X floatatom 481 66 0 0 0; #X obj 481 94 t b f; #X obj 481 122 s left; #X obj 541 122 s right; #X obj 166 118 !=; #X text 377 42 ouyvqdev qewrpfgvy; #X floatatom 202 335 0 0 0; #X floatatom 246 334 0 0 0; #X obj 208 46 <<; #X obj 259 46 >>; #X obj 202 308 <<; #X obj 246 307 >>; #X text 421 383 ouyvqwerfhb version 0.32; #X connect 5 0 0 0; #X connect 6 0 29 0; #X connect 6 0 30 0; #X connect 6 0 31 0; #X connect 6 0 32 0; #X connect 6 0 5 0; #X connect 7 0 29 1; #X connect 7 0 30 1; #X connect 7 0 31 1; #X connect 7 0 32 1; #X connect 7 0 5 1; #X connect 16 0 9 0; #X connect 17 0 8 0; #X connect 18 0 10 0; #X connect 19 0 11 0; #X connect 21 0 16 0; #X connect 21 0 17 0; #X connect 21 0 18 0; #X connect 21 0 19 0; #X connect 21 0 46 0; #X connect 21 0 47 0; #X connect 22 0 19 1; #X connect 22 0 18 1; #X connect 22 0 17 1; #X connect 22 0 16 1; #X connect 22 0 47 1; #X connect 22 0 46 1; #X connect 29 0 2 0; #X connect 30 0 1 0; #X connect 31 0 3 0; #X connect 32 0 4 0; #X connect 34 0 35 0; #X connect 36 0 37 0; #X connect 37 0 38 0; #X connect 37 1 39 0; #X connect 46 0 42 0; #X connect 47 0 43 0;
</code> Mensaje telepatico asistido por maquinas.
From: emviveros@gmail.com Date: Sat, 27 Feb 2016 19:19:33 +0000 Subject: Re: [PD] multi-language help patches To: lucarda27@hotmail.com; pd-list@lists.iem.at
Em sáb, 27 de fev de 2016 15:46, Lucas Cordiviola lucarda27@hotmail.com escreveu:
As an sketch:
pd nameoftheobject @wikipedia.org
pd osc~ or with the underscore pd_osc~
https://en.wikipedia.org/wiki/pd_osc~
It will be slow to fill objects but...
I feel one of the best aspects of PD are the examples via help patches so maybe splitting things up outside of PD might work against that?
That is definitely a great feature. If there's a way to keep that and add sane multi-language support, that would be the way to go.
Totally agree with that but perhaps that is just for the international english default (the standard default help system). Other languages could be HELPED in html format.
I`ve also proposed the translation of just the comments in *-help.pd files, but that seems difficult and language packs... I think a comment object with better features yet is a great feature, but the weighing the high development cost, this html solution for helps, can do the community more active once it documentation, maybe, can privilege the http://forum.pdpatchrepo.info for example to promote more organized collaboration of learning issues between pd community.
Mensaje telepatico asistido por maquinas.
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Probably an html server can provide both things, the html help AND the translated patch in the same url.
Whats important is that in can be completed/translated by users.
Wikipedia is the most familiar one to almost everyone. (perhaps I'm wrong here, not sure) Mensaje telepatico asistido por maquinas.
From: lucarda27@hotmail.com To: pd-list@lists.iem.at Date: Sat, 27 Feb 2016 21:33:25 +0000 Subject: Re: [PD] multi-language help patches
There are chances that we`re welcome at wikipedia.
Mensaje telepatico asistido por maquinas.
From: lucarda27@hotmail.com To: pd-list@lists.iem.at Date: Sat, 27 Feb 2016 21:18:01 +0000 Subject: Re: [PD] multi-language help patches
Of course if we`re gonna use wikipedia.org as storage for encoded html information of a software we should tell them about it an ask for their permission.
Probably they say no.
So we will be looking for another server.
But... Mensaje telepatico asistido por maquinas.
From: lucarda27@hotmail.com To: pd-list@lists.iem.at Date: Sat, 27 Feb 2016 20:37:37 +0000 Subject: Re: [PD] multi-language help patches
Eventually the user can make his particularly language translated patch:
Or it can be obteined with some href and an Id, not sure if its posible:
pd_object@wikipedia.org
<code>
#N canvas 20 43 698 447 12; #X floatatom 524 338 0 0 0; #X floatatom 353 338 0 0 0; #X floatatom 298 338 0 0 0; #X floatatom 413 338 0 0 0; #X floatatom 467 338 0 0 0; #X obj 524 311 <; #X obj 298 262 r left; #X obj 540 267 r right; #X floatatom 71 335 0 0 0; #X floatatom 19 334 0 0 0; #X floatatom 119 335 0 0 0; #X floatatom 163 334 0 0 0; #X obj 16 45 &; #X obj 66 45 |; #X obj 118 45 &&; #X obj 169 45 ||; #X obj 19 307 &; #X obj 71 308 |; #X obj 119 308 &&; #X obj 163 307 ||; #X text 13 73 uoyhbqrevfg qrepfgvb; #X obj 19 266 r left; #X obj 218 266 r right; #X obj 12 118 >; #X obj 61 118 >=; #X obj 114 118 ==; #X obj 215 119 <=; #X obj 262 119 <; #X text 11 153 ouyhqergf eqwrvgupoyhb; #X obj 298 312 >; #X obj 353 312 >=; #X obj 413 312 ==; #X obj 467 312 <=; #X text 16 190 piuqgherfpgiuhqerfg qerpfgiuberpigureg erpiuybqepirugbqerg qerpiyhbqperiugbqerg qepriyhbqepirgb
piybqergipub iuqberifvuhq[iuerhgfv qifvubqe[riuh[uheqrg piubqrguh ; #X floatatom 410 65 0 0 0; #X obj 410 92 s left; #X floatatom 481 66 0 0 0; #X obj 481 94 t b f; #X obj 481 122 s left; #X obj 541 122 s right; #X obj 166 118 !=; #X text 377 42 ouyvqdev qewrpfgvy; #X floatatom 202 335 0 0 0; #X floatatom 246 334 0 0 0; #X obj 208 46 <<; #X obj 259 46 >>; #X obj 202 308 <<; #X obj 246 307 >>; #X text 421 383 ouyvqwerfhb version 0.32; #X connect 5 0 0 0; #X connect 6 0 29 0; #X connect 6 0 30 0; #X connect 6 0 31 0; #X connect 6 0 32 0; #X connect 6 0 5 0; #X connect 7 0 29 1; #X connect 7 0 30 1; #X connect 7 0 31 1; #X connect 7 0 32 1; #X connect 7 0 5 1; #X connect 16 0 9 0; #X connect 17 0 8 0; #X connect 18 0 10 0; #X connect 19 0 11 0; #X connect 21 0 16 0; #X connect 21 0 17 0; #X connect 21 0 18 0; #X connect 21 0 19 0; #X connect 21 0 46 0; #X connect 21 0 47 0; #X connect 22 0 19 1; #X connect 22 0 18 1; #X connect 22 0 17 1; #X connect 22 0 16 1; #X connect 22 0 47 1; #X connect 22 0 46 1; #X connect 29 0 2 0; #X connect 30 0 1 0; #X connect 31 0 3 0; #X connect 32 0 4 0; #X connect 34 0 35 0; #X connect 36 0 37 0; #X connect 37 0 38 0; #X connect 37 1 39 0; #X connect 46 0 42 0; #X connect 47 0 43 0;
</code> Mensaje telepatico asistido por maquinas.
From: emviveros@gmail.com Date: Sat, 27 Feb 2016 19:19:33 +0000 Subject: Re: [PD] multi-language help patches To: lucarda27@hotmail.com; pd-list@lists.iem.at
Em sáb, 27 de fev de 2016 15:46, Lucas Cordiviola lucarda27@hotmail.com escreveu:
As an sketch:
pd nameoftheobject @wikipedia.org
pd osc~ or with the underscore pd_osc~
https://en.wikipedia.org/wiki/pd_osc~
It will be slow to fill objects but...
I feel one of the best aspects of PD are the examples via help patches so maybe splitting things up outside of PD might work against that?
That is definitely a great feature. If there's a way to keep that and add sane multi-language support, that would be the way to go.
Totally agree with that but perhaps that is just for the international english default (the standard default help system). Other languages could be HELPED in html format.
I`ve also proposed the translation of just the comments in *-help.pd files, but that seems difficult and language packs... I think a comment object with better features yet is a great feature, but the weighing the high development cost, this html solution for helps, can do the community more active once it documentation, maybe, can privilege the http://forum.pdpatchrepo.info for example to promote more organized collaboration of learning issues between pd community.
Mensaje telepatico asistido por maquinas.
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Portuguese translation of help patches are guaranteed! :)
Em sáb, 27 de fev de 2016 19:07, Lucas Cordiviola lucarda27@hotmail.com escreveu:
Probably an html server can provide both things, the html help AND the translated patch in the same url.
Whats important is that in can be completed/translated by users.
Wikipedia is the most familiar one to almost everyone. (perhaps I'm wrong here, not sure)
Mensaje telepatico asistido por maquinas.
From: lucarda27@hotmail.com To: pd-list@lists.iem.at Date: Sat, 27 Feb 2016 21:33:25 +0000
Subject: Re: [PD] multi-language help patches
There are chances that we`re welcome at wikipedia.
Mensaje telepatico asistido por maquinas.
From: lucarda27@hotmail.com To: pd-list@lists.iem.at Date: Sat, 27 Feb 2016 21:18:01 +0000 Subject: Re: [PD] multi-language help patches
Of course if we`re gonna use wikipedia.org as storage for encoded html information of a software we should tell them about it an ask for their permission.
Probably they say no.
So we will be looking for another server.
But...
Mensaje telepatico asistido por maquinas.
From: lucarda27@hotmail.com To: pd-list@lists.iem.at Date: Sat, 27 Feb 2016 20:37:37 +0000 Subject: Re: [PD] multi-language help patches
Eventually the user can make his particularly language translated patch:
Or it can be obteined with some href and an Id, not sure if its posible:
pd_object@wikipedia.org
<code>
#N canvas 20 43 698 447 12;
#X floatatom 524 338 0 0 0;
#X floatatom 353 338 0 0 0;
#X floatatom 298 338 0 0 0;
#X floatatom 413 338 0 0 0;
#X floatatom 467 338 0 0 0;
#X obj 524 311 <;
#X obj 298 262 r left;
#X obj 540 267 r right;
#X floatatom 71 335 0 0 0;
#X floatatom 19 334 0 0 0;
#X floatatom 119 335 0 0 0;
#X floatatom 163 334 0 0 0;
#X obj 16 45 &;
#X obj 66 45 |;
#X obj 118 45 &&;
#X obj 169 45 ||;
#X obj 19 307 &;
#X obj 71 308 |;
#X obj 119 308 &&;
#X obj 163 307 ||;
#X text 13 73 uoyhbqrevfg qrepfgvb;
#X obj 19 266 r left;
#X obj 218 266 r right;
#X obj 12 118 >;
#X obj 61 118 >=;
#X obj 114 118 ==;
#X obj 215 119 <=;
#X obj 262 119 <;
#X text 11 153 ouyhqergf eqwrvgupoyhb;
#X obj 298 312 >;
#X obj 353 312 >=;
#X obj 413 312 ==;
#X obj 467 312 <=;
#X text 16 190 piuqgherfpgiuhqerfg qerpfgiuberpigureg erpiuybqepirugbqerg qerpiyhbqperiugbqerg qepriyhbqepirgb
piybqergipub iuqberifvuhq[iuerhgfv qifvubqe[riuh[uheqrg piubqrguh
;
#X floatatom 410 65 0 0 0;
#X obj 410 92 s left;
#X floatatom 481 66 0 0 0;
#X obj 481 94 t b f;
#X obj 481 122 s left;
#X obj 541 122 s right;
#X obj 166 118 !=;
#X text 377 42 ouyvqdev qewrpfgvy;
#X floatatom 202 335 0 0 0;
#X floatatom 246 334 0 0 0;
#X obj 208 46 <<;
#X obj 259 46 >>;
#X obj 202 308 <<;
#X obj 246 307 >>;
#X text 421 383 ouyvqwerfhb version 0.32;
#X connect 5 0 0 0;
#X connect 6 0 29 0;
#X connect 6 0 30 0;
#X connect 6 0 31 0;
#X connect 6 0 32 0;
#X connect 6 0 5 0;
#X connect 7 0 29 1;
#X connect 7 0 30 1;
#X connect 7 0 31 1;
#X connect 7 0 32 1;
#X connect 7 0 5 1;
#X connect 16 0 9 0;
#X connect 17 0 8 0;
#X connect 18 0 10 0;
#X connect 19 0 11 0;
#X connect 21 0 16 0;
#X connect 21 0 17 0;
#X connect 21 0 18 0;
#X connect 21 0 19 0;
#X connect 21 0 46 0;
#X connect 21 0 47 0;
#X connect 22 0 19 1;
#X connect 22 0 18 1;
#X connect 22 0 17 1;
#X connect 22 0 16 1;
#X connect 22 0 47 1;
#X connect 22 0 46 1;
#X connect 29 0 2 0;
#X connect 30 0 1 0;
#X connect 31 0 3 0;
#X connect 32 0 4 0;
#X connect 34 0 35 0;
#X connect 36 0 37 0;
#X connect 37 0 38 0;
#X connect 37 1 39 0;
#X connect 46 0 42 0;
#X connect 47 0 43 0;
</code>
Mensaje telepatico asistido por maquinas.
From: emviveros@gmail.com Date: Sat, 27 Feb 2016 19:19:33 +0000 Subject: Re: [PD] multi-language help patches To: lucarda27@hotmail.com; pd-list@lists.iem.at
Em sáb, 27 de fev de 2016 15:46, Lucas Cordiviola lucarda27@hotmail.com escreveu:
As an sketch:
pd nameoftheobject @wikipedia.org
pd osc~ or with the underscore pd_osc~
https://en.wikipedia.org/wiki/pd_osc~
It will be slow to fill objects but...
I feel one of the best aspects of PD are the examples via help patches
so maybe splitting things up outside of PD might work against that?
That is definitely a great feature. If there's a way to keep that and add sane multi-language support, that would be the way to go.
Totally agree with that but perhaps that is just for the international english default (the standard default help system). Other languages could be HELPED in html format.
I`ve also proposed the translation of just the comments in *-help.pd files, but that seems difficult and language packs...
I think a comment object with better features yet is a great feature, but the weighing the high development cost, this html solution for helps, can do the community more active once it documentation, maybe, can privilege the http://forum.pdpatchrepo.info for example to promote more organized collaboration of learning issues between pd community.
Mensaje telepatico asistido por maquinas.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Probably wikipedia.org can do object help and object-help patch translation, the most primitive form could be an screen snapshot of the translated patch, and its text equivalent inside an <code> </code> html tag.
But this don't cover the /2.control.examples, /3.audio.examples /4.data.structures , etc, that form the powerful help system.
This can be translated with an FTP server, but it's hard to prevent accidental file deletion. Mensaje telepatico asistido por maquinas.
From: emviveros@gmail.com Date: Sat, 27 Feb 2016 22:21:07 +0000 Subject: Re: [PD] multi-language help patches To: lucarda27@hotmail.com; pd-list@lists.iem.at
Portuguese translation of help patches are guaranteed! :)
Yes... These way seems to some 99% of the auto learning issues about help translations... Much more I can imagine before this thread..
Em sáb, 27 de fev de 2016 15:13, Jonathan Wilkes via Pd-list < pd-list@lists.iem.at> escreveu:
I feel one of the best aspects of PD are the examples via help patches
so maybe splitting things up outside of PD might work against that?
That is definitely a great feature. If there's a way to keep that and add sane multi-language support, that would be the way to go.
-Jonathan
On Friday, February 26, 2016 7:08 PM, Dan Wilcox danomatika@gmail.com wrote:
Also, my thinking is going in this direction as we’re dealing with the same issues in the OpenFrameworks community. My uni department just hosted an OF DocSprint last weekend and we spent a good amount of time wrangling how best to integrate a Markdown + Doxygen generated reference system.
Of course pure data patch files and C++ source files are somewhat different, but I feel there are the same issues to solve such as what requires the most maintenance, works on all platforms, and is easy for non developer contributors to use. It’s one thing to build a custom system (we did) and quite another to get people to pitch in and fill the content in. I just wouldn’t want anyone to spend a lot of time making something admittedly cool and built into the canvas but, in the end, may not be leveraged by the community the same way a portable, easy to edit, cross platform standard might.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Feb 26, 2016, at 5:01 PM, Dan Wilcox danomatika@gmail.com wrote:
Ok, so which html reference system should I leverage here?
Probably something using css and an html template that make it easy for people to fill out. I’d say 1 main html file for each object to document w/ room for sub pages if needed. Different languages can live in different folders.
The nice thing about this approach is lots of people can edit html, there are plenty of designers, the files can be rendered by pretty much anything, etc. Another option is to have a templating system that uses Markdown, etc and just renders to html. It can then live in it’s own source repository for shared work and be used as a basis for online as well as distributed documentation.
Maybe a good start would be to look at the pure data object database/wiki that is around somewhere. I can’t find the link off the top of my head.
Where will the html files get stored, and how do we get from clicking the link in the help patch (I'm assuming we're still using the current help patches to show a simple demo of the object) to opening the html doc in the correct language?
Just like opening a help patch with a context menu option or maybe links we can open from the patch itself. Use the current help paths for searching and use tcl to launch the path in the system web browser if found.
I’d say the most useful thing would be add linking between patches and external files (html, etc) in general. I believe Hans had this in extended for the pd-doc stuff.
I’m suggesting this approach partially so you/we don’t end up reinventing the wheel. A custom, integrated system would be *nice* but I feel that will require too much backend work to build and them probably too much work to maintain/extend in the future. HTML+CSS has the option of being loaded into a web view within TK I imagine, so another option would be a side pane or extra window that can open up right in PD. I’d suggest staying away from building extra widgets etc to render a custom approach within the patch itself.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Feb 26, 2016, at 4:44 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
-Jonathan
On Friday, February 26, 2016 4:34 PM, Dan Wilcox danomatika@gmail.com wrote:
I think what implying is that maybe Pd *doesn’t* need to handle it. Simply, Pd could open a local webpage, similar to how the Processing “Find in reference” context menu option works when highlighting a function in the editor.
Not to say you/we can’t work out a file format/system to handle alot of this, but I’m thinking that html reference already works well for many other contexts an doesn’t require building new formats/systems to solve alot of the same problems.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Feb 26, 2016, at 2:08 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
html could be leveraged, but I'm really looking for a spec for how Pd handles it. Is it a GUI widget? An abstraction? A canvas method? A new "#" directive?
Do the translations get saved along with the help patch, or are they stored in a directory and fetched when needed? Etc.
-Jonathan
On Friday, February 26, 2016 1:02 PM, Dan Wilcox danomatika@gmail.com wrote:
I'll implement any *clear* spec for multi-language help patches someone comes up with with the following constraints:
- it separates design from content.
- in only requires documentation writers to care about content.
- it does not pigeonhole help patches into having a single, ugly design
- documentation writers will be guaranteed that whatever they write, it
won't overlap patch content. 5. it is maintainable and scalable
Sounds like .html.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Are you shure you want to use the wikipedia for that?
Mensaje telepatico asistido por maquinas.
Date: Fri, 26 Feb 2016 23:44:49 +0000 To: danomatika@gmail.com CC: pd-list@lists.iem.at Subject: Re: [PD] multi-language help patches From: pd-list@lists.iem.at
Ok, so which html reference system should I leverage here? Where will the html files get stored, and how do we get from clicking the link in the help patch (I'm assuming we're still using the current help patches to show a simple demo of the object) to opening the html doc in the correct language? -Jonathan
On Friday, February 26, 2016 4:34 PM, Dan Wilcox <danomatika@gmail.com> wrote:
I think what implying is that maybe Pd *doesn’t* need to handle it. Simply, Pd could open a local webpage, similar to how the Processing “Find in reference” context menu option works when highlighting a function in the editor.Not to say you/we can’t work out a file format/system to handle alot of this, but I’m thinking that html reference already works well for many other contexts an doesn’t require building new formats/systems to solve alot of the same problems. --------Dan Wilcox@danomatikadanomatika.comrobotcowboy.com
On Feb 26, 2016, at 2:08 PM, Jonathan Wilkes jancsika@yahoo.com wrote:html could be leveraged, but I'm really looking for a spec for how Pd handles it. Is it a GUI widget? An abstraction? A canvas method? A new "#" directive?Do the translations get saved along with the help patch, or are they stored in a directory and fetched when needed? Etc.-Jonathan On Friday, February 26, 2016 1:02 PM, Dan Wilcox danomatika@gmail.com wrote: I'll implement any *clear* spec for multi-language help patches someone comes up with with the following constraints:1. it separates design from content.2. in only requires documentation writers to care about content.3. it does not pigeonhole help patches into having a single, ugly design4. documentation writers will be guaranteed that whatever they write, it won't overlap patch content.5. it is maintainable and scalableSounds like .html. --------Dan Wilcox@danomatikadanomatika.comrobotcowboy.com_______________________________________________Pd-list@lists.iem.at mailing listUNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Dan Wilcox -
Esteban Viveros -
IOhannes m zmölnig -
Jonathan Wilkes -
Lucas Cordiviola