Re: [patch] Re: \textvisiblespace

2011-07-20 Thread Jürgen Spitzmüller
Uwe Stöhr wrote:
   It is totally confusing that we have the menu Insert-Special character
 that already provides the char. 

I don't understand.

 OK, this doesn't work on windows because
 the Windows standard fonts don't support to display this character and one
 therefore cannot even see it in the special character dialog. But we also
 have the menu for special formatting characters and that is what
 \textvisiblespace is.

Sure. InsetSpace _is_ in that menu.

 Inserting it as a space is illogical. I mean with a character I can really
 do something, with a space not. So I can paint it red, I can emphasize it,
 I can scale and rotate it - all because it is a character. All this cannot
 be done with a space. Or do you ant to extend the space insert that it is
 possible to apply character styles and font formattings to it.
 So yes, the concept of spaces and characters is important here.

Of course I can scale a space. Compare foo~bar to foo{\huge ~}bar
I can also emphasize it. The difference is more subtle, but it's there.

Then we have the brace, the arrows, the line and all in InsetSpace (hfill). 
These I can even paint red.

  The discussion about glyph classification (technical symbol vs.
  space) is completely irrelevant for most users. They might just want
  to make a space visible, and that's what \textvisible space is useful
  for.
 
 They can already do this in listings and when I want a character to
 visualize it is logical to me that I insert an appropriate character for
 it.

But what if I do not want to have a listing, but a visible space in text? 
Listing is a special case.

 But it is illogical that I can transform a real space to a character with
 all the consequences in an inset that is designed for spaced and not
 characters.

No. See above.

Jürgen

   but to sum up as the time passed we have 3 patches:
   1. special symbol - simple Unicode char
   2. part of insetspace
   3. special symbol - specific drawing
 
 regards Uwe



Re: build error with trunk on openSUSE

2011-07-20 Thread Stephan Witt
Am 20.07.2011 um 01:09 schrieb Pavel Sanda:

 Stephan Witt wrote:
 In case of interest
 
 QT_VERSION=4.10.3 sh -c 'v=0x0; for i in ${QT_VERSION//./ } ; do case $i 
 in 10) v=$v0a ;; 11) v=$v0b ;; 12) v=$v0c ;; 13) v=$v0d ;; 14) 
 v=$v0e ;; 15) v=$v0f ;; *) v=$v0$i ;; esac ; done; echo $v'
 
 prints 0x0040a03
 
 how do cmake people solve this in windows? pavel

This is not for cmake. It's a possible replacement for the construct with bc in
src/frontends/qt4/Makefile.am

I don't know if add bc as a build requirement is a solution too.

Stephan

Re: build error with trunk on openSUSE

2011-07-20 Thread Enrico Forestieri
On Wed, Jul 20, 2011 at 08:57:46AM +0200, Stephan Witt wrote:
 Am 20.07.2011 um 01:09 schrieb Pavel Sanda:
 
  Stephan Witt wrote:
  In case of interest
  
  QT_VERSION=4.10.3 sh -c 'v=0x0; for i in ${QT_VERSION//./ } ; do case 
  $i in 10) v=$v0a ;; 11) v=$v0b ;; 12) v=$v0c ;; 13) v=$v0d ;; 14) 
  v=$v0e ;; 15) v=$v0f ;; *) v=$v0$i ;; esac ; done; echo $v'
  
  prints 0x0040a03

This code uses bash specific features and fails with a posix shell (try it
with dash, for example). As a matter of fact, it fails on solaris.

  how do cmake people solve this in windows? pavel
 
 This is not for cmake. It's a possible replacement for the construct with bc 
 in
 src/frontends/qt4/Makefile.am
 
 I don't know if add bc as a build requirement is a solution too.

The basic calculator (bc) is part of the Single UNIX specification, so it
is expected to be there, such as one expects that ls is there. So, I don't
know what it means adding bc as a build requirement, as we don't add
tens of other commands as build requirement and simply expect that they
are there.

-- 
Enrico


Re: about the initials module

2011-07-20 Thread Jean-Marc Lasgouttes

Le 20/07/2011 06:26, Uwe Stöhr a écrit :

Am 20.07.2011 03:45, schrieb Pavel Sanda:

on many linux distros latex is divided on the basic packages and extra
sets for advanced usage only - not installed by default and without
any automatical setup on request like miktex on windows do.


It is impossible to take care about every OS. For MiKTeX, MacTeX/TeXLive
there is no problem and TeXLive works on all platforms.

In general installing a LateX package is not difficult and LateX tells
you which package it misses. On many platforms it even works
automatically as long as you have an Internet connection. On Windows all
module packages are even installed automatically together with LyX when
LyX is started the first time. This will hopefully also be the case in
TeXLive 2011.


This is funny when we see the code we had to add to adapt to miktex 
quirks (like checking for packages in configure.py just to let miktex 
install them). We are leaning to having lyx work well only when 
connected to internet just because miktex forces us to do it, and this 
is a terrible user interface IMO.


miktex also is just another distro.

JMarc


Re: about the initials module

2011-07-20 Thread Uwe Stöhr

Am 20.07.2011 12:08, schrieb Jean-Marc Lasgouttes:


This is funny when we see the code we had to add to adapt to miktex quirks 
(like checking for
packages in configure.py just to let miktex install them).


(MiKTeX is just one of the various LaTeX distros but one of the most used one as it is more or less 
the standard on Windows.)


But installing a package is really easy with TeXLive thanks to its package manager and TeXLive is 
the reference distro of the LateX community and is available on all platforms and can even be used 
as Live distribution without installing it.


However, I try to keep the exotic package away from the UserGuide. But the EmbeddedObjecs manual 
that contains now the Initials documentation was from its beginning designed to explain more special 
features and therefore uses since ever some non-standard packages like e.g. arydshln and the like. 
The first note in the manual lists the packages.


For the UserGuide I added a section about special lists features that requires enumitem. This 
package might not be standard but is in my opinion in the same level as e.g. wrapfig that is already 
required since a long time. The advantage is that we for the first time can show the users solutions 
for problems that appear very frequently on the users list. In my experience the question how to 
resume a list is one of most often asked questions in the list.

While I'm at it, many thanks Günter for the enumitem module!


We are leaning to having lyx work well
only when connected to internet just because miktex forces us to do it, and 
this is a terrible user
interface IMO.


There is still the possibility to install/use TeXLive with all packages on CTAN. Then no Internet 
connection is necessary, except for the first time where you download TeXLive.
But also with MiKTeX you only need Internet access when installing LyX. Then you already have all 
packages installed that are supported by LyX and its modules and can work offline for the future.
But this is the same as for many other programs. Take for example MSVC or Adobe Reader. For these 
you also need Internet connection to install the programs.
But in general on all platforms you always have to have at least once Internet connection. Also for 
LyX on Linux and Mac you need an Internet connection to download LyX or install its package.


So the statement lyx work well only when connected to internet is not correct. If this would be 
correct then you are right that this is not acceptable.


regards Uwe


Re: [patch] Re: \textvisiblespace

2011-07-20 Thread Uwe Stöhr

Am 20.07.2011 08:10, schrieb Jürgen Spitzmüller:


   It is totally confusing that we have the menu Insert-Special character
that already provides the char.


I don't understand.


We have the menu
Insert-Special character
for characters but the space inset is in the menu
Insert-Formatting
So the space inset is a formating inset and \textvisiblespace is a character that you would not 
expect in the Formattings menu.

Moreover \textvisiblespace is already available in the menu
Insert-Special character
via Symbols...


OK, this doesn't work on windows because
the Windows standard fonts don't support to display this character and one
therefore cannot even see it in the special character dialog. But we also
have the menu for special formatting characters and that is what
\textvisiblespace is.


Sure. InsetSpace _is_ in that menu.


No it is in Formatting not in Special character.


Inserting it as a space is illogical. I mean with a character I can really
do something, with a space not. So I can paint it red, I can emphasize it,
I can scale and rotate it - all because it is a character. All this cannot
be done with a space. Or do you ant to extend the space insert that it is
possible to apply character styles and font formattings to it.
So yes, the concept of spaces and characters is important here.


Of course I can scale a space. Compare foo~bar to foo{\huge ~}bar
I can also emphasize it. The difference is more subtle, but it's there.


OK, and with my solution one would also not see within LyX when it is e.g. painted red. Will this be 
visible in the InsetSpace implementation?



Then we have the brace, the arrows, the line and all in InsetSpace (hfill).
These I can even paint red.


The implementation in InsetSpace is indeed better for the on-screen representation. So I'm convinced 
now, but we should do something about the menu logic. Perhaps we can use the menu Insert-Special 
character-Visible space that inserts an InsetSpace with \textvisiblespace?



But it is illogical that I can transform a real space to a character with
all the consequences in an inset that is designed for spaced and not
characters.


No. See above.


At this point I'm not yet convinced. I still think that also in the InsetSpace implementation, it 
should not be possible to change a visible space to e.g. an interword space because their width in 
the output will not be the same.


regards Uwe


Re: about the initials module

2011-07-20 Thread Liviu Andronic
On Wed, Jul 20, 2011 at 5:50 PM, Uwe Stöhr uwesto...@web.de wrote:
 But also with MiKTeX you only need Internet access when installing LyX. Then
 you already have all packages installed that are supported by LyX and its
 modules and can work offline for the future.

This is true only in part. It doesn't hold if 'Install on-the-fly' is
set to 'No', and it can backfire when set to 'Ask'.

I have recently installed LyX with MiKTeX on several Windows systems
the one big hurdle I have run into, using default settings and even
though I'm a seasoned user of LyX, was MiKTeX's 'Ask' whether to
install required packages on-the-fly.

First it's confusing: as a user, you don't really know why the LyX
installer asks you all these scary questions with funny names, and why
it keeps asking the same question all over again. (A long time ago
when I was first confronted with the Windows LyX installer, all the
'Install this required package?' questions got me to abort the
installation several times.) Second, it's so very slow and requires
too much intervention from the user. (After the 6th-7th such question
I usually don't care any more and switch it to 'Yes, always install
on-the-fly'.)

In all, I would say that 'Ask' is an impractical default for the LyX
installation. 'No' is unacceptable, because you get a LyX installation
where the chances are high that documents won't compile for no
apparent reason. (Only yesterday a friend of mine complained that it
took him a lot of work and internet searches just to get a basic
document compile with LyX and MiKTeX. It seemed to be an issue of
missing packages.)

Thus, would the maintainers of the installer consider using 'Yes' as a
default for the MiKTeX on-the-fly installation of packages? Regards
Liviu


Re: build error with trunk on openSUSE

2011-07-20 Thread Stephan Witt

Am 20.07.2011 um 10:52 schrieb Enrico Forestieri:

 On Wed, Jul 20, 2011 at 08:57:46AM +0200, Stephan Witt wrote:
 Am 20.07.2011 um 01:09 schrieb Pavel Sanda:
 
 Stephan Witt wrote:
 In case of interest
 
 QT_VERSION=4.10.3 sh -c 'v=0x0; for i in ${QT_VERSION//./ } ; do case 
 $i in 10) v=$v0a ;; 11) v=$v0b ;; 12) v=$v0c ;; 13) v=$v0d ;; 14) 
 v=$v0e ;; 15) v=$v0f ;; *) v=$v0$i ;; esac ; done; echo $v'
 
 prints 0x0040a03
 
 This code uses bash specific features and fails with a posix shell (try it
 with dash, for example). As a matter of fact, it fails on solaris.

Ok. I know the pattern matching substitution is not bourne shell.
The bc replacement is the case part of the solution.

 
 how do cmake people solve this in windows? pavel
 
 This is not for cmake. It's a possible replacement for the construct with bc 
 in
 src/frontends/qt4/Makefile.am
 
 I don't know if add bc as a build requirement is a solution too.
 
 The basic calculator (bc) is part of the Single UNIX specification, so it
 is expected to be there, such as one expects that ls is there. So, I don't
 know what it means adding bc as a build requirement, as we don't add
 tens of other commands as build requirement and simply expect that they
 are there.

Cor wrote it was needed to add on the build system.

I have no problem with the bc based solution.

Stephan

Re: about the initials module

2011-07-20 Thread Uwe Stöhr

Am 20.07.2011 18:55, schrieb Liviu Andronic:


On Wed, Jul 20, 2011 at 5:50 PM, Uwe Stöhruwesto...@web.de  wrote:

But also with MiKTeX you only need Internet access when installing LyX. Then
you already have all packages installed that are supported by LyX and its
modules and can work offline for the future.


This is true only in part. It doesn't hold if 'Install on-the-fly' is
set to 'No', and it can backfire when set to 'Ask'.


The LyX for Windows installer therefore sets it automatically to 'Install 
on-the-fly'.


I have recently installed LyX with MiKTeX on several Windows systems
the one big hurdle I have run into, using default settings and even
though I'm a seasoned user of LyX, was MiKTeX's 'Ask' whether to
install required packages on-the-fly.


Even in case this dialog pops once, you can use the message not to show it again and you will get 
the 'Install on-the-fly' feature.



First it's confusing: as a user, you don't really know why the LyX
installer asks you all these scary questions


I don't understand. The Windows installer sets the 'Install on-the-fly' option for you so you should 
not get these MiKTeX dialog. It seems you found an installer bug.


regards Uwe


MiKTeX on-the-fly installation and the windows installer (was: Re: about the initials module)

2011-07-20 Thread Julien Rioux

On 20/07/2011 12:55 PM, Liviu Andronic wrote:

On Wed, Jul 20, 2011 at 5:50 PM, Uwe Stöhruwesto...@web.de  wrote:

But also with MiKTeX you only need Internet access when installing LyX. Then
you already have all packages installed that are supported by LyX and its
modules and can work offline for the future.


This is true only in part. It doesn't hold if 'Install on-the-fly' is
set to 'No', and it can backfire when set to 'Ask'.

I have recently installed LyX with MiKTeX on several Windows systems
the one big hurdle I have run into, using default settings and even
though I'm a seasoned user of LyX, was MiKTeX's 'Ask' whether to
install required packages on-the-fly.

First it's confusing: as a user, you don't really know why the LyX
installer asks you all these scary questions with funny names, and why
it keeps asking the same question all over again. (A long time ago
when I was first confronted with the Windows LyX installer, all the
'Install this required package?' questions got me to abort the
installation several times.) Second, it's so very slow and requires
too much intervention from the user. (After the 6th-7th such question
I usually don't care any more and switch it to 'Yes, always install
on-the-fly'.)

In all, I would say that 'Ask' is an impractical default for the LyX
installation. 'No' is unacceptable, because you get a LyX installation
where the chances are high that documents won't compile for no
apparent reason. (Only yesterday a friend of mine complained that it
took him a lot of work and internet searches just to get a basic
document compile with LyX and MiKTeX. It seemed to be an issue of
missing packages.)

Thus, would the maintainers of the installer consider using 'Yes' as a
default for the MiKTeX on-the-fly installation of packages? Regards
Liviu



Great observation. Just like you, it also frustrates me to have to click 
yes/no a number of times, with several minutes inbetween each requests 
to the user, as packages are being downloaded one-by-one. However, it 
would frustrate me even more if my MiKTeX setting was changed from 'Ask' 
to 'Yes', and packages I really don't want get installed behind my back. 
Being able to change the MiKTeX 'Yes/No/Ask' setting from the installer 
would be fine with me, but definitely no changing behind my back.


Additionally to your comment, let me say that in my opinion the LyX 
installer should not rely on on-the-fly installation. Even with the 
automatic download setting of MiKTeX set to 'Yes', the download and 
installation still occurs package-by-package and is slow. Instead I 
picture that the installer would offer a selectable list of packages, 
presented in a single frame in the GUI. The user would make all their 
decisions at once on this frame. Then a click of the Next button calls 
the MiKTeX package manager directly using the command line interface of 
MiKTeX, mpm (the call is something like mpm --admin 
--install-some=list.txt where list.txt is the list of user selected 
packages). You can even query the MiKTeX installation to find out 
whether these packages are already installed or not, and give feedback 
in the GUI if they are.


Regards,
Julien



Re: about the initials module

2011-07-20 Thread Julien Rioux

On 20/07/2011 1:35 PM, Uwe Stöhr wrote:

Am 20.07.2011 18:55, schrieb Liviu Andronic:


On Wed, Jul 20, 2011 at 5:50 PM, Uwe Stöhruwesto...@web.de wrote:

But also with MiKTeX you only need Internet access when installing
LyX. Then
you already have all packages installed that are supported by LyX and
its
modules and can work offline for the future.


This is true only in part. It doesn't hold if 'Install on-the-fly' is
set to 'No', and it can backfire when set to 'Ask'.


The LyX for Windows installer therefore sets it automatically to
'Install on-the-fly'.


I have recently installed LyX with MiKTeX on several Windows systems
the one big hurdle I have run into, using default settings and even
though I'm a seasoned user of LyX, was MiKTeX's 'Ask' whether to
install required packages on-the-fly.


Even in case this dialog pops once, you can use the message not to show
it again and you will get the 'Install on-the-fly' feature.


First it's confusing: as a user, you don't really know why the LyX
installer asks you all these scary questions


I don't understand. The Windows installer sets the 'Install on-the-fly'
option for you so you should not get these MiKTeX dialog. It seems you
found an installer bug.



I think in the 1.6 series, your alt installer did this, but the official 
installer did not. This has personally kept me away from your alt installer.



regards Uwe



Regards,
Julien



Re: about the initials module

2011-07-20 Thread Pavel Sanda
Uwe Stöhr wrote:
 It is impossible to take care about every OS. For MiKTeX, MacTeX/TeXLive 
 there is no problem and TeXLive works on all platforms.

 In your Linux distro, the package might be tricky to install in another 
 distro it is not tricky. What is a common package in your distro might be a 
 non- standard package in another distro. There are too many distros 
 available and LyX doesn't need to take care about the spacial packaging of 
 your OS. But it needs to describe its features.

 In general installing a LateX package is not difficult and LateX tells you 
 which package it misses. On many platforms it even works automatically as 
 long as you have an Internet connection. On Windows all module packages are 
 even installed automatically together with LyX when LyX is started the 
 first time. This will hopefully also be the case in TeXLive 2011.

what is written in the paragraphs around above shows that you have little idea 
how 
things are done except of the windows pond. texlive creature is way too big to
be installed and splitting it into parts where advanced parts are installed on
administrator request only (not necessarily under user control). this is done
on important linux archs, i'm not picking some skeleton from the closet.

although automatic updates might be possible with upcoming texlive installs
it wouldn't be prefered way of packaging except of windows.

so your usage of 'all platforms' seems to be synonym to 'distribution workflow
on windows' and translation of 'It is impossible to take care about every OS'
should be read as 'it is impossible to take care about anything except of
windows OS'.

pavel


Re: build error with trunk on openSUSE

2011-07-20 Thread Enrico Forestieri
On Wed, Jul 20, 2011 at 07:23:51PM +0200, Stephan Witt wrote:
 
 Am 20.07.2011 um 10:52 schrieb Enrico Forestieri:
 
  On Wed, Jul 20, 2011 at 08:57:46AM +0200, Stephan Witt wrote:
  Am 20.07.2011 um 01:09 schrieb Pavel Sanda:
  
  Stephan Witt wrote:
  In case of interest
  
  QT_VERSION=4.10.3 sh -c 'v=0x0; for i in ${QT_VERSION//./ } ; do 
  case $i in 10) v=$v0a ;; 11) v=$v0b ;; 12) v=$v0c ;; 13) v=$v0d 
  ;; 14) v=$v0e ;; 15) v=$v0f ;; *) v=$v0$i ;; esac ; done; echo $v'
  
  prints 0x0040a03
  
  This code uses bash specific features and fails with a posix shell (try it
  with dash, for example). As a matter of fact, it fails on solaris.
 
 Ok. I know the pattern matching substitution is not bourne shell.
 The bc replacement is the case part of the solution.
 
  
  how do cmake people solve this in windows? pavel
  
  This is not for cmake. It's a possible replacement for the construct with 
  bc in
  src/frontends/qt4/Makefile.am
  
  I don't know if add bc as a build requirement is a solution too.
  
  The basic calculator (bc) is part of the Single UNIX specification, so it
  is expected to be there, such as one expects that ls is there. So, I don't
  know what it means adding bc as a build requirement, as we don't add
  tens of other commands as build requirement and simply expect that they
  are there.
 
 Cor wrote it was needed to add on the build system.
 
 I have no problem with the bc based solution.

I also have no problem with any other portable solution avoiding bc.
Here is a posix compliant version of the above:

QT_VERSION=4.10.3 sh -c 'IFS=.; v=0x; for i in $QT_VERSION; do case $i in 
10) v=$v0a;; 11) v=$v0b;; 12) v=$v0c;; 13) v=$v0d;; 14) v=$v0e;; 15) 
v=$v0f;; *) v=$v0$i;; esac; done; echo $v'

-- 
Enrico


Re: about the initials module

2011-07-20 Thread Pavel Sanda
Uwe Stöhr wrote:
 moreover there is no intuitive way how to typeset big initial without
 reading manual where special construct needs to be learned.
 the charstyle path is not clean, but for the basic usage works without any 
 need
 to read manual pages.

 What do you expect? No style is self-explanatory. Of course one needs to 
 read first how it works.

yes, we are from different worlds. i read documentation exceptionaly and
most of my know-how of software comes from playing with trial and error.
thus the two hints inside the module are quite enough for user like me :)
in the same vein i'm not way too much worried about possible latex errors.
i have seen zilion of them while working with lyx and when they happen i just
fix the problem. 

thats why i'm not jumping for joy about the style solution. its just nicer
ERT and there is no way how to use it except of reading some additional
docs.

as admitted the charstyle is somewhat hackish and poor support because i dont
see way how to solve it correctly with our machinery. it works by chance but it
works. the latex problems is solvable by ERT similarly as you are doing in the
style solution. if somebody is unable to solve latex issues he will encounter
troubles with your solution as well - so there is not much difference.

 Our aim should be to 
 provide features that do work in all cases and don't interfere with other 
 ones, or even lead to LaTeX errors.

its nice to read this just mail after you calmly throw to the dustbin warnings
about latex issues (ie missing packages) in the manuals. because we can't
care about all cases.

 you are probably right that when you use combinations of
 lettrine with weird stuff around, weird things can happen. like with many 
 other
 insets in lyx.

 Sorry, but I cannot agree to this. We worked hard that this doesn't happen 
 otherwise LyX would be quite useless for real life documents like a thesis 
 or a business report. Where do you see that problems? If there is one it is 
 a bug we need to fix.

especially the starting pages of papers with wild combination of title, date,
subtitile, authors, affiliation, abstract are rich source of latex errs.  using
space inset is magic, ie. you can not trust that putting 1.mm space in lyx 
document
will have this result in pdf output. you never know what happen unless you
latex it. or mixing different latex packages. or using different output routes
like postscript vs pdf. or insert weird combination of insets into each other.
or using something different than windows when you want to typeset our manuals 
:))

 For compatibility reasons I left your style definition

 first of all - as far as compatibility reasons is concerned - your last 
 changes
 will cause lyx 2.0.0 not being able to compile some 2.0.x0 files due to
 missing style

 You mean because I added a style? Yes, LyX 2.0.0 will tell you that a style 
 is unknown when loading a file made with LyX 2.0.1 that usess my new style. 
 But this cannot be avoided. Take for example the various layout files we 
 need to update from time to time when there are new versions. Especially 
 for example the scientific paper classes we have to add new styles or 
 rename some LaTeX commands all the time.

 but I think we should remove it.

 in branch? then some files produced by lyx 2.0.x1 wont be compilable with
 lyx 2.0.0.

 As I said, better we get rid of the buggy code right now than to wait 
 longer. Currently the probability that people use the feature is relatively 
 low because there was no documentation and LyX 2.0.0 is still quites new 
 (many users I know wait for the 0.1 release before they switch from 1.6 to 
 2.0). And we cannot wait until LyX 2.1 because this might be a year and it 
 is in my opinion not acceptable to provide a style that could lead to LaTeX 
 errors.

*shrug*
this is call for Richard.

to summary my pov for better review:
- i admit that charstyle solution is poor, because it allows only special case 
of initials.
- moreover in specific combination it can lead to latex erros unless you use 
specific ERT to fix it.
- seeing the debate now i admit that its questionable whether it should have
  been added to lyx at all and let the enh request wontfix instead. however
  some of these points have been raised months ago and nobody else was against.
  its my lesson to be more conservative about putting new modules to the tree.
- the new added style solution makes it possible to use lettrine package to its 
depth.
  its enhacenment to the current state of things.
- both solutions can lead to latex errors by missing some ERT, both can be fixed
  (at least the charstyle counterexample posted).
for branch:
- new style can be added, lyx 2.0.0 won't process 2.0.1 files. i dont remember 
what was the
  previous policies about adding stuff.
- i dont see latex the problems described as something detrimental, the more 
that the second
  solution calls for the same problems (ie instruct user to use ERT commands).
  if other 

ubuntu - an error when I double click on a .lyx flie, but no error when I run from terminal

2011-07-20 Thread Xu Wang
If I start LyX from the terminal, everything works fine.


But if I just start LyX by double clicking on a .lyx file, then I have
problems (pasted at the end of email). I have tried reconfigure.

Do I have a problem with permissions or something? I don't see why the two
would be different.


I have tried reconfigure and reinstalling and neither has helped.


Here is the error in LyX:

File does not exist: /tmp/lyx_tmpdir.MT6574/lyx_tmpbuf2/testfile.pdf


In the terminal, here is the output:

Systemcall.cpp(238): Systemcall: 'pdflatex  testfile.tex' did not start!
Systemcall.cpp(239): error The process failed to start. Either the invoked
program is missing, or you may have insufficient permissions to invoke the
program.
Error: Cannot view file

File does not exist: /tmp/lyx_tmpdir.MT6574/lyx_tmpbuf2/testfile.pdf


I am using Ubuntu 11.04 64-bit.
LyX version 2.0.1svn
Qt 4.7.2
xuwang@ubuntu:~$ lyx --version
LyX 2.0.1svn (not released yet)
Built on Jul 13 2011, 00:57:55
Configuration
  Host type:x86_64-unknown-linux-gnu
  Special build flags:  build=development warnings assertions
stdlib-debug concept-checks
  C   Compiler: gcc
  C   Compiler LyX flags:
  C   Compiler flags:   -Wextra -Wall   -g -O
  C++ Compiler: g++ (4.5.2)
  C++ Compiler LyX flags:
  C++ Compiler flags:   -Wextra -Wall   -g -O
  Linker flags:
  Linker user flags:
  Qt 4 Frontend:
  Qt 4 version: 4.7.2
  Packaging:posix
  LyX binary dir:   /usr/local/bin
  LyX files dir:/usr/local/share/lyx

any ideas?

Thank you, Xu


Re: [patch] Re: \textvisiblespace

2011-07-20 Thread Jürgen Spitzmüller
Uwe Stöhr wrote:
>   It is totally confusing that we have the menu Insert->Special character
> that already provides the char. 

I don't understand.

> OK, this doesn't work on windows because
> the Windows standard fonts don't support to display this character and one
> therefore cannot even see it in the special character dialog. But we also
> have the menu for special formatting characters and that is what
> \textvisiblespace is.

Sure. InsetSpace _is_ in that menu.

> Inserting it as a space is illogical. I mean with a character I can really
> do something, with a space not. So I can paint it red, I can emphasize it,
> I can scale and rotate it - all because it is a character. All this cannot
> be done with a space. Or do you ant to extend the space insert that it is
> possible to apply character styles and font formattings to it.
> So yes, the concept of spaces and characters is important here.

Of course I can scale a space. Compare "foo~bar" to "foo{\huge ~}bar"
I can also emphasize it. The difference is more subtle, but it's there.

Then we have the brace, the arrows, the line and all in InsetSpace (hfill). 
These I can even paint red.

> > The discussion about glyph classification ("technical symbol" vs.
> > "space") is completely irrelevant for most users. They might just want
> > to "make a space visible", and that's what \textvisible space is useful
> > for.
> 
> They can already do this in listings and when I want a character to
> visualize it is logical to me that I insert an appropriate character for
> it.

But what if I do not want to have a listing, but a visible space in text? 
Listing is a special case.

> But it is illogical that I can transform a real space to a character with
> all the consequences in an inset that is designed for spaced and not
> characters.

No. See above.

Jürgen

>  > but to sum up as the time passed we have 3 patches:
>  > 1. special symbol - simple Unicode char
>  > 2. part of insetspace
>  > 3. special symbol - specific drawing
> 
> regards Uwe



Re: build error with trunk on openSUSE

2011-07-20 Thread Stephan Witt
Am 20.07.2011 um 01:09 schrieb Pavel Sanda:

> Stephan Witt wrote:
>> In case of interest
>> 
>> QT_VERSION="4.10.3" sh -c 'v="0x0"; for i in ${QT_VERSION//./ } ; do case $i 
>> in 10) v=$v"0a" ;; 11) v=$v"0b" ;; 12) v=$v"0c" ;; 13) v=$v"0d" ;; 14) 
>> v=$v"0e" ;; 15) v=$v"0f" ;; *) v=$v"0"$i ;; esac ; done; echo $v'
>> 
>> prints 0x0040a03
> 
> how do cmake people solve this in windows? pavel

This is not for cmake. It's a possible replacement for the construct with bc in
src/frontends/qt4/Makefile.am

I don't know if add bc as a build requirement is a solution too.

Stephan

Re: build error with trunk on openSUSE

2011-07-20 Thread Enrico Forestieri
On Wed, Jul 20, 2011 at 08:57:46AM +0200, Stephan Witt wrote:
> Am 20.07.2011 um 01:09 schrieb Pavel Sanda:
> 
> > Stephan Witt wrote:
> >> In case of interest
> >> 
> >> QT_VERSION="4.10.3" sh -c 'v="0x0"; for i in ${QT_VERSION//./ } ; do case 
> >> $i in 10) v=$v"0a" ;; 11) v=$v"0b" ;; 12) v=$v"0c" ;; 13) v=$v"0d" ;; 14) 
> >> v=$v"0e" ;; 15) v=$v"0f" ;; *) v=$v"0"$i ;; esac ; done; echo $v'
> >> 
> >> prints 0x0040a03

This code uses bash specific features and fails with a posix shell (try it
with dash, for example). As a matter of fact, it fails on solaris.

> > how do cmake people solve this in windows? pavel
> 
> This is not for cmake. It's a possible replacement for the construct with bc 
> in
> src/frontends/qt4/Makefile.am
> 
> I don't know if add bc as a build requirement is a solution too.

The basic calculator (bc) is part of the Single UNIX specification, so it
is expected to be there, such as one expects that ls is there. So, I don't
know what it means "adding bc as a build requirement", as we don't add
tens of other commands as build requirement and simply expect that they
are there.

-- 
Enrico


Re: about the initials module

2011-07-20 Thread Jean-Marc Lasgouttes

Le 20/07/2011 06:26, Uwe Stöhr a écrit :

Am 20.07.2011 03:45, schrieb Pavel Sanda:

on many linux distros latex is divided on the basic packages and extra
sets for advanced usage only - not installed by default and without
any automatical setup on request like miktex on windows do.


It is impossible to take care about every OS. For MiKTeX, MacTeX/TeXLive
there is no problem and TeXLive works on all platforms.

In general installing a LateX package is not difficult and LateX tells
you which package it misses. On many platforms it even works
automatically as long as you have an Internet connection. On Windows all
module packages are even installed automatically together with LyX when
LyX is started the first time. This will hopefully also be the case in
TeXLive 2011.


This is funny when we see the code we had to add to adapt to miktex 
quirks (like checking for packages in configure.py just to let miktex 
install them). We are leaning to having lyx work well only when 
connected to internet just because miktex forces us to do it, and this 
is a terrible user interface IMO.


miktex also is just another distro.

JMarc


Re: about the initials module

2011-07-20 Thread Uwe Stöhr

Am 20.07.2011 12:08, schrieb Jean-Marc Lasgouttes:


This is funny when we see the code we had to add to adapt to miktex quirks 
(like checking for
packages in configure.py just to let miktex install them).


(MiKTeX is just one of the various LaTeX distros but one of the most used one as it is more or less 
the standard on Windows.)


But installing a package is really easy with TeXLive thanks to its package manager and TeXLive is 
the reference distro of the LateX community and is available on all platforms and can even be used 
as Live distribution without installing it.


However, I try to keep the exotic package away from the UserGuide. But the EmbeddedObjecs manual 
that contains now the Initials documentation was from its beginning designed to explain more special 
features and therefore uses since ever some non-standard packages like e.g. arydshln and the like. 
The first note in the manual lists the packages.


For the UserGuide I added a section about special lists features that requires enumitem. This 
package might not be standard but is in my opinion in the same level as e.g. wrapfig that is already 
required since a long time. The advantage is that we for the first time can show the users solutions 
for problems that appear very frequently on the users list. In my experience the question how to 
resume a list is one of most often asked questions in the list.

While I'm at it, many thanks Günter for the enumitem module!


We are leaning to having lyx work well
only when connected to internet just because miktex forces us to do it, and 
this is a terrible user
interface IMO.


There is still the possibility to install/use TeXLive with all packages on CTAN. Then no Internet 
connection is necessary, except for the first time where you download TeXLive.
But also with MiKTeX you only need Internet access when installing LyX. Then you already have all 
packages installed that are supported by LyX and its modules and can work offline for the future.
But this is the same as for many other programs. Take for example MSVC or Adobe Reader. For these 
you also need Internet connection to install the programs.
But in general on all platforms you always have to have at least once Internet connection. Also for 
LyX on Linux and Mac you need an Internet connection to download LyX or install its package.


So the statement "lyx work well only when connected to internet" is not correct. If this would be 
correct then you are right that this is not acceptable.


regards Uwe


Re: [patch] Re: \textvisiblespace

2011-07-20 Thread Uwe Stöhr

Am 20.07.2011 08:10, schrieb Jürgen Spitzmüller:


   It is totally confusing that we have the menu Insert->Special character
that already provides the char.


I don't understand.


We have the menu
Insert->Special character
for characters but the space inset is in the menu
Insert->Formatting
So the space inset is a formating inset and \textvisiblespace is a character that you would not 
expect in the Formattings menu.

Moreover \textvisiblespace is already available in the menu
Insert->Special character
via Symbols...


OK, this doesn't work on windows because
the Windows standard fonts don't support to display this character and one
therefore cannot even see it in the special character dialog. But we also
have the menu for special formatting characters and that is what
\textvisiblespace is.


Sure. InsetSpace _is_ in that menu.


No it is in Formatting not in Special character.


Inserting it as a space is illogical. I mean with a character I can really
do something, with a space not. So I can paint it red, I can emphasize it,
I can scale and rotate it - all because it is a character. All this cannot
be done with a space. Or do you ant to extend the space insert that it is
possible to apply character styles and font formattings to it.
So yes, the concept of spaces and characters is important here.


Of course I can scale a space. Compare "foo~bar" to "foo{\huge ~}bar"
I can also emphasize it. The difference is more subtle, but it's there.


OK, and with my solution one would also not see within LyX when it is e.g. painted red. Will this be 
visible in the InsetSpace implementation?



Then we have the brace, the arrows, the line and all in InsetSpace (hfill).
These I can even paint red.


The implementation in InsetSpace is indeed better for the on-screen representation. So I'm convinced 
now, but we should do something about the menu logic. Perhaps we can use the menu Insert->Special 
character->Visible space that inserts an InsetSpace with \textvisiblespace?



But it is illogical that I can transform a real space to a character with
all the consequences in an inset that is designed for spaced and not
characters.


No. See above.


At this point I'm not yet convinced. I still think that also in the InsetSpace implementation, it 
should not be possible to change a visible space to e.g. an interword space because their width in 
the output will not be the same.


regards Uwe


Re: about the initials module

2011-07-20 Thread Liviu Andronic
On Wed, Jul 20, 2011 at 5:50 PM, Uwe Stöhr  wrote:
> But also with MiKTeX you only need Internet access when installing LyX. Then
> you already have all packages installed that are supported by LyX and its
> modules and can work offline for the future.
>
This is true only in part. It doesn't hold if 'Install on-the-fly' is
set to 'No', and it can backfire when set to 'Ask'.

I have recently installed LyX with MiKTeX on several Windows systems
the one big hurdle I have run into, using default settings and even
though I'm a seasoned user of LyX, was MiKTeX's 'Ask' whether to
install required packages on-the-fly.

First it's confusing: as a user, you don't really know why the LyX
installer asks you all these scary questions with funny names, and why
it keeps asking the same question all over again. (A long time ago
when I was first confronted with the Windows LyX installer, all the
'Install this required package?' questions got me to abort the
installation several times.) Second, it's so very slow and requires
too much intervention from the user. (After the 6th-7th such question
I usually don't care any more and switch it to 'Yes, always install
on-the-fly'.)

In all, I would say that 'Ask' is an impractical default for the LyX
installation. 'No' is unacceptable, because you get a LyX installation
where the chances are high that documents won't compile for no
apparent reason. (Only yesterday a friend of mine complained that it
took him a lot of work and internet searches just to get a basic
document compile with LyX and MiKTeX. It seemed to be an issue of
missing packages.)

Thus, would the maintainers of the installer consider using 'Yes' as a
default for the MiKTeX on-the-fly installation of packages? Regards
Liviu


Re: build error with trunk on openSUSE

2011-07-20 Thread Stephan Witt

Am 20.07.2011 um 10:52 schrieb Enrico Forestieri:

> On Wed, Jul 20, 2011 at 08:57:46AM +0200, Stephan Witt wrote:
>> Am 20.07.2011 um 01:09 schrieb Pavel Sanda:
>> 
>>> Stephan Witt wrote:
 In case of interest
 
 QT_VERSION="4.10.3" sh -c 'v="0x0"; for i in ${QT_VERSION//./ } ; do case 
 $i in 10) v=$v"0a" ;; 11) v=$v"0b" ;; 12) v=$v"0c" ;; 13) v=$v"0d" ;; 14) 
 v=$v"0e" ;; 15) v=$v"0f" ;; *) v=$v"0"$i ;; esac ; done; echo $v'
 
 prints 0x0040a03
> 
> This code uses bash specific features and fails with a posix shell (try it
> with dash, for example). As a matter of fact, it fails on solaris.

Ok. I know the pattern matching substitution is not bourne shell.
The bc replacement is the "case" part of the solution.

> 
>>> how do cmake people solve this in windows? pavel
>> 
>> This is not for cmake. It's a possible replacement for the construct with bc 
>> in
>> src/frontends/qt4/Makefile.am
>> 
>> I don't know if add bc as a build requirement is a solution too.
> 
> The basic calculator (bc) is part of the Single UNIX specification, so it
> is expected to be there, such as one expects that ls is there. So, I don't
> know what it means "adding bc as a build requirement", as we don't add
> tens of other commands as build requirement and simply expect that they
> are there.

Cor wrote it was needed to add on the build system.

I have no problem with the bc based solution.

Stephan

Re: about the initials module

2011-07-20 Thread Uwe Stöhr

Am 20.07.2011 18:55, schrieb Liviu Andronic:


On Wed, Jul 20, 2011 at 5:50 PM, Uwe Stöhr  wrote:

But also with MiKTeX you only need Internet access when installing LyX. Then
you already have all packages installed that are supported by LyX and its
modules and can work offline for the future.


This is true only in part. It doesn't hold if 'Install on-the-fly' is
set to 'No', and it can backfire when set to 'Ask'.


The LyX for Windows installer therefore sets it automatically to 'Install 
on-the-fly'.


I have recently installed LyX with MiKTeX on several Windows systems
the one big hurdle I have run into, using default settings and even
though I'm a seasoned user of LyX, was MiKTeX's 'Ask' whether to
install required packages on-the-fly.


Even in case this dialog pops once, you can use the message not to show it again and you will get 
the 'Install on-the-fly' feature.



First it's confusing: as a user, you don't really know why the LyX
installer asks you all these scary questions


I don't understand. The Windows installer sets the 'Install on-the-fly' option for you so you should 
not get these MiKTeX dialog. It seems you found an installer bug.


regards Uwe


MiKTeX on-the-fly installation and the windows installer (was: Re: about the initials module)

2011-07-20 Thread Julien Rioux

On 20/07/2011 12:55 PM, Liviu Andronic wrote:

On Wed, Jul 20, 2011 at 5:50 PM, Uwe Stöhr  wrote:

But also with MiKTeX you only need Internet access when installing LyX. Then
you already have all packages installed that are supported by LyX and its
modules and can work offline for the future.


This is true only in part. It doesn't hold if 'Install on-the-fly' is
set to 'No', and it can backfire when set to 'Ask'.

I have recently installed LyX with MiKTeX on several Windows systems
the one big hurdle I have run into, using default settings and even
though I'm a seasoned user of LyX, was MiKTeX's 'Ask' whether to
install required packages on-the-fly.

First it's confusing: as a user, you don't really know why the LyX
installer asks you all these scary questions with funny names, and why
it keeps asking the same question all over again. (A long time ago
when I was first confronted with the Windows LyX installer, all the
'Install this required package?' questions got me to abort the
installation several times.) Second, it's so very slow and requires
too much intervention from the user. (After the 6th-7th such question
I usually don't care any more and switch it to 'Yes, always install
on-the-fly'.)

In all, I would say that 'Ask' is an impractical default for the LyX
installation. 'No' is unacceptable, because you get a LyX installation
where the chances are high that documents won't compile for no
apparent reason. (Only yesterday a friend of mine complained that it
took him a lot of work and internet searches just to get a basic
document compile with LyX and MiKTeX. It seemed to be an issue of
missing packages.)

Thus, would the maintainers of the installer consider using 'Yes' as a
default for the MiKTeX on-the-fly installation of packages? Regards
Liviu



Great observation. Just like you, it also frustrates me to have to click 
yes/no a number of times, with several minutes inbetween each requests 
to the user, as packages are being downloaded one-by-one. However, it 
would frustrate me even more if my MiKTeX setting was changed from 'Ask' 
to 'Yes', and packages I really don't want get installed behind my back. 
Being able to change the MiKTeX 'Yes/No/Ask' setting from the installer 
would be fine with me, but definitely no changing behind my back.


Additionally to your comment, let me say that in my opinion the LyX 
installer should not rely on on-the-fly installation. Even with the 
automatic download setting of MiKTeX set to 'Yes', the download and 
installation still occurs package-by-package and is slow. Instead I 
picture that the installer would offer a selectable list of packages, 
presented in a single frame in the GUI. The user would make all their 
decisions at once on this frame. Then a click of the Next button calls 
the MiKTeX package manager directly using the command line interface of 
MiKTeX, mpm (the call is something like mpm --admin 
--install-some=list.txt where list.txt is the list of user selected 
packages). You can even query the MiKTeX installation to find out 
whether these packages are already installed or not, and give feedback 
in the GUI if they are.


Regards,
Julien



Re: about the initials module

2011-07-20 Thread Julien Rioux

On 20/07/2011 1:35 PM, Uwe Stöhr wrote:

Am 20.07.2011 18:55, schrieb Liviu Andronic:


On Wed, Jul 20, 2011 at 5:50 PM, Uwe Stöhr wrote:

But also with MiKTeX you only need Internet access when installing
LyX. Then
you already have all packages installed that are supported by LyX and
its
modules and can work offline for the future.


This is true only in part. It doesn't hold if 'Install on-the-fly' is
set to 'No', and it can backfire when set to 'Ask'.


The LyX for Windows installer therefore sets it automatically to
'Install on-the-fly'.


I have recently installed LyX with MiKTeX on several Windows systems
the one big hurdle I have run into, using default settings and even
though I'm a seasoned user of LyX, was MiKTeX's 'Ask' whether to
install required packages on-the-fly.


Even in case this dialog pops once, you can use the message not to show
it again and you will get the 'Install on-the-fly' feature.


First it's confusing: as a user, you don't really know why the LyX
installer asks you all these scary questions


I don't understand. The Windows installer sets the 'Install on-the-fly'
option for you so you should not get these MiKTeX dialog. It seems you
found an installer bug.



I think in the 1.6 series, your alt installer did this, but the official 
installer did not. This has personally kept me away from your alt installer.



regards Uwe



Regards,
Julien



Re: about the initials module

2011-07-20 Thread Pavel Sanda
Uwe Stöhr wrote:
> It is impossible to take care about every OS. For MiKTeX, MacTeX/TeXLive 
> there is no problem and TeXLive works on all platforms.
>
> In your Linux distro, the package might be tricky to install in another 
> distro it is not tricky. What is a common package in your distro might be a 
> non- standard package in another distro. There are too many distros 
> available and LyX doesn't need to take care about the spacial packaging of 
> your OS. But it needs to describe its features.
>
> In general installing a LateX package is not difficult and LateX tells you 
> which package it misses. On many platforms it even works automatically as 
> long as you have an Internet connection. On Windows all module packages are 
> even installed automatically together with LyX when LyX is started the 
> first time. This will hopefully also be the case in TeXLive 2011.

what is written in the paragraphs around above shows that you have little idea 
how 
things are done except of the windows pond. texlive creature is way too big to
be installed and splitting it into parts where advanced parts are installed on
administrator request only (not necessarily under user control). this is done
on important linux archs, i'm not picking some skeleton from the closet.

although automatic updates might be possible with upcoming texlive installs
it wouldn't be prefered way of packaging except of windows.

so your usage of 'all platforms' seems to be synonym to 'distribution workflow
on windows' and translation of 'It is impossible to take care about every OS'
should be read as 'it is impossible to take care about anything except of
windows OS'.

pavel


Re: build error with trunk on openSUSE

2011-07-20 Thread Enrico Forestieri
On Wed, Jul 20, 2011 at 07:23:51PM +0200, Stephan Witt wrote:
> 
> Am 20.07.2011 um 10:52 schrieb Enrico Forestieri:
> 
> > On Wed, Jul 20, 2011 at 08:57:46AM +0200, Stephan Witt wrote:
> >> Am 20.07.2011 um 01:09 schrieb Pavel Sanda:
> >> 
> >>> Stephan Witt wrote:
>  In case of interest
>  
>  QT_VERSION="4.10.3" sh -c 'v="0x0"; for i in ${QT_VERSION//./ } ; do 
>  case $i in 10) v=$v"0a" ;; 11) v=$v"0b" ;; 12) v=$v"0c" ;; 13) v=$v"0d" 
>  ;; 14) v=$v"0e" ;; 15) v=$v"0f" ;; *) v=$v"0"$i ;; esac ; done; echo $v'
>  
>  prints 0x0040a03
> > 
> > This code uses bash specific features and fails with a posix shell (try it
> > with dash, for example). As a matter of fact, it fails on solaris.
> 
> Ok. I know the pattern matching substitution is not bourne shell.
> The bc replacement is the "case" part of the solution.
> 
> > 
> >>> how do cmake people solve this in windows? pavel
> >> 
> >> This is not for cmake. It's a possible replacement for the construct with 
> >> bc in
> >> src/frontends/qt4/Makefile.am
> >> 
> >> I don't know if add bc as a build requirement is a solution too.
> > 
> > The basic calculator (bc) is part of the Single UNIX specification, so it
> > is expected to be there, such as one expects that ls is there. So, I don't
> > know what it means "adding bc as a build requirement", as we don't add
> > tens of other commands as build requirement and simply expect that they
> > are there.
> 
> Cor wrote it was needed to add on the build system.
> 
> I have no problem with the bc based solution.

I also have no problem with any other portable solution avoiding bc.
Here is a posix compliant version of the above:

QT_VERSION="4.10.3" sh -c 'IFS=.; v="0x"; for i in $QT_VERSION; do case $i in 
10) v=$v"0a";; 11) v=$v"0b";; 12) v=$v"0c";; 13) v=$v"0d";; 14) v=$v"0e";; 15) 
v=$v"0f";; *) v=$v"0"$i;; esac; done; echo $v'

-- 
Enrico


Re: about the initials module

2011-07-20 Thread Pavel Sanda
Uwe Stöhr wrote:
>> moreover there is no intuitive way how to typeset big initial without
>> reading manual where special construct needs to be learned.
>> the charstyle path is not clean, but for the basic usage works without any 
>> need
>> to read manual pages.
>
> What do you expect? No style is self-explanatory. Of course one needs to 
> read first how it works.

yes, we are from different worlds. i read documentation exceptionaly and
most of my know-how of software comes from playing with trial and error.
thus the two hints inside the module are quite enough for user like me :)
in the same vein i'm not way too much worried about possible latex errors.
i have seen zilion of them while working with lyx and when they happen i just
fix the problem. 

thats why i'm not jumping for joy about the style solution. its just nicer
ERT and there is no way how to use it except of reading some additional
docs.

as admitted the charstyle is somewhat hackish and poor support because i dont
see way how to solve it correctly with our machinery. it works by chance but it
works. the latex problems is solvable by ERT similarly as you are doing in the
style solution. if somebody is unable to solve latex issues he will encounter
troubles with your solution as well - so there is not much difference.

> Our aim should be to 
> provide features that do work in all cases and don't interfere with other 
> ones, or even lead to LaTeX errors.

its nice to read this just mail after you calmly throw to the dustbin warnings
about latex issues (ie missing packages) in the manuals. because we can't
care about all cases.

>> you are probably right that when you use combinations of
>> lettrine with weird stuff around, weird things can happen. like with many 
>> other
>> insets in lyx.
>
> Sorry, but I cannot agree to this. We worked hard that this doesn't happen 
> otherwise LyX would be quite useless for real life documents like a thesis 
> or a business report. Where do you see that problems? If there is one it is 
> a bug we need to fix.

especially the starting pages of papers with wild combination of title, date,
subtitile, authors, affiliation, abstract are rich source of latex errs.  using
space inset is magic, ie. you can not trust that putting 1.mm space in lyx 
document
will have this result in pdf output. you never know what happen unless you
latex it. or mixing different latex packages. or using different output routes
like postscript vs pdf. or insert weird combination of insets into each other.
or using something different than windows when you want to typeset our manuals 
:))

>>> For compatibility reasons I left your style definition
>>
>> first of all - as far as compatibility reasons is concerned - your last 
>> changes
>> will cause lyx 2.0.0 not being able to compile some 2.0.x>0 files due to
>> missing style
>
> You mean because I added a style? Yes, LyX 2.0.0 will tell you that a style 
> is unknown when loading a file made with LyX 2.0.1 that usess my new style. 
> But this cannot be avoided. Take for example the various layout files we 
> need to update from time to time when there are new versions. Especially 
> for example the scientific paper classes we have to add new styles or 
> rename some LaTeX commands all the time.
>
>>> but I think we should remove it.
>>
>> in branch? then some files produced by lyx 2.0.x>1 wont be compilable with
>> lyx 2.0.0.
>
> As I said, better we get rid of the buggy code right now than to wait 
> longer. Currently the probability that people use the feature is relatively 
> low because there was no documentation and LyX 2.0.0 is still quites new 
> (many users I know wait for the 0.1 release before they switch from 1.6 to 
> 2.0). And we cannot wait until LyX 2.1 because this might be a year and it 
> is in my opinion not acceptable to provide a style that could lead to LaTeX 
> errors.

*shrug*
this is call for Richard.

to summary my pov for better review:
- i admit that charstyle solution is poor, because it allows only special case 
of initials.
- moreover in specific combination it can lead to latex erros unless you use 
specific ERT to fix it.
- seeing the debate now i admit that its questionable whether it should have
  been added to lyx at all and let the enh request wontfix instead. however
  some of these points have been raised months ago and nobody else was against.
  its my lesson to be more conservative about putting new modules to the tree.
- the new added style solution makes it possible to use lettrine package to its 
depth.
  its enhacenment to the current state of things.
- both solutions can lead to latex errors by missing some ERT, both can be fixed
  (at least the charstyle counterexample posted).
for branch:
- new style can be added, lyx 2.0.0 won't process 2.0.1 files. i dont remember 
what was the
  previous policies about adding stuff.
- i dont see latex the problems described as something detrimental, the more 
that the second
  solution calls for 

ubuntu - an error when I double click on a .lyx flie, but no error when I run from terminal

2011-07-20 Thread Xu Wang
If I start LyX from the terminal, everything works fine.


But if I just start LyX by double clicking on a .lyx file, then I have
problems (pasted at the end of email). I have tried reconfigure.

Do I have a problem with permissions or something? I don't see why the two
would be different.


I have tried reconfigure and reinstalling and neither has helped.


Here is the error in LyX:

File does not exist: /tmp/lyx_tmpdir.MT6574/lyx_tmpbuf2/testfile.pdf


In the terminal, here is the output:

Systemcall.cpp(238): Systemcall: 'pdflatex  "testfile.tex"' did not start!
Systemcall.cpp(239): error The process failed to start. Either the invoked
program is missing, or you may have insufficient permissions to invoke the
program.
Error: Cannot view file

File does not exist: /tmp/lyx_tmpdir.MT6574/lyx_tmpbuf2/testfile.pdf


I am using Ubuntu 11.04 64-bit.
LyX version 2.0.1svn
Qt 4.7.2
xuwang@ubuntu:~$ lyx --version
LyX 2.0.1svn (not released yet)
Built on Jul 13 2011, 00:57:55
Configuration
  Host type:x86_64-unknown-linux-gnu
  Special build flags:  build=development warnings assertions
stdlib-debug concept-checks
  C   Compiler: gcc
  C   Compiler LyX flags:
  C   Compiler flags:   -Wextra -Wall   -g -O
  C++ Compiler: g++ (4.5.2)
  C++ Compiler LyX flags:
  C++ Compiler flags:   -Wextra -Wall   -g -O
  Linker flags:
  Linker user flags:
  Qt 4 Frontend:
  Qt 4 version: 4.7.2
  Packaging:posix
  LyX binary dir:   /usr/local/bin
  LyX files dir:/usr/local/share/lyx

any ideas?

Thank you, Xu