Use Qt 5.9.0 for Mac/Win binaries?

[Scott Kostyshak]

Dear all,

I would like to propose that we release our LyX 2.3.0 alpha binaries for
Mac and Windows with Qt 5.9.0beta1 and that we release our final LyX
2.3.0 binaries with the final release of Qt 5.9.0.

I think there is an advantage to releasing the final LyX version with
the same Qt x.y version (here I am considering Qt 5.9beta1 and Qt 5.9
final the "same") as our pre-releases. I make this claim for a few
reasons:

- In the past, sometimes when we switched Qt versions, this involved
  switching versions of compilers, which caused complications (e.g. not
  being able to compile) and worse, bugs (either a bug from the new
  compiler or a bug in LyX that was exposed by the new computer and not
  caught because not much testing).

- I consider Qt development snapshots to be quite stable. This is only
  based on my own observations.

- (I'm not sure of this one) We are more likely to get a Qt bug that is
  a regression fixed. Normally, regressions with respect to the most
  recently released version are given higher priority than regressions
  with respect to the version before the previous released version.

Now some arguments specific to the current situation of Qt development:

- From what I understand, there will be no Qt 5.8.1 released. Instead,
  these improvements will only go in to Qt 5.9.0. See [1], in
  particular, the following quote:

Unless there are significant security or other issues found,
we are not planning to provide any patch releases for Qt 5.8
to make sure that we release Qt 5.9.0 with the planned
schedule. Qt Support will assist customers to overcome
possible issues found in Qt 5.8.0 release.

- There will be Qt 5.9.z patch versions released [1]. This increases the
  probability that our LyX 2.3.1 will be released with the same major Qt
  version as 2.3.0, which minimizes regressions due to Qt.

- The alpha release met its deadline, and the beta release was only two
  days late. Although historically Qt's releases have missed many of
  their targets, there seems to be an increased effort by Qt's
  development team to meet the deadlines on their release plan [2]. This
  leads me to think that even if there are delays and Qt 5.9.0 final is
  not released on 31 May, as currently planned, it will be released not
  too late after.

Stephan and Uwe, do you forsee any problems with this plan? Would it be
a lot of extra work to also compile our alpha and beta with Qt 5.8.0,
but to not post these installers. This way, if we have a tester that
reports a regression that no LyX developer can reproduce, at least we
can ask them if they can reproduce with the LyX+5.8.0 installers (which
we would just send privately and not post publicly)? This could tell us
whether a regression is due to LyX or Qt.

If there is agreement on the above plan, I would then like to ask if
anyone could test LyX master with Qt 5.9beta going forward. There are no
offline installers for Qt 5.9beta, but there are binaries available
through the online installer. If you haven't used this yet, it is pretty
easy (at least in my experience on Linux). The most painful part for me
was answering questions before being able to download the online
installer.

I have only briefly tested Qt 5.9beta. At least, master compiles against
it without error. My plan would be to test master with 5.9beta, and for
work where I need a stable LyX, I would use 2.2.x branch compiled with
5.9beta.

Scott

[1]
http://blog.qt.io/blog/2017/02/22/qt-roadmap-for-2017/

[2]
https://wiki.qt.io/Qt_5.9_Release



signature.asc
Description: PGP signature

Is anyone planning to test TL 2017 pre-test?

[Scott Kostyshak]

Dear all,

Is anyone planning to test TL 2017 pretest? It begins 16 April [1]. I am
planning to install it and run all of our export tests. Some will surely
fail. And then it will be a question of whether we need to change our
LaTeX export. Hopefully we will not, but it is good to plan for this
possibility.

I'm hoping that another LyX developer will have a virtual box set up
with LyX and TL 2017 pretest so that they can help figure out whether
and how we need to change our LaTeX export code.

Scott

[1]
https://www.tug.org/texlive/


signature.asc
Description: PGP signature

Tentative schedule for 2.3.0 release

[Scott Kostyshak]

Dear all,

I think there is agreement that master is pretty stable. Besides just a
feeling, I think that this can be confirmed by looking at the trac
tickets with "2.3.0" milestone and tickets with the "regression"
keyword.

I propose the following schedule for the 2.3.0 release process:

alpha:   22 April
feature freeze:  19 May
beta:09 June
RC:  12 July
final:   01 August

Uwe and Stephan, do you know if you will be available around these dates
to produce binaries?

As usual, this schedule is tentative and likely to change (dates could
be earlier or later).

Please feel free to propose changes to this schedule, or to ask for me
to explain why I chose a certain date (or rather a certain duration
between stages).

Scott



signature.asc
Description: PGP signature

Re: How far is 2.3.0?

[Scott Kostyshak]

On Sat, Mar 04, 2017 at 07:06:51PM +, José Abílio Matos wrote:

> Now regarding the other issue at hand and looking into history we have that:
> 
> 2.2.0 -> 2016.05
> 2.1.0 -> 2014.04
> 2.0.0 -> 2011.04
> 1.6.0 -> 2008.11
> 1.5.0 -> 2007.07
> 1.4.0 -> 2006.03
> 
> First the obvious conclusion, those number are completely arbitrary. Each of 
> those versions has been a major version on its own. And as usual I propose to 
> go the way of gcc (not necessarily dropping the first .0 ;-) ). And use 
> simply 
> a major number and a minor number for the version.
> 
> An yearly version on the other hand seems a good compromise. Again gcc is a 
> good model.

I don't have a strong opinion on this. Does anyone else?

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] Length.cpp: add new unit representing \baselineskip

[Scott Kostyshak]

On Sat, Apr 08, 2017 at 03:30:29AM +0200, Uwe Stöhr wrote:
> commit b3b7675f544128ea4bbff564262774533af3598f
> Author: Uwe Stöhr 
> Date:   Sat Apr 8 03:30:21 2017 +0200
> 
> Length.cpp: add new unit representing \baselineskip
> 
> - fileformat change

This commit broke the test

  check_Length

I'm guessing that there is no regression and that the test just needs to
be updated. Uwe, can you please take a look?

Scott


signature.asc
Description: PGP signature

Re: [patch] fix for bug 10440 (LyX.exe does no longer work on command line)

[Scott Kostyshak]

On Mon, Apr 10, 2017 at 01:38:49AM +0200, Uwe Stöhr wrote:
> Bug http://www.lyx.org/trac/ticket/10440
> in at least on Windows a major issue.

I agree.

> 5 months ago the user "backbone" presented a patch that fixes the bug for me
> (see attached).
> I don't understand what is wrong wit this patch and all further patches do
> not work.

See comment 15. backbone replied to this question.

I agree that this issue is important. We are waiting for input from
Georg. If Georg does not have time to take a look before alpha, then we
will need to make a decision without him.

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] Add support to cross out characters

[Scott Kostyshak]

On Mon, Apr 10, 2017 at 01:00:07AM +0200, Uwe Stöhr wrote:

> However, I still think that we should not leave the WYSIWYM track in favor
> of WYSIWYG. The number of strokes is not important within LyX. The user
> should see that there will be strokes and that is it.

That's exactly the problem: For certain zoom levels, I see strokes and
that is it. I see no text behind the strokes. See the attached
screenshot. Do you see the problem that I'm referring to?

Scott


signature.asc
Description: PGP signature

Re: prefs2prefs.py not compatible with python3 [PATCH]

[Scott Kostyshak]

On Sat, Apr 08, 2017 at 08:59:04PM +0200, Stephan Witt wrote:
> Am 06.04.2017 um 03:10 schrieb Scott Kostyshak :
> > 
> > On Sat, Apr 01, 2017 at 09:49:13AM +0100, José Abílio Matos wrote:
> >> On Saturday, 1 April 2017 06.16.55 WEST Scott Kostyshak wrote:
> >>> José, any thoughts?
> >> 
> >> The changes are reasonable and in line with what has been done in other 
> >> places.
> >> So if it works for both python 2 and 3 it should go in. :-)
> > 
> > Thanks, Stephan do you want to commit?
> 
> Yes, thanks for asking. I did it now.

Thanks.

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] Work around bug in QTextLine::xToCursor

[Scott Kostyshak]

On Thu, Apr 06, 2017 at 01:46:32PM +0200, Jean-Marc Lasgouttes wrote:
> Le 06/04/2017 à 05:05, Scott Kostyshak a écrit :
> > To make sure I understand, you are against the attached patch because
> > the changes are not as complicated as in the iconv case, right?
> 
> No, I would be against the attached because it is wrong: what should be in
> ifdef is the
>   if(){} else{}
> and the comment above it. The patch does some code cleanup that is good in
> any case.

Ah I see.

> What I meant earlier is that I was lazy to do it and what not sure it would
> worth the effort. But please have a go at it.

OK. Actually, I will leave it be.

Thanks,

Scott


signature.asc
Description: PGP signature

[patch] fix bug 10270 - allow float placements for rotated floats

[Uwe Stöhr]

As reported in
http://www.lyx.org/trac/ticket/10270
LyX forbids incorrectly the float placement options.

The attached patch fixed this.

I don't think that a fileformat change is necessary but I could of 
course do this.


regards Uwe
 src/frontends/qt4/FloatPlacement.cpp | 12 ++--
 src/insets/InsetFloat.cpp|  2 +-
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/src/frontends/qt4/FloatPlacement.cpp 
b/src/frontends/qt4/FloatPlacement.cpp
index b446c7c057..3ce414ed44 100644
--- a/src/frontends/qt4/FloatPlacement.cpp
+++ b/src/frontends/qt4/FloatPlacement.cpp
@@ -245,17 +245,17 @@ void FloatPlacement::checkAllowed() const
bool const span = spanCB->isChecked();
bool const sideways = sidewaysCB->isChecked();
defaultsCB->setEnabled(!sideways);
-   topCB->setEnabled(!sideways && !defaults && !heredefinitely
+   topCB->setEnabled(!defaults && !heredefinitely
  && contains(allowed_placement_, 't'));
-   bottomCB->setEnabled(!sideways && !defaults && !span && 
!heredefinitely
+   bottomCB->setEnabled(!defaults && !span && !heredefinitely
 && contains(allowed_placement_, 'b'));
-   pageCB->setEnabled(!sideways && !defaults && !heredefinitely
+   pageCB->setEnabled(!defaults && !heredefinitely
   && contains(allowed_placement_, 'p'));
-   herepossiblyCB->setEnabled(!sideways && !defaults && !span && 
!heredefinitely
+   herepossiblyCB->setEnabled(!defaults && !span && !heredefinitely
   && contains(allowed_placement_, 
'h'));
-   heredefinitelyCB->setEnabled(!sideways && !defaults && !span
+   heredefinitelyCB->setEnabled(!defaults && !span
 && contains(allowed_placement_, 
'H'));
-   ignoreCB->setEnabled(!sideways && !defaults && ignore && 
!heredefinitely
+   ignoreCB->setEnabled(!defaults && ignore && !heredefinitely
 && contains(allowed_placement_, '!'));
spanCB->setEnabled(allows_wide_ && (!sideways || 
standardfloat_));
sidewaysCB->setEnabled(allows_sideways_);
diff --git a/src/insets/InsetFloat.cpp b/src/insets/InsetFloat.cpp
index 7a95178227..c3feb0e5ba 100644
--- a/src/insets/InsetFloat.cpp
+++ b/src/insets/InsetFloat.cpp
@@ -390,7 +390,7 @@ void InsetFloat::latex(otexstream & os, OutputParams const 
& runparams_in) const
os.texrow().start(runparams.lastid, runparams.lastpos);
// We only output placement if different from the def_placement.
// sidewaysfloats always use their own page
-   if (!placement.empty() && !params_.sideways)
+   if (!placement.empty())
os << '[' << from_ascii(placement) << ']';
os << '\n';
 

Re: [patch] support for fontspec options

[Uwe Stöhr]

El 10.04.2017 a las 00:44, Uwe Stöhr escribió:

And that way I googled around. Googling brings you quickly to the 
"Script=Devanagari option. So one doesn't need to be a TeXpert to find 
this. One now only needs an input field for that option. When this is 
implemented I can update our Wiki pages accordingly.

Therefore I still think that this is a valuable feature.


It is like with bug
http://www.lyx.org/trac/ticket/8034
, we wait for years now and I don't see a reason why we don't start to 
implement the possibilities to add options to fontspec and also to 
polyglossia now.


Our Arabic translator would need the polyglossia options feature too:
http://www.lyx.org/trac/ticket/9577

regards Uwe

[patch] fix for bug 10440 (LyX.exe does no longer work on command line)

[Uwe Stöhr]

Bug http://www.lyx.org/trac/ticket/10440
in at least on Windows a major issue.

5 months ago the user "backbone" presented a patch that fixes the bug 
for me (see attached).
I don't understand what is wrong wit this patch and all further patches 
do not work.


Therefore the patch should go in if it doesn't have effects for other 
OSes. The aim of this discussion to fix the bug soon (if possible even 
for LyX 2.2.3).


regards Uwe
diff --git 
"a/C:\\Users\\Usti\\AppData\\Local\\Temp\\TortoiseGit\\LyX-d568846.000.cpp" 
"b/D:\\LyXGit\\Master\\src\\LyX.cpp"
index 12bdbe..4075db6b55 100644
--- "a/C:\\Users\\Usti\\AppData\\Local\\Temp\\TortoiseGit\\LyX-d568846.000.cpp"
+++ "b/D:\\LyXGit\\Master\\src\\LyX.cpp"
@@ -315,9 +315,13 @@ int LyX::exec(int & argc, char * argv[])
LYXERR(Debug::LOCALE, message.title_ + ", " + message.details_);
}
 
+   // Bug #10440: argv modification leads to runtime error with msvc 2015, 
so copy them
+   char ** argv_local = new char * [argc + 1];
+   memcpy (argv_local, argv, (argc + 1) * sizeof (char *));
+
// Here we need to parse the command line. At least
// we need to parse for "-dbg" and "-help"
-   easyParse(argc, argv);
+   easyParse(argc, argv_local);
 
 #if QT_VERSION >= 0x050600
// Check whether Qt will scale all GUI elements and accordingly
@@ -346,7 +350,7 @@ int LyX::exec(int & argc, char * argv[])
setLocale();
 
if (!use_gui) {
-   LyXConsoleApp app(this, argc, argv);
+   LyXConsoleApp app(this, argc, argv_local);
 
// Reestablish our defaults, as Qt overwrites them
// after creating app
@@ -356,7 +360,7 @@ int LyX::exec(int & argc, char * argv[])
}
 
// Let the frontend parse and remove all arguments that it knows
-   pimpl_->application_.reset(createApplication(argc, argv));
+   pimpl_->application_.reset(createApplication(argc, argv_local));
 
// Reestablish our defaults, as Qt overwrites them
// after createApplication()
@@ -364,7 +368,8 @@ int LyX::exec(int & argc, char * argv[])
 
// Parse and remove all known arguments in the LyX singleton
// Give an error for all remaining ones.
-   int exit_status = init(argc, argv);
+   int exit_status = init(argc, argv_local);
+   delete [] argv_local;
if (exit_status) {
// Kill the application object before exiting.
pimpl_->application_.reset();

Re: [LyX/master] Add support to cross out characters

[Uwe Stöhr]

El 06.04.2017 a las 11:10, Jean-Marc Lasgouttes escribió:

That is not how it works. Actually, I propose to add a rule to our 
coding rules that says that no code which does not take in account zoom 
and DPI when drawing should be accepted (with the usual exceptions, of 
course).


I have not heard about this rule. I also sent the patch to the list for 
some days before I put it in. I haven't got this info from you.


You search for ulem.sty, which is full of horrible code. Then you search 
in there for the definition of \xout, which is admittedly still weird, 
but simpler:

\def\xout{\bgroup \markoverwith{\hbox to.35em{\hss/\hss}}\ULon}

What does it tell us? That the strike out is obtained with a `/' 
character, and that it is spaced with 0.35em. This should be enough to 
make an easy and good lookalike screen representation.


I don't get it. Seems that I have been away for too long. At first, yes 
I can read TeX code, yes I experimented with painting including the

zoom.
I could not find a better solution that I proposed. When zooming out a 
lot one got no stroke at all.


However, I still think that we should not leave the WYSIWYM track in 
favor of WYSIWYG. The number of strokes is not important within LyX. The 
user should see that there will be strokes and that is it. That is the 
WYSIWYM concept. As I understand you, you want me to use the currently 
selected screen font to draw a '/' character over the text that is 
repeated by 0.35em (in pixels). That is quite complicated (at least for 
me) and I don't see the benefit. That would be WYSIWYG. Is this really 
necessary?


thanks and regards
Uwe

Re: [LyX/master] MathsUi.ui: adjust dimensions as requested

[Uwe Stöhr]

El 07.04.2017 a las 22:19, Guillaume MM escribió:


- 411
- 351
+ 480
+ 350


One should need to rely on the indicative pixel size which does not take 
into account the platform, dpi and language. This probably indicates 
that the ui file is broken.


I don't understand. I have not changed the UI file in the way that I 
added the  tag. It was there before as you can see in the changes.
I use the official Qt 5.6 designer to edit the UI files. I always did so 
and until now I did not get any problems.
I think the problem here was the QVBoxLayout is rendered different on 
different machines. I don't know why. I removed it now.


regards Uwe

Re: [patch] support for fontspec options

[Uwe Stöhr]

El 09.04.2017 a las 10:27, Jürgen Spitzmüller escribió:


In any case, such features need to be implemented at the beginning of
new development cycles, since they need testing and improvement, not at
the end of cycles.


I don't understand. We are talking about 3 simple line edits. As you can 
see in the patch, this not a massive change in anything. It is just to 
provide a field to enter package options. I mean we also provide such a 
field where the user can enter "T1" or a font encoding of his choice. I 
don't see any difference to the 3 edit fields I proposed.


Concerning the cycles. I have not contributed much for months due to 
lack of time. now I had a week in late shift. That sucks, but gives time 
at night that can be used. In fact I cannot plan my life for development 
cycles. As I said, unless anything is announced that new features are no 
longer allowed, I think I can send patches.



\setmainfont[Script=Devanagari
is sometimes necessary. Inputting the Script option is currently
almost
impossible if you are not a LaTeX master.


You need the same level of LaTeX knowledge (or knowledge of the
fontspec package, for that matter) in order to use your proposed UI. It
does not make things easier at all. It will rather confuse users who do
not know what to enter there (and if they know, adding a line to the
preamble is in no way more difficult).


I see it differently. A good friend of mine is from India and he once 
asked me about LyX. I created a Wiki page:

https://wiki.lyx.org/Windows/Devanagari
And that way I googled around. Googling brings you quickly to the 
"Script=Devanagari option. So one doesn't need to be a TeXpert to find 
this. One now only needs an input field for that option. When this is 
implemented I can update our Wiki pages accordingly.

Therefore I still think that this is a valuable feature.


we speak about adding simply 3 line edit fields.


Which make the dialog unnecessarily wide and which nobody can use
without having the fontspec manual open. It's bad UI design.


To be constructive. Why don't you propose a better UI? It cannot be that 
complicated to decide where 3 edit fields belong to.
And as you can see in my patch, I have not increased the width of the 
dialog.



I plan to implement some generic key-value dialog widget in the 2.4
cycle. This would translate key-value option to either checkboxes
(booleans), combos (closed lists), editable combos (open lists) or line
widgets (text input). The UI could be oriented for instance at the UI
of the Qt designer. It occurred to me that such a thing is needed to
implement the rest of biblatex, but it will also be useful for class
and package options, and it can be used to implement a proper font
features UI.


That would be a massive change. Since I cannot see much difference to 
the line edit for the font encoding I don't see why we must wait for the 
2.4. cycle to add the new edit fields. As you plan to rearrange them 
anyway soon, you will in any case shift everything around.
I mean when you e.g manufacture a car and an engineer proposes to add a 
second inner mirror, you are able to do this even as you know that will 
will redesign the car for in future. Then the future car will have also 
2 inner mirrors, but maybe with another shape and in another position.



I implemented that the fields are only active when fontspec is
actually
used. If you see here mistakes in my patch, please tell me.


Yet they are still visible (and hence clutter the dialog) when fontspec
is not used.


That is easy to change. So if we would find a suitable position for the 
fields I will add this to the patch.

That's what I do. But you seem to always take criticism personally,
whereas I am criticizing the implementation proposal, not you.


It depends on how you say things. I took it personally. But it is OK now.

regards Uwe

Re: [patch] support for fontspec options

[Jürgen Spitzmüller]

Am Freitag, den 07.04.2017, 00:44 +0200 schrieb Uwe Stöhr:
> Since many years LyX misses the feature to input options to the font 
> loading commands \setmainfont etc. We did not act for 5 years
> because 
> you said exactly the same as today that it is not the right time:
> http://www.lyx.org/trac/ticket/8226#comment:2

The comment you refer to was posted when fontspec basic support was
just added. I argued that this basic support needs testing and bug
fixing before we start to add new features to it, and it turned out
that this was no wrong prediction.

In any case, such features need to be implemented at the beginning of
new development cycles, since they need testing and improvement, not at
the end of cycles.

> There might perhaps never be the right time, so let's eventually do
> it! 

I agree it should be done eventually. But properly, with a thought-out
UI and some real testing time.

The feature is important for several languages:
> 
> \setmainfont[Script=Devanagari
> 
> is sometimes necessary. Inputting the Script option is currently
> almost 
> impossible if you are not a LaTeX master. 

You need the same level of LaTeX knowledge (or knowledge of the
fontspec package, for that matter) in order to use your proposed UI. It
does not make things easier at all. It will rather confuse users who do
not know what to enter there (and if they know, adding a line to the
preamble is in no way more difficult).

> Therefore the right way to do 
> this is to provide an input field for all options people might need.
> So 
> we speak about adding simply 3 line edit fields.

Which make the dialog unnecessarily wide and which nobody can use
without having the fontspec manual open. It's bad UI design.

A good UI design takes time and thinking. I have thought for _months_
about how to implement biblatex UI-wise before I even started to code
one line (this is why it took so long). I don't say that this feature
is as complex as Biblatex, but going "let's implement the feature and
fix the UI later" is always a bad idea.

In general, the "Fonts pane" needs to be re-thought. Particularly
during this cycle, new widgets have been added (microtype, em-dash)
which I think make this pane inconsistent. I do not have a good idea
yet (I think we need some kind of "Advanced Font Features" subdialog or
pane), but as I said, this needs time and thinking.

> 
> I think the fields are at the right tab where I put them. Of course
> we 
> can rearrange their position and size. Please make a proposal.

I plan to implement some generic key-value dialog widget in the 2.4
cycle. This would translate key-value option to either checkboxes
(booleans), combos (closed lists), editable combos (open lists) or line
widgets (text input). The UI could be oriented for instance at the UI
of the Qt designer. It occurred to me that such a thing is needed to
implement the rest of biblatex, but it will also be useful for class
and package options, and it can be used to implement a proper font
features UI.


> I implemented that the fields are only active when fontspec is
> actually 
> used. If you see here mistakes in my patch, please tell me.

Yet they are still visible (and hence clutter the dialog) when fontspec
is not used.

> 
> So again, please be constructive and help.
> 
> Concerning the features of LyX 2.3. Scott encouraged me to have a
> look 
> for features I proposed to LyX 2.3. So I took some spare time after
> a 
> long break with LyX and came up with some patches for new features.
> Unless a feature freeze is announced one could work on features. If I
> am 
> encouraged to look and decide what could be part of LyX 2.3 I think
> I 
> should be treated fair and my patches should be reviewed in a normal
> manner.

That's what I do. But you seem to always take criticism personally,
whereas I am criticizing the implementation proposal, not you.

> I already skipped things I won't have time to implement or that would
> be 
> too massive changes for LyX 2.3.

Everybody does that (fortunately).

Jürgen

> 
> thanks and regards
> Uwe

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