----- Original Message -----
From: "Andre Poenitz" <[EMAIL PROTECTED]>
To: "Stephen Harris" <[EMAIL PROTECTED]>
Cc: "Michael Gerz" <[EMAIL PROTECTED]>; "Bo Peng"
<[EMAIL PROTECTED]>; <lyx-users@lists.lyx.org>; <lyx-devel@lists.lyx.org>
Sent: Sunday, January 08, 2006 12:00 PM
Subject: Re: [announce] sixth release of LyXWinInstaller
On Mon, Jan 02, 2006 at 02:24:58PM -0800, Stephen Harris wrote:
Why doesn't English have the default of C:\Programs?
Is it because C:\program files adheres to basic Windows guidelines?
No, certainly not.
Just because Word pioneered filenames with spaces doesn't
mean that practice should be emulated by other editors, nor
does Words ability to do this elevate the filename with spaces
capability to a "basic windows guideline".
It's not Word pioneering bad practices, it's about Microsoft setting
rules about what is acceptable in their world and what not. Like it or
not, they are entitled to do that.
I agree with you, "It's not Word pioneering bad practices" and
that is not the point I made, so this part of your response is off
target. Nor is my point about the advantages of having Word
tied into Internet Explorer, Outlook or Excel. Nor is my point
about other Microsoft owned programs or other commercial
programs that are originally designed to work under Windows.
My point _is_ that programs that are ported to Windows should
adhere to Windows habits unless that causes a problem. But if
this habit causes a problem, and correcting a particular problem
like paths with spaces, to paths with no spaces fixes the problem,
and does not create a problem with Windows, then use the
standard workaround, which is paths with no spaces. Windows
does not consider a filename to be equivalent to a directory path.
I used Word as an analogy, other ported word processors don't
need to emulate filenames with spaces::LyX and its helper programs don't
need to emulate C:\program files\xxx
LyX itself doesn't have a problem with filenames with spaces.
Your claim that installing LyX to C:\program files\Lyx is a good
idea because they have decided to install other programs to
C:\program files is simply false. It is not part of "their world"
nor does it benefit the interoperability of programs running under
the Windows OS. It does precisely the opposite. LaTex is a
major part of LyX productivity and it should *not* be installed
to C:\program files\texmf or C:\program files\miktex\texmf
There's a nice book on that. I put a copy of it between my desk and
monitor at work to make sure it does not crash. I forgot the title,
though, but could tell you on Tuesday if you want.
Yes, if it has a bearing on the actual benefit of installing LyX and
other ported *nix programs to C:\program files or other directories
because it improves operation of the programs. IOW, the book
needs to explain why C:\program files is a better choice than the
intuitve C:\programs in terms of the system working better. As it
stands now, that decision was a marketing decision, because the
choice causes problem with porting programs to Windows which Microsoft
doesn't gather revenue from. I'm sick of that ludicrous
misnomer, "guideline" being applied to a proprietary money-making scheme
which does nothing to benefit the operation of LyX&helpers.
The possibly surprising part is that most things in there actually
make sense and lead to that 'smooth' user experience when switsching
between different applications under Windows (compared to the constand
retraining under *nix)
There is some interoperability due to vbscript. That doesn't require
a path with spaces. Protext and Win32 do not default to a path with spaces
such as C:\program files. The recommended Miktex (Latex
LyX install for windows) has instructions that it is not recommended
to Miktex to a directory with spaces.
The default install directory says C:\texmf
the user just has to hit OK, that is their habit
and so mentioning "retraining" is a red herring.
The going gets rough only if the user decides to
be clever, do more work, and change the default
install to C:\program files\texmf which contains
the .bst files under bibtex.
This is the issue I'm addressing in this thread which has done
quite a bit of wandering. If you download a .bst file from the
internet, put it into the C:\texmf\bibtex\bst folder
run miktex options refresh, Lyx reconfigure and rescan, it works.
If you download a .bst file from the internet and put it into
C:\My research papers along with research.lyx it doesn't
work, not because of some alleged problem that reflects to
C:\My Documents, but for the same reason C:\program files\texmf
doesn't work. It has nothing to do with retraining.
I think the question is whether Lyx should follow the usual Windows
Latex program guidelines of using an installation directory which
has no spaces in its path and provokes no problems or -- decide
to use a deleterious Windows installation of a directory with a space.
The problem with fixing Lyx/Miktex so that it does windows habits:
"Angus: Ahhhh. Don't do that. BibTeX and "spaces in paths" don't live well
together. In fact they don't live together at all.
We jump through a lot of hoops to ensure that your BibTeX data base will
continue to work if it lives in a path with spaces. I don't see any reason
at all to add a heap of fragile code to cover the .bst file too.
In my view this one get's filed under WONTFIX."
install
I've investigated this issue. I have not been able to find any
reason for the adoption of path with spaces to make the
Windows OS work better or work better with other programs.
People just like to type Phrases with Spaces instead
Phrases-with-hyphens_or_underscores.
What does Phrases with Spaces have to do with justifying
using paths with spaces for Miktex?? The problem comes
putting the .bst file into the odd location. It took six months
for a clever developer to stumble across/discover this problem.
It really has nothing to do with
People just like to type Phrases with Spaces instead
Phrases-with-hyphens_or_underscores.
You think my analogy implied this because you didn't
understand the issue involved. My analogy meant that
Lyx doesn't have to keep up with Jones's when the Jones's
are self-serving implement practices which interfere with
the problem free operation of Lyx and helpers.
It's a bit of 'making life simpler for the user' vs 'making life
simpler for the prorammer'.
Of course, in the *nix world most users are more or less programmers as
well so they tend to agree on the fact that life should be simple for
programmers as well.
I think then that the default install of a path with spaces is not
part of basic windows guidelines.
For certain countries it is. Most notably for GB and the US.
Andre'
It is not a guideline it is a worthless anal habit. It is not a feature
but a deliberate attack on ported software that does not pay
a tribute to Microsoft. Other victims besides ghostscript include:
http://www.mozilla.com/firefox/releases/1.0.1.html Linux and Unix
If Firefox is installed to a location with spaces in the path, Firefox
may not be able to set itself as Default browser and may keep prompting at
startup. The work around is to install into a path without spaces.
----------------------------------------
Hi Srikanth,
the problem is the space in path - in "Program Files". To be able to
build targets with Real-Time Windows Target, the path where you install
MATLAB cannot contain spaces. So the workaround would be to
move your MATLAB installation to e.g. E:\MATLAB704.
--------------------------------------------
To verify that your system PATH variable is set correctly (it should
have the directory containing vtk*.dll, including vtk*Java.dll). One
thing that I noticed recently on some WinXP system is that dynamic
libraries from paths containing spaces, for instance, C:\Program
Files\vtk\bin, may not load correctly, even if you put them in quotation
marks"". Best way to fix it is to move your dlls into a path without
spaces, for instance c:\apps\vtk42.
-------------------------------------------
Quincy 99 is a Windows 95/98/NT/2000 hosted Integrated Development
Environment (IDE) front end for the GNU gcc C/C++ compilers. Build 15 [this
version] works with the Mingw32 port of gcc 2.95.2 [the latest
version]. You will have to make sure that there are no spaces in the
folder name or in any higher folder name in the hierarchy. For example,
you cannot install into the Windows 9x "Program Files" folder. The
compilers do not work properly when there are spaces in the folder names.
------------------------------------------------
I found hardly a true appropriate remark in either Gerz or your post,
Stephen
