Re: lyx140cvs, qt: table dialogue window
Angus Leeming wrote: Hmmm. But that can be turned off (and is by default). I think that the toolbar should provide shortcuts to things that are also possible in the dialogs, no? Or in the menu... Jürgen
Re: lyx140cvs, qt: table dialogue window
Juergen Spitzmueller wrote: Hmmm. But that can be turned off (and is by default). I think that the toolbar should provide shortcuts to things that are also possible in the dialogs, no? Or in the menu... Good point. I'll withdraw my objection then. -- Angus
Re: QT 3/Win Free
[EMAIL PROTECTED] wrote: For drawing table cell boundaries, LyX sets the style of a QPen in the following way: QPen pen = ...; pen.setColor(LightSteelBlue); pen.setStyle(QPen:DotLine); pen.setWidth(0); As a result, a thin blue dotted line should be drawn when using this pen. But instead, a black (sometimes red) solid line is draw (the color may depend on former drawing operations). If you can spare some time, you might have a look at the corresponding Qt code. Unfortunately, I haven't been able to create a test case yet due to time constraints. I can try to create one this evening if that helps. Hi, Michael. It's great to see that you're actually using this thing! Do you see the drawing problems that I describe in my Just for fun mail too? -- Angus
Re: [rework docs] reasons, plans, questions
John Spray wrote: On Sun, 2005-01-09 at 20:14 +0100, Andre Poenitz wrote: Depends on the release date. If that's 'soonish', probably not, otherwise i depends on th GTK frontend to catch up... I keep offering the GTK frontend cookies and sweets to try and get it to catch up, but it just sits there obstinately waiting for me to work on it. lyx-gtk is pretty broken atm, actually, one can't even scroll around in a document due to some changes somewhere along the line in lyx proper: I cannot say when since I was not paying attention at the time. I know what this it: the gtk frontend fires the scrolling signal when setting the scrollbar parameters from inside LyX: the kernel expects that setting the parameters only changes the scrollbar visually (and invokes no scrolling). This results in an infinite loop. There was a similar problem in the qt frontend, that was solved by deactivating the signal somewhere IIRC. Unfortunately I cannot look at the problem more closely ATM. useless rant OTOH the requirement to have bleeding edge gtkmm libs just to be able to compile it doesn't make the work easy for us to keep up... /useless rant I'm hoping that my sense of humour will improve when I've had some sleep. To quote Lars: Blame it on the Pub[1]. ;-) Alfredo
Re: Creating a std::string from unsigned char[4097] ?
John Weiss [EMAIL PROTECTED] writes: PATH_MAX does not seem like a good idea. (and then you must at least zero out application_support first.) | Umm, Lars, the constructor for POD arrays *always* zeros out the | elements, remember? (bitterIt's in the Standard; I know. I spent the | summer studying the bloody thing in prep for interviews. Fat | load-o-good that did me.../bitter) No. Only if it is static or global. Another thing for your interviews I guess :-) -- Lgb
External material subfigure
Angus, I notice that subfigure is not supported yet in the external material inset. It shouldn't be very hard to add, the way it looks now. One very simple way for doing this is the following: 1) Define, in a layout file widely included (e.g., stdlayouts.inc) a layout subfigure of latextype command and latexname subfigure. 2) Give this layout an optional argument (the subcaption text to be) 3) Include as the main content of the paragraph the external material inset. Like this in ascii art: [Figure float] +---+ |(subfigure para style) [OptArg] [Xfig: myfigure 1] | | [The subfigure 1 caption] | |(subfigure para style) [OptArg] [Xfig: myfigure 2] | | [The subfigure 2 caption] | | | |(caption para style) The figure main caption | +---+ This is a little cludgy but very straightforward. I foresee a problem with the caption hack though in text.C :-( Which we should perhaps re-think. What do you think? -- Martin Vermeer [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: LyX on Windows
Hi, I managed to checkout qt3 win32 free and lyx-devel. I even managed to compile qt-3, although I ran out of disk space, and what not. Now, I'm starting to build a VS.NET 7.1 project file for LyX, but I need all the generated files from configure on Windows from one of you guys, since I refuse to install cygwin or mingw. For starters, could someone hand me a config.h file? Also, if someone could provide a rough list of which source files (i.e. which directories) needs to be compiled into the LyX proper in the Qt edition, that would be helpfulp. Thanks, Asger
Re: [rework docs] reasons, plans, questions
On Mon, 2005-01-17 at 10:08 +0100, Alfredo Braunstein wrote: I know what this it: the gtk frontend fires the scrolling signal when setting the scrollbar parameters from inside LyX: the kernel expects that setting the parameters only changes the scrollbar visually (and invokes no scrolling). This results in an infinite loop. Great, I figured it was something like this but hadn't gotten around to looking. There is now a stickynote on my desktop about this. useless rant OTOH the requirement to have bleeding edge gtkmm libs just to be able to compile it doesn't make the work easy for us to keep up... /useless rant useless indignant squeal At the risk of being a GNOME-enthusiast-asshole, I have bleeding edge gtkmm libs, and they're not what LyX depends on: there are widgets in 2.5.x that I'd like to use in LyX but I'm holding back precisely for the benefit of those who don't have the degree of love for compiling GTK+ from CVS that I do ;-) /useless indignant squeal John
Re: LyX on Windows
Asger Ottar Alstrup wrote: I managed to checkout qt3 win32 free and lyx-devel. Note that I've only tried to get BRANCH_1_3_X to compile. I even managed to compile qt-3, although I ran out of disk space, and what not. Now, I'm starting to build a VS.NET 7.1 project file for LyX, but I need all the generated files from configure on Windows from one of you guys, since I refuse to install cygwin or mingw. When it comes to *running* lyx you'll still need a decent shell and associated utilities to run the lib/configure scipt. For starters, could someone hand me a config.h file? Mine are attached, both for 1.3.x and for 1.4.x. Also, if someone could provide a rough list of which source files (i.e. which directories) needs to be compiled into the LyX proper in the Qt edition, that would be helpfulp. You need the qt3.3.3.dll (or some such name). Is that not the end result of compiling the src/kernel directories? You'll also need the uic and moc executables. -- Angus config_13x.h.bz2 Description: BZip2 compressed data config_14x.h.bz2 Description: BZip2 compressed data
Re: External material subfigure
Martin Vermeer wrote: Angus, I notice that subfigure is not supported yet in the external material inset. It never will. It shouldn't be very hard to add, the way it looks now. We need a new inset which shouldn't be very hard to write. InsetSubfigure. One very simple way for doing this is the following: 1) Define, in a layout file widely included (e.g., stdlayouts.inc) a layout subfigure of latextype command and latexname subfigure. 2) Give this layout an optional argument (the subcaption text to be) 3) Include as the main content of the paragraph the external material inset. Like this in ascii art: [Figure float] +---+ |(subfigure para style) [OptArg] [Xfig: myfigure 1] | | [The subfigure 1 caption] | |(subfigure para style) [OptArg] [Xfig: myfigure 2] | | [The subfigure 2 caption] | | | |(caption para style) The figure main caption | +---+ This is a little cludgy but very straightforward. I foresee a problem with the caption hack though in text.C :-( Which we should perhaps re-think. What do you think? Sounds like a plan to me, but I tend to be less ruthless about hacks than some ;-) -- Angus
Re: LyX on Windows
Angus Leeming wrote: Note that I've only tried to get BRANCH_1_3_X to compile. OK, I'm working on the main branch. When it comes to *running* lyx you'll still need a decent shell and associated utilities to run the lib/configure scipt. That is something to address then for a native Windows port to work out. I'd like to produce a native LyX binary with as few unix dependencies as possible. Further out, I'd even like to kick out LaTeX, and put some other backend in instead to reduce the footprint. Mine are attached, both for 1.3.x and for 1.4.x. Thanks, that gets me down to about 1500 remaining errors and warnings ;-) You need the qt3.3.3.dll (or some such name). Is that not the end result of compiling the src/kernel directories? There is no src/kernel directory, but I have a qt-mt3.dll from the Qt compile. You'll also need the uic and moc executables. I have those as part of the Qt compile. What is the compilation procedure for those Qt .ui files? I get a bunch of errors like: QERTDialog.C c:\lyx\lyx-devel\src\frontends\qt2\QERTDialog.h(15) : fatal error C1083: Cannot open include file: 'ui/QERTDialogBase.h': No such file or directory so I guess those files are generated by some Qt utility. My plan is this: - get everything to compile. - get everything to link. - get it to start-up (without crash). - get it to run without all those unix dependencies. The main barrier for me is disk space... I keep running out, and since it's a laptop, it's a bit problematic for me to add more space. I'll have to get an external firewire or usb-2 disc I suppose. Regards, Asger
[PATCH 13x, 14x] package and relative paths from PATH
The attached patches enable the lyx executable to be found from the PATH
environment variable if it expands to elements with relative paths.
Confirmed as working and fixes a clear bug so I'm committing to both trees
now.
--
AngusIndex: src/support/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/ChangeLog,v
retrieving revision 1.149.2.27
diff -u -p -r1.149.2.27 ChangeLog
--- src/support/ChangeLog 13 Jan 2005 10:09:46 - 1.149.2.27
+++ src/support/ChangeLog 17 Jan 2005 11:42:48 -
@@ -1,3 +1,8 @@
+2005-01-17 Angus Leeming [EMAIL PROTECTED]
+
+ * package.C (get_binary_path): convert relative paths stored
+ in the PATH environment variable to absolute ones.
+
2005-01-12 Angus Leeming [EMAIL PROTECTED]
* filetools.[Ch] (setEnvPath): new function to create a PATH-style
Index: src/support/package.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/Attic/package.C,v
retrieving revision 1.1.2.2
diff -u -p -r1.1.2.2 package.C
--- src/support/package.C 12 Jan 2005 23:43:38 - 1.1.2.2
+++ src/support/package.C 17 Jan 2005 11:42:49 -
@@ -145,7 +145,7 @@ Package::Package(string const command_
\tdocument_dir document_dir() '\n'
\ttemp_dir temp_dir() '\n'
\thome_dir home_dir() '\n'
- \\package\n std::endl;
+ /package\n std::endl;
}
@@ -351,11 +351,10 @@ string const get_binary_path(string cons
std::vectorstring::const_iterator it = path.begin();
std::vectorstring::const_iterator const end = path.end();
for (; it != end; ++it) {
- if (!os::is_absolute_path(*it))
- // Someone is playing silly buggers.
- continue;
+ // This will do nothing if *it is already absolute.
+ string const exe_dir = MakeAbsPath(*it);
- string const exe_path = AddName(*it, exe_name);
+ string const exe_path = AddName(exe_dir, exe_name);
if (lyx::FileInfo(exe_path, true).isOK())
return exe_path;
}
Index: src/support/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/ChangeLog,v
retrieving revision 1.307
diff -u -p -r1.307 ChangeLog
--- src/support/ChangeLog 16 Jan 2005 21:01:41 - 1.307
+++ src/support/ChangeLog 17 Jan 2005 11:34:07 -
@@ -1,3 +1,8 @@
+2005-01-17 Angus Leeming [EMAIL PROTECTED]
+
+ * package.C.in (get_binary_path): convert relative paths stored
+ in the PATH environment variable to absolute ones.
+
2005-01-16 Angus Leeming [EMAIL PROTECTED]
* filetools.[Ch] (prependEnvPath): prepend a list of paths to
Index: src/support/package.C.in
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/package.C.in,v
retrieving revision 1.4
diff -u -p -r1.4 package.C.in
--- src/support/package.C.in 13 Jan 2005 16:50:44 - 1.4
+++ src/support/package.C.in 17 Jan 2005 11:34:08 -
@@ -80,6 +80,9 @@ void init_package(string const command
Package const package()
{
+ // Commented out because package().locale_dir() can be called
+ // from the message translation code in messages.C before
+ // init_package() is called. Lars is on the case...
// BOOST_ASSERT(initialised_);
return package_;
}
@@ -150,7 +153,7 @@ Package::Package(string const command_
\tdocument_dir document_dir() '\n'
\ttemp_dir temp_dir() '\n'
\thome_dir home_dir() '\n'
- \\package\n std::endl;
+ /package\n std::endl;
}
@@ -388,11 +391,10 @@ string const get_binary_path(string cons
std::vectorstring::const_iterator it = path.begin();
std::vectorstring::const_iterator const end = path.end();
for (; it != end; ++it) {
- if (!os::is_absolute_path(*it))
- // Someone is playing silly buggers.
- continue;
+ // This will do nothing if *it is already absolute.
+ string const exe_dir = MakeAbsPath(*it);
- string const exe_path = AddName(*it, exe_name);
+ string const exe_path = AddName(exe_dir, exe_name);
if (FileInfo(exe_path, true).isOK())
return exe_path;
}
Paragraph indendation
I am trying to fix the broken paragraph indendation (i.e., its representation on screen). So far, I have spotted the line to blame. It's the check for InsetBase::TEXT_CODE in the following snippet (text.C, 598ff): if (pos = 0 [...] // in charstyles, tabulars and ert paragraphs are never indented! (par.ownerCode() != InsetBase::TEXT_CODE par.ownerCode() != InsetBase::ERT_CODE par.ownerCode() != InsetBase::CHARSTYLE_CODE) InsetBase::TEXT_CODE should avoid indedations in tabulars, but it is also true in normal text. I have replaced that with InsetBase::TABULAR_CODE, but this doesn't work either (i.e. pars in tabulars are indented). Any idea? Jürgen
Re: External material subfigure
On Mon, 2005-01-17 at 12:14, Angus Leeming wrote: Martin Vermeer wrote: Angus, I notice that subfigure is not supported yet in the external material inset. It never will. It shouldn't be very hard to add, the way it looks now. We need a new inset which shouldn't be very hard to write. InsetSubfigure. Doable, yes. 1.5. One very simple way for doing this is the following: Sounds like a plan to me, but I tend to be less ruthless about hacks than some ;-) Unfortunately this works only as long as you don't want to put subfigures side by side... inevitable consequence of making subfigure a paragraph. A well, ERT works for me now. - Martin signature.asc Description: This is a digitally signed message part
Re: LyX on Windows
Asger Ottar Alstrup [EMAIL PROTECTED] writes: | I have those as part of the Qt compile. | What is the compilation procedure for those Qt .ui files? That is in the makefiles... If you want to do this without the use of automake/autoconf: Good Luck. But please do not clutter the directories with .proj files. -- Lgb
Re: LyX on Windows
Asger Ottar Alstrup wrote: That is something to address then for a native Windows port to work out. I'd like to produce a native LyX binary with as few unix dependencies as possible. I think that this is a very plausible goal. The only big task will be to rewrite lib/configure as a python script. Further out, I'd even like to kick out LaTeX, and put some other backend in instead to reduce the footprint. Note that I'm running lyx 1.3.x on windows without any LaTeX installation at all. I can't generate printable output but I can edit the .lyx files. You need the qt3.3.3.dll (or some such name). Is that not the end result of compiling the src/kernel directories? There is no src/kernel directory, but I have a qt-mt3.dll from the Qt compile. I thought you were talking about which bits of the Qt source were needed by LyX? What is the compilation procedure for those Qt .ui files? See lyx-root/src/frontend/qt2/ui/Makefile.am. It's not very hard to decipher ;-) -- Angus
Re: LyX on Windows
Lars Gullik Bjønnes wrote: | What is the compilation procedure for those Qt .ui files? That is in the makefiles... Does anybody know the exact command line I need to use? If you want to do this without the use of automake/autoconf: Good Luck. But please do not clutter the directories with .proj files. I am making one .sln file, and one .vcproj file for the entire tree. Regards, Asger
Re: Reworking of Kayvan's cygwin_path_fix patch
Angus Leeming wrote:
Kayvan A. Sylvan wrote:
I am able to run it from the build directory via src/lyx. and was
able to confirm that the patch works as expected. Thank you!
Good. Then I'll commit that.
Now, we have to fix this new bug (can not determine the path to the
LyX binary).
H. So lyx is in your path, right? Can you investigate? The routine
that is failing is src/support/package.C.in's abs_path_from_binary_name
(get_binary_path, actually).
Kayvan, I just committed a little patch to this piece of code. It fixes a
clear bug but I wonder if it resolves your problem too?
@@ -388,11 +391,10 @@ string const get_binary_path(string cons
std::vectorstring::const_iterator it = path.begin();
std::vectorstring::const_iterator const end = path.end();
for (; it != end; ++it) {
-if (!os::is_absolute_path(*it))
-// Someone is playing silly buggers.
-continue;
-
-string const exe_path = AddName(*it, exe_name);
+// This will do nothing if *it is already absolute.
+string const exe_dir = MakeAbsPath(*it);
+
+string const exe_path = AddName(exe_dir, exe_name);
if (FileInfo(exe_path, true).isOK())
return exe_path;
}
--
Angus
Re: LyX on Windows
Asger Ottar Alstrup [EMAIL PROTECTED] writes: | Lars Gullik Bjønnes wrote: | What is the compilation procedure for those Qt .ui files? That is in the makefiles... | Does anybody know the exact command line I need to use? If you want to do this without the use of automake/autoconf: Good Luck. But please do not clutter the directories with .proj files. | I am making one .sln file, and one .vcproj file for the entire tree. | Regards, | Asger UICFLAGS=-tr qt_ %.h: %.ui $(UIC) $(UICFLAGS) $ -o $@ %.C: %.h %.ui $(PCH_FILE) $(UIC) $(UICFLAGS) -impl `echo $^ | sed 's/pch.h.gch//'` -o $@ the .h file: uic -tr qt_ foo.ui -o foo.h the .C file: uic -tr qt_ foo.ui -impl foo.h foo.ui -o foo.C -- Lgb
Re: Paragraph indendation
Juergen Spitzmueller wrote: I am trying to fix the broken paragraph indendation (i.e., its representation on screen). So far, I have spotted the line to blame. It's the check for InsetBase::TEXT_CODE in the following snippet (text.C, 598ff): if (pos = 0 [...] // in charstyles, tabulars and ert paragraphs are never indented! (par.ownerCode() != InsetBase::TEXT_CODE par.ownerCode() != InsetBase::ERT_CODE par.ownerCode() != InsetBase::CHARSTYLE_CODE) InsetBase::TEXT_CODE should avoid indedations in tabulars, but it is also true in normal text. I have replaced that with InsetBase::TABULAR_CODE, but this doesn't work either (i.e. pars in tabulars are indented). Any idea? Paragraph::ownerCode() seems to refer to the insettext owner, not to the tabular owner and this explains why we cannot currently distinguish between normal text and text in tabulars. I think (but almost without reading the code) that The Correct Fix (TM) is to - make leftMargin receive a 1) DocIterator const or even a 2) (pit, pos, InsetBase::InsetCode) instead of a (pit, pos) and - 1) look in the stack of insets whatever it needs to get the correct margin (in this case, it seems it only needs the topmost inset, which is indeed a tabular) or 2) just use the InsetCode provided. Eliminating Paragraph::ownerCode() would even eliminate one more acess to inset_owner (and there are only a few remaining)... I don't know if leftMargins callers have this information available though. I cannot work on this until I get a house adsl (hopefully in some weeks), but I can try to give some other puny advice every now and then ;-) HTH, Alfredo
Re: LyX on Windows
Asger Ottar Alstrup wrote: My plan is this: - get everything to compile. - get everything to link. - get it to start-up (without crash). - get it to run without all those unix dependencies. My immediate targets are * to address the question that started this thread --- do you have any insights you'd care to share? * the signal handling code in lyx_main.C. I'm aware that the non-existence of SIGHUP under Windows isn't an issue. I also understand from Microsoft's UNIX Application Migration Guide http://msdn.microsoft.com/library/en-us/dnucmg/html/UCMGch09.asp?frame=true#ucmgch09_topic3 Equivalent URL: http://tinyurl.com/3pbpp that Windows' signal implentation supports all of the signals that we're interested in: = Table 3. Windows signals SIGFPEFloating-point error SIGINTCTRL+C signal SIGSEGV Illegal storage access SIGTERM Termination request Note When a Ctrl+C interrupt occurs, Win32 operating systems generate a new thread to handle the interrupt. This can cause a single-thread application, such as one ported from UNIX, to become multithreaded, potentially resulting in unexpected behavior. = So, we should probably use Windows Messages instead of SIGINT because LyX definitely isn't a multithreaded beast. Again, have you any thoughts on this? -- Angus
Re: LyX on Windows
Hi Angus,
The irritating thing with Windows is that all stdout messages get lost
somewhere when using the GUI subsystem. You would have to add additional
code to handle all debugging messages. Now that isn´t that hard to do, but
another issue was that some shell script stopped working when linking to the
gui subsystem. I cannot remember what worked and what didn´t. Maybe the
mingw runtime does a better job, but you´ll have to try that out.
Anyway, at that time I´ve looked around, but there didn´t seem to be a more
elegant solution. The console closing code is not that sophisticated, so
that could be improved.
BTW The WinMain stuff get´s added by qtmain automatically.
Ruurd
Angus Leeming [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Good evening, Ruurd.
I wonder if you could help out a Windows novice --- me?
My question concerns the way that Windows treats LyX --- as
a Windows GUI app or as a console one. At the moment, Windows
believes that LyX is a console app because it has a main
function rather than a WinMain.
You've added code in os_win32.C's init function to close
down the console window that Windows helpfully displays
for us:
void os::init(int /* argc */, char * argv[])
{
#ifdef _WIN32
// Close the console when run (probably)
// not run from command prompt
char WindowTitle[1024];
HWND hwndFound;
GetConsoleTitle(WindowTitle,1024);
if ((strcmp(WindowTitle, argv[0]) == 0) ||
(strcmp(WindowTitle,LyX) == 0)) {
// format a unique newWindowTitle
wsprintf(WindowTitle,%d/%d,
GetTickCount(),
GetCurrentProcessId());
// change current window title
SetConsoleTitle(WindowTitle);
// ensure window title has been updated
Sleep(40);
// look for newWindowTitle
hwndFound=FindWindow(NULL, WindowTitle);
// If found, hide it
if ( hwndFound != NULL)
ShowWindow( hwndFound, SW_HIDE);
}
#endif
}
Would it not be more elegant to tell Windows that LyX
is actually a GUI-based app by giving it a WinMain?
The code below compiles fine for me with
$ g++ -mwindows -o trial trial.C
#if defined (_WIN32)
# define WIN32_LEAN_AND_MEAN
# include stdlib.h // for __argc, __argv
# include windows.h // for WinMain
#endif
#if defined (_WIN32)
int mymain(int argc, char * argv[])
#else
int main(int argc, char * argv[])
#endif
{
// LyX's code, unchanged, goes here.
Sleep(5000);
return 0;
}
// This will require the -mwindows flag when linking with
// gcc under MinGW.
// For MSVC, use /subsystem:windows.
#if defined (_WIN32)
int WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
{
std::cout WinMain std::endl;
return mymain(__argc, __argv);
}
#endif
Regards,
Angus
Re: LyX on Windows
Asger, you might want to look into am2msdev ftp://ftp.slac.stanford.edu/users/pfkeb/automake/. This tool will at least provide you with a skeleton. And, I believe the source even includes a project file, so no scary mingw/cygwin tools. There also seems to be an options to add visual studio directives to automake files, that get ignored by the normal autotools. But..I´ve tried what you are trying right now, but became very frustated with this approach;-) Ruurd Asger Ottar Alstrup [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi, I managed to checkout qt3 win32 free and lyx-devel. I even managed to compile qt-3, although I ran out of disk space, and what not. Now, I'm starting to build a VS.NET 7.1 project file for LyX, but I need all the generated files from configure on Windows from one of you guys, since I refuse to install cygwin or mingw. For starters, could someone hand me a config.h file? Also, if someone could provide a rough list of which source files (i.e. which directories) needs to be compiled into the LyX proper in the Qt edition, that would be helpfulp. Thanks, Asger
Re: LyX on Windows
Ruurd Reitsma wrote: Hi Angus, The irritating thing with Windows is that all stdout messages get lost somewhere when using the GUI subsystem. You would have to add additional code to handle all debugging messages. Now that isn´t that hard to do, but another issue was that some shell script stopped working when linking to the gui subsystem. I cannot remember what worked and what didn´t. Maybe the mingw runtime does a better job, but you´ll have to try that out. Anyway, at that time I´ve looked around, but there didn´t seem to be a more elegant solution. The console closing code is not that sophisticated, so that could be improved. BTW The WinMain stuff get´s added by qtmain automatically. Reading this thread http://lists.trolltech.com/qt-interest/2001-11/thread00727-0.html A Windows application does not have any stdout/stderr by default, all output vanishes without a trace for you.But if you want to, you can create a console with AllocConsole() and attach that to stdout/stderr ... Add following lines into main : #ifdef WIN32 AllocConsole(); freopen(conin$, r, stdin); freopen(conout$, w, stdout); freopen(conout$, w, stderr); #endif That suggests that the console could be added when lyxerr is invoked. Anyway, I think that I'll just add your code as-is for now with some commentary describing the alternative. -- Angus
Re: Paragraph indendation
Alfredo Braunstein wrote: Paragraph::ownerCode() seems to refer to the insettext owner, not to the tabular owner and this explains why we cannot currently distinguish between normal text and text in tabulars. Ah, I suspected something like this. Is it possible that this lack of distinguishing is also responsible for some other display bugs (e.g. that the cell's pwidth isn't displayed)? I cannot work on this until I get a house adsl (hopefully in some weeks), but I can try to give some other puny advice every now and then ;-) To be honest, I'd prefer if André or you could take this and do it proper (not because I'm lazy, I just haven't my hands deep enough in it). For now, good luck for your house hunting. Jürgen
Re: LyX on Windows
Angus Leeming [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Reading this thread http://lists.trolltech.com/qt-interest/2001-11/thread00727-0.html A Windows application does not have any stdout/stderr by default, all output vanishes without a trace for you.But if you want to, you can create a console with AllocConsole() and attach that to stdout/stderr ... Add following lines into main : #ifdef WIN32 AllocConsole(); freopen(conin$, r, stdin); freopen(conout$, w, stdout); freopen(conout$, w, stderr); #endif Yep, tried this too. But then it turned out that some shell scripts failed, for mysterious reasons... Ruurd
Re: LyX on Windows
Ruurd Reitsma wrote: Angus Leeming [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Reading this thread http://lists.trolltech.com/qt-interest/2001-11/thread00727-0.html A Windows application does not have any stdout/stderr by default, all output vanishes without a trace for you.But if you want to, you can create a console with AllocConsole() and attach that to stdout/stderr ... Add following lines into main : #ifdef WIN32 AllocConsole(); freopen(conin$, r, stdin); freopen(conout$, w, stdout); freopen(conout$, w, stderr); #endif Yep, tried this too. But then it turned out that some shell scripts failed, for mysterious reasons... So, as said. I'll do it your way and add some notes about why. This is something that can easily be revisited at a later date. -- Angus
Re: LyX on Windows
Angus Leeming [EMAIL PROTECTED] writes: | Ruurd Reitsma wrote: Hi Angus, The irritating thing with Windows is that all stdout messages get lost somewhere when using the GUI subsystem. You would have to add additional code to handle all debugging messages. Now that isn´t that hard to do, but another issue was that some shell script stopped working when linking to the gui subsystem. I cannot remember what worked and what didn´t. Maybe the mingw runtime does a better job, but you´ll have to try that out. Anyway, at that time I´ve looked around, but there didn´t seem to be a more elegant solution. The console closing code is not that sophisticated, so that could be improved. BTW The WinMain stuff get´s added by qtmain automatically. | Reading this thread | http://lists.trolltech.com/qt-interest/2001-11/thread00727-0.html | A Windows application does not have any stdout/stderr by default, all | output vanishes without a trace for you.But if you want to, you can create | a console with AllocConsole() and attach that to stdout/stderr ... | Add following lines into main : | #ifdef WIN32 | AllocConsole(); | freopen(conin$, r, stdin); | freopen(conout$, w, stdout); | freopen(conout$, w, stderr); | #endif | That suggests that the console could be added when lyxerr is invoked. | Anyway, I think that I'll just add your code as-is for now with some | commentary describing the alternative. I feel we are beginning on a slippery slope now... ok to support windows if only minimal changes are needed... but now we see more and more changes needed to support this. I am not sure that I am really happy about this progress -- Lgb
Re: LyX on Windows
Lars Gullik Bjønnes wrote: I feel we are beginning on a slippery slope now... ok to support windows if only minimal changes are needed... but now we see more and more changes needed to support this. I am not sure that I am really happy about this progress Let me try and reassure you then. If you look at the code base, you'll find minimal evidence of any pollution. Why don you think I've taken a month to gradually merge Ruurd's changes into the repository rather than just commit the thing in its original state? $ egrep -r '_WIN32|WINDOWS' src shows that the only files containing even a sniff of Windows-specific stuff are: src/config.h.in src/support/filename.C src/support/os.C src/support/os_win32.C src/support/package.C.in That doesn't look too terrible, does it? The same is true of all the changes yet to come. Everything can be encapsulated so that the code base suffers minimally. So, what else needs to be done before Ruurd's patch can be declared as fully-merged? 1. This code we've been discussing about Windows notion of a console or a gui app. 2. The signal-handling code needs to be considered carefully as we have a reputation to consider; LyX doesn't eat your data ;-) I plan to write some little test codes to try out the MinGW implementation of these. See also my message a little later in this thread http://article.gmane.org/gmane.editors.lyx.devel:40725 3. The child process code. My general plan is to first refactor the existing code a little so that we present a common interface to the rest of LyX. Again, that's not slippery slope territory. Thereafter, we will need some Windows specific code, but that will be hidden away behind this interface. At that point, we can say that all is done. Fin. Finito. Ferdig. -- Angus
Re: LyX on Windows
Angus Leeming [EMAIL PROTECTED] writes: | Lars Gullik Bjønnes wrote: I feel we are beginning on a slippery slope now... ok to support windows if only minimal changes are needed... but now we see more and more changes needed to support this. I am not sure that I am really happy about this progress | Let me try and reassure you then. If you look at the code base, you'll | find minimal evidence of any pollution. Why don you think I've taken a | month to gradually merge Ruurd's changes into the repository rather than | just commit the thing in its original state? So far it has been stuff that makes LyX more portable. A good thing. But now we are also beginning to much with the build system. As much as I'd like Asger to work on LyX again I am not sure these changes (depends completely how they evolve) are worth it in the long run. I just wanted to flag my growing concerns. -- Lgb
Re: Paragraph indendation
Juergen Spitzmueller wrote: Alfredo Braunstein wrote: Paragraph::ownerCode() seems to refer to the insettext owner, not to the tabular owner and this explains why we cannot currently distinguish between normal text and text in tabulars. Ah, I suspected something like this. Is it possible that this lack of distinguishing is also responsible for some other display bugs (e.g. that the cell's pwidth isn't displayed)? Probably... is this already on bugzilla? I cannot work on this until I get a house adsl (hopefully in some weeks), but I can try to give some other puny advice every now and then ;-) To be honest, I'd prefer if Andr or you could take this and do it proper (not because I'm lazy, I just haven't my hands deep enough in it). Fair enough. One of my next goals is to try to get rid of all back pointers, so this would be part of it anyways. For now, good luck for your house hunting. Thanks! (almost done) Alfredo
Re: LyX on Windows
Lars Gullik Bjønnes wrote: I just wanted to flag my growing concerns. Frankly, I consider this FUD. Complain when you see something you disagree with. Do not complain in advance about what you fear might happen. Regards, Asger
Re: LyX on Windows
Asger Ottar Alstrup [EMAIL PROTECTED] writes: | Lars Gullik Bjønnes wrote: I just wanted to flag my growing concerns. | Frankly, I consider this FUD. Complain when you see something you | disagree with. Do not complain in advance about what you fear might | happen. Well then I am full of FUD, and as we have seen if you don't speak up before something happens... after the fact it is too late... And (also) frankly I am not at all alleviated by having my concerns called FUD. My fuddy feellings just increased instead. One thing I do disagree with is having several ways of building LyX. -- Lgb
Re: LyX on Windows
Lars Gullik Bjønnes wrote: I feel we are beginning on a slippery slope now... ok to support windows if only minimal changes are needed... but now we see more and more changes needed to support this. I am not sure that I am really happy about this progress | Let me try and reassure you then. If you look at the code base, you'll | find minimal evidence of any pollution. Why don you think I've taken a | month to gradually merge Ruurd's changes into the repository rather | than just commit the thing in its original state? So far it has been stuff that makes LyX more portable. A good thing. But now we are also beginning to much with the build system. As I see it, you do not need to worry about this either. Asger is not proposing to muck with the existing build system at all. He's proposing to add an entirely separate one. Moreover, he appears to be talking about adding a maximum of one or two files to the root directory of the repository. Given that the reposititory currently contains 4309 files, I don't think that is any problem at all ;-) As much as I'd like Asger to work on LyX again I am not sure these changes (depends completely how they evolve) are worth it in the long run. My view? We've gone so far to make this bloody thing 'portable'. We should go the extra mile to prove that it actually is portable and not just 'portable'. Otherwise, who are we trying to kid? I just wanted to flag my growing concerns. LOL. Don't worry, Lars, I'm on your side here. (Ok, ok, that might well be something you were worried might happen ;-) -- Angus
Invoking lyx2lyx
There have been a number of mentions on the lyx-users list that the
Windows port of LyX 1.3.5 is unable to run lyx2lyx. That's because Windows
in its braindead-ness doesn't recognize 'lyx2lyx' as a python script (it
doesn't read the first line of the file).
It seems to me that this patch is the minimally-invasive solution:
--- src/buffer.C6 Jan 2005 16:52:08 - 1.601
+++ src/buffer.C17 Jan 2005 14:55:26 -
@@ -619,7 +619,8 @@ bool Buffer::readFile(LyXLex lex, stri
filename));
return false;
}
- string command = LibFileSearch(lyx2lyx, lyx2lyx);
+ string command = string(python ) +
+ LibFileSearch(lyx2lyx, lyx2lyx);
if (command.empty()) {
Alert::error(_(Conversion script not found),
bformat(_(%1$s is from an earlier
Clearly, this hard-codes us to a specific name for the python executable,
but then so does
#! /usr/bin/env python
Any objections to me applying this patch to the 1.4.x tree?
--
Angus
Re: Paragraph indendation
Alfredo Braunstein wrote: Probably... is this already on bugzilla? No. I'll file bugs on all these cases to you. I cannot work on this until I get a house adsl (hopefully in some weeks), but I can try to give some other puny advice every now and then ;-) To be honest, I'd prefer if Andr or you could take this and do it proper (not because I'm lazy, I just haven't my hands deep enough in it). Fair enough. One of my next goals is to try to get rid of all back pointers, so this would be part of it anyways. Good. For now, good luck for your house hunting. Thanks! (almost done) That's good to hear. I hope your current accommodation isn't too buggy. Jrgen
Win version of LyX: Wrong page numberes in ToF and ToT - one more latex-run needed?
Hello, I just experienced following: When exporting to PDF (ALT-f-e-f), the Table of Figures and the Table of Tables may contain wrong page numbers (when they just changed before in my document). I need to start another PDF run for correct page numbers. As I recall from my earlier use of LyX (under Unix), three LaTeX runs where done, but now only two runs are performed. Is that maybe the reason for the wrong numbers? I'm using LyX 1.3.3 and actual MikTeX (but I think I got the same problems on another machine with LyX 1.3.5) Frank
Re: Invoking lyx2lyx
On Monday 17 January 2005 15:04, Angus Leeming wrote: Any objections to me applying this patch to the 1.4.x tree? Not from me. :-) The first line is just to be able to call it from any shell. -- Angus -- José Abílio
Re: Win version of LyX: Wrong page numberes in ToF and ToT - one more latex-run needed?
Steinhauer, Frank (CAM) wrote: Hello, I just experienced following: When exporting to PDF (ALT-f-e-f), the Table of Figures and the Table of Tables may contain wrong page numbers (when they just changed before in my document). I need to start another PDF run for correct page numbers. As I recall from my earlier use of LyX (under Unix), three LaTeX runs where done, but now only two runs are performed. Is that maybe the reason for the wrong numbers? I'm using LyX 1.3.3 and actual MikTeX (but I think I got the same problems on another machine with LyX 1.3.5) Hello, Frank. could you post an example file that has these problems, please. -- Angus
Re: Invoking lyx2lyx
Jose' Matos wrote:
Any objections to me applying this patch to the 1.4.x tree?
Not from me. :-)
Then I'll commit the attached patch and place a similar one in my pending
queue for 1.3.x.
The first line is just to be able to call it from any shell.
Compreendo.
--
AngusIndex: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.2085
diff -u -p -r1.2085 ChangeLog
--- src/ChangeLog 16 Jan 2005 21:01:37 - 1.2085
+++ src/ChangeLog 17 Jan 2005 18:37:29 -
@@ -1,3 +1,8 @@
+2005-01-17 Angus Leeming [EMAIL PROTECTED]
+
+ * buffer.C (readFile): prepend the name of the lyx2lyx script
+ with python . Workaround for a brain-dead Windows.
+
2005-01-16 Angus Leeming [EMAIL PROTECTED]
* lyx_main.[Ch] (init): rewrite code to prepend the CWD to the PATH
Index: src/buffer.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/buffer.C,v
retrieving revision 1.601
diff -u -p -r1.601 buffer.C
--- src/buffer.C 6 Jan 2005 16:52:08 - 1.601
+++ src/buffer.C 17 Jan 2005 18:37:30 -
@@ -619,7 +619,8 @@ bool Buffer::readFile(LyXLex lex, stri
filename));
return false;
}
- string command = LibFileSearch(lyx2lyx, lyx2lyx);
+ string command =
+ python + LibFileSearch(lyx2lyx, lyx2lyx);
if (command.empty()) {
Alert::error(_(Conversion script not found),
bformat(_(%1$s is from an earlier
Index: src/frontends/controllers/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/ChangeLog,v
retrieving revision 1.465
diff -u -p -r1.465 ChangeLog
--- src/frontends/controllers/ChangeLog 11 Jan 2005 13:22:41 - 1.465
+++ src/frontends/controllers/ChangeLog 17 Jan 2005 18:37:33 -
@@ -1,3 +1,8 @@
+2005-01-17 Angus Leeming [EMAIL PROTECTED]
+
+ * tex_helpers.C (rescanTexStyles): prepend the name of the
+ TeXFiles script with sh . Workaround for a brain-dead Windows.
+
2005-01-10 Jean-Marc Lasgouttes [EMAIL PROTECTED]
* ControlErrorList.C (goTo): fix the commented-out code (bug
Index: src/frontends/controllers/tex_helpers.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/tex_helpers.C,v
retrieving revision 1.23
diff -u -p -r1.23 tex_helpers.C
--- src/frontends/controllers/tex_helpers.C 10 Jan 2005 19:17:40 - 1.23
+++ src/frontends/controllers/tex_helpers.C 17 Jan 2005 18:37:33 -
@@ -50,7 +50,7 @@ void rescanTexStyles()
Path p(package().user_support());
Systemcall one;
one.startscript(Systemcall::Wait,
- LibFileSearch(scripts, TeXFiles.sh));
+ sh + LibFileSearch(scripts, TeXFiles.sh));
}
Re: LyX on Windows
Angus Leeming wrote: As I see it, you do not need to worry about this either. Angus, even though it's not Friday yet, I think I am going to have to curse you up and down now until you can't see what is up and down anymore. It's for your own good. You see, Lars and I are just starting to heat up to get a real good flame-fest going that might last all up to Friday. It would be like the good old days! But then you come along talking nice soft words and putting all this oil on the waters. Jean-Marc said it: you're a real diplomat, but sometimes a party-spoiler as well. In this case, diplomacy is not what the doctor ordered: On the LyX-devel list, you have to be nice to the *new-comers*. But all the others, you have to scorn and give a hell of a time starting exactly Monday. This state of affairs builds up over the week come Friday, where everybody makes up, and have a beer. That's just the way it is, and the way it has always been. It's like heaven and hell. You can't have one without the other. So, with that basic lesson in LyX manners out of the way, will you let us resume the flame-fest as common courtesy calls for? Cheers, Asger
Re: LyX on Windows
Asger Ottar Alstrup wrote: So, with that basic lesson in LyX manners out of the way, will you let us resume the flame-fest as common courtesy calls for? Sure, you wanker. Happy now? -- Angus
Re: LyX on Windows
Lars Gullik Bjønnes wrote: Well then I am full of FUD, and as we have seen if you don't speak up before something happens... after the fact it is too late... Tell you what: This wanker is going to continue commiting things behind your back that I consider obvious monotoneous progress until you can find an example which you disagree with. And at that point, I guess you have to pull the plug and steal my karma! So, I'll be stretching the obviously correct rule to the limit, but I'll not cross it too much. And (also) frankly I am not at all alleviated by having my concerns called FUD. My fuddy feellings just increased instead. He he, I will keep the pressure up, so you better stay alert. One thing I do disagree with is having several ways of building LyX. So far, you should not loose sleep. I still have 275 errors and 399 warnings to combat. Regards, Asger
Re: LyX on Windows
Angus Leeming wrote: Asger Ottar Alstrup wrote: So, with that basic lesson in LyX manners out of the way, will you let us resume the flame-fest as common courtesy calls for? Sure, you wanker. Happy now? Incidentally, has an experienced Windows hand like yourself not got any suggestions for what I should do to handle SIGINT on Windows? I really don't think that we should use the existing code unchanged and define a signal handler for it if Windows is going to spawn a new thread to handle the Ctrl+C interupt. See my mail describing the problem elsewhere in this thread. LyX ain't in any fit state to be multi-threaded just yet and I've never written any Windows Messages code before... -- Angus
Invoking reLyX
My build dir/lib/lyxrc.defaults file contains the entry: \converter latex lyx reLyX-1.4.0cvs -f $$i This converter has never worked, not even on *nix, if I don't go to the bother to install lyx because the script is located in the build support/lib/reLyX directory and LyX can't find it. Of course, when lyx is installed, this script and noweb2lyx are both copied to the lyx binary dir. Thereafter, invoking them works because they're in the PATH. This strategy will fail to work on Windows for the same reason that invoking lyx2lyx didn't work. Windows is unable to work out that reLyX is a perl script and act accordingly. I'd like to suggest three changes: 1. Leave reLyX and noweb2lyx either in the build support/reLyX directory or in the system support/reLyX directory depending on whether we're using an uninstalled or installed version of LyX. 2. Change the meaning of the (1.4.x) $$s placeholder from its current meaning of support dir/scripts to simply support dir. 3. Change the definition of the various scripts defined as converters in the lyxrc.defaults to: -\converter latex lyx reLyX-1.4.0cvs -f $$i +\converter latex lyx perl $$s/reLyX/reLyX-1.4.0cvs -f $$i Similarly, the definition of all the converters that are located in the scripts sub-directory will be changed in similar fashion to: -\converter fig pstex sh $$s/fig2pstex.sh $$i $$o +\converter fig pstex sh $$s/scripts/fig2pstex.sh $$i $$o Not only will this mean that things will work under Windows, but it will also mean that they'll work on *nix when we're using an uninstalled version of LyX. Thoughts? (I don't think that it matters that reLyX is slated to be retired. The same argument still holds true for noweb2lyx.) -- Angus
Re: QT 3/Win Free
Hi Angus, It's great to see that you're actually using this thing! Do you see the drawing problems that I describe in my Just for fun mail too? No, the splash screen looks nice and beautiful here, even after opening and closing some document. I am using the very latest MinGW (they have released a new api some days ago), and the very latest sources of Qt 3/Win Free and LyX 1.3.X. However, I can confirm that the disabled menus are not visible at all. I don't consider this an error - it's just a different way of representation (which BTW makes it easier to detect bugs in LyX - I noticed that if you hightlight a word by double-clicking, it is not possible to cut the word afterwards) The next tasks on my todo list are the inclusion of apell and aiksaurus. Unfortunately, I am not able to compile both tools out of the box with MinGW. And then, of course, there is the Qt DottedLine bug left... Angus, you should also have a look at the console output of the configure script. When creating ./doc/LaTeXConfig.lyx, I get the following error message: sed: file chkconfig.sed line 1: Unknown option to 's' Doesn't look like a critical bug but maybe you have an idea what is going wrong. Have a nice evening, Michael
Re: QT 3/Win Free
Michael Schmitt wrote: It's great to see that you're actually using this thing! Do you see the drawing problems that I describe in my Just for fun mail too? No, the splash screen looks nice and beautiful here, even after opening and closing some document. I am using the very latest MinGW (they have released a new api some days ago), and the very latest sources of Qt 3/Win Free and LyX 1.3.X. Strange. Me too. Angus, you should also have a look at the console output of the configure script. When creating ./doc/LaTeXConfig.lyx, I get the following error message: sed: file chkconfig.sed line 1: Unknown option to 's' Doesn't look like a critical bug but maybe you have an idea what is going wrong. You've got an old and buggy version of sed. The lyx-users list is full of reports that all come down to this. Upgrade to the latest and greatest gnu sed and all will be well. http://sed.sourceforge.net/ -- Angus
Re: Just for fun
Angus Leeming [EMAIL PROTECTED] writes: I attach two (small) screen shots of LyX when it starts up under both linux and windows. The windows version uses the Qt Free/Win32 port. About the splash screen: Any chance to blame it on the video card/driver? Looks like a broken BITBLT operation... What happens if you start the LyX binary on another Windose machine? /Andreas
Re: Just for fun
Andreas Vox wrote: About the splash screen: Any chance to blame it on the video card/driver? Looks like a broken BITBLT operation... Nope. Everything else is just find and dandy thanks. What happens if you start the LyX binary on another Windose machine? -- Angus
Re: Just for fun
Andreas Vox [EMAIL PROTECTED] writes: Angus Leeming leeming at ... writes: I attach two (small) screen shots of LyX when it starts up under both linux and windows. The windows version uses the Qt Free/Win32 port. About the splash screen: Any chance to blame it on the video card/driver? Looks like a broken BITBLT operation... On second thought it looks as if some bytes in the graphic file are skipped. Is it a P6 *.ppm file on 1.3.6 also? (the 1.4.0 banner has this format) Is it checked in as binary file into CVS? /Andreas
JMarc's configure changes
Jean-Marc try this: $ ./configure --prefix=$HOME/lyx-installed $ make $ make install All will appear to be fine. Now look in lyx-installed/share/lyx. There's no reLyX directory. Dunno if there's meant to be one --- guess there is because... ... in build dir/lib/reLyX See the ' directory? (That's the apostrophe directory). ls lyx/devel/build/lib/reLyX/\'/home/angus/lyx-installed\'/share/lyx-1.4.0cvs/reLyX/ BasicLyX.pm CleanTeX.pm ReadCommands.pm reLyXmain.pl syntax.default BUGS LastLyX.pm README reLyX.pod Text CHANGES MakePreamble.pm RelyxFigure.pm RelyxTable.pm Verbatim.pm Ooops! -- Angus
Re: Just for fun
Andreas Vox wrote: I attach two (small) screen shots of LyX when it starts up under both linux and windows. The windows version uses the Qt Free/Win32 port. About the splash screen: Any chance to blame it on the video card/driver? Looks like a broken BITBLT operation... On second thought it looks as if some bytes in the graphic file are skipped. Is it a P6 *.ppm file on 1.3.6 also? (the 1.4.0 banner has this format) Is it checked in as binary file into CVS? Oh, koo-ell! Here it is in .jpg format (370kB - 30kB) -- Angusattachment: banner.jpg
Re: Just for fun
Angus Leeming [EMAIL PROTECTED] writes: Oh, koo-ell! Here it is in .jpg format (370kB - 30kB) The attached file shows the same rainbowy colors as the screenshot (PowerBook, tested with Safari, Preview and ImageMagick) Maybe the conversion didn't work? Anyway, why don't you use PNG or GIF? (lossless compression) /Andreas
Re: Just for fun
Andreas Vox wrote: Oh, koo-ell! Here it is in .jpg format (370kB - 30kB) The attached file shows the same rainbowy colors as the screenshot (PowerBook, tested with Safari, Preview and ImageMagick) That's right. This is the weird and wonderful file that I have in my Windows repository. I guess that we'll have to get Lars to tell cvs that lib/images/banner.ppm is a binary file, both in the 1.3.x and 1.4.x trees. Lars? Maybe the conversion didn't work? Anyway, why don't you use PNG or GIF? (lossless compression) shrug I just wanted to send something that wouldn't eat up everybody's bandwidth /shrug Of course, if the XForms frontend were retired, then we could store all these images as PNG in the first place... -- Angus
Re: solution for LyXWin's math font problems
I wrote yesterday: So we should better use the ttf's from Bakoma. There are currently some small errors int the ttf's. Ekkehardt send me now some corrected ttf's where all problems are fixed. I uploaded all necessary fonts for LyxWin to http://fkurth.de/uwest/LyX/LyXWinMathFonts.rar Please test them. thanks and regards Uwe
Re: Reworking of Kayvan's cygwin_path_fix patch
Your reworking has completely broken LyX on cygwin for me.
I can no longer run any external programs.
Even running Tools-Reconfigure comes back immediately with no effect.
Help!
---Kayvan
On Mon, Jan 17, 2005 at 12:05:06PM +, Angus Leeming wrote:
Angus Leeming wrote:
Kayvan A. Sylvan wrote:
I am able to run it from the build directory via src/lyx. and was
able to confirm that the patch works as expected. Thank you!
Good. Then I'll commit that.
Now, we have to fix this new bug (can not determine the path to the
LyX binary).
H. So lyx is in your path, right? Can you investigate? The routine
that is failing is src/support/package.C.in's abs_path_from_binary_name
(get_binary_path, actually).
Kayvan, I just committed a little patch to this piece of code. It fixes a
clear bug but I wonder if it resolves your problem too?
@@ -388,11 +391,10 @@ string const get_binary_path(string cons
std::vectorstring::const_iterator it = path.begin();
std::vectorstring::const_iterator const end = path.end();
for (; it != end; ++it) {
-if (!os::is_absolute_path(*it))
-// Someone is playing silly buggers.
-continue;
-
-string const exe_path = AddName(*it, exe_name);
+// This will do nothing if *it is already absolute.
+string const exe_dir = MakeAbsPath(*it);
+
+string const exe_path = AddName(exe_dir, exe_name);
if (FileInfo(exe_path, true).isOK())
return exe_path;
}
--
Angus
--
Kayvan A. Sylvan | Proud husband of | Father to my kids:
Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89)
http://sylvan.com/~kayvan | crown of her husband | Robin Gregory (2/28/92)
Re: Reworking of Kayvan's cygwin_path_fix patch
On Mon, Jan 17, 2005 at 08:17:42PM -0800, Kayvan A. Sylvan wrote: Your reworking has completely broken LyX on cygwin for me. I can no longer run any external programs. Even running Tools-Reconfigure comes back immediately with no effect. Help! To verify, I went back to 01/16/2005 and everything that is now botched up works correctly (except for the Unable to determine the path [...]). I can probably spend a bit of time isolating exactly which change broke lyx on Cygwin, after I have finished some work for my employer and finished an assignment for school. Best regards, ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | crown of her husband | Robin Gregory (2/28/92)
Re: Invoking reLyX
On Monday 17 January 2005 19:37, Angus Leeming wrote: ... Not only will this mean that things will work under Windows, but it will also mean that they'll work on *nix when we're using an uninstalled version of LyX. Thoughts? (I don't think that it matters that reLyX is slated to be retired. The same argument still holds true for noweb2lyx.) Go for it. I noticed this long time ago but never cared enough to make the change. :-) -- José Abílio
Re: lyx140cvs, qt: table dialogue window
Angus Leeming wrote: > Hmmm. But that can be turned off (and is by default). I think that the > toolbar should provide shortcuts to things that are also possible in the > dialogs, no? Or in the menu... Jürgen
Re: lyx140cvs, qt: table dialogue window
Juergen Spitzmueller wrote: >> Hmmm. But that can be turned off (and is by default). I think that the >> toolbar should provide shortcuts to things that are also possible in the >> dialogs, no? > > Or in the menu... Good point. I'll withdraw my objection then. -- Angus
Re: QT 3/Win Free
[EMAIL PROTECTED] wrote:
> For drawing table cell boundaries, LyX sets the style of a QPen in the
> following way:
>
> QPen pen = ...;
> pen.setColor("LightSteelBlue");
> pen.setStyle(QPen:DotLine);
> pen.setWidth(0);
>
> As a result, a thin blue dotted line should be drawn when using this
> pen. But instead, a black (sometimes red) solid line is draw (the color
> may depend on former drawing operations).
>
> If you can spare some time, you might have a look at the corresponding
> Qt code. Unfortunately, I haven't been able to create a test case yet
> due to time constraints. I can try to create one this evening if that
> helps.
Hi, Michael.
It's great to see that you're actually using this thing! Do you see the
drawing problems that I describe in my "Just for fun" mail too?
--
Angus
Re: [rework docs] reasons, plans, questions
John Spray wrote: > On Sun, 2005-01-09 at 20:14 +0100, Andre Poenitz wrote: >> Depends on the release date. If that's 'soonish', probably not, >> otherwise i depends on th GTK frontend to catch up... > > I keep offering the GTK frontend cookies and sweets to try and get it to > catch up, but it just sits there obstinately waiting for me to work on > it. lyx-gtk is pretty broken atm, actually, one can't even scroll > around in a document due to some changes somewhere along the line in lyx > proper: I cannot say when since I was not paying attention at the time. I know what this it: the gtk frontend fires the "scrolling" signal when setting the scrollbar parameters from inside LyX: the kernel expects that setting the parameters only changes the scrollbar visually (and invokes no scrolling). This results in an infinite loop. There was a similar problem in the qt frontend, that was solved by deactivating the signal somewhere IIRC. Unfortunately I cannot look at the problem more closely ATM. OTOH the requirement to have bleeding edge gtkmm libs just to be able to compile it doesn't make the work easy for us to keep up... > I'm hoping that my sense of humour will improve when I've had some > sleep. To quote Lars: "Blame it on the Pub"[1]. ;-) Alfredo
Re: Creating a std::string from unsigned char[4097] ?
John Weiss <[EMAIL PROTECTED]> writes: >> PATH_MAX does not seem like a good idea. (and then you must at least >> zero out application_support first.) > | Umm, Lars, the constructor for POD arrays *always* zeros out the | elements, remember? (It's in the Standard; I know. I spent the | summer studying the bloody thing in prep for interviews. Fat | load-o-good that did me...) No. Only if it is static or global. Another thing for your interviews I guess :-) -- Lgb
External material subfigure
Angus, I notice that subfigure is not supported yet in the external material inset. It shouldn't be very hard to add, the way it looks now. One very simple way for doing this is the following: 1) Define, in a layout file widely included (e.g., stdlayouts.inc) a layout "subfigure" of latextype command and latexname subfigure. 2) Give this layout an optional argument (the subcaption text to be) 3) Include as the main content of the paragraph the "external material" inset. Like this in ascii art: [Figure float] +---+ |(subfigure para style) [OptArg] [Xfig: myfigure 1] | | [The subfigure 1 caption] | |(subfigure para style) [OptArg] [Xfig: myfigure 2] | | [The subfigure 2 caption] | | | |(caption para style) The figure main caption | +---+ This is a little cludgy but very straightforward. I foresee a problem with the "caption hack" though in text.C :-( Which we should perhaps re-think. What do you think? -- Martin Vermeer <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: LyX on Windows
Hi, I managed to checkout qt3 win32 free and lyx-devel. I even managed to compile qt-3, although I ran out of disk space, and what not. Now, I'm starting to build a VS.NET 7.1 project file for LyX, but I need all the generated files from configure on Windows from one of you guys, since I refuse to install cygwin or mingw. For starters, could someone hand me a config.h file? Also, if someone could provide a rough list of which source files (i.e. which directories) needs to be compiled into the LyX proper in the Qt edition, that would be helpfulp. Thanks, Asger
Re: [rework docs] reasons, plans, questions
On Mon, 2005-01-17 at 10:08 +0100, Alfredo Braunstein wrote: > I know what this it: the gtk frontend fires the "scrolling" signal when > setting the scrollbar parameters from inside LyX: the kernel expects that > setting the parameters only changes the scrollbar visually (and invokes no > scrolling). This results in an infinite loop. Great, I figured it was something like this but hadn't gotten around to looking. There is now a stickynote on my desktop about this. > > OTOH the requirement to have bleeding edge gtkmm libs just to be able to > compile it doesn't make the work easy for us to keep up... > At the risk of being a GNOME-enthusiast-asshole, I have bleeding edge gtkmm libs, and they're not what LyX depends on: there are widgets in 2.5.x that I'd like to use in LyX but I'm holding back precisely for the benefit of those who don't have the degree of love for compiling GTK+ from CVS that I do ;-) John
Re: LyX on Windows
Asger Ottar Alstrup wrote: > I managed to checkout qt3 win32 free and lyx-devel. Note that I've only tried to get BRANCH_1_3_X to compile. > I even managed to > compile qt-3, although I ran out of disk space, and what not. > > Now, I'm starting to build a VS.NET 7.1 project file for LyX, but I need > all the generated files from configure on Windows from one of you guys, > since I refuse to install cygwin or mingw. When it comes to *running* lyx you'll still need a decent shell and associated utilities to run the lib/configure scipt. > For starters, could someone hand me a config.h file? Mine are attached, both for 1.3.x and for 1.4.x. > Also, if someone could provide a rough list of which source files (i.e. > which directories) needs to be compiled into the LyX proper in the Qt > edition, that would be helpfulp. You need the qt3.3.3.dll (or some such name). Is that not the end result of compiling the src/kernel directories? You'll also need the uic and moc executables. -- Angus config_13x.h.bz2 Description: BZip2 compressed data config_14x.h.bz2 Description: BZip2 compressed data
Re: External material subfigure
Martin Vermeer wrote: > Angus, > > I notice that subfigure is not supported yet in the external material > inset. It never will. > It shouldn't be very hard to add, the way it looks now. We need a new inset which shouldn't be very hard to write. InsetSubfigure. > One very simple way for doing this is the following: > > 1) Define, in a layout file widely included (e.g., stdlayouts.inc) a > layout "subfigure" of latextype command and latexname subfigure. > > 2) Give this layout an optional argument (the subcaption text to be) > > 3) Include as the main content of the paragraph the "external material" > inset. > > Like this in ascii art: > > [Figure float] > +---+ > |(subfigure para style) [OptArg] [Xfig: myfigure 1] | > | [The subfigure 1 caption] | > |(subfigure para style) [OptArg] [Xfig: myfigure 2] | > | [The subfigure 2 caption] | > | | > |(caption para style) The figure main caption | > +---+ > > This is a little cludgy but very straightforward. I foresee a problem > with the "caption hack" though in text.C :-( Which we should perhaps > re-think. > > What do you think? Sounds like a plan to me, but I tend to be less ruthless about hacks than some ;-) -- Angus
Re: LyX on Windows
Angus Leeming wrote: Note that I've only tried to get BRANCH_1_3_X to compile. OK, I'm working on the main branch. When it comes to *running* lyx you'll still need a decent shell and associated utilities to run the lib/configure scipt. That is something to address then for a native Windows port to work out. I'd like to produce a native LyX binary with as few unix dependencies as possible. Further out, I'd even like to kick out LaTeX, and put some other backend in instead to reduce the footprint. Mine are attached, both for 1.3.x and for 1.4.x. Thanks, that gets me down to about 1500 remaining errors and warnings ;-) You need the qt3.3.3.dll (or some such name). Is that not the end result of compiling the src/kernel directories? There is no src/kernel directory, but I have a qt-mt3.dll from the Qt compile. > You'll also need the uic and moc executables. I have those as part of the Qt compile. What is the compilation procedure for those Qt .ui files? I get a bunch of errors like: QERTDialog.C c:\lyx\lyx-devel\src\frontends\qt2\QERTDialog.h(15) : fatal error C1083: Cannot open include file: 'ui/QERTDialogBase.h': No such file or directory so I guess those files are generated by some Qt utility. My plan is this: - get everything to compile. - get everything to link. - get it to start-up (without crash). - get it to run without all those unix dependencies. The main barrier for me is disk space... I keep running out, and since it's a laptop, it's a bit problematic for me to add more space. I'll have to get an external firewire or usb-2 disc I suppose. Regards, Asger
[PATCH 13x, 14x] package and relative paths from PATH
The attached patches enable the lyx executable to be found from the PATH
environment variable if it expands to elements with relative paths.
Confirmed as working and fixes a clear bug so I'm committing to both trees
now.
--
AngusIndex: src/support/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/ChangeLog,v
retrieving revision 1.149.2.27
diff -u -p -r1.149.2.27 ChangeLog
--- src/support/ChangeLog 13 Jan 2005 10:09:46 - 1.149.2.27
+++ src/support/ChangeLog 17 Jan 2005 11:42:48 -
@@ -1,3 +1,8 @@
+2005-01-17 Angus Leeming <[EMAIL PROTECTED]>
+
+ * package.C (get_binary_path): convert relative paths stored
+ in the PATH environment variable to absolute ones.
+
2005-01-12 Angus Leeming <[EMAIL PROTECTED]>
* filetools.[Ch] (setEnvPath): new function to create a PATH-style
Index: src/support/package.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/Attic/package.C,v
retrieving revision 1.1.2.2
diff -u -p -r1.1.2.2 package.C
--- src/support/package.C 12 Jan 2005 23:43:38 - 1.1.2.2
+++ src/support/package.C 17 Jan 2005 11:42:49 -
@@ -145,7 +145,7 @@ Package::Package(string const & command_
<< "\tdocument_dir " << document_dir() << '\n'
<< "\ttemp_dir " << temp_dir() << '\n'
<< "\thome_dir " << home_dir() << '\n'
- << "<\\package>\n" << std::endl;
+ << "\n" << std::endl;
}
@@ -351,11 +351,10 @@ string const get_binary_path(string cons
std::vector::const_iterator it = path.begin();
std::vector::const_iterator const end = path.end();
for (; it != end; ++it) {
- if (!os::is_absolute_path(*it))
- // Someone is playing silly buggers.
- continue;
+ // This will do nothing if *it is already absolute.
+ string const exe_dir = MakeAbsPath(*it);
- string const exe_path = AddName(*it, exe_name);
+ string const exe_path = AddName(exe_dir, exe_name);
if (lyx::FileInfo(exe_path, true).isOK())
return exe_path;
}
Index: src/support/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/ChangeLog,v
retrieving revision 1.307
diff -u -p -r1.307 ChangeLog
--- src/support/ChangeLog 16 Jan 2005 21:01:41 - 1.307
+++ src/support/ChangeLog 17 Jan 2005 11:34:07 -
@@ -1,3 +1,8 @@
+2005-01-17 Angus Leeming <[EMAIL PROTECTED]>
+
+ * package.C.in (get_binary_path): convert relative paths stored
+ in the PATH environment variable to absolute ones.
+
2005-01-16 Angus Leeming <[EMAIL PROTECTED]>
* filetools.[Ch] (prependEnvPath): prepend a list of paths to
Index: src/support/package.C.in
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/package.C.in,v
retrieving revision 1.4
diff -u -p -r1.4 package.C.in
--- src/support/package.C.in 13 Jan 2005 16:50:44 - 1.4
+++ src/support/package.C.in 17 Jan 2005 11:34:08 -
@@ -80,6 +80,9 @@ void init_package(string const & command
Package const & package()
{
+ // Commented out because package().locale_dir() can be called
+ // from the message translation code in messages.C before
+ // init_package() is called. Lars is on the case...
// BOOST_ASSERT(initialised_);
return package_;
}
@@ -150,7 +153,7 @@ Package::Package(string const & command_
<< "\tdocument_dir " << document_dir() << '\n'
<< "\ttemp_dir " << temp_dir() << '\n'
<< "\thome_dir " << home_dir() << '\n'
- << "<\\package>\n" << std::endl;
+ << "\n" << std::endl;
}
@@ -388,11 +391,10 @@ string const get_binary_path(string cons
std::vector::const_iterator it = path.begin();
std::vector::const_iterator const end = path.end();
for (; it != end; ++it) {
- if (!os::is_absolute_path(*it))
- // Someone is playing silly buggers.
- continue;
+ // This will do nothing if *it is already absolute.
+ string const exe_dir = MakeAbsPath(*it);
- string const exe_path = AddName(*it, exe_name);
+ string const exe_path = AddName(exe_dir, exe_name);
if (FileInfo(exe_path, true).isOK())
return exe_path;
}
Paragraph indendation
I am trying to fix the broken paragraph indendation (i.e., its representation on screen). So far, I have spotted the line to blame. It's the check for InsetBase::TEXT_CODE in the following snippet (text.C, 598ff): if (pos = 0 [...] // in charstyles, tabulars and ert paragraphs are never indented! && (par.ownerCode() != InsetBase::TEXT_CODE && par.ownerCode() != InsetBase::ERT_CODE && par.ownerCode() != InsetBase::CHARSTYLE_CODE) InsetBase::TEXT_CODE should avoid indedations in tabulars, but it is also true in normal text. I have replaced that with InsetBase::TABULAR_CODE, but this doesn't work either (i.e. pars in tabulars are indented). Any idea? Jürgen
Re: External material subfigure
On Mon, 2005-01-17 at 12:14, Angus Leeming wrote: > Martin Vermeer wrote: > > > Angus, > > > > I notice that subfigure is not supported yet in the external material > > inset. > > It never will. > > > It shouldn't be very hard to add, the way it looks now. > > We need a new inset which shouldn't be very hard to write. InsetSubfigure. Doable, yes. 1.5. > > One very simple way for doing this is the following: > Sounds like a plan to me, but I tend to be less ruthless about hacks than > some ;-) Unfortunately this works only as long as you don't want to put subfigures side by side... inevitable consequence of making subfigure a paragraph. A well, ERT works for me now. - Martin signature.asc Description: This is a digitally signed message part
Re: LyX on Windows
Asger Ottar Alstrup <[EMAIL PROTECTED]> writes: | I have those as part of the Qt compile. > | What is the compilation procedure for those Qt .ui files? That is in the makefiles... If you want to do this without the use of automake/autoconf: Good Luck. But please do not clutter the directories with .proj files. -- Lgb
Re: LyX on Windows
Asger Ottar Alstrup wrote: > That is something to address then for a native Windows port to work out. > I'd like to produce a native LyX binary with as few unix dependencies as > possible. I think that this is a very plausible goal. The only big task will be to rewrite lib/configure as a python script. > Further out, I'd even like to kick out LaTeX, and put some > other backend in instead to reduce the footprint. Note that I'm running lyx 1.3.x on windows without any LaTeX installation at all. I can't generate printable output but I can edit the .lyx files. >> You need the qt3.3.3.dll (or some such name). Is that not the end result >> of compiling the src/kernel directories? > > There is no src/kernel directory, but I have a qt-mt3.dll from the Qt > compile. I thought you were talking about which bits of the Qt source were needed by LyX? > What is the compilation procedure for those Qt .ui files? See /src/frontend/qt2/ui/Makefile.am. It's not very hard to decipher ;-) -- Angus
Re: LyX on Windows
Lars Gullik Bjønnes wrote: | What is the compilation procedure for those Qt .ui files? That is in the makefiles... Does anybody know the exact command line I need to use? If you want to do this without the use of automake/autoconf: Good Luck. But please do not clutter the directories with .proj files. I am making one .sln file, and one .vcproj file for the entire tree. Regards, Asger
Re: Reworking of Kayvan's cygwin_path_fix patch
Angus Leeming wrote:
> Kayvan A. Sylvan wrote:
>> I am able to run it from the build directory via "src/lyx". and was
>> able to confirm that the patch works as expected. Thank you!
>
> Good. Then I'll commit that.
>
>> Now, we have to fix this new bug (can not determine the path to the
>> LyX binary).
>
> H. So "lyx" is in your path, right? Can you investigate? The routine
> that is failing is src/support/package.C.in's abs_path_from_binary_name
> (get_binary_path, actually).
Kayvan, I just committed a little patch to this piece of code. It fixes a
clear bug but I wonder if it resolves your problem too?
@@ -388,11 +391,10 @@ string const get_binary_path(string cons
std::vector::const_iterator it = path.begin();
std::vector::const_iterator const end = path.end();
for (; it != end; ++it) {
-if (!os::is_absolute_path(*it))
-// Someone is playing silly buggers.
-continue;
-
-string const exe_path = AddName(*it, exe_name);
+// This will do nothing if *it is already absolute.
+string const exe_dir = MakeAbsPath(*it);
+
+string const exe_path = AddName(exe_dir, exe_name);
if (FileInfo(exe_path, true).isOK())
return exe_path;
}
--
Angus
Re: LyX on Windows
Asger Ottar Alstrup <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: >> | What is the compilation procedure for those Qt .ui files? >> That is in the makefiles... > | Does anybody know the exact command line I need to use? > >> If you want to do this without the use of automake/autoconf: Good >> Luck. But please do not clutter the directories with .proj files. > | I am making one .sln file, and one .vcproj file for the entire tree. > | Regards, | Asger > UICFLAGS=-tr qt_ %.h: %.ui $(UIC) $(UICFLAGS) $< -o $@ %.C: %.h %.ui $(PCH_FILE) $(UIC) $(UICFLAGS) -impl `echo $^ | sed 's/pch.h.gch//'` -o $@ the .h file: uic -tr qt_ foo.ui -o foo.h the .C file: uic -tr qt_ foo.ui -impl foo.h foo.ui -o foo.C -- Lgb
Re: Paragraph indendation
Juergen Spitzmueller wrote: > I am trying to fix the broken paragraph indendation (i.e., its > representation on screen). So far, I have spotted the line to blame. It's > the check for InsetBase::TEXT_CODE in the following snippet (text.C, > 598ff): > > if (pos = 0 >[...] > // in charstyles, tabulars and ert paragraphs are never indented! > && (par.ownerCode() != InsetBase::TEXT_CODE > && par.ownerCode() != InsetBase::ERT_CODE > && par.ownerCode() != InsetBase::CHARSTYLE_CODE) > > InsetBase::TEXT_CODE should avoid indedations in tabulars, but it is also > true in normal text. I have replaced that with InsetBase::TABULAR_CODE, > but this doesn't work either (i.e. pars in tabulars are indented). > > Any idea? Paragraph::ownerCode() seems to refer to the insettext owner, not to the tabular owner and this explains why we cannot currently distinguish between normal text and text in tabulars. I think (but almost without reading the code) that The Correct Fix (TM) is to - make leftMargin receive a 1) DocIterator const & or even a 2) (pit, pos, InsetBase::InsetCode) instead of a (pit, pos) and - 1) look in the stack of insets whatever it needs to get the correct margin (in this case, it seems it only needs the topmost inset, which is indeed a tabular) or 2) just use the InsetCode provided. Eliminating Paragraph::ownerCode() would even eliminate one more acess to inset_owner (and there are only a few remaining)... I don't know if leftMargins callers have this information available though. I cannot work on this until I get a house & adsl (hopefully in some weeks), but I can try to give some other puny advice every now and then ;-) HTH, Alfredo
Re: LyX on Windows
Asger Ottar Alstrup wrote: > My plan is this: > - get everything to compile. > - get everything to link. > - get it to start-up (without crash). > - get it to run without all those unix dependencies. My immediate targets are * to address the question that started this thread --- do you have any insights you'd care to share? * the signal handling code in lyx_main.C. I'm aware that the non-existence of SIGHUP under Windows isn't an issue. I also understand from Microsoft's "UNIX Application Migration Guide" http://msdn.microsoft.com/library/en-us/dnucmg/html/UCMGch09.asp?frame=true#ucmgch09_topic3 Equivalent URL: http://tinyurl.com/3pbpp that Windows' signal implentation supports all of the signals that we're interested in: = Table 3. Windows signals SIGFPEFloating-point error SIGINTCTRL+C signal SIGSEGV Illegal storage access SIGTERM Termination request Note When a Ctrl+C interrupt occurs, Win32 operating systems generate a new thread to handle the interrupt. This can cause a single-thread application, such as one ported from UNIX, to become multithreaded, potentially resulting in unexpected behavior. = So, we should probably use Windows Messages instead of SIGINT because LyX definitely isn't a multithreaded beast. Again, have you any thoughts on this? -- Angus
Re: LyX on Windows
Hi Angus,
The irritating thing with Windows is that all stdout messages get lost
somewhere when using the GUI subsystem. You would have to add additional
code to handle all debugging messages. Now that isn´t that hard to do, but
another issue was that some shell script stopped working when linking to the
gui subsystem. I cannot remember what worked and what didn´t. Maybe the
mingw runtime does a better job, but you´ll have to try that out.
Anyway, at that time I´ve looked around, but there didn´t seem to be a more
elegant solution. The console closing code is not that sophisticated, so
that could be improved.
BTW The WinMain stuff get´s added by qtmain automatically.
Ruurd
"Angus Leeming" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Good evening, Ruurd.
>
> I wonder if you could help out a Windows novice --- me?
> My question concerns the way that Windows treats LyX --- as
> a Windows GUI app or as a console one. At the moment, Windows
> believes that LyX is a console app because it has a "main"
> function rather than a "WinMain".
>
> You've added code in os_win32.C's init function to close
> down the console window that Windows helpfully displays
> for us:
>
> void os::init(int /* argc */, char * argv[])
> {
> #ifdef _WIN32
> // Close the console when run (probably)
> // not run from command prompt
> char WindowTitle[1024];
> HWND hwndFound;
> GetConsoleTitle(WindowTitle,1024);
> if ((strcmp(WindowTitle, argv[0]) == 0) ||
> (strcmp(WindowTitle,"LyX") == 0)) {
> // format a "unique" newWindowTitle
> wsprintf(WindowTitle,"%d/%d",
> GetTickCount(),
> GetCurrentProcessId());
> // change current window title
> SetConsoleTitle(WindowTitle);
> // ensure window title has been updated
> Sleep(40);
> // look for newWindowTitle
> hwndFound=FindWindow(NULL, WindowTitle);
> // If found, hide it
> if ( hwndFound != NULL)
> ShowWindow( hwndFound, SW_HIDE);
> }
> #endif
> }
>
>
> Would it not be more elegant to tell Windows that LyX
> is actually a GUI-based app by giving it a WinMain?
>
> The code below compiles fine for me with
> $ g++ -mwindows -o trial trial.C
>
> #if defined (_WIN32)
> # define WIN32_LEAN_AND_MEAN
> # include // for __argc, __argv
> # include // for WinMain
> #endif
>
>
> #if defined (_WIN32)
> int mymain(int argc, char * argv[])
> #else
> int main(int argc, char * argv[])
> #endif
> {
> // LyX's code, unchanged, goes here.
> Sleep(5000);
> return 0;
> }
>
>
> // This will require the "-mwindows" flag when linking with
> // gcc under MinGW.
> // For MSVC, use "/subsystem:windows".
> #if defined (_WIN32)
> int WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
> {
> std::cout << "WinMain" << std::endl;
> return mymain(__argc, __argv);
> }
> #endif
>
> Regards,
> Angus
>
Re: LyX on Windows
Asger, you might want to look into am2msdev ftp://ftp.slac.stanford.edu/users/pfkeb/automake/. This tool will at least provide you with a skeleton. And, I believe the source even includes a project file, so no scary mingw/cygwin tools. There also seems to be an options to add visual studio directives to automake files, that get ignored by the normal autotools. But..I´ve tried what you are trying right now, but became very frustated with this approach;-) Ruurd "Asger Ottar Alstrup" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Hi, > > I managed to checkout qt3 win32 free and lyx-devel. I even managed to > compile qt-3, although I ran out of disk space, and what not. > > Now, I'm starting to build a VS.NET 7.1 project file for LyX, but I need > all the generated files from configure on Windows from one of you guys, > since I refuse to install cygwin or mingw. > > For starters, could someone hand me a config.h file? > > Also, if someone could provide a rough list of which source files (i.e. > which directories) needs to be compiled into the LyX proper in the Qt > edition, that would be helpfulp. > > Thanks, > Asger >
Re: LyX on Windows
Ruurd Reitsma wrote:
> Hi Angus,
>
> The irritating thing with Windows is that all stdout messages get lost
> somewhere when using the GUI subsystem. You would have to add additional
> code to handle all debugging messages. Now that isn´t that hard to do,
> but another issue was that some shell script stopped working when linking
> to the gui subsystem. I cannot remember what worked and what didn´t.
> Maybe the mingw runtime does a better job, but you´ll have to try that
> out.
>
> Anyway, at that time I´ve looked around, but there didn´t seem to be a
> more elegant solution. The console closing code is not that
> sophisticated, so that could be improved.
>
> BTW The WinMain stuff get´s added by qtmain automatically.
Reading this thread
http://lists.trolltech.com/qt-interest/2001-11/thread00727-0.html
A Windows application does not have any stdout/stderr by default, all
output vanishes without a trace for you.But if you want to, you can create
a console with AllocConsole() and attach that to stdout/stderr ...
Add following lines into main :
#ifdef WIN32
AllocConsole();
freopen("conin$", "r", stdin);
freopen("conout$", "w", stdout);
freopen("conout$", "w", stderr);
#endif
That suggests that the console could be added when lyxerr is invoked.
Anyway, I think that I'll just add your code as-is for now with some
commentary describing the alternative.
--
Angus
Re: Paragraph indendation
Alfredo Braunstein wrote: > Paragraph::ownerCode() seems to refer to the insettext owner, not to the > tabular owner and this explains why we cannot currently distinguish between > normal text and text in tabulars. Ah, I suspected something like this. Is it possible that this lack of distinguishing is also responsible for some other display bugs (e.g. that the cell's pwidth isn't displayed)? > I cannot work on this until I get a house & adsl (hopefully in some weeks), > but I can try to give some other puny advice every now and then ;-) To be honest, I'd prefer if André or you could take this and do it proper (not because I'm lazy, I just haven't my hands deep enough in it). For now, good luck for your house hunting. Jürgen
Re: LyX on Windows
"Angus Leeming" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Reading this thread
> http://lists.trolltech.com/qt-interest/2001-11/thread00727-0.html
>
> A Windows application does not have any stdout/stderr by default, all
> output vanishes without a trace for you.But if you want to, you can create
> a console with AllocConsole() and attach that to stdout/stderr ...
>
> Add following lines into main :
> #ifdef WIN32
> AllocConsole();
> freopen("conin$", "r", stdin);
> freopen("conout$", "w", stdout);
> freopen("conout$", "w", stderr);
> #endif
>
Yep, tried this too. But then it turned out that some shell scripts failed,
for mysterious reasons...
Ruurd
Re: LyX on Windows
Ruurd Reitsma wrote:
> "Angus Leeming" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
>> Reading this thread
>> http://lists.trolltech.com/qt-interest/2001-11/thread00727-0.html
>>
>> A Windows application does not have any stdout/stderr by default, all
>> output vanishes without a trace for you.But if you want to, you can
>> create a console with AllocConsole() and attach that to stdout/stderr
>> ...
>>
>> Add following lines into main :
>> #ifdef WIN32
>> AllocConsole();
>> freopen("conin$", "r", stdin);
>> freopen("conout$", "w", stdout);
>> freopen("conout$", "w", stderr);
>> #endif
>>
>
> Yep, tried this too. But then it turned out that some shell scripts
> failed, for mysterious reasons...
So, as said. I'll do it your way and add some notes about why. This is
something that can easily be revisited at a later date.
--
Angus
Re: LyX on Windows
Angus Leeming <[EMAIL PROTECTED]> writes:
| Ruurd Reitsma wrote:
>> Hi Angus,
>>
>> The irritating thing with Windows is that all stdout messages get lost
>> somewhere when using the GUI subsystem. You would have to add additional
>> code to handle all debugging messages. Now that isn´t that hard to do,
>> but another issue was that some shell script stopped working when linking
>> to the gui subsystem. I cannot remember what worked and what didn´t.
>> Maybe the mingw runtime does a better job, but you´ll have to try that
>> out.
>>
>> Anyway, at that time I´ve looked around, but there didn´t seem to be a
>> more elegant solution. The console closing code is not that
>> sophisticated, so that could be improved.
>>
>> BTW The WinMain stuff get´s added by qtmain automatically.
>
| Reading this thread
| http://lists.trolltech.com/qt-interest/2001-11/thread00727-0.html
>
| A Windows application does not have any stdout/stderr by default, all
| output vanishes without a trace for you.But if you want to, you can create
| a console with AllocConsole() and attach that to stdout/stderr ...
>
| Add following lines into main :
| #ifdef WIN32
| AllocConsole();
| freopen("conin$", "r", stdin);
| freopen("conout$", "w", stdout);
| freopen("conout$", "w", stderr);
| #endif
>
| That suggests that the console could be added when lyxerr is invoked.
>
| Anyway, I think that I'll just add your code as-is for now with some
| commentary describing the alternative.
I feel we are beginning on a slippery slope now... ok to support
windows if only minimal changes are needed... but now we see more and
more changes needed to support this.
I am not sure that I am really happy about this "progress"
--
Lgb
Re: LyX on Windows
Lars Gullik Bjønnes wrote: > I feel we are beginning on a slippery slope now... ok to support > windows if only minimal changes are needed... but now we see more and > more changes needed to support this. > > I am not sure that I am really happy about this "progress" Let me try and reassure you then. If you look at the code base, you'll find minimal evidence of any pollution. Why don you think I've taken a month to gradually merge Ruurd's changes into the repository rather than just commit the thing in its original state? $ egrep -r '_WIN32|WINDOWS' src shows that the only files containing even a sniff of Windows-specific stuff are: src/config.h.in src/support/filename.C src/support/os.C src/support/os_win32.C src/support/package.C.in That doesn't look too terrible, does it? The same is true of all the changes yet to come. Everything can be encapsulated so that the code base suffers minimally. So, what else needs to be done before Ruurd's patch can be declared as fully-merged? 1. This code we've been discussing about Windows notion of a console or a gui app. 2. The signal-handling code needs to be considered carefully as we have a reputation to consider; LyX doesn't eat your data ;-) I plan to write some little test codes to try out the MinGW implementation of these. See also my message a little later in this thread http://article.gmane.org/gmane.editors.lyx.devel:40725 3. The child process code. My general plan is to first refactor the existing code a little so that we present a common interface to the rest of LyX. Again, that's not slippery slope territory. Thereafter, we will need some Windows specific code, but that will be hidden away behind this interface. At that point, we can say that all is done. Fin. Finito. Ferdig. -- Angus
Re: LyX on Windows
Angus Leeming <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: >> I feel we are beginning on a slippery slope now... ok to support >> windows if only minimal changes are needed... but now we see more and >> more changes needed to support this. >> >> I am not sure that I am really happy about this "progress" > | Let me try and reassure you then. If you look at the code base, you'll | find minimal evidence of any pollution. Why don you think I've taken a | month to gradually merge Ruurd's changes into the repository rather than | just commit the thing in its original state? So far it has been stuff that makes LyX more portable. A good thing. But now we are also beginning to much with the build system. As much as I'd like Asger to work on LyX again I am not sure these changes (depends completely how they evolve) are worth it in the long run. I just wanted to "flag" my growing concerns. -- Lgb
Re: Paragraph indendation
Juergen Spitzmueller wrote: > Alfredo Braunstein wrote: >> Paragraph::ownerCode() seems to refer to the insettext owner, not to the >> tabular owner and this explains why we cannot currently distinguish >> between normal text and text in tabulars. > > Ah, I suspected something like this. Is it possible that this lack of > distinguishing is also responsible for some other display bugs (e.g. that > the cell's pwidth isn't displayed)? Probably... is this already on bugzilla? >> I cannot work on this until I get a house & adsl (hopefully in some >> weeks), but I can try to give some other puny advice every now and then >> ;-) > > To be honest, I'd prefer if Andrà or you could take this and do it proper > (not because I'm lazy, I just haven't my hands deep enough in it). Fair enough. One of my next goals is to try to get rid of all back pointers, so this would be part of it anyways. > For now, good luck for your house hunting. Thanks! (almost done) Alfredo
Re: LyX on Windows
Lars Gullik Bjønnes wrote: I just wanted to "flag" my growing concerns. Frankly, I consider this FUD. Complain when you see something you disagree with. Do not complain in advance about what you fear might happen. Regards, Asger
Re: LyX on Windows
Asger Ottar Alstrup <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: >> I just wanted to "flag" my growing concerns. > | Frankly, I consider this FUD. Complain when you see something you | disagree with. Do not complain in advance about what you fear might | happen. Well then I am full of FUD, and as we have seen if you don't speak up before something happens... after the fact it is too late... And (also) frankly I am not at all alleviated by having my concerns called FUD. My fuddy feellings just increased instead. One thing I do disagree with is having several ways of building LyX. -- Lgb
Re: LyX on Windows
Lars Gullik Bjønnes wrote: >>> I feel we are beginning on a slippery slope now... ok to support >>> windows if only minimal changes are needed... but now we see more and >>> more changes needed to support this. >>> >>> I am not sure that I am really happy about this "progress" >> > | Let me try and reassure you then. If you look at the code base, you'll > | find minimal evidence of any pollution. Why don you think I've taken a > | month to gradually merge Ruurd's changes into the repository rather > | than just commit the thing in its original state? > > So far it has been stuff that makes LyX more portable. A good thing. > But now we are also beginning to much with the build system. As I see it, you do not need to worry about this either. Asger is not proposing to muck with the existing build system at all. He's proposing to add an entirely separate one. Moreover, he appears to be talking about adding a maximum of one or two files to the root directory of the repository. Given that the reposititory currently contains 4309 files, I don't think that is any problem at all ;-) > As much as I'd like Asger to work on LyX again I am not sure these > changes (depends completely how they evolve) are worth it in the long > run. My view? We've gone so far to make this bloody thing 'portable'. We should go the extra mile to prove that it actually is portable and not just 'portable'. Otherwise, who are we trying to kid? > I just wanted to "flag" my growing concerns. LOL. Don't worry, Lars, I'm on your side here. (Ok, ok, that might well be something you were worried might happen ;-) -- Angus
Invoking lyx2lyx
There have been a number of mentions on the lyx-users list that the
Windows port of LyX 1.3.5 is unable to run lyx2lyx. That's because Windows
in its braindead-ness doesn't recognize 'lyx2lyx' as a python script (it
doesn't read the first line of the file).
It seems to me that this patch is the minimally-invasive solution:
--- src/buffer.C6 Jan 2005 16:52:08 - 1.601
+++ src/buffer.C17 Jan 2005 14:55:26 -
@@ -619,7 +619,8 @@ bool Buffer::readFile(LyXLex & lex, stri
filename));
return false;
}
- string command = LibFileSearch("lyx2lyx", "lyx2lyx");
+ string command = string("python ") +
+ LibFileSearch("lyx2lyx", "lyx2lyx");
if (command.empty()) {
Alert::error(_("Conversion script not found"),
bformat(_("%1$s is from an earlier"
Clearly, this hard-codes us to a specific name for the python executable,
but then so does
#! /usr/bin/env python
Any objections to me applying this patch to the 1.4.x tree?
--
Angus
Re: Paragraph indendation
Alfredo Braunstein wrote: > Probably... is this already on bugzilla? No. I'll file bugs on all these cases to you. > >> I cannot work on this until I get a house & adsl (hopefully in some > >> weeks), but I can try to give some other puny advice every now and then > >> ;-) > > > > To be honest, I'd prefer if Andrà or you could take this and do it proper > > (not because I'm lazy, I just haven't my hands deep enough in it). > > Fair enough. One of my next goals is to try to get rid of all back > pointers, so this would be part of it anyways. Good. > > For now, good luck for your house hunting. > > Thanks! (almost done) That's good to hear. I hope your current accommodation isn't too buggy. JÃrgen
Win version of LyX: Wrong page numberes in ToF and ToT - one more latex-run needed?
Hello, I just experienced following: When exporting to PDF (ALT-f-e-f), the Table of Figures and the Table of Tables may contain wrong page numbers (when they just changed before in my document). I need to start another PDF run for correct page numbers. As I recall from my earlier use of LyX (under Unix), three LaTeX runs where done, but now only two runs are performed. Is that maybe the reason for the wrong numbers? I'm using LyX 1.3.3 and actual MikTeX (but I think I got the same problems on another machine with LyX 1.3.5) Frank
Re: Invoking lyx2lyx
On Monday 17 January 2005 15:04, Angus Leeming wrote: > Any objections to me applying this patch to the 1.4.x tree? Not from me. :-) The first line is just to be able to call it from any shell. > -- > Angus -- José Abílio
Re: Win version of LyX: Wrong page numberes in ToF and ToT - one more latex-run needed?
Steinhauer, Frank (CAM) wrote: > Hello, > > I just experienced following: > > When exporting to PDF (ALT-f-e-f), the Table of Figures and the Table of > Tables may contain wrong page numbers (when they just changed before in > my document). I need to start another PDF run for correct page numbers. > As I recall from my earlier use of LyX (under Unix), three LaTeX runs > where done, but now only two runs are performed. Is that maybe the reason > for the wrong numbers? > > I'm using LyX 1.3.3 and actual MikTeX (but I think I got the same > problems on another machine with LyX 1.3.5) Hello, Frank. could you post an example file that has these problems, please. -- Angus
Re: Invoking lyx2lyx
Jose' Matos wrote:
>> Any objections to me applying this patch to the 1.4.x tree?
> Not from me. :-)
Then I'll commit the attached patch and place a similar one in my pending
queue for 1.3.x.
> The first line is just to be able to call it from any shell.
Compreendo.
--
AngusIndex: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.2085
diff -u -p -r1.2085 ChangeLog
--- src/ChangeLog 16 Jan 2005 21:01:37 - 1.2085
+++ src/ChangeLog 17 Jan 2005 18:37:29 -
@@ -1,3 +1,8 @@
+2005-01-17 Angus Leeming <[EMAIL PROTECTED]>
+
+ * buffer.C (readFile): prepend the name of the "lyx2lyx" script
+ with "python ". Workaround for a brain-dead Windows.
+
2005-01-16 Angus Leeming <[EMAIL PROTECTED]>
* lyx_main.[Ch] (init): rewrite code to prepend the CWD to the PATH
Index: src/buffer.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/buffer.C,v
retrieving revision 1.601
diff -u -p -r1.601 buffer.C
--- src/buffer.C 6 Jan 2005 16:52:08 - 1.601
+++ src/buffer.C 17 Jan 2005 18:37:30 -
@@ -619,7 +619,8 @@ bool Buffer::readFile(LyXLex & lex, stri
filename));
return false;
}
- string command = LibFileSearch("lyx2lyx", "lyx2lyx");
+ string command =
+ "python " + LibFileSearch("lyx2lyx", "lyx2lyx");
if (command.empty()) {
Alert::error(_("Conversion script not found"),
bformat(_("%1$s is from an earlier"
Index: src/frontends/controllers/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/ChangeLog,v
retrieving revision 1.465
diff -u -p -r1.465 ChangeLog
--- src/frontends/controllers/ChangeLog 11 Jan 2005 13:22:41 - 1.465
+++ src/frontends/controllers/ChangeLog 17 Jan 2005 18:37:33 -
@@ -1,3 +1,8 @@
+2005-01-17 Angus Leeming <[EMAIL PROTECTED]>
+
+ * tex_helpers.C (rescanTexStyles): prepend the name of the
+ "TeXFiles" script with "sh ". Workaround for a brain-dead Windows.
+
2005-01-10 Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
* ControlErrorList.C (goTo): fix the commented-out code (bug
Index: src/frontends/controllers/tex_helpers.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/tex_helpers.C,v
retrieving revision 1.23
diff -u -p -r1.23 tex_helpers.C
--- src/frontends/controllers/tex_helpers.C 10 Jan 2005 19:17:40 - 1.23
+++ src/frontends/controllers/tex_helpers.C 17 Jan 2005 18:37:33 -
@@ -50,7 +50,7 @@ void rescanTexStyles()
Path p(package().user_support());
Systemcall one;
one.startscript(Systemcall::Wait,
- LibFileSearch("scripts", "TeXFiles.sh"));
+ "sh " + LibFileSearch("scripts", "TeXFiles.sh"));
}
Re: LyX on Windows
Angus Leeming wrote: As I see it, you do not need to worry about this either. Angus, even though it's not Friday yet, I think I am going to have to curse you up and down now until you can't see what is up and down anymore. It's for your own good. You see, Lars and I are just starting to heat up to get a real good flame-fest going that might last all up to Friday. It would be like the good old days! But then you come along talking nice soft words and putting all this oil on the waters. Jean-Marc said it: you're a real diplomat, but sometimes a party-spoiler as well. In this case, diplomacy is not what the doctor ordered: On the LyX-devel list, you have to be nice to the *new-comers*. But all the others, you have to scorn and give a hell of a time starting exactly Monday. This state of affairs builds up over the week come Friday, where everybody makes up, and have a beer. That's just the way it is, and the way it has always been. It's like heaven and hell. You can't have one without the other. So, with that basic lesson in LyX manners out of the way, will you let us resume the flame-fest as common courtesy calls for? Cheers, Asger
Re: LyX on Windows
Asger Ottar Alstrup wrote: > So, with that basic lesson in LyX manners out of the way, will you let > us resume the flame-fest as common courtesy calls for? Sure, you wanker. Happy now? -- Angus
