Le 18/07/2020 à 19:05, Enrico Forestieri a écrit :
On Sat, Jul 18, 2020 at 12:06:26AM +0200, Jean-Marc Lasgouttes wrote:
Now that I have a HiDpi screen, I really feel the need to do something.
This trivial patch works pretty well with Linux/X11 :)
Could someone try it it with Windows/Wayland
On Sat, Jul 18, 2020 at 12:06:26AM +0200, Jean-Marc Lasgouttes wrote:
> Now that I have a HiDpi screen, I really feel the need to do something.
>
> This trivial patch works pretty well with Linux/X11 :)
>
> Could someone try it it with Windows/Wayland/macOS (with normal dpi or
&
Now that I have a HiDpi screen, I really feel the need to do something.
This trivial patch works pretty well with Linux/X11 :)
Could someone try it it with Windows/Wayland/macOS (with normal dpi or
HiDpi).
I will try a few cases myself, but I could use some help.
JMarc
>F
On 7/7/20 1:09 PM, Jürgen Spitzmüller wrote:
> Am Dienstag, den 07.07.2020, 19:36 +0300 schrieb Yuval Deutscher:
>> I hereby agree that my contributions to LyX be licensed under the
>> General Public License, Version 2 or any later version.
> Thank you very much. Committed to master.
>
> Riki,
Am Dienstag, den 07.07.2020, 19:36 +0300 schrieb Yuval Deutscher:
> I hereby agree that my contributions to LyX be licensed under the
> General Public License, Version 2 or any later version.
Thank you very much. Committed to master.
Riki, this is candidate for stable.
Jürgen
signature.asc
modercv's layout according to the
> > documentation of the cventry command in moderncv.
>
> Thanks for this. Could you please re-send the patch as an attachment,
> and also add a license agreement assuring that your contributions to
> LyX might be licensed under the General Public
Am Samstag, den 04.07.2020, 22:03 +0300 schrieb Yuval Deutscher:
> Update the user-facing strings in modercv's layout according to the
> documentation of the cventry command in moderncv.
Thanks for this. Could you please re-send the patch as an attachment,
and also add a license agr
Update the user-facing strings in modercv's layout according to the
documentation of the cventry command in moderncv.
Signed-off-by: Yuval Deutscher
---
lib/layouts/moderncv.layout | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/lib/layouts/moderncv.layout
On Fri, Mar 20, 2020 at 03:08:20PM +0100, Jean-Marc Lasgouttes wrote:
> Le 20/03/2020 à 14:49, Scott Kostyshak a écrit :
> > > I would say that we don't care, so width() is better since is is shorter
> > > and
> > > easier to understand :)
> >
> > Just to double-check: By width() you mean
On Fri, Mar 20, 2020 at 12:29:34PM +0100, Kornel Benko wrote:
> Am Thu, 19 Mar 2020 18:53:46 -0400
> schrieb Scott Kostyshak :
>
> > See attached patch regarding our development script cat.py. It fixes a
> > Python 3 deprecation warning. However, I believe it changes behav
Le 20/03/2020 à 14:49, Scott Kostyshak a écrit :
I would say that we don't care, so width() is better since is is shorter and
easier to understand :)
Just to double-check: By width() you mean boundingRect().width(), and
yes
you are saying it is shorter than horizontalAdvance() because we do
On Fri, Mar 20, 2020 at 10:17:51AM +0100, Jean-Marc Lasgouttes wrote:
> Le 20/03/2020 à 03:41, Scott Kostyshak a écrit :
> > > The entry in the change log hints (from my understanding) that it is a
> > > renaming, but the blog article I linked to suggests things could be more
> > > complicated.
>
Am Thu, 19 Mar 2020 18:53:46 -0400
schrieb Scott Kostyshak :
> See attached patch regarding our development script cat.py. It fixes a
> Python 3 deprecation warning. However, I believe it changes behavior
> with Python 2. The script has a "python3" shebang line (see
>
Le 20/03/2020 à 03:41, Scott Kostyshak a écrit :
The entry in the change log hints (from my understanding) that it is a
renaming, but the blog article I linked to suggests things could be more
complicated.
Looking at the code, it does seem to be equivalent:
qreal QFontMetricsF::width(const
From what I understand, we are indeed writing custom text
> > > shaping/layouting code.
> >
> > Yes, but mostly for the code in GuiFontMetrics.
> >
> > > Attached is a patch. I don't propose to commit this patch; I just attach
> > > it to give an idea of
See attached patch regarding our development script cat.py. It fixes a
Python 3 deprecation warning. However, I believe it changes behavior
with Python 2. The script has a "python3" shebang line (see
3f03f0a447e), however that does not mean that it is not currently
compatible with Python
On Fri, Mar 13, 2020 at 11:17:57AM +0100, Jean-Marc Lasgouttes wrote:
> Le 13/03/2020 à 03:40, Scott Kostyshak a écrit :
> > I've tested this patch on Ubuntu 20.04 daily for Enchant 2.x, and on
> > Ubuntu 19.10 for Enchant 1.x.
>
> Do you need something for autoconf too?
I t
Le 13/03/2020 à 03:40, Scott Kostyshak a écrit :
I've tested this patch on Ubuntu 20.04 daily for Enchant 2.x, and on
Ubuntu 19.10 for Enchant 1.x.
Do you need something for autoconf too?
JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Am Thu, 12 Mar 2020 22:40:21 -0400
schrieb Scott Kostyshak :
> I've tested this patch on Ubuntu 20.04 daily for Enchant 2.x, and on
> Ubuntu 19.10 for Enchant 1.x.
>
> Kornel, any thoughts?
>
> Scott
Looks OK.
If that works for you, then +1.
Kornel
pgpe49J6O_Y
I've tested this patch on Ubuntu 20.04 daily for Enchant 2.x, and on
Ubuntu 19.10 for Enchant 1.x.
Kornel, any thoughts?
Scott
From 1314d3885ec6c477db18d2ef6628e4e217c6c089 Mon Sep 17 00:00:00 2001
From: Scott Kostyshak
Date: Thu, 12 Mar 2020 22:36:49 -0400
Subject: [PATCH] CMake build: find
On Wed, Mar 11, 2020 at 03:43:00PM +0100, Jean-Marc Lasgouttes wrote:
> Le 10/03/2020 à 15:31, Scott Kostyshak a écrit :
> > Perhaps the following be more reasonable and safer?
> >
> >setCursor(cur, cur.pit(), cur.pos());
> >
> > The above seems safe since I'm just changing "0" to
Le 10/03/2020 à 15:31, Scott Kostyshak a écrit :
Perhaps the following be more reasonable and safer?
setCursor(cur, cur.pit(), cur.pos());
The above seems safe since I'm just changing "0" to "cur.pos()", and I
don't see how the length of the paragraph can change after this
operation.
This
On Tue, Mar 10, 2020 at 04:56:35PM +0100, Pavel Sanda wrote:
> On Tue, Mar 10, 2020 at 10:31:10AM -0400, Scott Kostyshak wrote:
> > your questions. I tried to test regarding Pavel's concern, but I don't
> > know a situation when the depth changes;
>
> Actually you are likely right. The
On Tue, Mar 10, 2020 at 10:31:10AM -0400, Scott Kostyshak wrote:
> your questions. I tried to test regarding Pavel's concern, but I don't
> know a situation when the depth changes;
Actually you are likely right. The destruction of depth structure comes
with moving paragraphs lfuns, not
; > It has been this way for a long time, at least since 71f356c3.
> > >
> > > Attached is a patch to remove it so that the cursor position does not
> > > change when executing those actions.
> >
> > Is there a concern that these actions might invalidate the curso
necessary in my testing, but I'm wondering if
> > there's a case I'm missing. Or perhaps it is not necessary but is
> > desired behavior for some reason?
> >
> > It has been this way for a long time, at least since 71f356c3.
> >
> > Attached is a patch to remove it
t is not necessary but is
> desired behavior for some reason?
>
> It has been this way for a long time, at least since 71f356c3.
>
> Attached is a patch to remove it so that the cursor position does not
> change when executing those actions.
Is there a concern that these actions might invali
for a long time, at least since 71f356c3.
Attached is a patch to remove it so that the cursor position does not
change when executing those actions.
Scott
From 452256b432268ffd69abc9c615d4f8131b1357ca Mon Sep 17 00:00:00 2001
From: Scott Kostyshak
Date: Mon, 9 Mar 2020 20:01:53 -0400
Subject
Fix deprecation warnings from use of qSort() in master at 14f369b4.
Scott
signature.asc
Description: PGP signature
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On Tue, Mar 03, 2020 at 02:24:39PM -0500, Scott Kostyshak wrote:
> On Fri, Feb 28, 2020 at 02:35:18PM -0500, Scott Kostyshak wrote:
> > Compiling LyX with Qt 5.14.1 gives deprecation warnings, which breaks
> > compilation of LyX with -Werror. I'm working on a patch to address
On Thu, Mar 05, 2020 at 12:00:32PM +0100, Pavel Sanda wrote:
> On Tue, Mar 03, 2020 at 08:40:38PM -0500, Scott Kostyshak wrote:
> > When you dereference an iterator, isn't it usually expected to return the
> > object, not a pointer to the object?
>
> It might be we don't use that in lyx codebase,
On Tue, Mar 03, 2020 at 08:40:38PM -0500, Scott Kostyshak wrote:
> When you dereference an iterator, isn't it usually expected to return the
> object, not a pointer to the object?
It might be we don't use that in lyx codebase, but I don't have any particular
expectations for the underlying type.
On Tue, Mar 03, 2020 at 11:32:51PM +0100, Pavel Sanda wrote:
> On Tue, Mar 03, 2020 at 02:24:39PM -0500, Scott Kostyshak wrote:
> > understand what "**it" is, or how it works. Does this mean that somehow
> > a QTreeWidgetItem::operator* is defined or something like that?
>
> Yes,
On Tue, Mar 03, 2020 at 02:24:39PM -0500, Scott Kostyshak wrote:
> understand what "**it" is, or how it works. Does this mean that somehow
> a QTreeWidgetItem::operator* is defined or something like that?
Yes, https://doc.qt.io/qt-5/qtreewidgetitemiterator.html#operator-2a
P
--
lyx-devel
On Fri, Feb 28, 2020 at 02:35:18PM -0500, Scott Kostyshak wrote:
> Compiling LyX with Qt 5.14.1 gives deprecation warnings, which breaks
> compilation of LyX with -Werror. I'm working on a patch to address
> these. I'm sending this message just to avoid duplication of effort in
> case
t; > shaping/layouting code.
>
> Yes, but mostly for the code in GuiFontMetrics.
>
> > Attached is a patch. I don't propose to commit this patch; I just attach
> > it to give an idea of how many replacements are needed and in case
> > someone can check that we do indeed want horizo
e.
Yes, but mostly for the code in GuiFontMetrics.
Attached is a patch. I don't propose to commit this patch; I just attach
it to give an idea of how many replacements are needed and in case
someone can check that we do indeed want horizontalAdvance() as the
replacement in all cases and not boundi
On Fri, Feb 28, 2020 at 02:35:18PM -0500, Scott Kostyshak wrote:
> Compiling LyX with Qt 5.14.1 gives deprecation warnings, which breaks
> compilation of LyX with -Werror. I'm working on a patch to address
> these. I'm sending this message just to avoid duplication of effort in
> case
Compiling LyX with Qt 5.14.1 gives deprecation warnings, which breaks
compilation of LyX with -Werror. I'm working on a patch to address
these. I'm sending this message just to avoid duplication of effort in
case anyone else comes across these warnings. I'll hopefully finish the
patch next week
> > > On Mon, Feb 24, 2020 at 11:05:51AM -0500, Scott Kostyshak wrote:
> > > > >
> > > > > Apparently another approach would be to add the following:
> > > > >
> > > > > memset(_event, 0, sizeof(padded_event));
tt Kostyshak wrote:
> > > >
> > > > Apparently another approach would be to add the following:
> > > >
> > > > memset(_event, 0, sizeof(padded_event));
> > > >
> > > > Valgrind does not complain when this line is added to the union patch.
wing:
> > >
> > > memset(_event, 0, sizeof(padded_event));
> > >
> > > Valgrind does not complain when this line is added to the union patch.
> >
> > I am baffled. The last suggestion I have is trying
> >
> > alignas(32) xcb_sel
t; > Valgrind does not complain when this line is added to the union patch.
>
> I am baffled. The last suggestion I have is trying
>
> alignas(32) xcb_selection_notify_event_t nev = {0};
Valgrind still gives the error. I attach the full Valgrind log.
Scott
==20157== Memcheck, a
On Mon, Feb 24, 2020 at 11:05:51AM -0500, Scott Kostyshak wrote:
>
> Apparently another approach would be to add the following:
>
> memset(_event, 0, sizeof(padded_event));
>
> Valgrind does not complain when this line is added to the union patch.
I am baffled. The last
> > > > > > } padded_event;
> > > > > > > auto & nev = padded_event.event;
> > > > > >
> > > > > > Enrico, I propose that you commit. Thanks for the fix.
> > > > >
> > > > > Accor
t; > } padded_event;
> > > > > > auto & nev = padded_event.event;
> > > > >
> > > > > Enrico, I propose that you commit. Thanks for the fix.
> > > >
> > > > According to the followups to the post by Pavel and com
On Mon, Feb 24, 2020 at 11:19:50AM +0100, Jean-Marc Lasgouttes wrote:
>
> BTW, our download page says that we only support windows 7 and later since
> June 2016.
But the sources would still allow compiling with Xp and earlier versions.
> A relevant bug: https://www.lyx.org/trac/ticket/10186
I
Le 24/02/2020 à 10:57, Stephan Witt a écrit :
On Mac OS 10.8.5 (2012+) with Apple clang 4.0 the build
of lyx-2.3.4.2 fails with compiler errors in boost:
ATM, I’m able to build LyX on Mac OS 10.11.6 (El Capitan 2015).
Thanks for checking. I guess we can update README and the download page.
Am 23.02.2020 um 16:07 schrieb Jean-Marc Lasgouttes :
>
> Le 23/02/2020 à 15:42, Stephan Witt a écrit :
>> What’s the audience of this file?
>> Perhaps it’s possible to download a LyX for 10.4 - but is this the
>> intention of the authors of this list of requirements?
>
> The question is: is it
ng to the followups to the post by Pavel and commit 748bb5a0,
> > > I think that the C++11 alignas solution is preferred. Given that you
> > > can check its effectiveness, I think that it is better that you
> > > commit it.
> >
> > I tried to test but probably
Windows, our implementation of realPath() works
> >>> only with
> >>> file names but does not work with directory names. On the other hand,
> >>> QFileInfo::canonicalFilePath() does not resolve junctions (directory
> >>> symlinks).
> >>
On Sun, Feb 23, 2020 at 12:04:20PM -0500, Scott Kostyshak wrote:
> On Sun, Feb 23, 2020 at 03:10:37PM +0100, Enrico Forestieri wrote:
> > On Sun, Feb 23, 2020 at 08:22:55AM -0500, Scott Kostyshak wrote:
> > > On Wed, Feb 19, 2020 at 08:07:46PM +0100, Enrico Forestieri wrote:
> > > > On Wed, Feb
with directory names. On the other hand,
>>> QFileInfo::canonicalFilePath() does not resolve junctions (directory
>>> symlinks).
>>
>> Dropping support for Windows Xp, the attached patch works for me with
>> both files and directories. I am going to apply it, as I thi
t5XcbQpa.so.5.12.4)
==14514==by 0x9C63286: ??? (in
/usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5.12.4)
==14514==by 0x633684C: g_main_context_dispatch (in
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6200.1)
==14514==by 0x6336ACF: ??? (in
/usr/lib/x86_64-linux-gnu/libglib-2.
Le 23/02/2020 à 15:42, Stephan Witt a écrit :
What’s the audience of this file?
Perhaps it’s possible to download a LyX for 10.4 - but is this the
intention of the authors of this list of requirements?
The question is: is it possible to compile LyX so that it runs under
MacOS X 10.4? But
f realPath() works only
>>>> with
>>>> file names but does not work with directory names. On the other hand,
>>>> QFileInfo::canonicalFilePath() does not resolve junctions (directory
>>>> symlinks).
>>> Dropping support for Windows Xp, the at
es. On the other hand,
>>> QFileInfo::canonicalFilePath() does not resolve junctions (directory
>>> symlinks).
>> Dropping support for Windows Xp, the attached patch works for me with
>> both files and directories. I am going to apply it, as I think it is
>> not con
On Sun, Feb 23, 2020 at 08:22:55AM -0500, Scott Kostyshak wrote:
> On Wed, Feb 19, 2020 at 08:07:46PM +0100, Enrico Forestieri wrote:
> > On Wed, Feb 19, 2020 at 01:19:54PM -0500, Scott Kostyshak wrote:
> > >
> > > It seems I committed too soon. Sorry for not waiting. Both the macro
> > >
On Wed, Feb 19, 2020 at 08:07:46PM +0100, Enrico Forestieri wrote:
> On Wed, Feb 19, 2020 at 01:19:54PM -0500, Scott Kostyshak wrote:
> >
> > It seems I committed too soon. Sorry for not waiting. Both the macro
> > approach and Enrico's proposal are cleaner than my approach. I was
> > planning to
.
Mystery solved. On Windows, our implementation of realPath() works only with
file names but does not work with directory names. On the other hand,
QFileInfo::canonicalFilePath() does not resolve junctions (directory
symlinks).
Dropping support for Windows Xp, the attached patch works for me
On Sun, Feb 23, 2020 at 12:20:16PM +0100, Stephan Witt wrote:
> Am 23.02.2020 um 00:27 schrieb Enrico Forestieri :
> >
> > On Thu, Feb 20, 2020 at 08:24:41AM +0100, Enrico Forestieri wrote:
> >> On Wed, Feb 19, 2020 at 10:33:45PM +0100, Stephan Witt wrote:
> >>>
> >>> What I wonder: there are
Am 23.02.2020 um 00:27 schrieb Enrico Forestieri :
>
> On Thu, Feb 20, 2020 at 08:24:41AM +0100, Enrico Forestieri wrote:
>> On Wed, Feb 19, 2020 at 10:33:45PM +0100, Stephan Witt wrote:
>>>
>>> What I wonder: there are the Qt elements used. Why don’t we rely
>>> on the services of QFileInfo
ery solved. On Windows, our implementation of realPath() works only with
> file names but does not work with directory names. On the other hand,
> QFileInfo::canonicalFilePath() does not resolve junctions (directory
> symlinks).
Dropping support for Windows Xp, the attached patch works for me w
On Tue, Feb 18, 2020 at 07:55:13PM +0100, Enrico Forestieri wrote:
>
> Still, why realPath() returns a short path name in one case and not in the
> other case remains a mystery.
Mystery solved. On Windows, our implementation of realPath() works only with
file names but does not work with
On Thu, Feb 20, 2020 at 08:24:41AM +0100, Enrico Forestieri wrote:
> On Wed, Feb 19, 2020 at 10:33:45PM +0100, Stephan Witt wrote:
> >
> > What I wonder: there are the Qt elements used. Why don’t we rely
> > on the services of QFileInfo class? E.g. canonicalFilePath() and
> > friends? Are there
t;>> On Tue, Feb 18, 2020 at 09:43:07AM +0100, Stephan Witt wrote:
>>>>>
>>>>> Because I’m unable to test it with other PDF viewers with SyncTeX
>>>>> support and/or to test it on Linux and Windows I post the patch
>>>>> and
Le 20/02/2020 à 14:42, Pavel Sanda a écrit :
This is my personal opinion and others might see it differently but I am
somewhat frustrated with appearing regressions that are not getting fixed even
if properly reported to the bug tracker and the recent decision to hide LTS
releases with stability
On Thu, Feb 20, 2020 at 01:01:27PM +0100, Enrico Forestieri wrote:
> On Thu, Feb 20, 2020 at 03:09:56AM -0500, Richard Kimberly Heck wrote:
> > On 2/20/20 2:24 AM, Enrico Forestieri wrote:
> > > On Wed, Feb 19, 2020 at 10:33:45PM +0100, Stephan Witt wrote:
> > >
> > >> What I wonder: there are the
save doesn’t guarantee
>> a match so a check for the match is needed after all.
>>
>> This makes me unsure what should be done in this case.
>> Ignore it or warn about it or try something else?
>
> Please, see suggestion below.
Oh, yes. That’s pre
On Thu, Feb 20, 2020 at 09:37:12AM +0100, Stephan Witt wrote:
> Hi all,
>
> the last one of the potential memory leaks is a little bit trickier.
>
> The loop logic for subcatItem if cats contains catsave doesn’t guarantee
> a match so a check for the match is needed after all.
>
> This makes me
On Thu, Feb 20, 2020 at 03:09:56AM -0500, Richard Kimberly Heck wrote:
> On 2/20/20 2:24 AM, Enrico Forestieri wrote:
> > On Wed, Feb 19, 2020 at 10:33:45PM +0100, Stephan Witt wrote:
> >
> >> What I wonder: there are the Qt elements used. Why don’t we rely
> >> on the services of QFileInfo class?
Am Wed, 19 Feb 2020 22:45:12 +0100
schrieb Jean-Marc Lasgouttes :
> Le 19 février 2020 22:25:31 GMT+01:00, Pavel Sanda a écrit :
> >So the oldest distro on which I regularly compile lyx master has gcc
> >4.8.
> >Because I suspect no one around is using even older config we can't
> >really
>
Hi all,
the last one of the potential memory leaks is a little bit trickier.
The loop logic for subcatItem if cats contains catsave doesn’t guarantee
a match so a check for the match is needed after all.
This makes me unsure what should be done in this case.
Ignore it or warn about it or try
On 2/20/20 2:24 AM, Enrico Forestieri wrote:
> On Wed, Feb 19, 2020 at 10:33:45PM +0100, Stephan Witt wrote:
>
>> What I wonder: there are the Qt elements used. Why don’t we rely
>> on the services of QFileInfo class? E.g. canonicalFilePath() and
>> friends? Are there historical reasons only?
>
gt; >>>
> >>> Because I’m unable to test it with other PDF viewers with SyncTeX
> >>> support and/or to test it on Linux and Windows I post the patch
> >>> and it would be nice if you can test if it breaks something used
> >>> to work.
> >
Le 19 février 2020 22:25:31 GMT+01:00, Pavel Sanda a écrit :
>So the oldest distro on which I regularly compile lyx master has gcc
>4.8.
>Because I suspect no one around is using even older config we can't
>really
>guarantee 4.7 (stand up if I am wrong) so we should change INSTALL
>instructions
yncTeX
>>> support and/or to test it on Linux and Windows I post the patch
>>> and it would be nice if you can test if it breaks something used
>>> to work.
>>
>> It works for me on linux and cygwin, but does not on native windows.
>> Inserting so
On Wed, Feb 19, 2020 at 06:13:08PM +0100, Pavel Sanda wrote:
> > We are requiring C++11 these days, right?
>
> Can't remember, notions of gcc 4.7 in INSTALL is not strongly indicative of
> that ;)
> Need to check whether one of my antique system still compiles with 4.7 or 4.8,
> maybe we can
On Wed, Feb 19, 2020 at 01:19:54PM -0500, Scott Kostyshak wrote:
>
> It seems I committed too soon. Sorry for not waiting. Both the macro
> approach and Enrico's proposal are cleaner than my approach. I was
> planning to pursue the macro approach in a follow-up commit.
Apparently, the macro
On Wed, Feb 19, 2020 at 07:22:36PM +0100, Pavel Sanda wrote:
> On Wed, Feb 19, 2020 at 06:28:51PM +0100, Enrico Forestieri wrote:
> > Uh? In the Requirements section I read:
> >
> > First of all, you will need a C++11 standard conforming compiler, like gcc
> > (at least 4.7) or clang.
>
> My
On Wed, Feb 19, 2020 at 06:28:51PM +0100, Enrico Forestieri wrote:
> Uh? In the Requirements section I read:
>
> First of all, you will need a C++11 standard conforming compiler, like gcc
> (at least 4.7) or clang.
My undesrtanding was that only 4.8 is C++11 complete, especially wrt
On Wed, Feb 19, 2020 at 06:28:51PM +0100, Enrico Forestieri wrote:
> On Wed, Feb 19, 2020 at 06:13:08PM +0100, Pavel Sanda wrote:
> > On Wed, Feb 19, 2020 at 05:24:46PM +0100, Enrico Forestieri wrote:
> > > > Did not try, but I am afraid generally it won't, because
> > > >
On Wed, Feb 19, 2020 at 06:13:08PM +0100, Pavel Sanda wrote:
> On Wed, Feb 19, 2020 at 05:24:46PM +0100, Enrico Forestieri wrote:
> > > Did not try, but I am afraid generally it won't, because
> > > xcb_selection_notify_event_t is not enforced to have 32 bits,
> > > while that's requested by
On Wed, Feb 19, 2020 at 05:24:46PM +0100, Enrico Forestieri wrote:
> > Did not try, but I am afraid generally it won't, because
> > xcb_selection_notify_event_t is not enforced to have 32 bits,
> > while that's requested by underlying X routines. That's why
> > the padding by 0s.
>
> Ok, then
On Wed, Feb 19, 2020 at 08:42:57AM +0100, Pavel Sanda wrote:
> On Wed, Feb 19, 2020 at 08:24:43AM +0100, Enrico Forestieri wrote:
> > On Tue, Feb 18, 2020 at 09:49:08PM -0500, Scott Kostyshak wrote:
> > >
> > > Attached is a patch. I really don't know what I'm doi
On Wed, Feb 19, 2020 at 09:56:20AM -0500, Scott Kostyshak wrote:
> If there is interest, I can work on a patch for using the macro.
It would reduce the work of relearning the topic for someone
stumbling upon this TODO in 5 years.
> Should I condition on the Qt version and if it is les
On Wed, Feb 19, 2020 at 09:53:35AM -0500, Scott Kostyshak wrote:
> On Wed, Feb 19, 2020 at 11:51:58AM +0100, Jean-Marc Lasgouttes wrote:
> > Stealing the definition of the macro when we do not have it is the best
> > solution IMO.
>
> I put in the patch with comments
On Wed, Feb 19, 2020 at 11:51:58AM +0100, Jean-Marc Lasgouttes wrote:
> Stealing the definition of the macro when we do not have it is the best
> solution IMO.
I put in the patch with comments addressing both yours and Pavel's ideas
(to either wait until Qt 5.6.3 is required, or t
Stealing the definition of the macro when we do not have it is the best
solution IMO.
JMarc
Le 19 février 2020 08:39:35 GMT+01:00, Pavel Sanda a écrit :
>On Tue, Feb 18, 2020 at 09:49:08PM -0500, Scott Kostyshak wrote:
>> Could anyone take a close look at this? If there is a better fix,
On Wed, Feb 19, 2020 at 08:24:43AM +0100, Enrico Forestieri wrote:
> On Tue, Feb 18, 2020 at 09:49:08PM -0500, Scott Kostyshak wrote:
> >
> > Attached is a patch. I really don't know what I'm doing. The use of
> > calloc scares me. I just used the xcb_send_event man page
On Tue, Feb 18, 2020 at 09:49:08PM -0500, Scott Kostyshak wrote:
> Could anyone take a close look at this? If there is a better fix, please
> go ahead.
Looks OK to me.
I would just put into comments TODO to switch to
Q_DECLARE_XCB_EVENT(event, xcb_selection_notify_event_t); once we require qt >=
On Tue, Feb 18, 2020 at 09:49:08PM -0500, Scott Kostyshak wrote:
>
> Attached is a patch. I really don't know what I'm doing. The use of
> calloc scares me. I just used the xcb_send_event man page and
> experimented until compilation and valgrind did not complain.
>
> Could a
)
(in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.12.4)
This Valgrind error can be triggered by just starting a new document, typing
"abc", doing "shift + " to select "c", and then quitting LyX.
Attached is a patch. I really don't know what I'm doing. The use of
calloc scare
On Tue, Feb 18, 2020 at 07:36:54PM +0100, Enrico Forestieri wrote:
> On Tue, Feb 18, 2020 at 09:43:07AM +0100, Stephan Witt wrote:
> >
> > Because I’m unable to test it with other PDF viewers with SyncTeX
> > support and/or to test it on Linux and Windows I post the patch
>
On Tue, Feb 18, 2020 at 09:43:07AM +0100, Stephan Witt wrote:
>
> Because I’m unable to test it with other PDF viewers with SyncTeX
> support and/or to test it on Linux and Windows I post the patch
> and it would be nice if you can test if it breaks something used
> to work.
> expression is OK? I do not know how to test it.
>
> I would be more happy to just rewrite it with a normal loop.
I agree but cannot provide a patch. I don’t know how to test it.
Stephan
>
> - Lambda expression will break older gcc's and I do not find that fortunate
>
kup
always, IMO. The attached patch does this. It works very well on Mac.
Because I’m unable to test it with other PDF viewers with SyncTeX
support and/or to test it on Linux and Windows I post the patch
and it would be nice if you can test if it breaks something used
to work.
[Note: the patch conta
ko in the code.
I think the patch is OK. The removed inautoarg assignment is indeed
practically useless.
Jürgen
signature.asc
Description: This is a digitally signed message part
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On Mon, Feb 17, 2020 at 04:35:05PM +0100, Stephan Witt wrote:
> Any comments or ok to apply?
The first snippet looks fine, the second is technically correct but it might
signalize that author (Juergen?) might have different logic in mind and there
is some thinko in the code.
Pavel
--
lyx-devel
, Stephan Witt wrote:
>>>>> Am 16.02.2020 um 17:54 schrieb Enrico Forestieri :
>>>>>> On Sun, Feb 16, 2020 at 02:52:52PM +0100, Stephan Witt wrote:
>>>>>>> The latest version of the mentioned patch I’ve used for 1. and 2. is
>>>>>> Than
601 - 700 of 76897 matches
Mail list logo
