Re: back to LyX and therefore questions concerning LyX 2.2
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
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
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
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
Op 24 okt. 2015 20:42 schreef "Uwe Stöhr" mailto:uwesto...@web.de>>: > 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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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 ;)