[PD-dev] PD mime setup

[Hans-Christoph Steiner]

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

----------------------------------------------------------------------------

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