Re: [LyX/master] Add option to reset to default booktabs lines
Am Montag, den 01.04.2019, 10:21 +0200 schrieb Kornel Benko: > Sorry for making trouble. It's not you making trouble, but Qt. Jürgen signature.asc Description: This is a digitally signed message part
Re: [LyX/master] Add option to reset to default booktabs lines
Am Montag, den 01.04.2019, 10:58 +0200 schrieb Kornel Benko: > Meant is 'horizontal' I suppose? Yes, right. Thanks. Jürgen signature.asc Description: This is a digitally signed message part
Re: [LyX/master] Add option to reset to default booktabs lines
Am Montag, 1. April 2019, 10:21:42 CEST schrieb Kornel Benko: > Am Montag, 1. April 2019, 09:20:32 CEST schrieb Jürgen Spitzmüller: > > Am Montag, den 01.04.2019, 09:03 +0200 schrieb Kornel Benko: > > > I get following compiler errors for GuiTabular.cpp > > > > Should be fixed. The bad news is that we now (again) have to manually > > edit ui files generated with Qt 5.12. > > > > Jürgen > > > > Thanks. Sorry for making trouble. Compiles now. > > Kornel > There seems to be wrong text for the formal tables "If this is checked, the table will be reset to the formal default style (only top and bottom row have vertical lines)" Meant is 'horizontal' I suppose? Kornel signature.asc Description: This is a digitally signed message part.
Re: [LyX/master] Add option to reset to default booktabs lines
Am Montag, 1. April 2019, 09:20:32 CEST schrieb Jürgen Spitzmüller: > Am Montag, den 01.04.2019, 09:03 +0200 schrieb Kornel Benko: > > I get following compiler errors for GuiTabular.cpp > > Should be fixed. The bad news is that we now (again) have to manually > edit ui files generated with Qt 5.12. > > Jürgen > Thanks. Sorry for making trouble. Compiles now. Kornel signature.asc Description: This is a digitally signed message part.
Re: [LyX/master] Add option to reset to default booktabs lines
Am Montag, den 01.04.2019, 09:03 +0200 schrieb Kornel Benko: > I get following compiler errors for GuiTabular.cpp Should be fixed. The bad news is that we now (again) have to manually edit ui files generated with Qt 5.12. Jürgen signature.asc Description: This is a digitally signed message part
Re: Ticket #3072: incomplete booktabs support: optional arguments of \cmidrule not supported
On 20.10.2017 23:56, Scott Kostyshak wrote: Please make sure to add your thoughts to the ticket, so they don't get lost. Done. http://www.lyx.org/trac/ticket/3072#comment:11 Daniel
Re: Ticket #3072: incomplete booktabs support: optional arguments of \cmidrule not supported
On Fri, Oct 20, 2017 at 08:13:53AM +, racoon wrote:
> On 20.10.2017 11:06, racoon wrote:
> > For example, if a column with a \cmidrule underneath is set to "align
> > center" then this should be inherited by its \cmidrule, i.e.
> >
> > \cmidrule(c){...}
> Or maybe if all columns just below a \cmidrule are set to "align center"? In
> this way it is still possible to use some other custom distribution of
> columns.
Please make sure to add your thoughts to the ticket, so they don't get
lost.
Scott
signature.asc
Description: PGP signature
Re: Ticket #3072: incomplete booktabs support: optional arguments of \cmidrule not supported
On 20.10.2017 11:06, racoon wrote:
For example, if a column with a \cmidrule underneath is set to "align
center" then this should be inherited by its \cmidrule, i.e.
\cmidrule(c){...}
Or maybe if all columns just below a \cmidrule are set to "align
center"? In this way it is still possible to use some other custom
distribution of columns.
Daniel
Ticket #3072: incomplete booktabs support: optional arguments of \cmidrule not supported
Maybe some arguments of \cmidrule could be set automatically without
additional UI?
For example, if a column with a \cmidrule underneath is set to "align
center" then this should be inherited by its \cmidrule, i.e.
\cmidrule(c){...}
Also, a \cmidrule should never stretch over more than one (multi)column.
This makes possible to to have rules with small breaks in between.
See both cases here in action here:
https://tex.stackexchange.com/a/60604/36836
I know that this might not be the wanted result in all cases. But maybe
it is what is wanted in almost all cases. And once a UI gets implemented
to set these optional arguments, in the Border dialog or so, then this
could override the default as outlined above.
Daniel
Re: booktabs and LyX?
On Samstag 12 Januar 2008, Uwe Stöhr wrote: Is it planned to officially support that package? LyX 1.5 supports this except of some specialities like e.g. the alignment of the table rules. Thanks to José and you for this information. I have only recently been pointed to booktabs (a style for non-ugly tables suitable for books) -- has anyone used that with LyX yet? (How?) For LyX 1.4 you need some ERT. But it is not difficult and I wrote my diploma thesis with LyX 1.3 using this method. Attached an example. Thanks, too. Actually, I /think/ my version is slightly cleaner from a LaTeX perspective (although yours looks cleaner in LyX), in the sense that there's no additional table row after the bottom rule. I see that you've always put your tables into floats, so that might not matter there. Looking forward to trying out LyX 1.5/1.6 again soon.. Greetings, Hans signature.asc Description: This is a digitally signed message part.
Re: booktabs and LyX?
On Samstag 12 Januar 2008, Uwe Stöhr wrote: > > Is it planned to officially support that package? > > LyX 1.5 supports this except of some specialities like e.g. the alignment > of the table rules. Thanks to José and you for this information. > > I have only recently been pointed to booktabs (a style for non-ugly > > tables suitable for books) -- has anyone used that with LyX yet? (How?) > > For LyX 1.4 you need some ERT. But it is not difficult and I wrote my > diploma thesis with LyX 1.3 using this method. Attached an example. Thanks, too. Actually, I /think/ my version is slightly cleaner from a LaTeX perspective (although yours looks cleaner in LyX), in the sense that there's no additional table row after the bottom rule. I see that you've always put your tables into floats, so that might not matter there. Looking forward to trying out LyX 1.5/1.6 again soon.. Greetings, Hans signature.asc Description: This is a digitally signed message part.
booktabs and LyX?
Hi!
Disclaimer: Since I have only three weeks left for finishing my PhD thesis, I
am still using 1.4.6svn -- no time for any upgrade surprises anymore.
I have only recently been pointed to booktabs (a style for non-ugly tables
suitable for books) -- has anyone used that with LyX yet? (How?)
Is it planned to officially support that package?
Heh, I just managed to convert a simple existing table by
- adding \usepackage{booktabs}
- removing all borders
- adding ERT \toprule at the beginning of the first cell
- adding ERT \midrule at the beginning of the first cell after the headers
- adding ERT \tabularnewline\bottomrule% at the end of the last cell
(Attached.)
Although this is clearly a hack, this seems to be good enough(TM) for me ATM.
Ciao, / /.o.
/--/ ..o
/ / ANS ooo
booktabs-test.lyx
Description: application/lyx
signature.asc
Description: This is a digitally signed message part.
Re: booktabs and LyX?
On Saturday 12 January 2008 20:53:35 Hans Meine wrote: Hi! Disclaimer: Since I have only three weeks left for finishing my PhD thesis, I am still using 1.4.6svn -- no time for any upgrade surprises anymore. I have only recently been pointed to booktabs (a style for non-ugly tables suitable for books) -- has anyone used that with LyX yet? (How?) Is it planned to officially support that package? First early congratulations. :-) Second you don't want to hear the answer but your request is a new feature of lyx 1.5. :-) :-) -- José Abílio
Re: booktabs and LyX?
I have only recently been pointed to booktabs (a style for non-ugly tables suitable for books) -- has anyone used that with LyX yet? (How?) For LyX 1.4 you need some ERT. But it is not difficult and I wrote my diploma thesis with LyX 1.3 using this method. Attached an example. Is it planned to officially support that package? LyX 1.5 supports this except of some specialities like e.g. the alignment of the table rules. regards Uwe booktabsLyX14.lyx Description: application/lyx
booktabs and LyX?
Hi!
Disclaimer: Since I have only three weeks left for finishing my PhD thesis, I
am still using 1.4.6svn -- no time for any upgrade surprises anymore.
I have only recently been pointed to booktabs (a style for non-ugly tables
suitable for books) -- has anyone used that with LyX yet? (How?)
Is it planned to officially support that package?
Heh, I just managed to convert a simple existing table by
- adding \usepackage{booktabs}
- removing all borders
- adding ERT "\toprule" at the beginning of the first cell
- adding ERT "\midrule" at the beginning of the first cell after the headers
- adding ERT "\tabularnewline\bottomrule%" at the end of the last cell
(Attached.)
Although this is clearly a hack, this seems to be good enough(TM) for me ATM.
Ciao, / /.o.
/--/ ..o
/ / ANS ooo
booktabs-test.lyx
Description: application/lyx
signature.asc
Description: This is a digitally signed message part.
Re: booktabs and LyX?
On Saturday 12 January 2008 20:53:35 Hans Meine wrote: > Hi! > > Disclaimer: Since I have only three weeks left for finishing my PhD thesis, > I am still using 1.4.6svn -- no time for any upgrade surprises anymore. > > I have only recently been pointed to booktabs (a style for non-ugly tables > suitable for books) -- has anyone used that with LyX yet? (How?) > Is it planned to officially support that package? First early congratulations. :-) Second you don't want to hear the answer but your request is a new feature of lyx 1.5. :-) :-) -- José Abílio
Re: booktabs and LyX?
> I have only recently been pointed to booktabs (a style for non-ugly tables > suitable for books) -- has anyone used that with LyX yet? (How?) For LyX 1.4 you need some ERT. But it is not difficult and I wrote my diploma thesis with LyX 1.3 using this method. Attached an example. > Is it planned to officially support that package? LyX 1.5 supports this except of some specialities like e.g. the alignment of the table rules. regards Uwe booktabsLyX14.lyx Description: application/lyx
Re: [patch] merge booktabs branch
Jean-Marc Lasgouttes wrote: A question: + The row tag of tabulars has the following new attributes: + topspace, bottomspace and interlinespace. All take a LyXLength + as value, or the special keyword default. Are these new spacing for booktabs only? No, but the nonbooktabs implementation is suboptimal, so it is recommended to use them only with booktabs. Georg
Re: [patch] merge booktabs branch
Jean-Marc Lasgouttes wrote: > A question: > + The tag of tabulars has the following new attributes: > + topspace, bottomspace and interlinespace. All take a LyXLength > + as value, or the special keyword "default". > > Are these new spacing for booktabs only? No, but the nonbooktabs implementation is suboptimal, so it is recommended to use them only with booktabs. Georg
Re: [patch] merge booktabs branch
Georg == Georg Baum [EMAIL PROTECTED] writes: Georg The booktabs support is fully functional now (except gtk Georg frontend). One feature is missing: Suport for left and right Georg adjustment of \clines. Georg Since I don't know when I will be able to implement that, and Georg since I want the current booktabs support in before the next Georg freeze I plan to merge the branch back soon. Unless I get Georg objections this will happen on monday. The diff that will be Georg merged is attached. Go ahead! JMarc
Re: [patch] merge booktabs branch
Lars Gullik Bjønnes wrote:
We really should make a decision on how we want our naming to be.
Yes. I prefer CamelCase, but am fine with whatever we choose. Please make a
decision and document it in Code_Rules, discussing this again and again is
really tiresome.
CamelCase or stl/boost style.
At least we should not use different style for the same kind of
entities. (Not really related to this patch though)
That is what I tried (but did not use ALL_CAPS because we have a rule
against it).
Index: src/insets/ChangeLog
===
--- src/insets/ChangeLog (Revision 14275)
+++ src/insets/ChangeLog (Revision 14278)
@@ -799,6 +799,10 @@
* insettabular.[Ch] (string2params): Don't pretend to return the
active cell anymore and simplify keyword parsing.
+2004-11-11 Edwin Leuven
+
+ * insettabular.C (getStatus, tabularFeatures): handle booktabs feature
+
2004-11-10 Jean-Marc Lasgouttes
[EMAIL PROTECTED]
* insetlatexaccent.h (isLetter): implement, so that word selection
Is this info now out dated?
No, it still decsribes a chaneg wrt trunk.
And strictly speaking we are not using the ChangeLog more anyway...
(Handled at commit time I guess.)
You remember when the booktabs branch started? End of 2004 (still ChangeLog
time). Should I remove those entries? I don't think so, because they are
not captured by commit logs.
Index: src/tabular.C
===
--- src/tabular.C (Revision 14275)
+++ src/tabular.C (Revision 14278)
@@ -64,6 +64,8 @@ using std::strlen;
namespace {
int const WIDTH_OF_LINE = 5;
+int const default_line_space = 10;
Hmm.. is this the same as the one in the other file?
Yes.
(In insettabular.C)
If so we should perhaps find a way so that we only need one of them?
I thought about that, but did not want to put it in a header because it is
an implementation detail. IMO the split of the tabular code between
tabular.C and insettabular.C is artificial and all should be moved to
insettabular.C eventually, so I prefer this solution that will then be
automatically merged.
What do you think?
So I have looked through the patch and saw nothing wrong with it. I
havent compiled or tested it though.
Good work.
This goes mainly to Edwin and Jürgen, they did a great part of it.
Georg
Re: [patch] merge booktabs branch
Georg Baum wrote: This goes mainly to Edwin and Jürgen, they did a great part of it. 1 + 1 + 1 = 4
Re: [patch] merge booktabs branch
Jean-Marc Lasgouttes wrote: Go ahead! I am doing it right now, but first I need to add a format description which I forgot. GeorgIndex: development/FORMAT === --- development/FORMAT (Revision 14311) +++ development/FORMAT (Arbeitskopie) @@ -1,6 +1,19 @@ LyX file-format changes --- +2006-07-03 Georg Baum [EMAIL PROTECTED] + + * format incremented to 248: Basic booktabs support + + The features tag has a new switch: booktabs=true|false. + An absent switch is equivalent to booktabs=false. + Horizontal lines are set with the booktabs package if this switch + is on. + + The row tag of tabulars has the following new attributes: + topspace, bottomspace and interlinespace. All take a LyXLength + as value, or the special keyword default. + 2006-06-10 Jürgen Spitzmüller [EMAIL PROTECTED] * format incremented to 247. The Grand Font Interface Rewrite.
Re: [patch] merge booktabs branch
Georg == Georg Baum [EMAIL PROTECTED] writes: Georg Jean-Marc Lasgouttes wrote: Go ahead! Georg I am doing it right now, but first I need to add a format Georg description which I forgot. A question: + The row tag of tabulars has the following new attributes: + topspace, bottomspace and interlinespace. All take a LyXLength + as value, or the special keyword default. Are these new spacing for booktabs only? JMarc
Re: [patch] merge booktabs branch
>>>>> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: Georg> The booktabs support is fully functional now (except gtk Georg> frontend). One feature is missing: Suport for left and right Georg> adjustment of \clines. Georg> Since I don't know when I will be able to implement that, and Georg> since I want the current booktabs support in before the next Georg> freeze I plan to merge the branch back soon. Unless I get Georg> objections this will happen on monday. The diff that will be Georg> merged is attached. Go ahead! JMarc
Re: [patch] merge booktabs branch
Lars Gullik Bjønnes wrote:
> We really should make a decision on how we want our naming to be.
Yes. I prefer CamelCase, but am fine with whatever we choose. Please make a
decision and document it in Code_Rules, discussing this again and again is
really tiresome.
> CamelCase or stl/boost style.
>
> At least we should not use different style for the same kind of
> entities. (Not really related to this patch though)
That is what I tried (but did not use ALL_CAPS because we have a rule
against it).
> Index: src/insets/ChangeLog
> ===
> --- src/insets/ChangeLog (Revision 14275)
> +++ src/insets/ChangeLog (Revision 14278)
> @@ -799,6 +799,10 @@
> * insettabular.[Ch] (string2params): Don't pretend to return the
> active cell anymore and simplify keyword parsing.
>
> +2004-11-11 Edwin Leuven
> +
> + * insettabular.C (getStatus, tabularFeatures): handle booktabs feature
> +
> 2004-11-10 Jean-Marc Lasgouttes
> <[EMAIL PROTECTED]>
>
> * insetlatexaccent.h (isLetter): implement, so that word selection
>
> Is this info now out dated?
No, it still decsribes a chaneg wrt trunk.
> And strictly speaking we are not using the ChangeLog more anyway...
> (Handled at commit time I guess.)
You remember when the booktabs branch started? End of 2004 (still ChangeLog
time). Should I remove those entries? I don't think so, because they are
not captured by commit logs.
> Index: src/tabular.C
> ===
> --- src/tabular.C (Revision 14275)
> +++ src/tabular.C (Revision 14278)
> @@ -64,6 +64,8 @@ using std::strlen;
> namespace {
>
> int const WIDTH_OF_LINE = 5;
> +int const default_line_space = 10;
>
> Hmm.. is this the same as the one in the other file?
Yes.
> (In insettabular.C)
> If so we should perhaps find a way so that we only need one of them?
I thought about that, but did not want to put it in a header because it is
an implementation detail. IMO the split of the tabular code between
tabular.C and insettabular.C is artificial and all should be moved to
insettabular.C eventually, so I prefer this solution that will then be
automatically merged.
What do you think?
> So I have looked through the patch and saw nothing wrong with it. I
> havent compiled or tested it though.
>
> Good work.
This goes mainly to Edwin and Jürgen, they did a great part of it.
Georg
Re: [patch] merge booktabs branch
Georg Baum wrote: This goes mainly to Edwin and Jürgen, they did a great part of it. 1 + 1 + 1 = 4
Re: [patch] merge booktabs branch
Jean-Marc Lasgouttes wrote: > Go ahead! I am doing it right now, but first I need to add a format description which I forgot. GeorgIndex: development/FORMAT === --- development/FORMAT (Revision 14311) +++ development/FORMAT (Arbeitskopie) @@ -1,6 +1,19 @@ LyX file-format changes --- +2006-07-03 Georg Baum <[EMAIL PROTECTED]> + + * format incremented to 248: Basic booktabs support + + The tag has a new switch: booktabs="true|false". + An absent switch is equivalent to booktabs="false". + Horizontal lines are set with the booktabs package if this switch + is on. + + The tag of tabulars has the following new attributes: + topspace, bottomspace and interlinespace. All take a LyXLength + as value, or the special keyword "default". + 2006-06-10 Jürgen Spitzmüller <[EMAIL PROTECTED]> * format incremented to 247. The Grand Font Interface Rewrite.
Re: [patch] merge booktabs branch
>>>>> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: Georg> Jean-Marc Lasgouttes wrote: >> Go ahead! Georg> I am doing it right now, but first I need to add a format Georg> description which I forgot. A question: + The tag of tabulars has the following new attributes: + topspace, bottomspace and interlinespace. All take a LyXLength + as value, or the special keyword "default". Are these new spacing for booktabs only? JMarc
[patch] merge booktabs branch
The booktabs support is fully functional now (except gtk frontend). One feature is missing: Suport for left and right adjustment of \clines. Since I don't know when I will be able to implement that, and since I want the current booktabs support in before the next freeze I plan to merge the branch back soon. Unless I get objections this will happen on monday. The diff that will be merged is attached. Georg merge.diff.gz Description: GNU Zip compressed data
Re: [patch] merge booktabs branch
Georg Baum wrote: Since I don't know when I will be able to implement that, and since I want the current booktabs support in before the next freeze I plan to merge the branch back soon. Good plan! Jürgen
Re: [patch] merge booktabs branch
Georg Baum [EMAIL PROTECTED] writes:
| The booktabs support is fully functional now (except gtk frontend). One
| feature is missing: Suport for left and right adjustment of \clines.
|
| Since I don't know when I will be able to implement that, and since I want
| the current booktabs support in before the next freeze I plan to merge
| the branch back soon. Unless I get objections this will happen on monday.
| The diff that will be merged is attached.
Index: src/insets/insettabular.C
===
--- src/insets/insettabular.C (Revision 14275)
+++ src/insets/insettabular.C (Revision 14278)
@@ -72,6 +72,7 @@ namespace {
int const ADD_TO_HEIGHT = 2;
int const ADD_TO_TABULAR_WIDTH = 2;
+int const default_line_space = 10;
We really should make a decision on how we want our naming to be.
CamelCase or stl/boost style.
At least we should not use different style for the same kind of
entities. (Not really related to this patch though)
Index: src/insets/ChangeLog
===
--- src/insets/ChangeLog(Revision 14275)
+++ src/insets/ChangeLog(Revision 14278)
@@ -799,6 +799,10 @@
* insettabular.[Ch] (string2params): Don't pretend to return the
active cell anymore and simplify keyword parsing.
+2004-11-11 Edwin Leuven
+
+ * insettabular.C (getStatus, tabularFeatures): handle booktabs feature
+
2004-11-10 Jean-Marc Lasgouttes [EMAIL PROTECTED]
* insetlatexaccent.h (isLetter): implement, so that word selection
Is this info now out dated?
And strictly speaking we are not using the ChangeLog more anyway...
(Handled at commit time I guess.)
[snip the other ChangeLogs]
Index: src/tabular.C
===
--- src/tabular.C (Revision 14275)
+++ src/tabular.C (Revision 14278)
@@ -64,6 +64,8 @@ using std::strlen;
namespace {
int const WIDTH_OF_LINE = 5;
+int const default_line_space = 10;
Hmm.. is this the same as the one in the other file?
(In insettabular.C)
If so we should perhaps find a way so that we only need one of them?
So I have looked through the patch and saw nothing wrong with it. I
havent compiled or tested it though.
Good work.
--
Lgb
[patch] merge booktabs branch
The booktabs support is fully functional now (except gtk frontend). One feature is missing: Suport for left and right adjustment of \clines. Since I don't know when I will be able to implement that, and since I want the current booktabs support in before the next freeze I plan to merge the branch back soon. Unless I get objections this will happen on monday. The diff that will be merged is attached. Georg merge.diff.gz Description: GNU Zip compressed data
Re: [patch] merge booktabs branch
Georg Baum wrote: > Since I don't know when I will be able to implement that, and since I want > the current booktabs support in before the next freeze I plan to merge > the branch back soon. Good plan! Jürgen
Re: [patch] merge booktabs branch
Georg Baum <[EMAIL PROTECTED]> writes:
| The booktabs support is fully functional now (except gtk frontend). One
| feature is missing: Suport for left and right adjustment of \clines.
|
| Since I don't know when I will be able to implement that, and since I want
| the current booktabs support in before the next freeze I plan to merge
| the branch back soon. Unless I get objections this will happen on monday.
| The diff that will be merged is attached.
Index: src/insets/insettabular.C
===
--- src/insets/insettabular.C (Revision 14275)
+++ src/insets/insettabular.C (Revision 14278)
@@ -72,6 +72,7 @@ namespace {
int const ADD_TO_HEIGHT = 2;
int const ADD_TO_TABULAR_WIDTH = 2;
+int const default_line_space = 10;
We really should make a decision on how we want our naming to be.
CamelCase or stl/boost style.
At least we should not use different style for the same kind of
entities. (Not really related to this patch though)
Index: src/insets/ChangeLog
===
--- src/insets/ChangeLog(Revision 14275)
+++ src/insets/ChangeLog(Revision 14278)
@@ -799,6 +799,10 @@
* insettabular.[Ch] (string2params): Don't pretend to return the
active cell anymore and simplify keyword parsing.
+2004-11-11 Edwin Leuven
+
+ * insettabular.C (getStatus, tabularFeatures): handle booktabs feature
+
2004-11-10 Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
* insetlatexaccent.h (isLetter): implement, so that word selection
Is this info now out dated?
And strictly speaking we are not using the ChangeLog more anyway...
(Handled at commit time I guess.)
[snip the other ChangeLogs]
Index: src/tabular.C
===
--- src/tabular.C (Revision 14275)
+++ src/tabular.C (Revision 14278)
@@ -64,6 +64,8 @@ using std::strlen;
namespace {
int const WIDTH_OF_LINE = 5;
+int const default_line_space = 10;
Hmm.. is this the same as the one in the other file?
(In insettabular.C)
If so we should perhaps find a way so that we only need one of them?
So I have looked through the patch and saw nothing wrong with it. I
havent compiled or tested it though.
Good work.
--
Lgb
Re: booktabs
Georg Baum wrote:
Am Sonntag, 25. Juni 2006 19:41 schrieb Juergen Spitzmueller:
Very good, thanks. However, I think the default switches should be
disabled
initially at least for non-booktabs tables. It looks rather odd for
those (on
screen and output).
Only bottom_space makes sense for non booktab tables IMO. I implemented
the others because it was easier for me than a logic for
enabling/disabling them. Feel free to change that.
OK. Then I'll disable the setting of the spaces initially. BTW I'd like to
adapt the spaces UI more to the other spaces UI in LyX, that is instead of
the check boxes: a combo none, default, custom. Agreed?
The length fields do use length validators. Why does it not work?
You have used the wrong signal. The attached patch fixes that. I'm currently
committing. The crash is now fixed AFAICS.
Well, for my usual work with booktabs, one important feature would be
missing:
Proper support for \cmidrule (i.e. ability to use something like
\cmidrule(l){2-3}\cmidrule(lr){4-4}\cmidrule(r){5-6}
). I'm not sure how the UI for this might look like, though.
That is indeed difficult. What about adding short lines to the left and
right of the bottom and top line of the border widget that can be set and
unset? E.g
- -- -
whould give \cmidrule{2-2}, and
-- -
would give \cmidrule(l){2-2} etc.
rules would be combined if the short lines inbetween are set, e.g.
- -- -
both in cell 2 and 3 would give \cmidrule{2-3}.
Sounds good! Do you have a go?
BTW the spaces should ideally be incorporated into the border widget,
because then it is clear what they do.
Yes, why not. There's enough room.
Jürgen
Georg
Index: src/frontends/qt4/QTabularDialog.C
===
--- src/frontends/qt4/QTabularDialog.C (Revision 14208)
+++ src/frontends/qt4/QTabularDialog.C (Arbeitskopie)
@@ -41,55 +41,55 @@ QTabularDialog::QTabularDialog(QTabular
bottomspaceED-setValidator(new LengthValidator(bottomspaceED));
interlinespaceED-setValidator(new LengthValidator(interlinespaceED));
- connect(topspaceED, SIGNAL(textChanged(const QString )),
+ connect(topspaceED, SIGNAL(returnPressed()),
this, SLOT(topspace_changed()));
connect(topspaceUnit, SIGNAL(selectionChanged(LyXLength::UNIT)),
this, SLOT(topspace_changed()));
connect(topspaceCB, SIGNAL(clicked()), this, SLOT(topspace_changed()));
- connect(bottomspaceED, SIGNAL(textChanged(const QString )),
+ connect(bottomspaceED, SIGNAL(returnPressed()),
this, SLOT(bottomspace_changed()));
connect(bottomspaceUnit, SIGNAL(selectionChanged(LyXLength::UNIT)),
this, SLOT(bottomspace_changed()));
connect(bottomspaceCB, SIGNAL(clicked()), this, SLOT(bottomspace_changed()));
- connect(interlinespaceED, SIGNAL(textChanged(const QString )),
+ connect(interlinespaceED, SIGNAL(returnPressed()),
this, SLOT(interlinespace_changed()));
connect(interlinespaceUnit, SIGNAL(selectionChanged(LyXLength::UNIT)),
this, SLOT(interlinespace_changed()));
connect(interlinespaceCB, SIGNAL(clicked()), this, SLOT(interlinespace_changed()));
connect(booktabsCB, SIGNAL(clicked()), this, SLOT(on_booktabsCB_stateChanged()));
connect( borderSetPB, SIGNAL( clicked() ), this, SLOT( borderSet_clicked() ) );
-connect( borderUnsetPB, SIGNAL( clicked() ), this, SLOT( borderUnset_clicked() ) );
-connect( longTabularCB, SIGNAL( toggled(bool) ), longtableGB, SLOT( setEnabled(bool) ) );
-connect( longTabularCB, SIGNAL( toggled(bool) ), newpageCB, SLOT( setEnabled(bool) ) );
-connect( hAlignCB, SIGNAL( activated(int) ), this, SLOT( hAlign_changed(int) ) );
-connect( vAlignCB, SIGNAL( activated(int) ), this, SLOT( vAlign_changed(int) ) );
-connect( multicolumnCB, SIGNAL( clicked() ), this, SLOT( multicolumn_clicked() ) );
-connect( newpageCB, SIGNAL( clicked() ), this, SLOT( ltNewpage_clicked() ) );
-connect( headerStatusCB, SIGNAL( clicked() ), this, SLOT( ltHeaderStatus_clicked() ) );
-connect( headerBorderAboveCB, SIGNAL( clicked() ), this, SLOT( ltHeaderBorderAbove_clicked() ) );
-connect( headerBorderBelowCB, SIGNAL( clicked() ), this, SLOT( ltHeaderBorderBelow_clicked() ) );
-connect( firstheaderStatusCB, SIGNAL( clicked() ), this, SLOT( ltFirstHeaderStatus_clicked() ) );
-connect( firstheaderBorderAboveCB, SIGNAL( clicked() ), this, SLOT( ltFirstHeaderBorderAbove_clicked() ) );
-connect( firstheaderBorderBelowCB, SIGNAL( clicked() ), this, SLOT( ltFirstHeaderBorderBelow_clicked() ) );
-connect( firstheaderNoContentsCB, SIGNAL( clicked() ), this, SLOT( ltFirstHeaderEmpty_clicked() ) );
-connect( footerStatusCB, SIGNAL( clicked() ), this, SLOT( ltFooterStatus_clicked() ) );
-connect( footerBorderAboveCB, SIGNAL( clicked() ), this, SLOT( ltFooterBorderAbove_clicked() ) );
-connect( footerBorderBelowCB, SIGNAL( clicked() ), this, SLOT
Re: booktabs
Juergen Spitzmueller wrote:
OK. Then I'll disable the setting of the spaces initially. BTW I'd like to
adapt the spaces UI more to the other spaces UI in LyX, that is instead of
the check boxes: a combo none, default, custom. Agreed?
Yes.
You have used the wrong signal. The attached patch fixes that. I'm
currently committing. The crash is now fixed AFAICS.
Great!
That is indeed difficult. What about adding short lines to the left and
right of the bottom and top line of the border widget that can be set and
unset? E.g
- -- -
whould give \cmidrule{2-2}, and
-- -
would give \cmidrule(l){2-2} etc.
rules would be combined if the short lines inbetween are set, e.g.
- -- -
both in cell 2 and 3 would give \cmidrule{2-3}.
Sounds good! Do you have a go?
When I find some time, yes.
Georg
Re: booktabs
Georg Baum wrote: Juergen Spitzmueller wrote: OK. Then I'll disable the setting of the spaces initially. BTW I'd like to adapt the spaces UI more to the other spaces UI in LyX, that is instead of the check boxes: a combo none, default, custom. Agreed? Yes. OK, attached is a patch that does that and - sets spaces to none initially - moves the booktabs button to borders as well, since it looks more obvious there. - changed the input validators, so it is now possible to insert lenghts like 2em directly to the widget. (cf. the attached screenshot) OK to apply? Sounds good! Do you have a go? When I find some time, yes. Great. It's gonna be a very nice feature. Jürgen Georg bt3.diff.gz Description: GNU Zip compressed data lyx-bt.png Description: PNG image
Re: booktabs
Juergen Spitzmueller wrote:
OK, attached is a patch that does that and
- sets spaces to none initially
- moves the booktabs button to borders as well, since it looks more
obvious there.
- changed the input validators, so it is now possible to insert lenghts
like 2em directly to the widget.
I see that you used validators for unsigned lengths. I agree that this is
the normal case, but maybe it should be possible to insert a negative
length in special cases?
OK to apply?
Yes, but I have some comments:
+ if (!form_-bc().bp().isReadOnly()) {
+ topspaceED-setEnabled(false);
+ topspaceUnit-setEnabled(false);
+ }
The if is not needed here.
+ connect(topspaceCO, SIGNAL( activated(int) ), this,
SLOT(topspace_changed()));
I think our spacing rules say
+ connect(topspaceCO, SIGNAL(activated(int)), this,
SLOT(topspace_changed()));
- tabstoptopspaceED/tabstop
- tabstoptopspaceUnit/tabstop
- tabstopbottomspaceED/tabstop
- tabstopbottomspaceUnit/tabstop
- tabstopinterlinespaceED/tabstop
- tabstopinterlinespaceUnit/tabstop
Why are the new widgets not listed?
Georg
Re: booktabs
Georg Baum wrote:
I see that you used validators for unsigned lengths. I agree that this is
the normal case, but maybe it should be possible to insert a negative
length in special cases?
Right, I didn't think about that.
OK to apply?
Yes, but I have some comments:
+ if (!form_-bc().bp().isReadOnly()) {
+ topspaceED-setEnabled(false);
+ topspaceUnit-setEnabled(false);
+ }
The if is not needed here.
Indeed.
+ connect(topspaceCO, SIGNAL( activated(int) ), this,
SLOT(topspace_changed()));
I think our spacing rules say
+ connect(topspaceCO, SIGNAL(activated(int)), this,
SLOT(topspace_changed()));
OK. I'll correct this in the cotext as well (Abdel, you're reading this?).
- tabstoptopspaceED/tabstop
- tabstoptopspaceUnit/tabstop
- tabstopbottomspaceED/tabstop
- tabstopbottomspaceUnit/tabstop
- tabstopinterlinespaceED/tabstop
- tabstopinterlinespaceUnit/tabstop
Why are the new widgets not listed?
I missed that.
I corrected the issues and will commit now.
Jürgen
Georg
Re: booktabs
Georg Baum wrote:
> Am Sonntag, 25. Juni 2006 19:41 schrieb Juergen Spitzmueller:
> > Very good, thanks. However, I think the "default" switches should be
>
> disabled
>
> > initially at least for non-booktabs tables. It looks rather odd for
>
> those (on
>
> > screen and output).
>
> Only bottom_space makes sense for non booktab tables IMO. I implemented
> the others because it was easier for me than a logic for
> enabling/disabling them. Feel free to change that.
OK. Then I'll disable the setting of the spaces initially. BTW I'd like to
adapt the spaces UI more to the other spaces UI in LyX, that is instead of
the check boxes: a combo "none", "default", "custom". Agreed?
> The length fields do use length validators. Why does it not work?
You have used the wrong signal. The attached patch fixes that. I'm currently
committing. The crash is now fixed AFAICS.
> > Well, for my usual work with booktabs, one important feature would be
>
> missing:
> > Proper support for \cmidrule (i.e. ability to use something like
> > \cmidrule(l){2-3}\cmidrule(lr){4-4}\cmidrule(r){5-6}
> > ). I'm not sure how the UI for this might look like, though.
>
> That is indeed difficult. What about adding short lines to the left and
> right of the bottom and top line of the border widget that can be set and
> unset? E.g
>
> - -- -
>
> whould give \cmidrule{2-2}, and
>
> -- -
>
> would give \cmidrule(l){2-2} etc.
>
> rules would be combined if the short lines inbetween are set, e.g.
>
> - -- -
>
> both in cell 2 and 3 would give \cmidrule{2-3}.
Sounds good! Do you have a go?
> BTW the spaces should ideally be incorporated into the border widget,
> because then it is clear what they do.
Yes, why not. There's enough room.
Jürgen
> Georg
Index: src/frontends/qt4/QTabularDialog.C
===
--- src/frontends/qt4/QTabularDialog.C (Revision 14208)
+++ src/frontends/qt4/QTabularDialog.C (Arbeitskopie)
@@ -41,55 +41,55 @@ QTabularDialog::QTabularDialog(QTabular
bottomspaceED->setValidator(new LengthValidator(bottomspaceED));
interlinespaceED->setValidator(new LengthValidator(interlinespaceED));
- connect(topspaceED, SIGNAL(textChanged(const QString &)),
+ connect(topspaceED, SIGNAL(returnPressed()),
this, SLOT(topspace_changed()));
connect(topspaceUnit, SIGNAL(selectionChanged(LyXLength::UNIT)),
this, SLOT(topspace_changed()));
connect(topspaceCB, SIGNAL(clicked()), this, SLOT(topspace_changed()));
- connect(bottomspaceED, SIGNAL(textChanged(const QString &)),
+ connect(bottomspaceED, SIGNAL(returnPressed()),
this, SLOT(bottomspace_changed()));
connect(bottomspaceUnit, SIGNAL(selectionChanged(LyXLength::UNIT)),
this, SLOT(bottomspace_changed()));
connect(bottomspaceCB, SIGNAL(clicked()), this, SLOT(bottomspace_changed()));
- connect(interlinespaceED, SIGNAL(textChanged(const QString &)),
+ connect(interlinespaceED, SIGNAL(returnPressed()),
this, SLOT(interlinespace_changed()));
connect(interlinespaceUnit, SIGNAL(selectionChanged(LyXLength::UNIT)),
this, SLOT(interlinespace_changed()));
connect(interlinespaceCB, SIGNAL(clicked()), this, SLOT(interlinespace_changed()));
connect(booktabsCB, SIGNAL(clicked()), this, SLOT(on_booktabsCB_stateChanged()));
connect( borderSetPB, SIGNAL( clicked() ), this, SLOT( borderSet_clicked() ) );
-connect( borderUnsetPB, SIGNAL( clicked() ), this, SLOT( borderUnset_clicked() ) );
-connect( longTabularCB, SIGNAL( toggled(bool) ), longtableGB, SLOT( setEnabled(bool) ) );
-connect( longTabularCB, SIGNAL( toggled(bool) ), newpageCB, SLOT( setEnabled(bool) ) );
-connect( hAlignCB, SIGNAL( activated(int) ), this, SLOT( hAlign_changed(int) ) );
-connect( vAlignCB, SIGNAL( activated(int) ), this, SLOT( vAlign_changed(int) ) );
-connect( multicolumnCB, SIGNAL( clicked() ), this, SLOT( multicolumn_clicked() ) );
-connect( newpageCB, SIGNAL( clicked() ), this, SLOT( ltNewpage_clicked() ) );
-connect( headerStatusCB, SIGNAL( clicked() ), this, SLOT( ltHeaderStatus_clicked() ) );
-connect( headerBorderAboveCB, SIGNAL( clicked() ), this, SLOT( ltHeaderBorderAbove_clicked() ) );
-connect( headerBorderBelowCB, SIGNAL( clicked() ), this, SLOT( ltHeaderBorderBelow_clicked() ) );
-connect( firstheaderStatusCB, SIGNAL( clicked() ), this, SLOT( ltFirstHeaderStatus_clicked() ) );
-connect( firstheaderBorderAboveCB, SIGNAL( clicked() ), this, SLOT( ltFirstHeaderBorderAbove_clicked() ) );
-connect( firstheaderBorderBelowCB, SIGNAL( clicked() ), this, SLOT( ltFirstHeaderBorderBelow_clicked() ) );
-connect( firstheaderNoContentsCB, SIGNAL( clicked() ), this, SLOT( ltFirstHeaderEmpty_clicked() ) );
-
Re: booktabs
Juergen Spitzmueller wrote:
> OK. Then I'll disable the setting of the spaces initially. BTW I'd like to
> adapt the spaces UI more to the other spaces UI in LyX, that is instead of
> the check boxes: a combo "none", "default", "custom". Agreed?
Yes.
> You have used the wrong signal. The attached patch fixes that. I'm
> currently committing. The crash is now fixed AFAICS.
Great!
>> That is indeed difficult. What about adding short lines to the left and
>> right of the bottom and top line of the border widget that can be set and
>> unset? E.g
>>
>> - -- -
>>
>> whould give \cmidrule{2-2}, and
>>
>> -- -
>>
>> would give \cmidrule(l){2-2} etc.
>>
>> rules would be combined if the short lines inbetween are set, e.g.
>>
>> - -- -
>>
>> both in cell 2 and 3 would give \cmidrule{2-3}.
>
> Sounds good! Do you have a go?
When I find some time, yes.
Georg
Re: booktabs
Georg Baum wrote: > Juergen Spitzmueller wrote: > > OK. Then I'll disable the setting of the spaces initially. BTW I'd like > > to adapt the spaces UI more to the other spaces UI in LyX, that is > > instead of the check boxes: a combo "none", "default", "custom". Agreed? > > Yes. OK, attached is a patch that does that and - sets spaces to "none" initially - moves the booktabs button to "borders" as well, since it looks more obvious there. - changed the input validators, so it is now possible to insert lenghts like "2em" directly to the widget. (cf. the attached screenshot) OK to apply? > > Sounds good! Do you have a go? > > When I find some time, yes. Great. It's gonna be a very nice feature. Jürgen > Georg bt3.diff.gz Description: GNU Zip compressed data lyx-bt.png Description: PNG image
Re: booktabs
Juergen Spitzmueller wrote:
> OK, attached is a patch that does that and
> - sets spaces to "none" initially
> - moves the booktabs button to "borders" as well, since it looks more
> obvious there.
> - changed the input validators, so it is now possible to insert lenghts
> like "2em" directly to the widget.
I see that you used validators for unsigned lengths. I agree that this is
the normal case, but maybe it should be possible to insert a negative
length in special cases?
> OK to apply?
Yes, but I have some comments:
+ if (!form_->bc().bp().isReadOnly()) {
+ topspaceED->setEnabled(false);
+ topspaceUnit->setEnabled(false);
+ }
The if is not needed here.
+ connect(topspaceCO, SIGNAL( activated(int) ), this,
SLOT(topspace_changed()));
I think our spacing rules say
+ connect(topspaceCO, SIGNAL(activated(int)), this,
SLOT(topspace_changed()));
- topspaceED
- topspaceUnit
- bottomspaceED
- bottomspaceUnit
- interlinespaceED
- interlinespaceUnit
Why are the new widgets not listed?
Georg
Re: booktabs
Georg Baum wrote:
> I see that you used validators for unsigned lengths. I agree that this is
> the normal case, but maybe it should be possible to insert a negative
> length in special cases?
Right, I didn't think about that.
> > OK to apply?
>
> Yes, but I have some comments:
>
> + if (!form_->bc().bp().isReadOnly()) {
> + topspaceED->setEnabled(false);
> + topspaceUnit->setEnabled(false);
> + }
>
> The if is not needed here.
Indeed.
> + connect(topspaceCO, SIGNAL( activated(int) ), this,
> SLOT(topspace_changed()));
>
>
> I think our spacing rules say
>
> + connect(topspaceCO, SIGNAL(activated(int)), this,
> SLOT(topspace_changed()));
OK. I'll correct this in the cotext as well (Abdel, you're reading this?).
> - topspaceED
> - topspaceUnit
> - bottomspaceED
> - bottomspaceUnit
> - interlinespaceED
> - interlinespaceUnit
>
> Why are the new widgets not listed?
I missed that.
I corrected the issues and will commit now.
Jürgen
> Georg
[patch] small booktabs fix
This fixes a wrong signal/slot connection and goes in now.
Georg
Log:
* src/frontends/qt4/QTabularDialog.[Ch]
(QTabularDialog::on_booktabsCB_stateChanged): remove int argument,
since the signal connected to this slot does not take an argument.
* src/frontends/qt4/QTabularDialog.C:
(QTabularDialog::on_booktabsCB_stateChanged): call update_borders
Index: src/frontends/qt4/QTabularDialog.C
===
--- src/frontends/qt4/QTabularDialog.C (Revision 14207)
+++ src/frontends/qt4/QTabularDialog.C (Arbeitskopie)
@@ -106,10 +106,11 @@ void QTabularDialog::closeEvent(QCloseEv
}
-void QTabularDialog::on_booktabsCB_stateChanged(int checked)
+void QTabularDialog::on_booktabsCB_stateChanged()
{
form_-changed();
- form_-controller().booktabs(checked);
+ form_-controller().booktabs(booktabsCB-isChecked());
+ form_-update_borders();
}
Index: src/frontends/qt4/QTabularDialog.h
===
--- src/frontends/qt4/QTabularDialog.h (Revision 14207)
+++ src/frontends/qt4/QTabularDialog.h (Arbeitskopie)
@@ -35,7 +35,7 @@ protected slots:
virtual void topspace_changed();
virtual void bottomspace_changed();
virtual void interlinespace_changed();
- virtual void on_booktabsCB_stateChanged(int);
+ virtual void on_booktabsCB_stateChanged();
virtual void close_clicked();
virtual void borderSet_clicked();
virtual void borderUnset_clicked();
Re: booktabs
Georg Baum wrote: Edwin, could you please have a look at the qt4 problem? After that is fixed the branch could be merged. will do (saw the space problem too, but have been unable to trace down the culprit...)
Re: booktabs
Georg Baum wrote:
Am Montag, 12. Juni 2006 15:13 schrieb Juergen Spitzmueller:
I had a quick look. It looks good. However, it should be possible to use
\addlinespace (without optional argument). I guess most of the time
you'll
need the same linespace, which is then globally defined.
This patch adds that. It goes in now, please test.
Very good, thanks. However, I think the default switches should be disabled
initially at least for non-booktabs tables. It looks rather odd for those (on
screen and output).
Also there are accelerators missing for the default checks (and some
duplicated accelerators for _T_op Space/_T_able Settings and _B_ottom
Space/_B_orders).
Attached is a patch for the gui issues issues, which I'll shove in.
Known problems: qt4 crashes if you want to change the spaces, I don't know
why.
There's a cut'n'paste error in QDialog.C (see attached patch). That was
obviously one cause. Now it only crashes if you insert bogus data (like r)
to the fields. I guess it needs a proper input validator.
I have no further plans for the booktabs branch. Is anything missing?
Well, for my usual work with booktabs, one important feature would be missing:
Proper support for \cmidrule (i.e. ability to use something like
\cmidrule(l){2-3}\cmidrule(lr){4-4}\cmidrule(r){5-6}
). I'm not sure how the UI for this might look like, though.
Jürgen
Edwin, could you please have a look at the qt4 problem? After that is
fixed the branch could be merged.
Georg
Index: src/frontends/qt3/ui/QTabularDialogBase.ui
===
--- src/frontends/qt3/ui/QTabularDialogBase.ui (Revision 14208)
+++ src/frontends/qt3/ui/QTabularDialogBase.ui (Arbeitskopie)
@@ -306,7 +306,6 @@
/widget
/grid
/widget
-
widget class=QWidget
property name=name
cstringtab/cstring
@@ -324,7 +323,7 @@
property name=spacing
number6/number
/property
-widget class=LengthCombo row=0 column=2
+widget class=LengthCombo row=0 column=2
property name=name
cstringtopspaceUnit/cstring
/property
@@ -340,12 +339,8 @@
property name=focusPolicy
enumStrongFocus/enum
/property
-property
-nametoolTip/name
-stringTopspace unit/string
-/property
/widget
-widget class=QLineEdit row=0 column=1
+widget class=QLineEdit row=0 column=1
property name=name
cstringtopspaceED/cstring
/property
@@ -355,17 +350,15 @@
property name=text
string/string
/property
-property
-nametoolTip/name
-stringExtra space above the row/string
+property name= stdset=0
/property
/widget
-widget class=QLabel row=0 column=0
+widget class=QLabel row=0 column=0
property name=name
cstringtopspaceLA/cstring
/property
property name=text
-stringamp;Top space:/string
+stringTamp;op space:/string
/property
property name=buddy stdset=0
cstringtopspaceED/cstring
@@ -376,13 +369,16 @@
cstringtopspaceCB/cstring
/property
property name=text
-stringDefault/string
+stringamp;Default/string
+/property
+property name=accel
+stringAlt+D/string
/property
property name=toolTip stdset=0
stringUse the default top space amount/string
/property
/widget
-widget class=LengthCombo row=1 column=2
+widget class=LengthCombo row=1 column=2
property name=name
cstringbottomspaceUnit/cstring
/property
@@ -398,12 +394,8 @@
property name=focusPolicy
enumStrongFocus/enum
/property
-property
Re: booktabs
Am Sonntag, 25. Juni 2006 19:41 schrieb Juergen Spitzmueller:
Very good, thanks. However, I think the default switches should be
disabled
initially at least for non-booktabs tables. It looks rather odd for
those (on
screen and output).
Only bottom_space makes sense for non booktab tables IMO. I implemented
the others because it was easier for me than a logic for
enabling/disabling them. Feel free to change that.
Also there are accelerators missing for the default checks (and some
duplicated accelerators for _T_op Space/_T_able Settings and _B_ottom
Space/_B_orders).
Attached is a patch for the gui issues issues, which I'll shove in.
Known problems: qt4 crashes if you want to change the spaces, I don't
know
why.
There's a cut'n'paste error in QDialog.C (see attached patch). That was
obviously one cause. Now it only crashes if you insert bogus data
(like r)
to the fields. I guess it needs a proper input validator.
Thanks, it is really too easy to overlook ones own mistakes.
The length fields do use length validators. Why does it not work?
Well, for my usual work with booktabs, one important feature would be
missing:
Proper support for \cmidrule (i.e. ability to use something like
\cmidrule(l){2-3}\cmidrule(lr){4-4}\cmidrule(r){5-6}
). I'm not sure how the UI for this might look like, though.
That is indeed difficult. What about adding short lines to the left and
right of the bottom and top line of the border widget that can be set and
unset? E.g
- -- -
whould give \cmidrule{2-2}, and
-- -
would give \cmidrule(l){2-2} etc.
rules would be combined if the short lines inbetween are set, e.g.
- -- -
both in cell 2 and 3 would give \cmidrule{2-3}.
BTW the spaces should ideally be incorporated into the border widget,
because then it is clear what they do.
Georg
[patch] small booktabs fix
This fixes a wrong signal/slot connection and goes in now.
Georg
Log:
* src/frontends/qt4/QTabularDialog.[Ch]
(QTabularDialog::on_booktabsCB_stateChanged): remove int argument,
since the signal connected to this slot does not take an argument.
* src/frontends/qt4/QTabularDialog.C:
(QTabularDialog::on_booktabsCB_stateChanged): call update_borders
Index: src/frontends/qt4/QTabularDialog.C
===
--- src/frontends/qt4/QTabularDialog.C (Revision 14207)
+++ src/frontends/qt4/QTabularDialog.C (Arbeitskopie)
@@ -106,10 +106,11 @@ void QTabularDialog::closeEvent(QCloseEv
}
-void QTabularDialog::on_booktabsCB_stateChanged(int checked)
+void QTabularDialog::on_booktabsCB_stateChanged()
{
form_->changed();
- form_->controller().booktabs(checked);
+ form_->controller().booktabs(booktabsCB->isChecked());
+ form_->update_borders();
}
Index: src/frontends/qt4/QTabularDialog.h
===
--- src/frontends/qt4/QTabularDialog.h (Revision 14207)
+++ src/frontends/qt4/QTabularDialog.h (Arbeitskopie)
@@ -35,7 +35,7 @@ protected slots:
virtual void topspace_changed();
virtual void bottomspace_changed();
virtual void interlinespace_changed();
- virtual void on_booktabsCB_stateChanged(int);
+ virtual void on_booktabsCB_stateChanged();
virtual void close_clicked();
virtual void borderSet_clicked();
virtual void borderUnset_clicked();
Re: booktabs
Georg Baum wrote: Edwin, could you please have a look at the qt4 problem? After that is fixed the branch could be merged. will do (saw the space problem too, but have been unable to trace down the culprit...)
Re: booktabs
Georg Baum wrote:
> Am Montag, 12. Juni 2006 15:13 schrieb Juergen Spitzmueller:
> > I had a quick look. It looks good. However, it should be possible to use
> > \addlinespace (without optional argument). I guess most of the time
>
> you'll
>
> > need the same linespace, which is then globally defined.
>
> This patch adds that. It goes in now, please test.
Very good, thanks. However, I think the "default" switches should be disabled
initially at least for non-booktabs tables. It looks rather odd for those (on
screen and output).
Also there are accelerators missing for the default checks (and some
duplicated accelerators for _T_op Space/_T_able Settings and _B_ottom
Space/_B_orders).
Attached is a patch for the gui issues issues, which I'll shove in.
> Known problems: qt4 crashes if you want to change the spaces, I don't know
> why.
There's a cut'n'paste error in QDialog.C (see attached patch). That was
obviously one cause. Now it only crashes if you insert bogus data (like "r")
to the fields. I guess it needs a proper input validator.
> I have no further plans for the booktabs branch. Is anything missing?
Well, for my usual work with booktabs, one important feature would be missing:
Proper support for \cmidrule (i.e. ability to use something like
\cmidrule(l){2-3}\cmidrule(lr){4-4}\cmidrule(r){5-6}
). I'm not sure how the UI for this might look like, though.
Jürgen
> Edwin, could you please have a look at the qt4 problem? After that is
> fixed the branch could be merged.
>
>
> Georg
Index: src/frontends/qt3/ui/QTabularDialogBase.ui
===
--- src/frontends/qt3/ui/QTabularDialogBase.ui (Revision 14208)
+++ src/frontends/qt3/ui/QTabularDialogBase.ui (Arbeitskopie)
@@ -306,7 +306,6 @@
-
tab
@@ -324,7 +323,7 @@
6
-
+
topspaceUnit
@@ -340,12 +339,8 @@
StrongFocus
-
-toolTip
-Topspace unit
-
-
+
topspaceED
@@ -355,17 +350,15 @@
-
-toolTip
-Extra space above the row
+
-
+
topspaceLA
-Top space:
+Top space:
topspaceED
@@ -376,13 +369,16 @@
topspaceCB
-Default
+Default
+
+
+Alt+D
Use the default top space amount
-
+
bottomspaceUnit
@@ -398,12 +394,8 @@
StrongFocus
-
-toolTip
-Bottomspace unit
-
-
+
bottomspaceED
@@ -413,17 +405,15 @@
-
-toolTip
-Extra space below the row
+
-
+
bottomspaceLA
-Bottom space:
+Bottom space:
bottomspaceED
@@ -434,13 +424,16 @@
bottomspaceCB
Re: booktabs
Am Sonntag, 25. Juni 2006 19:41 schrieb Juergen Spitzmueller:
> Very good, thanks. However, I think the "default" switches should be
disabled
> initially at least for non-booktabs tables. It looks rather odd for
those (on
> screen and output).
Only bottom_space makes sense for non booktab tables IMO. I implemented
the others because it was easier for me than a logic for
enabling/disabling them. Feel free to change that.
> Also there are accelerators missing for the default checks (and some
> duplicated accelerators for _T_op Space/_T_able Settings and _B_ottom
> Space/_B_orders).
> Attached is a patch for the gui issues issues, which I'll shove in.
>
> > Known problems: qt4 crashes if you want to change the spaces, I don't
know
> > why.
>
> There's a cut'n'paste error in QDialog.C (see attached patch). That was
> obviously one cause. Now it only crashes if you insert bogus data
(like "r")
> to the fields. I guess it needs a proper input validator.
Thanks, it is really too easy to overlook ones own mistakes.
The length fields do use length validators. Why does it not work?
> Well, for my usual work with booktabs, one important feature would be
missing:
> Proper support for \cmidrule (i.e. ability to use something like
> \cmidrule(l){2-3}\cmidrule(lr){4-4}\cmidrule(r){5-6}
> ). I'm not sure how the UI for this might look like, though.
That is indeed difficult. What about adding short lines to the left and
right of the bottom and top line of the border widget that can be set and
unset? E.g
- -- -
whould give \cmidrule{2-2}, and
-- -
would give \cmidrule(l){2-2} etc.
rules would be combined if the short lines inbetween are set, e.g.
- -- -
both in cell 2 and 3 would give \cmidrule{2-3}.
BTW the spaces should ideally be incorporated into the border widget,
because then it is clear what they do.
Georg
Re: booktabs
Am Mittwoch, 7. Juni 2006 02:45 schrieb Edwin Leuven:
the attached patch includes qt4 (haven't had time to test yet, added
booktabs but didn't check out interline space)
Thanks, I put the stuff without the interlinespace changes in. The current
diff is now attrached. I still need to think about the space stuff.
Georg
Index: src/insets/insettabular.C
===
--- src/insets/insettabular.C (Revision 14175)
+++ src/insets/insettabular.C (Arbeitskopie)
@@ -135,6 +135,9 @@ TabularFeature tabularFeature[] =
{ LyXTabular::SET_SPECIAL_MULTI, set-special-multi },
{ LyXTabular::SET_BOOKTABS, set-booktabs },
{ LyXTabular::UNSET_BOOKTABS, unset-booktabs },
+ { LyXTabular::SET_TOP_SPACE, set-top-space },
+ { LyXTabular::SET_BOTTOM_SPACE, set-bottom-space },
+ { LyXTabular::SET_INTERLINE_SPACE, set-interline-space },
{ LyXTabular::LAST_ACTION, }
};
@@ -270,8 +273,10 @@ void InsetTabular::metrics(MetricsInfo
tabular.setWidthOfCell(cell, dim.wid);
++cell;
}
- tabular.setAscentOfRow(i, maxAsc + ADD_TO_HEIGHT);
- tabular.setDescentOfRow(i, maxDesc + ADD_TO_HEIGHT);
+ tabular.setAscentOfRow(i, maxAsc + ADD_TO_HEIGHT +
+ tabular.row_info[i].top_space.inPixels(mi.base.textwidth));
+ tabular.setDescentOfRow(i, maxDesc + ADD_TO_HEIGHT +
+ tabular.row_info[i].bottom_space.inPixels(mi.base.textwidth));
}
dim.asc = tabular.getAscentOfRow(0);
@@ -814,6 +819,9 @@ bool InsetTabular::getStatus(LCursor c
case LyXTabular::DELETE_COLUMN:
case LyXTabular::SET_ALL_LINES:
case LyXTabular::UNSET_ALL_LINES:
+ case LyXTabular::SET_TOP_SPACE:
+ case LyXTabular::SET_BOTTOM_SPACE:
+ case LyXTabular::SET_INTERLINE_SPACE:
status.clear();
return true;
@@ -1141,11 +1149,10 @@ int InsetTabular::dist(idx_type const ce
Point o = theCoords.getInsets().xy(inset);
int const xbeg = o.x_ - tabular.getBeginningOfTextInCell(cell);
int const xend = xbeg + tabular.getWidthOfColumn(cell);
- int const ybeg = o.y_ - inset.ascent();
row_type const row = tabular.row_of_cell(cell);
- int const rowheight = tabular.getAscentOfRow(row)
- + tabular.getDescentOfRow(row);
- int const yend = ybeg + rowheight;
+ int const ybeg = o.y_ - tabular.getAscentOfRow(row) -
+ tabular.getAdditionalHeight(row);
+ int const yend = o.y_ + tabular.getDescentOfRow(row);
if (x xbeg)
xx = xbeg - x;
@@ -1656,6 +1663,33 @@ void InsetTabular::tabularFeatures(LCurs
tabular.setBookTabs(false);
break;
+ case LyXTabular::SET_TOP_SPACE: {
+ LyXLength len;
+ if (isValidLength(value, len)) {
+ for (row_type i = sel_row_start; i = sel_row_end; ++i)
+tabular.row_info[i].top_space = len;
+ }
+ break;
+ }
+
+ case LyXTabular::SET_BOTTOM_SPACE: {
+ LyXLength len;
+ if (isValidLength(value, len)) {
+ for (row_type i = sel_row_start; i = sel_row_end; ++i)
+tabular.row_info[i].bottom_space = len;
+ }
+ break;
+ }
+
+ case LyXTabular::SET_INTERLINE_SPACE: {
+ LyXLength len;
+ if (isValidLength(value, len)) {
+ for (row_type i = sel_row_start; i = sel_row_end; ++i)
+tabular.row_info[i].interline_space = len;
+ }
+ break;
+ }
+
// dummy stuff just to avoid warnings
case LyXTabular::LAST_ACTION:
break;
Index: src/frontends/qt3/QTabularDialog.C
===
--- src/frontends/qt3/QTabularDialog.C (Revision 14175)
+++ src/frontends/qt3/QTabularDialog.C (Arbeitskopie)
@@ -37,6 +37,9 @@ QTabularDialog::QTabularDialog(QTabular
form, SLOT(slotClose()));
widthED-setValidator(unsignedLengthValidator(widthED));
+ topspaceED-setValidator(new LengthValidator(topspaceED));
+ bottomspaceED-setValidator(new LengthValidator(bottomspaceED));
+ interlinespaceED-setValidator(new LengthValidator(interlinespaceED));
}
@@ -119,6 +122,30 @@ void QTabularDialog::width_changed()
}
+void QTabularDialog::topspace_changed()
+{
+ form_-changed();
+ string const topspace = widgetsToLength(topspaceED, topspaceUnit);
+ form_-controller().set(LyXTabular::SET_TOP_SPACE, topspace);
+}
+
+
+void QTabularDialog::bottomspace_changed()
+{
+ form_-changed();
+ string const bottomspace = widgetsToLength(bottomspaceED, bottomspaceUnit);
+ form_-controller().set(LyXTabular::SET_BOTTOM_SPACE, bottomspace);
+}
+
+
+void QTabularDialog::interlinespace_changed()
+{
+ form_-changed();
+ string const interlinespace = widgetsToLength(interlinespaceED, interlinespaceUnit);
+ form_-controller().set(LyXTabular::SET_INTERLINE_SPACE, interlinespace);
+}
+
+
void QTabularDialog::multicolumn_clicked()
{
form_-controller().toggleMultiColumn();
Index: src/frontends/qt3/ui/QTabularDialogBase.ui
===
--- src/frontends/qt3/ui/QTabularDialogBase.ui (Revision 14175)
+++ src/frontends/qt3/ui/QTabularDialogBase.ui (Arbeitskopie)
@@ -306,6 +306,187 @@
/widget
/grid
/widget
Re: booktabs
Am Mittwoch, 7. Juni 2006 02:45 schrieb Edwin Leuven:
> the attached patch includes qt4 (haven't had time to test yet, added
> booktabs but didn't check out interline space)
Thanks, I put the stuff without the interlinespace changes in. The current
diff is now attrached. I still need to think about the space stuff.
Georg
Index: src/insets/insettabular.C
===
--- src/insets/insettabular.C (Revision 14175)
+++ src/insets/insettabular.C (Arbeitskopie)
@@ -135,6 +135,9 @@ TabularFeature tabularFeature[] =
{ LyXTabular::SET_SPECIAL_MULTI, "set-special-multi" },
{ LyXTabular::SET_BOOKTABS, "set-booktabs" },
{ LyXTabular::UNSET_BOOKTABS, "unset-booktabs" },
+ { LyXTabular::SET_TOP_SPACE, "set-top-space" },
+ { LyXTabular::SET_BOTTOM_SPACE, "set-bottom-space" },
+ { LyXTabular::SET_INTERLINE_SPACE, "set-interline-space" },
{ LyXTabular::LAST_ACTION, "" }
};
@@ -270,8 +273,10 @@ void InsetTabular::metrics(MetricsInfo &
tabular.setWidthOfCell(cell, dim.wid);
++cell;
}
- tabular.setAscentOfRow(i, maxAsc + ADD_TO_HEIGHT);
- tabular.setDescentOfRow(i, maxDesc + ADD_TO_HEIGHT);
+ tabular.setAscentOfRow(i, maxAsc + ADD_TO_HEIGHT +
+ tabular.row_info[i].top_space.inPixels(mi.base.textwidth));
+ tabular.setDescentOfRow(i, maxDesc + ADD_TO_HEIGHT +
+ tabular.row_info[i].bottom_space.inPixels(mi.base.textwidth));
}
dim.asc = tabular.getAscentOfRow(0);
@@ -814,6 +819,9 @@ bool InsetTabular::getStatus(LCursor & c
case LyXTabular::DELETE_COLUMN:
case LyXTabular::SET_ALL_LINES:
case LyXTabular::UNSET_ALL_LINES:
+ case LyXTabular::SET_TOP_SPACE:
+ case LyXTabular::SET_BOTTOM_SPACE:
+ case LyXTabular::SET_INTERLINE_SPACE:
status.clear();
return true;
@@ -1141,11 +1149,10 @@ int InsetTabular::dist(idx_type const ce
Point o = theCoords.getInsets().xy();
int const xbeg = o.x_ - tabular.getBeginningOfTextInCell(cell);
int const xend = xbeg + tabular.getWidthOfColumn(cell);
- int const ybeg = o.y_ - inset.ascent();
row_type const row = tabular.row_of_cell(cell);
- int const rowheight = tabular.getAscentOfRow(row)
- + tabular.getDescentOfRow(row);
- int const yend = ybeg + rowheight;
+ int const ybeg = o.y_ - tabular.getAscentOfRow(row) -
+ tabular.getAdditionalHeight(row);
+ int const yend = o.y_ + tabular.getDescentOfRow(row);
if (x < xbeg)
xx = xbeg - x;
@@ -1656,6 +1663,33 @@ void InsetTabular::tabularFeatures(LCurs
tabular.setBookTabs(false);
break;
+ case LyXTabular::SET_TOP_SPACE: {
+ LyXLength len;
+ if (isValidLength(value, )) {
+ for (row_type i = sel_row_start; i <= sel_row_end; ++i)
+tabular.row_info[i].top_space = len;
+ }
+ break;
+ }
+
+ case LyXTabular::SET_BOTTOM_SPACE: {
+ LyXLength len;
+ if (isValidLength(value, )) {
+ for (row_type i = sel_row_start; i <= sel_row_end; ++i)
+tabular.row_info[i].bottom_space = len;
+ }
+ break;
+ }
+
+ case LyXTabular::SET_INTERLINE_SPACE: {
+ LyXLength len;
+ if (isValidLength(value, )) {
+ for (row_type i = sel_row_start; i <= sel_row_end; ++i)
+tabular.row_info[i].interline_space = len;
+ }
+ break;
+ }
+
// dummy stuff just to avoid warnings
case LyXTabular::LAST_ACTION:
break;
Index: src/frontends/qt3/QTabularDialog.C
===
--- src/frontends/qt3/QTabularDialog.C (Revision 14175)
+++ src/frontends/qt3/QTabularDialog.C (Arbeitskopie)
@@ -37,6 +37,9 @@ QTabularDialog::QTabularDialog(QTabular
form, SLOT(slotClose()));
widthED->setValidator(unsignedLengthValidator(widthED));
+ topspaceED->setValidator(new LengthValidator(topspaceED));
+ bottomspaceED->setValidator(new LengthValidator(bottomspaceED));
+ interlinespaceED->setValidator(new LengthValidator(interlinespaceED));
}
@@ -119,6 +122,30 @@ void QTabularDialog::width_changed()
}
+void QTabularDialog::topspace_changed()
+{
+ form_->changed();
+ string const topspace = widgetsToLength(topspaceED, topspaceUnit);
+ form_->controller().set(LyXTabular::SET_TOP_SPACE, topspace);
+}
+
+
+void QTabularDialog::bottomspace_changed()
+{
+ form_->changed();
+ string const bottomspace = widgetsToLength(bottomspaceED, bottomspaceUnit);
+ form_->controller().set(LyXTabular::SET_BOTTOM_SPACE, bottomspace);
+}
+
+
+void QTabularDialog::interlinespace_changed()
+{
+ form_->changed();
+ string const interlinespace = widgetsToLength(interlinespaceED, interlinespaceUnit);
+ form_->controller().set(LyXTabular::SET_INTERLINE_SPACE, interlinespace);
+}
+
+
void QTabularDialog::multicolumn_clicked()
{
form_->controller().toggleMultiColumn();
Index: src/frontends/qt3/ui/QTabularDialogBase.ui
===
--- src/fronten
Re: booktabs
Georg Baum wrote: Remaining tasks: Add support for interline space (half finished, see attached) and testing. I had a quick look. It looks good. However, it should be possible to use \addlinespace (without optional argument). I guess most of the time you'll need the same linespace, which is then globally defined. Apart from that, I think this could be merged in soon. Jürgen
Re: booktabs
Georg Baum wrote: > Remaining tasks: Add support for interline space (half finished, see > attached) and testing. I had a quick look. It looks good. However, it should be possible to use \addlinespace (without optional argument). I guess most of the time you'll need the same linespace, which is then globally defined. Apart from that, I think this could be merged in soon. Jürgen
Re: booktabs
On Wednesday 07 June 2006 01:45, Edwin Leuven wrote: i = i + 1 For 1.5.x it is acceptable (and recommended) to use i += 1 It is easier to read and the restriction to use python 1.5.2 has been lifted. I know the code was there before but the warning remains. :-) -- José Abílio
Re: booktabs
On Wednesday 07 June 2006 01:45, Edwin Leuven wrote: > i = i + 1 For 1.5.x it is acceptable (and recommended) to use i += 1 It is easier to read and the restriction to use python 1.5.2 has been lifted. I know the code was there before but the warning remains. :-) -- José Abílio
booktabs
what ever happened to that one? georg, i guess you know? thanks, edwin
Re: booktabs
Am Montag, 5. Juni 2006 20:20 schrieb Edwin Leuven:
what ever happened to that one?
georg, i guess you know?
Yes, I do. The branch
svn://svn.lyx.org/lyx/lyx-devel/branches/BooktabBranch does still exist.
I just merged the latest changes from trunk to the branch.
Remaining tasks: Add support for interline space (half finished, see
attached) and testing.
Georg
Index: src/insets/insettabular.C
===
--- src/insets/insettabular.C (Revision 14014)
+++ src/insets/insettabular.C (Arbeitskopie)
@@ -133,6 +133,9 @@ TabularFeature tabularFeature[] =
{ LyXTabular::SET_SPECIAL_MULTI, set-special-multi },
{ LyXTabular::SET_BOOKTABS, set-booktabs },
{ LyXTabular::UNSET_BOOKTABS, unset-booktabs },
+ { LyXTabular::SET_TOP_SPACE, set-top-space },
+ { LyXTabular::SET_BOTTOM_SPACE, set-bottom-space },
+ { LyXTabular::SET_INTERLINE_SPACE, set-interline-space },
{ LyXTabular::LAST_ACTION, }
};
@@ -268,8 +271,10 @@ void InsetTabular::metrics(MetricsInfo
tabular.setWidthOfCell(cell, dim.wid);
++cell;
}
- tabular.setAscentOfRow(i, maxAsc + ADD_TO_HEIGHT);
- tabular.setDescentOfRow(i, maxDesc + ADD_TO_HEIGHT);
+ tabular.setAscentOfRow(i, maxAsc + ADD_TO_HEIGHT +
+ tabular.row_info[i].top_space.inPixels(mi.base.textwidth));
+ tabular.setDescentOfRow(i, maxDesc + ADD_TO_HEIGHT +
+ tabular.row_info[i].bottom_space.inPixels(mi.base.textwidth));
}
dim.asc = tabular.getAscentOfRow(0);
@@ -804,6 +809,9 @@ bool InsetTabular::getStatus(LCursor c
case LyXTabular::DELETE_COLUMN:
case LyXTabular::SET_ALL_LINES:
case LyXTabular::UNSET_ALL_LINES:
+ case LyXTabular::SET_TOP_SPACE:
+ case LyXTabular::SET_BOTTOM_SPACE:
+ case LyXTabular::SET_INTERLINE_SPACE:
status.clear();
return true;
@@ -1131,11 +1139,10 @@ int InsetTabular::dist(idx_type const ce
Point o = theCoords.getInsets().xy(inset);
int const xbeg = o.x_ - tabular.getBeginningOfTextInCell(cell);
int const xend = xbeg + tabular.getWidthOfColumn(cell);
- int const ybeg = o.y_ - inset.ascent();
row_type const row = tabular.row_of_cell(cell);
- int const rowheight = tabular.getAscentOfRow(row)
- + tabular.getDescentOfRow(row);
- int const yend = ybeg + rowheight;
+ int const ybeg = o.y_ - tabular.getAscentOfRow(row) -
+ tabular.getAdditionalHeight(row);
+ int const yend = o.y_ + tabular.getDescentOfRow(row);
if (x xbeg)
xx = xbeg - x;
@@ -1646,6 +1653,33 @@ void InsetTabular::tabularFeatures(LCurs
tabular.setBookTabs(false);
break;
+ case LyXTabular::SET_TOP_SPACE: {
+ LyXLength len;
+ if (isValidLength(value, len)) {
+ for (row_type i = sel_row_start; i = sel_row_end; ++i)
+tabular.row_info[i].top_space = len;
+ }
+ break;
+ }
+
+ case LyXTabular::SET_BOTTOM_SPACE: {
+ LyXLength len;
+ if (isValidLength(value, len)) {
+ for (row_type i = sel_row_start; i = sel_row_end; ++i)
+tabular.row_info[i].bottom_space = len;
+ }
+ break;
+ }
+
+ case LyXTabular::SET_INTERLINE_SPACE: {
+ LyXLength len;
+ if (isValidLength(value, len)) {
+ for (row_type i = sel_row_start; i = sel_row_end; ++i)
+tabular.row_info[i].interline_space = len;
+ }
+ break;
+ }
+
// dummy stuff just to avoid warnings
case LyXTabular::LAST_ACTION:
break;
Index: src/frontends/qt3/QTabularDialog.C
===
--- src/frontends/qt3/QTabularDialog.C (Revision 14014)
+++ src/frontends/qt3/QTabularDialog.C (Arbeitskopie)
@@ -37,6 +37,9 @@ QTabularDialog::QTabularDialog(QTabular
form, SLOT(slotClose()));
widthED-setValidator(unsignedLengthValidator(widthED));
+ topspaceED-setValidator(new LengthValidator(topspaceED));
+ bottomspaceED-setValidator(new LengthValidator(bottomspaceED));
+ interlinespaceED-setValidator(new LengthValidator(interlinespaceED));
}
@@ -119,6 +122,30 @@ void QTabularDialog::width_changed()
}
+void QTabularDialog::topspace_changed()
+{
+ form_-changed();
+ string const topspace = widgetsToLength(topspaceED, topspaceUnit);
+ form_-controller().set(LyXTabular::SET_TOP_SPACE, topspace);
+}
+
+
+void QTabularDialog::bottomspace_changed()
+{
+ form_-changed();
+ string const bottomspace = widgetsToLength(bottomspaceED, bottomspaceUnit);
+ form_-controller().set(LyXTabular::SET_BOTTOM_SPACE, bottomspace);
+}
+
+
+void QTabularDialog::interlinespace_changed()
+{
+ form_-changed();
+ string const interlinespace = widgetsToLength(interlinespaceED, interlinespaceUnit);
+ form_-controller().set(LyXTabular::SET_INTERLINE_SPACE, interlinespace);
+}
+
+
void QTabularDialog::multicolumn_clicked()
{
form_-controller().toggleMultiColumn();
Index: src/frontends/qt3/ui/QTabularDialogBase.ui
===
--- src/frontends/qt3/ui/QTabularDialogBase.ui (Revision 14014)
+++ src/frontends/qt3/ui/QTabularDialogBase.ui (Arbeitskopie)
@@ -306,6 +306,187 @@
/widget
booktabs
what ever happened to that one? georg, i guess you know? thanks, edwin
Re: booktabs
Am Montag, 5. Juni 2006 20:20 schrieb Edwin Leuven:
> what ever happened to that one?
>
> georg, i guess you know?
Yes, I do. The branch
svn://svn.lyx.org/lyx/lyx-devel/branches/BooktabBranch does still exist.
I just merged the latest changes from trunk to the branch.
Remaining tasks: Add support for interline space (half finished, see
attached) and testing.
Georg
Index: src/insets/insettabular.C
===
--- src/insets/insettabular.C (Revision 14014)
+++ src/insets/insettabular.C (Arbeitskopie)
@@ -133,6 +133,9 @@ TabularFeature tabularFeature[] =
{ LyXTabular::SET_SPECIAL_MULTI, "set-special-multi" },
{ LyXTabular::SET_BOOKTABS, "set-booktabs" },
{ LyXTabular::UNSET_BOOKTABS, "unset-booktabs" },
+ { LyXTabular::SET_TOP_SPACE, "set-top-space" },
+ { LyXTabular::SET_BOTTOM_SPACE, "set-bottom-space" },
+ { LyXTabular::SET_INTERLINE_SPACE, "set-interline-space" },
{ LyXTabular::LAST_ACTION, "" }
};
@@ -268,8 +271,10 @@ void InsetTabular::metrics(MetricsInfo &
tabular.setWidthOfCell(cell, dim.wid);
++cell;
}
- tabular.setAscentOfRow(i, maxAsc + ADD_TO_HEIGHT);
- tabular.setDescentOfRow(i, maxDesc + ADD_TO_HEIGHT);
+ tabular.setAscentOfRow(i, maxAsc + ADD_TO_HEIGHT +
+ tabular.row_info[i].top_space.inPixels(mi.base.textwidth));
+ tabular.setDescentOfRow(i, maxDesc + ADD_TO_HEIGHT +
+ tabular.row_info[i].bottom_space.inPixels(mi.base.textwidth));
}
dim.asc = tabular.getAscentOfRow(0);
@@ -804,6 +809,9 @@ bool InsetTabular::getStatus(LCursor & c
case LyXTabular::DELETE_COLUMN:
case LyXTabular::SET_ALL_LINES:
case LyXTabular::UNSET_ALL_LINES:
+ case LyXTabular::SET_TOP_SPACE:
+ case LyXTabular::SET_BOTTOM_SPACE:
+ case LyXTabular::SET_INTERLINE_SPACE:
status.clear();
return true;
@@ -1131,11 +1139,10 @@ int InsetTabular::dist(idx_type const ce
Point o = theCoords.getInsets().xy();
int const xbeg = o.x_ - tabular.getBeginningOfTextInCell(cell);
int const xend = xbeg + tabular.getWidthOfColumn(cell);
- int const ybeg = o.y_ - inset.ascent();
row_type const row = tabular.row_of_cell(cell);
- int const rowheight = tabular.getAscentOfRow(row)
- + tabular.getDescentOfRow(row);
- int const yend = ybeg + rowheight;
+ int const ybeg = o.y_ - tabular.getAscentOfRow(row) -
+ tabular.getAdditionalHeight(row);
+ int const yend = o.y_ + tabular.getDescentOfRow(row);
if (x < xbeg)
xx = xbeg - x;
@@ -1646,6 +1653,33 @@ void InsetTabular::tabularFeatures(LCurs
tabular.setBookTabs(false);
break;
+ case LyXTabular::SET_TOP_SPACE: {
+ LyXLength len;
+ if (isValidLength(value, )) {
+ for (row_type i = sel_row_start; i <= sel_row_end; ++i)
+tabular.row_info[i].top_space = len;
+ }
+ break;
+ }
+
+ case LyXTabular::SET_BOTTOM_SPACE: {
+ LyXLength len;
+ if (isValidLength(value, )) {
+ for (row_type i = sel_row_start; i <= sel_row_end; ++i)
+tabular.row_info[i].bottom_space = len;
+ }
+ break;
+ }
+
+ case LyXTabular::SET_INTERLINE_SPACE: {
+ LyXLength len;
+ if (isValidLength(value, )) {
+ for (row_type i = sel_row_start; i <= sel_row_end; ++i)
+tabular.row_info[i].interline_space = len;
+ }
+ break;
+ }
+
// dummy stuff just to avoid warnings
case LyXTabular::LAST_ACTION:
break;
Index: src/frontends/qt3/QTabularDialog.C
===
--- src/frontends/qt3/QTabularDialog.C (Revision 14014)
+++ src/frontends/qt3/QTabularDialog.C (Arbeitskopie)
@@ -37,6 +37,9 @@ QTabularDialog::QTabularDialog(QTabular
form, SLOT(slotClose()));
widthED->setValidator(unsignedLengthValidator(widthED));
+ topspaceED->setValidator(new LengthValidator(topspaceED));
+ bottomspaceED->setValidator(new LengthValidator(bottomspaceED));
+ interlinespaceED->setValidator(new LengthValidator(interlinespaceED));
}
@@ -119,6 +122,30 @@ void QTabularDialog::width_changed()
}
+void QTabularDialog::topspace_changed()
+{
+ form_->changed();
+ string const topspace = widgetsToLength(topspaceED, topspaceUnit);
+ form_->controller().set(LyXTabular::SET_TOP_SPACE, topspace);
+}
+
+
+void QTabularDialog::bottomspace_changed()
+{
+ form_->changed();
+ string const bottomspace = widgetsToLength(bottomspaceED, bottomspaceUnit);
+ form_->controller().set(LyXTabular::SET_BOTTOM_SPACE, bottomspace);
+}
+
+
+void QTabularDialog::interlinespace_changed()
+{
+ form_->changed();
+ string const interlinespace = widgetsToLength(interlinespaceED, interlinespaceUnit);
+ form_->controller().set(LyXTabular::SET_INTERLINE_SPACE, interlinespace);
+}
+
+
void QTabularDialog::multicolumn_clicked()
{
form_->controller().toggleMultiColumn();
Index: src/frontends/qt3/ui/QTabularDialogBase.ui
===
--- src/fron
Booktabs branch
I have updated the booktabs branch to current trunk. It works for me, and I will try to finish it so that it can be merged back in the not so far future, but of course bug fixing for 1.4.1 has higher priority for some time. Georg
Booktabs branch
I have updated the booktabs branch to current trunk. It works for me, and I will try to finish it so that it can be merged back in the not so far future, but of course bug fixing for 1.4.1 has higher priority for some time. Georg
Re: booktabs
On Fri, Dec 03, 2004 at 06:00:38PM -0500, candide wrote: No, the only three real problems with branches are: - Unfamiliarity with them, possibly combined with fear of them. I have worked with them although I am afraid of them. I was no happy and I don't see the benefits outweighting the costs. - Laziness and/or sloppiness. Sure, but these a two of the virtues of a good programmer. Only lazy people think hard about modularization and code reuse because they are afraid of doiung the same work twice. - Active development on the same piece of code at the same time by 2 or more people. Unfortuanately that's the situation we have. You can mitigate the latter by: a) Becoming Main Owner and Proprietor of the branch. And what good does that? There are still four or five people touching the same code at the same time. Look at what happened to the tabular code during the last four weeks. priv_dispatch, coords, lyx2lyx, indices, regression fixing. All in one file. b) Applying patches when Lars does. Huh? (Only needed for patches affecting code you're working on. Otherwise, just Merge Early and Often.) Lars's patches tend to touch lots of files, so you most certainly get lots of conflicts if you are not close to HEAD and have similar patches in the queue. And while you may fall into the first category, I doubt you, a core LyX Developer, fall into the second! :) Huh again. I don't see the point. Andre'
Re: booktabs
Andre Poenitz [EMAIL PROTECTED] writes: (Only needed for patches affecting code you're working on. Otherwise, just Merge Early and Often.) | Lars's patches tend to touch lots of files, so you most certainly get | lots of conflicts if you are not close to HEAD and have similar patches | in the queue. Nobody should have similar patches to me :-) And if you are on a branch you should update whenever head touches your part of the code. -- Lgb
Re: booktabs
On Fri, Dec 03, 2004 at 06:00:38PM -0500, candide wrote: > No, the only three real problems with branches are: > > - Unfamiliarity with them, possibly combined with fear of them. I have worked with them although I am afraid of them. I was no happy and I don't see the benefits outweighting the costs. > - Laziness and/or sloppiness. Sure, but these a two of the virtues of a good programmer. Only lazy people think hard about modularization and code reuse because they are afraid of doiung the same work twice. > - Active development on the same piece of code at the same time by 2 > or more people. Unfortuanately that's the situation we have. > You can mitigate the latter by: > > a) Becoming Main Owner and Proprietor of the branch. And what good does that? There are still four or five people touching the same code at the same time. Look at what happened to the tabular code during the last four weeks. priv_dispatch, coords, lyx2lyx, indices, regression fixing. All in one file. > b) Applying patches when Lars does. Huh? >(Only needed for patches affecting code you're working on. > Otherwise, just Merge Early and Often.) Lars's patches tend to touch lots of files, so you most certainly get lots of conflicts if you are not close to HEAD and have similar patches in the queue. > And while you may fall into the first category, I doubt you, a core > LyX Developer, fall into the second! :) Huh again. I don't see the point. Andre'
Re: booktabs
Andre Poenitz <[EMAIL PROTECTED]> writes: >>(Only needed for patches affecting code you're working on. >> Otherwise, just Merge Early and Often.) > | Lars's patches tend to touch lots of files, so you most certainly get | lots of conflicts if you are not close to HEAD and have similar patches | in the queue. Nobody should have similar patches to me :-) And if you are on a branch you should update whenever head touches "your" part of the code. -- Lgb
Re: booktabs
On Sun, Nov 07, 2004 at 08:57:10PM +0100, Andre Poenitz wrote: Working with branches is a pain, frustrates people and eats into already scarce resources. Balderdash, I say! I've worked with code on 3 different branches, simultaneously. The only problem I encountered was remembering which branch's working directory I was in when rapidly hopping from one to the other. Nor is merging a branch and the trunk all that difficult, if you Update Early and Often. Or in this case, Merge Early and Often. No, the only three real problems with branches are: - Unfamiliarity with them, possibly combined with fear of them. - Laziness and/or sloppiness. - Active development on the same piece of code at the same time by 2 or more people. You can mitigate the latter by: a) Becoming Main Owner and Proprietor of the branch. b) Applying patches when Lars does. (Only needed for patches affecting code you're working on. Otherwise, just Merge Early and Often.) And while you may fall into the first category, I doubt you, a core LyX Developer, fall into the second! :)
Re: booktabs
On Sun, Nov 07, 2004 at 08:57:10PM +0100, Andre Poenitz wrote: > Working with branches is a pain, frustrates people and eats into already > scarce resources. Balderdash, I say! I've worked with code on 3 different branches, simultaneously. The only problem I encountered was remembering which branch's working directory I was in when rapidly hopping from one to the other. Nor is merging a branch and the trunk all that difficult, if you Update Early and Often. Or in this case, Merge Early and Often. No, the only three real problems with branches are: - Unfamiliarity with them, possibly combined with fear of them. - Laziness and/or sloppiness. - Active development on the same piece of code at the same time by 2 or more people. You can mitigate the latter by: a) Becoming Main Owner and Proprietor of the branch. b) Applying patches when Lars does. (Only needed for patches affecting code you're working on. Otherwise, just Merge Early and Often.) And while you may fall into the first category, I doubt you, a core LyX Developer, fall into the second! :)
Re: booktabs branch
Georg Baum wrote: 1. Disable changing of vertical rules in the frontends if booktabs are enabled. The output of vertical rules is already suppressed. The attached patch implements this. Looks good. Jürgen P.S.: I have tried the booktabs branch yesterday. Looks very good so far. Then I noticed how bad the shape of the tabular code is ATM. Multicolumn is disabled; rotate_cell does not work; UNSET_ALL_LINES is disabled; getActiveCell always return 0 etc. I guess we will have some work with this. I will have to do some real work for the next week. Then I'll come back to this issue. My ideas apart from what you have planned: - try to find a better dialog structure. Maybe a tabular tab and a cell/column/row (better name?) tab, if possible. - I wonder if we should disallow double rules. LyX sets them by default (in the headline), but they do not make any sense in formal tables (and are considered bad typography IIRC).
Re: booktabs branch
Am Sonntag, 14. November 2004 11:37 schrieb Juergen Spitzmueller: P.S.: I have tried the booktabs branch yesterday. Looks very good so far. Then I noticed how bad the shape of the tabular code is ATM. Multicolumn is disabled; rotate_cell does not work; UNSET_ALL_LINES is disabled; getActiveCell always return 0 etc. I guess we will have some work with this. Yes. I noticed that, too. I will have to do some real work for the next week. Then I'll come back to this issue. My ideas apart from what you have planned: - try to find a better dialog structure. Maybe a tabular tab and a cell/column/row (better name?) tab, if possible. This would be similar to the xforms dialog. I agree that the structure needs to be improved. - I wonder if we should disallow double rules. LyX sets them by default (in the headline), but they do not make any sense in formal tables (and are considered bad typography IIRC). I am not sure. In contrast to the vertical rules that do not work with booktabs, double horizontal rules do. Georg
Re: booktabs branch
Georg Baum wrote: > > 1. Disable changing of vertical rules in the frontends if booktabs are > > enabled. The output of vertical rules is already suppressed. > > The attached patch implements this. Looks good. Jürgen P.S.: I have tried the booktabs branch yesterday. Looks very good so far. Then I noticed how bad the shape of the tabular code is ATM. Multicolumn is disabled; rotate_cell does not work; UNSET_ALL_LINES is disabled; getActiveCell always return 0 etc. I guess we will have some work with this. I will have to do some real work for the next week. Then I'll come back to this issue. My ideas apart from what you have planned: - try to find a better dialog structure. Maybe a "tabular" tab and a "cell/column/row" (better name?) tab, if possible. - I wonder if we should disallow double rules. LyX sets them by default (in the headline), but they do not make any sense in formal tables (and are considered bad typography IIRC).
Re: booktabs branch
Am Sonntag, 14. November 2004 11:37 schrieb Juergen Spitzmueller: > P.S.: I have tried the booktabs branch yesterday. Looks very good so far. Then > I noticed how bad the shape of the tabular code is ATM. Multicolumn is > disabled; rotate_cell does not work; UNSET_ALL_LINES is disabled; > getActiveCell always return 0 etc. I guess we will have some work with this. Yes. I noticed that, too. > I will have to do some real work for the next week. Then I'll come back to > this issue. > > My ideas apart from what you have planned: > > - try to find a better dialog structure. Maybe a "tabular" tab and a > "cell/column/row" (better name?) tab, if possible. This would be similar to the xforms dialog. I agree that the structure needs to be improved. > - I wonder if we should disallow double rules. LyX sets them by default (in > the headline), but they do not make any sense in formal tables (and are > considered bad typography IIRC). I am not sure. In contrast to the vertical rules that do not work with booktabs, double horizontal rules do. Georg
Re: booktabs branch
Am Donnerstag, 11. November 2004 20:09 schrieb Georg Baum:
TODO list:
1. Disable changing of vertical rules in the frontends if booktabs are
enabled. The output of vertical rules is already suppressed.
The attached patch implements this.
Georg
Index: src/frontends/qt2/QTabular.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QTabular.C,v
retrieving revision 1.31.4.1
diff -u -p -r1.31.4.1 QTabular.C
--- src/frontends/qt2/QTabular.C 11 Nov 2004 19:09:06 - 1.31.4.1
+++ src/frontends/qt2/QTabular.C 13 Nov 2004 20:45:43 -
@@ -90,10 +90,11 @@ void QTabular::update_borders()
LyXTabular const tabular = controller().tabular();
int const cell = controller().getActiveCell();
bool const isMulticolumnCell = tabular.isMultiColumn(cell);
+ bool const useBookTabs = tabular.useBookTabs();
if (!isMulticolumnCell) {
- dialog_-borders-setLeftEnabled(true);
- dialog_-borders-setRightEnabled(true);
+ dialog_-borders-setLeftEnabled(!useBookTabs);
+ dialog_-borders-setRightEnabled(!useBookTabs);
dialog_-borders-setTop(tabular.topLine(cell, true));
dialog_-borders-setBottom(tabular.bottomLine(cell, true));
dialog_-borders-setLeft(tabular.leftLine(cell, true));
@@ -105,18 +106,18 @@ void QTabular::update_borders()
dialog_-borders-setTop(tabular.topLine(cell));
dialog_-borders-setBottom(tabular.bottomLine(cell));
- // pay attention to left/right lines: they are only allowed
- // to set if we are in first/last cell of row or if the left/right
- // cell is also a multicolumn.
+ // pay attention to left/right lines: they are only allowed to set
+ // if we don't use booktabs and if we are in first/last cell of row
+ // or if the left/right cell is also a multicolumn.
if (tabular.isFirstCellInRow(cell) || tabular.isMultiColumn(cell - 1)) {
- dialog_-borders-setLeftEnabled(true);
+ dialog_-borders-setLeftEnabled(!useBookTabs);
dialog_-borders-setLeft(tabular.leftLine(cell));
} else {
dialog_-borders-setLeft(false);
dialog_-borders-setLeftEnabled(false);
}
if (tabular.isLastCellInRow(cell) || tabular.isMultiColumn(cell + 1)) {
- dialog_-borders-setRightEnabled(true);
+ dialog_-borders-setRightEnabled(!useBookTabs);
dialog_-borders-setRight(tabular.rightLine(cell));
} else {
dialog_-borders-setRight(false);
Index: src/frontends/qt2/QTabularDialog.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QTabularDialog.C,v
retrieving revision 1.24.4.1
diff -u -p -r1.24.4.1 QTabularDialog.C
--- src/frontends/qt2/QTabularDialog.C 11 Nov 2004 19:09:06 - 1.24.4.1
+++ src/frontends/qt2/QTabularDialog.C 13 Nov 2004 20:45:43 -
@@ -352,6 +352,8 @@ void QTabularDialog::booktabs_clicked()
form_-controller().set(LyXTabular::SET_BOOKTABS);
else
form_-controller().set(LyXTabular::UNSET_BOOKTABS);
+ form_-update_borders();
+ form_-changed();
}
} // namespace frontend
Index: src/frontends/xforms/FormTabular.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/FormTabular.C,v
retrieving revision 1.83.4.1
diff -u -p -r1.83.4.1 FormTabular.C
--- src/frontends/xforms/FormTabular.C 11 Nov 2004 19:09:07 - 1.83.4.1
+++ src/frontends/xforms/FormTabular.C 13 Nov 2004 20:45:46 -
@@ -180,13 +180,15 @@ void FormTabular::update()
tabular.bottomLine(cell)?1:0);
setEnabled(cell_options_-check_border_bottom, true);
// pay attention to left/right lines they are only allowed
- // to set if we are in first/last cell of row or if the left/right
- // cell is also a multicolumn.
+ // to set if we don't use booktabs and if we are in
+ // first/last cell of row or if the left/right cell is also a
+ // multicolumn.
if (tabular.isFirstCellInRow(cell) ||
tabular.isMultiColumn(cell-1)) {
fl_set_button(cell_options_-check_border_left,
tabular.leftLine(cell)?1:0);
- setEnabled(cell_options_-check_border_left, true);
+ setEnabled(cell_options_-check_border_left,
+ !tabular.useBookTabs());
} else {
fl_set_button(cell_options_-check_border_left, 0);
setEnabled(cell_options_-check_border_left, false);
@@ -195,7 +197,8 @@ void FormTabular::update()
tabular.isMultiColumn(cell+1)) {
fl_set_button(cell_options_-check_border_right,
tabular.rightLine(cell)?1:0);
- setEnabled(cell_options_-check_border_right, true);
+ setEnabled(cell_options_-check_border_right,
+ !tabular.useBookTabs());
} else {
fl_set_button(cell_options_-check_border_right, 0);
setEnabled(cell_options_-check_border_right, false);
Re: booktabs branch
Am Donnerstag, 11. November 2004 20:09 schrieb Georg Baum:
> TODO list:
>
> 1. Disable changing of vertical rules in the frontends if booktabs are
> enabled. The output of vertical rules is already suppressed.
The attached patch implements this.
Georg
Index: src/frontends/qt2/QTabular.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QTabular.C,v
retrieving revision 1.31.4.1
diff -u -p -r1.31.4.1 QTabular.C
--- src/frontends/qt2/QTabular.C 11 Nov 2004 19:09:06 - 1.31.4.1
+++ src/frontends/qt2/QTabular.C 13 Nov 2004 20:45:43 -
@@ -90,10 +90,11 @@ void QTabular::update_borders()
LyXTabular const & tabular = controller().tabular();
int const cell = controller().getActiveCell();
bool const isMulticolumnCell = tabular.isMultiColumn(cell);
+ bool const useBookTabs = tabular.useBookTabs();
if (!isMulticolumnCell) {
- dialog_->borders->setLeftEnabled(true);
- dialog_->borders->setRightEnabled(true);
+ dialog_->borders->setLeftEnabled(!useBookTabs);
+ dialog_->borders->setRightEnabled(!useBookTabs);
dialog_->borders->setTop(tabular.topLine(cell, true));
dialog_->borders->setBottom(tabular.bottomLine(cell, true));
dialog_->borders->setLeft(tabular.leftLine(cell, true));
@@ -105,18 +106,18 @@ void QTabular::update_borders()
dialog_->borders->setTop(tabular.topLine(cell));
dialog_->borders->setBottom(tabular.bottomLine(cell));
- // pay attention to left/right lines: they are only allowed
- // to set if we are in first/last cell of row or if the left/right
- // cell is also a multicolumn.
+ // pay attention to left/right lines: they are only allowed to set
+ // if we don't use booktabs and if we are in first/last cell of row
+ // or if the left/right cell is also a multicolumn.
if (tabular.isFirstCellInRow(cell) || tabular.isMultiColumn(cell - 1)) {
- dialog_->borders->setLeftEnabled(true);
+ dialog_->borders->setLeftEnabled(!useBookTabs);
dialog_->borders->setLeft(tabular.leftLine(cell));
} else {
dialog_->borders->setLeft(false);
dialog_->borders->setLeftEnabled(false);
}
if (tabular.isLastCellInRow(cell) || tabular.isMultiColumn(cell + 1)) {
- dialog_->borders->setRightEnabled(true);
+ dialog_->borders->setRightEnabled(!useBookTabs);
dialog_->borders->setRight(tabular.rightLine(cell));
} else {
dialog_->borders->setRight(false);
Index: src/frontends/qt2/QTabularDialog.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QTabularDialog.C,v
retrieving revision 1.24.4.1
diff -u -p -r1.24.4.1 QTabularDialog.C
--- src/frontends/qt2/QTabularDialog.C 11 Nov 2004 19:09:06 - 1.24.4.1
+++ src/frontends/qt2/QTabularDialog.C 13 Nov 2004 20:45:43 -
@@ -352,6 +352,8 @@ void QTabularDialog::booktabs_clicked()
form_->controller().set(LyXTabular::SET_BOOKTABS);
else
form_->controller().set(LyXTabular::UNSET_BOOKTABS);
+ form_->update_borders();
+ form_->changed();
}
} // namespace frontend
Index: src/frontends/xforms/FormTabular.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/FormTabular.C,v
retrieving revision 1.83.4.1
diff -u -p -r1.83.4.1 FormTabular.C
--- src/frontends/xforms/FormTabular.C 11 Nov 2004 19:09:07 - 1.83.4.1
+++ src/frontends/xforms/FormTabular.C 13 Nov 2004 20:45:46 -
@@ -180,13 +180,15 @@ void FormTabular::update()
tabular.bottomLine(cell)?1:0);
setEnabled(cell_options_->check_border_bottom, true);
// pay attention to left/right lines they are only allowed
- // to set if we are in first/last cell of row or if the left/right
- // cell is also a multicolumn.
+ // to set if we don't use booktabs and if we are in
+ // first/last cell of row or if the left/right cell is also a
+ // multicolumn.
if (tabular.isFirstCellInRow(cell) ||
tabular.isMultiColumn(cell-1)) {
fl_set_button(cell_options_->check_border_left,
tabular.leftLine(cell)?1:0);
- setEnabled(cell_options_->check_border_left, true);
+ setEnabled(cell_options_->check_border_left,
+ !tabular.useBookTabs());
} else {
fl_set_button(cell_options_->check_border_left, 0);
setEnabled(cell_options_->check_border_left, false);
@@ -195,7 +197,8 @@ void FormTabular::update()
tabular.isMultiColumn(cell+1)) {
fl_set_button(cell_options_->check_border_right,
tabular.rightLine(cell)?1:0);
- setEnabled(cell_options_->check_border_right, true);
+ setEnabled(cell_options_->check_border_right,
+ !tabular.useBookTabs());
} else {
fl_set_button(cell_options_->check_border_right, 0);
setEnabled(cell_options_->check_border_right, false);
booktabs branch
Jürgen,
I have created the branch for the booktabs support. The current diff against
HEAD is attached.
You can update an existing tree with
cvs update -P -r BooktabBranch
TODO list:
1. Disable changing of vertical rules in the frontends if booktabs are
enabled. The output of vertical rules is already suppressed.
2. add GUI for \addlinespace
3. maybe add \morecmidrules somewhere (don't know if this is necessary)
4. documentation
5. testing of course
6. convince Lars to merge it back to HEAD :-)
I will probably look after 1. and 3, but not too soon.
Georg? build-tree
? conf
? x.diff
Index: lib/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/ChangeLog,v
retrieving revision 1.651
diff -u -p -r1.651 ChangeLog
--- lib/ChangeLog 5 Nov 2004 13:28:01 - 1.651
+++ lib/ChangeLog 11 Nov 2004 18:55:12 -
@@ -1,3 +1,7 @@
+2004-11-11 Georg Baum [EMAIL PROTECTED]
+
+ * chkconfig.ltx: check package booktabs
+
2004-11-05 Bennett Helm [EMAIL PROTECTED]
* bind/mac.bind: use cmd-Tab and cmd-backtab as shortcuts for
Index: lib/chkconfig.ltx
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/chkconfig.ltx,v
retrieving revision 1.14
diff -u -p -r1.14 chkconfig.ltx
--- lib/chkconfig.ltx 14 Sep 2004 10:20:37 - 1.14
+++ lib/chkconfig.ltx 11 Nov 2004 18:55:12 -
@@ -200,6 +200,7 @@
\TestPackage{a4wide}
\TestPackage{array}
\TestPackage{babel}
+\TestPackage{booktabs}
\TestPackage{color} % this one should be there if graphics.sty is there.
\TestPackage{fancyhdr}
\TestPackage{floatflt}
Index: lib/doc/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/doc/ChangeLog,v
retrieving revision 1.15
diff -u -p -r1.15 ChangeLog
--- lib/doc/ChangeLog 4 Nov 2004 15:42:38 - 1.15
+++ lib/doc/ChangeLog 11 Nov 2004 18:55:12 -
@@ -1,3 +1,7 @@
+2004-11-11 Georg Baum [EMAIL PROTECTED]
+
+ * LaTeXConfig.lyx.in, LyXConfig.lyx.in: add booktabs package
+
2004-11-04 Christian Ridderström [EMAIL PROTECTED]
* LaTeXConfig.lyx.in: remove supported and other from CTAN
Index: lib/doc/LaTeXConfig.lyx.in
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/doc/LaTeXConfig.lyx.in,v
retrieving revision 1.40
diff -u -p -r1.40 LaTeXConfig.lyx.in
--- lib/doc/LaTeXConfig.lyx.in 4 Nov 2004 15:42:38 - 1.40
+++ lib/doc/LaTeXConfig.lyx.in 11 Nov 2004 18:55:13 -
@@ -2107,6 +2107,32 @@ Table of contents
\begin_layout Subsection
+booktabs
+\end_layout
+
+\begin_layout Description
+
+Found: @chk_booktabs@
+\end_layout
+
+\begin_layout Description
+
+CTAN:
+\family typewriter
+macros/latex/contrib/booktabs/
+\end_layout
+
+\begin_layout Description
+
+Notes: The package
+\family sans
+booktabs
+\family default
+ is needed by LyX to be able to output correctly formal tables.
+\end_layout
+
+\begin_layout Subsection
+
color
\end_layout
Index: lib/doc/LyXConfig.lyx.in
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/doc/LyXConfig.lyx.in,v
retrieving revision 1.4
diff -u -p -r1.4 LyXConfig.lyx.in
--- lib/doc/LyXConfig.lyx.in 17 Jan 2003 13:50:10 - 1.4
+++ lib/doc/LyXConfig.lyx.in 11 Nov 2004 18:55:13 -
@@ -1135,6 +1135,24 @@ Table of contents
if you want to use non-English quotes.
\layout Subsection
+booktabs
+\layout Description
+
+Found: @chk_booktabs@
+\layout Description
+
+CTAN:
+\family typewriter
+macros/latex/contrib/booktabs/
+\layout Description
+
+Notes: The package
+\family sans
+booktabs
+\family default
+ is needed by LyX to be able to output correctly formal tables.
+\layout Subsection
+
color
\layout Description
Index: lib/lyx2lyx/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/lyx2lyx/ChangeLog,v
retrieving revision 1.49
diff -u -p -r1.49 ChangeLog
--- lib/lyx2lyx/ChangeLog 28 Oct 2004 11:21:26 - 1.49
+++ lib/lyx2lyx/ChangeLog 11 Nov 2004 18:55:14 -
@@ -1,3 +1,8 @@
+2004-11-11 Georg Baum [EMAIL PROTECTED]
+
+ * lyx_1_4.py, LyX.py: handle new format 238
+ * lyx_1_4.py (revert_booktabs): new
+
2004-10-28 José Matos [EMAIL PROTECTED]
* LyX.pm: add internal documentation.
Index: lib/lyx2lyx/LyX.py
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/lyx2lyx/LyX.py,v
retrieving revision 1.5
diff -u -p -r1.5 LyX.py
--- lib/lyx2lyx/LyX.py 28 Oct 2004 11:21:27 - 1.5
+++ lib/lyx2lyx/LyX.py 11 Nov 2004 18:55:14 -
@@ -44,7 +44,7 @@ format_relation = [(0_10, [210], [0.
(1_1_6fix3, [218], [1.1.6fix3,1.1.6fix4,1.1]),
(1_2, [220], [1.2.0,1.2.1,1.2.3,1.2.4,1.2]),
(1_3, [221], [1.3.0,1.3.1,1.3.2,1.3.3,1.3.4,1.3.5,1.3
Re: booktabs branch
Georg Baum wrote: I have created the branch for the booktabs support. The current diff against HEAD is attached. Cool. I'm already updating. TODO list: 1. Disable changing of vertical rules in the frontends if booktabs are enabled. The output of vertical rules is already suppressed. 2. add GUI for \addlinespace 3. maybe add \morecmidrules somewhere (don't know if this is necessary) 4. documentation 5. testing of course 6. convince Lars to merge it back to HEAD :-) I will probably look after 1. and 3, but not too soon. I'll try things out and then look after 2 at first. Regards, Jürgen
booktabs branch
Jürgen,
I have created the branch for the booktabs support. The current diff against
HEAD is attached.
You can update an existing tree with
cvs update -P -r BooktabBranch
TODO list:
1. Disable changing of vertical rules in the frontends if booktabs are
enabled. The output of vertical rules is already suppressed.
2. add GUI for \addlinespace
3. maybe add \morecmidrules somewhere (don't know if this is necessary)
4. documentation
5. testing of course
6. convince Lars to merge it back to HEAD :-)
I will probably look after 1. and 3, but not too soon.
Georg? build-tree
? conf
? x.diff
Index: lib/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/ChangeLog,v
retrieving revision 1.651
diff -u -p -r1.651 ChangeLog
--- lib/ChangeLog 5 Nov 2004 13:28:01 - 1.651
+++ lib/ChangeLog 11 Nov 2004 18:55:12 -
@@ -1,3 +1,7 @@
+2004-11-11 Georg Baum <[EMAIL PROTECTED]>
+
+ * chkconfig.ltx: check package booktabs
+
2004-11-05 Bennett Helm <[EMAIL PROTECTED]>
* bind/mac.bind: use -Tab and -backtab as shortcuts for
Index: lib/chkconfig.ltx
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/chkconfig.ltx,v
retrieving revision 1.14
diff -u -p -r1.14 chkconfig.ltx
--- lib/chkconfig.ltx 14 Sep 2004 10:20:37 - 1.14
+++ lib/chkconfig.ltx 11 Nov 2004 18:55:12 -
@@ -200,6 +200,7 @@
\TestPackage{a4wide}
\TestPackage{array}
\TestPackage{babel}
+\TestPackage{booktabs}
\TestPackage{color} % this one should be there if graphics.sty is there.
\TestPackage{fancyhdr}
\TestPackage{floatflt}
Index: lib/doc/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/doc/ChangeLog,v
retrieving revision 1.15
diff -u -p -r1.15 ChangeLog
--- lib/doc/ChangeLog 4 Nov 2004 15:42:38 - 1.15
+++ lib/doc/ChangeLog 11 Nov 2004 18:55:12 -
@@ -1,3 +1,7 @@
+2004-11-11 Georg Baum <[EMAIL PROTECTED]>
+
+ * LaTeXConfig.lyx.in, LyXConfig.lyx.in: add booktabs package
+
2004-11-04 Christian Ridderström <[EMAIL PROTECTED]>
* LaTeXConfig.lyx.in: remove "supported" and "other" from CTAN
Index: lib/doc/LaTeXConfig.lyx.in
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/doc/LaTeXConfig.lyx.in,v
retrieving revision 1.40
diff -u -p -r1.40 LaTeXConfig.lyx.in
--- lib/doc/LaTeXConfig.lyx.in 4 Nov 2004 15:42:38 - 1.40
+++ lib/doc/LaTeXConfig.lyx.in 11 Nov 2004 18:55:13 -
@@ -2107,6 +2107,32 @@ Table of contents
\begin_layout Subsection
+booktabs
+\end_layout
+
+\begin_layout Description
+
+Found: @chk_booktabs@
+\end_layout
+
+\begin_layout Description
+
+CTAN:
+\family typewriter
+macros/latex/contrib/booktabs/
+\end_layout
+
+\begin_layout Description
+
+Notes: The package
+\family sans
+booktabs
+\family default
+ is needed by LyX to be able to output correctly formal tables.
+\end_layout
+
+\begin_layout Subsection
+
color
\end_layout
Index: lib/doc/LyXConfig.lyx.in
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/doc/LyXConfig.lyx.in,v
retrieving revision 1.4
diff -u -p -r1.4 LyXConfig.lyx.in
--- lib/doc/LyXConfig.lyx.in 17 Jan 2003 13:50:10 - 1.4
+++ lib/doc/LyXConfig.lyx.in 11 Nov 2004 18:55:13 -
@@ -1135,6 +1135,24 @@ Table of contents
if you want to use non-English quotes.
\layout Subsection
+booktabs
+\layout Description
+
+Found: @chk_booktabs@
+\layout Description
+
+CTAN:
+\family typewriter
+macros/latex/contrib/booktabs/
+\layout Description
+
+Notes: The package
+\family sans
+booktabs
+\family default
+ is needed by LyX to be able to output correctly formal tables.
+\layout Subsection
+
color
\layout Description
Index: lib/lyx2lyx/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/lyx2lyx/ChangeLog,v
retrieving revision 1.49
diff -u -p -r1.49 ChangeLog
--- lib/lyx2lyx/ChangeLog 28 Oct 2004 11:21:26 - 1.49
+++ lib/lyx2lyx/ChangeLog 11 Nov 2004 18:55:14 -
@@ -1,3 +1,8 @@
+2004-11-11 Georg Baum <[EMAIL PROTECTED]>
+
+ * lyx_1_4.py, LyX.py: handle new format 238
+ * lyx_1_4.py (revert_booktabs): new
+
2004-10-28 José Matos <[EMAIL PROTECTED]>
* LyX.pm: add internal documentation.
Index: lib/lyx2lyx/LyX.py
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/lyx2lyx/LyX.py,v
retrieving revision 1.5
diff -u -p -r1.5 LyX.py
--- lib/lyx2lyx/LyX.py 28 Oct 2004 11:21:27 - 1.5
+++ lib/lyx2lyx/LyX.py 11 Nov 2004 18:55:14 -
@@ -44,7 +44,7 @@ format_relation = [("0_10", [210], ["0.
("1_1_6fix3", [218], ["1.1.6fix3","1.1.6fix4","1.1"]),
Re: booktabs branch
Georg Baum wrote: > I have created the branch for the booktabs support. The current diff > against HEAD is attached. Cool. I'm already updating. > TODO list: > > 1. Disable changing of vertical rules in the frontends if booktabs are > enabled. The output of vertical rules is already suppressed. > 2. add GUI for \addlinespace > 3. maybe add \morecmidrules somewhere (don't know if this is necessary) > 4. documentation > 5. testing of course > 6. convince Lars to merge it back to HEAD :-) > > I will probably look after 1. and 3, but not too soon. I'll try things out and then look after 2 at first. Regards, Jürgen
Re: booktabs
Lars Gullik Bjønnes wrote: | As it stands now I will not do further work on the booktabs stuff. I | really don't know wether that has any influence on the number of fixed | bugs or not. That'd be a pity. I might be swayed if all three of you test and perfect this patch. Well, then let's do our best ;-) Seriously, Georg, if we had a branch, it would be much easier to improve and test in parallel (given that someone (you?) is willing to maintain the branch; i.e., if I have some proposals, I send a diff against the branch to the list, and you can commit it or just give me a go!). One major problem might be conflicts with BRANCH_ALFREDO, if Alfredo is doing some rewrite of the tabular code. Jürgen
Re: booktabs
Alfredo Braunstein wrote: I see. And what's the improvement wrt to plain LaTeX tables? The ability to put horizontal lines independently in any column? The output quality. You can kind of emulate formal tables with LaTeX's own tabular stuff, but that looks just plain ugly (to say the least). Booktabs has thick rules (for top and bottom) and thin rules (for inbetween) and other stuff that makes a table look like it should for good typography. Additional to Andreas' link, I'd like to redirect your eye to this: http://www.tug.org/tex-archive/info/german/tabsatz/tabsatz.ps It's a german tutorial, but the example tabulars speak for themselves. Jürgen
Re: booktabs
Juergen Spitzmueller wrote: I might be swayed if all three of you test and perfect this patch. Well, then let's do our best ;-) Well said. Seriously, Georg, if we had a branch, it would be much easier to improve and test in parallel (given that someone (you?) is willing to maintain the branch; i.e., if I have some proposals, I send a diff against the branch to the list, and you can commit it or just give me a go!). One major problem might be conflicts with BRANCH_ALFREDO, if Alfredo is doing some rewrite of the tabular code. I don't plan to do it (but when you're around please fix it at pleasure ;-)) so don't worry about that. Regards, Alfredo
Re: booktabs
Am Dienstag, 9. November 2004 18:28 schrieb Juergen Spitzmueller: Lars Gullik Bjønnes wrote: I might be swayed if all three of you test and perfect this patch. Well, then let's do our best ;-) Seriously, Georg, if we had a branch, it would be much easier to improve and test in parallel (given that someone (you?) is willing to maintain the branch; i.e., if I have some proposals, I send a diff against the branch to the list, and you can commit it or just give me a go!). Who am I that I can give you a go? Seriously, I think the normal rules should apply: Asking for comments, and just committing if nobody finds a problem. I think I'll be creating the branch sometimes in the next days (even if it is some work, I can probably use the gained knowledge for my own work). One major problem might be conflicts with BRANCH_ALFREDO, if Alfredo is doing some rewrite of the tabular code. I believe he wrote that he would not do that in the near future? And even if he does that: the conflicts will not be too big. Of course only if he does no rewrite _all_ ;-) Georg
Re: booktabs
Lars Gullik Bjønnes wrote: > | As it stands now I will not do further work on the booktabs stuff. I > | really don't know wether that has any influence on the number of fixed > | bugs or not. That'd be a pity. > I might be swayed if all three of you test and "perfect" this patch. Well, then let's do our best ;-) Seriously, Georg, if we had a branch, it would be much easier to improve and test in parallel (given that someone (you?) is willing to "maintain" the branch; i.e., if I have some proposals, I send a diff against the branch to the list, and you can commit it or just give me a "go!"). One major problem might be conflicts with BRANCH_ALFREDO, if Alfredo is doing some rewrite of the tabular code. Jürgen
Re: booktabs
Alfredo Braunstein wrote: > I see. And what's the improvement wrt to plain LaTeX tables? The ability > to put horizontal lines independently in any column? The output quality. You can kind of "emulate" formal tables with LaTeX's own tabular stuff, but that looks just plain ugly (to say the least). Booktabs has thick rules (for top and bottom) and thin rules (for inbetween) and other stuff that makes a table look like it should for good typography. Additional to Andreas' link, I'd like to redirect your eye to this: http://www.tug.org/tex-archive/info/german/tabsatz/tabsatz.ps It's a german tutorial, but the example tabulars speak for themselves. Jürgen
Re: booktabs
Juergen Spitzmueller wrote: >> I might be swayed if all three of you test and "perfect" this patch. > > Well, then let's do our best ;-) Well said. > Seriously, Georg, if we had a branch, it would be much easier to improve > and test in parallel (given that someone (you?) is willing to "maintain" > the branch; i.e., if I have some proposals, I send a diff against the > branch to the list, and you can commit it or just give me a "go!"). > > One major problem might be conflicts with BRANCH_ALFREDO, if Alfredo is > doing some rewrite of the tabular code. I don't plan to do it (but when you're around please fix it at pleasure ;-)) so don't worry about that. Regards, Alfredo
Re: booktabs
Am Dienstag, 9. November 2004 18:28 schrieb Juergen Spitzmueller: > Lars Gullik Bjønnes wrote: > > I might be swayed if all three of you test and "perfect" this patch. > > Well, then let's do our best ;-) > Seriously, Georg, if we had a branch, it would be much easier to improve and > test in parallel (given that someone (you?) is willing to "maintain" the > branch; i.e., if I have some proposals, I send a diff against the branch to > the list, and you can commit it or just give me a "go!"). Who am I that I can give you a "go"? Seriously, I think the normal rules should apply: Asking for comments, and just committing if nobody finds a problem. I think I'll be creating the branch sometimes in the next days (even if it is some work, I can probably use the gained knowledge for my own work). > One major problem might be conflicts with BRANCH_ALFREDO, if Alfredo is > doing some rewrite of the tabular code. I believe he wrote that he would not do that in the near future? And even if he does that: the conflicts will not be too big. Of course only if he does no rewrite _all_ ;-) Georg
Re: booktabs
Juergen Spitzmueller wrote: As to me: don't hold your breath (but at least I fixed two critical bugs in the last week, and that's surprising enough for a human scientist) ;-) I know. That's more than most of us go human sciences! Alfredo
Re: booktabs
On Sun, Nov 07, 2004 at 08:58:55PM +, John Levon wrote: I did try not to respond to this. On Sun, Nov 07, 2004 at 08:57:10PM +0100, Andre Poenitz wrote: I'd rather officially lift the freeze for a short while and let everybody work on his pet project in this time. This also includes XML support as this is a thing of fairly high 'public interest' which also happens to be comparatively independent of the current core problems. A decision was already made once that has screwed up LyX 1.4, please don't do it again... When, please? LyX core was not in good shape since the revamp of the update() stuff - pretty early in the 1.4 cycle. And this was dearly needed, as it was impossible to fix serious bugs in the core anymore. Ever tried to add real 'undo' for math? I mean that kind of undo that does not place the cursor outside the inset? The idea that in freeze time everybody starts fixing bugs might be nice in theory but seemingly does not work too well in reality. And this time is not the first time. 1.2 was no better. We could have had 1.4 out of the door by now if we'd stopped soon after Lars' STL-in-the-core changes. Then we'd have a 1.4 with the same user visible feature set as 1.3 and a 1.5cvs in the same shape as 1.4cvs right now. I don't really see the big advantage. For either developer or user. [In fact, there's one good thing about the long 1.3 area: Almost all current distros have 1.3.x in one form or another and we really do not have to care for 1.2.x anymore.] I'd really like to have a happy, busy lyx-devel list doing fancy things _including_ fixing a bug from time to time instead of a dead list with two kinds of corpses: Those that can't fix 'deep' bugs because they just started finding their ways around in LyX source, and those that theoretically could but feel defeated from several hundred open bugs and seemingly no support from anybody else. You actively chose to rip the core code to shreds in the hope somebody miight have time to rebuild it, and convinced Lars of it. I tried as hard as I could to evangelise against this for precisely these reasons, but lost the argument. You might have missed the point that I did quite a bit of rebuilding the LyX core since then. And I have certainly missed the point of your active contribution in this process. And I 'did not convince Lars of it'. I don't want to annoy you any more, so I'll leave it here, but please don't complain about situations you knowingly created. I was not asking you. Your opinion is known and noted. It is even taken into consideration even if you don't believe so. On the other hand I was thinking about adding a line like 'BTW, John, shut up.' - for good reason as I see now - to the last mail but tried to stay on the polite side. Andre'
Re: booktabs
Alfredo Braunstein wrote: Andre Poenitz wrote: That'd be good (so we could work on it together). I never created a branch myself, though. Working with branches is a pain, frustrates people and eats into already scrace resources. I never did that before. But if it is so much work, I do not want that anymore. I just did not want to pass patches around, because that can quickly become a pain, too. Note that I am in favour of the feature freeze, too, and that I do not come up with arbitrary new features, but since Edwin already did half the work and chances are really low that it breaks anything (almost everything enclosed in if (use_booktabs) and since there are at least three of us who need this I thought that it should be added. As it stands now I will not do further work on the booktabs stuff. I really don't know wether that has any influence on the number of fixed bugs or not. (cannot wait to have Juergen and Georg's skills employed in fixing core bugs ;-)) Well, if you could transfer your core knowledge magically to me, then this could happen, but otherwise I fear you have to wait a long time ;-( Georg
Re: booktabs
Georg Baum [EMAIL PROTECTED] writes: | Alfredo Braunstein wrote: Andre Poenitz wrote: That'd be good (so we could work on it together). I never created a branch myself, though. Working with branches is a pain, frustrates people and eats into already scrace resources. | I never did that before. But if it is so much work, I do not want that | anymore. I just did not want to pass patches around, because that can | quickly become a pain, too. | Note that I am in favour of the feature freeze, too, and that I do not come | up with arbitrary new features, but since Edwin already did half the work | and chances are really low that it breaks anything (almost everything | enclosed in if (use_booktabs) and since there are at least three of us | who need this I thought that it should be added. | As it stands now I will not do further work on the booktabs stuff. I really | don't know wether that has any influence on the number of fixed bugs or | not. I might be swayed if all three of you test and perfect this patch. -- Lgb
Re: booktabs
Lars Gullik Bjnnes wrote: | I never did that before. But if it is so much work, I do not want that | anymore. I just did not want to pass patches around, because that can | quickly become a pain, too. | Note that I am in favour of the feature freeze, too, and that I do not | come up with arbitrary new features, but since Edwin already did half | the work and chances are really low that it breaks anything (almost | everything enclosed in if (use_booktabs) and since there are at least | three of us who need this I thought that it should be added. | As it stands now I will not do further work on the booktabs stuff. I | really don't know wether that has any influence on the number of fixed | bugs or not. I might be swayed if all three of you test and perfect this patch. I offer myself to test it if somebody explain me what's about ;-) Alfredo
Re: booktabs
Alfredo Braunstein [EMAIL PROTECTED] writes: I might be swayed if all three of you test and perfect this patch. I offer myself to test it if somebody explain me what's about Any layout with a vertical line can be improved immediately by removing that line -- I don't remember where this quote comes from, but as you will have noticed, most LaTeX tables have lots of vertical lines which can be improved ;-) Formal tables have only one horizontal line if they are simple and a few more short horizontal lines if they contain column groups. The rest of the layout is done with alignment and spaces. Or did you want to know how the _patch_ works? :-) /Andreas
Re: booktabs
Andreas Vox wrote: Any layout with a vertical line can be improved immediately by removing that line -- I don't remember where this quote comes from, but as you will have noticed, most LaTeX tables have lots of vertical lines which can be improved ;-) Formal tables have only one horizontal line if they are simple and a few more short horizontal lines if they contain column groups. The rest of the layout is done with alignment and spaces. I see. And what's the improvement wrt to plain LaTeX tables? The ability to put horizontal lines independently in any column? Or did you want to know how the _patch_ works? :-) Not at all, I just want to be able to test it ;-) Alfredo
Re: booktabs
Alfredo Braunstein [EMAIL PROTECTED] writes: I see. And what's the improvement wrt to plain LaTeX tables? The ability to put horizontal lines independently in any column? LaTeX does support that AFAIK. The improvement should be that you *can't* put lines anywhere you want. Or, as the masters tell it: http://www.dante.de/CTAN/macros/latex/contrib/booktabs/booktabs.pdf /Andreas
Re: booktabs
Juergen Spitzmueller wrote: > As to me: don't hold your breath (but at least I fixed two critical bugs > in the last week, and that's surprising enough for a human scientist) ;-) I know. That's more than most of us go human sciences! Alfredo
Re: booktabs
On Sun, Nov 07, 2004 at 08:58:55PM +, John Levon wrote: > > I did try not to respond to this. > > On Sun, Nov 07, 2004 at 08:57:10PM +0100, Andre Poenitz wrote: > > > I'd rather officially lift the freeze for a short while and let > > everybody work on his pet project in this time. This also includes XML > > support as this is a thing of fairly high 'public interest' which also > > happens to be comparatively independent of the current core problems. > > A decision was already made once that has screwed up LyX 1.4, please > don't do it again... When, please? LyX core was not in good shape since the revamp of the update() stuff - pretty early in the 1.4 cycle. And this was dearly needed, as it was impossible to fix serious bugs in the core anymore. Ever tried to add real 'undo' for math? I mean that kind of undo that does not place the cursor outside the inset? > > The idea that in freeze time everybody starts fixing bugs might be nice > > in theory but seemingly does not work too well in reality. And this time > > is not the first time. 1.2 was no better. > > We could have had 1.4 out of the door by now if we'd stopped soon after > Lars' STL-in-the-core changes. Then we'd have a 1.4 with the same user visible feature set as 1.3 and a 1.5cvs in the same shape as 1.4cvs right now. I don't really see the big advantage. For either developer or user. [In fact, there's one good thing about the long 1.3 area: Almost all current distros have 1.3.x in one form or another and we really do not have to care for 1.2.x anymore.] > > I'd really like to have a happy, busy lyx-devel list doing fancy > > things _including_ fixing a bug from time to time instead of a dead > > list with two kinds of corpses: Those that can't fix 'deep' bugs > > because they just started finding their ways around in LyX source, > > and those that theoretically could but feel defeated from several > > hundred open bugs and seemingly no support from anybody else. > > You actively chose to rip the core code to shreds in the hope somebody > miight have time to rebuild it, and convinced Lars of it. I tried > as hard as I could to evangelise against this for precisely these > reasons, but lost the argument. You might have missed the point that I did quite a bit of rebuilding the LyX core since then. And I have certainly missed the point of your active contribution in this process. And I 'did not convince Lars of it'. > I don't want to annoy you any more, so I'll leave it here, but please > don't complain about situations you knowingly created. I was not asking you. Your opinion is known and noted. It is even taken into consideration even if you don't believe so. On the other hand I was thinking about adding a line like 'BTW, John, shut up.' - for good reason as I see now - to the last mail but tried to stay on the polite side. Andre'
Re: booktabs
Alfredo Braunstein wrote: > Andre Poenitz wrote: > >>> That'd be good (so we could work on it together). I never created a >>> branch myself, though. >> >> Working with branches is a pain, frustrates people and eats into already >> scrace resources. I never did that before. But if it is so much work, I do not want that anymore. I just did not want to pass patches around, because that can quickly become a pain, too. Note that I am in favour of the feature freeze, too, and that I do not come up with arbitrary new features, but since Edwin already did half the work and chances are really low that it breaks anything (almost everything enclosed in "if (use_booktabs)" and since there are at least three of us who need this I thought that it should be added. As it stands now I will not do further work on the booktabs stuff. I really don't know wether that has any influence on the number of fixed bugs or not. > (cannot wait to have Juergen and Georg's skills employed in fixing core > bugs ;-)) Well, if you could transfer your core knowledge magically to me, then this could happen, but otherwise I fear you have to wait a long time ;-( Georg
