Re: [Cvslog] r15872 - in /lyx-devel/trunk: Status.15x src/frontends/qt...

[Georg Baum]

Am Sonntag, 12. November 2006 10:36 schrieb [EMAIL PROTECTED]:
 Author: baum
 Date: Sun Nov 12 10:36:08 2006
 New Revision: 15872
 
 URL: http://www.lyx.org/trac/changeset/15872
 Log:
 Fix translation of ambiguous messages
 
   * src/frontends/qt4/ui/QPrefConvertersUi.ui: Readd translation hint
   to label and remove broken tooltip that somebody created instead
 
   * src/messages.C
   (Messages::Pimpl::get): reenable stripping of [[..]] from
   untranslated messages
 
 Modified:
 lyx-devel/trunk/Status.15x
 lyx-devel/trunk/src/frontends/qt4/ui/QPrefConvertersUi.ui
 lyx-devel/trunk/src/messages.C


It turned out that somebody converted the translation hint to a tooltip:


 Modified: lyx-devel/trunk/src/frontends/qt4/ui/QPrefConvertersUi.ui
 URL: 
http://www.lyx.org/trac/file/lyx-devel/trunk/src/frontends/qt4/ui/QPrefConvertersUi.ui?rev=15872
 
==
 --- lyx-devel/trunk/src/frontends/qt4/ui/QPrefConvertersUi.ui (original)
 +++ lyx-devel/trunk/src/frontends/qt4/ui/QPrefConvertersUi.ui Sun Nov 12 
10:36:08 2006
 @@ -146,11 +146,8 @@
   /item
   item row=1 column=0 
widget class=QLabel name=converterToLA 
 -   property name=toolTip 
 -stringlt;htmllt;headlt;meta name=qrichtext 
content=1 /lt;/headlt;body style= white-space: pre-wrap; 
font-family:Sans Serif; font-size:9pt; font-weight:400; font-style:normal; 
text-decoration:none;lt;p style= margin-top:0px; margin-bottom:0px; 
margin-left:0px; margin-right:0px; -qt-block-indent:0; 
text-indent:0px;[[as in 'From format x to format 
y']]lt;/plt;/bodylt;/html/string
 -   /property
 -   property name=text 
 -stringamp;To:/string
 +   property name=text 
 +stringamp;To:[[as in 'From format x to format y']]/string
 /property
 property name=buddy 
  cstringconverterToCO/cstring
 


Because of the recent translation remerge the translations for this tstring 
are lost. This is a reminder that a suffix [[]] of a message is a 
translation hint for ambigous messages. It gets stripped if no translation 
is provided, and it should not be removed!


Georg

'Private Mail' for Joost.

[Andre Poenitz]

Joost, your SF account seems to be overly sensitive when it comes to
identification of spam:

- Forwarded message from Mail Delivery System [EMAIL PROTECTED] -

Date: Sat, 11 Nov 2006 10:16:17 +0100
From: Mail Delivery System [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Mail-Fehler - Mail delivery failed: returning message to sender

Diese Mail wurde automatisch erzeugt vom Mail-Transportsystem auf
   lana.hrz.tu-chemnitz.de, Mail-Relay der TU Chemnitz, Deutschland
-- This message was created automatically by mail delivery software at
lana.hrz.tu-chemnitz.de, e-mail relay at Chemnitz University, Germany
[EMAIL PROTECTED]

Eine E-Mail mit der Absenderadresse [EMAIL PROTECTED]
gesendet vom Rechner dialin-212-144-009-148.pools.arcor-ip.net [212.144.9.148]
konnte an folgende Empfaenger NICHT ZUGESTELLT werden:

-- A message with sender address [EMAIL PROTECTED]
-- sent by host dialin-212-144-009-148.pools.arcor-ip.net [212.144.9.148]
-- could NOT BE DELIVERED to the following address(es):

  [EMAIL PROTECTED]
SMTP error from remote mail server after end of data:
host mail.sourceforge.net [66.35.250.206]: 550-SPAM:
This message appears to be spam (5.5 points).
550--
550-If you believe this message was classified as spam in error,
550-please open a Support Request at the URL below.
550-(Please include this message in any Support Request).
550--
550--
550-Spam Filtering performed by sourceforge.net.
550-See http://spamassassin.org/tag/ for more details.
550-Report problems to 
http://sf.net/tracker/?func=addgroup_id=1atid=21
550-1.0 FORGED_RCVD_HELO   Received: contains a forged HELO
550 4.5 DATE_IN_PAST_48_96 Date: is 48 to 96 hours before Received:
date

 Es folgt eine Kopie der E-Mail mit allen Header-Zeilen: 
--   This is a copy of the message, including all the headers: --

Return-path: [EMAIL PROTECTED]
Received: from dialin-212-144-009-148.pools.arcor-ip.net ([212.144.9.148] 
helo=millo.mpi.htwm.de)
by lana.hrz.tu-chemnitz.de with esmtpa (Exim 4.60)
(envelope-from [EMAIL PROTECTED])
id 1Gioy5-0002Pf-GF; Sat, 11 Nov 2006 10:16:06 +0100
Received: by millo.mpi.htwm.de (Postfix, from userid 500)
id EB0D27EC91; Wed,  8 Nov 2006 23:25:39 +0100 (CET)
Date: Wed, 8 Nov 2006 23:25:39 +0100
From: Andre Poenitz [EMAIL PROTECTED]
To: Joost Verburg [EMAIL PROTECTED]
Cc: Lars Gullik =?iso-8859-1?Q?Bj=F8nnes?= [EMAIL PROTECTED],
LyX Developers List lyx-devel@lists.lyx.org
Subject: Re: About New TabBar and Multiple-Windows
Message-ID: [EMAIL PROTECTED]
References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL 
PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL 
PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: [EMAIL PROTECTED]
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.9 (/)
X-Spam-Report: --- Start der SpamAssassin 3.1.6 Textanalyse (-0.9 Punkte)
Fragen an/questions to:  Postmaster TU Chemnitz [EMAIL PROTECTED]
0.5 DATE_IN_PAST_48_96 Absendezeit 48 bis 96 Stunden vor Datum in
Received-Kopfzeilen
-1.4 ALL_TRUSTEDNachricht wurde nur ueber 
vertrauenswuerdige Rechner
weitergeleitet
--- Ende der SpamAssassin Textanalyse
X-Scan-Signature: e90a451e269f6704296cddf3d75231cf

On Wed, Nov 01, 2006 at 08:09:08PM +0100, Joost Verburg wrote:
 Lars Gullik Bj=F8nnes wrote:
 sure it does. I do this all the time with emacs and firefox.
=20
 Firefox has only a single process for all windows.
=20
 In LyX you can have right now:
=20
 1) Multiple LyX instances (different processes)
 2) Multiple windows per instance
 3) Multiple documents per window
=20
 2) and 3) share the same data, but 1) does not. Do you really expect th=
e=20
 users to know which windows belong to which instance?
=20
 It should not be possible to have the same document in, say, 3 windows,=
=20
 where window 1 and 2 share the data but window 3 does not.

And a solution for that would be to have one window per instance.

Andre'



- End forwarded message -

-- 

Re: Let us remove the multi-window support !

[Andre Poenitz]

On Tue, Nov 07, 2006 at 08:00:18PM +0100, Joost Verburg wrote:
 José Matos wrote:
 Instead of hard-coding this like on Mac OS X right now, the Windows /
 Mac installers can set a default in lyxrc.dist and users will always be
 able to change it.
 
   There are two separate issues as we have discussed before. I don't have 
   any problem with your proposal above.
 
 OK. I'm only talking about the situation when a user clicks the LyX icon 
 on the desktop or start menu. If LyX is already running, normal behavior 
 for a Windows application is to open a new window in the current process.

I pretty mch doubt this can be considered 'normal behaviour'. MS
Visual Studio starts another process. Windows Explorer can be configured
to use separate processes. The command prompt starts another process.

Andre' 

Re: cutandpaste.C simplifications

[Andre Poenitz]

On Tue, Nov 07, 2006 at 09:06:14AM +0100, Jean-Marc Lasgouttes wrote:
  Martin == Martin Vermeer [EMAIL PROTECTED] writes:
 
 Martin On Mon, Nov 06, 2006 at 11:03:55PM +0100, Michael Gerz wrote:
  Hi,
  
  am I too stupid to see the brilliancy of the code or can
  cutandpaste.C be simplified?
 
 Martin Probably both ;-)
  
 Yes, I suspect that someone wanted to play with all the new toys he
 read about in a C++ book.

OTOH, the 'push_back()' of the empty par and filling it in-place as
opposed to filling it outside and append it later might be intentional
as this effectively saves a deep copy.

Andre'

Re: Question about wide inset...

[Andre Poenitz]

On Tue, Nov 07, 2006 at 05:47:25PM +0100, Lars Gullik Bjønnes wrote:
 I think you should also change setWide to wide...
 
 void wide(bool wide_inset) { wide_inset_ = wide_inset; }
 
 either both setX and getX, or just X and X (I like this last one
 best.)

X and X is pretty confusing as one can never be certain whether
'foo(x)' is a setter for x or a const function taking an additional
argument.

x-xgetX-setX setX-x

aethetics00-
line noise   +-0
clarity  -++

sum: 000

So all depends on the relative weight you put on the categories.

I actually like the setX/x combo as most function calls are usually
getters, so this is low noise overhead.

Andre'

Re: Single-instance support on Windows

[Andre Poenitz]

On Sat, Nov 11, 2006 at 12:45:31AM +0100, Jean-Marc Lasgouttes wrote:
 Joost should be sent to all open windows using EnumWindows. In
 Joost GuiApplication.C, a WinEventHandler function can capture this
 Joost message and send a return value, so the calling process knows
 Joost that LyX is found.
 
 Why is he mutex useful?

Races.

It would be the right thing to use if a single instance were wanted.
That, however, I dispute.

Andre'

Re: Can LyX handle large files ?

[Andre Poenitz]

On Tue, Nov 07, 2006 at 11:14:03PM +0100, Abdelrazak Younes wrote:
 Asger Ottar Alstrup wrote:
 Asger Ottar Alstrup wrote:
 Try running LyX with a command line parameter -dbg any and inspect 
 the output when redrawing. If lots of stuff is coming out, review that 
 output to make sure it is not done like the above.
 
 Most of it was done wrong - some of it even using monsters like 
 BOOST_CURRENT_FUNCTION. Who knows what voodoo that shit does?
 
 I've changed it. Please test. There is a fair chance this gives a nice 
 speedup, maybe even on MacOS as well.
 
 That would be an easy way out but I am not convinced... Visually 
 speaking, all these if are not very nice...

That's why we shoul use macros there:

Instead of

  lyxerr[Debug::PAINTING]  draw   std::string(str.toUtf8())
  at   x  ,  y  std::endl;

which is slow, or

if (whatever(Debug::PAINTING)) {
lyxerr[Debug::PAINTING]  draw   std::string(str.toUtf8())
  at   x  ,  y  
std::endl;
}

which is (significantly) faster but too noisy to be useful on a big
scale


  LYXERR(draw   std::string(str.toUtf8())   at   x  ,  y);

should be used. This is as fast a the second version and even more
compact than the first.

Andre'

Re: citation dialog

[Andre Poenitz]

On Fri, Nov 10, 2006 at 10:15:56PM +0100, Alfredo Braunstein wrote:
 Hehe I'd love to come back... I hope to find some time soon (more than the
 one needed to occasionally lurk on the list at least!)
 
 Btw, it seems that you guys are doing a wonderful job with 1.5!

Looks like you haven't even compiled 1.5.x so far...

Andre'

Re: Can LyX handle large files ?

[Andre Poenitz]

On Tue, Nov 07, 2006 at 04:43:07PM +0100, Abdelrazak Younes wrote:
 As my painting investigation continue, it seems that this problem has 
 _nothing_ to do with painting on screen at all. Modifying a text line 
 between two huge formula exhibits the slow behaviour even if only the 
 text line is repainted on screen (you can use -dbg painting to make 
 sure of that.

As I said. Mathed is essentially uchanged since 1.2.0. It was completely
different before, but speed was acceptable in the 1.2.x and 1.3.x
series. So whatever triggers that behaviour is some recent interaction.

Note that I am not saying the data model is perfect, especially since
I changed my stance about reference counting and deep copies vs COW
lately.

 I guess this could be related to the data memory models used in mathed. 
 Maybe some big tables created/deleted on the fly?

Hm... the macro tables?

 Also, this comment from Michael Wojcik* makes me wonder if maybe mathed 
 does something special with lyxerr... any clue someone?

We should have a macro encapsulating lyxerr that guarantees minimal
overhead...

 So, for example, if LyX were running with debug enabled, the debug
 lines being written to the LyX console window might cause a noticeable
 jump in csrss load.  But I haven't tested that.

[Console output is terribly slow on Windows btw.]

Andre'

Re: Can LyX handle large files ?

[Andre Poenitz]

On Tue, Nov 07, 2006 at 12:14:46PM +0100, Abdelrazak Younes wrote:
 I've tested again this document and the good news is that the 
 performance will soon be a bit better in 1.5 with my forthcoming 
 painting performance patch. But the problem I think Georg is right in 
 that the problem lies in how lines and symbols are painted on screen 
 with mathed.

While this might be true, it is also a fact that math painting has not
significantly changed since 1.2.0, in fact, this was the first component
using two-phase-drawing. So it is a bit strange that nowadays it shuld
be suddenly the bottleneck.

Andre' 

Re: cutandpaste.C simplifications

[Andre Poenitz]

On Tue, Nov 07, 2006 at 05:49:31PM +0100, Lars Gullik Bjønnes wrote:
 Michael Gerz [EMAIL PROTECTED] writes:
 
 | Hi,
 | 
 | am I too stupid to see the brilliancy of the code
 
 yes.
 (oh where did the friday go...)
 
 It is in the vein of prefere algorithms to manual constructs

... even if it hurts terribly.

Andre'

Re: [Cvslog] r15872 - in /lyx-devel/trunk: Status.15x src/frontends/qt...

[Edwin Leuven]

Georg Baum wrote:

Am Sonntag, 12. November 2006 10:36 schrieb [EMAIL PROTECTED]:
It turned out that somebody converted the translation hint to a tooltip:


oops, that was me i think

Because of the recent translation remerge the translations for this tstring 
are lost. This is a reminder that a suffix [[]] of a message is a 
translation hint for ambigous messages. It gets stripped if no translation 
is provided, and it should not be removed!


didn't know that, i thought it was part to the label since it doesn't 
get stripped in my native english lyx version (1.4.3)

Re: [Cvslog] r15872 - in /lyx-devel/trunk: Status.15x src/frontends/qt...

[Michael Gerz]

Georg Baum wrote:

Because of the recent translation remerge the translations for this tstring 
are lost. This is a reminder that a suffix [[]] of a message is a 
translation hint for ambigous messages. It gets stripped if no translation 
is provided, and it should not be removed!
 


FYI: I will remerge the po files soon due to minimal changes in stdmenus.ui.

Georg, are you going to commit new stuff soon? In that case, I will wait.

Michael

Re: Can LyX handle large files ?

[Abdelrazak Younes]

Andre Poenitz wrote:

On Tue, Nov 07, 2006 at 12:14:46PM +0100, Abdelrazak Younes wrote:
I've tested again this document and the good news is that the 
performance will soon be a bit better in 1.5 with my forthcoming 
painting performance patch. But the problem I think Georg is right in 
that the problem lies in how lines and symbols are painted on screen 
with mathed.


While this might be true, it is also a fact that math painting has not
significantly changed since 1.2.0, in fact, this was the first component
using two-phase-drawing. So it is a bit strange that nowadays it shuld
be suddenly the bottleneck.


I didn't say that mathed is the culprit here. I am just saying that the 
problem is triggered by mathed which uses a lot of insets apparently. I 
don't really know if the problem lies in the InsetIterators or the 
ParIterator or something else but I am pretty sure this has nothing to 
do with drawing anyway.


Abdel.

PS: I removed lyx-general for the recipients.

Re: [Cvslog] r15872 - in /lyx-devel/trunk: Status.15x src/frontends/qt...

[Georg Baum]

Am Sonntag, 12. November 2006 11:17 schrieb Michael Gerz:
 Georg, are you going to commit new stuff soon? In that case, I will wait.

I might do some further unciode stuff, but that does not change the 
messages.


Georg

Re: [Cvslog] r15872 - in /lyx-devel/trunk: Status.15x src/frontends/qt...

[Georg Baum]

Am Sonntag, 12. November 2006 11:16 schrieb Edwin Leuven:

 didn't know that, i thought it was part to the label since it doesn't 
 get stripped in my native english lyx version (1.4.3)

That is a bug then. Are you using the dummy Messages class? If yes you 
might need to implement the stripping in that class, too.


Georg

Re: Can LyX handle large files ?

[Abdelrazak Younes]

Andre Poenitz wrote:

On Tue, Nov 07, 2006 at 04:43:07PM +0100, Abdelrazak Younes wrote:
As my painting investigation continue, it seems that this problem has 
_nothing_ to do with painting on screen at all. Modifying a text line 
between two huge formula exhibits the slow behaviour even if only the 
text line is repainted on screen (you can use -dbg painting to make 
sure of that.


As I said. Mathed is essentially uchanged since 1.2.0. It was completely
different before, but speed was acceptable in the 1.2.x and 1.3.x
series. So whatever triggers that behaviour is some recent interaction.


Indeed, the problem only appears with 1.4.



Note that I am not saying the data model is perfect, especially since
I changed my stance about reference counting and deep copies vs COW
lately.

I guess this could be related to the data memory models used in mathed. 
Maybe some big tables created/deleted on the fly?


Hm... the macro tables?


I've tried to disable buildMacro() but that didn't help much.


Also, this comment from Michael Wojcik* makes me wonder if maybe mathed 
does something special with lyxerr... any clue someone?


We should have a macro encapsulating lyxerr that guarantees minimal
overhead...


Agreed. And I agree also with your macro proposal.




So, for example, if LyX were running with debug enabled, the debug
lines being written to the LyX console window might cause a noticeable
jump in csrss load.  But I haven't tested that.


[Console output is terribly slow on Windows btw.]


And maybe that is the main problem. IIRC correctly LyX is compiled as a 
console application; maybe, _maybe_, the problem with csrss.exe will 
disappear if we change that.


Abdel.

Classis.ui - Obsolete?

[Michael Gerz]

Hello,

are we going to maintain classic.ui for LyX 1.5.0?

I guess it is neither feature complete nor does it reflect the latest 
bookmark changes. There may also be some problems with shortcuts.


I am tempted to remove it from the repository. What do you think?

Michael

Re: [Cvslog] r15872 - in /lyx-devel/trunk: Status.15x src/frontends/qt...

[Edwin Leuven]

Georg Baum wrote:
That is a bug then. Are you using the dummy Messages class? If yes you 
might need to implement the stripping in that class, too.


i don't know anything about this stuff. the windows installer this is...

Re: Can LyX handle large files ?

[christian . ridderstrom]

On Sat, 11 Nov 2006, Andre Poenitz wrote:


   LYXERR(draw   std::string(str.toUtf8())   at   x  ,  y);
 
 should be used. This is as fast a the second version and even more
 compact than the first.

Peter sent a patch to the list just three days ago that used the above 
approach. He didn't report any significant gains with though.

http://article.gmane.org/gmane.editors.lyx.devel/72138

Maybe it should go in regardless?

/Christian

-- 
Christian Ridderström, +46-8-768 39 44   http://www.md.kth.se/~chr

Re: r15876 - /lyx-devel/trunk/src/bufferview_funcs.C

[Abdelrazak Younes]

[EMAIL PROTECTED] wrote:

Author: younes
Date: Sun Nov 12 12:03:55 2006
New Revision: 15876

URL: http://www.lyx.org/trac/changeset/15876
Log:
- coordOffset(): add an assertion on par.rows() emptiness before accessing it 
and a FIXME.


Opinion?



Modified:
lyx-devel/trunk/src/bufferview_funcs.C

Modified: lyx-devel/trunk/src/bufferview_funcs.C
URL: 
http://www.lyx.org/trac/file/lyx-devel/trunk/src/bufferview_funcs.C?rev=15876
==
--- lyx-devel/trunk/src/bufferview_funcs.C (original)
+++ lyx-devel/trunk/src/bufferview_funcs.C Sun Nov 12 12:03:55 2006
@@ -177,6 +177,8 @@
// Add contribution of initial rows of outermost paragraph
CursorSlice const  sl = dit[0];
Paragraph const  par = sl.text()-getPar(sl.pit());
+   // FIXME: I wonder if a case exists where this could happen:
+   BOOST_ASSERT(!par.rows().empty());
y -= par.rows()[0].ascent();
 #if 1
size_t rend;

Re: [Cvslog] r15872 - in /lyx-devel/trunk: Status.15x src/frontends/qt...

[Georg Baum]

Am Sonntag, 12. November 2006 11:37 schrieb Edwin Leuven:
 Georg Baum wrote:
  That is a bug then. Are you using the dummy Messages class? If yes you 
  might need to implement the stripping in that class, too.
 
 i don't know anything about this stuff. the windows installer this is...

OK, I changed the dummy variant in trunk. This should probably be done in 
1.4, too. I am surprised that the windows installer does not use the 
translations.


Georg

Re: r15867 - /lyx-devel/trunk/Status.15x

[Juergen Spitzmueller]

[EMAIL PROTECTED] wrote:
 +* broken signal/slot connection:
 +  Object::connect: No such signal
 LengthCombo::selectionChanged(LyXLength::UNIT) +  Object::connect:  (sender
 name:   'unitCO')
 +  Object::connect:  (receiver name: 'QVSpaceUi')

The attached patch fixes that. I'll commit soon.

Jürgen

BTW seems that deleting any kind of inset crashes LyX currently.
Index: src/frontends/qt4/QExternalDialog.C
===
--- src/frontends/qt4/QExternalDialog.C	(Revision 15873)
+++ src/frontends/qt4/QExternalDialog.C	(Arbeitskopie)
@@ -65,7 +65,7 @@ QExternalDialog::QExternalDialog(QExtern
 	connect( extraED, SIGNAL( textChanged(const QString) ), this, SLOT( extraChanged(const QString) ) );
 	connect( extraFormatCO, SIGNAL( activated(const QString) ), this, SLOT( formatChanged(const QString) ) );
 	connect( widthUnitCO, SIGNAL( activated(int) ), this, SLOT( widthUnitChanged() ) );
-	connect( heightUnitCO, SIGNAL( selectionChanged(LyXLength::UNIT) ), this, SLOT( change_adaptor() ) );
+	connect( heightUnitCO, SIGNAL( selectionChanged(lyx::LyXLength::UNIT) ), this, SLOT( change_adaptor() ) );
 	connect( displayCB, SIGNAL( stateChanged(int) ), this, SLOT( change_adaptor() ) );
 	connect( displayscaleED, SIGNAL( textChanged(const QString) ), this, SLOT( change_adaptor() ) );
 	connect( angleED, SIGNAL( textChanged(const QString) ), this, SLOT( change_adaptor() ) );
Index: src/frontends/qt4/QVSpaceDialog.C
===
--- src/frontends/qt4/QVSpaceDialog.C	(Revision 15873)
+++ src/frontends/qt4/QVSpaceDialog.C	(Arbeitskopie)
@@ -46,7 +46,7 @@ QVSpaceDialog::QVSpaceDialog(QVSpace * f
 connect( valueLE, SIGNAL( textChanged(const QString) ), this, SLOT( change_adaptor() ) );
 connect( spacingCO, SIGNAL( activated(int) ), this, SLOT( enableCustom(int) ) );
 connect( keepCB, SIGNAL( clicked() ), this, SLOT( change_adaptor() ) );
-connect( unitCO, SIGNAL( selectionChanged(LyXLength::UNIT) ), this, SLOT( change_adaptor() ) );
+connect( unitCO, SIGNAL( selectionChanged(lyx::LyXLength::UNIT) ), this, SLOT( change_adaptor() ) );
 
 	valueLE-setValidator(unsignedLengthValidator(valueLE));
 }
Index: src/frontends/qt4/QBoxDialog.C
===
--- src/frontends/qt4/QBoxDialog.C	(Revision 15873)
+++ src/frontends/qt4/QBoxDialog.C	(Arbeitskopie)
@@ -39,10 +39,10 @@ QBoxDialog::QBoxDialog(QBox * form)
 		form, SLOT(slotClose()));
 
 connect( widthED, SIGNAL( textChanged(const QString) ), this, SLOT( change_adaptor() ) );
-connect( widthUnitsLC, SIGNAL( selectionChanged(LyXLength::UNIT) ), this, SLOT( change_adaptor() ) );
+connect( widthUnitsLC, SIGNAL( selectionChanged(lyx::LyXLength::UNIT) ), this, SLOT( change_adaptor() ) );
 connect( valignCO, SIGNAL( highlighted(const QString) ), this, SLOT( change_adaptor() ) );
 connect( heightED, SIGNAL( textChanged(const QString) ), this, SLOT( change_adaptor() ) );
-connect( heightUnitsLC, SIGNAL( selectionChanged(LyXLength::UNIT) ), this, SLOT( change_adaptor() ) );
+connect( heightUnitsLC, SIGNAL( selectionChanged(lyx::LyXLength::UNIT) ), this, SLOT( change_adaptor() ) );
 connect( restorePB, SIGNAL( clicked() ), this, SLOT( restoreClicked() ) );
 connect( typeCO, SIGNAL( activated(int) ), this, SLOT( change_adaptor() ) );
 connect( typeCO, SIGNAL( activated(int) ), this, SLOT( typeChanged(int) ) );

Re: r15867 - /lyx-devel/trunk/Status.15x

[Abdelrazak Younes]

Juergen Spitzmueller wrote:

[EMAIL PROTECTED] wrote:

+* broken signal/slot connection:
+  Object::connect: No such signal
LengthCombo::selectionChanged(LyXLength::UNIT) +  Object::connect:  (sender
name:   'unitCO')
+  Object::connect:  (receiver name: 'QVSpaceUi')


The attached patch fixes that. I'll commit soon.

Jürgen

BTW seems that deleting any kind of inset crashes LyX currently.


Oups, might be my fault... I'll see to it.

Abdel.

Re: r15876 - /lyx-devel/trunk/src/bufferview_funcs.C

[Kornel Benko]

Am Sonntag, 12. November 2006 12:05 schrieb Abdelrazak Younes:
 [EMAIL PROTECTED] wrote:
  Author: younes
  Date: Sun Nov 12 12:03:55 2006
  New Revision: 15876
 
  URL: http://www.lyx.org/trac/changeset/15876
  Log:
  - coordOffset(): add an assertion on par.rows() emptiness before
  accessing it and a FIXME.

 Opinion?

  Modified:
  lyx-devel/trunk/src/bufferview_funcs.C
 
  Modified: lyx-devel/trunk/src/bufferview_funcs.C
  URL:
  http://www.lyx.org/trac/file/lyx-devel/trunk/src/bufferview_funcs.C?rev=1
 5876
  =
 = --- lyx-devel/trunk/src/bufferview_funcs.C (original)
  +++ lyx-devel/trunk/src/bufferview_funcs.C Sun Nov 12 12:03:55 2006
  @@ -177,6 +177,8 @@
  // Add contribution of initial rows of outermost paragraph
  CursorSlice const  sl = dit[0];
  Paragraph const  par = sl.text()-getPar(sl.pit());
  +   // FIXME: I wonder if a case exists where this could happen:
  +   BOOST_ASSERT(!par.rows().empty());
  y -= par.rows()[0].ascent();
   #if 1
  size_t rend;

Very easy to reproduce this here:

Program received signal SIGABRT, Aborted.
[Switching to Thread 1087020320 (LWP 22933)]
0xe410 in ?? ()
(gdb) bt
#0  0xe410 in ?? ()
#1  0xbfffdd88 in ?? ()
#2  0x0006 in ?? ()
#3  0x5995 in ?? ()
#4  0x40bb9d41 in raise () from /lib/tls/libc.so.6
#5  0x40bbb529 in abort () from /lib/tls/libc.so.6
#6  0x084f3e6b in lyx::support::abort ()
#7  0x080d090e in boost::assertion_failed ()
#8  0x08115805 in lyx::bv_funcs::coordOffset ()
#9  0x08115ae8 in lyx::bv_funcs::getPos ()
#10 0x0812d53e in lyx::LCursor::getPos ()
#11 0x083478bf in lyx::frontend::WorkArea::showCursor ()
#12 0x0834798b in lyx::frontend::WorkArea::toggleCursor ()
...

1 Start lyx
2 open a File which is at say 3 screen pages sized.
3 go to page 2
4 select new window
5 move pointer into the newly created window (here the new window has 
different size, because of the previous session)
6 move pointer back to the first window
== crash

Kornel
-- 
Kornel Benko
[EMAIL PROTECTED]


pgpx1atlUAUQB.pgp
Description: PGP signature

Re: citation dialog

[Alfredo Braunstein]

Andre Poenitz wrote:

 On Fri, Nov 10, 2006 at 10:15:56PM +0100, Alfredo Braunstein wrote:
 Hehe I'd love to come back... I hope to find some time soon (more than
 the one needed to occasionally lurk on the list at least!)
 
 Btw, it seems that you guys are doing a wonderful job with 1.5!
 
 Looks like you haven't even compiled 1.5.x so far...

Why? I did.

A/

German Translations

[Michael Gerz]

Hello, German users,

I have just committed some updates to de.po. The German localization 
should be more or less useable now. There are still about 150 messages 
to be translated but the most important ones (menu entries) are done. 
(It took quite some time to get all the shortcuts right.)


I will continue work on de.po by the end of the week,

Regards,
Michael

Re: citation dialog

[Alfredo Braunstein]

Alfredo Braunstein wrote:

 Andre Poenitz wrote:
 
 On Fri, Nov 10, 2006 at 10:15:56PM +0100, Alfredo Braunstein wrote:
 Hehe I'd love to come back... I hope to find some time soon (more than
 the one needed to occasionally lurk on the list at least!)
 
 Btw, it seems that you guys are doing a wonderful job with 1.5!
 
 Looks like you haven't even compiled 1.5.x so far...
 
 Why? I did.
 
 A/

Btw, hello ;-)

A/

Re: r15876 - /lyx-devel/trunk/src/bufferview_funcs.C

[Kornel Benko]

Am Sonntag, 12. November 2006 12:59 schrieb Kornel Benko:
 1 Start lyx
 2 open a File which is at say 3 screen pages sized.
 3 go to page 2
 4 select new window
 5 move pointer into the newly created window (here the new window has
 different size, because of the previous session)
 6 move pointer back to the first window
 == crash

No crash in revision 15881.
This was very fast.
Kornel
-- 
Kornel Benko
[EMAIL PROTECTED]


pgp924G5A1k06.pgp
Description: PGP signature

Re: r15867 - /lyx-devel/trunk/Status.15x

[Abdelrazak Younes]

Abdelrazak Younes wrote:

Juergen Spitzmueller wrote:

[EMAIL PROTECTED] wrote:

+* broken signal/slot connection:
+  Object::connect: No such signal
LengthCombo::selectionChanged(LyXLength::UNIT) +  Object::connect:  
(sender

name:   'unitCO')
+  Object::connect:  (receiver name: 'QVSpaceUi')


The attached patch fixes that. I'll commit soon.

Jürgen

BTW seems that deleting any kind of inset crashes LyX currently.


Oups, might be my fault... I'll see to it.


This is fixed now. FYI, I removed earlier the paragraph breaks redoing 
from setCursor(). I did that in order to optimise mouse navigation. I 
will review all setCursor() calls now.


Sorry for the disturbance,
Abdel.

Re: r15867 - /lyx-devel/trunk/Status.15x

[Abdelrazak Younes]

Abdelrazak Younes wrote:

Abdelrazak Younes wrote:

Juergen Spitzmueller wrote:

[EMAIL PROTECTED] wrote:

+* broken signal/slot connection:
+  Object::connect: No such signal
LengthCombo::selectionChanged(LyXLength::UNIT) +  Object::connect:  
(sender

name:   'unitCO')
+  Object::connect:  (receiver name: 'QVSpaceUi')


The attached patch fixes that. I'll commit soon.

Jürgen

BTW seems that deleting any kind of inset crashes LyX currently.


Oups, might be my fault... I'll see to it.


This is fixed now. FYI, I removed earlier the paragraph breaks redoing 
from setCursor(). I did that in order to optimise mouse navigation. I 
will review all setCursor() calls now.


I think I've solved all important issues due to my setCursor() change. I 
am (only now!) starting to get a good grasp of how things are working. 
IMO, it is no wonder that 1.4 is very slow compared to 1.3. We repeat a 
lot of operations unnecessarily. I believe that a true model/view 
separation in 1.6 will bring a huge performance improvement.


I am on the way to do some more optimisations nevertheless...

Abdel.

Re: [patch] Allow unicode labels in layout files

[Martin Vermeer]

On Sat, Nov 11, 2006 at 12:50:59PM +0100, Georg Baum wrote:
 Am Freitag, 10. November 2006 11:22 schrieb Georg Baum:
  Jean-Marc Lasgouttes wrote:
  
   Georg == Georg Baum
   [EMAIL PROTECTED]
   writes:
   
   Georg BTW, why is layout-labelstring() sometimes used untranslated?
   
   Where?
  
  When setting the setLabelWidthString of ParagraphParameters. This updated
  patch does also translate these cases. Is this OK, or is there some 
 special
  reason for not translating these cases?

I may be talking out of the back of my head, but isn't the label width
string only meant to specify the width of the label graphically, i.e.,
the label's contents don't matter but *should not change* from under the
user?

- Martin

windows bug fixing

[Georg Baum]

Am Sonntag, 12. November 2006 18:08 schrieb [EMAIL PROTECTED]:
  Do you say that 1.4.3-4 and 1.4.3-5 use a different code base?
 
 Yes I think so. It still bases on the version 1.4.3 source code but Joost 
has
 built in some new things to fix bug 2918, bug 2923, bug 2936. He also 
moved the
 debug output to a new application that informs the user about the debug 
output
 when LyX crashes.

Why are these fixes not in 1.4.4svn? Or if they are, why are they not 
mentioned in status.14x?

Why is this called 1.4.3-5 and not 1.4.3-winfixes5 or something like that? 
That creates confusion.


Georg

Re: [patch] Allow unicode labels in layout files

[Georg Baum]

Am Sonntag, 12. November 2006 19:03 schrieb Martin Vermeer:
 I may be talking out of the back of my head, but isn't the label width
 string only meant to specify the width of the label graphically, i.e.,
 the label's contents don't matter but *should not change* from under the
 user?

Yes. This is normally set by the user, only in the case when it is empty it 
is preset by LyX with the label string. If that makes sense at all then 
only with translation IMHO.


Georg

Re: 3 important bugs right now - more testing needed!

[Georg Baum]

Am Donnerstag, 9. November 2006 14:53 schrieb Jean-Marc Lasgouttes:
  Jean-Pierre == Jean-Pierre Chrétien [EMAIL PROTECTED] writes:
 
 Jean-Pierre Could the diacritics problem come from the list of
 Jean-Pierre locales not including utf8 ?
 
 What is the diacritics problem? That we cannot check accented
 characters? We should find a way to read unicode table and decide what
 is the class of the different characters (to replace the code in
 support/textutils.h). I think this is a prerequisite for 1.5.

I agree.

 Is this
  http://crl.nmsu.edu/~mleisher/ucdata.html
 something we could use?

Maybe.

 Or do we have a way to coerce the c library to 
  give us the information we need without switching locales?

The C library is only helpful if wchar_t is 4 byte wide. Otherwise it has 
no useful information about UCS4 strings.

 I see here that boost.Regex is able to use character properties:
 http://www.boost.org/libs/regex/doc/character_class_names.html
 
 Does that mean that we should also be able to access them with our
 current code?

No. They use the wchar_t stuff from the C library for wide strings 
internally. If that is usable (e.g. on linux) we can as well use it 
directly.

The attached patch does that. I am very tempted to apply it and have the 
windows people look for a solution for their platform. If such a solution 
is found we can still decide whether we use it always or only on windows.

Unless somebody has very good reasons to not use the C library support for 
wchar_t when it is usable I am going to put this in.

The proper C++ way would be to implement a full UCS4 ctype facet and use 
that instead of the stuff in textutils.h and lstrings.h, but I don't feel 
like doing this now.


Georg
Index: src/buffer.C
===
--- src/buffer.C	(Revision 15887)
+++ src/buffer.C	(Arbeitskopie)
@@ -554,11 +554,9 @@ void Buffer::insertStringAsLines(Paragra
 }
 space_inserted = true;
 			}
-/* FIXME: not needed anymore?
 		} else if (!isPrintable(*cit)) {
 			// Ignore unprintables
 			continue;
-*/
 		} else {
 			// just insert the character
 			par.insertChar(pos, *cit, font, params().trackChanges);
Index: src/support/lstrings.C
===
--- src/support/lstrings.C	(Revision 15887)
+++ src/support/lstrings.C	(Arbeitskopie)
@@ -32,6 +32,16 @@
 #include algorithm
 #include sstream
 
+#if defined(HAVE_WCHAR_T)  SIZEOF_WCHAR_T == 4
+// All implementations that have a 4byte wchar_t use UCS4 as encoding, so we
+// can simply use the wchar_t C library functions
+#include wctype.h
+#else
+// Steal some code from somewhere else, e.g. glib (look at gunicode.h)
+// The code that we currently use does not really work.
+#endif
+
+
 using lyx::docstring;
 
 using std::transform;
@@ -76,8 +86,8 @@ int compare_no_case(docstring const  s,
 	docstring::const_iterator p2 = s2.begin();
 
 	while (p != s.end()  p2 != s2.end()) {
-		int const lc1 = tolower(*p);
-		int const lc2 = tolower(*p2);
+		char_type const lc1 = lowercase(*p);
+		char_type const lc2 = lowercase(*p2);
 		if (lc1 != lc2)
 			return (lc1  lc2) ? -1 : 1;
 		++p;
@@ -94,7 +104,7 @@ int compare_no_case(docstring const  s,
 
 namespace {
 
-int ascii_tolower(int c) {
+char_type ascii_tolower(char_type c) {
 	if (c = 'A'  c = 'Z')
 		return c - 'A' + 'a';
 	return c;
@@ -108,8 +118,8 @@ int do_compare_ascii_no_case(String cons
 	typename String::const_iterator p2 = s2.begin();
 
 	while (p != s.end()  p2 != s2.end()) {
-		int const lc1 = ascii_tolower(*p);
-		int const lc2 = ascii_tolower(*p2);
+		char_type const lc1 = ascii_tolower(*p);
+		char_type const lc2 = ascii_tolower(*p2);
 		if (lc1 != lc2)
 			return (lc1  lc2) ? -1 : 1;
 		++p;
@@ -300,7 +310,9 @@ char uppercase(char c)
 	return char(toupper(c));
 }
 
-// FIXME for lowercase() and uppercase() function below:
+
+// FIXME UNICODE
+// for lowercase() and uppercase() function below when wchar_t is not used:
 // 1) std::tolower() and std::toupper() are templates that
 // compile fine with char_type. With the test (c = 256) we
 // do not trust these function to do the right thing with
@@ -310,19 +322,27 @@ char uppercase(char c)
 
 char_type lowercase(char_type c)
 {
+#if defined(HAVE_WCHAR_T)  SIZEOF_WCHAR_T == 4
+	return towlower(c);
+#else
 	if (c = 256)
 		return c;
 
 	return tolower(c);
+#endif
 }
 
 
 char_type uppercase(char_type c)
 {
+#if defined(HAVE_WCHAR_T)  SIZEOF_WCHAR_T == 4
+	return towupper(c);
+#else
 	if (c = 256)
 		return c;
 
 	return toupper(c);
+#endif
 }
 
 
Index: src/support/textutils.h
===
--- src/support/textutils.h	(Revision 15887)
+++ src/support/textutils.h	(Arbeitskopie)
@@ -17,12 +17,21 @@
 
 #include support/types.h
 
+#if defined(HAVE_WCHAR_T)  SIZEOF_WCHAR_T == 4
+// All implementations that have a 4byte wchar_t use UCS4 as encoding, so we
+// can simply use the wchar_t C library 

Re: windows bug fixing

[Uwe Stöhr]

Georg Baum schrieb:


Joost has
built in some new things to fix bug 2918, bug 2923, bug 2936. He also moved the
debug output to a new application that informs the user about the debug output
when LyX crashes.


Why are these fixes not in 1.4.4svn? Or if they are, why are they not 
mentioned in status.14x?


Bug 2936 is not fixed, I was too rash here.
I remember that I've seen the SVN-log for the fix of bug 2923.
I was surprised that bug 2918 is fixed because I haven't seen a 
corresponding SVN commit.


Joost currently has no bugzilla account so that he's not able to post 
something there.


regards Uwe

[patch] Check only once for dtl tools

[Enrico Forestieri]

In configure.py, DTL tools are checked for in two distinct places.
The attached patches fix this. Ok to apply to both 1.4.x and trunk?

-- 
Enrico
Index: lib/configure.py
===
--- lib/configure.py(revision 15890)
+++ lib/configure.py(working copy)
@@ -179,13 +179,23 @@ def checkViewer(description, progs, rc_e
 return checkProg(description, progs, rc_entry, path, not_found = 'auto')
 
 
-def checkLatex():
-''' Check latex, return lyx_check_config '''
+def checkDTLtools():
+''' Check whether DTL tools are available (Windows only) '''
 # Find programs! Returned path is not used now
 if ((os.name == 'nt' or sys.platform == 'cygwin') and
 checkProg('DVI to DTL converter', ['dv2dt']) != ['', ''] and
 checkProg('DTL to DVI converter', ['dt2dv']) != ['', '']):
 # Windows only: DraftDVI
+dtl_tools = 'true'
+else:
+dtl_tools = 'false'
+return dtl_tools
+
+
+def checkLatex(dtl_tools):
+''' Check latex, return lyx_check_config '''
+if (dtl_tools):
+# Windows only: DraftDVI
 converter_entry = r'''\converter latex  dvi2   %%latex
 \converter dvi2   dvipython -tt $$s/scripts/clean_dvi.py $$i $$o 
'''
 else:
@@ -213,7 +223,7 @@ def checkLatex():
 return ''
 
 
-def checkFormatEntries():  
+def checkFormatEntries(dtl_tools):  
 ''' Check all formats (\Format entries) '''
 checkViewer('a Tgif viewer and editor', ['tgif'],
 rc_entry = [r'\Format tgif   obj Tgif
%%%%'])
@@ -271,9 +281,7 @@ def checkFormatEntries():  
 #
 checkViewer('a DVI previewer', ['xdvi', 'kdvi'],
 rc_entry = [r'\Format dvidvi DVID  
%%'])
-if ((os.name == 'nt' or sys.platform == 'cygwin') and
-checkProg('DVI to DTL converter', ['dv2dt']) != ['', ''] and
-checkProg('DTL to DVI converter', ['dt2dv']) != ['', '']):
+if (dtl_tools):
 # Windows only: DraftDVI
 addToRC(r'\Format dvi2   dvi DraftDVI  
')
 #
@@ -747,6 +755,7 @@ Options:
 setEnviron()
 createDirectories()
 windows_style_tex_paths = checkTeXPaths()
+dtl_tools = checkDTLtools()
 ## Write the first part of outfile
 writeToFile(outfile, '''# This file has been automatically generated by 
LyX' lib/configure.py
 # script. It contains default settings that have been determined by
@@ -756,8 +765,8 @@ Options:
 # override the values given here.
 ''')
 # check latex
-LATEX = checkLatex()
-checkFormatEntries()
+LATEX = checkLatex(dtl_tools)
+checkFormatEntries(dtl_tools)
 checkConverterEntries()
 (chk_linuxdoc, bool_linuxdoc, linuxdoc_cmd) = checkLinuxDoc()
 (chk_docbook, bool_docbook, docbook_cmd) = checkDocBook()
Index: lib/configure.py
===
--- lib/configure.py(revision 15890)
+++ lib/configure.py(working copy)
@@ -183,13 +183,23 @@ def checkViewer(description, progs, rc_e
 return checkProg(description, progs, rc_entry, path, not_found = 'auto')
 
 
-def checkLatex():
-''' Check latex, return lyx_check_config '''
+def checkDTLtools():
+''' Check whether DTL tools are available (Windows only) '''
 # Find programs! Returned path is not used now
 if ((os.name == 'nt' or sys.platform == 'cygwin') and
 checkProg('DVI to DTL converter', ['dv2dt']) != ['', ''] and
 checkProg('DTL to DVI converter', ['dt2dv']) != ['', '']):
 # Windows only: DraftDVI
+dtl_tools = 'true'
+else:
+dtl_tools = 'false'
+return dtl_tools
+
+
+def checkLatex(dtl_tools):
+''' Check latex, return lyx_check_config '''
+if (dtl_tools):
+# Windows only: DraftDVI
 converter_entry = r'''\converter latex  dvi2   %%latex
 \converter dvi2   dvipython -tt $$s/scripts/clean_dvi.py $$i $$o 
'''
 else:
@@ -217,7 +227,7 @@ def checkLatex():
 return ''
 
 
-def checkFormatEntries():  
+def checkFormatEntries(dtl_tools):  
 ''' Check all formats (\Format entries) '''
 checkViewer('a Tgif viewer and editor', ['tgif'],
 rc_entry = [r'\Format tgif   obj Tgif
%%%%vector'])
@@ -278,9 +288,7 @@ def checkFormatEntries():  
 #
 checkViewer('a DVI previewer', ['xdvi', 'kdvi'],
 rc_entry = [r'\Format dvidvi DVID  
%%  document,vector'])
-if ((os.name == 'nt' or sys.platform == 'cygwin') and
-checkProg('DVI to DTL converter', ['dv2dt']) != ['', ''] and
-checkProg('DTL to DVI converter', ['dt2dv']) != ['', '']):
+if (dtl_tools):
 # Windows only: DraftDVI
 addToRC(r'\Format dvi2   dvi DraftDVI  
document,vector')
 #
@@ -756,6 +764,7 

Crash in view-something with Extended-Insets.lyx

[Kornel Benko]

Latest in trunk

in LyX open file Extended-Insets.lyx (The latest anounced by Uwe Stöhr,
http://wiki.lyx.org/LyX/DocumentationDevelopment#Extended-Insets)
view-DVI (or view-Postscript etc)
== crash
...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1087020320 (LWP 13458)]
0x40ba8f4d in __gconv_close () from /lib/tls/libc.so.6
(gdb) bt
#0  0x40ba8f4d in __gconv_close () from /lib/tls/libc.so.6
#1  0x40ba85dc in iconv_close () from /lib/tls/libc.so.6
#2  0x0851cb15 in lyx::IconvProcessor::~IconvProcessor ()
#3  0x0851eaac in std::pairstd::string, lyx::IconvProcessor::~pair ()
#4  0x0851daa3 in lyx::ucs4_to_eightbit ()
#5  0x081dcdd9 in lyx::(anonymous namespace)::TeXOnePar ()
#6  0x081dd4aa in lyx::latexParagraphs ()
#7  0x083114d9 in lyx::InsetText::latex ()
#8  0x082e3bc9 in lyx::InsetFoot::latex ()
#9  0x081eda72 in lyx::Paragraph::Pimpl::simpleTeXSpecialChars ()
#10 0x081e42e5 in lyx::Paragraph::simpleTeXOnePar ()
#11 0x081dc02b in lyx::(anonymous namespace)::TeXOnePar ()
#12 0x081dd4aa in lyx::latexParagraphs ()
#13 0x083114d9 in lyx::InsetText::latex ()
#14 0x082bfe3c in lyx::InsetBox::latex ()
...

But no problems with my other lyx-files

Kornel
--

Re: 3 important bugs right now - more testing needed!

[Jean-Marc Lasgouttes]

 Georg == Georg Baum [EMAIL PROTECTED] writes:

Georg No. They use the wchar_t stuff from the C library for wide
Georg strings internally. If that is usable (e.g. on linux) we can as
Georg well use it directly.

Georg The attached patch does that. I am very tempted to apply it and
Georg have the windows people look for a solution for their platform.
Georg If such a solution is found we can still decide whether we use
Georg it always or only on windows.

This is not a regression for windows anyway, right? I'd say to put the
patch in, except that it might be better to define a
USE_LIBC_WCHAR_SUPPORT (or something more explicit) define instead of
+#if defined(HAVE_WCHAR_T)  SIZEOF_WCHAR_T == 4

I am not sure where it should be defined, though.

JMarc

Re: [patch] esint support

[Jean-Marc Lasgouttes]

 Georg == Georg Baum [EMAIL PROTECTED] writes:

 Here is a patch that does that for InsetInclude. This is cleaner
 IMHO even if the special cases in TocBackend are still ugly.

Georg I like the solution with addToToc better. In general we tried
Georg to remove as much as possible special inset casing. All inset
Georg knowledge should be inside the insets.

Agreed. We have to get rid of as many uses of lyxCode as possible.
Virtual functions are here to help us.

JMarc

Re: Advice needed: Change tracking of End-Of-Par

[Jean-Marc Lasgouttes]

 Georg == Georg Baum [EMAIL PROTECTED] writes:

 Personally, I could live with the restriction but I would like to
 get your opinion before I spent more time on cleaning up change
 tracking.

Georg I think that the current solution is OK. 

I also think we should stick with that.

JMarc

Re: [patch] Check only once for dtl tools

[Jean-Marc Lasgouttes]

 Enrico == Enrico Forestieri [EMAIL PROTECTED] writes:

Enrico In configure.py, DTL tools are checked for in two distinct
Enrico places. The attached patches fix this. Ok to apply to both
Enrico 1.4.x and trunk?

Yes (I assume you have tested it :)

JMarc

Re: Crash in view-something with Extended-Insets.lyx

[Abdelrazak Younes]

Kornel Benko wrote:

Latest in trunk

in LyX open file Extended-Insets.lyx (The latest anounced by Uwe Stöhr,
http://wiki.lyx.org/LyX/DocumentationDevelopment#Extended-Insets)
view-DVI (or view-Postscript etc)
== crash


Does the attached patch helps?



But no problems with my other lyx-files


It seems that this file has multiple encodings, which is not the case 
normally.


Georg, did you test the support for multiple encodings and my associated 
changes with IconvProcessor?


Abdel.

Re: Crash in view-something with Extended-Insets.lyx

[Abdelrazak Younes]

Abdelrazak Younes wrote:

Kornel Benko wrote:

Latest in trunk

in LyX open file Extended-Insets.lyx (The latest anounced by Uwe Stöhr,
http://wiki.lyx.org/LyX/DocumentationDevelopment#Extended-Insets)
view-DVI (or view-Postscript etc)
== crash


Does the attached patch helps?


The patch...

Index: support/unicode.C
===
--- support/unicode.C   (revision 15890)
+++ support/unicode.C   (working copy)
@@ -52,10 +52,12 @@
 
 IconvProcessor::~IconvProcessor()
 {
+   /*
if (iconv_close(pimpl_-cd) == -1) {
lyxerr  Error returned from iconv_close(
 errno  )  endl;
}
+   */
delete pimpl_;
 }
 

Re: Advice needed: Change tracking of End-Of-Par

[José Matos]

On Saturday 11 November 2006 3:45 pm, Michael Gerz wrote:
 BTW, did you make up your mind about the CT related ile format change? If
 we decide that it is a change we should implement that before the first
 alpha.
   

 I think Jose mentioned that all author information are dropped during
 1.4-1.3 conversion. Nonetheless, it is still on my agenda.

  ??

  How can that be a problem?

  We are talking about 1.5, why should we be restrainted by 1.3?

 Michael

-- 
José Abílio

Re: Advice needed: Change tracking of End-Of-Par

[José Matos]

On Sunday 12 November 2006 8:43 pm, Jean-Marc Lasgouttes wrote:
 I also think we should stick with that.

  +1

 JMarc

-- 
José Abílio

Re: [patch] Check only once for dtl tools

[Enrico Forestieri]

On Sun, Nov 12, 2006 at 09:52:40PM +0100, Jean-Marc Lasgouttes wrote:

  Enrico == Enrico Forestieri [EMAIL PROTECTED] writes:
 
 Enrico In configure.py, DTL tools are checked for in two distinct
 Enrico places. The attached patches fix this. Ok to apply to both
 Enrico 1.4.x and trunk?
 
 Yes (I assume you have tested it :)

As always ;-)

-- 
Enrico

Re: Crash in view-something with Extended-Insets.lyx

[Abdelrazak Younes]

Kornel Benko wrote:

Latest in trunk

in LyX open file Extended-Insets.lyx (The latest anounced by Uwe Stöhr,
http://wiki.lyx.org/LyX/DocumentationDevelopment#Extended-Insets)
view-DVI (or view-Postscript etc)
== crash


I don't have a crash with or without my patch on Windows. But LateX 
gives me an error:


  Paragraph ended before [EMAIL PROTECTED] was complete.

I suspect you've forgotten a `}', causing me to apply this
control sequence to too much text. How can we recover?
My plan is to forget the whole thing and hope for the best.

Abdel.

Re: Crash in view-something with Extended-Insets.lyx

[Kornel Benko]

Am Sonntag, 12. November 2006 22:08 schrieb Abdelrazak Younes:
 Abdelrazak Younes wrote:
  Kornel Benko wrote:
  Latest in trunk
 
  in LyX open file Extended-Insets.lyx (The latest anounced by Uwe Stöhr,
  http://wiki.lyx.org/LyX/DocumentationDevelopment#Extended-Insets)
  view-DVI (or view-Postscript etc)
  == crash
 
  Does the attached patch helps?

 The patch...

Did not help :(

But this time the stack is as follows:
(gdb) bt
#0  0x40ba8dc9 in __gconv () from /lib/tls/libc.so.6
#1  0x40ba84ba in iconv () from /lib/tls/libc.so.6
#2  0x0851cd79 in lyx::IconvProcessor::convert ()
#3  0x0851e163 in lyx::(anonymous namespace)::iconv_convertchar, wchar_t ()
#4  0x0851db3f in lyx::ucs4_to_eightbit ()
#5  0x081dce39 in lyx::(anonymous namespace)::TeXOnePar ()
#6  0x081dd50a in lyx::latexParagraphs ()
#7  0x083115fd in lyx::InsetText::latex ()
#8  0x082e3ced in lyx::InsetFoot::latex ()
#9  0x081edad2 in lyx::Paragraph::Pimpl::simpleTeXSpecialChars ()
#10 0x081e4345 in lyx::Paragraph::simpleTeXOnePar ()
#11 0x081dc08b in lyx::(anonymous namespace)::TeXOnePar ()
#12 0x081dd50a in lyx::latexParagraphs ()
#13 0x083115fd in lyx::InsetText::latex ()
#14 0x082bff60 in lyx::InsetBox::latex ()
#15 0x081edad2 in lyx::Paragraph::Pimpl::simpleTeXSpecialChars ()
#16 0x081e4345 in lyx::Paragraph::simpleTeXOnePar ()
#17 0x081dc08b in lyx::(anonymous namespace)::TeXOnePar ()
#18 0x081dd50a in lyx::latexParagraphs ()
#19 0x080d87ee in lyx::Buffer::writeLaTeXSource ()
#20 0x080d7b5d in lyx::Buffer::makeLaTeXFile ()
#21 0x0813a701 in lyx::Exporter::Export ()
...
Kornel

-- 
Kornel Benko
[EMAIL PROTECTED]


pgpyWuZEbJZOh.pgp
Description: PGP signature

revert changeset 15545 and 15546

[Uwe Stöhr]

I don't like the change made in
http://www.lyx.org/trac/changeset/15545
and
http://www.lyx.org/trac/changeset/15546
as this destroys the date formatting.

Using
%A, %d %B %Y
instead of
%A, %e %B %Y
fixes the crash reported in bug 2839
http://bugzilla.lyx.org/show_bug.cgi?id=2839
and keeps the date formatting.

Opinions?

regards Uwe

Re: 3 important bugs right now - more testing needed!

[Enrico Forestieri]

On Sun, Nov 12, 2006 at 09:34:16PM +0100, Jean-Marc Lasgouttes wrote:

 This is not a regression for windows anyway, right?

Yes, neither mingw nor cygwin have support for anything else than
the C locale, and I doubt that MSVC has any, too.

 I'd say to put the
 patch in, except that it might be better to define a
 USE_LIBC_WCHAR_SUPPORT (or something more explicit) define instead of
 +#if defined(HAVE_WCHAR_T)  SIZEOF_WCHAR_T == 4

I tried to see whether the #ifdef's could be avoided altogether,
and simply use the wctype functions anyway. This would be possible
on cygwin, as the attached test program produces:

sizeof(wint_t) = 4
towupper(97) = 65
towupper(4294967295) = 4294967295

but it turned out that it is not possible with mingw, as the result was:

sizeof(wint_t) = 4
towupper(97) = 65
towupper(4294967295) = 65535

I don't know what happens with MSVC.

 I am not sure where it should be defined, though.

Isn't config.h the home of such things?

-- 
Enrico
#include stdio.h
#include wchar.h
#include wctype.h
#include limits.h

int main(void)
{
printf(sizeof(wint_t) = %d\n, sizeof(wint_t));
printf(towupper(97) = %d\n, towupper(97));
printf(towupper(%u) = %u\n, UINT_MAX, towupper(UINT_MAX));
return 0;
}

Re: problems with lyx 1.5

[Pavel Sanda]

 * outputs, look and feel, language settings in tools/oreferences dialog
  cant be translated, and i dont see the corresponding strings in .po file
  although i rememeber translating them previously.
  the same with open recent in file menu and other menu items. 
  it seems somebody unapropriately deleted items from .po files..
 
 Ts, ts... nobody removes items from each others .po file!
 
 Well, I did somehow :-) I followed your advice and added English 
 shortcuts whereever possible. As a consequence, several po entries have 
 changed.

i dont think this explains/corrects everything. e.g. Look and feel are not 
part
of the menu. even in new remerged .po i cant see the string for translation.
in the initial revision the string and the translation was there.

 #: src/lengthcommon.C:39
 msgid Line Width %
 (line in the sense of line of the table or row of text?)
  
if 
 Good question. Create a doc with this setting and export to LaTeX :-)

if i had found in which dialog its appearing, i wouldnt have asked :)

pavel

Re: problems with lyx 1.5

[Michael Gerz]

Pavel Sanda schrieb:

i dont think this explains/corrects everything. e.g. Look and feel are not 
part
of the menu. even in new remerged .po i cant see the string for translation.
in the initial revision the string and the translation was there.
  

??? Hmmm I don't feel guilty. Where is Look and feel used?


if i had found in which dialog its appearing, i wouldnt have asked :)
  

It is used in many dialogs. I guess, e.g., in the Box dialog.

Michael

Re: problems with lyx 1.5

[Pavel Sanda]

 ??? Hmmm I don't feel guilty. Where is Look and feel used?

Tools/preferences.

Re: Offering tweaks in the GUI

[Andreas K .]

 [EMAIL PROTECTED] writes:

 Dear LyX developers,
 
   LaTeX often requires little modifications that are hard to find out
 for the beginner.  I am talking about, for example, removing the page
 numbering from the first page or having an empty author (and I mean
 empty, like in lambda or epsilon, not blank, like in
 only spaces).  While those can be resolved with ERT, it would be much
 nicer to offer those options in the Document settings dialogue.
 
   Leslie


I do agree. I have suggested such changes earlier, see 
http://bugzilla.lyx.org/show_bug.cgi?id=2530 

If you write a comment there maybe the developers see that more users are 
interested in these enhancements, and can implement these.

Andreas

Re: [patch] image file cache

[José Matos]

On Saturday 11 November 2006 8:41 pm, Georg Baum wrote:
 As promised I ported the image file cache to 1.5. I use it without problems
 since several weeks, and it works fine.
 I added two lyxrc settings (without GUI yet, you have to write them by
 hand). On windows it is not possible yet to tighten the permissions of the
 cache files, but I understand that the directory we use cannot be read by
 other users, so this is not too important (and btw the situation is the
 same for the temporary folders).

 José, can this go in?

  As discussed before, yes.

 Georg

-- 
José Abílio

CT Status Quo

[Michael Gerz]

Dear Jose,

Nov 13th is getting closer (oops, it's already there) and, to my 
greatest regret, I haven't managed to fix all CT problems.


AFAICS, the following things do not work presently:

- No change bar is given in LaTeX output if (only) the par break has changed
- No visual clue is presente to the user, which indicates the status of 
the imaginary end-of-par character.

- In tables, cut  paste (complete cells) do not support change tracking
- Capitalize, Uppercase, and Lowercase are broken and must be rewritten 
to better support CT
- When accepting or rejecting changes, paragraphs with deleted par 
breaks are not merged in nested text insets
- There may be potential problems with breaking paragraphs (two places 
in the code look suspicious)

- When accepting a change, LyX may hang (same as in 1.4.3)

Jose, I don't know whether you are going to publish LyX 1.5alpha today. 
IMHO, none of the open issues above should stop you from doing so. I am 
pretty confident that CT is already in a better state than it is in 
1.4.3. People, who don't use CT, shouldn't be affected at all. Moreover, 
there is bigger problems (e.g., broken spell checker). Nevertheless, the 
open issues MUST be addressed for the first LyX 1.5beta.


Unfortunately, I won't be able to work on the open issues in the next 
two days. With a little luck, I will continue on Wednesday.


Regards,
Michael

PS: I like the way LyX 1.5 evolves. The LyX developers have become a 
real good team!

Re: Crash in view-something with Extended-Insets.lyx

[Uwe Stöhr]

 I don't have a crash with or without my patch on Windows. But LaTeX
 gives me an error:...

Could you please export the file to LaTeX(pdflatex) and send it to me. I 
can then compare it with the LaTeX-output of LyX 1.4.3.


thanks and regards
Uwe

[PATCH] Optimize drawing (was Re: CT Status Quo)

[Abdelrazak Younes]

Michael Gerz wrote:

Dear Jose,

Nov 13th is getting closer (oops, it's already there) and, to my 
greatest regret, I haven't managed to fix all CT problems.


And I haven't manage to fix some performance problem... But I am very 
close :-)


Attached patch minimizes considerably the number of metrics updates and 
screen redraws. The only problem left is that collapsable insets are not 
correctly open/collapse. Don't try it because this will clear out the 
Coord cache and leads to redraw problems. If this happen, you will need 
a full paragraph rebreak anywhere in order to refresh the cache.


I might not be ready for this alpha but I will for the next.

Abdel.

Index: BufferView.C
===
--- BufferView.C(revision 15890)
+++ BufferView.C(working copy)
@@ -362,15 +362,27 @@
// Update macro store
buffer_-buildMacros();
 
-   // First drawing step
+   // Now do the first drawing step if needed. This consists on updating
+   // the CoordCache in updateMetrics().
+   // The second drawing step is done in WorkArea::redraw() if needed.
+
+   // Case when no explicit update is requested.
+   if (!(flags  (Update::SinglePar | Update::Force))) {
+   if (fitCursor() || multiParSel()) {
+   // a CoordCache update is needed
+   updateMetrics(false);
+   // tell the frontend to update the screen.
+   return true;
+   }
+   // no need to do anything.
+   return false;
+   }
+
+   // We are now in the case (Update::SinglePar | Update::Force)
updateMetrics(flags  Update::SinglePar);
 
-   // The second drawing step is done in WorkArea::redraw() if needed.
-   bool const need_second_step =
-   (flags  (Update::SinglePar | Update::Force | Update::FitCursor 
| Update::MultiParSel))
-(fitCursor() || multiParSel());
-
-   return need_second_step;
+   // Don't forget to do check for fitCursor() and multiParSel().
+   return fitCursor() || multiParSel();
 }
 
 
@@ -1050,7 +1062,7 @@
}
 
// When the above and the inner function are fixed, we can do this:
-   //return needRedraw;
+   return needRedraw;
return true;
 }
 
@@ -1204,7 +1216,7 @@
 void BufferView::updateMetrics(bool singlepar)
 {
// Clear out the position cache in case of full screen redraw.
-   //if (!singlepar)
+   if (!singlepar)
coord_cache_.clear();
 
LyXText  buftext = buffer_-text();
Index: insets/insetcollapsable.C
===
--- insets/insetcollapsable.C   (revision 15890)
+++ insets/insetcollapsable.C   (working copy)
@@ -293,6 +293,10 @@
 
switch (cmd.action) {
case LFUN_MOUSE_PRESS:
+   if (cmd.button() == mouse_button::button1  hitButton(cmd)) {
+   cur.dispatched();
+   break;
+   }
if (status() == Inlined)
InsetText::doDispatch(cur, cmd);
else if (status() == Open  !hitButton(cmd))
@@ -325,6 +329,8 @@
setStatus(cur, Open);
edit(cur, true);
cur.bv().cursor() = cur;
+   cur.dispatched();
+   cur.updateFlags(Update::Force | Update::FitCursor);
break;
 
case Open: {
@@ -332,6 +338,8 @@
//lyxerr  InsetCollapsable::lfunMouseRelease 
2  endl;
setStatus(cur, Collapsed);
cur.bv().cursor() = cur;
+   cur.dispatched();
+   cur.updateFlags(Update::Force | 
Update::FitCursor);
} else {
//lyxerr  InsetCollapsable::lfunMouseRelease 
3  endl;
InsetText::doDispatch(cur, cmd);
Index: text3.C
===
--- text3.C (revision 15890)
+++ text3.C (working copy)
@@ -997,6 +997,11 @@

lyx::dispatch(FuncRequest(LFUN_PRIMARY_SELECTION_PASTE, paragraph));
}
 
+   if (cmd.button() == mouse_button::button1) {
+   needsUpdate = false;
+   cur.noUpdate();
+   }
+
break;
}
 
@@ -1046,8 +1051,14 @@
break;
 
// finish selection
-   if (cmd.button() == mouse_button::button1)
-   theSelection().haveSelection(cur.selection());
+   if (cmd.button() == mouse_button::button1) {
+   if (cur.selection())
+   

Re: revert changeset 15545 and 15546

[Enrico Forestieri]

On Sun, Nov 12, 2006 at 11:14:49PM +0100, Uwe Stöhr wrote:

 I don't like the change made in
 http://www.lyx.org/trac/changeset/15545
 and
 http://www.lyx.org/trac/changeset/15546
 as this destroys the date formatting.
 
 Using
 %A, %d %B %Y
 instead of
 %A, %e %B %Y
 fixes the crash reported in bug 2839
 http://bugzilla.lyx.org/show_bug.cgi?id=2839
 and keeps the date formatting.
 
 Opinions?

What about the attached patch?

-- 
Enrico
Index: src/support/os_unix.C
===
--- src/support/os_unix.C   (revision 15890)
+++ src/support/os_unix.C   (working copy)
@@ -110,6 +110,13 @@ shell_type shell()
 }
 
 
+size_t strftime(char *date, size_t size, string const  fmt,
+   struct tm const * loc_tm)
+{
+   return ::strftime(date, size, fmt.c_str(), loc_tm);
+}
+
+
 char path_separator()
 {
return ':';
Index: src/support/os.h
===
--- src/support/os.h(revision 15890)
+++ src/support/os.h(working copy)
@@ -15,6 +15,7 @@
 #define OS_H
 
 #include string
+#include time.h
 
 
 namespace lyx {
@@ -38,6 +39,9 @@ std::string current_root();
 ///
 shell_type shell();
 
+/// Wrapper for the compiler dependent strftime
+size_t strftime(char *, size_t, std::string const , struct tm const *);
+
 /// Name of the python interpreter
 std::string const python();
 
Index: src/support/os_win32.C
===
--- src/support/os_win32.C  (revision 15890)
+++ src/support/os_win32.C  (working copy)
@@ -302,6 +302,17 @@ shell_type shell()
 }
 
 
+size_t strftime(char *date, size_t size, string const  fmt,
+   struct tm const * loc_tm)
+{
+#ifdef _MSC_VER
+   return ::strftime(date, size, subst(fmt, %e, %#d).c_str(), loc_tm);
+#else
+   return ::strftime(date, size, fmt.c_str(), loc_tm);
+#endif
+}
+
+
 char path_separator()
 {
return ';';
Index: src/support/lyxtime.C
===
--- src/support/lyxtime.C   (revision 15890)
+++ src/support/lyxtime.C   (working copy)
@@ -11,9 +11,11 @@
 #include config.h
 
 #include support/lyxtime.h
+#include support/os.h
 #include lyxrc.h
 
 using std::string;
+using lyx::support::os::strftime;
 
 namespace lyx {
 
@@ -27,7 +29,7 @@ string const formatted_time(time_type t,
 {
struct tm * loc_tm = localtime(t);
char date[50];
-   strftime(date, sizeof(date), fmt.c_str(), loc_tm);
+   strftime(date, sizeof(date), fmt, loc_tm);
return string(date);
 }
 
Index: src/support/os_cygwin.C
===
--- src/support/os_cygwin.C (revision 15890)
+++ src/support/os_cygwin.C (working copy)
@@ -270,6 +270,13 @@ shell_type shell()
 }
 
 
+size_t strftime(char *date, size_t size, string const  fmt,
+   struct tm const * loc_tm)
+{
+   return ::strftime(date, size, fmt.c_str(), loc_tm);
+}
+
+
 char path_separator()
 {
return ':';
Index: src/lyxrc.C
===
--- src/lyxrc.C (revision 15890)
+++ src/lyxrc.C (working copy)
@@ -282,7 +282,7 @@ void LyXRC::setDefaults() {
show_banner = true;
windows_style_tex_paths = false;
tex_allows_spaces = false;
-   date_insert_format = %x;
+   date_insert_format = %A, %e %B %Y;
cursor_follows_scrollbar = false;
dialogs_iconify_with_main = false;
label_init_length = 3;

Re: CT Status Quo

[Martin Vermeer]

On Mon, Nov 13, 2006 at 12:10:07AM +0100, Michael Gerz wrote:
 Dear Jose,
 
 Nov 13th is getting closer (oops, it's already there) and, to my 
 greatest regret, I haven't managed to fix all CT problems.
 
 AFAICS, the following things do not work presently:
 
 - No change bar is given in LaTeX output if (only) the par break has changed
 - No visual clue is presente to the user, which indicates the status of 
 the imaginary end-of-par character.
 - In tables, cut  paste (complete cells) do not support change tracking
 - Capitalize, Uppercase, and Lowercase are broken and must be rewritten 
 to better support CT
 - When accepting or rejecting changes, paragraphs with deleted par 
 breaks are not merged in nested text insets
 - There may be potential problems with breaking paragraphs (two places 
 in the code look suspicious)
 - When accepting a change, LyX may hang (same as in 1.4.3)

Wasn't this fixed in 1.4.3? And does that fix work here too?
 
 Jose, I don't know whether you are going to publish LyX 1.5alpha today. 
 IMHO, none of the open issues above should stop you from doing so. I am 
 pretty confident that CT is already in a better state than it is in 
 1.4.3. People, who don't use CT, shouldn't be affected at all. Moreover, 
 there is bigger problems (e.g., broken spell checker). Nevertheless, the 
 open issues MUST be addressed for the first LyX 1.5beta.
 
 Unfortunately, I won't be able to work on the open issues in the next 
 two days. With a little luck, I will continue on Wednesday.
 
 Regards,
 Michael
 
 PS: I like the way LyX 1.5 evolves. The LyX developers have become a 
 real good team!

+1

- Martin
 

Re: [Cvslog] r15872 - in /lyx-devel/trunk: Status.15x src/frontends/qt...

[Georg Baum]

Am Sonntag, 12. November 2006 10:36 schrieb [EMAIL PROTECTED]:
> Author: baum
> Date: Sun Nov 12 10:36:08 2006
> New Revision: 15872
> 
> URL: http://www.lyx.org/trac/changeset/15872
> Log:
> Fix translation of ambiguous messages
> 
>   * src/frontends/qt4/ui/QPrefConvertersUi.ui: Readd translation hint
>   to label and remove broken tooltip that somebody created instead
> 
>   * src/messages.C
>   (Messages::Pimpl::get): reenable stripping of [[..]] from
>   untranslated messages
> 
> Modified:
> lyx-devel/trunk/Status.15x
> lyx-devel/trunk/src/frontends/qt4/ui/QPrefConvertersUi.ui
> lyx-devel/trunk/src/messages.C


It turned out that somebody converted the translation hint to a tooltip:


> Modified: lyx-devel/trunk/src/frontends/qt4/ui/QPrefConvertersUi.ui
> URL: 
http://www.lyx.org/trac/file/lyx-devel/trunk/src/frontends/qt4/ui/QPrefConvertersUi.ui?rev=15872
> 
==
> --- lyx-devel/trunk/src/frontends/qt4/ui/QPrefConvertersUi.ui (original)
> +++ lyx-devel/trunk/src/frontends/qt4/ui/QPrefConvertersUi.ui Sun Nov 12 
10:36:08 2006
> @@ -146,11 +146,8 @@
>   
>   
>
> -   
> -html>head>meta name="qrichtext" 
content="1" />/head>body style=" white-space: pre-wrap; 
font-family:Sans Serif; font-size:9pt; font-weight:400; font-style:normal; 
text-decoration:none;">p style=" margin-top:0px; margin-bottom:0px; 
margin-left:0px; margin-right:0px; -qt-block-indent:0; 
text-indent:0px;">[[as in 'From format x to format 
y']]/p>/body>/html>
> -   
> -   
> -To:
> +   
> +To:[[as in 'From format x to format y']]
> 
> 
>  converterToCO
> 


Because of the recent translation remerge the translations for this tstring 
are lost. This is a reminder that a suffix [[]] of a message is a 
translation hint for ambigous messages. It gets stripped if no translation 
is provided, and it should not be removed!


Georg

'Private Mail' for Joost.

[Andre Poenitz]

Joost, your SF account seems to be overly sensitive when it comes to
identification of spam:

- Forwarded message from Mail Delivery System <[EMAIL PROTECTED]> -

Date: Sat, 11 Nov 2006 10:16:17 +0100
From: Mail Delivery System <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Mail-Fehler - Mail delivery failed: returning message to sender

Diese Mail wurde automatisch erzeugt vom Mail-Transportsystem auf
   lana.hrz.tu-chemnitz.de, Mail-Relay der TU Chemnitz, Deutschland
-- This message was created automatically by mail delivery software at
lana.hrz.tu-chemnitz.de, e-mail relay at Chemnitz University, Germany
<[EMAIL PROTECTED]>

Eine E-Mail mit der Absenderadresse <[EMAIL PROTECTED]>
gesendet vom Rechner dialin-212-144-009-148.pools.arcor-ip.net [212.144.9.148]
konnte an folgende Empfaenger NICHT ZUGESTELLT werden:

-- A message with sender address <[EMAIL PROTECTED]>
-- sent by host dialin-212-144-009-148.pools.arcor-ip.net [212.144.9.148]
-- could NOT BE DELIVERED to the following address(es):

  [EMAIL PROTECTED]
SMTP error from remote mail server after end of data:
host mail.sourceforge.net [66.35.250.206]: 550-SPAM:
This message appears to be spam (5.5 points).
550--
550-If you believe this message was classified as spam in error,
550-please open a Support Request at the URL below.
550-(Please include this message in any Support Request).
550--
550--
550-Spam Filtering performed by sourceforge.net.
550-See http://spamassassin.org/tag/ for more details.
550-Report problems to 
http://sf.net/tracker/?func=add_id=1=21
550-1.0 FORGED_RCVD_HELO   Received: contains a forged HELO
550 4.5 DATE_IN_PAST_48_96 Date: is 48 to 96 hours before Received:
date

 Es folgt eine Kopie der E-Mail mit allen Header-Zeilen: 
--   This is a copy of the message, including all the headers: --

Return-path: <[EMAIL PROTECTED]>
Received: from dialin-212-144-009-148.pools.arcor-ip.net ([212.144.9.148] 
helo=millo.mpi.htwm.de)
by lana.hrz.tu-chemnitz.de with esmtpa (Exim 4.60)
(envelope-from <[EMAIL PROTECTED]>)
id 1Gioy5-0002Pf-GF; Sat, 11 Nov 2006 10:16:06 +0100
Received: by millo.mpi.htwm.de (Postfix, from userid 500)
id EB0D27EC91; Wed,  8 Nov 2006 23:25:39 +0100 (CET)
Date: Wed, 8 Nov 2006 23:25:39 +0100
From: Andre Poenitz <[EMAIL PROTECTED]>
To: Joost Verburg <[EMAIL PROTECTED]>
Cc: Lars Gullik =?iso-8859-1?Q?Bj=F8nnes?= <[EMAIL PROTECTED]>,
LyX Developers List 
Subject: Re: About New TabBar and Multiple-Windows
Message-ID: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL 
PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL 
PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <[EMAIL PROTECTED]>
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.9 (/)
X-Spam-Report: --- Start der SpamAssassin 3.1.6 Textanalyse (-0.9 Punkte)
Fragen an/questions to:  Postmaster TU Chemnitz <[EMAIL PROTECTED]>
0.5 DATE_IN_PAST_48_96 Absendezeit 48 bis 96 Stunden vor Datum in
"Received"-Kopfzeilen
-1.4 ALL_TRUSTEDNachricht wurde nur ueber 
vertrauenswuerdige Rechner
weitergeleitet
--- Ende der SpamAssassin Textanalyse
X-Scan-Signature: e90a451e269f6704296cddf3d75231cf

On Wed, Nov 01, 2006 at 08:09:08PM +0100, Joost Verburg wrote:
> Lars Gullik Bj=F8nnes wrote:
> >sure it does. I do this all the time with emacs and firefox.
>=20
> Firefox has only a single process for all windows.
>=20
> In LyX you can have right now:
>=20
> 1) Multiple LyX instances (different processes)
> 2) Multiple windows per instance
> 3) Multiple documents per window
>=20
> 2) and 3) share the same data, but 1) does not. Do you really expect th=
e=20
> users to know which windows belong to which instance?
>=20
> It should not be possible to have the same document in, say, 3 windows,=
=20
> where window 1 and 2 share the data but window 3 does not.

And a solution for that would be to have one window per instance.

Andre'



- End forwarded message -

-- 

Re: Let us remove the multi-window support !

[Andre Poenitz]

On Tue, Nov 07, 2006 at 08:00:18PM +0100, Joost Verburg wrote:
> José Matos wrote:
> >>Instead of hard-coding this like on Mac OS X right now, the Windows /
> >>Mac installers can set a default in lyxrc.dist and users will always be
> >>able to change it.
> >
> >  There are two separate issues as we have discussed before. I don't have 
> >  any problem with your proposal above.
> 
> OK. I'm only talking about the situation when a user clicks the LyX icon 
> on the desktop or start menu. If LyX is already running, normal behavior 
> for a Windows application is to open a new window in the current process.

I pretty mch doubt this can be considered 'normal behaviour'. MS
Visual Studio starts another process. Windows Explorer can be configured
to use separate processes. The command prompt starts another process.

Andre' 

Re: cutandpaste.C simplifications

[Andre Poenitz]

On Tue, Nov 07, 2006 at 09:06:14AM +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
> 
> Martin> On Mon, Nov 06, 2006 at 11:03:55PM +0100, Michael Gerz wrote:
> >> Hi,
> >> 
> >> am I too stupid to see the brilliancy of the code or can
> >> cutandpaste.C be simplified?
> 
> Martin> Probably both ;-)
>  
> Yes, I suspect that someone wanted to play with all the new toys he
> read about in a C++ book.

OTOH, the 'push_back()' of the empty par and filling it in-place as
opposed to filling it outside and append it later might be intentional
as this effectively saves a deep copy.

Andre'

Re: Question about wide inset...

[Andre Poenitz]

On Tue, Nov 07, 2006 at 05:47:25PM +0100, Lars Gullik Bjønnes wrote:
> I think you should also change setWide to wide...
> 
> void wide(bool wide_inset) { wide_inset_ = wide_inset; }
> 
> either both setX and getX, or just X and X (I like this last one
> best.)

X and X is pretty confusing as one can never be certain whether
'foo(x)' is a setter for x or a const function taking an additional
argument.

x-xgetX-setX setX-x

aethetics00-
line noise   +-0
clarity  -++

sum: 000

So all depends on the relative weight you put on the categories.

I actually like the setX/x combo as most function calls are usually
getters, so this is low noise overhead.

Andre'

Re: Single-instance support on Windows

[Andre Poenitz]

On Sat, Nov 11, 2006 at 12:45:31AM +0100, Jean-Marc Lasgouttes wrote:
> Joost> should be sent to all open windows using EnumWindows. In
> Joost> GuiApplication.C, a WinEventHandler function can capture this
> Joost> message and send a return value, so the calling process knows
> Joost> that LyX is found.
> 
> Why is he mutex useful?

Races.

It would be the right thing to use if a single instance were wanted.
That, however, I dispute.

Andre'

Re: Can LyX handle large files ?

[Andre Poenitz]

On Tue, Nov 07, 2006 at 11:14:03PM +0100, Abdelrazak Younes wrote:
> Asger Ottar Alstrup wrote:
> >Asger Ottar Alstrup wrote:
> >>Try running LyX with a command line parameter "-dbg any" and inspect 
> >>the output when redrawing. If lots of stuff is coming out, review that 
> >>output to make sure it is not done like the above.
> >
> >Most of it was done wrong - some of it even using monsters like 
> >BOOST_CURRENT_FUNCTION. Who knows what voodoo that shit does?
> >
> >I've changed it. Please test. There is a fair chance this gives a nice 
> >speedup, maybe even on MacOS as well.
> 
> That would be an easy way out but I am not convinced... Visually 
> speaking, all these if are not very nice...

That's why we shoul use macros there:

Instead of

  lyxerr[Debug::PAINTING] << "draw " << std::string(str.toUtf8())
<< " at " << x << "," << y << std::endl;

which is slow, or

if (whatever(Debug::PAINTING)) {
lyxerr[Debug::PAINTING] << "draw " << std::string(str.toUtf8())
<< " at " << x << "," << y << 
std::endl;
}

which is (significantly) faster but too noisy to be useful on a big
scale


  LYXERR("draw " << std::string(str.toUtf8()) << " at " << x << "," << y);

should be used. This is as fast a the second version and even more
compact than the first.

Andre'

Re: citation dialog

[Andre Poenitz]

On Fri, Nov 10, 2006 at 10:15:56PM +0100, Alfredo Braunstein wrote:
> Hehe I'd love to come back... I hope to find some time soon (more than the
> one needed to occasionally lurk on the list at least!)
> 
> Btw, it seems that you guys are doing a wonderful job with 1.5!

Looks like you haven't even compiled 1.5.x so far...

Andre'

Re: Can LyX handle large files ?

[Andre Poenitz]

On Tue, Nov 07, 2006 at 04:43:07PM +0100, Abdelrazak Younes wrote:
> As my painting investigation continue, it seems that this problem has 
> _nothing_ to do with painting on screen at all. Modifying a text line 
> between two huge formula exhibits the slow behaviour even if only the 
> text line is repainted on screen (you can use "-dbg painting" to make 
> sure of that.

As I said. Mathed is essentially uchanged since 1.2.0. It was completely
different before, but speed was acceptable in the 1.2.x and 1.3.x
series. So whatever triggers that behaviour is some recent interaction.

Note that I am not saying the data model is perfect, especially since
I changed my stance about reference counting and deep copies vs COW
lately.

> I guess this could be related to the data memory models used in mathed. 
> Maybe some big tables created/deleted on the fly?

Hm... the macro tables?

> Also, this comment from Michael Wojcik* makes me wonder if maybe mathed 
> does something special with lyxerr... any clue someone?

We should have a macro encapsulating lyxerr that guarantees minimal
overhead...

> "So, for example, if LyX were running with debug enabled, the debug
> lines being written to the LyX console window might cause a noticeable
> jump in csrss load.  But I haven't tested that."

[Console output is terribly slow on Windows btw.]

Andre'

Re: Can LyX handle large files ?

[Andre Poenitz]

On Tue, Nov 07, 2006 at 12:14:46PM +0100, Abdelrazak Younes wrote:
> I've tested again this document and the good news is that the 
> performance will soon be a bit better in 1.5 with my forthcoming 
> painting performance patch. But the problem I think Georg is right in 
> that the problem lies in how lines and symbols are painted on screen 
> with mathed.

While this might be true, it is also a fact that math painting has not
significantly changed since 1.2.0, in fact, this was the first component
using two-phase-drawing. So it is a bit strange that nowadays it shuld
be suddenly the bottleneck.

Andre' 

Re: cutandpaste.C simplifications

[Andre Poenitz]

On Tue, Nov 07, 2006 at 05:49:31PM +0100, Lars Gullik Bjønnes wrote:
> Michael Gerz <[EMAIL PROTECTED]> writes:
> 
> | Hi,
> | 
> | am I too stupid to see the brilliancy of the code
> 
> yes.
> (oh where did the friday go...)
> 
> It is in the vein of "prefere algorithms to manual constructs"

... even if it hurts terribly.

Andre'

Re: [Cvslog] r15872 - in /lyx-devel/trunk: Status.15x src/frontends/qt...

[Edwin Leuven]

Georg Baum wrote:

Am Sonntag, 12. November 2006 10:36 schrieb [EMAIL PROTECTED]:
It turned out that somebody converted the translation hint to a tooltip:


oops, that was me i think

Because of the recent translation remerge the translations for this tstring 
are lost. This is a reminder that a suffix [[]] of a message is a 
translation hint for ambigous messages. It gets stripped if no translation 
is provided, and it should not be removed!


didn't know that, i thought it was part to the label since it doesn't 
get stripped in my native english lyx version (1.4.3)

Re: [Cvslog] r15872 - in /lyx-devel/trunk: Status.15x src/frontends/qt...

[Michael Gerz]

Georg Baum wrote:

Because of the recent translation remerge the translations for this tstring 
are lost. This is a reminder that a suffix [[]] of a message is a 
translation hint for ambigous messages. It gets stripped if no translation 
is provided, and it should not be removed!
 


FYI: I will remerge the po files soon due to minimal changes in stdmenus.ui.

Georg, are you going to commit new stuff soon? In that case, I will wait.

Michael

Re: Can LyX handle large files ?

[Abdelrazak Younes]

Andre Poenitz wrote:

On Tue, Nov 07, 2006 at 12:14:46PM +0100, Abdelrazak Younes wrote:
I've tested again this document and the good news is that the 
performance will soon be a bit better in 1.5 with my forthcoming 
painting performance patch. But the problem I think Georg is right in 
that the problem lies in how lines and symbols are painted on screen 
with mathed.


While this might be true, it is also a fact that math painting has not
significantly changed since 1.2.0, in fact, this was the first component
using two-phase-drawing. So it is a bit strange that nowadays it shuld
be suddenly the bottleneck.


I didn't say that mathed is the culprit here. I am just saying that the 
problem is triggered by mathed which uses a lot of insets apparently. I 
don't really know if the problem lies in the InsetIterators or the 
ParIterator or something else but I am pretty sure this has nothing to 
do with drawing anyway.


Abdel.

PS: I removed lyx-general for the recipients.

Re: [Cvslog] r15872 - in /lyx-devel/trunk: Status.15x src/frontends/qt...

[Georg Baum]

Am Sonntag, 12. November 2006 11:17 schrieb Michael Gerz:
> Georg, are you going to commit new stuff soon? In that case, I will wait.

I might do some further unciode stuff, but that does not change the 
messages.


Georg

Re: [Cvslog] r15872 - in /lyx-devel/trunk: Status.15x src/frontends/qt...

[Georg Baum]

Am Sonntag, 12. November 2006 11:16 schrieb Edwin Leuven:

> didn't know that, i thought it was part to the label since it doesn't 
> get stripped in my native english lyx version (1.4.3)

That is a bug then. Are you using the dummy Messages class? If yes you 
might need to implement the stripping in that class, too.


Georg

Re: Can LyX handle large files ?

[Abdelrazak Younes]

Andre Poenitz wrote:

On Tue, Nov 07, 2006 at 04:43:07PM +0100, Abdelrazak Younes wrote:
As my painting investigation continue, it seems that this problem has 
_nothing_ to do with painting on screen at all. Modifying a text line 
between two huge formula exhibits the slow behaviour even if only the 
text line is repainted on screen (you can use "-dbg painting" to make 
sure of that.


As I said. Mathed is essentially uchanged since 1.2.0. It was completely
different before, but speed was acceptable in the 1.2.x and 1.3.x
series. So whatever triggers that behaviour is some recent interaction.


Indeed, the problem only appears with 1.4.



Note that I am not saying the data model is perfect, especially since
I changed my stance about reference counting and deep copies vs COW
lately.

I guess this could be related to the data memory models used in mathed. 
Maybe some big tables created/deleted on the fly?


Hm... the macro tables?


I've tried to disable buildMacro() but that didn't help much.


Also, this comment from Michael Wojcik* makes me wonder if maybe mathed 
does something special with lyxerr... any clue someone?


We should have a macro encapsulating lyxerr that guarantees minimal
overhead...


Agreed. And I agree also with your macro proposal.




"So, for example, if LyX were running with debug enabled, the debug
lines being written to the LyX console window might cause a noticeable
jump in csrss load.  But I haven't tested that."


[Console output is terribly slow on Windows btw.]


And maybe that is the main problem. IIRC correctly LyX is compiled as a 
console application; maybe, _maybe_, the problem with csrss.exe will 
disappear if we change that.


Abdel.

Classis.ui - Obsolete?

[Michael Gerz]

Hello,

are we going to maintain classic.ui for LyX 1.5.0?

I guess it is neither "feature complete" nor does it reflect the latest 
bookmark changes. There may also be some problems with shortcuts.


I am tempted to remove it from the repository. What do you think?

Michael

Re: [Cvslog] r15872 - in /lyx-devel/trunk: Status.15x src/frontends/qt...

[Edwin Leuven]

Georg Baum wrote:
That is a bug then. Are you using the dummy Messages class? If yes you 
might need to implement the stripping in that class, too.


i don't know anything about this stuff. the windows installer this is...

Re: Can LyX handle large files ?

[christian . ridderstrom]

On Sat, 11 Nov 2006, Andre Poenitz wrote:


>   LYXERR("draw " << std::string(str.toUtf8()) << " at " << x << "," << y);
> 
> should be used. This is as fast a the second version and even more
> compact than the first.

Peter sent a patch to the list just three days ago that used the above 
approach. He didn't report any significant gains with though.

http://article.gmane.org/gmane.editors.lyx.devel/72138

Maybe it should go in regardless?

/Christian

-- 
Christian Ridderström, +46-8-768 39 44   http://www.md.kth.se/~chr

Re: r15876 - /lyx-devel/trunk/src/bufferview_funcs.C

[Abdelrazak Younes]

[EMAIL PROTECTED] wrote:

Author: younes
Date: Sun Nov 12 12:03:55 2006
New Revision: 15876

URL: http://www.lyx.org/trac/changeset/15876
Log:
- coordOffset(): add an assertion on par.rows() emptiness before accessing it 
and a FIXME.


Opinion?



Modified:
lyx-devel/trunk/src/bufferview_funcs.C

Modified: lyx-devel/trunk/src/bufferview_funcs.C
URL: 
http://www.lyx.org/trac/file/lyx-devel/trunk/src/bufferview_funcs.C?rev=15876
==
--- lyx-devel/trunk/src/bufferview_funcs.C (original)
+++ lyx-devel/trunk/src/bufferview_funcs.C Sun Nov 12 12:03:55 2006
@@ -177,6 +177,8 @@
// Add contribution of initial rows of outermost paragraph
CursorSlice const & sl = dit[0];
Paragraph const & par = sl.text()->getPar(sl.pit());
+   // FIXME: I wonder if a case exists where this could happen:
+   BOOST_ASSERT(!par.rows().empty());
y -= par.rows()[0].ascent();
 #if 1
size_t rend;

Re: [Cvslog] r15872 - in /lyx-devel/trunk: Status.15x src/frontends/qt...

[Georg Baum]

Am Sonntag, 12. November 2006 11:37 schrieb Edwin Leuven:
> Georg Baum wrote:
> > That is a bug then. Are you using the dummy Messages class? If yes you 
> > might need to implement the stripping in that class, too.
> 
> i don't know anything about this stuff. the windows installer this is...

OK, I changed the dummy variant in trunk. This should probably be done in 
1.4, too. I am surprised that the windows installer does not use the 
translations.


Georg

Re: r15867 - /lyx-devel/trunk/Status.15x

[Juergen Spitzmueller]

[EMAIL PROTECTED] wrote:
> +* broken signal/slot connection:
> +  Object::connect: No such signal
> LengthCombo::selectionChanged(LyXLength::UNIT) +  Object::connect:  (sender
> name:   'unitCO')
> +  Object::connect:  (receiver name: 'QVSpaceUi')

The attached patch fixes that. I'll commit soon.

Jürgen

BTW seems that deleting any kind of inset crashes LyX currently.
Index: src/frontends/qt4/QExternalDialog.C
===
--- src/frontends/qt4/QExternalDialog.C	(Revision 15873)
+++ src/frontends/qt4/QExternalDialog.C	(Arbeitskopie)
@@ -65,7 +65,7 @@ QExternalDialog::QExternalDialog(QExtern
 	connect( extraED, SIGNAL( textChanged(const QString&) ), this, SLOT( extraChanged(const QString&) ) );
 	connect( extraFormatCO, SIGNAL( activated(const QString&) ), this, SLOT( formatChanged(const QString&) ) );
 	connect( widthUnitCO, SIGNAL( activated(int) ), this, SLOT( widthUnitChanged() ) );
-	connect( heightUnitCO, SIGNAL( selectionChanged(LyXLength::UNIT) ), this, SLOT( change_adaptor() ) );
+	connect( heightUnitCO, SIGNAL( selectionChanged(lyx::LyXLength::UNIT) ), this, SLOT( change_adaptor() ) );
 	connect( displayCB, SIGNAL( stateChanged(int) ), this, SLOT( change_adaptor() ) );
 	connect( displayscaleED, SIGNAL( textChanged(const QString&) ), this, SLOT( change_adaptor() ) );
 	connect( angleED, SIGNAL( textChanged(const QString&) ), this, SLOT( change_adaptor() ) );
Index: src/frontends/qt4/QVSpaceDialog.C
===
--- src/frontends/qt4/QVSpaceDialog.C	(Revision 15873)
+++ src/frontends/qt4/QVSpaceDialog.C	(Arbeitskopie)
@@ -46,7 +46,7 @@ QVSpaceDialog::QVSpaceDialog(QVSpace * f
 connect( valueLE, SIGNAL( textChanged(const QString&) ), this, SLOT( change_adaptor() ) );
 connect( spacingCO, SIGNAL( activated(int) ), this, SLOT( enableCustom(int) ) );
 connect( keepCB, SIGNAL( clicked() ), this, SLOT( change_adaptor() ) );
-connect( unitCO, SIGNAL( selectionChanged(LyXLength::UNIT) ), this, SLOT( change_adaptor() ) );
+connect( unitCO, SIGNAL( selectionChanged(lyx::LyXLength::UNIT) ), this, SLOT( change_adaptor() ) );
 
 	valueLE->setValidator(unsignedLengthValidator(valueLE));
 }
Index: src/frontends/qt4/QBoxDialog.C
===
--- src/frontends/qt4/QBoxDialog.C	(Revision 15873)
+++ src/frontends/qt4/QBoxDialog.C	(Arbeitskopie)
@@ -39,10 +39,10 @@ QBoxDialog::QBoxDialog(QBox * form)
 		form, SLOT(slotClose()));
 
 connect( widthED, SIGNAL( textChanged(const QString&) ), this, SLOT( change_adaptor() ) );
-connect( widthUnitsLC, SIGNAL( selectionChanged(LyXLength::UNIT) ), this, SLOT( change_adaptor() ) );
+connect( widthUnitsLC, SIGNAL( selectionChanged(lyx::LyXLength::UNIT) ), this, SLOT( change_adaptor() ) );
 connect( valignCO, SIGNAL( highlighted(const QString&) ), this, SLOT( change_adaptor() ) );
 connect( heightED, SIGNAL( textChanged(const QString&) ), this, SLOT( change_adaptor() ) );
-connect( heightUnitsLC, SIGNAL( selectionChanged(LyXLength::UNIT) ), this, SLOT( change_adaptor() ) );
+connect( heightUnitsLC, SIGNAL( selectionChanged(lyx::LyXLength::UNIT) ), this, SLOT( change_adaptor() ) );
 connect( restorePB, SIGNAL( clicked() ), this, SLOT( restoreClicked() ) );
 connect( typeCO, SIGNAL( activated(int) ), this, SLOT( change_adaptor() ) );
 connect( typeCO, SIGNAL( activated(int) ), this, SLOT( typeChanged(int) ) );

Re: r15867 - /lyx-devel/trunk/Status.15x

[Abdelrazak Younes]

Juergen Spitzmueller wrote:

[EMAIL PROTECTED] wrote:

+* broken signal/slot connection:
+  Object::connect: No such signal
LengthCombo::selectionChanged(LyXLength::UNIT) +  Object::connect:  (sender
name:   'unitCO')
+  Object::connect:  (receiver name: 'QVSpaceUi')


The attached patch fixes that. I'll commit soon.

Jürgen

BTW seems that deleting any kind of inset crashes LyX currently.


Oups, might be my fault... I'll see to it.

Abdel.

Re: r15876 - /lyx-devel/trunk/src/bufferview_funcs.C

[Kornel Benko]

Am Sonntag, 12. November 2006 12:05 schrieb Abdelrazak Younes:
> [EMAIL PROTECTED] wrote:
> > Author: younes
> > Date: Sun Nov 12 12:03:55 2006
> > New Revision: 15876
> >
> > URL: http://www.lyx.org/trac/changeset/15876
> > Log:
> > - coordOffset(): add an assertion on par.rows() emptiness before
> > accessing it and a FIXME.
>
> Opinion?
>
> > Modified:
> > lyx-devel/trunk/src/bufferview_funcs.C
> >
> > Modified: lyx-devel/trunk/src/bufferview_funcs.C
> > URL:
> > http://www.lyx.org/trac/file/lyx-devel/trunk/src/bufferview_funcs.C?rev=1
> >5876
> > =
> >= --- lyx-devel/trunk/src/bufferview_funcs.C (original)
> > +++ lyx-devel/trunk/src/bufferview_funcs.C Sun Nov 12 12:03:55 2006
> > @@ -177,6 +177,8 @@
> > // Add contribution of initial rows of outermost paragraph
> > CursorSlice const & sl = dit[0];
> > Paragraph const & par = sl.text()->getPar(sl.pit());
> > +   // FIXME: I wonder if a case exists where this could happen:
> > +   BOOST_ASSERT(!par.rows().empty());
> > y -= par.rows()[0].ascent();
> >  #if 1
> > size_t rend;

Very easy to reproduce this here:

Program received signal SIGABRT, Aborted.
[Switching to Thread 1087020320 (LWP 22933)]
0xe410 in ?? ()
(gdb) bt
#0  0xe410 in ?? ()
#1  0xbfffdd88 in ?? ()
#2  0x0006 in ?? ()
#3  0x5995 in ?? ()
#4  0x40bb9d41 in raise () from /lib/tls/libc.so.6
#5  0x40bbb529 in abort () from /lib/tls/libc.so.6
#6  0x084f3e6b in lyx::support::abort ()
#7  0x080d090e in boost::assertion_failed ()
#8  0x08115805 in lyx::bv_funcs::coordOffset ()
#9  0x08115ae8 in lyx::bv_funcs::getPos ()
#10 0x0812d53e in lyx::LCursor::getPos ()
#11 0x083478bf in lyx::frontend::WorkArea::showCursor ()
#12 0x0834798b in lyx::frontend::WorkArea::toggleCursor ()
...

1 Start lyx
2 open a File which is at say 3 screen pages sized.
3 go to page 2
4 select new window
5 move pointer into the newly created window (here the new window has 
different size, because of the previous session)
6 move pointer back to the first window
==> crash

Kornel
-- 
Kornel Benko
[EMAIL PROTECTED]


pgpx1atlUAUQB.pgp
Description: PGP signature

Re: citation dialog

[Alfredo Braunstein]

Andre Poenitz wrote:

> On Fri, Nov 10, 2006 at 10:15:56PM +0100, Alfredo Braunstein wrote:
>> Hehe I'd love to come back... I hope to find some time soon (more than
>> the one needed to occasionally lurk on the list at least!)
>> 
>> Btw, it seems that you guys are doing a wonderful job with 1.5!
> 
> Looks like you haven't even compiled 1.5.x so far...

Why? I did.

A/

German Translations

[Michael Gerz]

Hello, German users,

I have just committed some updates to de.po. The German localization 
should be more or less useable now. There are still about 150 messages 
to be translated but the most important ones (menu entries) are done. 
(It took quite some time to get all the shortcuts right.)


I will continue work on de.po by the end of the week,

Regards,
Michael

Re: citation dialog

[Alfredo Braunstein]

Alfredo Braunstein wrote:

> Andre Poenitz wrote:
> 
>> On Fri, Nov 10, 2006 at 10:15:56PM +0100, Alfredo Braunstein wrote:
>>> Hehe I'd love to come back... I hope to find some time soon (more than
>>> the one needed to occasionally lurk on the list at least!)
>>> 
>>> Btw, it seems that you guys are doing a wonderful job with 1.5!
>> 
>> Looks like you haven't even compiled 1.5.x so far...
> 
> Why? I did.
> 
> A/

Btw, hello ;-)

A/

Re: r15876 - /lyx-devel/trunk/src/bufferview_funcs.C

[Kornel Benko]

Am Sonntag, 12. November 2006 12:59 schrieb Kornel Benko:
> 1 Start lyx
> 2 open a File which is at say 3 screen pages sized.
> 3 go to page 2
> 4 select new window
> 5 move pointer into the newly created window (here the new window has
> different size, because of the previous session)
> 6 move pointer back to the first window
> ==> crash

No crash in revision 15881.
This was very fast.
Kornel
-- 
Kornel Benko
[EMAIL PROTECTED]


pgp924G5A1k06.pgp
Description: PGP signature

Re: r15867 - /lyx-devel/trunk/Status.15x

[Abdelrazak Younes]

Abdelrazak Younes wrote:

Juergen Spitzmueller wrote:

[EMAIL PROTECTED] wrote:

+* broken signal/slot connection:
+  Object::connect: No such signal
LengthCombo::selectionChanged(LyXLength::UNIT) +  Object::connect:  
(sender

name:   'unitCO')
+  Object::connect:  (receiver name: 'QVSpaceUi')


The attached patch fixes that. I'll commit soon.

Jürgen

BTW seems that deleting any kind of inset crashes LyX currently.


Oups, might be my fault... I'll see to it.


This is fixed now. FYI, I removed earlier the paragraph breaks redoing 
from setCursor(). I did that in order to optimise mouse navigation. I 
will review all setCursor() calls now.


Sorry for the disturbance,
Abdel.

Re: r15867 - /lyx-devel/trunk/Status.15x

[Abdelrazak Younes]

Abdelrazak Younes wrote:

Abdelrazak Younes wrote:

Juergen Spitzmueller wrote:

[EMAIL PROTECTED] wrote:

+* broken signal/slot connection:
+  Object::connect: No such signal
LengthCombo::selectionChanged(LyXLength::UNIT) +  Object::connect:  
(sender

name:   'unitCO')
+  Object::connect:  (receiver name: 'QVSpaceUi')


The attached patch fixes that. I'll commit soon.

Jürgen

BTW seems that deleting any kind of inset crashes LyX currently.


Oups, might be my fault... I'll see to it.


This is fixed now. FYI, I removed earlier the paragraph breaks redoing 
from setCursor(). I did that in order to optimise mouse navigation. I 
will review all setCursor() calls now.


I think I've solved all important issues due to my setCursor() change. I 
am (only now!) starting to get a good grasp of how things are working. 
IMO, it is no wonder that 1.4 is very slow compared to 1.3. We repeat a 
lot of operations unnecessarily. I believe that a true model/view 
separation in 1.6 will bring a huge performance improvement.


I am on the way to do some more optimisations nevertheless...

Abdel.

Re: [patch] Allow unicode labels in layout files

[Martin Vermeer]

On Sat, Nov 11, 2006 at 12:50:59PM +0100, Georg Baum wrote:
> Am Freitag, 10. November 2006 11:22 schrieb Georg Baum:
> > Jean-Marc Lasgouttes wrote:
> > 
> > >> "Georg" == Georg Baum
> > >> <[EMAIL PROTECTED]>
> > >> writes:
> > > 
> > > Georg> BTW, why is layout->labelstring() sometimes used untranslated?
> > > 
> > > Where?
> > 
> > When setting the setLabelWidthString of ParagraphParameters. This updated
> > patch does also translate these cases. Is this OK, or is there some 
> special
> > reason for not translating these cases?

I may be talking out of the back of my head, but isn't the label width
string only meant to specify the width of the label graphically, i.e.,
the label's contents don't matter but *should not change* from under the
user?

- Martin

windows bug fixing

[Georg Baum]

Am Sonntag, 12. November 2006 18:08 schrieb [EMAIL PROTECTED]:
> > Do you say that 1.4.3-4 and 1.4.3-5 use a different code base?
> 
> Yes I think so. It still bases on the version 1.4.3 source code but Joost 
has
> built in some new things to fix bug 2918, bug 2923, bug 2936. He also 
moved the
> debug output to a new application that informs the user about the debug 
output
> when LyX crashes.

Why are these fixes not in 1.4.4svn? Or if they are, why are they not 
mentioned in status.14x?

Why is this called 1.4.3-5 and not 1.4.3-winfixes5 or something like that? 
That creates confusion.


Georg

Re: [patch] Allow unicode labels in layout files

[Georg Baum]

Am Sonntag, 12. November 2006 19:03 schrieb Martin Vermeer:
> I may be talking out of the back of my head, but isn't the label width
> string only meant to specify the width of the label graphically, i.e.,
> the label's contents don't matter but *should not change* from under the
> user?

Yes. This is normally set by the user, only in the case when it is empty it 
is preset by LyX with the label string. If that makes sense at all then 
only with translation IMHO.


Georg

Re: 3 important bugs right now - more testing needed!

[Georg Baum]

Am Donnerstag, 9. November 2006 14:53 schrieb Jean-Marc Lasgouttes:
> > "Jean-Pierre" == Jean-Pierre Chrétien <[EMAIL PROTECTED]> writes:
> 
> Jean-Pierre> Could the diacritics problem come from the list of
> Jean-Pierre> locales not including utf8 ?
> 
> What is the diacritics problem? That we cannot check accented
> characters? We should find a way to read unicode table and decide what
> is the class of the different characters (to replace the code in
> support/textutils.h). I think this is a prerequisite for 1.5.

I agree.

> Is this
>  http://crl.nmsu.edu/~mleisher/ucdata.html
> something we could use?

Maybe.

> Or do we have a way to coerce the c library to 
>  give us the information we need without switching locales?

The C library is only helpful if wchar_t is 4 byte wide. Otherwise it has 
no useful information about UCS4 strings.

> I see here that boost.Regex is able to use character properties:
> http://www.boost.org/libs/regex/doc/character_class_names.html
> 
> Does that mean that we should also be able to access them with our
> current code?

No. They use the wchar_t stuff from the C library for wide strings 
internally. If that is usable (e.g. on linux) we can as well use it 
directly.

The attached patch does that. I am very tempted to apply it and have the 
windows people look for a solution for their platform. If such a solution 
is found we can still decide whether we use it always or only on windows.

Unless somebody has very good reasons to not use the C library support for 
wchar_t when it is usable I am going to put this in.

The proper C++ way would be to implement a full UCS4 ctype facet and use 
that instead of the stuff in textutils.h and lstrings.h, but I don't feel 
like doing this now.


Georg
Index: src/buffer.C
===
--- src/buffer.C	(Revision 15887)
+++ src/buffer.C	(Arbeitskopie)
@@ -554,11 +554,9 @@ void Buffer::insertStringAsLines(Paragra
 }
 space_inserted = true;
 			}
-/* FIXME: not needed anymore?
 		} else if (!isPrintable(*cit)) {
 			// Ignore unprintables
 			continue;
-*/
 		} else {
 			// just insert the character
 			par.insertChar(pos, *cit, font, params().trackChanges);
Index: src/support/lstrings.C
===
--- src/support/lstrings.C	(Revision 15887)
+++ src/support/lstrings.C	(Arbeitskopie)
@@ -32,6 +32,16 @@
 #include 
 #include 
 
+#if defined(HAVE_WCHAR_T) && SIZEOF_WCHAR_T == 4
+// All implementations that have a 4byte wchar_t use UCS4 as encoding, so we
+// can simply use the wchar_t C library functions
+#include 
+#else
+// Steal some code from somewhere else, e.g. glib (look at gunicode.h)
+// The code that we currently use does not really work.
+#endif
+
+
 using lyx::docstring;
 
 using std::transform;
@@ -76,8 +86,8 @@ int compare_no_case(docstring const & s,
 	docstring::const_iterator p2 = s2.begin();
 
 	while (p != s.end() && p2 != s2.end()) {
-		int const lc1 = tolower(*p);
-		int const lc2 = tolower(*p2);
+		char_type const lc1 = lowercase(*p);
+		char_type const lc2 = lowercase(*p2);
 		if (lc1 != lc2)
 			return (lc1 < lc2) ? -1 : 1;
 		++p;
@@ -94,7 +104,7 @@ int compare_no_case(docstring const & s,
 
 namespace {
 
-int ascii_tolower(int c) {
+char_type ascii_tolower(char_type c) {
 	if (c >= 'A' && c <= 'Z')
 		return c - 'A' + 'a';
 	return c;
@@ -108,8 +118,8 @@ int do_compare_ascii_no_case(String cons
 	typename String::const_iterator p2 = s2.begin();
 
 	while (p != s.end() && p2 != s2.end()) {
-		int const lc1 = ascii_tolower(*p);
-		int const lc2 = ascii_tolower(*p2);
+		char_type const lc1 = ascii_tolower(*p);
+		char_type const lc2 = ascii_tolower(*p2);
 		if (lc1 != lc2)
 			return (lc1 < lc2) ? -1 : 1;
 		++p;
@@ -300,7 +310,9 @@ char uppercase(char c)
 	return char(toupper(c));
 }
 
-// FIXME for lowercase() and uppercase() function below:
+
+// FIXME UNICODE
+// for lowercase() and uppercase() function below when wchar_t is not used:
 // 1) std::tolower() and std::toupper() are templates that
 // compile fine with char_type. With the test (c >= 256) we
 // do not trust these function to do the right thing with
@@ -310,19 +322,27 @@ char uppercase(char c)
 
 char_type lowercase(char_type c)
 {
+#if defined(HAVE_WCHAR_T) && SIZEOF_WCHAR_T == 4
+	return towlower(c);
+#else
 	if (c >= 256)
 		return c;
 
 	return tolower(c);
+#endif
 }
 
 
 char_type uppercase(char_type c)
 {
+#if defined(HAVE_WCHAR_T) && SIZEOF_WCHAR_T == 4
+	return towupper(c);
+#else
 	if (c >= 256)
 		return c;
 
 	return toupper(c);
+#endif
 }
 
 
Index: src/support/textutils.h
===
--- src/support/textutils.h	(Revision 15887)
+++ src/support/textutils.h	(Arbeitskopie)
@@ -17,12 +17,21 @@
 
 #include "support/types.h"
 
+#if defined(HAVE_WCHAR_T) && SIZEOF_WCHAR_T == 4
+// All implementations that have a 4byte wchar_t use UCS4 as encoding, so we
+// can simply 

Re: windows bug fixing

[Uwe Stöhr]

Georg Baum schrieb:


Joost has
built in some new things to fix bug 2918, bug 2923, bug 2936. He also moved the
debug output to a new application that informs the user about the debug output
when LyX crashes.


Why are these fixes not in 1.4.4svn? Or if they are, why are they not 
mentioned in status.14x?


Bug 2936 is not fixed, I was too rash here.
I remember that I've seen the SVN-log for the fix of bug 2923.
I was surprised that bug 2918 is fixed because I haven't seen a 
corresponding SVN commit.


Joost currently has no bugzilla account so that he's not able to post 
something there.


regards Uwe

[patch] Check only once for dtl tools

[Enrico Forestieri]

In configure.py, DTL tools are checked for in two distinct places.
The attached patches fix this. Ok to apply to both 1.4.x and trunk?

-- 
Enrico
Index: lib/configure.py
===
--- lib/configure.py(revision 15890)
+++ lib/configure.py(working copy)
@@ -179,13 +179,23 @@ def checkViewer(description, progs, rc_e
 return checkProg(description, progs, rc_entry, path, not_found = 'auto')
 
 
-def checkLatex():
-''' Check latex, return lyx_check_config '''
+def checkDTLtools():
+''' Check whether DTL tools are available (Windows only) '''
 # Find programs! Returned path is not used now
 if ((os.name == 'nt' or sys.platform == 'cygwin') and
 checkProg('DVI to DTL converter', ['dv2dt']) != ['', ''] and
 checkProg('DTL to DVI converter', ['dt2dv']) != ['', '']):
 # Windows only: DraftDVI
+dtl_tools = 'true'
+else:
+dtl_tools = 'false'
+return dtl_tools
+
+
+def checkLatex(dtl_tools):
+''' Check latex, return lyx_check_config '''
+if (dtl_tools):
+# Windows only: DraftDVI
 converter_entry = r'''\converter latex  dvi2   "%%""latex"
 \converter dvi2   dvi"python -tt $$s/scripts/clean_dvi.py $$i $$o" 
""'''
 else:
@@ -213,7 +223,7 @@ def checkLatex():
 return ''
 
 
-def checkFormatEntries():  
+def checkFormatEntries(dtl_tools):  
 ''' Check all formats (\Format entries) '''
 checkViewer('a Tgif viewer and editor', ['tgif'],
 rc_entry = [r'\Format tgif   obj Tgif   "" 
"%%""%%"'])
@@ -271,9 +281,7 @@ def checkFormatEntries():  
 #
 checkViewer('a DVI previewer', ['xdvi', 'kdvi'],
 rc_entry = [r'\Format dvidvi DVID  
"%%"""'])
-if ((os.name == 'nt' or sys.platform == 'cygwin') and
-checkProg('DVI to DTL converter', ['dv2dt']) != ['', ''] and
-checkProg('DTL to DVI converter', ['dt2dv']) != ['', '']):
+if (dtl_tools):
 # Windows only: DraftDVI
 addToRC(r'\Format dvi2   dvi DraftDVI   "" ""  
""')
 #
@@ -747,6 +755,7 @@ Options:
 setEnviron()
 createDirectories()
 windows_style_tex_paths = checkTeXPaths()
+dtl_tools = checkDTLtools()
 ## Write the first part of outfile
 writeToFile(outfile, '''# This file has been automatically generated by 
LyX' lib/configure.py
 # script. It contains default settings that have been determined by
@@ -756,8 +765,8 @@ Options:
 # override the values given here.
 ''')
 # check latex
-LATEX = checkLatex()
-checkFormatEntries()
+LATEX = checkLatex(dtl_tools)
+checkFormatEntries(dtl_tools)
 checkConverterEntries()
 (chk_linuxdoc, bool_linuxdoc, linuxdoc_cmd) = checkLinuxDoc()
 (chk_docbook, bool_docbook, docbook_cmd) = checkDocBook()
Index: lib/configure.py
===
--- lib/configure.py(revision 15890)
+++ lib/configure.py(working copy)
@@ -183,13 +183,23 @@ def checkViewer(description, progs, rc_e
 return checkProg(description, progs, rc_entry, path, not_found = 'auto')
 
 
-def checkLatex():
-''' Check latex, return lyx_check_config '''
+def checkDTLtools():
+''' Check whether DTL tools are available (Windows only) '''
 # Find programs! Returned path is not used now
 if ((os.name == 'nt' or sys.platform == 'cygwin') and
 checkProg('DVI to DTL converter', ['dv2dt']) != ['', ''] and
 checkProg('DTL to DVI converter', ['dt2dv']) != ['', '']):
 # Windows only: DraftDVI
+dtl_tools = 'true'
+else:
+dtl_tools = 'false'
+return dtl_tools
+
+
+def checkLatex(dtl_tools):
+''' Check latex, return lyx_check_config '''
+if (dtl_tools):
+# Windows only: DraftDVI
 converter_entry = r'''\converter latex  dvi2   "%%""latex"
 \converter dvi2   dvi"python -tt $$s/scripts/clean_dvi.py $$i $$o" 
""'''
 else:
@@ -217,7 +227,7 @@ def checkLatex():
 return ''
 
 
-def checkFormatEntries():  
+def checkFormatEntries(dtl_tools):  
 ''' Check all formats (\Format entries) '''
 checkViewer('a Tgif viewer and editor', ['tgif'],
 rc_entry = [r'\Format tgif   obj Tgif   "" 
"%%""%%""vector"'])
@@ -278,9 +288,7 @@ def checkFormatEntries():  
 #
 checkViewer('a DVI previewer', ['xdvi', 'kdvi'],
 rc_entry = [r'\Format dvidvi DVID  
"%%"""  "document,vector"'])
-if ((os.name == 'nt' or sys.platform == 'cygwin') and
-checkProg('DVI to DTL converter', ['dv2dt']) != ['', ''] and
-checkProg('DTL to DVI converter', ['dt2dv']) != ['', '']):
+if (dtl_tools):
 # Windows only: DraftDVI
 addToRC(r'\Format dvi2   dvi DraftDVI   "" "" 

Crash in view->something with Extended-Insets.lyx

[Kornel Benko]

Latest in trunk

in LyX open file Extended-Insets.lyx (The latest anounced by Uwe Stöhr,
http://wiki.lyx.org/LyX/DocumentationDevelopment#Extended-Insets)
view->DVI (or view->Postscript etc)
==> crash
...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1087020320 (LWP 13458)]
0x40ba8f4d in __gconv_close () from /lib/tls/libc.so.6
(gdb) bt
#0  0x40ba8f4d in __gconv_close () from /lib/tls/libc.so.6
#1  0x40ba85dc in iconv_close () from /lib/tls/libc.so.6
#2  0x0851cb15 in lyx::IconvProcessor::~IconvProcessor ()
#3  0x0851eaac in std::pair::~pair ()
#4  0x0851daa3 in lyx::ucs4_to_eightbit ()
#5  0x081dcdd9 in lyx::(anonymous namespace)::TeXOnePar ()
#6  0x081dd4aa in lyx::latexParagraphs ()
#7  0x083114d9 in lyx::InsetText::latex ()
#8  0x082e3bc9 in lyx::InsetFoot::latex ()
#9  0x081eda72 in lyx::Paragraph::Pimpl::simpleTeXSpecialChars ()
#10 0x081e42e5 in lyx::Paragraph::simpleTeXOnePar ()
#11 0x081dc02b in lyx::(anonymous namespace)::TeXOnePar ()
#12 0x081dd4aa in lyx::latexParagraphs ()
#13 0x083114d9 in lyx::InsetText::latex ()
#14 0x082bfe3c in lyx::InsetBox::latex ()
...

But no problems with my other lyx-files

Kornel
--

Re: 3 important bugs right now - more testing needed!

[Jean-Marc Lasgouttes]

> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:

Georg> No. They use the wchar_t stuff from the C library for wide
Georg> strings internally. If that is usable (e.g. on linux) we can as
Georg> well use it directly.

Georg> The attached patch does that. I am very tempted to apply it and
Georg> have the windows people look for a solution for their platform.
Georg> If such a solution is found we can still decide whether we use
Georg> it always or only on windows.

This is not a regression for windows anyway, right? I'd say to put the
patch in, except that it might be better to define a
USE_LIBC_WCHAR_SUPPORT (or something more explicit) define instead of
+#if defined(HAVE_WCHAR_T) && SIZEOF_WCHAR_T == 4

I am not sure where it should be defined, though.

JMarc