Martin Vermeer wrote:
This is a real bug, and probably easy to fix. In math_gridinset's
getStatus, there should be tests for nrows() = 0 and ncols() = 0 for
the cases add-(h/v)line-(above|below), just like there are for the
others.
I thought that every MathGridInset has at least one row and
Angus Leeming wrote:
Here's an unchecked implementation of the idea. Frontend only. No hooks
from the core. However, I'm sure that you'll be able to turn this into
working code ;-)
I'll try to do that later.
Thanks!
Georg
Juergen Spitzmueller wrote:
Sun, 20 Mar 2005 08:26:53 -0800
The striking-out line for erased text is misplaced in the first row of the
main text, since this also includes the top margin, which is not honoured by
the strikeout calculation. The attached patch fixes it.
This works for the
Attached, update to reflect progress on gtk frontend.
John
Index: guii.php3
===
RCS file: /cvs/lyx/www-devel/guii.php3,v
retrieving revision 1.72
diff -u -p -r1.72 guii.php3
--- guii.php3 2004/11/15 15:35:27 1.72
+++ guii.php3
Johnathan Burchill wrote:
Juergen Spitzmueller wrote:
Sun, 20 Mar 2005 08:26:53 -0800
The striking-out line for erased text is misplaced in the first row of
the main text, since this also includes the top margin, which is not
honoured by the strikeout calculation. The attached patch fixes
Georg Baum wrote:
Angus Leeming wrote:
Here's an unchecked implementation of the idea. Frontend only. No hooks
from the core. However, I'm sure that you'll be able to turn this into
working code ;-)
I'll try to do that later.
Thanks!
My pleasure. One refinement. It probably makes a
Alfredo Braunstein wrote:
Shows as a disalignement for instance in selections of nested tables.
I've commited this.
Alfredo
John Spray wrote:
Attached, update to reflect progress on gtk frontend.
Comitted. You should see the change in ½hour or so.
--
Angus
Angus == Angus Leeming [EMAIL PROTECTED] writes:
Angus Conceptually, doing so is easy. We just need to tell the Dialog
Angus that the buffer has become readOnly, no? That way, the OK and
Angus Apply buttons will be disabled.
Angus Here's an unchecked implementation of the idea. Frontend only.
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes:
Juergen Yes, of course not (btw this one is useless on KDE systems,
Juergen because KWin catches C-Tab).
Yes.
Juergen Revised patches attached. OK now?
Yes.
JMarc
Angus == Angus Leeming [EMAIL PROTECTED] writes:
Angus Jean-Marc Lasgouttes wrote:
This patch fixes the following bug:
1/ create an InsetInclude with type 'include'
2/ place the cursor after the inset and hit return
3/ see how the button turned into a small white square.
The
Juergen Spitzmueller wrote:
Andre Poenitz wrote:
So a good check is always math-in-math-in-note-in-table-in-table. If
something works in this scenario it is fairly safe to assume it works
everywhere.
This works too.
Thanks Juergen, Martin and Andre. I'll commit this tonight (gotta run).
Georg == Georg Baum [EMAIL PROTECTED] writes:
Georg This patch fixes the appendix problems Jean-Pierre reported. A
Georg test file is also attached. OK to apply?
This looks good to me.
JMarc
Jean-Marc Lasgouttes wrote:
Angus, considering that we know how broken the preview code is in this
case, can I still apply my fix, which is unrelated to the preview
stuff?
Certainly. It fixes a clear problem.
--
Angus
Jean-Marc Lasgouttes wrote:
Angus Conceptually, doing so is easy. We just need to tell the Dialog
Angus that the buffer has become readOnly, no? That way, the OK and
Angus Apply buttons will be disabled.
Angus Here's an unchecked implementation of the idea. Frontend only.
Angus No hooks
Angus == Angus Leeming [EMAIL PROTECTED] writes:
Angus The point being that the core would explicitly tell individual
Angus (named) dialogs when it was illegal to Apply their contents.
Angus Your suggesting (if I understand correctly) that each and every
Angus open dialog should recieve
On Mon, 2005-03-21 at 10:16, Georg Baum wrote:
Martin Vermeer wrote:
This is a real bug, and probably easy to fix. In math_gridinset's
getStatus, there should be tests for nrows() = 0 and ncols() = 0 for
the cases add-(h/v)line-(above|below), just like there are for the
others.
I
My take on José's LyX archaeology page
http://www.devel.lyx.org/~leeming/www-user/archaeology/lyx_timeline.php
isn't validating as XHTML 1.0 ATM because it contains multiple blocks:
dl id=a
contents
/dl
W3C's validator complains with lots of:
Line 202, column 10: ID a first defined here
dl
Angus Leeming wrote:
My take on José's LyX archaeology page
http://www.devel.lyx.org/~leeming/www-user/archaeology/lyx_timeline.php
isn't validating as XHTML 1.0 ATM because it contains multiple blocks:
dl id=a
contents
/dl
W3C's validator complains with lots of:
Line 202, column
José,
do you have any patches to make old versions of LyX compile against XForms
1.0?
If so, can you post them to me and I'll update
http://www.devel.lyx.org/~leeming/www-user/archaeology/lyx_timeline.php
--
Angus
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
While you are at it: Shouldn't the other lfuns that exist in
do_dispatch() be handled in getStatus(), too?.
Martin Only those that are connected to a menu entry or such, that
Martin should be greyed out. I think.
No, all functions handled in
Martin Vermeer wrote:
The problem is not that a MathGridInset would have only one row/col. The
problem is that MathGridInset's getStatus gets called even for insets
that in reality are _not_ array-type insets.
Do you know why? It looks like my picture of this whole getStatus/dispatch
Eitan == Eitan [EMAIL PROTECTED] writes:
Eitan --- Jean-Marc Lasgouttes [EMAIL PROTECTED] wrote:
Another possibility would be to just output the content of the
field without any label: + if (!annote.empty()) + result \n\n
annote;
Eitan Good enough for me...
I applied it to both
Angus == Angus Leeming [EMAIL PROTECTED] writes:
Angus Jean-Marc Lasgouttes wrote:
Angus, considering that we know how broken the preview code is in
this case, can I still apply my fix, which is unrelated to the
preview stuff?
Angus Certainly. It fixes a clear problem.
Thanks. Done.
JMarc
On Monday 21 March 2005 13:28, Angus Leeming wrote:
José,
do you have any patches to make old versions of LyX compile against
XForms 1.0?
Sort of... :-)
I have the original directories as well as the new, a recursive diff
should do it.
If so, can you post them to me and I'll update
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars | May I kindly ask for the result of our discussion? | I
Lars answered all of your questions and now I cannot see how to
Lars proceed.
Lars For 1.3. J-M is calling the shots.
I propose to commit the QuoteName changes to 1.3.x and
Jose' == Jose' Matos [EMAIL PROTECTED] writes:
Jose' I will do it this week, and then I will send you the
Jose' resulting bits.
It would be nice to have statistics on the growth of LyX among
versions (tar size, binary size, compile time, whatever...), too.
Especially since you have all these
Angus == Angus Leeming [EMAIL PROTECTED] writes:
Angus José, do you have any patches to make old versions of LyX
Angus compile against XForms 1.0?
Angus If so, can you post them to me and I'll update
Angus http://www.devel.lyx.org/~leeming/www-user/archaeology/lyx_timeline.php
Angus, there are
Hi,
In InsetGraphicsParams::init, we have:
scale = string(); // output scaling in percentage
width = LyXLength();
height = LyXLength();
Would it not be more sensible to have scale = 100? or does this get
set elsewhere?
John
On Mon, 2005-03-21 at 16:36, Georg Baum wrote:
Martin Vermeer wrote:
The problem is not that a MathGridInset would have only one row/col. The
problem is that MathGridInset's getStatus gets called even for insets
that in reality are _not_ array-type insets.
Do you know why? It looks
Jean-Marc Lasgouttes wrote:
Angus, there are also some recent announcements in www-user/announce.
You may want to link to them...
Great idea.
--
Angus
Juergen Spitzmueller [EMAIL PROTECTED] writes:
| The striking-out line for erased text is misplaced in the first row of the
| main text, since this also includes the top margin, which is not honoured by
| the strikeout calculation. The attached patch fixes it.
| The offset is still there for
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
| Lars | May I kindly ask for the result of our discussion? | I
| Lars answered all of your questions and now I cannot see how to
| Lars proceed.
| Lars For 1.3. J-M is calling the shots.
| I
Martin Vermeer wrote:
The problem is that MathGridInset is abused by MathHullInset to draw
grid-like display formulas of various kinds, which can do most of the
things a true gridinset can (like swapping two rows or columns) but
not everything. See the handling of rowChangeOK and colChangeOK
John Spray wrote:
Would it not be more sensible to have scale = 100? or does this get
set elsewhere?
The scale param is not written in this case. The backend outputs it in
original size (i.e. 100%) then, so it's not necessary to set it explicitely
to 100%.
Regards,
Jürgen
Lars Gullik Bjønnes wrote:
Is it not possible to get rid of the '13'?
Yes it is. See me updated patch (reattached to this mail).
Jürgen
P.S.: I found out that 1/3 of the font maxAscent gives the best result for
different font sizes, but also to the default size.
Index: rowpainter.C
On Mon, 2005-03-21 at 19:26 +0100, Juergen Spitzmueller wrote:
John Spray wrote:
Would it not be more sensible to have scale = 100? or does this get
set elsewhere?
The scale param is not written in this case. The backend outputs it in
original size (i.e. 100%) then, so it's not
John Spray wrote:
So would it be correct to say that if (scale == string() width ==
LyXLength() height == LyXLength()) then I should present the user
with UI representing 100% scaling?
Yes, I think so. This is also what the qt graphics dialog does.
Jürgen
Juergen Spitzmueller [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
Is it not possible to get rid of the '13'?
| Yes it is. See me updated patch (reattached to this mail).
Ok, thanks,
--
Lgb
On Mon, 2005-03-21 at 19:37 +0100, Juergen Spitzmueller wrote:
John Spray wrote:
So would it be correct to say that if (scale == string() width ==
LyXLength() height == LyXLength()) then I should present the user
with UI representing 100% scaling?
Yes, I think so. This is also what the
John Spray wrote
Yes, I think so. This is also what the qt graphics dialog does.
Hmm, here the qt graphics dialog initially displays 0%.
Hmm. you're right. This has changed since 1.3. 100% seems more sensible,
though (even if the result is the same).
Jürgen
So the test file actually works. I am surprised that the runtime test
yields 'no'.
On another front, what happens when you edit the lyxrc.defaults file
to contain
\tex_allows_spaces true
?
Does typesetting of docs in directories-with-spaces-in-their-name
work?
Yes. (This is in lyx-136.)
In
On Mon, Mar 21, 2005 at 03:36:15PM +0100, Georg Baum wrote:
There is one (btw for every math inset):
Not for every one, only for these that need extra tweaking in some form
or the other. Unfortunately there are quite a few of them. This is sort
of poor man's RTTI.
virtual MathGridInset
On Mon, Mar 21, 2005 at 01:54:34PM +0200, Martin Vermeer wrote:
The problem is not that a MathGridInset would have only one row/col. The
problem is that MathGridInset's getStatus gets called even for insets
that in reality are _not_ array-type insets.
Every math inset is wrapped in a
On Mon, Mar 21, 2005 at 09:16:24AM +0100, Georg Baum wrote:
Martin Vermeer wrote:
This is a real bug, and probably easy to fix. In math_gridinset's
getStatus, there should be tests for nrows() = 0 and ncols() = 0 for
the cases add-(h/v)line-(above|below), just like there are for the
On Mon, Mar 21, 2005 at 05:56:42PM +0200, Martin Vermeer wrote:
I believe that asGridInset will not return the right answer: it will
always return true if the inset is a MathGridInset in the C++ sense,
irrespective whether it is in the role of, e.g., an eqnarray.
Indeed.
From my testing it
On Mon, Mar 21, 2005 at 05:17:53PM +0100, Lars Gullik Bjønnes wrote:
Andre Poenitz [EMAIL PROTECTED] writes:
| It looks like I can't really resist here, however I am not happy at all
| about this or later thing. I am interested to keep my code (well, at
| least the part related to LyX) free
Andre Poenitz [EMAIL PROTECTED] writes:
| On Mon, Mar 21, 2005 at 05:17:53PM +0100, Lars Gullik Bjønnes wrote:
Andre Poenitz [EMAIL PROTECTED] writes:
| It looks like I can't really resist here, however I am not happy at all
| about this or later thing. I am interested to keep my code (well,
Andre Poenitz wrote:
Anyway. Angus, you may add my name to that list of yours (not the one of
people owing you lots of beer, but that other one with poeple granting
permission to licence their contributions to LyX under the Gnu General
Public Licence, version 2 or later).
Great! Done so.
On Mon, Mar 21, 2005 at 08:43:46PM +0100, Andre Poenitz wrote:
On Mon, Mar 21, 2005 at 01:54:34PM +0200, Martin Vermeer wrote:
The problem is not that a MathGridInset would have only one row/col. The
problem is that MathGridInset's getStatus gets called even for insets
that in reality are
On Mon, Mar 21, 2005 at 08:52:30PM +0100, Andre Poenitz wrote:
On Mon, Mar 21, 2005 at 05:56:42PM +0200, Martin Vermeer wrote:
From my testing it appears that for a true grid inset (which may be
nested inside an untrue one), control never even passes the
MathHullInset getStatus method:
Martin Vermeer wrote:
On Mon, Mar 21, 2005 at 08:52:30PM +0100, Andre Poenitz wrote:
So this indicates a bug in either doDispatch or getStatus in this area.
The most nested inset should be asked first and thus gets a chance to
give a definite answer first. If that does not happen
Lars Gullik Bjønnes wrote:
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
| Lars | May I kindly ask for the result of our discussion? | I
| Lars answered all of your questions and now I cannot see how to
| Lars proceed.
| Lars For 1.3. J-M is
Martin Vermeer wrote:
> This is a real bug, and probably easy to fix. In math_gridinset's
> getStatus, there should be tests for nrows() <= 0 and ncols() <= 0 for
> the cases add-(h/v)line-(above|below), just like there are for the
> others.
I thought that every MathGridInset has at least one
Angus Leeming wrote:
> Here's an unchecked implementation of the idea. Frontend only. No hooks
> from the core. However, I'm sure that you'll be able to turn this into
> working code ;-)
I'll try to do that later.
Thanks!
Georg
Juergen Spitzmueller wrote:
> Sun, 20 Mar 2005 08:26:53 -0800
> The striking-out line for erased text is misplaced in the first row of the
> main text, since this also includes the top margin, which is not honoured by
> the strikeout calculation. The attached patch fixes it.
This works for the
Attached, update to reflect progress on gtk frontend.
John
Index: guii.php3
===
RCS file: /cvs/lyx/www-devel/guii.php3,v
retrieving revision 1.72
diff -u -p -r1.72 guii.php3
--- guii.php3 2004/11/15 15:35:27 1.72
+++ guii.php3
Johnathan Burchill wrote:
> Juergen Spitzmueller wrote:
> > Sun, 20 Mar 2005 08:26:53 -0800
> > The striking-out line for erased text is misplaced in the first row of
> > the main text, since this also includes the top margin, which is not
> > honoured by the strikeout calculation. The attached
Georg Baum wrote:
> Angus Leeming wrote:
>
>> Here's an unchecked implementation of the idea. Frontend only. No hooks
>> from the core. However, I'm sure that you'll be able to turn this into
>> working code ;-)
>
> I'll try to do that later.
>
> Thanks!
My pleasure. One refinement. It
Alfredo Braunstein wrote:
> Shows as a disalignement for instance in selections of nested tables.
I've commited this.
Alfredo
John Spray wrote:
> Attached, update to reflect progress on gtk frontend.
Comitted. You should see the change in ½hour or so.
--
Angus
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Conceptually, doing so is easy. We just need to tell the Dialog
Angus> that the buffer has become readOnly, no? That way, the OK and
Angus> Apply buttons will be disabled.
Angus> Here's an unchecked implementation of the idea.
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Yes, of course not (btw this one is useless on KDE systems,
Juergen> because KWin catches C-Tab).
Yes.
Juergen> Revised patches attached. OK now?
Yes.
JMarc
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Jean-Marc Lasgouttes wrote:
>> This patch fixes the following bug:
>>
>> 1/ create an InsetInclude with type 'include'
>>
>> 2/ place the cursor after the inset and hit
>>
>> 3/ see how the button turned into a small white
Juergen Spitzmueller wrote:
> Andre Poenitz wrote:
>> So a good check is always math-in-math-in-note-in-table-in-table. ÂIf
>> something works in this scenario it is fairly safe to assume it works
>> everywhere.
>
> This works too.
Thanks Juergen, Martin and Andre. I'll commit this tonight
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> This patch fixes the appendix problems Jean-Pierre reported. A
Georg> test file is also attached. OK to apply?
This looks good to me.
JMarc
Jean-Marc Lasgouttes wrote:
> Angus, considering that we know how broken the preview code is in this
> case, can I still apply my fix, which is unrelated to the preview
> stuff?
Certainly. It fixes a clear problem.
--
Angus
Jean-Marc Lasgouttes wrote:
> Angus> Conceptually, doing so is easy. We just need to tell the Dialog
> Angus> that the buffer has become readOnly, no? That way, the OK and
> Angus> Apply buttons will be disabled.
>
> Angus> Here's an unchecked implementation of the idea. Frontend only.
> Angus>
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> The point being that the core would explicitly tell individual
Angus> (named) dialogs when it was illegal to Apply their contents.
Angus> Your suggesting (if I understand correctly) that each and every
Angus> open dialog should
On Mon, 2005-03-21 at 10:16, Georg Baum wrote:
> Martin Vermeer wrote:
>
> > This is a real bug, and probably easy to fix. In math_gridinset's
> > getStatus, there should be tests for nrows() <= 0 and ncols() <= 0 for
> > the cases add-(h/v)line-(above|below), just like there are for the
> >
My take on José's LyX archaeology page
http://www.devel.lyx.org/~leeming/www-user/archaeology/lyx_timeline.php
isn't validating as XHTML 1.0 ATM because it contains multiple blocks:
contents
W3C's validator complains with lots of:
Line 202, column 10: ID "a" first defined here
Line 232,
Angus Leeming wrote:
> My take on José's LyX archaeology page
> http://www.devel.lyx.org/~leeming/www-user/archaeology/lyx_timeline.php
> isn't validating as XHTML 1.0 ATM because it contains multiple blocks:
>
>
> contents
>
>
> W3C's validator complains with lots of:
> Line 202, column
José,
do you have any patches to make old versions of LyX compile against XForms
1.0?
If so, can you post them to me and I'll update
http://www.devel.lyx.org/~leeming/www-user/archaeology/lyx_timeline.php
--
Angus
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>> While you are at it: Shouldn't the other lfuns that exist in
>> do_dispatch() be handled in getStatus(), too?.
Martin> Only those that are connected to a menu entry or such, that
Martin> should be greyed out. I think.
No, all
Martin Vermeer wrote:
> The problem is not that a MathGridInset would have only one row/col. The
> problem is that MathGridInset's getStatus gets called even for insets
> that in reality are _not_ array-type insets.
Do you know why? It looks like my picture of this whole getStatus/dispatch
> "Eitan" == Eitan <[EMAIL PROTECTED]> writes:
Eitan> --- Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote:
>> Another possibility would be to just output the content of the
>> field without any label: + if (!annote.empty()) + result << "\n\n"
>> << annote;
>>
Eitan> Good enough for me...
I
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Jean-Marc Lasgouttes wrote:
>> Angus, considering that we know how broken the preview code is in
>> this case, can I still apply my fix, which is unrelated to the
>> preview stuff?
Angus> Certainly. It fixes a clear problem.
On Monday 21 March 2005 13:28, Angus Leeming wrote:
> José,
>
> do you have any patches to make old versions of LyX compile against
> XForms 1.0?
Sort of... :-)
I have the original directories as well as the new, a recursive diff
should do it.
> If so, can you post them to me and I'll
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> | May I kindly ask for the result of our discussion? | I
Lars> answered all of your questions and now I cannot see how to
Lars> proceed.
Lars> For 1.3. J-M is calling the shots.
I propose to commit the QuoteName changes to
> "Jose'" == Jose' Matos <[EMAIL PROTECTED]> writes:
Jose'> I will do it this week, and then I will send you the
Jose'> resulting bits.
It would be nice to have statistics on the growth of LyX among
versions (tar size, binary size, compile time, whatever...), too.
Especially since you have
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> José, do you have any patches to make old versions of LyX
Angus> compile against XForms 1.0?
Angus> If so, can you post them to me and I'll update
Angus> http://www.devel.lyx.org/~leeming/www-user/archaeology/lyx_timeline.php
Hi,
In InsetGraphicsParams::init, we have:
> scale = string(); // output scaling in percentage
> width = LyXLength();
> height = LyXLength();
Would it not be more sensible to have scale = "100"? or does this get
set elsewhere?
John
On Mon, 2005-03-21 at 16:36, Georg Baum wrote:
> Martin Vermeer wrote:
>
> > The problem is not that a MathGridInset would have only one row/col. The
> > problem is that MathGridInset's getStatus gets called even for insets
> > that in reality are _not_ array-type insets.
>
> Do you know why? It
Jean-Marc Lasgouttes wrote:
> Angus, there are also some recent announcements in www-user/announce.
> You may want to link to them...
Great idea.
--
Angus
Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
| The striking-out line for erased text is misplaced in the first row of the
| main text, since this also includes the top margin, which is not honoured by
| the strikeout calculation. The attached patch fixes it.
>
| The offset is still there
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
| Lars> | May I kindly ask for the result of our discussion? | I
| Lars> answered all of your questions and now I cannot see how to
| Lars> proceed.
>
| Lars> For 1.3. J-M is
Martin Vermeer wrote:
> The problem is that MathGridInset is "abused" by MathHullInset to draw
> grid-like display formulas of various kinds, which can do most of the
> things a "true" gridinset can (like swapping two rows or columns) but
> not everything. See the handling of rowChangeOK and
John Spray wrote:
> Would it not be more sensible to have scale = "100"? or does this get
> set elsewhere?
The scale param is not written in this case. The backend outputs it in
original size (i.e. 100%) then, so it's not necessary to set it explicitely
to 100%.
Regards,
Jürgen
Lars Gullik Bjønnes wrote:
> Is it not possible to get rid of the '13'?
Yes it is. See me updated patch (reattached to this mail).
Jürgen
P.S.: I found out that 1/3 of the font maxAscent gives the best result for
different font sizes, but also to the default size.
Index: rowpainter.C
On Mon, 2005-03-21 at 19:26 +0100, Juergen Spitzmueller wrote:
> John Spray wrote:
> > Would it not be more sensible to have scale = "100"? or does this get
> > set elsewhere?
>
> The scale param is not written in this case. The backend outputs it in
> original size (i.e. 100%) then, so it's
John Spray wrote:
> So would it be correct to say that if (scale == string() && width ==
> LyXLength() && height == LyXLength()) then I should present the user
> with UI representing 100% scaling?
Yes, I think so. This is also what the qt graphics dialog does.
Jürgen
Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>> Is it not possible to get rid of the '13'?
>
| Yes it is. See me updated patch (reattached to this mail).
Ok, thanks,
--
Lgb
On Mon, 2005-03-21 at 19:37 +0100, Juergen Spitzmueller wrote:
> John Spray wrote:
> > So would it be correct to say that if (scale == string() && width ==
> > LyXLength() && height == LyXLength()) then I should present the user
> > with UI representing 100% scaling?
>
> Yes, I think so. This is
John Spray wrote
> > Yes, I think so. This is also what the qt graphics dialog does.
>
> Hmm, here the qt graphics dialog initially displays 0%.
Hmm. you're right. This has changed since 1.3. 100% seems more sensible,
though (even if the result is the same).
Jürgen
So the test file actually works. I am surprised that the runtime test
yields 'no'.
On another front, what happens when you edit the lyxrc.defaults file
to contain
\tex_allows_spaces true
?
Does typesetting of docs in directories-with-spaces-in-their-name
work?
Yes. (This is in lyx-136.)
In
On Mon, Mar 21, 2005 at 03:36:15PM +0100, Georg Baum wrote:
> There is one (btw for every math inset):
Not for every one, only for these that need extra tweaking in some form
or the other. Unfortunately there are quite a few of them. This is sort
of "poor man's RTTI".
> virtual MathGridInset
On Mon, Mar 21, 2005 at 01:54:34PM +0200, Martin Vermeer wrote:
> The problem is not that a MathGridInset would have only one row/col. The
> problem is that MathGridInset's getStatus gets called even for insets
> that in reality are _not_ array-type insets.
Every math inset is wrapped in a
On Mon, Mar 21, 2005 at 09:16:24AM +0100, Georg Baum wrote:
> Martin Vermeer wrote:
>
> > This is a real bug, and probably easy to fix. In math_gridinset's
> > getStatus, there should be tests for nrows() <= 0 and ncols() <= 0 for
> > the cases add-(h/v)line-(above|below), just like there are for
On Mon, Mar 21, 2005 at 05:56:42PM +0200, Martin Vermeer wrote:
> I believe that asGridInset will not return the right answer: it will
> always return true if the inset is a MathGridInset in the C++ sense,
> irrespective whether it is in the role of, e.g., an eqnarray.
Indeed.
> From my testing
On Mon, Mar 21, 2005 at 05:17:53PM +0100, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | It looks like I can't really resist here, however I am not happy at all
> | about this "or later" thing. I am interested to keep my code (well, at
> | least the part related to
1 - 100 of 106 matches
Mail list logo
