Re: LyX-Workarea: Background not shown correctly

[Patrick De Visschere]

> On 22 Oct 2017, at 23:11, Jean-Marc Lasgouttes  wrote:
> 
> Le 21 octobre 2017 14:56:36 GMT+02:00, Patrick De Visschere 
>  a écrit :
>> Jean-Marc,
>> 
>> This works because every update is turned into a FullScreenUpdate.
>> Right?
> 
> If I understand correctly, it turns every update related to an UpdateRequest 
> event (something internal to qt) into a full screen update (in the LyX 
> sense). But I think that these updates (those which create the black screen) 
> are not the norm.
> You can check that by adding some debug information along with the new code 
> in my patch to see how often it triggers.

With the patch in place, SingleParUpdate in bufferView::draw is never reached.

> 
> It would be interesting to set a break on QWindow::requestUpdate and see 
> whether to is something we do that triggers this effect.

I did and it’s never triggered.

>> Isn’t this a waste of work?
>> 
>> Do you consider this as a permanent solution?
> 
> Yes maybe, along with other improvement on our draw code. But I might not 
> understand exactly what is happening.
> 
>> I’ve tried to solve the problem by using: viewport()->update(0,y,w,h)
>> and thus specifying the proper coordinates.
> 
> Which one?

The following gives me the correct coordinates for a simple paragraph (for 
tables using top_pit looks better).

void BufferView::rectToUpdate(int *y, int *w, int *h)
{
if(d->update_strategy_ == SingleParUpdate) {
Text & buftext = buffer_.text();
pit_type const bottom_pit = d->cursor_.bottom().pit();
TextMetrics & tm = textMetrics();
*h = tm.parMetrics(bottom_pit).height();
*y = tm.parMetrics(bottom_pit).position() - 
tm.parMetrics(bottom_pit).ascent();
} else {
*y = 0;
*h = height_;
}
*w = width_;
}


> 
>> If I pass the coordinates of the paragraph, I notice that
>> “SingleParUpdate" actually means “SingleRowUpdate". Since only the
>> current paragraph is painted black now, except for the current row.
> 
> Interesting. Does this mean that we could somehow disable completely these 
> black screen paintings ?

Actually I need the coordinates of the current Row instead of those of the 
Paragraph, but sofar I couldn’t find this information. I’m afraid that the 
currrent Row of a paragraph is not cached somewhere.
And this does not work yet when making a selection or moving the cursor around.

It will only work if for every update we can pass via viewport()->update(x, y, 
w,h) the exact area to be painted later. If it’s too large it will be partially 
black and if too small updates will be missed.

> 
> The whole situation is not clear to me as you can see.

I’m still having problems with the basics. I thought there existed a document 
describing the basics of textMetrics, paragraphMetrics … .
I found something on the wiki but not so much.

> 
> JMarc
> 




smime.p7s
Description: S/MIME cryptographic signature

Re: Initial view of document (master)

[Pavel Sanda]

Pavel Sanda wrote:
> Pavel Sanda wrote:
> > Jean-Marc Lasgouttes wrote:
> > > Le 19/10/2017 ?? 15:05, Pavel Sanda a écrit :
> > >> Pavel Sanda wrote:
> > >>> d) Editing problems
> > >>> Don't see how to produce solid recipy but something is wrong with 
> > >>> editing 
> > >>> as well.
> > >> Try couple times this one:
> > >> 1. open user guid, uncheck disable editing
> > >> 2. go to in front of "i" in "What is LyX"
> > >> 3. hit delete
> > >> 4. in most cases the character does not disappear although deleted once 
> > >> you move caret
> > >
> > > This (and the insert note crash) are fixed in this latest version. I send 
> > > it because I will not have much time on it until next Tuesday.
> > 
> > After some testing:
> > - initial thread report present
> > - a is present
> > - b is fixed
> > - c mostly fixed, ghost c3*** still remains
> 
> Another cursor issue (I have vague memory this was already discussed):
> while editing paragraph of text go to the end of last word.
> Hit spacebar - space is inserted, but cursor stays at the end of word
> and shows only after inserting the next non whitespace character.

And I have reproducible crash:
1. start new document
2. write "ambititious ", spellcheck correctly underlies text.
3. try to fix spelling via context menu, choose "ambitious"
4. kaboom

> Pavel

Re: Initial view of document (master)

[Pavel Sanda]

Pavel Sanda wrote:
> Jean-Marc Lasgouttes wrote:
> > Le 19/10/2017 ?? 15:05, Pavel Sanda a écrit :
> >> Pavel Sanda wrote:
> >>> d) Editing problems
> >>> Don't see how to produce solid recipy but something is wrong with editing 
> >>> as well.
> >> Try couple times this one:
> >> 1. open user guid, uncheck disable editing
> >> 2. go to in front of "i" in "What is LyX"
> >> 3. hit delete
> >> 4. in most cases the character does not disappear although deleted once 
> >> you move caret
> >
> > This (and the insert note crash) are fixed in this latest version. I send 
> > it because I will not have much time on it until next Tuesday.
> 
> After some testing:
> - initial thread report present
> - a is present
> - b is fixed
> - c mostly fixed, ghost c3*** still remains

Another cursor issue (I have vague memory this was already discussed):
while editing paragraph of text go to the end of last word.
Hit spacebar - space is inserted, but cursor stays at the end of word
and shows only after inserting the next non whitespace character.

Pavel

Re: compilation of LyX 2.3 fails with Python 3.6.2

[Guenter Milde]

On 2017-10-23, Helge Hafting wrote:
> Den 17. okt. 2017 19:50, skrev Guenter Milde:

Hej Helge,

thank you for looking into this.

>> TODO: find out which encoding is used for the arguments by CMake
>> (maybe we need the locale encoding) and eventually adapt the argument
>> parsing:

>>arg = arg.decode('UTF-8') # support non-ASCII characters in arguments

> Is that sort of thing necessary?
> Arguments are often file/pathnames, right? 

Often, yes. But here we have also the to-be-replaced values and their
replacement are handed to the script as command line arguments:

# Syntax: ReplaceValues.py [= [= ...]]  
[ ...]

> Anyway, anything that *is* a 
> pathname, should not be 'decoded' or otherwise altered. 

Then, we need a way to get the raw byte-string of the command line in
Python 3. (The above line is only used to get the same result with Py2 and
Py3.)

However, we have to think of the use case: ReplaceValues.py is an auxiliary
script for the package generation with cmake. It is developers-only.

> While it may be necessary to encode/decode the contents of files, this 
> should not be done with pathnames. A pathname is the real name used by 
> the underlying filesystem. Any change, and it won't match reality 
> anymore.

This is a bit tricky: 

* if I get the pathname from the system, it is best to keep it undecoded,
* if the pathname is stored in a script or data file, I need to change the
  encodings from the data-file's encoding to the filesystem encoding.

Here, it is even a bit more tricky, because the pathname is stored in a
cmake config file and passed as command line argument to the script via make.
Fortunately, filenames of the LyX documentation are all ASCII.

Thanks,
Günter

Re: Show changes don't work properly with display math

[Enrico Forestieri]

On Sun, Oct 22, 2017 at 01:27:24PM +0200, Enrico Forestieri wrote:
> On Fri, Oct 20, 2017 at 10:17:34AM +0300, racoon wrote:
> 
> > Open and typeset the attached file with a deleted text immediately followed
> > by a display math (the way one should typeset display math without extra
> > space in LyX) and active show changes. It shows both the original results
> > without deletions and the actual results.
> > 
> > Notes:
> > The main problem is shown at 2 compared to 1 where the display math is
> > translated to the top.
> > 
> > But there is also a minor problem. When preceded by a new paragraph, as
> > shown in 3 and 4, the display math is translated to the right and bottom
> > which does not seem fully correct either.
> > 
> > (The result is independent of the enumerations.)
> 
> Thanks for the report. Should be fixed in master at 7f23ca91.

Scott, what about 2.3.x?

-- 
Enrico

Re: compilation of LyX 2.3 fails with Python 3.6.2

[Helge Hafting]

Den 17. okt. 2017 19:50, skrev Guenter Milde:


TODO: find out which encoding is used for the arguments by CMake
(maybe we need the locale encoding) and eventually adapt the argument
parsing:

   arg = arg.decode('UTF-8') # support non-ASCII characters in arguments


Is that sort of thing necessary?
Arguments are often file/pathnames, right?  Anyway, anything that *is* a 
pathname, should not be 'decoded' or otherwise altered. A filename is 'a 
string of bytes', and that should work. It *will* work with the 
underlying filesystem - which may have folders encoded in any weird 
encoding not matching LANG or whatever.


Realistic example:
Linux-based file server. Some users use windows (and whatever encoding 
they have.) Some uses linux with utf-8, and some uses linux with some 
iso8859-x encoding. All these people can see their own files named 
correctly, precisely because the server don't care about filename 
encoding. They may see some garbage in other people's filenames - but 
don't care. Each works mostly with their own. A garbled name only has a 
few wrong characters, because A-Z covers 90% even for those who needs 
more than ascii.


Still, you will sometimes have to work with lyx in a shared folder 
created & named by one of the others. The language is not english, so 
yes - the folder name contains non-ascii characters, possibly in an 
encoding you don't use.


Failing to display pathnames correctly under such circumstances is OK. 
(The company should standardize on some encoding, if they want correct 
display in all cases!)


Failing to run scripts, or failure to find files after a 'decoding' 
mangled the pathname is NOT OK.



While it may be necessary to encode/decode the contents of files, this 
should not be done with pathnames. A pathname is the real name used by 
the underlying filesystem. Any change, and it won't match reality 
anymore. It can be changed for display purposes, but note that 
conversion may very well be impossible. At worst, you have 
folderone/foldertwo/filename where "folderone" is in utf-8 and 
"foldertwo" is in iso8859 - both using non-ascii characters. There is no 
need to break because of that.


Conversion errors had better not stop us. Ugly display is something we 
can live with, software stopping with an error is not. And we can of 
course not prevent people from using a perfectly normal folder name in 
whatever language they use.

Inkscape warnings

[Jean-Pierre Chrétien]

Hello,

When I open a manual (e.g. math) with a recent 2.3.x compiled with cmake, I get 
export infos and warnings like these in the command window:



 Background RRGGBBAA: ff00
Area 0:0:48:48 exported to 48 x 48 pixels (96 dpi)

** (inkscape:27501): WARNING **: No cc:license metadata found, derived license 
URI from cc:License: http://creativecommons.org/publicdomain/zero/1.0/

Bitmap saved as: /tmp/lyx_tmpdir.hbKWZiQ27469/gconvertd27469.png


I googled the warning message without success. There is no such option as 
"quiet" with inkscape.


I was able to remove the warnings by modifying the lyxrc.defaults file like 
this:

\converter svgpng"inkscape --without-gui --file=$$i 
--export-png=$$o >/dev/null""",
\converter svgz   png"inkscape --without-gui --file=$$i 
--export-png=$$o >/dev/null"""


But I could do nothing about the export info, even by redirecting /dev/null 
towards 2>&1?


Any other clue to remove the export info?

--
Jean-Pierre

Re: compilation of LyX 2.3 fails with Python 3.6.2

[Kornel Benko]

Am Montag, 23. Oktober 2017 um 00:08:22, schrieb Uwe Stöhr 
> El 22.10.2017 a las 13:43, Uwe Stöhr escribió:
> 
> > great work! Now it works and also the line break issue is now solved.
> 
> OK, there is a minor issue left:
> 
> The script is run on ALL files in the doc directories, so also for the 
> changelog and the attic files. Especially for the changelog files this 
> is not sensible since they are textfiles. So if possible the 
> ReplaceValues.py script should only be run on *.lyx files.

There is a problem. The script _should_ run an all files, because it not only
handled origin but also LYX_USERDIR_VER and LYX_DIR_VER. These values have to 
be changed for
lyx compiled in suffixed mode.

The second effect is the implicit copy of the file to the build-directory.

Question: Is it possible to have also the input-textfiles be utf-8 encoded?

As it is now, the script converts them, which I think is OK.

> regards Uwe

Kornel

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

Re: Update on the 2.3.0rc1 situation

[Enrico Forestieri]

On Sun, Oct 22, 2017 at 09:36:56PM -0400, Richard Heck wrote:
> On 10/22/2017 06:19 PM, Scott Kostyshak wrote:
> > On Sat, Oct 14, 2017 at 06:37:06AM +, Jürgen Spitzmüller wrote:
> >
> >> Also, I think we should consider Günter's lyx2lyx patch [1], but I
> >> didn't have time to thoroughly review it myself.
> > Will anyone have time to take a look at the patch by Wednesday?
> 
> I could look at the code from a code-triaging point of view, but I have
> not followed
> the controversy about this, so someone would need to tell me what the
> code is supposed
> to do.

I don't think this is a change that should be performed at a RC1 stage,
frankly. It is too risky and of dubious utility.

-- 
Enrico

Tickets 9361 and 10661

[Jean-Pierre Chrétien]

Dear Developers

I've closed these two tickets, which were the two last defect tickets remaining 
on my account.


--
Jean-Pierre

Re: Make the math package loading automatic

[Jean-Pierre Chrétien]

Le 23/10/2017 à 08:28, Scott Kostyshak a écrit :

On Fri, Oct 20, 2017 at 09:01:02PM +, Scott Kostyshak wrote:


That way I can run the ctests just to double-check.


Thanks for sending me the patch. I checked and there are no changes in
ctests (with respect to 71a35ea) so I think we are good to go.


Done at 95f60915a7 (2.3.x) and 1720f54b41 (master).

--
Jean-Pierre

Re: Make the math package loading automatic

[Scott Kostyshak]

On Fri, Oct 20, 2017 at 09:01:02PM +, Scott Kostyshak wrote:

> That way I can run the ctests just to double-check.

Thanks for sending me the patch. I checked and there are no changes in
ctests (with respect to 71a35ea) so I think we are good to go.

Scott


signature.asc
Description: PGP signature