Re: LyX master Work Area Disappears on Initial Save (Redraw issue?)

[Richard Kimberly Heck]

On 05/14/2018 03:50 AM, Jean-Marc Lasgouttes wrote:
> diff --git a/src/frontends/qt4/GuiWorkArea.cpp 
> b/src/frontends/qt4/GuiWorkArea.cpp
> index 7c80fcc..8dc0739 100644
> --- a/src/frontends/qt4/GuiWorkArea.cpp
> +++ b/src/frontends/qt4/GuiWorkArea.cpp
> @@ -1247,9 +1247,14 @@ void GuiWorkArea::Private::paintPreeditText(GuiPainter 
> & pain)
>  
>  void GuiWorkArea::paintEvent(QPaintEvent * ev)
>  {
> - // Hopefully fixes bug #10989.
> - if (view().busy())
> + // Do not trigger the painting machinery if we are not ready (see
> + // bug #10989). However, since macOS has turned the screen back at

"black", I take it.

Riki

Re: LyX 2.3.0 Regression Inquiry

[Joel Kulesza]

On Mon, May 14, 2018 at 11:51 AM, Richard Kimberly Heck 
wrote:

> On 05/14/2018 01:28 PM, Jürgen Spitzmüller wrote:
> > Am Montag, den 14.05.2018, 13:18 -0400 schrieb Richard Kimberly Heck:
> >> I've been thinking about this, too, and had come to a somewhat
> >> similar
> >> conclusion, though not with nearly as much detail. I.e., it seemed to
> >> me
> >> that there was something wrong with how the parents were being
> >> assigned
> >> when we clone. Unfortunately, there is a reason that we clone from
> >> the
> >> master: There may be macros defined there that are needed in the
> >> child.
> >> (See 2d6173d8103.) It may be that we should have said that wasn't a
> >> bug:
> >> If you view only the child, then you shouldn't expect macros defined
> >> outside it to work. Maybe the include_only support allows people to
> >> do
> >> what they were trying to do here by viewing only the child?
> > That's definitely wrong. A child compiled standalone should not inherit
> >  anything from a parent. This opens up for all sorts of bugs.
> >
> >> It seems to me that, in some ways, this is tied up with different
> >> understandings people have of the master-child relationship, and what
> >> it means to view "only the child".
> > Maybe. But "Viewing the child" is actually not what is the case here.
> > It's not a child in that case (we have includeonly support for that
> > case).
>
> Yes, I agree, but I think that's how people often think of it. They're
> not really treating the child as a standalone document. They just want
> to see the PDF of that chapter (say), and not the whole thing. I think
> that must be what Joel is doing. Certainly Chapter 1 is not going to be
> a standalone document. (Joel, tell me if I'm wrong.) As you say, the
> right way to do that is to use the includeonly stuff. But I'm guessing
> Joel isn't the only person who would try to 'view only one chapter' this
> way.
>
> So probably 2d6173d8103 was a mistake: We should just have said that you
> can't do that. But that was before the includeonly support, I believe,
> so maybe it made sense then? I'm not sure.
>
> I wonder if it would help people here to have some LFUN that would allow
> one to "view only the child" in the way people want. What it would do,
> basically, is includeonly the current Buffer and its descendants, then
> view that. I.e., you wouldn't have to go to the master, fiddle with
> those settings, and then view. So it would work kind of like
> master-buffer-view, but take care of the includeonly stuff for you. Then
> again, that might not work in a lot of cases. E.g., you might need to
> include the bibliography always---which is why Joel has that complex
> ERT. (But then maybe there could be a setting for that? But maybe that
> gets too complicated)
>
> Riki
>
>
I appreciate the time invested and technical back-and-forth discussion on
my behalf.  What's below doesn't add much (if anything) to the discussion,
but some thoughts regarding how I got myself to where I am vs. what others
might encounter:

   - Riki is correct; the dissertation will be a single multi-chapter
   document in the end.  However, there is an overriding concern that compels
   me to render individual chapters.  Several chapters are very equation heavy
   (with each equation quite long), so only by rendering can I confirm that
   the equations lay out in a sane way.  Limiting the scope of rendering
   allows for faster rendering (some chapters are image and/or TikZ heavy and
   are slow to render regularly).
   - Because of the equation layout concern and the need to conform to
   university formatting requirements, I want to be sure all preamble
   customizations are universally available to the whole document or its
   individual parts (without me having to keep settings across multiple files
   in sync).  This is why I have a preamble.tex called in to each file rather
   than having some form of down-propagation from the parent to the
   child(ren).
   - As I render each chapter (while I'm working on it) I want to have a
   bibliography and nomenclature listing in each chapter.  This keeps things
   in context.  This is also helpful as I provide chapters to others for
   review.  However, for the full document, I only want one nomenclature (near
   the beginning) and one bibliography (near the end).
   - My thought was that branches with includes could accomplish these
   goals while minimizing or eliminating the amount of things I'd need to
   change if I update something as I'm working in a child.  For those changes,
   I want to have the change "trickle up" to the parent without having to
   attend to the parent at that very moment.  Example: I need to define a new
   color name for a TikZ image I'm preparing in a child.  I'd rather just open
   an external "include" file in an editor to define it and know that change
   will then be applied to the parent and all children.  I'm not sure where
   this desire/approach puts me on 

Re: LyX master Work Area Disappears on Initial Save (Redraw issue?)

[Joel Kulesza]

On Mon, May 14, 2018 at 1:50 AM, Jean-Marc Lasgouttes 
wrote:

> Le 13/05/2018 à 04:07, Richard Kimberly Heck a écrit :
>
>> Right, in that case, we do reload. So we'll have to request an explicit
>> redraw of the screen,
>> and I suppose a reload of the dialogs, etc.
>>
>> I'm not sure how to do that, but either I'll figure it out or someone
>> will tell me.
>>
>
> What about this patch?
>

Applying the attached patch to 45fba1ce1b fixes the problem I showed: the
work area now doesn't disappear on save.

Thanks,
Joel

Re: LyX 2.3.0 Regression Inquiry

[Richard Kimberly Heck]

On 05/14/2018 01:28 PM, Jürgen Spitzmüller wrote:
> Am Montag, den 14.05.2018, 13:18 -0400 schrieb Richard Kimberly Heck:
>> I've been thinking about this, too, and had come to a somewhat
>> similar
>> conclusion, though not with nearly as much detail. I.e., it seemed to
>> me
>> that there was something wrong with how the parents were being
>> assigned
>> when we clone. Unfortunately, there is a reason that we clone from
>> the
>> master: There may be macros defined there that are needed in the
>> child.
>> (See 2d6173d8103.) It may be that we should have said that wasn't a
>> bug:
>> If you view only the child, then you shouldn't expect macros defined
>> outside it to work. Maybe the include_only support allows people to
>> do
>> what they were trying to do here by viewing only the child?
> That's definitely wrong. A child compiled standalone should not inherit
>  anything from a parent. This opens up for all sorts of bugs.
>
>> It seems to me that, in some ways, this is tied up with different
>> understandings people have of the master-child relationship, and what
>> it means to view "only the child".
> Maybe. But "Viewing the child" is actually not what is the case here.
> It's not a child in that case (we have includeonly support for that
> case).

Yes, I agree, but I think that's how people often think of it. They're
not really treating the child as a standalone document. They just want
to see the PDF of that chapter (say), and not the whole thing. I think
that must be what Joel is doing. Certainly Chapter 1 is not going to be
a standalone document. (Joel, tell me if I'm wrong.) As you say, the
right way to do that is to use the includeonly stuff. But I'm guessing
Joel isn't the only person who would try to 'view only one chapter' this
way.

So probably 2d6173d8103 was a mistake: We should just have said that you
can't do that. But that was before the includeonly support, I believe,
so maybe it made sense then? I'm not sure.

I wonder if it would help people here to have some LFUN that would allow
one to "view only the child" in the way people want. What it would do,
basically, is includeonly the current Buffer and its descendants, then
view that. I.e., you wouldn't have to go to the master, fiddle with
those settings, and then view. So it would work kind of like
master-buffer-view, but take care of the includeonly stuff for you. Then
again, that might not work in a lot of cases. E.g., you might need to
include the bibliography always---which is why Joel has that complex
ERT. (But then maybe there could be a setting for that? But maybe that
gets too complicated)

Riki

Re: LyX 2.3.0 Regression Inquiry

[Jürgen Spitzmüller]

Am Montag, den 14.05.2018, 13:18 -0400 schrieb Richard Kimberly Heck:
> I've been thinking about this, too, and had come to a somewhat
> similar
> conclusion, though not with nearly as much detail. I.e., it seemed to
> me
> that there was something wrong with how the parents were being
> assigned
> when we clone. Unfortunately, there is a reason that we clone from
> the
> master: There may be macros defined there that are needed in the
> child.
> (See 2d6173d8103.) It may be that we should have said that wasn't a
> bug:
> If you view only the child, then you shouldn't expect macros defined
> outside it to work. Maybe the include_only support allows people to
> do
> what they were trying to do here by viewing only the child?

That's definitely wrong. A child compiled standalone should not inherit
 anything from a parent. This opens up for all sorts of bugs.

> It seems to me that, in some ways, this is tied up with different
> understandings people have of the master-child relationship, and what
> it
> means to view "only the child".

Maybe. But "Viewing the child" is actually not what is the case here.
It's not a child in that case (we have includeonly support for that
case).

Jürgen

> 
> Riki
> 

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

Re: LyX 2.3.0 Regression Inquiry

[Richard Kimberly Heck]

On 05/14/2018 02:55 AM, Jürgen Spitzmüller wrote:
> Am Freitag, den 11.05.2018, 21:44 -0600 schrieb Joel Kulesza:
>> LyX Developers,
>>
>> As I'm writing my dissertation, I've been using LyX 2.2.3 but today
>> decided to try migrating it to 2.3.0.  Upon doing so, I encountered
>> what appears to be a regression (or else I've been doing something
>> invalid all along that 2.2.3 accepts without complaint).
> I get the same problem with 2.2.3. It is a mystery to me why this works
> for you.

I checked with 2.2.3 and didn't see this problem. I thought it was due
to some code's having been moved as part of the biblatex stuff that the
bug got revealed. That's why I initially thought this might be tied to
some of that: not that the biblatex stuff caused the bug, but that it
revealed it. But I'd have to check again.

>> I cannot make the document available but I have a not-quite-MWE
>> available that I hope you could work with to see if you can reproduce
>> what I'm seeing with LyX 2.2.3/2.3.0 on two separate computers (macOS
>> 10.13.4 and OS X 10.11.6).  If this can be reproduced and someone can
>> help me characterize this, I'm happy to file an item in the tracker.
>>
>> Steps to reproduce:
>> Clone https://github.com/jkulesza/UMich_Dissertation_LyX and checkout
>> the "lyx_mwe" branch.
>> Open dissertation.lyx in LyX 2.2.3.  Render.  This should succeed.
>> Right-click chapter_01.lyx -> Edit.  Render.  This should succeed.
>> Exit.
>> Open dissertation.lyx in LyX 2.3.0.  Render.  This should succeed.
>> Right-click chapter_01.lyx -> Edit.  Render.  This should fail with
>> the attached regarding being unable to find my .bst file.
>> At this point, I'm unsure where the problem lies (if it is indeed a
>> problem) so anything I'd file in the tracker is no more help that
>> what I'm filing here.
>>
>> As always, your help and time is appreciated!
> The story is long and complex. If you are not interested in the
> background but only in what I think the bug here is, jump to the last
> paragraph.
>
> []
>
> In fact, the attached patch fixes the issue with Joel's test files for
> me. It strikes me more logical than what we have now, but since I know
> very less about the cloning procedure, I am sure I miss something
> fundamental that is the reason of how cloning is done now.
>
> Riki, you are more familiar with this part of the code, so I am looking
> forward to your comments.

I've been thinking about this, too, and had come to a somewhat similar
conclusion, though not with nearly as much detail. I.e., it seemed to me
that there was something wrong with how the parents were being assigned
when we clone. Unfortunately, there is a reason that we clone from the
master: There may be macros defined there that are needed in the child.
(See 2d6173d8103.) It may be that we should have said that wasn't a bug:
If you view only the child, then you shouldn't expect macros defined
outside it to work. Maybe the include_only support allows people to do
what they were trying to do here by viewing only the child?

It seems to me that, in some ways, this is tied up with different
understandings people have of the master-child relationship, and what it
means to view "only the child".

Riki

Re: Hide Changes in LyX Display

[Jean-Marc Lasgouttes]

Le 10/05/2018 à 20:35, Richard Kimberly Heck a écrit :

* what happens with cursor movement across deleted parts? This looks
tough to solve properly. The situation would be much easier with a
Changes inset, but we are not ready for that yet.


I was about to write you about that. This is the remaining problem. By
default, the cursor 'sees' the deleted material, so moving right (say)
sometimes does nothing. I think what is needed is a routine somewhere
that puts the cursor at the end or beginning of deleted material.


It is not "a problem". It would require massive changes to all places 
that manipulate cursors. A more invasive change would change the 
Paragraph class so that it lies and hides the existence of deleted 
characters. This is far from trivial IMO.


JMarc

Re: LyX master Work Area Disappears on Initial Save (Redraw issue?)

[Jean-Marc Lasgouttes]

Le 13/05/2018 à 04:07, Richard Kimberly Heck a écrit :
Right, in that case, we do reload. So we'll have to request an explicit 
redraw of the screen,

and I suppose a reload of the dialogs, etc.

I'm not sure how to do that, but either I'll figure it out or someone 
will tell me.


What about this patch?

JMarc


From e6f1e54238b0ca51ccc2d7c288d7f1c83f44734b Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Mon, 14 May 2018 09:46:54 +0200
Subject: [PATCH] Avoid black screen on macOS

When paintEvent is triggered on macOS, the least we can do is to copy
our backing store to the screen.
---
 src/frontends/qt4/GuiWorkArea.cpp | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/src/frontends/qt4/GuiWorkArea.cpp b/src/frontends/qt4/GuiWorkArea.cpp
index 7c80fcc..8dc0739 100644
--- a/src/frontends/qt4/GuiWorkArea.cpp
+++ b/src/frontends/qt4/GuiWorkArea.cpp
@@ -1247,9 +1247,14 @@ void GuiWorkArea::Private::paintPreeditText(GuiPainter & pain)
 
 void GuiWorkArea::paintEvent(QPaintEvent * ev)
 {
-	// Hopefully fixes bug #10989.
-	if (view().busy())
+	// Do not trigger the painting machinery if we are not ready (see
+	// bug #10989). However, since macOS has turned the screen back at
+	// this point, copy our backing store to screen.
+	if (view().busy()) {
+		d->updateScreen(ev->rect());
+		ev->accept();
 		return;
+	}
 
 	// LYXERR(Debug::PAINTING, "paintEvent begin: x: " << rc.x()
 	//	<< " y: " << rc.y() << " w: " << rc.width() << " h: " << rc.height());
-- 
2.7.4

KMM 5.0.0

[Michael Berger]

Hello Thomas,

I upgraded KMM to version 5.0.0 and  I am back in business after having 
to do some minor corrections re foreign currency exchange rates.


My base currency is the EURO. Currencies like the Swiss Franc and others 
showed correct exchange rates that did not need any adjustment. But the 
exchange rates of currencies with an extrem splay like the € to IDR (1€ 
~ 16 500 IDR) returned large crazy figures that made no sense at all. 
But then it was easy to make the necessary corrections in KMM's Price 
Editor.


I increased the default precision setting to eight digits, e.g. 1 IDR 
equals 0,6001 €.


The Price Editor is now back to presenting the online quotes as before - 
special thanks for this great add-in feature!


Should I come across some other imperfections I will report them to you 
(but so far it doesn't look like).


I am using Mageia 6

Thanks again for the great program and best regards,
Michael

Re: LyX banner language

[Jean-Pierre Chrétien]

Le 29/04/2018 à 11:27, Jürgen Spitzmüller a écrit :

Am Donnerstag, den 26.04.2018, 19:00 -0400 schrieb Scott Kostyshak:

I'd suggest that you apply your 11107.diff patch, which replaces

hard

coded text by translatable one. It allows translators to put

whatever

appropriate sentence which fits in with their language, either a
translation of 'The Document Processor' or just 'Welcome'.

Scott ? Riki ? What is your feeling about this issue ?


That seems reasonable to me.


I don't have a preference.


OK, done.


Riki answered positively about the possibility to backport to 2.3.1, but
before you proceed, we need feedback about this feature on master as far as the 
platform is concerned. For me it looks good on Debian Stretch, but what about 
Windows and MacOS (the German and the French UIs are translated there)?


--
Jean-Pierre

Re: LyX 2.3.0 Regression Inquiry

[Jürgen Spitzmüller]

Am Freitag, den 11.05.2018, 21:44 -0600 schrieb Joel Kulesza:
> LyX Developers,
> 
> As I'm writing my dissertation, I've been using LyX 2.2.3 but today
> decided to try migrating it to 2.3.0.  Upon doing so, I encountered
> what appears to be a regression (or else I've been doing something
> invalid all along that 2.2.3 accepts without complaint).

I get the same problem with 2.2.3. It is a mystery to me why this works
for you.

> I cannot make the document available but I have a not-quite-MWE
> available that I hope you could work with to see if you can reproduce
> what I'm seeing with LyX 2.2.3/2.3.0 on two separate computers (macOS
> 10.13.4 and OS X 10.11.6).  If this can be reproduced and someone can
> help me characterize this, I'm happy to file an item in the tracker.
> 
> Steps to reproduce:
> Clone https://github.com/jkulesza/UMich_Dissertation_LyX and checkout
> the "lyx_mwe" branch.
> Open dissertation.lyx in LyX 2.2.3.  Render.  This should succeed.
> Right-click chapter_01.lyx -> Edit.  Render.  This should succeed.
> Exit.
> Open dissertation.lyx in LyX 2.3.0.  Render.  This should succeed.
> Right-click chapter_01.lyx -> Edit.  Render.  This should fail with
> the attached regarding being unable to find my .bst file.
> At this point, I'm unsure where the problem lies (if it is indeed a
> problem) so anything I'd file in the tracker is no more help that
> what I'm filing here.
> 
> As always, your help and time is appreciated!

The story is long and complex. If you are not interested in the
background but only in what I think the bug here is, jump to the last
paragraph.

The problem is as follows: bibliography.lyx is included both in
dissertation.lyx and chapter_01.lyx (which is also a child of
dissertation.lyx). This leads to bibliography.lyx claiming two "parent
buffers", one of which at the same time is its grandparent, a setting
which LyX is not (yet) prepared for (you also get a warning on the
console because of that).

Since only one parent is currently allowed, the last allocated one is
the effective parent (in your case, it happens to be chapter_01.lyx,
but read on...).

This "effective" parent is used for inheriting specific settings and
data to the children (e.g. for instant preview, source preview, labels
for cross-referencing, bibliography data for citing, etc.). I call this
type of parent "workarea parent" in what follows. The situation that
chapter_01.lyx is the "workarea parent" is most probably not what you
want, since I suppose you want to inherit settings and data from
dissertation.lyx. We could (try to) always use the uppermost buffer in
the hierarchy as "workarea parent" (if this can be determined), but
ideally, we should allow for multiple parents and provide a way to
select the "main" one that is used for workarea purposes (sometimes
uppermost parents are just portmanteaus for specific purposes; think
beamer handouts). However, this is a different bug ...

But next to the "workarea parent", the is another (and sometimes
different) kind of parent, namely the master document (henceforth
called "output parent"). If you compile your MWE from dissertation.lyx,
this file is the master document (output parent) and chapter_01.lyx and
bibliography.lyx are its children. If you compile from chapter_01.lyx,
however, this one is the master, with bibliography.lyx as child.

In order to account for that, we try to completely cut the links from
chapter_01.lyx to dissertation.lyx in that latter scenario (via the
ignore_parent bool that is set on latex export). This makes
chapter_01.lyx "output parent" of bibliography, or at least it is
supposed to be so.

Over the weekend, I tried to understand why this is not fully the case,
i.e., why the BibTeX inset in bibliography.lyx, when compiled from
chapter_01.lyx, has dissertation.lyx as its "output parent" (effecting
in the wrong tmp dir location determined via masterBuffer()-
>temppath()), even though we have explicitly cut the link from
chapter_01.lyx upwards. I first thought that the "workarea parent"
chimes in here, but that's not true, since as we saw above, "workarea
parent" is (erroneously) set to chapter_01.lyx as well!

And here is what I think to be the problem: a bug in the the buffer
cloning logic. Buffer cloning is done for exporting buffers; all
involved buffers are copied and then used for the export (this allows
for editing the real buffers during export). 
When we do that cloning, the parents are newly assigned to the clones.
And here's the problem: this is always done from the effective
"workarea parent" of the buffer that is about to be processed
(asyncBufferProcessing() calls cloneFromMaster(), which starts
processing at masterBuffer()). So while exporting, which starts from
the real "output parent", chapter_01.lyx, the parents are newly
assigned to the whole family, and since dissertation.lyx is the
workarea parent of chapter_01.lyx, dissertation.lyx is (wrongly)
declared as (output!) parent of chapter_01.lyx _and_