Re: Cursor position just after a math-inset
On Mon, Mar 31, 2003 at 08:42:56PM +0200, Christian Ridderstr?m wrote: > Hmm.. so it's fixed for instant preview. I've never used that function, > but I think that instant previews aren't instant-instant, if you know > what I mean. I.e. would it keep me from doing this stupid sequence? > Nothing, I guess, but you would have to talk to the people involved (ie. andre and michael) to find out why this can't be fixed. > I'm going to try and get instant preview running, but if that's not > enough, should I add a comment to 819, or file a separate thing? Perhaps 819 should be reopened and WONTFIXed. This is up to andre, I would appreciate an explanation. john
[patch] Tenth rowlist patch
Another fun patch.
A lot of changes in this one, I have not had time to test this well.
So there might be problems.
Please try it out if you have the chance.
Index: po/POTFILES.in
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/po/POTFILES.in,v
retrieving revision 1.324
diff -u -p -r1.324 POTFILES.in
--- po/POTFILES.in 26 Mar 2003 15:55:51 - 1.324
+++ po/POTFILES.in 1 Apr 2003 00:43:59 -
@@ -29,9 +29,10 @@ src/frontends/controllers/helper_funcs.C
src/frontends/gnome/GLog.C
src/frontends/LyXView.C
src/frontends/qt2/Alert_pimpl.C
+src/frontends/qt2/BulletsModule.C
src/frontends/qt2/Dialogs.C
src/frontends/qt2/FileDialog.C
-src/frontends/qt2/lengthcombo.C
+src/frontends/qt2/floatplacement.C
src/frontends/qt2/QAbout.C
src/frontends/qt2/QBibitem.C
src/frontends/qt2/QBibtex.C
@@ -123,7 +124,6 @@ src/frontends/xforms/FormToc.C
src/frontends/xforms/FormUrl.C
src/frontends/xforms/FormVCLog.C
src/frontends/xforms/FormWrap.C
-src/frontends/xforms/input_validators.C
src/frontends/xforms/Menubar_pimpl.C
src/frontends/xforms/xformsBC.h
src/frontends/xforms/xforms_helpers.C
@@ -169,7 +169,6 @@ src/lyxfont.C
src/lyxfunc.C
src/lyx_main.C
src/lyxrc.C
-src/lyxtextclasslist.C
src/lyxvc.C
src/mathed/formulabase.C
src/mathed/formulamacro.C
@@ -181,8 +180,6 @@ src/paragraph.C
src/paragraph_funcs.C
src/ParagraphParameters.C
src/rowpainter.C
-src/support/filetools.C
-src/tabular.C
src/text2.C
src/text3.C
src/text.C
Index: src/lyxcursor.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxcursor.C,v
retrieving revision 1.17
diff -u -p -r1.17 lyxcursor.C
--- src/lyxcursor.C 13 Feb 2003 16:52:29 - 1.17
+++ src/lyxcursor.C 1 Apr 2003 00:43:59 -
@@ -111,25 +111,25 @@ int LyXCursor::iy() const
}
-void LyXCursor::row(Row * r)
+void LyXCursor::row(RowList::iterator r)
{
row_ = r;
}
-Row * LyXCursor::row() const
+RowList::iterator LyXCursor::row() const
{
return row_;
}
-void LyXCursor::irow(Row * r)
+void LyXCursor::irow(RowList::iterator r)
{
irow_ = r;
}
-Row * LyXCursor::irow() const
+RowList::iterator LyXCursor::irow() const
{
return irow_;
}
Index: src/lyxcursor.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxcursor.h,v
retrieving revision 1.29
diff -u -p -r1.29 lyxcursor.h
--- src/lyxcursor.h 13 Feb 2003 16:52:29 - 1.29
+++ src/lyxcursor.h 1 Apr 2003 00:43:59 -
@@ -10,10 +10,10 @@
#ifndef LYXCURSOR_H
#define LYXCURSOR_H
+#include "RowList.h"
#include "support/types.h"
class Paragraph;
-class Row;
/**
* The cursor class describes the position of a cursor within a document.
@@ -81,11 +81,11 @@ public:
*/
int iy() const;
/// set the row of the paragraph the cursor is in
- void row(Row * r);
+ void row(RowList::iterator r);
/// return the row of the paragraph this cursor is in
- Row * row() const;
+ RowList::iterator row() const;
/// set the stored next row
- void irow(Row * r);
+ void irow(RowList::iterator r);
/**
* Return the next row, when this
* cursor is at the end of the previous row, for insets that take
@@ -93,7 +93,7 @@ public:
*
* FIXME: explain why we need this ? especially for y...
*/
- Row * irow() const;
+ RowList::iterator irow() const;
private:
/// The paragraph the cursor is in.
Paragraph * par_;
@@ -126,9 +126,9 @@ private:
/// the stored next-row y position
int iy_;
/// the containing row
- Row * row_;
+ RowList::iterator row_;
/// the containing row for the next line
- Row * irow_;
+ RowList::iterator irow_;
};
/// these three dictate the others
Index: src/rowpainter.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/rowpainter.C,v
retrieving revision 1.10
diff -u -p -r1.10 rowpainter.C
--- src/rowpainter.C 22 Mar 2003 17:25:59 - 1.10
+++ src/rowpainter.C 1 Apr 2003 00:44:00 -
@@ -53,8 +53,8 @@ BufferView * perv(BufferView const & bv)
} // namespace anon
-RowPainter::RowPainter(BufferView const & bv, LyXText const & text, Row const & row)
- : bv_(bv), pain_(bv_.painter()), text_(text), row_(row), par_(*row.par())
+RowPainter::RowPainter(BufferView const & bv, LyXText const & text, RowList::iterator rit)
+ : bv_(bv), pain_(bv_.painter()), text_(text), row_(rit), par_(*rit->par())
{
}
@@ -97,8 +97,7 @@ char const RowPainter::transformChar(cha
int RowPainter::leftMargin() const
{
- Row * row(const_cast(&row_));
- return text_.leftMargin(row);
+ return text_.leftMargin(row_);
}
@@ -113,7 +112,7 @@ void RowPainter::paintInset(pos_type con
#warning inset->update FIXME
inset->update(perv(bv_), false);
- inset->draw(perv(bv_), font, yo_ + row_.baseline(), x_);
+ inset->draw(perv(bv_), font, yo_ + row_->baseline(), x_);
}
@@ -148,7 +147,7 @@ void RowPainter::paintHebrewComposeChar(
Re: [patch] Ninth rowlist patch.
Alfredo Braunstein <[EMAIL PROTECTED]> writes: | True, it undo works with 1) solved. [...] | this modified redoParagraphs solves 1) (and the undo) and 2) for me (the | modified regions are above ^, sorry for not providing a patch | against your patch, I'm too lazy to cvs up and reapply it). Just great. You just understands the inner workings for this Row strangeness a lot better than me. As far as I can see this now works perfectly. I'll apply it before anyne else finds more errors. :-) -- Lgb
Re: [patch] Ninth rowlist patch.
Lars Gullik Bjønnes wrote:
> Alfredo Braunstein <[EMAIL PROTECTED]> writes:
>
> | Lars Gullik Bjønnes wrote:
> |
> | > This patch basically rewrites redoParagraphs to use the
> | > RowList::iterators instead of Row*.
> | >
> | > This is a very important function and quite complex too, so strange
> | > things might arise here.
> |
> | 1) It crashes on cut:
> |
> | aaa|
>
> 1
> 2
>
> crashes as well...
>
> I bet if that is fixed this will just work...
>
True, it undo works with 1) solved.
I found the error in 2) (the same thing mostly), in your patch you have:
+--tmprit;
and below:
-if (!tmprow) {
-insertParagraph(tmppar, rowlist_.begin());
-} else {
-insertParagraph(tmppar, tmprow->next());
-}
-
-
-if (!tmprow) {
-tmprow = &*rows().begin();
+insertParagraph(tmppar, tmprit);
but --tmprit with tmprit == rows().begin() is == rows.end() in the
implementation, then the inversion of rows.
this modified redoParagraphs solves 1) (and the undo) and 2) for me (the
modified regions are above ^, sorry for not providing a patch
against your patch, I'm too lazy to cvs up and reapply it).
void LyXText::redoParagraphs(LyXCursor const & cur,
Paragraph const * endpar)
{
Paragraph * tmppar = 0;
Paragraph * first_phys_par = 0;
RowList::iterator tmprit = cur.row();
int y = cur.y() - tmprit->baseline();
if (tmprit == rows().begin()) {
// a trick/hack for UNDO
// This is needed because in an UNDO/REDO we could have changed
// the ownerParagrah() so the paragraph inside the row is NOT
// my really first par anymore. Got it Lars ;) (Jug 20011206)
first_phys_par = ownerParagraph();
} else {
first_phys_par = tmprit->par();
while (tmprit != rows().begin()
&& boost::prior(tmprit)->par() == first_phys_par)
{
--tmprit;
y -= tmprit->height();
}
}
RowList::iterator prevrit;
if (tmprit != rows().begin()) {
prevrit = boost::prior(tmprit);
} else {
prevrit = tmprit;
y = prevrit->height();
}
^^^
// remove it
if (boost::next(tmprit) != rows().end())
tmppar = boost::next(tmprit)->par();
else
tmppar = 0;
while (boost::next(tmprit) != rows().end() && tmppar != endpar) {
removeRow(boost::next(tmprit));
if (boost::next(tmprit) != rows().end()) {
tmppar = boost::next(tmprit)->par();
} else {
tmppar = 0;
}
}
// remove the first one
RowList::iterator tmprit2 = tmprit; /* this is because tmprow->previous()
can be 0 */
++tmprit;
^^^
removeRow(tmprit2);
// Reinsert the paragraphs.
tmppar = first_phys_par;
do {
if (tmppar) {
insertParagraph(tmppar, tmprit);
while (tmprit != rows().end()
&& tmprit->par() == tmppar) {
++tmprit;
}
tmppar = tmppar->next();
}
} while (tmppar && tmppar != endpar);
// this is because of layout changes
setHeightOfRow(prevrit);
const_cast(this)->postPaint(y - prevrit->height());
^
if (tmprit != rows().end() && boost::next(tmprit) != rows().end())
setHeightOfRow(boost::next(tmprit));
updateCounters();
}
Hope it helps,
Alfredo
Re: [patch] Ninth rowlist patch.
Alfredo Braunstein <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: | | > This patch basically rewrites redoParagraphs to use the | > RowList::iterators instead of Row*. | > | > This is a very important function and quite complex too, so strange | > things might arise here. | | 1) It crashes on cut: | | aaa| 1 2 crashes as well... I bet if that is fixed this will just work... -- Lgb
Re: [patch] Ninth rowlist patch.
Lars Gullik Bjønnes wrote:
> This patch basically rewrites redoParagraphs to use the
> RowList::iterators instead of Row*.
>
> This is a very important function and quite complex too, so strange
> things might arise here.
1) It crashes on cut:
aaa|
select the last 'a' and cut: crash. The backtrace shows that the problem is
that there is no check that tmprit != begin() in:
+RowList::iterator prevrit = boost::prior(tmprit);
and below we have:
+if (prevrit != rows().begin()) {
+setHeightOfRow(prevrit);
2)
aaa
bbb|
select the last b and cut: the rows become inverted.
I'm digging further on this other one.
Alfredo
Re: lyx-1.4.0cvs compile error (text.C)
On Mon, Mar 31, 2003 at 10:55:31PM +0200, Alfredo Braunstein wrote: > Lars Gullik Bjønnes wrote: > > > "Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: > > > > | gcc-2.95.3 on SunOS-2.5.1: > > | > > | text.C:911: prototype for `int LyXText::fill(Row &, int)' does not match > > | any in class `LyXText' lyxtext.h:606: candidate is: int > > | LyXText::fill(Row &, int) const > > > > Try out the ninth and I'll help you. > > blackmail? ;) > > I'm trying it out. Lars, it looks like your blackmail threat is ineffective, since Angus has come to the rescue! 2003-03-31 Angus Leeming <[EMAIL PROTECTED]> * text.C (fill): ensure that the signature is the same as that in the header file. Thanks, Angus! ---Kayvan P.S. I will try out your patches. No blackmail necessary. ;-) -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92)
Re: lyx-1.4.0cvs compile error (text.C)
Alfredo Braunstein <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: | | > "Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: | > | > | gcc-2.95.3 on SunOS-2.5.1: | > | | > | text.C:911: prototype for `int LyXText::fill(Row &, int)' does not match | > | any in class `LyXText' lyxtext.h:606: candidate is: int | > | LyXText::fill(Row &, int) const | > | > Try out the ninth and I'll help you. | | blackmail? ;) Yes. (and the patch also fixes this problem) | I'm trying it out. Thanks a lot. -- Lgb
Re: lyx-1.4.0cvs compile error (text.C)
Lars Gullik Bjønnes wrote: > "Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: > > | gcc-2.95.3 on SunOS-2.5.1: > | > | text.C:911: prototype for `int LyXText::fill(Row &, int)' does not match > | any in class `LyXText' lyxtext.h:606: candidate is: int > | LyXText::fill(Row &, int) const > > Try out the ninth and I'll help you. blackmail? ;) I'm trying it out. Alfredo
Re: lyx-1.4.0cvs compile error (text.C)
"Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: | gcc-2.95.3 on SunOS-2.5.1: | | text.C:911: prototype for `int LyXText::fill(Row &, int)' does not match any in class `LyXText' | lyxtext.h:606: candidate is: int LyXText::fill(Row &, int) const Try out the ninth and I'll help you. -- Lgb
lyx-1.4.0cvs compile error (text.C)
gcc-2.95.3 on SunOS-2.5.1: make[3]: Entering directory `/remote/simian1/ksylvan/lyx/src' source='text.C' object='text.o' libtool=no \ depfile='.deps/text.Po' tmpdepfile='.deps/text.TPo' \ depmode=gcc /bin/ksh ../config/depcomp \ g++ -DHAVE_CONFIG_H -I. -I. -I. -I../boost -I/u/ksylvan/include -isystem /usr/openwin/include -O2 -Wno-non-template-friend -ftemplate-depth-30 -W -Wall -c -o text.o `test -f 'text.C' || echo './'`text.C text.C:290: warning: #warning inset->update FIXME text.C:1064: warning: #warning inset->update FIXME text.C:1523: warning: #warning Trouble Point! (Lgb) text.C:2131: warning: #warning handle multi par selection text.C:2152: warning: #warning handle multi par selection text.C:2387: warning: #warning changes text.C:911: prototype for `int LyXText::fill(Row &, int)' does not match any in class `LyXText' lyxtext.h:606: candidate is: int LyXText::fill(Row &, int) const -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92)
Re: LyX 131 for SuSE
Not really, just one file: lyx.spec to locate the qt3.1.1 libs. I guess you can drop that one. Thanks again for all your efforts. Building rpms is easy and microsocopic contribution to the LyX community with respect to the devel and doc team. Best regards Paul Jean-Marc Lasgouttes wrote: > "Paul" == Paul Borgermans <[EMAIL PROTECTED]> writes: Paul> Hello Upon request, I uploaded the SuSE rpm and src.rpm compiled Paul> with qt3.1.1 into ftp.lyx.org/incoming Paul> lyx-1.3.1-1_SuSE8.1_qt3.1.1.i386.rpm Paul> lyx-1.3.1-1_SuSE8.1_qt3.1.1.src.rpm Paul> The spec file is changed to reflect SuSE package names and Paul> dependencies. Paul> It installs and runs fine with an updated SuSE linux Paul> distribution including the latest qt3 rpm (qt3.1.1 mostly gets Paul> installed with KDE3.1, but the latter not required) Hello, Is the src.rpm really needed too? Is it different from the qt2 src.rpm? JMarc
Undo in math mode exits math mode
Hi Here's another (old) annoying behaviour. If you are in math mode and do undo, the cursor skips out of math mode. I tried searching for it in bugzilla, but seem to get "Zarro Boogs" all the time. This is one I did expect to find though... hasn't it been around for ages? Bugzilla it? /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: Cursor position just after a math-inset
On Mon, 31 Mar 2003, John Levon wrote: > On Mon, Mar 31, 2003 at 07:30:03PM +0200, Christian Ridderstr?m wrote: > > > I'm typing some equation and then press to get out of math mode. > > The cursor leaves math mode, but for some reason I think that I've > > hit twice so there's an extra space between the math-inset and the > > location of the cursor... so I do backspace and the whole math-inset is > > deleted - does this sound familiar? > > Just a little > > http://bugzilla.lyx.org/show_bug.cgi?id=819 > Hmm.. so it's fixed for instant preview. I've never used that function, but I think that instant previews aren't instant-instant, if you know what I mean. I.e. would it keep me from doing this stupid sequence? Here's a screenshot with the distances (wish I knew how to capture the cursor) ... http://www.md.kth.se/~chr/lyx/bugs/distance_to_cursor_too_big.png I'm going to try and get instant preview running, but if that's not enough, should I add a comment to 819, or file a separate thing? As for solutions, the problem 819 discusses is that the space (that doesn't really exist) is too big, whereas I'm primarily concerned with the position of the cursor. Here it would be enough to "shift" the cursor a bit to the left when just behind a math-inset. Although that seems a bit like a hack, if it's really the math border that takes up space. And also... fiddling a bit with it just now, it *is* annoying that you can't tell if there is a space next to the math-inset or not... (that might actually get a bit better if the cursor position was adjusted). /Christian -- Christian Ridderström, +46-8-790 91 37 http://www.md.kth.se/~chr Mechatronics lab, Dept. of Machine Designhttp://www.md.kth.se
[patch] Ninth rowlist patch.
This patch basically rewrites redoParagraphs to use the
RowList::iterators instead of Row*.
This is a very important function and quite complex too, so strange
things might arise here.
Would be nice if people could test this a bit.
Index: po/POTFILES.in
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/po/POTFILES.in,v
retrieving revision 1.324
diff -u -p -r1.324 POTFILES.in
--- po/POTFILES.in 26 Mar 2003 15:55:51 - 1.324
+++ po/POTFILES.in 31 Mar 2003 18:01:14 -
@@ -29,9 +29,10 @@ src/frontends/controllers/helper_funcs.C
src/frontends/gnome/GLog.C
src/frontends/LyXView.C
src/frontends/qt2/Alert_pimpl.C
+src/frontends/qt2/BulletsModule.C
src/frontends/qt2/Dialogs.C
src/frontends/qt2/FileDialog.C
-src/frontends/qt2/lengthcombo.C
+src/frontends/qt2/floatplacement.C
src/frontends/qt2/QAbout.C
src/frontends/qt2/QBibitem.C
src/frontends/qt2/QBibtex.C
@@ -123,7 +124,6 @@ src/frontends/xforms/FormToc.C
src/frontends/xforms/FormUrl.C
src/frontends/xforms/FormVCLog.C
src/frontends/xforms/FormWrap.C
-src/frontends/xforms/input_validators.C
src/frontends/xforms/Menubar_pimpl.C
src/frontends/xforms/xformsBC.h
src/frontends/xforms/xforms_helpers.C
@@ -169,7 +169,6 @@ src/lyxfont.C
src/lyxfunc.C
src/lyx_main.C
src/lyxrc.C
-src/lyxtextclasslist.C
src/lyxvc.C
src/mathed/formulabase.C
src/mathed/formulamacro.C
@@ -181,8 +180,6 @@ src/paragraph.C
src/paragraph_funcs.C
src/ParagraphParameters.C
src/rowpainter.C
-src/support/filetools.C
-src/tabular.C
src/text2.C
src/text3.C
src/text.C
Index: src/text.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text.C,v
retrieving revision 1.334
diff -u -p -r1.334 text.C
--- src/text.C 31 Mar 2003 16:57:44 - 1.334
+++ src/text.C 31 Mar 2003 18:01:18 -
@@ -907,7 +907,7 @@ LyXText::rowBreakPoint(Row const & row)
// returns the minimum space a row needs on the screen in pixel
-int LyXText::fill(Row & row, int paper_width)
+int LyXText::fill(Row & row, int paper_width) const
{
if (paper_width < 0)
return 0;
Index: src/text2.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text2.C,v
retrieving revision 1.313
diff -u -p -r1.313 text2.C
--- src/text2.C 31 Mar 2003 16:57:45 - 1.313
+++ src/text2.C 31 Mar 2003 18:01:19 -
@@ -679,83 +679,78 @@ void LyXText::redoDrawingOfParagraph(LyX
void LyXText::redoParagraphs(LyXCursor const & cur,
Paragraph const * endpar)
{
- Row * tmprow = cur.row();
+ Paragraph * tmppar = 0;
+ Paragraph * first_phys_par = 0;
- int y = cur.y() - tmprow->baseline();
+ RowList::iterator tmprit = cur.row();
- Paragraph * first_phys_par = 0;
- if (!tmprow->previous()) {
+ int y = cur.y() - tmprit->baseline();
+
+ if (tmprit == rows().begin()) {
// a trick/hack for UNDO
// This is needed because in an UNDO/REDO we could have changed
// the ownerParagrah() so the paragraph inside the row is NOT
// my really first par anymore. Got it Lars ;) (Jug 20011206)
first_phys_par = ownerParagraph();
} else {
- first_phys_par = tmprow->par();
-
- // Find first row of this paragraph.
- while (tmprow->previous()
- && tmprow->previous()->par() == first_phys_par)
+ first_phys_par = tmprit->par();
+ while (tmprit != rows().begin()
+ && boost::prior(tmprit)->par() == first_phys_par)
{
- tmprow = tmprow->previous();
- y -= tmprow->height();
+ --tmprit;
+ y -= tmprit->height();
}
}
- Row * prevrow = tmprow->previous();
+ RowList::iterator prevrit = boost::prior(tmprit);
- // Remove all the rows until we reach endpar
- Paragraph * tmppar = 0;
- if (tmprow->next())
- tmppar = tmprow->next()->par();
- while (tmprow->next() && tmppar != endpar) {
- removeRow(tmprow->next());
- if (tmprow->next()) {
- tmppar = tmprow->next()->par();
+ // remove it
+ if (boost::next(tmprit) != rows().end())
+ tmppar = boost::next(tmprit)->par();
+ else
+ tmppar = 0;
+ while (boost::next(tmprit) != rows().end() && tmppar != endpar) {
+ removeRow(boost::next(tmprit));
+ if (boost::next(tmprit) != rows().end()) {
+ tmppar = boost::next(tmprit)->par();
} else {
tmppar = 0;
}
}
- // Remove the first of the paragraphs rows.
- // This is because tmprow->previous() can be 0
- Row * tmprow2 = tmprow;
- tmprow = tmprow->previous();
- removeRow(tmprow2);
+ // remove the first one
+ RowList::iterator tmprit2 = tmprit; /* this is because tmprow->previous()
+ can be 0 */
+ --tmprit;
+ removeRow(tmprit2);
// Reinsert the paragraphs.
tmppar = first_phys_par;
do {
if (tmppar) {
- if (!tmprow) {
-insertParagraph(tmppar, rowlist_.begin());
- } else {
-insertParagraph(tmppar, tmprow->next());
- }
-
-
- if (!tmprow) {
-tmprow = &*rows().begin();
+ insertParagraph(tmppar, tmprit);
+ if (tmprit == rows().end()) {
+tmprit = rows().begin();
}
-
Re: Start times: 1.4.0cvs vs. 1.3.0
On Mon, Mar 31, 2003 at 07:40:07PM +0200, Lars Gullik Bj?nnes wrote: > not sure... I'd just like to see some updated profiling. Sure, then, it is no big bother. john
Re: Start times: 1.4.0cvs vs. 1.3.0
John Levon <[EMAIL PROTECTED]> writes: | On Mon, Mar 31, 2003 at 07:13:21PM +0200, Lars Gullik Bj?nnes wrote: | | > | Extremely often during the key binding setup phase. | > | > After I have got all the rowlist patches in, can you then rebuild your | > lyx with -O2 and do another profiling run? | | Why ? What will change ? not sure... I'd just like to see some updated profiling. -- Lgb
Re: Alfredo insettext patch ...
On Sun, Mar 30, 2003 at 01:35:18AM +0100, Alfredo Braunstein wrote: > Can you try this? I've put inside #if 0 the code that make local the > mouseclick position before calling edit or localDispatch on a > !isHiglyEditable() child inset, and added a simple localdispatch for > insetbuttons that call edit(). > This works because simple insets (that do not have an overloaded > localDispatch()) do not use the cursor position received on edit(), AFAIK. Hmm, OK. Then where is the comment above the #if 0 saying this ? I willl add it, and test the patch in a bit. Thanks. > I think that we should switch to _always_ pass the local coordinates to > insets in the future, but at least it's more uniform with this patch. Yes, we really need to clean the whole thing altogether. It's mostly a residue of when the cursor presses were not lfuns. I'm in favour of dropping ->edit() stuff altogether. If an inset doesn't care, it can inherit a default or something regards john
Re: cm fonts status - SOLVED
On Mon, Mar 31, 2003 at 06:57:41PM +0300, Dan Armak wrote: > Someone please fetch and test http://cvs.gentoo.org/~danarmak/fonts.tar.bz2 . > These are modified bluesky fonts. Use as a replacement to the bakoma ones (no > change needed to lyx code). Can you check if things work if you set LANG=ru_RU ? I suspect they may still break, but it would be nice to check. regards john
Re: Cursor position just after a math-inset
On Mon, Mar 31, 2003 at 07:30:03PM +0200, Christian Ridderstr?m wrote: > I'm typing some equation and then press to get out of math mode. > The cursor leaves math mode, but for some reason I think that I've > hit twice so there's an extra space between the math-inset and the > location of the cursor... so I do backspace and the whole math-inset is > deleted - does this sound familiar? Just a little http://bugzilla.lyx.org/show_bug.cgi?id=819 john
Cursor position just after a math-inset
Hi I was just working with LyX and noticed something that's actually been a nuisance for years... here's what typically happens: I'm typing some equation and then press to get out of math mode. The cursor leaves math mode, but for some reason I think that I've hit twice so there's an extra space between the math-inset and the location of the cursor... so I do backspace and the whole math-inset is deleted - does this sound familiar? Anyway, I looked closer at it (literally) and noticed that the cursor actually moves a small distance when you leave the math-inset, which could explain why I think there's a space there. My suggestion is that this distance either be reduced or removed, I think it could be removed now with the red (?) box around the math-inset that appear when you're in math mode. Opinions? Objections to filing it as an enhancement request? As a temporary "workaround", I can start using to leave math-mode, but I think I'd prefer . /Chrsitian -- Christian Ridderström http://www.md.kth.se/~chr
Re: Start times: 1.4.0cvs vs. 1.3.0
On Mon, Mar 31, 2003 at 07:13:21PM +0200, Lars Gullik Bj?nnes wrote: > | Extremely often during the key binding setup phase. > > After I have got all the rowlist patches in, can you then rebuild your > lyx with -O2 and do another profiling run? Why ? What will change ? john
Re: Start times: 1.4.0cvs vs. 1.3.0
John Levon <[EMAIL PROTECTED]> writes: | On Mon, Mar 31, 2003 at 06:11:06PM +0200, Jean-Marc Lasgouttes wrote: | | > John> Yes, although operator== didn't have any debug anyway. I suspect | > John> we could fix this in a much smarter way somehow. | > | > But why is this operator so costly? Is it called very often? | | Extremely often during the key binding setup phase. After I have got all the rowlist patches in, can you then rebuild your lyx with -O2 and do another profiling run? -- Lgb
Re: menubackend.defaults
On Mon, Mar 31, 2003 at 11:15:41AM +0200, Jean-Marc Lasgouttes wrote: > I think we should remove this fallback stuff (also for toolbars). We > should probably make sure that LyX works nevertheless. There are > people who would be interested in having no toolbar, for example. I Isn't this done by not listing a toolbar in the .ui file ? regards, john
Re: Start times: 1.4.0cvs vs. 1.3.0
On Mon, Mar 31, 2003 at 06:11:06PM +0200, Jean-Marc Lasgouttes wrote: > John> Yes, although operator== didn't have any debug anyway. I suspect > John> we could fix this in a much smarter way somehow. > > But why is this operator so costly? Is it called very often? Extremely often during the key binding setup phase. regards, john
Re: cm fonts status - SOLVED
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 31 March 2003 19:30, Dan Armak wrote: > How that name got there, I've no idea, since it is called "kappa" in the > original bluesky type1 font, so either my generating scripts or pfaedit > itself are at fault... Sorry, my mistake. My scripts actually told pfaedit to change every character's name to match its new unicode value! So most characters now have wrong names... Problem is, if I tell pfaedit not to change the names (call from script SetUnicodeValue(value, 0) ) it segfaults... Don't know why, or how to go around it, yet... - -- Dan Armak Gentoo Linux developer (KDE) Matan, Israel Public GPG key: http://www.gentoo.org/~danarmak/danarmak-gpg-public.key -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+iG/zUI2RQ41fiVERAvcfAJ9JEQA6yQ+GiotfOHU38cvF1fT5mACfQiCH w52n1GuG0bGFb6AHeRqP5Aw= =BPyM -END PGP SIGNATURE-
Re: cm fonts status - SOLVED
On Mon, Mar 31, 2003 at 07:30:26PM +0300, Dan Armak wrote: > 1) exists in cmmi10 (both bakoma and bluesky-derived versions). So apparently > lyx isn't using that font here. (BTW I'd really appreciate an explanation of > what characters it takes from what font, since most of them are present in > several.) Look at lib/symbols file. > I'll try to fix this - there's a whole bunch of characters around kappa in Great work Dan, much appreciated. regards, john
Re: cm fonts status - SOLVED
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 31 March 2003 19:07, Dekel Tsur wrote: > I had a problem with the following symbols: \kappa I looked at kappa as an example. It: 1) exists in cmmi10 (both bakoma and bluesky-derived versions). So apparently lyx isn't using that font here. (BTW I'd really appreciate an explanation of what characters it takes from what font, since most of them are present in several.) 2) exists in bakoma msbm10 as "kappa" at unicode address 007b. It also exists in my bluesky-derived font at 007b, but isn't called "kappa". Rather, it's called "braceleft", which is the unicode char that really owns location 007b. How that name got there, I've no idea, since it is called "kappa" in the original bluesky type1 font, so either my generating scripts or pfaedit itself are at fault... I'll try to fix this - there's a whole bunch of characters around kappa in msbm10 that have the wrong names (the names of the unicode chars that should be at their address). Meanwhile a quick explanation of when lyx uses unicode values, and when it uses character names, would be much appreciated. - -- Dan Armak Gentoo Linux developer (KDE) Matan, Israel Public GPG key: http://www.gentoo.org/~danarmak/danarmak-gpg-public.key -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+iG0iUI2RQ41fiVERAnV/AJ9CJOt3XIIFbuAUfnmNtV5mU05t+wCfT2BA fEHuGjGXkbPgeoOj6t3UIPA= =huWs -END PGP SIGNATURE-
Re: cm fonts status - SOLVED
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 31 March 2003 19:07, Dekel Tsur wrote: > I had a problem with the following symbols: \kappa, \upuparrows, > \backepsilon, \nleqq, \backepsilon and \circleddash. If you can tell me in which fonts these are supposed to be, I can add them (assuming I can find them somewhere in the bleusky or other texmf type1 fonts). Or I could just check all the bakoma fonts to see which have these... (Assuming the character names are also 'kappa', 'upuparrows' etc?) For the latter two I would need to know the "unicode" values to use as well (what does lyx expect them to be?) I say "unicode", because the values used by bakoma aren't the real unicode values for these chars - they are some weird custom and (to me) meaningless values, which is why lyx can't use any truly unicode font that provides the necessary symbols. It took me two days to realize that, after which I just spent several hours scripting pfaedit to grab the character name --> 'unicode' value mappings from the bakoma fonts, and rearranging the bluesky fonts to match. > They appear as a square (the latter two also appear as squares when using > the bakoma fonts, so it is possible that the problem is in lib/symbols). > I'll investigate later. > Also, eufm10.ttf is missing That's because bakoma doesn't have eufm10 either (nor wasy10). I intentionally didn't put in anything that doesn't exist in the bakoma package, because I wouldn't know what unicode values to give the chars. - -- Dan Armak Gentoo Linux developer (KDE) Matan, Israel Public GPG key: http://www.gentoo.org/~danarmak/danarmak-gpg-public.key -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+iGq7UI2RQ41fiVERAiRSAJ45MTJMbpLqlhgxkgiyyoz7CWkoDgCdE3py Vvx4nThJh5OTPX1hDhtuLeQ= =wFJL -END PGP SIGNATURE-
Re: LyX 131 for SuSE
> "Paul" == Paul Borgermans <[EMAIL PROTECTED]> writes: Paul> Hello Upon request, I uploaded the SuSE rpm and src.rpm compiled Paul> with qt3.1.1 into ftp.lyx.org/incoming Paul> lyx-1.3.1-1_SuSE8.1_qt3.1.1.i386.rpm Paul> lyx-1.3.1-1_SuSE8.1_qt3.1.1.src.rpm Paul> The spec file is changed to reflect SuSE package names and Paul> dependencies. Paul> It installs and runs fine with an updated SuSE linux Paul> distribution including the latest qt3 rpm (qt3.1.1 mostly gets Paul> installed with KDE3.1, but the latter not required) Hello, Is the src.rpm really needed too? Is it different from the qt2 src.rpm? JMarc
Re: bmod function
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> On Mon, Mar 24, 2003 at 07:37:16PM +0100, Andre Poenitz wrote: >> As long as I don't know whether it can take limits (like 'lim') or >> not (like 'cos') I have to guess as well... John> JMarc, two patches for 1.3.2 consideration. Applied. JMarc
Re: Start times: 1.4.0cvs vs. 1.3.0
> "John" == John Levon <[EMAIL PROTECTED]> writes:
John> On Fri, Mar 28, 2003 at 07:00:34PM +0100, Jean-Marc Lasgouttes
John> wrote:
>> How should this data be read? Can oprofile provide a call graph
>> like gprof does?
John> Arggh ! [1]
OK, I won't insist :)
John> Yes, although operator== didn't have any debug anyway. I suspect
John> we could fix this in a much smarter way somehow.
But why is this operator so costly? Is it called very often?
John>1239 int c = fgetc(inf); 1240 while (c != EOF) { 1241 ret +=
John> static_cast(c); 1242 c = fgetc(inf); 1243 }
John> is probably not too smart. At least, we could use getc() not
John> fgetc
Or fread(), maybe.
JMarc
Re: cm fonts status - SOLVED
On Mon, Mar 31, 2003 at 06:57:41PM +0300, Dan Armak wrote: > > Sorry for shouting SOLVED like that, but I've been working on this for the > last three days, and solved the problem through sheer stubbornness, because I > started out with zero knowledge... So now I'm really happy :-) > > Someone please fetch and test http://cvs.gentoo.org/~danarmak/fonts.tar.bz2 . > These are modified bluesky fonts. Use as a replacement to the bakoma ones (no > change needed to lyx code). > Just put the fonts somewhere under /usr/share/fonts, run fc-cache as root and > as user, run lyx with a qt3.1 interface (that uses fontconfig+xft2) and see > if the matheditor's formulas show the right characters. > > Someone please confirm that it works (and I wonder about the xforms frontend, > since it doesn't use fontconfig afaik...), and if it does work, I'll provide > details about it if anyone wants them. If it doesn't... I had a problem with the following symbols: \kappa, \upuparrows, \backepsilon, \nleqq, \backepsilon and \circleddash. They appear as a square (the latter two also appear as squares when using the bakoma fonts, so it is possible that the problem is in lib/symbols). I'll investigate later. Also, eufm10.ttf is missing
Re: cm fonts status - SOLVED
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello everyone, Sorry for shouting SOLVED like that, but I've been working on this for the last three days, and solved the problem through sheer stubbornness, because I started out with zero knowledge... So now I'm really happy :-) Someone please fetch and test http://cvs.gentoo.org/~danarmak/fonts.tar.bz2 . These are modified bluesky fonts. Use as a replacement to the bakoma ones (no change needed to lyx code). Just put the fonts somewhere under /usr/share/fonts, run fc-cache as root and as user, run lyx with a qt3.1 interface (that uses fontconfig+xft2) and see if the matheditor's formulas show the right characters. Someone please confirm that it works (and I wonder about the xforms frontend, since it doesn't use fontconfig afaik...), and if it does work, I'll provide details about it if anyone wants them. If it doesn't... - -- Dan Armak Gentoo Linux developer (KDE) Matan, Israel Public GPG key: http://www.gentoo.org/~danarmak/danarmak-gpg-public.key -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+iGV5UI2RQ41fiVERAoyqAJ9rjDekStSTa44f//HWa0zAQzvvhwCfaszP /2DB6if/oymnp56fAt6djnU= =Zl44 -END PGP SIGNATURE-
Re: [PATCH] lyx2lyx: subcaption in LyX file format 2.15
On Mon, Mar 31, 2003 at 03:36:01PM +0200, Jean-Marc Lasgouttes wrote: > > "Jos?" == Jos? Matos <[EMAIL PROTECTED]> writes: > > Jos?> On Friday 28 March 2003 17:54, John Levon wrote: > >> > What is the status of that? Is it supposed to be safe now? > >> > >> Jose said "it was probably OK" or something. It works for me ... > >> but I don't know python > > Jos?> The original code is from Dekel, John's fix looks reasonable > Jos?> to me and I would need to see different cases to fully assert > Jos?> the validity of the patch. > > Jos?> That said I think that Jonh code is correct, is deals with one > Jos?> missing case that is not dealt now, so it should go. > > Unfortunately this is false :( See the message I forwarded a minute > ago. This is easy to fix. Attached is an updated patch ? x.lyx Index: lyxconvert_218.py === RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/lyx2lyx/lyxconvert_218.py,v retrieving revision 1.33 diff -u -p -r1.33 lyxconvert_218.py --- lyxconvert_218.py 14 Mar 2003 15:00:02 - 1.33 +++ lyxconvert_218.py 31 Mar 2003 15:53:53 - @@ -403,9 +403,13 @@ def remove_figinset(lines): else: display = "color" - subcaptionText = get_value(lines, "subcaption", i+1, j) - if subcaptionText != "": - subcaptionText = '"'+subcaptionText+'"' + subcaptionText = "" + subcaptionLine = find_token(lines, "subcaption", i+1, j) + if subcaptionLine != -1: +subcaptionText = lines[subcaptionLine][11:] + if subcaptionText != "": + subcaptionText = '"'+subcaptionText+'"' + k = find_token(lines, "subfigure", i+1,j) if k == -1: subcaption = 0
Re: [patch] Eight rowlist patch
Angus Leeming <[EMAIL PROTECTED]> writes: | > the prossess has been a lot harder than it aught to be. | > (millions of updates form cvs, fixing conflics, making tousands | > of trees... | | Did you come to any conclusions about alternatices to cvs? No. I am wary of projects that does not have a developer base. And projects that are not in stable state. And CVS is not that bad... so before switching it must be evident that we actually gain something by switching. -- Lgb
Re: [patch] Eight rowlist patch
Lars Gullik Bjønnes wrote: > Perhaps... but I have no X at the moment and need help to make sure > that I do not break something. More generally, I would say that the problem is that very few of the developers can afford to devote time to LyX during the working day. So you have to accept some considerable delay when requesting feedback. I will try to compile and run LyX this evening. If you haven't committed patches 7 and 8 between in the interim, then I'll apply them to my local tree. Incidentally: > the prossess has been a lot harder than it aught to be. > (millions of updates form cvs, fixing conflics, making tousands > of trees... Did you come to any conclusions about alternatices to cvs? -- Angus
Re: [patch] Eight rowlist patch
Angus Leeming <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: | > Perhaps but there has been seven other patches as well in this | > series, and not a lot of people have tried those... | | > And most of the patches (except the first two really) and just been | > dumb translating old constructs into new ones. | | Alfredo (and maybe John?) seemed to squash what bugs existed in the | first two patches. Thereafter people have looked at the patches and | said "what's to test". Perhaps ;-) Perhaps... but I have no X at the moment and need help to make sure that I do not break something. -- Lgb
Re: [patch] Eight rowlist patch
Lars Gullik Bjønnes wrote: > Perhaps but there has been seven other patches as well in this > series, and not a lot of people have tried those... > And most of the patches (except the first two really) and just been > dumb translating old constructs into new ones. Alfredo (and maybe John?) seemed to squash what bugs existed in the first two patches. Thereafter people have looked at the patches and said "what's to test". Perhaps ;-) > Only a couple of more patches to go now. Keep it up! -- Angus
Re: [Markus Grabner ] Re: [PATCH] lyx2lyx: subcaption in LyX file format 2.15
On Mon, Mar 31, 2003 at 03:34:40PM +0200, Jean-Marc Lasgouttes wrote: > It seems that John's patch does not work after all. Example file and > error trace below, thanks to Markus Grabner. Hmm, weird, I didn't get this on my test files. Maybe I just screwed up try this john Index: lyxconvert_218.py === RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/lyx2lyx/lyxconvert_218.py,v retrieving revision 1.33 diff -u -p -r1.33 lyxconvert_218.py --- lyxconvert_218.py 14 Mar 2003 15:00:02 - 1.33 +++ lyxconvert_218.py 31 Mar 2003 15:04:48 - @@ -403,9 +403,13 @@ def remove_figinset(lines): else: display = "color" - subcaptionText = get_value(lines, "subcaption", i+1, j) - if subcaptionText != "": - subcaptionText = '"'+subcaptionText+'"' + subcaptionText = "" + subcaptionLine = find_token(lines, "subcaption", i+1, j) + if subcaptionLine != -1: +subcaptionText = lines[subcaptionLine][11:] + if subcaptionText != "": + subcaptionText = '"'+subcaptionText+'"' + k = find_token(lines, "subfigure", i+1,j) if k == -1: subcaption = 0
CVS: insetgraphics.C:711: syntax error before `;'
gmake on current CVS:
[...]
insetgraphics.C:711: syntax error before `;'
insetgraphics.C:712: syntax error before `)'
gmake[3]: *** [insetgraphics.lo] Error 1
Please replace (line 711)
str += from + _(" format files to " + to;
by something like
str += from + _(" format files to ") + to;
and (line 712)
str += ".\nTry defining a convertor in the preferences.");
by
str += _(".\nTry defining a convertor in the preferences.");
Rob.
Re: [patch] Eight rowlist patch
Angus Leeming <[EMAIL PROTECTED]> writes:
| So, your request for people to try it out is pretty meaningless then.
| If it compiles all is well.
Perhaps but there has been seven other patches as well in this series,
and not a lot of people have tried those...
| Fair enough. So you aren't bothered about the unnecessary const_casts
| in the operator==() function either? I can't see any reason why this
| won't compile:
I don't see any reason to change it (now).
| bool operator==(RowList::const_iterator const & i1,
| RowList::const_iterator const & i2)
| {
| return &(*i1) == &(*i2);
| }
|
| Nonetheless, I have been very impressed by the manner in which you
| have applied these changes. I would have had no idea how to go about
| things in such a small step by small step manner.
I am not impressed, and the prossess has been a lot harder than it
aught to be. (millions of updates form cvs, fixing conflics, making
tousands of trees... my home box has not worked this hard for over a year.)
And most of the patches (except the first two really) and just been
dumb translating old constructs into new ones.
The one thing that has help the most with this, is the
RowList::iterator constructor that takes a Row*. with this is has been
possible to mix RowList::iterator and Row* pretty much all over.
Only a couple of more patches to go now.
--
Lgb
Re: [patch] Eight rowlist patch
Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | Lars Gullik Bjønnes wrote:
> |
> | > I have not tested this, but it compiles find. I am pretty
> | > certain it will just work. Please have a look at it. And try it
> | > out.
> |
> | You don't seem to have actually _used_ const_iterator anywhere in
> | the code. Maybe that's why nothing has broken?
>
> That is very intentional since comparing const_iterator and iterator
> is quite hard. So instead by introducing const_iterator I verify
> that we are not dependant on it.
So, your request for people to try it out is pretty meaningless then.
If it compiles all is well.
> This is supposed to ease the transition to the real
> std::list later.
>
> | One small thought about your patch. Does it not improve
> | readability to forward declare the iterator classes?
>
> Perhaps, but there is no point in doing that... in two patches time
> the whole RowList class will be replced with a
>
> typedef std::list RowList;
Fair enough. So you aren't bothered about the unnecessary const_casts
in the operator==() function either? I can't see any reason why this
won't compile:
bool operator==(RowList::const_iterator const & i1,
RowList::const_iterator const & i2)
{
return &(*i1) == &(*i2);
}
Nonetheless, I have been very impressed by the manner in which you
have applied these changes. I would have had no idea how to go about
things in such a small step by small step manner.
Regards,
--
Angus
Re: [patch] Eight rowlist patch
Angus Leeming <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: | | > I have not tested this, but it compiles find. I am pretty certain it | > will just work. Please have a look at it. And try it out. | | You don't seem to have actually _used_ const_iterator anywhere in the | code. Maybe that's why nothing has broken? That is very intentional since comparing const_iterator and iterator is quite hard. So instead by introducing const_iterator I verify that we are not dependant on it. This is supposed to ease the transition to the real std::list later. | One small thought about your patch. Does it not improve readability | to forward declare the iterator classes? Perhaps, but there is no point in doing that... in two patches time the whole RowList class will be replced with a typedef std::list RowList; -- Lgb
Re: [patch] Eight rowlist patch
Lars Gullik Bjønnes wrote:
> I have not tested this, but it compiles find. I am pretty certain it
> will just work. Please have a look at it. And try it out.
You don't seem to have actually _used_ const_iterator anywhere in the
code. Maybe that's why nothing has broken?
One small thought about your patch. Does it not improve readability
to forward declare the iterator classes?
class RowList {
public:
class iterator;
class const_iterator;
iterator begin();
iterator end();
const_iterator begin() const;
const_iterator end() const;
};
class RowList::iterator {
...
};
class RowList::const_iterator {
...
};
--
Angus
[patch] Eight rowlist patch
This patch introduces the RowList::const_iterator, and adjusts
functions to accomodate this. Fortunately by settign the rowlist_
mutable, all const reduction has been avoided in function prototypes.
I have not tested this, but it compiles find. I am pretty certain it
will just work. Please have a look at it. And try it out.
Index: po/POTFILES.in
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/po/POTFILES.in,v
retrieving revision 1.324
diff -u -p -r1.324 POTFILES.in
--- po/POTFILES.in 26 Mar 2003 15:55:51 - 1.324
+++ po/POTFILES.in 31 Mar 2003 13:47:49 -
@@ -29,9 +29,10 @@ src/frontends/controllers/helper_funcs.C
src/frontends/gnome/GLog.C
src/frontends/LyXView.C
src/frontends/qt2/Alert_pimpl.C
+src/frontends/qt2/BulletsModule.C
src/frontends/qt2/Dialogs.C
src/frontends/qt2/FileDialog.C
-src/frontends/qt2/lengthcombo.C
+src/frontends/qt2/floatplacement.C
src/frontends/qt2/QAbout.C
src/frontends/qt2/QBibitem.C
src/frontends/qt2/QBibtex.C
@@ -123,7 +124,6 @@ src/frontends/xforms/FormToc.C
src/frontends/xforms/FormUrl.C
src/frontends/xforms/FormVCLog.C
src/frontends/xforms/FormWrap.C
-src/frontends/xforms/input_validators.C
src/frontends/xforms/Menubar_pimpl.C
src/frontends/xforms/xformsBC.h
src/frontends/xforms/xforms_helpers.C
@@ -169,7 +169,6 @@ src/lyxfont.C
src/lyxfunc.C
src/lyx_main.C
src/lyxrc.C
-src/lyxtextclasslist.C
src/lyxvc.C
src/mathed/formulabase.C
src/mathed/formulamacro.C
@@ -181,8 +180,6 @@ src/paragraph.C
src/paragraph_funcs.C
src/ParagraphParameters.C
src/rowpainter.C
-src/support/filetools.C
-src/tabular.C
src/text2.C
src/text3.C
src/text.C
Index: src/RowList.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/RowList.C,v
retrieving revision 1.2
diff -u -p -r1.2 RowList.C
--- src/RowList.C 27 Mar 2003 12:41:46 - 1.2
+++ src/RowList.C 31 Mar 2003 13:47:49 -
@@ -79,6 +79,81 @@ bool operator!=(RowList::iterator const
}
+// The RowList::const_iterator
+
+RowList::const_iterator::const_iterator()
+ : ptr(0)
+{}
+
+
+RowList::const_iterator::const_iterator(Row * p)
+ : ptr(p)
+{}
+
+
+RowList::const_iterator::const_reference
+RowList::const_iterator::operator*()
+{
+ return *ptr;
+}
+
+
+RowList::const_iterator::const_pointer
+RowList::const_iterator::operator->()
+{
+ return ptr;
+}
+
+
+RowList::const_iterator &
+RowList::const_iterator::operator++()
+{
+ ptr = ptr->next();
+ return *this;
+}
+
+
+RowList::const_iterator
+RowList::const_iterator::operator++(int)
+{
+ const_iterator tmp = *this;
+ ++*this;
+ return tmp;
+}
+
+
+RowList::const_iterator &
+RowList::const_iterator::operator--()
+{
+ ptr = ptr->previous();
+ return *this;
+}
+
+
+RowList::const_iterator
+RowList::const_iterator::operator--(int)
+{
+ const_iterator tmp = *this;
+ --*this;
+ return tmp;
+}
+
+
+bool operator==(RowList::const_iterator const & i1,
+ RowList::const_iterator const & i2)
+{
+ return &(*const_cast(i1))
+ == &(*const_cast(i2));
+}
+
+
+bool operator!=(RowList::const_iterator const & i1,
+ RowList::const_iterator const & i2)
+{
+ return !(i1 == i2);
+}
+
+
// The RowList proper
RowList::RowList()
: rowlist(0)
@@ -144,9 +219,9 @@ RowList::iterator RowList::begin()
}
-RowList::iterator RowList::begin() const
+RowList::const_iterator RowList::begin() const
{
- return iterator(rowlist);
+ return const_iterator(rowlist);
}
@@ -156,9 +231,9 @@ RowList::iterator RowList::end()
}
-RowList::iterator RowList::end() const
+RowList::const_iterator RowList::end() const
{
- return iterator();
+ return const_iterator();
}
@@ -189,12 +264,6 @@ Row & RowList::back()
while (tmp->next())
tmp = tmp->next();
return *tmp;
-}
-
-
-void RowList::set(Row * p)
-{
- rowlist = p;
}
Index: src/RowList.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/RowList.h,v
retrieving revision 1.1
diff -u -p -r1.1 RowList.h
--- src/RowList.h 26 Mar 2003 11:04:29 - 1.1
+++ src/RowList.h 31 Mar 2003 13:47:49 -
@@ -44,6 +44,39 @@ public:
Row * ptr;
};
///
+ class const_iterator {
+ public:
+ ///
+ typedef std::bidirectional_iterator_tag iterator_category;
+ ///
+ typedef Row * value_type;
+ ///
+ typedef ptrdiff_t difference_type;
+ ///
+ typedef Row const * const_pointer;
+ ///
+ typedef Row const & const_reference;
+ ///
+ const_iterator();
+ ///
+ const_iterator(value_type);
+ ///
+ const_reference operator*();
+ ///
+ const_pointer operator->();
+ ///
+ const_iterator & operator++();
+ ///
+ const_iterator operator++(int);
+ ///
+ const_iterator & operator--();
+ ///
+ const_iterator operator--(int);
+ private:
+ ///
+ Row * ptr;
+ };
+ ///
RowList();
///
iterator insert(iterator it, Row * row);
@@ -54,13 +87,11 @@ public:
///
iterator begin();
///
- iterator begin() const;
+ const_iterator begi
Re: [PATCH] lyx2lyx: subcaption in LyX file format 2.15
> "José" == José Matos <[EMAIL PROTECTED]> writes: José> On Friday 28 March 2003 17:54, John Levon wrote: >> > What is the status of that? Is it supposed to be safe now? >> >> Jose said "it was probably OK" or something. It works for me ... >> but I don't know python José> The original code is from Dekel, John's fix looks reasonable José> to me and I would need to see different cases to fully assert José> the validity of the patch. José> That said I think that Jonh code is correct, is deals with one José> missing case that is not dealt now, so it should go. Unfortunately this is false :( See the message I forwarded a minute ago. JMarc
[Markus Grabner ] Re: [PATCH] lyx2lyx: subcaption in LyX file format 2.15
It seems that John's patch does not work after all. Example file and error trace below, thanks to Markus Grabner. JMarc --- Begin Message --- Jean-Marc Lasgouttes wrote: >>"John" == John Levon <[EMAIL PROTECTED]> writes: > > > John> On Mon, Mar 24, 2003 at 01:38:49AM +0100, Markus Grabner wrote: > >>>LyX 1.3.0 and 1.3.1 can't correctly import subfigure captions >>>stored in the ancient lyx 2.15 file format. Subfigure captions are >>>only read up to the first whitespace character, the rest is >>>ignored. > > > John> Here's a fix. lyx2lyx people, please look and OK or fix up > John> yourself > > John> JMarc, this is a dataloss, probably wanted for 1.3.2 > > What is the status of that? Is it supposed to be safe now? Sorry to say, but right after I reported success, I received a file by a student which works with the unmodified converter, but crashes the modified one :-( The offending file and the error message are attached. Kind regards, Markus -- Markus Grabner - Computer Graphics and Vision Graz University of Technology, Inffeldgasse 16/II, 8010 Graz, Austria Phone: +43/316/873-5041, Fax: +43/316/873-5050 Email: [EMAIL PROTECTED], WWW: http://www.icg.tu-graz.ac.at/~grabner #LyX 1.1 created this file. For more info see http://www.lyx.org/ \lyxformat 218 \textclass article \language english \inputencoding auto \fontscheme default \graphics default \paperfontsize default \spacing single \papersize Default \paperpackage a4 \use_geometry 0 \use_amsmath 0 \paperorientation portrait \secnumdepth 3 \tocdepth 3 \paragraph_separation indent \defskip medskip \quotes_language english \quotes_times 2 \papercolumns 1 \papersides 1 \paperpagestyle default \layout Standard ABSTRACT \layout Standard In this document we present a viewer for the visualization of archeological sites. This viewer - in contrast to many other available viewers - is specialized to the needs of digital archeology and thus brings the needed functions of navigation without the inconvenience of losing the watched objects in 3d-space or being able to walk through solid walls. \layout Standard So the main focus in this project is the good usability of the provided viewing functions as most of the archeologists that will be using our tool are not yet very familiar with computers. This is achieved by an elaborate user interface, the use of collision-detection and terrain-tracking and last but not least by multi-resolution algorithms that make it possible to adapt to slow data transfer rates when using the online database of the excavation site. \layout Standard Another important point is the size of the viewer. It is planned to make it available as a downloadable browser-plugin, which of course restricts the maximum size of the whole program. \layout Section Introduction \layout Standard Most of the available VRML-viewers are multi-purpose tools. That's good as long as the user accepts the possibility of finding himself standing amidst a solid wall or losing the scene in 3-dimensional space because of a navigation error. Some users also feel uncomfortable navigating through the scene, because the user-interface often isn't really intuitive. Of course such multi-purpose-tools cannot do their work right for every task. \layout Standard In archeology the tasks of a viewing tool are well defined. For example, walls are composed of textured triangles. Every triangle has two sides. But no one is interested in viewing a wall from the inside because it's irrelevant in reality. So anti-collision algorithms are used that would possibly restrict the usability of a multi-purpose tool too much. \layout Standard Another important point is the definition of the scene. Of Course the easiest way is to define one scene that contains all the faces and textures. But if take into account that this scene should be transmitted using slow internet connections, some additional thoughts concerning multi-resolution are worth the effort. Again it's clear that it makes sense to use specialized tools for these requirements. \layout Standard One of the most difficult problems for novice users is to learn to navigate within a virtual reality scene using the mouse and the keyboard. We specified a user interface that should make navigation easy even for people who are not familiar with common 3d software or games. \layout Section Implementation \layout Standard For the implementation we used the qt-library which provides support for browser-plugins by utilizing Netscapes Plug-in SDK. Also OpenGL is well supported by qt. So this is the ideal base for such projects. Another advantage is the availability for many different platforms (Linux, Windows, Mac, ...) which makes it much easier to port the software - an important aspect if it should work as plugin. \layout Section Navigation \layout Standard There are several different navigation-modes the user can choose from. In each mode the mot
Re: xforms
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Jean-Marc Lasgouttes wrote: * how much work is involved. John> I guess you intend to keep xforms in mostly "maintenance mode", John> CJK stuff aside. I suspect you won't find it too onerous then. >> I think you should really restricts yourself to maintenance mode, >> since we are using only a subset of xforms (some people seem to >> like opengl support, for example), larger changes may be dangerous. Angus> I would have no intention of doing anything more than Angus> maintenance of the existing code base were I to become the Angus> maintainer. Something that may be useful is the transition to autoconf and friends. Compiling xforms with non default settings is ridiculously complicated. Angus> Anyway, everything is on hold for the time being. It seems that Angus> the xforms mailing list is currently really sick since I got an Angus> "unable to deliver your mail after 4 hours will continue trying Angus> for 5 days" nessage over the weekend. Super. JMarc
current cvs
To compile without USE_BOOST_FORMAT
Index: insets/insetgraphics.C
===
RCS file: /cvs/lyx/lyx-devel/src/insets/insetgraphics.C,v
retrieving revision 1.163
diff -u -p -u -r1.163 insetgraphics.C
--- insets/insetgraphics.C 2003/03/31 02:59:34 1.163
+++ insets/insetgraphics.C 2003/03/31 11:43:47
@@ -708,8 +708,8 @@ string const InsetGraphics::prepareFile(
string str = fmt.str();
#else
string str = _("No information for converting ");
- str += from + _(" format files to " + to;
- str += ".\nTry defining a convertor in the
preferences.");
+ str += from + _(" format files to ") + to;
+ str += _(".\nTry defining a convertor in the
preferences."
);
#endif
Alert::error(_("Could not convert image"), str);
}
Re: xforms
Jean-Marc Lasgouttes wrote: >>> * how much work is involved. > John> I guess you intend to keep xforms in mostly > John> "maintenance mode", CJK stuff aside. I suspect > John> you won't find it too onerous then. > I think you should really restricts yourself to maintenance mode, > since we are using only a subset of xforms (some people seem to like > opengl support, for example), larger changes may be dangerous. I would have no intention of doing anything more than maintenance of the existing code base were I to become the maintainer. Anyway, everything is on hold for the time being. It seems that the xforms mailing list is currently really sick since I got an "unable to deliver your mail after 4 hours will continue trying for 5 days" nessage over the weekend. -- Angus
Re: Input Combox Widget
Thanks for the feedback. I think that I've come to the conclusion that it really isn't a widget after all. I'll try and write it as an xforms demo program instead. That just leaves fdesign support and some documentation and it'll be ready for the big time. (Of all 10 people who use xforms for their app ;-) -- Angus
Re: [PATCH] lyx2lyx: subcaption in LyX file format 2.15
On Friday 28 March 2003 17:54, John Levon wrote: > > What is the status of that? Is it supposed to be safe now? > > Jose said "it was probably OK" or something. It works for me ... but I > don't know python The original code is from Dekel, John's fix looks reasonable to me and I would need to see different cases to fully assert the validity of the patch. That said I think that Jonh code is correct, is deals with one missing case that is not dealt now, so it should go. > john -- José Abílio
Re: kill DEP/SM again
Jean-Marc Lasgouttes wrote: I am not sure you understand what people use in real-life documents. I have already seen some scary lyx files, and I indeed think this is going to get worse with what you propose. I use paragraph spacing in my book, knowing how this work. I often use ctrl+enter to make room for a signature when writing a one-page letter though. Because it is so simple and easy to do, and I know it won't go wrong in a single-page thing anyway. Having an easier way to do this would be nice, preferably something that don't involve a menu or popup. It would then be as easy as ctrl+enter. Currently, extra spacing is shown as ^ | 2.5 cm/ex/in/bigskip/. . . v Ability to edit that number directly by clicking on it would be nice. (instead of layout->paragraph->popupwindow) I guess showing a ^ | v in _every_ paragraph break is asking too much, as some styles use indenting instead. But bringing this up should be simple, perhaps bound to some key. If such direct editing of distances is ever implemented. Helge Hafting
Re: kill DEP/SM again
Alfredo Braunstein wrote: Lars Gullik Bjønnes wrote: | 1) respect user decision We don't want to respect user decision. With this I don't agree... but We are not we i guess. If the user is visually informed about what's happening, I don't see why not. The user wants a nice document, I guess everybode respects that. But many a user don't know enough to make an informed choice. Formatting using blank lines etc. may work for the specific case of filling out a form, but it breaks down badly when you write a many-page document and don't know in advance where the page breaks will be. Multi-page documents is the common case that should work well easily. For those that haven't tried - make a document where every paragraph is separated with three blank lines (ctrl+enter) instead of increasing the paragraph spacing. Print it and notice how the page breaks sometimes gets in the middle of such a sequence occationally leaving you with a blank line or two at the top of a page. Using large paragraph spacing has the advantage that latex knows that it isn't supposed to put such spacing at the top or bottom of pages. The page break is space enough for all cases. Perhaps this explanation ought to be somewhere in the documentation, an informative message could then refer to it. Helge Hafting
Re: menubackend.defaults
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> Can we just remove this ? It's useless. We should just error John> out. Same goes for all other system files that must exist in John> lyx_main.C I think we should remove this fallback stuff (also for toolbars). We should probably make sure that LyX works nevertheless. There are people who would be interested in having no toolbar, for example. I assume it is not very easy in xforms, but I am sure that qt can do that. JMarc
Re: XForms: patches
Jean-Marc Lasgouttes wrote: >> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > Angus> Here is the result of my probings. The only difference that I > Angus> can ascertain between the two logs on baywatch (for mails > Angus> posted using kmail's SMTP and sendmail respectively) is the > Angus> address. > > Angus> kmail SMTP from=<[EMAIL PROTECTED]> sendmail > Angus> from=<[EMAIL PROTECTED]> > > I think the key is the following assertion from the mailing list page: > > Posting to the xforms list is restricted to subscribed addresses to > stop spammers from abusing the list. > > Indeed, I am subscribed as [EMAIL PROTECTED], but I post as > [EMAIL PROTECTED] The only problem is that the mailaing > list software silently rejects the messages :( Well I definitely post to xforms as [EMAIL PROTECTED] However, as Lars says, I have to fix my sendmail MASQUERADE_AS amd envelope stuff so that reflects this. -- Angus
Re: lyxrc.auto_reset_options
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> It loses exactly these : John> sides columns pagestyle options secnumdepth tocdepth John> Now, of all these, "options" is the only one I can really think John> of being annoyed at losing. what classes set a non-empty John> "options" ? "sides" (which is 1 in article) can be annoying, pagestyle too. JMarc
Re: xforms
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> On Fri, Mar 28, 2003 at 07:39:27PM +, Angus Leeming wrote: >> * how much work is involved. John> I guess you intend to keep xforms in mostly "maintenance mode", John> CJK stuff aside. I suspect you won't find it too onerous then. I think you should really restricts yourself to maintenance mode, since we are using only a subset of xforms (some people seem to like opengl support, for example), larger changes may be dangerous. Of course, you could implement a real menubar, themes, and translucent windows... >> * where to host the repository (on baywatch or on sourceforge?) John> I think sourceforge would be more appropriate, or one of the John> equivalents. Yes. JMarc
Re: XForms: patches
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Here is the result of my probings. The only difference that I Angus> can ascertain between the two logs on baywatch (for mails Angus> posted using kmail's SMTP and sendmail respectively) is the Angus> address. Angus> kmail SMTP from=<[EMAIL PROTECTED]> sendmail Angus> from=<[EMAIL PROTECTED]> I think the key is the following assertion from the mailing list page: Posting to the xforms list is restricted to subscribed addresses to stop spammers from abusing the list. Indeed, I am subscribed as [EMAIL PROTECTED], but I post as [EMAIL PROTECTED] The only problem is that the mailaing list software silently rejects the messages :( JMarc
