donating to LyX project

2010-03-11 Thread Chris Reynolds
Hello,

We would like to donate to the LyX Project and become your official
sponsors. Could someone in charge of such questions get back to me with our
options.

Thanks in advance.

Chris R.




Re: Some technical details - bug fixed

2010-03-11 Thread Uwe Stöhr

 I think it may be better to put this in an application like the
 LyXLauncher that I made for my installer. AFAIK with a batch file you
 get an ugly pop-up window.

I already use LyXLauncher. I only invented the batch file that calls 
LyXLauncher, to avoid the LANG variable issue. When LANG is not set on a 
PC, your solution works fine. When it is set, I don't have another idea 
than to remove it when installing LyX. But this would be problematic for 
programs that are using LANG.


regards Uwe


Re: LyX 2.0 release plan

2010-03-11 Thread Jean-Marc Lasgouttes

Le 10/03/2010 23:39, Abdelrazak Younes a écrit :

The problem is that it modifies stuff outside of the cell itself.


Such as?

Vincent made the same argument but I fail to see where this is true. For
longtable, we iterate through the rows and the collumns to see if header
of firstheader is set. For border, each cell is independent,
set-all-lines will loop over all cells of a row.


And so if one invokes set-all-lines the changes are outside of the cell 
parameters, right? I have to admit I do not know well this tabular stuff.


JMarc


The updateBuffer() Patch

2010-03-11 Thread rgheck


So, here it is. This takes us down to three calls to updateBuffer():

1. The main call, and ideally the only one we would need, is in 
GuiApplication::dispatch(), after the dispatch cycle has completed.


2. A call in Buffer::reload(), before the call to Buffer::changed(). 
Without this, we can crash, in TextMetrics, since the new file has no 
label information yet (I think). I wonder myself if the call to 
changed() is in the wrong place.


3. A call in GuiView::setBuffer(). This could probably go, but I'm not 
sure exactly how.


Comments welcome, of course.

Since the main Qt 4.6.x crash has been fixed, and because I think there 
may actually be some crashes here, like the one mentioned at (2), I now 
think this should probably wait until after alpha.


Richard

Index: Cursor.h
===
--- Cursor.h	(revision 33709)
+++ Cursor.h	(working copy)
@@ -229,6 +229,12 @@
 	void dispatched();
 	/// Set which update should be done
 	void updateFlags(Update::flags f);
+	///
+	void forceBufferUpdate();
+	///
+	void clearBufferUpdate();
+	///
+	bool needBufferUpdate() const;
 	/**
 	 * don't call update() when done
 	 *
Index: insets/InsetBibitem.cpp
===
--- insets/InsetBibitem.cpp	(revision 33709)
+++ insets/InsetBibitem.cpp	(working copy)
@@ -93,8 +93,6 @@
 			it will be changed to %2$s.), new_key, key));
 	}
 	setParam(key, key);
-
-	buffer().updateBuffer();
 }
 
 
@@ -128,8 +126,9 @@
 			updateCommand(p[key]);
 			cur.bv().buffer().changeRefsIfUnique(old_key,
 params()[key], CITE_CODE);
+			cur.forceBufferUpdate();
+			buffer_-invalidateBibinfoCache();
 		}
-		buffer_-invalidateBibinfoCache();
 		break;
 	}
 
Index: insets/Inset.cpp
===
--- insets/Inset.cpp	(revision 33709)
+++ insets/Inset.cpp	(working copy)
@@ -233,13 +233,7 @@
 	return getLayout().forceLTR();
 }
 
-void Inset::initView()
-{
-	if (isLabeled())
-		buffer().updateBuffer();
-}
 
-
 docstring Inset::toolTip(BufferView const , int, int) const
 {
 	return docstring();
Index: insets/InsetInclude.cpp
===
--- insets/InsetInclude.cpp	(revision 33709)
+++ insets/InsetInclude.cpp	(working copy)
@@ -274,6 +274,7 @@
 }
 			}
 			setParams(p);
+			cur.forceBufferUpdate();
 		} else
 			cur.noUpdate();
 		break;
Index: insets/Inset.h
===
--- insets/Inset.h	(revision 33709)
+++ insets/Inset.h	(working copy)
@@ -124,7 +124,7 @@
 	  *
 	  * \sa isLabeled()
 	  **/
-	virtual void initView();
+	virtual void initView() {};
 	/// \return true if this inset is labeled.
 	virtual bool isLabeled() const { return false; }
 
Index: insets/InsetFloat.cpp
===
--- insets/InsetFloat.cpp	(revision 33709)
+++ insets/InsetFloat.cpp	(working copy)
@@ -152,7 +152,7 @@
 		setNewLabel();
 		if (params_.type != params.type) {
 			params_.type = params.type;
-			buffer().updateBuffer();
+			cur.forceBufferUpdate();
 		}
 		break;
 	}
Index: insets/InsetLabel.cpp
===
--- insets/InsetLabel.cpp	(revision 33709)
+++ insets/InsetLabel.cpp	(working copy)
@@ -97,10 +97,6 @@
 		}
 	}
 	buffer().undo().endUndoGroup();
-
-	// We need an update of the Buffer reference cache. This is achieved by
-	// updateBuffer().
-	buffer().updateBuffer();
 }
 
 
@@ -205,6 +201,7 @@
 		}
 		if (p[name] != params()[name])
 			updateCommand(p[name]);
+		cur.forceBufferUpdate();
 		break;
 	}
 
Index: insets/InsetCommand.cpp
===
--- insets/InsetCommand.cpp	(revision 33709)
+++ insets/InsetCommand.cpp	(working copy)
@@ -144,6 +144,8 @@
 			cur.noUpdate();
 		else
 			setParams(p);
+		if (isLabeled())
+			cur.forceBufferUpdate();
 		break;
 	}
 
Index: BufferView.cpp
===
--- BufferView.cpp	(revision 33709)
+++ BufferView.cpp	(working copy)
@@ -408,6 +408,8 @@
 		 , singlepar =   (flags  Update::SinglePar)
 		 ]  buffer:   buffer_);
 
+	// FIXME Does this really need doing here? It's done in updateBuffer, and
+	// if the Buffer doesn't need updating, then do the macros?
 	buffer_.updateMacros();
 
 	// Now do the first drawing step if needed. This consists on updating
@@ -912,7 +914,6 @@
 	setCursor(backcur.asDocIterator(buffer_));
 
 	buffer_.errors(Class Switch);
-	buffer_.updateBuffer();
 }
 
 /** Return the change status at cursor position, taking in account the
@@ -1185,6 +1186,7 @@
 		// It is then better to make sure that all dialogs are in sync with
 		// current document settings.
 		dr.update(Update::Force | Update::FitCursor);
+		dr.forceBufferUpdate();
 		break;
 	}
 		
@@ -1196,6 +1198,7 @@
 		buffer_.params().makeDocumentClass();

Re: Some technical details - bug fixed

2010-03-11 Thread Joost Verburg

On 3/11/2010 8:34 AM, Uwe Stöhr wrote:

I already use LyXLauncher. I only invented the batch file that calls
LyXLauncher, to avoid the LANG variable issue. When LANG is not set on a
PC, your solution works fine. When it is set, I don't have another idea
than to remove it when installing LyX. But this would be problematic for
programs that are using LANG.


Then you can set the environment variable inside LyXLauncher, just like 
all the other ones.


Joost



Command line problems

2010-03-11 Thread Vincent van Ravesteijn

Enrico,

1.

Tex2lyx is not working for me anymore. This is caused by the assertion 
introduced in r33561:


__wgetmainargs(argc_, argv_, envp, -1, newmode);
LASSERT(argc == argc_, /**/);

If I call  tex2lyx -sysdir /path/to/lib -f test.tex, argc = 2 while 
argc_ = 5.


2.

When I call lyx -sysdir /path/to/lib test.lyx, LyX opens with the 
error message that -sysdir.lyx cannot be found.


Vincent


Compile problem branch: cmake+boost+pcheaders.h

2010-03-11 Thread Vincent van Ravesteijn

When I try to compile branch with cmake I get the following error:

pcheaders.h(41) : fatal error C1083: Cannot open include file: 
'boost/test/utils/nullstream.hpp': No such file or directory


This is wat pcheaders.h says:

# include boost/test/utils/nullstream.hpp

This file really does not exist.

Vincent


Re: Mac widgets

2010-03-11 Thread Vincent van Ravesteijn



I'm not sure if you've already implemented these changes. If so, I
don't see any effect and thought it worth reporting that.

If not, well ... I'll just wait until you do. No hurry.

BH
  

I've committed some changes in http://www.lyx.org/trac/changeset/33716.

- No more Drawers,
- ProgressView and SourceView are docked at the bottom,
- SpellChecker, FindAndReplace and Outline are floating by default, but 
dockable.


Please have a look whether it's better now.

Vincent


Re: Tabular code question

2010-03-11 Thread Uwe Stöhr

 I want to fix the vertical alignment bugs in LyX 1.6 and also trunk.
 To be able to do this, I need to calculate the height of the content
 of the current cell (not the height of the row). How is this done?

Edwin, Abdel, Vincent, do you have any hint for me how this can be done?

thanks and regards
Uwe


[Patch] Dialog to produce backtrace after each crash,

2010-03-11 Thread John McCabe-Dansted
This patch adds a backtrace helper.
1) On LASSERTS it will pop-up a dialog notifying the user an assert
has occurred and that a back-trace has been generated. It will then
continue. There were some arguments for aborting LyX, but I think they
were made on the understanding that aborting LyX was the only way to
get a back-trace. Anyway if the new behavior is not desired one can
set the LYX_NO_BACKTRACE_HELPER command-line variable.
2) On SIGSEGV's and SIGABRTS it will print a notification of the
back-trace being generated on the terminal, and popup the backtrace
this is not as pretty as the QEditText proposal, but this is
sufficient for getting the backtrace to the user. This will be
discussed a bit below.

Compatibililty:
   Compilers: This patch only supports GNUC (gcc, mingw etc.). Other
compilers get the old behavior. It should be easy to extend to other
compilers however (1-5 LOC per compiler).
   OS: This patch should support all OS's LyX supports, but I have
only tested Linux. There are some OS specific #ifdef's I have not
tested.

I have noticed a bug where error_handler() is not called if there was
a stack_overflow (where would the local variables  needed by the
handler be allocated?). This means no backtrace and no emergency save.
We could perhaps fix this with sigaltstack, but this particular
patch does not do so.

On Wed, Mar 10, 2010 at 2:44 AM, Pavel Sanda sa...@lyx.org wrote:
 why to care about async-safe code, why are already killed at this point, no?
 pavel

OK, at worst we don't get a backtrace. I am avoiding the use of QtGui
in the signal hander though since that seems a bit much.

This patch does not implement your idea where we pipe data into
separate process with a QTextEdit. However, it does get the job done
of displaying the needed information to the users and I recall that
you wanted to avoid over-engineering. Would you still like this
functionality?
 I note that such a binary would be about  330K (or 27k stripped).
Would you like a separate binary, called say lyx-backtrace-dialog
or to instead embed it into LyX so e.g that you do
   gdb ... | lyx --backtrace-dialog

-- 
John C. McCabe-Dansted
Index: LyX.cpp
===
--- LyX.cpp	(revision 33691)
+++ LyX.cpp	(working copy)
@@ -611,14 +611,34 @@
 
 	// This shouldn't matter here, however, as we've already invoked
 	// emergencyCleanup.
+
+	// NOTE: this error handler is *not* called if a SIGSEGV was
+	// caused by a stack overflow. (or at least not on Linux)
+	// We will need to use sigaltstack to fix this. BUG!
+
 	switch (err_sig) {
 #ifdef SIGHUP
 	case SIGHUP:
 		lyxerr  \nlyx: SIGHUP signal caught\nBye.  endl;
 		break;
 #endif
+/* We do not trap the following errors, maybe we should?
+   These errors generate a core dump, so it would make sense to output a backtrace.
+	case SIGILL:  //Illegal Instruction
+	case SIGQUIT: //User requests core dump
+	case SIGTRAP: //Debugger Trap
+	case SIGSYS:  //Bad syscall argument (might not be implemented)
+	case SIGEMT:  //Emulator trap (might not be implemented)
+	case SIGBUS:  //With these last three errors the core dump might fail
+	case SIGXCPU: //Process exceeded allowed CPU time
+	case SIGXFSZ: //Process attempt to generate too large file */
+	case SIGABRT:
+		lyxerr  \nlyx: SIGABRT signal caught\nBye.  endl;
+		BACKTRACE_HERE
+		break;
 	case SIGFPE:
 		lyxerr  \nlyx: SIGFPE signal caught\nBye.  endl;
+		BACKTRACE_HERE
 		break;
 	case SIGSEGV:
 		lyxerr  \nlyx: SIGSEGV signal caught\n
@@ -626,6 +646,7 @@
 			  Please read the bug-reporting instructions 
 			  in Help-Introduction and send us a bug report, 
 			  if necessary. Thanks !\nBye.  endl;
+		BACKTRACE_HERE 
 		break;
 	case SIGINT:
 	case SIGTERM:
@@ -637,6 +658,7 @@
 #ifdef SIGHUP
 	signal(SIGHUP, SIG_DFL);
 #endif
+	signal(SIGABRT, SIG_DFL);
 	signal(SIGINT, SIG_DFL);
 	signal(SIGFPE, SIG_DFL);
 	signal(SIGSEGV, SIG_DFL);
@@ -668,6 +690,7 @@
 #ifdef SIGHUP
 	signal(SIGHUP, error_handler);
 #endif
+	signal(SIGABRT, error_handler);
 	signal(SIGFPE, error_handler);
 	signal(SIGSEGV, error_handler);
 	signal(SIGINT, error_handler);
Index: support/lassert.cpp
===
--- support/lassert.cpp	(revision 33691)
+++ support/lassert.cpp	(working copy)
@@ -14,13 +14,135 @@
 
 #include boost/assert.hpp
 
+#include string
+
+#if defined(__GNUC__)  !defined(NO_BACKTRACE_HELPER)
+#define BACKTRACE_HELPER
+#endif
+
+#ifdef BACKTRACE_HELPER
+#include support/docstring.h
+#include support/environment.h
+#include support/FileName.h
+#include support/filetools.h
+#include support/lassert.h
+#include support/lstrings.h
+#include support/lyxtime.h
+#include support/os.h
+#include support/gettext.h
+
+#include boost/regex.hpp
+#include QtGui/qmessagebox.h
+
+#include cstdlib
+#include set
+#include sstream
+
+using namespace lyx;
+using namespace lyx::support;
+#endif
+
+using namespace std;
+
 namespace lyx {
 
+static int 

Re: Tabular code question

2010-03-11 Thread Vincent van Ravesteijn

Uwe Stöhr schreef:


 I want to fix the vertical alignment bugs in LyX 1.6 and also trunk.
 To be able to do this, I need to calculate the height of the content
 of the current cell (not the height of the row). How is this done?

Edwin, Abdel, Vincent, do you have any hint for me how this can be done?

thanks and regards
Uwe

tabular.cellInset(cell)-metrics(m, dim);

See InsetTabular::metrics(). Here the ascent and descent for each cell 
in the row is determined and the maximum is set for the whole row.


Vincent


Re: meaningless error message for missing document packages

2010-03-11 Thread Jean-Marc Lasgouttes

Le 09/03/2010 14:00, rgheck a écrit :

FYI, I've had a look at this and will make some comments and/or go ahead
and commit. But I'm tied up with the Qt 4.6.x crashes at the moment.

JMarc, could you have a look at the TeX-related parts of the patch?


I took a look at it and there are things like \...@expandtwoargs that I do 
not understand. But Julien, if you are sure you know what you are doing 
here, it is OK.


Actually what should be done if you feel like it is to unify the
handling of layouts and modules. The availability of features is not 
checked at the same place, which is a bit ridiculous.


JMarc


Did I ever mention how much I like LyX?

2010-03-11 Thread Steve Litt
Hi all,

Did I ever mention how much I like LyX? It's wonderful. I'm writing my new 
book right now, and LyX is so easy and transparent that I'm pounding out an 
average of 3,000 words per day. LyX just stays out of your way and let's you 
whomp out content. It's great.

Thanks to the developers for making this great bookmaking software, and the 
community for making it better and providing information.

SteveT

Steve Litt
Recession Relief Package
http://www.recession-relief.US
Twitter: http://www.twitter.com/stevelitt



Re: r33720 - lyx-devel/trunk/src/insets

2010-03-11 Thread rgheck

On 03/11/2010 04:11 PM, v...@lyx.org wrote:

Author: vfr
Date: Thu Mar 11 22:11:03 2010
New Revision: 33720
URL: http://www.lyx.org/trac/changeset/33720

Log:
Fix the InsetBranchParams::read function after that the '\n' was removed from 
params2string in r33710.

   

Thanks.

There's a lot more cleanup here that's possible, since Andre's 
introduction of  and  to Lexer some time ago.


rh



Re: Tabular code question

2010-03-11 Thread Guenter Milde
On 2010-03-11, Vincent van Ravesteijn wrote:
 Uwe Stöhr schreef:

  I want to fix the vertical alignment bugs in LyX 1.6 and also trunk.
  To be able to do this, I need to calculate the height of the content
  of the current cell (not the height of the row). How is this done?

 Edwin, Abdel, Vincent, do you have any hint for me how this can be done?

 tabular.cellInset(cell)-metrics(m, dim);

I assume Uwe wanted the height of the cell content *in the output*,
which might be accessible via a \vphantom{cell-content} command.
There might be side-effects if the cell-content contains macros that
increase a counter (or similar).

Günter



Re: meaningless error message for missing document packages

2010-03-11 Thread Julien Rioux

On 11/03/2010 4:12 PM, Jean-Marc Lasgouttes wrote:

Le 09/03/2010 14:00, rgheck a écrit :
I took a look at it and there are things like \...@expandtwoargs that I do
not understand. But Julien, if you are sure you know what you are doing
here, it is OK.


I can explain that particular line:

 \...@expandtwoargs\in@{.}{\file}

I want to check if the macro \file contains the file extension or not, 
so I check for a dot . in it (this is the \in@ part; \...@expandtwoargs 
is to expand the \file macro). If the extension is missing, it should be 
appended to the filename.


This is because LyX's textclass declaration is flexible such as
\DeclareLaTeXClass[aguplus,agums.sty]{...}

The check for extension could be done with a latex package like xstring, 
but LyX's configuration script should not rely on the users having this 
package in their installation, hence the obfuscated TeX construct.


In the previous instance of the code, the check was to look for the 
existence of \file. When this fails, look for \file + .cls. When this 
fails again, mark the textclass unavailable.


But now the aim is to record the missing dependency to textclass.lst, 
and I ended up with lots of package.sty.cls and such, which is wrong. I 
welcome a different suggestion.


By the way, I learned about \...@for from this code! Now somebody else can 
learn about \...@expandtwoargs, maybe :)




Actually what should be done if you feel like it is to unify the
handling of layouts and modules. The availability of features is not
checked at the same place, which is a bit ridiculous.



Do you mean in configure.py, in chkconfig.ltx, or in LyX's code ?


JMarc


Cheers,
Julien


Re: Command line problems

2010-03-11 Thread Enrico Forestieri
On Thu, Mar 11, 2010 at 05:22:36PM +0100, Vincent van Ravesteijn wrote:
 Enrico,

 1.

 Tex2lyx is not working for me anymore. This is caused by the assertion  
 introduced in r33561:

 __wgetmainargs(argc_, argv_, envp, -1, newmode);
 LASSERT(argc == argc_, /**/);

 If I call  tex2lyx -sysdir /path/to/lib -f test.tex, argc = 2 while  
 argc_ = 5.

 2.

 When I call lyx -sysdir /path/to/lib test.lyx, LyX opens with the  
 error message that -sysdir.lyx cannot be found.

I think I know where the problem is. This only happens on native Windows.
I'll fix it as soon as I find the time.

-- 
Enrico


Re: Compile problem branch: cmake+boost+pcheaders.h

2010-03-11 Thread Peter Kümmel
Vincent van Ravesteijn wrote:
 When I try to compile branch with cmake I get the following error:
 
 pcheaders.h(41) : fatal error C1083: Cannot open include file: 
 'boost/test/utils/nullstream.hpp': No such file or directory
 
 This is wat pcheaders.h says:
 
 # include boost/test/utils/nullstream.hpp
 
 This file really does not exist.
 
 Vincent
 

You could remove these lines. Which boost version does branch use?
Now I realize I've not updated branch when I upgraded trunk.

Peter


Re: Command line problems

2010-03-11 Thread Enrico Forestieri
On Thu, Mar 11, 2010 at 05:22:36PM +0100, Vincent van Ravesteijn wrote:
 Enrico,

 1.

 Tex2lyx is not working for me anymore. This is caused by the assertion  
 introduced in r33561:

 __wgetmainargs(argc_, argv_, envp, -1, newmode);
 LASSERT(argc == argc_, /**/);

 If I call  tex2lyx -sysdir /path/to/lib -f test.tex, argc = 2 while  
 argc_ = 5.

 2.

 When I call lyx -sysdir /path/to/lib test.lyx, LyX opens with the  
 error message that -sysdir.lyx cannot be found.

Should be fixed now.

-- 
Enrico


Re: Tabular code question

2010-03-11 Thread Uwe Stöhr

Am 11.03.2010 21:25, schrieb Vincent van Ravesteijn:


I want to fix the vertical alignment bugs in LyX 1.6 and also trunk.
To be able to do this, I need to calculate the height of the content
of the current cell (not the height of the row). How is this done?


tabular.cellInset(cell)-metrics(m, dim);

See InsetTabular::metrics(). Here the ascent and descent for each cell
in the row is determined and the maximum is set for the whole row.


Thanks for the hint. I'm nevertheless not able to access the metrics inside the draw() routine. 
Attached is a patch that should fix the vertical alignment drawing for normal cells. The problem is 
that it doesn't compile because of an unresolved external:


InsetTabular.obj : error LNK2019: unresolved external symbol public: __thiscall
 lyx::MetricsInfo::MetricsInfo(void) (??0metricsi...@lyx@@q...@xz) referenced 
in
 function public: virtual void __thiscall lyx::InsetTabular::draw(class lyx::Pa
interInfo ,int,int)const  
(?d...@insettabular@lyx@@ubexaavpainteri...@2@h...@z)

The problem is that the MetricsInfo is not available. I tried to extend the draw() routine so that 
it also grabs the MetricsInfo and the Dimension and not only the PainterInfo but this fails too.

Is there a way to access the metrics?

thanks and regards
Uwe

p.s. I still don't understand how exactly dim.asc is calculated. Where in the 
code is this done?
Index: InsetTabular.cpp
===
--- InsetTabular.cpp	(revision 33720)
+++ InsetTabular.cpp	(working copy)
@@ -3249,6 +3249,7 @@
 	dim.wid = tabular.width() + 2 * ADD_TO_TABULAR_WIDTH;
 }
 
+
 bool InsetTabular::isCellSelected(Cursor  cur, row_type row, col_type col) 
 	const
 {
@@ -3291,6 +3292,7 @@
 	bool const original_selection_state = pi.selected;
 
 	idx_type idx = 0;
+	int cy = 0;
 	first_visible_cell = Tabular::npos;
 	for (row_type r = 0; r  tabular.nrows(); ++r) {
 		int nx = x;
@@ -3309,8 +3311,30 @@
 first_visible_cell = idx;
 
 			pi.selected |= isCellSelected(cur, r, c);
+
+			// set the position for the vertical alignment
+			cy = y;
+			Dimension dim;
+			MetricsInfo m;
+			// determine the cell dimensions
+			tabular.cellInset(idx)-metrics(m, dim);
+			// if the cell height is below the row height then
+			// substract space according to the row height
+			if ((dim.asc + dim.des)  tabular.rowHeight(idx)) {
+cy += tabular.rowHeight(idx)/2;
+switch (tabular.getVAlignment(idx)) {
+	case Tabular::LYX_VALIGN_TOP:
+		break;
+	case Tabular::LYX_VALIGN_MIDDLE:
+		cy -= (dim.asc + dim.des)/2;
+		break;
+	case Tabular::LYX_VALIGN_BOTTOM:
+		cy -= dim.asc + dim.des;
+		break;
+}
+			}
+
 			int const cx = nx + tabular.textHOffset(idx);
-			int const cy = y  + tabular.textVOffset(idx);
 			// Cache the Inset position.
 			bv-coordCache().insets().add(cell(idx).get(), cx, y);
 			cell(idx)-draw(pi, cx, cy);


Re: r33723 - in lyx-devel/trunk/src: . support tex2lyx

2010-03-11 Thread Enrico Forestieri
On Fri, Mar 12, 2010 at 02:18:40AM +0100, for...@lyx.org wrote:
 Author: forenr
 Date: Fri Mar 12 02:18:39 2010
 New Revision: 33723
 URL: http://www.lyx.org/trac/changeset/33723
 
 Log:
 Fix command line parsing and allow unicode arguments for tex2lyx on Windows.

Jürgen, this is also needed in branch.

 Modified:
lyx-devel/trunk/src/LyX.cpp
lyx-devel/trunk/src/support/os.h
lyx-devel/trunk/src/support/os_cygwin.cpp
lyx-devel/trunk/src/support/os_unix.cpp
lyx-devel/trunk/src/support/os_win32.cpp
lyx-devel/trunk/src/tex2lyx/tex2lyx.cpp
 
 Modified: lyx-devel/trunk/src/LyX.cpp
 ==
 --- lyx-devel/trunk/src/LyX.cpp   Fri Mar 12 01:27:12 2010(r33722)
 +++ lyx-devel/trunk/src/LyX.cpp   Fri Mar 12 02:18:39 2010(r33723)
 @@ -1133,6 +1133,7 @@
   // Now, remove used arguments by shifting
   // the following ones remove places down.
   if (remove  0) {
 + os::remove_internal_args(i, remove);
   argc -= remove;
   for (int j = i; j  argc; ++j)
   argv[j] = argv[j + remove];
 
 Modified: lyx-devel/trunk/src/support/os.h
 ==
 --- lyx-devel/trunk/src/support/os.h  Fri Mar 12 01:27:12 2010(r33722)
 +++ lyx-devel/trunk/src/support/os.h  Fri Mar 12 02:18:39 2010(r33723)
 @@ -49,6 +49,9 @@
  /// Returns the i-th program argument in utf8 encoding.
  std::string utf8_argv(int i);
  
 +/// Removes from the internal copy \p num program arguments starting from \p 
 i.
 +void remove_internal_args(int i, int num);
 +
  /// Returns the name of the NULL device (/dev/null, null).
  std::string const  nulldev();
  
 
 Modified: lyx-devel/trunk/src/support/os_cygwin.cpp
 ==
 --- lyx-devel/trunk/src/support/os_cygwin.cpp Fri Mar 12 01:27:12 2010
 (r33722)
 +++ lyx-devel/trunk/src/support/os_cygwin.cpp Fri Mar 12 02:18:39 2010
 (r33723)
 @@ -228,6 +228,10 @@
  }
  
  
 +void remove_internal_args(int, int)
 +{}
 +
 +
  string current_root()
  {
   return string(/);
 
 Modified: lyx-devel/trunk/src/support/os_unix.cpp
 ==
 --- lyx-devel/trunk/src/support/os_unix.cpp   Fri Mar 12 01:27:12 2010
 (r33722)
 +++ lyx-devel/trunk/src/support/os_unix.cpp   Fri Mar 12 02:18:39 2010
 (r33723)
 @@ -52,6 +52,10 @@
  }
  
  
 +void remove_internal_args(int, int)
 +{}
 +
 +
  string current_root()
  {
   return /;
 
 Modified: lyx-devel/trunk/src/support/os_win32.cpp
 ==
 --- lyx-devel/trunk/src/support/os_win32.cpp  Fri Mar 12 01:27:12 2010
 (r33722)
 +++ lyx-devel/trunk/src/support/os_win32.cpp  Fri Mar 12 02:18:39 2010
 (r33723)
 @@ -209,6 +209,14 @@
  }
  
  
 +void remove_internal_args(int i, int num)
 +{
 + argc_ -= num;
 + for (int j = i; j  argc_; ++j)
 + argv_[j] = argv_[j + num];
 +}
 +
 +
  string current_root()
  {
   // _getdrive returns the current drive (1=A, 2=B, and so on).
 
 Modified: lyx-devel/trunk/src/tex2lyx/tex2lyx.cpp
 ==
 --- lyx-devel/trunk/src/tex2lyx/tex2lyx.cpp   Fri Mar 12 01:27:12 2010
 (r33722)
 +++ lyx-devel/trunk/src/tex2lyx/tex2lyx.cpp   Fri Mar 12 02:18:39 2010
 (r33723)
 @@ -381,13 +381,14 @@
   continue;
   }
  
 - string arg(to_utf8(from_local8bit((i + 1  argc) ? argv[i + 1] 
 : )));
 - string arg2(to_utf8(from_local8bit((i + 2  argc) ? argv[i + 2] 
 : )));
 + string arg = (i + 1  argc) ? os::utf8_argv(i + 1) : string();
 + string arg2 = (i + 2  argc) ? os::utf8_argv(i + 2) : string();
  
   int const remove = 1 + it-second(arg, arg2);
  
   // Now, remove used arguments by shifting
   // the following ones remove places down.
 + os::remove_internal_args(i, remove);
   argc -= remove;
   for (int j = i; j  argc; ++j)
   argv[j] = argv[j + remove];
 @@ -519,14 +520,15 @@
  
   lyxerr.setStream(cerr);
  
 + os::init(argc, argv);
 +
   easyParse(argc, argv);
  
   if (argc = 1) 
   error_message(Not enough arguments.);
 - os::init(argc, argv);
  
   try {
 - init_package(internal_path(to_utf8(from_local8bit(argv[0]))),
 + init_package(internal_path(os::utf8_argv(0)),
cl_system_support, cl_user_support,
top_build_dir_is_two_levels_up);
   } catch (ExceptionMessage const  message) {
 @@ -538,12 

Re: Tabular code question

2010-03-11 Thread Uwe Stöhr

 I assume Uwe wanted the height of the cell content *in the output*

No, I want to calculate the cell height as drawn in LyX. (Exactly as Vincent 
replied me)

thanks and regards
Uwe


LyX's LaTeX preferences dialog needs quick UI overhaul

2010-03-11 Thread Uwe Stöhr

In LyX 2.0svn open the menu Tools-Preferences-Output-LaTeX

You can see that the text fields don't have a uniform left border.
(I would have fixed this right now but my Qt designer currently doesn't work.)

regards Uwe


Re: Mac widgets

2010-03-11 Thread BH
On Thu, Mar 11, 2010 at 2:37 PM, Vincent van Ravesteijn
v.f.vanraveste...@tudelft.nl wrote:

 I'm not sure if you've already implemented these changes. If so, I
 don't see any effect and thought it worth reporting that.

 If not, well ... I'll just wait until you do. No hurry.

 BH


 I've committed some changes in http://www.lyx.org/trac/changeset/33716.

 - No more Drawers,
 - ProgressView and SourceView are docked at the bottom,
 - SpellChecker, FindAndReplace and Outline are floating by default, but
 dockable.


 Please have a look whether it's better now.

Yes, that works well ... at least that's what I asked for. (Thanks!)
Now that I see it, however, I notice some potential problems.

On Mac, it is typical to have one instance of an application open at a
time and for that application to have multiple document windows,
typically with one document per window. Given this, it is typical for
there to be a single set of floating widgets whose content changes to
match the frontmost document window.

This is not how LyX currently works: having multiple windows means
having multiple sets of floating widgets, with no easy way to tell
which widget belongs to which window. That gets confusing fast, and
I'd like to see it changed if possible. (No other Mac program that I'm
aware of works this way.)

Currently, a single window will have only one set of widgets
associated with it, so that switching between tabs of a single window
will cause the widgets to change their contents appropriately. Can
that be the default for multiple windows as well?

BH


Re: Did I ever mention how much I like LyX?

2010-03-11 Thread john
Steve Litt wrote:
 Hi all,

 Did I ever mention how much I like LyX? It's wonderful. I'm writing my new 
 book right now, and LyX is so easy and transparent that I'm pounding out an 
 average of 3,000 words per day. LyX just stays out of your way and let's you 
 whomp out content. It's great.

 Thanks to the developers for making this great bookmaking software, and the 
 community for making it better and providing information.
   
Amen to that!
It's my favourite piece of software and has been for more than a decade!

John O'Gorman

 SteveT

 Steve Litt
 Recession Relief Package
 http://www.recession-relief.US
 Twitter: http://www.twitter.com/stevelitt



   



Re: Mac widgets

2010-03-11 Thread Abdelrazak Younes

On 03/12/2010 04:57 AM, BH wrote:

On Thu, Mar 11, 2010 at 2:37 PM, Vincent van Ravesteijn
v.f.vanraveste...@tudelft.nl  wrote:
   
 

I'm not sure if you've already implemented these changes. If so, I
don't see any effect and thought it worth reporting that.

If not, well ... I'll just wait until you do. No hurry.

BH

   

I've committed some changes in http://www.lyx.org/trac/changeset/33716.

- No more Drawers,
- ProgressView and SourceView are docked at the bottom,
- SpellChecker, FindAndReplace and Outline are floating by default, but
dockable.


Please have a look whether it's better now.
 

Yes, that works well ... at least that's what I asked for. (Thanks!)
Now that I see it, however, I notice some potential problems.

On Mac, it is typical to have one instance of an application open at a
time and for that application to have multiple document windows,
typically with one document per window. Given this, it is typical for
there to be a single set of floating widgets whose content changes to
match the frontmost document window.

This is not how LyX currently works: having multiple windows means
having multiple sets of floating widgets, with no easy way to tell
which widget belongs to which window. That gets confusing fast, and
I'd like to see it changed if possible. (No other Mac program that I'm
aware of works this way.)

Currently, a single window will have only one set of widgets
associated with it, so that switching between tabs of a single window
will cause the widgets to change their contents appropriately. Can
that be the default for multiple windows as well?
   


That could (and should) be done but this is not as simple as it may 
seem. The problem is that all dialogs are own and managed by the window 
(GuiView) not by the application (GuiApplication). So, while I agree 
this is wrong and has always been wrong since we are multi-windows 
capbale, it's a bit difficult to do it right now.


Abdel.




Re: donating to LyX project

2010-03-11 Thread Abdelrazak Younes

On 03/11/2010 11:31 AM, Chris Reynolds wrote:

Hello,

We would like to donate to the LyX Project and become your official
sponsors. Could someone in charge of such questions get back to me with our
options.
   


Hello Chris,

Donation from company has been done once in the past, to sponsor a 
development project (see about Beslist.nl in www.lyx.org/Donate). Would 
you company want to sponsor a particular project or is this about a 
general donation?


Abdel.



donating to LyX project

2010-03-11 Thread Chris Reynolds
Hello,

We would like to donate to the LyX Project and become your official
sponsors. Could someone in charge of such questions get back to me with our
options.

Thanks in advance.

Chris R.




Re: Some technical details - bug fixed

2010-03-11 Thread Uwe Stöhr

> I think it may be better to put this in an application like the
> LyXLauncher that I made for my installer. AFAIK with a batch file you
> get an ugly pop-up window.

I already use LyXLauncher. I only invented the batch file that calls 
LyXLauncher, to avoid the LANG variable issue. When LANG is not set on a 
PC, your solution works fine. When it is set, I don't have another idea 
than to remove it when installing LyX. But this would be problematic for 
programs that are using LANG.


regards Uwe


Re: LyX 2.0 release plan

2010-03-11 Thread Jean-Marc Lasgouttes

Le 10/03/2010 23:39, Abdelrazak Younes a écrit :

The problem is that it modifies stuff outside of the cell itself.


Such as?

Vincent made the same argument but I fail to see where this is true. For
longtable, we iterate through the rows and the collumns to see if header
of firstheader is set. For border, each cell is independent,
set-all-lines will loop over all cells of a row.


And so if one invokes set-all-lines the changes are outside of the cell 
parameters, right? I have to admit I do not know well this tabular stuff.


JMarc


The updateBuffer() Patch

2010-03-11 Thread rgheck


So, here it is. This takes us down to three calls to updateBuffer():

1. The "main" call, and ideally the only one we would need, is in 
GuiApplication::dispatch(), after the dispatch cycle has completed.


2. A call in Buffer::reload(), before the call to Buffer::changed(). 
Without this, we can crash, in TextMetrics, since the new file has no 
label information yet (I think). I wonder myself if the call to 
changed() is in the wrong place.


3. A call in GuiView::setBuffer(). This could probably go, but I'm not 
sure exactly how.


Comments welcome, of course.

Since the main Qt 4.6.x crash has been fixed, and because I think there 
may actually be some crashes here, like the one mentioned at (2), I now 
think this should probably wait until after alpha.


Richard

Index: Cursor.h
===
--- Cursor.h	(revision 33709)
+++ Cursor.h	(working copy)
@@ -229,6 +229,12 @@
 	void dispatched();
 	/// Set which update should be done
 	void updateFlags(Update::flags f);
+	///
+	void forceBufferUpdate();
+	///
+	void clearBufferUpdate();
+	///
+	bool needBufferUpdate() const;
 	/**
 	 * don't call update() when done
 	 *
Index: insets/InsetBibitem.cpp
===
--- insets/InsetBibitem.cpp	(revision 33709)
+++ insets/InsetBibitem.cpp	(working copy)
@@ -93,8 +93,6 @@
 			"it will be changed to %2$s."), new_key, key));
 	}
 	setParam("key", key);
-
-	buffer().updateBuffer();
 }
 
 
@@ -128,8 +126,9 @@
 			updateCommand(p["key"]);
 			cur.bv().buffer().changeRefsIfUnique(old_key,
 params()["key"], CITE_CODE);
+			cur.forceBufferUpdate();
+			buffer_->invalidateBibinfoCache();
 		}
-		buffer_->invalidateBibinfoCache();
 		break;
 	}
 
Index: insets/Inset.cpp
===
--- insets/Inset.cpp	(revision 33709)
+++ insets/Inset.cpp	(working copy)
@@ -233,13 +233,7 @@
 	return getLayout().forceLTR();
 }
 
-void Inset::initView()
-{
-	if (isLabeled())
-		buffer().updateBuffer();
-}
 
-
 docstring Inset::toolTip(BufferView const &, int, int) const
 {
 	return docstring();
Index: insets/InsetInclude.cpp
===
--- insets/InsetInclude.cpp	(revision 33709)
+++ insets/InsetInclude.cpp	(working copy)
@@ -274,6 +274,7 @@
 }
 			}
 			setParams(p);
+			cur.forceBufferUpdate();
 		} else
 			cur.noUpdate();
 		break;
Index: insets/Inset.h
===
--- insets/Inset.h	(revision 33709)
+++ insets/Inset.h	(working copy)
@@ -124,7 +124,7 @@
 	  *
 	  * \sa isLabeled()
 	  **/
-	virtual void initView();
+	virtual void initView() {};
 	/// \return true if this inset is labeled.
 	virtual bool isLabeled() const { return false; }
 
Index: insets/InsetFloat.cpp
===
--- insets/InsetFloat.cpp	(revision 33709)
+++ insets/InsetFloat.cpp	(working copy)
@@ -152,7 +152,7 @@
 		setNewLabel();
 		if (params_.type != params.type) {
 			params_.type = params.type;
-			buffer().updateBuffer();
+			cur.forceBufferUpdate();
 		}
 		break;
 	}
Index: insets/InsetLabel.cpp
===
--- insets/InsetLabel.cpp	(revision 33709)
+++ insets/InsetLabel.cpp	(working copy)
@@ -97,10 +97,6 @@
 		}
 	}
 	buffer().undo().endUndoGroup();
-
-	// We need an update of the Buffer reference cache. This is achieved by
-	// updateBuffer().
-	buffer().updateBuffer();
 }
 
 
@@ -205,6 +201,7 @@
 		}
 		if (p["name"] != params()["name"])
 			updateCommand(p["name"]);
+		cur.forceBufferUpdate();
 		break;
 	}
 
Index: insets/InsetCommand.cpp
===
--- insets/InsetCommand.cpp	(revision 33709)
+++ insets/InsetCommand.cpp	(working copy)
@@ -144,6 +144,8 @@
 			cur.noUpdate();
 		else
 			setParams(p);
+		if (isLabeled())
+			cur.forceBufferUpdate();
 		break;
 	}
 
Index: BufferView.cpp
===
--- BufferView.cpp	(revision 33709)
+++ BufferView.cpp	(working copy)
@@ -408,6 +408,8 @@
 		<< ", singlepar = " << (flags & Update::SinglePar)
 		<< "]  buffer: " << _);
 
+	// FIXME Does this really need doing here? It's done in updateBuffer, and
+	// if the Buffer doesn't need updating, then do the macros?
 	buffer_.updateMacros();
 
 	// Now do the first drawing step if needed. This consists on updating
@@ -912,7 +914,6 @@
 	setCursor(backcur.asDocIterator(_));
 
 	buffer_.errors("Class Switch");
-	buffer_.updateBuffer();
 }
 
 /** Return the change status at cursor position, taking in account the
@@ -1185,6 +1186,7 @@
 		// It is then better to make sure that all dialogs are in sync with
 		// current document settings.
 		dr.update(Update::Force | Update::FitCursor);
+		dr.forceBufferUpdate();
 		break;
 	}
 		
@@ -1196,6 +1198,7 @@
 		

Re: Some technical details - bug fixed

2010-03-11 Thread Joost Verburg

On 3/11/2010 8:34 AM, Uwe Stöhr wrote:

I already use LyXLauncher. I only invented the batch file that calls
LyXLauncher, to avoid the LANG variable issue. When LANG is not set on a
PC, your solution works fine. When it is set, I don't have another idea
than to remove it when installing LyX. But this would be problematic for
programs that are using LANG.


Then you can set the environment variable inside LyXLauncher, just like 
all the other ones.


Joost



Command line problems

2010-03-11 Thread Vincent van Ravesteijn

Enrico,

1.

Tex2lyx is not working for me anymore. This is caused by the assertion 
introduced in r33561:


__wgetmainargs(_, _, , -1, );
LASSERT(argc == argc_, /**/);

If I call  "tex2lyx -sysdir /path/to/lib -f test.tex", argc = 2 while 
argc_ = 5.


2.

When I call "lyx -sysdir /path/to/lib test.lyx", LyX opens with the 
error message that "-sysdir.lyx" cannot be found.


Vincent


Compile problem branch: cmake+boost+pcheaders.h

2010-03-11 Thread Vincent van Ravesteijn

When I try to compile branch with cmake I get the following error:

pcheaders.h(41) : fatal error C1083: Cannot open include file: 
'boost/test/utils/nullstream.hpp': No such file or directory


This is wat pcheaders.h says:

# include 

This file really does not exist.

Vincent


Re: Mac widgets

2010-03-11 Thread Vincent van Ravesteijn



I'm not sure if you've already implemented these changes. If so, I
don't see any effect and thought it worth reporting that.

If not, well ... I'll just wait until you do. No hurry.

BH
  

I've committed some changes in http://www.lyx.org/trac/changeset/33716.

- No more Drawers,
- ProgressView and SourceView are docked at the bottom,
- SpellChecker, FindAndReplace and Outline are floating by default, but 
dockable.


Please have a look whether it's better now.

Vincent


Re: Tabular code question

2010-03-11 Thread Uwe Stöhr

> I want to fix the vertical alignment bugs in LyX 1.6 and also trunk.
> To be able to do this, I need to calculate the height of the content
> of the current cell (not the height of the row). How is this done?

Edwin, Abdel, Vincent, do you have any hint for me how this can be done?

thanks and regards
Uwe


[Patch] Dialog to produce backtrace after each crash,

2010-03-11 Thread John McCabe-Dansted
This patch adds a backtrace helper.
1) On LASSERTS it will pop-up a dialog notifying the user an assert
has occurred and that a back-trace has been generated. It will then
continue. There were some arguments for aborting LyX, but I think they
were made on the understanding that aborting LyX was the only way to
get a back-trace. Anyway if the new behavior is not desired one can
set the LYX_NO_BACKTRACE_HELPER command-line variable.
2) On SIGSEGV's and SIGABRTS it will print a notification of the
back-trace being generated on the terminal, and popup the backtrace
this is not as pretty as the QEditText proposal, but this is
sufficient for getting the backtrace to the user. This will be
discussed a bit below.

Compatibililty:
   Compilers: This patch only supports GNUC (gcc, mingw etc.). Other
compilers get the old behavior. It should be easy to extend to other
compilers however (1-5 LOC per compiler).
   OS: This patch should support all OS's LyX supports, but I have
only tested Linux. There are some OS specific #ifdef's I have not
tested.

I have noticed a bug where error_handler() is not called if there was
a stack_overflow (where would the local variables  needed by the
handler be allocated?). This means no backtrace and no emergency save.
We could perhaps fix this with "sigaltstack", but this particular
patch does not do so.

On Wed, Mar 10, 2010 at 2:44 AM, Pavel Sanda  wrote:
> why to care about async-safe code, why are already killed at this point, no?
> pavel

OK, at worst we don't get a backtrace. I am avoiding the use of QtGui
in the signal hander though since that seems a bit much.

This patch does not implement your idea where we pipe data into
separate process with a QTextEdit. However, it does get the job done
of displaying the needed information to the users and I recall that
you wanted to avoid over-engineering. Would you still like this
functionality?
 I note that such a binary would be about  330K (or 27k stripped).
Would you like a separate binary, called say "lyx-backtrace-dialog"
or to instead embed it into LyX so e.g that you do
  " gdb ... | lyx --backtrace-dialog"

-- 
John C. McCabe-Dansted
Index: LyX.cpp
===
--- LyX.cpp	(revision 33691)
+++ LyX.cpp	(working copy)
@@ -611,14 +611,34 @@
 
 	// This shouldn't matter here, however, as we've already invoked
 	// emergencyCleanup.
+
+	// NOTE: this error handler is *not* called if a SIGSEGV was
+	// caused by a stack overflow. (or at least not on Linux)
+	// We will need to use sigaltstack to fix this. BUG!
+
 	switch (err_sig) {
 #ifdef SIGHUP
 	case SIGHUP:
 		lyxerr << "\nlyx: SIGHUP signal caught\nBye." << endl;
 		break;
 #endif
+/* We do not trap the following errors, maybe we should?
+   These errors generate a core dump, so it would make sense to output a backtrace.
+	case SIGILL:  //Illegal Instruction
+	case SIGQUIT: //User requests core dump
+	case SIGTRAP: //Debugger Trap
+	case SIGSYS:  //Bad syscall argument (might not be implemented)
+	case SIGEMT:  //Emulator trap (might not be implemented)
+	case SIGBUS:  //With these last three errors the core dump might fail
+	case SIGXCPU: //Process exceeded allowed CPU time
+	case SIGXFSZ: //Process attempt to generate too large file */
+	case SIGABRT:
+		lyxerr << "\nlyx: SIGABRT signal caught\nBye." << endl;
+		BACKTRACE_HERE
+		break;
 	case SIGFPE:
 		lyxerr << "\nlyx: SIGFPE signal caught\nBye." << endl;
+		BACKTRACE_HERE
 		break;
 	case SIGSEGV:
 		lyxerr << "\nlyx: SIGSEGV signal caught\n"
@@ -626,6 +646,7 @@
 			  "Please read the bug-reporting instructions "
 			  "in Help->Introduction and send us a bug report, "
 			  "if necessary. Thanks !\nBye." << endl;
+		BACKTRACE_HERE 
 		break;
 	case SIGINT:
 	case SIGTERM:
@@ -637,6 +658,7 @@
 #ifdef SIGHUP
 	signal(SIGHUP, SIG_DFL);
 #endif
+	signal(SIGABRT, SIG_DFL);
 	signal(SIGINT, SIG_DFL);
 	signal(SIGFPE, SIG_DFL);
 	signal(SIGSEGV, SIG_DFL);
@@ -668,6 +690,7 @@
 #ifdef SIGHUP
 	signal(SIGHUP, error_handler);
 #endif
+	signal(SIGABRT, error_handler);
 	signal(SIGFPE, error_handler);
 	signal(SIGSEGV, error_handler);
 	signal(SIGINT, error_handler);
Index: support/lassert.cpp
===
--- support/lassert.cpp	(revision 33691)
+++ support/lassert.cpp	(working copy)
@@ -14,13 +14,135 @@
 
 #include 
 
+#include 
+
+#if defined(__GNUC__) && !defined(NO_BACKTRACE_HELPER)
+#define BACKTRACE_HELPER
+#endif
+
+#ifdef BACKTRACE_HELPER
+#include "support/docstring.h"
+#include "support/environment.h"
+#include "support/FileName.h"
+#include "support/filetools.h"
+#include "support/lassert.h"
+#include "support/lstrings.h"
+#include "support/lyxtime.h"
+#include "support/os.h"
+#include "support/gettext.h"
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+using namespace lyx;
+using namespace lyx::support;
+#endif
+
+using namespace std;
+
 namespace lyx {
 
+static int 

Re: Tabular code question

2010-03-11 Thread Vincent van Ravesteijn

Uwe Stöhr schreef:


> I want to fix the vertical alignment bugs in LyX 1.6 and also trunk.
> To be able to do this, I need to calculate the height of the content
> of the current cell (not the height of the row). How is this done?

Edwin, Abdel, Vincent, do you have any hint for me how this can be done?

thanks and regards
Uwe

tabular.cellInset(cell)->metrics(m, dim);

See InsetTabular::metrics(). Here the ascent and descent for each cell 
in the row is determined and the maximum is set for the whole row.


Vincent


Re: meaningless error message for missing document packages

2010-03-11 Thread Jean-Marc Lasgouttes

Le 09/03/2010 14:00, rgheck a écrit :

FYI, I've had a look at this and will make some comments and/or go ahead
and commit. But I'm tied up with the Qt 4.6.x crashes at the moment.

JMarc, could you have a look at the TeX-related parts of the patch?


I took a look at it and there are things like \...@expandtwoargs that I do 
not understand. But Julien, if you are sure you know what you are doing 
here, it is OK.


Actually what should be done if you feel like it is to unify the
handling of layouts and modules. The availability of features is not 
checked at the same place, which is a bit ridiculous.


JMarc


Did I ever mention how much I like LyX?

2010-03-11 Thread Steve Litt
Hi all,

Did I ever mention how much I like LyX? It's wonderful. I'm writing my new 
book right now, and LyX is so easy and transparent that I'm pounding out an 
average of 3,000 words per day. LyX just stays out of your way and let's you 
whomp out content. It's great.

Thanks to the developers for making this great bookmaking software, and the 
community for making it better and providing information.

SteveT

Steve Litt
Recession Relief Package
http://www.recession-relief.US
Twitter: http://www.twitter.com/stevelitt



Re: r33720 - lyx-devel/trunk/src/insets

2010-03-11 Thread rgheck

On 03/11/2010 04:11 PM, v...@lyx.org wrote:

Author: vfr
Date: Thu Mar 11 22:11:03 2010
New Revision: 33720
URL: http://www.lyx.org/trac/changeset/33720

Log:
Fix the InsetBranchParams::read function after that the '\n' was removed from 
params2string in r33710.

   

Thanks.

There's a lot more cleanup here that's possible, since Andre's 
introduction of ">>" and "<<" to Lexer some time ago.


rh



Re: Tabular code question

2010-03-11 Thread Guenter Milde
On 2010-03-11, Vincent van Ravesteijn wrote:
> Uwe Stöhr schreef:

>> > I want to fix the vertical alignment bugs in LyX 1.6 and also trunk.
>> > To be able to do this, I need to calculate the height of the content
>> > of the current cell (not the height of the row). How is this done?

>> Edwin, Abdel, Vincent, do you have any hint for me how this can be done?

> tabular.cellInset(cell)->metrics(m, dim);

I assume Uwe wanted the height of the cell content *in the output*,
which might be accessible via a \vphantom{} command.
There might be side-effects if the  contains macros that
increase a counter (or similar).

Günter



Re: meaningless error message for missing document packages

2010-03-11 Thread Julien Rioux

On 11/03/2010 4:12 PM, Jean-Marc Lasgouttes wrote:

Le 09/03/2010 14:00, rgheck a écrit :
I took a look at it and there are things like \...@expandtwoargs that I do
not understand. But Julien, if you are sure you know what you are doing
here, it is OK.


I can explain that particular line:

 \...@expandtwoargs\in@{.}{\file}

I want to check if the macro \file contains the file extension or not, 
so I check for a dot "." in it (this is the \in@ part; \...@expandtwoargs 
is to expand the \file macro). If the extension is missing, it should be 
appended to the filename.


This is because LyX's textclass declaration is flexible such as
\DeclareLaTeXClass[aguplus,agums.sty]{...}

The check for extension could be done with a latex package like xstring, 
but LyX's configuration script should not rely on the users having this 
package in their installation, hence the obfuscated TeX construct.


In the previous instance of the code, the check was to look for the 
existence of \file. When this fails, look for \file + ".cls". When this 
fails again, mark the textclass unavailable.


But now the aim is to record the missing dependency to textclass.lst, 
and I ended up with lots of package.sty.cls and such, which is wrong. I 
welcome a different suggestion.


By the way, I learned about \...@for from this code! Now somebody else can 
learn about \...@expandtwoargs, maybe :)




Actually what should be done if you feel like it is to unify the
handling of layouts and modules. The availability of features is not
checked at the same place, which is a bit ridiculous.



Do you mean in configure.py, in chkconfig.ltx, or in LyX's code ?


JMarc


Cheers,
Julien


Re: Command line problems

2010-03-11 Thread Enrico Forestieri
On Thu, Mar 11, 2010 at 05:22:36PM +0100, Vincent van Ravesteijn wrote:
> Enrico,
>
> 1.
>
> Tex2lyx is not working for me anymore. This is caused by the assertion  
> introduced in r33561:
>
> __wgetmainargs(_, _, , -1, );
> LASSERT(argc == argc_, /**/);
>
> If I call  "tex2lyx -sysdir /path/to/lib -f test.tex", argc = 2 while  
> argc_ = 5.
>
> 2.
>
> When I call "lyx -sysdir /path/to/lib test.lyx", LyX opens with the  
> error message that "-sysdir.lyx" cannot be found.

I think I know where the problem is. This only happens on native Windows.
I'll fix it as soon as I find the time.

-- 
Enrico


Re: Compile problem branch: cmake+boost+pcheaders.h

2010-03-11 Thread Peter Kümmel
Vincent van Ravesteijn wrote:
> When I try to compile branch with cmake I get the following error:
> 
> pcheaders.h(41) : fatal error C1083: Cannot open include file: 
> 'boost/test/utils/nullstream.hpp': No such file or directory
> 
> This is wat pcheaders.h says:
> 
> # include 
> 
> This file really does not exist.
> 
> Vincent
> 

You could remove these lines. Which boost version does branch use?
Now I realize I've not updated branch when I upgraded trunk.

Peter


Re: Command line problems

2010-03-11 Thread Enrico Forestieri
On Thu, Mar 11, 2010 at 05:22:36PM +0100, Vincent van Ravesteijn wrote:
> Enrico,
>
> 1.
>
> Tex2lyx is not working for me anymore. This is caused by the assertion  
> introduced in r33561:
>
> __wgetmainargs(_, _, , -1, );
> LASSERT(argc == argc_, /**/);
>
> If I call  "tex2lyx -sysdir /path/to/lib -f test.tex", argc = 2 while  
> argc_ = 5.
>
> 2.
>
> When I call "lyx -sysdir /path/to/lib test.lyx", LyX opens with the  
> error message that "-sysdir.lyx" cannot be found.

Should be fixed now.

-- 
Enrico


Re: Tabular code question

2010-03-11 Thread Uwe Stöhr

Am 11.03.2010 21:25, schrieb Vincent van Ravesteijn:


I want to fix the vertical alignment bugs in LyX 1.6 and also trunk.
To be able to do this, I need to calculate the height of the content
of the current cell (not the height of the row). How is this done?


tabular.cellInset(cell)->metrics(m, dim);

See InsetTabular::metrics(). Here the ascent and descent for each cell
in the row is determined and the maximum is set for the whole row.


Thanks for the hint. I'm nevertheless not able to access the metrics inside the draw() routine. 
Attached is a patch that should fix the vertical alignment drawing for normal cells. The problem is 
that it doesn't compile because of an unresolved external:


InsetTabular.obj : error LNK2019: unresolved external symbol "public: __thiscall
 lyx::MetricsInfo::MetricsInfo(void)" (??0metricsi...@lyx@@q...@xz) referenced 
in
 function "public: virtual void __thiscall lyx::InsetTabular::draw(class lyx::Pa
interInfo &,int,int)const " 
(?d...@insettabular@lyx@@ubexaavpainteri...@2@h...@z)

The problem is that the MetricsInfo is not available. I tried to extend the draw() routine so that 
it also grabs the MetricsInfo and the Dimension and not only the PainterInfo but this fails too.

Is there a way to access the metrics?

thanks and regards
Uwe

p.s. I still don't understand how exactly dim.asc is calculated. Where in the 
code is this done?
Index: InsetTabular.cpp
===
--- InsetTabular.cpp	(revision 33720)
+++ InsetTabular.cpp	(working copy)
@@ -3249,6 +3249,7 @@
 	dim.wid = tabular.width() + 2 * ADD_TO_TABULAR_WIDTH;
 }
 
+
 bool InsetTabular::isCellSelected(Cursor & cur, row_type row, col_type col) 
 	const
 {
@@ -3291,6 +3292,7 @@
 	bool const original_selection_state = pi.selected;
 
 	idx_type idx = 0;
+	int cy = 0;
 	first_visible_cell = Tabular::npos;
 	for (row_type r = 0; r < tabular.nrows(); ++r) {
 		int nx = x;
@@ -3309,8 +3311,30 @@
 first_visible_cell = idx;
 
 			pi.selected |= isCellSelected(cur, r, c);
+
+			// set the position for the vertical alignment
+			cy = y;
+			Dimension dim;
+			MetricsInfo m;
+			// determine the cell dimensions
+			tabular.cellInset(idx)->metrics(m, dim);
+			// if the cell height is below the row height then
+			// substract space according to the row height
+			if ((dim.asc + dim.des) < tabular.rowHeight(idx)) {
+cy += tabular.rowHeight(idx)/2;
+switch (tabular.getVAlignment(idx)) {
+	case Tabular::LYX_VALIGN_TOP:
+		break;
+	case Tabular::LYX_VALIGN_MIDDLE:
+		cy -= (dim.asc + dim.des)/2;
+		break;
+	case Tabular::LYX_VALIGN_BOTTOM:
+		cy -= dim.asc + dim.des;
+		break;
+}
+			}
+
 			int const cx = nx + tabular.textHOffset(idx);
-			int const cy = y  + tabular.textVOffset(idx);
 			// Cache the Inset position.
 			bv->coordCache().insets().add(cell(idx).get(), cx, y);
 			cell(idx)->draw(pi, cx, cy);


Re: r33723 - in lyx-devel/trunk/src: . support tex2lyx

2010-03-11 Thread Enrico Forestieri
On Fri, Mar 12, 2010 at 02:18:40AM +0100, for...@lyx.org wrote:
> Author: forenr
> Date: Fri Mar 12 02:18:39 2010
> New Revision: 33723
> URL: http://www.lyx.org/trac/changeset/33723
> 
> Log:
> Fix command line parsing and allow unicode arguments for tex2lyx on Windows.

Jürgen, this is also needed in branch.

> Modified:
>lyx-devel/trunk/src/LyX.cpp
>lyx-devel/trunk/src/support/os.h
>lyx-devel/trunk/src/support/os_cygwin.cpp
>lyx-devel/trunk/src/support/os_unix.cpp
>lyx-devel/trunk/src/support/os_win32.cpp
>lyx-devel/trunk/src/tex2lyx/tex2lyx.cpp
> 
> Modified: lyx-devel/trunk/src/LyX.cpp
> ==
> --- lyx-devel/trunk/src/LyX.cpp   Fri Mar 12 01:27:12 2010(r33722)
> +++ lyx-devel/trunk/src/LyX.cpp   Fri Mar 12 02:18:39 2010(r33723)
> @@ -1133,6 +1133,7 @@
>   // Now, remove used arguments by shifting
>   // the following ones remove places down.
>   if (remove > 0) {
> + os::remove_internal_args(i, remove);
>   argc -= remove;
>   for (int j = i; j < argc; ++j)
>   argv[j] = argv[j + remove];
> 
> Modified: lyx-devel/trunk/src/support/os.h
> ==
> --- lyx-devel/trunk/src/support/os.h  Fri Mar 12 01:27:12 2010(r33722)
> +++ lyx-devel/trunk/src/support/os.h  Fri Mar 12 02:18:39 2010(r33723)
> @@ -49,6 +49,9 @@
>  /// Returns the i-th program argument in utf8 encoding.
>  std::string utf8_argv(int i);
>  
> +/// Removes from the internal copy \p num program arguments starting from \p 
> i.
> +void remove_internal_args(int i, int num);
> +
>  /// Returns the name of the NULL device (/dev/null, null).
>  std::string const & nulldev();
>  
> 
> Modified: lyx-devel/trunk/src/support/os_cygwin.cpp
> ==
> --- lyx-devel/trunk/src/support/os_cygwin.cpp Fri Mar 12 01:27:12 2010
> (r33722)
> +++ lyx-devel/trunk/src/support/os_cygwin.cpp Fri Mar 12 02:18:39 2010
> (r33723)
> @@ -228,6 +228,10 @@
>  }
>  
>  
> +void remove_internal_args(int, int)
> +{}
> +
> +
>  string current_root()
>  {
>   return string("/");
> 
> Modified: lyx-devel/trunk/src/support/os_unix.cpp
> ==
> --- lyx-devel/trunk/src/support/os_unix.cpp   Fri Mar 12 01:27:12 2010
> (r33722)
> +++ lyx-devel/trunk/src/support/os_unix.cpp   Fri Mar 12 02:18:39 2010
> (r33723)
> @@ -52,6 +52,10 @@
>  }
>  
>  
> +void remove_internal_args(int, int)
> +{}
> +
> +
>  string current_root()
>  {
>   return "/";
> 
> Modified: lyx-devel/trunk/src/support/os_win32.cpp
> ==
> --- lyx-devel/trunk/src/support/os_win32.cpp  Fri Mar 12 01:27:12 2010
> (r33722)
> +++ lyx-devel/trunk/src/support/os_win32.cpp  Fri Mar 12 02:18:39 2010
> (r33723)
> @@ -209,6 +209,14 @@
>  }
>  
>  
> +void remove_internal_args(int i, int num)
> +{
> + argc_ -= num;
> + for (int j = i; j < argc_; ++j)
> + argv_[j] = argv_[j + num];
> +}
> +
> +
>  string current_root()
>  {
>   // _getdrive returns the current drive (1=A, 2=B, and so on).
> 
> Modified: lyx-devel/trunk/src/tex2lyx/tex2lyx.cpp
> ==
> --- lyx-devel/trunk/src/tex2lyx/tex2lyx.cpp   Fri Mar 12 01:27:12 2010
> (r33722)
> +++ lyx-devel/trunk/src/tex2lyx/tex2lyx.cpp   Fri Mar 12 02:18:39 2010
> (r33723)
> @@ -381,13 +381,14 @@
>   continue;
>   }
>  
> - string arg(to_utf8(from_local8bit((i + 1 < argc) ? argv[i + 1] 
> : "")));
> - string arg2(to_utf8(from_local8bit((i + 2 < argc) ? argv[i + 2] 
> : "")));
> + string arg = (i + 1 < argc) ? os::utf8_argv(i + 1) : string();
> + string arg2 = (i + 2 < argc) ? os::utf8_argv(i + 2) : string();
>  
>   int const remove = 1 + it->second(arg, arg2);
>  
>   // Now, remove used arguments by shifting
>   // the following ones remove places down.
> + os::remove_internal_args(i, remove);
>   argc -= remove;
>   for (int j = i; j < argc; ++j)
>   argv[j] = argv[j + remove];
> @@ -519,14 +520,15 @@
>  
>   lyxerr.setStream(cerr);
>  
> + os::init(argc, argv);
> +
>   easyParse(argc, argv);
>  
>   if (argc <= 1) 
>   error_message("Not enough arguments.");
> - os::init(argc, argv);
>  
>   try {
> - init_package(internal_path(to_utf8(from_local8bit(argv[0]))),
> + init_package(internal_path(os::utf8_argv(0)),
>

Re: Tabular code question

2010-03-11 Thread Uwe Stöhr

> I assume Uwe wanted the height of the cell content *in the output*

No, I want to calculate the cell height as drawn in LyX. (Exactly as Vincent 
replied me)

thanks and regards
Uwe


LyX's LaTeX preferences dialog needs quick UI overhaul

2010-03-11 Thread Uwe Stöhr

In LyX 2.0svn open the menu Tools->Preferences->Output->LaTeX

You can see that the text fields don't have a uniform left border.
(I would have fixed this right now but my Qt designer currently doesn't work.)

regards Uwe


Re: Mac widgets

2010-03-11 Thread BH
On Thu, Mar 11, 2010 at 2:37 PM, Vincent van Ravesteijn
 wrote:
>
>> I'm not sure if you've already implemented these changes. If so, I
>> don't see any effect and thought it worth reporting that.
>>
>> If not, well ... I'll just wait until you do. No hurry.
>>
>> BH
>>
>
> I've committed some changes in http://www.lyx.org/trac/changeset/33716.
>
> - No more Drawers,
> - ProgressView and SourceView are docked at the bottom,
> - SpellChecker, FindAndReplace and Outline are floating by default, but
> dockable.
>
>
> Please have a look whether it's better now.

Yes, that works well ... at least that's what I asked for. (Thanks!)
Now that I see it, however, I notice some potential problems.

On Mac, it is typical to have one instance of an application open at a
time and for that application to have multiple document windows,
typically with one document per window. Given this, it is typical for
there to be a single set of floating widgets whose content changes to
match the frontmost document window.

This is not how LyX currently works: having multiple windows means
having multiple sets of floating widgets, with no easy way to tell
which widget belongs to which window. That gets confusing fast, and
I'd like to see it changed if possible. (No other Mac program that I'm
aware of works this way.)

Currently, a single window will have only one set of widgets
associated with it, so that switching between tabs of a single window
will cause the widgets to change their contents appropriately. Can
that be the default for multiple windows as well?

BH


Re: Did I ever mention how much I like LyX?

2010-03-11 Thread john
Steve Litt wrote:
> Hi all,
>
> Did I ever mention how much I like LyX? It's wonderful. I'm writing my new 
> book right now, and LyX is so easy and transparent that I'm pounding out an 
> average of 3,000 words per day. LyX just stays out of your way and let's you 
> whomp out content. It's great.
>
> Thanks to the developers for making this great bookmaking software, and the 
> community for making it better and providing information.
>   
Amen to that!
It's my favourite piece of software and has been for more than a decade!

John O'Gorman

> SteveT
>
> Steve Litt
> Recession Relief Package
> http://www.recession-relief.US
> Twitter: http://www.twitter.com/stevelitt
>
>
>
>   



Re: Mac widgets

2010-03-11 Thread Abdelrazak Younes

On 03/12/2010 04:57 AM, BH wrote:

On Thu, Mar 11, 2010 at 2:37 PM, Vincent van Ravesteijn
  wrote:
   
 

I'm not sure if you've already implemented these changes. If so, I
don't see any effect and thought it worth reporting that.

If not, well ... I'll just wait until you do. No hurry.

BH

   

I've committed some changes in http://www.lyx.org/trac/changeset/33716.

- No more Drawers,
- ProgressView and SourceView are docked at the bottom,
- SpellChecker, FindAndReplace and Outline are floating by default, but
dockable.


Please have a look whether it's better now.
 

Yes, that works well ... at least that's what I asked for. (Thanks!)
Now that I see it, however, I notice some potential problems.

On Mac, it is typical to have one instance of an application open at a
time and for that application to have multiple document windows,
typically with one document per window. Given this, it is typical for
there to be a single set of floating widgets whose content changes to
match the frontmost document window.

This is not how LyX currently works: having multiple windows means
having multiple sets of floating widgets, with no easy way to tell
which widget belongs to which window. That gets confusing fast, and
I'd like to see it changed if possible. (No other Mac program that I'm
aware of works this way.)

Currently, a single window will have only one set of widgets
associated with it, so that switching between tabs of a single window
will cause the widgets to change their contents appropriately. Can
that be the default for multiple windows as well?
   


That could (and should) be done but this is not as simple as it may 
seem. The problem is that all dialogs are own and managed by the window 
(GuiView) not by the application (GuiApplication). So, while I agree 
this is wrong and has always been wrong since we are multi-windows 
capbale, it's a bit difficult to do it right now.


Abdel.




Re: donating to LyX project

2010-03-11 Thread Abdelrazak Younes

On 03/11/2010 11:31 AM, Chris Reynolds wrote:

Hello,

We would like to donate to the LyX Project and become your official
sponsors. Could someone in charge of such questions get back to me with our
options.
   


Hello Chris,

Donation from company has been done once in the past, to sponsor a 
development project (see about Beslist.nl in www.lyx.org/Donate). Would 
you company want to sponsor a particular project or is this about a 
general donation?


Abdel.