[PD] external viewers for additional file types ?

Pete Redest postal759 at hotmail.com
Thu Mar 15 03:21:57 CET 2007

Yes, adding some minimal sanity checking of the files to be opened
will make the browser more solid, and for all we know, checking
the "magic" prefixes of files is a snap. BTW, for kicks I tried to open
a .wav file (there are a couple in the examles somewhere) knowning
the problem .... guess what happened :-)    ... fixing this can be a
good thing. I volunteer, but please read on.

About the general position about expanding/not-expanding viewing
capabilities I guess it is a matter of perception by the user of
whether an implementation is "complete".

As an example of what I mean about "complete", when an entity
that is named "browser" presents a list of items, it seems
reasonable to expect that it will be able to "handle" the listed
items in a manner consistent with their type. I dare to submit
that this is kind of software engineering common wisdom. If
it can not handle something, don't list it.

But eliminating things from the list because it can not handle
them, renders the browser incomplete: it is not listing
everything it sees, even though it is still displaying subdirs of
the help dir. To me this does not seem right.

Furthermore, I tried to find any justification for having support
(i.e. launch a viewer for) e.g. .html files and not for pdf files.
HTML is a standard markup format for which there are plenty
of free and legal viewers.
PDF is a standard markup format for which there are plenty
of free and legal viewers.
Folks publish documents for PD in HTML format. e.g. many.
Folks publish documents for PD in PDF format, e.g. IOhannes.

Now (STARTING OF THE ROLLING DRUMS prrrrrrrrrrrrrrrrrrrrrr)
THE DIFFERENCES ARE!!: .......... fill the blanks with what you
believe the differences are .... I am sure that you will find a hard
time to exclude one or the other, and HTML support is already

An the obvioius question is *why* to exclude, rather than include,
approaching completeness, rather than perpetuating incompleteness.
The documents and other files (e.g. the Gem demo movie) are
utterly useful as help tools: why would we force new users to
open 10 applications to navigate separately to each of these
docs or files when it is perfectly possible, and easy, to support
a decent number of them. And in fact, it is even easier to launch
a standard script that the user can modify to add whatever crap
she wants.

There is very little to code here, and doing it "open ended"
make it very easy to port to various platforms. Very flexible.

Yet, as you say, and I agree, there is no real "necessity" to
add this. It is just cheap convenience and completeness.
PD can live without it, as it did so far.

Look forward to hear your thoughts.


>From: IOhannes m zmoelnig <zmoelnig at iem.at>
>To: Pete Redest <postal759 at hotmail.com>
>CC: pd-list at iem.at
>Subject: Re: [PD] external viewers for additional file types ?
>Date: Tue, 13 Mar 2007 09:09:29 +0100
>Pete Redest wrote:
> >
> > Probably the easiest would be to launch an external script that
> > incorporates the added "viewer" table lookup or something like
> > that. Or add the table lookup right into u_main.tk. I don't know
> > much Tcl/Tk so ... will see. Will get to it sometime soon.
>hmm, probably the easiest way would be to not open unkwown files at all.
>(i don't see a real necessity to open a pdf from within pd; i don't
>think that it would be a very good idea to make pd just another
>however, pd _should_ definitely check whether the file it wants to load
>as a patch is really a patch, e.g. by reading the first few bytes.
>if there is "#N canvas", then it is _rather_ save to open the file; if
>it is something else ("%PDF-1.4") pd should just refuse.

Get a FREE Web site, company branded e-mail and more from Microsoft Office 
Live! http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/

More information about the Pd-list mailing list