I would have sent this to the debian PD maintainer, but it appears the package is orphaned right now.
If you the attached puredata.xml file into /usr/share/mime/packages/ and then run 'sudo update-mime-database /usr/share/mime/packages' programs like rox-filer and nautilus will recognize the application/x-puredata mimetype, allowing the association of the files for point and click opening.
I joined the list in order to forward this info, so please pardon me if this has already come up before. Is this something that would be good to include as an optional installable part of pd for those who use this mime update method?
Also, I have embedded the expat xml parsing library into a pd external in order to import objects from svg documents edited in inkscape into pd structs, what would be the best way to share this with others once I get my code cleaned up enough for distribution? (so far, between the external and a pd patch I can import three sided shapes accurately, accounting for scale / translate / shear / rotation data).
On Oct 5, 2009, at 10:46 PM, Justin Glenn Smith wrote:
I would have sent this to the debian PD maintainer, but it appears the package is orphaned right now.
If you the attached puredata.xml file into /usr/share/mime/packages/ and then run 'sudo update-mime-database /usr/share/mime/packages' programs like rox-filer and nautilus will recognize the application/x-puredata mimetype, allowing the association of the files for point and click opening.
That would be a great thing to include. There is a lot of that kind of stuff included in the Pd-extended package that is distributed outside of Debian/Ubuntu. Please take a look at them and see if you can see anything to improve. You can see those files here:
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/packages/linux_m...
I joined the list in order to forward this info, so please pardon me if this has already come up before. Is this something that would be good to include as an optional installable part of pd for those who use this mime update method?
Yeah, we need to iron out a grand plan before taking on the 'puredata' package again. There has been discussion, next we need motion. :)
Also, I have embedded the expat xml parsing library into a pd external in order to import objects from svg documents edited in inkscape into pd structs, what would be the best way to share this with others once I get my code cleaned up enough for distribution? (
This sounds super useful if it will do general XML parsing. Your idea sounds quite cool too. To start with, I think you should package it as a libdir library and distribute it on puredata.info or wherever you want.
http://puredata.info/docs/developer/Libdir
.hc
so far, between the external and a pd patch I can import three sided shapes accurately, accounting for scale / translate / shear / rotation data).
<?xml version="1.0" encoding="UTF-8"?>
<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info ">
<mime-type type="application/x-puredata"> <comment>puredata patch</comment> <glob pattern="*.pd"/> </mime-type> </mime-info> _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
"Making boring techno music is really easy with modern tools," he says, "but with live coding, boring techno is much harder." - Chris McCormick
Hans-Christoph Steiner wrote:
On Oct 5, 2009, at 10:46 PM, Justin Glenn Smith wrote:
I would have sent this to the debian PD maintainer, but it appears the package is orphaned right now.
If you the attached puredata.xml file into /usr/share/mime/packages/ and then run 'sudo update-mime-database /usr/share/mime/packages' programs like rox-filer and nautilus will recognize the application/x-puredata mimetype, allowing the association of the files for point and click opening.
That would be a great thing to include. There is a lot of that kind of stuff included in the Pd-extended package that is distributed outside of Debian/Ubuntu. Please take a look at them and see if you can see anything to improve. You can see those files here:
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/packages/linux_m...
I joined the list in order to forward this info, so please pardon me if this has already come up before. Is this something that would be good to include as an optional installable part of pd for those who use this mime update method?
Yeah, we need to iron out a grand plan before taking on the 'puredata' package again. There has been discussion, next we need motion. :)
Also, I have embedded the expat xml parsing library into a pd external in order to import objects from svg documents edited in inkscape into pd structs, what would be the best way to share this with others once I get my code cleaned up enough for distribution? (
This sounds super useful if it will do general XML parsing. Your idea sounds quite cool too. To start with, I think you should package it as a libdir library and distribute it on puredata.info or wherever you want.
Thanks for the info.
The expat object will handle any proper xml document, as far as I know. It currently has outlets for entity name, entity end (that outputs the name also, to simplify keeping track of nesting, though it could technically be a bang given the structure of xml), attribute name, attribute value, text-data layed out in the following order
end start attribute value text-data
and doing the standard thing of outputing in a general right to left direction (though of course most elements have multiple attributes and some values have multiple pairs)
It also destructures style into key value pairs at the value outlet, outputting one pair at a time and ending with the symbol style at the attribute outlet, and converts all space, comma, or semicolon separators into seperate atoms in a list, and attempts to convert every atom into a float, including #abcdef color notation
If anyone has any suggestions for added or changed behavior while I am still ironing it out, it is easier to do those improvements while the code is still plastic and fresh in my mind, so please do offer suggestions if you have any.
On Oct 6, 2009, at 12:16 AM, Justin Glenn Smith wrote:
Hans-Christoph Steiner wrote:
On Oct 5, 2009, at 10:46 PM, Justin Glenn Smith wrote:
I would have sent this to the debian PD maintainer, but it appears the package is orphaned right now.
If you the attached puredata.xml file into /usr/share/mime/ packages/ and then run 'sudo update-mime-database /usr/share/mime/packages' programs like rox-filer and nautilus will recognize the application/x- puredata mimetype, allowing the association of the files for point and click opening.
That would be a great thing to include. There is a lot of that kind of stuff included in the Pd-extended package that is distributed outside of Debian/Ubuntu. Please take a look at them and see if you can see anything to improve. You can see those files here:
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/packages/linux_m...
I joined the list in order to forward this info, so please pardon me if this has already come up before. Is this something that would be good to include as an optional installable part of pd for those who use this mime update method?
Yeah, we need to iron out a grand plan before taking on the 'puredata' package again. There has been discussion, next we need motion. :)
Also, I have embedded the expat xml parsing library into a pd external in order to import objects from svg documents edited in inkscape into pd structs, what would be the best way to share this with others once I get my code cleaned up enough for distribution? (
This sounds super useful if it will do general XML parsing. Your idea sounds quite cool too. To start with, I think you should package it as a libdir library and distribute it on puredata.info or wherever you want.
Thanks for the info.
The expat object will handle any proper xml document, as far as I know. It currently has outlets for entity name, entity end (that outputs the name also, to simplify keeping track of nesting, though it could technically be a bang given the structure of xml), attribute name, attribute value, text-data layed out in the following order
end start attribute value text-data
and doing the standard thing of outputing in a general right to left direction (though of course most elements have multiple attributes and some values have multiple pairs)
It also destructures style into key value pairs at the value outlet, outputting one pair at a time and ending with the symbol style at the attribute outlet, and converts all space, comma, or semicolon separators into seperate atoms in a list, and attempts to convert every atom into a float, including #abcdef color notation
If anyone has any suggestions for added or changed behavior while I am still ironing it out, it is easier to do those improvements while the code is still plastic and fresh in my mind, so please do offer suggestions if you have any.
It would be a lot easier to give feedback if we could try it :) The trickiest part will be mapping XML flow to Pd flow, but it sounds like you are headed in the right direction. I would use 'bang' whenever appropriate.
.hc
----------------------------------------------------------------------------