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 in.
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.
-P
From: IOhannes m zmoelnig zmoelnig@iem.at To: Pete Redest postal759@hotmail.com CC: pd-list@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 exploder/konqueror/nautilus/...)
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.
mfgadsr IOhannes
Get a FREE Web site, company branded e-mail and more from Microsoft Office Live! http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/