Re: patches
Lars Gullik Bjønnes wrote: > If you tested it, then yes. Tested now and applied. Regards, Alfredo
Re: [PATCH] Branch/Note "final"
Martin Vermeer wrote: > Yellow on grey is *awful*. The yellow is surely from the association with > MMM Post-It (TM). It'd be nice if we could have a custom background color for inset buttons. > Actually why a distinction? They are a lot more similar > than different. Compared to footnote, branch etc, etc. that is. It is not important. BTW, keep in mind that the (old) comment environment is redundant now. Juergen.
Re: [PATCH] QNote
Lars Gullik Bjønnes wrote: > Yes, Juergen can have a CVS account. Oh... thanks. > But I am a bit pressed for free time at the moment. It's certainly not urgent. Juergen.
Re: patches
Alfredo Braunstein <[EMAIL PROTECTED]> writes: | Juergen Spitzmueller wrote: | | > This would be it. Works very well in text3.C (normal text) and insettext | > (tested inside footnotes, minipages). | | OK to apply? If you tested it, then yes. -- Lgb
Re: Assert
Andre Poenitz <[EMAIL PROTECTED]> writes:
| I think there are a few places in InsetText that are never reached.
| Should I put in a lyxerr<< or an Assert or ...?
|
|
| I.e.
I think Assert.
perhaps we should have an Assert with message?
| LyXCursor const & InsetText::cursor(BufferView * bv) const
| {
| if (the_locking_inset) {
| lyxerr << "InsetText::cursor(). Should not happen!\n";
| return the_locking_inset->cursor(bv);
| }
| return getLyXText(bv)->cursor;
| }
|
| Andre'
|
--
Lgb
Re: [PATCH] QNote
John Levon <[EMAIL PROTECTED]> writes: | On Mon, Jul 14, 2003 at 04:32:52PM +0200, Juergen Spitzmueller wrote: | | > > Looks fine. Lars, can Juergen have a CVS account for stuff like this | > > please ? | > | > Can you please apply it otherwise, John? | | I'm lazy enough to give Lars a while more to respond ... if he's not | shown up by the end of the day I'll apply it Yes, Juergen can have a CVS account. But I am a bit pressed for free time at the moment. -- Lgb
Re: why cut->paste text from other documents = blue underlined?
On Tue, Jul 15, 2003 at 12:39:48AM +0100, John Levon wrote: > > >, it is desired that LyX should automatically change the language of > > the copied text to American, and then the user should fix the spelling. > > And what if it's *not* intended to be a single-language document ? You > just broke my document ... Admittedly, there is something conceptually to the argument that a Document Setting of language specification (as opposed to a Text Style language specification) ought not to travel with copied text, just as a Document Setting of font size 12 would not travel with copied text and render LARGE text in a font size 10 document. This special treatment of the document level language specification surprised me at first, but now I understand it and can work around it. Obviously, the way it works now addresses a certain set of problems, which would return if it worked the other way.
Re: why cut->paste text from other documents = blue underlined?
On Tue, Jul 15, 2003 at 12:13:00AM +0300, Dekel Tsur wrote: > Actually, single-language documents are more common than multiple-language > documents. Yes. But they're irrelevant - when I'm working with a single language, I never see the blue underline, because there is only one language :) > Thus, when someone copy text from, e.g., British document to an American > document But then it's not a single-language document. >, it is desired that LyX should automatically change the language of > the copied text to American, and then the user should fix the spelling. And what if it's *not* intended to be a single-language document ? You just broke my document ... I do not see a way we can change language behind the user's back in a reliable manner, and I don't think we should. regards john
Re: why cut->paste text from other documents = blue underlined?
Dekel Tsur wrote: > > On Mon, Jul 14, 2003 at 12:11:49AM +0100, John Levon wrote: > > On Sun, Jul 13, 2003 at 07:57:43AM -0700, [EMAIL PROTECTED] wrote: > > > > > By the way, if you would consider the carrying over of a language specification > > > in a cut/paste operation to be in any manner a bug, let me know and I'll file a > > > report. > > > > It's fully intentional exactly to help avoid color vs. colour problems > > Actually, single-language documents are more common than multiple-language > documents. > Thus, when someone copy text from, e.g., British document to an American > document, it is desired that LyX should automatically change the language of > the copied text to American, and then the user should fix the spelling. The problem is that you need to see some indication of which parts of the text have changed so you know what to spellcheck. It would be nice if the spellchecker could check just marked text. Also, if I am inserting a British quote, I usually keep the British spelling even if it is an American document. The "best" solution is not obvious to me. Garst
Re: why cut->paste text from other documents = blue underlined?
On Mon, Jul 14, 2003 at 12:11:49AM +0100, John Levon wrote: > On Sun, Jul 13, 2003 at 07:57:43AM -0700, [EMAIL PROTECTED] wrote: > > > By the way, if you would consider the carrying over of a language specification > > in a cut/paste operation to be in any manner a bug, let me know and I'll file a > > report. > > It's fully intentional exactly to help avoid color vs. colour problems Actually, single-language documents are more common than multiple-language documents. Thus, when someone copy text from, e.g., British document to an American document, it is desired that LyX should automatically change the language of the copied text to American, and then the user should fix the spelling.
Re: why cut->paste text from other documents = blue underlined?
On Sun, Jul 13, 2003 at 11:34:21PM -0700, [EMAIL PROTECTED] wrote: > On Sun, Jul 13, 2003 at 03:15:26PM -0300, Garst R. Reese wrote: > > ...Preferences->Lang Opts>Language>Mark foreign <> > > Thanks. Couldn't find that one. With this available, the function > certainly makes sense. This will just hide the "problem". It is better to leave this button enabled, and use the character dialog to reset the language after pasting from another document.
Re: another resize problem
Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
>>> Random question: Is there an intended difference between
>>> "rowlist_.clear(); init(bv)" and "init(bv, true)"? Both are used, but
>>> are slightly different.
>>
>> None that I've understood so far. Which, of course, doesn't mean there
>> wasn't a reason.
Effectively, it seems there's no need for a difference. The attached patch
seems to work fine (will test it a little more though).
Regards, Alfredo
Index: lyxtext.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxtext.h,v
retrieving revision 1.185
diff -u -p -u -r1.185 lyxtext.h
--- lyxtext.h 10 Jul 2003 08:00:37 - 1.185
+++ lyxtext.h 14 Jul 2003 18:40:37 -
@@ -59,7 +59,7 @@ public:
/// sets inset as owner
LyXText(BufferView *, InsetText *);
- void init(BufferView *, bool reinit = false);
+ void init(BufferView *);
///
int height;
///
Index: text2.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text2.C,v
retrieving revision 1.383
diff -u -p -u -r1.383 text2.C
--- text2.C 14 Jul 2003 15:17:38 - 1.383
+++ text2.C 14 Jul 2003 18:40:40 -
@@ -81,16 +81,14 @@ LyXText::LyXText(BufferView * bv, InsetT
}
-void LyXText::init(BufferView * bview, bool reinit)
+void LyXText::init(BufferView * bview)
{
bv_owner = bview;
- if (reinit) {
- rowlist_.clear();
- need_break_row = rows().end();
- width = height = 0;
- clearPaint();
- } else if (!rowlist_.empty())
- return;
+
+ rowlist_.clear();
+ need_break_row = rows().end();
+ width = height = 0;
+ clearPaint();
anchor_row_ = rows().end();
anchor_row_offset_ = 0;
@@ -100,9 +98,9 @@ void LyXText::init(BufferView * bview, b
current_font = getFont(bview->buffer(), pit, 0);
- for (; pit != end; ++pit) {
+ for (; pit != end; ++pit)
insertParagraph(pit, rowlist_.end());
- }
+
setCursorIntern(rowlist_.begin()->par(), 0);
selection.cursor = cursor;
@@ -728,7 +726,6 @@ void LyXText::redoParagraphs(LyXCursor c
void LyXText::fullRebreak()
{
- rows().clear();
init(bv());
setCursorIntern(cursor.par(), cursor.pos());
}
Index: insets/insettext.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insettext.C,v
retrieving revision 1.426
diff -u -p -u -r1.426 insettext.C
--- insets/insettext.C 14 Jul 2003 17:50:00 - 1.426
+++ insets/insettext.C 14 Jul 2003 18:40:45 -
@@ -1999,7 +1999,7 @@ void InsetText::resizeLyXText(BufferView
// no data, resize not neccessary!
// we have to do this as a fixed width may have changed!
saveLyXTextState();
- text_.init(bv, true);
+ text_.init(bv);
restoreLyXTextState();
return;
}
@@ -2020,7 +2020,7 @@ void InsetText::resizeLyXText(BufferView
const_cast(paragraphs).end(),
boost::bind(&Paragraph::resizeInsetsLyXText, _1, bv));
- text_.init(bv, true);
+ text_.init(bv);
restoreLyXTextState();
if (the_locking_inset) {
@@ -2052,7 +2052,7 @@ void InsetText::reinitLyXText() const
const_cast(paragraphs).end(),
boost::bind(&Paragraph::resizeInsetsLyXText, _1, bv));
- text_.init(bv, true);
+ text_.init(bv);
restoreLyXTextState();
if (the_locking_inset) {
inset_x = cix(bv) - top_x + drawTextXOffset;
BranchList class for comment
Attached.
Martin V
--
Martin Vermeer [EMAIL PROTECTED]
Helsinki University of Technology
Dept. of Surveying, Inst. of Geodesy
P.O. Box 1200, FIN-02015 HUT, Finland
:wq
// -*- C++ -*-
/* This file is part of
* ==
*
* LyX, The Document Processor
*
* Copyright 1995 Matthias Ettrich
* Copyright 1995-2001 The LyX Team.
*
*
* == */
/**
* \class Branch
*
* A class describing a 'branch', i.e., a named alternative for
* selectively outputting some parts of a document while suppressing
* other parts.
*
* A branch has a name, can either be selected or not, and uses a
* user-specifyable background colour. All these can be set and
* queried.
*
* \class BranchList
*
* A class containing a vector of all defined branches within a
* document. Has methods for selecting or deselecting branches by
* name, for outputting a '|'-separated string of all elements or only
* the selected ones, and for adding and removing elements.
*/
#ifndef BRANCHES_H
#define BRANCHES_H
#include "LString.h"
#include "LColor.h"
#include
class Branch {
public:
///
string getBranch() const;
///
void setBranch(string const &);
///
bool getSelected() const;
///
void setSelected(bool);
///
LColor::color getColor() const;
///
void setColor(LColor::color const &);
private:
///
string branch_;
///
bool selected_;
///
LColor::color color_;
};
class BranchList {
public:
///
typedef std::vector List;
///
void select(string const &);
///
void deselect(string const &);
///
void add(string const &);
///
void remove(string const &);
///
bool selected(string const &);
///
string allBranches();
///
string allSelected();
private:
///
List list;
};
#endif
/* This file is part of
* ==
*
* LyX, The Document Processor
*
* Copyright 1995 Matthias Ettrich
* Copyright 1995-2001 The LyX Team.
*
*
* == */
#include "BranchList.h"
using std::vector;
string Branch::getBranch() const
{
return branch_;
}
void Branch::setBranch(string const & s)
{
branch_ = s;
}
bool Branch::getSelected() const
{
return selected_;
}
void Branch::setSelected(bool b)
{
selected_ = b;
}
LColor::color Branch::getColor() const
{
return color_;
}
void Branch::setColor(LColor::color const & c)
{
color_ = c;
}
void BranchList::select(string const & s)
{
List::iterator it = list.begin();
List::iterator end = list.end();
for (; it != end; it++) {
if (s.find(it->getBranch(), 0) != string::npos)
it->setSelected(true);
}
}
void BranchList::deselect(string const & s)
{
List::iterator it = list.begin();
List::iterator end = list.end();
for (; it != end; it++) {
if (s.find(it->getBranch(), 0) != string::npos)
it->setSelected(false);
}
}
void BranchList::add(string const & s)
{
Branch br;
br.setBranch(s);
br.setSelected(false);
br.setColor(LColor::none);
list.push_back();
}
void BranchList::remove(string const & s)
{
List::iterator it = list.begin();
List::iterator end = list.end();
for (; it != end; it++) {
if (it->getBranch() == s) list.erase(it);
}
}
bool BranchList::selected(string const & s)
{
List::iterator it = list.begin();
List::iterator end = list.end();
for (; it != end; it++) {
if (s == it->getBranch())
return true;
}
return false;
}
string BranchList::allBranches()
{
List::iterator it = list.begin();
List::iterator end = list.end();
string ret;
string ch = "|";
for (; it != end; it++) {
ret += it->getBranch() + ch;
}
// remove final '|':
unsigned i = ret.find_last_of(ch);
if (i != string::npos)
ret.erase(i);
return ret;
}
string BranchList::allSelected()
{
List::iterator it = list.begin();
List::iterator end = list.end();
string ret;
string ch = "|";
for (; it != end; it++) {
if (it->getSelected())
ret += it->getBranch() + ch;
}
// remove final '|':
unsigned i = ret.find_last_of(ch);
if (i != string::npos)
ret.erase(i);
return ret;
}
pgp0.pgp
Description
Re: patches
Juergen Spitzmueller wrote: > This would be it. Works very well in text3.C (normal text) and insettext > (tested inside footnotes, minipages). OK to apply? Alfredo
Re: [PATCH] Branch/Note "final"
On Wed, Jul 09, 2003 at 09:34:45AM +0200, Juergen Spitzmueller spake thusly:
> Martin Vermeer wrote:
> > Note patch committed! (and I didn't forget the changelog :)
>
> Some comments:
>
> 1. greyedout code is still wrong.
> You are using
> \textcolor[gray]{0.8}{
> }
> which breaks latex as soon as you have more than one paragraph (or a
> non-standard paragraph).
> Use
> \color[gray]{0.8}
>
> \normalcolor
> instead.
Oops. Patch attached. OK to go in?
> 2. It would be nice to have an lfun with argument
> note-insert [note|comment|greyedout]
> (I'd like to use comment as default).
Yes, wouldn't it :-) I'll keep it in the back of my mind.
> 3. Probably a visual distinction between note and comment (yellow/magenta?)
> would be nice. BTW though this is not your doing, yellow text on grey
> background (i.e. the button) is not what I'd call readable (or even, what it
> is supposed to be, eye catching).
Yellow on grey is *awful*. The yellow is surely from the association with MMM
Post-It (TM). Actually why a distinction? They are a lot more similar
than different. Compared to footnote, branch etc, etc. that is.
> Regards,
> Juergen.
>
t. Martin
Index: insetnote.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetnote.C,v
retrieving revision 1.27
diff -u -p -r1.27 insetnote.C
--- insetnote.C 8 Jul 2003 14:19:25 - 1.27
+++ insetnote.C 14 Jul 2003 18:20:58 -
@@ -143,7 +143,7 @@ int InsetNote::latex(Buffer const * buf,
int i = 0;
if (pt == "Comment") os << "%\n\\begin{comment}\n"; // remember to validate
- if (pt == "Greyedout") os << "%\n\\textcolor[gray]{0.8}{";
+ if (pt == "Greyedout") os << "%\n\\color[gray]{0.8}";
if (pt != "Note") {
i = inset.latex(buf, os, runparams);
}
@@ -152,7 +152,7 @@ int InsetNote::latex(Buffer const * buf,
i += 3;
}
if (pt == "Greyedout") {
- os << "%\n}";
+ os << "\\normalcolor%\n}";
i += 2;
}
return i;
pgp0.pgp
Description: PGP signature
Re: [patch] hide RowPainter
On Mon, Jul 14, 2003 at 06:40:10PM +0100, John Levon wrote: > > Note that the current split in 'constructor' and function call > > is rather arbitrary. > > I know ... most of the state is ugly crap anyway though... As long as it is as self-cointained as it is right now there is not too much to worry... Well... we could think about changing most of the 'float' to 'int' and the rest to 'double'... float really has no benefit there... > > Ok. 'paintRows' perhaps? > > Sweet. Done. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: [patch] hide RowPainter
On Mon, Jul 14, 2003 at 07:39:51PM +0200, Andre Poenitz wrote: > > Suppose so. I don't like so many parameters though, > > Note that the current split in 'constructor' and function call > is rather arbitrary. I know ... most of the state is ugly crap anyway though... > Ok. 'paintRows' perhaps? Sweet. regards john
Re: [patch] hide RowPainter
On Mon, Jul 14, 2003 at 06:32:58PM +0100, John Levon wrote: > On Mon, Jul 14, 2003 at 07:03:05PM +0200, Andre Poenitz wrote: > > > I thought it could be moved behind a single > > > > void paint(BufferView const & bv, LyXText const & text, > > RowList::iterator rit, int y_offset, int x_offset, int y) > > Suppose so. I don't like so many parameters though, Note that the current split in 'constructor' and function call is rather arbitrary. > and I find the idea > of a namespace-polluting paint() a bit dodgy ... Ok. 'paintRows' perhaps? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: [patch] hide RowPainter
On Mon, Jul 14, 2003 at 07:03:05PM +0200, Andre Poenitz wrote: > I thought it could be moved behind a single > > void paint(BufferView const & bv, LyXText const & text, > RowList::iterator rit, int y_offset, int x_offset, int y) Suppose so. I don't like so many parameters though, and I find the idea of a namespace-polluting paint() a bit dodgy ... regards john
Re: Assert
Andre Poenitz wrote: > I think there are a few places in InsetText that are never reached. > Should I put in a lyxerr<< or an Assert or ...? I'm for the assert. Alfredo
[patch] hide RowPainter
As all RowPainter usage follows the mantra
RowPainter painter(bv, text, rit);
painter.paint(y_offset, x_offset, y);
I thought it could be moved behind a single
void paint(BufferView const & bv, LyXText const & text,
RowList::iterator rit, int y_offset, int x_offset, int y)
function.
This cuts down rowpainter.h to a minimum...
Ok?
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Index: rowpainter.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/rowpainter.C,v
retrieving revision 1.21
diff -u -p -r1.21 rowpainter.C
--- rowpainter.C30 Jun 2003 23:55:57 - 1.21
+++ rowpainter.C14 Jul 2003 16:57:21 -
@@ -54,8 +54,77 @@ BufferView * perv(BufferView const & bv)
return const_cast(&bv);
}
-} // namespace anon
-
+/**
+ * A class used for painting an individual row of text.
+ */
+class RowPainter {
+public:
+ /// initialise painter
+ RowPainter(BufferView const & bv, LyXText const & text, RowList::iterator rit);
+
+ /// paint the row.
+ void paint(int y_offset, int x_offset, int y);
+
+private:
+ // paint various parts
+ void paintBackground();
+ void paintSelection();
+ void paintAppendix();
+ void paintDepthBar();
+ void paintChangeBar();
+ void paintFirst();
+ void paintLast();
+ void paintForeignMark(float const orig_x, LyXFont const & orig_font);
+ void paintHebrewComposeChar(lyx::pos_type & vpos);
+ void paintArabicComposeChar(lyx::pos_type & vpos);
+ void paintChars(lyx::pos_type & vpos, bool hebrew, bool arabic);
+ int paintPageBreak(string const & label, int y);
+ int paintAppendixStart(int y);
+ int paintLengthMarker(string const & prefix, VSpace const & vsp, int start);
+ void paintText();
+ void paintFromPos(lyx::pos_type & vpos);
+ void paintInset(lyx::pos_type const pos);
+
+ /// return left margin
+ int leftMargin() const;
+
+ /// return the font at the given pos
+ LyXFont const getFont(lyx::pos_type pos) const;
+
+ /// return the label font for this row
+ LyXFont const getLabelFont() const;
+
+ char const transformChar(char c, lyx::pos_type pos) const;
+
+ /// return pixel width for the given pos
+ int singleWidth(lyx::pos_type pos) const;
+ int singleWidth(lyx::pos_type pos, char c) const;
+
+ /// bufferview to paint on
+ BufferView const & bv_;
+
+ /// Painter to use
+ Painter & pain_;
+
+ /// LyXText for the row
+ LyXText const & text_;
+
+ /// The row to paint
+ RowList::iterator row_;
+
+ /// Row's paragraph
+ mutable ParagraphList::iterator pit_;
+
+ // Looks ugly - is
+ int xo_;
+ int yo_;
+ float x_;
+ int y_;
+ int width_;
+ float separator_;
+ float hfill_;
+ float label_hfill_;
+};
RowPainter::RowPainter(BufferView const & bv,
LyXText const & text, RowList::iterator rit)
@@ -480,27 +549,6 @@ void RowPainter::paintDepthBar()
}
-int getLengthMarkerHeight(BufferView const & bv, VSpace const & vsp)
-{
- if (vsp.kind() == VSpace::NONE)
- return 0;
-
- int const arrow_size = 4;
- int const space_size = int(vsp.inPixels(bv));
-
- LyXFont font;
- font.decSize();
- int const min_size = max(3 * arrow_size,
- font_metrics::maxAscent(font)
- + font_metrics::maxDescent(font));
-
- if (vsp.length().len().value() < 0.0)
- return min_size;
- else
- return max(min_size, space_size);
-}
-
-
int RowPainter::paintLengthMarker(string const & prefix, VSpace const & vsp, int
start)
{
if (vsp.kind() == VSpace::NONE)
@@ -1007,4 +1055,37 @@ void RowPainter::paint(int y_offset, int
// paint text
paintText();
+}
+
+
+} // namespace anon
+
+
+int getLengthMarkerHeight(BufferView const & bv, VSpace const & vsp)
+{
+ if (vsp.kind() == VSpace::NONE)
+ return 0;
+
+ int const arrow_size = 4;
+ int const space_size = int(vsp.inPixels(bv));
+
+ LyXFont font;
+ font.decSize();
+ int const min_size = max(3 * arrow_size,
+ font_metrics::maxAscent(font)
+ + font_metrics::maxDescent(font));
+
+ if (vsp.length().len().value() < 0.0)
+ return min_size;
+ else
+ return max(min_size, space_size);
+}
+
+
+
+void paint(BufferView const & bv, LyXText const & text, RowList::iterator rit,
+ int y_offset, int x_offset, int y)
+{
+ RowPainter painter(bv, text, rit);
+ painter.paint(y_offset, x_offset, y);
}
Index: rowpainter.h
===
Assert
I think there are a few places in InsetText that are never reached.
Should I put in a lyxerr<< or an Assert or ...?
I.e.
LyXCursor const & InsetText::cursor(BufferView * bv) const
{
if (the_locking_inset) {
lyxerr << "InsetText::cursor(). Should not happen!\n";
return the_locking_inset->cursor(bv);
}
return getLyXText(bv)->cursor;
}
Andre'
Re: patches
Alfredo Braunstein wrote:
> OTOH it would be safe to add overwriteSelection to bufferview_funcs.C and
> use that also from insettext: If the LFUN thing get changed then it would
> do no harm.
This would be it. Works very well in text3.C (normal text) and insettext
(tested inside footnotes, minipages).
> Otherwise it would be wise to add the updated patch to bugzilla so we don't
> forget!
Done (this is bug 1226 btw).
Regards,
Juergen.
Index: src/ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/src/ChangeLog,v
retrieving revision 1.1413
diff -u -r1.1413 ChangeLog
--- src/ChangeLog 2003/07/14 15:17:38 1.1413
+++ src/ChangeLog 2003/07/14 16:23:08
@@ -8,6 +8,12 @@
* text2.C (init): fix a crash fired on resize
+2003-07-14 Juergen Spitzmueller <[EMAIL PROTECTED]>
+
+ * bufferview_funcs.[Ch]: introduce function replaceSelection()
+ * text3.C: use it to delete selections in some cases
+ (bugs 441, 673, 702, 954).
+
2003-07-11 Alfredo Braunstein <[EMAIL PROTECTED]>
* buffer.[Ch]: added new closing signal
Index: src/bufferview_funcs.C
===
RCS file: /cvs/lyx/lyx-devel/src/bufferview_funcs.C,v
retrieving revision 1.85
diff -u -r1.85 bufferview_funcs.C
--- src/bufferview_funcs.C 2003/07/10 12:26:35 1.85
+++ src/bufferview_funcs.C 2003/07/14 16:23:11
@@ -414,4 +414,15 @@
}
}
+
+// deletes a selection during an insertion
+void replaceSelection(LyXText * lt)
+{
+ if (lt->selection.set()) {
+ lt->update();
+ lt->cutSelection(true, false);
+ lt->update();
+ }
+}
+
}; // namespace bv_funcs
Index: src/bufferview_funcs.h
===
RCS file: /cvs/lyx/lyx-devel/src/bufferview_funcs.h,v
retrieving revision 1.19
diff -u -r1.19 bufferview_funcs.h
--- src/bufferview_funcs.h 2003/07/10 12:26:35 1.19
+++ src/bufferview_funcs.h 2003/07/14 16:23:12
@@ -86,7 +86,8 @@
///
extern void toggleAndShow(BufferView *, LyXFont const &,
bool toggleall = true);
-
+/// replace selection with insertion
+extern void replaceSelection(LyXText * lt);
}; // namespace bv_funcs
#endif
Index: src/text3.C
===
RCS file: /cvs/lyx/lyx-devel/src/text3.C,v
retrieving revision 1.86
diff -u -r1.86 text3.C
--- src/text3.C 2003/07/01 11:51:19 1.86
+++ src/text3.C 2003/07/14 16:23:15
@@ -20,6 +20,7 @@
#include "debug.h"
#include "bufferparams.h"
#include "buffer.h"
+#include "bufferview_funcs.h"
#include "ParagraphParameters.h"
#include "gettext.h"
#include "factory.h"
@@ -44,6 +45,7 @@
#include
using namespace lyx::support;
+using namespace bv_funcs;
using std::endl;
using std::find;
@@ -369,6 +371,7 @@
{
lt->update();
InsetSpecialChar * new_inset = new InsetSpecialChar(kind);
+ replaceSelection(lt);
if (!bv->insertInset(new_inset))
delete new_inset;
else
@@ -723,7 +726,7 @@
if (cursor.pos() <= body)
break;
- bv->beforeChange(this);
+ replaceSelection(bv->getLyXText());
insertInset(new InsetNewline);
update();
setCursor(cursor.par(), cursor.pos());
@@ -833,7 +836,7 @@
break;
case LFUN_BREAKPARAGRAPH:
- bv->beforeChange(this);
+ replaceSelection(bv->getLyXText());
breakParagraph(bv->buffer()->paragraphs, 0);
update();
selection.cursor = cursor;
@@ -842,7 +845,7 @@
break;
case LFUN_BREAKPARAGRAPHKEEPLAYOUT:
- bv->beforeChange(this);
+ replaceSelection(bv->getLyXText());
breakParagraph(bv->buffer()->paragraphs, 1);
update();
selection.cursor = cursor;
@@ -855,7 +858,7 @@
// indentation and add a "defskip" at the top.
// Otherwise, do the same as LFUN_BREAKPARAGRAPH.
LyXCursor cur = cursor;
- bv->beforeChange(this);
+ replaceSelection(bv->getLyXText());
if (cur.pos() == 0) {
if (cur.par()->params().spaceTop() == VSpace(VSpace::NONE)) {
setParagraph(
@@ -1028,10 +1031,7 @@
case LFUN_PASTE: {
cmd.message(_("Paste"));
- // clear the selection
- bv->toggleSelection();
- clearSelection();
- update();
+ replaceSelection(bv->getLyXText());
size_t sel_index = 0;
string const & arg = cmd.argument;
if (isStrUnsignedInt(arg)) {
@@ -1200,6 +1200,7 @@
}
case LFUN_QUOTE: {
+ replaceSelection(bv->getLyXText());
ParagraphList::iterator pit = cursor.par();
lyx::pos_type pos = cursor.pos();
char c;
@@ -1221,6 +1222,7 @@
}
case LFUN_DATE_INSERT: {
+ replaceSelection(bv->getLyXText());
time_t now_time_t = time(NULL);
struct tm * now_tm = localtime(&now_time_t);
setlocale(LC_TIME, "");
Index: src/insets/ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/src/insets/ChangeLog,v
retrieving revision 1.736
diff -u -r1.736 ChangeLog
--- src/insets/ChangeLog 2003/07/14 15:17:39 1.736
+++ src/insets/ChangeLog 2003/07/14 16:23:35
@@ -10,6 +10,11 @@
* insettext.[Ch]: used cached metrics a bit more
+2003-07-14
Changing Table Output
I have recently started working with lyx and wanted to try some customizations. I am using the '(SGML) linuxdoc article' layout for my document and I am outputting it to html. I like the way that this layout looks once converted, but I am having problems with tables. First, the tables end up looking (something) like this: ++---+Data|Data ++---+Data|Data ++---+Data|Data ++---+Data|Data I'm not sure how to fix that. Secondly, I would like to output actual HTML tables instead of ASCII tables. Any help would be greatly appreciated. Thank you, -- Jason L W Lynn <[EMAIL PROTECTED]>
[patch] more insettext simplification
This removes a few BufferView * arguments that aren't used anymore.
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.391
diff -u -p -r1.391 BufferView_pimpl.C
--- BufferView_pimpl.C 11 Jul 2003 12:21:30 - 1.391
+++ BufferView_pimpl.C 14 Jul 2003 14:13:54 -
@@ -656,7 +656,7 @@ void BufferView::Pimpl::update(LyXText *
text->partialRebreak();
if (text->inset_owner) {
- text->inset_owner->setUpdateStatus(bv_, InsetText::NONE);
+ text->inset_owner->setUpdateStatus(InsetText::NONE);
updateInset(text->inset_owner);
} else {
update();
@@ -675,7 +675,7 @@ void BufferView::Pimpl::update(BufferVie
text->partialRebreak();
if (text->inset_owner) {
- text->inset_owner->setUpdateStatus(bv_, InsetText::NONE);
+ text->inset_owner->setUpdateStatus(InsetText::NONE);
updateInset(text->inset_owner);
} else {
update();
Index: text2.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text2.C,v
retrieving revision 1.381
diff -u -p -r1.381 text2.C
--- text2.C 10 Jul 2003 11:17:31 - 1.381
+++ text2.C 14 Jul 2003 14:13:54 -
@@ -762,7 +762,7 @@ void LyXText::setSelection()
bool const lsel = TextCursor::setSelection();
if (inset_owner && (selection.set() || lsel))
- inset_owner->setUpdateStatus(bv(), InsetText::SELECTION);
+ inset_owner->setUpdateStatus(InsetText::SELECTION);
}
@@ -849,7 +849,7 @@ void LyXText::toggleFree(LyXFont const &
selection.cursor = cursor;
}
if (inset_owner)
- inset_owner->setUpdateStatus(bv(), InsetText::CURSOR_PAR);
+ inset_owner->setUpdateStatus(InsetText::CURSOR_PAR);
}
Index: insets/insetcollapsable.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetcollapsable.C,v
retrieving revision 1.150
diff -u -p -r1.150 insetcollapsable.C
--- insets/insetcollapsable.C 4 Jul 2003 08:23:21 - 1.150
+++ insets/insetcollapsable.C 14 Jul 2003 14:13:54 -
@@ -236,7 +236,7 @@ void InsetCollapsable::lfunMouseRelease(
if (collapsed_ && cmd.button() != mouse_button::button3) {
collapsed_ = false;
- inset.setUpdateStatus(bv, InsetText::FULL);
+ inset.setUpdateStatus(InsetText::FULL);
bv->updateInset(this);
bv->buffer()->markDirty();
return;
@@ -247,7 +247,7 @@ void InsetCollapsable::lfunMouseRelease(
{
if (collapsed_) {
collapsed_ = false;
- inset.setUpdateStatus(bv, InsetText::FULL);
+ inset.setUpdateStatus(InsetText::FULL);
bv->updateInset(this);
bv->buffer()->markDirty();
} else {
@@ -317,7 +317,7 @@ Inset::RESULT InsetCollapsable::localDis
if (collapsed_) {
collapsed_ = false;
if (bv->lockInset(this)) {
- inset.setUpdateStatus(bv,
InsetText::FULL);
+ inset.setUpdateStatus(InsetText::FULL);
bv->updateInset(this);
bv->buffer()->markDirty();
inset.localDispatch(cmd);
Index: insets/insetert.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetert.C,v
retrieving revision 1.134
diff -u -p -r1.134 insetert.C
--- insets/insetert.C 30 Jun 2003 23:56:18 - 1.134
+++ insets/insetert.C 14 Jul 2003 14:13:54 -
@@ -585,7 +585,7 @@ void InsetERT::status(BufferView * bv, E
switch (st) {
case Inlined:
if (bv)
- inset.setUpdateStatus(bv, InsetText::INIT);
+ inset.setUpdateStatus(InsetText::INIT);
break;
case Open:
collapsed_ = false;
Index: insets/insettext.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insettext.C,v
retrieving revision 1.423
diff -u -p -r1.423 insettext.C
--- insets/insettext.C 14 Jul 2003 13:49:13 - 1.4
Re: [bug] reference dialog
On Mon, Jul 14, 2003 at 10:48:31AM -0400, Kuba Ober wrote: > [Slang was unintended, it was already past lunchtime on Friday. A plausible > excuse I hope ;-] Everybody knows anything goes on a Friday, world over ! john
Re: [bug] reference dialog
On piątek 11 lipiec 2003 02:57 pm, Kuba Ober wrote: > On środa 09 lipiec 2003 08:59 am, Andre Poenitz wrote: > > On Wed, Jul 09, 2003 at 01:47:49PM +0100, John Levon wrote: > > > On Wed, Jul 09, 2003 at 01:53:26PM +0200, Andre Poenitz wrote: > > > > > How sweet! As an opensource key developper of LyX, I would expect > > > > > you to care for things beyond. > > > > > > > > Why? Can't remember swearing a Big Oath of Altruism... > > > > > > Isn't there an Implicit Oath of Quality ? > > > > As these keyhole dialogs are not usable for me I don't > > consider them good quality... > > Can't you just resize the dialogs by draggin thir marigins with your > pointing device, and (if not present already) add code to store their new > sizes in lyxrc or somesuch? [Slang was unintended, it was already past lunchtime on Friday. A plausible excuse I hope ;-] Cheers, Kuba
Re: [PATCH] QNote
On Mon, Jul 14, 2003 at 04:32:52PM +0200, Juergen Spitzmueller wrote: > > Looks fine. Lars, can Juergen have a CVS account for stuff like this > > please ? > > Can you please apply it otherwise, John? I'm lazy enough to give Lars a while more to respond ... if he's not shown up by the end of the day I'll apply it regards john
Re: [PATCH] QNote
John Levon wrote: > > The new QNote dialog (and a credits update). > > Looks fine. Lars, can Juergen have a CVS account for stuff like this > please ? Can you please apply it otherwise, John? Thanks, Juergen.
Re: another resize problem
On Mon, Jul 14, 2003 at 02:56:27PM +0100, John Levon wrote: > > Feels like it, I can't reproduce it in 1.3.3cvs. > > Can you give me a simple testcase to follow please ? I'll file it on > bugzilla New doc a b c click behind the displayed formula. d -> formula row is not properly redrawn. Physical content is ok as verified by export to LaTeX. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: another resize problem
On Mon, Jul 14, 2003 at 02:55:32PM +0100, John Levon wrote: > On Mon, Jul 14, 2003 at 03:06:19PM +0200, Andre Poenitz wrote: > > > Patch attached. I see no difference compared to current CVS. > > My quick testing agrees with you, the change seems to be OK. But where > are you going with this ? This is further separating cursor & text (good per se), but the reason I'd like to do this is the following: Currently, the cursor holds irow, i.e. an RowList::iterator, which is invalidated as soon as the rowlist is rebuild. Now, the cheapest (implementation wise...) version of two-phase drawing for InsetText is to rebuild the rowlist of its 'LyXText text_' member in each metrics() call. So we'd better not depend on "external" iterator to that list if that can be avoided. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: another resize problem
On Mon, Jul 14, 2003 at 03:42:05PM +0200, Andre Poenitz wrote: > > > Note, however, that updating a row containing a displayed formula is > > > broken if the cursor is in the 'dummy position' behind the formula. > > > (with and without the patch). > > Feels like it, I can't reproduce it in 1.3.3cvs. Can you give me a simple testcase to follow please ? I'll file it on bugzilla john
Re: another resize problem
On Mon, Jul 14, 2003 at 03:06:19PM +0200, Andre Poenitz wrote: > Patch attached. I see no difference compared to current CVS. My quick testing agrees with you, the change seems to be OK. But where are you going with this ? regards john
[patch] more insettext
This takes care of one of the recently introduced "performance
offenders".
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Index: insettext.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insettext.C,v
retrieving revision 1.422
diff -u -p -r1.422 insettext.C
--- insettext.C 10 Jul 2003 14:44:13 - 1.422
+++ insettext.C 14 Jul 2003 13:42:35 -
@@ -274,10 +274,10 @@ void InsetText::read(Buffer const * buf,
void InsetText::metrics(MetricsInfo & mi, Dimension & dim) const
{
BufferView * bv = mi.base.bv;
- LyXText * text = getLyXText(bv);
- dim.asc = text->rows().begin()->ascent_of_text() + TEXT_TO_INSET_OFFSET;
- dim.des = text->height - dim.asc + TEXT_TO_INSET_OFFSET;
- dim.wid = max(textWidth(bv), int(text->width)) + 2 * TEXT_TO_INSET_OFFSET;
+ setViewCache(bv);
+ dim.asc = text_.rows().begin()->ascent_of_text() + TEXT_TO_INSET_OFFSET;
+ dim.des = text_.height - dim.asc + TEXT_TO_INSET_OFFSET;
+ dim.wid = max(textWidth(bv), int(text_.width)) + 2 * TEXT_TO_INSET_OFFSET;
dim.wid = max(dim.wid, 10);
dim_ = dim;
}
@@ -1938,15 +1938,13 @@ int InsetText::cix(BufferView * bv) cons
int InsetText::cy(BufferView * bv) const
{
- LyXFont font;
- return text_.cursor.y() - ascent(bv, font) + TEXT_TO_INSET_OFFSET;
+ return text_.cursor.y() - dim_.asc + TEXT_TO_INSET_OFFSET;
}
int InsetText::ciy(BufferView * bv) const
{
- LyXFont font;
- return text_.cursor.iy() - ascent(bv, font) + TEXT_TO_INSET_OFFSET;
+ return text_.cursor.iy() - dim_.asc + TEXT_TO_INSET_OFFSET;
}
Re: another resize problem
On Mon, Jul 14, 2003 at 02:29:23PM +0100, John Levon wrote: > On Mon, Jul 14, 2003 at 03:06:19PM +0200, Andre Poenitz wrote: > > > Patch attached. I see no difference compared to current CVS. > > I'll try it now. > > > Note, however, that updating a row containing a displayed formula is > > broken if the cursor is in the 'dummy position' behind the formula. > > (with and without the patch). > > Regression ? Feels like it, I can't reproduce it in 1.3.3cvs. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: another resize problem
On Mon, Jul 14, 2003 at 03:06:19PM +0200, Andre Poenitz wrote: > Patch attached. I see no difference compared to current CVS. I'll try it now. > Note, however, that updating a row containing a displayed formula is > broken if the cursor is in the 'dummy position' behind the formula. > (with and without the patch). Regression ? regards john
Re: another resize problem
On Mon, Jul 14, 2003 at 03:15:21PM +0200, Andre Poenitz wrote: > If so, wouldn't it be sufficient just to _draw_ the cursor there instead > of physically placing it there? Maybe. I don't understand it myself, sorry john
Re: 1.4.0 road map
On Mon, Jul 14, 2003 at 03:23:01PM +0200, Michael Schmitt wrote: > Andre Poenitz wrote: > > >I remember saying something like "even if we had a feature freeze right > >now and only tried to make everything work again, 1.4.0 won't be out > >before Christmas". > > Why? Is it due to missing parts of the implementation, existing bugs, or > unpredictable problems that you expect to occur? Existing bugs that would need nontrivial work-arounds cementing a broken architecture. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: 1.4.0 road map
Andre Poenitz wrote: I remember saying something like "even if we had a feature freeze right now and only tried to make everything work again, 1.4.0 won't be out before Christmas". Why? Is it due to missing parts of the implementation, existing bugs, or unpredictable problems that you expect to occur? [And even more annoying: All this patch work will be lost in case we'll have the cleanup some day later...] I think nobody wants this. Michael
Re: another resize problem
On Mon, Jul 14, 2003 at 01:58:18PM +0100, John Levon wrote: > It's to maintain the cursor position at a more useful place when it's > right in front of a full-row inset (not just one that happens to take up > a full row though). You mean that 'dummy position' in front of a big inset where typing something ends up in the row above? If so, wouldn't it be sufficient just to _draw_ the cursor there instead of physically placing it there? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: another resize problem
On Mon, Jul 14, 2003 at 01:58:18PM +0100, John Levon wrote:
> I suggest removing the setting and seeing for yourself :) (I think I
> tried this some time ago)
Patch attached. I see no difference compared to current CVS.
Note, however, that updating a row containing a displayed formula is
broken if the cursor is in the 'dummy position' behind the formula.
(with and without the patch).
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Index: lyxcursor.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxcursor.C,v
retrieving revision 1.22
diff -u -p -r1.22 lyxcursor.C
--- lyxcursor.C 27 Jun 2003 08:38:36 - 1.22
+++ lyxcursor.C 14 Jul 2003 12:27:42 -
@@ -111,18 +111,6 @@ int LyXCursor::iy() const
}
-void LyXCursor::irow(RowList::iterator r)
-{
- irow_ = r;
-}
-
-
-RowList::iterator LyXCursor::irow() const
-{
- return irow_;
-}
-
-
bool operator==(LyXCursor const & a, LyXCursor const & b)
{
return a.par() == b.par()
Index: lyxcursor.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxcursor.h,v
retrieving revision 1.33
diff -u -p -r1.33 lyxcursor.h
--- lyxcursor.h 27 Jun 2003 08:38:36 - 1.33
+++ lyxcursor.h 14 Jul 2003 12:27:42 -
@@ -10,7 +10,6 @@
#ifndef LYXCURSOR_H
#define LYXCURSOR_H
-#include "RowList.h"
#include "ParagraphList.h"
#include "support/types.h"
@@ -79,16 +78,6 @@ public:
* FIXME: explain why we need this ? especially for y...
*/
int iy() const;
- /// set the stored next row
- void irow(RowList::iterator r);
- /**
-* Return the next row, when this
-* cursor is at the end of the previous row, for insets that take
-* a full row.
-*
-* FIXME: explain why we need this ? especially for y...
-*/
- RowList::iterator irow() const;
private:
/// The paragraph the cursor is in.
ParagraphList::iterator par_;
@@ -120,8 +109,6 @@ private:
int y_;
/// the stored next-row y position
int iy_;
- /// the containing row for the next line
- RowList::iterator irow_;
};
///
Index: lyxfunc.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxfunc.C,v
retrieving revision 1.462
diff -u -p -r1.462 lyxfunc.C
--- lyxfunc.C 11 Jul 2003 12:21:31 - 1.462
+++ lyxfunc.C 14 Jul 2003 12:27:42 -
@@ -909,12 +909,13 @@ void LyXFunc::dispatch(FuncRequest const
owner->clearMessage();
goto exit_with_message;
} else if (result == FINISHED_UP) {
- if (TEXT()->cursor.irow() != TEXT()->rows().begin()) {
+ RowList::iterator const irow = TEXT()->cursorIRow();
+ if (irow != TEXT()->rows().begin()) {
#if 1
TEXT()->setCursorFromCoordinates(
TEXT()->cursor.ix() + inset_x,
TEXT()->cursor.iy() -
- TEXT()->cursor.irow()->baseline() - 1);
+ irow->baseline() - 1);
TEXT()->cursor.x_fix(TEXT()->cursor.x());
#else
TEXT()->cursorUp(view());
@@ -926,13 +927,14 @@ void LyXFunc::dispatch(FuncRequest const
owner->clearMessage();
goto exit_with_message;
} else if (result == FINISHED_DOWN) {
- if (boost::next(TEXT()->cursor.irow()) !=
TEXT()->rows().end()) {
+ RowList::iterator const irow = TEXT()->cursorIRow();
+ if (boost::next(irow) != TEXT()->rows().end()) {
#if 1
TEXT()->setCursorFromCoordinates(
TEXT()->cursor.ix() + inset_x,
TEXT()->cursor.iy() -
- TEXT()->cursor.irow()->baseline() +
- TEXT()->cursor.irow()->height() + 1);
+ irow->baseline() +
+ irow->height() + 1);
TEXT()->cursor.x_fix(TEXT()->cursor.x());
#else
TEXT()->cursorDown(view());
Index: lyxtext.h
===
RCS file: /usr/local/lyx/cvsroot/ly
Re: 1.4.0 road map
On Mon, Jul 14, 2003 at 02:33:24PM +0200, Michael Schmitt wrote: > Would it be possible to suspend the kernel rewrite at some clearly > defined point? Say, after the metrics-draw split? Or do we have to fix > _everything_ before the kernel becomes stable again? What are the tasks I suspect "everything". It depends on how far Andre really plans to go. > that must be performed before we reach the nearest point at which we are > able to release 1.4.0? There are quite a few bugs targetted already on bugzilla. Those have to be fixed. Also change tracking is busted from parlist stuff, I need to talk to Lars about that since the fix become non-trivial :/ > Andre is doing his magic. Maybe we should start to minimize the number > of open bugs to shorten the code freeze period later? I'm moving into my own feature freeze anyway, even if nobody joins me :) regards john
Re: 1.4.0 road map
On Mon, Jul 14, 2003 at 02:33:24PM +0200, Michael Schmitt wrote: > Hello everybody, > > as Andre pointed out last week, it is likely that the rework of the LyX > kernel will continue for many more months. I really appreciate what > Andre has done so far Oh, the biggest chunk in 1.4.0cvs so far is the paragraph & rowlist sanitizing. Not my doing... > and what he will hopefully do in the future. [I am pretty sure I have to reduce LyX related activities from the end of the year on. I'll lose my job (project runs out, no extension possible, no other projects in sight...) and there are 'family matters' looming.] > However, we should also think about a roadmap for 1.4.0 again. 1.4.0cvs > already offers a lot of nice new features and it would be a pity if the > users had to wait until next year. I remember saying something like "even if we had a feature freeze right now and only tried to make everything work again, 1.4.0 won't be out before Christmas". [And even more annoying: All this patch work will be lost in case we'll have the cleanup some day later...] > Would it be possible to suspend the kernel rewrite at some clearly > defined point? Say, after the metrics-draw split? Probably. But it is hard to tell where the 'metrics-draw split' ends and where general LyXText/InsetText cleanup begins. Alone in the discussion about such thing we will waste a lot of energy. > Or do we have to fix _everything_ before the kernel becomes stable > again? No. But quite a bit... We could e.g. leave out the 'centralized cursor' even if that would mean no 'inset unification' in 1.4. We could leave out 'InsetEnvironment' related stuff as this is a new feature. We could leave out 'consolidation of InsetText and main text' as it 'used to be like that'... > What are the tasks that must be performed before we reach the > nearest point at which we are able to release 1.4.0? 'Update removal' plus the missing parts of 'Two phase drawing' (i.e. the metrics/draw split) should be a safe bet. The first should bring robustness, the second is needed to make the first happen. > Last Friday, John convinced me to work through all the open (not > verified) bugzilla entries (472 as of today) and check whether they > are still relevant. Most bug reports are independent from the current > kernel rewrite and there are many small(er) issues that could be fixed > while Andre is doing his magic. Maybe we should start to minimize the > number of open bugs to shorten the code freeze period later? I certainly don't object. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: another resize problem
On Mon, Jul 14, 2003 at 11:11:08AM +0200, Andre Poenitz wrote: > In the mean time I'd still glad to see any explanation for the > existence of the LyXCursor::irow member. > > Anybody an idea? It's to maintain the cursor position at a more useful place when it's right in front of a full-row inset (not just one that happens to take up a full row though). I suggest removing the setting and seeing for yourself :) (I think I tried this some time ago) john
Re: How conglomerate handles text styles
On Mon, Jul 14, 2003 at 08:53:11AM +0200, Lars Gullik Bj?nnes wrote: > But perhaps we should do this for index entries as well? > (similar) Index entries ? How would that work ? > Let's do this! We need to consider if it's an option and if so, what's the default. I can see the markers being quite distracting ... regards john
1.4.0 road map
Hello everybody, as Andre pointed out last week, it is likely that the rework of the LyX kernel will continue for many more months. I really appreciate what Andre has done so far and what he will hopefully do in the future. However, we should also think about a roadmap for 1.4.0 again. 1.4.0cvs already offers a lot of nice new features and it would be a pity if the users had to wait until next year. Would it be possible to suspend the kernel rewrite at some clearly defined point? Say, after the metrics-draw split? Or do we have to fix _everything_ before the kernel becomes stable again? What are the tasks that must be performed before we reach the nearest point at which we are able to release 1.4.0? Last Friday, John convinced me to work through all the open (not verified) bugzilla entries (472 as of today) and check whether they are still relevant. Most bug reports are independent from the current kernel rewrite and there are many small(er) issues that could be fixed while Andre is doing his magic. Maybe we should start to minimize the number of open bugs to shorten the code freeze period later? Kind regards, Michael
argh...
Just need a way to vent my spleen...
(a) 1.3.2 just crashed on me and took three minutes of work with it.
No big deal? Lucky me just had (manually) run 'cvs commit' on my home
dir... Emergency and autosave both missing from previous cursor
position after an orgy of _two_ consecutive undos. *sigh*
[To get on-topic: Whatever crashes in undo in 1.4.0cvs might as well
have been present there all the time...]
(b) I recently decided to go back to good ol' ERT for things like
\begin{foo}...\end{foo} (foo \in example, remark, proof etc) just to
get some work done and not to fight LyX as such.
[On-topic part: We desparately need InsetEnvironment, not just as as
proof-of-concept-implementation, but "usable"]
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: another resize problem
On Mon, Jul 14, 2003 at 11:42:07AM +0200, Alfredo Braunstein wrote: > A proposal: how about making the draws step order explicit? I mean to keep > the 'current step' in some variable and abort (or complain) if a given > operation is not allowed on this step (like getting the cursor row or y > position before a needed rebreak). It would certainly make debugging easier > IMHO, and maybe not too invasive if we add the checks on a lower enough > level. Do you think it would be feasible/useful? I think it is a good idea. But I'd guess we'd get lots of 'illegal' accesses as long as 'update' is still present, so I am not sure it will help much at the beginning. To iron out the last wrinkles after 'update' is gone, it just looks fine, though. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: another resize problem
Andre Poenitz wrote: >> Random question: Is there an intended difference between >> "rowlist_.clear(); init(bv)" and "init(bv, true)"? Both are used, but are >> slightly different. > > None that I've understood so far. Which, of course, doesn't mean there > wasn't a reason. The only difference I see is that reinit=true sets widht & height to zero (harmless to do it always I would think), initializes need_break_row_ (harmless) and adds a clearPaint call (same thing). I suppose it's a matter of trying. > In fact, I'd be glad, if there was a single LyXText::init(bv) > function (named 'rebuild' or similar) that simply re-builds the rowlist > cache but keeps the cursor and selection valid. > > [Unfortunately we still have the cursor in the text to be taken care of > (this is sometimes done with a setCursor() from par+pos). > > I have a strong feeling that things would structurally simplify if we > would not store any row and position information in the cursor at all, > but to re-build that information when needed. But I have an equally > strong feeling that this would be too costly (run time wise), so this > is none of the next possible steps...] Agreed on both. > In the mean time I'd still glad to see any explanation for the > existence of the LyXCursor::irow member. > > Anybody an idea? Not me (well, I was told that it has to do somewhat with full row insets, but nothing more). A proposal: how about making the draws step order explicit? I mean to keep the 'current step' in some variable and abort (or complain) if a given operation is not allowed on this step (like getting the cursor row or y position before a needed rebreak). It would certainly make debugging easier IMHO, and maybe not too invasive if we add the checks on a lower enough level. Do you think it would be feasible/useful? Regards, Alfredo
Re: another resize problem
On Mon, Jul 14, 2003 at 10:54:53AM +0200, Alfredo Braunstein wrote: > Andre Poenitz wrote: > > > On Thu, Jul 10, 2003 at 03:50:27PM +0200, Alfredo Braunstein wrote: > >> I can reproduce it reliably: resize to the minimum, then enlarge to > >> maximum -> bang. > > > > > Busted (anchor_row_ was not initialized on init). Can I apply this? Sure. Thanks. > Random question: Is there an intended difference between "rowlist_.clear(); > init(bv)" and "init(bv, true)"? Both are used, but are slightly different. None that I've understood so far. Which, of course, doesn't mean there wasn't a reason. In fact, I'd be glad, if there was a single LyXText::init(bv) function (named 'rebuild' or similar) that simply re-builds the rowlist cache but keeps the cursor and selection valid. [Unfortunately we still have the cursor in the text to be taken care of (this is sometimes done with a setCursor() from par+pos). I have a strong feeling that things would structurally simplify if we would not store any row and position information in the cursor at all, but to re-build that information when needed. But I have an equally strong feeling that this would be too costly (run time wise), so this is none of the next possible steps...] In the mean time I'd still glad to see any explanation for the existence of the LyXCursor::irow member. Anybody an idea? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: another resize problem
Andre Poenitz wrote: > On Thu, Jul 10, 2003 at 03:50:27PM +0200, Alfredo Braunstein wrote: >> I can reproduce it reliably: resize to the minimum, then enlarge to >> maximum -> bang. > Busted (anchor_row_ was not initialized on init). Can I apply this? Random question: Is there an intended difference between "rowlist_.clear(); init(bv)" and "init(bv, true)"? Both are used, but are slightly different. Regards, Alfredo Index: ChangeLog === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v retrieving revision 1.1411 diff -u -p -u -r1.1411 ChangeLog --- ChangeLog 11 Jul 2003 12:21:30 - 1.1411 +++ ChangeLog 14 Jul 2003 08:44:17 - @@ -1,3 +1,7 @@ +2003-07-14 Alfredo Braunstein <[EMAIL PROTECTED]> + + * text2.C (init): fix a crash fired on resize + 2003-07-11 Alfredo Braunstein <[EMAIL PROTECTED]> * buffer.[Ch]: added new closing signal Index: text2.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text2.C,v retrieving revision 1.381 diff -u -p -u -r1.381 text2.C --- text2.C 10 Jul 2003 11:17:31 - 1.381 +++ text2.C 14 Jul 2003 08:44:24 - @@ -88,10 +88,12 @@ void LyXText::init(BufferView * bview, b rowlist_.clear(); need_break_row = rows().end(); width = height = 0; - top_y(0); clearPaint(); } else if (!rowlist_.empty()) return; + + anchor_row_ = rows().end(); + anchor_row_offset_ = 0; ParagraphList::iterator pit = ownerParagraphs().begin(); ParagraphList::iterator end = ownerParagraphs().end();
