> Please try to convince Jean-Marc to use configure.py instead, We don't
> have the reasources to do this double work.

Hmm, JMarc? We have been using configure .py for a while and it
working all right. We indeed do not have time to port whatever change
to configure.py to configure.m4.

> > +bool autoViewFile(std::string const & filename, std::string const &
> mode="open");

You are right.

> This function is misnamed: a "View" method should not "edit". The mode
> argument is also misnamed. Please use something like
>
> bool autoViewFile(std::string const & filename);
> bool autoEditFile(std::string const & filename);

Two separate implementation? Macro? autoEditFile calls autoViewFile?

> enum openFileMode {
>         view,
>         edit
> };
> bool openFile(std::string const & filename, openFileMode mode = view);

openFile has been used in too many places, so I used view. Maybe
shellOpenFile or shellExecuteFile?

> > +def autoFormatEntries():
>
> This is error prone. When I want to add a new format I have to touch two
> different places. Please hold back the configure.py change. I have an
> almost finished different solution that does not need it.
>
> The rest is fine with me.

Not a problem. Just remember that this autoFormatEntries may be used
for mac or kde as well. No immediate plan though.

> What it's saying is tht autoViewFile is called if !format or if
> format->viewer() is empty. That's wrong. (The remaining test
> is correct of course.)

> I think that the code should be something like.

>       bool able_to_view = (format && !format->viewer().empty());
>      if (able_to_view && format_viewer() == "auto") {
>              able_to_view = autoViewFile(filename, "open");
>       }

When lyx somehow knows nothing about a file (no format, no viewer), I
just let users to decide since he requested to view a file. This
action may remind a user to install a viewer program since a 'choose a
program' dialog will be shown if windows does not know what to do
either.

Bo

Reply via email to