Browsing with the browser through the docs and examples, I run into a PDF file that that I generated from the tex source in tutorials/externals-howto (I copied this under /usr/local/lib/pd/doc from a download). Naively I thought I will click on the PDF and it will open in a PDF viewer. That didn't happen. Rather PD got stuck and I could only forcibly cancel it.
Is there a way to define external viewers for files, e.g. a list of the kind: pdf /usr/bin/acroread text /usr/bin/gvim mov /usr/bin/xine txt internal [mM]akefile internal TODO internal .... Get the drift?. If there isn't such capability, can someone point for me at the PD source that makes the decisions with what program to open files (i.e. where it says if (!strcmp(suffix, ".pd") { open_with_pd(file) } or whatever is that it says) and if that is ok with the maintainers, I will incorporate this functionality and submit a patch for consideration. I am far too new to PD to try to find this myself.
Thanks, -P
Rates near 39yr lows! $430K Loan for $1,399/mo - Paying Too Much? Calculate new payment http://www.lowermybills.com/lre/index.jsp?sourceid=lmb-9632-18226&moid=7...
Is there a way to define external viewers for files, e.g. a list of the kind: pdf /usr/bin/acroread text /usr/bin/gvim mov /usr/bin/xine txt internal [mM]akefile internal TODO internal .... Get the drift?. If there isn't such capability
theres something like this for gnome, where if you run 'gnome-remote /path/to/some.pdf' it will launch evince. osux has something similar, called 'open' i think. on windows, im not sure what you do, maybe 'exec explorer.exe filename'..
im pretty sure pd just uses the tk_fileChooser so youre going to have to figure out how to override its default somehow.. maybe check the tk docs? and check pd.tk. its surely no more than a few lines to do what you want, on all the platforms..
Will take a look at the code and check for use of tk_fileChooser - may be someone has more specific info I can use.
BTW, I am guessing that the particular bad behavior when clicking on a PDF file, is that there is a bug in the browser, whereby it takes the ".pd" of the ".pdf" suffix and "believes" it is a PD file, then tries to open it in PD. That looks at first as a "hang" but if I wait 2 minutes, I see a lot of binary-printed insults in the PD log area, like: ..... GEM: with help by Guenter Geiger, Daniel Heckenberg, Cyrille Henry, et al. GEM: using MMX optimization error: %PDF-1.3: no such object error: ?????l?à?Ù}gßf??Õ}???ûýòÇæÃõ]vê?dEÆÓB: no such object ..... etc ad-infinitum (well, not really infinitum: a few thousand lines like that).
From: carmen _@whats-your.name To: pd-list@iem.at Subject: Re: [PD] external viewers for additional file types ? Date: Mon, 12 Mar 2007 02:48:51 -0400
Is there a way to define external viewers for files, e.g. a list of the kind: pdf /usr/bin/acroread text /usr/bin/gvim mov /usr/bin/xine txt internal [mM]akefile internal TODO internal .... Get the drift?. If there isn't such capability
theres something like this for gnome, where if you run 'gnome-remote /path/to/some.pdf' it will launch evince. osux has something similar, called 'open' i think. on windows, im not sure what you do, maybe 'exec explorer.exe filename'..
im pretty sure pd just uses the tk_fileChooser so youre going to have to figure out how to override its default somehow.. maybe check the tk docs? and check pd.tk. its surely no more than a few lines to do what you want, on all the platforms..
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
With tax season right around the corner, make sure to follow these few simple tips. http://articles.moneycentral.msn.com/Taxes/PreparationTips/PreparationTips.a...
ok. it doesnt use tk_fileChooser, but the code is in u_main.tk. The function menu_doc_open does some minimal parsing and invokes one of just 3 handlers.
I will think some more how to handle this. Also, my observation of incorrect parsing of the .pdf suffix is not what is happening, but rather that as-is, the code will open with pd anything that is not .txt .c or .html.
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. Thanks! -Peter
From: "Pete Redest" postal759@hotmail.com To: _@whats-your.name, pd-list@iem.at Subject: Re: [PD] external viewers for additional file types ? Date: Tue, 13 Mar 2007 03:19:48 +0000
Will take a look at the code and check for use of tk_fileChooser - may be someone has more specific info I can use.
BTW, I am guessing that the particular bad behavior when clicking on a PDF file, is that there is a bug in the browser, whereby it takes the ".pd" of the ".pdf" suffix and "believes" it is a PD file, then tries to open it in PD. That looks at first as a "hang" but if I wait 2 minutes, I see a lot of binary-printed insults in the PD log area, like: ..... GEM: with help by Guenter Geiger, Daniel Heckenberg, Cyrille Henry, et al. GEM: using MMX optimization error: %PDF-1.3: no such object error: ?????l?à?Ù}gßf??Õ}???ûýòÇæÃõ]vê?dEÆÓB: no such object ..... etc ad-infinitum (well, not really infinitum: a few thousand lines like that).
From: carmen _@whats-your.name To: pd-list@iem.at Subject: Re: [PD] external viewers for additional file types ? Date: Mon, 12 Mar 2007 02:48:51 -0400
Is there a way to define external viewers for files, e.g. a list of the kind: pdf /usr/bin/acroread text /usr/bin/gvim mov /usr/bin/xine txt internal [mM]akefile internal TODO internal .... Get the drift?. If there isn't such capability
theres something like this for gnome, where if you run 'gnome-remote /path/to/some.pdf' it will launch evince. osux has something similar, called 'open' i think. on windows, im not sure what you do, maybe 'exec explorer.exe filename'..
im pretty sure pd just uses the tk_fileChooser so youre going to have to figure out how to override its default somehow.. maybe check the tk docs? and check pd.tk. its surely no more than a few lines to do what you want, on all the platforms..
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
With tax season right around the corner, make sure to follow these few simple tips. http://articles.moneycentral.msn.com/Taxes/PreparationTips/PreparationTips.a...
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Find what you need at prices youll love. Compare products and save at MSN® Shopping. http://shopping.msn.com/default/shp/?ptnrid=37,ptnrdata=24102&tcode=T001...
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
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/
I am sure I replied to this, but the msg apparently got lost in cyberspace ...
Anyways, here it goes again.
Indeed, it should be easy to check both the file "type" a-la-Windows, and have PD open only .pd files, after validating some "magic" prefix. This implies also to not to have a default handler (PD is the default right now, which is bad news).
As per the need of additional handlers, it is not a necessity indeed. It is more a matter of completeness and consistency, and I (we?) being a pedantic perfectionist, like to see these attributes in any software piece, in particular PD+Gem which are a magnificent display of the power of open source and community development, supplementing the good work and generosity of Miller Puckette, yours, and the other folks that contributed to this project.
The Help Browser, or any browser for that matter, if it lists an item, it better know what to do with it. Listing a "PDF" and not doing anything with it does not sound (I dare to say plainly: it is *not*) right. To fix this, we can skip it from the listing, leading to incompleteness, and effectively hiding parts (important parts, indeed, e.g. your Gem document) of the generic "Help" system. Anything that is documentation of PD is helpful, so that excluding something does not sound like a very good idea.
In addition, excluding PDF while including HTML (the "fixed"situation, assuming the PDFs are skipped because they get passed to PD for processing right now) is plainly inconsistent. Here is a quiz:
The PDF format is a commonly used markup format for presentation of documents, for which there is full published documentation and for which there are plenty of free and legal readers.
The HTML format is a commonly used markup format for presentation of documents, for which there is full published documentation and for which there are plenty of free and legal readers.
PDF is used to document some components in PD. HTML is used to document some components in PD.
Quiz: what grants to HTML the status of "included" in the browser and denies that same status to PDF?
I had a hard time trying to find an answer to that question, and didn't find a satisfactory one, (satisfactory *to me*, of course). The only ones that came to mind were like "I feel that ....". IMO "feelings" in this business have a limited role. And if I have to invoke feelings, I "felt" surprised and disappointed that had to find manually othe progs to open various docs, movie, sound files. Truly annoying.
Further, being so easy to put together a script that will include the current file types that appear under the various directories visited by the browser, it seems rather arbitrary not to include them because it is not necessary to include them. And indeed, necessary it is not: PD and Gem can work without this. However, the users, to access a PDF or to view the Gem demo movie, need to go somewhere else, launch an app, navigate, .... and FINALLY!! see the desired document/file. I, naturally, ask an honest question: WHY?.
Anyways, I can fix the current situation of mishandling unknown formats by adding sanity checks. At the same time I would add an invocation to an external script, if it exists in the PATH, in a way that is OS-independent. If it doesn't exist, nothing has happened, if it does, it can launch a user-defined app. We could provide some succint initial version of it, in the spirit of my initial post(s).
Best regards, -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/
-
carmen -
IOhannes m zmoelnig -
Pete Redest