On Sat, Oct 25, 2003 at 12:18:05AM +0200, Alfredo Braunstein spake thusly:
> This seems to be the culprit. (even if your change seems reasonable and
> other parts may be adjusted instead)
>
> Alfredo
Funny thing is, I looked at this yesterday and wondered, would that be
the culprit?
Then I had
On Fri, Oct 24, 2003 at 11:24:22AM -0700, Kayvan A. Sylvan spake thusly:
> > With or without, I propose to check this in. It solves the critical
> > side of the problem even while lacking a desirable feature.
>
> I agree. We should continue to hammer at this, though. Anybody else have
> any ideas
Martin Vermeer wrote:
> The problem was indeed, that if the target paragraph is inside an
> inset, then in lyxfunc.C dispatch() LFUN_GOTO_PARAGRAPH we have
> a call to setCursor() which takes its 'this' from the main LyXText of
> the document, while the paragraph is in the internal LyXText of the
Martin Vermeer wrote:
> Funny thing is, I looked at this yesterday and wondered, would that be
> the culprit?
> Then I had to take care of other things and go home, and couldn't
> check it out ;-)
Thanks for looking at it anyways
If you have the time and will, I'd really appreciate if you ca
Alfredo Braunstein wrote:
> Alfredo Braunstein wrote:
>
>> A simplistic rowbreakpoint sanitizing patch... that works (or seems to).
>> It's still somewhat ugly (I'm cleaning it a bit) but loads the UserGuide
>> correctly.
>
> But it's not working fine. It leaves too much space sometimes and ther
Index: undo.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/undo.C,v
retrieving revision 1.23
diff -u -p -u -r1.23 undo.C
--- undo.C 15 Oct 2003 08:49:42 - 1.23
+++ undo.C 25 Oct 2003 11:24:16 -
@@ -170,7 +1
On Sat, 25 Oct 2003, Angus Leeming wrote:
> Amir Michail wrote:
> > Hi,
>
> > The discussion on this has been quite useful to us. I have
> > contacted other academics at UNSW CSE and have shown them this
> > thread to see what they think.
>
> > BTW, there may be university regulations about whe
Pretty straightforward. Ok?
Alfredo
Index: text2.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text2.C,v
retrieving revision 1.485
diff -u -p -u -r1.485 text2.C
--- text2.C 24 Oct 2003 15:04:17 - 1.485
+++ text2.C
Attached is a fix for the branches color issues in qt (1. branches color was
not immediately updated, buffer reload was necessary; 2. new branches had
black background). Everything works as expected now.
Martin, I have introduced a setColor() function in ControlDocument, similar to
the one in C
Juergen Spitzmueller wrote:
> BTW do you have any idea why (un)collapsing branches sets the document's
> state to "changed"?
Actually this happens with any collapsable inset (ERT, footnote, note etc.).
Jürgen.
Juergen Spitzmueller wrote:
> Juergen Spitzmueller wrote:
>> BTW do you have any idea why (un)collapsing branches sets the document's
>> state to "changed"?
>
> Actually this happens with any collapsable inset (ERT, footnote, note
> etc.).
I believe it is intended, because the state collapsed/un
Alfredo Braunstein wrote:
> I believe it is intended, because the state collapsed/uncollapsed gets
> saved.
I see. Yes, that makes sense.
Thanks,
Jürgen.
Juergen Spitzmueller wrote:
> Attached is a fix for the branches color issues in qt (1. branches color
> was not immediately updated, buffer reload was necessary; 2. new branches
> had black background). Everything works as expected now.
*Sigh*
Please try this one. I don't think a LyXName -> LColo
Juergen Spitzmueller wrote:
Index: src/frontends/qt2/QDocument.C
> + string x11hexname = params.branchlist().getColor(current_branch);
> + // check that we have a valid color!
> + if (x11hexname[0] != '#')
> + x11hexname = lcolor.getX11Name(LColor::background);
Is this saf
Angus Leeming wrote:
> Index: src/frontends/qt2/QDocument.C
>
> > + string x11hexname = params.branchlist().getColor(current_branch);
> > + // check that we have a valid color!
> > + if (x11hexname[0] != '#')
> > + x11hexname = lcolor.getX11Name(LColor::background);
>
> Is t
Juergen Spitzmueller wrote:
> branchlist().getColor() can return string() (but it shouldn't as I read the
> code). What I want is that we fall back to the background color whenever
> the branch has no sensible color or color "none". Doesn't an empty string
> mean "no color"? Anyway, the branches ba
width of a single inset row is broken.
width of a row ending on a line-break is broken.
Ideas?
Regards, Alfredo
<>
Juergen Spitzmueller wrote:
> Martin, I have introduced a setColor() function in ControlDocument, similar
> to the one in ControlPrefs. I think you could use that also in the xforms
> frontend, instead of the colorhandler thing you have now.
The attached patch lets xforms use the same method as qt
On Sat, Oct 25, 2003 at 04:38:48PM +0200, Juergen Spitzmueller spake thusly:
>
> Juergen Spitzmueller wrote:
> > Martin, I have introduced a setColor() function in ControlDocument, similar
> > to the one in ControlPrefs. I think you could use that also in the xforms
> > frontend, instead of the co
On Sat, Oct 25, 2003 at 04:32:40PM +0200, Alfredo Braunstein spake thusly:
> width of a single inset row is broken.
Did this ever work (lately?) The text is indented with the standard
paragraph indent.
> width of a row ending on a line-break is broken.
Huh? That should work. The code doing it
On Sat, Oct 25, 2003 at 04:32:40PM +0200, Alfredo Braunstein spake thusly:
> width of a single inset row is broken.
Ah yes, sorry, did not read carefully. An eternity (1.4 cycle) bug
this too.
The inset width should be shorter in case of a single line. I had code
for this at some point, but it
Martin Vermeer wrote:
> Yes... line 1257 above. Change it into
>
>1257 && !pit->isNewline(row.endpos() - 1)
>
> ... remember endpos() is really one-past-the-end right? (But in the
Oh yes I *do* remember. ;-)
> case of the inset on line 1248 we really *do* want the first
> '
Martin Vermeer wrote:
> On Sat, Oct 25, 2003 at 04:32:40PM +0200, Alfredo Braunstein spake thusly:
>
>> width of a single inset row is broken.
>
> Ah yes, sorry, did not read carefully. An eternity (1.4 cycle) bug
> this too.
>
> The inset width should be shorter in case of a single line. I ha
On Sat, Oct 25, 2003 at 05:46:17PM +0200, Alfredo Braunstein wrote:
> No, the problem I see is even for multi-row insets, that the inset go too
> much to the right and you don't see the right border of it nor even the
> rightest part of the text. Do you know the cause? It seems to me that this
> w
John Levon wrote:
> On Sat, Oct 25, 2003 at 05:46:17PM +0200, Alfredo Braunstein wrote:
>
>> No, the problem I see is even for multi-row insets, that the inset go too
>> much to the right and you don't see the right border of it nor even the
>> rightest part of the text. Do you know the cause? It
On Sat, Oct 25, 2003 at 06:05:32PM +0200, Alfredo Braunstein wrote:
> > Are you sure ? AFAIK this bug has existed since the day Andre introduced
> > it in his cleanups.
>
> No I'm not sure. I though that I remembered ;-)
FYI: http://bugzilla.lyx.org/show_bug.cgi?id=1282
john
--
Khendon's Law:
John Levon wrote:
> On Sat, Oct 25, 2003 at 06:05:32PM +0200, Alfredo Braunstein wrote:
>
>> > Are you sure ? AFAIK this bug has existed since the day Andre
>> > introduced it in his cleanups.
>>
>> No I'm not sure. I though that I remembered ;-)
>
> FYI: http://bugzilla.lyx.org/show_bug.cgi?id
On Sat, Oct 25, 2003 at 05:40:34PM +0200, Alfredo Braunstein spake thusly:
>
> > case of the inset on line 1248 we really *do* want the first
> > 'character' -- i.e., the inset -- on the next line to decide if we
> > should not stretch this line. Different situation.)
>
> Cool. Made the change
On Sat, Oct 25, 2003 at 05:46:17PM +0200, Alfredo Braunstein spake thusly:
>
> Martin Vermeer wrote:
>
> > On Sat, Oct 25, 2003 at 04:32:40PM +0200, Alfredo Braunstein spake thusly:
> > A possibly related problem that you see in multi-line paragraphs in
> > insets, is that the right edge of the
Martin Vermeer wrote:
> On Sat, Oct 25, 2003 at 04:38:48PM +0200, Juergen Spitzmueller spake
> thusly:
>>
>> Juergen Spitzmueller wrote:
>> > Martin, I have introduced a setColor() function in
>> > ControlDocument, similar to the one in ControlPrefs. I think you
>> > could use that also in the xf
Martin Vermeer wrote:
> If it works (also in the borderline situations such as defining a new
> branch and not rightaway a color, as well as the save/load cycle) then
> very much so. I am again behind a dial-up here for the weekend.
Unfortunately it does not. LyX (xforms) crashes whenever I want t
Martin Vermeer wrote:
> No, it was right originally. And remained right when I added the test
> for a display() type inset one line below. It became wrong only when
> someone(s) started tinkering with the ways used to denote the
> one-past-the-end of the row (IIRC originally next_row.pos() ), and
These are the two missing fixes + a bit of noncontroversial rowbreakpoint
simplification.
Regards, Alfredo
Index: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.1651
diff -u -p -u -r
Alfredo Braunstein wrote:
> +pos_type i = pos;
> for ( ; i < end; ++i) {
Do you need 'i' after the end of this for loop? If so, rename it. If
not, shove it into 'for (pos_type i = pos; i < end; ++i) {'
--
Angus
Angus Leeming wrote:
> Alfredo Braunstein wrote:
>
>> +pos_type i = pos;
>> for ( ; i < end; ++i) {
>
> Do you need 'i' after the end of this for loop? If so, rename it. If
Yes. What do you suggest for a name? I'm out of imagination.
Alfredo
The attach patch (committed) gets rid of th dynamic_casts in
InsetExternal and generally cleans things up a little.
Christian, could you see whether it now works with gcc 2.96?
--
AngusIndex: src/insets/ChangeLog
===
RCS file: /usr
Alfredo Braunstein wrote:
>> Do you need 'i' after the end of this for loop? If so, rename it.
>> If
>
> Yes. What do you suggest for a name? I'm out of imagination.
Ok, I looked at the code and all appears fine. Sorry for the noise.
Angus
pos_type point = end;
pos_type i = pos;
37 matches
Mail list logo
