Re: citation dialog

[Alfredo Braunstein]

Georg Baum wrote:

 Am Donnerstag, 9. November 2006 16:09 schrieb Jean-Marc Lasgouttes:
  Alfredo == Alfredo Braunstein
  [EMAIL PROTECTED] writes:
 
 Alfredo PS: there's a surprising (good) amount of activity on this
 Alfredo list!
 
 Hello Alfredo,
 
 Do you feel like coming back to have fun with us?
 
 That would be great!

Hello Jean-Marc, hello Georg!

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!

A/

Re: New Mac Profile

[Andre Poenitz]

On Tue, Oct 31, 2006 at 09:36:49PM +0100, Abdelrazak Younes wrote:
 Bennett Helm wrote:
 On Oct 31, 2006, at 12:23 PM, Andreas Vox wrote:
 
 I didn't save the old profile, so I've created a new one. The screenshot 
 can be found here:
 
 http://edisk.fandm.edu/bennett.helm/LyX/QLPainter.C-profile.jpg
 
 Hum... That's what I feared. We have eliminated all important 
 bottlenecks in LyX. Remains the Qt ones. I don't understand why the 
 QPainter::drawText() is so slow on Mac.
 
 There's maybe some Mac specific settings that we should set to speed up 
 things. Maybe limit the number of colors to 256 or something like that...
 
 Some googling is in order.

Why not asking on [EMAIL PROTECTED]

Andre'

Re: About New TabBar and Multiple-Windows

[Andre Poenitz]

On Wed, Nov 01, 2006 at 09:39:02PM +0100, Joost Verburg wrote:
 Lars Gullik Bjønnes wrote:
 We have a filesystem...
 Filesystems are shared between computers...
 Computer have users...
 Users run LyX...
 LyX loads the same file...
 
 LyX can set a write lock on open files.

How?

NFS locking is notorious for working only on Fridays when the moon is
full.

 There are indeed two options:
 
 1) Display an error message when the file is already opened by another 
 LyX process.

How do you know that a file is opened by a process in a portable manner?

 It will be impossible to know which windows have the data 
 of the document (they all look the same independent of the process).
 2) Use a single process by default so users will automatically get a new 
 view with the right contents.
 
 Option 2 is definitely more user-friendly.

As in can't run batch converters anymore just because someone views a
lyx file?

Andre'

Re: [Cvslog] r15792 - in /lyx-devel/trunk/src: BufferView.C frontends/...

[Andre Poenitz]

On Tue, Nov 07, 2006 at 09:31:35PM -, [EMAIL PROTECTED] wrote:
 Author: alstrup
 Date: Tue Nov  7 22:31:33 2006
 New Revision: 15792
 
 URL: http://www.lyx.org/trac/changeset/15792
 Log:
 - Avoid lyxerr[] like the plague. Use if (lyxerr.debugging( ... )) instead.
 
 Modified:
 lyx-devel/trunk/src/BufferView.C
 lyx-devel/trunk/src/frontends/WorkArea.C
 lyx-devel/trunk/src/rowpainter.C
 lyx-devel/trunk/src/text.C
 
 Modified: lyx-devel/trunk/src/BufferView.C
 URL: http://www.lyx.org/trac/file/lyx-devel/trunk/src/BufferView.C?rev=15792
 ==
 --- lyx-devel/trunk/src/BufferView.C (original)
 +++ lyx-devel/trunk/src/BufferView.C Tue Nov  7 22:31:33 2006
 @@ -355,7 +355,9 @@
   if (!buffer_)
   return false;
  
 - lyxerr[Debug::WORKAREA]  BufferView::update  std::endl;
 + if (lyxerr.debugging(Debug::WORKAREA)) {
 + lyxerr[Debug::WORKAREA]  BufferView::update  std::endl;
 + }

Isn't that equivalent to

 +  if (lyxerr.debugging(Debug::WORKAREA)) {
 +  lyxerr  BufferView::update  std::endl;
 +  }

?

Apart from that lyxerr usage is one of the places where I'd prefer real
macros using __FILE__ and __LINE__ that could be used for 'one-click-
navigation'.

#define LYXERR(channel, msg) \
if (!lyxerr.debugging(channel)) \
; \
else \
lyxerr  __FILE__  (  __LINE__  ):   msg  
std::endl

and

 LYXERR(Debug::WORKAREA, BufferView::update);

would do for starters.

Less clutter in the source, faster execution if the message is not shown
and more useful information if it is shown. Pretty much a win-win-win
situation.

Andre'

Re: [patch] Fix writing a space after a latex macro

[Andre Poenitz]

On Mon, Oct 30, 2006 at 08:03:56PM +0100, Enrico Forestieri wrote:
 On Mon, Oct 30, 2006 at 07:49:46PM +0100, Georg Baum wrote:
 
  Am Montag, 30. Oktober 2006 19:17 schrieb Enrico Forestieri:
   The attached patch fixes the \sinx problem.
  
  Good that you found it.
  
   Any objections to applying it? 
  
  Yes. isAlpha() should be implemented as an ucs4 function, and if a hack is 
  needed it should be done inside this function.
 
 An hack? What do you mean?
 
  Then I would also like to know why this problem was introduced. Probably 
  not by removing the code you just added (or was it done by accident?).
 
 Probably by adding the overloaded  operator and not taking the appropriate
 actions. Last week it was really difficult to follow all changes...
 
  Are 
  you sure that you do not trigger another problem that was to be solved by 
  the patch that created the \sinx problem?
 
 No, I am not sure of anything, but I can't see what problem could be
 introduced. The \sinx problem was introduced by overlooking, IMO.

No, probably when converting the math parser to unicode.

Andre'

Re: New Mac Profile

[Andre Poenitz]

On Wed, Nov 01, 2006 at 11:03:18AM +0100, Abdelrazak Younes wrote:
 The nice thing about it is that we draw directly on screen thus 
 eliminating the transfer of the old backing pixmap onto the screen.
 On the other hand, the screen estate is not saved. This means that, if 
 part of the WorkArea is masked, the widget will receive a paint Event 
 and everything will be redrawn, not only the part that is not masked.

Stuff like that (parts of windows hidden behind others) is usually taken
care of by the system.

I'd be really surprised if any windowing system from this millenium
would actively send draw requests to the application just because some
window is moving in front of it.

I'd rather suspect we are sending an update() somewhere ourselves.

 Confirmed, sort of (there may be several redraws per keypress)
 
 Yes, the number of lyx-redraws depend now on the number of Qt 
 paintEvent(). paintEvent() can be triggered by other thing than 
 WorkArea::redraw().

It will be triggered by an update() (or sequence of updtes() for that
matter). I would like to see a situation where paintEvent() is called
without us actively calling update() (or doing 'obvious' stuff, like
showing the widget for the first time...)

Andre'

Re: About New TabBar and Multiple-Windows

[Andre Poenitz]

On Wed, Nov 01, 2006 at 09:04:51PM +0100, Jean-Marc Lasgouttes wrote:
  Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
 
 | In LyX 1.4 there is one window per process. However now one process 
 | can have multiple windows, there should only be one running process.
 
 Lars I don't get this logic.
 
 Let's say we should use the same instance by default (to avoid
 surprises), but there should be a way to launch a new instance.

Could anybody elaborte on the practical side how such an 'instance
singleton' would be implemented?

Maybe with home dir and LyX itself on NFS shares?

And maybe while retaining the possibility to use LyX in batchmode?

Andre'

Re: Movable toolbars

[Andre Poenitz]

On Wed, Nov 01, 2006 at 08:43:19AM +1800, Bo Peng wrote:
 I've just enabled it.
 
 
 Then, it makes sense to save toolbar position in session. Could you
 please tell me the functions to get/set toolbar position? Note that
 the interface has to be done independent of frontend.

Why don't you simply declare toolbars a GUI issue and use
QMainWindow::{save,restore}State?

Andre'

Re: [patch] xymatrix

[Andre Poenitz]

On Mon, Oct 30, 2006 at 10:04:15PM +0100, Georg Baum wrote:
 This patch makes it possible to read and write all \xymatrix commands. 
 There is no UI, meaning it is not possible to enter the extended commands 
 in mathed other than copying the pure LaTeX from outside of LyX or texted, 
 and you cannot see the aditional arguments on screen other than in the 
 status line.

Nice.

Andre'

Re: [Patch] optimize utf8_to_ucs4

[Andre Poenitz]

On Mon, Oct 30, 2006 at 08:49:36PM +0100, Joost Verburg wrote:
 Georg Baum wrote:
 OK, so it is like that: Up to 4 bytes per code point are used for the 
 currently defined 21 bits of UCS4, but UTF8 is designed in such a way that 
 it is possible to encode all 36 bits of UCS4 with at most 6 bytes per code 
 point.
 
 Not really. Some years ago there was not yet a real limit in the Unicode 
 specification for the number of code points (the theoretical limit was 
 2^31 if I remember correctly).
 
 However, the limit has now been set to 2^20+2^16 code points. There is 
 still a lot of space available, but there will _never_ be any more code 
 points than 2^20+2^16 (also not in UCS-4!).

Roughly a million characters does not sound as overly excessive when
there are languages using several thousands of them already...

Andre'

Re: [Updated PATCH] session/toolbar.

[Andre Poenitz]

On Thu, Nov 02, 2006 at 12:37:41PM +1800, Bo Peng wrote:
  The major problem is with
  math/review/table toolbars. The logic is now:
 
  1. if math is on when lyx exists, I assume it is always on
  2. if math is off when lyx exists, I assume it is auto.
 
 But now it does not remember the position of the moved auto toolbars.
 
 Because auto toolbars are not visible when lyx closes! How can I get
 their location if they are not visible? (I guess your previous patch
 does this?)

show them while you are shutting down.

Andre'

Re: About New TabBar and Multiple-Windows

[Andre Poenitz]

On Wed, Nov 01, 2006 at 08:11:11PM +0100, Joost Verburg wrote:
 José Matos wrote:
   What is the difference to what we have now?
 
   Why don't we see people complaining about that?
 
 In LyX 1.4 there is one window per process. However now one process can 
 have multiple windows, there should only be one running process.

I'd rather have only one window per process. This could have mutliple
buffers arranged in a tabbed widget or such.

Andre'

Re: [Cvslog] r15630 - in /lyx-devel/trunk: INSTALL development/TodoPla...

[Andre Poenitz]

On Mon, Oct 30, 2006 at 09:45:38PM -, [EMAIL PROTECTED] wrote:
 +++ lyx-devel/trunk/src/frontends/qt4/GuiFontLoader.C Mon Oct 30 22:45:37 2006
 @@ -141,7 +141,6 @@
   return true;
   }
  
 - // Qt 3.2 beta1 returns xft for all xft fonts
   // Qt 4.1 returns Multi for all ? xft fonts
   if (font.rawName() == xft || font.rawName() == Multi) {
   if (contains(fromqstr(fi.family()), family)) {

So when can a font.rawName() be xft nowadays?

Andre'

Re: About New TabBar and Multiple-Windows

[Andre Poenitz]

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

Re: Maximized window bug

[Andre Poenitz]

On Wed, Nov 01, 2006 at 02:42:19PM +, John Levon wrote:
 On Wed, Nov 01, 2006 at 03:28:29PM +0100, Peter Kümmel wrote:
 
  I've field two bugs, this
  http://www.trolltech.com/developer/task-tracker/index_html?id=119684+method=entry
  and the maximized, but they say they can't do anything, as in the docs.
 
 Yeah, I never had much luck getting Trolltech to fix their bugs either.

Poor little tiger.

Andre'

Re: About New TabBar and Multiple-Windows

[Andre Poenitz]

On Wed, Nov 01, 2006 at 09:18:53PM +0100, Joost Verburg wrote:
 Abdelrazak Younes wrote:
 I can explain you how it works on Windows,
 
 Yes please.
 
 You can use a mutex to detect the running process and a window message 
 to have the existing process start a new document.

Windows has system-global mutexes. A very limited number for that
matter. And you btter make really sure your app releases them even
when it dies unexpectedly.

Unix does not have that. I doubt Macs have that.

Andre'

Re: Movable toolbars

[Andre Poenitz]

On Tue, Oct 31, 2006 at 03:30:43PM +, John Levon wrote:
 On Tue, Oct 31, 2006 at 03:22:34PM +, José Matos wrote:
 
  On Tuesday 31 October 2006 2:43 pm, John Levon wrote:
   On Tue, Oct 31, 2006 at 03:42:32PM +0100, Peter Kümmel wrote:
I've just enabled it.
  
   Nice :(
  
Could you elaborate, please?
  
The switch is simple, and we can change it at any time. :-)
 
 That it just happened without discussion of whether it makes sense,
 unlike when I disabled it, when I actually asked people?

People expect that from a Qt application, no matter whether it makes
sense or not.

And it is completely invisble to people that do not try to move toolbars
anyway.

Andre'

Re: About New TabBar and Multiple-Windows

[Andre Poenitz]

On Wed, Nov 01, 2006 at 06:48:33PM +0100, Enrico Forestieri wrote:
 On Wed, Nov 01, 2006 at 06:25:05PM +0100, Joost Verburg wrote:
 
  Peter Kümmel wrote:
   I don't understand why we need this new Window feature.
   If someone wants two top level LyX programs then he could
   start LyX twice.
  
  Sometimes you want to edit to same document in two places. However now 
  we have this multiple window feature, it should not be possible anymore 
  to start multiple LyX instances.
 
 Unless specifically requested. I have your word that I can have
 that option ;-)

And that option will be named  'lyx  ; lyx '

Andre'

Re: [Cvslog] r15728 - /lyx-devel/trunk/src/mathed/MathParser.C

[Andre Poenitz]

On Sun, Nov 05, 2006 at 09:33:42PM +0100, Herbert Voss wrote:
 Georg Baum schrieb:
  Am Sonntag, 5. November 2006 19:22 schrieb Herbert Voss:
  I am interested in seeing how someone will parse a tex source, where
  _every_ macro or environment can be hide after several other macros
  or catcode changes ...
  
  Impossible IMHO. It is possible to create a tex2lyx that works perfectly 
  for most _usual_ documents (no catcode games, no redefinition of standard 
  macros with different semantics), and tex2lyx is in some areas close to 
  that, but if you consider changed catcodes and macros you get a real mess.
 
 Every thesis without catcode stuff has a _lot_ of redefinitions in the
 preamble. As I said, it is lost time and work for such a converter
 which will only work for some (short) documents ... and it confuses
 the users, when there is a tex2lyx, which works sometimes ...

Better a half-working tex2lyx than no way to import LaTeX at all.

Andre'

Re: About New TabBar and Multiple-Windows

[Andre Poenitz]

On Wed, Nov 01, 2006 at 07:11:34PM +0100, Joost Verburg wrote:
 Lars Gullik Bjønnes wrote:
 | Sometimes you want to edit to same document in two places. However now
 | we have this multiple window feature, it should not be possible
 | anymore to start multiple LyX instances. Can someone take a look at
 | this?
 
 Why?
 
 It does not make sense to allow multiple instances when each instance 
 can also have multiple windows. There is no way to tell which window 
 belongs to which instance and therefore you can easily loose data by 
 saving the wrong version of a document.

There are many good reasons.

For one: if one instance crashes I have still the others active.
For two: You can't implement it properly.
For three: Multiple 'big' windows per application are bad per se,
so if you don't use them, you won't run into the problem you mentioned.
Even Microsoft changed its attitude here.

Andre'

Re: [Cvslog] r15791 - in /lyx-devel/trunk/src: frontends/FontMetrics.h...

[Andre Poenitz]

On Tue, Nov 07, 2006 at 08:46:40PM -, [EMAIL PROTECTED] wrote:
 Author: baum
 Date: Tue Nov  7 21:46:38 2006
 New Revision: 15791
 
 URL: http://www.lyx.org/trac/changeset/15791
 Log:
 document docstring abuse for symbol font code points

I wonder whether a 'drawSymbol' function would not have been 
better documentation...

Andre'

Re: r15615 - in /lyx-devel/trunk/src: insets/insettabular.C m...

[Andre Poenitz]

On Mon, Oct 30, 2006 at 02:41:15PM +0100, Georg Baum wrote:
 Yes, that was the reason for similar problems in the past, but I could not
 find any undefined virtual method. Are we all blind? BTW Abdel your latest
 patch does not help either (although callinf the Painter() constructor is a
 good idea anyway).

Could you elaborate on why this can make a difference?

Andre'

Re: About New TabBar and Multiple-Windows

[Andre Poenitz]

On Wed, Nov 01, 2006 at 06:25:05PM +0100, Joost Verburg wrote:
 Peter Kümmel wrote:
 I don't understand why we need this new Window feature.
 If someone wants two top level LyX programs then he could
 start LyX twice.
 
 Sometimes you want to edit to same document in two places. However now 
 we have this multiple window feature, it should not be possible anymore 
 to start multiple LyX instances. Can someone take a look at this?

Rest assured that I will try my best to immediately revert any patch
that tries to remove my ability to start mulitple instances of LyX.

Andre'

Re: About New TabBar and Multiple-Windows

[Andre Poenitz]

On Wed, Nov 01, 2006 at 07:05:34PM +0100, Abdelrazak Younes wrote:
 Joost Verburg wrote:
 Abdelrazak Younes wrote:
 Sometimes you want to edit to same document in two places. However 
 now we have this multiple window feature, it should not be possible 
 anymore to start multiple LyX instances. Can someone take a look at 
 this?
 
 Could you post again the code to do so?
 
 I can explain you how it works on Windows,
 
 Yes please.
 
 I don't know about UNIX. Or 
 does Qt provide some generic method?
 
 No but KDE does AFAIR. It's called KUniqueApplication or something like 
 that. We could borrow some of their code.

Why the f*** do you want to cripple LyX?

These 'single instance' applications are a major pain (and never really
work well) in a distributed environment. Windows has system-global
entities to lock stuff, but it is essentially a single-user,
non-network transparent OS that can live with blocking stuff as the
single user is usually blocking only himself. This does not work on *nix
(and it doesn't even work properly on Windows terminal server either)

Andre'

-- 

Re: Movable toolbars

[Andre Poenitz]

On Tue, Oct 31, 2006 at 03:51:44PM +0100, Peter Kümmel wrote:
 José Matos wrote:
  GuiView.C:78: error: ISO C++ forbids declaration of 'QTabBar' with no type
 
 I've added the include of QTabBar.
 Does this help?
 
 Maybe I should remove the Qt headers from the precompiled msvc-headers.

Why?

The speedup is significant.

Andre'

Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)

[Andre Poenitz]

On Thu, Nov 02, 2006 at 01:34:20PM +0100, Peter Kümmel wrote:
 Thanks Abdel, this is very good. We should add it some where in the wiki.

And to the code somewhere. Perhaps BufferView.C with pointers from
buffer and LyXView.

Andre'

Re: [Cvslog] r15728 - /lyx-devel/trunk/src/mathed/MathParser.C

[Andre Poenitz]

On Sun, Nov 05, 2006 at 04:00:39PM +0100, Abdelrazak Younes wrote:
 Enrico Forestieri wrote:
 On Sun, Nov 05, 2006 at 09:58:28AM +0100, Georg Baum wrote:
 I think that we should leave the 256, but if you and others don't agree,
 then please also make the corresponding changes to texparser.C
 Abdel is right that a table of 256 is not needed, since we never set the 
 catcode of any character above 256 to something else than 256, and we 
 need the if anyway. I have changed the comment accordingly, but if 
 anybody else prefers 256 I have no problem with that either.
 
 I am trying to say that, currently, LyX is not correctly tracking catcodes
 and if we want to improve on that, then we should maintain the 256.
 
 As an example, try importing in LyX the attached valid latex file and you
 will see what I mean. This is a bug, IMO.
 
 Are you saying that it is allowed to create new catcodes in a latex file?

You can redefine them.

Andre'

Re: About New TabBar and Multiple-Windows

[Abdelrazak Younes]

Andre Poenitz wrote:

On Wed, Nov 01, 2006 at 08:11:11PM +0100, Joost Verburg wrote:

José Matos wrote:

 What is the difference to what we have now?

 Why don't we see people complaining about that?
In LyX 1.4 there is one window per process. However now one process can 
have multiple windows, there should only be one running process.


I'd rather have only one window per process. This could have mutliple
buffers arranged in a tabbed widget or such.


I agree that on Windows, Single-window and Multi-WorkArea (via tabbed 
widget and/or split windows) is the best idea. Once this is done, we can 
remove multi-window support. But on X11, I insist that we should support 
 multi-windows.


Abdel.

Re: [patch] esint support

[Jean-Marc Lasgouttes]

 Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:

Abdelrazak I was partly wrong. While disabling these methods
Abdelrazak definitely helps (with the attached patch), the csrss.exe
Abdelrazak problem and the poor typing performance at the end the doc
Abdelrazak is still there. I really wonder why the slowness is only
Abdelrazak for the paragraph immediately before or after a big
Abdelrazak equation...

You mean that typing in a paragraph calls updateLabels? This should
definitely not happen IMO. We should find out why.

One thing that is probably a big problem is the construction of macro
table by Buffer::buildMacros at each update.

JMarc

Re: [Cvslog] r15791 - in /lyx-devel/trunk/src: frontends/FontMetrics.h...

[Georg Baum]

Am Mittwoch, 8. November 2006 21:37 schrieb Andre Poenitz:
 On Tue, Nov 07, 2006 at 08:46:40PM -, [EMAIL PROTECTED] wrote:
  Author: baum
  Date: Tue Nov  7 21:46:38 2006
  New Revision: 15791
  
  URL: http://www.lyx.org/trac/changeset/15791
  Log:
  document docstring abuse for symbol font code points
 
 I wonder whether a 'drawSymbol' function would not have been 
 better documentation...

Yes, I thought about that. I did not do it, because you would need several 
ones (in mathed and frontend, and also for metrics), the code would be 
exactly identical to the existing methods, and you would need to introduce 
a switch in InsetMathSymbol that decides whether to use drawSymbol or 
drawText (which both would do the same). That did not look like a good 
solution to me and prone to somebody doing some cleanup.
A real solution would probably use two different insets for real symbols 
(drawn with symbol fonts) and functions and unknown symbols, but I did not 
want to do that at this time.


Georg

Re: r15615 - in /lyx-devel/trunk/src: insets/insettabular.C m...

[Georg Baum]

Am Mittwoch, 8. November 2006 19:18 schrieb Andre Poenitz:
 On Mon, Oct 30, 2006 at 02:41:15PM +0100, Georg Baum wrote:
  Yes, that was the reason for similar problems in the past, but I could 
not
  find any undefined virtual method. Are we all blind? BTW Abdel your 
latest
  patch does not help either (although callinf the Painter() constructor 
is a
  good idea anyway).
 
 Could you elaborate on why this can make a difference?

I probably mixed that up with calling the copy constructor of a base class.


Georg

Re: [patch] esint support

[Georg Baum]

Am Freitag, 10. November 2006 22:39 schrieb Abdelrazak Younes:
 Because the plan is to move toc.[Ch] altogether. We can then rename 
 TocBackend to something else if you want.

I don't care about the name as long as the code speaks for itself.

  I do neither understand why TocBackend is not in namespace toc.
 
 Could be indeed. But we decided that we will only do lyx and 
 lyx::support and lyx::frontend from now on, didn't we?

I did not notice that, but in that case nothing should be in that 
namespace. I am not picky about namespaces in general, the important thing 
for me is that there is some logic in the naming.

 TocBackend. The typedefs are just there because of API compatibility 
 issue; see my other mail.

I understand that now, but it took me some time. If you do something like 
this the next time please add some comments.


Georg

Re: TOC-crach backtrace

[Martin Vermeer]

On Fri, 10 Nov 2006 17:06:00 +0100 Abdelrazak Younes [EMAIL PROTECTED] wrote:

 Martin Vermeer wrote:
  On Fri, 2006-11-10 at 11:09 +0100, Jean-Marc Lasgouttes wrote:
  Martin == Martin Vermeer [EMAIL PROTECTED] writes:
  Martin Before going to work on this, consider the patch (for 1.4)
  Martin that I submitted a while ago and may be relevant. Attached
  Martin again.
 
  Martin, I finally tested your patch! Better late than never...
 
  It works as advertised. Please apply (with status.14x entry!) and
  close the relevant bug.
  
  So done, thanks. (What was the bug number? Don't find it.) Should
 this
  go into 1.5 too?
  
  * src/toc.C
  (outline): Fix undo bug in TOC navigation
 
 If it is a fix, why not?
 
 Abdel.

Is the code base still close enough? I remember you did things there.

- Martin

Re: [patch] esint support

[Georg Baum]

Am Samstag, 11. November 2006 03:05 schrieb Abdelrazak Younes:
  I wonder if this addToToc() method is a good idea at all... I'd prefer 
  the TocBackend to it himself. InsetInclude doesn't need to know how to 
  do that. The same goes for InsetFloat and InsetWrap I guess.

It is a good idea IMO. Nothing outside of InsetWrap etc. should need to 
know how InsetWrap etc. works. addToToc() is a clean solution IMO: Any 
inset that has to add something to the ToC can implement it, and fill the 
list.

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

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


Georg

Re: [patch] Allow unicode labels in layout files

[Georg Baum]

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?

Oops, forgot the patch. This one is now going in, if the addtitional 
translations are wrong please shout.


Georg
Index: src/text2.C
===
--- src/text2.C	(Revision 15853)
+++ src/text2.C	(Arbeitskopie)
@@ -352,7 +352,7 @@ void LyXText::setLayout(Buffer const  b
 	for (pit_type pit = start; pit != end; ++pit) {
 		pars_[pit].applyLayout(lyxlayout);
 		if (lyxlayout-margintype == MARGIN_MANUAL)
-			pars_[pit].setLabelWidthString(lyxlayout-labelstring());
+			pars_[pit].setLabelWidthString(buffer.translateLabel(lyxlayout-labelstring()));
 	}
 }
 
@@ -604,7 +604,7 @@ docstring LyXText::getStringToIndex(LCur
 
 void LyXText::setParagraph(LCursor  cur,
 			   Spacing const  spacing, LyXAlignment align,
-			   string const  labelwidthstring, bool noindent)
+			   docstring const  labelwidthstring, bool noindent)
 {
 	BOOST_ASSERT(cur.text());
 	// make sure that the depth behind the selection are restored, too
@@ -628,8 +628,7 @@ void LyXText::setParagraph(LCursor  cur
 			else
 params.align(align);
 		}
-		// FIXME UNICODE
-		par.setLabelWidthString(from_ascii(labelwidthstring));
+		par.setLabelWidthString(labelwidthstring);
 		params.noindent(noindent);
 	}
 }
Index: src/buffer.C
===
--- src/buffer.C	(Revision 15853)
+++ src/buffer.C	(Arbeitskopie)
@@ -1445,6 +1445,18 @@ docstring const Buffer::B_(string const 
 }
 
 
+docstring const Buffer::translateLabel(docstring const  label) const
+{
+	if (support::isAscii(label))
+		// Probably standard layout, try to translate
+		return B_(to_ascii(label));
+	else
+		// This must be a user defined layout. We can not translate
+		// this, since gettext accepts only ascii keys.
+		return label;
+}
+
+
 bool Buffer::isClean() const
 {
 	return pimpl_-lyx_clean;
Index: src/lyxtext.h
===
--- src/lyxtext.h	(Revision 15854)
+++ src/lyxtext.h	(Arbeitskopie)
@@ -260,7 +260,7 @@ public:
 	void setParagraph(LCursor  cur,
 			  Spacing const  spacing,
 			  LyXAlignment align,
-			  std::string const  labelwidthstring,
+			  docstring const  labelwidthstring,
 			  bool noindent);
 
 	/* these things are for search and replace */
Index: src/buffer.h
===
--- src/buffer.h	(Revision 15853)
+++ src/buffer.h	(Arbeitskopie)
@@ -170,6 +170,8 @@ public:
 	Language const * getLanguage() const;
 	/// get l10n translated to the buffers language
 	docstring const B_(std::string const  l10n) const;
+	/// translate \p label to the buffer language if possible
+	docstring const translateLabel(docstring const  label) const;
 
 	///
 	int runChktex();
Index: src/support/lstrings.C
===
--- src/support/lstrings.C	(Revision 15853)
+++ src/support/lstrings.C	(Arbeitskopie)
@@ -279,6 +279,16 @@ int hexToInt(docstring const  str)
 }
 
 
+bool isAscii(docstring const  str)
+{
+	int const len = str.length();
+	for (int i = 0; i  len; ++i)
+		if (str[i] = 0x80)
+			return false;
+	return true;
+}
+
+
 char lowercase(char c)
 {
 	return char(tolower(c));
Index: src/support/lstrings.h
===
--- src/support/lstrings.h	(Revision 15853)
+++ src/support/lstrings.h	(Arbeitskopie)
@@ -72,6 +72,9 @@ bool isHex(lyx::docstring const  str);
 
 int hexToInt(lyx::docstring const  str);
 
+/// is \p str pure ascii?
+bool isAscii(docstring const  str);
+
 ///
 char lowercase(char c);
 
Index: src/text3.C
===
--- src/text3.C	(Revision 15854)
+++ src/text3.C	(Arbeitskopie)
@@ -1411,7 +1411,7 @@ void LyXText::dispatch(LCursor  cur, Fu
 			}
 
 			setLayout(cur, tclass.defaultLayoutName());
-			setParagraph(cur, Spacing(), LYX_ALIGN_LAYOUT, string(), 0);
+			setParagraph(cur, Spacing(), LYX_ALIGN_LAYOUT, docstring(), 0);
 			insertInset(cur, new InsetFloatList(to_utf8(cmd.argument(;
 			cur.posRight();
 		} else {
@@ -1455,11 +1455,10 @@ void LyXText::dispatch(LCursor  cur, Fu
 		lex.setStream(is);
 		ParagraphParameters params;
 		params.read(lex);
-		// FIXME UNICODE
 		setParagraph(cur,
 			 params.spacing(),
 			 params.align(),
-			 to_ascii(params.labelWidthString()),
+			 params.labelWidthString(),
 			 params.noindent());
 		cur.message(_(Paragraph layout set));
 		break;
Index: src/lyxlayout.C

Re: [patch] esint support

[Georg Baum]

Am Samstag, 11. November 2006 03:05 schrieb Abdelrazak Younes:
 Abdelrazak Younes wrote:
  I wonder if this addToToc() method is a good idea at all... I'd prefer 
  the TocBackend to it himself. InsetInclude doesn't need to know how to 
  do that. The same goes for InsetFloat and InsetWrap I guess.
 
 Here is a patch that does that for InsetInclude. This is cleaner IMHO 
 even if the special cases in TocBackend are still ugly.

As I wrote I do not like that. I updated my version after your changes, and 
here it is. The patch lloks bigger than it really is, because most of the 
changes are renamed toc stuff. I also solved the problem of non-working 
setBuffer by switching to the existing view of the other buffer instead.
I changed the stuff in InsetInclude to not load the document anymore. That 
speeds up loading of the master a lot. Of course the included docs are now 
only shown in the navigate menu if they are already loaded by other means, 
but that is a good compromise IMO.

I consider this now stable enough and ready for 1.5.0. What do you think 
José? And what about the esint stuff?


Georg
Index: src/buffer_funcs.h
===
--- src/buffer_funcs.h	(Revision 15855)
+++ src/buffer_funcs.h	(Arbeitskopie)
@@ -58,17 +58,17 @@ lyx::docstring expandLabel(Buffer const 
 /**
 A full updateLabels(Buffer const ) will be called if not possible.
 */
-void updateLabels(Buffer const  buf, ParIterator  it);
+void updateLabels(Buffer const  buf, ParIterator  it, bool childonly = false);
 
 /// update labels between from and to if possible.
 /**
 A full updateLabels(Buffer const ) will be called if not possible.
 */
 void updateLabels(Buffer const  buf,
-	ParIterator  from, ParIterator  to);
+	ParIterator  from, ParIterator  to, bool childonly = false);
 
 /// updates all counters
-void updateLabels(Buffer const );
+void updateLabels(Buffer const , bool childonly = false);
 
 
 } // namespace lyx
Index: src/insets/insetfloat.C
===
--- src/insets/insetfloat.C	(Revision 15855)
+++ src/insets/insetfloat.C	(Arbeitskopie)
@@ -29,13 +29,11 @@
 #include lyxlex.h
 #include outputparams.h
 #include paragraph.h
-#include pariterator.h
+#include TocBackend.h
 
 #include support/lstrings.h
 #include support/convert.h
 
-#include sstream
-
 
 namespace lyx {
 
@@ -378,7 +376,7 @@ void InsetFloat::sideways(bool s, Buffer
 }
 
 
-void InsetFloat::addToToc(TocBackend::TocList  toclist, Buffer const  buf) const
+void InsetFloat::addToToc(TocList  toclist, Buffer const  buf) const
 {
 	ParConstIterator pit = par_const_iterator_begin(*this);
 	ParConstIterator end = par_const_iterator_end(*this);
@@ -390,7 +388,7 @@ void InsetFloat::addToToc(TocBackend::To
 			docstring const str =
 convertdocstring(toclist[type].size() + 1)
 + .  + pit-asString(buf, false);
-			TocBackend::Item const item(pit, 0, str);
+			TocItem const item(pit, 0, str);
 			toclist[type].push_back(item);
 		}
 	}
Index: src/insets/insetbase.h
===
--- src/insets/insetbase.h	(Revision 15855)
+++ src/insets/insetbase.h	(Arbeitskopie)
@@ -36,6 +36,7 @@ class MetricsInfo;
 class Dimension;
 class PainterInfo;
 class OutputParams;
+class TocList;
 
 
 namespace graphics { class PreviewLoader; }
@@ -381,6 +382,8 @@ public:
 	 *  defaults to empty.
 	 */
 	virtual void addPreview(graphics::PreviewLoader ) const {}
+	/// Add an antry to the TocList
+	virtual void addToToc(TocList , Buffer const ) const {}
 
 public:
 	/// returns LyX code associated with the inset. Used for TOC, ...)
Index: src/insets/insetinclude.h
===
--- src/insets/insetinclude.h	(Revision 15855)
+++ src/insets/insetinclude.h	(Arbeitskopie)
@@ -92,6 +92,10 @@ public:
 	///
 	void addPreview(graphics::PreviewLoader ) const;
 	///
+	void addToToc(TocList , Buffer const ) const;
+	///
+	void updateLabels(Buffer const  buffer) const;
+	///
 	bool getStatus(LCursor , FuncRequest const , FuncStatus ) const;
 protected:
 	InsetInclude(InsetInclude const );
Index: src/insets/insetwrap.C
===
--- src/insets/insetwrap.C	(Revision 15855)
+++ src/insets/insetwrap.C	(Arbeitskopie)
@@ -28,7 +28,7 @@
 #include lyxlex.h
 #include outputparams.h
 #include paragraph.h
-#include pariterator.h
+#include TocBackend.h
 
 #include support/convert.h
 
@@ -224,7 +224,7 @@ bool InsetWrap::showInsetDialog(BufferVi
 }
 
 
-void InsetWrap::addToToc(TocBackend::TocList  toclist, Buffer const  buf) const
+void InsetWrap::addToToc(TocList  toclist, Buffer const  buf) const
 {
 	ParConstIterator pit = par_const_iterator_begin(*this);
 	ParConstIterator end = par_const_iterator_end(*this);
@@ -236,7 +236,7 @@ void InsetWrap::addToToc(TocBackend::Toc
 			docstring const str =
 convertdocstring(toclist[type].size() + 1)
 

Re: [patch] esint support

[Abdelrazak Younes]

Georg Baum wrote:

Am Samstag, 11. November 2006 03:05 schrieb Abdelrazak Younes:
I wonder if this addToToc() method is a good idea at all... I'd prefer 
the TocBackend to it himself. InsetInclude doesn't need to know how to 
do that. The same goes for InsetFloat and InsetWrap I guess.


It is a good idea IMO. Nothing outside of InsetWrap etc. should need to 
know how InsetWrap etc. works. addToToc() is a clean solution IMO: Any 
inset that has to add something to the ToC can implement it, and fill the 
list.


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


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


OK. I am not fully convinced but I don't have a strong opinion on the 
other solution anyway so we go with your solution.


Abdel.

Advice needed: Change tracking of End-Of-Par

[Michael Gerz]

Hello everybody,

I need your advice on a possibly critical issue:

Presently, LyX does not have an end-of-par character. However, for 
change tracking purposes, it is essential to track the deletion and 
insertion of paragraph breaks. Therefore, in the LyX 1.4 code (and also 
in the current 1.5 implementation), this issue is handled by tracking a 
end-of-par change at position par.size() in the Changes data structure.


There are two major implications of this approach:

(1) There is no end-of-par character in the paragraph data structure, 
only in the associated Change data structure. Accordingly,  the user 
doesn't see the  status of the end-of-par at the moment. (However, I 
think it is possible to add a simple workaround for this in Rowpainter.)


(2) If there are two unchanged paragraphs and the user removes the par 
break between them in CT mode, there is no way to merge the two pars 
while preserving the paragraph break (then marked as deleted). As a 
workaround, we do NOT merge the paragraphs but mark the end-of-par as 
deleted. Later, when the user accepts his change, the two paragraphs are 
finally merged. A consequence of this approach is that the LaTeX output 
is not fully correct as long as the change is not accepted (two pars 
instead of one). (I don't know whether this problem can be handled by 
another workaround)


To solve the above-mentioned problems in an elegant way, we need a real 
end-of-par character or inset. However, this requires substantial 
changes to the LyX core and will certainly result in temporary 
instability. I think it will me take me about two weeks to get 
everything right (given the fact that I will be very busy next week) 
whereas it will take me about 1-2 days to finalize the current solution.


Thus my question: Do you think that it is worth changing the current 
approach? Or do you think that the restriction imposed by (2) is 
acceptable from a user's perspective (After all, it may be a matter of 
how this happens).


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.


Please reply quickly - Sunday is the best day for hacking :-)

Regards,
Michael

Re: [patch] esint support

[Abdelrazak Younes]

Georg Baum wrote:

Am Samstag, 11. November 2006 03:05 schrieb Abdelrazak Younes:

Abdelrazak Younes wrote:
I wonder if this addToToc() method is a good idea at all... I'd prefer 
the TocBackend to it himself. InsetInclude doesn't need to know how to 
do that. The same goes for InsetFloat and InsetWrap I guess.
Here is a patch that does that for InsetInclude. This is cleaner IMHO 
even if the special cases in TocBackend are still ugly.


As I wrote I do not like that. I updated my version after your changes, and 
here it is. The patch lloks bigger than it really is, because most of the 
changes are renamed toc stuff. I also solved the problem of non-working 
setBuffer by switching to the existing view of the other buffer instead.
I changed the stuff in InsetInclude to not load the document anymore. That 
speeds up loading of the master a lot. Of course the included docs are now 
only shown in the navigate menu if they are already loaded by other means, 
but that is a good compromise IMO.


What is the other means? Personnally I'd like child document to be 
opened automatically; maybe a user preference setting?




I consider this now stable enough and ready for 1.5.0.


Me too. This is fine with me and there is no big risk either.

Good work.

Abdel.

Re: [patch] esint support

[Abdelrazak Younes]

Jean-Marc Lasgouttes wrote:

Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:


Abdelrazak I was partly wrong. While disabling these methods
Abdelrazak definitely helps (with the attached patch), the csrss.exe
Abdelrazak problem and the poor typing performance at the end the doc
Abdelrazak is still there. I really wonder why the slowness is only
Abdelrazak for the paragraph immediately before or after a big
Abdelrazak equation...

You mean that typing in a paragraph calls updateLabels? This should
definitely not happen IMO. We should find out why.


No, this was my initial theory but it appears that this is not the case.



One thing that is probably a big problem is the construction of macro
table by Buffer::buildMacros at each update.


I'll try to disable that to see if that helps.

Abdel.

Re: [patch] esint support

[Abdelrazak Younes]

Abdelrazak Younes wrote:

Jean-Marc Lasgouttes wrote:
Abdelrazak == Abdelrazak Younes 
[EMAIL PROTECTED] writes:


Abdelrazak I was partly wrong. While disabling these methods
Abdelrazak definitely helps (with the attached patch), the csrss.exe
Abdelrazak problem and the poor typing performance at the end the doc
Abdelrazak is still there. I really wonder why the slowness is only
Abdelrazak for the paragraph immediately before or after a big
Abdelrazak equation...

You mean that typing in a paragraph calls updateLabels? This should
definitely not happen IMO. We should find out why.


No, this was my initial theory but it appears that this is not the case.



One thing that is probably a big problem is the construction of macro
table by Buffer::buildMacros at each update.


I'll try to disable that to see if that helps.


It doesn't :-(

Abdel.

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

[Michael Gerz]

Michael Gerz wrote:

Thus my question: Do you think that it is worth changing the current 
approach? Or do you think that the restriction imposed by (2) is 
acceptable from a user's perspective (After all, it may be a matter of 
how this happens).


... how OFTEN this happens ...

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.


Please reply quickly - Sunday is the best day for hacking :-)


Michael

Re: Failed assertion in ParagraphPimpl::eraseChars()

[Michael Gerz]

Michael Gerz wrote:

 int Paragraph::Pimpl::eraseChars(pos_type start, pos_type end, bool 
trackChanges)

 {
   BOOST_ASSERT(start = 0  start = size());
   BOOST_ASSERT(end  start  end = size() + 1);

I check for end  start, because the caller of eraseChars may 
mistakenly assume that end is the last char (but in fact end - 1 is).


However, it turns out that eraseChar() is called by CutAndPaste.C 
without a prior check whether there is actually a character to delete 
(e.g. start and end are both 0).


What shall I do? Loosen the above assertion (end = start) or surround 
several calls to eraseChars by if(...) statements?


Since nobody seems to have a strong opinion on this issue, I am going to 
loosen the assertion (which looks reasonable after a few hours of sleep 
:-) )


Michael

Re: [patch] esint support

[Georg Baum]

Am Samstag, 11. November 2006 14:59 schrieb Abdelrazak Younes:
 Georg Baum wrote:
  I changed the stuff in InsetInclude to not load the document anymore. 
That 
  speeds up loading of the master a lot. Of course the included docs are 
now 
  only shown in the navigate menu if they are already loaded by other 
means, 
  but that is a good compromise IMO.
 
 What is the other means?

By typesetting it or opening it manually from the grey include button.

 Personnally I'd like child document to be  
 opened automatically; maybe a user preference setting?

Maybe, but I am not sure. Speeding up document loading would be better.


Georg

Re: problems with lyx 1.5

[Michael Gerz]

Pavel Sanda wrote:


* when opening already opened document(or document with newer backup), mouse 
pointer
 is switched into the clock, although it waits for confirmation dialog.
 


I added it to Status.15x.


* backuping works weirdly
 


A known issue.


* environments when using czech translation doesnt work: e.g.
 itemize(Polozka) - ERROR (layoutSelected): layout not found!
 


added to Status.15x.

 
* 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.



* nobody answered my previous question about meaning of these items in .po
 


#: src/lengthcommon.C:39
msgid Line Width %
(line in the sense of line of the table or row of text?)
 


Good question. Create a doc with this setting and export to LaTeX :-)

Michael

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

[Enrico Forestieri]

On Sat, Nov 11, 2006 at 02:56:23PM +0100, Michael Gerz wrote:

 Thus my question: Do you think that it is worth changing the current 
 approach? Or do you think that the restriction imposed by (2) is 
 acceptable from a user's perspective (After all, it may be a matter of 
 how this happens).

In LyX I see a changebar when I delete and end of paragraph, so I know
something changed even if I don't see what. Could the latex output be
adapted to at least show a changebar?

As regards visual feedback, in LyX the same symbol shown when breaking
a line with Ctrl-Enter could be shown crossed out at the end of the
first paragraph, and in latex something similar could be cooked and
similarly shown crossed out (thus automatically providing a changebar).

I am speaking without knowing the internals, so all I say may be nonsense.

-- 
Enrico

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

[Georg Baum]

Am Samstag, 11. November 2006 14:56 schrieb Michael Gerz:

 Thus my question: Do you think that it is worth changing the current 
 approach? Or do you think that the restriction imposed by (2) is 
 acceptable from a user's perspective (After all, it may be a matter of 
 how this happens).

I believe that a special end-of-paragraph inset will create other problems: 
It must never be placed anywhere else than at the end of a paragraph. This 
will probably require some code to ensure that. It cannot be selected by 
the user, because it is not visible. There are probably other things as 
well.

 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.

I think that the current solution is OK. The end-of-par inset may be a bit 
easier to handle in total, but I am pretty sure that it will require other 
workarounds. The workarounds for the current solution are almost all in 
place. Given the many CT bugs in 1.4 I think that the current solution is 
good enough, even if the problem (2) cannot be worked around.

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.


Georg

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

[Michael Gerz]

Enrico Forestieri wrote:


In LyX I see a changebar when I delete and end of paragraph, so I know
something changed even if I don't see what. Could the latex output be
adapted to at least show a changebar?
 

Yes, the LaTeX output shows a changebar if Show changes in output is 
activated.



As regards visual feedback, in LyX the same symbol shown when breaking
a line with Ctrl-Enter could be shown crossed out at the end of the
first paragraph,

Yes, there are various ways to represent deleted par breaks in LyX. I 
don't care about CT in LyX. It's doable.


The only critical issue is:

- There is a par break marked as deleted in the document.
- The user deactivates Show changes in output.
- The user exports to DVI/PDF.
- The user assumes that LyX has merged the paragraphs correctly
 = LyX didn't merge them in DVI/PDF output

I don't know whether this can fixed. Everything else can be handled with 
the current approach.


What do you think? Does it sound like something we have to care for?

Michael

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

[Michael Gerz]

Georg Baum wrote:

I believe that a special end-of-paragraph inset will create other problems: 
It must never be placed anywhere else than at the end of a paragraph. This 
will probably require some code to ensure that. It cannot be selected by 
the user, because it is not visible. There are probably other things as 
well.
 

This is also my feeling. It would take time to get things right. I am 
glad that you see it the same way.


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.


Michael

Re: [patch] fix math parser bug

[Georg Baum]

Am Montag, 6. November 2006 14:49 schrieb Jean-Marc Lasgouttes:

 Well, my fixes in this area were not mainly this point, and I _seem_
 to remember that I did that only because it looked nicer. So I think
 indeed that we should revert this.

I did this in 1.4 and trunk. Joost, could you please check whether the 
disappearing nucleus problem (bug 2921) is now fixed?


Georg

Offering tweaks in the GUI

[leslie . polzer]

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

-- 
gpg --keyserver pgp.mit.edu --recv-keys DD4EBF83
http://nic-nac-project.de/~skypher/


pgpvU6jAhtcZz.pgp
Description: PGP signature

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

[Enrico Forestieri]

On Sat, Nov 11, 2006 at 04:42:34PM +0100, Michael Gerz wrote:

 Enrico Forestieri wrote:
 
 In LyX I see a changebar when I delete and end of paragraph, so I know
 something changed even if I don't see what. Could the latex output be
 adapted to at least show a changebar?
   
 
 Yes, the LaTeX output shows a changebar if Show changes in output is 
 activated.

Sorry, but I don't get a changebar in the output when using the
attached file.

 As regards visual feedback, in LyX the same symbol shown when breaking
 a line with Ctrl-Enter could be shown crossed out at the end of the
 first paragraph,
 
 Yes, there are various ways to represent deleted par breaks in LyX. I 
 don't care about CT in LyX. It's doable.
 
 The only critical issue is:
 
  - There is a par break marked as deleted in the document.
  - The user deactivates Show changes in output.
  - The user exports to DVI/PDF.
  - The user assumes that LyX has merged the paragraphs correctly
   = LyX didn't merge them in DVI/PDF output
 
 I don't know whether this can fixed. Everything else can be handled with 
 the current approach.
 
 What do you think? Does it sound like something we have to care for?

This is indeed a problem, but maybe not a critical one. Given that it
is a matter of outputting a blank line or not, I can't believe it cannot
be fixed in a way or another. But, to repeat myself, I don't know the
internals, so I cannot suggest a way to do that.

Perhaps in the OutputParams class a bool merge could be added to
signal that the current paragraph should be merged with the next one?

-- 
Enrico

Re: Maximized window bug

[John Levon]

On Wed, Nov 08, 2006 at 10:58:25PM +0100, Andre Poenitz wrote:

 On Wed, Nov 01, 2006 at 02:42:19PM +, John Levon wrote:
  On Wed, Nov 01, 2006 at 03:28:29PM +0100, Peter Kümmel wrote:
  
   I've field two bugs, this
   http://www.trolltech.com/developer/task-tracker/index_html?id=119684+method=entry
   and the maximized, but they say they can't do anything, as in the docs.
  
  Yeah, I never had much luck getting Trolltech to fix their bugs either.
 
 Poor little tiger.

Hear me mew?

john

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

[Enrico Forestieri]

On Sat, Nov 11, 2006 at 06:00:35PM +0100, Enrico Forestieri wrote:

 Sorry, but I don't get a changebar in the output when using the
 attached file.

This one.

-- 
Enrico
#LyX 1.5.0svn created this file. For more info see http://www.lyx.org/
\lyxformat 253
\begin_document
\begin_header
\textclass article
\language english
\inputencoding auto
\font_roman default
\font_sans default
\font_typewriter default
\font_default_family default
\font_sc false
\font_osf false
\font_sf_scale 100
\font_tt_scale 100
\graphics default
\paperfontsize default
\papersize default
\use_geometry false
\use_amsmath 1
\cite_engine basic
\use_bibtopic false
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes true
\output_changes true
\author John Smith 
\author John Smith [EMAIL PROTECTED]
\end_header

\begin_body

\begin_layout Standard
First paragraph.
\change_deleted 1 1163260979

\end_layout

\begin_layout Standard
Second paragraph.
\end_layout

\end_body
\end_document

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

[Michael Gerz]

Enrico Forestieri wrote:


Sorry, but I don't get a changebar in the output when using the
attached file.
 


IIRC you need pplatex and dvipost.

Michael

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

[Enrico Forestieri]

On Sat, Nov 11, 2006 at 06:38:04PM +0100, Michael Gerz wrote:

 Enrico Forestieri wrote:
 
 Sorry, but I don't get a changebar in the output when using the
 attached file.
   
 
 IIRC you need pplatex and dvipost.

I have them. I see a change bar only if I make another change other
than deleting the end of paragraph.

I attach here the latex file exported from LyX. If this works for
you, I think I may have some other problem with wide streams on
cygwin.

-- 
Enrico


delpar.tex
Description: TeX document

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

[Michael Gerz]

Enrico Forestieri wrote:


I have them. I see a change bar only if I make another change other
than deleting the end of paragraph.

I attach here the latex file exported from LyX. If this works for
you, I think I may have some other problem with wide streams on
cygwin.
 


I will have look - probably tomorrow ...

Michael

[patch] image file cache

[Georg Baum]

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?


Georg
Index: src/insets/insetgraphics.C
===
--- src/insets/insetgraphics.C	(Revision 15863)
+++ src/insets/insetgraphics.C	(Arbeitskopie)
@@ -722,7 +722,9 @@ string const InsetGraphics::prepareFile(
 
 	// FIXME (Abdel 12/08/06): Is there a need to show these errors?
 	ErrorList el;
-	if (converters.convert(buf, temp_file, temp_file, from, to, el, true)) {
+	if (converters.convert(buf, temp_file, to_file, orig_file,
+	   from, to, el,
+	   Converters::try_default | Converters::try_cache)) {
 		runparams.exportdata-addExternalFile(tex_format,
 to_file, output_to_file);
 		runparams.exportdata-addExternalFile(dvi,
Index: src/insets/ExternalSupport.C
===
--- src/insets/ExternalSupport.C	(Revision 15863)
+++ src/insets/ExternalSupport.C	(Arbeitskopie)
@@ -305,14 +305,13 @@ void updateExternal(InsetExternalParams 
 	// Yes if to_file does not exist or if from_file is newer than to_file
 	if (support::compare_timestamps(temp_file, abs_to_file)  0)
 		return; // SUCCESS
-	string const to_file_base =
-		support::changeExtension(to_file, string());
 
 	// FIXME (Abdel 12/08/06): Is there a need to show these errors?
 	ErrorList el;
 	/* bool const success = */
-		converters.convert(buffer, temp_file, to_file_base,
-   from_format, to_format, el, true);
+		converters.convert(buffer, temp_file, abs_to_file,
+		   abs_from_file, from_format, to_format, el,
+		   Converters::try_default | Converters::try_cache);
 	// return success
 }
 
Index: src/exporter.C
===
--- src/exporter.C	(Revision 15863)
+++ src/exporter.C	(Arbeitskopie)
@@ -217,18 +217,20 @@ bool Exporter::Export(Buffer * buffer, s
 	}
 
 	string const error_type = (format == program)? Build : bufferFormat(*buffer);
-	bool const success = converters.convert(buffer, filename, filename,
-		backend_format, format, result_file,
+	string const ext = formats.extension(format);
+	string const tmp_result_file = changeExtension(filename, ext);
+	bool const success = converters.convert(buffer, filename,
+		tmp_result_file, buffer-fileName(), backend_format, format,
 		buffer-errorList(error_type));
 	// Emit the signal to show the error list.
 	buffer-errors(error_type);
 	if (!success)
 		return false;
 
-	if (!put_in_tempdir) {
-		string const tmp_result_file = result_file;
-		result_file = changeExtension(buffer-fileName(),
-	  formats.extension(format));
+	if (put_in_tempdir)
+		result_file = tmp_result_file;
+	else {
+		result_file = changeExtension(buffer-fileName(), ext);
 		// We need to copy referenced files (e. g. included graphics
 		// if format == dvi) to the result dir.
 		vectorExportedFile const files =
Index: src/graphics/GraphicsCacheItem.C
===
--- src/graphics/GraphicsCacheItem.C	(Revision 15863)
+++ src/graphics/GraphicsCacheItem.C	(Arbeitskopie)
@@ -16,6 +16,7 @@
 #include GraphicsConverter.h
 #include GraphicsImage.h
 
+#include ConverterCache.h
 #include debug.h
 #include format.h
 
@@ -28,7 +29,6 @@
 
 namespace lyx {
 
-using support::changeExtension;
 using support::FileMonitor;
 using support::isFileReadable;
 using support::makeDisplayPath;
@@ -108,6 +108,8 @@ public:
 	bool zipped_;
 	/// If so, store the uncompressed file in this temporary file.
 	string unzipped_filename_;
+	/// The target format
+	string to_;
 	/// What file are we trying to load?
 	string file_to_load_;
 	/** Should we delete the file after loading? True if the file is
@@ -228,6 +230,7 @@ void CacheItem::Impl::reset()
 		unlink(file_to_load_);
 	remove_loaded_file_ = false;
 	file_to_load_.erase();
+	to_.erase();
 
 	if (image_.get())
 		image_.reset();
@@ -278,6 +281,9 @@ void CacheItem::Impl::imageConverted(boo
 		return;
 	}
 
+	// Add the converted file to the file cache
+	ConverterCache::get().add(filename_, to_, file_to_load_);
+
 	loadImage();
 }
 
@@ -403,9 +409,9 @@ void CacheItem::Impl::convertToDisplayFo
 	}
 	lyxerr[Debug::GRAPHICS]
 		 \n\tThe file contains   from   format data.  endl;
-	string const to = findTargetFormat(from);
+	to_ = findTargetFormat(from);
 
-	if (from == to) {
+	if (from == to_) {
 		// No conversion needed!
 		lyxerr[Debug::GRAPHICS]  \tNo conversion needed (from == to)!  endl;
 		file_to_load_ = filename;
@@ -413,7 +419,15 @@ void 

Re: TOC-crach backtrace

[Abdelrazak Younes]

Martin Vermeer wrote:

On Fri, 10 Nov 2006 17:06:00 +0100 Abdelrazak Younes [EMAIL PROTECTED] wrote:


Martin Vermeer wrote:

On Fri, 2006-11-10 at 11:09 +0100, Jean-Marc Lasgouttes wrote:

Martin == Martin Vermeer [EMAIL PROTECTED] writes:

Martin Before going to work on this, consider the patch (for 1.4)
Martin that I submitted a while ago and may be relevant. Attached
Martin again.

Martin, I finally tested your patch! Better late than never...

It works as advertised. Please apply (with status.14x entry!) and
close the relevant bug.

So done, thanks. (What was the bug number? Don't find it.) Should

this

go into 1.5 too?

* src/toc.C
(outline): Fix undo bug in TOC navigation

If it is a fix, why not?

Abdel.


Is the code base still close enough? I remember you did things there.


yes, I didn't touch the contents of outline at all.

Abdel.

Re: citation dialog

[Alfredo Braunstein]

Georg Baum wrote:

> Am Donnerstag, 9. November 2006 16:09 schrieb Jean-Marc Lasgouttes:
>> > "Alfredo" == Alfredo Braunstein
>> > <[EMAIL PROTECTED]> writes:
>> 
>> Alfredo> PS: there's a surprising (good) amount of activity on this
>> Alfredo> list!
>> 
>> Hello Alfredo,
>> 
>> Do you feel like coming back to have fun with us?
> 
> That would be great!

Hello Jean-Marc, hello Georg!

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!

A/

Re: New Mac Profile

[Andre Poenitz]

On Tue, Oct 31, 2006 at 09:36:49PM +0100, Abdelrazak Younes wrote:
> Bennett Helm wrote:
> >On Oct 31, 2006, at 12:23 PM, Andreas Vox wrote:
> 
> >I didn't save the old profile, so I've created a new one. The screenshot 
> >can be found here:
> >
> >
> 
> Hum... That's what I feared. We have eliminated all important 
> bottlenecks in LyX. Remains the Qt ones. I don't understand why the 
> QPainter::drawText() is so slow on Mac.
> 
> There's maybe some Mac specific settings that we should set to speed up 
> things. Maybe limit the number of colors to 256 or something like that...
> 
> Some googling is in order.

Why not asking on [EMAIL PROTECTED]

Andre'

Re: About New TabBar and Multiple-Windows

[Andre Poenitz]

On Wed, Nov 01, 2006 at 09:39:02PM +0100, Joost Verburg wrote:
> Lars Gullik Bjønnes wrote:
> >We have a filesystem...
> >Filesystems are shared between computers...
> >Computer have users...
> >Users run LyX...
> >LyX loads the same file...
> 
> LyX can set a write lock on open files.

How?

NFS locking is notorious for working only on Fridays when the moon is
full.

> There are indeed two options:
> 
> 1) Display an error message when the file is already opened by another 
> LyX process.

How do you know that a file is opened by a process in a portable manner?

> It will be impossible to know which windows have the data 
> of the document (they all look the same independent of the process).
> 2) Use a single process by default so users will automatically get a new 
> view with the right contents.
> 
> Option 2 is definitely more user-friendly.

As in "can't run batch converters anymore just because someone views a
lyx file"?

Andre'

Re: [Cvslog] r15792 - in /lyx-devel/trunk/src: BufferView.C frontends/...

[Andre Poenitz]

On Tue, Nov 07, 2006 at 09:31:35PM -, [EMAIL PROTECTED] wrote:
> Author: alstrup
> Date: Tue Nov  7 22:31:33 2006
> New Revision: 15792
> 
> URL: http://www.lyx.org/trac/changeset/15792
> Log:
> - Avoid lyxerr[] like the plague. Use if (lyxerr.debugging( ... )) instead.
> 
> Modified:
> lyx-devel/trunk/src/BufferView.C
> lyx-devel/trunk/src/frontends/WorkArea.C
> lyx-devel/trunk/src/rowpainter.C
> lyx-devel/trunk/src/text.C
> 
> Modified: lyx-devel/trunk/src/BufferView.C
> URL: http://www.lyx.org/trac/file/lyx-devel/trunk/src/BufferView.C?rev=15792
> ==
> --- lyx-devel/trunk/src/BufferView.C (original)
> +++ lyx-devel/trunk/src/BufferView.C Tue Nov  7 22:31:33 2006
> @@ -355,7 +355,9 @@
>   if (!buffer_)
>   return false;
>  
> - lyxerr[Debug::WORKAREA] << "BufferView::update" << std::endl;
> + if (lyxerr.debugging(Debug::WORKAREA)) {
> + lyxerr[Debug::WORKAREA] << "BufferView::update" << std::endl;
> + }

Isn't that equivalent to

 +  if (lyxerr.debugging(Debug::WORKAREA)) {
 +  lyxerr << "BufferView::update" << std::endl;
 +  }

?

Apart from that lyxerr usage is one of the places where I'd prefer real
macros using __FILE__ and __LINE__ that could be used for 'one-click-
navigation'.

#define LYXERR(channel, msg) \
if (!lyxerr.debugging(channel)) \
; \
else \
lyxerr << __FILE__ << "(" << __LINE__ << "): " << msg << 
std::endl

and

 LYXERR(Debug::WORKAREA, "BufferView::update");

would do for starters.

Less clutter in the source, faster execution if the message is not shown
and more useful information if it is shown. Pretty much a win-win-win
situation.

Andre'

Re: [patch] Fix writing a space after a latex macro

[Andre Poenitz]

On Mon, Oct 30, 2006 at 08:03:56PM +0100, Enrico Forestieri wrote:
> On Mon, Oct 30, 2006 at 07:49:46PM +0100, Georg Baum wrote:
> 
> > Am Montag, 30. Oktober 2006 19:17 schrieb Enrico Forestieri:
> > > The attached patch fixes the \sinx problem.
> > 
> > Good that you found it.
> > 
> > > Any objections to applying it? 
> > 
> > Yes. isAlpha() should be implemented as an ucs4 function, and if a hack is 
> > needed it should be done inside this function.
> 
> An hack? What do you mean?
> 
> > Then I would also like to know why this problem was introduced. Probably 
> > not by removing the code you just added (or was it done by accident?).
> 
> Probably by adding the overloaded << operator and not taking the appropriate
> actions. Last week it was really difficult to follow all changes...
> 
> > Are 
> > you sure that you do not trigger another problem that was to be solved by 
> > the patch that created the \sinx problem?
> 
> No, I am not sure of anything, but I can't see what problem could be
> introduced. The \sinx problem was introduced by overlooking, IMO.

No, probably when converting the math parser to unicode.

Andre'

Re: New Mac Profile

[Andre Poenitz]

On Wed, Nov 01, 2006 at 11:03:18AM +0100, Abdelrazak Younes wrote:
> The nice thing about it is that we draw directly on screen thus 
> eliminating the transfer of the old backing pixmap onto the screen.
> On the other hand, the screen estate is not saved. This means that, if 
> part of the WorkArea is masked, the widget will receive a paint Event 
> and everything will be redrawn, not only the part that is not masked.

Stuff like that (parts of windows hidden behind others) is usually taken
care of by the system.

I'd be really surprised if any windowing system from this millenium
would actively send draw requests to the application just because some
window is moving in front of it.

I'd rather suspect we are sending an update() somewhere ourselves.

> >Confirmed, sort of (there may be several redraws per keypress)
> 
> Yes, the number of lyx-redraws depend now on the number of Qt 
> paintEvent(). paintEvent() can be triggered by other thing than 
> WorkArea::redraw().

It will be triggered by an update() (or sequence of updtes() for that
matter). I would like to see a situation where paintEvent() is called
without us actively calling update() (or doing 'obvious' stuff, like
showing the widget for the first time...)

Andre'

Re: About New TabBar and Multiple-Windows

[Andre Poenitz]

On Wed, Nov 01, 2006 at 09:04:51PM +0100, Jean-Marc Lasgouttes wrote:
> > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
> 
> | In LyX 1.4 there is one window per process. However now one process 
> | can have multiple windows, there should only be one running process.
> 
> Lars> I don't get this logic.
> 
> Let's say we should use the same instance by default (to avoid
> surprises), but there should be a way to launch a new instance.

Could anybody elaborte on the practical side how such an 'instance
singleton' would be implemented?

Maybe with home dir and LyX itself on NFS shares?

And maybe while retaining the possibility to use LyX in batchmode?

Andre'

Re: Movable toolbars

[Andre Poenitz]

On Wed, Nov 01, 2006 at 08:43:19AM +1800, Bo Peng wrote:
> >I've just enabled it.
> >
> 
> Then, it makes sense to save toolbar position in session. Could you
> please tell me the functions to get/set toolbar position? Note that
> the interface has to be done independent of frontend.

Why don't you simply declare toolbars a GUI issue and use
QMainWindow::{save,restore}State?

Andre'

Re: [patch] xymatrix

[Andre Poenitz]

On Mon, Oct 30, 2006 at 10:04:15PM +0100, Georg Baum wrote:
> This patch makes it possible to read and write all \xymatrix commands. 
> There is no UI, meaning it is not possible to enter the extended commands 
> in mathed other than copying the pure LaTeX from outside of LyX or texted, 
> and you cannot see the aditional arguments on screen other than in the 
> status line.

Nice.

Andre'

Re: [Patch] optimize utf8_to_ucs4

[Andre Poenitz]

On Mon, Oct 30, 2006 at 08:49:36PM +0100, Joost Verburg wrote:
> Georg Baum wrote:
> >OK, so it is like that: Up to 4 bytes per code point are used for the 
> >currently defined 21 bits of UCS4, but UTF8 is designed in such a way that 
> >it is possible to encode all 36 bits of UCS4 with at most 6 bytes per code 
> >point.
> 
> Not really. Some years ago there was not yet a real limit in the Unicode 
> specification for the number of code points (the theoretical limit was 
> 2^31 if I remember correctly).
> 
> However, the limit has now been set to 2^20+2^16 code points. There is 
> still a lot of space available, but there will _never_ be any more code 
> points than 2^20+2^16 (also not in UCS-4!).

Roughly a million characters does not sound as overly excessive when
there are languages using several thousands of them already...

Andre'

Re: [Updated PATCH] session/toolbar.

[Andre Poenitz]

On Thu, Nov 02, 2006 at 12:37:41PM +1800, Bo Peng wrote:
> >> The major problem is with
> >> math/review/table toolbars. The logic is now:
> >>
> >> 1. if math is on when lyx exists, I assume it is always on
> >> 2. if math is off when lyx exists, I assume it is auto.
> >
> >But now it does not remember the position of the moved auto toolbars.
> 
> Because auto toolbars are not visible when lyx closes! How can I get
> their location if they are not visible? (I guess your previous patch
> does this?)

show them while you are shutting down.

Andre'

Re: About New TabBar and Multiple-Windows

[Andre Poenitz]

On Wed, Nov 01, 2006 at 08:11:11PM +0100, Joost Verburg wrote:
> José Matos wrote:
> >  What is the difference to what we have now?
> >
> >  Why don't we see people complaining about that?
> 
> In LyX 1.4 there is one window per process. However now one process can 
> have multiple windows, there should only be one running process.

I'd rather have only one window per process. This could have mutliple
buffers arranged in a tabbed widget or such.

Andre'

Re: [Cvslog] r15630 - in /lyx-devel/trunk: INSTALL development/TodoPla...

[Andre Poenitz]

On Mon, Oct 30, 2006 at 09:45:38PM -, [EMAIL PROTECTED] wrote:
> +++ lyx-devel/trunk/src/frontends/qt4/GuiFontLoader.C Mon Oct 30 22:45:37 2006
> @@ -141,7 +141,6 @@
>   return true;
>   }
>  
> - // Qt 3.2 beta1 returns "xft" for all xft fonts
>   // Qt 4.1 returns "Multi" for all ? xft fonts
>   if (font.rawName() == "xft" || font.rawName() == "Multi") {
>   if (contains(fromqstr(fi.family()), family)) {

So when can a font.rawName() be "xft" nowadays?

Andre'

Re: About New TabBar and Multiple-Windows

[Andre Poenitz]

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

Re: Maximized window bug

[Andre Poenitz]

On Wed, Nov 01, 2006 at 02:42:19PM +, John Levon wrote:
> On Wed, Nov 01, 2006 at 03:28:29PM +0100, Peter Kümmel wrote:
> 
> > I've field two bugs, this
> > http://www.trolltech.com/developer/task-tracker/index_html?id=119684+=entry
> > and the maximized, but they say they can't do anything, as in the docs.
> 
> Yeah, I never had much luck getting Trolltech to fix their bugs either.

Poor little tiger.

Andre'

Re: About New TabBar and Multiple-Windows

[Andre Poenitz]

On Wed, Nov 01, 2006 at 09:18:53PM +0100, Joost Verburg wrote:
> Abdelrazak Younes wrote:
> >>I can explain you how it works on Windows,
> >
> >Yes please.
> 
> You can use a mutex to detect the running process and a window message 
> to have the existing process start a new document.

Windows has system-global mutexes. A very limited number for that
matter. And you btter make really sure your app releases them even
when it dies unexpectedly.

Unix does not have that. I doubt Macs have that.

Andre'

Re: Movable toolbars

[Andre Poenitz]

On Tue, Oct 31, 2006 at 03:30:43PM +, John Levon wrote:
> On Tue, Oct 31, 2006 at 03:22:34PM +, José Matos wrote:
> 
> > On Tuesday 31 October 2006 2:43 pm, John Levon wrote:
> > > On Tue, Oct 31, 2006 at 03:42:32PM +0100, Peter Kümmel wrote:
> > > > I've just enabled it.
> > >
> > > Nice :(
> > 
> >   Could you elaborate, please?
> > 
> >   The switch is simple, and we can change it at any time. :-)
> 
> That it just happened without discussion of whether it makes sense,
> unlike when I disabled it, when I actually asked people?

People expect that from a Qt application, no matter whether it makes
sense or not.

And it is completely invisble to people that do not try to move toolbars
anyway.

Andre'

Re: About New TabBar and Multiple-Windows

[Andre Poenitz]

On Wed, Nov 01, 2006 at 06:48:33PM +0100, Enrico Forestieri wrote:
> On Wed, Nov 01, 2006 at 06:25:05PM +0100, Joost Verburg wrote:
> 
> > Peter Kümmel wrote:
> > > I don't understand why we need this new Window feature.
> > > If someone wants two top level LyX programs then he could
> > > start LyX twice.
> > 
> > Sometimes you want to edit to same document in two places. However now 
> > we have this multiple window feature, it should not be possible anymore 
> > to start multiple LyX instances.
> 
> Unless specifically requested. I have your word that I can have
> that option ;-)

And that option will be named  'lyx & ; lyx &'

Andre'

Re: [Cvslog] r15728 - /lyx-devel/trunk/src/mathed/MathParser.C

[Andre Poenitz]

On Sun, Nov 05, 2006 at 09:33:42PM +0100, Herbert Voss wrote:
> Georg Baum schrieb:
> > Am Sonntag, 5. November 2006 19:22 schrieb Herbert Voss:
> >> I am interested in seeing how someone will parse a tex source, where
> >> _every_ macro or environment can be hide after several other macros
> >> or catcode changes ...
> > 
> > Impossible IMHO. It is possible to create a tex2lyx that works perfectly 
> > for most _usual_ documents (no catcode games, no redefinition of standard 
> > macros with different semantics), and tex2lyx is in some areas close to 
> > that, but if you consider changed catcodes and macros you get a real mess.
> 
> Every thesis without catcode stuff has a _lot_ of redefinitions in the
> preamble. As I said, it is lost time and work for such a converter
> which will only work for some (short) documents ... and it confuses
> the users, when there is a tex2lyx, which works sometimes ...

Better a half-working tex2lyx than no way to import LaTeX at all.

Andre'

Re: About New TabBar and Multiple-Windows

[Andre Poenitz]

On Wed, Nov 01, 2006 at 07:11:34PM +0100, Joost Verburg wrote:
> Lars Gullik Bjønnes wrote:
> >| Sometimes you want to edit to same document in two places. However now
> >| we have this multiple window feature, it should not be possible
> >| anymore to start multiple LyX instances. Can someone take a look at
> >| this?
> >
> >Why?
> 
> It does not make sense to allow multiple instances when each instance 
> can also have multiple windows. There is no way to tell which window 
> belongs to which instance and therefore you can easily loose data by 
> saving the wrong version of a document.

There are many good reasons.

For one: if one instance crashes I have still the others active.
For two: You can't implement it properly.
For three: Multiple 'big' windows per application are bad per se,
so if you don't use them, you won't run into the problem you mentioned.
Even Microsoft changed its attitude here.

Andre'

Re: [Cvslog] r15791 - in /lyx-devel/trunk/src: frontends/FontMetrics.h...

[Andre Poenitz]

On Tue, Nov 07, 2006 at 08:46:40PM -, [EMAIL PROTECTED] wrote:
> Author: baum
> Date: Tue Nov  7 21:46:38 2006
> New Revision: 15791
> 
> URL: http://www.lyx.org/trac/changeset/15791
> Log:
> document docstring abuse for symbol font code points

I wonder whether a 'drawSymbol' function would not have been 
better documentation...

Andre'

Re: r15615 - in /lyx-devel/trunk/src: insets/insettabular.C m...

[Andre Poenitz]

On Mon, Oct 30, 2006 at 02:41:15PM +0100, Georg Baum wrote:
> Yes, that was the reason for similar problems in the past, but I could not
> find any undefined virtual method. Are we all blind? BTW Abdel your latest
> patch does not help either (although callinf the Painter() constructor is a
> good idea anyway).

Could you elaborate on why this can make a difference?

Andre'

Re: About New TabBar and Multiple-Windows

[Andre Poenitz]

On Wed, Nov 01, 2006 at 06:25:05PM +0100, Joost Verburg wrote:
> Peter Kümmel wrote:
> >I don't understand why we need this new Window feature.
> >If someone wants two top level LyX programs then he could
> >start LyX twice.
> 
> Sometimes you want to edit to same document in two places. However now 
> we have this multiple window feature, it should not be possible anymore 
> to start multiple LyX instances. Can someone take a look at this?

Rest assured that I will try my best to immediately revert any patch
that tries to remove my ability to start mulitple instances of LyX.

Andre'

Re: About New TabBar and Multiple-Windows

[Andre Poenitz]

On Wed, Nov 01, 2006 at 07:05:34PM +0100, Abdelrazak Younes wrote:
> Joost Verburg wrote:
> >Abdelrazak Younes wrote:
> >>>Sometimes you want to edit to same document in two places. However 
> >>>now we have this multiple window feature, it should not be possible 
> >>>anymore to start multiple LyX instances. Can someone take a look at 
> >>>this?
> >>
> >>Could you post again the code to do so?
> >
> >I can explain you how it works on Windows,
> 
> Yes please.
> 
> >I don't know about UNIX. Or 
> >does Qt provide some generic method?
> 
> No but KDE does AFAIR. It's called KUniqueApplication or something like 
> that. We could borrow some of their code.

Why the f*** do you want to cripple LyX?

These 'single instance' applications are a major pain (and never really
work well) in a distributed environment. Windows has system-global
entities to lock stuff, but it is essentially a single-user,
non-network transparent OS that can live with blocking stuff as the
single user is usually blocking only himself. This does not work on *nix
(and it doesn't even work properly on Windows terminal server either)

Andre'

-- 

Re: Movable toolbars

[Andre Poenitz]

On Tue, Oct 31, 2006 at 03:51:44PM +0100, Peter Kümmel wrote:
> José Matos wrote:
> > GuiView.C:78: error: ISO C++ forbids declaration of 'QTabBar' with no type
> 
> I've added the include of QTabBar.
> Does this help?
> 
> Maybe I should remove the Qt headers from the precompiled msvc-headers.

Why?

The speedup is significant.

Andre'

Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)

[Andre Poenitz]

On Thu, Nov 02, 2006 at 01:34:20PM +0100, Peter Kümmel wrote:
> Thanks Abdel, this is very good. We should add it some where in the wiki.

And to the code somewhere. Perhaps BufferView.C with pointers from
buffer and LyXView.

Andre'

Re: [Cvslog] r15728 - /lyx-devel/trunk/src/mathed/MathParser.C

[Andre Poenitz]

On Sun, Nov 05, 2006 at 04:00:39PM +0100, Abdelrazak Younes wrote:
> Enrico Forestieri wrote:
> >On Sun, Nov 05, 2006 at 09:58:28AM +0100, Georg Baum wrote:
> >>>I think that we should leave the 256, but if you and others don't agree,
> >>>then please also make the corresponding changes to texparser.C
> >>Abdel is right that a table of 256 is not needed, since we never set the 
> >>catcode of any character above 256 to something else than 256, and we 
> >>need the if anyway. I have changed the comment accordingly, but if 
> >>anybody else prefers 256 I have no problem with that either.
> >
> >I am trying to say that, currently, LyX is not correctly tracking catcodes
> >and if we want to improve on that, then we should maintain the 256.
> >
> >As an example, try importing in LyX the attached valid latex file and you
> >will see what I mean. This is a bug, IMO.
> 
> Are you saying that it is allowed to create new catcodes in a latex file?

You can redefine them.

Andre'

Re: About New TabBar and Multiple-Windows

[Abdelrazak Younes]

Andre Poenitz wrote:

On Wed, Nov 01, 2006 at 08:11:11PM +0100, Joost Verburg wrote:

José Matos wrote:

 What is the difference to what we have now?

 Why don't we see people complaining about that?
In LyX 1.4 there is one window per process. However now one process can 
have multiple windows, there should only be one running process.


I'd rather have only one window per process. This could have mutliple
buffers arranged in a tabbed widget or such.


I agree that on Windows, Single-window and Multi-WorkArea (via tabbed 
widget and/or split windows) is the best idea. Once this is done, we can 
remove multi-window support. But on X11, I insist that we should support 
 multi-windows.


Abdel.

Re: [patch] esint support

[Jean-Marc Lasgouttes]

> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:

Abdelrazak> I was partly wrong. While disabling these methods
Abdelrazak> definitely helps (with the attached patch), the csrss.exe
Abdelrazak> problem and the poor typing performance at the end the doc
Abdelrazak> is still there. I really wonder why the slowness is only
Abdelrazak> for the paragraph immediately before or after a big
Abdelrazak> equation...

You mean that typing in a paragraph calls updateLabels? This should
definitely not happen IMO. We should find out why.

One thing that is probably a big problem is the construction of macro
table by Buffer::buildMacros at each update.

JMarc

Re: [Cvslog] r15791 - in /lyx-devel/trunk/src: frontends/FontMetrics.h...

[Georg Baum]

Am Mittwoch, 8. November 2006 21:37 schrieb Andre Poenitz:
> On Tue, Nov 07, 2006 at 08:46:40PM -, [EMAIL PROTECTED] wrote:
> > Author: baum
> > Date: Tue Nov  7 21:46:38 2006
> > New Revision: 15791
> > 
> > URL: http://www.lyx.org/trac/changeset/15791
> > Log:
> > document docstring abuse for symbol font code points
> 
> I wonder whether a 'drawSymbol' function would not have been 
> better documentation...

Yes, I thought about that. I did not do it, because you would need several 
ones (in mathed and frontend, and also for metrics), the code would be 
exactly identical to the existing methods, and you would need to introduce 
a switch in InsetMathSymbol that decides whether to use drawSymbol or 
drawText (which both would do the same). That did not look like a good 
solution to me and prone to somebody doing some "cleanup".
A real solution would probably use two different insets for real symbols 
(drawn with symbol fonts) and functions and unknown symbols, but I did not 
want to do that at this time.


Georg

Re: r15615 - in /lyx-devel/trunk/src: insets/insettabular.C m...

[Georg Baum]

Am Mittwoch, 8. November 2006 19:18 schrieb Andre Poenitz:
> On Mon, Oct 30, 2006 at 02:41:15PM +0100, Georg Baum wrote:
> > Yes, that was the reason for similar problems in the past, but I could 
not
> > find any undefined virtual method. Are we all blind? BTW Abdel your 
latest
> > patch does not help either (although callinf the Painter() constructor 
is a
> > good idea anyway).
> 
> Could you elaborate on why this can make a difference?

I probably mixed that up with calling the copy constructor of a base class.


Georg

Re: [patch] esint support

[Georg Baum]

Am Freitag, 10. November 2006 22:39 schrieb Abdelrazak Younes:
> Because the plan is to move toc.[Ch] altogether. We can then rename 
> TocBackend to something else if you want.

I don't care about the name as long as the code speaks for itself.

> > I do neither understand why TocBackend is not in namespace toc.
> 
> Could be indeed. But we decided that we will only do lyx and 
> lyx::support and lyx::frontend from now on, didn't we?

I did not notice that, but in that case nothing should be in that 
namespace. I am not picky about namespaces in general, the important thing 
for me is that there is some logic in the naming.

> TocBackend. The typedefs are just there because of API compatibility 
> issue; see my other mail.

I understand that now, but it took me some time. If you do something like 
this the next time please add some comments.


Georg

Re: TOC-crach backtrace

[Martin Vermeer]

On Fri, 10 Nov 2006 17:06:00 +0100 Abdelrazak Younes <[EMAIL PROTECTED]> wrote:

> Martin Vermeer wrote:
> > On Fri, 2006-11-10 at 11:09 +0100, Jean-Marc Lasgouttes wrote:
> >>> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
> >> Martin> Before going to work on this, consider the patch (for 1.4)
> >> Martin> that I submitted a while ago and may be relevant. Attached
> >> Martin> again.
> >>
> >> Martin, I finally tested your patch! Better late than never...
> >>
> >> It works as advertised. Please apply (with status.14x entry!) and
> >> close the relevant bug.
> > 
> > So done, thanks. (What was the bug number? Don't find it.) Should
> this
> > go into 1.5 too?
> > 
> > * src/toc.C
> > (outline): Fix undo bug in TOC navigation
> 
> If it is a fix, why not?
> 
> Abdel.

Is the code base still close enough? I remember you did things there.

- Martin

Re: [patch] esint support

[Georg Baum]

Am Samstag, 11. November 2006 03:05 schrieb Abdelrazak Younes:
> > I wonder if this addToToc() method is a good idea at all... I'd prefer 
> > the TocBackend to it himself. InsetInclude doesn't need to know how to 
> > do that. The same goes for InsetFloat and InsetWrap I guess.

It is a good idea IMO. Nothing outside of InsetWrap etc. should need to 
know how InsetWrap etc. works. addToToc() is a clean solution IMO: Any 
inset that has to add something to the ToC can implement it, and fill the 
list.

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

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


Georg

Re: [patch] Allow unicode labels in layout files

[Georg Baum]

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?

Oops, forgot the patch. This one is now going in, if the addtitional 
translations are wrong please shout.


Georg
Index: src/text2.C
===
--- src/text2.C	(Revision 15853)
+++ src/text2.C	(Arbeitskopie)
@@ -352,7 +352,7 @@ void LyXText::setLayout(Buffer const & b
 	for (pit_type pit = start; pit != end; ++pit) {
 		pars_[pit].applyLayout(lyxlayout);
 		if (lyxlayout->margintype == MARGIN_MANUAL)
-			pars_[pit].setLabelWidthString(lyxlayout->labelstring());
+			pars_[pit].setLabelWidthString(buffer.translateLabel(lyxlayout->labelstring()));
 	}
 }
 
@@ -604,7 +604,7 @@ docstring LyXText::getStringToIndex(LCur
 
 void LyXText::setParagraph(LCursor & cur,
 			   Spacing const & spacing, LyXAlignment align,
-			   string const & labelwidthstring, bool noindent)
+			   docstring const & labelwidthstring, bool noindent)
 {
 	BOOST_ASSERT(cur.text());
 	// make sure that the depth behind the selection are restored, too
@@ -628,8 +628,7 @@ void LyXText::setParagraph(LCursor & cur
 			else
 params.align(align);
 		}
-		// FIXME UNICODE
-		par.setLabelWidthString(from_ascii(labelwidthstring));
+		par.setLabelWidthString(labelwidthstring);
 		params.noindent(noindent);
 	}
 }
Index: src/buffer.C
===
--- src/buffer.C	(Revision 15853)
+++ src/buffer.C	(Arbeitskopie)
@@ -1445,6 +1445,18 @@ docstring const Buffer::B_(string const 
 }
 
 
+docstring const Buffer::translateLabel(docstring const & label) const
+{
+	if (support::isAscii(label))
+		// Probably standard layout, try to translate
+		return B_(to_ascii(label));
+	else
+		// This must be a user defined layout. We can not translate
+		// this, since gettext accepts only ascii keys.
+		return label;
+}
+
+
 bool Buffer::isClean() const
 {
 	return pimpl_->lyx_clean;
Index: src/lyxtext.h
===
--- src/lyxtext.h	(Revision 15854)
+++ src/lyxtext.h	(Arbeitskopie)
@@ -260,7 +260,7 @@ public:
 	void setParagraph(LCursor & cur,
 			  Spacing const & spacing,
 			  LyXAlignment align,
-			  std::string const & labelwidthstring,
+			  docstring const & labelwidthstring,
 			  bool noindent);
 
 	/* these things are for search and replace */
Index: src/buffer.h
===
--- src/buffer.h	(Revision 15853)
+++ src/buffer.h	(Arbeitskopie)
@@ -170,6 +170,8 @@ public:
 	Language const * getLanguage() const;
 	/// get l10n translated to the buffers language
 	docstring const B_(std::string const & l10n) const;
+	/// translate \p label to the buffer language if possible
+	docstring const translateLabel(docstring const & label) const;
 
 	///
 	int runChktex();
Index: src/support/lstrings.C
===
--- src/support/lstrings.C	(Revision 15853)
+++ src/support/lstrings.C	(Arbeitskopie)
@@ -279,6 +279,16 @@ int hexToInt(docstring const & str)
 }
 
 
+bool isAscii(docstring const & str)
+{
+	int const len = str.length();
+	for (int i = 0; i < len; ++i)
+		if (str[i] >= 0x80)
+			return false;
+	return true;
+}
+
+
 char lowercase(char c)
 {
 	return char(tolower(c));
Index: src/support/lstrings.h
===
--- src/support/lstrings.h	(Revision 15853)
+++ src/support/lstrings.h	(Arbeitskopie)
@@ -72,6 +72,9 @@ bool isHex(lyx::docstring const & str);
 
 int hexToInt(lyx::docstring const & str);
 
+/// is \p str pure ascii?
+bool isAscii(docstring const & str);
+
 ///
 char lowercase(char c);
 
Index: src/text3.C
===
--- src/text3.C	(Revision 15854)
+++ src/text3.C	(Arbeitskopie)
@@ -1411,7 +1411,7 @@ void LyXText::dispatch(LCursor & cur, Fu
 			}
 
 			setLayout(cur, tclass.defaultLayoutName());
-			setParagraph(cur, Spacing(), LYX_ALIGN_LAYOUT, string(), 0);
+			setParagraph(cur, Spacing(), LYX_ALIGN_LAYOUT, docstring(), 0);
 			insertInset(cur, new InsetFloatList(to_utf8(cmd.argument(;
 			cur.posRight();
 		} else {
@@ -1455,11 +1455,10 @@ void LyXText::dispatch(LCursor & cur, Fu
 		lex.setStream(is);
 		ParagraphParameters params;
 		params.read(lex);
-		// FIXME UNICODE
 		setParagraph(cur,
 			 params.spacing(),
 			 params.align(),
-			 to_ascii(params.labelWidthString()),
+			 params.labelWidthString(),
 			 params.noindent());
 		cur.message(_("Paragraph layout set"));
 		break;

Re: [patch] esint support

[Georg Baum]

Am Samstag, 11. November 2006 03:05 schrieb Abdelrazak Younes:
> Abdelrazak Younes wrote:
> > I wonder if this addToToc() method is a good idea at all... I'd prefer 
> > the TocBackend to it himself. InsetInclude doesn't need to know how to 
> > do that. The same goes for InsetFloat and InsetWrap I guess.
> 
> Here is a patch that does that for InsetInclude. This is cleaner IMHO 
> even if the special cases in TocBackend are still ugly.

As I wrote I do not like that. I updated my version after your changes, and 
here it is. The patch lloks bigger than it really is, because most of the 
changes are renamed toc stuff. I also solved the problem of non-working 
setBuffer by switching to the existing view of the other buffer instead.
I changed the stuff in InsetInclude to not load the document anymore. That 
speeds up loading of the master a lot. Of course the included docs are now 
only shown in the navigate menu if they are already loaded by other means, 
but that is a good compromise IMO.

I consider this now stable enough and ready for 1.5.0. What do you think 
José? And what about the esint stuff?


Georg
Index: src/buffer_funcs.h
===
--- src/buffer_funcs.h	(Revision 15855)
+++ src/buffer_funcs.h	(Arbeitskopie)
@@ -58,17 +58,17 @@ lyx::docstring expandLabel(Buffer const 
 /**
 A full updateLabels(Buffer const &) will be called if not possible.
 */
-void updateLabels(Buffer const & buf, ParIterator & it);
+void updateLabels(Buffer const & buf, ParIterator & it, bool childonly = false);
 
 /// update labels between "from" and "to" if possible.
 /**
 A full updateLabels(Buffer const &) will be called if not possible.
 */
 void updateLabels(Buffer const & buf,
-	ParIterator & from, ParIterator & to);
+	ParIterator & from, ParIterator & to, bool childonly = false);
 
 /// updates all counters
-void updateLabels(Buffer const &);
+void updateLabels(Buffer const &, bool childonly = false);
 
 
 } // namespace lyx
Index: src/insets/insetfloat.C
===
--- src/insets/insetfloat.C	(Revision 15855)
+++ src/insets/insetfloat.C	(Arbeitskopie)
@@ -29,13 +29,11 @@
 #include "lyxlex.h"
 #include "outputparams.h"
 #include "paragraph.h"
-#include "pariterator.h"
+#include "TocBackend.h"
 
 #include "support/lstrings.h"
 #include "support/convert.h"
 
-#include 
-
 
 namespace lyx {
 
@@ -378,7 +376,7 @@ void InsetFloat::sideways(bool s, Buffer
 }
 
 
-void InsetFloat::addToToc(TocBackend::TocList & toclist, Buffer const & buf) const
+void InsetFloat::addToToc(TocList & toclist, Buffer const & buf) const
 {
 	ParConstIterator pit = par_const_iterator_begin(*this);
 	ParConstIterator end = par_const_iterator_end(*this);
@@ -390,7 +388,7 @@ void InsetFloat::addToToc(TocBackend::To
 			docstring const str =
 convert(toclist[type].size() + 1)
 + ". " + pit->asString(buf, false);
-			TocBackend::Item const item(pit, 0, str);
+			TocItem const item(pit, 0, str);
 			toclist[type].push_back(item);
 		}
 	}
Index: src/insets/insetbase.h
===
--- src/insets/insetbase.h	(Revision 15855)
+++ src/insets/insetbase.h	(Arbeitskopie)
@@ -36,6 +36,7 @@ class MetricsInfo;
 class Dimension;
 class PainterInfo;
 class OutputParams;
+class TocList;
 
 
 namespace graphics { class PreviewLoader; }
@@ -381,6 +382,8 @@ public:
 	 *  defaults to empty.
 	 */
 	virtual void addPreview(graphics::PreviewLoader &) const {}
+	/// Add an antry to the TocList
+	virtual void addToToc(TocList &, Buffer const &) const {}
 
 public:
 	/// returns LyX code associated with the inset. Used for TOC, ...)
Index: src/insets/insetinclude.h
===
--- src/insets/insetinclude.h	(Revision 15855)
+++ src/insets/insetinclude.h	(Arbeitskopie)
@@ -92,6 +92,10 @@ public:
 	///
 	void addPreview(graphics::PreviewLoader &) const;
 	///
+	void addToToc(TocList &, Buffer const &) const;
+	///
+	void updateLabels(Buffer const & buffer) const;
+	///
 	bool getStatus(LCursor &, FuncRequest const &, FuncStatus &) const;
 protected:
 	InsetInclude(InsetInclude const &);
Index: src/insets/insetwrap.C
===
--- src/insets/insetwrap.C	(Revision 15855)
+++ src/insets/insetwrap.C	(Arbeitskopie)
@@ -28,7 +28,7 @@
 #include "lyxlex.h"
 #include "outputparams.h"
 #include "paragraph.h"
-#include "pariterator.h"
+#include "TocBackend.h"
 
 #include "support/convert.h"
 
@@ -224,7 +224,7 @@ bool InsetWrap::showInsetDialog(BufferVi
 }
 
 
-void InsetWrap::addToToc(TocBackend::TocList & toclist, Buffer const & buf) const
+void InsetWrap::addToToc(TocList & toclist, Buffer const & buf) const
 {
 	ParConstIterator pit = par_const_iterator_begin(*this);
 	ParConstIterator end = par_const_iterator_end(*this);
@@ -236,7 +236,7 @@ void InsetWrap::addToToc(TocBackend::Toc
 			docstring 

Re: [patch] esint support

[Abdelrazak Younes]

Georg Baum wrote:

Am Samstag, 11. November 2006 03:05 schrieb Abdelrazak Younes:
I wonder if this addToToc() method is a good idea at all... I'd prefer 
the TocBackend to it himself. InsetInclude doesn't need to know how to 
do that. The same goes for InsetFloat and InsetWrap I guess.


It is a good idea IMO. Nothing outside of InsetWrap etc. should need to 
know how InsetWrap etc. works. addToToc() is a clean solution IMO: Any 
inset that has to add something to the ToC can implement it, and fill the 
list.


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


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


OK. I am not fully convinced but I don't have a strong opinion on the 
other solution anyway so we go with your solution.


Abdel.

Advice needed: Change tracking of End-Of-Par

[Michael Gerz]

Hello everybody,

I need your advice on a possibly critical issue:

Presently, LyX does not have an end-of-par character. However, for 
change tracking purposes, it is essential to track the deletion and 
insertion of paragraph breaks. Therefore, in the LyX 1.4 code (and also 
in the current 1.5 implementation), this issue is handled by tracking a 
end-of-par change at position "par.size()" in the Changes data structure.


There are two major implications of this approach:

(1) There is no end-of-par character in the paragraph data structure, 
only in the associated Change data structure. Accordingly,  the user 
doesn't see the  status of the end-of-par at the moment. (However, I 
think it is possible to add a simple workaround for this in Rowpainter.)


(2) If there are two unchanged paragraphs and the user removes the par 
break between them in CT mode, there is no way to merge the two pars 
while preserving the paragraph break (then marked as deleted). As a 
workaround, we do NOT merge the paragraphs but mark the end-of-par as 
deleted. Later, when the user accepts his change, the two paragraphs are 
finally merged. A consequence of this approach is that the LaTeX output 
is not fully correct as long as the change is not accepted (two pars 
instead of one). (I don't know whether this problem can be handled by 
another workaround)


To solve the above-mentioned problems in an elegant way, we need a real 
end-of-par character or inset. However, this requires substantial 
changes to the LyX core and will certainly result in temporary 
instability. I think it will me take me about two weeks to get 
everything right (given the fact that I will be very busy next week) 
whereas it will take me about 1-2 days to finalize the current solution.


Thus my question: Do you think that it is worth changing the current 
approach? Or do you think that the restriction imposed by (2) is 
acceptable from a user's perspective (After all, it may be a matter of 
how this happens).


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.


Please reply quickly - Sunday is the best day for hacking :-)

Regards,
Michael

Re: [patch] esint support

[Abdelrazak Younes]

Georg Baum wrote:

Am Samstag, 11. November 2006 03:05 schrieb Abdelrazak Younes:

Abdelrazak Younes wrote:
I wonder if this addToToc() method is a good idea at all... I'd prefer 
the TocBackend to it himself. InsetInclude doesn't need to know how to 
do that. The same goes for InsetFloat and InsetWrap I guess.
Here is a patch that does that for InsetInclude. This is cleaner IMHO 
even if the special cases in TocBackend are still ugly.


As I wrote I do not like that. I updated my version after your changes, and 
here it is. The patch lloks bigger than it really is, because most of the 
changes are renamed toc stuff. I also solved the problem of non-working 
setBuffer by switching to the existing view of the other buffer instead.
I changed the stuff in InsetInclude to not load the document anymore. That 
speeds up loading of the master a lot. Of course the included docs are now 
only shown in the navigate menu if they are already loaded by other means, 
but that is a good compromise IMO.


What is the other means? Personnally I'd like child document to be 
opened automatically; maybe a user preference setting?




I consider this now stable enough and ready for 1.5.0.


Me too. This is fine with me and there is no big risk either.

Good work.

Abdel.

Re: [patch] esint support

[Abdelrazak Younes]

Jean-Marc Lasgouttes wrote:

"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:


Abdelrazak> I was partly wrong. While disabling these methods
Abdelrazak> definitely helps (with the attached patch), the csrss.exe
Abdelrazak> problem and the poor typing performance at the end the doc
Abdelrazak> is still there. I really wonder why the slowness is only
Abdelrazak> for the paragraph immediately before or after a big
Abdelrazak> equation...

You mean that typing in a paragraph calls updateLabels? This should
definitely not happen IMO. We should find out why.


No, this was my initial theory but it appears that this is not the case.



One thing that is probably a big problem is the construction of macro
table by Buffer::buildMacros at each update.


I'll try to disable that to see if that helps.

Abdel.

Re: [patch] esint support

[Abdelrazak Younes]

Abdelrazak Younes wrote:

Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes 
<[EMAIL PROTECTED]> writes:


Abdelrazak> I was partly wrong. While disabling these methods
Abdelrazak> definitely helps (with the attached patch), the csrss.exe
Abdelrazak> problem and the poor typing performance at the end the doc
Abdelrazak> is still there. I really wonder why the slowness is only
Abdelrazak> for the paragraph immediately before or after a big
Abdelrazak> equation...

You mean that typing in a paragraph calls updateLabels? This should
definitely not happen IMO. We should find out why.


No, this was my initial theory but it appears that this is not the case.



One thing that is probably a big problem is the construction of macro
table by Buffer::buildMacros at each update.


I'll try to disable that to see if that helps.


It doesn't :-(

Abdel.