Re: [LyX/master] * lib/RELEASE-NOTES

[Jürgen Spitzmüller]

Am Montag, den 27.01.2020, 14:28 + schrieb José Abílio Matos:
> I create the fedora packages and I have never used it, at least, in
> the last 
> 10 years.
> 
> So I agree.

OK, done.

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

Re: [LyX/master] * lib/RELEASE-NOTES

[José Abílio Matos]

On Wednesday, January 15, 2020 5:06:06 PM WET Pavel Sanda wrote:
> I looked at that, seems lyx-fedora is unmaintained since 2012 and should
> be IMHO moved to attic (Jose?).

I create the fedora packages and I have never used it, at least, in the last 
10 years.

So I agree.

> Pavel

-- 
José Abílio


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] * lib/RELEASE-NOTES

[Pavel Sanda]

On Wed, Jan 15, 2020 at 06:48:01PM +0100, Jürgen Spitzmüller wrote:
> Am Mittwoch, den 15.01.2020, 18:08 +0100 schrieb Pavel Sanda:
> > On Wed, Jan 15, 2020 at 06:06:06PM +0100, Pavel Sanda wrote:
> > > Kicking dvipost from LaTeX.nsh seem straightforward, but since I am
> > > not building the installer to test, I leave it to Riki :)
> > 
> > patch attached for your convenience. p
> 
> Note, though, that also some other *.nsh files list dvipost
> (filelist.nsh, declarations.nsh, install.nsh, settings.nsh).

Oops, I did case sensitive grep only. It's now bug #11719 so we won't forget it.
Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] * lib/RELEASE-NOTES

[Jürgen Spitzmüller]

Am Mittwoch, den 15.01.2020, 18:08 +0100 schrieb Pavel Sanda:
> On Wed, Jan 15, 2020 at 06:06:06PM +0100, Pavel Sanda wrote:
> > Kicking dvipost from LaTeX.nsh seem straightforward, but since I am
> > not building the installer to test, I leave it to Riki :)
> 
> patch attached for your convenience. p

Note, though, that also some other *.nsh files list dvipost
(filelist.nsh, declarations.nsh, install.nsh, settings.nsh).

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

Re: [LyX/master] * lib/RELEASE-NOTES

[Pavel Sanda]

On Wed, Jan 15, 2020 at 06:06:06PM +0100, Pavel Sanda wrote:
> Kicking dvipost from LaTeX.nsh seem straightforward, but since I am
> not building the installer to test, I leave it to Riki :)

patch attached for your convenience. p
diff --git a/development/Win32/packaging/installer/include/LaTeX.nsh 
b/development/Win32/packaging/installer/include/LaTeX.nsh
index a94f269f9d..f65037c799 100644
--- a/development/Win32/packaging/installer/include/LaTeX.nsh
+++ b/development/Win32/packaging/installer/include/LaTeX.nsh
@@ -201,9 +201,6 @@ Function ConfigureMiKTeX
 
   # only install the LyX packages if they are not already installed
   ${ifnot} ${FileExists} "$PathLaTeXLocal\tex\latex\lyx\broadway.cls"
-   # dvipost
-   SetOutPath "$PathLaTeXLocal\tex\latex\dvipost"
-   File "${FILES_DVIPOST_PKG}\dvipost.sty"
# files in Resources\tex
SetOutPath "$PathLaTeXLocal\tex\latex\lyx"
CopyFiles /SILENT "$INSTDIR\Resources\tex\*.*" 
"$PathLaTeXLocal\tex\latex\lyx"
@@ -242,9 +239,6 @@ Function ConfigureTeXLive
   
   # only install the LyX packages if they are not already installed
   ${ifnot} ${FileExists} 
"$PathLaTeXLocal\texmf-dist\tex\latex\lyx\broadway.cls"
-   # dvipost
-   SetOutPath "$PathLaTeXLocal\texmf-dist\tex\latex\dvipost"
-   File "${FILES_DVIPOST_PKG}\dvipost.sty"
# files in Resources\tex
SetOutPath "$PathLaTeXLocal\texmf-dist\tex\latex\lyx"
CopyFiles /SILENT "$INSTDIR\Resources\tex\*.*" 
"$PathLaTeXLocal\texmf-dist\tex\latex\lyx"
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] * lib/RELEASE-NOTES

[Pavel Sanda]

On Wed, Jan 15, 2020 at 11:01:18AM +0100, Jürgen Spitzmüller wrote:
> BTW grep revealed that development/tools/lyx-fedora defines it as
> dependency, and the windows installer packs it as well.

I looked at that, seems lyx-fedora is unmaintained since 2012 and should
be IMHO moved to attic (Jose?).

Kicking dvipost from LaTeX.nsh seem straightforward, but since I am
not building the installer to test, I leave it to Riki :)

Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] * lib/RELEASE-NOTES

[Jürgen Spitzmüller]

Am Mi., 15. Jan. 2020 um 09:17 Uhr schrieb Pavel Sanda :

> Well, right, we list it as an optional package and some distributions
> have it as an optional dependency.
>
> It looked safer to me to use somewhere the keyword dependency. The original
> statement maybe technically more correct but seem to have higher chance of
> being overlooked. Anyway I don't have strong opinion and can revert if you
> wish.
>

No, I am fine with it.

BTW grep revealed that development/tools/lyx-fedora defines it as
dependency, and the windows installer packs it as well.
I won't touch these. But whoever is responsible should remove dvipost from
there.

Jürgen
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] * lib/RELEASE-NOTES

[Pavel Sanda]

On Wed, Jan 15, 2020 at 07:36:37AM +0100, Jürgen Spitzmüller wrote:
> Am Dienstag, den 14.01.2020, 21:57 +0100 schrieb Pavel Sanda:
> > -* The pplatex/dvipost program is no longer used.
> > +* The dependency on pplatex/dvipost was dropped.
> 
> I don't think we ever declared that a "dependency" (I didn't find such
> a statement). And LyX could always be used perfectly well without
> pplatex/dvipost (if svipost wasn't found, ulem/xcolor was used for
> change tracking).

Well, right, we list it as an optional package and some distributions
have it as an optional dependency.

It looked safer to me to use somewhere the keyword dependency. The original
statement maybe technically more correct but seem to have higher chance of
being overlooked. Anyway I don't have strong opinion and can revert if you
wish. 

Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] * lib/RELEASE-NOTES

[Jürgen Spitzmüller]

Am Dienstag, den 14.01.2020, 21:57 +0100 schrieb Pavel Sanda:
> -* The pplatex/dvipost program is no longer used.
> +* The dependency on pplatex/dvipost was dropped.

I don't think we ever declared that a "dependency" (I didn't find such
a statement). And LyX could always be used perfectly well without
pplatex/dvipost (if svipost wasn't found, ulem/xcolor was used for
change tracking).

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

Re: [LyX/master] * lib/RELEASE-NOTES

[Jean-Marc Lasgouttes]

Le 30/05/2016 17:16, Guillaume Munch a écrit :

Now if you tried qt5 you could see what fast means :)


I guess the reason is this:
https://codereview.qt-project.org/#/c/34112/

JMarc

Re: [LyX/master] * lib/RELEASE-NOTES

[Guillaume Munch]

Le 30/05/2016 15:58, Jean-Marc Lasgouttes a écrit :

Le 30/05/2016 16:40, Guillaume Munch a écrit :

Qt4: 75% of the time is spent (in number of instructions) inside
QTextEngine::shapeText(). Of these 75%, 2/3 is requested by metrics
calculation (QTextLine::setLineWidth() from GuiFontMetrics::breakAt())
and 1/3 by painting (GuiPainter::text()). Ultimately, 74% of the time
is spent in in FT_Load_Glyph and FT_Render_Glyph from
libfreetype.so.6.12.1 (thus, including the metrics phase).


At some time, I had the idea of caching the QTextLine object in the row
element. I suspect this would be a good thing to do.


I do not see the point. You already keep all the useful information.
Keeping the QtextLine object is not going to make setLineWidth run
faster.


We would avoid the double shapeText call between breakAt and draw.
Caching QTextLines is more expensive but much more rich than caching
only the line width.


I cannot see for sure that it will not call shapeText again, but it is
worth a try.




Ubuntu 16.04, callgrind.


Hmm, callgrind. It is so slow that I often do not even think about using
it.


Wild guess, you need to start it with recording off. See:
https://wiki.lyx.org/FAQ/FurtherHelp .




Now if you tried qt5 you could see what fast means :)


I guess that your window manager is set to redraw in real time when
resizing a window, right?



Yes.

Re: [LyX/master] * lib/RELEASE-NOTES

[Jean-Marc Lasgouttes]

Le 30/05/2016 16:40, Guillaume Munch a écrit :

Qt4: 75% of the time is spent (in number of instructions) inside
QTextEngine::shapeText(). Of these 75%, 2/3 is requested by metrics
calculation (QTextLine::setLineWidth() from GuiFontMetrics::breakAt())
and 1/3 by painting (GuiPainter::text()). Ultimately, 74% of the time
is spent in in FT_Load_Glyph and FT_Render_Glyph from
libfreetype.so.6.12.1 (thus, including the metrics phase).


At some time, I had the idea of caching the QTextLine object in the row
element. I suspect this would be a good thing to do.


I do not see the point. You already keep all the useful information.
Keeping the QtextLine object is not going to make setLineWidth run faster.


We would avoid the double shapeText call between breakAt and draw. 
Caching QTextLines is more expensive but much more rich than caching 
only the line width.



Ubuntu 16.04, callgrind.


Hmm, callgrind. It is so slow that I often do not even think about using it.


Now if you tried qt5 you could see what fast means :)


I guess that your window manager is set to redraw in real time when 
resizing a window, right?


JMarc

Re: [LyX/master] * lib/RELEASE-NOTES

[Guillaume Munch]

Le 30/05/2016 14:33, Jean-Marc Lasgouttes a écrit :

Le 27/05/2016 23:08, Guillaume Munch a écrit :

The protocol is to change the width of the window (all other things
equal).

Qt4: 75% of the time is spent (in number of instructions) inside
QTextEngine::shapeText(). Of these 75%, 2/3 is requested by metrics
calculation (QTextLine::setLineWidth() from GuiFontMetrics::breakAt())
and 1/3 by painting (GuiPainter::text()). Ultimately, 74% of the time
is spent in in FT_Load_Glyph and FT_Render_Glyph from
libfreetype.so.6.12.1 (thus, including the metrics phase).


At some time, I had the idea of caching the QTextLine object in the row
element. I suspect this would be a good thing to do.


I do not see the point. You already keep all the useful information.
Keeping the QtextLine object is not going to make setLineWidth run faster.




Qt5: QTextEngine::shapeText() only accounts for 13.22% of the cycles,
and costs 28 times less per call (69729 instructions vs 1932642).
QTextLine::setLineWidth() only costs 4% total. GuiPainter::text() costs
21%, with time spent in a certain QRasterPaintEngine::drawCachedGlyphs().


This difference is very surprising, there has to be something that is
different.


Conclusion: using QTextLine::setLineWidth() breaking rows is very costly
with qt4.8.7, and much less with qt5. I agree with you that I do not
remember seeing this slowness before, and I do not know what exactly
could trigger this behaviour.


I have to double-check, but this seems indeed slower now than it used to
be. What is your OS?

What tool did you use to assess performance?



Ubuntu 16.04, callgrind.

Now if you tried qt5 you could see what fast means :)

Re: [LyX/master] * lib/RELEASE-NOTES

[Jean-Marc Lasgouttes]

Le 27/05/2016 23:08, Guillaume Munch a écrit :

The protocol is to change the width of the window (all other things equal).

Qt4: 75% of the time is spent (in number of instructions) inside
QTextEngine::shapeText(). Of these 75%, 2/3 is requested by metrics
calculation (QTextLine::setLineWidth() from GuiFontMetrics::breakAt())
and 1/3 by painting (GuiPainter::text()). Ultimately, 74% of the time
is spent in in FT_Load_Glyph and FT_Render_Glyph from
libfreetype.so.6.12.1 (thus, including the metrics phase).


At some time, I had the idea of caching the QTextLine object in the row 
element. I suspect this would be a good thing to do.



Qt5: QTextEngine::shapeText() only accounts for 13.22% of the cycles,
and costs 28 times less per call (69729 instructions vs 1932642).
QTextLine::setLineWidth() only costs 4% total. GuiPainter::text() costs
21%, with time spent in a certain QRasterPaintEngine::drawCachedGlyphs().


This difference is very surprising, there has to be something that is 
different.



Conclusion: using QTextLine::setLineWidth() breaking rows is very costly
with qt4.8.7, and much less with qt5. I agree with you that I do not
remember seeing this slowness before, and I do not know what exactly
could trigger this behaviour.


I have to double-check, but this seems indeed slower now than it used to 
be. What is your OS?


What tool did you use to assess performance?

JMarc

Re: [LyX/master] * lib/RELEASE-NOTES

[Guillaume Munch]

Le 24/05/2016 09:49, Jean-Marc Lasgouttes a écrit :

Le 24/05/2016 à 00:51, Guillaume Munch a écrit :

Do you know any other bug on Linux+qt5.5.1 than
http://www.lyx.org/trac/ticket/9731 ?

Because on the other hand with qt4 there is the critical
http://www.lyx.org/trac/ticket/9362. I also noticed that lyx is
very slow with qt4 now, with profiling showing that most of the
time is spent in QTextLine::setLineWidth() below
GuiFontMetrics::breakAt(). In fact I find it more annoying than
#9731, so much that I switched to 5.5.1. I wonder whether LyX 2.2
should not be built with qt >= 5.5.1 on Linux when possible.


Could you give more details? I do all my development in 4.8, so I am
a bit surprised. Or maybe I missed how fast it is now with 5.6 :)
Anyway, the new code is faster for me with 4.8 than the old one.


It really feels fast with qt5 :)

The protocol is to change the width of the window (all other things equal).

Qt4: 75% of the time is spent (in number of instructions) inside
QTextEngine::shapeText(). Of these 75%, 2/3 is requested by metrics
calculation (QTextLine::setLineWidth() from GuiFontMetrics::breakAt())
and 1/3 by painting (GuiPainter::text()). Ultimately, 74% of the time
is spent in in FT_Load_Glyph and FT_Render_Glyph from
libfreetype.so.6.12.1 (thus, including the metrics phase).

Qt5: QTextEngine::shapeText() only accounts for 13.22% of the cycles,
and costs 28 times less per call (69729 instructions vs 1932642).
QTextLine::setLineWidth() only costs 4% total. GuiPainter::text() costs
21%, with time spent in a certain QRasterPaintEngine::drawCachedGlyphs().

Conclusion: using QTextLine::setLineWidth() breaking rows is very costly
with qt4.8.7, and much less with qt5. I agree with you that I do not
remember seeing this slowness before, and I do not know what exactly
could trigger this behaviour.

Let me know if you need more details.



For these reasons as well, I am hoping that for 2.3 the community
of LyX developers will choose to focus on qt >= 5.6.


With Ubuntu 14.04 offering 5.2.1 and 16.04 offering 5.5.1, this
seems premature to me, especially when the cost of supporting 4.8 is
low for now as far as I can see. We shall of course remove support
for Qt < 4.8.



Note that, as I wrote on the tracker, the bug that prompted Scott to
recommend qt5.5 probably comes from the same wrong use of
ShortcutOverride, and therefore the requirement for qt5 could be lowered
(I remember that qt5.4 was quite usable without this bug).


Le 24/05/2016 20:40, Jean-Marc Lasgouttes a écrit :

Le 24/05/16 à 21:31, Georg Baum a écrit :

On linux most people do not compile qt themselves, and simply
use the preinstalled version, because it is so much easier. Those
who do compile qt are experts, I trust them to choose a good
version.



Unless the question is choosing between qt4 and qt5 :)


For these reasons as well, I am hoping that for 2.3 the community
of LyX developers will choose to focus on qt >= 5.6.


+1

However, I also agree with Jean-Marc: As long as keeping LyX
compilable with qt 4.8 is close to zero effort we should support
4.8 as in "LyX compiles and does not crash immediately".


I do not mind including the occasional #if #else for Qt4 if this does
not involve much effort. By focusing on qt >= 5.6, I mean that I would
not like to be discouraged from using new features if the opportunity
arises. So, let's keep the door open for discussing dropping qt4.8
once a concrete motivation arises (for instance I was curious about Qt
Quick, but this appears to exist in Qt4.8 already). I also meant that we
can expect to discover many bugs during the ongoing transition to qt5,
especially in the high-dpi category, and qt5.6 is seems very different
from qt5.5 in this area.

I also wonder whether the --enable-qt5 option should be made default
starting from 2.3.



In the foreseeable future, I will compile and use 4.8.x. Actually, I
 have no real incentive to switch to Qt5 in Linux, so I will act as
the resident old-timer, until the cost is too high.


One of my concerns was spending efforts on qt4 compatibility without
anybody to provide feedback during development. Thank you for playing
this necessary role.



I guess that one problem will be with the UI files.



I guess we will have to see.



Guillaume

Re: [LyX/master] * lib/RELEASE-NOTES

[Scott Kostyshak]

On Tue, May 24, 2016 at 10:05:59PM +0200, Jean-Marc Lasgouttes wrote:
> Le 24/05/16 à 22:01, Scott Kostyshak a écrit :
> > > I guess that one problem will be with the UI files.
> > 
> > I don't understand. Why would the UI files cause a problem? Do you mean
> > because if we have to choose between a .ui that looks good on Qt 4 or
> > looks good on Qt 5 we will choose Qt 5 and cannot use guards like in cpp
> > files?
> 
> I thought that UI files produced with Qt5 qtdesigner would not be usable
> with Qt4.8. I would be glad to be wrong.

I did not find a definitive source on this topic.

It does seem that we experienced an issue with backwards compatibility
between 4.2 and 4.3:
http://lyx-devel.lyx.narkive.com/7ui1juCT/compilation-problem-with-ui-files

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] * lib/RELEASE-NOTES

[Jean-Marc Lasgouttes]

Le 24/05/16 à 22:01, Scott Kostyshak a écrit :

I guess that one problem will be with the UI files.


I don't understand. Why would the UI files cause a problem? Do you mean
because if we have to choose between a .ui that looks good on Qt 4 or
looks good on Qt 5 we will choose Qt 5 and cannot use guards like in cpp
files?


I thought that UI files produced with Qt5 qtdesigner would not be usable 
with Qt4.8. I would be glad to be wrong.


JMarc

Re: [LyX/master] * lib/RELEASE-NOTES

[Scott Kostyshak]

On Tue, May 24, 2016 at 09:40:46PM +0200, Jean-Marc Lasgouttes wrote:
> Le 24/05/16 à 21:31, Georg Baum a écrit :
> > > For these reasons as well, I am hoping that for 2.3 the community of LyX
> > > developers will choose to focus on qt >= 5.6.
> > 
> > +1
> > 
> > However, I also agree with Jean-Marc: As long as keeping LyX compilable with
> > qt 4.8 is close to zero effort we should support 4.8 as in "LyX compiles and
> > does not crash immediately".
> 
> In the foreseeable future, I will compile and use 4.8.x. Actually, I have no
> real incentive to switch to Qt5 in Linux, so I will act as the resident
> old-timer, until the cost is too high.
> 
> I guess that one problem will be with the UI files.

I don't understand. Why would the UI files cause a problem? Do you mean
because if we have to choose between a .ui that looks good on Qt 4 or
looks good on Qt 5 we will choose Qt 5 and cannot use guards like in cpp
files?

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] * lib/RELEASE-NOTES

[Jean-Marc Lasgouttes]

Le 24/05/16 à 21:31, Georg Baum a écrit :

For these reasons as well, I am hoping that for 2.3 the community of LyX
developers will choose to focus on qt >= 5.6.


+1

However, I also agree with Jean-Marc: As long as keeping LyX compilable with
qt 4.8 is close to zero effort we should support 4.8 as in "LyX compiles and
does not crash immediately".


In the foreseeable future, I will compile and use 4.8.x. Actually, I 
have no real incentive to switch to Qt5 in Linux, so I will act as the 
resident old-timer, until the cost is too high.


I guess that one problem will be with the UI files.

JMarc

Re: [LyX/master] * lib/RELEASE-NOTES

[Georg Baum]

Guillaume Munch wrote:

> Because on the other hand with qt4 there is the critical
> http://www.lyx.org/trac/ticket/9362. I also noticed that lyx is very
> slow with qt4 now, with profiling showing that most of the time is spent
> in QTextLine::setLineWidth() below GuiFontMetrics::breakAt(). In fact I
> find it more annoying than #9731, so much that I switched to 5.5.1. I
> wonder whether LyX 2.2 should not be built with qt >= 5.5.1 on Linux
> when possible.

On linux most people do not compile qt themselves, and simply use the 
preinstalled version, because it is so much easier. Those who do compile qt 
are experts, I trust them to choose a good version.

> For these reasons as well, I am hoping that for 2.3 the community of LyX
> developers will choose to focus on qt >= 5.6.

+1

However, I also agree with Jean-Marc: As long as keeping LyX compilable with 
qt 4.8 is close to zero effort we should support 4.8 as in "LyX compiles and 
does not crash immediately".


Georg

Re: [LyX/master] * lib/RELEASE-NOTES

[Jean-Marc Lasgouttes]

Le 24/05/2016 à 00:51, Guillaume Munch a écrit :

Do you know any other bug on Linux+qt5.5.1 than
http://www.lyx.org/trac/ticket/9731 ?

Because on the other hand with qt4 there is the critical
http://www.lyx.org/trac/ticket/9362. I also noticed that lyx is very
slow with qt4 now, with profiling showing that most of the time is spent
in QTextLine::setLineWidth() below GuiFontMetrics::breakAt(). In fact I
find it more annoying than #9731, so much that I switched to 5.5.1. I
wonder whether LyX 2.2 should not be built with qt >= 5.5.1 on Linux
when possible.


Could you give more details? I do all my development in 4.8, so I am a 
bit surprised. Or maybe I missed how fast it is now with 5.6 :) Anyway, 
the new code is faster for me with 4.8 than the old one.



For these reasons as well, I am hoping that for 2.3 the community of LyX
developers will choose to focus on qt >= 5.6.


With Ubuntu 14.04 offering 5.2.1 and 16.04 offering 5.5.1, this seems 
premature to me, especially when the cost of supporting 4.8 is low for 
now as far as I can see. We shall of course remove support for Qt < 4.8.


JMarc

Re: [LyX/master] * lib/RELEASE-NOTES

[Scott Kostyshak]

On Tue, May 24, 2016 at 01:03:28AM +0100, Guillaume Munch wrote:
> Le 24/05/2016 00:06, Scott Kostyshak a écrit :
> > On Mon, May 23, 2016 at 11:51:11PM +0100, Guillaume Munch wrote:
> > > Le 23/05/2016 23:12, Scott Kostyshak a écrit :
> > > > On Wed, May 11, 2016 at 10:36:13AM -0700, Pavel Sanda wrote:
> > > > > Pavel Sanda wrote:
> > > > > > commit 518876b370ac00f4ee5840a65d40c1d79d0ed2ad
> > > > > > Author: Pavel Sanda 
> > > > > > Date:   Wed May 11 10:31:59 2016 -0700
> > > > > > 
> > > > > >   * lib/RELEASE-NOTES
> > > > > 
> > > > > It would be nice if someone involved in numerous dicussions about
> > > > > various bugs under different Qt 5.x versions wrote summary 
> > > > > paragraph...
> > > > 
> > > > We have the following in RELEASE-NOTES:
> > > > 
> > > > * LyX 2.2.0 and the following 2.2.x releases will continue to work well 
> > > > with
> > > > Qt 4.5 (and later Qt 4.x) but will also support Qt 5.6, which 
> > > > brings some
> > > > advantages most notably for users with HiDPI displays. Note that if 
> > > > you
> > > > compile LyX with a Qt 5 release before 5.6 you are likely to run 
> > > > into
> > > > several regressions with respect to Qt 4.x. See #9215 for a list of 
> > > > bugs
> > > > related to compiling LyX with different versions of Qt.
> > > > 
> > > > I think it is sufficient. The nice thing is that we can add more
> > > > information to #9215 after release if we want since we reference it.
> > > > 
> > > 
> > > Do you know any other bug on Linux+qt5.5.1 than
> > > http://www.lyx.org/trac/ticket/9731 ?
> > 
> > Not offhand but I'm sure there are some that I cannot remember. I might
> > look through our bugs with "qtbug" keyword and improve #9215.
> > 
> > > Because on the other hand with qt4 there is the critical
> > > http://www.lyx.org/trac/ticket/9362. I also noticed that lyx is very slow
> > > with qt4 now, with profiling showing that most of the time is spent in
> > > QTextLine::setLineWidth() below GuiFontMetrics::breakAt(). In fact I find 
> > > it
> > > more annoying than #9731, so much that I switched to 5.5.1.
> > 
> > Is the above with 4.8.6? Is there a chance that 4.8.7 has improved
> > something?
> 
> I noticed this starting with 4.8.7.

Dang. Good to know.

Scott

> > > I wonder whether
> > > LyX 2.2 should not be built with qt >= 5.5.1 on Linux when possible.
> > 
> > > For these reasons as well, I am hoping that for 2.3 the community of LyX
> > > developers will choose to focus on qt >= 5.6.
> > 
> > +1
> > 
> > Note that Ubuntu 16.04 shipped Qt 5.5.1 and that will be around for a
> > while. It would be nice to test our LyX with that Qt version as well.
> 
> Yes, one can expect feedback from this version as well.


signature.asc
Description: PGP signature

Re: [LyX/master] * lib/RELEASE-NOTES

[Guillaume Munch]

Le 24/05/2016 00:06, Scott Kostyshak a écrit :

On Mon, May 23, 2016 at 11:51:11PM +0100, Guillaume Munch wrote:

Le 23/05/2016 23:12, Scott Kostyshak a écrit :

On Wed, May 11, 2016 at 10:36:13AM -0700, Pavel Sanda wrote:

Pavel Sanda wrote:

commit 518876b370ac00f4ee5840a65d40c1d79d0ed2ad
Author: Pavel Sanda 
Date:   Wed May 11 10:31:59 2016 -0700

  * lib/RELEASE-NOTES


It would be nice if someone involved in numerous dicussions about
various bugs under different Qt 5.x versions wrote summary paragraph...


We have the following in RELEASE-NOTES:

* LyX 2.2.0 and the following 2.2.x releases will continue to work well with
Qt 4.5 (and later Qt 4.x) but will also support Qt 5.6, which brings some
advantages most notably for users with HiDPI displays. Note that if you
compile LyX with a Qt 5 release before 5.6 you are likely to run into
several regressions with respect to Qt 4.x. See #9215 for a list of bugs
related to compiling LyX with different versions of Qt.

I think it is sufficient. The nice thing is that we can add more
information to #9215 after release if we want since we reference it.



Do you know any other bug on Linux+qt5.5.1 than
http://www.lyx.org/trac/ticket/9731 ?


Not offhand but I'm sure there are some that I cannot remember. I might
look through our bugs with "qtbug" keyword and improve #9215.


Because on the other hand with qt4 there is the critical
http://www.lyx.org/trac/ticket/9362. I also noticed that lyx is very slow
with qt4 now, with profiling showing that most of the time is spent in
QTextLine::setLineWidth() below GuiFontMetrics::breakAt(). In fact I find it
more annoying than #9731, so much that I switched to 5.5.1.


Is the above with 4.8.6? Is there a chance that 4.8.7 has improved
something?


I noticed this starting with 4.8.7.




I wonder whether
LyX 2.2 should not be built with qt >= 5.5.1 on Linux when possible.



For these reasons as well, I am hoping that for 2.3 the community of LyX
developers will choose to focus on qt >= 5.6.


+1

Note that Ubuntu 16.04 shipped Qt 5.5.1 and that will be around for a
while. It would be nice to test our LyX with that Qt version as well.


Yes, one can expect feedback from this version as well.

Re: [LyX/master] * lib/RELEASE-NOTES

[Scott Kostyshak]

On Mon, May 23, 2016 at 11:51:11PM +0100, Guillaume Munch wrote:
> Le 23/05/2016 23:12, Scott Kostyshak a écrit :
> > On Wed, May 11, 2016 at 10:36:13AM -0700, Pavel Sanda wrote:
> > > Pavel Sanda wrote:
> > > > commit 518876b370ac00f4ee5840a65d40c1d79d0ed2ad
> > > > Author: Pavel Sanda 
> > > > Date:   Wed May 11 10:31:59 2016 -0700
> > > > 
> > > >  * lib/RELEASE-NOTES
> > > 
> > > It would be nice if someone involved in numerous dicussions about
> > > various bugs under different Qt 5.x versions wrote summary paragraph...
> > 
> > We have the following in RELEASE-NOTES:
> > 
> > * LyX 2.2.0 and the following 2.2.x releases will continue to work well with
> >Qt 4.5 (and later Qt 4.x) but will also support Qt 5.6, which brings some
> >advantages most notably for users with HiDPI displays. Note that if you
> >compile LyX with a Qt 5 release before 5.6 you are likely to run into
> >several regressions with respect to Qt 4.x. See #9215 for a list of bugs
> >related to compiling LyX with different versions of Qt.
> > 
> > I think it is sufficient. The nice thing is that we can add more
> > information to #9215 after release if we want since we reference it.
> > 
> 
> Do you know any other bug on Linux+qt5.5.1 than
> http://www.lyx.org/trac/ticket/9731 ?

Not offhand but I'm sure there are some that I cannot remember. I might
look through our bugs with "qtbug" keyword and improve #9215.

> Because on the other hand with qt4 there is the critical
> http://www.lyx.org/trac/ticket/9362. I also noticed that lyx is very slow
> with qt4 now, with profiling showing that most of the time is spent in
> QTextLine::setLineWidth() below GuiFontMetrics::breakAt(). In fact I find it
> more annoying than #9731, so much that I switched to 5.5.1.

Is the above with 4.8.6? Is there a chance that 4.8.7 has improved
something?

> I wonder whether
> LyX 2.2 should not be built with qt >= 5.5.1 on Linux when possible.

> For these reasons as well, I am hoping that for 2.3 the community of LyX
> developers will choose to focus on qt >= 5.6.

+1

Note that Ubuntu 16.04 shipped Qt 5.5.1 and that will be around for a
while. It would be nice to test our LyX with that Qt version as well.

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] * lib/RELEASE-NOTES

[Guillaume Munch]

Le 23/05/2016 23:12, Scott Kostyshak a écrit :

On Wed, May 11, 2016 at 10:36:13AM -0700, Pavel Sanda wrote:

Pavel Sanda wrote:

commit 518876b370ac00f4ee5840a65d40c1d79d0ed2ad
Author: Pavel Sanda 
Date:   Wed May 11 10:31:59 2016 -0700

 * lib/RELEASE-NOTES


It would be nice if someone involved in numerous dicussions about
various bugs under different Qt 5.x versions wrote summary paragraph...


We have the following in RELEASE-NOTES:

* LyX 2.2.0 and the following 2.2.x releases will continue to work well with
   Qt 4.5 (and later Qt 4.x) but will also support Qt 5.6, which brings some
   advantages most notably for users with HiDPI displays. Note that if you
   compile LyX with a Qt 5 release before 5.6 you are likely to run into
   several regressions with respect to Qt 4.x. See #9215 for a list of bugs
   related to compiling LyX with different versions of Qt.

I think it is sufficient. The nice thing is that we can add more
information to #9215 after release if we want since we reference it.



Do you know any other bug on Linux+qt5.5.1 than 
http://www.lyx.org/trac/ticket/9731 ?


Because on the other hand with qt4 there is the critical 
http://www.lyx.org/trac/ticket/9362. I also noticed that lyx is very 
slow with qt4 now, with profiling showing that most of the time is spent 
in QTextLine::setLineWidth() below GuiFontMetrics::breakAt(). In fact I 
find it more annoying than #9731, so much that I switched to 5.5.1. I 
wonder whether LyX 2.2 should not be built with qt >= 5.5.1 on Linux 
when possible.


For these reasons as well, I am hoping that for 2.3 the community of LyX 
developers will choose to focus on qt >= 5.6.

Re: [LyX/master] * lib/RELEASE-NOTES

[Scott Kostyshak]

On Wed, May 11, 2016 at 10:36:13AM -0700, Pavel Sanda wrote:
> Pavel Sanda wrote:
> > commit 518876b370ac00f4ee5840a65d40c1d79d0ed2ad
> > Author: Pavel Sanda 
> > Date:   Wed May 11 10:31:59 2016 -0700
> > 
> > * lib/RELEASE-NOTES
> 
> It would be nice if someone involved in numerous dicussions about 
> various bugs under different Qt 5.x versions wrote summary paragraph...

We have the following in RELEASE-NOTES:

* LyX 2.2.0 and the following 2.2.x releases will continue to work well with
  Qt 4.5 (and later Qt 4.x) but will also support Qt 5.6, which brings some
  advantages most notably for users with HiDPI displays. Note that if you
  compile LyX with a Qt 5 release before 5.6 you are likely to run into
  several regressions with respect to Qt 4.x. See #9215 for a list of bugs
  related to compiling LyX with different versions of Qt.

I think it is sufficient. The nice thing is that we can add more
information to #9215 after release if we want since we reference it.

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] * lib/RELEASE-NOTES

[Pavel Sanda]

Pavel Sanda wrote:
> commit 518876b370ac00f4ee5840a65d40c1d79d0ed2ad
> Author: Pavel Sanda 
> Date:   Wed May 11 10:31:59 2016 -0700
> 
> * lib/RELEASE-NOTES

It would be nice if someone involved in numerous dicussions about 
various bugs under different Qt 5.x versions wrote summary paragraph...

Pavel