Le 09/01/2021 à 10:41, Yuriy Skalko a écrit :
Also I noticed that these files are accessed on every keypress (even on
navigating document with arrows):
lib/images/undo.svgz
lib/images/textstyle-apply.svgz
lib/images/paste.svgz
Is it *really* necessary?
Only these files?
JMarc
--
lyx-devel
On 1/9/21 4:41 AM, Yuriy Skalko wrote:
>> I don't know enough about this stuff to say much. I think this would be
>> worth doing for 2.4.0, as it will probably provide for some speed as
>> well.
>>
>> Riki
>
> Committed at 854c9de.
>
> Also I noticed that these files are accessed on every keypress
I don't know enough about this stuff to say much. I think this would be
worth doing for 2.4.0, as it will probably provide for some speed as well.
Riki
Committed at 854c9de.
Also I noticed that these files are accessed on every keypress (even on
navigating document with arrows):
On 1/6/21 7:33 PM, Yuriy Skalko wrote:
> This should reduce memory allocations for this heavily used class.
I don't know enough about this stuff to say much. I think this would be
worth doing for 2.4.0, as it will probably provide for some speed as well.
Riki
--
lyx-devel mailing list
This should reduce memory allocations for this heavily used class.
Yuriy
From 15c952108bd6e79a712f159326804a145186b50b Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Thu, 7 Jan 2021 02:27:31 +0200
Subject: [PATCH] Add move constructor and move assignment operator for
FileName class
und that saving the preamble and closing the window
> (triggering saving the cursors position, etc) and opening it again
> breaks the second preamble tab text: don't bother looking into the
> patch, it needs a lot of fixing. I'm on it.
We should try to do this for 2.4.0. There are several
On Mon, Dec 28, 2020 at 09:20:26PM +0200, Yuriy Skalko wrote:
> As I see we already have latest 1.2.11 in master branch. So I'm committing
> the patch.
Indeed, oversight on my side... P
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Looks like a good idea. Note that we have in our tree zlib 1.2.8; dunno
what part of the code is using it, but there have been several bugfix
releases since then (currently 1.2.11).
Pavel
As I see we already have latest 1.2.11 in master branch. So I'm
committing the patch.
Yuriy
--
lyx
On 12/28/20 12:03 PM, Pavel Sanda wrote:
> On Mon, Dec 28, 2020 at 04:16:36PM +0200, Yuriy Skalko wrote:
>> zlib has implementation of crc32 algorithm, I've used it instead of Boost's
>> one.
>> Now another part of Boost can be thrown away :)
> Looks like a good idea. Note that we have in our tree
On Mon, Dec 28, 2020 at 04:16:36PM +0200, Yuriy Skalko wrote:
> zlib has implementation of crc32 algorithm, I've used it instead of Boost's
> one.
> Now another part of Boost can be thrown away :)
Looks like a good idea. Note that we have in our tree zlib 1.2.8; dunno
what part of the code is
On Mon, Dec 28, 2020 at 04:20:16PM +0200, Yuriy Skalko wrote:
> From 4f38e801eb930ca70b6a086f0aa553e1d19b21a3 Mon Sep 17 00:00:00 2001
> From: Yuriy Skalko
> Date: Tue, 22 Dec 2020 12:14:00 +0200
> Subject: [PATCH 6/7] Update Doxygen options to have more dependency graphs
>
&g
From 4f38e801eb930ca70b6a086f0aa553e1d19b21a3 Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Tue, 22 Dec 2020 12:14:00 +0200
Subject: [PATCH 6/7] Update Doxygen options to have more dependency graphs
Now many graphs are not generated due to excessive dependencies
(default node limit for one
zlib has implementation of crc32 algorithm, I've used it instead of
Boost's one.
Now another part of Boost can be thrown away :)
Yuriy
From ec7563f53dc84f80bef4ba067a61d7ec5a9d4bac Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Sat, 26 Dec 2020 21:23:44 +0200
Subject: [PATCH 7/7] Use crc32
Am Di., 15. Dez. 2020 um 05:34 Uhr schrieb Richard Kimberly Heck <
rikih...@lyx.org>:
> Fixed. Not sure what I was thinking.
>
Thank you.
Jürgen
>
> Riki
>
>
>
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On 12/12/20 12:08 PM, Richard Kimberly Heck wrote:
On 12/12/20 4:02 AM, Jürgen Spitzmüller wrote:
Am Freitag, dem 11.12.2020 um 22:49 +0100 schrieb Pavel Sanda:
Closing ERT inset produces thin box with no text visible.
This one's not caused by this patch. I suspect it has been introduced
Am Sonntag, dem 13.12.2020 um 13:38 +0100 schrieb Stephan Witt:
> With the attached patch I’m seeing this:
>
> frontends/qt/GuiApplication.cpp (2836): application palette change
> frontends/qt/GuiView.cpp (1433): application palette change
> frontends/qt/GuiView.cpp (1436): main
. (Switch from
>> dark mode back to normal.)
>
> I agree. It's probably not hard if we know which signal is emitted in
> that case.
>
> Jürgen
With the attached patch I’m seeing this:
frontends/qt/GuiApplication.cpp (2836): application palette change
frontends/qt/GuiView.
Am Sonntag, dem 13.12.2020 um 11:01 +0100 schrieb Stephan Witt:
> I’ll do some investigation how to detect the switch from or to dark
> mode at runtime.
> I think it’s worth to afford - see the effect below. (Switch from
> dark mode back to normal.)
I agree. It's probably not hard if we know
Am Samstag, dem 12.12.2020 um 15:05 +0100 schrieb Jean-Marc Lasgouttes:
> Le 12/12/2020 à 11:02, Jürgen Spitzmüller a écrit :
> > One issue I see is that the IconInfo inset does not use the adapted
> > icons; it loads the icon files directly via graphic inset.
> >
> > This could be fixed by using
On Friday, December 11, 2020 6:50:49 PM WET Jürgen Spitzmüller wrote:
> Dear all
>
> The attached patch addresses #8325 and adds support for dark mode in
> the workarea.
I tried the committed version. The improvement is striking, in some cases the
difference is between not to be
On 12/12/20 4:02 AM, Jürgen Spitzmüller wrote:
> Am Freitag, dem 11.12.2020 um 22:49 +0100 schrieb Pavel Sanda:
>> Closing ERT inset produces thin box with no text visible.
> This one's not caused by this patch. I suspect it has been introduced
> by 16834a32ad (Use LOCK symbol wi
Am Samstag, dem 12.12.2020 um 14:54 +0100 schrieb Pavel Sanda:
> I can change those few cases mentioned if you don't mind.
Go ahead. Note, though, that I already tried to address those, so
please re-check with master before changing.
Jürgen
signature.asc
Description: This is a digitally
Le 12/12/2020 à 11:02, Jürgen Spitzmüller a écrit :
One issue I see is that the IconInfo inset does not use the adapted
icons; it loads the icon files directly via graphic inset.
This could be fixed by using a QPixmap (or QImage) via QPainter
instead. Then we can just do the same overlay we do
On Sat, Dec 12, 2020 at 09:23:23AM +0100, Jürgen Spitzmüller wrote:
> Thanks. As I said, colors are just tentative now. They should be
> adapted by someone who uses dark mode once this is committed.
I can change those few cases mentioned if you don't mind. Pavel
--
lyx-devel mailing list
Am Freitag, dem 11.12.2020 um 22:49 +0100 schrieb Pavel Sanda:
> The icons inserted via insetinfo in manual are invisible (completely
> black), eg. section 13 in math manual.
One issue I see is that the IconInfo inset does not use the adapted
icons; it loads the icon files directly via graphic
Am Freitag, dem 11.12.2020 um 22:49 +0100 schrieb Pavel Sanda:
> Closing ERT inset produces thin box with no text visible.
This one's not caused by this patch. I suspect it has been introduced
by 16834a32ad (Use LOCK symbol with Minimalistic decoration, too.).
Riki?
Jürgen
signature.
Am Freitag, dem 11.12.2020 um 22:49 +0100 schrieb Pavel Sanda:
> I needed to override isDarkMode() to true to
> see the dark mode at all. All my toolbar stay in light mode, not sure
> how to turn them to dark mode here).
You need to manually select a dark qt theme via (e.g.
Am Freitag, dem 11.12.2020 um 22:49 +0100 schrieb Pavel Sanda:
> I am somewhat confused that that content of greyed out is (too) dark
> blue in math manual, but when I create greyedout inset in completely
> new file the color is (correctly) grey.
The reason is that a custom color for greyedout
Am Freitag, dem 11.12.2020 um 15:17 -0500 schrieb Richard Kimberly
Heck:
> I also don't use dark mode, but the approach seems right. One
> question I
> had, though, is whether it is better to adapt the icons on the fly
> (which needs processing power) or to write some script that would
> convert
Am Freitag, dem 11.12.2020 um 22:49 +0100 schrieb Pavel Sanda:
> On Fri, Dec 11, 2020 at 07:50:49PM +0100, Jürgen Spitzmüller wrote:
> > Thoughts?
>
> I gave it a try. The labels on (foot/lyx/comment/margin)notes are
> hard to read
> because the text is too light or not enough intense (margin)
On Fri, Dec 11, 2020 at 07:50:49PM +0100, Jürgen Spitzmüller wrote:
> Thoughts?
I gave it a try. The labels on (foot/lyx/comment/margin)notes are hard to read
because the text is too light or not enough intense (margin) IMHO.
I am somewhat confused that that content of greyed out is (too) dark
On 12/11/20 1:50 PM, Jürgen Spitzmüller wrote:
> Dear all
>
> The attached patch addresses #8325 and adds support for dark mode in
> the workarea.
>
> This adds another color to the ColorSet, x11darkhexname, and adds
> colors that work well with dark background for the seman
On 12/6/20 1:32 PM, Yuriy Skalko wrote:
Here is an update for this refactoring.
Makes a lot of sense.
Riki
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Here is an update for this refactoring.
Yuriy
From c36594e9ef489b5bb95a54b61576686bf92aaa1e Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Sun, 6 Dec 2020 18:01:09 +0200
Subject: [PATCH] Move implementation details to constructors. Amend 78f457796c
---
src/frontends/qt/DialogFactory.cpp
On 12/5/20 11:52 AM, Yuriy Skalko wrote:
> Please review this patch. The change is pretty straightforward. And
> according to the comment "// will be replaced by a proper factory..."
> that appeared in 2007 (169d3fa39e) it should be done long ago :)
I'll also have a look at t
Please review this patch. The change is pretty straightforward. And
according to the comment "// will be replaced by a proper factory..."
that appeared in 2007 (169d3fa39e) it should be done long ago :)
Yuriy
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.o
From 5d787f00733e53ee943466fc6d8e8fe45f6950b6 Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Thu, 3 Dec 2020 19:41:52 +0200
Subject: [PATCH] Implement proper Dialog factory instead of implicit link-time
dependencies
---
src/frontends/qt/DialogFactory.cpp | 239
Le 26/11/2020 à 22:42, Yuriy Skalko a écrit :
Ping...
Sorry, I did not realize you were still waiting. Go ahead.
JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Ping...
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
OK from me. These (duplicated) files are not part of the test suite.
Kornel
Thanks, committed.
Yuriy
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Am Sun, 15 Nov 2020 19:24:32 -0500
schrieb Scott Kostyshak :
> On Sun, Nov 15, 2020 at 06:47:47PM -0500, Richard Kimberly Heck wrote:
> > On 11/15/20 4:10 PM, Yuriy Skalko wrote:
> > > I've spotted some duplication in LyX repository related to math
> > > macros.
On Sun, Nov 15, 2020 at 06:47:47PM -0500, Richard Kimberly Heck wrote:
> On 11/15/20 4:10 PM, Yuriy Skalko wrote:
> > I've spotted some duplication in LyX repository related to math
> > macros. This patch deletes unneeded files.
>
> I'm clueless about test stuff. Scott? Korne
On 11/15/20 4:10 PM, Yuriy Skalko wrote:
> I've spotted some duplication in LyX repository related to math
> macros. This patch deletes unneeded files.
I'm clueless about test stuff. Scott? Kornel?
Riki
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/li
I've spotted some duplication in LyX repository related to math macros.
This patch deletes unneeded files.
Yuriy
From c0aab852629e96dcf202e99737a206783a73a71b Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Sun, 15 Nov 2020 22:22:47 +0200
Subject: [PATCH 1/3] Remove old duplicated files
On Wed, Nov 11, 2020 at 04:32:57PM +1300, Sam Crawley wrote:
> I hereby grant permission to license my contributions to LyX under the GNU
> General Public License, version 2 or any later version.
Thanks, I added you to credits.
Pavel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
On Sat, Nov 14, 2020 at 11:28:43AM -0500, Richard Kimberly Heck wrote:
> On 11/13/20 8:24 PM, Scott Kostyshak wrote:
> > On Sat, Nov 14, 2020 at 01:43:08AM +0100, Kornel Benko wrote:
> >> Am Sat, 14 Nov 2020 13:22:39 +1300
> >> schrieb "Sam Crawley" :
> >>
> >>> On Sat, 14 Nov 2020, at 12:36,
On 11/13/20 8:24 PM, Scott Kostyshak wrote:
> On Sat, Nov 14, 2020 at 01:43:08AM +0100, Kornel Benko wrote:
>> Am Sat, 14 Nov 2020 13:22:39 +1300
>> schrieb "Sam Crawley" :
>>
>>> On Sat, 14 Nov 2020, at 12:36, Kornel Benko wrote:
> Defined at development/checkurls/CMakeLists.txt:8
>
On Sat, Nov 14, 2020 at 01:43:08AM +0100, Kornel Benko wrote:
> Am Sat, 14 Nov 2020 13:22:39 +1300
> schrieb "Sam Crawley" :
>
> > On Sat, 14 Nov 2020, at 12:36, Kornel Benko wrote:
> > > >
> > > > Defined at development/checkurls/CMakeLists.txt:8
> > > > find_package(Perl REQUIRED)
> > > >
> >
Am Sat, 14 Nov 2020 13:22:39 +1300
schrieb "Sam Crawley" :
> On Sat, 14 Nov 2020, at 12:36, Kornel Benko wrote:
> > >
> > > Defined at development/checkurls/CMakeLists.txt:8
> > > find_package(Perl REQUIRED)
> > >
> > > Apparently you do not have '-DLYX_ENABLE_URLTESTS:BOOL=ON'. We should
> >
Am Fri, 13 Nov 2020 23:42:29 +0100
schrieb Kornel Benko :
> Am Sat, 14 Nov 2020 10:55:48 +1300
> schrieb "Sam Crawley" :
>
> > On Sat, 14 Nov 2020, at 00:12, Kornel Benko wrote:
> > > Running the test I get:
> > > ...
> > > Can't exec
> > >
Am Fri, 13 Nov 2020 23:42:29 +0100
schrieb Kornel Benko :
> Am Sat, 14 Nov 2020 10:55:48 +1300
> schrieb "Sam Crawley" :
>
> > On Sat, 14 Nov 2020, at 00:12, Kornel Benko wrote:
> > > Running the test I get:
> > > ...
> > > Can't exec
> > >
Am Sat, 14 Nov 2020 10:55:48 +1300
schrieb "Sam Crawley" :
> On Sat, 14 Nov 2020, at 00:12, Kornel Benko wrote:
> > Running the test I get:
> > ...
> > Can't exec
> > "/usr2/src/lyx/lyx-git/development/batchtests/bin/compare_custom.pl":
> > Permission denied at
> >
On Sat, 14 Nov 2020, at 00:12, Kornel Benko wrote:
> Running the test I get:
> ...
> Can't exec
> "/usr2/src/lyx/lyx-git/development/batchtests/bin/compare_custom.pl":
> Permission denied at
> /BUILD/BUILDMint18/BuildLyxGitQt5.9.5local-gcc8.4.0/lyx_batch.pl
> line 195.
> ...
>
> The attached
Am Fri, 13 Nov 2020 21:11:07 +1300
schrieb "Sam Crawley" :
> I've attached an updated patchset.
>
> As discussed, there's now a different parameter for "dialog-show compare"
> called
> "run-blocking", which is appropriate for calling from the command line. The
> tests now
> use this. A couple
On Thu, Nov 12, 2020 at 08:57:42PM +1300, Sam Crawley wrote:
> In that case, I'll add a different parameter to the LFUN to differentiate
> between case (ii) and (iii). So instead of passing "run" (and the two file
> names), you will pass "run-sync" to indicate that you want it to block for
>
ization issues.
> he (ii) case was hijacking slotOK call in initializeparams to mimick as
> if the comparison was normally launched by user.
>
> Now, your patch is fixing (iii) but at the same time undoing the logic
> of how error() and finished() is used in case (ii) so my concern is
>
usly
tried and per your comments might not even work due to synchronization issues.
he (ii) case was hijacking slotOK call in initializeparams to mimick as if the
comparison was normally launched by user.
Now, your patch is fixing (iii) but at the same time undoing the logic of how
error() and fini
On Wed, 11 Nov 2020, at 00:31, Pavel Sanda wrote:
> So I looked at the code for the command line run at this place looks
> good enough.
Thanks for having a look.
> I have another concerns though:
> 1) slotOK contains error() call which seems to be missed now. If you
> don't want it for
>
I hereby grant permission to license my contributions to LyX under the GNU
General Public License, version 2 or any later version.
Sam Crawley.
On Tue, 10 Nov 2020, at 23:39, Kornel Benko wrote:
> Am Sun, 8 Nov 2020 11:32:59 +0100
> schrieb Pavel Sanda :
>
> > On Sun, Nov 08, 2020 at
On Mon, Nov 09, 2020 at 01:03:47AM +0100, Pavel Sanda wrote:
> > > > @@ -343,7 +348,12 @@ bool GuiCompare::initialiseParams(std::string
> > > > const )
> > > > if (cmd.getArg(0) == "run") {
> > > > oldFileCB->setEditText(toqstr(cmd.getArg(1)));
> > > >
Am Sun, 8 Nov 2020 11:32:59 +0100
schrieb Pavel Sanda :
> On Sun, Nov 08, 2020 at 05:14:42PM +1300, Sam Crawley wrote:
> > Hi all,
>
> Hi Sam,
>
> welcome and thanks for working on this. Couple small things:
>
> - Please send in a separate email to our list the following GPL statement:
>
>
gt;
> That is the format I used, unless I'm missing something. The 'subject' line
> in a git patch file is the first line of the commit message.
My oversight, it's indeed inside subject line.
> > > @@ -343,7 +348,12 @@ bool GuiCompare::initialiseParams(std::string const
Am Mon, 09 Nov 2020 09:07:35 +1300
schrieb "Sam Crawley" :
> On Mon, 9 Nov 2020, at 01:01, Kornel Benko wrote:
> > Needed new perl module (Slurp.pm), got from package 'libfile-slurp-perl'.
>
> I think this use to be in Perl core, but it's now been taken out. I can
> easily rewrite
> if the
Am Mon, 09 Nov 2020 09:00:48 +1300
schrieb "Sam Crawley" :
> On Sun, 8 Nov 2020, at 22:28, Kornel Benko wrote:
> > Am Sun, 08 Nov 2020 17:14:42 +1300
> > schrieb "Sam Crawley" :
> > ...
> > > diff --git a/lib/scripts/lyx_batch.pl.in b/lib/scripts/lyx_batch.pl.in
> > > index 2d93d27c59..32ef0f974a
On Sun, 8 Nov 2020, at 23:32, Pavel Sanda wrote:
> Git commit messages tend to have the following structure: first summary line,
> empty line and then the details. This helps with log summaries.
That is the format I used, unless I'm missing something. The 'subject' line in
a git patc
On Sun, 8 Nov 2020, at 22:28, Kornel Benko wrote:
> Am Sun, 08 Nov 2020 17:14:42 +1300
> schrieb "Sam Crawley" :
> ...
> > diff --git a/lib/scripts/lyx_batch.pl.in b/lib/scripts/lyx_batch.pl.in
> > index 2d93d27c59..32ef0f974a 100644
> > --- a/lib/scripts/lyx_batch.pl.in
> > +++
On Mon, 9 Nov 2020, at 01:01, Kornel Benko wrote:
> Needed new perl module (Slurp.pm), got from package 'libfile-slurp-perl'.
I think this use to be in Perl core, but it's now been taken out. I can easily
rewrite if the dependency is a problem.--
lyx-devel mailing list
lyx-devel@lists.lyx.org
On Sun, Nov 08, 2020 at 12:48:11PM -0500, Richard Kimberly Heck wrote:
> On 11/8/20 12:12 PM, Scott Kostyshak wrote:
> > On Sun, Nov 08, 2020 at 11:32:59AM +0100, Pavel Sanda wrote:
> >> Scott/Kornel will presumably review/check the testing part.
> > I don't have much time to review or help,
On 11/8/20 12:12 PM, Scott Kostyshak wrote:
> On Sun, Nov 08, 2020 at 11:32:59AM +0100, Pavel Sanda wrote:
>> Scott/Kornel will presumably review/check the testing part.
> I don't have much time to review or help, although I would be happy to take a
> look in the future (possibly not for a while
On Sun, Nov 08, 2020 at 11:32:59AM +0100, Pavel Sanda wrote:
>
> Scott/Kornel will presumably review/check the testing part.
I don't have much time to review or help, although I would be happy to take a
look in the future (possibly not for a while though). Thanks to Pavel and
Kornel for giving
Am Sun, 8 Nov 2020 13:01:14 +0100
schrieb Kornel Benko :
> Am Sun, 8 Nov 2020 10:28:51 +0100
> schrieb Kornel Benko :
>
> > Am Sun, 08 Nov 2020 17:14:42 +1300
> > schrieb "Sam Crawley" :
> > ...
> > > diff --git a/lib/scripts/lyx_batch.pl.in b/lib/scripts/lyx_batch.pl.in
> > > index
Am Sun, 8 Nov 2020 10:28:51 +0100
schrieb Kornel Benko :
> Am Sun, 08 Nov 2020 17:14:42 +1300
> schrieb "Sam Crawley" :
> ...
> > diff --git a/lib/scripts/lyx_batch.pl.in b/lib/scripts/lyx_batch.pl.in
> > index 2d93d27c59..32ef0f974a 100644
> > --- a/lib/scripts/lyx_batch.pl.in
> > +++
GNU
General Public License, version 2 or any later version.
> From c11d1d7fec19f2c37ed9e2a2162e1d2966d3c643 Mon Sep 17 00:00:00 2001
> From: Sam Crawley
> Date: Fri, 6 Nov 2020 20:56:09 +1300
> Subject: [PATCH 1/4] Fix issue in running compare as a command
>
> Because Compare
Am Sun, 08 Nov 2020 17:14:42 +1300
schrieb "Sam Crawley" :
...
> diff --git a/lib/scripts/lyx_batch.pl.in b/lib/scripts/lyx_batch.pl.in
> index 2d93d27c59..32ef0f974a 100644
> --- a/lib/scripts/lyx_batch.pl.in
> +++ b/lib/scripts/lyx_batch.pl.in
> @@ -8,11 +8,6 @@ use warnings;
> use File::Copy;
Le 23/10/2020 à 09:15, Yuriy Skalko a écrit :
The patch makes all disabled informational menu items use parenthesis.
These menu items are already use such formatting:
(No Document Open)
(Empty Table of Contents)
Looks fine.
JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http
The patch makes all disabled informational menu items use parenthesis.
These menu items are already use such formatting:
(No Document Open)
(Empty Table of Contents)
Yuriy
From 95d1b4d6436faae1e97c2402c9e7d9f48368f8f6 Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Fri, 23 Oct 2020 09:24:53
On 10/8/20 9:28 AM, Jean-Marc Lasgouttes wrote:
> Le 07/10/2020 à 17:31, Richard Kimberly Heck a écrit :
>> On 10/7/20 10:31 AM, Yuriy Skalko wrote:
>>> And the last patch based on the static analyzers output.
>>
>> diff --git a/src/Author.cpp b/src/Author.cpp
&
Le 07/10/2020 à 17:31, Richard Kimberly Heck a écrit :
On 10/7/20 10:31 AM, Yuriy Skalko wrote:
And the last patch based on the static analyzers output.
diff --git a/src/Author.cpp b/src/Author.cpp
index 9a2dc1ea43..b4cf9fd97b 100644
--- a/src/Author.cpp
+++ b/src/Author.cpp
@@ -31,8 +31,8
On 10/7/20 3:09 PM, Yuriy Skalko wrote:
>> I like that. I have to admit that I gave up checking that the loops were
>> equivalent roughly at the first third of the patch :)
>>
>> Is it done by hand or with some tool?
> I used combination of clang-tidy and hands.
>
> I like that. I have to admit that I gave up checking that the loops were
> equivalent roughly at the first third of the patch :)
>
> Is it done by hand or with some tool?
I used combination of clang-tidy and hands.
> There are also in the Qt p
On 10/7/20 10:31 AM, Yuriy Skalko wrote:
> And the last patch based on the static analyzers output.
diff --git a/src/Author.cpp b/src/Author.cpp
index 9a2dc1ea43..b4cf9fd97b 100644
--- a/src/Author.cpp
+++ b/src/Author.cpp
@@ -31,8 +31,8 @@ static int computeHash(docstring const &am
Le 07/10/2020 à 16:31, Yuriy Skalko a écrit :
And the last patch based on the static analyzers output.
I like that. I have to admit that I gave up checking that the loops were
equivalent roughly at the first third of the patch :)
Is it done by hand or with some tool?
A few remarks, first
And the last patch based on the static analyzers output.
Yuriy
From 763c67bba79be0b3d08f7f86b6935bba81e25a9e Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Wed, 7 Oct 2020 17:27:09 +0300
Subject: [PATCH] Loop refactoring
---
src/Author.cpp | 4 +-
src/Buffer.cpp
> What José said.
>
> Riki
Yes, backward compatibility wins again, even the *man* cannot change that.
Yuriy
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
> It wouldn't be awful, but we do not want to allow assignments to these
> things. That's why that's there, and undefined.
>
> Riki
> Is not your patch like:
>
> InsetTableCell::InsetTableCell(InsetTableCell const & in) = default;
>
> Or I am in the wron
Le 7 octobre 2020 02:32:06 GMT+02:00, Richard Kimberly Heck
a écrit : InsetTableCell::InsetTableCell(InsetTableCell const & in) = default;
>>
>>
>> Or I am in the wrong standard?
>>
>I think this must be the magic JMarc was looking for. This is in C++11,
>so OK for us, right?
I like it!
JMarc
On 10/6/20 8:18 PM, José Abílio Matos wrote:
>
> On Monday, October 5, 2020 6:27:15 PM WEST Richard Kimberly Heck wrote:
>
> > I'm actually not sure why the assignment operator is made unavailable,
>
> > but attached is a suitable patch, I think.
>
> >
>
&
On Monday, October 5, 2020 6:27:15 PM WEST Richard Kimberly Heck wrote:
> I'm actually not sure why the assignment operator is made unavailable,
> but attached is a suitable patch, I think.
>
> Riki
Is not your patch like:
InsetTableCell::InsetTableCell(InsetTableCell const &am
at we should do.
>>> I'm actually not sure why the assignment operator is made unavailable,
>>> but attached is a suitable patch, I think.
>> It looks reasonable, but I really do not know why we have to do this. I
>> hoped there was some nice idiomatic C++11 magic that would g
y the assignment operator is made unavailable,
> >but attached is a suitable patch, I think.
>
> It looks reasonable, but I really do not know why we have to do this. I
> hoped there was some nice idiomatic C++11 magic that would get us out of
> this mess. Adding this code feels like
Le 05/10/2020 à 19:27, Richard Kimberly Heck a écrit :
PS: yes, a proper fix will be eventually required, but I do not really
know what we should do.
I'm actually not sure why the assignment operator is made unavailable,
but attached is a suitable patch, I think.
It looks reasonable, but I
Le 05/10/2020 à 21:38, José Abílio Matos a écrit :
I created a new directory. And then ran configure on that directory using the
CC and CXX environment variables to force clang.
This is what I get. I am using qt-5.15.1 FWIW:
/home/jamatos/lyx/lyx/src/frontends/qt/GuiView.cpp:221:11: warning:
On Monday, October 5, 2020 6:09:40 PM WEST Jean-Marc Lasgouttes wrote:
> Le 05/10/2020 à 18:43, José Abílio Matos a écrit :
> > On Monday, October 5, 2020 5:19:46 PM WEST Jean-Marc Lasgouttes wrote:
> >> Fixed
> >>
> >> JMarc
> >
> > Now, if I may ask what about the following kind of warning:
>
a
>> user-declared copy assignment operator [-Wdeprecated-copy]
>> void operator=(InsetTableCell const &);
>
> Fixed ;)
>
> JMarc
>
> PS: yes, a proper fix will be eventually required, but I do not really
> know what we should do.
I
Le 05/10/2020 à 18:43, José Abílio Matos a écrit :
On Monday, October 5, 2020 5:19:46 PM WEST Jean-Marc Lasgouttes wrote:
Fixed
JMarc
Now, if I may ask what about the following kind of warning:
In file included from ./ui_TabularUi.h:28:
On Monday, October 5, 2020 5:19:46 PM WEST Jean-Marc Lasgouttes wrote:
> Fixed
>
> JMarc
Now, if I may ask what about the following kind of warning:
In file included from ./ui_TabularUi.h:28:
/home/jamatos/lyx/lyx/src/frontends/qt/GuiSetBorder.h:30:59: warning: 'QFlags'
is deprecated: Use
Le 05/10/2020 à 17:50, José Abílio Matos a écrit :
On Monday, October 5, 2020 2:13:35 PM WEST Jean-Marc Lasgouttes wrote:
Yes, clang 10 does
JMarc
BTW compiling with clang 11 and without changing the compile flags I get lots
(in the tens) of warnings like this:
On 10/5/20 11:50 AM, José Abílio Matos wrote:
> On Monday, October 5, 2020 2:13:35 PM WEST Jean-Marc Lasgouttes wrote:
>> Yes, clang 10 does
>>
>> JMarc
> BTW compiling with clang 11 and without changing the compile flags I get lots
> (in the tens) of warnings like this:
>
>
On Monday, October 5, 2020 2:13:35 PM WEST Jean-Marc Lasgouttes wrote:
> Yes, clang 10 does
>
> JMarc
BTW compiling with clang 11 and without changing the compile flags I get lots
(in the tens) of warnings like this:
/home/jamatos/lyx/lyx/src/insets/InsetTabular.h:92:7: warning: definition of
>> No worries I can decode it, it's just that the previous pattern is already
>> unconsciously hardwired in my brain, so I can process it faster ;)
>> As other(s) seem to be ok with the change I am not going to fight it.
> Same here. I also do not object to the patch, but my b
401 - 500 of 76897 matches
Mail list logo
