Re: back to LyX and therefore questions concerning LyX 2.2

[Vincent van Ravesteijn]

Op 24 okt. 2015 20:42 schreef "Uwe Stöhr" :
>
> Am 23.10.2015 um 10:25 schrieb Jean-Marc Lasgouttes:
>
>> If you look closely, they are not closer than the vertival line over B_V
>> is fromthe text. Seriously this is a much bigger problem
>
>
> But it still doesn't look as good as with \raisebox in my opinion.
>
>
>>> Besides this, if you prefer formal tables, no problem (the Math
>>> manual was written before this feature was available).
>>
>>
>> Yes, I would really propose that we use formal tables all over the
>> documents.
>
>
> OK, I will do this in the math manual when I find time.
>
>
>> It would be nice if the use of formal tables was described as the good
>> choice, and the culprits of normal tables with vertical lines discussed.
>> Where are these formal tables discussed, actually?
>
>
> In the EmbeddedObjects manual, sec. 2.9 and NOT in the UserGuide.
> As long as our default are non-formal tables I would not advertise formal
tables as the better solution.
> Note that the vast majority of the world's computer users are used to
Excel and Word tables and they are not formal. Even in many scientific
publications formal tables are not used. So for most users formal tables
are something special. I remember that I needed some time until I liked
them.
>
>
>>> That the tables are not floating is on purpose. I once tried floats
>>> and went crazy to get an acceptable PDF output.
>>
>>
>> Well, I am a believer in floating floats, but let's keep this point for
>> later :)
>
>
> Me too but LaTeX's float mechanism breaks if there are too many floats.
There is some literature about this topic and some suggest to omit floating
if one cannot allow the objects to float. This is the case in the math
manual.
>

Hmm we, as the experts, should not set the bad example. The fact that LyX's
docs don't use floats will be used by the unbelievers as an argument
against it.

Vincent

Re: back to LyX and therefore questions concerning LyX 2.2

[Jean-Marc Lasgouttes]

Op 24 okt. 2015 20:42 schreef "Uwe Stöhr" >:



 > But it still doesn't look as good as with \raisebox in my opinion.


The header and the line before the header are definitely better, and I 
would say that the line with the raisebox are too tall. It is subjective 
of course (from both of us). But a manual should just pick a good 
package and stick to it without adding fixes all over the place IMO.



 >> Yes, I would really propose that we use formal tables all over the
 >> documents.



 > OK, I will do this in the math manual when I find time.


Thanks. I understand that this requires time.


 > Note that the vast majority of the world's computer users are used to
Excel and Word tables and they are not formal. Even in many scientific
publications formal tables are not used. So for most users formal tables
are something special. I remember that I needed some time until I liked
them.


The vast majority of people are used to word/excel. I thought that the 
point of LyX was to advocate something better. I agree that publications 
that print whatever was sent by the will sport word-tables, but I can 
tell you that Springer Verlag, for example, will rewrite tables to be up 
to publishing standards.


I really think that formal tables should be given a very prominent place 
in the docs.

Re: back to LyX and therefore questions concerning LyX 2.2

[Uwe Stöhr]

Am 23.10.2015 um 10:25 schrieb Jean-Marc Lasgouttes:


If you look closely, they are not closer than the vertival line over B_V
is fromthe text. Seriously this is a much bigger problem


But it still doesn't look as good as with \raisebox in my opinion.


Besides this, if you prefer formal tables, no problem (the Math
manual was written before this feature was available).


Yes, I would really propose that we use formal tables all over the
documents.


OK, I will do this in the math manual when I find time.


It would be nice if the use of formal tables was described as the good
choice, and the culprits of normal tables with vertical lines discussed.
Where are these formal tables discussed, actually?


In the EmbeddedObjects manual, sec. 2.9 and NOT in the UserGuide.
As long as our default are non-formal tables I would not advertise 
formal tables as the better solution.
Note that the vast majority of the world's computer users are used to 
Excel and Word tables and they are not formal. Even in many scientific 
publications formal tables are not used. So for most users formal tables 
are something special. I remember that I needed some time until I liked 
them.



That the tables are not floating is on purpose. I once tried floats
and went crazy to get an acceptable PDF output.


Well, I am a believer in floating floats, but let's keep this point for
later :)


Me too but LaTeX's float mechanism breaks if there are too many floats. 
There is some literature about this topic and some suggest to omit 
floating if one cannot allow the objects to float. This is the case in 
the math manual.


regards Uwe

Re: back to LyX and therefore questions concerning LyX 2.2

[Scott Kostyshak]

On Fri, Oct 23, 2015 at 06:46:59PM -0700, Pavel Sanda wrote:
> Vincent van Ravesteijn wrote:
> > IMO, a separate hard string freeze is not needed as long as we act 
> > reasonable.
> 
> I meant it as a part of feature freeze. Whether you are working on 
> documentation
> or translation only, you don't want people mess with UI logic and strings.
> Pavel

OK so it seems there is agreement on the idea that the feature freeze
should imply the string freeze (it is just a matter of implicitly or
explicitly).

Thank you for this discussion.

Scott

Re: back to LyX and therefore questions concerning LyX 2.2

[Uwe Stöhr]

Am 24.10.2015 um 22:04 schrieb Jean-Marc Lasgouttes:


I really think that formal tables should be given a very prominent place
in the docs.


Then we should default to formal border style.

We still lack proper support for booktab's \cmidrule:
http://www.lyx.org/trac/ticket/3072

regards Uwe

Re: back to LyX and therefore questions concerning LyX 2.2

[Uwe Stöhr]

Am 24.10.2015 um 21:49 schrieb Vincent van Ravesteijn:


Hmm we, as the experts, should not set the bad example. The fact that LyX's
docs don't use floats will be used by the unbelievers as an argument
against it.


The Math manual is the only one where floats are not used.

These tables are not allowed to float and there are too many with not 
enough text between them so that LaTeX's floating mechanism fails 
leading to a horrible output. As I wrote I once tried this for the Math 
manual - a nightmare! And setting all table floats there to the position 
H prevents floating and thus floats could then also be omitted.


regards Uwe

Re: back to LyX and therefore questions concerning LyX 2.2

[Scott Kostyshak]

On Fri, Oct 23, 2015 at 12:15:26AM -0700, Pavel Sanda wrote:
> Vincent van Ravesteijn wrote:
> > >> - Will there be a code-freeze after that strings can still be changed?
> > >
> > > Is this what is normally done? I'm new at this.
> > 
> > I've actually no clue what is meant with a code freeze after that
> > strings an be changed ?
> 
> I think the question was, whether the feature freeze includes string freeze
> or there will be separate one.
> 
> This question is relevant to both docs and translators because if we
> continuously change the translatable strings they can't reasonably work.
> 
> My approach to this used to be:
> 1. summarize all features people want to finish and most critical bugs
>to be solved for release.
> 
> 2. based on feelings from (1) announce some time schedule for alpha/beta/rc
>(yes, it will be broken but people can synchronize much better when some
>time plan is announced)

My current plan is to wait to announce a schedule until alpha is
released. I would like to first make sure Qt 5.6 beta is released and
that it does not cause any disastrous bugs from LyX's perspective.

> 
> 3. releasing alphas until features are done or kicked away (or some critical 
> bugs).
>then soft freeze - no more new features, people should focus on fixing 
> bugs.
>it's also time to freeze the strings so translators and documentation
>can be done - time to send some suppliant mail to trnaslators & doclist.
> 
> 4. release beta. if no major bugs found and some reasonable time for testing
>by users was provided go to rc, if no continue with next betas.
> 
> 5. rc, hard freeze. every commit needs either release manager or two devs
>ack, only docs and translation can still flow in.
> 
> So back to Uwe's question, it would be good you announce at some point
> - features won't change ( except of bugfixing )
> - translatable strings are not going to be changed (except obvious 
> bugs/typos).
> and maybe give some hint when this might occur :)
> 
> YMMV,

Thanks for this summary. It is helpful.

Scott

Re: back to LyX and therefore questions concerning LyX 2.2

[Uwe Stöhr]

  Original Message  
From: Scott Kostyshak
Sent: Donnerstag, 22. Oktober 2015 18:45‎
‎
On Thu, Oct 22, 2015 at 08:55:05AM +0200, Vincent van Ravesteijn wrote:
> On Thu, Oct 22, 2015 at 7:13 AM, Scott Kostyshak  wrote:
> > On Mon, Oct 19, 2015 at 04:33:43PM +0200, Uwe Stöhr wrote:
> >> Dear LyXers,
> >>
> >> I would like to have a beta release short after the feature-freeze.
> >> During the beta and RC-cycle the docs will be updated because this
> >> usually takes some weeks.
> >
> > Sounds good to me.
> 
> IMO, it sounds a bit weird to me to have a beta release short after a
> feature freeze without considering the state of the codebase. I guess
> you announce a feature freeze, after which all devs will focus on
> improving the quality of the codebase until a certain level is reached
> at which a beta can be released. A feature freeze is just meant to
> bundle the devs' energy to focus on bugfixing and polishing existing
> features, and to make sure that not one part of the devs are doing the
> hard work on fixing bugs while the other half is introducing new ones.

Thank you for pointing this out, Vincent! I see what you mean and what
you suggest sounds the most sensible (and likely the most common in
other projects as well). After the feature freeze we might want some
time to iron out some bugs before releasing a beta. And besides, after a
feature freeze it seems there is already the necessary information to
start the process of updating the documentation. 

> Uwe, can you explain‎
why it is useful to have the beta released before starting to work on
the documentation? Why not start right after the feature freeze?

I need fixed strings. In my experience string changes happened frequently 
before releases and with a beta they were more or less frozen. So I don't 
insist on a beta but in more or less stable strings ( menu names etc.).

Regards Uwe 

Scott

Re: back to LyX and therefore questions concerning LyX 2.2

[Uwe Stöhr]

  Original Message  
From: Scott Kostyshak
Sent: Donnerstag, 22. Oktober 2015 18:45‎

> Uwe, can you explain‎
why it is useful to have the beta released before starting to work on
the documentation? Why not start right after the feature freeze?

I need fixed strings. In my experience string changes happened frequently 
before releases and with a beta they were more or less frozen. So I don't 
insist on a beta but in more or less stable strings ( menu names etc.).

Regards Uwe 

Scott

Re: back to LyX and therefore questions concerning LyX 2.2

[Vincent van Ravesteijn]

Op 23-10-2015 om 9:15 schreef Pavel Sanda:
So back to Uwe's question, it would be good you announce at some point 
- features won't change ( except of bugfixing ) - translatable strings 
are not going to be changed (except obvious bugs/typos). and maybe 
give some hint when this might occur :)


I assume that people will not start changing strings for fun when we are 
in the feature freeze phase. So I expect hardly any string changes then. 
And when there is a serious reason for changing a string, it can 
probably be adjusted anyway in the translations/docs, but maybe with a 
little more effort.


IMO, a separate hard string freeze is not needed as long as we act 
reasonable.


Vincent

Re: back to LyX and therefore questions concerning LyX 2.2

[Pavel Sanda]

Vincent van Ravesteijn wrote:
> IMO, a separate hard string freeze is not needed as long as we act 
> reasonable.

I meant it as a part of feature freeze. Whether you are working on documentation
or translation only, you don't want people mess with UI logic and strings.
Pavel

Re: back to LyX and therefore questions concerning LyX 2.2

[Pavel Sanda]

Vincent van Ravesteijn wrote:
> >> - Will there be a code-freeze after that strings can still be changed?
> >
> > Is this what is normally done? I'm new at this.
> 
> I've actually no clue what is meant with a code freeze after that
> strings an be changed ?

I think the question was, whether the feature freeze includes string freeze
or there will be separate one.

This question is relevant to both docs and translators because if we
continuously change the translatable strings they can't reasonably work.

My approach to this used to be:
1. summarize all features people want to finish and most critical bugs
   to be solved for release.

2. based on feelings from (1) announce some time schedule for alpha/beta/rc
   (yes, it will be broken but people can synchronize much better when some
   time plan is announced)

3. releasing alphas until features are done or kicked away (or some critical 
bugs).
   then soft freeze - no more new features, people should focus on fixing bugs.
   it's also time to freeze the strings so translators and documentation
   can be done - time to send some suppliant mail to trnaslators & doclist.

4. release beta. if no major bugs found and some reasonable time for testing
   by users was provided go to rc, if no continue with next betas.

5. rc, hard freeze. every commit needs either release manager or two devs
   ack, only docs and translation can still flow in.

So back to Uwe's question, it would be good you announce at some point
- features won't change ( except of bugfixing )
- translatable strings are not going to be changed (except obvious bugs/typos).
and maybe give some hint when this might occur :)

YMMV,
Pavel

Re: back to LyX and therefore questions concerning LyX 2.2

[Jean-Marc Lasgouttes]

Le 23/10/2015 02:57, Uwe Stöhr a écrit :

I had now a look and the formal tables doesn't solve the spacing
problems: The "V" of the underscript/subscript are too close.


If you look closely, they are not closer than the vertival line over B_V 
is fromthe text. Seriously this is a much bigger problem



One could add space to ALL table rows but this looks also not nice
for tables where this is not necessary. So what is wrong in using
\raisebox?


OK, I re-read the messages and the files and indeed the problem is not
really about the \raisebox. But I think that the spacing obtained with 
formal tables is just good enough and an be kept without additional 
modifications. This is especially true from the fact that very few 
horizontal lines are used in this style.


But it you look at the two first lines of the table, they are frankly
not tall enough. This is actually a well known flaw of the basic latex
tabular environment. I would say it is one of the rare features of LaTeX
where the defaults are bad.


Besides this, if you prefer formal tables, no problem (the Math
manual was written before this feature was available).


Yes, I would really propose that we use formal tables all over the
documents. No printed book done by a reputable publisher use ugly
msword-like tables, actually. Good tables are formal tables. And
moreover the spacing is much more reasonably implemented.

It would be nice if the use of formal tables was described as the good
choice, and the culprits of normal tables with vertical lines discussed.
Where are these formal tables discussed, actually?

I remember that there were talks about making formal tables the default.
I think that this would be a good move.

OTOH, I understand that this could be too much work for now. It is your 
call, ultimately.



That the tables are not floating is on purpose. I once tried floats
and went crazy to get an acceptable PDF output.


Well, I am a believer in floating floats, but let's keep this point for 
later :)


JMarc

Re: back to LyX and therefore questions concerning LyX 2.2

[Vincent van Ravesteijn]

On Thu, Oct 22, 2015 at 7:13 AM, Scott Kostyshak  wrote:
> On Mon, Oct 19, 2015 at 04:33:43PM +0200, Uwe Stöhr wrote:
>> Dear LyXers,
>>
>> I would like to have a beta release short after the feature-freeze.
>> During the beta and RC-cycle the docs will be updated because this
>> usually takes some weeks.
>
> Sounds good to me.

IMO, it sounds a bit weird to me to have a beta release short after a
feature freeze without considering the state of the codebase. I guess
you announce a feature freeze, after which all devs will focus on
improving the quality of the codebase until a certain level is reached
at which a beta can be released. A feature freeze is just meant to
bundle the devs' energy to focus on bugfixing and polishing existing
features, and to make sure that not one part of the devs are doing the
hard work on fixing bugs while the other half is introducing new ones.

>>
>> - Will there be a code-freeze after that strings can still be changed?
>
> Is this what is normally done? I'm new at this.

I've actually no clue what is meant with a code freeze after that
strings an be changed ?

Vincent

Re: back to LyX and therefore questions concerning LyX 2.2

[Uwe Stöhr]

Am 21.10.2015 um 12:06 schrieb Jean-Marc Lasgouttes:


What do you mean? Apparently I missed your mail too.


Sorry, I should have given the references:
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg183726.html


Hi JMarc,

I had now a look and the formal tables doesn't solve the spacing 
problems: The "V" of the underscript/subscript are too close.


One could add space to ALL table rows but this looks also not nice for 
tables where this is not necessary.

So what is wrong in using \raisebox?

Besides this, if you prefer formal tables, no problem (the Math manual 
was written before this feature was available). That the tables are not 
floating is on purpose. I once tried floats and went crazy to get an 
acceptable PDF output.


regards Uwe

Re: back to LyX and therefore questions concerning LyX 2.2

[Scott Kostyshak]

On Thu, Oct 22, 2015 at 08:55:05AM +0200, Vincent van Ravesteijn wrote:
> On Thu, Oct 22, 2015 at 7:13 AM, Scott Kostyshak  wrote:
> > On Mon, Oct 19, 2015 at 04:33:43PM +0200, Uwe Stöhr wrote:
> >> Dear LyXers,
> >>
> >> I would like to have a beta release short after the feature-freeze.
> >> During the beta and RC-cycle the docs will be updated because this
> >> usually takes some weeks.
> >
> > Sounds good to me.
> 
> IMO, it sounds a bit weird to me to have a beta release short after a
> feature freeze without considering the state of the codebase. I guess
> you announce a feature freeze, after which all devs will focus on
> improving the quality of the codebase until a certain level is reached
> at which a beta can be released. A feature freeze is just meant to
> bundle the devs' energy to focus on bugfixing and polishing existing
> features, and to make sure that not one part of the devs are doing the
> hard work on fixing bugs while the other half is introducing new ones.

Thank you for pointing this out, Vincent! I see what you mean and what
you suggest sounds the most sensible (and likely the most common in
other projects as well). After the feature freeze we might want some
time to iron out some bugs before releasing a beta. And besides, after a
feature freeze it seems there is already the necessary information to
start the process of updating the documentation. Uwe, can you explain
why it is useful to have the beta released before starting to work on
the documentation? Why not start right after the feature freeze?

Scott

Re: back to LyX and therefore questions concerning LyX 2.2

[Scott Kostyshak]

On Mon, Oct 19, 2015 at 04:33:43PM +0200, Uwe Stöhr wrote:
> Dear LyXers,
> 
> I would like to have a beta release short after the feature-freeze.
> During the beta and RC-cycle the docs will be updated because this
> usually takes some weeks.

Sounds good to me.
> 
> - Will there be a code-freeze after that strings can still be changed?

Is this what is normally done? I'm new at this.

Scott

Re: back to LyX and therefore questions concerning LyX 2.2

[Jean-Marc Lasgouttes]

Le 20/10/2015 23:16, Uwe Stöhr a écrit :

Am 19.10.2015 um 16:42 schrieb Jean-Marc Lasgouttes:

PS: and of course my idea of replacing ugly tables with nice formal
tables and remove all the spacing hacks you had to do is still waiting
for your answer ;)


What do you mean? Apparently I missed your mail too.


Sorry, I should have given the references:
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg183726.html
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg186218.html

JMarc

Re: back to LyX and therefore questions concerning LyX 2.2

[Uwe Stöhr]

Am 19.10.2015 um 16:42 schrieb Jean-Marc Lasgouttes:


Welcome back!


Thanks JMarc for the info.


PS: and of course my idea of replacing ugly tables with nice formal
tables and remove all the spacing hacks you had to do is still waiting
for your answer ;)


What do you mean? Apparently I missed your mail too.

regards Uwe

Re: back to LyX and therefore questions concerning LyX 2.2

[Jean-Marc Lasgouttes]

Le 19/10/15 16:33, Uwe Stöhr a écrit :

- what is the timetable for LyX 2.2?


Maybe an alpha release next week.


- Will there be a code-freeze after that strings can still be changed?


Don't know


- Who is the release manager for 2.2


Scott.


- A request: could anybody please add all new features, also the small
ones, to http://wiki.lyx.org/LyX/NewInLyX22
This page is not up to date and it would help me a lot with the
documentation. You know: an undocumented feature is an unused feature


I'll take a look.


Today I added my last feature for 2.2 - only a module improvement. I had
2 days time since a long time and could not resist ;-) And yes, it was
fun to write a completely new manual for such an exciting feature like
the fancy boxes. (I wished I had known this feature before.)


Please take a look at Scott's anwsers.

Welcome back!

JMarc

PS: and of course my idea of replacing ugly tables with nice formal 
tables and remove all the spacing hacks you had to do is still waiting 
for your answer ;)