Re: r14917 - in /lyx-devel/branches/personal/kuemmel/sharedli...

2006-09-07 Thread Andre Poenitz
On Wed, Sep 06, 2006 at 05:40:23PM +0200, Peter Kümmel wrote:
 Peter Kümmel wrote:
  care about it. I just wanna see if it's possible to get Dlls without
  huge changes.
 
 Maybe the design of lyx is s bad that it is not possible. ;)

It is indeed so bad. But that's not new knowledge...

Andre'


Re: r14917 - in /lyx-devel/branches/personal/kuemmel/sharedli...

2006-09-07 Thread Andre Poenitz
On Wed, Sep 06, 2006 at 05:06:08PM +0200, Lars Gullik Bjønnes wrote:
 Isn't it possible to use export lists instead of doing the (imho
 braindead) annotation on all functions?

It is possible. The problem then is to enumerate all the _mangled_ names
in the .def file. That's even worse. Maybe there's a tool for generating 
a list. mingw32 used to have a 'dlltool' IIRC, but yjis probably won't
work in a MSVC environment.

And no, I don't like the EXPORT macro stuff either.

Andre'

-- 


Re: Active table and math toolbar

2006-09-07 Thread Abdelrazak Younes

Michael Gerz wrote:
BTW: bottom is ignored in 1.5.0svn/qt4. The tool bar is always 
displayed at the top. Should I add a bugzilla report?


Yes, I am aware of it an I plaid guilty. Right now the toolbars are 
hard-coded to be at the top because I didn't have the time to fix it 
properly last christmas.


Abdel.



Re: Let's do the same for dialogs! (was Re: [Patch] use enum instead of strings for type of math 'hull' inset)

2006-09-07 Thread Abdelrazak Younes

Andre Poenitz wrote:

On Tue, Sep 05, 2006 at 03:33:36PM +0200, Abdelrazak Younes wrote:

 char const * const dialognames[] = {
 aboutlyx, bibitem, bibtex, box, branch, changes,...

For this I'd actually prefer a factory that's initialized by static
singleton or such.

Could you elaborate a bit please?
The different dialogs are accessed with a string key. The key could as 
well be an int without any difference in behaviour, that's what I mean.


The enum requires a place where all dialogs are known (at least
conceptionally) so that we can define an 


  enum { dialogFoo, dialogBar  }

With a factory (in an ideal world...) we could (in theory...) have a
core completely ignorant of concrete dialogs. 'lfun-insert-inset foo'
would just ask the factory to create a dialog by a generator registered
under the name 'foo'.


I agree that the core should not know about concrete dialog. But I would 
like to be sure that the dialog IDs are exactly the same for all 
frontends. For this I need the enum to be placed in src/frontend/. Then 
each frontend could choose to implement or not a dialog. The code in 
src/frontend/ is an abstraction of the frontend and does not really 
belong to the core.


Abdel.



Re: Shared Libraries

2006-09-07 Thread Abdelrazak Younes

Peter Kümmel wrote:

Andre Poenitz wrote:

On Tue, Sep 05, 2006 at 11:16:14AM +0200, Peter Kümmel wrote:

I have started with frontend/qt4/ but give up because qt4 needs several
functions from the other libs.
We must start at the bottom not at the top, and qt4 is at the top.

Exactly.

The problem with the current architecture is, of, course, that drawing
is 'pushed' by the kernel, not 'pulled' by the frontend (containing th
painter)

Andre'


Yes, building insets is completely hopeless. And this artifact was
nicely hidden by the gcc.
Why has lyx not a mvc design where the model nothing knows about
the view but its base class?


For inset drawing, it will be difficult to achieve easily but that's the 
goal yes.


OTOH, dialogs can and should be converted to a model/view separation. 
Please have a look at the TOC implementation in qt4/.


Abdel.



Re: Shared Libraries

2006-09-07 Thread Abdelrazak Younes

Andre Poenitz wrote:

On Tue, Sep 05, 2006 at 11:16:14AM +0200, Peter Kümmel wrote:

I have started with frontend/qt4/ but give up because qt4 needs several
functions from the other libs.
We must start at the bottom not at the top, and qt4 is at the top.


Exactly.

The problem with the current architecture is, of, course, that drawing
is 'pushed' by the kernel, not 'pulled' by the frontend (containing th
painter)


The plan is of course to change that.

Abdel.



Re: Shared Libraries

2006-09-07 Thread Abdelrazak Younes

Andre Poenitz wrote:

On Tue, Sep 05, 2006 at 10:37:27AM +0200, Abdelrazak Younes wrote:
That's exactly the problem indeed. My earlier cleanup work is heading 
toward the frontend use the kernel as a library design. Once this is 
achieved, splitting out the toolkit specific frontend should be easy. So 
clearly the first candidate for a new dll is the code in frontend/qt4/.


Doesn't that contradict each other?

Shouldn't there be a lyxkernel.dll and the frontend  using this?


The frontend virtual interface yes. The qt4 frontend will just be an 
implementation of this interface and could entirely be in a single dll. 
This way the lyx-executable would not even have to link to Qt4, only the 
qt4 frontend dll.


 

The controller will need some cleanup before it could be split up.


I still think merging the controller into the frontend specific code
would make things a grest deal simpler, more flexible _and_ smaller,
even when using two frontends...


I agree this should be done on a case by case basis. Each dialog 
controller should be reviewed for correctness. A controller should not 
open a dialog for example. The spellchecher controller is an example of 
such bad design.


Abdel.



Re: Shared Libraries

2006-09-07 Thread Abdelrazak Younes

Andre Poenitz wrote:

On Tue, Sep 05, 2006 at 10:59:41AM +0200, Abdelrazak Younes wrote:

Peter Kümmel wrote:


At the current stage the code is full of dependencies,
and some circular could only be solved by moving functions
into a other library.
I think you should forget about the controller for now and concentrated 
on the frontend. Mathed seems also to be a good candidate.


Mathed depends on the core _and_ on the painert stuff, so how could that
be a good candidate to start with?


This was just a guess as the mathed code seems pretty isolated from the 
rest of the LyX code. As you said in an earlier mail, the painter stuff 
needs to be rethought.


Abdel.



Re: [PATCH] Re-introduce layout menu

2006-09-07 Thread Jean-Marc Lasgouttes
 Michael == Michael Gerz [EMAIL PROTECTED] writes:

Michael Nevertheless, at some point in time, we should ask the LyX
Michael users (not the developers) what they would like to see as the
Michael default. Personally, I think that the traditional
Michael Windows/Word/OOo user prefers the classic look  feel but
Michael that is left to be proven. Does anybody read the lyx users
Michael mailing list regularly? What did the old guys say about the
Michael new 1.4 menu structure?

All I can say is that there have been less resistance wrt the menu
structure than I expected. But I cannot tell what this means :)

JMarc


Re: Towards LyX 1.4.3 [status update #1]

2006-09-07 Thread Georg Baum
Jean-Marc Lasgouttes wrote:

 2698  add buttons for \intop and \ointop to math panel
 
   Georg, did you have time to look at the icons? Otherwise, we shall
   postpone.

Now I looked at it. This patch adds the icons from Uwe. OK to go in?


Georg

Log:
Fix bug 2698 (new images from Uwe Stöhr)

* src/frontends/controllers/ControlMath.C
(latex_misc): Add intop and ointop

* lib/images/math/intop.xpm: New
* lib/images/math/ointop.xpm: Ditto

* lib/images/math/int.xpm: Add box to make the difference to intop clear
* lib/images/math/oint.xpm: ditto

* lib/Makefile.am: add new filesIndex: src/frontends/controllers/ControlMath.C
===
--- src/frontends/controllers/ControlMath.C	(Revision 14921)
+++ src/frontends/controllers/ControlMath.C	(Arbeitskopie)
@@ -188,7 +188,7 @@ char const * latex_misc[] = {
 int const nr_latex_misc = sizeof(latex_misc) / sizeof(char const *);
 
 char const * latex_varsz[] = {
-	sum, int, oint,
+	sum, int, intop, oint, ointop,
 	prod, coprod, bigsqcup,
 	bigotimes, bigodot, bigoplus,
 	bigcap, bigcup, biguplus,
Index: status.14x
===
--- status.14x	(Revision 14921)
+++ status.14x	(Arbeitskopie)
@@ -30,6 +30,8 @@ What's new
 - Updated Czech (Tutorial, new splash) and German (UserGuide,
   Extended) documentation.
 
+- Add buttons for \intop and \ointop to the math panel (bug 2698)
+
 ** Bug fixes:
 
 * Document Input/Output
Index: lib/images/math/intop.xpm
===
--- lib/images/math/intop.xpm	(Revision 14921)
+++ lib/images/math/intop.xpm	(Arbeitskopie)
@@ -0,0 +1,41 @@
+/* XPM */
+static char *a[] = {
+/* columns rows colors chars-per-pixel */
+15 32 3 1,
+  c #00,
+. c #00,
+X c None,
+/* pixels */
+XX...XX,
+X.X,
+..XXX.X,
+..XX..X,
+..X,
+XXX..XX,
+XXX..XX,
+XXX..XX,
+XXX..XX,
+XXX..XX,
+XXX..XX,
+XXX..XX,
+XXX..XX,
+XX..XXX,
+XX..XXX,
+XX..XXX,
+XX..XXX,
+XX..XXX,
+XX..XXX,
+XX..XXX,
+XX..XXX,
+X..,
+X..XX..,
+X.XXX..,
+X.X,
+XX...XX,
+XXX,
+.X.X.X.,
+XXX,
+.X.,
+XXX,
+.X.X.X.,
+};
Index: lib/images/math/oint.xpm
===
--- lib/images/math/oint.xpm	(Revision 14921)
+++ lib/images/math/oint.xpm	(Arbeitskopie)
@@ -1,35 +1,35 @@
 /* XPM */
 static char *a[] = {
 /* columns rows colors chars-per-pixel */
-13 26 3 1,
+15 26 3 1,
   c #00,
 . c #00,
 X c None,
 /* pixels */
-X...X,
-.,
-XXX..XXX.,
-XXX..XX..,
-XXX..,
-XX..X,
-XX..X,
-XX..X,
-XX..X,
-.,
-XX...XXXX,
-X..XXX..XX.XX,
-X..XXX..XX.XX,
-X..XX..XXX.XX,
-X...X..XXX.XX,
-XX.X..XXX,
-X,
-X..XX,
-X..XX,
-X..XX,
-X..XX,
-..XXX,
-..XX..XXX,
-.XXX..XXX,
-.,
-X...X
+X...XXX,
+.XX,
+XXX..XXX.XX,
+XXX..XX..XX,
+XXX..XX,
+XX..XXX,
+XX..XXX,
+XX..XXX,
+XX..XXX,
+.XX,
+XX...XX,
+X..XXX..XX.,
+X..XXX..XX.,
+X..XX..XXX.,
+X...X..XXX.,
+XX.X..X,
+XXX,
+X..,
+X..,
+X..,
+X..,
+..XX.X.X.X.,
+..XX..X,
+.XXX..XX.X.,
+.XX,
+X....X.X.X.
 };
Index: lib/images/math/int.xpm
===
--- lib/images/math/int.xpm	(Revision 14921)
+++ lib/images/math/int.xpm	(Arbeitskopie)
@@ -1,48 +1,35 @@
 /* XPM */
-static char const * const int_xpm[] = {
-/* width height ncolors chars_per_pixel */
-18 25 16 1,
-/* colors */
-O c None,
+static char *a[] = {
+/* columns rows colors chars-per-pixel */
+17 26 3 1,
   c #00,
-. c #939393,
-X c #676767,
-o c #3B3B3B,
-+ c #CECECE,
-@ c #0F0F0F,
-# c #B0B0B0,
-$ c #A2A2A2,
-% c #848484,
- c #767676,
-* c #585858,
-= c #4A4A4A,
-- c #2C2C2C,
-; c #1E1E1E,
-: c #BFBFBF,
+. c #00,
+X c None,
 /* pixels */
-OO,
-OO,
-[EMAIL PROTECTED],
-OOO=+O,
-OO#XOO,
-OO%OO,
-OO=:OO,
-[EMAIL PROTECTED],
-O#oOOO,
-OXOOO,
-O*OOO,
-O;$OOO,
-+ +OOO,
-$;,
-X=,
-*X,
--$,
- O,
-OOO#-O,
-OOO.XO,
-OOOX.O,
-OOOo+O,
-OO+-OO,
-O-X%OO,
-O=oOOO
+XX...,
+X.XXX,
+..XXX.XXX,
+..XX..XXX,

Re: USE_CYGWIN_PACKAGING

2006-09-07 Thread Enrico Forestieri
On Wed, Sep 06, 2006 at 09:29:21PM -0500, Bo Peng wrote:

 I plan to refine and apply the attached patch to 1.4.x. This patch
 lets 'scons install' generate the right kind of cygwin binary package
 (with /usr/doc/ ..., strip etc). To better reflect the uniqueness of
 cygwin, I have added USE_CYGWIN_PACKAGING to src/support/package.C,
 which basically says that cygwin has $HOME, and .exe suffix.
 
 JMarc, what do you think about this macro? It is nice to have but it
 is not absolutely needed since I can walk around it in SConstruct.
 Some autotools changes may be needed.

IMO, USE_CYGWIN_PACKAGING is neither needed nor useful. You don't have
to care about the .exe suffix, cygwin takes care of that and in a well
thought manner. Every POSIX program that checks for its own name works
when compiled on cygwin. No need to fiddle with .exe suffix. Please ;-)
Cygwin is POSIX.

-- 
Enrico


Re: r14917 - in /lyx-devel/branches/personal/kuemmel/sharedli...

2006-09-07 Thread Peter Kümmel
Lars Gullik Bjønnes wrote:
 Peter Kümmel [EMAIL PROTECTED] writes:
 
 | Peter Kümmel wrote:
 |  care about it. I just wanna see if it's possible to get Dlls without
 |  huge changes.
 | 
 | Maybe the design of lyx is s bad that it is not possible. ;)
 
 Works without change on linux...
 

Building a dll on windows is like linking
with --no-undefined under linux.

Try to link with this option then you will
see how wired the dependencies are.


-- 
Peter Kümmel



Re: generating project files with cmake

2006-09-07 Thread Peter Kümmel
Georg Baum wrote:
 Joost Verburg wrote:
 
 Abdelrazak Younes wrote:
 Are there any tools available to locate it?
 I've heard good things about valgrind. But it's linux only AFAIK.
 Does anyone know of such a tool for Windows?
 
 I once worked with purify, but that is some time ago. See
 http://www-306.ibm.com/software/awdtools/purifyplus/
 

This was very nice:

http://www.glowcode.com/


 
 If we are going to switch, we should go for Enchant. This is a library
 that makes it is possible to support Aspell/Pspell, Ispell, HunSpell,
 MySpell, Uspell, Hspell and Mac OS X Applespell.
 
 That has been suggested already long time ago. I don't think that it would
 be too difficult to add enchant as an additional spell checker, and if
 everything works drop the other ones.
 
 
 Georg
 
 


-- 
Peter Kümmel


[PATCH] Inset dissolve cleanup

2006-09-07 Thread Jean-Marc Lasgouttes

The following pair of patch implement inset-dissolve in what I believe
to be a clean way. There is no code in insets directory (the disabling
for tabular insets is done by testing inset.nargs() == 1 instead).

Please test.

JMarc

Index: src/insets/insettabular.C
===
--- src/insets/insettabular.C	(revision 14921)
+++ src/insets/insettabular.C	(working copy)
@@ -1045,28 +1045,6 @@ bool InsetTabular::getStatus(LCursor  c
 			return true;
 		}
 
-	case LFUN_INSET_DISSOLVE: {
-		status.enabled(false);
-		return true;
-	}
-
-	// because of the dissolve handling in insettext:
-	case LFUN_CHAR_DELETE_FORWARD:
-		if (!cur.selection()  cur.depth()  1
-		 cur.pit() == cur.lastpit()
-		 cur.pos() == cur.lastpos()) {
-		status.enabled(false);
-		return true;
-		}
-		// Fall through
-
-	case LFUN_CHAR_DELETE_BACKWARD:
-		if (cur.depth()  1  cur.pit() == 0  cur.pos() == 0) {
-		status.enabled(false);
-		return true;
-		}
-		// Fall through
-
 	case LFUN_INSET_MODIFY:
 		if (translate(cmd.getArg(0)) == TABULAR_CODE) {
 			status.enabled(true);
Index: src/insets/insettext.C
===
--- src/insets/insettext.C	(revision 14921)
+++ src/insets/insettext.C	(working copy)
@@ -268,47 +268,14 @@ void InsetText::doDispatch(LCursor  cur
 			   [ cmd.action = 
 			  cmd.action  ']'  endl;
 	setViewCache(cur.bv());
-
-	switch (cmd.action) {
-
-	case LFUN_CHAR_DELETE_FORWARD: {
-		if (!cur.selection()  cur.depth()  1
-		 cur.pit() == cur.lastpit()
-		 cur.pos() == cur.lastpos())
-			// Merge inset with owner
-			cmd = FuncRequest(LFUN_INSET_DISSOLVE);
-		text_.dispatch(cur, cmd);
-		break;
-	}
-
-	case LFUN_CHAR_DELETE_BACKWARD: {
-		if (cur.depth()  1  cur.pit() == 0  cur.pos() == 0)
-			// Merge inset with owner
-			cmd = FuncRequest(LFUN_INSET_DISSOLVE);
-		text_.dispatch(cur, cmd);
-		break;
-	}
-	
-	default:
-		text_.dispatch(cur, cmd);
-		break;
-	}
+	text_.dispatch(cur, cmd);
 }
 
 
 bool InsetText::getStatus(LCursor  cur, FuncRequest const  cmd,
 	FuncStatus  status) const
 {
-	switch (cmd.action) {
-
-	case LFUN_CHAR_DELETE_FORWARD:
-	case LFUN_CHAR_DELETE_BACKWARD:
-		status.enabled(true);
-		return true;
-
-	default:
-		return text_.getStatus(cur, cmd, status);
-	}
+	return text_.getStatus(cur, cmd, status);
 }
 
 
Index: src/lyxtext.h
===
--- src/lyxtext.h	(revision 14921)
+++ src/lyxtext.h	(working copy)
@@ -232,6 +232,8 @@ public:
 	bool backspacePos0(LCursor  cur);
 	/// Delete character before cursor. Honour CT
 	bool backspace(LCursor  cur);
+	// Dissolve the inset under cursor
+	bool dissolveInset(LCursor  cur);
 	///
 	bool selectWordWhenUnderCursor(LCursor  cur, lyx::word_location);
 	///
Index: src/text3.C
===
--- src/text3.C	(revision 14921)
+++ src/text3.C	(working copy)
@@ -79,7 +79,6 @@ using lyx::pos_type;
 
 using lyx::cap::copySelection;
 using lyx::cap::cutSelection;
-using lyx::cap::pasteParagraphList;
 using lyx::cap::pasteSelection;
 using lyx::cap::replaceSelection;
 
@@ -709,34 +708,9 @@ void LyXText::dispatch(LCursor  cur, Fu
 		break;
 	}
 
-	case LFUN_INSET_DISSOLVE: {
-		recordUndoInset(cur);
-		cur.selHandle(false);
-		// save position
-		lyx::pos_type spos = cur.pos();
-		lyx::pit_type spit = cur.pit();
-		ParagraphList plist;
-		if (cur.lastpit() != 0 || cur.lastpos() != 0) 
-			plist = paragraphs();
-		cur.popLeft();
-		// store cursor offset
-		if (spit == 0)
-			spos += cur.pos();
-		spit += cur.pit();
-		cur.paragraph().erase(cur.pos());
-		if (!plist.empty()) {
-			Buffer * b = bv-buffer();
-			pasteParagraphList(cur, plist, b-params().textclass, 
-	   b-errorList(Paste));
-			// restore position
-			cur.pit() = std::min(cur.lastpit(), spit);
-			cur.pos() = std::min(cur.lastpos(), spos);
-		}
-		cur.clearSelection();
-		cur.resetAnchor();
-		needsUpdate = true;
+	case LFUN_INSET_DISSOLVE:
+		needsUpdate = dissolveInset(cur);
 		break;
-	}
 
 	case LFUN_INSET_SETTINGS:
 		cur.inset().showInsetDialog(bv);
@@ -1720,20 +1694,17 @@ bool LyXText::getStatus(LCursor  cur, F
 		enable = lyx::cap::numberOfSelections()  0;
 		break;
 
-	case LFUN_PARAGRAPH_MOVE_UP: {
+	case LFUN_PARAGRAPH_MOVE_UP:
 		enable = cur.pit()  0  !cur.selection();
 		break;
-	}
 
-	case LFUN_PARAGRAPH_MOVE_DOWN: {
+	case LFUN_PARAGRAPH_MOVE_DOWN:
 		enable = cur.pit()  cur.lastpit()  !cur.selection();
 		break;
-	}
 
-	case LFUN_INSET_DISSOLVE: {
-		enable = !isMainText()  cur.inTexted();
+	case LFUN_INSET_DISSOLVE:
+		enable = !isMainText()  cur.inset().nargs() == 1;
 		break;
-	}
 
 	case LFUN_WORD_DELETE_FORWARD:
 	case LFUN_WORD_DELETE_BACKWARD:
Index: src/text.C
===
--- src/text.C	(revision 14921)
+++ src/text.C	(working copy)
@@ -88,6 +88,7 @@ using lyx::support::split;
 using 

Re: Towards LyX 1.4.3 [status update #1]

2006-09-07 Thread Jean-Marc Lasgouttes
 Georg == Georg Baum [EMAIL PROTECTED] writes:

Georg Jean-Marc Lasgouttes wrote:
 2698 add buttons for \intop and \ointop to math panel
 
 Georg, did you have time to look at the icons? Otherwise, we shall
 postpone.

Georg Now I looked at it. This patch adds the icons from Uwe. OK to
Georg go in?

Sure.

JMarc



Re: Active table and math toolbar

2006-09-07 Thread Jean-Marc Lasgouttes
 John == John Levon [EMAIL PROTECTED] writes:

John On Wed, Sep 06, 2006 at 11:01:41PM +0200, Michael Gerz wrote:
 I think this patch (or a similar one) has been discussed already.
 Should I commit it?

John This is a really difficult one to decide. I can see this being
John enormously irritating default behaviour for some people, and we
John don't yet have a View-Toolbars that can easily turn it off. On
John the other hand, these toolbars are extremely useful.

What about a new 'Allow automatic toolbars' lyxrc entry?

Then we could set the default to 'true'.

Or to 'false' :)

JMarc


[PATCH] bug 2600: Change tracking and tables hangs or asserts

2006-09-07 Thread Jean-Marc Lasgouttes

The following patches fix a crash:
http://bugzilla.lyx.org/show_bug.cgi?id=2600

The problem was the assumption that the LyXText of the cursor is the
same as the LyXText of cursor.selBegin.

I think there are still problems with CT and tables, but I propose to
apply at least this one.

I think that the rest of the problem would be fixed by a proper fix to
bug 2510.

JMarc

Index: src/BufferView_pimpl.C
===
--- src/BufferView_pimpl.C	(revision 14926)
+++ src/BufferView_pimpl.C	(working copy)
@@ -749,17 +749,11 @@ bool BufferView::Pimpl::available() cons
 
 Change const BufferView::Pimpl::getCurrentChange()
 {
-	if (!buffer_-params().tracking_changes)
+	if (!buffer_-params().tracking_changes || !cursor_.selection())
 		return Change(Change::UNCHANGED);
 
-	LyXText * text = bv_-getLyXText();
-	LCursor  cur = cursor_;
-
-	if (!cur.selection())
-		return Change(Change::UNCHANGED);
-
-	return text-getPar(cur.selBegin().pit()).
-			lookupChangeFull(cur.selBegin().pos());
+	DocIterator dit = cursor_.selectionBegin();
+	return dit.paragraph().lookupChangeFull(dit.pos());
 }
 
 
Index: src/BufferView_pimpl.C
===
--- src/BufferView_pimpl.C	(revision 14924)
+++ src/BufferView_pimpl.C	(working copy)
@@ -586,17 +586,11 @@ bool BufferView::Pimpl::available() cons
 
 Change const BufferView::Pimpl::getCurrentChange()
 {
-	if (!buffer_-params().tracking_changes)
+	if (!buffer_-params().tracking_changes || !cursor_.selection())
 		return Change(Change::UNCHANGED);
 
-	LyXText * text = bv_-getLyXText();
-	LCursor  cur = cursor_;
-
-	if (!cur.selection())
-		return Change(Change::UNCHANGED);
-
-	return text-getPar(cur.selBegin().pit()).
-			lookupChange(cur.selBegin().pos());
+	DocIterator dit = cursor_.selectionBegin();
+	return dit.paragraph().lookupChange(dit.pos());
 }
 
 


Re: Towards LyX 1.4.3 [status update #1]

2006-09-07 Thread Enrico Forestieri
On Fri, Aug 25, 2006 at 05:05:04PM +0200, Jean-Marc Lasgouttes wrote:
 
 We have come a long way towards 1.4.3, so now is the time to think
 about a release. I will be in vacation again next week, so the date
 should be some time at the beginning of September.

Please JMarc, could the attached patch be applied to 1.4.x?

It is about small fixes for the cygwin target:
- Cygwin does not have locale support, so the warning about
  Locale xx_XX could not be set is bogus.
- Some unnecessary path conversions are avoided.
- When the fronted is Qt3/X11, it is not necessary that external_path
  and external_path_list return a windows style path.

Thanks in advance.

-- 
Enrico
Index: src/ChangeLog
===
--- src/ChangeLog   (revision 14926)
+++ src/ChangeLog   (working copy)
@@ -1,3 +1,8 @@
+1006-09-07  Enrico Forestieri [EMAIL PROTECTED]
+
+   * messages.C (Messages::get): don't warn about locale on cygwin
+   as it is not supported.
+
 2006-08-19  Jean-Marc Lasgouttes  [EMAIL PROTECTED]
 
* BufferView_pimpl.C (focusChange): new method; updates the
Index: src/support/ChangeLog
===
--- src/support/ChangeLog   (revision 14926)
+++ src/support/ChangeLog   (working copy)
@@ -1,3 +1,11 @@
+2006-09-07  Enrico Forestieri  [EMAIL PROTECTED]
+   * os_cygwin.C (is_windows_path): avoid unnecessary conversion
+   when path is relative
+   (convert_path_list): avoid unnecessary conversion when path
+   list is empty
+   (external_path, external_path_list): for an X11 build it is not
+   necessary that the output path style is windows
+
 2006-06-27  Enrico Forestieri  [EMAIL PROTECTED]
 
* os.h: rename cygwin_path_fix as windows_style_tex_paths.
Index: src/support/os_cygwin.C
===
--- src/support/os_cygwin.C (revision 14926)
+++ src/support/os_cygwin.C (working copy)
@@ -55,8 +55,7 @@ bool is_posix_path(string const  p)
 
 bool is_windows_path(string const  p)
 {
-   return p.empty() ||
-   (!contains(p, '\\')  (p.length() = 1 || p[1] == ':'));
+   return p.empty() || (!contains(p, '\\')  p[0] != '/');
 }
 
 
@@ -87,6 +86,9 @@ string convert_path(string const  p, Pa
 
 string convert_path_list(string const  p, PathStyle const  target)
 {
+   if (p.empty())
+   return p;
+
char const * const pc = p.c_str();
PathStyle const actual = cygwin_posix_path_list_p(pc) ? posix : windows;
 
@@ -186,7 +188,11 @@ string::size_type common_path(string con
 
 string external_path(string const  p)
 {
+#ifdef X_DISPLAY_MISSING
return convert_path(p, PathStyle(windows));
+#else
+   return convert_path(p, PathStyle(posix));
+#endif
 }
 
 
@@ -198,7 +204,11 @@ string internal_path(string const  p)
 
 string external_path_list(string const  p)
 {
+#ifdef X_DISPLAY_MISSING
return convert_path_list(p, PathStyle(windows));
+#else
+   return convert_path_list(p, PathStyle(posix));
+#endif
 }
 
 
Index: src/messages.C
===
--- src/messages.C  (revision 14926)
+++ src/messages.C  (working copy)
@@ -126,10 +126,10 @@ public:
 #endif
// setlocale fails (returns NULL) if the corresponding locale
// is not installed.
-   // On windows (mingw) it always returns NULL.
+   // On windows (mingw and cygwin) it always returns NULL.
// Since this method gets called for every translatable
// buffer string like e.g. Figure: we warn only once.
-#ifndef _WIN32
+#if !defined(_WIN32)  !defined(__CYGWIN__)
static bool warned = false;
if (!warned  !lc_msgs) {
warned = true;


Re: inset-dissolve

2006-09-07 Thread Helge Hafting

Michael Gerz wrote:

Hi Jürgen,

inset-dissolve is still broken: If you open a new document, the 
function is enabled (which wrong) as you can see in the menu. If you 
want to dissolve the non-existent inset nevertheless, LyX crashes.

But this is correct behaviour!
You dissolve the empty document - lyx indeed goes away! ;-)

Helge Hafting


Re: Towards LyX 1.4.3 [status update #1]

2006-09-07 Thread Martin Vermeer
On Mon, 2006-09-04 at 11:08 +0200, Juergen Spitzmueller wrote:
 Jean-Marc Lasgouttes wrote:
  My question now is whether to put this in 1.4.3 or 1.4.4. I tend to think
  it will be 1.4.4, but I am not fixed on that.
 
 I tend to think so, too, for testing reasons. Let's put the patch in soon 
 after 1.4.3 is released, so that people who use 1.4svn for daily work (like 
 me) can text it under real life conditions before releasing.
 
 Jürgen

I second that. Thanks for the offer :-)

- Martin



signature.asc
Description: This is a digitally signed message part


fs_extras compile fails (errno not declared in this scope)

2006-09-07 Thread Kayvan A. Sylvan
if /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. 
-I../../src   -I./.. -I../../boost -Wextra -Wall-I/usr/X11R6/include  -O2 
-MT fs_extras.lo -MD -MP -MF .deps/fs_extras.Tpo -c -o fs_extras.lo 
fs_extras.C; \
then mv -f .deps/fs_extras.Tpo .deps/fs_extras.Plo; else rm -f 
.deps/fs_extras.Tpo; exit 1; fi
 g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./.. -I../../boost -Wextra -Wall 
-I/usr/X11R6/include -O2 -MT fs_extras.lo -MD -MP -MF .deps/fs_extras.Tpo -c 
fs_extras.C -o fs_extras.o
fs_extras.C: In function 'void boost::filesystem::copy_file(const 
boost::filesystem::path, const boost::filesystem::path, bool)':
fs_extras.C:101: error: 'errno' was not declared in this scope
fs_extras.C:107: error: 'errno' was not declared in this scope
fs_extras.C:120: error: 'errno' was not declared in this scope
fs_extras.C:148: error: 'errno' was not declared in this scope
make[6]: *** [fs_extras.lo] Error 1
make[6]: Leaving directory 
`/home/kayvan/rpmbuild/BUILD/lyx-1.5.0svn/src/support'
make[5]: *** [all-recursive] Error 1
make[5]: Leaving directory 
`/home/kayvan/rpmbuild/BUILD/lyx-1.5.0svn/src/support'
make[4]: *** [all] Error 2
make[4]: Leaving directory 
`/home/kayvan/rpmbuild/BUILD/lyx-1.5.0svn/src/support'
-- 
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 | my beautiful Queen.| Robin Gregory (2/28/92)


pgpmq69amdoxc.pgp
Description: PGP signature


Re: Towards LyX 1.4.3 [status update #1]

2006-09-07 Thread Georg Baum
Jean-Marc Lasgouttes wrote:

 2660  patch   german userguide broken
 
   What remains to be done is copy the icons and update Makefile.am.
   Please, someone...

I just did that (and found two more invalid image paths). We need some lint
for .lyx files.


Georg



Re: fs_extras compile fails (errno not declared in this scope)

2006-09-07 Thread Georg Baum
Kayvan A. Sylvan wrote:

 fs_extras.C:101: error: 'errno' was not declared in this scope
 fs_extras.C:107: error: 'errno' was not declared in this scope
 fs_extras.C:120: error: 'errno' was not declared in this scope
 fs_extras.C:148: error: 'errno' was not declared in this scope make[6]:

This is fixed now. errno.h was not included.


Georg



Re: fs_extras compile fails (errno not declared in this scope)

2006-09-07 Thread Lars Gullik Bjønnes
Georg Baum [EMAIL PROTECTED] writes:

| Kayvan A. Sylvan wrote:
| 
|  fs_extras.C:101: error: 'errno' was not declared in this scope
|  fs_extras.C:107: error: 'errno' was not declared in this scope
|  fs_extras.C:120: error: 'errno' was not declared in this scope
|  fs_extras.C:148: error: 'errno' was not declared in this scope make[6]:
| 
| This is fixed now. errno.h was not included.

and should not be included ... we want cerrno

-- 
Lgb



Re: USE_CYGWIN_PACKAGING

2006-09-07 Thread Bo Peng

IMO, USE_CYGWIN_PACKAGING is neither needed nor useful. You don't have


In the patch, I use packaging_method == 'cygwin' to install files as
instructed by cygwin-packaging standard. I can use platform ==
'cygwin' but the former seems to be more logical. Also, it might not
be at all useful, but the packaging option (both autotools and scons)
allows us to make packages cross-platformly.

Bo


Re: Towards LyX 1.4.3 [status update #1]

2006-09-07 Thread Jean-Marc Lasgouttes
 Georg == Georg Baum [EMAIL PROTECTED] writes:

Georg Jean-Marc Lasgouttes wrote:
 2660 patch german userguide broken
 
 What remains to be done is copy the icons and update Makefile.am.
 Please, someone...

Georg I just did that (and found two more invalid image paths). We
Georg need some lint for .lyx files.

Thanks a lot!

JMarc


Re: fs_extras compile fails (errno not declared in this scope)

2006-09-07 Thread Georg Baum
Lars Gullik Bjønnes wrote:

 and should not be included ... we want cerrno

Why? I don't know any advantage, only a disadvantage: Some compilers do not
have it.


Georg



Re: please complete short Questionnaire for Developers (part of a user interface study)

2006-09-07 Thread Abdelrazak Younes

Daryl Hepting wrote:

Lyx Developer Questionnaire

This questionnaire will be used by students of the CS305 course at the 
University of Regina to inform their semester’s work.  Results of this

work will be contributed back to the lyx project.  All replies sent to me
directly ([EMAIL PROTECTED]) will 
have all identifying information

removed before anyone else sees them.  This course project study has been
approved by the Research Ethics Board at the University of Regina
([EMAIL PROTECTED]).  If any 
publication follows the semester’s

work, your replies will not be directly quoted and your responses will
not be identifiable. [If you would like to be identified and associated
with your comments, please indicate that to me in your reply.]  Your
completion (and return) of this questionnaire implies your consent for
the uses stated above.

Why did you choose to become involved with the lyx project?


I wanted to learn Qt and contribute something to LyX. Porting LyX from 
Qt3 to Qt4 seemed to be an easy enough task. I didn't know at the time 
how much time this project will suck in my life...




How would you describe the vision for the lyx project, and why?


The best portable document writing tool ever.



For whom is lyx intended?


Hopefully to anybody willing to spend half a day reading the Tutorial. 
It's the optimal tool for Scientists and I've heard for Linguists too.




Are there any comments you’d like to share about your experience
with the lyx project?


Come on-board, plenty of things to do here!

Abdel.



Re: Towards LyX 1.4.3 [status update #1]

2006-09-07 Thread José Matos
On Thursday 07 September 2006 13:50, Georg Baum wrote:
 I just did that (and found two more invalid image paths). We need some lint
 for .lyx files.

  It is on my todo list, FWIW. :-)

 Georg

-- 
José Abílio


Re: please complete short Questionnaire for Developers (part of a user interface study)

2006-09-07 Thread Bo Peng

Why did you choose to become involved with the lyx project?


I like lyx, I was between jobs, and I find that it is easier to
contribute than arguing in the mailing list and waiting for months
(years?) for a feature to be implemented.


How would you describe the vision for the lyx project, and why?


The best tool for tech writing.


For whom is lyx intended?


People who have higher standard for the look of their article (book
etc), need to write lots of formula, willing to learn a bit latex and
read some tutorials about lyx.

Bo


Re: fs_extras compile fails (errno not declared in this scope)

2006-09-07 Thread Jean-Marc Lasgouttes
 Georg == Georg Baum [EMAIL PROTECTED] writes:

Georg Lars Gullik Bjønnes wrote:
 and should not be included ... we want cerrno

Georg Why? I don't know any advantage, only a disadvantage: Some
Georg compilers do not have it.

I think all compilers have it now.

JMarc


Re: fs_extras compile fails (errno not declared in this scope)

2006-09-07 Thread Georg Baum
Jean-Marc Lasgouttes wrote:

 Georg == Georg Baum
 [EMAIL PROTECTED]
 writes:
 
 Georg Lars Gullik Bjønnes wrote:
 and should not be included ... we want cerrno
 
 Georg Why? I don't know any advantage, only a disadvantage: Some
 Georg compilers do not have it.
 
 I think all compilers have it now.

OK I changed it, but I am still curious to hear why cerrno is better.


Georg



Re: Shared Libraries

2006-09-07 Thread Andre Poenitz
On Thu, Sep 07, 2006 at 09:39:13AM +0200, Abdelrazak Younes wrote:
 Shouldn't there be a lyxkernel.dll and the frontend  using this?
 
 The frontend virtual interface yes. The qt4 frontend will just be an 
 implementation of this interface and could entirely be in a single dll. 
 This way the lyx-executable would not even have to link to Qt4, only the 
 qt4 frontend dll.

I am not sure there needs to be a virtual frontend interface at all.

In theory, ther kernel could be completely ignorant of any frontend and
just signal internal changes.

A frontend would directly call into the kernel to make things happen and
adjust afterwards by listening to the signals.

IMO a common frontend base is a design mistake that puts things downside
up: The kernel tells the frontend to draw and listen to events from the
frontend. No good.

Andre'


Re: r14917 - in /lyx-devel/branches/personal/kuemmel/sharedli...

2006-09-07 Thread Andre Poenitz
On Thu, Sep 07, 2006 at 11:29:05AM +0200, Peter Kümmel wrote:
 Lars Gullik Bjønnes wrote:
  Peter Kümmel [EMAIL PROTECTED] writes:
  
  | Peter Kümmel wrote:
  |  care about it. I just wanna see if it's possible to get Dlls without
  |  huge changes.
  | 
  | Maybe the design of lyx is s bad that it is not possible. ;)
  
  Works without change on linux...
  
 
 Building a dll on windows is like linking
 with --no-undefined under linux.

--no-undefined plus -Bsymbolic plus explicit symbol export plus separate
heaps plus some 'minor' details.

Andre'


Re: Shared Libraries

2006-09-07 Thread Andre Poenitz
On Thu, Sep 07, 2006 at 09:41:55AM +0200, Abdelrazak Younes wrote:
 Mathed depends on the core _and_ on the painert stuff, so how could that
 be a good candidate to start with?
 
 This was just a guess as the mathed code seems pretty isolated from the 
 rest of the LyX code. As you said in an earlier mail, the painter stuff 
 needs to be rethought.

Mathed is indeed pretty isolated in the sense that even largish internal
changes do not affect the rest much. However, it is not easily
separable into a self-contained library.

Andre'


Re: Shared Libraries

2006-09-07 Thread Andre Poenitz
On Wed, Sep 06, 2006 at 08:49:35PM +0200, Peter Kümmel wrote:
  The problem with the current architecture is, of, course, that drawing
  is 'pushed' by the kernel, not 'pulled' by the frontend (containing th
  painter)
 
 Yes, building insets is completely hopeless. And this artifact was
 nicely hidden by the gcc.
 Why has lyx not a mvc design where the model nothing knows about
 the view but its base class?

Because LyX architecture is ten years old and mvc wasn't exactly hyped
at this time?

Andre'


Re: Shared Libraries

2006-09-07 Thread Andre Poenitz
On Thu, Sep 07, 2006 at 09:30:18AM +0200, Abdelrazak Younes wrote:
 Andre Poenitz wrote:
 On Tue, Sep 05, 2006 at 11:16:14AM +0200, Peter Kümmel wrote:
 I have started with frontend/qt4/ but give up because qt4 needs several
 functions from the other libs.
 We must start at the bottom not at the top, and qt4 is at the top.
 
 Exactly.
 
 The problem with the current architecture is, of, course, that drawing
 is 'pushed' by the kernel, not 'pulled' by the frontend (containing th
 painter)
 
 The plan is of course to change that.

Of course.

Last time I tried it I got stuck somewhere between
updateInsetInInset and tabulators in MathParInset...

Andre'


Re: Active table and math toolbar

2006-09-07 Thread Michael Gerz

Jean-Marc Lasgouttes schrieb:

John This is a really difficult one to decide. I can see this being
John enormously irritating default behaviour for some people, and we
John don't yet have a View-Toolbars that can easily turn it off. On
John the other hand, these toolbars are extremely useful.

What about a new 'Allow automatic toolbars' lyxrc entry?

Then we could set the default to 'true'.

Or to 'false' :)
  

In that case, the current UI file design does not make sense any longer.

Anyway, there are at least three people among us who would like to see a 
short-term solution. See


  http://bugzilla.lyx.org/show_bug.cgi?id=2813

Why don't we activate the toolbars for now (and for 1.4.3)? The 
activation is not a showstopper in case someone wants to optimize the 
look  feel later.


Michael


Re: [PATCH] Re-introduce layout menu

2006-09-07 Thread Michael Gerz

John Levon schrieb:

What would be REALLY cool is some actual UI testing in a proper lab
infrastructure. But slightly cool would be something that collected
real-life data on menu use, and allowed us to collect it (modulo privacy
concerns etc.)

Asking a self-selecting population is notoriously tricky for getting
meaningful answers.
  
How about my recent Character Style patch? Is this something in the 
spirit of your GUI design (most important things first etc.)?


Michael


Re: [PATCH] Inset dissolve cleanup

2006-09-07 Thread Michael Gerz

Jean-Marc Lasgouttes schrieb:

The following pair of patch implement inset-dissolve in what I believe
to be a clean way. There is no code in insets directory (the disabling
for tabular insets is done by testing inset.nargs() == 1 instead).

Please test.
  
inset-dissolve works for 1.5.0, even with nested insets! (I am not able 
to test 1.4.X right now)


Just one cosmetic issue: If you want to undo inset-dissolve, you have to 
press CTRL-Z twice. This might be a bit disturbing for some users.


Michael


Re: [PATCH] Re-introduce layout menu

2006-09-07 Thread Martin Vermeer
On Wed, Sep 06, 2006 at 11:29:58PM +0200, Michael Gerz wrote:
 John, JMarc,
 
 what do you think about the patch below? The idea is to have a submenu 
 for character styles that combines layout-specific char styles, 
 bold/emphasize/noun style, and the font dialog. The layout-specific char 
 styles have been moved from menu Insert. Although the styles are 
 actually implemented as insets, the user does not think in terms of 
 inserting something. Bold/emphasize/noun style - whether you like it 
 or not - are frequently requested features. There is at least one 
 bugzilla report for re-adding bold to the menu. The font dialog is 
 listed at the end (Other...) because users should not be encouraged to 
 use it often. Regarding the word-* functions:  We might move them to the 
 submenu as well to shorten the Edit menu (as done in the patch). 
 However, after testing word-capitalize, I really doubt that this 
 particular functions is very useful (why do we have it at all?).
 
 Any comments?
 
 Michael

 
This looks very nice to me.

- Martin
 
 Index: stdmenus.ui
 ===
 --- stdmenus.ui(revision 14919)
 +++ stdmenus.ui(working copy)
 @@ -89,14 +89,10 @@
 Separator
 Item Find  Replace...|F dialog-show findreplace
 Separator
 -Item Word in Small Capitals word-capitalize
 -Item Word in Uppercase word-upcase
 -Item Word in Lowercase word-lowcase
 -Separator
 Item Move Paragraph Up|o paragraph-move-up
 Item Move Paragraph Down|v paragraph-move-down
 Separator
 -Item Text Style...|S dialog-show character
 +Submenu Character Style...|C insert_charstyles
 Item Paragraph Settings...|P layout-paragraph
 Separator
 # Mathed b0rkage means these don't work properly
 @@ -136,6 +132,19 @@
 PasteRecent
 End
 
 +Menu insert_charstyles
 +CharStyles
 +Separator
 +Item Emphasize Style|E font-emph
 +Item Noun Style|N font-noun
 +Item Bold Style|B font-bold
 +Separator
 +Item Other...|O dialog-show character
 +Separator
 +Item Uppercase word-upcase
 +Item Lowercase word-lowcase
 +End
 +
 # not much we can do to help here
 Menu edit_tabular
 Item Multicolumn|M tabular-feature multicolumn
 @@ -253,7 +262,6 @@
 # YUCK
 Submenu Note|N insert_note
 OptSubmenu Branch|B insert_branches
 -OptSubmenu Character Style|y insert_charstyles
 Submenu File|e insert_file
 Item Box box-insert Frameless
 Separator
 @@ -377,10 +385,6 @@
 Branches
 End
 
 -Menu insert_charstyles
 -CharStyles
 -End
 -
 #
 # DOCUMENT MENU
 #
 



pgpH4y6x618o6.pgp
Description: PGP signature


Re: USE_CYGWIN_PACKAGING

2006-09-07 Thread Bo Peng

On 9/7/06, Bo Peng [EMAIL PROTECTED] wrote:

 IMO, USE_CYGWIN_PACKAGING is neither needed nor useful. You don't have


Hi, Enrico,

Could you please apply the attached patch, install scons-local, run

python scons.py -f development/scons/SConstruct DESTDIR=cygwin_test
mode=release install

and check if the files are correctly installed as described in
http://cygwin.com/setup.html ?

I have also attached the required  setup.hint.

Bo
Index: development/scons/SConstruct
===
--- development/scons/SConstruct	(revision 14932)
+++ development/scons/SConstruct	(working copy)
@@ -54,6 +54,7 @@
 # some global settings
 #
 package_version = '1.4.3svn'
+package_cygwin_version = '1.4.3svn-1'
 boost_version = '1_32'
 
 devel_version = True
@@ -397,14 +398,14 @@
 share_dir = 'Resources'
 man_dir = 'Resources/man/man1'
 locale_dir = 'Resources/locale'
-default_prefix = 'c:/program files/lyx'
 else:
 share_dir = 'share/lyx'
-man_dir = 'man/man1'
 locale_dir = 'share/locale'
-default_prefix = '/usr/local/'
+if platform_name == 'cygwin':
+man_dir = 'share/man/man1'
+else:
+man_dir = 'man/man1'
 
-# install to default_prefix by default
 # program suffix: can be yes, or a string
 if env.has_key('version_suffix'):
 if env['version_suffix'] in true_strings:
@@ -792,6 +793,14 @@
 else:
 env['MSGFMT'] = env_cache['MSGFMT']
 
+# cygwin packaging requires the binaries to be stripped
+if platform_name == 'cygwin':
+if not fast_start:
+env['STRIP'] = conf.CheckCommand('strip')
+env_cache['STRIP'] = env['STRIP']
+else:
+env['STRIP'] = env_cache['STRIP']
+
 # check uic and moc commands for qt frontends
 if not fast_start:
 if frontend[:2] == 'qt' and (conf.CheckCommand('uic') == None \
@@ -1331,7 +1340,7 @@
 # for details
 #
 if platform_name == 'cygwin':
-ld_script_path = '/usr/lib/qt3/mkspecs/cygwin-g++'
+ld_script_path = '/tmp'
 ld_script = utils.installCygwinLDScript(ld_script_path)
 env.AppendUnique(LINKFLAGS = ['-Wl,--enable-runtime-pseudo-reloc',
 '-Wl,--script,%s' % ld_script, '-Wl,-s'])
@@ -2008,23 +2017,21 @@
 else:
 version_suffix = ''
 #
-# install lyx
-target_name = os.path.split(str(lyx[0]))[1].replace('lyx', 'lyx%s' % version_suffix)
-target = os.path.join(bin_dest_dir, target_name)
-env.InstallAs(target, lyx)
-Alias('install', target)
-#
-# install tex2lyx
-target_name = os.path.split(str(tex2lyx[0]))[1].replace('tex2lyx', 'tex2lyx%s' % version_suffix)
-target = os.path.join(bin_dest_dir, target_name)
-env.InstallAs(target, tex2lyx)
-Alias('install', target)
-#
-# install lyxclient, may not exist
-if client != None:
-target_name = os.path.split(str(client[0]))[1].replace('client', 'client%s' % version_suffix)
+# install lyx, if in release mode, try to strip the binary
+if env.has_key('STRIP') and env['STRIP'] is not None and mode != 'debug':
+# create a builder to strip and install
+env['BUILDERS']['StripInstallAs'] = Builder(action='$STRIP $SOURCE -o $TARGET')
+
+# install executables
+for (name, obj) in (('lyx', lyx), ('tex2lyx', tex2lyx), ('client', client)):
+if obj is None:
+continue
+target_name = os.path.split(str(obj[0]))[1].replace(name, '%s%s' % (name, version_suffix))
 target = os.path.join(bin_dest_dir, target_name)
-env.InstallAs(target, client)
+if env['BUILDERS'].has_key('StripInstallAs'):
+env.StripInstallAs(target, obj)
+else:
+env.InstallAs(target, obj)
 Alias('install', target)
 #
 # share/lyx
@@ -2046,14 +2053,27 @@
 ('lyx2lyx', lib_lyx2lyx_files)]:
 dirs.append(env.Install(os.path.join(share_dest_dir, dir),
 [env.subst('$TOP_SRCDIR/lib/%s/%s' % (dir, file)) for file in files]))
+Alias('install', dirs)
 
+if platform_name == 'cygwin':
+# cygwin packaging requires a file /usr/share/doc/Cygwin/foot-vendor-suffix.README
+Cygwin_README = os.path.join(dest_prefix_dir, 'doc', 'Cygwin', 
+'%s%s.README' % (package, package_cygwin_version))
+env.InstallAs(Cygwin_README,
+os.path.join(env.subst('$TOP_SRCDIR'), 'README.cygwin'))
+Alias('install', Cygwin_README)
+# also a directory /usr/share/doc/lyx for README etc
+Cygwin_Doc = os.path.join(dest_prefix_dir, 'doc', package)
+env.Install(Cygwin_Doc, [os.path.join(env.subst('$TOP_SRCDIR'), x) for x in \
+['INSTALL', 'README', 'README.Cygwin', 'RELEASE-NOTES', 'COPYING', 'ANNOUNCE']])
+Alias('install', Cygwin_Doc)
+
 # lyx1.4.x does not have lyx2lyx_version.py.in
 if os.path.isfile(env.subst('$TOP_SRCDIR/lib/lyx2lyx/lyx2lyx_version.py.in')):
 # subst and install this file
 env.substFile(share_dest_dir + 

Re: [PATCH] Inset dissolve cleanup

2006-09-07 Thread Jean-Marc Lasgouttes
 Michael == Michael Gerz [EMAIL PROTECTED] writes:

Michael Just one cosmetic issue: If you want to undo inset-dissolve,
Michael you have to press CTRL-Z twice. This might be a bit
Michael disturbing for some users.

I know that, but I have not been able to avoid it. It is because we
use the cut and paste machinery, which does its own undo. I really
think it should not, if this is possible.

Thanks for testing.

JMarc


Re: Shared Libraries

2006-09-07 Thread Jean-Marc Lasgouttes
 Andre == Andre Poenitz [EMAIL PROTECTED] writes:

Andre Because LyX architecture is ten years old and mvc wasn't
Andre exactly hyped at this time?

Well, LyX is not older than smalltalk...

JMarc


Re: [PATCH] Re-introduce layout menu

2006-09-07 Thread John Levon
On Thu, Sep 07, 2006 at 09:07:17PM +0200, Michael Gerz wrote:

 John Levon schrieb:
 What would be REALLY cool is some actual UI testing in a proper lab
 infrastructure. But slightly cool would be something that collected
 real-life data on menu use, and allowed us to collect it (modulo privacy
 concerns etc.)
 
 Asking a self-selecting population is notoriously tricky for getting
 meaningful answers.
   
 How about my recent Character Style patch? Is this something in the 
 spirit of your GUI design (most important things first etc.)?

I'm at a conference right now, I'll try and look tonight?

john


Re: Active table and math toolbar

2006-09-07 Thread John Levon
On Thu, Sep 07, 2006 at 08:54:38PM +0200, Michael Gerz wrote:

 Why don't we activate the toolbars for now (and for 1.4.3)? The 
 activation is not a showstopper in case someone wants to optimize the 
 look  feel later.

Let's activate it for 1.5.0svn and see what happens, but not 1.4...

regards
john


Re: USE_CYGWIN_PACKAGING

2006-09-07 Thread Enrico Forestieri
On Thu, Sep 07, 2006 at 03:02:59PM -0500, Bo Peng wrote:
 On 9/7/06, Bo Peng [EMAIL PROTECTED] wrote:
  IMO, USE_CYGWIN_PACKAGING is neither needed nor useful. You don't have
 
 Hi, Enrico,
 
 Could you please apply the attached patch, install scons-local, run
 
 python scons.py -f development/scons/SConstruct DESTDIR=cygwin_test
 mode=release install

I had already installed scons, so I ran scons -f ..., instead.
I have not installed the boost libraries, so included boost was used.
Scons detected that I have Aiksaurus and compilation went smooth
till the final link stage which however failed as follows:

g++ -o release/qt2/lyx.exe -Wl,--enable-runtime-pseudo-reloc 
-Wl,--script,/tmp/i386pe.x-no-rdata -Wl,-s release/common/main.o -Lrelease/libs 
-L/usr/lib/qt3/lib -L/usr/X11R6/lib -llyxbase_pre -lmathed -linsets -lfrontends 
-lqt2 -lcontrollers -lgraphics -lsupport -llyxbase_post 
-lincluded_boost_signals -lincluded_boost_regex -lincluded_boost_filesystem 
-lqt-mt -lintl -lshlwapi -lstdc++ -lz -liconv -lgdi32 -lAiksaurus -laspell
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot 
find -lAiksaurus
collect2: ld returned 1 exit status
scons: *** [release/qt2/lyx.exe] Error 1
scons: building terminated because of errors.

After I added extra_lib_path=/usr/local/lib to the scons command line
(libAiksaurus.dll.a is there) everything went fine till the end.

 and check if the files are correctly installed as described in
 http://cygwin.com/setup.html ?

It seems ok to me. However, don't be afraid, they (cygwin-apps) will tell
you if something needs to be tuned.

 Index: README.Cygwin
 ===
 --- README.Cygwin (revision 14932)
 +++ README.Cygwin (working copy)
 @@ -1,32 +1,44 @@
  LyX/Cygwin
 +==
 +
  Ruurd Reitsma  [EMAIL PROTECTED]
 +Bo Peng ben.bob#gmail.com
  
 -There are two ways to run LyX on Windows:
 -* as a native Windows application, using the Qt/Win Free clone of
 -  Trolltech's cross-platform Qt toolkit.
 -* as a POSIX application running under the Cygwin environment.
  
  This README describes what is needed for the latter of these two
  options. Please refer to README.Win32 if you'd like to run LyX
  as a native Windows application.

Maybe the previous last three lines should be deleted, too?

 +
 +Hide the cygwin console
 +===
 +
  If you want to run LyX with no console windows open, there's a small
  program in development/Win32 that will set the proper environment vars
  and start LyX.

I am afraid both lyxwin32.c and lyxprofile are not in development/Win32
anymore...

I am attaching here a small script which will help you spotting dependencies.
Launching it with a directory name as an argument (chkdep dir), it will
scan that directory for executables and libraries and tells you the names
of the packages containing the needed dynamic libraries.

I also suggest that you apply this patch for the cygwin distribution:
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg100129.html
(in case JMarc does not agree to apply it to 1.4.x) as you are allowed
to apply local patches to the upstream sources.

-- 
Enrico
#!/bin/sh
find $1 -name '*.exe' -o -name '*.dll' -o -name '*.bin' | \xargs cygcheck | \
   sed -e '/\.exe/d' -e 's,\\,/,g' | sort -bu | \
   xargs -n1 cygpath -u | xargs cygcheck -f | uniq


Re: USE_CYGWIN_PACKAGING

2006-09-07 Thread Bo Peng

I have not installed the boost libraries, so included boost was used.


Even if you have installed boost, the included boost will be used
after a version check.


Scons detected that I have Aiksaurus and compilation went smooth
till the final link stage which however failed as follows:
After I added extra_lib_path=/usr/local/lib to the scons command line
(libAiksaurus.dll.a is there) everything went fine till the end.


This is something need to be fixed. I will have a look.


scan that directory for executables and libraries and tells you the names
of the packages containing the needed dynamic libraries.


I will do this within SConstruct.


I also suggest that you apply this patch for the cygwin distribution:


This patch should be applied. I have seen it twice but JMarc somehow
missed them.

Thanks.
Bo


Hebrew Translation

2006-09-07 Thread Guy Rutenberg

hi,

I would like to help with the hebrew translation of the LyX documentation. I
contacted Tzafrir Cohen (which is listed as the contact for hebrew) but he
told me that he doesn't activly maintain the hebrew translation. As there is
no active contact for hebrew translation i don't know how can i help with
the translation. I would thank you if you could explain to me how can i send
new translation for the documentation and if I can be the hebrew tranlation
contact man.

Best Regards,
Guy Rutenberg


Re: r14917 - in /lyx-devel/branches/personal/kuemmel/sharedli...

2006-09-07 Thread Andre Poenitz
On Wed, Sep 06, 2006 at 05:40:23PM +0200, Peter Kümmel wrote:
> Peter Kümmel wrote:
> > care about it. I just wanna see if it's possible to get Dlls without
> > huge changes.
> 
> Maybe the design of lyx is s bad that it is not possible. ;)

It is indeed so bad. But that's not new knowledge...

Andre'


Re: r14917 - in /lyx-devel/branches/personal/kuemmel/sharedli...

2006-09-07 Thread Andre Poenitz
On Wed, Sep 06, 2006 at 05:06:08PM +0200, Lars Gullik Bjønnes wrote:
> Isn't it possible to use export lists instead of doing the (imho
> braindead) annotation on all functions?

It is possible. The problem then is to enumerate all the _mangled_ names
in the .def file. That's even worse. Maybe there's a tool for generating 
a list. mingw32 used to have a 'dlltool' IIRC, but yjis probably won't
work in a MSVC environment.

And no, I don't like the EXPORT macro stuff either.

Andre'

-- 


Re: Active table and math toolbar

2006-09-07 Thread Abdelrazak Younes

Michael Gerz wrote:
BTW: "bottom" is ignored in 1.5.0svn/qt4. The tool bar is always 
displayed at the top. Should I add a bugzilla report?


Yes, I am aware of it an I plaid guilty. Right now the toolbars are 
hard-coded to be at the top because I didn't have the time to fix it 
properly last christmas.


Abdel.



Re: Let's do the same for dialogs! (was Re: [Patch] use enum instead of strings for type of math 'hull' inset)

2006-09-07 Thread Abdelrazak Younes

Andre Poenitz wrote:

On Tue, Sep 05, 2006 at 03:33:36PM +0200, Abdelrazak Younes wrote:

 char const * const dialognames[] = {
 "aboutlyx", "bibitem", "bibtex", "box", "branch", "changes",...

For this I'd actually prefer a factory that's initialized by static
singleton or such.

Could you elaborate a bit please?
The different dialogs are accessed with a string key. The key could as 
well be an int without any difference in behaviour, that's what I mean.


The enum requires a place where all dialogs are known (at least
conceptionally) so that we can define an 


  enum { dialogFoo, dialogBar  }

With a factory (in an ideal world...) we could (in theory...) have a
core completely ignorant of concrete dialogs. 'lfun-insert-inset foo'
would just ask the factory to create a dialog by a generator registered
under the name 'foo'.


I agree that the core should not know about concrete dialog. But I would 
like to be sure that the dialog IDs are exactly the same for all 
frontends. For this I need the enum to be placed in src/frontend/. Then 
each frontend could choose to implement or not a dialog. The code in 
src/frontend/ is an abstraction of the frontend and does not really 
belong to the core.


Abdel.



Re: Shared Libraries

2006-09-07 Thread Abdelrazak Younes

Peter Kümmel wrote:

Andre Poenitz wrote:

On Tue, Sep 05, 2006 at 11:16:14AM +0200, Peter Kümmel wrote:

I have started with frontend/qt4/ but give up because qt4 needs several
functions from the other libs.
We must start at the bottom not at the top, and qt4 is at the top.

Exactly.

The problem with the current architecture is, of, course, that drawing
is 'pushed' by the kernel, not 'pulled' by the frontend (containing th
painter)

Andre'


Yes, building insets is completely hopeless. And this artifact was
nicely hidden by the gcc.
Why has lyx not a mvc design where the model nothing knows about
the view but its base class?


For inset drawing, it will be difficult to achieve easily but that's the 
goal yes.


OTOH, dialogs can and should be converted to a model/view separation. 
Please have a look at the TOC implementation in qt4/.


Abdel.



Re: Shared Libraries

2006-09-07 Thread Abdelrazak Younes

Andre Poenitz wrote:

On Tue, Sep 05, 2006 at 11:16:14AM +0200, Peter Kümmel wrote:

I have started with frontend/qt4/ but give up because qt4 needs several
functions from the other libs.
We must start at the bottom not at the top, and qt4 is at the top.


Exactly.

The problem with the current architecture is, of, course, that drawing
is 'pushed' by the kernel, not 'pulled' by the frontend (containing th
painter)


The plan is of course to change that.

Abdel.



Re: Shared Libraries

2006-09-07 Thread Abdelrazak Younes

Andre Poenitz wrote:

On Tue, Sep 05, 2006 at 10:37:27AM +0200, Abdelrazak Younes wrote:
That's exactly the problem indeed. My earlier cleanup work is heading 
toward "the frontend use the kernel as a library" design. Once this is 
achieved, splitting out the toolkit specific frontend should be easy. So 
clearly the first candidate for a new dll is the code in frontend/qt4/.


Doesn't that contradict each other?

Shouldn't there be a lyxkernel.dll and the frontend  using this?


The frontend virtual interface yes. The qt4 frontend will just be an 
implementation of this interface and could entirely be in a single dll. 
This way the lyx-executable would not even have to link to Qt4, only the 
qt4 frontend dll.


 

The controller will need some cleanup before it could be split up.


I still think merging the controller into the frontend specific code
would make things a grest deal simpler, more flexible _and_ smaller,
even when using two frontends...


I agree this should be done on a case by case basis. Each dialog 
controller should be reviewed for correctness. A controller should not 
open a dialog for example. The spellchecher controller is an example of 
such bad design.


Abdel.



Re: Shared Libraries

2006-09-07 Thread Abdelrazak Younes

Andre Poenitz wrote:

On Tue, Sep 05, 2006 at 10:59:41AM +0200, Abdelrazak Younes wrote:

Peter Kümmel wrote:


At the current stage the code is full of dependencies,
and some circular could only be solved by moving functions
into a other library.
I think you should forget about the controller for now and concentrated 
on the frontend. Mathed seems also to be a good candidate.


Mathed depends on the core _and_ on the painert stuff, so how could that
be a good candidate to start with?


This was just a guess as the mathed code seems pretty isolated from the 
rest of the LyX code. As you said in an earlier mail, the painter stuff 
needs to be rethought.


Abdel.



Re: [PATCH] Re-introduce layout menu

2006-09-07 Thread Jean-Marc Lasgouttes
> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes:

Michael> Nevertheless, at some point in time, we should ask the LyX
Michael> users (not the developers) what they would like to see as the
Michael> default. Personally, I think that the traditional
Michael> Windows/Word/OOo user prefers the classic look & feel but
Michael> that is left to be proven. Does anybody read the lyx users
Michael> mailing list regularly? What did the old guys say about the
Michael> new 1.4 menu structure?

All I can say is that there have been less resistance wrt the menu
structure than I expected. But I cannot tell what this means :)

JMarc


Re: Towards LyX 1.4.3 [status update #1]

2006-09-07 Thread Georg Baum
Jean-Marc Lasgouttes wrote:

> 2698  add buttons for \intop and \ointop to math panel
> 
>   Georg, did you have time to look at the icons? Otherwise, we shall
>   postpone.

Now I looked at it. This patch adds the icons from Uwe. OK to go in?


Georg

Log:
Fix bug 2698 (new images from Uwe Stöhr)

* src/frontends/controllers/ControlMath.C
(latex_misc): Add intop and ointop

* lib/images/math/intop.xpm: New
* lib/images/math/ointop.xpm: Ditto

* lib/images/math/int.xpm: Add box to make the difference to intop clear
* lib/images/math/oint.xpm: ditto

* lib/Makefile.am: add new filesIndex: src/frontends/controllers/ControlMath.C
===
--- src/frontends/controllers/ControlMath.C	(Revision 14921)
+++ src/frontends/controllers/ControlMath.C	(Arbeitskopie)
@@ -188,7 +188,7 @@ char const * latex_misc[] = {
 int const nr_latex_misc = sizeof(latex_misc) / sizeof(char const *);
 
 char const * latex_varsz[] = {
-	"sum", "int", "oint",
+	"sum", "int", "intop", "oint", "ointop",
 	"prod", "coprod", "bigsqcup",
 	"bigotimes", "bigodot", "bigoplus",
 	"bigcap", "bigcup", "biguplus",
Index: status.14x
===
--- status.14x	(Revision 14921)
+++ status.14x	(Arbeitskopie)
@@ -30,6 +30,8 @@ What's new
 - Updated Czech (Tutorial, new splash) and German (UserGuide,
   Extended) documentation.
 
+- Add buttons for \intop and \ointop to the math panel (bug 2698)
+
 ** Bug fixes:
 
 * Document Input/Output
Index: lib/images/math/intop.xpm
===
--- lib/images/math/intop.xpm	(Revision 14921)
+++ lib/images/math/intop.xpm	(Arbeitskopie)
@@ -0,0 +1,41 @@
+/* XPM */
+static char *a[] = {
+/* columns rows colors chars-per-pixel */
+"15 32 3 1",
+"  c #00",
+". c #00",
+"X c None",
+/* pixels */
+"XX...XX",
+"X.X",
+"..XXX.X",
+"..XX..X",
+"..X",
+"XXX..XX",
+"XXX..XX",
+"XXX..XX",
+"XXX..XX",
+"XXX..XX",
+"XXX..XX",
+"XXX..XX",
+"XXX..XX",
+"XX..XXX",
+"XX..XXX",
+"XX..XXX",
+"XX..XXX",
+"XX..XXX",
+"XX..XXX",
+"XX..XXX",
+"XX..XXX",
+"X..",
+"X..XX..",
+"X.XXX..",
+"X.X",
+"XX...XX",
+"XXX",
+".X.X.X.",
+"XXX",
+".X.",
+"XXX",
+".X.X.X.",
+};
Index: lib/images/math/oint.xpm
===
--- lib/images/math/oint.xpm	(Revision 14921)
+++ lib/images/math/oint.xpm	(Arbeitskopie)
@@ -1,35 +1,35 @@
 /* XPM */
 static char *a[] = {
 /* columns rows colors chars-per-pixel */
-"13 26 3 1",
+"15 26 3 1",
 "  c #00",
 ". c #00",
 "X c None",
 /* pixels */
-"X...X",
-".",
-"XXX..XXX.",
-"XXX..XX..",
-"XXX..",
-"XX..X",
-"XX..X",
-"XX..X",
-"XX..X",
-".",
-"XX...XXXX",
-"X..XXX..XX.XX",
-"X..XXX..XX.XX",
-"X..XX..XXX.XX",
-"X...X..XXX.XX",
-"XX.X..XXX",
-"X",
-"X..XX",
-"X..XX",
-"X..XX",
-"X..XX",
-"..XXX",
-"..XX..XXX",
-".XXX..XXX",
-".",
-"X...X"
+"X...XXX",
+".XX",
+"XXX..XXX.XX",
+"XXX..XX..XX",
+"XXX..XX",
+"XX..XXX",
+"XX..XXX",
+"XX..XXX",
+"XX..XXX",
+".XX",
+"XX...XX",
+"X..XXX..XX.",
+"X..XXX..XX.",
+"X..XX..XXX.",
+"X...X..XXX.",
+"XX.X..X",
+"XXX",
+"X..",
+"X..",
+"X..",
+"X..",
+"..XX.X.X.X.",
+"..XX..X",
+".XXX..XX.X.",
+".XX",
+"X....X.X.X."
 };
Index: lib/images/math/int.xpm
===
--- lib/images/math/int.xpm	(Revision 14921)
+++ lib/images/math/int.xpm	(Arbeitskopie)
@@ -1,48 +1,35 @@
 /* XPM */
-static char const * const int_xpm[] = {
-/* width height ncolors chars_per_pixel */
-"18 25 16 1",
-/* colors */
-"O c None",
+static char *a[] = {
+/* columns rows colors chars-per-pixel */
+"17 26 3 1",
 "  c #00",
-". c #939393",
-"X c #676767",
-"o c #3B3B3B",
-"+ c #CECECE",
-"@ c #0F0F0F",
-"# c #B0B0B0",
-"$ c #A2A2A2",
-"% c #848484",
-"& c #767676",
-"* c #585858",
-"= c #4A4A4A",
-"- c #2C2C2C",
-"; c #1E1E1E",
-": c #BFBFBF",
+". c #00",
+"X c None",
 /* pixels */
-"OO",
-"OO",
-"[EMAIL PROTECTED]",
-"OOO=+O",
-"OO#XOO",
-"OO&%OO",
-"OO=:OO",
-"[EMAIL PROTECTED]",
-"O#oOOO",
-"O",
-"O*",
-"O;$OOO",
-"+ +OOO",
-"$;",
-"X=",

Re: USE_CYGWIN_PACKAGING

2006-09-07 Thread Enrico Forestieri
On Wed, Sep 06, 2006 at 09:29:21PM -0500, Bo Peng wrote:

> I plan to refine and apply the attached patch to 1.4.x. This patch
> lets 'scons install' generate the right kind of cygwin binary package
> (with /usr/doc/ ..., strip etc). To better reflect the uniqueness of
> cygwin, I have added USE_CYGWIN_PACKAGING to src/support/package.C,
> which basically says that cygwin has $HOME, and .exe suffix.
> 
> JMarc, what do you think about this macro? It is nice to have but it
> is not absolutely needed since I can walk around it in SConstruct.
> Some autotools changes may be needed.

IMO, USE_CYGWIN_PACKAGING is neither needed nor useful. You don't have
to care about the .exe suffix, cygwin takes care of that and in a well
thought manner. Every POSIX program that checks for its own name works
when compiled on cygwin. No need to fiddle with .exe suffix. Please ;-)
Cygwin is POSIX.

-- 
Enrico


Re: r14917 - in /lyx-devel/branches/personal/kuemmel/sharedli...

2006-09-07 Thread Peter Kümmel
Lars Gullik Bjønnes wrote:
> Peter Kümmel <[EMAIL PROTECTED]> writes:
> 
> | Peter Kümmel wrote:
> | > care about it. I just wanna see if it's possible to get Dlls without
> | > huge changes.
> | 
> | Maybe the design of lyx is s bad that it is not possible. ;)
> 
> Works without change on linux...
> 

Building a dll on windows is like linking
with --no-undefined under linux.

Try to link with this option then you will
see how wired the dependencies are.


-- 
Peter Kümmel



Re: generating project files with cmake

2006-09-07 Thread Peter Kümmel
Georg Baum wrote:
> Joost Verburg wrote:
> 
>> Abdelrazak Younes wrote:
 Are there any tools available to locate it?
>>> I've heard good things about valgrind. But it's linux only AFAIK.
>> Does anyone know of such a tool for Windows?
> 
> I once worked with purify, but that is some time ago. See
> http://www-306.ibm.com/software/awdtools/purifyplus/
> 

This was very nice:

http://www.glowcode.com/


> 
>> If we are going to switch, we should go for Enchant. This is a library
>> that makes it is possible to support Aspell/Pspell, Ispell, HunSpell,
>> MySpell, Uspell, Hspell and Mac OS X Applespell.
> 
> That has been suggested already long time ago. I don't think that it would
> be too difficult to add enchant as an additional spell checker, and if
> everything works drop the other ones.
> 
> 
> Georg
> 
> 


-- 
Peter Kümmel


[PATCH] Inset dissolve cleanup

2006-09-07 Thread Jean-Marc Lasgouttes

The following pair of patch implement inset-dissolve in what I believe
to be a clean way. There is no code in insets directory (the disabling
for tabular insets is done by testing "inset.nargs() == 1" instead).

Please test.

JMarc

Index: src/insets/insettabular.C
===
--- src/insets/insettabular.C	(revision 14921)
+++ src/insets/insettabular.C	(working copy)
@@ -1045,28 +1045,6 @@ bool InsetTabular::getStatus(LCursor & c
 			return true;
 		}
 
-	case LFUN_INSET_DISSOLVE: {
-		status.enabled(false);
-		return true;
-	}
-
-	// because of the dissolve handling in insettext:
-	case LFUN_CHAR_DELETE_FORWARD:
-		if (!cur.selection() && cur.depth() > 1
-		&& cur.pit() == cur.lastpit()
-		&& cur.pos() == cur.lastpos()) {
-		status.enabled(false);
-		return true;
-		}
-		// Fall through
-
-	case LFUN_CHAR_DELETE_BACKWARD:
-		if (cur.depth() > 1 && cur.pit() == 0 && cur.pos() == 0) {
-		status.enabled(false);
-		return true;
-		}
-		// Fall through
-
 	case LFUN_INSET_MODIFY:
 		if (translate(cmd.getArg(0)) == TABULAR_CODE) {
 			status.enabled(true);
Index: src/insets/insettext.C
===
--- src/insets/insettext.C	(revision 14921)
+++ src/insets/insettext.C	(working copy)
@@ -268,47 +268,14 @@ void InsetText::doDispatch(LCursor & cur
 			 << " [ cmd.action = "
 			 << cmd.action << ']' << endl;
 	setViewCache(());
-
-	switch (cmd.action) {
-
-	case LFUN_CHAR_DELETE_FORWARD: {
-		if (!cur.selection() && cur.depth() > 1
-		&& cur.pit() == cur.lastpit()
-		&& cur.pos() == cur.lastpos())
-			// Merge inset with owner
-			cmd = FuncRequest(LFUN_INSET_DISSOLVE);
-		text_.dispatch(cur, cmd);
-		break;
-	}
-
-	case LFUN_CHAR_DELETE_BACKWARD: {
-		if (cur.depth() > 1 && cur.pit() == 0 && cur.pos() == 0)
-			// Merge inset with owner
-			cmd = FuncRequest(LFUN_INSET_DISSOLVE);
-		text_.dispatch(cur, cmd);
-		break;
-	}
-	
-	default:
-		text_.dispatch(cur, cmd);
-		break;
-	}
+	text_.dispatch(cur, cmd);
 }
 
 
 bool InsetText::getStatus(LCursor & cur, FuncRequest const & cmd,
 	FuncStatus & status) const
 {
-	switch (cmd.action) {
-
-	case LFUN_CHAR_DELETE_FORWARD:
-	case LFUN_CHAR_DELETE_BACKWARD:
-		status.enabled(true);
-		return true;
-
-	default:
-		return text_.getStatus(cur, cmd, status);
-	}
+	return text_.getStatus(cur, cmd, status);
 }
 
 
Index: src/lyxtext.h
===
--- src/lyxtext.h	(revision 14921)
+++ src/lyxtext.h	(working copy)
@@ -232,6 +232,8 @@ public:
 	bool backspacePos0(LCursor & cur);
 	/// Delete character before cursor. Honour CT
 	bool backspace(LCursor & cur);
+	// Dissolve the inset under cursor
+	bool dissolveInset(LCursor & cur);
 	///
 	bool selectWordWhenUnderCursor(LCursor & cur, lyx::word_location);
 	///
Index: src/text3.C
===
--- src/text3.C	(revision 14921)
+++ src/text3.C	(working copy)
@@ -79,7 +79,6 @@ using lyx::pos_type;
 
 using lyx::cap::copySelection;
 using lyx::cap::cutSelection;
-using lyx::cap::pasteParagraphList;
 using lyx::cap::pasteSelection;
 using lyx::cap::replaceSelection;
 
@@ -709,34 +708,9 @@ void LyXText::dispatch(LCursor & cur, Fu
 		break;
 	}
 
-	case LFUN_INSET_DISSOLVE: {
-		recordUndoInset(cur);
-		cur.selHandle(false);
-		// save position
-		lyx::pos_type spos = cur.pos();
-		lyx::pit_type spit = cur.pit();
-		ParagraphList plist;
-		if (cur.lastpit() != 0 || cur.lastpos() != 0) 
-			plist = paragraphs();
-		cur.popLeft();
-		// store cursor offset
-		if (spit == 0)
-			spos += cur.pos();
-		spit += cur.pit();
-		cur.paragraph().erase(cur.pos());
-		if (!plist.empty()) {
-			Buffer * b = bv->buffer();
-			pasteParagraphList(cur, plist, b->params().textclass, 
-	   b->errorList("Paste"));
-			// restore position
-			cur.pit() = std::min(cur.lastpit(), spit);
-			cur.pos() = std::min(cur.lastpos(), spos);
-		}
-		cur.clearSelection();
-		cur.resetAnchor();
-		needsUpdate = true;
+	case LFUN_INSET_DISSOLVE:
+		needsUpdate = dissolveInset(cur);
 		break;
-	}
 
 	case LFUN_INSET_SETTINGS:
 		cur.inset().showInsetDialog(bv);
@@ -1720,20 +1694,17 @@ bool LyXText::getStatus(LCursor & cur, F
 		enable = lyx::cap::numberOfSelections() > 0;
 		break;
 
-	case LFUN_PARAGRAPH_MOVE_UP: {
+	case LFUN_PARAGRAPH_MOVE_UP:
 		enable = cur.pit() > 0 && !cur.selection();
 		break;
-	}
 
-	case LFUN_PARAGRAPH_MOVE_DOWN: {
+	case LFUN_PARAGRAPH_MOVE_DOWN:
 		enable = cur.pit() < cur.lastpit() && !cur.selection();
 		break;
-	}
 
-	case LFUN_INSET_DISSOLVE: {
-		enable = !isMainText() && cur.inTexted();
+	case LFUN_INSET_DISSOLVE:
+		enable = !isMainText() && cur.inset().nargs() == 1;
 		break;
-	}
 
 	case LFUN_WORD_DELETE_FORWARD:
 	case LFUN_WORD_DELETE_BACKWARD:
Index: src/text.C
===
--- src/text.C	(revision 14921)
+++ src/text.C	(working 

Re: Towards LyX 1.4.3 [status update #1]

2006-09-07 Thread Jean-Marc Lasgouttes
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:

Georg> Jean-Marc Lasgouttes wrote:
>> 2698 add buttons for \intop and \ointop to math panel
>> 
>> Georg, did you have time to look at the icons? Otherwise, we shall
>> postpone.

Georg> Now I looked at it. This patch adds the icons from Uwe. OK to
Georg> go in?

Sure.

JMarc



Re: Active table and math toolbar

2006-09-07 Thread Jean-Marc Lasgouttes
> "John" == John Levon <[EMAIL PROTECTED]> writes:

John> On Wed, Sep 06, 2006 at 11:01:41PM +0200, Michael Gerz wrote:
>> I think this patch (or a similar one) has been discussed already.
>> Should I commit it?

John> This is a really difficult one to decide. I can see this being
John> enormously irritating default behaviour for some people, and we
John> don't yet have a View->Toolbars that can easily turn it off. On
John> the other hand, these toolbars are extremely useful.

What about a new 'Allow automatic toolbars' lyxrc entry?

Then we could set the default to 'true'.

Or to 'false' :)

JMarc


[PATCH] bug 2600: Change tracking and tables hangs or asserts

2006-09-07 Thread Jean-Marc Lasgouttes

The following patches fix a crash:
http://bugzilla.lyx.org/show_bug.cgi?id=2600

The problem was the assumption that the LyXText of the cursor is the
same as the LyXText of cursor.selBegin.

I think there are still problems with CT and tables, but I propose to
apply at least this one.

I think that the rest of the problem would be fixed by a proper fix to
bug 2510.

JMarc

Index: src/BufferView_pimpl.C
===
--- src/BufferView_pimpl.C	(revision 14926)
+++ src/BufferView_pimpl.C	(working copy)
@@ -749,17 +749,11 @@ bool BufferView::Pimpl::available() cons
 
 Change const BufferView::Pimpl::getCurrentChange()
 {
-	if (!buffer_->params().tracking_changes)
+	if (!buffer_->params().tracking_changes || !cursor_.selection())
 		return Change(Change::UNCHANGED);
 
-	LyXText * text = bv_->getLyXText();
-	LCursor & cur = cursor_;
-
-	if (!cur.selection())
-		return Change(Change::UNCHANGED);
-
-	return text->getPar(cur.selBegin().pit()).
-			lookupChangeFull(cur.selBegin().pos());
+	DocIterator dit = cursor_.selectionBegin();
+	return dit.paragraph().lookupChangeFull(dit.pos());
 }
 
 
Index: src/BufferView_pimpl.C
===
--- src/BufferView_pimpl.C	(revision 14924)
+++ src/BufferView_pimpl.C	(working copy)
@@ -586,17 +586,11 @@ bool BufferView::Pimpl::available() cons
 
 Change const BufferView::Pimpl::getCurrentChange()
 {
-	if (!buffer_->params().tracking_changes)
+	if (!buffer_->params().tracking_changes || !cursor_.selection())
 		return Change(Change::UNCHANGED);
 
-	LyXText * text = bv_->getLyXText();
-	LCursor & cur = cursor_;
-
-	if (!cur.selection())
-		return Change(Change::UNCHANGED);
-
-	return text->getPar(cur.selBegin().pit()).
-			lookupChange(cur.selBegin().pos());
+	DocIterator dit = cursor_.selectionBegin();
+	return dit.paragraph().lookupChange(dit.pos());
 }
 
 


Re: Towards LyX 1.4.3 [status update #1]

2006-09-07 Thread Enrico Forestieri
On Fri, Aug 25, 2006 at 05:05:04PM +0200, Jean-Marc Lasgouttes wrote:
> 
> We have come a long way towards 1.4.3, so now is the time to think
> about a release. I will be in vacation again next week, so the date
> should be some time at the beginning of September.

Please JMarc, could the attached patch be applied to 1.4.x?

It is about small fixes for the cygwin target:
- Cygwin does not have locale support, so the warning about
  "Locale xx_XX could not be set" is bogus.
- Some unnecessary path conversions are avoided.
- When the fronted is Qt3/X11, it is not necessary that external_path
  and external_path_list return a windows style path.

Thanks in advance.

-- 
Enrico
Index: src/ChangeLog
===
--- src/ChangeLog   (revision 14926)
+++ src/ChangeLog   (working copy)
@@ -1,3 +1,8 @@
+1006-09-07  Enrico Forestieri <[EMAIL PROTECTED]>
+
+   * messages.C (Messages::get): don't warn about locale on cygwin
+   as it is not supported.
+
 2006-08-19  Jean-Marc Lasgouttes  <[EMAIL PROTECTED]>
 
* BufferView_pimpl.C (focusChange): new method; updates the
Index: src/support/ChangeLog
===
--- src/support/ChangeLog   (revision 14926)
+++ src/support/ChangeLog   (working copy)
@@ -1,3 +1,11 @@
+2006-09-07  Enrico Forestieri  <[EMAIL PROTECTED]>
+   * os_cygwin.C (is_windows_path): avoid unnecessary conversion
+   when path is relative
+   (convert_path_list): avoid unnecessary conversion when path
+   list is empty
+   (external_path, external_path_list): for an X11 build it is not
+   necessary that the output path style is windows
+
 2006-06-27  Enrico Forestieri  <[EMAIL PROTECTED]>
 
* os.h: rename cygwin_path_fix as windows_style_tex_paths.
Index: src/support/os_cygwin.C
===
--- src/support/os_cygwin.C (revision 14926)
+++ src/support/os_cygwin.C (working copy)
@@ -55,8 +55,7 @@ bool is_posix_path(string const & p)
 
 bool is_windows_path(string const & p)
 {
-   return p.empty() ||
-   (!contains(p, '\\') && (p.length() <= 1 || p[1] == ':'));
+   return p.empty() || (!contains(p, '\\') && p[0] != '/');
 }
 
 
@@ -87,6 +86,9 @@ string convert_path(string const & p, Pa
 
 string convert_path_list(string const & p, PathStyle const & target)
 {
+   if (p.empty())
+   return p;
+
char const * const pc = p.c_str();
PathStyle const actual = cygwin_posix_path_list_p(pc) ? posix : windows;
 
@@ -186,7 +188,11 @@ string::size_type common_path(string con
 
 string external_path(string const & p)
 {
+#ifdef X_DISPLAY_MISSING
return convert_path(p, PathStyle(windows));
+#else
+   return convert_path(p, PathStyle(posix));
+#endif
 }
 
 
@@ -198,7 +204,11 @@ string internal_path(string const & p)
 
 string external_path_list(string const & p)
 {
+#ifdef X_DISPLAY_MISSING
return convert_path_list(p, PathStyle(windows));
+#else
+   return convert_path_list(p, PathStyle(posix));
+#endif
 }
 
 
Index: src/messages.C
===
--- src/messages.C  (revision 14926)
+++ src/messages.C  (working copy)
@@ -126,10 +126,10 @@ public:
 #endif
// setlocale fails (returns NULL) if the corresponding locale
// is not installed.
-   // On windows (mingw) it always returns NULL.
+   // On windows (mingw and cygwin) it always returns NULL.
// Since this method gets called for every translatable
// buffer string like e.g. "Figure:" we warn only once.
-#ifndef _WIN32
+#if !defined(_WIN32) && !defined(__CYGWIN__)
static bool warned = false;
if (!warned && !lc_msgs) {
warned = true;


Re: inset-dissolve

2006-09-07 Thread Helge Hafting

Michael Gerz wrote:

Hi Jürgen,

inset-dissolve is still broken: If you open a new document, the 
function is enabled (which wrong) as you can see in the menu. If you 
want to dissolve the non-existent inset nevertheless, LyX crashes.

But this is correct behaviour!
You dissolve the empty document - lyx indeed goes away! ;-)

Helge Hafting


Re: Towards LyX 1.4.3 [status update #1]

2006-09-07 Thread Martin Vermeer
On Mon, 2006-09-04 at 11:08 +0200, Juergen Spitzmueller wrote:
> Jean-Marc Lasgouttes wrote:
> > My question now is whether to put this in 1.4.3 or 1.4.4. I tend to think
> > it will be 1.4.4, but I am not fixed on that.
> 
> I tend to think so, too, for testing reasons. Let's put the patch in soon 
> after 1.4.3 is released, so that people who use 1.4svn for daily work (like 
> me) can text it under real life conditions before releasing.
> 
> Jürgen

I second that. Thanks for the offer :-)

- Martin



signature.asc
Description: This is a digitally signed message part


fs_extras compile fails (errno not declared in this scope)

2006-09-07 Thread Kayvan A. Sylvan
if /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. 
-I../../src   -I./.. -I../../boost -Wextra -Wall-I/usr/X11R6/include  -O2 
-MT fs_extras.lo -MD -MP -MF ".deps/fs_extras.Tpo" -c -o fs_extras.lo 
fs_extras.C; \
then mv -f ".deps/fs_extras.Tpo" ".deps/fs_extras.Plo"; else rm -f 
".deps/fs_extras.Tpo"; exit 1; fi
 g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./.. -I../../boost -Wextra -Wall 
-I/usr/X11R6/include -O2 -MT fs_extras.lo -MD -MP -MF .deps/fs_extras.Tpo -c 
fs_extras.C -o fs_extras.o
fs_extras.C: In function 'void boost::filesystem::copy_file(const 
boost::filesystem::path&, const boost::filesystem::path&, bool)':
fs_extras.C:101: error: 'errno' was not declared in this scope
fs_extras.C:107: error: 'errno' was not declared in this scope
fs_extras.C:120: error: 'errno' was not declared in this scope
fs_extras.C:148: error: 'errno' was not declared in this scope
make[6]: *** [fs_extras.lo] Error 1
make[6]: Leaving directory 
`/home/kayvan/rpmbuild/BUILD/lyx-1.5.0svn/src/support'
make[5]: *** [all-recursive] Error 1
make[5]: Leaving directory 
`/home/kayvan/rpmbuild/BUILD/lyx-1.5.0svn/src/support'
make[4]: *** [all] Error 2
make[4]: Leaving directory 
`/home/kayvan/rpmbuild/BUILD/lyx-1.5.0svn/src/support'
-- 
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 | my beautiful Queen.| Robin Gregory (2/28/92)


pgpmq69amdoxc.pgp
Description: PGP signature


Re: Towards LyX 1.4.3 [status update #1]

2006-09-07 Thread Georg Baum
Jean-Marc Lasgouttes wrote:

> 2660  patch   german userguide broken
> 
>   What remains to be done is copy the icons and update Makefile.am.
>   Please, someone...

I just did that (and found two more invalid image paths). We need some lint
for .lyx files.


Georg



Re: fs_extras compile fails (errno not declared in this scope)

2006-09-07 Thread Georg Baum
Kayvan A. Sylvan wrote:

> fs_extras.C:101: error: 'errno' was not declared in this scope
> fs_extras.C:107: error: 'errno' was not declared in this scope
> fs_extras.C:120: error: 'errno' was not declared in this scope
> fs_extras.C:148: error: 'errno' was not declared in this scope make[6]:

This is fixed now. errno.h was not included.


Georg



Re: fs_extras compile fails (errno not declared in this scope)

2006-09-07 Thread Lars Gullik Bjønnes
Georg Baum <[EMAIL PROTECTED]> writes:

| Kayvan A. Sylvan wrote:
| 
| > fs_extras.C:101: error: 'errno' was not declared in this scope
| > fs_extras.C:107: error: 'errno' was not declared in this scope
| > fs_extras.C:120: error: 'errno' was not declared in this scope
| > fs_extras.C:148: error: 'errno' was not declared in this scope make[6]:
| 
| This is fixed now. errno.h was not included.

and should not be included ... we want 

-- 
Lgb



Re: USE_CYGWIN_PACKAGING

2006-09-07 Thread Bo Peng

IMO, USE_CYGWIN_PACKAGING is neither needed nor useful. You don't have


In the patch, I use packaging_method == 'cygwin' to install files as
instructed by cygwin-packaging standard. I can use platform ==
'cygwin' but the former seems to be more logical. Also, it might not
be at all useful, but the packaging option (both autotools and scons)
allows us to make packages cross-platformly.

Bo


Re: Towards LyX 1.4.3 [status update #1]

2006-09-07 Thread Jean-Marc Lasgouttes
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:

Georg> Jean-Marc Lasgouttes wrote:
>> 2660 patch german userguide broken
>> 
>> What remains to be done is copy the icons and update Makefile.am.
>> Please, someone...

Georg> I just did that (and found two more invalid image paths). We
Georg> need some lint for .lyx files.

Thanks a lot!

JMarc


Re: fs_extras compile fails (errno not declared in this scope)

2006-09-07 Thread Georg Baum
Lars Gullik Bjønnes wrote:

> and should not be included ... we want 

Why? I don't know any advantage, only a disadvantage: Some compilers do not
have it.


Georg



Re: please complete short "Questionnaire for Developers" (part of a user interface study)

2006-09-07 Thread Abdelrazak Younes

Daryl Hepting wrote:

Lyx Developer Questionnaire

This questionnaire will be used by students of the CS305 course at the 
University of Regina to inform their semester’s work.  Results of this

work will be contributed back to the lyx project.  All replies sent to me
directly ([EMAIL PROTECTED]) will 
have all identifying information

removed before anyone else sees them.  This course project study has been
approved by the Research Ethics Board at the University of Regina
([EMAIL PROTECTED]).  If any 
publication follows the semester’s

work, your replies will not be directly quoted and your responses will
not be identifiable. [If you would like to be identified and associated
with your comments, please indicate that to me in your reply.]  Your
completion (and return) of this questionnaire implies your consent for
the uses stated above.

Why did you choose to become involved with the lyx project?


I wanted to learn Qt and contribute something to LyX. Porting LyX from 
Qt3 to Qt4 seemed to be an easy enough task. I didn't know at the time 
how much time this project will suck in my life...




How would you describe the vision for the lyx project, and why?


The best portable document writing tool ever.



For whom is lyx intended?


Hopefully to anybody willing to spend half a day reading the Tutorial. 
It's the optimal tool for Scientists and I've heard for Linguists too.




Are there any comments you’d like to share about your experience
with the lyx project?


Come on-board, plenty of things to do here!

Abdel.



Re: Towards LyX 1.4.3 [status update #1]

2006-09-07 Thread José Matos
On Thursday 07 September 2006 13:50, Georg Baum wrote:
> I just did that (and found two more invalid image paths). We need some lint
> for .lyx files.

  It is on my todo list, FWIW. :-)

> Georg

-- 
José Abílio


Re: please complete short "Questionnaire for Developers" (part of a user interface study)

2006-09-07 Thread Bo Peng

Why did you choose to become involved with the lyx project?


I like lyx, I was between jobs, and I find that it is easier to
contribute than arguing in the mailing list and waiting for months
(years?) for a feature to be implemented.


How would you describe the vision for the lyx project, and why?


The best tool for tech writing.


For whom is lyx intended?


People who have higher standard for the look of their article (book
etc), need to write lots of formula, willing to learn a bit latex and
read some tutorials about lyx.

Bo


Re: fs_extras compile fails (errno not declared in this scope)

2006-09-07 Thread Jean-Marc Lasgouttes
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:

Georg> Lars Gullik Bjønnes wrote:
>> and should not be included ... we want 

Georg> Why? I don't know any advantage, only a disadvantage: Some
Georg> compilers do not have it.

I think all compilers have it now.

JMarc


Re: fs_extras compile fails (errno not declared in this scope)

2006-09-07 Thread Georg Baum
Jean-Marc Lasgouttes wrote:

>> "Georg" == Georg Baum
>> <[EMAIL PROTECTED]>
>> writes:
> 
> Georg> Lars Gullik Bjønnes wrote:
>>> and should not be included ... we want 
> 
> Georg> Why? I don't know any advantage, only a disadvantage: Some
> Georg> compilers do not have it.
> 
> I think all compilers have it now.

OK I changed it, but I am still curious to hear why cerrno is better.


Georg



Re: Shared Libraries

2006-09-07 Thread Andre Poenitz
On Thu, Sep 07, 2006 at 09:39:13AM +0200, Abdelrazak Younes wrote:
> >Shouldn't there be a lyxkernel.dll and the frontend  using this?
> 
> The frontend virtual interface yes. The qt4 frontend will just be an 
> implementation of this interface and could entirely be in a single dll. 
> This way the lyx-executable would not even have to link to Qt4, only the 
> qt4 frontend dll.

I am not sure there needs to be a virtual frontend interface at all.

In theory, ther kernel could be completely ignorant of any frontend and
just signal internal changes.

A frontend would directly call into the kernel to make things happen and
adjust afterwards by listening to the signals.

IMO a common frontend base is a design mistake that puts things downside
up: The kernel tells the frontend to draw and listen to events from the
frontend. No good.

Andre'


Re: r14917 - in /lyx-devel/branches/personal/kuemmel/sharedli...

2006-09-07 Thread Andre Poenitz
On Thu, Sep 07, 2006 at 11:29:05AM +0200, Peter Kümmel wrote:
> Lars Gullik Bjønnes wrote:
> > Peter Kümmel <[EMAIL PROTECTED]> writes:
> > 
> > | Peter Kümmel wrote:
> > | > care about it. I just wanna see if it's possible to get Dlls without
> > | > huge changes.
> > | 
> > | Maybe the design of lyx is s bad that it is not possible. ;)
> > 
> > Works without change on linux...
> > 
> 
> Building a dll on windows is like linking
> with --no-undefined under linux.

--no-undefined plus -Bsymbolic plus explicit symbol export plus separate
heaps plus some 'minor' details.

Andre'


Re: Shared Libraries

2006-09-07 Thread Andre Poenitz
On Thu, Sep 07, 2006 at 09:41:55AM +0200, Abdelrazak Younes wrote:
> >Mathed depends on the core _and_ on the painert stuff, so how could that
> >be a good candidate to start with?
> 
> This was just a guess as the mathed code seems pretty isolated from the 
> rest of the LyX code. As you said in an earlier mail, the painter stuff 
> needs to be rethought.

Mathed is indeed pretty isolated in the sense that even largish internal
changes do not affect the rest much. However, it is not easily
separable into a self-contained library.

Andre'


Re: Shared Libraries

2006-09-07 Thread Andre Poenitz
On Wed, Sep 06, 2006 at 08:49:35PM +0200, Peter Kümmel wrote:
> > The problem with the current architecture is, of, course, that drawing
> > is 'pushed' by the kernel, not 'pulled' by the frontend (containing th
> > painter)
> 
> Yes, building insets is completely hopeless. And this artifact was
> nicely hidden by the gcc.
> Why has lyx not a mvc design where the model nothing knows about
> the view but its base class?

Because LyX architecture is ten years old and mvc wasn't exactly hyped
at this time?

Andre'


Re: Shared Libraries

2006-09-07 Thread Andre Poenitz
On Thu, Sep 07, 2006 at 09:30:18AM +0200, Abdelrazak Younes wrote:
> Andre Poenitz wrote:
> >On Tue, Sep 05, 2006 at 11:16:14AM +0200, Peter Kümmel wrote:
> >>I have started with frontend/qt4/ but give up because qt4 needs several
> >>functions from the other libs.
> >>We must start at the bottom not at the top, and qt4 is at the top.
> >
> >Exactly.
> >
> >The problem with the current architecture is, of, course, that drawing
> >is 'pushed' by the kernel, not 'pulled' by the frontend (containing th
> >painter)
> 
> The plan is of course to change that.

Of course.

Last time I tried it I got stuck somewhere between
updateInsetInInset and tabulators in MathParInset...

Andre'


Re: Active table and math toolbar

2006-09-07 Thread Michael Gerz

Jean-Marc Lasgouttes schrieb:

John> This is a really difficult one to decide. I can see this being
John> enormously irritating default behaviour for some people, and we
John> don't yet have a View->Toolbars that can easily turn it off. On
John> the other hand, these toolbars are extremely useful.

What about a new 'Allow automatic toolbars' lyxrc entry?

Then we could set the default to 'true'.

Or to 'false' :)
  

In that case, the current UI file design does not make sense any longer.

Anyway, there are at least three people among us who would like to see a 
short-term solution. See


  http://bugzilla.lyx.org/show_bug.cgi?id=2813

Why don't we activate the toolbars for now (and for 1.4.3)? The 
activation is not a showstopper in case someone wants to optimize the 
look & feel later.


Michael


Re: [PATCH] Re-introduce layout menu

2006-09-07 Thread Michael Gerz

John Levon schrieb:

What would be REALLY cool is some actual UI testing in a proper lab
infrastructure. But slightly cool would be something that collected
real-life data on menu use, and allowed us to collect it (modulo privacy
concerns etc.)

Asking a self-selecting population is notoriously tricky for getting
meaningful answers.
  
How about my recent Character Style patch? Is this something in the 
spirit of your GUI design (most important things first etc.)?


Michael


Re: [PATCH] Inset dissolve cleanup

2006-09-07 Thread Michael Gerz

Jean-Marc Lasgouttes schrieb:

The following pair of patch implement inset-dissolve in what I believe
to be a clean way. There is no code in insets directory (the disabling
for tabular insets is done by testing "inset.nargs() == 1" instead).

Please test.
  
inset-dissolve works for 1.5.0, even with nested insets! (I am not able 
to test 1.4.X right now)


Just one cosmetic issue: If you want to undo inset-dissolve, you have to 
press CTRL-Z twice. This might be a bit disturbing for some users.


Michael


Re: [PATCH] Re-introduce layout menu

2006-09-07 Thread Martin Vermeer
On Wed, Sep 06, 2006 at 11:29:58PM +0200, Michael Gerz wrote:
> John, JMarc,
> 
> what do you think about the patch below? The idea is to have a submenu 
> for character styles that combines layout-specific char styles, 
> bold/emphasize/noun style, and the font dialog. The layout-specific char 
> styles have been moved from menu "Insert". Although the styles are 
> actually implemented as insets, the user does not think in terms of 
> "inserting" something. Bold/emphasize/noun style - whether you like it 
> or not - are frequently requested features. There is at least one 
> bugzilla report for re-adding "bold" to the menu. The font dialog is 
> listed at the end ("Other...") because users should not be encouraged to 
> use it often. Regarding the word-* functions:  We might move them to the 
> submenu as well to shorten the "Edit" menu (as done in the patch). 
> However, after testing "word-capitalize", I really doubt that this 
> particular functions is very useful (why do we have it at all?).
> 
> Any comments?
> 
> Michael

 
This looks very nice to me.

- Martin
 
> Index: stdmenus.ui
> ===
> --- stdmenus.ui(revision 14919)
> +++ stdmenus.ui(working copy)
> @@ -89,14 +89,10 @@
> Separator
> Item "Find & Replace...|F" "dialog-show findreplace"
> Separator
> -Item "Word in Small Capitals" "word-capitalize"
> -Item "Word in Uppercase" "word-upcase"
> -Item "Word in Lowercase" "word-lowcase"
> -Separator
> Item "Move Paragraph Up|o" "paragraph-move-up"
> Item "Move Paragraph Down|v" "paragraph-move-down"
> Separator
> -Item "Text Style...|S" "dialog-show character"
> +Submenu "Character Style...|C" "insert_charstyles"
> Item "Paragraph Settings...|P" "layout-paragraph"
> Separator
> # Mathed b0rkage means these don't work properly
> @@ -136,6 +132,19 @@
> PasteRecent
> End
> 
> +Menu "insert_charstyles"
> +CharStyles
> +Separator
> +Item "Emphasize Style|E" "font-emph"
> +Item "Noun Style|N" "font-noun"
> +Item "Bold Style|B" "font-bold"
> +Separator
> +Item "Other...|O" "dialog-show character"
> +Separator
> +Item "Uppercase" "word-upcase"
> +Item "Lowercase" "word-lowcase"
> +End
> +
> # not much we can do to help here
> Menu "edit_tabular"
> Item "Multicolumn|M" "tabular-feature multicolumn"
> @@ -253,7 +262,6 @@
> # YUCK
> Submenu "Note|N" "insert_note"
> OptSubmenu "Branch|B" "insert_branches"
> -OptSubmenu "Character Style|y" "insert_charstyles"
> Submenu "File|e" "insert_file"
> Item "Box" "box-insert Frameless"
> Separator
> @@ -377,10 +385,6 @@
> Branches
> End
> 
> -Menu "insert_charstyles"
> -CharStyles
> -End
> -
> #
> # DOCUMENT MENU
> #
> 



pgpH4y6x618o6.pgp
Description: PGP signature


Re: USE_CYGWIN_PACKAGING

2006-09-07 Thread Bo Peng

On 9/7/06, Bo Peng <[EMAIL PROTECTED]> wrote:

> IMO, USE_CYGWIN_PACKAGING is neither needed nor useful. You don't have


Hi, Enrico,

Could you please apply the attached patch, install scons-local, run

python scons.py -f development/scons/SConstruct DESTDIR=cygwin_test
mode=release install

and check if the files are correctly installed as described in
http://cygwin.com/setup.html ?

I have also attached the required  setup.hint.

Bo
Index: development/scons/SConstruct
===
--- development/scons/SConstruct	(revision 14932)
+++ development/scons/SConstruct	(working copy)
@@ -54,6 +54,7 @@
 # some global settings
 #
 package_version = '1.4.3svn'
+package_cygwin_version = '1.4.3svn-1'
 boost_version = '1_32'
 
 devel_version = True
@@ -397,14 +398,14 @@
 share_dir = 'Resources'
 man_dir = 'Resources/man/man1'
 locale_dir = 'Resources/locale'
-default_prefix = 'c:/program files/lyx'
 else:
 share_dir = 'share/lyx'
-man_dir = 'man/man1'
 locale_dir = 'share/locale'
-default_prefix = '/usr/local/'
+if platform_name == 'cygwin':
+man_dir = 'share/man/man1'
+else:
+man_dir = 'man/man1'
 
-# install to default_prefix by default
 # program suffix: can be yes, or a string
 if env.has_key('version_suffix'):
 if env['version_suffix'] in true_strings:
@@ -792,6 +793,14 @@
 else:
 env['MSGFMT'] = env_cache['MSGFMT']
 
+# cygwin packaging requires the binaries to be stripped
+if platform_name == 'cygwin':
+if not fast_start:
+env['STRIP'] = conf.CheckCommand('strip')
+env_cache['STRIP'] = env['STRIP']
+else:
+env['STRIP'] = env_cache['STRIP']
+
 # check uic and moc commands for qt frontends
 if not fast_start:
 if frontend[:2] == 'qt' and (conf.CheckCommand('uic') == None \
@@ -1331,7 +1340,7 @@
 # for details
 #
 if platform_name == 'cygwin':
-ld_script_path = '/usr/lib/qt3/mkspecs/cygwin-g++'
+ld_script_path = '/tmp'
 ld_script = utils.installCygwinLDScript(ld_script_path)
 env.AppendUnique(LINKFLAGS = ['-Wl,--enable-runtime-pseudo-reloc',
 '-Wl,--script,%s' % ld_script, '-Wl,-s'])
@@ -2008,23 +2017,21 @@
 else:
 version_suffix = ''
 #
-# install lyx
-target_name = os.path.split(str(lyx[0]))[1].replace('lyx', 'lyx%s' % version_suffix)
-target = os.path.join(bin_dest_dir, target_name)
-env.InstallAs(target, lyx)
-Alias('install', target)
-#
-# install tex2lyx
-target_name = os.path.split(str(tex2lyx[0]))[1].replace('tex2lyx', 'tex2lyx%s' % version_suffix)
-target = os.path.join(bin_dest_dir, target_name)
-env.InstallAs(target, tex2lyx)
-Alias('install', target)
-#
-# install lyxclient, may not exist
-if client != None:
-target_name = os.path.split(str(client[0]))[1].replace('client', 'client%s' % version_suffix)
+# install lyx, if in release mode, try to strip the binary
+if env.has_key('STRIP') and env['STRIP'] is not None and mode != 'debug':
+# create a builder to strip and install
+env['BUILDERS']['StripInstallAs'] = Builder(action='$STRIP $SOURCE -o $TARGET')
+
+# install executables
+for (name, obj) in (('lyx', lyx), ('tex2lyx', tex2lyx), ('client', client)):
+if obj is None:
+continue
+target_name = os.path.split(str(obj[0]))[1].replace(name, '%s%s' % (name, version_suffix))
 target = os.path.join(bin_dest_dir, target_name)
-env.InstallAs(target, client)
+if env['BUILDERS'].has_key('StripInstallAs'):
+env.StripInstallAs(target, obj)
+else:
+env.InstallAs(target, obj)
 Alias('install', target)
 #
 # share/lyx
@@ -2046,14 +2053,27 @@
 ('lyx2lyx', lib_lyx2lyx_files)]:
 dirs.append(env.Install(os.path.join(share_dest_dir, dir),
 [env.subst('$TOP_SRCDIR/lib/%s/%s' % (dir, file)) for file in files]))
+Alias('install', dirs)
 
+if platform_name == 'cygwin':
+# cygwin packaging requires a file /usr/share/doc/Cygwin/foot-vendor-suffix.README
+Cygwin_README = os.path.join(dest_prefix_dir, 'doc', 'Cygwin', 
+'%s%s.README' % (package, package_cygwin_version))
+env.InstallAs(Cygwin_README,
+os.path.join(env.subst('$TOP_SRCDIR'), 'README.cygwin'))
+Alias('install', Cygwin_README)
+# also a directory /usr/share/doc/lyx for README etc
+Cygwin_Doc = os.path.join(dest_prefix_dir, 'doc', package)
+env.Install(Cygwin_Doc, [os.path.join(env.subst('$TOP_SRCDIR'), x) for x in \
+['INSTALL', 'README', 'README.Cygwin', 'RELEASE-NOTES', 'COPYING', 'ANNOUNCE']])
+Alias('install', Cygwin_Doc)
+
 # lyx1.4.x does not have lyx2lyx_version.py.in
 if os.path.isfile(env.subst('$TOP_SRCDIR/lib/lyx2lyx/lyx2lyx_version.py.in')):
 # subst and install this file
 env.substFile(share_dest_dir + 

Re: [PATCH] Inset dissolve cleanup

2006-09-07 Thread Jean-Marc Lasgouttes
> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes:

Michael> Just one cosmetic issue: If you want to undo inset-dissolve,
Michael> you have to press CTRL-Z twice. This might be a bit
Michael> disturbing for some users.

I know that, but I have not been able to avoid it. It is because we
use the cut and paste machinery, which does its own undo. I really
think it should not, if this is possible.

Thanks for testing.

JMarc


Re: Shared Libraries

2006-09-07 Thread Jean-Marc Lasgouttes
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:

Andre> Because LyX architecture is ten years old and mvc wasn't
Andre> exactly hyped at this time?

Well, LyX is not older than smalltalk...

JMarc


Re: [PATCH] Re-introduce layout menu

2006-09-07 Thread John Levon
On Thu, Sep 07, 2006 at 09:07:17PM +0200, Michael Gerz wrote:

> John Levon schrieb:
> >What would be REALLY cool is some actual UI testing in a proper lab
> >infrastructure. But slightly cool would be something that collected
> >real-life data on menu use, and allowed us to collect it (modulo privacy
> >concerns etc.)
> >
> >Asking a self-selecting population is notoriously tricky for getting
> >meaningful answers.
> >  
> How about my recent Character Style patch? Is this something in the 
> spirit of your GUI design (most important things first etc.)?

I'm at a conference right now, I'll try and look tonight?

john


Re: Active table and math toolbar

2006-09-07 Thread John Levon
On Thu, Sep 07, 2006 at 08:54:38PM +0200, Michael Gerz wrote:

> Why don't we activate the toolbars for now (and for 1.4.3)? The 
> activation is not a showstopper in case someone wants to optimize the 
> look & feel later.

Let's activate it for 1.5.0svn and see what happens, but not 1.4...

regards
john


Re: USE_CYGWIN_PACKAGING

2006-09-07 Thread Enrico Forestieri
On Thu, Sep 07, 2006 at 03:02:59PM -0500, Bo Peng wrote:
> On 9/7/06, Bo Peng <[EMAIL PROTECTED]> wrote:
> >> IMO, USE_CYGWIN_PACKAGING is neither needed nor useful. You don't have
> 
> Hi, Enrico,
> 
> Could you please apply the attached patch, install scons-local, run
> 
> python scons.py -f development/scons/SConstruct DESTDIR=cygwin_test
> mode=release install

I had already installed scons, so I ran "scons -f ...", instead.
I have not installed the boost libraries, so included boost was used.
Scons detected that I have Aiksaurus and compilation went smooth
till the final link stage which however failed as follows:

g++ -o release/qt2/lyx.exe -Wl,--enable-runtime-pseudo-reloc 
-Wl,--script,/tmp/i386pe.x-no-rdata -Wl,-s release/common/main.o -Lrelease/libs 
-L/usr/lib/qt3/lib -L/usr/X11R6/lib -llyxbase_pre -lmathed -linsets -lfrontends 
-lqt2 -lcontrollers -lgraphics -lsupport -llyxbase_post 
-lincluded_boost_signals -lincluded_boost_regex -lincluded_boost_filesystem 
-lqt-mt -lintl -lshlwapi -lstdc++ -lz -liconv -lgdi32 -lAiksaurus -laspell
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot 
find -lAiksaurus
collect2: ld returned 1 exit status
scons: *** [release/qt2/lyx.exe] Error 1
scons: building terminated because of errors.

After I added "extra_lib_path=/usr/local/lib" to the scons command line
(libAiksaurus.dll.a is there) everything went fine till the end.

> and check if the files are correctly installed as described in
> http://cygwin.com/setup.html ?

It seems ok to me. However, don't be afraid, they (cygwin-apps) will tell
you if something needs to be tuned.

> Index: README.Cygwin
> ===
> --- README.Cygwin (revision 14932)
> +++ README.Cygwin (working copy)
> @@ -1,32 +1,44 @@
>  LyX/Cygwin
> +==
> +
>  Ruurd Reitsma  <[EMAIL PROTECTED]>
> +Bo Peng 
>  
> -There are two ways to run LyX on Windows:
> -* as a native Windows application, using the Qt/Win Free clone of
> -  Trolltech's cross-platform Qt toolkit.
> -* as a POSIX application running under the Cygwin environment.
>  
>  This README describes what is needed for the latter of these two
>  options. Please refer to README.Win32 if you'd like to run LyX
>  as a native Windows application.

Maybe the previous last three lines should be deleted, too?

> +
> +Hide the cygwin console
> +===
> +
>  If you want to run LyX with no console windows open, there's a small
>  program in development/Win32 that will set the proper environment vars
>  and start LyX.

I am afraid both lyxwin32.c and lyxprofile are not in development/Win32
anymore...

I am attaching here a small script which will help you spotting dependencies.
Launching it with a directory name as an argument (chkdep dir), it will
scan that directory for executables and libraries and tells you the names
of the packages containing the needed dynamic libraries.

I also suggest that you apply this patch for the cygwin distribution:
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg100129.html
(in case JMarc does not agree to apply it to 1.4.x) as you are allowed
to apply local patches to the upstream sources.

-- 
Enrico
#!/bin/sh
find $1 -name '*.exe' -o -name '*.dll' -o -name '*.bin' | \xargs cygcheck | \
   sed -e '/\.exe/d' -e 's,\\,/,g' | sort -bu | \
   xargs -n1 cygpath -u | xargs cygcheck -f | uniq


Re: USE_CYGWIN_PACKAGING

2006-09-07 Thread Bo Peng

I have not installed the boost libraries, so included boost was used.


Even if you have installed boost, the included boost will be used
after a version check.


Scons detected that I have Aiksaurus and compilation went smooth
till the final link stage which however failed as follows:
After I added "extra_lib_path=/usr/local/lib" to the scons command line
(libAiksaurus.dll.a is there) everything went fine till the end.


This is something need to be fixed. I will have a look.


scan that directory for executables and libraries and tells you the names
of the packages containing the needed dynamic libraries.


I will do this within SConstruct.


I also suggest that you apply this patch for the cygwin distribution:


This patch should be applied. I have seen it twice but JMarc somehow
missed them.

Thanks.
Bo


Hebrew Translation

2006-09-07 Thread Guy Rutenberg

hi,

I would like to help with the hebrew translation of the LyX documentation. I
contacted Tzafrir Cohen (which is listed as the contact for hebrew) but he
told me that he doesn't activly maintain the hebrew translation. As there is
no active contact for hebrew translation i don't know how can i help with
the translation. I would thank you if you could explain to me how can i send
new translation for the documentation and if I can be the hebrew tranlation
contact man.

Best Regards,
Guy Rutenberg