Re: [patch] Re: \textvisiblespace
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
On Wed, Jul 20, 2011 at 5:50 PM, Uwe Stöhrwrote: > 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
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
Am 20.07.2011 18:55, schrieb Liviu Andronic: On Wed, Jul 20, 2011 at 5:50 PM, Uwe Stöhrwrote: 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)
On 20/07/2011 12:55 PM, Liviu Andronic wrote: On Wed, Jul 20, 2011 at 5:50 PM, Uwe Stöhrwrote: 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
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öhrwrote: 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
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
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
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
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