Ok, I know this is a strange place to announce a new Unix tool. But LyX is the inspiration for this, and workinng well with LyX is a high priority. I'd like to get feedback from LyX users early, so please bear with me. To provide some motivation for looking at this, here's an excerpt from my .lyx/preferences:
bhuda% cd ~/.lyx bhuda% grep open preferences \viewer "dvi" "open" \viewer "eps" "open" \viewer "html" "open" \viewer "pdf" "open" \viewer "ps" "open" \viewer "rtf" "open" bhuda% grep convert preferences \converter "latex" "dvi" "convert -f dvi $$i" "" \converter "latex" "html" "convert -f html $$i" "originaldir,needaux" \converter "ps" "pdf" "convert -f pdf $$i" "" \converter "latex" "rtf" "convert -f rtf $$i" "" Note that this does require Python 2.4. Depending on feedback, that may change. Here's the announcement as used elsewhere "open" is designed to provide Unix users with a single tool for dealing with the multitude of applications that deal with data files. Without open - or something like it - every time a user wants to look at a file, they have to figure out what type the file is and which application on their path can open that file, and then invoke that application with the appropriate arguments. Likewise, every application that uses external applications has it's own database of file types and applications. Applications developers have to choose a format for the database, write code to parse it, and provide a GUI for editing it. This not only represents a duplication of effort, but requires the user to tell every application how to deal with each type of file, meaning they have to learn multiple different tools for dealing with this information. "open" was designed to solve these problems. If the user wants to open a file, they just invoke "open" on it. To edit it, they just invoke "open -c edit" (or "edit" if they've installed it that way). Open will figure out which application they want to use for this, and arrange that it gets called appropriately. If open can't find an application, it'll ask the user to choose one, and save that choice for future reference. For applications, open provides an API that takes care of the entire problem. There's no need to parse a configuration file, provide facilities for editing the configuration file, ensure the consistency of the configuration file, or any such thing. The application merely hands the file name to "open", and "open" does the rest. Further, the API is one that any program that has to deal with external applications already deals with - launching an external application on a file. So users can start getting the benefit of using "open" even if none of the applications they have installed know about it - all they have to do is tell each application to use "open" for everything. Hopefully, applications will start checking for and using "open" as an external viewer by default, removing even that burden from the user. The benefits to the user are multifold. They only have to learn one interface for configuring the invocation of external programs. If they install a new foo viewer, and decide they want to use that for viewing foos everywhere, they only have to change it in one place - the "open" database. Users can quit worrying about "What application opens this file" at the command line. Well, most of the time. Instead, they just do "open <filename>", and let open sort it out. It's not got it's own web page yet. The tarball can be found at <URL: http://www.mired.org/downloads/open-0.2.tar.gz >. Discussionn shold take place off-list. Thanks, <mike -- Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.
