In <[EMAIL PROTECTED]>, Georg Baum <[EMAIL PROTECTED]> typed:
> Jose' Matos wrote:
>
> > Better than that we should have some kind of profile configuration, so
> > that
> > if I choose kde as my preferred desktop environment I get kpdf, if I
> > choose gnome I get evince and if I choose plain X I get xpdf, wind users
> > get ...
> >
> > That would allow a coherent set of first choices to the viewers, what we
> > have now is a mess.
>
> I agree, but since this is not 1.4.0 stuff, I filed it in bugzilla:
> http://bugzilla.lyx.org/show_bug.cgi?id=2017
If it's not appropriate to talk about non 1.4.0 stuff at this time, I
apologize. But I've been thinking about this, and would like to get
feedback. Answers off-list if you feel that's required.
This is a hard problem in general. How is the data stored, how does
the user edit it, what do we do on failure, and so on. It's harder on
Unix than on OS X or Windows, because the answer changes depending on
whether or not $DISPLAY is set.
However, LyX doens't need to worry about any of that. It needs two
things. Well, three:
1) A way to get an arbitrary file.
2) A way to find out if files with a given extension can be displayed
by this tool.
3) A way to check that it's got the right tool.
If we provide a tool that covers those things, we can change it later
to make it "right". This seems like a generally useful tool, so I'm
going to implement a first cut over the weekend.
The command will be called "open". I prefer it to "start", but am open
to other suggestions.
If you invoke it with a single argument, it uses the extension on the
argument to search for an application, and then said application is
asked to open the argument. That's point 1.
If invoked as "open -q ext", it does the same search, except it exits
with success if it knows how to open files with extension ext, and
exits with failure if it doesn't. That's point 2.
If invoked with "open --open-protocol" it will print a numeric version
number followed by a string of single-character options that it
understands. This lets applications that are trying to do what
lib/configure does verify that they have something that understands
the "-q" option as described herein. That's point 3.
The changes to lib/configure are to search $PATH for "open", and if it
finds one do "open --open-protocol" to see if it understands the "-q"
option. If it doesn't, keep searching. If it does, save the full path
for future reference.
If configure has a path to an open, configure will ask open whether it
knows how to deal with file types of the appropriate extension before
searching the list of applications for that file type. If open answers
yes, then that "open" becomes the application to use for this file
type. If the answer is no, configure does what it does now.
Comments? Questions? Feedback? Anyone think the proposed changes to
configure would be worth making to committing (I'll probably make them
as a test of open)?
Thanks,
<mike
--
Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
