Re: [patch] support for fontspec options
Am Dienstag, den 11.04.2017, 08:30 +0200 schrieb Jürgen Spitzmüller: > Am Montag, den 10.04.2017, 00:44 +0200 schrieb Uwe Stöhr: > > I don't understand. We are talking about 3 simple line edits. > > And I tried to argue that I think these line edits are not a suitable > UI. > > > 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. > > It is much more different, since the line edit are supposed complex > key-value pairs. Supposed _to take_ complex kv-pairs. And besides that, you cannot simply add a fontend line to the preamble, since fontenc needs to be loaded early (and we use the fontenc value at other places when encodings are changed). Jürgen signature.asc Description: This is a digitally signed message part
Re: [patch] support for fontspec options
Am Montag, den 10.04.2017, 01:47 +0200 schrieb Uwe Stöhr: > 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. Yes, but putting in a line edit that just pretends native support and actually does not any benefit over the preamble is not a real solution to this. It just hides the actual problem. Jürgen > > Our Arabic translator would need the polyglossia options feature too: > http://www.lyx.org/trac/ticket/9577 > > regards Uwe signature.asc Description: This is a digitally signed message part
Re: [patch] support for fontspec options
Am Montag, den 10.04.2017, 00:44 +0200 schrieb Uwe Stöhr: > I don't understand. We are talking about 3 simple line edits. And I tried to argue that I think these line edits are not a suitable UI. > 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. It is much more different, since the line edit are supposed complex key-value pairs. > 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. You can also store your work and submit it when the new cycle starts. > > > > \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. But googling also brings you to the whole macro. This is really no step forward. > To be constructive. Why don't you propose a better UI? I did. > It cannot be that > complicated to decide where 3 edit fields belong to. Certainly not. But the point is that these 3 edit fields are a wrong design decision to begin with. > And as you can see in my patch, I have not increased the width of > the > dialog. I see an increasement. > > 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 repeat what I wrote in the last mail: going "let's implement the feature and fix the UI later" is always a bad idea. > > > 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. "let's implement the feature and fix the UI later" is always a bad idea. > > 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. Good. Jürgen > > regards Uwe signature.asc Description: This is a digitally signed message part
Re: [patch] fix float label (bug 10618)
Le 11/04/2017 à 02:53, Uwe Stöhr a écrit : The attached simple patch fixes http://www.lyx.org/trac/ticket/10618 The bug is that on opening /saving a file only the float type is written to the label. But there exists a detailed label writing function that is just not called (only on buffer update). OK to go in or have I overseen anything? If it goes in, this would be a candidate for LyX 2.2.3 as well. This looks OK to me. JMarc
Re: Tentative schedule for 2.3.0 release
On 11/04/2017 2:45 p.m., Scott Kostyshak wrote: A second reason to keep the alpha is that very few Windows and Mac users can compile a development version. An alpha is nice in situations where we cannot reproduce a bug. We can ask users if they can still reproduce e.g. a serious crash that they reported. This can let us know if that issue is something we need to focus on fixing before a beta. On Mon, Apr 10, 2017 at 11:58:51AM +0200, Jean-Marc Lasgouttes wrote: Seriously, I am not sure about the alpha release. It is serious work, and I am not sure what we will gain from it (how many user would try it, but not try nightlies, for example). Have we produced nightlies before? Doesn't that require an automatic build system for Mac and Windows? I hope others join this conversation. To alpha or not to alpha? Scott For what it's worth, both alpha1 and alpha2 of the LyX 2.2 release had significant bugs on windows (http://marc.info/?l=lyx-users&m=144833725611421&w=2 and http://marc.info/?l=lyx-devel&m=144878562018319&w=2). Andrew --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: LyX docs: cleaning up math options
On Mon, Nov 21, 2016 at 10:00:19PM -0500, Scott Kostyshak wrote: > On Mon, Nov 21, 2016 at 05:13:55PM +, Jean-Pierre Chrétien wrote: > > > 88% tests passed, 669 tests failed out of 5553 > > Does this sound correct? I have TL2016 with all language collections and > > fonts installed. > > Doesn't seem too strange. If I run all the tests, I get 148 failing out > of 6469, but this is because I have spent a lot of time satisfying the > dependencies of the tests so that is expected. > > > I won't touch the files with option 2 (always load). > > Why not? I would prefer to change those to automatic also. > > > Any further idea ? In particular, should I run ctest with other options > > than export? > > I think your plan is good. I will also save my ctest results > before/after your changes so I will double-check that no tests go from > passing to failing. > > Thanks, > > Scott Jean-Pierre, Any update on this? Scott signature.asc Description: PGP signature
Re: [LyX/master] Add support to cross out characters
On Thu, Apr 06, 2017 at 09:41:57AM +0100, José Abílio Matos wrote: > On Thursday, 6 April 2017 02.56.51 WEST Scott Kostyshak wrote: > > I see it's used in other places in lyx2lyx (grep for '== True'), so > > perhaps this is convention in Python? > > Nope. > > The convention is the former: > > if changed: > ... I was going to make this change, but then I checked more globally and there are instances of the "== true" in our C++ code. If someone wants me to change this for the instances in our C++ and our Python code, I will put this on my TODO list after the release of 2.3.0 (we might as well make this change at the beginning of a cycle). Otherwise, I will forget about it. To see instances in other parts of the code, run git grep -i "== true" Scott signature.asc Description: PGP signature
Re: Tentative schedule for 2.3.0 release
On Mon, Apr 10, 2017 at 09:46:45AM +0200, Jean-Marc Lasgouttes wrote: > It was proably discussed last time, but I do not remember: what is the > rationale for having an alpha before feature freeze? Shouldn't it be > the opposite? The requirements and expectations of an alpha are low. I think it is understood that there should not be any big features right before the feature freeze. But doing it this way allows us to get an alpha out quickly and get testing on 99% of the features that will go into the final release. On Mon, Apr 10, 2017 at 11:23:16AM +0100, José Abílio Matos wrote: > OTHO I remember that as the release manager of one of the previous releases > the alpha release was the first moment to the test and lubricate the release > procedure. To guarantee that tools like "make distcheck" work as intended. By > decoupling this from the beta stage where we should by then be in feature > freeze the testing was easier. > Note that this is my personal recollection, I can be wrong. :-) Indeed, this is nice. I think it was more important last time when it was the first time I was release manager. It was good for me to practice the fun process of signing the files, make sure upload to FTP works, etc. > With that said we have improved the test and maintenance of the release tools > and since the last version was released less than one year ago and Scott is > the release manager I agree that we can skip this version. But clearly this > is > Scott's call. I am inclined to keep the alpha but am open to more discussion. One reason for keeping the alpha is that we do not have strong requirements to get it out. It is a way to start the ball rolling. Requirements to release a beta are more strict, and it is nice to break up a big task into smaller more achievable tasks. A second reason to keep the alpha is that very few Windows and Mac users can compile a development version. An alpha is nice in situations where we cannot reproduce a bug. We can ask users if they can still reproduce e.g. a serious crash that they reported. This can let us know if that issue is something we need to focus on fixing before a beta. On Mon, Apr 10, 2017 at 11:58:51AM +0200, Jean-Marc Lasgouttes wrote: > Seriously, I am not sure about the alpha release. It is serious work, and I > am not sure what we will gain from it (how many user would try it, but not > try nightlies, for example). Have we produced nightlies before? Doesn't that require an automatic build system for Mac and Windows? I hope others join this conversation. To alpha or not to alpha? Scott signature.asc Description: PGP signature
Re: Use Qt 5.9.0 for Mac/Win binaries?
On Mon, Apr 10, 2017 at 09:41:56AM +0200, Jean-Marc Lasgouttes wrote: > I would expect LTS to be a safe, conservative choice, but I may be > wrong. I think you are right. Scott signature.asc Description: PGP signature
Re: Use Qt 5.9.0 for Mac/Win binaries?
On Mon, Apr 10, 2017 at 11:47:40PM +0200, Uwe Stöhr wrote: > El 10.04.2017 a las 09:41, Jean-Marc Lasgouttes escribió: > > > I have not followed the recent Qt development, but I find it depressing > > that we have to use the latst and greatest because anything older has > > significant issues. I would expect LTS to be a safe, conservative > > choice, but I may be wrong. > > My experience with Qt is that .0 releases often had bugs. Therefore I waited > for 4.8.1 etc. I also see that bugs are often not fixed for older releases. > With the LTS versions QT went another way. Now they try to backport the > major bugfixes. > > Therefore I would like to use the latest Qt LTS version. This is still > version 5.6 (just a year old). They plan to release a new bugfix version of > 5.6 soon. OK 5.6 sounds like a good and safe idea. Unless we know of bugs (I don't) that affect LyX that are fixed, we can stick with that. Thanks for the comments, Scott signature.asc Description: PGP signature
Re: [LyX/master] Add support to cross out characters
On Mon, Apr 10, 2017 at 11:20:51PM +0200, Uwe Stöhr wrote: > El 10.04.2017 a las 10:43, Jean-Marc Lasgouttes escribió: > > > > I have not heard about this rule. > > > > This is why there is the word "propose" in the sentence above. > > OK. Nevertheless I support this rule. Btw. where can I find accepted rules? The only place I know is Development.lyx. Scott signature.asc Description: PGP signature
Re: [LyX/master] Length.cpp: add new unit representing \baselineskip
On Tue, Apr 11, 2017 at 02:58:08AM +0200, Uwe Stöhr wrote: > El 10.04.2017 a las 05:35, Scott Kostyshak escribió: > > > 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? > > How is this test executed? What problems do you get and where is the test > defined? If you use CMake, you can run: ctest -R "check_Length" For autotools, I think this test is run when you do make check make distcheck But I think the test has been fixed. Scott signature.asc Description: PGP signature
Re: [LyX/master] Length.cpp: add new unit representing \baselineskip
El 10.04.2017 a las 05:35, Scott Kostyshak escribió: 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? How is this test executed? What problems do you get and where is the test defined? I only find check_Length.cpp which compiles here without errors or warnings. regards Uwe
[patch] fix float label (bug 10618)
The attached simple patch fixes http://www.lyx.org/trac/ticket/10618 The bug is that on opening /saving a file only the float type is written to the label. But there exists a detailed label writing function that is just not called (only on buffer update). OK to go in or have I overseen anything? If it goes in, this would be a candidate for LyX 2.2.3 as well. reards Uwe
Re: [patch] fix bug 10270 - allow float placements for rotated floats
El 10.04.2017 a las 11:05, Jean-Marc Lasgouttes escribió:
These environment always put the result its own page for technical
reasons. All the original reporter said is "I think the 'Here if
possible' and 'Here definitely' GUI options should still remain available".
I think we have here the same case as with \baselineskip. LaTeX allows
all placement options. They might not be sensible but if the user wants
to use them we should not forbid them like we do not forbid
\baselineskip as horizontal length.
I rethought the patch and think a fileformat is necessary. Attached is
an updated patch where I for now disabled the top and bottom placement
ans you proposed.
thanks and regards
Uwe
development/FORMAT | 4 +++
lib/lyx2lyx/lyx_2_3.py | 49 +++-
src/frontends/qt4/FloatPlacement.cpp | 9 ---
src/insets/InsetFloat.cpp| 2 +-
src/tex2lyx/text.cpp | 5
src/version.h| 4 +--
6 files changed, 65 insertions(+), 8 deletions(-)
diff --git a/development/FORMAT b/development/FORMAT
index 13dad66442..0a2de0370d 100644
--- a/development/FORMAT
+++ b/development/FORMAT
@@ -7,6 +7,10 @@ changes happened in particular if possible. A good example
would be
---
+2017-04-11 Uwe Stöhr
+ * Format incremented to 540: support for rotated float placements
+ - no new LFUN or buffer parameters
+
2017-04-08 Uwe Stöhr
* Format incremented to 539: support for \baselineskip.
- new length unit BLS
diff --git a/lib/lyx2lyx/lyx_2_3.py b/lib/lyx2lyx/lyx_2_3.py
index 392f5e5dbc..23eee11d11 100644
--- a/lib/lyx2lyx/lyx_2_3.py
+++ b/lib/lyx2lyx/lyx_2_3.py
@@ -2063,6 +2063,51 @@ def revert_baselineskip(document):
i = i + 1
+def revert_rotfloat(document):
+ " Revert placement options for rotated floats "
+ i = 0
+ j = 0
+ k = 0
+ while True:
+i = find_token(document.body, "sideways true", i)
+if i != -1:
+ regexp = re.compile(r'^.*placement.*$')
+ j = find_re(document.body, regexp, i-2)
+ if j == -1:
+ return
+ if j != i-2:
+ i = i + 1
+ continue
+else:
+ return
+# we found a sideways float with placement options
+# at first store the placement
+beg = document.body[i-2].rfind(" ");
+placement = document.body[i-2][beg+1:]
+# check if the option'H' is used
+if placement.find("H") != -1:
+ add_to_preamble(document, ["\\usepackage{float}"])
+# now check if it is a starred type
+if document.body[i-1].find("wide true") != -1:
+ star = '*'
+else:
+ star = ''
+# store the float type
+beg = document.body[i-3].rfind(" ");
+fType = document.body[i-3][beg+1:]
+# now output TeX code
+endInset = find_end_of_inset(document.body, i-3)
+if endInset == -1:
+ document.warning("Malformed LyX document: Missing '\\end_inset' of Float
inset.")
+ return
+else:
+ document.body[endInset-2: endInset+1] = put_cmd_in_ert("\\end{sideways"
+ fType + star + '}')
+ document.body[i-3: i+2] = put_cmd_in_ert("\\begin{sideways" + fType +
star + "}[" + placement + ']')
+ add_to_preamble(document, ["\\usepackage{rotfloat}"])
+
+i = i + 1
+
+
##
# Conversion hub
#
@@ -2099,10 +2144,12 @@ convert = [
[536, []],
[537, []],
[538, [convert_mathindent]],
- [539, []]
+ [539, []],
+ [540, []]
]
revert = [
+ [539, [revert_rotfloat]],
[538, [revert_baselineskip]],
[537, [revert_mathindent]],
[536, [revert_xout]],
diff --git a/src/frontends/qt4/FloatPlacement.cpp
b/src/frontends/qt4/FloatPlacement.cpp
index b446c7c057..d0c7a58bcf 100644
--- a/src/frontends/qt4/FloatPlacement.cpp
+++ b/src/frontends/qt4/FloatPlacement.cpp
@@ -244,18 +244,19 @@ void FloatPlacement::checkAllowed() const
if (spanCB->isVisible()) {
bool const span = spanCB->isChecked();
bool const sideways = sidewaysCB->isChecked();
- defaultsCB->setEnabled(!sideways);
topCB->setEnabled(!sideways && !defaults && !heredefinitely
&& contains(allowed_placement_, 't'));
bottomCB->setEnabled(!sideways && !defaults && !span &&
!heredefinitely
&& contains(allowed_placement_, 'b'));
pageCB->setEnabled(!sideways && !defaults && !heredefinitely
&& contains(allowed_placement_, 'p'));
- herepossiblyCB->setEnabled(!sideways && !defaults && !span &&
!heredefinitely
+ if (!pageCB->isChecked())
+ pageCB->setChecked(sideways &&
contains(allowed_placement_, 'p'));
+ herepossiblyCB->setEnabled(!defaults && !span && !heredefinitely
Re: Use Qt 5.9.0 for Mac/Win binaries?
El 10.04.2017 a las 09:41, Jean-Marc Lasgouttes escribió: I have not followed the recent Qt development, but I find it depressing that we have to use the latst and greatest because anything older has significant issues. I would expect LTS to be a safe, conservative choice, but I may be wrong. My experience with Qt is that .0 releases often had bugs. Therefore I waited for 4.8.1 etc. I also see that bugs are often not fixed for older releases. With the LTS versions QT went another way. Now they try to backport the major bugfixes. Therefore I would like to use the latest Qt LTS version. This is still version 5.6 (just a year old). They plan to release a new bugfix version of 5.6 soon. regards Uwe
Re: [patch] fix for bug 10440 (LyX.exe does no longer work on command line)
El 10.04.2017 a las 05:33, Scott Kostyshak escribió: 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 don't understand this comment. Enrico replied that what backbone understood in the comment was not what he meant. However, I don't know anything here concerning the code, but I can tell that I had the patch often and at least on Windows it works fine. 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. This bug is also in LyX 2.2.x so we should act independent of LyX 2.3. regards Uwe
Re: [LyX/master] Add support to cross out characters
El 10.04.2017 a las 23:20, Uwe Stöhr escribió: You mean that formulas are now also indented within LyX. I'll have a look but. I had a look but failed as often: I cannot find a start point where displayed formulas are painted. I often have to stop at this point. LyX needs like a sitemap where what is done. In this case I know where the different math features are painted but not where the math inset itself is painted. regards Uwe
Re: [LyX/master] Add support to cross out characters
El 10.04.2017 a las 10:43, Jean-Marc Lasgouttes escribió:
I have not heard about this rule.
This is why there is the word "propose" in the sentence above.
OK. Nevertheless I support this rule. Btw. where can I find accepted rules?
I could not find a better solution that I proposed. When zooming out a
lot one got no stroke at all.
I implemented this for you now at 94114fd1. It is even a little bit
shorter than the original code, I do not think that the price to pay was
so high for something correct.
Thanks. It works better but still the number of strokes depends on the
zoom level. For example
This is \xout{xout text}.
gives me 10 or 11 strokes (slashes) depending on the zoom level.
But more important, the problem reported by Scott is gone.
WYSIWYM is not about "I have the right to give an ugly screen output",
it is about having a visually pleasant output that tells you what your
output in a meaningful way. The only difference with WYSIWYG is that
some things (labels, footnotes, line breaks) are not represented
visually, but semantically.
Hmm, I did not design ugly screen output. Here it was an acceptable
solution. I did not see the problem of Scott. Of course for Scott it was
then indeed ugly.
So, what I mean is that mimicking LaTeX is not a requirement, it is a
trick to help you.
OK, I understand.
Now, what I would like to see is some action on the lefteqn patch ;)
What exactly? I added now a tooltip that I forgot ;-)
You mean that formulas are now also indented within LyX. I indeed never
thought about this. (I simply use fleqn for so long that I did not miss
the on-screen representation.) I'll have a look but.
regards Uwe
Re: [patch] Re: LyX master still not ready for Python 3
On Mon, Apr 10, 2017 at 03:07:34PM +0200, Jean-Marc Lasgouttes wrote: > Le 10/04/2017 à 12:27, José Abílio Matos a écrit : > > Since this fixes a bug I think that it should be committed. > > For the final version I intend to uniform all the changes that have been > > done > > to support python 2 and 3 to make the code more maintainable. > > OK, I did that. Thanks. Short on time lately. -- Enrico
Re: Tentative schedule for 2.3.0 release
Am 10.04.2017 um 05:40 schrieb 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? Yes. These dates are no problem for me. I’m in France when final is planned. But I cannot think of a hotel without network access in Europe. Stephan > > 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 >
Re: Ticket #10455
Le 10/04/2017 à 21:05, racoon a écrit : Hi! Can someone check http://www.lyx.org/trac/ticket/10455 and put it into master for testing? Best, Daniel Hello Daniel and the list, you also have http://www.lyx.org/trac/ticket/10483 http://www.lyx.org/trac/ticket/10379 http://www.lyx.org/trac/ticket/10283 they are (and remain) on my to-do list for 2.3, but anybody else please feel free to review the patches since it takes so much time for me to get back to it. Sincerely, Guillaume
Ticket #10455
Hi! Can someone check http://www.lyx.org/trac/ticket/10455 and put it into master for testing? Best, Daniel
Re: Inconsistency in "Advices for using the LyX bug tracker"
On 10.04.2017 11:14, Jean-Marc Lasgouttes wrote: Le 08/04/2017 à 09:13, racoon a écrit : In "Advices for using the LyX bug tracker" http://www.lyx.org/trac/wiki/reportingBugs It is stated: "When reporting a bug, indicate your LyX version and *platform* (the latter via TicketKeywords)." I changed the page. Is it better now? Yes, thanks! Daniel
Re: [patch] Re: LyX master still not ready for Python 3
Le 10/04/2017 à 12:27, José Abílio Matos a écrit : Since this fixes a bug I think that it should be committed. For the final version I intend to uniform all the changes that have been done to support python 2 and 3 to make the code more maintainable. OK, I did that. JMarc
Re: [patch] Re: LyX master still not ready for Python 3
On Monday, 10 April 2017 11.02.21 WEST Jean-Marc Lasgouttes wrote: > As I wrote, it fixes my problem. Do you want me to apply it, or are > there reasons to hold it? > > JMarc Since this fixes a bug I think that it should be committed. For the final version I intend to uniform all the changes that have been done to support python 2 and 3 to make the code more maintainable. -- José Abílio
Re: Tentative schedule for 2.3.0 release
On Monday, 10 April 2017 10.58.51 WEST Jean-Marc Lasgouttes wrote: > No, because doing everything by opposition to others is like doing doing > it like them: it is following their whim :-) > Seriously, I am not sure about the alpha release. It is serious work, > and I am not sure what we will gain from it (how many user would try it, > but not try nightlies, for example). > > JMarc That is a reasonable objection. In essence that was the reason to have it dropped from Fedora. OTHO I remember that as the release manager of one of the previous releases the alpha release was the first moment to the test and lubricate the release procedure. To guarantee that tools like "make distcheck" work as intended. By decoupling this from the beta stage where we should by then be in feature freeze the testing was easier. Note that this is my personal recollection, I can be wrong. :-) With that said we have improved the test and maintenance of the release tools and since the last version was released less than one year ago and Scott is the release manager I agree that we can skip this version. But clearly this is Scott's call. -- José Abílio
Jenkins build is back to normal : Build branch "master" » ubuntu-xenial-qt4-autotools-extended #148
https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-xenial-qt4-autotools-extended/148/
Re: [patch] Re: LyX master still not ready for Python 3
Le 05/04/2017 à 22:08, Enrico Forestieri a écrit : Most probably you have some non-ascii characters in a \DeclareLaTeXClass line in some of your layout files. Now those files are explicitly read as utf-8 encoded. If this is so, the attached patch should help. Another consequence of the recent changes is that if someone has old layouts containing latin1 characters then configure will now misteriously fail. As I wrote, it fixes my problem. Do you want me to apply it, or are there reasons to hold it? JMarc
Re: How far is 2.3.0?
Le 10/04/2017 à 11:49, José Abílio Matos a écrit : FWIW, IMHO it all comes to: What is the event that we think is relevant to jump to the 3.x series? If none then the first number in the 2.x.y moniker is irrelevant and it should be dropped. I agree with what you write, but it does not seem important enough to me to actually act on it :) Either way, I do not really care. The only numbering that makes a real difference to me is Year.Month, but it is not adapted to our workflow. JMarc
Re: Tentative schedule for 2.3.0 release
Le 10/04/2017 à 11:27, José Abílio Matos a écrit : Again following your reasoning since everyone is abandoning the alpha release we should keep it. ;-) No, because doing everything by opposition to others is like doing doing it like them: it is following their whim :) Seriously, I am not sure about the alpha release. It is serious work, and I am not sure what we will gain from it (how many user would try it, but not try nightlies, for example). JMarc
Re: How far is 2.3.0?
On Monday, 10 April 2017 08.50.32 WEST Jean-Marc Lasgouttes wrote: > Version numbers are just version numbers, I do not think that they make > as much of a difference than getting versions out fast. In the case of > firefox and gcc, the important part of the new release scheme was speed. > The rest is just marketing. > > JMarc My rationale is always the same we have basically major and minor versions. For major versions we introduce changes that are incompatible with older versions, in the sense that older versions can not read the new file formats (lyx file, layouts, etc). Minor versions are strictly compatible and represent incremental improvements in the same stable series. So if our development only has two types of releases we should use two numbers, the major and the minor. I remember this type of discussion that we had to jump to the 1.0 release, to jump to the 2.0 release and so on. :-) In the case of gcc btw the idea was not to get faster versions, since the release cycle was kept at one year, but to convey the message that each new major version is really a major version. The marketing even in free software projects is also important, as you know. :-) Also as a developer that has to type the version number often when comparing previous formats I would appreciate to have to type less meaningless numbers. This is a very objective argument. FWIW, IMHO it all comes to: What is the event that we think is relevant to jump to the 3.x series? If none then the first number in the 2.x.y moniker is irrelevant and it should be dropped. -- José Abílio
Re: Tentative schedule for 2.3.0 release
On Monday, 10 April 2017 08.46.45 WEST Jean-Marc Lasgouttes wrote: > It was proably discussed last time, but I do not remember: what is the > rationale for having an alpha before feature freeze? Shouldn't it be the > opposite? I think that this is the usual procedure. Take Fedora as an example, the alpha release is done before the feature freeze. The rationale, as far as I can remember, is to invite the users to test and get an idea where the project is coming and how do the new features integrate in the project. So it could be possible that some feature is deemed unready and dropped before feature freeze. On the other hand there is a proposal to drop the alpha release starting from Fedora 27 (to be released in October/November). So that means that Fedora 26 alpha, that was released last Tuesday, is the last alpha release for Fedora. Again following your reasoning since everyone is abandoning the alpha release we should keep it. ;-) -- José Abílio
Re: Inconsistency in "Advices for using the LyX bug tracker"
Le 08/04/2017 à 09:13, racoon a écrit : In "Advices for using the LyX bug tracker" http://www.lyx.org/trac/wiki/reportingBugs It is stated: "When reporting a bug, indicate your LyX version and *platform* (the latter via TicketKeywords)." I changed the page. Is it better now? JMarc
Re: [patch] fix bug 10270 - allow float placements for rotated floats
Le 10/04/2017 à 02:21, Uwe Stöhr a écrit : As reported in http://www.lyx.org/trac/ticket/10270 LyX forbids incorrectly the float placement options. The attached patch fixed this. These environment always put the result its own page for technical reasons. All the original reporter said is "I think the 'Here if possible' and 'Here definitely' GUI options should still remain available". This comment is correct as far as I understand from my cursory google search. Nobody 'forgot' to implement sideways for sidewyas, things like 'top' or 'bottom' are correctly disabled (and page should be on but disabled IMO). JMarc
Re: [LyX/master] support to indent formulas
Le 08/04/2017 à 02:13, Uwe Stöhr a écrit : But OK, I moved it now as you requested. Thanks Uwe. JMarc
Re: [patch] support for \baselineskip
Le 08/04/2017 à 04:58, Uwe Stöhr a écrit : El 07.04.2017 a las 10:51, Jean-Marc Lasgouttes escribió: Maybe more like:... Thanks. The patch is now in including this hint and the new BLS unit is available for all lengths. Thanks. JMarc
Re: [LyX/master] Add support to cross out characters
Le 10/04/2017 à 01:00, Uwe Stöhr a écrit : 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. This is why there is the word "propose" in the sentence above. I also sent the patch to the list for some days before I put it in. I haven't got this info from you. This is why I did not complain about that. But it is not because a patch is in that it is immune of of code review (especially when there are user-visible issues). 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. I implemented this for you now at 94114fd1. It is even a little bit shorter than the original code, I do not think that the price to pay was so high for something correct. 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. WYSIWYM is not about "I have the right to give an ugly screen output", it is about having a visually pleasant output that tells you what your output in a meaningful way. The only difference with WYSIWYG is that some things (labels, footnotes, line breaks) are not represented visually, but semantically. 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? You got it wrong. What I say is a _requirement_ is to have a good output at a high zoom level (this is a good way to see what HiDPI users will see). Now, how do I find a nice way to have good output at high DPI? Wait, LaTeX does output at high DPI !! Let's see what it does and do the same if it is not too complicated! So, what I mean is that mimicking LaTeX is not a requirement, it is a trick to help you. And don't come tell me that the new code is more complicated than the old one, because it is not. Now, what I would like to see is some action on the lefteqn patch ;) JMarc
Re: Build failed in Jenkins: Build branch "master" » ubuntu-xenial-qt4-autotools-extended #145
Am Montag, 10. April 2017 um 09:43:15, schrieb Jean-Marc Lasgouttes > Le 10/04/2017 à 09:23, Kornel Benko a écrit : > > The first number is value in pixels(250) for 2342baselineskip%, > > the second is value in Big Points for 2342baselineskip% > > > > I propose more readable output for check_Length.cpp. > > For instance the attached. > > Yes, please put it in and fix the test. > > Thanks, > JMarc OK, done at 560ebc1 Kornel signature.asc Description: This is a digitally signed message part.
Re: How far is 2.3.0?
Le 10/04/2017 à 05:36, Scott Kostyshak a écrit : 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? Well, everybody is doing that. It looks like a good reason for _not_ doing it :) Version numbers are just version numbers, I do not think that they make as much of a difference than getting versions out fast. In the case of firefox and gcc, the important part of the new release scheme was speed. The rest is just marketing. JMarc
Re: Tentative schedule for 2.3.0 release
Le 10/04/2017 à 05:40, Scott Kostyshak a écrit : 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. Yes, I think it is time to think seriously about it. I propose the following schedule for the 2.3.0 release process: alpha: 22 April feature freeze: 19 May It was proably discussed last time, but I do not remember: what is the rationale for having an alpha before feature freeze? Shouldn't it be the opposite? beta:09 June RC: 12 July final: 01 August 1st of august will probably be a slow period. But there may not be a better solution. JMarc
Re: Build failed in Jenkins: Build branch "master" » ubuntu-xenial-qt4-autotools-extended #145
Le 10/04/2017 à 09:23, Kornel Benko a écrit : The first number is value in pixels(250) for 2342baselineskip%, the second is value in Big Points for 2342baselineskip% I propose more readable output for check_Length.cpp. For instance the attached. Yes, please put it in and fix the test. Thanks, JMarc
Re: Use Qt 5.9.0 for Mac/Win binaries?
Le 10/04/2017 à 06:39, Scott Kostyshak a écrit : 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. Hello, A question: do we have compelling reasons to use this instead of Qt 5.6 LTS? I have not followed the recent Qt development, but I find it depressing that we have to use the latst and greatest because anything older has significant issues. I would expect LTS to be a safe, conservative choice, but I may be wrong. JMarc
Re: Build failed in Jenkins: Build branch "master" » ubuntu-xenial-qt4-autotools-extended #145
Am Samstag, 8. April 2017 um 22:49:48, schrieb Jean-Marc Lasgouttes
> Le 08/04/2017 à 16:24, Kornel Benko a écrit :
> >> I think this is real breakage and not due to me testing things. Perhaps
> >> related to Uwe's recent changes?
> >
> > Fails under cmake too (e.g. #ctest -R check_Length)
> >
> > Diff for expected and created data
> > #diff /src/tests/regfiles/Length /src/tests/Length_data
> > 18a19
> > > 279990
> > 37a39
> > > 280
> >
> > But these are new length values, so nothing old changed.
>
> Probably related to the fact that a new unit got added, but this
> deserves to be checked by hand.
>
> JMarc
The first number is value in pixels(250) for 2342baselineskip%,
the second is value in Big Points for 2342baselineskip%
I propose more readable output for check_Length.cpp.
For instance the attached.
Kornel
signature.asc
Description: This is a digitally signed message part.
diff --git a/src/tests/check_Length.cpp b/src/tests/check_Length.cpp
index 8311e45..37286e5 100644
--- a/src/tests/check_Length.cpp
+++ b/src/tests/check_Length.cpp
@@ -18,7 +18,7 @@ void test_inPixels()
lyxrc.dpi = 72;
for (int i = Length::BP; i <= Length::UNIT_NONE; ++i) {
Length const l(2342, static_cast(i));
- cout << l.inPixels(250) << endl;
+ cout << l.inPixels(250) << " pix(250) = " << l.asString() << endl;
}
}
@@ -27,7 +27,7 @@ void test_inBP()
{
for (int i = Length::BP; i <= Length::UNIT_NONE; ++i) {
Length const l(2342, static_cast(i));
- cout << l.inBP() << endl;
+ cout << l.inBP() << " BP = " << l.asString() << endl;
}
}
