Am Mittwoch, 29. März 2006 20:49 schrieb Enrico Forestieri:

> I have reorganized things in this way:
> 1) The kind of path style to be written into .tex files is only
>    decided by the configure script which checks what the correct
>    style is (miktex vs cygwin tetex).
> 2) The "Use Cygwin-style paths" checkbox is now unrelated to the
>    check performed by the configure script.

I am not sure that this good. This checkbox was introduced because the 
user should be able to override the result of the configure script (if 
you want to know more, read the thread "Latest LyX on Latest Cygwin" from 
jan 2005).
IMHO the checkbox should go completely if it is never necessary to correct 
the decision of the configure script, or it should stay and override that 
decision as it has been originally.

>    When unchecked, all 
>    paths written to .lyx files, returned by the dialogs, and shown
>    in preferences are in pseudo win-style, including the PATH prefix.

What has the path prefix to do with that?

>    When using win-style paths, the .lyx files written by the cygwin
>    version can also be read by the native LyX version (when they
>    contain absolute paths).

In 1.3 it was possible to use the same files with relative filenames on 
linux and native win, does this still work?
IMHO the paths in LyX files should always be with forward slashes. This 
should not be configurable. That gives maximum compatibility between 
platforms.
Note that the "Use Cygwin-style paths" was originally implemented only for 
LaTeX paths. IMO it should retain that meaning. The problem that other 
programs (converters) may need different paths was not dealt with at all, 
but the thread mentioned above has solutions.

>   Index: insets/insetgraphics.C
> ===================================================================
> --- insets/insetgraphics.C      (revision 13529)
> +++ insets/insetgraphics.C      (working copy)
> @@ -597,7 +597,7 @@ string const InsetGraphics::prepareFile(
>                         copyToDirIfNeeded(orig_file, temp_path, zipped);
>  
>         if (status == FAILURE)
> -               return orig_file;
> +               return os::latex_path(orig_file);
>  
>         // a relative filename should be relative to the master
>         // buffer.
> @@ -629,7 +629,7 @@ string const InsetGraphics::prepareFile(
>                                 boost::tie(status, bb_file) =
>                                         copyFileIfNeeded(bb_orig_file, 
bb_file);
>                                 if (status == FAILURE)
> -                                       return orig_file;
> +                                       return 
os::latex_path(orig_file);
>                                 runparams.exportdata->addExternalFile("latex",
>                                                 bb_file);
>                         }

These changes are not necessary, but don't hurt either. These return 
statements are only executed if something failed already, so the .tex 
file cannot be compiled anyway.

> Index: bufferlist.C
> ===================================================================
> --- bufferlist.C        (revision 13529)
> +++ bufferlist.C        (working copy)
> @@ -28,6 +28,7 @@
>  
>  #include "support/filetools.h"
>  #include "support/package.h"
> +#include "support/os.h"
>  
>  #include <boost/bind.hpp>
>  
> @@ -43,6 +44,8 @@ using lyx::support::removeAutosaveFile;
>  using lyx::support::package;
>  using lyx::support::prefixIs;
>  
> +using lyx::support::os::external_path;
> +
>  using boost::bind;
>  
>  using std::auto_ptr;
> @@ -379,7 +382,7 @@ Buffer * BufferList::getBufferFromTmp(st
>         BufferStorage::iterator it = bstore.begin();
>         BufferStorage::iterator end = bstore.end();
>         for (; it < end; ++it)
> -               if (prefixIs(s, (*it)->temppath()))
> +               if (prefixIs(external_path(s), 
external_path((*it)->temppath())))
>                         return *it;
>         return 0;
>  }

This looks strange. Why is it needed? Please add an explaining comment.

> Index: exporter.C
> ===================================================================
> --- exporter.C  (revision 13529)
> +++ exporter.C  (working copy)
> @@ -33,6 +33,7 @@
>  #include "support/filetools.h"
>  #include "support/lyxlib.h"
>  #include "support/package.h"
> +#include "support/os.h"
>  
>  #include <boost/filesystem/operations.hpp>
>  
> @@ -46,6 +47,7 @@ using lyx::support::OnlyFilename;
>  using lyx::support::OnlyPath;
>  using lyx::support::package;
>  using lyx::support::prefixIs;
> +using lyx::support::os::external_path;
>  
>  using std::find;
>  using std::string;
> @@ -107,7 +109,8 @@ CopyStatus copyFile(string const & forma
>         // overwrite themselves. This check could be changed to
>         // boost::filesystem::equivalent(sourceFile, destFile) if export 
to
>         // other directories than the document directory is desired.
> -       if (!prefixIs(OnlyPath(sourceFile), package().temp_dir()))
> +       if (!prefixIs(external_path(OnlyPath(sourceFile)),
> +                               external_path(package().temp_dir())))
>                 return ret;
>  
>         if (!force) {

ditto, why external_path here?

> Index: frontends/qt2/QPrefs.C
> ===================================================================
> --- frontends/qt2/QPrefs.C      (revision 13529)
> +++ frontends/qt2/QPrefs.C      (working copy)
> @@ -148,6 +148,11 @@ string const internal_path(QString const
>         return lyx::support::os::internal_path(fromqstr(input));
>  }
>  
> +string const internal_path_list(QString const & input)
> +{
> +       return lyx::support::os::internal_path_list(fromqstr(input));
> +}
> +
>  }

Does this frontend stuff also work with unpatched qt?

> Index: support/os_cygwin.C
> ===================================================================
> --- support/os_cygwin.C (revision 13529)
> +++ support/os_cygwin.C (working copy)
> @@ -65,40 +65,97 @@ string::size_type common_path(string con
>  namespace {
>  
>  bool cygwin_path_fix_ = false;
> +bool cygwin_style_paths_ = false;
> +
> +using lyx::support::contains;
> +
> +bool is_posix_path(string const & p)
> +{
> +       return  p.empty() ||
> +               (!contains(p, '\\') && (p.length() < 1 || p[1] != ':'));
> +}
> +
> +// Windows path really is a win32 style path with forward slashes.
> +
> +bool is_windows_path(string const & p)
> +{
> +       return p.empty() ||
> +               (!contains(p, '\\') && (p.length() < 1 || p[1] == ':'));
> +}

These two functions look fragile. Are you sure that boost::filesystem does 
not have similar functions?

I give up now. This patch combines too many things for my taste. Is it not 
possible to do the presentation of paths in the GUI separately?


Georg

Reply via email to