Re: [Patch] Re: [patch] key event queue
Martin Vermeer [EMAIL PROTECTED] writes: So it seems to fix most problems we have and feels uniformly better that what we have right now? If so... | Yes, I believe so. | Therefore I will commit the attached, if no new objections come up. I | have somewhat thoroughly tested this with the User Guide. Go ahead. I will redo my test afterwards. -- Lgb
Re: LyX meeting in Paris. What about July 14-18?
Jean-Marc Lasgouttes wrote: I was just gratuitously bitching about the flight to/from Paris, since you said yourself it was too slow and too expensive... Ah, I see. Yes, I'll just let you have all the pain :-) The only compensation is a hot climate, a nice swimming pool, a nice view, and all the Efes you can handle. If the meeting had been at another point in time, I'd have no problem taking an expensive bad connection to Paris, but since it's in the middle of my precious vacation, my tolerance is lower. Regards, Asger
Re: [1.3] Compiling package.C fails on Debian unstable
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Then this will be automatically installed by autogen.sh. Well, we need to have the right one to generate the tarball anyway. Lars Will that help at all? Or does libtool have a problem with Lars FreeBSD and Darwin in general? I gave FreeBSD and Darwin as gratuitous examples, I do not remember the specifics. Contrary to autoconf, libtool relies on a big switch to know what to do with each platform, which means that it is very sensitive to behavioral changes in different versions of OSes. JMarc
Re: LyX meeting in Paris. What about July 14-18?
Asger == Asger Alstrup [EMAIL PROTECTED] writes: Asger If the meeting had been at another point in time, I'd have no Asger problem taking an expensive bad connection to Paris, but Asger since it's in the middle of my precious vacation, my tolerance Asger is lower. Sure, I understand that. JMarc PS: this morning, I was triaging old papers and found ``Project LyX3'', ``Strings and encodings in LyX 1.2'' and ``Design and implementation of the data structure layer in the new LyX kernel'', all of them by the very esteemed Asger Alstrup Nielsen. These even sport nice tables and figures :)
Re: Graphics path with :
Michael Schmitt wrote:
Angus,
I tried to insert a graphics which is located in directory
C:\blabla\blabla. However, LyX 1.3.6cvs complains about the path
containing invalid character :. Didn't this work before?
In src/frontends/controllers/helper_funcs.C, try removing the ':' from
string const get_invalid_chars_latex()
{
string invalid_chars(#$%{}()[]:\^);
if (!lyxrc.tex_allows_spaces)
invalid_chars += ' ';
return invalid_chars;
}
Reading http://wiki.lyx.org/LaTeX/FilesWithSpecialChars and
http://wiki.lyx.org/uploads/LaTeX/FilesWithSpecialChars/filenames.tex, I
don't see why a ':' in a file name won't work, but you're the one using
this stuff...
Please report back if LaTeX is happy.
--
Angus
Re: Graphics path with :
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Reading http://wiki.lyx.org/LaTeX/FilesWithSpecialChars and Angus http://wiki.lyx.org/uploads/LaTeX/FilesWithSpecialChars/filenames.tex, Angus I don't see why a ':' in a file name won't work, but you're the Angus one using this stuff... I guess ':' is a problem in a windows file name if it is not the drive separator. JMarc
Re: Translation of layout files
G == G Milde [EMAIL PROTECTED] writes: G On 27.05.05, Jean-Marc Lasgouttes wrote: G == G Milde [EMAIL PROTECTED] writes: In the meantime, labelstrings help, but they are a hack. And really, if all they are good for is to show the Style name, we have a problem. G Open the dinbrief template, to see what I mean. G E.g. there are 3 Styles that take an address: My_Address (letter G head), Send_To_Address (addressee) ReturnAddress (backaddress in G address window) G IMHO, labeling them is more distinct and transparent than relying G only on different physical layout on screen. I understand what the problem is. I just say that Labelstring is not supposed to be used for that. But for now, it will be OK. G Also, a number of LaTeX commands adds a label, e.g. \abstract in G some classes, or in dinbrief the styles G PS Encl cc But these are real labelstrings (that appear in printout), right? JMarc
Re: Graphics path with :
Jean-Marc Lasgouttes wrote: Angus Reading http://wiki.lyx.org/LaTeX/FilesWithSpecialChars and Angus http://wiki.lyx.org/uploads/LaTeX/FilesWithSpecialChars/filenames.tex, Angus I don't see why a ':' in a file name won't work, but you're the Angus one using this stuff... I guess ':' is a problem in a windows file name if it is not the drive separator. Not from a LaTeX point of view. The OS will complain that such a file name is illegal and that the file can't exist. I don't think that we need to do anything special to handle such situations. One thing that I have noticed (not a bug, but an inconsistency) is that in the Preferences dialog, the Paths pane displays all paths in UNIX style. This looks a little odd because at the bottom of the list is the prepend_path variable which is displayed as C:\foo\bar;C:\bar\baz. Do you think that we should pass the other paths through (in,ex}ternal_path() ? -- Angus
Re: Windows installer
Angus Leeming wrote: I think I'd like to add this to development/Windows. OK? Go ahead. You can find the resulting installer itself at http://www.devel.lyx.org/~leeming/lyx_setup_136.exe. It's 5.8 MB in size. As such, I'm quite pleased with the installer. Me too. Good work! However, it is not yet complete. It should run the Resources/lyx/configure script but doing so will require it to check for/find a unix shell environment. I plan to add this support but, for now, you should run sh configure from the Resources/lyx directory before launching lyx. Once again, I'll say that rewriting configure in some other programming language would be a scoop. I've seen a few projects use JavaScript: libxml, libxslt, but you almost had a shell in c++, which I believe would be the best, since then configure could be live inside LyX: It could automatically check dependencies just-in-time. As a second best option, you could extend the installer with downloads and installs of the necessary components. Anyway, as a minimum, you should present a web-page at the end with a bunch of download links for all the prerequisites and optional extension packages required to get the full benefit of LyX. A few other comments: A nice installer will offer to start the application after the installation, to relieve the poor user from having to find the icon himself. Normally, it is good manners to ask whether to register the application with the .lyx suffix or not. In theory, the user might have another application that uses the same suffix, and would prefer to keep it that way. Of course, a port to 1.4.x would be great. Finally a question: did you use the most aggressive 7-zip compression? 5.8 Mb is a bit steep, Regards, Asger
Re: Graphics path with :
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus One thing that I have noticed (not a bug, but an inconsistency) Angus is that in the Preferences dialog, the Paths pane displays all Angus paths in UNIX style. This looks a little odd because at the Angus bottom of the list is the prepend_path variable which is Angus displayed as C:\foo\bar;C:\bar\baz. Angus Do you think that we should pass the other paths through Angus (in,ex}ternal_path() ? We should probably. But in which form should we store them? JMarc
Re: [PATCH] Bug 1892: inserting an index or a tabular can move the cursor.
Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Jean-Marc Here is a patch for this bug, which boils down to: Jean-Marc createInset should create insets, and dispatch is Jean-Marc responsible for spawning dialogs if needed. The Jean-Marc constification of getStringToIndex is not needed, but I Jean-Marc think it is better. Jean-Marc I will commit on monday if nobody objects. I did it. JMarc
[PATCH] bug 1891: note-next triggers assertion
The following patch repairs gotoInset so that it does not crash when
the document is empty.
OK?
JMarc
Index: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.2189
diff -u -p -r1.2189 ChangeLog
--- src/ChangeLog 30 May 2005 15:35:09 - 1.2189
+++ src/ChangeLog 31 May 2005 09:21:13 -
@@ -1,3 +1,8 @@
+2005-05-31 Jean-Marc Lasgouttes [EMAIL PROTECTED]
+
+ * bufferview_funcs.C (gotoInset): fix the wrap-around code to
+ avoid a crash (bug 1891)
+
2005-05-27 Jean-Marc Lasgouttes [EMAIL PROTECTED]
Fix bug 1892:
Index: src/bufferview_funcs.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/bufferview_funcs.C,v
retrieving revision 1.151
diff -u -p -r1.151 bufferview_funcs.C
--- src/bufferview_funcs.C 26 Apr 2005 11:12:09 - 1.151
+++ src/bufferview_funcs.C 31 May 2005 09:21:13 -
@@ -253,12 +253,15 @@ void gotoInset(BufferView * bv, vectorI
}
if (!gotoNextInset(tmpcur, codes, contents)) {
- if (tmpcur != doc_iterator_begin(tmpcur.inset())) {
+ if (bv-cursor() != doc_iterator_begin(bv-buffer()-inset())) {
tmpcur.reset(tmpcur.bottom().inset());
- if (!gotoNextInset(tmpcur, codes, contents))
+ if (!gotoNextInset(tmpcur, codes, contents)) {
bv-cursor().message(_(No more insets));
+return;
+ }
} else {
bv-cursor().message(_(No more insets));
+ return;
}
}
Re: Windows installer
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus As such, I'm quite pleased with the installer. However, it is Angus not yet complete. It should run the Resources/lyx/configure Angus script but doing so will require it to check for/find a unix Angus shell environment. I plan to add this support but, for now, you Angus should run sh configure from the Resources/lyx directory Angus before launching lyx. Are you sure this is needed? lib/configure should be run automatically in the user directory when starting. If it does not we should investigate why. JMarc
Re: [PATCH] bug 1891: note-next triggers assertion
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| The following patch repairs gotoInset so that it does not crash when
| the document is empty.
| OK?
sure.
| if (!gotoNextInset(tmpcur, codes, contents)) {
| - if (tmpcur != doc_iterator_begin(tmpcur.inset())) {
h| +if (bv-cursor() != doc_iterator_begin(bv-buffer()-inset())) {
tmpcur invalidated by gotoNextInset?
--
Lgb
Re: Windows installer
Jean-Marc Lasgouttes wrote: Angus As such, I'm quite pleased with the installer. However, it is Angus not yet complete. It should run the Resources/lyx/configure Angus script but doing so will require it to check for/find a unix Angus shell environment. I plan to add this support but, for now, you Angus should run sh configure from the Resources/lyx directory Angus before launching lyx. Are you sure this is needed? lib/configure should be run automatically in the user directory when starting. If it does not we should investigate why. Yes, but really the installer should generate Resources/lyx/lyxrc.defaults for system-wide stuff, no? -- Angus
Re: Windows installer
Asger == Asger Alstrup [EMAIL PROTECTED] writes: Asger Once again, I'll say that rewriting configure in some other Asger programming language would be a scoop. I've seen a few projects Asger use JavaScript: libxml, libxslt, but you almost had a shell in Asger c++, which I believe would be the best, since then configure Asger could be live inside LyX: It could automatically check Asger dependencies just-in-time. I see two possibilities: - rewrite in python - rewrite in C++ inside LyX. I am not sure how maintainable it would be. Asger As a second best option, you could extend the installer with Asger downloads and installs of the necessary components. Anyway, as Asger a minimum, you should present a web-page at the end with a Asger bunch of download links for all the prerequisites and optional Asger extension packages required to get the full benefit of LyX. Yes, being able to check whether msys, python, etc. are installed would be great. JMarc
Re: Windows installer
Jean-Marc Lasgouttes wrote: I see two possibilities: - rewrite in python - rewrite in C++ inside LyX. I am not sure how maintainable it would be. As I said, other projects have decided to use JavaScript. That is better than Python, since it does not require Python. JavaScript is part of the OS. Regards, Asger
Re: Windows installer
Asger Alstrup wrote: Angus Leeming wrote: I think I'd like to add this to development/Windows. OK? Go ahead. You can find the resulting installer itself at http://www.devel.lyx.org/~leeming/lyx_setup_136.exe. It's 5.8 MB in size. As such, I'm quite pleased with the installer. Me too. Good work! However, it is not yet complete. It should run the Resources/lyx/configure script but doing so will require it to check for/find a unix shell environment. I plan to add this support but, for now, you should run sh configure from the Resources/lyx directory before launching lyx. Once again, I'll say that rewriting configure in some other programming language would be a scoop. I've seen a few projects use JavaScript: libxml, libxslt, but you almost had a shell in c++, which I believe would be the best, since then configure could be live inside LyX: It could automatically check dependencies just-in-time. I can do only so much, Asger :) As a second best option, you could extend the installer with downloads and installs of the necessary components. Anyway, as a minimum, you should present a web-page at the end with a bunch of download links for all the prerequisites and optional extension packages required to get the full benefit of LyX. That's the plan. I've got code to check the registry for python, perl and imagemagick and to open up the relevant download page in your web browser. Looking for minSYS is a bit more complicated because it doesn't write to the registry at all. The trick, apparently is to look for the uninstaller .ini script. What else? MikTeX I guess... I imagine adding a page to the installer: Perl[ C:\foo\bar\perl.exe ] [ Browse ] [ Download ] Python [_] [ Browse ] [ Download ] MinSYS [_] [ Browse ] [ Download ] MikTeX [_] [ Browse ] [ Download ] ImageMagick [_] [ Browse ] [ Download ] [ OK ] where the input widgets are populated with entries from the Registry, but I have no idea if such a page is possible with NSIS. Do you? If so, could you cobble something hackish together to give me a bit of a start? A few other comments: A nice installer will offer to start the application after the installation, to relieve the poor user from having to find the icon himself. Trivially easy but pointless if I can't get Resources/lyx/configure to run. (Pointless because LyX will refuse to start if it can't find the generated lyxrc.defaults file.) What I'd like to do is to set the PATH to include at least the MinSYS directory, run configure, getting it to write the path_prefix variable to lyxrc.defaults containing all of these extras and then show the final page with a checkbox specifying whether lyx.exe should be launched at the end of installation. Normally, it is good manners to ask whether to register the application with the .lyx suffix or not. In theory, the user might have another application that uses the same suffix, and would prefer to keep it that way. OK. That's easy to do. Of course, a port to 1.4.x would be great. If you look at the script itself you'll see a bunch of PRODUCT_XYZ macros at the top of the file. That should be all you need to change. Finally a question: did you use the most aggressive 7-zip compression? 5.8 Mb is a bit steep, Crappy old zip compression: 8MB. bzip2 compression: 6.7MB Brand new lmza compression: 5.8MB. I compiled with g++ 3.4. Ruurd was compiling his original port with the free msvc compiler, using a wrapper to convert g++ command line args to something comprehensible to msvc. I guess that this would produce a leaner executable but, again, I've only got so much time and energy. Regards, Asger -- Angus
Re: Windows installer
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Jean-Marc Lasgouttes wrote: As such, I'm quite pleased with the Angus installer. However, it is not yet complete. It should run the Angus Resources/lyx/configure script but doing so will require it to Angus check for/find a unix shell environment. I plan to add this Angus support but, for now, you should run sh configure from the Angus Resources/lyx directory before launching lyx. Are you sure this is needed? lib/configure should be run automatically in the user directory when starting. If it does not we should investigate why. Angus Yes, but really the installer should generate Angus Resources/lyx/lyxrc.defaults for system-wide stuff, no? I am not sure this system-wide lyxrc.defaults is really needed. IMO it should not. JMarc
Re: Windows installer
Asger == Asger Alstrup [EMAIL PROTECTED] writes: Asger Jean-Marc Lasgouttes wrote: I see two possibilities: - rewrite in python - rewrite in C++ inside LyX. I am not sure how maintainable it would be. Asger As I said, other projects have decided to use JavaScript. That Asger is better than Python, since it does not require Python. Asger JavaScript is part of the OS. But we already require python. And what do you mean by 'part of the OS'? JMarc
Re: Graphics path with :
Jean-Marc Lasgouttes wrote: Angus One thing that I have noticed (not a bug, but an inconsistency) Angus is that in the Preferences dialog, the Paths pane displays all Angus paths in UNIX style. This looks a little odd because at the Angus bottom of the list is the prepend_path variable which is Angus displayed as C:\foo\bar;C:\bar\baz. Angus Do you think that we should pass the other paths through Angus (in,ex}ternal_path() ? We should probably. But in which form should we store them? lyxrc.defaults/preferences: external_path. Convert to internal_path in lyxrc::read() and to external_path in lyxrc::write(). -- Angus
Re: Windows installer
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Trivially easy but pointless if I can't get Angus Resources/lyx/configure to run. (Pointless because LyX will Angus refuse to start if it can't find the generated lyxrc.defaults Angus file.) I think we should change that and have LyX look for another file. Finally a question: did you use the most aggressive 7-zip compression? 5.8 Mb is a bit steep, Angus Crappy old zip compression: 8MB. bzip2 compression: 6.7MB Brand Angus new lmza compression: 5.8MB. And this does not include the docs, it seems. Angus I compiled with g++ 3.4. Ruurd was compiling his original port Angus with the free msvc compiler, using a wrapper to convert g++ Angus command line args to something comprehensible to msvc. I guess Angus that this would produce a leaner executable but, again, I've Angus only got so much time and energy. The executable is 11Mb. Are you sure it is correctly stripped? I see the console window flashes shortly on startup. Is there a reason why you do not use -mwindows as link option instead of trying to close the console by hand? JMarc
Re: [PATCH] bug 1891: note-next triggers assertion
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars tmpcur invalidated by gotoNextInset? Yes, when getoNextInset fails, it means that tmpcur is empty. Thefore there is no tmpcur.inset() to test against. I am not sure ho I managed to miss that. The second part of the fix is to avoid setting the cursor when the search failed. I committed it. JMarc
Re: Windows installer
Jean-Marc Lasgouttes wrote: Angus Jean-Marc Lasgouttes wrote: As such, I'm quite pleased with the Angus installer. However, it is not yet complete. It should run the Angus Resources/lyx/configure script but doing so will require it to Angus check for/find a unix shell environment. I plan to add this Angus support but, for now, you should run sh configure from the Angus Resources/lyx directory before launching lyx. Are you sure this is needed? lib/configure should be run automatically in the user directory when starting. If it does not we should investigate why. Angus Yes, but really the installer should generate Angus Resources/lyx/lyxrc.defaults for system-wide stuff, no? I am not sure this system-wide lyxrc.defaults is really needed. IMO it should not. Anyway, let's not get too worried about this bit. First, we should get the installer to check for the presence of python, perl, minsys, miktex, imagemagick... -- Angus
Re: Windows installer
Jean-Marc Lasgouttes wrote: Angus Trivially easy but pointless if I can't get Angus Resources/lyx/configure to run. (Pointless because LyX will Angus refuse to start if it can't find the generated lyxrc.defaults Angus file.) I think we should change that and have LyX look for another file. I'm not even sure that my statement is true... I do know that I explcitly remove lyxrc.defaults et al. before trying to package lyx. I'll investigate further. Finally a question: did you use the most aggressive 7-zip compression? 5.8 Mb is a bit steep, Angus Crappy old zip compression: 8MB. bzip2 compression: 6.7MB Brand Angus new lmza compression: 5.8MB. And this does not include the docs, it seems. Angus I compiled with g++ 3.4. Ruurd was compiling his original port Angus with the free msvc compiler, using a wrapper to convert g++ Angus command line args to something comprehensible to msvc. I guess Angus that this would produce a leaner executable but, again, I've Angus only got so much time and energy. The executable is 11Mb. Are you sure it is correctly stripped? shrugWhat does correctly mean? It works, doesn't it?/shrug The executable was built with --disable-debug --enable-optimization. Thereafter I ran strip over it. What more can I do? The debug build has a 120MB executable... I see the console window flashes shortly on startup. Is there a reason why you do not use -mwindows as link option instead of trying to close the console by hand? I followed Ruurd's advice on this one. See the commentary in support/os_win.C. -- Angus
RE: Re: Windows installer
Angus Leeming wrote: You can find the resulting installer itself at http://www.devel.lyx.org/~leeming/lyx_setup_136.exe. It's 5.8 MB in size. just wondering: a colleague wants to install lyx under windows. should he use this installer or is it better to use ruurd's files...? thanks regards, ed.
Re: Translation of layout files
On 31.05.05, Jean-Marc Lasgouttes wrote: G == G Milde [EMAIL PROTECTED] writes: G On 27.05.05, Jean-Marc Lasgouttes wrote: G == G Milde [EMAIL PROTECTED] writes: I understand what the problem is. I just say that Labelstring is not supposed to be used for that. But for now, it will be OK. G Also, a number of LaTeX commands adds a label, e.g. \abstract in G some classes, or in dinbrief the styles G PS Encl cc But these are real labelstrings (that appear in printout), right? Yes, this is what I mean with LaTeX commands adds a label. Did I get you right in supposing this is the right use of LabelStrings? So, the next problem arises: translating of this label strings is handeled by babel in LaTeX on a per-document basis, while the translation in LyX is governed by the LANG environment variable. Maybe not translating label strings at all is better? Günter -- G.Milde web.de
RE: Re: Windows installer
Leuven, E. wrote: Angus Leeming wrote: You can find the resulting installer itself at http://www.devel.lyx.org/~leeming/lyx_setup_136.exe. It's 5.8 MB in size. just wondering: a colleague wants to install lyx under windows. should he use this installer or is it better to use ruurd's files...? thanks regards, ed. I'd say that this 1.3.6pre1 (:-)) was uniformly better than Ruurd's 1.3.5 port. Your colleague should install python, perl, minsys, miktex (or similar), imagemagic and should add these paths to the path_prefix variable in lyxrc.defaults/preferences. Known bugs: only that it is currently impossible to load graphics files containing ':' (C:\foo\bar) using the file browser. -- Angus
Re: Windows installer
Angus Leeming wrote: Finally a question: did you use the most aggressive 7-zip compression? 5.8 Mb is a bit steep, Angus Crappy old zip compression: 8MB. bzip2 compression: 6.7MB Brand Angus new lmza compression: 5.8MB. And this does not include the docs, it seems. Angus I compiled with g++ 3.4. Ruurd was compiling his original port Angus with the free msvc compiler, using a wrapper to convert g++ Angus command line args to something comprehensible to msvc. I guess Angus that this would produce a leaner executable but, again, I've Angus only got so much time and energy. The executable is 11Mb. Are you sure it is correctly stripped? shrugWhat does correctly mean? It works, doesn't it?/shrug Note also that Ruurd's 1.3.5 port http://prdownloads.sourceforge.net/lyx-win32/lyx-1.3.5-win32.exe?download comes in at 5.5MB when using the Qt/WinFree port and at 6.5MB when using Qt Non-Commercial 3.2.1. From Ruurd's web pages: The latest binary you will find here is compiled using MSVC 8 beta, Qt Non-commercial 3.2.1 and Cygwin. With the new free Qt port from the kde-cygwin project, it's possible to compile the whole thing with mingw (and msys), or MSVC 7.1 (aka 2003) and up. The free Qt port still has a few bugs though. I take that as saying that compiling with MSVC doesn NOT produce a much leaner executable than g++. -- Angus
Re: Windows installer
Jean-Marc Lasgouttes wrote: But we already require python. And what do you mean by 'part of the OS'? We only require Python for lyx2lyx, and some of the converters. Besides that, LyX is fully usable without Python: You can author a document from scratch, and produce a working PDF without Python. JavaScript comes with Windows (or more correctly Internet Explorer). You do not have to install anything to get that. Regards, Asger
Re: Windows installer
Another bug: When you uninstall, it does not unregister the .lyx file association. Regards, Asger
Re: Windows installer
Angus Leeming wrote:
Asger Alstrup wrote:
[Rewrite configure]
I can do only so much, Asger :)
Yes, and somehow you manage to do it all anyway! It's fantastic ;-)
Looking for minSYS is a bit more complicated because it doesn't write to
the registry at all. The trick, apparently is to look for the uninstaller
.ini script.
I see. Can't you try to run a command from minSYS? It that fails, it is not
installed or configured correctly. If it runs, you can find it through the
PATH.
I imagine adding a page to the installer:
Perl[ C:\foo\bar\perl.exe ] [ Browse ] [ Download ]
Python [_] [ Browse ] [ Download ]
MinSYS [_] [ Browse ] [ Download ]
MikTeX [_] [ Browse ] [ Download ]
ImageMagick [_] [ Browse ] [ Download ]
[ OK ]
where the input widgets are populated with entries from the Registry,
but I have no idea if such a page is possible with NSIS. Do you? If so,
could you cobble something hackish together to give me a bit of a start?
It should be possible. I attach some parts of some internal NSIS code
(don't tell anybody), which does something similar. Look at the JDK stuff,
and the ioWhereToGetConfig for some pieces that might help: The JDK stuff
presents a radio choice: Use the JDK installed, or install a new one. The
where to get config stuff allows the user to browse for a file.
Regarding size: I guess the size is fine for now. Regarding size: You could
try to optimise the executable for space, rather than speed. It might even
turn out to be faster. Later, we could try to split out the translations,
and provide those as a separate installer.
Regards,
Asger
[Settings]
NumFields=4
[Field 1]
Type=Label
Left=0
Right=-1
Top=0
Bottom=40
Text=To configure the CMS, the installer now needs to access the CMS
configurator. You must have a connection to the Internet to install the
CMS.\nPlease choose where you are going to get CMS configurator from. Do not
change the default settings if you are not sure:
[Field 2]
Type=RadioButton
Left=0
Right=-1
Top=43
Bottom=54
Text=from the Internet (default)
State=1
Flags=NOTIFY
[Field 3]
Type=RadioButton
Left=0
Right=-1
Top=59
Bottom=70
Text=use local file cms_configure_eng.exe or cms_configure_int.exe (for
advanced users):
State=0
Flags=NOTIFY
[Field 4]
Type=FileRequest
Left=15
Right=-1
Top=75
Bottom=86
Filter=Executable files|*.exe
Flags=FILE_MUST_EXIST|DISABLED
Text=Browse; ***
; CMS configurator install script
; Author: Yuri Gubanov
;
; The main purpose of CMS configurator is to
; actually establish all settings and copy CMS
; latest binaries
;
; ***
!include MUI.nsh
!include LogicLib.nsh
!include Sections.nsh
!include Useful\StrStr.nsh
!include Useful\SetFocus.nsh
!include CMS_Constants.nsh
!include CMS_Messages.nsh
!include SaveUserData.nsh
!include Useful\IO.nsh
ShowInstDetails show
;
;Variables
Var JBOSS_PORT_NUMBER
Var LDAP_PORT_NUMBER
Var ADMIN_PASSWORD
Var ADMIN_PASSWORD2
Var REGISTER_OPENLDAP
Var REGISTER_JBOSS
Var WHOLE_TEXT
Var SMTP_SERVER
Var ADMIN_EMAIL
Var OldBootstrapperRun
Var OldInstallationPath
Var JDK_Installed
Var LdapContext
Var HWND ; Used for storing HWND of installer pages, e.g. for setting focus
; on page controls
;
;General
;Name and file
Name${ProductName}
Caption ${ProductName} installer
OutFile ${ConfiguratorSetupFileName}
BrandingText ${ProductFullName}
!insertmacro MUI_DEFAULT MUI_ICON ..\cms_files\cms.ico
!insertmacro MUI_DEFAULT MUI_UNICON ..\cms_files\cms.ico
;Get installation folder from registry if available
InstallDirRegKey HKLM ${RegistryCMSSubkey} ${InstallDirKeyName}
;
;Interface Settings
!define MUI_ABORTWARNING
!define MUI_CUSTOMFUNCTION_ABORT AbortFunction
;
;Pages
Page custom InstallJDK InstallJDK_LeaveFunction
!define MUI_PAGE_HEADER_TEXT CMS installer
Page custom CustomPageCreateAdmin CustomPageCreateAdmin_LeaveFunction
Page custom CustomPageEmail Email_LeaveFunction
Page custom CustomPageAdvanced CustomPageAdvanced_LeaveFunction
!insertmacro MUI_PAGE_INSTFILES
Page custom CustomPageJBoss
!define MUI_FINISHPAGE_TEXT ${FinishPageMessage}
!define MUI_FINISHPAGE_RUN_TEXT Start CMS Server
!define MUI_FINISHPAGE_RUN ${CMSRunFile}
!insertmacro MUI_PAGE_FINISH
!insertmacro MUI_UNPAGE_WELCOME
!insertmacro MUI_UNPAGE_CONFIRM
UninstPage custom un.AskSaveUserData
!insertmacro MUI_UNPAGE_INSTFILES
;
;Languages
!insertmacro MUI_LANGUAGE English
;
;Reserve Files
;These files should be inserted before other files in the data block
;Keep these lines before
Re: Windows installer
Asger Alstrup wrote:
Another bug: When you uninstall, it does not unregister the .lyx file
association.
Well, it is meant to. I used the abiword functions that you posted the
link to...
Section Uninstall
RMDir /r $INSTDIR
ReadRegStr $0 ${PRODUCT_ROOT_KEY} ${PRODUCT_UNINST_KEY} StartMenu
RMDir /r $0
Delete $DESKTOP\${PRODUCT_NAME}.lnk
DeleteRegKey ${PRODUCT_ROOT_KEY} ${PRODUCT_UNINST_KEY}
DeleteRegKey HKLM ${PRODUCT_DIR_REGKEY}
${RemoveFileAssociation} ${PRODUCT_EXT} ${appType}
SetAutoClose true
SectionEnd
--
Angus
Re: Windows installer
Asger Alstrup wrote: I attach some parts of some internal NSIS code which does something similar. Thanks Asger. I'll look through this later. -- Angus
Re: Windows installer
Angus == Angus Leeming [EMAIL PROTECTED] writes: The executable is 11Mb. Are you sure it is correctly stripped? Angus shrugWhat does correctly mean? It works, doesn't Angus it?/shrug I take it you are getting annoyed by my questions :) Angus The executable was built with --disable-debug Angus --enable-optimization. Thereafter I ran strip over it. What Angus more can I do? Nothing. I am happy with the answer. I see the console window flashes shortly on startup. Is there a reason why you do not use -mwindows as link option instead of trying to close the console by hand? Angus I followed Ruurd's advice on this one. See the commentary in Angus support/os_win.C. OK, I should have read that, I guess. A solution would be to redirect the standard output to some log file in user_dir (provided you know where this is, of course). This is not needed right now, anyway. JMarc
Re: Windows installer
Asger == Asger Alstrup [EMAIL PROTECTED] writes: Asger JavaScript comes with Windows (or more correctly Internet Asger Explorer). You do not have to install anything to get that. You remember we support other OSes, do you? I am not against using javascript, but this is yet another scripting language, not some magic bullet. JMarc
Re: Translation of layout files
G == G Milde [EMAIL PROTECTED] writes: G Yes, this is what I mean with LaTeX commands adds a label. G Did I get you right in supposing this is the right use of G LabelStrings? Yes. G So, the next problem arises: translating of this label strings is G handeled by babel in LaTeX on a per-document basis, while the G translation in LyX is governed by the LANG environment variable. Not for labelstrings. These are now translated according to the document language in 1.4 (and this is why I added Labelstring to translatable strings). JMarc
Re: Windows installer
Jean-Marc Lasgouttes wrote: Asger == Asger Alstrup [EMAIL PROTECTED] writes: Asger JavaScript comes with Windows (or more correctly Internet Asger Explorer). You do not have to install anything to get that. You remember we support other OSes, do you? We do? Why didn't anybody tell me? I am not against using javascript, but this is yet another scripting language, not some magic bullet. I was not arguing to kick out the shell configure. Just to add a JavaScript one to fix Windows. That's what libxml and libxslt do. Regards, Asger
Re: Windows installer
Jean-Marc Lasgouttes wrote: The executable is 11Mb. Are you sure it is correctly stripped? Angus shrugWhat does correctly mean? It works, doesn't Angus it?/shrug I take it you are getting annoyed by my questions :) Nope, I was being genuine. What else could I do? Angus The executable was built with --disable-debug Angus --enable-optimization. Thereafter I ran strip over it. What Angus more can I do? Nothing. I am happy with the answer. So it seems that 5.8MB is as good as we can get. -- Angus
Re: Windows installer
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus So it seems that 5.8MB is as good as we can get. But you have to add the docs to that, right? JMarc
Re: Windows installer
Asger == Asger Alstrup [EMAIL PROTECTED] writes: Asger I was not arguing to kick out the shell configure. Just to add Asger a JavaScript one to fix Windows. That's what libxml and libxslt Asger do. I see. I think it would be better to have only one configure for everything. I for one would be happy to see the current m4/sh code die. JMarc
Re: Windows installer
Asger Alstrup wrote: Asger JavaScript comes with Windows (or more correctly Internet Asger Explorer). You do not have to install anything to get that. You remember we support other OSes, do you? We do? Why didn't anybody tell me? I am not against using javascript, but this is yet another scripting language, not some magic bullet. I was not arguing to kick out the shell configure. Just to add a JavaScript one to fix Windows. That's what libxml and libxslt do. We've had this discussion before (maybe Asger was offline at the time.) I believe that the conclusion was that we should recognize our aspirations that LyX become a genuinely multi-platform app and end up using a genuinely multi-platform scripting language. So that means we should work to remove the requirement to have a UNIX shell at run time. That leaves the question of what to replace it with. I understand that we came to the concensus that it would be nice to use one scripting language only. Python, perl, javascript, ruby, lisp, etc, etc. They are all perfectly reasonable choices, but... * none of us like perl. * we have no code written in javascript, lisp, ruby, etc, etc. * we have a considerable body of code written in python, at least one python expert and several python hackers. The conclusion seems obvious to me... -- Angus
Re: Windows installer
Jean-Marc Lasgouttes wrote: Angus So it seems that 5.8MB is as good as we can get. But you have to add the docs to that, right? JMarc Presumably, when LyX 1.3.6 is released, you'll provide a lyx_1_3_6.tar.gz source distribution, no? I'll (configure, make, make install) that and build the Windows installer from the contents of the installed directory. -- Angus
Re: Windows installer
Angus Leeming wrote: Asger Alstrup wrote: I was not arguing to kick out the shell configure. Just to add a JavaScript one to fix Windows. That's what libxml and libxslt do. We can't afford double maintenance. * none of us like perl. * we have no code written in javascript, lisp, ruby, etc, etc. * we have a considerable body of code written in python, at least one python expert and several python hackers. The conclusion seems obvious to me... I even remember that the conclusion was spelled out: Use python and nothing else. And it is IMHO the only reasonable choice with regard to the lacking manpower. Georg
Re: Windows installer
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Jean-Marc Lasgouttes wrote: So it seems that 5.8MB is as good Angus as we can get. But you have to add the docs to that, right? JMarc Angus Presumably, when LyX 1.3.6 is released, you'll provide a Angus lyx_1_3_6.tar.gz source distribution, no? I'll (configure, Angus make, make install) that and build the Windows installer from Angus the contents of the installed directory. That's fine. JMarc
Re: Windows installer
Georg Baum wrote: The conclusion seems obvious to me... I even remember that the conclusion was spelled out: Use python and nothing else. And it is IMHO the only reasonable choice with regard to the lacking manpower. Well, well, well. I disagree. I think C++ would be better than Python: - We have more C++ resources than Python - C++ opens the door for live configuration at runtime - C++ does not require Python on Windows, which I think is a problem. So, to me, the ranking is: 1) C++ 2) JavaScript + shell 3) Python 4) Shell only This also reflects the priorities a typical user would have. Regards, Asger
[PATCH] bug 1890: insetoptarg triggers assertion
The following (trivial) patch fixes bug 1890. Although it is a
satisfactory fix (insert the optarg inset as open instead of
collapsed, like for all other collapsable insets), it hides a more
annoying bug: when the collapsable inset is inserted as collapsed, the
xo() and yo() values are not set correctly by the metrics (?) phase
and trigger an assertion. The backtrace (here through valgrind) looks
like the following:
[snip]
==4488==by 0x80F366C: lyxbreaker(void const*, char const*, int)
(coordcache.C:30)
==4488==by 0x81CEFA3: CoordCacheBaseInsetBase::check(InsetBase const*,
char const*) const (coordcache.h:92)
==4488==by 0x81F8F16: CoordCacheBaseInsetBase::x(InsetBase const*) const
(coordcache.h:59)
==4488==by 0x81F8A78: InsetBase::xo() const (insetbase.C:324)
==4488==by 0x8207CBF: InsetCollapsable::getCursorPos(CursorSlice const,
int, int) const (insetcollapsable.C:199)
==4488==by 0x80E2F16: bv_funcs::coordOffset(DocIterator const)
(bufferview_funcs.C:165)
==4488==by 0x80E316B: bv_funcs::getPos(DocIterator const)
(bufferview_funcs.C:195)
==4488==by 0x8069F4B: BufferView::Pimpl::fitCursor()
(BufferView_pimpl.C:600)
==4488==by 0x806A0DF: BufferView::Pimpl::update(bool, bool)
(BufferView_pimpl.C:636)
==4488==by 0x80659BA: BufferView::update(bool, bool) (BufferView.C:147)
==4488==by 0x8133D1B: LyXFunc::dispatch(FuncRequest const) (lyxfunc.C:1525)
[snip]
I'd appreciate if somebody who knows about this stuff could take a
quick look. I will wait a bit before committing my patch so that
people have the opportunity to investigate.
JMarc
Index: src/insets/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/ChangeLog,v
retrieving revision 1.1150
diff -u -p -r1.1150 ChangeLog
--- src/insets/ChangeLog 24 May 2005 10:23:30 - 1.1150
+++ src/insets/ChangeLog 31 May 2005 14:13:02 -
@@ -1,3 +1,8 @@
+2005-05-31 Jean-Marc Lasgouttes [EMAIL PROTECTED]
+
+ * insetoptarg.C (InsetOptArg): make the inset open by default
+ (fixes bug 1890)
+
2005-05-23 Jean-Marc Lasgouttes [EMAIL PROTECTED]
* insetvspace.C (draw): use VSpace::asGUIName.
Index: src/insets/insetoptarg.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetoptarg.C,v
retrieving revision 1.29
diff -u -p -r1.29 insetoptarg.C
--- src/insets/insetoptarg.C 11 May 2005 09:47:54 - 1.29
+++ src/insets/insetoptarg.C 31 May 2005 14:13:02 -
@@ -26,7 +26,7 @@ using std::ostringstream;
InsetOptArg::InsetOptArg(BufferParams const ins)
- : InsetCollapsable(ins, Collapsed)
+ : InsetCollapsable(ins)
{
LyXFont font(LyXFont::ALL_SANE);
font.setColor(LColor::collapsable);
Re: Windows installer
Asger Alstrup wrote: Georg Baum wrote: The conclusion seems obvious to me... I even remember that the conclusion was spelled out: Use python and nothing else. And it is IMHO the only reasonable choice with regard to the lacking manpower. Well, well, well. I disagree. I think C++ would be better than Python: - We have more C++ resources than Python Agreed. But as a group we're not unprofficient at python either. - C++ opens the door for live configuration at runtime There is a lot of work to do between now and then. Direct communication with a working python script would be a reasonable first step. - C++ does not require Python on Windows, which I think is a problem. You keep saying this but I don't get it. Why is downloading python a problem? Fact: anyone using lyx for real work *requires* python to convert his lyx document from one lyx format to the next one. Fact: anyone using lyx on Windows and referencing files with spaces will need to use the clean_dvi.py script to view a .dvi, .ps file. Sure it could be rewritten in another language, but why should we do so? Fact: we have many other python scripts that do a variety of things. Fact: none of our existing Windows users have complained that they need to use python, perl and a unix shell. Granted, they are probably just soldiering on quietly, but reducing this list gradually to just python is hardly likely to raise a storm of protest. So, to me, the ranking is: 1) C++ 2) JavaScript + shell 3) Python 4) Shell only But Georg is right. Those people who are actively developing LyX at the moment are competent users of python. I for one know no Javascript. I'm pretty expert at using the unix shell though. Maybe I should just stick to that, huh, and let our Javascript experts duplicate (and maintain) all our shell scripts? This also reflects the priorities a typical user would have. Come on, Asger! Statements like that are based on nothing but suposition and your own personal bias. -- Angus
Re: [Patch] Re: [patch] key event queue
On Tue, 2005-05-31 at 09:55, Lars Gullik Bjnnes wrote: Martin Vermeer [EMAIL PROTECTED] writes: So it seems to fix most problems we have and feels uniformly better that what we have right now? If so... | Yes, I believe so. | Therefore I will commit the attached, if no new objections come up. I | have somewhat thoroughly tested this with the User Guide. Go ahead. I will redo my test afterwards. So done. - Martin signature.asc Description: This is a digitally signed message part
Re: Windows installer
Well, I'll cave in. A python solution is better than no solution, and I will not complain about progress. To explain, I consider Python a problem, because it is a 10.7 MB download. Every extra MB reduces your market. But a nice installer, which offers to download and install Python for you if it is not present is obviously a pain killer, and many users will not be scared of that. And who am I to kid: MikTeX is the big one with a 250+ MB download, what is 11MB extra? The long term solution is either to provide an internet LyX-PDF server, and rig that up in LyX, or add Lout support. So, until we have either of those, Python configure is sweet as pie, and I would be stupid to complain when you do all the work. Thanks for that, by the way. I believe LyX has a huge potential on Windows - much bigger than the current and future user base on Unix. But for every megabyte the download increases, a whole bunch of users will not want to try it out. So, I just figured that if a rewrite is called for anywhy, why not go the extra mile for the C++ solution to save those 11 MB? (I just disagree about Python being vital, especially with a LyX - PDF server solution.) But I can't make you walk that extra mile, so I'll just shut up and be happy about what you have achieved so far, which is absolutely fantastic. Regards, Asger
Re: LyX python package
G. Milde wrote: My mail reception system changed last week and for some reason I never saw this message. :-( I am answering this using gmane. On 20.05.05, Jose' Matos wrote: On Friday 20 May 2005 10:04, G. Milde wrote: Now a serious question: is this [__init__.py] a trivial (empty) file or do you have any initialization step going inside? Currently, its just Package of scripts for the LyX Document Processor (www.lyx.org) # we might need __all__ on Windows (update and comment out in this case) # __all__ = ['bindings' #'lfuns', #'lyxclient', #'lyxserver', #'pyfuns', # ] At some stage, there might be code to add a directory with user-provided python scripts to the packages __path__, so the package becomes extensible. (Remember, my main concern is a scripting support for LyX.) I am not sure if it is worth to have a local script directory. In most of the points bellow this is my main objection. --- Clearly we are talking about two different subjects: the python library; the python scripts that use the library. I want to place the python library into the place used by python libraries. So do I. We still need some nice place (and name) for the python LyX library in the CVS, so my idea was to keep the files at this place and symlink to the python site-library (or use a pth file) at install time. I am not sure if every platforms we support have symbolic links. For cvs a python directory (called python naturally seems a good bet). :-) Why not to use distutils? This allows us to install the package in any platform, no need for this file. I do not insist on my idea, and have no objection to move the library files to the site-library with distutils at install time. Distutils comes with the more modern python versions. If we ship this for 1.5 the python requirements will guarantee us that this is not a problem. The python scripts should go in lyx. (the /usr/share/lyx above) Yes, end-user scripts (like lyx2lyx, lyx-Mx or lyx-remote) should go to /usr/share/lyx/scripts. Good. In the long run, however, I would like to merge lyx2lyx into the LyX package (as ...LyX/lyx2lyx sub-module). ... But that is already done. :-) Unfortunately, I can not see it. Clearly here the problem is that lyx2lyx means two different things again. :-) One is the directory where the code is present and the other is the script that converts the lyx files. Another problem is the different organization of the CVS tree and the final layout. lyx2lyx script: lyx2lyx is a client script with 67 lines (85 if you consider the license). All the knowledge how to deal with lyx files is inside LyX.py and the lyx_*.py files, not lyx2lyx. We cannot have both, LyX.py and a LyX package inside the python library path. Now it was my time not to be clear. ;-) If we have a LyX package we should split LyX.py content into separate files. The only import modules are: import getopt import sys import LyX As you see if we create a LyX module there is no need to change the lyx2lyx script. With a LyX *package*, at least one change to lyx2lyx is needed. With /lyx2lyx/ - site-lib/LyX/, and LyX/__init__.py the minimal change is - import LyX + from LyX import LyX (untested, I don't know whether there is a name conflict) No this remains the same. The python directory will then be: site-lib/LyX/File.Py and site-lib/LyX/NewFile.Py or + from LyX.lyx2lyx.LyX import * (and change of all LyX. to ) or (I do not like the idea of a LyX module in a LyX package, so I suggest renaming the LyX.py module to the more specific lyxfile.py) Yes, something like that. + from LyX import lyxfile (and change of all LyX. to lyxfile.) Not only that but I propose to move the lyx2lyx script from its present location to share/scripts. This is something we can agree on easily :-) lyx2lyx directory: I have been working on the lyx2lyx directory because cvs looses the history if you rename a directory. If that was not the case this directory would have been renamed LyX for more than a year ago. So at this level, at least for me lyx2lyx == LyX In the CVS, lyx2lyx (or pyLyX) is still a more transparent name than lyx-cvs/devel/lib/LyX/. Once installed, python-site-lib/LyX/ is preferable. I agree. when you say a LyX/lyx2lyx sub-module, there is no need for it, we already have a LyX.File that does all the work for you. With a LyX package this would become LyX.LyX.File As I have told you I would remove the need for the middle LyX I do not like the idea of a module LyX in package LyX. My suggestion is to rename LyX.py to lyxfile.py. Also, I would like to hide
Re: Windows installer
Asger Ottar Alstrup wrote: So, I just figured that if a rewrite is called for anywhy, why not go the extra mile for the C++ solution to save those 11 MB? (I just disagree about Python being vital, especially with a LyX - PDF server solution.) But I can't make you walk that extra mile, so I'll just shut up and be happy about what you have achieved so far, which is absolutely fantastic. You have just inherited my diplomatic crown :) Maybe something that would be fun and not too time consuming, allowing you to participate, would be to write a short paper on the wiki sketching out this configure-on-demand solution. It may be clear in your head, but it's not in mine :) It would be much easier to make some rational judgment if we could see what was involved. I'd be more than willing to participate in such a discussion. Angus
Re: tex2lyx and included files
Jean-Pierre Chrtien [EMAIL PROTECTED] writes: Here is my suggestion: - enumerate absolute path of \included ou \inputted files converted to lyx (with indication of creation or overwrite). - warn about inset of original .tex file if existing lyx file (this may be very misleading). I'd uploaded a sunos version on the wiki including these changes, without waiting for Georg to commit them if he founds appropriate, but I removed my script tes2lyx.sh as it is currently broken with all available ports but sunos. The new messages I get with my simplified dependency example read as such: - run from scratch: -tex2lyx.sh main tex2lyx.sh will clobber all depending .lyx files (called by include, input, or verbatiminput). Continue ? y/N y Converting main.tex and dependant files to lyx format 241... Ignoring options 'T1' of package fontenc. Creating file /tmp/tex2lyx_depend/chapters/intro.lyx Converting back to lyx format 221... main.lyx available. /tmp/tex2lyx_depend/chapters/intro.lyx available. Conversion completed. - rerun with clobbering of existing lyx files: -rm main.lyx ; tex2lyx.sh main rm: remove main.lyx (yes/no)? yes tex2lyx.sh will clobber all depending .lyx files (called by include, input, or verbatiminput). Continue ? y/N y Converting main.tex and dependant files to lyx format 241... Ignoring options 'T1' of package fontenc. Overwriting existing file /tmp/tex2lyx_depend/chapters/intro.lyx Converting back to lyx format 221... main.lyx available. /tmp/tex2lyx_depend/chapters/intro.lyx available. Conversion completed. - tex2lyx run alone without -f option: -rm main.lyx; /usr/local/LyX/bin/tex2lyx main.tex main.lyx rm: remove main.lyx (yes/no)? yes Ignoring options 'T1' of package fontenc. Not overwriting existing file /tmp/tex2lyx_depend/chapters/intro.lyx Existing chapters/intro.lyx, insetting chapters/intro.tex texlyx remains mute about \verbatiminput file suffix. -- Jean-Pierre
Re: Windows installer
Angus Leeming wrote:
Maybe something that would be fun and not too time consuming, allowing
you to participate, would be to write a short paper on the wiki
sketching out this configure-on-demand solution. It may be clear in
your head, but it's not in mine :)
Take a snippet like this from configure:
--
define(CHECKLATEX2E,[
## Check whether this is really LaTeX2e
rm -f chklatex.ltx
cat chklatex.ltx EOF
\\nonstopmode\\makeatletter
\\ifx\\undefined\\documentclass\\else
\\message{ThisIsLaTeX2e}
\\fi
\\@@end
EOF
if eval ${LATEX} chklatex.ltx /dev/null 2/dev/null \
| grep 'ThisIsLaTeX2e' /dev/null; then
:
else
LATEX=
ac_result=not useable
fi
rm -f chklatex.ltx chklatex.log])dnl
dnl
# Search LaTeX2e
SEARCH_PROG([for a LaTeX2e program],LATEX,pplatex latex2e
latex,CHECKLATEX2E,dnl
[lyx_check_config=no])
latex_to_dvi=$LATEX
test -z $latex_to_dvi latex_to_dvi=none
--
What it does is to check whether we have a working LaTeX by producing a
small document. This pattern is repeated a bunch of times: We try to run
a bunch of different alternative names of these programs, check the
output, and decides what name to use, or decide that program is not
available.
In addition to the snippet above in configure, there is corresponding
code that reads the configuration from a file, the code which uses the
configuration, and there is a special LyX teamplate document which
describes the results from the configuration, and presents this in the
Help menu. Add to this list the stuff you are doing now in the
installer, where you are adding OS specific installation tests and
download links for these packages. So the information about this is
scattered in a bunch of related, but different places.
Inside LyX, we use this configuration information when we are to produce
a DVI file. But in fact, we use old information: We use the information
that was recorded in a configuration file. So, let's assume that the
last time we ran this test, we failed to find a working LaTeX. Then LyX
greys out those commands in the GUI that need this command. There is no
explanation for the user. The expert users will learn to check some
fancy document in the Help menu, but the novice users are lost.
The first improvement is that LyX can rerun the check before greying out
the item. It might be that LaTeX was installed since configure. The next
step is that it could help the user resolve the situation. Instead of
greying out the option, it could open a dialog which said: LaTeX is
missing. Click here to download and install LaTeX. And after the
installation, it could rerun the test, and the command would succeed.
The first time LyX is started, it will run all the tests, and provide a
dialog where the user can check-off which missing components to download
and install. By putting this stuff in LyX itself, it is readily
available when needed.
(Writing this, it occurs to me that an alternative is to use NSIS for
some of this.)
So the point is to centralise all of this information into one place in
the form of a class that handles detection, downloading/installation,
explaning to the user, and the use of the detected information. In other
words, use C++ to implement a small domain specific language for the
full circle that revolves around run-time configuration issues.
This is basically a base interface class in C++, a bunch of toolboxes
for the different kinds of tests (running and interpreting the results
of commands), and all the configuration instances that implement
whatever they need to do.
An added benefit by having such a toolkit is that it can be made
available for other programs, such as tex2lyx and similar which also
need this kind of external package configuration support.
Does this help?
Regards,
Asger
Re: Windows installer
Angus Leeming wrote: Your colleague should install python, perl, minsys, miktex (or similar), imagemagic and should add these paths to the path_prefix variable in lyxrc.defaults/preferences. I recommend installing ghostview / ghostview as well. See http://www.cs.wisc.edu/~ghost/ Michael
tex2lyx + international characters = redundant braces in lyx (1.3)?
Hi, I just stumbled over what I think is a little quirk in tex2lyx. When
I convert a file that contains {\ss} latex codes, using the tex2lyx -
lyx2lyx - lyx 1.3.5 procedure from the wiki (on windows), the braces
appear as ERT in the final lyx file, although they are redundant.
The braces don't do any harm, they're only redundant.
Example: the latex input So{\ss}e should appear as Soße in the lyx file.
(Hope the German es-zett is preserved in the mail.) What appears is:
Soert{/ertßert}/erte.
Tried to workaround with So\ss{}e, which gives
Soßert{/ertert}/erte (still two different ert insets)
So is it possible for tex2lyx to recognize a pair of braces that simply
serves to delimit latex codes from surrounding text, and remove them in
the lyx file? That would be great.
Btw, note that all the {\ss} in the input file were caused by the WinEdt
(very popular windows latex shell) function to automatically save
non-ascii input as ascii-latex-codes. So I guess this (minor) problem
may appear more often in the future when lyx on windows is more
widespread, and many people want to import their non-English latex files
into lyx.
cheers,
sven
Re: Windows installer
Asger Ottar Alstrup [EMAIL PROTECTED] writes: | (Writing this, it occurs to me that an alternative is to use NSIS for | some of this.) Nah... we don't want to use nsis for something that has the same problem (and possibly the possibiluyty of the same solution on unix) And it could just as well be implemented in python as in C++. -- Lgb
Re: Windows installer
Lars Gullik Bjønnes wrote: Nah... we don't want to use nsis for something that has the same problem (and possibly the possibiluyty of the same solution on unix) And it could just as well be implemented in python as in C++. Yes, it could, except for the GUI stuff: Explaining to the user what a given package provides, provide a GUI for manual configuration of packages, asking whether to downloading and install a package, and so on. A C++ solution would provide all the toolbox stuff required to retire a bunch of the python converter scripts into C++. (We would need to invoke Python from C++. Therefore, the Python solution has a chicken-and-egg problem with the configuration and detection of Python itself from C++.) But as I said before: A Python solution is progress to me, so I won't say no to that. Regards, Asger
Re: LyX meeting in Paris. What about July 14-18?
Jean-Marc Lasgouttes wrote: PS: this morning, I was triaging old papers and found ``Project LyX3'', ``Strings and encodings in LyX 1.2'' and ``Design and implementation of the data structure layer in the new LyX kernel'', all of them by the very esteemed Asger Alstrup Nielsen. These even sport nice tables and figures :) Yeah, and see how much of that effort materialised. It might have influenced some things, but since then, I've learned to value the agile manifesto: Prefer working software to comprehensive documentation. Regards, Asger
Re: LyX meeting in Paris. What about July 14-18?
Asger Ottar Alstrup [EMAIL PROTECTED] writes: | Jean-Marc Lasgouttes wrote: PS: this morning, I was triaging old papers and found ``Project LyX3'', ``Strings and encodings in LyX 1.2'' and ``Design and implementation of the data structure layer in the new LyX kernel'', all of them by the very esteemed Asger Alstrup Nielsen. These even sport nice tables and figures :) | Yeah, and see how much of that effort materialised. It might have | influenced some things, but since then, I've learned to value the | agile manifesto: | Prefer working software to comprehensive documentation. I belive the manifesto is a bit larger than that :-) But sure, documentation for documentations own sake is just wasted effort. (and can lead to problems...) -- Lgb
Re: Graphics path with :
Angus Leeming wrote: In src/frontends/controllers/helper_funcs.C, try removing the ':' from Please report back if LaTeX is happy. LaTeX is happy and I am happy, too :-) What astonishes me is the fact that LyX 1.4 works without a patch. Maybe it converts paths before the character check... Regards, Michael
Script alternative - Ch (Was: Windows installer)
On Tue, 31 May 2005, Angus Leeming wrote: That leaves the question of what to replace it with. I understand that we came to the concensus that it would be nice to use one scripting language only. Python, perl, javascript, ruby, lisp, etc, etc. They are all perfectly reasonable choices, but... * none of us like perl. * we have no code written in javascript, lisp, ruby, etc, etc. * we have a considerable body of code written in python, at least one python expert and several python hackers. The language called Ch might be an alternative, I guess it's advantage is that it's a superset of normal C, which everybody here already knows. Having said that, I've never actually done more with it than checked that I could actually write C statements on its shell prompt. Here's a link: http://www.softintegration.com/ /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Graphics path with :
Michael Schmitt wrote: Angus Leeming wrote: In src/frontends/controllers/helper_funcs.C, try removing the ':' from Please report back if LaTeX is happy. LaTeX is happy and I am happy, too :-) Then I'll commit the patch... Done. What astonishes me is the fact that LyX 1.4 works without a patch. Maybe it converts paths before the character check... Perhaps you aren't looking hard enough. The check is in the input widget in 1.4.x. The first time you input an invalid file name you'll get a dialog popping up to tell you so, but thereafter it won't. Instead, the input widget's label should go red and the dialog OK,Apply buttons will be disabled. Angus
The agile manifesto
Lars Gullik Bjønnes wrote: Asger Ottar Alstrup [EMAIL PROTECTED] writes: | Prefer working software to comprehensive documentation. I belive the manifesto is a bit larger than that :-) Not much. From memory: Individuals and interactions over processes and tools Working software over comprehensive documentation Responding to change over following a plan Customer collaboration over contract negotiation Check www.agilemanifesto.org if you want to check me. At our software company, we have been practicing this for many years. It was a revelation when the agile manifesto was published: we were not alone. Regards, Asger
Re: The agile manifesto
Asger Ottar Alstrup [EMAIL PROTECTED] writes: | Individuals and interactions over processes and tools | Working software over comprehensive documentation | Responding to change over following a plan | Customer collaboration over contract negotiation | Check www.agilemanifesto.org if you want to check me. | At our software company, we have been practicing this for many years. | It was a revelation when the agile manifesto was published: we were | not alone. Yeah. I kindo feel at home in that mindset as well. -- Lgb
Mac build problem
Does anyone else see this? Fresh CVS check out/build. OS X 10.4. I've built successfully on Tiger before. g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -I../../../src -I../../../src/frontends -I../../../images -I/Users/robbear/dev/qt-mac-free-3.3.4/include -I../../../boost -I../../../src/frontends/controllers -W -Wall -fno-exceptions -g -Os -c QBibtexDialog.C -MT QBibtexDialog.lo -MD -MP -MF .deps/QBibtexDialog.TPlo -o QBibtexDialog.o QBibtexDialog.C: In member function `virtual void lyx::frontend::QBibtexDialog::addDatabase()': QBibtexDialog.C:153: error: could not convert `QLineEdit::text() const()' to ` const std::string' ../../../src/support/lstrings.h:135: error: in passing argument 1 of `const std::string lyx::support::trim(const std::string, const char*)' make[5]: *** [QBibtexDialog.lo] Error 1 make[4]: *** [all-recursive] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all] Error 2 make: *** [all-recursive] Error 1
Re: [Patch] Re: [patch] key event queue
Martin Vermeer [EMAIL PROTECTED] writes: | On Tue, 2005-05-31 at 09:55, Lars Gullik Bjønnes wrote: Martin Vermeer [EMAIL PROTECTED] writes: So it seems to fix most problems we have and feels uniformly better that what we have right now? If so... | Yes, I believe so. | Therefore I will commit the attached, if no new objections come up. I | have somewhat thoroughly tested this with the User Guide. Go ahead. I will redo my test afterwards. | So done. Ok. I did my tests. I must admit that I now find it unusable. No feedback on screen when using cursor keys for movement (on auto-repeat) Same with PageDown/PageUp. (except from the scrollbar) The scrolling problem is fixed by adding in the event queue, but the cursor on auto-repeat is not fixed by that. We absolutely want the cursor on-screen when moving around. Ideas on how to fix this? -- Lgb
Re: Mac build problem
Rob Bearman wrote:
Does anyone else see this? Fresh CVS check out/build. OS X 10.4. I've built
successfully on Tiger before.
Nope. But different Qt versions may behave differently.
QBibtexDialog.C:153: error: could not convert `QLineEdit::text() const()' to
Does the attached patch cure the problem?
Angus
Index: src/frontends/qt2/QBibtexDialog.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QBibtexDialog.C,v
retrieving revision 1.32
diff -u -a -u -r1.32 QBibtexDialog.C
--- src/frontends/qt2/QBibtexDialog.C 16 May 2005 09:14:17 - 1.32
+++ src/frontends/qt2/QBibtexDialog.C 31 May 2005 19:40:44 -
@@ -150,9 +150,9 @@
void QBibtexDialog::addDatabase()
{
int const sel = add_-bibLB-currentItem();
- QString const file = trim(add_-bibED-text());
+ string const file = trim(fromqstr(add_-bibED-text()));
- if (sel 0 file.isNull())
+ if (sel 0 file.empty())
return;
// Add the selected browser_bib keys to browser_database
@@ -165,8 +165,8 @@
}
}
- if (!file.isEmpty()) {
- QString const f = toqstr(ChangeExtension(fromqstr(file), ));
+ if (!file.empty()) {
+ QString const f = toqstr(ChangeExtension(file, ));
if ((databaseLB-findItem(f)) == 0)
databaseLB-insertItem(f);
}
Re: Windows installer
Asger Alstrup wrote:
Another bug: When you uninstall, it does not unregister the .lyx file
association.
I don't see this.
The installer makes the following registry entries:
HKCR\.lyx\LyX
HKCR\.lyx\application/lyx
It removes these on install (see
It does not remove
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.lyx
because it didn't make this entry.
Is this what you see?
Angus
In fact, it adds associations to the HKCR tree only:
$ grep HK abi_util_fileassoc.nsh
ReadRegStr $0 HKCR ${extension} ; read current
value
WriteRegStr HKCR ${extension} prior_value $0 ; actually
store the old association
WriteRegStr HKCR ${extension} ${appType}
WriteRegStr HKCR ${extension} Content Type ${contentType}
WriteRegStr HKCR ${appType} ${appDesc}
WriteRegStr HKCR ${appType}\shell open
WriteRegStr HKCR ${appType}\DefaultIcon ${defIcon}
WriteRegStr HKCR ${appType}\shell\open\command '${exeCmd} %1'
; WriteRegStr HKCR ${appType}\shell\open\command ${exeCmd}
; WriteRegStr HKCR ${appType}\shell\open\ddeexec '[Open(%1)]'
; WriteRegStr HKCR ${appType}\shell\open\ddeexec\application ${appName}
; WriteRegStr HKCR ${appType}\shell\open\ddeexec\topic System
; WriteRegStr HKCR ${appType}\shell\edit Edit Options File
; WriteRegStr HKCR ${appType}\shell\edit\command '${exeCmd} %1'
ReadRegStr $0 HKCR ${extension}
ReadRegStr $0 HKCR ${extension} prior_value
ReadRegStr $1 HKCR $0 ; restore
previous association
WriteRegStr HKCR ${extension} $0
; actually restore prior association
DeleteRegValue HKCR ${extension} prior_value
; and remove stored value
DeleteRegKey HKCR ${extension} ; actually
remove file assoications
Re: Mac build problem
On 5/31/05 12:43 PM, Angus Leeming [EMAIL PROTECTED] wrote: Rob Bearman wrote: Does anyone else see this? Fresh CVS check out/build. OS X 10.4. I've built successfully on Tiger before. Nope. But different Qt versions may behave differently. QBibtexDialog.C:153: error: could not convert `QLineEdit::text() const()' to Does the attached patch cure the problem? Angus Yes, it does. Thank you. Thanks Rob
Re: Windows installer
Angus Leeming wrote: You can find the resulting installer itself at http://www.devel.lyx.org/~leeming/lyx_setup_136.exe. It's 5.8 MB in size. just wondering: a colleague wants to install lyx under windows. should he use this installer or is it better to use ruurd's files...? thanks regards, ed. I'd say that this 1.3.6pre1 (:-)) was uniformly better than Ruurd's 1.3.5 port. Your colleague should install python, perl, minsys, miktex (or similar), imagemagic and should add these paths to the path_prefix variable in lyxrc.defaults/preferences. Known bugs: only that it is currently impossible to load graphics files containing ':' (C:\foo\bar) using the file browser. Hi, Ed. If your colleague were to grab the version of lyx_setup_136.exe that's now on my devel.lyx.org pages, he'd find that this particular bug has been squashed. Angus
Re: [Patch] Re: [patch] key event queue
Martin Vermeer <[EMAIL PROTECTED]> writes: >> So it seems to fix most problems we have and feels uniformly better that >> what we have right now? If so... > | Yes, I believe so. > | Therefore I will commit the attached, if no new objections come up. I | have somewhat thoroughly tested this with the User Guide. Go ahead. I will redo my test afterwards. -- Lgb
Re: LyX meeting in Paris. What about July 14-18?
Jean-Marc Lasgouttes wrote: I was just gratuitously bitching about the flight to/from Paris, since you said yourself it was too slow and too expensive... Ah, I see. Yes, I'll just let you have all the pain :-) The only compensation is a hot climate, a nice swimming pool, a nice view, and all the Efes you can handle. If the meeting had been at another point in time, I'd have no problem taking an expensive & bad connection to Paris, but since it's in the middle of my precious vacation, my tolerance is lower. Regards, Asger
Re: [1.3] Compiling package.C fails on Debian unstable
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Then this will be automatically installed by autogen.sh. Well, we need to have the right one to generate the tarball anyway. Lars> Will that help at all? Or does libtool have a problem with Lars> FreeBSD and Darwin in general? I gave FreeBSD and Darwin as gratuitous examples, I do not remember the specifics. Contrary to autoconf, libtool relies on a big switch to know what to do with each platform, which means that it is very sensitive to behavioral changes in different versions of OSes. JMarc
Re: LyX meeting in Paris. What about July 14-18?
> "Asger" == Asger Alstrup <[EMAIL PROTECTED]> writes: Asger> If the meeting had been at another point in time, I'd have no Asger> problem taking an expensive & bad connection to Paris, but Asger> since it's in the middle of my precious vacation, my tolerance Asger> is lower. Sure, I understand that. JMarc PS: this morning, I was triaging old papers and found ``Project LyX3'', ``Strings and encodings in LyX 1.2'' and ``Design and implementation of the data structure layer in the new LyX kernel'', all of them by the very esteemed Asger Alstrup Nielsen. These even sport nice tables and figures :)
Re: Graphics path with ":"
Michael Schmitt wrote:
> Angus,
>
> I tried to insert a graphics which is located in directory
> C:\blabla\blabla. However, LyX 1.3.6cvs complains about the path
> containing invalid character ":". Didn't this work before?
In src/frontends/controllers/helper_funcs.C, try removing the ':' from
string const get_invalid_chars_latex()
{
string invalid_chars("#$%{}()[]:\"^");
if (!lyxrc.tex_allows_spaces)
invalid_chars += ' ';
return invalid_chars;
}
Reading http://wiki.lyx.org/LaTeX/FilesWithSpecialChars and
http://wiki.lyx.org/uploads/LaTeX/FilesWithSpecialChars/filenames.tex, I
don't see why a ':' in a file name won't work, but you're the one using
this stuff...
Please report back if LaTeX is happy.
--
Angus
Re: Graphics path with ":"
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Reading http://wiki.lyx.org/LaTeX/FilesWithSpecialChars and Angus> http://wiki.lyx.org/uploads/LaTeX/FilesWithSpecialChars/filenames.tex, Angus> I don't see why a ':' in a file name won't work, but you're the Angus> one using this stuff... I guess ':' is a problem in a windows file name if it is not the drive separator. JMarc
Re: Translation of layout files
> "G" == G Milde <[EMAIL PROTECTED]> writes: G> On 27.05.05, Jean-Marc Lasgouttes wrote: >> > "G" == G Milde <[EMAIL PROTECTED]> writes: >> In the meantime, labelstrings help, but they are a hack. And >> really, if all they are good for is to show the Style name, we have >> a problem. G> Open the dinbrief template, to see what I mean. G> E.g. there are 3 Styles that take an address: My_Address (letter G> head), Send_To_Address (addressee) ReturnAddress (backaddress in G> address window) G> IMHO, labeling them is more distinct and transparent than relying G> only on different physical layout on screen. I understand what the problem is. I just say that Labelstring is not supposed to be used for that. But for now, it will be OK. G> Also, a number of LaTeX commands adds a label, e.g. \abstract in G> some classes, or in dinbrief the styles G> PS Encl cc But these are real labelstrings (that appear in printout), right? JMarc
Re: Graphics path with ":"
Jean-Marc Lasgouttes wrote: > Angus> Reading http://wiki.lyx.org/LaTeX/FilesWithSpecialChars and > Angus> http://wiki.lyx.org/uploads/LaTeX/FilesWithSpecialChars/filenames.tex, > Angus> I don't see why a ':' in a file name won't work, but you're the > Angus> one using this stuff... > > I guess ':' is a problem in a windows file name if it is not the drive > separator. Not from a LaTeX point of view. The OS will complain that such a file name is illegal and that the file can't exist. I don't think that we need to do anything special to handle such situations. One thing that I have noticed (not a bug, but an inconsistency) is that in the Preferences dialog, the Paths pane displays all paths in UNIX style. This looks a little odd because at the bottom of the list is the "prepend_path" variable which is displayed as "C:\foo\bar;C:\bar\baz". Do you think that we should pass the other paths through (in,ex}ternal_path() ? -- Angus
Re: Windows installer
Angus Leeming wrote: I think I'd like to add this to development/Windows. OK? Go ahead. You can find the resulting installer itself at http://www.devel.lyx.org/~leeming/lyx_setup_136.exe. It's 5.8 MB in size. As such, I'm quite pleased with the installer. Me too. Good work! > However, it is not yet complete. It should run the Resources/lyx/configure script but doing so will require it to check for/find a unix shell environment. I plan to add this support but, for now, you should run "sh configure" from the Resources/lyx directory before launching lyx. Once again, I'll say that rewriting configure in some other programming language would be a scoop. I've seen a few projects use JavaScript: libxml, libxslt, but you almost had a shell in c++, which I believe would be the best, since then "configure" could be live inside LyX: It could automatically check dependencies just-in-time. As a second best option, you could extend the installer with downloads and installs of the necessary components. Anyway, as a minimum, you should present a web-page at the end with a bunch of download links for all the prerequisites and optional extension packages required to get the full benefit of LyX. A few other comments: A nice installer will offer to start the application after the installation, to relieve the poor user from having to find the icon himself. Normally, it is good manners to ask whether to register the application with the .lyx suffix or not. In theory, the user might have another application that uses the same suffix, and would prefer to keep it that way. Of course, a port to 1.4.x would be great. Finally a question: did you use the most aggressive 7-zip compression? 5.8 Mb is a bit steep, Regards, Asger
Re: Graphics path with ":"
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> One thing that I have noticed (not a bug, but an inconsistency) Angus> is that in the Preferences dialog, the Paths pane displays all Angus> paths in UNIX style. This looks a little odd because at the Angus> bottom of the list is the "prepend_path" variable which is Angus> displayed as "C:\foo\bar;C:\bar\baz". Angus> Do you think that we should pass the other paths through Angus> (in,ex}ternal_path() ? We should probably. But in which form should we store them? JMarc
Re: [PATCH] Bug 1892: inserting an index or a tabular can move the cursor.
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: Jean-Marc> Here is a patch for this bug, which boils down to: Jean-Marc> createInset should create insets, and dispatch is Jean-Marc> responsible for spawning dialogs if needed. The Jean-Marc> constification of getStringToIndex is not needed, but I Jean-Marc> think it is better. Jean-Marc> I will commit on monday if nobody objects. I did it. JMarc
[PATCH] bug 1891: note-next triggers assertion
The following patch repairs gotoInset so that it does not crash when
the document is empty.
OK?
JMarc
Index: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.2189
diff -u -p -r1.2189 ChangeLog
--- src/ChangeLog 30 May 2005 15:35:09 - 1.2189
+++ src/ChangeLog 31 May 2005 09:21:13 -
@@ -1,3 +1,8 @@
+2005-05-31 Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
+
+ * bufferview_funcs.C (gotoInset): fix the wrap-around code to
+ avoid a crash (bug 1891)
+
2005-05-27 Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
Fix bug 1892:
Index: src/bufferview_funcs.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/bufferview_funcs.C,v
retrieving revision 1.151
diff -u -p -r1.151 bufferview_funcs.C
--- src/bufferview_funcs.C 26 Apr 2005 11:12:09 - 1.151
+++ src/bufferview_funcs.C 31 May 2005 09:21:13 -
@@ -253,12 +253,15 @@ void gotoInset(BufferView * bv, vectorcursor() != doc_iterator_begin(bv->buffer()->inset())) {
tmpcur.reset(tmpcur.bottom().inset());
- if (!gotoNextInset(tmpcur, codes, contents))
+ if (!gotoNextInset(tmpcur, codes, contents)) {
bv->cursor().message(_("No more insets"));
+return;
+ }
} else {
bv->cursor().message(_("No more insets"));
+ return;
}
}
Re: Windows installer
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> As such, I'm quite pleased with the installer. However, it is Angus> not yet complete. It should run the Resources/lyx/configure Angus> script but doing so will require it to check for/find a unix Angus> shell environment. I plan to add this support but, for now, you Angus> should run "sh configure" from the Resources/lyx directory Angus> before launching lyx. Are you sure this is needed? lib/configure should be run automatically in the user directory when starting. If it does not we should investigate why. JMarc
Re: [PATCH] bug 1891: note-next triggers assertion
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| The following patch repairs gotoInset so that it does not crash when
| the document is empty.
>
| OK?
sure.
| if (!gotoNextInset(tmpcur, codes, contents)) {
| - if (tmpcur != doc_iterator_begin(tmpcur.inset())) {
h| +if (bv->cursor() != doc_iterator_begin(bv->buffer()->inset())) {
tmpcur invalidated by gotoNextInset?
--
Lgb
Re: Windows installer
Jean-Marc Lasgouttes wrote: > Angus> As such, I'm quite pleased with the installer. However, it is > Angus> not yet complete. It should run the Resources/lyx/configure > Angus> script but doing so will require it to check for/find a unix > Angus> shell environment. I plan to add this support but, for now, you > Angus> should run "sh configure" from the Resources/lyx directory > Angus> before launching lyx. > > Are you sure this is needed? lib/configure should be run automatically > in the user directory when starting. If it does not we should > investigate why. Yes, but really the installer should generate Resources/lyx/lyxrc.defaults for system-wide stuff, no? -- Angus
Re: Windows installer
> "Asger" == Asger Alstrup <[EMAIL PROTECTED]> writes: Asger> Once again, I'll say that rewriting configure in some other Asger> programming language would be a scoop. I've seen a few projects Asger> use JavaScript: libxml, libxslt, but you almost had a shell in Asger> c++, which I believe would be the best, since then "configure" Asger> could be live inside LyX: It could automatically check Asger> dependencies just-in-time. I see two possibilities: - rewrite in python - rewrite in C++ inside LyX. I am not sure how maintainable it would be. Asger> As a second best option, you could extend the installer with Asger> downloads and installs of the necessary components. Anyway, as Asger> a minimum, you should present a web-page at the end with a Asger> bunch of download links for all the prerequisites and optional Asger> extension packages required to get the full benefit of LyX. Yes, being able to check whether msys, python, etc. are installed would be great. JMarc
Re: Windows installer
Jean-Marc Lasgouttes wrote: I see two possibilities: - rewrite in python - rewrite in C++ inside LyX. I am not sure how maintainable it would be. As I said, other projects have decided to use JavaScript. That is better than Python, since it does not require Python. JavaScript is part of the OS. Regards, Asger
Re: Windows installer
Asger Alstrup wrote: > Angus Leeming wrote: >> I think I'd like to add this to development/Windows. OK? > > Go ahead. > >> You can find the resulting installer itself at >> http://www.devel.lyx.org/~leeming/lyx_setup_136.exe. It's 5.8 MB in >> size. >> >> As such, I'm quite pleased with the installer. > > Me too. Good work! > > > However, it is not yet >> complete. It should run the Resources/lyx/configure script but doing so >> will require it to check for/find a unix shell environment. I plan to >> add this support but, for now, you should run "sh configure" from the >> Resources/lyx directory before launching lyx. > > Once again, I'll say that rewriting configure in some other programming > language would be a scoop. I've seen a few projects use JavaScript: > libxml, libxslt, but you almost had a shell in c++, which I believe would > be the best, since then "configure" could be live inside LyX: It could > automatically check dependencies just-in-time. I can do only so much, Asger :) > As a second best option, you could extend the installer with downloads > and installs of the necessary components. Anyway, as a minimum, you > should present a web-page at the end with a bunch of download links for > all the prerequisites and optional extension packages required to get the > full benefit of LyX. That's the plan. I've got code to check the registry for python, perl and imagemagick and to open up the relevant download page in your web browser. Looking for minSYS is a bit more complicated because it doesn't write to the registry at all. The trick, apparently is to look for the uninstaller .ini script. What else? MikTeX I guess... I imagine adding a page to the installer: Perl[ C:\foo\bar\perl.exe ] [ Browse ] [ Download ] Python [_] [ Browse ] [ Download ] MinSYS [_] [ Browse ] [ Download ] MikTeX [_] [ Browse ] [ Download ] ImageMagick [_] [ Browse ] [ Download ] [ OK ] where the input widgets are populated with entries from the Registry, but I have no idea if such a page is possible with NSIS. Do you? If so, could you cobble something hackish together to give me a bit of a start? > A few other comments: A nice installer will offer to start the > application after the installation, to relieve the poor user from having > to find the icon himself. Trivially easy but pointless if I can't get Resources/lyx/configure to run. (Pointless because LyX will refuse to start if it can't find the generated lyxrc.defaults file.) What I'd like to do is to set the PATH to include at least the MinSYS directory, run configure, getting it to write the "path_prefix" variable to lyxrc.defaults containing all of these extras and then show the final page with a checkbox specifying whether lyx.exe should be launched at the end of installation. > Normally, it is good manners to ask whether to register the application > with the .lyx suffix or not. In theory, the user might have another > application that uses the same suffix, and would prefer to keep it that > way. OK. That's easy to do. > Of course, a port to 1.4.x would be great. If you look at the script itself you'll see a bunch of PRODUCT_XYZ macros at the top of the file. That should be all you need to change. > Finally a question: did you use the most aggressive 7-zip compression? > 5.8 Mb is a bit steep, Crappy old zip compression: 8MB. bzip2 compression: 6.7MB Brand new lmza compression: 5.8MB. I compiled with g++ 3.4. Ruurd was compiling his original port with the free msvc compiler, using a wrapper to convert g++ command line args to something comprehensible to msvc. I guess that this would produce a leaner executable but, again, I've only got so much time and energy. > Regards, > Asger -- Angus
Re: Windows installer
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Jean-Marc Lasgouttes wrote: As such, I'm quite pleased with the Angus> installer. However, it is not yet complete. It should run the Angus> Resources/lyx/configure script but doing so will require it to Angus> check for/find a unix shell environment. I plan to add this Angus> support but, for now, you should run "sh configure" from the Angus> Resources/lyx directory before launching lyx. >> Are you sure this is needed? lib/configure should be run >> automatically in the user directory when starting. If it does not >> we should investigate why. Angus> Yes, but really the installer should generate Angus> Resources/lyx/lyxrc.defaults for system-wide stuff, no? I am not sure this system-wide lyxrc.defaults is really needed. IMO it should not. JMarc
Re: Windows installer
> "Asger" == Asger Alstrup <[EMAIL PROTECTED]> writes: Asger> Jean-Marc Lasgouttes wrote: >> I see two possibilities: - rewrite in python - rewrite in C++ >> inside LyX. I am not sure how maintainable it would be. Asger> As I said, other projects have decided to use JavaScript. That Asger> is better than Python, since it does not require Python. Asger> JavaScript is part of the OS. But we already require python. And what do you mean by 'part of the OS'? JMarc
Re: Graphics path with ":"
Jean-Marc Lasgouttes wrote: > Angus> One thing that I have noticed (not a bug, but an inconsistency) > Angus> is that in the Preferences dialog, the Paths pane displays all > Angus> paths in UNIX style. This looks a little odd because at the > Angus> bottom of the list is the "prepend_path" variable which is > Angus> displayed as "C:\foo\bar;C:\bar\baz". > > Angus> Do you think that we should pass the other paths through > Angus> (in,ex}ternal_path() ? > > We should probably. But in which form should we store them? lyxrc.defaults/preferences: external_path. Convert to internal_path in lyxrc::read() and to external_path in lyxrc::write(). -- Angus
Re: Windows installer
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Trivially easy but pointless if I can't get Angus> Resources/lyx/configure to run. (Pointless because LyX will Angus> refuse to start if it can't find the generated lyxrc.defaults Angus> file.) I think we should change that and have LyX look for another file. >> Finally a question: did you use the most aggressive 7-zip >> compression? 5.8 Mb is a bit steep, Angus> Crappy old zip compression: 8MB. bzip2 compression: 6.7MB Brand Angus> new lmza compression: 5.8MB. And this does not include the docs, it seems. Angus> I compiled with g++ 3.4. Ruurd was compiling his original port Angus> with the free msvc compiler, using a wrapper to convert g++ Angus> command line args to something comprehensible to msvc. I guess Angus> that this would produce a leaner executable but, again, I've Angus> only got so much time and energy. The executable is 11Mb. Are you sure it is correctly stripped? I see the console window flashes shortly on startup. Is there a reason why you do not use -mwindows as link option instead of trying to close the console by hand? JMarc
Re: [PATCH] bug 1891: note-next triggers assertion
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> tmpcur invalidated by gotoNextInset? Yes, when getoNextInset fails, it means that tmpcur is empty. Thefore there is no tmpcur.inset() to test against. I am not sure ho I managed to miss that. The second part of the fix is to avoid setting the cursor when the search failed. I committed it. JMarc
Re: Windows installer
Jean-Marc Lasgouttes wrote: > Angus> Jean-Marc Lasgouttes wrote: As such, I'm quite pleased with the > Angus> installer. However, it is not yet complete. It should run the > Angus> Resources/lyx/configure script but doing so will require it to > Angus> check for/find a unix shell environment. I plan to add this > Angus> support but, for now, you should run "sh configure" from the > Angus> Resources/lyx directory before launching lyx. >>> Are you sure this is needed? lib/configure should be run >>> automatically in the user directory when starting. If it does not >>> we should investigate why. > > Angus> Yes, but really the installer should generate > Angus> Resources/lyx/lyxrc.defaults for system-wide stuff, no? > > I am not sure this system-wide lyxrc.defaults is really needed. IMO it > should not. Anyway, let's not get too worried about this bit. First, we should get the installer to check for the presence of python, perl, minsys, miktex, imagemagick... -- Angus
Re: Windows installer
Jean-Marc Lasgouttes wrote: > Angus> Trivially easy but pointless if I can't get > Angus> Resources/lyx/configure to run. (Pointless because LyX will > Angus> refuse to start if it can't find the generated lyxrc.defaults > Angus> file.) > > I think we should change that and have LyX look for another file. I'm not even sure that my statement is true... I do know that I explcitly remove lyxrc.defaults et al. before trying to package lyx. I'll investigate further. >>> Finally a question: did you use the most aggressive 7-zip >>> compression? 5.8 Mb is a bit steep, > > Angus> Crappy old zip compression: 8MB. bzip2 compression: 6.7MB Brand > Angus> new lmza compression: 5.8MB. > > And this does not include the docs, it seems. > > Angus> I compiled with g++ 3.4. Ruurd was compiling his original port > Angus> with the free msvc compiler, using a wrapper to convert g++ > Angus> command line args to something comprehensible to msvc. I guess > Angus> that this would produce a leaner executable but, again, I've > Angus> only got so much time and energy. > > The executable is 11Mb. Are you sure it is correctly stripped? What does "correctly" mean? It works, doesn't it? The executable was built with --disable-debug --enable-optimization. Thereafter I ran strip over it. What more can I do? The debug build has a 120MB executable... > I see the console window flashes shortly on startup. Is there a reason > why you do not use -mwindows as link option instead of trying to close > the console by hand? I followed Ruurd's advice on this one. See the commentary in support/os_win.C. -- Angus
RE: Re: Windows installer
> Angus Leeming wrote: >> You can find the resulting installer itself at >> http://www.devel.lyx.org/~leeming/lyx_setup_136.exe. It's 5.8 MB in >> size. just wondering: a colleague wants to install lyx under windows. should he use this installer or is it better to use ruurd's files...? thanks & regards, ed.
Re: Translation of layout files
On 31.05.05, Jean-Marc Lasgouttes wrote: > > "G" == G Milde <[EMAIL PROTECTED]> writes: > > G> On 27.05.05, Jean-Marc Lasgouttes wrote: > >> > "G" == G Milde <[EMAIL PROTECTED]> writes: > I understand what the problem is. I just say that Labelstring is not > supposed to be used for that. But for now, it will be OK. > > G> Also, a number of LaTeX commands adds a label, e.g. \abstract in > G> some classes, or in dinbrief the styles > > G> PS Encl cc > > But these are real labelstrings (that appear in printout), right? Yes, this is what I mean with "LaTeX commands adds a label". Did I get you right in supposing this is "the right" use of LabelStrings? So, the next problem arises: translating of this label strings is handeled by babel in LaTeX on a per-document basis, while the translation in LyX is governed by the LANG environment variable. Maybe not translating label strings at all is better? Günter -- G.Milde web.de
RE: Re: Windows installer
Leuven, E. wrote: >> Angus Leeming wrote: >>> You can find the resulting installer itself at >>> http://www.devel.lyx.org/~leeming/lyx_setup_136.exe. It's 5.8 MB in >>> size. > > just wondering: a colleague wants to install lyx under windows. should he > use this installer or is it better to use ruurd's files...? > > thanks & regards, ed. I'd say that this 1.3.6pre1 (:-)) was uniformly better than Ruurd's 1.3.5 port. Your colleague should install python, perl, minsys, miktex (or similar), imagemagic and should add these paths to the path_prefix variable in lyxrc.defaults/preferences. Known bugs: only that it is currently impossible to load graphics files containing ':' (C:\foo\bar) using the file browser. -- Angus
Re: Windows installer
Angus Leeming wrote: Finally a question: did you use the most aggressive 7-zip compression? 5.8 Mb is a bit steep, >> >> Angus> Crappy old zip compression: 8MB. bzip2 compression: 6.7MB Brand >> Angus> new lmza compression: 5.8MB. >> >> And this does not include the docs, it seems. >> >> Angus> I compiled with g++ 3.4. Ruurd was compiling his original port >> Angus> with the free msvc compiler, using a wrapper to convert g++ >> Angus> command line args to something comprehensible to msvc. I guess >> Angus> that this would produce a leaner executable but, again, I've >> Angus> only got so much time and energy. >> >> The executable is 11Mb. Are you sure it is correctly stripped? > > What does "correctly" mean? It works, doesn't it? Note also that Ruurd's 1.3.5 port http://prdownloads.sourceforge.net/lyx-win32/lyx-1.3.5-win32.exe?download comes in at 5.5MB when using the Qt/WinFree port and at 6.5MB when using Qt Non-Commercial 3.2.1. >From Ruurd's web pages: The latest binary you will find here is compiled using MSVC 8 beta, Qt Non-commercial 3.2.1 and Cygwin. With the new free Qt port from the kde-cygwin project, it's possible to compile the whole thing with mingw (and msys), or MSVC 7.1 (aka 2003) and up. The free Qt port still has a few bugs though. I take that as saying that compiling with MSVC doesn NOT produce a much leaner executable than g++. -- Angus
