Re: Questions for Uwe once you are back

[Peter Kümmel]

Am 15.01.2016 um 22:33 schrieb Georg Baum:


And these problems do exist. The 2.2 alpha is not the first windows
binary that turned out to be built from different sources than
originally thought (http://www.lyx.org/trac/ticket/9878). I remember a
similar issue from several years ago, might be 1.6 or 2.0. This type of
mistakes (which can cost lots of hours or even days of wasted time for
several people) is easy to make with your current approach. It is very
difficult to make with my proposal.


Reading this I would say we should not release any installer with a LyX 
version build with msvc.


Uwe have you the time to build a installer with a mingw build?

If not maybe someone else finds the time, building native on Windows has 
become much simpler for Linux users:


Windows 10 .iso files are now available and it is easy to install it in 
a virtual box. No Windows keys are needed while installing and all works 
without any "key activation".





I am willing to help you to get a reproducible, clean build. I am not
willing to waste my time investigating bugs that are caused by
inconsistently built binaries.


Georg

Re: [LyX/master] Update LFUNs.lyx to current format

[Guillaume Munch]

Le 16/01/2016 10:12, Georg Baum a écrit :

Guillaume Munch wrote:


I believe as well that we should not extend the already long checklist
for format changes. Updatedocs could take care of running gen_lfuns and
then update it to the latest format.


Good idea. I added the generation of LFUNs.lyx, the version updating did
exist already. However, I think we should stick to one generator of
LFUNs.lyx in git: Either we only submit files generated by gen_lfuns.py, and
not saved by LyX or lyx2lyx (this is done up to now), or we always open and
save the file with LyX after generation and before submit. Otherwise we get
lots of unwanted whitespace changes in the diffs.



Good. But if we go this way, Development.lyx has to be updated to inform
that this is now done automatically and in particular that one should
not necessarily worry if there are more changes than expected in LFUNs.lyx.

Re: Questions for Uwe once you are back

[Peter Kümmel]

Am 15.01.2016 um 22:39 schrieb Georg Baum:

Peter Kümmel wrote:


I also don't see a problem to build from a clean git repository.
Only thing I would ensure is to "sit" on tagged release.


I agree that building from a clean git directory is not a problem concerning
the resulting build or reproducibility.

There is however one difference between building from a git tag and from the
corresponding source tar ball (which is not the main topic of this thread):
If you build from git you do not check that the tar ball is complete. In
theory, completeness of the tar ball is checked by "make distcheck", but it
does not take files into account that are only needed for windows (e.g. it
would not find whether a file from 3rdparty is missing).


I assume the tar could only be complete for an installation on Linux.

For Windows Uwe uploaded a ~200 MB zip needed to build the Windows 
installer, these files we will never pack into the tar.


On Windows it would only be possible to build a correct LyX binary with 
all the docs/translations (which I hope is already done by the build 
bot) or the recently added mingw.bat script.





Georg

Re: Questions for Uwe once you are back

[Peter Kümmel]

Am 15.01.2016 um 16:19 schrieb Stephan Witt:



Am 15.01.2016 um 15:48 schrieb Peter Kümmel :



Am 15.01.2016 um 15:01 schrieb Stephan Witt:

Am 15.01.2016 um 14:41 schrieb Peter Kümmel :


Am 14.01.2016 um 23:32 schrieb Uwe Stöhr:

Am 14.01.2016 um 21:22 schrieb Georg Baum:


So I still think that creating a new git branch and copying the files
from the tar there is the quickest and also safest way - no need to
fiddle around with any path.


Here I strongly disagree. By doing this, you have no control over the
information from the previous builds that is in the cmake cache.
Therefore it is never sure whether such a build is reproducible (e.g. if
you re-used the directory to build from git again).


I don't understand. It is up to me to decide which branch becomes
active. All other branches and their files are invisible for the
compiler and also for CMake. As I understood it CMake is only necessary
to tell the compiler where and in which order to take the files from. I
built this way now for about 2 years. Why do I need to take care of the
CMake cache? From where do you know that building from a git folder is
not reproducible? If that would be the case how can people work with git
in their jobs?


I also don't see a problem to build from a clean git repository.
Only thing I would ensure is to "sit" on tagged release.


Sorry, I sent it too early…

I think there is some misunderstanding here. You’re not talking of the
same use pattern of git.

I think it should go like this:

The git-repository checkout is the source directory.
The build directory should always be outside the source directory.
A clean build starts with removing the build directory completely.


Sure, the git tree should not be touched, and the build should be in an
build directory; I never tough some does in-source builds.


Touching the git tree was the start of the discussion. See above.


Seems, I missed the point.



Stephan

Re: [LyX/master] Prefered use of direct links to ctan, not to a mirror

[Kornel Benko]

Am Samstag, 16. Januar 2016 um 12:16:14, schrieb Jürgen Spitzmüller 

> Am Donnerstag, den 14.01.2016, 00:09 +0100 schrieb Kornel Benko:
> > commit 51bc75ca2ba3d8fb862bbbad474841327f1d9eb7
> > Author: Kornel Benko 
> > Date:   Thu Jan 14 00:07:57 2016 +0100
> > 
> > Prefered use of direct links to ctan, not to a mirror
> 
> Actually, the CTAN team always advices people to use mirror links, not
> direct links. That's why we started to systematically use mirror links
> some time ago.
> 
> Jürgen

I am confused. Citing Jean-Pierre:
In addition, I think it is better to give links to CTAN from 
www.ctan.org instead of mirrors.ctan.org,
the server shifts to a mirror is a file ends the link

I am open to either way, but it should be consistent through our docs.

Kornel


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

Re: [LyX/master] Prefered use of direct links to ctan, not to a mirror

[Guenter Milde]

On 2016-01-16, Kornel Benko wrote:
> Am Samstag, 16. Januar 2016 um 12:16:14, schrieb Jürgen Spitzmüller 
> 
>> Am Donnerstag, den 14.01.2016, 00:09 +0100 schrieb Kornel Benko:
>> > commit 51bc75ca2ba3d8fb862bbbad474841327f1d9eb7
>> > Author: Kornel Benko 
>> > Date:   Thu Jan 14 00:07:57 2016 +0100
>> > 
>> > Prefered use of direct links to ctan, not to a mirror

>> Actually, the CTAN team always advices people to use mirror links, not
>> direct links. That's why we started to systematically use mirror links
>> some time ago.

This was true at the time CTAN people had no direct access to the
www.ctan.org URL.

Since a year (or more), www.ctan.org redirects to the mirrors and is the
preferred address.

> I am confused. Citing Jean-Pierre:

>  In addition, I think it is better to give links to CTAN from
>  www.ctan.org instead of mirrors.ctan.org, the server shifts to
>  a mirror is a file ends the link

> I am open to either way, but it should be consistent through our docs.

I suggest consistently using www.ctan.org.

Günter

Re: [LyX/master] Prefered use of direct links to ctan, not to a mirror

[Jürgen Spitzmüller]

Am Donnerstag, den 14.01.2016, 00:09 +0100 schrieb Kornel Benko:
> commit 51bc75ca2ba3d8fb862bbbad474841327f1d9eb7
> Author: Kornel Benko 
> Date:   Thu Jan 14 00:07:57 2016 +0100
> 
> Prefered use of direct links to ctan, not to a mirror

Actually, the CTAN team always advices people to use mirror links, not
direct links. That's why we started to systematically use mirror links
some time ago.

Jürgen

Re: Beta hopefully soon, only waiting on Windows installer(s)

[Peter Kümmel]

Am 16. Januar 2016 23:43:12 MEZ, schrieb Scott Kostyshak :
>Dear all,
>
>Hopefully we will release beta1 very soon. As far as I'm concerned, the
>only thing we are waiting for is the Windows installer(s). The reason
>why we are waiting for this and not just proceeding with the other
>parts
>of the beta1 release is that there might be changes needed to the
>source
>to clear up the build issues. These changes should be included in
>beta1.
>There are some questions about the build process that we hope to clear
>up; and if Uwe is OK with it, I think it would be great to build both
>an
>MSVC installer and an MinGW installer. We all understand that Uwe does
>not have much time, but it also seems that it might not require too
>much
>of his time, thanks to the help from Georg, Peter, and Kornel for build
>and CMake issues.
>
>After that is cleared up, I will do some final commits and build the
>tar
>balls. It would be nice to have a day or so where there are no commits
>so that we are all encouraged to test beta1 for a day.
>
>Please let me know if I'm missing anything.
>
>Scott

I would release the beta with the available Windows installer, but would also 
mention, that because of men power this time on Windows there will be nothing 
better that beta quality. 
In the announcement you could mention that we are busy improving this, but that 
at the moment no Windows developer has the time to create a reliable installer 
and that we are very interested in someone who wanna help out. 
It would be a starter project which could be done without C++ knowledge.

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Guillaume Munch]

Le 16/01/2016 22:26, Enrico Forestieri a écrit :

On Sat, Jan 16, 2016 at 06:29:32PM +, Guillaume Munch wrote:


Le 16/01/2016 17:06, Enrico Forestieri a écrit :

On Fri, Jan 15, 2016 at 07:45:35PM +, Guillaume Munch wrote:


However, this reveals new ways of creating an "after" cursor
position:

* A visually-after cursor position appears with
Ctrl+Shift+Arrows (LFUN_*_SELECT_WORD of something like this).
It remains a right position after deselection, for instance by
doing copy and immediately paste.


I could not reproduce this one.


I can reproduce it systematically.

1. New file 2. Type something in an itemize environment 3. Enter
three times, get a separator 4. Place the cursor at the beginning
of the document 5. Ctrl+Shift+Right until the after position is
reached

optionally:

6. Do copy+paste, to get the same cursor position but with the
selection removed.


This only occurs when the separator is the last character in the
document. In this case you don't need Ctrl+Shift+Right but simply
use → to get there.


I cannot reproduce your description. My recipe works as well if there is
some paragraph after. (Also you can probably deduce from the context
that I would have noticed.)




* A logically-after cursor position appears when double
clicking the separator inset or the line.


This one was easy. It was also occurring when triple clicking.
See attached.



It is somehow better, but it is very strange because the behaviour
is not consistent: most of the time it selects the word before, but
sometimes it selects the separator (i.e. separator is removed if I
type a key). I get the second behaviour if I quadruple-click (!!)
on the separator or after it (but this was not the only way).


So, what would be missing is a visual indication that the separator
was selected. I don't know how to do that, but maybe someone else
does.


Something else: if you place the cursor before a separator and
press enter, the separator stays on the same paragraph. Is this
voluntary?


Yes. Ideally, you are at the end of the line and pressing enter there
gets you a new paragraph.


Ok, this is just something to get used to.




Also, I was wondering whether we should remove superfluous
separators in the DEPM. This would make a lot of sense to me.


Then, the same should be done for the newline inset. For example,
hit 3 or more times Ctrl+Enter in a standard layout, then remove
everything in the paragraph before the first newline inset (such
that it is now alone on the line). Now you have an uncompilable
document. At least, it could be compiled if you had multiple
separators like that.


I disagree with your newline comparison. Having several newlines
compiles to a different latex code and makes sense, and compilation
issues have nothing to do with DEPM.



Please note that we can stay here finding much more quirks in LyX
that are annoying. The point is that they are not so annoying if
they can only be obtained with uncommon operations.


The "uncommon operations" are only recipes to reproduce consistently. Of
course they can look far-fetched. I got there by trying to reproduce
behaviour that happened by chance without trying too much. I believe you
are shooting the messenger.

The editing operations in the buffer view are a critical part of lyx,
and one that does not suffer from clumsiness so far, which is essential
in particular for the learning curve given that it is so much different
from other softwares. It worries me to introduce quirks and inconsistent
behaviour in this aspect, such as not knowing whether one has to hit del
of backspace, or why the thing suddenly disappeared.



Then, this being free software, if they annoy someone so much, he
can also propose patches.



I prefer not to reply to this or we could get into considerations quite
remote from our current concerns using the same logic.

If you are worried about my suggestion about DEPM being too much for 2.2
you can just say so. You may have noticed that I used a different
phrasing, and I was ready to say that this can be filed as an
enhancement request. Please do not worry about this last suggestion.



Guillaume

Re: Beta hopefully soon, only waiting on Windows installer(s)

[Guillaume Munch]

Le 16/01/2016 22:43, Scott Kostyshak a écrit :

Dear all,

Hopefully we will release beta1 very soon. As far as I'm concerned, the
only thing we are waiting for is the Windows installer(s). The reason
why we are waiting for this and not just proceeding with the other parts
of the beta1 release is that there might be changes needed to the source
to clear up the build issues. These changes should be included in beta1.
There are some questions about the build process that we hope to clear
up; and if Uwe is OK with it, I think it would be great to build both an
MSVC installer and an MinGW installer. We all understand that Uwe does
not have much time, but it also seems that it might not require too much
of his time, thanks to the help from Georg, Peter, and Kornel for build
and CMake issues.

After that is cleared up, I will do some final commits and build the tar
balls. It would be nice to have a day or so where there are no commits
so that we are all encouraged to test beta1 for a day.

Please let me know if I'm missing anything.



I think we are waiting for a last input about tabular-modify: 
. I do not imagine 
there is any question of committing this between beta and release, so 
given that it has a file format change, it has to be before beta1 or not 
until 2.3. But as I understand we are nearly done and nobody is trying 
to postpone this.

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Guillaume Munch]

Le 16/01/2016 22:26, Enrico Forestieri a écrit :


It is somehow better, but it is very strange because the behaviour is not
consistent: most of the time it selects the word before, but sometimes it
selects the separator (i.e. separator is removed if I type a key). I get the
second behaviour if I quadruple-click (!!) on the separator or after it (but
this was not the only way).


So, what would be missing is a visual indication that the separator was
selected. I don't know how to do that, but maybe someone else does.



Forgot to reply to this one.

I do not know. I would agree with the logic that the separator cannot be
selected. I think the visual indication is a separate issue, the issue
being more that it does not behave in a predictable fashion.

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Enrico Forestieri]

On Sun, Jan 17, 2016 at 03:23:31AM +, Guillaume Munch wrote:

> Le 16/01/2016 22:31, Enrico Forestieri a écrit :
> >On Sat, Jan 16, 2016 at 07:14:56PM +, Guillaume Munch wrote:
> >
> >>Le 16/01/2016 18:34, Enrico Forestieri a écrit :
> >>>On Wed, Jan 13, 2016 at 11:15:44PM +0100, Enrico Forestieri wrote:
> On Wed, Jan 13, 2016 at 06:40:21PM +, Guillaume Munch wrote:
> >
> >Maybe ¶ does not grow on you as it did on me, but ultimately it is going
> >to be your call.
> 
> Maybe ¶ is also easier to implement and distinguishable by its different
> shading rather than color.
> >>>
> >>>I just discovered the reversed pilcrow sign ⁋ (u+204b) and used this in
> >>>the attached patch. If this is acceptable as a parbreak separator there
> >>>would be no problem as regards distinguishability.
> >>>
> >>
> >>The patch seems safe to me although I am not an expert of such code.
> >
> >I have difficulties interpreting this as a +1.
> 
> I tested the patch and convinced myself that the patch was essentially
> moving block boundaries, so I am ready to +1 if we specifically test it on
> windows in case you decide for the reversed pilcrow. Thank you for the patch
> in any case.
> 
> >
> >>However, for the reversed pilcrow, there was issues with it recently
> >>(see d9524321).
> >
> >I cannot see anything related to the reversed pilcrow there.
> 
> It removes 0x204B in Changes.cpp, but more importantly there is a link to
> the beginning of the discussion on the list. Essentially, it did not display
> on windows (I was able to check on windows 10). Maybe qt5 fixes that, and I
> would be able to test again after a windows installer is released if you
> decide to put it in beta. Other people would need to test on older versions
> of windows. Also you know that I prefer the pilcrow, but this is your call.
> Given that it is not something that we would like to change lightly, I think
> you would be justified in asking for additional tests.

I see. Then I am not going to commit the patch.

-- 
Enrico

Re: [LyX/master] Update LFUNs.lyx to current format

[Georg Baum]

Guillaume Munch wrote:

> I believe as well that we should not extend the already long checklist
> for format changes. Updatedocs could take care of running gen_lfuns and
> then update it to the latest format.

Good idea. I added the generation of LFUNs.lyx, the version updating did 
exist already. However, I think we should stick to one generator of 
LFUNs.lyx in git: Either we only submit files generated by gen_lfuns.py, and 
not saved by LyX or lyx2lyx (this is done up to now), or we always open and 
save the file with LyX after generation and before submit. Otherwise we get 
lots of unwanted whitespace changes in the diffs.


Georg

Re: Questions for Uwe once you are back

[Peter Kümmel]

Am 13.01.2016 um 00:21 schrieb Uwe Stöhr:

CMake. As soon as I create a new folder and copy there code, I need to
run CMake from scratch and specify about 40 paths (most of them to Qt).
If I make a mistake there I get strange builds.


Uwe, why do you waste you time with such a msvc2010 fiddling?
Why do you not use MinGW builds (your own or the one from the bot?
It would save you much time. You only would have to update the Installer 
nsi scripts a bit.





Georg

Re: [LyX/master] Update LFUNs.lyx to current format

[Guenter Milde]

On 2016-01-16, Georg Baum wrote:
> Guillaume Munch wrote:

>> I believe as well that we should not extend the already long checklist
>> for format changes. Updatedocs could take care of running gen_lfuns and
>> then update it to the latest format.

> Good idea. I added the generation of LFUNs.lyx, the version updating did 
> exist already. However, I think we should stick to one generator of 
> LFUNs.lyx in git: Either we only submit files generated by gen_lfuns.py, and 
> not saved by LyX or lyx2lyx (this is done up to now), or we always open and 
> save the file with LyX after generation and before submit.

Or we remove this generated file from git (my preference).

Günter

Re: two patches for ctest

[Kornel Benko]

Am Samstag, 16. Januar 2016 um 14:47:05, schrieb Guenter Milde 

> On 2016-01-13, Guenter Milde wrote:
> 
> Dear Scott,
> 
> > maybe it is not the time now, yet there are two more patches for the ctests
> > and examples in the pipeline...
> 
> > After applying the second one (aas_sample), I experienced a test failure:
> 
> > The following tests FAILED:
> > 1945 - EXAMPLES_export/examples/aas_sample_pdf4_systemF (Failed)
> > Errors while running CTest
> 
> With this failure now solved, would it be OK to commit the changes?
> 
> Günter

+1

Kornel



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

Re: Windows: release with Qt 5.5.1 or 5.6?

[Jean-Marc Lasgouttes]

We could also release both, one as the main and the other as backup.

JMarc

Le 16 janvier 2016 16:21:15 GMT+01:00, Scott Kostyshak  a 
écrit :
>We need to figure out the MSVC vs. mingw issue before releasing beta. I
>don't think it would be a good idea to release one and then switch to
>the other for final release. We have seen many installer-related issues
>in the past so it seems it is a fragile part that would not be good to
>change after beta. I am interested in other opinions though.
>
>Scott

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Guillaume Munch]

Le 16/01/2016 17:06, Enrico Forestieri a écrit :

On Fri, Jan 15, 2016 at 07:45:35PM +, Guillaume Munch wrote:


However, this reveals new ways of creating an "after" cursor position:

* A visually-after cursor position appears with Ctrl+Shift+Arrows
(LFUN_*_SELECT_WORD of something like this). It remains a right position
after deselection, for instance by doing copy and immediately paste.


I could not reproduce this one.


I can reproduce it systematically.

1. New file
2. Type something in an itemize environment
3. Enter three times, get a separator
4. Place the cursor at the beginning of the document
5. Ctrl+Shift+Right until the after position is reached

optionally:

6. Do copy+paste, to get the same cursor position but with the selection 
removed.





* A logically-after cursor position appears when double clicking the
separator inset or the line.


This one was easy. It was also occurring when triple clicking. See attached.



It is somehow better, but it is very strange because the behaviour is 
not consistent: most of the time it selects the word before, but 
sometimes it selects the separator (i.e. separator is removed if I type 
a key). I get the second behaviour if I quadruple-click (!!) on the 
separator or after it (but this was not the only way).


Something else: if you place the cursor before a separator and press 
enter, the separator stays on the same paragraph. Is this voluntary?


Also, I was wondering whether we should remove superfluous separators in 
the DEPM. This would make a lot of sense to me. There are a lot of ways 
to get superfluous separators: if I accidentally press enter 3 times 
instead of 2 while all I want is start a new paragraph, or if I do 
copy-paste...



Guillaume

Re: two patches for ctest

[Scott Kostyshak]

On Sat, Jan 16, 2016 at 04:02:55PM +0100, Kornel Benko wrote:
> Am Samstag, 16. Januar 2016 um 14:47:05, schrieb Guenter Milde 
> 
> > On 2016-01-13, Guenter Milde wrote:
> > 
> > Dear Scott,
> > 
> > > maybe it is not the time now, yet there are two more patches for the 
> > > ctests
> > > and examples in the pipeline...
> > 
> > > After applying the second one (aas_sample), I experienced a test failure:
> > 
> > > The following tests FAILED:
> > >   1945 - EXAMPLES_export/examples/aas_sample_pdf4_systemF (Failed)
> > > Errors while running CTest
> > 
> > With this failure now solved, would it be OK to commit the changes?
> > 
> > Günter
> 
> +1

Yes please commit.

Thanks,

Scott


signature.asc
Description: PGP signature

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Guillaume Munch]

Le 16/01/2016 15:52, Enrico Forestieri a écrit :

On Fri, Jan 15, 2016 at 07:45:35PM +, Guillaume Munch wrote:


Le 14/01/2016 20:13, Enrico Forestieri a écrit :

On Thu, Jan 14, 2016 at 03:59:41PM +, Guillaume Munch wrote:


We might be speaking of two different issues:

* If I click on the right-hand half of the separator, the cursor moves
after the separator both visually and logically (a position that cannot
be reached using ← and →).

* If I click further on the line to the right of the separator (does not
need to be too far away), then the cursor gets located visually to the
left and logically to the right (what could be reached using ↑ and ↓
until your patch).

To see if the cursor is logically to the left or the right of the
separator, I try to see which of Del of Backspace deletes it.


I have now found where to tweak the sources and the attached x1.diff
patch solves the issue for me.


Thanks again for taking all these remarks into account.

x1.diff works as expected, it solves both issues, and I am ready to +1 you.


Committed.


However, this reveals new ways of creating an "after" cursor position:

* A visually-after cursor position appears with Ctrl+Shift+Arrows
(LFUN_*_SELECT_WORD of something like this). It remains a right position
after deselection, for instance by doing copy and immediately paste.

* A logically-after cursor position appears when double clicking the
separator inset or the line.


I will have a look. However, this may take some time because, as already
said, I am not too familiar with this part of the code.


A second issue I just noticed is when deleting the separator: the
paragraph after should not immediately be merged with the one that
contains the deleted separator, if none is empty, I think. Hitting Del
should just remove the separator. (To test this, start with two
non-empty enumerate environments with a par break separator at the end
of the first one, and then try to delete the separator.)


I will have a look at this.


The attached x2.diff patch takes care of this. It seems that this
behavior was a deliberate choice of mine, but it was wrong, apparently.



Actually I think it was a good idea, but only when the separator is alone on
the line. Would you like to keep your code but add instead a check for the
separator being alone on its paragraph? Otherwise I can vouch for the patch,
if you prefer removing your code.


On second thought, I think it is better to not complicate the code for a
not so clear improvement. If the separator was alone on the line, that
line will be automatically removed by the DEPM mechanism. So, I committed
the patch as is.



Ok. What does DEPM stands for?

Re: Questions for Uwe once you are back

[Scott Kostyshak]

On Sat, Jan 16, 2016 at 12:13:54PM +0100, Peter Kümmel wrote:
> 
> Am 15.01.2016 um 22:33 schrieb Georg Baum:
> >
> >And these problems do exist. The 2.2 alpha is not the first windows
> >binary that turned out to be built from different sources than
> >originally thought (http://www.lyx.org/trac/ticket/9878). I remember a
> >similar issue from several years ago, might be 1.6 or 2.0. This type of
> >mistakes (which can cost lots of hours or even days of wasted time for
> >several people) is easy to make with your current approach. It is very
> >difficult to make with my proposal.
> 
> Reading this I would say we should not release any installer with a LyX
> version build with msvc.

From what I understand, this issue can be solved with MSVC. I think
there is interest in helping Uwe improve the process.

> Uwe have you the time to build a installer with a mingw build?

Indeed this would be nice. I'm not sure Uwe has the time though and no
one else seems to want to do this work.

Scott


signature.asc
Description: PGP signature

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Jean-Marc Lasgouttes]

Le 16/01/16 18:56, Guillaume Munch a écrit :

Ok. What does DEPM stands for?


Delete Empty Paragraph Mechanism. It is also the code that removes 
double spaces.


JMarc

Re: two patches for ctest

[Guenter Milde]

On 2016-01-13, Guenter Milde wrote:

Dear Scott,

> maybe it is not the time now, yet there are two more patches for the ctests
> and examples in the pipeline...

> After applying the second one (aas_sample), I experienced a test failure:

> The following tests FAILED:
>   1945 - EXAMPLES_export/examples/aas_sample_pdf4_systemF (Failed)
> Errors while running CTest

With this failure now solved, would it be OK to commit the changes?

Günter

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Enrico Forestieri]

On Fri, Jan 15, 2016 at 07:45:35PM +, Guillaume Munch wrote:

> Le 14/01/2016 20:13, Enrico Forestieri a écrit :
> >On Thu, Jan 14, 2016 at 03:59:41PM +, Guillaume Munch wrote:
> >>
> >>We might be speaking of two different issues:
> >>
> >>* If I click on the right-hand half of the separator, the cursor moves
> >>after the separator both visually and logically (a position that cannot
> >>be reached using ← and →).
> >>
> >>* If I click further on the line to the right of the separator (does not
> >>need to be too far away), then the cursor gets located visually to the
> >>left and logically to the right (what could be reached using ↑ and ↓
> >>until your patch).
> >>
> >>To see if the cursor is logically to the left or the right of the
> >>separator, I try to see which of Del of Backspace deletes it.
> >
> >I have now found where to tweak the sources and the attached x1.diff
> >patch solves the issue for me.
> 
> Thanks again for taking all these remarks into account.
> 
> x1.diff works as expected, it solves both issues, and I am ready to +1 you.

Committed.

> However, this reveals new ways of creating an "after" cursor position:
> 
> * A visually-after cursor position appears with Ctrl+Shift+Arrows
> (LFUN_*_SELECT_WORD of something like this). It remains a right position
> after deselection, for instance by doing copy and immediately paste.
> 
> * A logically-after cursor position appears when double clicking the
> separator inset or the line.

I will have a look. However, this may take some time because, as already
said, I am not too familiar with this part of the code.

> A second issue I just noticed is when deleting the separator: the
> paragraph after should not immediately be merged with the one that
> contains the deleted separator, if none is empty, I think. Hitting Del
> should just remove the separator. (To test this, start with two
> non-empty enumerate environments with a par break separator at the end
> of the first one, and then try to delete the separator.)
> >>>
> >>>I will have a look at this.
> >
> >The attached x2.diff patch takes care of this. It seems that this
> >behavior was a deliberate choice of mine, but it was wrong, apparently.
> 
> 
> Actually I think it was a good idea, but only when the separator is alone on
> the line. Would you like to keep your code but add instead a check for the
> separator being alone on its paragraph? Otherwise I can vouch for the patch,
> if you prefer removing your code.

On second thought, I think it is better to not complicate the code for a
not so clear improvement. If the separator was alone on the line, that
line will be automatically removed by the DEPM mechanism. So, I committed
the patch as is.

-- 
Enrico

Re: Questions for Uwe once you are back

[Scott Kostyshak]

On Sat, Jan 16, 2016 at 12:02:52PM +0100, Peter Kümmel wrote:
> >Am 13.01.2016 um 00:21 schrieb Uwe Stöhr:
> >>CMake. As soon as I create a new folder and copy there code, I need to
> >>run CMake from scratch and specify about 40 paths (most of them to Qt).
> >>If I make a mistake there I get strange builds.
> 
> Uwe, why do you waste you time with such a msvc2010 fiddling?

From what I understand, he does this because it works for him and he
doesn't have that much time.

> Why do you not use MinGW builds (your own or the one from the bot?
> It would save you much time. You only would have to update the Installer nsi
> scripts a bit.

If it really is this easy, then hopefully someone else can step up to do
this.

Scott


signature.asc
Description: PGP signature

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Enrico Forestieri]

On Fri, Jan 15, 2016 at 07:45:35PM +, Guillaume Munch wrote:
> 
> However, this reveals new ways of creating an "after" cursor position:
> 
> * A visually-after cursor position appears with Ctrl+Shift+Arrows
> (LFUN_*_SELECT_WORD of something like this). It remains a right position
> after deselection, for instance by doing copy and immediately paste.

I could not reproduce this one.

> * A logically-after cursor position appears when double clicking the
> separator inset or the line.

This one was easy. It was also occurring when triple clicking. See attached.

-- 
Enrico
diff --git a/src/Text3.cpp b/src/Text3.cpp
index fbcd9b7..787b03b 100644
--- a/src/Text3.cpp
+++ b/src/Text3.cpp
@@ -1594,6 +1594,8 @@ void Text::dispatch(Cursor & cur, FuncRequest & cmd)
 
 	case LFUN_MOUSE_DOUBLE:
 		if (cmd.button() == mouse_button::button1) {
+			if (cur.pos() && cur.paragraph().isEnvSeparator(cur.pos() - 1))
+cur.posBackward();
 			selectWord(cur, WHOLE_WORD);
 			bv->cursor() = cur;
 		}
diff --git a/src/TextMetrics.cpp b/src/TextMetrics.cpp
index 325fb6c..7d94d64 100644
--- a/src/TextMetrics.cpp
+++ b/src/TextMetrics.cpp
@@ -1581,7 +1581,8 @@ bool TextMetrics::cursorEnd(Cursor & cur)
 			boundary = true;
 		else
 			--end;
-	}
+	} else if (end && cur.paragraph().isEnvSeparator(end-1))
+		--end;
 	return text_->setCursor(cur, cur.pit(), end, true, boundary);
 }
 

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Enrico Forestieri]

On Wed, Jan 13, 2016 at 11:15:44PM +0100, Enrico Forestieri wrote:
> On Wed, Jan 13, 2016 at 06:40:21PM +, Guillaume Munch wrote:
> > 
> > Maybe ¶ does not grow on you as it did on me, but ultimately it is going
> > to be your call.
> 
> Maybe ¶ is also easier to implement and distinguishable by its different
> shading rather than color.

I just discovered the reversed pilcrow sign ⁋ (u+204b) and used this in
the attached patch. If this is acceptable as a parbreak separator there
would be no problem as regards distinguishability.

-- 
Enrico
diff --git a/src/insets/InsetSeparator.cpp b/src/insets/InsetSeparator.cpp
index 7fb7c64..b642c18 100644
--- a/src/insets/InsetSeparator.cpp
+++ b/src/insets/InsetSeparator.cpp
@@ -174,27 +174,28 @@ docstring InsetSeparator::xhtml(XHTMLStream & xs, OutputParams const &) const
 void InsetSeparator::metrics(MetricsInfo & mi, Dimension & dim) const
 {
 	frontend::FontMetrics const & fm = theFontMetrics(mi.base.font);
-	dim.asc = fm.maxAscent();
-	dim.des = fm.maxDescent();
-	dim.wid = fm.width('m');
-	if (params_.kind == InsetSeparatorParams::PLAIN)
-		dim.wid *= 5;
+	if (params_.kind == InsetSeparatorParams::PLAIN) {
+		dim.asc = fm.maxAscent();
+		dim.des = fm.maxDescent();
+		dim.wid = 5 * fm.width('m');
+	} else
+		dim = fm.dimension(0x204B);
 }
 
 
 void InsetSeparator::draw(PainterInfo & pi, int x, int y) const
 {
-	FontInfo font;
+	FontInfo font = pi.base.font;
 	font.setColor(ColorName());
 
-	frontend::FontMetrics const & fm = theFontMetrics(pi.base.font);
-	int const wid = fm.width('m');
-	int const asc = fm.maxAscent();
+	if (params_.kind == InsetSeparatorParams::PLAIN) {
+		frontend::FontMetrics const & fm = theFontMetrics(font);
+		int const wid = fm.width('m');
+		int const asc = fm.maxAscent();
 
-	int xp[3];
-	int yp[3];
+		int xp[3];
+		int yp[3];
 
-	if (params_.kind == InsetSeparatorParams::PLAIN) {
 		yp[0] = int(y - 0.500 * asc * 0.75);
 		yp[1] = int(y - 0.500 * asc * 0.75);
 
@@ -203,37 +204,8 @@ void InsetSeparator::draw(PainterInfo & pi, int x, int y) const
 
 		pi.pain.lines(xp, yp, 2, ColorName());
 	} else {
-		yp[0] = int(y - 0.875 * asc * 0.5);
-		yp[1] = int(y - 0.500 * asc * 0.5);
-		yp[2] = int(y - 0.125 * asc * 0.5);
-
-		if (pi.ltr_pos) {
-			xp[0] = int(x + wid * 0.375);
-			xp[1] = int(x);
-			xp[2] = int(x + wid * 0.375);
-		} else {
-			xp[0] = int(x + wid * 0.625);
-			xp[1] = int(x + wid);
-			xp[2] = int(x + wid * 0.625);
-		}
-
-		pi.pain.lines(xp, yp, 3, ColorName(), Painter::fill_oddeven);
-
-		yp[0] = int(y - 0.500 * asc * 0.5);
-		yp[1] = int(y - 0.500 * asc * 0.5);
-		yp[2] = int(y - asc * 0.5);
-
-		if (pi.ltr_pos) {
-			xp[0] = int(x);
-			xp[1] = int(x + wid);
-			xp[2] = int(x + wid);
-		} else {
-			xp[0] = int(x + wid);
-			xp[1] = int(x);
-			xp[2] = int(x);
-		}
-
-		pi.pain.lines(xp, yp, 3, ColorName());
+		char_type const reversed_pilcrow = 0x204B;
+		pi.pain.text(x, y, reversed_pilcrow, font);
 	}
 }
 

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Enrico Forestieri]

On Sat, Jan 16, 2016 at 06:29:32PM +, Guillaume Munch wrote:

> Le 16/01/2016 17:06, Enrico Forestieri a écrit :
> >On Fri, Jan 15, 2016 at 07:45:35PM +, Guillaume Munch wrote:
> >>
> >>However, this reveals new ways of creating an "after" cursor position:
> >>
> >>* A visually-after cursor position appears with Ctrl+Shift+Arrows
> >>(LFUN_*_SELECT_WORD of something like this). It remains a right position
> >>after deselection, for instance by doing copy and immediately paste.
> >
> >I could not reproduce this one.
> 
> I can reproduce it systematically.
> 
> 1. New file
> 2. Type something in an itemize environment
> 3. Enter three times, get a separator
> 4. Place the cursor at the beginning of the document
> 5. Ctrl+Shift+Right until the after position is reached
> 
> optionally:
> 
> 6. Do copy+paste, to get the same cursor position but with the selection
> removed.

This only occurs when the separator is the last character in the document.
In this case you don't need Ctrl+Shift+Right but simply use → to get there.

> >>* A logically-after cursor position appears when double clicking the
> >>separator inset or the line.
> >
> >This one was easy. It was also occurring when triple clicking. See attached.
> >
> 
> It is somehow better, but it is very strange because the behaviour is not
> consistent: most of the time it selects the word before, but sometimes it
> selects the separator (i.e. separator is removed if I type a key). I get the
> second behaviour if I quadruple-click (!!) on the separator or after it (but
> this was not the only way).

So, what would be missing is a visual indication that the separator was
selected. I don't know how to do that, but maybe someone else does.

> Something else: if you place the cursor before a separator and press enter,
> the separator stays on the same paragraph. Is this voluntary?

Yes. Ideally, you are at the end of the line and pressing enter there
gets you a new paragraph.

> Also, I was wondering whether we should remove superfluous separators in the
> DEPM. This would make a lot of sense to me.

Then, the same should be done for the newline inset. For example, hit 3 or
more times Ctrl+Enter in a standard layout, then remove everything in the
paragraph before the first newline inset (such that it is now alone on the
line). Now you have an uncompilable document. At least, it could be
compiled if you had multiple separators like that.

Please note that we can stay here finding much more quirks in LyX that are
annoying. The point is that they are not so annoying if they can only be
obtained with uncommon operations. Then, this being free software, if they
annoy someone so much, he can also propose patches.

-- 
Enrico

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Enrico Forestieri]

On Sat, Jan 16, 2016 at 07:14:56PM +, Guillaume Munch wrote:

> Le 16/01/2016 18:34, Enrico Forestieri a écrit :
> >On Wed, Jan 13, 2016 at 11:15:44PM +0100, Enrico Forestieri wrote:
> >>On Wed, Jan 13, 2016 at 06:40:21PM +, Guillaume Munch wrote:
> >>>
> >>>Maybe ¶ does not grow on you as it did on me, but ultimately it is going
> >>>to be your call.
> >>
> >>Maybe ¶ is also easier to implement and distinguishable by its different
> >>shading rather than color.
> >
> >I just discovered the reversed pilcrow sign ⁋ (u+204b) and used this in
> >the attached patch. If this is acceptable as a parbreak separator there
> >would be no problem as regards distinguishability.
> >
> 
> The patch seems safe to me although I am not an expert of such code.

I have difficulties interpreting this as a +1.

> However, for the reversed pilcrow, there was issues with it recently
> (see d9524321).

I cannot see anything related to the reversed pilcrow there.

> I noticed something interesting: a parbreak separator can be used in the
> middle of an itemize environment to start a new latex paragraph in the
> item (using existing tricks to get to get the cursor after the
> separator) as an alternative to using a new lyx paragraph + indentation.

Yes, I also use many times the trick of forcing lyx into inserting
something that normally would not be inserted in order to perform
useful things. I would be annoyed if some forbidden operation would
not be really possible anymore...

-- 
Enrico

Beta hopefully soon, only waiting on Windows installer(s)

[Scott Kostyshak]

Dear all,

Hopefully we will release beta1 very soon. As far as I'm concerned, the
only thing we are waiting for is the Windows installer(s). The reason
why we are waiting for this and not just proceeding with the other parts
of the beta1 release is that there might be changes needed to the source
to clear up the build issues. These changes should be included in beta1.
There are some questions about the build process that we hope to clear
up; and if Uwe is OK with it, I think it would be great to build both an
MSVC installer and an MinGW installer. We all understand that Uwe does
not have much time, but it also seems that it might not require too much
of his time, thanks to the help from Georg, Peter, and Kornel for build
and CMake issues.

After that is cleared up, I will do some final commits and build the tar
balls. It would be nice to have a day or so where there are no commits
so that we are all encouraged to test beta1 for a day.

Please let me know if I'm missing anything.

Scott


signature.asc
Description: PGP signature

[patch] - GIT - version control for LyX documents not detected

[Stephan Witt]

The attached patch fixes the broken detection of GIT version control.
It seems so that Qt is caching the file meta data and fools the test
of file emptiness. Perhaps this has changed with Qt5 and didn’t happen
with Qt4… A proper solution for VCS would move doVCCommandWithOutput
to VCS::doVCCommandWithOutput and use it where a temporary file for
output is used. I’ll do this if such a change is allowed.

Perhaps a better fix is to disable QFileInfo caching or to call
fi.refresh() every time in FileName::isFileEmpty()?

Is anybody aware of other places having this kind of problem?

Stephan



VCBackend-git-enabled.patch
Description: Binary data

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Guillaume Munch]

Le 16/01/2016 18:34, Enrico Forestieri a écrit :

On Wed, Jan 13, 2016 at 11:15:44PM +0100, Enrico Forestieri wrote:

On Wed, Jan 13, 2016 at 06:40:21PM +, Guillaume Munch wrote:


Maybe ¶ does not grow on you as it did on me, but ultimately it is going
to be your call.


Maybe ¶ is also easier to implement and distinguishable by its different
shading rather than color.


I just discovered the reversed pilcrow sign ⁋ (u+204b) and used this in
the attached patch. If this is acceptable as a parbreak separator there
would be no problem as regards distinguishability.



The patch seems safe to me although I am not an expert of such code.
However, for the reversed pilcrow, there was issues with it recently
(see d9524321).

I noticed something interesting: a parbreak separator can be used in the
middle of an itemize environment to start a new latex paragraph in the
item (using existing tricks to get to get the cursor after the
separator) as an alternative to using a new lyx paragraph + indentation.


Guillaume

Re: [patch] - GIT - version control for LyX documents not detected

[Scott Kostyshak]

On Sat, Jan 16, 2016 at 11:13:23PM +0100, Stephan Witt wrote:
> The attached patch fixes the broken detection of GIT version control.
> It seems so that Qt is caching the file meta data and fools the test
> of file emptiness. Perhaps this has changed with Qt5 and didn’t happen
> with Qt4… A proper solution for VCS would move doVCCommandWithOutput
> to VCS::doVCCommandWithOutput and use it where a temporary file for
> output is used. I’ll do this if such a change is allowed.

I'm fine with the change in your patch. I am familiar with this type of
fix and the change is contained in VCBackend. I have not tested but if
it fixes it for you then go ahead. +1

> Perhaps a better fix is to disable QFileInfo caching or to call
> fi.refresh() every time in FileName::isFileEmpty()?
> 
> Is anybody aware of other places having this kind of problem?

Yes, I fixed one here: 43ca05ea. See the discussion in that commit
message. In particular, Pavel suggests that emptying the cache often
would cause a significant performance decrease for some use cases:
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg188628.html

Scott


signature.asc
Description: PGP signature

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Guillaume Munch]

Le 16/01/2016 22:31, Enrico Forestieri a écrit :

On Sat, Jan 16, 2016 at 07:14:56PM +, Guillaume Munch wrote:


Le 16/01/2016 18:34, Enrico Forestieri a écrit :

On Wed, Jan 13, 2016 at 11:15:44PM +0100, Enrico Forestieri wrote:

On Wed, Jan 13, 2016 at 06:40:21PM +, Guillaume Munch wrote:


Maybe ¶ does not grow on you as it did on me, but ultimately it is going
to be your call.


Maybe ¶ is also easier to implement and distinguishable by its different
shading rather than color.


I just discovered the reversed pilcrow sign ⁋ (u+204b) and used this in
the attached patch. If this is acceptable as a parbreak separator there
would be no problem as regards distinguishability.



The patch seems safe to me although I am not an expert of such code.


I have difficulties interpreting this as a +1.


I tested the patch and convinced myself that the patch was essentially 
moving block boundaries, so I am ready to +1 if we specifically test it 
on windows in case you decide for the reversed pilcrow. Thank you for 
the patch in any case.





However, for the reversed pilcrow, there was issues with it recently
(see d9524321).


I cannot see anything related to the reversed pilcrow there.


It removes 0x204B in Changes.cpp, but more importantly there is a link 
to the beginning of the discussion on the list. Essentially, it did not 
display on windows (I was able to check on windows 10). Maybe qt5 fixes 
that, and I would be able to test again after a windows installer is 
released if you decide to put it in beta. Other people would need to 
test on older versions of windows. Also you know that I prefer the 
pilcrow, but this is your call. Given that it is not something that we 
would like to change lightly, I think you would be justified in asking 
for additional tests.

Re: [patch] - GIT - version control for LyX documents not detected

[Richard Heck]

On 01/16/2016 05:27 PM, Scott Kostyshak wrote:

On Sat, Jan 16, 2016 at 11:13:23PM +0100, Stephan Witt wrote:

Perhaps a better fix is to disable QFileInfo caching or to call
fi.refresh() every time in FileName::isFileEmpty()?

Is anybody aware of other places having this kind of problem?

Yes, I fixed one here: 43ca05ea. See the discussion in that commit
message. In particular, Pavel suggests that emptying the cache often
would cause a significant performance decrease for some use cases:
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg188628.html


And, as I think is said there, we've seen issues with this, when using 
filesystems with
significant latency, e.g., over NFS. It'd be worth adding a comment to 
isFileEmpty() so

this question doesn't keep arising.

Richard

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Enrico Forestieri]

On Sun, Jan 17, 2016 at 03:03:20AM +, Guillaume Munch wrote:

> Le 16/01/2016 22:26, Enrico Forestieri a écrit :
> >On Sat, Jan 16, 2016 at 06:29:32PM +, Guillaume Munch wrote:
> >
> >>Le 16/01/2016 17:06, Enrico Forestieri a écrit :
> >>>On Fri, Jan 15, 2016 at 07:45:35PM +, Guillaume Munch wrote:
> 
> However, this reveals new ways of creating an "after" cursor
> position:
> 
> * A visually-after cursor position appears with
> Ctrl+Shift+Arrows (LFUN_*_SELECT_WORD of something like this).
> It remains a right position after deselection, for instance by
> doing copy and immediately paste.
> >>>
> >>>I could not reproduce this one.
> >>
> >>I can reproduce it systematically.
> >>
> >>1. New file 2. Type something in an itemize environment 3. Enter
> >>three times, get a separator 4. Place the cursor at the beginning
> >>of the document 5. Ctrl+Shift+Right until the after position is
> >>reached
> >>
> >>optionally:
> >>
> >>6. Do copy+paste, to get the same cursor position but with the
> >>selection removed.
> >
> >This only occurs when the separator is the last character in the
> >document. In this case you don't need Ctrl+Shift+Right but simply
> >use → to get there.
> 
> I cannot reproduce your description. My recipe works as well if there is
> some paragraph after. (Also you can probably deduce from the context
> that I would have noticed.)
> 
> >
> * A logically-after cursor position appears when double
> clicking the separator inset or the line.
> >>>
> >>>This one was easy. It was also occurring when triple clicking.
> >>>See attached.
> >>>
> >>
> >>It is somehow better, but it is very strange because the behaviour
> >>is not consistent: most of the time it selects the word before, but
> >>sometimes it selects the separator (i.e. separator is removed if I
> >>type a key). I get the second behaviour if I quadruple-click (!!)
> >>on the separator or after it (but this was not the only way).
> >
> >So, what would be missing is a visual indication that the separator
> >was selected. I don't know how to do that, but maybe someone else
> >does.
> >
> >>Something else: if you place the cursor before a separator and
> >>press enter, the separator stays on the same paragraph. Is this
> >>voluntary?
> >
> >Yes. Ideally, you are at the end of the line and pressing enter there
> >gets you a new paragraph.
> 
> Ok, this is just something to get used to.
> 
> >
> >>Also, I was wondering whether we should remove superfluous
> >>separators in the DEPM. This would make a lot of sense to me.
> >
> >Then, the same should be done for the newline inset. For example,
> >hit 3 or more times Ctrl+Enter in a standard layout, then remove
> >everything in the paragraph before the first newline inset (such
> >that it is now alone on the line). Now you have an uncompilable
> >document. At least, it could be compiled if you had multiple
> >separators like that.
> 
> I disagree with your newline comparison. Having several newlines
> compiles to a different latex code and makes sense, and compilation
> issues have nothing to do with DEPM.
> 
> >
> >Please note that we can stay here finding much more quirks in LyX
> >that are annoying. The point is that they are not so annoying if
> >they can only be obtained with uncommon operations.
> 
> The "uncommon operations" are only recipes to reproduce consistently. Of
> course they can look far-fetched. I got there by trying to reproduce
> behaviour that happened by chance without trying too much. I believe you
> are shooting the messenger.
> 
> The editing operations in the buffer view are a critical part of lyx,
> and one that does not suffer from clumsiness so far, which is essential
> in particular for the learning curve given that it is so much different
> from other softwares. It worries me to introduce quirks and inconsistent
> behaviour in this aspect, such as not knowing whether one has to hit del
> of backspace, or why the thing suddenly disappeared.
> 
> 
> >Then, this being free software, if they annoy someone so much, he
> >can also propose patches.
> >
> 
> I prefer not to reply to this or we could get into considerations quite
> remote from our current concerns using the same logic.
> 
> If you are worried about my suggestion about DEPM being too much for 2.2
> you can just say so. You may have noticed that I used a different
> phrasing, and I was ready to say that this can be filed as an
> enhancement request. Please do not worry about this last suggestion.

Yes, please. File everything as enhancement requests.

-- 
Enrico

Re: Beta hopefully soon, only waiting on Windows installer(s)

[Scott Kostyshak]

On Sun, Jan 17, 2016 at 02:30:06AM +, Guillaume Munch wrote:
> Le 16/01/2016 22:43, Scott Kostyshak a écrit :
> >Dear all,
> >
> >Hopefully we will release beta1 very soon. As far as I'm concerned, the
> >only thing we are waiting for is the Windows installer(s). The reason
> >why we are waiting for this and not just proceeding with the other parts
> >of the beta1 release is that there might be changes needed to the source
> >to clear up the build issues. These changes should be included in beta1.
> >There are some questions about the build process that we hope to clear
> >up; and if Uwe is OK with it, I think it would be great to build both an
> >MSVC installer and an MinGW installer. We all understand that Uwe does
> >not have much time, but it also seems that it might not require too much
> >of his time, thanks to the help from Georg, Peter, and Kornel for build
> >and CMake issues.
> >
> >After that is cleared up, I will do some final commits and build the tar
> >balls. It would be nice to have a day or so where there are no commits
> >so that we are all encouraged to test beta1 for a day.
> >
> >Please let me know if I'm missing anything.
> >
> 
> I think we are waiting for a last input about tabular-modify:
> . I do not imagine there 
> is
> any question of committing this between beta and release, so given that it
> has a file format change, it has to be before beta1 or not until 2.3. But as
> I understand we are nearly done and nobody is trying to postpone this.

OK. Thanks for bringing this to my attention.

Scott


signature.asc
Description: PGP signature

Re: Beta hopefully soon, only waiting on Windows installer(s)

[Scott Kostyshak]

On Sun, Jan 17, 2016 at 03:22:46AM +0100, Peter Kümmel wrote:
> Am 16. Januar 2016 23:43:12 MEZ, schrieb Scott Kostyshak :

> I would release the beta with the available Windows installer, but would also 
> mention, that because of men power this time on Windows there will be nothing 
> better that beta quality. 
> In the announcement you could mention that we are busy improving this, but 
> that at the moment no Windows developer has the time to create a reliable 
> installer and that we are very interested in someone who wanna help out. 
> It would be a starter project which could be done without C++ knowledge.

Good idea. We can indeed put a note in the announcement of the beta
release.

Scott


signature.asc
Description: PGP signature

Re: Windows: release with Qt 5.5.1 or 5.6?

[Scott Kostyshak]

On Sat, Jan 16, 2016 at 01:10:06AM +0100, Uwe Stöhr wrote:
> Am 15.01.2016 um 03:39 schrieb Scott Kostyshak:
> 
> >>Give me another day to test but I think that I am basically ready for beta1.
> >
> >Sounds good to me.
> 
> I tested it a lot today on different PCs and from my point of view it is
> stable. So I am ready for beta1.

We need to figure out the MSVC vs. mingw issue before releasing beta. I
don't think it would be a good idea to release one and then switch to
the other for final release. We have seen many installer-related issues
in the past so it seems it is a fragile part that would not be good to
change after beta. I am interested in other opinions though.

Scott


signature.asc
Description: PGP signature

Re: Windows: release with Qt 5.5.1 or 5.6?

[Scott Kostyshak]

On Sat, Jan 16, 2016 at 04:56:01PM +0100, Jean-Marc Lasgouttes wrote:
> We could also release both, one as the main and the other as backup.

+1

Uwe, I know you do not have much time but are you willing to make both
installers? It seems there is help available for both the MSVC and mingw
if you get stuck.

Scott

> JMarc
> 
> Le 16 janvier 2016 16:21:15 GMT+01:00, Scott Kostyshak  a 
> écrit :
> >We need to figure out the MSVC vs. mingw issue before releasing beta. I
> >don't think it would be a good idea to release one and then switch to
> >the other for final release. We have seen many installer-related issues
> >in the past so it seems it is a fragile part that would not be good to
> >change after beta. I am interested in other opinions though.
> >
> >Scott
> 


signature.asc
Description: PGP signature