Re: Annoying terminal messages: QXcbClipboard: SelectionRequest too old

[Scott Kostyshak]

On Sun, Jul 10, 2016 at 11:45:42AM +0200, Enrico Forestieri wrote:

> I don't think that they are going to fix this issue that seems to be
> there since ages. I was not even aware of the problem and it is not
> even serious as giving focus to a window before pasting avoids it.
> Should they fix this issue, the patch itself would become redundant
> but not harmful, so it should be safe. On the other hand it is something
> that testifies the quality of a software, so I think it is worth
> committing with some explanatory comment.

Enrico, have you seen the following?
https://codereview.qt-project.org/#/c/32263/

In particular, note the patch set here:
https://codereview.qt-project.org/#/c/32263/7//ALL

"Clients attempting to acquire a selection must set the time value of
the xcb_set_selection_owner request to the timestamp of the event
triggering the acquisition attempt, not to XCB_CURRENT_TIME."

Does this mean that setting to XCB_CURRENT_TIME in cb0c881b should be
changed to something else? I don't actually understand. I don't even
know if LyX is the "client" here (I would have guessed that "client"
referred to the application retrieving the selection, not writing it).

I have no idea if the above is relevant. Even if it is, if you don't
feel like spending more time on this, please don't. It is a minor issue
and you already committed a patch that works, so I doubt it is worth any
more of your time. I just send this to you in case it captures your
curiosity.

Scott


signature.asc
Description: PGP signature

Re: master is no longer compilable because of required polib library

[Uwe Stöhr]

Am 27.07.2016 um 06:11 schrieb Kornel Benko:


I understand. We may find a solution which suits us all.


Many thanks, your found one, now I can compile again here in my 
"Internet refugee camp" ;-)


regards Uwe

Re: Possibly wrong libraries on windows binaries

[Uwe Stöhr]

Am 27.07.2016 um 11:02 schrieb Alberto Escrig Vidal:


I've just updated to 2.2.1 and it doesn't work on my windows 7 32-bit machine. 
On startup, I get msvcp140.dll is not a valid Windows app or something like 
this.


Dear Alberto,

I released yesterday a fixed installer:
http://ftp.lyx.de/LyX%202.2.1/
(just install over the existing LyX 2.2.1)

It is not clear to me what happened because I distributed the 32bit DLLs 
of the latest MSVC 2015 version "update 3". For an unknown reason they 
don't work if one doesn't have MSVC 2015 installed. Now i did nothing 
else than to distribute the DLLs of "update 2" as I did for LyX 2.2.0 
and now it seems to work even on Win Vista.


regards Uwe

Re: #10310: Session handling does not restore cursor position

[Scott Kostyshak]

On Wed, Jul 27, 2016 at 03:23:37PM +0100, Guillaume Munch wrote:
> Le 27/07/2016 à 14:05, Davide Anchisi a écrit :
> > Yes, it is written in ~/.lyx/session every time I exit LyX.
> > It seems it is not read back (or used) when opening LyX again.
> > But, even stranger, it does work for some files, apparently those
> > created using LyX versions 2.1. For those files the cursor position is
> > correctly restored even when the position and/or the file is modified
> > with v. 2.2.1. And even for them the cursor position is written in
> > ~/.lyx/session with the same syntax, e.g.:
> > 12, 4, /home/myHome/file.lyx
> > 
> 
> I can reproduce. But it is not dependent on the version as this problem
> seems to be more than 10-year old. Here's the problem: there is a
> constant num_lastfilepos (=100) and LyX stops reading file positions
> after it has this many. (But it is still writing the positions when
> closing the file, which is why one still sees the positions in the
> session file.) Now, the file positions are stored ordered by the file
> and path name. Thus, instead of forgetting file positions depending on
> their age, it forgets them depending on the alphabet.
> 
> Two solutions:
> 1) remove the arbitrary limit num_lastfilepos.
> 2) store the file positions by age. (Internally, replace the map by a
> vector.)
> 
> Are there objections regarding the simplest solution 1) ?

I imagine it is there for performance reasons?

The original commit does not give details on why the limit exists:
b2effebe

LastFilePosSection::read() is called for every recent file when opening
LyX. I was hoping it was only called when actually opening a file.

If you are confident there is no performance concern then I don't see
why not remove the limit. If you are not sure, then maybe do a test with
as many recent files as our limit allows?

I think you could compare the output from the following command

  time mylyx master --execute lyx-quit

before and after your change.

Scott


signature.asc
Description: PGP signature

Re: C++ "good practices" regarding constifying a function parameter?

[Scott Kostyshak]

On Wed, Jul 27, 2016 at 12:06:51PM +0100, Guillaume Munch wrote:

> Hi Scott,
> 
> 
> - f(…, bool b)
> + f(…, bool const b)
> 
> This being passed by value, this changes nothing for the declaration.
> The two signatures are even considered equal for overloading (if it
> came to this). So I recommend leaving the header unchanged.

Good to know. I often switch back and forth between the .cpp and .h
files to understand a group of functions. Sometimes I would read the
signature of the declaration in the .h file and then go directly to the
function body without looking at the signature of it. But now I realize
this is a bad idea because the two signatures are not necessarily the
same. const can be different and even the parameter names are not
required to be the same, so now I know that when I go to the
implementation, I should not skip over the implementation's signature.

> For the function definition, the difference is in terms of
> documentation. If you are adding const in the definition because you
> find it clearer this way, then it is a good reason to change it.

Yes this was my intention. To me it has the same purpose as declaring a
local variable const in the body of a function. For example, if I see
that "param" is used at the end of a function I know that "param" is a
const parameter, I don't have to read the whole function looking to see
if param was modified in the middle. In addition to readability, I think
it can in some (unlikely) situations prevent future coding mistakes.
e.g. I might write the code and at the end of the body I use "param"
making the assumption that it has the same value that it started with.
If someone (e.g. future me) comes along and changes the value in the
middle of the function they'll get a compiler error and think twice
before removing const. I think the benefits are especially useful for
long functions.

Do you also const parameters and const local variables useful for
understanding and future-proofing functions or not really? If no, do you
find them annoying or just don't care?

> In this case, you can see "const" as a detail of implementation that the
> user of the header does not care about. If you see it that way, then the
> difference between the declaration and the definition looks strange no
> longer.

I see, makes sense now.

> The answer would be different if the const was somewhere inside, e.g.:
> - f(…, bool & b)
> + f(…, bool const & b)
> in which case the conveyed meaning is entirely different, and it would
> be a matter of priority to correctly document the declaration.

Indeed, I do see the difference.

So to double-check, no one is against the .cpp change I proposed, right?
(I will not commit the .h change after this helpful conversation)

Thanks for this detailed explanation, Guillaume. I think that small
things like this help me build up a better understanding of C++.

Scott


signature.asc
Description: PGP signature

Re: new compilation warning in 2.2.x branch

[Jean-Marc Lasgouttes]

Yes definitely.

JMarc

Le 26 juillet 2016 19:33:57 GMT+02:00, Richard Heck  a écrit :
>In this case, it looks as if it really should be a double: I.e., I can
>make
>it a double, and it still compiles.

French manuals and UI localization updates

[Jean-Pierre Chrétien]

Hello

commit 866b6d0ea33155c54b0e2efa3f8cd6759ade4429
Author: jpc 
Date:   Wed Jul 27 18:12:06 2016 +0100

  Update French UI localization

commit 14c308749f00c94af36ac95165dee614ef0c5ce1
Author: jpc 
Date:   Wed Jul 27 18:09:40 2016 +0100

   Update French Customization, Math, Tutorial and UserGuide manuals

Richard, ok to push ?

--
Jean-Pierre

Re: [LyX/2.2.x] Start preparations for 2.2.1.

[Kornel Benko]

Am Mittwoch, 27. Juli 2016 um 17:37:02, schrieb Jean-Pierre Chrétien 

> Le 26/07/2016 09:23, Guenter Milde a écrit :
> > On 2016-07-25, Guillaume Munch wrote:
> >> Le 24/07/2016 à 16:48, Jean-Pierre Chrétien a écrit :
> >>> Le 22/07/2016 16:21, Guillaume Munch a écrit :
>  Le 22/07/2016 à 14:31, Jean-Pierre Chrétien a écrit :
> >
> > ...
> >
> > What about "Export" rather than "Format"? This covers all three items in
> > the subwindow.
> >
>  It has the same issue as Output: "save transient properties" controls
>  the source file, rather than an output file.
> 
> In that case, what prevents the "Save Transient Properties" checkbox to be 
> inserted in the Document menu, before or after the "Compressed" and "Disable 
> Editing" checkboxes? Is it the fact that no tooltip is allowed there?
> Submenu title "Ouput" would remain appropriate as it is if this checkbox was 
> not 
> in the submenu.
> >
> 
> >
> >>> I agree with this, what about "LaTeX export panel" instead (and "LaTeX
> >>> export as window title)?
> >
> >> 1. no "LaTeX" since one can access any output format
> 
> Shame on me, I'd never seen that the pane could also display other sources 
> than 
> LaTeX. The pane title is thus badly named 'LaTeX Source".
> 
> >> To come back to your original source of disagreement, I just noticed
> >> that "Format" is currently used in the source panel in the same way as I
> >> meant it, and is already translated into "Format" in French (but your
> >> problem was more a collision with « Format local » maybe).
> >
> > IMV, the use of "Format" in the source pane is correct and unambiguous.
> 
> After reviewing the various uses of Format in the menus and the translations 
> I 
> made, I eventually agree upon this, as I use Format in French in 
> Preferences->File Formats.
> 
> So what about "LaTeX source"? Replace it by "Source Code"? or simply "Code"?
> Or make it follow a change of the selected format?
> 

Or 'Preview Output Source Formats'?

Kornel

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

Re: [LyX/2.2.x] Start preparations for 2.2.1.

[Jean-Pierre Chrétien]

Le 26/07/2016 09:23, Guenter Milde a écrit :

On 2016-07-25, Guillaume Munch wrote:

Le 24/07/2016 à 16:48, Jean-Pierre Chrétien a écrit :

Le 22/07/2016 16:21, Guillaume Munch a écrit :

Le 22/07/2016 à 14:31, Jean-Pierre Chrétien a écrit :


...


What about "Export" rather than "Format"? This covers all three items in
the subwindow.



It has the same issue as Output: "save transient properties" controls
the source file, rather than an output file.


In that case, what prevents the "Save Transient Properties" checkbox to be 
inserted in the Document menu, before or after the "Compressed" and "Disable 
Editing" checkboxes? Is it the fact that no tooltip is allowed there?
Submenu title "Ouput" would remain appropriate as it is if this checkbox was not 
in the submenu.







I agree with this, what about "LaTeX export panel" instead (and "LaTeX
export as window title)?



1. no "LaTeX" since one can access any output format


Shame on me, I'd never seen that the pane could also display other sources than 
LaTeX. The pane title is thus badly named 'LaTeX Source".



To come back to your original source of disagreement, I just noticed
that "Format" is currently used in the source panel in the same way as I
meant it, and is already translated into "Format" in French (but your
problem was more a collision with « Format local » maybe).


IMV, the use of "Format" in the source pane is correct and unambiguous.


After reviewing the various uses of Format in the menus and the translations I 
made, I eventually agree upon this, as I use Format in French in 
Preferences->File Formats.


So what about "LaTeX source"? Replace it by "Source Code"? or simply "Code"?
Or make it follow a change of the selected format?

--
Jean-Pierre

Re: #10310: Session handling does not restore cursor position

[Guillaume Munch]

Le 27/07/2016 à 14:05, Davide Anchisi a écrit :

Yes, it is written in ~/.lyx/session every time I exit LyX.
It seems it is not read back (or used) when opening LyX again.
But, even stranger, it does work for some files, apparently those
created using LyX versions 2.1. For those files the cursor position is
correctly restored even when the position and/or the file is modified
with v. 2.2.1. And even for them the cursor position is written in
~/.lyx/session with the same syntax, e.g.:
12, 4, /home/myHome/file.lyx



I can reproduce. But it is not dependent on the version as this problem
seems to be more than 10-year old. Here's the problem: there is a
constant num_lastfilepos (=100) and LyX stops reading file positions
after it has this many. (But it is still writing the positions when
closing the file, which is why one still sees the positions in the
session file.) Now, the file positions are stored ordered by the file
and path name. Thus, instead of forgetting file positions depending on
their age, it forgets them depending on the alphabet.

Two solutions:
1) remove the arbitrary limit num_lastfilepos.
2) store the file positions by age. (Internally, replace the map by a
vector.)

Are there objections regarding the simplest solution 1) ?


Guillaume

Re: #10310: Session handling does not restore cursor position

[Davide Anchisi]

Yes, it is written in ~/.lyx/session every time I exit LyX.
It seems it is not read back (or used) when opening LyX again.
But, even stranger, it does work for some files, apparently those created
using LyX versions 2.1. For those files the cursor position is correctly
restored even when the position and/or the file is modified with v. 2.2.1.
And even for them the cursor position is written in  ~/.lyx/session with
the same syntax, e.g.:
12, 4, /home/myHome/file.lyx

2016-07-26 21:31 GMT+02:00 LyX Ticket Tracker :

> #10310: Session handling does not restore cursor position
> --+-
>  Reporter:  danchisi  |   Owner:  lasgouttes
>  Type:  defect|  Status:  new
>  Priority:  normal|   Milestone:
> Component:  general   | Version:  2.2.1
>  Severity:  normal|  Resolution:
>  Keywords:|
> --+-
>
> Comment (by skostysh):
>
>  Replying to [ticket:10310 danchisi]:
>
>  I believe this information is stored in the "sessions" file in your user
>  directory (see Help > About). Is the location indeed written to it when
>  you exit LyX?
>
> --
> Ticket URL: 
> The LyX Project 
> LyX -- The Document Processor
>

Re: C++ "good practices" regarding constifying a function parameter?

[Guillaume Munch]

Le 27/07/2016 à 01:54, Scott Kostyshak a écrit :

The attached patch constifies a function parameter. My question is
whether this patch causes more pain to other developers than it does
good to the code.

The patch modifies a header that is included in many of our .cpp files,
so will cause a significant amount of recompilation.

I think I will come across this scenario in the future so I am curious:
what are your preferences?

(1) Do not commit any part of the patch because it is so minor.
(2) Commit the .cpp part, but not the .h part (this symmetry is not
checked by C++ since the constness only matters within the body of the
function).
(3) Commit the full patch, as is.
(4) Commit the full patch, as is. But save up these commits and push
only when I have a few of them or right after a commit that will cause
recompilation anyway.



Hi Scott,


- f(…, bool b)
+ f(…, bool const b)

This being passed by value, this changes nothing for the declaration.
The two signatures are even considered equal for overloading (if it
came to this). So I recommend leaving the header unchanged.

For the function definition, the difference is in terms of
documentation. If you are adding const in the definition because you
find it clearer this way, then it is a good reason to change it.

In this case, you can see "const" as a detail of implementation that the
user of the header does not care about. If you see it that way, then the
difference between the declaration and the definition looks strange no
longer.

The answer would be different if the const was somewhere inside, e.g.:
- f(…, bool & b)
+ f(…, bool const & b)
in which case the conveyed meaning is entirely different, and it would
be a matter of priority to correctly document the declaration.


Guillaume

Possibly wrong libraries on windows binaries

[Alberto Escrig Vidal]

Dear LyX developers

I've just updated to 2.2.1 and it doesn't work on my windows 7 32-bit machine. 
On startup, I get msvcp140.dll is not a valid Windows app or something like 
this.

It seems that you linked LyX against the 64bit version of the MSVC++ runtime 
libraries. Indeed if I run this command on cygwing I get:

$ file /cygdrive/c/Program\ Files/LyX\ 2.2/bin/msvcp140.dll
/cygdrive/c/Program Files (x86)/LyX 2.2/bin/msvcp140.dll: PE32+ executable 
(DLL) (console) x86-64, for MS Windows

I already had the Visual Studio 2015 32-bit redistributable installed on my 
computer, so I renamed mvcp140.dll and vsrunrime14.dll to see what happens but 
I get some scary name-mangling problems (though LyX apparently got started).

Please let me know.

Shall I meanwhile downgrade to 2.1.5?

Thanks



CONFIDENTIALITY NOTICE
The information in this e-mail message and any files transmitted with it are 
confidential/ privileged and intended solely for the person(s) to whom they are 
addressed. If you are not the intended recipient, or employee or person acting 
on behalf of the intended recipient, or have received this message by mistake, 
you are notified that disclosing, distributing or reproducing this message or 
files is strictly prohibited. If you receive this message or files in error, 
please notify us immediately and return the original message to: 
i...@itc.uji.es. Thank you.