forced screen recenter in GuiApplication::dispatch?

[Scott Kostyshak]

We currently have the following code in GuiApplication::dispatch:

  DispatchResult dr;
  // redraw the screen at the end (first of the two drawing steps).
  // This is done unless explicitly requested otherwise
  dr.screenUpdate(Update::FitCursor);
  dispatch(cmd, dr);
  updateCurrentView(cmd, dr);

Regarding the comment "This is done unless explicitly requested", is it
still possible to request that a redraw not be done and if so how? Or is
this comment left-over from how things were previously (e.g. a3aad45f)?
I don't see how the screen flags can be modified after FitCursor is set. 

I'm looking into how to disable recentering the screen upon a "copy".
The use case is that I often use ctrl+a, ctrl+a, ctrl+c to copy a large
inset and then paste it below. Currently, after ctrl+c LyX scrolls up to
the beginning of the large inset. I'm not confident this is a good
proposal, but in any case it lead me to this comment that I wasn't sure
is still valid.

Scott


signature.asc
Description: PGP signature

Re: #10481: Hardening LyX against potential misuse

[Tommaso Cucinotta]

I confess I'm lost as to which layouts have been proposed for the converters 
prefs pane.

Probably, having a few pics/snapshots comparing the options might be the best 
way to gather feedback from others.

Thanks,

T.

On 07/12/2016 21:00, Enrico Forestieri wrote:

On Wed, Dec 07, 2016 at 06:15:02PM +0100, Jean-Marc Lasgouttes wrote:


Yes, your patch make the separation clearer (although I am not sure that I
like the oval rect).


I thought it would have helped in distingushing the sections, but this is
a mere detail.


But the fact that this converter pane is already crowed means that we cannot
implement a proper UI for converter flags. It might be that such an UI would
be much too big anyway.


Why would you think that a proper implementation (if and when that will
be performed) would need more space? However, please have a look at the
attached patch, which leaves more space to the converters definitions.
No need to revert f0f555b5, as this time I used the designer and the
changes would have been anyway extensive.

Re: Document output format PDF(LuaTeX) .. instant preview of math

[Kornel Benko]

Am Freitag, 9. Dezember 2016 um 19:21:04, schrieb Kornel Benko 
> Am Freitag, 9. Dezember 2016 um 18:48:57, schrieb Enrico Forestieri 
> 
> > On Fri, Dec 09, 2016 at 02:36:04PM +0100, Kornel Benko wrote:
> > > 
> > > Nobody seems interested. Probably no one uses PDF(luatex) as default 
> > > output
> > > format.
> > 
> > Or, more simply, don't experience the issue. See attached.
> > 
> 
> Do you use the latest TL2016? I did not see it with TL2015 too.

Yes, just retested with TL2015. Looks good.

Kornel

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

Re: Document output format PDF(LuaTeX) .. instant preview of math

[Kornel Benko]

Am Freitag, 9. Dezember 2016 um 18:48:57, schrieb Enrico Forestieri 

> On Fri, Dec 09, 2016 at 02:36:04PM +0100, Kornel Benko wrote:
> > 
> > Nobody seems interested. Probably no one uses PDF(luatex) as default output
> > format.
> 
> Or, more simply, don't experience the issue. See attached.
> 

Do you use the latest TL2016? I did not see it with TL2015 too.

Kornel

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

Re: #10481: Hardening LyX against potential misuse

[Enrico Forestieri]

On Fri, Dec 09, 2016 at 10:39:14AM +0100, Jean-Marc Lasgouttes wrote:
> Le 07/12/2016 à 21:00, Enrico Forestieri a écrit :
> > Why would you think that a proper implementation (if and when that will
> > be performed) would need more space? However, please have a look at the
> > attached patch, which leaves more space to the converters definitions.
> > No need to revert f0f555b5, as this time I used the designer and the
> > changes would have been anyway extensive.
> 
> I like it better. I am not even sure that the vertical separator is needed.
> If it is kept, is it possible to have it continue higher up to the bold
> titles?

See attached.

> Concerning space, removing the raw flags field would require at least
> 
> - a flavor menu that combines latex, latex_flavor and xml (these variables
> do not need to be separate IIUC).
> - 3 check boxes for need_aux, need_auth and nice
> - 3 text fields for result_dir, result_file and parse_log (I suspect that
> the two first ones could be combined)
> 
> That's a lot of space IMO.

Well, I don't think the the raw flags are that a big issue. They are
very flexible and allow to add options or flavors without the need for
redesigning the gui. Going that direction we would have an ever increasing
space requirement. The most annoying behavior is that you have to remember
to hit "modify" for registering a change, or start modifying an existing
converter for adding one (!).

-- 
Enrico
diff --git a/src/frontends/qt4/ui/PrefConvertersUi.ui 
b/src/frontends/qt4/ui/PrefConvertersUi.ui
index f9c02a8..8120e7d 100644
--- a/src/frontends/qt4/ui/PrefConvertersUi.ui
+++ b/src/frontends/qt4/ui/PrefConvertersUi.ui
@@ -1,96 +1,97 @@
-
+
  PrefConvertersUi
- 
-  
+ 
+  

 0
 0
-438
-466
+596
+498

   
-  
+  

   
-  
-   
+  
+   
 9

-   
+   
 6

-   
-
- 
-  Converter Definitions
+   
+
+ 
+  QGroupBox{border:1px solid 
gray;margin-top:0.5ex;}
  
- 
-  
+ 
+  
+ 
+ 
+  
9
   
-  
+  
6
   
-  
-   
-
- 
-  7
-  7
+  
+   
+
+ 
   0
   0
  
 

   
-  
-   
-
+  
+   
+
  0
 
-
+
  6
 
-
- 
-  
-   0
-  
-  
+
+ 
+  
6
   
+  
+   0
+  
   
-   
+   
   
   
-   
+   
   
  
 
-
- 
-  
-   0
-  
-  
+
+ 
+  
6
   
+  
+   0
+  
   
-   
-
+   
+
  Converter:
 
-
+
  converterED
 

   
   
-   
-
+   
+
  Extra flag:
 
-
+
  converterFlagED
 

@@ -99,38 +100,36 @@
 

   
-  
-   
-
- 0
-
-
+  
+   
+
  6
 
+
+ 0
+
 
- 
-  
-   0
-  
-  
+ 
+  
6
   
+  
+   0
+  
   
-   
-
+   
+
  From format:
 
-
+
  converterFromCO
 

   
   
-   
-
- 
-  3
-  0
+   
+
+ 
   0
   0
  
@@ -140,29 +139,27 @@
  
 
 
- 
-  
-   0
-  
-  
+ 
+  
6
   
+  
+   0
+  
   
-   
-
+   
+
  To format:
 
-
+
  converterToCO
 

   
   
-   
-
- 
-  3
-  0
+   
+
+ 
   0
   0
  
@@ -173,49 +170,47 @@
 

   
-  
-   
-
- 0
-
-
+  
+   
+
  6
 
+
+ 0
+
 
- 
-  
+ 
+  
Add
   
  
 
 
- 
-  
+ 
+  
Modify
   
  
 
 
- 
-  
-   
-1
-

Re: Document output format PDF(LuaTeX) .. instant preview of math

[Enrico Forestieri]

On Fri, Dec 09, 2016 at 02:36:04PM +0100, Kornel Benko wrote:
> 
> Nobody seems interested. Probably no one uses PDF(luatex) as default output
> format.

Or, more simply, don't experience the issue. See attached.

-- 
Enrico

Removing pixmap cache?

[Jean-Marc Lasgouttes]

Hello,

The subject almost says it all. I am not sure that the pixmap cache (a 
different way of painting where the pixmaps corresponding to strings are 
remembered) is very useful these days, especially with my caching patch 
that also uses QTextLayout objects for painting.


Would somebody object to removing it altogether? Note that this thing 
does not work on Linux for some reason (which means that it is even less 
maintained).


It not be horrible to keep it. It is just a different code path in the 
painter with ~100 lines that behave in a subtly different way from the 
normal code path.


JMarc

Re: LyX and (ancient) Hebrew

[Jean-Marc Lasgouttes]

Le 09/12/2016 à 16:04, mn a écrit :

Right now I guess there were several reasons we arrived at the current
situation. Either very good or congruent reasons or just by chance.
But I also guess that no-one has tested or adjusted all the color options:

-- for people with (color-)vision abnormalities
-- for consistency of metaphors and hierarchies
-- the balance of beauty and usability (they are quite ugly, but I
actually do not care about this much since I found them to be 'working'
up until now)


I have tried once or twice to move in this direction, but there is a 
strong resistance on the list :) I guess if we made it easy to package 
color schemes, we could ship with a different one and keep the "classic" 
one for die hards. This is not difficult, but there is some background 
work to make it work. Unfortunately, these days I have other priorities, 
even LyX-wise.



The above is not meant as a complaint.
Nor am I a qualified expert for color-vision or cognitive ergonomics to
remedy this observation.
https://wiki.lyx.org/Tips/ColorSchemes and another website list several
"themes" that are arbitrary, cool, or likeable.


To be frank, I even did not know that we had this page on our wiki!

I would be willing to lend a hand to someone trying to implement the 
needed machinery for color themes in LyX. What is needed is

- a new command \color_theme, and some UI in preferences to go with it
- a way to read these colors (trivial AFAICS)
- a way to dump a color theme from a user's working LyX (not difficult)
- a way to declare that a color is the same as another one like
  \set_color "latex" "#A6E22E"
  \set_color "preview" "@latex"
 This should be mostly easy, but the UI will require some work
- some UI to declare a transparent color, and code in LyX to make sure 
that it works as intended (we already have Color_none for that)



Might it be better than the current options
– to allow for an option of differing text-background color for foreign
languages, (This is arguably very likely to conflict with all the other
background choices under Look )
– and make this switchable via a shortcut and toolbar toggle?


We could make this work together with the "show paragraph end" option (I 
do not like adding options :)



The quick toggle is presumably easiest and most important, given that
all those color options are daunting already.


Yes.


Note that one can see whether the language at cursor position is
different from default by looking at the status bar.


I didn't think of that within this scope.
This is indeed helpful but very limited.
Cursor position is unable to tell me the (is it correct?) extent of the
language declaration.


Yes.

JMarc

Re: LyX and (ancient) Hebrew

[mn]

On 09.12.16 13:25, Jean-Marc Lasgouttes wrote:
> Le 09/12/2016 à 12:59, mn a écrit :
>> This setting dwells under a different Settings group named Look?
>> There I can only change the color of this solid line, not its thickness
>> or position.
>> And in my eyes the line itself is the problem, not its color.
> 
> I understand your arguments, but this is all we have now. I am not 
> completely sure of what a good UI (visible but not obnoxious) would be.
> 

Neither am I.
Visibility and aesthetics are clashing frequently. Not just in LyX.
Right now I guess there were several reasons we arrived at the current
situation. Either very good or congruent reasons or just by chance.
But I also guess that no-one has tested or adjusted all the color options:

-- for people with (color-)vision abnormalities
-- for consistency of metaphors and hierarchies
-- the balance of beauty and usability (they are quite ugly, but I
actually do not care about this much since I found them to be 'working'
up until now)

The above is not meant as a complaint.
Nor am I a qualified expert for color-vision or cognitive ergonomics to
remedy this observation.
https://wiki.lyx.org/Tips/ColorSchemes and another website list several
"themes" that are arbitrary, cool, or likeable.
And I agree that this might be justifiably of some lower importance.


on topic:
Among others, I see the following scenarios:

a) Entering the text, manually or via c: the line is a hassle, and
helpful at the same time.

b) Proof-reading the content: the line is hassle.

c) Proof-reading for compilation or formatting errors and tweaks: the
line is essential.


Note that c and much more so b for me are the most important and
outstanding reasons that LyX is superior to any other TeX editor out there.

Might it be better than the current options
– to allow for an option of differing text-background color for foreign
languages, (This is arguably very likely to conflict with all the other
background choices under Look )
– and make this switchable via a shortcut and toolbar toggle?

The quick toggle is presumably easiest and most important, given that
all those color options are daunting already.

> Note that one can see whether the language at cursor position is 
> different from default by looking at the status bar.
> 

I didn't think of that within this scope.
This is indeed helpful but very limited.
Cursor position is unable to tell me the (is it correct?) extent of the
language declaration.

Mike

Re: LyX 2.2 slowness

[Jean-Marc Lasgouttes]

Le 07/12/2016 à 16:10, Jean-Marc Lasgouttes a écrit :

Le 07/12/2016 à 12:15, Jean-Marc Lasgouttes a écrit :

I'll post a new version to try soon.


Here is a patch to play with. It is not perfect, but I would be
interested to know whether it improves performance with Qt4.


I have improved a bit the patch (fixed a couple bugs)  and now it also 
comes with built-in profiling.

Just comment-out the
#define DISABLE_PMPROF
at the beginning to enable profiling of the 3 main caches.

Here is what I get on User Guide by using PageDown over the whole file 
(not very good for the cache)


#pmprof# getTextLayout: 11.11usec, count=30382, total=337.39msec
   hit: 62%, 4.41usec, count=18877, total=83.26msec
  miss: 37%, 22.09usec, count=11505, total=254.13msec
#pmprof# breakAt: 21.78usec, count=2247, total=48.94msec
   hit: 80%, 6.36usec, count=1811, total=11.51msec
  miss: 19%, 85.85usec, count=436, total=37.43msec
#pmprof# width: 4.03usec, count=212928, total=857.38msec
   hit: 90%, 1.31usec, count=192906, total=252.11msec
  miss: 9%, 30.23usec, count=20022, total=605.27msec

We can see here that there is a sizeable performance improvement from 
these metrics-related functions (note that getTextLayout is also used by 
the painter).

However, the total of these functions is not very large.

Also Tommaso, did you disable stdlib-debug when building master?

On the same file, if I just keep my finger on CursorRight, I get this 
one instead:

#pmprof# getTextLayout: 14.15usec, count=25433, total=359.96msec
   hit: 99%, 14.13usec, count=25337, total=357.91msec
  miss: 0%, 21.31usec, count=96, total=2.05msec
#pmprof# breakAt: 14.21usec, count=467, total=6.64msec
   hit: 97%, 8.37usec, count=454, total=3.80msec
  miss: 2%, 218.31usec, count=13, total=2.84msec
#pmprof# width: 1.91usec, count=57254, total=109.40msec
   hit: 99%, 1.51usec, count=56962, total=86.22msec
  miss: 0%, 79.41usec, count=292, total=23.19msec

What we can see here is very few calls to breakAt. Nevertheless the 
cache is still efficient.


JMarc
From 233b7954d5877aba58ee987517e326b42d3f796e Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Tue, 5 Jul 2016 14:06:22 +0200
Subject: [PATCH] Add caching for the QTextLayout objects we use

The QTextLayout handling is terribly slow on Qt 4.8.7, but some
caching has been added in Qt5 that makes it much faster. For some
reason, it is not that slow with Qt 4.8.1.

This commit introduces some caching, which should probably only be
active for Qt 4.

[NOTE: this version has profiling hooks, enabled by commenting out the line
  #define DISABLE_PMPROF
that should eventually be removed.]

Improve the caching of QTextLayout objects used for pos2x and x2pos
and use them for drawing too. We originally used a trivial caching
of the last QTextLayout, but now they are kept in a QCache.
Moreover, caching is enabled for these QTextLayout object (not sure
what this does).

This patch also adds some caching in the breakAt method, the only user of
QTextLayout which did not have some kind of caching already.

Finally the cached QTextLayout objects are also used by the painter
for drawing text.

For some weird reasons related to Argument-dependent look-up, the
qHash(docstring) function has to be defined in std namespace, since
lyx::docstring is actually std::basic_string.
---
 src/frontends/qt4/GuiFontMetrics.cpp |  133 +++---
 src/frontends/qt4/GuiFontMetrics.h   |   27 ---
 src/frontends/qt4/GuiPainter.cpp |   13 +++-
 src/support/convert.cpp  |7 ++
 4 files changed, 123 insertions(+), 57 deletions(-)

diff --git a/src/frontends/qt4/GuiFontMetrics.cpp b/src/frontends/qt4/GuiFontMetrics.cpp
index d3c89f1..d4aabf4 100644
--- a/src/frontends/qt4/GuiFontMetrics.cpp
+++ b/src/frontends/qt4/GuiFontMetrics.cpp
@@ -21,11 +21,33 @@
 
 #include "insets/Inset.h"
 
+#include "support/convert.h"
 #include "support/lassert.h"
 
+#define DISABLE_PMPROF
+#include "support/pmprof.h"
+
+#include 
+
 using namespace std;
 using namespace lyx::support;
 
+namespace std {
+
+/*
+ * Argument-dependent lookup implies that this function shall be
+ * declared in the namespace of its argument. But this is std
+ * namespace, since lyx::docstring is just std::basic_string.
+ */
+uint qHash(lyx::docstring const & s)
+{
+	return qHash(QByteArray(reinterpret_cast(s.data()),
+	s.size() * sizeof(lyx::docstring::value_type)));
+}
+
+}
+
+
 namespace lyx {
 namespace frontend {
 
@@ -51,11 +73,15 @@ inline QChar const ucs4_to_qchar(char_type const ucs4)
 } // anon namespace
 
 
-// Limit strwidth_cache_ size to 512kB of string data
+/*
+ * Limit (strwidth|breakat)_cache_ size to 512kB of string data.
+ * Limit qtextlayout_cache_ size to 500 elements (we do not know the
+ * size of the QTextLayout objects anyway).
+ * Note that all these numbers are arbitrary.
+ */
 GuiFontMetrics::GuiFontMetrics(QFont const & font)
 	: font_(font), metrics_(font, 0),
-	  

Re: LyX 2.2 slowness

[Jean-Marc Lasgouttes]

Le 09/12/2016 à 15:37, Tommaso Cucinotta a écrit :

On 09/12/2016 11:34, Jean-Marc Lasgouttes wrote:

Note though
that with my patch we directly draw the cached QTextLayout object.


your patch turns LyX from a snail to a lightning fast editor :-)!

It's a long time I don't have memory of being able to go through a doc
at such a speed, just keeping the cursor down key pressed.
How big can this new cache grow ? Perhaps you may want to add a dump of
its size under -dbg ...


The cache sizes are completely arbitrary: from the code
/*
 * Limit (strwidth|breakat)_cache_ size to 512kB of string data.
 * Limit qtextlayout_cache_ size to 500 elements (we do not know the
 * size of the QTextLayout objects anyway).
 * Note that all these numbers are arbitrary.
 */

For the strwidth and breakat caches, what we cache is either the length 
of the string, or the cursor position at which the string should be 
broken (given the margin). We limit to 512k of string data, which is 
pretty conservative.


For the other cache which contains a full QTextLayout object, I have 
limited the size to 500 elements, because I have no idea of the size of 
the thing. If somebody can tell what is the price to pay for these 
things, we may decide to increase the cache size.


Could you try to run the massif tool of valgrind with the patch attached?

JMarc

Re: LyX 2.2 slowness

[Tommaso Cucinotta]

On 09/12/2016 11:34, Jean-Marc Lasgouttes wrote:

Note though
that with my patch we directly draw the cached QTextLayout object.


your patch turns LyX from a snail to a lightning fast editor :-)!

It's a long time I don't have memory of being able to go through a doc at such 
a speed, just keeping the cursor down key pressed.
How big can this new cache grow ? Perhaps you may want to add a dump of its size 
under -dbg ...

Thanks,

T.

Re: Document output format PDF(LuaTeX) .. instant preview of math

[Kornel Benko]

Am Donnerstag, 8. Dezember 2016 um 23:31:48, schrieb Scott Kostyshak 

> On Sat, Nov 05, 2016 at 11:40:51AM +0100, Kornel Benko wrote:
> > Try to open attached document.
> > Wait a moment until the preview is done.
> > The formula takes too much space.
> 
> I thought someone had responded to this but I can't find it.
> We should make a bug report so we don't forget.
> 
> Scott

Nobody seems interested. Probably no one uses PDF(luatex) as default output 
format.

The script lyxpreview2bitmap.py is correctly called with '--png ... 
--latex=lualatex', but
the created png file is not cropped properly.
Removing the conversion Preview->png does not help. The created ppm file shows 
the same effect,
but at least the width is now correct.

Preview with lualatex:
Size of generated png: 951 x 1345
Size of generated ppm: 345 x 1345
Background of math not changed.
Preview with xelatex:
Size of generated png: 551 x 142, 
Background changes
Preview with pdflatex
Size of generated png: 551 x 142
Background of math not changed.

Kornel



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

Re: LyX and (ancient) Hebrew

[Jean-Marc Lasgouttes]

Le 09/12/2016 à 12:59, mn a écrit :

This setting dwells under a different Settings group named Look?
There I can only change the color of this solid line, not its thickness
or position.
And in my eyes the line itself is the problem, not its color.


I understand your arguments, but this is all we have now. I am not 
completely sure of what a good UI (visible but not obnoxious) would be.


Note that one can see whether the language at cursor position is 
different from default by looking at the status bar.


JMarc

Re: LyX and (ancient) Hebrew

[mn]

On 08.12.16 16:31, Jean-Marc Lasgouttes wrote:
> Le 08/12/2016 à 16:21, mn a écrit :
>> Try to select what comes after the first colon (to the left) up until
>> the second colon in the second line. Or in other words: what is just
>> between those two.
>> The selection will jump to the beginning of the first line (far right).
>> This was not intended.
> 
> If I understand correctly, this is bug #10424, which will be fixed in 2.2.3.
> 

Oh. Looks like it indeed.
Nice.

Mike

Re: LyX and (ancient) Hebrew

[mn]

On 08.12.16 16:27, Jean-Marc Lasgouttes wrote:
> Le 08/12/2016 à 16:20, mn a écrit :
>> Yes. But this means I loose the ability to immediately see whether or
>> not this part was correctly assigned to a given language.
>> I think there might be a better solution than to disable _a_ marking
>> completely. A grey bar in the background?
> 
> You can freely change the color of this underline, which is ugly by default.
> 

This setting dwells under a different Settings group named Look?
There I can only change the color of this solid line, not its thickness
or position.
And in my eyes the line itself is the problem, not its color.

Mike

Re: problems with quotes

[Jean-Marc Lasgouttes]

Le 08/12/2016 à 00:09, Guenter Milde a écrit :

* consistency: currently, if a user sees a guillemot « on screen, it can be
  a literal character or a Quote inset and the LaTeX export can be

  "«" or "\guillemotleft" (depending on the "inputencoding")
  "<<" (for Quote inset, even if « is supported by the encoding)


Concerning this particular part: it is a remnant of the situation for 
french language 10+ years ago whaere we had to competing solutions. So 
it should indeed be cleaned-up with vigor.


However, it would need to double check whether the handling of « as 
defined in some language agnostic unicode package catters for the need 
that we have for French language (to be frank, I do not have the answer 
here, but there is a lot of code in french.ldf).


JMarc

Re: problems with quotes

[Jean-Marc Lasgouttes]

Le 07/12/2016 à 18:49, Guenter Milde a écrit :

The current behaviour of "insert-quote" LFUN is usually called "smart
quotes". This can be done without Quote insets.


Sure. What the Quote inset brings us, as Juergen pointed out already, is 
some semantics. But it is not semantics that we really exploit now.



Only if we want to keep the type of quotes configurable also after
insertion, "dynamic" Quote insets are required.
But even then, the existing "static" Quote insets should be converted to
Unicode in the source files with lyx2lyx.


I am not so sure about that. The example of inner spacein french quotes 
is interesting in this repect. Sure, we can take the lazy approach and 
add inde spaces by hand. This lead french text to be full of ugly grey 
rectangles (the spaces) on screen in word processors. But it is not 
really a quote and a space. In some sense the space is part of the 
quote, like the spacing in math typesetting.


And pardon me for failing to be impressed by the modernity of people 
having unicode keyboards (how many keys does your keyboard have?) and 
selection of a character in a list or 65535 others in some GUI where I 
have to guess what is the category of the character I am looking for. 
Unicode is great, but it is not a religion I want to get enrolled in.


JMarc

Re: LyX 2.2 slowness

[Jean-Marc Lasgouttes]

Le 08/12/2016 à 23:18, Tommaso Cucinotta a écrit :

likely with this sequel [1], so the innermost LyX code seems:

lyx::frontend::GuiFontMetrics::breakAt,lyx::Row::Element::breakAt,
lyx::Row::shortenIfNeeded,lyx::TextMetrics::breakRow,lyx::TextMetrics::redoParagraph,


breakAt is the main method for which caching is added in my patch.


Now, I'm just moving the cursor and sometimes selecting with Shift down,
so do we actually need to redoParagraph() ?


This is an excellent question :) The problem is that this update code is 
very cery fragile. I have tried in the past to streamline 
BufferView::processUpdateFlags and BufferView::draw without much 
success. There are always cases where metrics are lost for some reason.


You can read development/PAINTING_ANALYSIS for some of my thoughts on 
the subject.
One thing I have been working towards is separating computation of 
metrics and inset positions, from drawing itself. This would have the 
obvious advantage to allow painting to happen at redraw events (or 
whatever they are called), like any normal application does.


However, I realize now that my assumption that painting is more 
expensive than metrics is not correct, especially now that we use 
QTextLayout to do the glyph combination for us. It might be that we 
should be at a lower level and leverage harfbuzz (or whatever thing I do 
not know) to this line breaking and cursor positioning job. I do not 
know what is the extra amount of work that is done by QTextLayout and 
that we do not really need. Note though that with my patch we directly 
draw the cached QTextLayout object.


And of course, the second work is to reduce the amount of metrics 
computation and of painting that happens. This is a pretty difficult 
job, especially since the code is peppered with random buffer.changed() 
calls (which force a redraw and/or metrics computation) which have been 
added for some forgotten reason, probably that it was easier than just 
thinking about what we were doing.


JMarc

Re: #10481: Hardening LyX against potential misuse

[Jean-Marc Lasgouttes]

Le 07/12/2016 à 21:00, Enrico Forestieri a écrit :

Why would you think that a proper implementation (if and when that will
be performed) would need more space? However, please have a look at the
attached patch, which leaves more space to the converters definitions.
No need to revert f0f555b5, as this time I used the designer and the
changes would have been anyway extensive.


I like it better. I am not even sure that the vertical separator is 
needed. If it is kept, is it possible to have it continue higher up to 
the bold titles?


Concerning space, removing the raw flags field would require at least

- a flavor menu that combines latex, latex_flavor and xml (these 
variables do not need to be separate IIUC).

- 3 check boxes for need_aux, need_auth and nice
- 3 text fields for result_dir, result_file and parse_log (I suspect 
that the two first ones could be combined)


That's a lot of space IMO.

JMarc