Re: [patch] more slowness
Alfredo Braunstein wrote:
> Angus Leeming wrote:
>
>> * Make generation of dvi, ps, pdf files etc asynchronous. If Alfredo
>> doesn't beat me to it.
>
> :-) Every time I look into this I finish by considering bigger reworking
> plans than I can manage. I will gladly help you with the dirty work, if
> there is some...
>
> Regards, Alfredo
I think that step one is to add functions to the insets
class InsetXYZ {
public:
virtual void prepare_to_export(ostream &, Buffer const &);
};
The idea being to generate a big shell script of all conversions etc that
need to be performed before we consider running latex, viewing docbook etc.
We can probably leverage the code in graphics/GraphicsConverter.[Ch],
probably also renaming it async_converter.[Ch].
I suspect that prepare_to_export will do little more than decide what format
is needed and whether a conversion is needed at all.
--
Angus
Re: Feature Request - converting to a single LaTeX file
> > Why don't you add it to bugzilla? > Done.. it's at: http://bugzilla.lyx.org/show_bug.cgi?id=1303 nirmal
Re: Feature Request - converting to a single LaTeX file
On Thu, 31 Jul 2003, Nirmal Govind wrote: > This request is based on experiences with trying to send LaTeX files > generated by LyX to other "pure" LaTeX users and a conference that required > a single LaTeX file which had everything in it.. So the request is to have > LyX convert the LyX document to a .tex file which would have the .eps > figures, .bbl file for bibliography and any other non-standard .sty files > (these may have to be user-specified) included in the .tex file using the > filecontents environment. This way, it is possible to just send the single > .tex file to any other LaTeX user and he/she can run LaTeX on it and the > figures, bibliography and sty files will be generated on the fly.. would > this be hard to implement? I'm guessing some shell scripting may also be > able to achieve the same... > > Thanks, > nirmal > Why don't you add it to bugzilla? /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: Question on lyx2lyx
On Friday 01 August 2003 17:13, Dekel Tsur wrote: > > > > That should be changed to english only if it is default, else it is a > > bug. > > Fixed. Should I commit it to the 1.3.x branch ? I would say so. Jean-Marc? -- José Abílio LyX and docbook, a perfect match. :-)
Re: Question on lyx2lyx
On Fri, Aug 01, 2003 at 04:00:29PM +0100, Jose' Matos wrote: > On Friday 01 August 2003 15:17, Dekel Tsur wrote: > > Jose, why does lyxconvert_216.py changes the language of the document to > > 'english' ? > > I agree that if the language was 'default' (IIRC, LyX used to have this > > option) then the language should be changed, but this is incorrect in all > > other cases. > > That should be changed to english only if it is default, else it is a bug. Fixed. Should I commit it to the 1.3.x branch ?
[PATCH] Re: lyxrc.defaults
> "Kayvan" == Kayvan A Sylvan <[EMAIL PROTECTED]> writes:
Kayvan> Building lyx and trying to run it from the lyx build directory
Kayvan> does not seem to work now.
Kayvan> ./src/lyx gives the dialog box: "Error while reading the
Kayvan> configuration file lyxrc.defaults"
Kayvan> Hit OK, lyx execution ends.
Kayvan> Copying lyxrc.defaults into ~/.lyx is a workaround.
Kayvan, Garst, can you confirm that the appended patch fixes the
problem?
JMarc
Index: src/support/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/ChangeLog,v
retrieving revision 1.195
diff -u -p -r1.195 ChangeLog
--- src/support/ChangeLog 29 Jul 2003 10:56:55 - 1.195
+++ src/support/ChangeLog 1 Aug 2003 16:09:01 -
@@ -1,3 +1,11 @@
+2003-08-01 Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
+
+ * path_defines.C.in (setLyxPaths): re-introduce the code to check
+ whether lyx is run in place
+ (build_dir): renamed from build_lyxdir
+ (build_lyxdir): give this better semantics compatible with what
+ LibFileSearch expects.
+
2003-07-29 Angus Leeming <[EMAIL PROTECTED]>
* filename.[Ch] (relFilename, outputFilename): the 'path' arg
Index: src/support/path_defines.C.in
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/path_defines.C.in,v
retrieving revision 1.5
diff -u -p -r1.5 path_defines.C.in
--- src/support/path_defines.C.in 28 Jul 2003 11:43:40 - 1.5
+++ src/support/path_defines.C.in 1 Aug 2003 16:09:01 -
@@ -32,6 +32,9 @@ namespace {
// Store for the path to the lyx support files we're actually going to use.
string system_lyxdir_;
+// Store for the path to the autogenerated files when running in place
+string build_lyxdir_;
+
// Store for the path to the user-level support files.
string user_lyxdir_;
@@ -72,13 +75,25 @@ string const & lyx_localedir()
}
-string const & build_lyxdir()
+string const & build_dir()
{
static string const bl = "%BUILDDIR%";
return bl;
}
+string const & build_lyxdir()
+{
+ return build_lyxdir_;
+}
+
+
+void build_lyxdir(string const & sld)
+{
+ build_lyxdir_ = sld;
+}
+
+
string const & system_lyxdir()
{
return system_lyxdir_;
@@ -122,6 +137,26 @@ bool setLyxPaths()
lyxerr[Debug::INIT] << "Name of binary: " << binname << endl;
lyxerr[Debug::INIT] << "Path of binary: " << binpath << endl;
+
+ string searchpath;
+
+ //
+ // Determine whether we are running in place and set
+ // build_lyxdir accordingly
+ //
+
+ string const buildlyxdir = MakeAbsPath("../lib", binpath);
+ if (!FileSearch(buildlyxdir, "lyxrc.defaults").empty()) {
+ searchpath += AddPath(lyx_top_srcdir(), "lib") + ';';
+ build_lyxdir(buildlyxdir);
+ lyxerr[Debug::INIT] << "Checking whether LyX is run in "
+ "place... yes" << endl;
+ } else {
+ lyxerr[Debug::INIT]
+ << "Checking whether LyX is run in place... no"
+ << endl;
+ }
+
//
// Determine system directory.
//
@@ -141,7 +176,6 @@ bool setLyxPaths()
// and the hardcoded lyx_dir is used.
// If we had a command line switch, system_lyxdir_ is already set
- string searchpath;
if (!system_lyxdir_.empty())
searchpath = MakeAbsPath(system_lyxdir_) + ';';
Index: src/support/path_defines.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/path_defines.h,v
retrieving revision 1.5
diff -u -p -r1.5 path_defines.h
--- src/support/path_defines.h 28 Jul 2003 11:43:40 - 1.5
+++ src/support/path_defines.h 1 Aug 2003 16:09:01 -
@@ -19,16 +19,14 @@ namespace support {
string const & lyx_localedir();
-/* The absolute path to the lyx build directory.
- * (Make-time value.)
- */
-string const & build_lyxdir();
-
/// The absolute path to the lyx support files we're actually going to use.
string const & system_lyxdir();
/// Set the absolute path to the lyx support files (from the command line).
void system_lyxdir(string const &);
+
+/// The absolute path to the lyx support files in the build directory
+string const & build_lyxdir();
/// The absolute path to the user-level lyx support files.
string const & user_lyxdir();
FYI: scrolling performance profiles
The map find at the top is the Qt char width cache. This is doing "page down"s in the user guide, optimised build. The QFontPrivate::load() looks odd. CPU: PIII, speed 863.205 MHz (estimated) Counted CPU_CLK_UNHALTED events (clocks processor is not halted) with a unit mask of 0x00 (No unit mask) count 2 vma samples % image name symbol name 0821a0b8 38821 5.8588 lyx _Rb_tree, unsigned short const>::find(unsigned short const&) 08135be4 22648 3.4180 lyx LyXText::setHeightOfRow(_List_iterator) 9f30 15721 2.3726 libpthread-0.10.so __pthread_alt_unlock a120 15092 2.2777 libpthread-0.10.so __pthread_alt_lock 082193d8 11490 1.7341 lyx qfont_loader::getfontinfo(LyXFont const&) 08133e08 11082 1.6725 lyx LyXText::leftMargin(Row const&) const 08126000 10591 1.5984 lyx paintRowsHelper(BufferView const&, LyXText const&, _List_iterator, int, int, int) 001a26f0 9820 1.4820 libqt-mt.so.3.0.5 QFontPrivate::load(QFont::Script, bool) 0821a74c 9499 1.4336 lyx font_metrics::width(char const*, unsigned, LyXFont const&) 08219464 8880 1.3402 lyx qfont_loader::charwidth(LyXFont const&, unsigned short) 080f0428 8170 1.2330 lyx LyXFont::realShape() const 93b0 7997 1.2069 libXft.so.2.0XftGlyphExtents 0811e37c 7981 1.2045 lyx Paragraph::Pimpl::getChar(int) const 0813f2d4 7966 1.2022 lyx LyXText::metrics(MetricsInfo&, Dimension&) 08064958 7363 1.1112 lyx _List_base::clear() 0807a024 7199 1.0865 lyx InsetList::begin() 0006a430 7189 1.0850 libstdc++.so.5.0.1 string::compare(char const*) const 6ce0 6905 1.0421 libpthread-0.10.so __GI___pthread_mutex_lock 420f0f50 6700 1.0112 libc-2.3.2.sopthread_mutex_lock 4207b8d0 6578 0.9927 libc-2.3.2.sostrlen 0811c42c 6523 0.9844 lyx Paragraph::size() const 0006a640 6334 0.9559 libstdc++.so.5.0.1 string::_Rep::_S_create(unsigned, allocator const&) 081c3b00 6208 0.9369 lyx InsetTabular::calculate_dimensions_of_cells(MetricsInfo&) const 0813d4f4 6085 0.9183 lyx LyXText::getFont(_List_iterator, int) const 081196b4 6056 0.9140 lyx Paragraph::getFontSettings(BufferParams const&, int) const 082fbacc 5586 0.8430 lyx lyx::support::Assert(bool) 4207d870 5552 0.8379 libc-2.3.2.somemcpy 001a3ef0 5400 0.8150 libqt-mt.so.3.0.5QFontMetrics::ascent() const 6eb0 5396 0.8144 libpthread-0.10.so __GI___pthread_mutex_unlock 08163830 5184 0.7824 lyx MathArray::metrics(MetricsInfo&) const cde0 5130 0.7742 libXft.so.2.0XftCharIndex 08135490 5122 0.7730 lyx LyXText::fill(_List_iterator, int) const 08134ef8 5096 0.7691 lyx LyXText::rowBreakPoint(Row const&) const 00067210 4898 0.7392 libstdc++.so.5.0.1 string::_Rep::_M_grab(allocator const&, allocator const&) 0811a970 4591 0.6929 lyx Paragraph::getDepth() const 0818f88c 4542 0.6855 lyx lookupFont(string const&) 080fd994 4480 0.6761 lyx LyXLength::inPixels(int, int) const 0821a418 4448 0.6713 lyx charwidth(unsigned short, LyXFont const&) 00067320 4310 0.6505 libstdc++.so.5.0.1 string::string(string const&) 081be0a0 4256 0.6423 lyx InsetQuotes::dispString(Language const*) const 0006a790 4228 0.6381 libstdc++.so.5.0.1 string::_Rep::_M_destroy(allocator const&) 0003ad88 4082 0.6161 libstdc++.so.5.0.1 __i686.get_pc_thunk.bx 420f0f90 3937 0.5942 libc-2.3.2.sopthread_mutex_unlock 08132cd0 3894 0.5877 lyx LyXText::bv() const 0810cb14 3879 0.5854 lyx Row::par() const -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: [Patch] authors update
On Fri, Aug 01, 2003 at 05:25:23PM +0200, Jean-Marc Lasgouttes spake thusly: > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: > > Martin> I will commit this, if you don't object. > > Go ahead. > > JMarc Done. - Martin pgp0.pgp Description: PGP signature
Re: lyxpreview2bitmap.sh
> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes: Dekel> Is there any objection to change the line LATEX=latex in Dekel> lyxpreview2bitmap.sh to LATEX=elatex ? Dekel> I want this change as latex with Hebrew requires using elatex. Dekel> As far as I know, there are no side effects when elatex is Dekel> used. ... except when elatex is not installed at the site. I know I have a crappy installation here, but I think that there are other persons that choose not to build these formats for whetever reason. Actually, what we need is a way for lyxpreview2bitmap.sh to pick up the latex->dvi converter setting, but I am not sure how. JMarc
Re: [Patch] authors update
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: Martin> I will commit this, if you don't object. Go ahead. JMarc
[patch] merge BufferView::update() and repaint
They do the same nowadays...
--
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...)
? 1.diff
? fullredraw.diff
? insets/1.diff
Index: BufferView.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView.C,v
retrieving revision 1.173
diff -u -p -r1.173 BufferView.C
--- BufferView.C1 Aug 2003 11:22:10 - 1.173
+++ BufferView.C1 Aug 2003 15:22:54 -
@@ -130,12 +130,6 @@ void BufferView::resize()
}
-void BufferView::repaint()
-{
- pimpl_->repaint();
-}
-
-
bool BufferView::fitCursor()
{
return pimpl_->fitCursor();
Index: BufferView.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView.h,v
retrieving revision 1.134
diff -u -p -r1.134 BufferView.h
--- BufferView.h28 Jul 2003 23:53:35 - 1.134
+++ BufferView.h1 Aug 2003 15:22:54 -
@@ -70,12 +70,6 @@ public:
/// resize event has happened
void resize();
- /**
-* Repaint the pixmap. Used for when we don't want
-* to go through the full update() logic, just a simple
-* repaint of the whole screen.
-*/
- void repaint();
/// reload the contained buffer
void reload();
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.405
diff -u -p -r1.405 BufferView_pimpl.C
--- BufferView_pimpl.C 1 Aug 2003 15:17:20 - 1.405
+++ BufferView_pimpl.C 1 Aug 2003 15:22:54 -
@@ -319,7 +319,7 @@ void BufferView::Pimpl::buffer(Buffer *
textcache.clear();
}
- repaint();
+ update();
updateScrollbar();
owner_->updateMenubar();
owner_->updateToolbar();
@@ -366,7 +366,7 @@ void BufferView::Pimpl::redoCurrentBuffe
resizeCurrentBuffer();
updateScrollbar();
owner_->updateLayoutChoice();
- repaint();
+ update();
}
}
@@ -466,14 +466,6 @@ int BufferView::Pimpl::resizeCurrentBuff
}
-void BufferView::Pimpl::repaint()
-{
- // Regenerate the screen.
- lyxerr << "BufferView::repaint()\n";
- screen().redraw(*bv_);
-}
-
-
void BufferView::Pimpl::updateScrollbar()
{
if (!bv_->text) {
@@ -635,9 +627,8 @@ void BufferView::Pimpl::workAreaResize()
}
}
- if (widthChange || heightChange) {
- repaint();
- }
+ if (widthChange || heightChange)
+ update();
// always make sure that the scrollbar is sane.
updateScrollbar();
@@ -1226,9 +1217,8 @@ bool BufferView::Pimpl::dispatch(FuncReq
if (name == "bibitem") {
// We need to do a redraw because the maximum
// InsetBibitem width could have changed
-#warning please check you mean repaint() not update(),
-#warning and whether the repaint() is needed at all
- bv_->repaint();
+#warning check whether the update() is needed at all
+ bv_->update();
bv_->fitCursor();
}
} else {
Index: BufferView_pimpl.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.h,v
retrieving revision 1.95
diff -u -p -r1.95 BufferView_pimpl.h
--- BufferView_pimpl.h 28 Jul 2003 21:22:39 - 1.95
+++ BufferView_pimpl.h 1 Aug 2003 15:22:54 -
@@ -59,8 +59,6 @@ struct BufferView::Pimpl : public boost:
///
bool loadLyXFile(string const &, bool);
///
- void repaint();
- ///
void workAreaResize();
///
void updateScrollbar();
Index: lyxfunc.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxfunc.C,v
retrieving revision 1.473
diff -u -p -r1.473 lyxfunc.C
--- lyxfunc.C 30 Jul 2003 15:34:47 - 1.473
+++ lyxfunc.C 1 Aug 2003 15:22:54 -
@@ -118,7 +118,7 @@ void LyXFunc::moveCursorUpdate()
if (lt->selection.mark()) {
lt->setSelection();
if (!lt->isInInset())
- view()->repaint();
+ view()->update();
}
view()->update(lt, BufferView::SELECT);
view()->switchKeyMap();
@@ -1535,7 +1535,7 @@ void LyXFunc::dispatch(FuncRequest const
// if values really changed...but not very important right now. (Lgb)
// All visible buffers will need resize
view()->resize();
- view()->repaint();
+ view()->u
[patch] remove needUpdate & Co
80 lines bite the dust...
--
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...)
? 1.diff
? fullredraw.diff
? insets/1.diff
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.404
diff -u -p -r1.404 BufferView_pimpl.C
--- BufferView_pimpl.C 1 Aug 2003 14:51:08 - 1.404
+++ BufferView_pimpl.C 1 Aug 2003 15:09:29 -
@@ -650,7 +650,6 @@ void BufferView::Pimpl::update()
{
lyxerr << "BufferView::update()\n";
screen().redraw(*bv_);
- bv_->text->clearPaint();
}
Index: lyxtext.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxtext.h,v
retrieving revision 1.203
diff -u -p -r1.203 lyxtext.h
--- lyxtext.h 1 Aug 2003 11:22:10 - 1.203
+++ lyxtext.h 1 Aug 2003 15:09:29 -
@@ -167,12 +167,6 @@ public:
/// compute text metrics
void metrics(MetricsInfo & mi, Dimension & dim);
- /// clear any pending paints
- void clearPaint();
-
- /// submit repaint request
- void postPaint();
-
///
InsetOld::RESULT dispatch(FuncRequest const & cmd);
@@ -181,16 +175,6 @@ public:
BufferView * bv() const;
friend class LyXScreen;
-
- /**
-* Return the status. This represents what repaints are
-* pending after some operation (e.g. inserting a char).
-*/
- bool needRefresh() const;
-
-private:
- // do we need a refresh?
- bool need_refresh_;
public:
/// only the top-level LyXText has this non-zero
Index: text.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text.C,v
retrieving revision 1.403
diff -u -p -r1.403 text.C
--- text.C 1 Aug 2003 14:12:03 - 1.403
+++ text.C 1 Aug 2003 15:09:29 -
@@ -126,7 +126,6 @@ void LyXText::top_y(int newy)
anchor_row_offset_ = newy - y;
lyxerr[Debug::GUI] << "changing reference to row: " << &*anchor_row_
<< " offset: " << anchor_row_offset_ << endl;
- postPaint();
}
@@ -1542,8 +1541,6 @@ void LyXText::breakParagraph(ParagraphLi
cursorLeft(bv());
}
- postPaint();
-
removeParagraph(cursorRow());
// set the dimensions of the cursor row
@@ -1732,8 +1729,6 @@ void LyXText::insertChar(char c)
setHeightOfRow(boost::prior(row));
- postPaint();
-
breakAgainOneRow(row);
current_font = rawtmpfont;
@@ -1760,7 +1755,6 @@ void LyXText::insertChar(char c)
}
if (c == Paragraph::META_INSET || row->fill() < 0) {
- postPaint();
breakAgainOneRow(row);
RowList::iterator next_row = boost::next(row);
@@ -1788,7 +1782,6 @@ void LyXText::insertChar(char c)
} else {
// FIXME: similar code is duplicated all over - make resetHeightOfRow
setHeightOfRow(row);
- postPaint();
current_font = rawtmpfont;
real_current_font = realtmpfont;
@@ -2266,9 +2259,6 @@ void LyXText::changeCase(LyXText::TextCa
++pos;
}
-
- if (getRow(to) != getRow(from))
- postPaint();
}
@@ -2350,10 +2340,7 @@ void LyXText::backspace()
cursorLeft(bv());
// the layout things can change the height of a row !
- int const tmpheight = cursorRow()->height();
setHeightOfRow(cursorRow());
- if (cursorRow()->height() != tmpheight)
- postPaint();
return;
}
}
@@ -2407,8 +2394,6 @@ void LyXText::backspace()
if (cursor.pos())
cursor.pos(cursor.pos() - 1);
- postPaint();
-
// remove the lost paragraph
// This one is not safe, since the paragraph that the tmprow
and the
// following rows belong to has been deleted by the
PasteParagraph
@@ -2531,7 +2516,6 @@ void LyXText::backspace()
y -= tmprow->height();
tmprow->fill(fill(tmprow, workWidth()));
setHeightOfRow(tmprow);
- postPaint();
setCursor(cursor.par(), cursor.pos(),
false, cursor.boundary());
@@ -2559,8 +2543,6 @@ void LyXText::backs
Re: Question on lyx2lyx
On Friday 01 August 2003 15:17, Dekel Tsur wrote: > Jose, why does lyxconvert_216.py changes the language of the document to > 'english' ? > I agree that if the language was 'default' (IIRC, LyX used to have this > option) then the language should be changed, but this is incorrect in all > other cases. That should be changed to english only if it is default, else it is a bug. -- José Abílio LyX and docbook, a perfect match. :-)
lyxpreview2bitmap.sh
Is there any objection to change the line LATEX=latex in lyxpreview2bitmap.sh to LATEX=elatex ? I want this change as latex with Hebrew requires using elatex. As far as I know, there are no side effects when elatex is used.
[patch] even more wasted cycles
But merges Screen::update() and Screen::redraw() and removes a redraw
argument.
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...)
? .text2.C.swp
? 1.diff
? fullredraw.diff
? insets/1.diff
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.403
diff -u -p -r1.403 BufferView_pimpl.C
--- BufferView_pimpl.C 31 Jul 2003 10:48:49 - 1.403
+++ BufferView_pimpl.C 1 Aug 2003 14:46:51 -
@@ -469,7 +469,8 @@ int BufferView::Pimpl::resizeCurrentBuff
void BufferView::Pimpl::repaint()
{
// Regenerate the screen.
- screen().redraw(bv_, bv_->text);
+ lyxerr << "BufferView::repaint()\n";
+ screen().redraw(*bv_);
}
@@ -648,7 +649,7 @@ void BufferView::Pimpl::workAreaResize()
void BufferView::Pimpl::update()
{
lyxerr << "BufferView::update()\n";
- screen().update(*bv_);
+ screen().redraw(*bv_);
bv_->text->clearPaint();
}
Index: text2.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text2.C,v
retrieving revision 1.411
diff -u -p -r1.411 text2.C
--- text2.C 1 Aug 2003 14:12:04 - 1.411
+++ text2.C 1 Aug 2003 14:46:51 -
@@ -648,7 +648,7 @@ void LyXText::redoParagraph(ParagraphLis
// insert a new row, starting at position 0
Row newrow(pit, 0);
rit = rowlist_.insert(rit, newrow);
- newrow.dump("newrow: ");
+ //newrow.dump("newrow: ");
// and now append the whole paragraph before the new row
// was: appendParagraph(rit);
@@ -660,12 +660,12 @@ void LyXText::redoParagraph(ParagraphLis
pos_type z = rowBreakPoint(*rit);
RowList::iterator tmprow = rit;
- tmprow->dump("tmprow: ");
+ //tmprow->dump("tmprow: ");
if (z < last) {
++z;
Row newrow(rit->par(), z);
- newrow.dump("newrow2: ");
+ //newrow.dump("newrow2: ");
rit = rowlist_.insert(boost::next(rit), newrow);
} else {
done = true;
@@ -674,11 +674,11 @@ void LyXText::redoParagraph(ParagraphLis
// Set the dimensions of the row
// fixed fill setting now by calling inset->update() in
// SingleWidth when needed!
- tmprow->dump("tmprow 1: ");
+ //tmprow->dump("tmprow 1: ");
tmprow->fill(fill(tmprow, workWidth()));
- tmprow->dump("tmprow 2: ");
+ //tmprow->dump("tmprow 2: ");
setHeightOfRow(tmprow);
- tmprow->dump("tmprow 3: ");
+ //tmprow->dump("tmprow 3: ");
height += rit->height();
} while (!done);
Index: frontends/screen.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/screen.C,v
retrieving revision 1.58
diff -u -p -r1.58 screen.C
--- frontends/screen.C 29 Jul 2003 10:00:51 - 1.58
+++ frontends/screen.C 1 Aug 2003 14:46:51 -
@@ -297,25 +297,6 @@ bool LyXScreen::fitCursor(LyXText * text
}
-void LyXScreen::update(BufferView & bv, int yo, int xo)
-{
- LyXText * text = bv.text;
-
- workarea().getPainter().start();
-
- if (text->needRefresh()) {
- int const vwidth = workarea().workWidth();
- int const vheight = workarea().workHeight();
- text->updateRowPositions();
- int const y = 0;
- drawFromTo(text, &bv, y, vheight, yo, xo);
- expose(0, y, vwidth, vheight - y);
- }
-
- workarea().getPainter().end();
-}
-
-
void LyXScreen::toggleSelection(LyXText * text, BufferView * bv,
bool kill_selection,
int yo, int xo)
@@ -348,9 +329,9 @@ void LyXScreen::toggleSelection(LyXText
}
-void LyXScreen::redraw(BufferView * bv, LyXText * text)
+void LyXScreen::redraw(BufferView & bv)
{
- greyed_out_ = !text;
+ greyed_out_ = !bv.text;
if (greyed_out_) {
greyOut();
@@ -359,8 +340,8 @@ void LyXScreen::redraw(BufferView * bv,
workarea().getPainter().start();
- text->updateRowPositions();
- drawFromTo(text, bv, 0, workarea().workHeight(), 0, 0);
+ bv.text->updateRowPositions();
+ drawFromTo(bv.text, &bv, 0, workarea().workHeight(), 0, 0);
expose(0, 0, workarea().workWidth(), workarea().workHeight());
workarea().getPainter().end();
Index: frontends/screen.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-d
Re: [patch] more slowness
Angus Leeming wrote: > * Make generation of dvi, ps, pdf files etc asynchronous. If Alfredo > doesn't beat me to it. :-) Every time I look into this I finish by considering bigger reworking plans than I can manage. I will gladly help you with the dirty work, if there is some... Regards, Alfredo
Re: [Patch] authors update
I will commit this, if you don't object. Martin -- Martin Vermeer [EMAIL PROTECTED] Helsinki University of Technology Dept. of Surveying, Inst. of Geodesy P.O. Box 1200, FIN-02015 HUT, Finland :wq Index: insetnote.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetnote.C,v retrieving revision 1.37 diff -u -p -r1.37 insetnote.C --- insetnote.C 30 Jul 2003 21:47:18 - 1.37 +++ insetnote.C 1 Aug 2003 14:42:35 - @@ -4,6 +4,8 @@ * Licence details can be found in the file COPYING. * * \author Angus Leeming + * \author Martin Vermeer + * \author Jürgen Spitzmüller * * Full author contact details are available in file CREDITS */ pgp0.pgp Description: PGP signature
Re: [Patch] Branch, latest
On Fri, Aug 01, 2003 at 05:22:41PM +0300, Martin Vermeer wrote: > I have read that in implementing a typical feature, 90% of the effort > goes to the user interface. Perhaps this is typical... Dunno where you heard that ... it's more the other way around. This is why you should never do mockups, people will think that you've finished :) john
Re: [Patch] Branch, latest
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: Martin> Actually I agree with you. The thing is ready, useable, and Martin> proposes a reasonable and clean extension to the document Martin> format. The only dangling end, colour, has a proposed Martin> consensus solution that is unimplemented still but similarly Martin> unproblematic. Martin> Lars, what do you think? Can this go in? Latest patch attached Martin> in toto. If I am allowed to be annoying (anyway this is friday...): --- src/lyxfunc.C 30 Jul 2003 15:34:47 - 1.473 +++ src/lyxfunc.C 1 Aug 2003 13:38:22 - @@ -636,6 +639,13 @@ FuncStatus LyXFunc::getStatus(FuncReques break; case LFUN_INSERT_NOTE: code = InsetOld::NOTE_CODE; + break; + case LFUN_INSERT_BRANCH: + code = InsetOld::BRANCH_CODE; + if (buf) + disable = buf->params.branchlist.allBranches().empty(); + else + disable = true; You are guaranteed at this point that buf is not null (due to the Noop flag of LFUN_INSERT_BRANCH), so it is not needed to test. Also, this code could (in theory, not in practice) set disable to false in a case where it was true for some other reason. So it is better to use if (buf->params.branchlist.allBranches().empty()) disable = true; or probably (but I am unsure of how hat works for bools) disable |= buf->params.branchlist.allBranches().empty(); Finally, it would be less costly to add a size() member to BranchList and use that instead of generating a full list of branches in the test. A very nice patch, indeed. I would not be annoyed if you commit it as it is and do the cleanup later. JMarc
Question on lyx2lyx
Jose, why does lyxconvert_216.py changes the language of the document to 'english' ? I agree that if the language was 'default' (IIRC, LyX used to have this option) then the language should be changed, but this is incorrect in all other cases.
Re: [Patch] Branch, latest
On Fri, Aug 01, 2003 at 05:22:41PM +0300, Martin Vermeer wrote: > The thing is ready, useable, and proposes a > reasonable and clean extension to the document format. The only > dangling end, colour, has a proposed consensus solution that is > unimplemented still but similarly unproblematic. So just commit. > I have read that in implementing a typical feature, 90% of the effort > goes to the user interface. Perhaps this is typical... *grin* Unfortunately... yes. Now, if you have spare capacity, there are a few math inset that could make use of a dialog ;-} 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...)
[patch] 'standalone' redoParagraph
This basically pulls in the rowbreaking code of insertParagraph and
appendParagraph into 'redoParagraph'. Plan is to cut to replace the
rowbreaking code spilled all over the place by calls to redoParagraph
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: text2.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text2.C,v
retrieving revision 1.410
diff -u -p -r1.410 text2.C
--- text2.C 1 Aug 2003 12:33:42 - 1.410
+++ text2.C 1 Aug 2003 14:06:31 -
@@ -281,11 +281,11 @@ void LyXText::removeParagraph(RowList::i
void LyXText::insertParagraph(ParagraphList::iterator pit,
- RowList::iterator rowit)
+ RowList::iterator rit)
{
// insert a new row, starting at position 0
Row newrow(pit, 0);
- RowList::iterator rit = rowlist_.insert(rowit, newrow);
+ rit = rowlist_.insert(rit, newrow);
// and now append the whole paragraph before the new row
appendParagraph(rit);
@@ -645,7 +645,44 @@ void LyXText::redoParagraph(ParagraphLis
}
// reinsert the paragraph
- insertParagraph(pit, rit);
+ // insert a new row, starting at position 0
+ Row newrow(pit, 0);
+ rit = rowlist_.insert(rit, newrow);
+ newrow.dump("newrow: ");
+
+ // and now append the whole paragraph before the new row
+ // was: appendParagraph(rit);
+
+ pos_type const last = rit->par()->size();
+ bool done = false;
+
+ do {
+ pos_type z = rowBreakPoint(*rit);
+
+ RowList::iterator tmprow = rit;
+ tmprow->dump("tmprow: ");
+
+ if (z < last) {
+ ++z;
+ Row newrow(rit->par(), z);
+ newrow.dump("newrow2: ");
+ rit = rowlist_.insert(boost::next(rit), newrow);
+ } else {
+ done = true;
+ }
+
+ // Set the dimensions of the row
+ // fixed fill setting now by calling inset->update() in
+ // SingleWidth when needed!
+ tmprow->dump("tmprow 1: ");
+ tmprow->fill(fill(tmprow, workWidth()));
+ tmprow->dump("tmprow 2: ");
+ setHeightOfRow(tmprow);
+ tmprow->dump("tmprow 3: ");
+ height += rit->height();
+
+ } while (!done);
+
setHeightOfRow(rows().begin());
}
@@ -661,7 +698,7 @@ void LyXText::fullRebreak()
void LyXText::metrics(MetricsInfo & mi, Dimension & dim)
{
- lyxerr << "LyXText::metrics: width: " << mi.base.textwidth << "\n";
+ //lyxerr << "LyXText::metrics: width: " << mi.base.textwidth << "\n";
//Assert(mi.base.textwidth);
// rebuild row cache
@@ -680,6 +717,8 @@ void LyXText::metrics(MetricsInfo & mi,
for (; ii != iend; ++ii) {
Dimension dim;
MetricsInfo m = mi;
+#warning FIXME: pos != 0
+ m.base.font = getFont(pit, 0);
ii->inset->metrics(m, dim);
}
@@ -1873,7 +1912,8 @@ void LyXText::cursorLeft(bool internal)
if (!internal && !boundary &&
isBoundary(bv()->buffer(), *cursor.par(), cursor.pos() + 1))
setCursor(cursor.par(), cursor.pos() + 1, true, true);
- } else if (cursor.par() != ownerParagraphs().begin()) { // steps into the
above paragraph.
+ } else if (cursor.par() != ownerParagraphs().begin()) {
+ // steps into the paragraph above
ParagraphList::iterator pit = boost::prior(cursor.par());
setCursor(pit, pit->size());
}
@@ -1949,12 +1989,10 @@ void LyXText::cursorDown(bool selecting)
void LyXText::cursorUpParagraph()
{
- if (cursor.pos() > 0) {
+ if (cursor.pos() > 0)
setCursor(cursor.par(), 0);
- }
- else if (cursor.par() != ownerParagraphs().begin()) {
+ else if (cursor.par() != ownerParagraphs().begin())
setCursor(boost::prior(cursor.par()), 0);
- }
}
Re: [Patch] Branch, latest
On Fri, Aug 01, 2003 at 08:38:37AM +0200, Juergen Spitzmueller spake thusly: > Martin Vermeer wrote: > > As I seem to be going off to the country again, you may wish to have a > > go at this yourself in your copious spare time [check weekday]. > > Why not applying your latest and greatest version of branches without color > support? You have done an amazing job and I think the thing is ready now. You > can append the color stuff when it's ready on don't have to bother about the > rest. > > Juergen. Juergen, flattering won't get you anywhere either [check weekday]. Actually you and Angus have no small part in this work. And all the others that broke in with their critique. This is the perfect learning environment. Actually I agree with you. The thing is ready, useable, and proposes a reasonable and clean extension to the document format. The only dangling end, colour, has a proposed consensus solution that is unimplemented still but similarly unproblematic. Lars, what do you think? Can this go in? Latest patch attached in toto. An interesting experience, though... I would have been perfectly happy with my first, pseudo-charstyles-based solution. (Actually I preferred its UI, even if it required maintenance of metadata in the user's head.) The present solution represents 10x the effort, 10x the LOC, and presumably a contribution to binary size that is similarly large. Ah well, memory is cheap. I *am* happy that what we now have is reasonably clean OO C++, even if the end user will never see it. It pays off longer term. I have read that in implementing a typical feature, 90% of the effort goes to the user interface. Perhaps this is typical... - Martin -- Martin Vermeer [EMAIL PROTECTED] Helsinki University of Technology Dept. of Surveying, Inst. of Geodesy P.O. Box 1200, FIN-02015 HUT, Finland :wq branch_n.diff.gz Description: application/gunzip pgp0.pgp Description: PGP signature
Re: [patch] more slowness
On Fri, Aug 01, 2003 at 01:50:16PM +0100, Angus Leeming wrote: > Your good lady [...] > Smaller bits: [...] > Bigger projects: [...] Okokok... 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] more slowness
Andre Poenitz wrote: > Exactly. > > And all the current "structure modifying functions" (like > appendParagraph) that happen to update the row cache (or even are > currently the primary means to keep that cache consistent) should > lose that ability in the end. So all of the "double work" should go. > > Feel invited to help. I'm afraid I will have to politely decline that invitation. Your good lady is keeping me quite busy enough, thank you: Smaller bits: * Extend the FileName class as discussed on the list. * Enable the user to choose the order in which External Templates appear in that combox by modifying the externall_templates file. The data must be stored in a vector rather tahn a map for this to be achieved. * Prevent unnecessary regeneration of temporary files when re-running latex. * Enable the user to choose 'PrettyRef' etc as the default in the reference dialog. The idea is to have a static default_type var hidden inside InsetRef.C and to use this to initialise the inset member var in the constructor. It will be re-set in the inset::read function. Bigger projects: * Finish cleaning up InsetBibtex's internal structure. Move the parsing of the Bibtex file out of InsetBibtex and into something analogous to the graphics code. * Finish the rework of the dialog controllers (9 left to convert). * Get rid of the graphics inset entirely. The grammar of the External Templates will need to be augmented for this to happen. I have some rough sketch for how to do this. * Make generation of dvi, ps, pdf files etc asynchronous. If Alfredo doesn't beat me to it. -- Angus
Re: [patch] more slowness
On Fri, Aug 01, 2003 at 01:11:46PM +0100, Angus Leeming wrote:
> Andre Poenitz wrote:
>
> >
> > Can anybody see a regression other than slowness with this?
> >
> > [This makes 'redoParagraphs' a loop over 'redoParagraph' instead of
> > calling the first from the latter.]
>
> Just for information, your plan is to re-implement drawing in a clear
> and transparent way. Thereafter, ascertain what optimisations are
> necessary to speed things up. In this way, you hope to understand how
> the whole thing fits together.
>
> Presumably you envisage a final, top-level algorithm taht can be
> represented in psudo code as
>
> Paragraph * par = par_that_has_been_modified();
> par()->metrics();
>
> ParagraphIterator pit = top_visible_paragraph();
> ParagraphIterator pend = one_past_bottom_visible_paragraph();
> for (; pit != pend; ++pit) {
> pit->draw();
> }
>
> The Paragraph::metrics() and Paragraph::draw() functions are just
> simple, 'brainless' loops over all chars/insets? No further
> optimisation should be needed.
>
> Is this how you envisage things panning out?
Exactly.
And all the current "structure modifying functions" (like
appendParagraph) that happen to update the row cache (or even are
currently the primary means to keep that cache consistent) should
lose that ability in the end. So all of the "double work" should go.
Feel invited to help.
> (Ok, I understand that rows and paragraph positions come in here
> somewhere too)
We can't do without them, but they would be much less visible in "User
code" as they are now...
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] more slowness
Andre Poenitz wrote:
>
> Can anybody see a regression other than slowness with this?
>
> [This makes 'redoParagraphs' a loop over 'redoParagraph' instead of
> calling the first from the latter.]
Just for information, your plan is to re-implement drawing in a clear
and transparent way. Thereafter, ascertain what optimisations are
necessary to speed things up. In this way, you hope to understand how
the whole thing fits together.
Presumably you envisage a final, top-level algorithm taht can be
represented in psudo code as
Paragraph * par = par_that_has_been_modified();
par()->metrics();
ParagraphIterator pit = top_visible_paragraph();
ParagraphIterator pend = one_past_bottom_visible_paragraph();
for (; pit != pend; ++pit) {
pit->draw();
}
The Paragraph::metrics() and Paragraph::draw() functions are just
simple, 'brainless' loops over all chars/insets? No further
optimisation should be needed.
Is this how you envisage things panning out?
(Ok, I understand that rows and paragraph positions come in here
somewhere too)
--
Angus
[patch] more slowness
Can anybody see a regression other than slowness with this?
[This makes 'redoParagraphs' a loop over 'redoParagraph' instead of
calling the first from the latter.]
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: text2.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text2.C,v
retrieving revision 1.408
diff -u -p -r1.408 text2.C
--- text2.C 1 Aug 2003 11:22:12 - 1.408
+++ text2.C 1 Aug 2003 11:46:37 -
@@ -631,80 +631,48 @@ RowList::iterator LyXText::firstRow(Para
// rebreaks all paragraphs between the specified pars
// This function is needed after SetLayout and SetFont etc.
void LyXText::redoParagraphs(ParagraphList::iterator start,
- ParagraphList::iterator endpit)
+ ParagraphList::iterator end)
{
- RowList::iterator rit = firstRow(start);
+ for ( ; start != end; ++start)
+ redoParagraph(start);
+}
+
+
+void LyXText::redoParagraph(ParagraphList::iterator pit)
+{
+ RowList::iterator rit = firstRow(pit);
if (rit == rows().end()) {
lyxerr << "LyXText::redoParagraphs: should not happen\n";
Assert(0);
}
- ParagraphList::iterator first_phys_pit;
- RowList::iterator prevrit;
- if (rit == rows().begin()) {
- // A trick/hack for UNDO.
- // This is needed because in an UNDO/REDO we could have
- // changed the ownerParagraph() so the paragraph inside
- // the row is NOT my really first par anymore.
- // Got it Lars ;) (Jug 20011206)
- first_phys_pit = ownerParagraphs().begin();
- prevrit = rows().end();
- } else {
- first_phys_pit = rit->par();
- while (rit != rows().begin()
- && boost::prior(rit)->par() == first_phys_pit)
- {
- --rit;
- }
- prevrit = boost::prior(rit);
- }
-
// remove it
- while (rit != rows().end() && rit->par() != endpit) {
+ while (rit != rows().end() && rit->par() == pit) {
RowList::iterator rit2 = rit++;
removeRow(rit2);
}
- // Reinsert the paragraphs.
- ParagraphList::iterator tmppit = first_phys_pit;
-
- while (tmppit != ownerParagraphs().end()) {
- insertParagraph(tmppit, rit);
- while (rit != rows().end() && rit->par() == tmppit)
- ++rit;
- ++tmppit;
- if (tmppit == endpit)
- break;
- }
- if (prevrit != rows().end())
- setHeightOfRow(prevrit);
- else
- setHeightOfRow(rows().begin());
- postPaint();
- if (rit != rows().end())
- setHeightOfRow(rit);
-
+ // Reinsert the paragraph.
+ insertParagraph(pit, rit);
+ setHeightOfRow(rows().begin());
updateCounters();
}
-void LyXText::redoParagraph(ParagraphList::iterator pit)
-{
- redoParagraphs(pit, boost::next(pit));
-}
-
-
void LyXText::fullRebreak()
{
- init(bv());
+ lyxerr << "fullRebreak\n";
+ redoParagraphs(ownerParagraphs().begin(), ownerParagraphs().end());
setCursorIntern(cursor.par(), cursor.pos());
+ selection.cursor = cursor;
}
void LyXText::metrics(MetricsInfo & mi, Dimension & dim)
{
- //lyxerr << "LyXText::metrics: width: " << mi.base.textwidth << "\n";
+ lyxerr << "LyXText::metrics: width: " << mi.base.textwidth << "\n";
+ //Assert(mi.base.textwidth);
// rebuild row cache
rowlist_.clear();
[patch] redoParagraph
trade a few cycles for a clearer interface
--
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...)
? .lyxtext.h.swp
? 1.diff
? insets/1.diff
Index: BufferView.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView.C,v
retrieving revision 1.172
diff -u -p -r1.172 BufferView.C
--- BufferView.C28 Jul 2003 23:53:34 - 1.172
+++ BufferView.C1 Aug 2003 11:11:01 -
@@ -625,8 +625,7 @@ bool BufferView::ChangeInsets(InsetOld::
// How to set the cursor corretly when it.size()>1 ??
if (it.size() == 1) {
text->setCursorIntern(it.pit(), 0);
- text->redoParagraphs(text->cursor,
-boost::next(text->cursor.par()));
+ text->redoParagraph(text->cursor.par());
text->partialRebreak();
}
}
Index: lyxtext.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxtext.h,v
retrieving revision 1.202
diff -u -p -r1.202 lyxtext.h
--- lyxtext.h 31 Jul 2003 14:07:59 - 1.202
+++ lyxtext.h 1 Aug 2003 11:11:01 -
@@ -131,15 +131,15 @@ public:
*/
void setFont(LyXFont const &, bool toggleall = false);
- /** deletes and inserts again all paragaphs between the cursor
- and the specified par. The Cursor is needed to set the refreshing
- parameters.
- This function is needed after SetLayout and SetFont etc.
- */
- void redoParagraphs(LyXCursor const & cursor,
- ParagraphList::iterator endpit);
- ///
+ /// rebreaks all paragaphs between the given pars.
+ void redoParagraphs(ParagraphList::iterator begin,
+ ParagraphList::iterator end);
+ /// rebreaks the given par
+ void redoParagraph(ParagraphList::iterator pit);
+ /// rebreaks the cursor par
void redoParagraph();
+ /// returns first row belongin to some par
+ RowList::iterator firstRow(ParagraphList::iterator pit);
///
void toggleFree(LyXFont const &, bool toggleall = false);
Index: text.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text.C,v
retrieving revision 1.401
diff -u -p -r1.401 text.C
--- text.C 31 Jul 2003 14:07:59 - 1.401
+++ text.C 1 Aug 2003 11:11:01 -
@@ -1579,7 +1579,7 @@ void LyXText::breakParagraph(ParagraphLi
void LyXText::redoParagraph()
{
clearSelection();
- redoParagraphs(cursor, boost::next(cursor.par()));
+ redoParagraph(cursor.par());
setCursorIntern(cursor.par(), cursor.pos());
}
@@ -2007,7 +2007,7 @@ void LyXText::acceptChange()
startc.par()->acceptChange(startc.pos(), endc.pos());
finishUndo();
clearSelection();
- redoParagraphs(startc, boost::next(startc.par()));
+ redoParagraph(startc.par());
setCursorIntern(startc.par(), 0);
}
#warning handle multi par selection
@@ -2026,7 +2026,7 @@ void LyXText::rejectChange()
startc.par()->rejectChange(startc.pos(), endc.pos());
finishUndo();
clearSelection();
- redoParagraphs(startc, boost::next(startc.par()));
+ redoParagraph(startc.par());
setCursorIntern(startc.par(), 0);
}
#warning handle multi par selection
Index: text2.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text2.C,v
retrieving revision 1.407
diff -u -p -r1.407 text2.C
--- text2.C 31 Jul 2003 13:38:06 - 1.407
+++ text2.C 1 Aug 2003 11:11:01 -
@@ -443,7 +443,7 @@ void LyXText::setLayout(string const & l
ParagraphList::iterator endpit = setLayout(cursor, selection.start,
selection.end, layout);
- redoParagraphs(selection.start, endpit);
+ redoParagraphs(selection.start.par(), endpit);
// we have to reset the selection, because the
// geometry could have changed
@@ -511,15 +511,12 @@ bool LyXText::changeDepth(bv_funcs::DEPT
if (test_only)
return changed;
- // Wow, redoParagraphs is stupid.
- LyXCursor tmpcursor;
- setCursor(tmpcursor, start, 0);
- redoParagraphs(tmpcursor, pastend);
+ redoParagraphs(start, pastend);
// We need to actually move the text->cursor. I don't
// understand why ...
- tmpcursor = cursor;
+ LyXCursor tmpcursor = cursor;
//
Re: A plan for spam^Wmetrics
On Fri, Aug 01, 2003 at 12:05:18PM +0100, Angus Leeming wrote: > > Not when doing e.g. page down. All the y positions need updating at > > least... > > I thought 'metrics' meant width and height? Nothing to do with > position which is updated only in 'draw'. Or am I misunderstanding? You are not. 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: A plan for spam^Wmetrics
John Levon wrote: > On Fri, Aug 01, 2003 at 12:39:54PM +0200, Andre Poenitz wrote: > >> > You don't ... that's my point. The context is lost at the end of >> > dispatch() (consider LFUN_UP triggering DEPM on the previous >> > paragraph) >> >> The exact cursor par at the begin of the dispatch and the end is >> known... Even if that were not the case a 'redo pars currently >> visible on screen' would be enough. > > Not when doing e.g. page down. All the y positions need updating at > least... I thought 'metrics' meant width and height? Nothing to do with position which is updated only in 'draw'. Or am I misunderstanding? -- Angus
Re: A plan for spam^Wmetrics
On Fri, Aug 01, 2003 at 12:37:44PM +0200, Andre Poenitz wrote: > John thinks I will end up doing something like this since I propose to > aim for that. Of course not as a final solution, but something that can OK, I misunderstood you then, sorry^Wit's friday john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: A plan for spam^Wmetrics
On Fri, Aug 01, 2003 at 12:39:54PM +0200, Andre Poenitz wrote: > > You don't ... that's my point. The context is lost at the end of > > dispatch() (consider LFUN_UP triggering DEPM on the previous paragraph) > > The exact cursor par at the begin of the dispatch and the end is > known... Even if that were not the case a 'redo pars currently > visible on screen' would be enough. Not when doing e.g. page down. All the y positions need updating at least... regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: elsart.layout
> "Rod" == Rod Pinna <[EMAIL PROTECTED]> writes: Rod> Hopefully generated the diff correctly. My last change wasn't Rod> correctly incorporated. Hmm, what was wrong? You seem to be adding the same entry twice, don't you? JMarc Rod> Patch below, generated with Rod> cvs diff -u, for the top directory. The patch is in the right form, anyway. JMarc
Re: [PATCH] 1.3.x - latex-xft-fonts
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> On Thu, Jul 31, 2003 at 12:43:12PM +0200, Jean-Marc Lasgouttes John> wrote: I've uploaded RPM and a tarball of latex-xft-fonts. John> JMarc, can you place in the right place please ? >> I did that. I left the latex-ttf stuff there for now, since it is >> what the docs refer to. Shall I just remove this? John> Let's just remove it. It's not like anybody actually reads those John> docs. Done. JMarc
Re: A plan for spam^Wmetrics
On Fri, Aug 01, 2003 at 12:34:07PM +0200, Jean-Marc Lasgouttes wrote: > > "John" == John Levon <[EMAIL PROTECTED]> writes: > > >> Why do you need to recompute the metrics of the whole doc? > > John> You don't ... that's my point. The context is lost at the end of > John> dispatch() (consider LFUN_UP triggering DEPM on the previous > John> paragraph) > > So in this case DEPM should recompute metrics, right? Only for a (toplevel) par or two... 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: A plan for spam^Wmetrics
On Fri, Aug 01, 2003 at 11:25:46AM +0100, John Levon wrote: > On Fri, Aug 01, 2003 at 11:20:45AM +0100, Angus Leeming wrote: > > > >> The last line of some dispatch() method. > > >> LyXView::dispatch() or LyXFunc::dispatch() probably. > > > > > > We've lost all context at that point. I don't believe that a > > > full-doc re-metrics is ever going to be fast enough. > > > > Why do you need to recompute the metrics of the whole doc? > > You don't ... that's my point. The context is lost at the end of > dispatch() (consider LFUN_UP triggering DEPM on the previous paragraph) The exact cursor par at the begin of the dispatch and the end is known... Even if that were not the case a 'redo pars currently visible on screen' would be enough. 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: A plan for spam^Wmetrics
John Levon wrote: > On Fri, Aug 01, 2003 at 11:20:45AM +0100, Angus Leeming wrote: > >> >> The last line of some dispatch() method. >> >> LyXView::dispatch() or LyXFunc::dispatch() probably. >> > >> > We've lost all context at that point. I don't believe that a >> > full-doc re-metrics is ever going to be fast enough. >> >> Why do you need to recompute the metrics of the whole doc? > > You don't ... that's my point. The context is lost at the end of > dispatch() (consider LFUN_UP triggering DEPM on the previous > paragraph) Ok, so a maximum of 2 adjacent paragraphs should need theie metric to be recomputed. Nonetheless, this is presumably orthogonal to André's current work which is to get 2-phase drawing working properly for a single paragraph. Is it not possible to design some generic algorithm to perform this control over which paragraphs should have their metrics recomputed before this work on drawing of individual paragraphs is finished. A sort of 'white paper' if you will? I think such a thing would be beneficial to all and for all. -- Angus
Re: A plan for spam^Wmetrics
On Fri, Aug 01, 2003 at 11:20:45AM +0100, Angus Leeming wrote: > John Levon wrote: > > > On Fri, Aug 01, 2003 at 09:49:41AM +0200, Andre Poenitz wrote: > > > >> The last line of some dispatch() method. > >> LyXView::dispatch() or LyXFunc::dispatch() probably. > > > > We've lost all context at that point. I don't believe that a > > full-doc re-metrics is ever going to be fast enough. > > I am somewhat baffled by all this. Surely you need recompute the > metrics of only the top level paragraph containing the cursor. Ever. > > Ok, synchronous changes to the graphics inset will change other > paragraphs. So the concept is not 'cursor' but 'event'. Nonetheless, > only one paragraph is affected. > > Why do you need to recompute the metrics of the whole doc? John thinks I will end up doing something like this since I propose to aim for that. Of course not as a final solution, but something that can get some optimization tacked on in the end - like only touching the outermost cursor par. 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: A plan for spam^Wmetrics
On Fri, Aug 01, 2003 at 12:34:07PM +0200, Jean-Marc Lasgouttes wrote: > John> You don't ... that's my point. The context is lost at the end of > John> dispatch() (consider LFUN_UP triggering DEPM on the previous > John> paragraph) > > So in this case DEPM should recompute metrics, right? I would say so yes. Similarly for the other "top level" places that change such things. I really don't think there are actually too many of them (and currently they must all somehow call the breaking code anyway) regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: A plan for spam^Wmetrics
> "John" == John Levon <[EMAIL PROTECTED]> writes: >> Why do you need to recompute the metrics of the whole doc? John> You don't ... that's my point. The context is lost at the end of John> dispatch() (consider LFUN_UP triggering DEPM on the previous John> paragraph) So in this case DEPM should recompute metrics, right? JMarc
Re: Cleaning up the bibtex inset
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Shall I just try and code something up and we can see how it Angus> "feels"? Yes. JMarc
Re: A plan for spam^Wmetrics
On Fri, Aug 01, 2003 at 11:20:45AM +0100, Angus Leeming wrote: > >> The last line of some dispatch() method. > >> LyXView::dispatch() or LyXFunc::dispatch() probably. > > > > We've lost all context at that point. I don't believe that a > > full-doc re-metrics is ever going to be fast enough. > > Why do you need to recompute the metrics of the whole doc? You don't ... that's my point. The context is lost at the end of dispatch() (consider LFUN_UP triggering DEPM on the previous paragraph) regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: A plan for spam^Wmetrics
John Levon wrote: > On Fri, Aug 01, 2003 at 09:49:41AM +0200, Andre Poenitz wrote: > >> The last line of some dispatch() method. >> LyXView::dispatch() or LyXFunc::dispatch() probably. > > We've lost all context at that point. I don't believe that a > full-doc re-metrics is ever going to be fast enough. I am somewhat baffled by all this. Surely you need recompute the metrics of only the top level paragraph containing the cursor. Ever. Ok, synchronous changes to the graphics inset will change other paragraphs. So the concept is not 'cursor' but 'event'. Nonetheless, only one paragraph is affected. Why do you need to recompute the metrics of the whole doc? -- Angus
Re: Cleaning up the bibtex inset
Jean-Marc Lasgouttes wrote: > No, what is reasonable (TeX-wise) is to add ~angus/doc/ to the > BSTINPUTS environment variable. > > But then I am not writing your papers for you. ;-) > What I am saying is that we should look for a scheme to provide > resonable defaults. The user should always be able to modify the > string by hand and override the clever guessing. > > JMarc Shall I just try and code something up and we can see how it "feels"? -- Angus
Re: A plan for spam^Wmetrics
On Fri, Aug 01, 2003 at 09:49:41AM +0200, Andre Poenitz wrote: > The last line of some dispatch() method. > LyXView::dispatch() or LyXFunc::dispatch() probably. We've lost all context at that point. I don't believe that a full-doc re-metrics is ever going to be fast enough. regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: Cleaning up the bibtex inset
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: >> 1/ after browsing (in which directories does it browse, anyway?), >> you have an absolute path /foo/bar.bib. Angus> That is correct. (I'm not sure. Will look this evening.) Angus> However, the user will also be able to enter a file by typing Angus> it into the input widget. That can, of course, be a relative Angus> path. That's OK too. You can use the strategy we discussed in chemnizt about how to handel relative paths. >> 2/ if Makerelpath(/foo/bar.bib,buffer_path) does not start with .., >> use a relative path Angus> This is where I disagree. I, for example, tend to use a doc Angus> directory with different papers in doc/some_sub_dir. However, Angus> they all share a common doc/references.bst file, stored in the Angus> lyx file as ../references.bst Angus> That sounds entirely reasonable to me. No, what is reasonable (TeX-wise) is to add ~angus/doc/ to the BSTINPUTS environment variable. But then I am not writing your papers for you. What I am saying is that we should look for a scheme to provide resonable defaults. The user should always be able to modify the string by hand and override the clever guessing. JMarc
Re: Cleaning up the bibtex inset
Jean-Marc Lasgouttes wrote:
>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
> Angus> How the file is stored/output can be selected using the three
> Angus> check buttons. The idea is to enable this on a file-by-file
> Angus> basis. Ie, the database must be first selected in the browser
> Angus> for the buttons to become active.
>
> Angus> ("TeX magic" might be better labelled as "Name only").
>
> This seems very very complicated to me.
Oh, not really. But it is definitely too complicated for LyX to be
able to tell me what I want and gt it right everytime.
> The user does not care about such subtleties. What I propose
> that you do is
>
> 1/ after browsing (in which directories does it browse, anyway?),
> you have an absolute path /foo/bar.bib.
That is correct. (I'm not sure. Will look this evening.)
However, the user will also be able to enter a file by typing it into
the input widget. That can, of course, be a relative path.
> 2/ if Makerelpath(/foo/bar.bib,buffer_path) does not start with ..,
> use a relative path
This is where I disagree. I, for example, tend to use a doc directory
with different papers in doc/some_sub_dir. However, they all share a
common doc/references.bst file, stored in the lyx file as
../references.bst
That sounds entirely reasonable to me.
> 3/ if bar.bib can be found by findtexfile.bst, then just use that
> [this is the TeX magic case]. You may have to make sure that the
> current directory is not the document directory, so that you know it
Good. I agree with this entirely.
I think that I start to see a solution. Will mull things over further
when I have some time.
--
Angus
Re: Cleaning up the bibtex inset
Jean-Marc Lasgouttes wrote: >> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > Angus> That's the idea. I am currently wrestling with what to do > with Angus> $ export BSTINPUTS=foo/bar bstfile = > foo/bar/bah/file.bst > > Angus> If I store bah/file.bst will kpsewhich find it? > > Are you talking about a relative path in BSTINPUTS? orget about such > nastyness. You can assume that the search path is made of absolute > paths, I think. No, I mean that if I have BSTINPUTS=/foo/bar and enter a bst file in the bibtex dialog by typing manually "/foo/bar/bah/file.bst" and then hit the check button "Use TeX magic to find this bugger", should I do any checking to see if I can indeed find this file or should I just store "file.bst"? The thing won't subsequently be found, but that is now the user's problem. Right? -- Angus
Re: Cleaning up the bibtex inset
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> How the file is stored/output can be selected using the three
Angus> check buttons. The idea is to enable this on a file-by-file
Angus> basis. Ie, the database must be first selected in the browser
Angus> for the buttons to become active.
Angus> ("TeX magic" might be better labelled as "Name only").
This seems very very complicated to me. The user does not care about
such subtleties. What I propose that you do is
1/ after browsing (in which directories does it browse, anyway?), you
have an absolute path /foo/bar.bib.
2/ if Makerelpath(/foo/bar.bib,buffer_path) does not start with ..,
use a relative path
3/ if bar.bib can be found by findtexfile.bst, then just use that
[this is the TeX magic case]. You may have to make sure that the
current directory is not the document directory, so that you know it
4/ otherwise use an absolute path.
I guess this logic should be encapsulated somewhere in filetools.C.
JMarc
Re: UG + other slowness
Andre Poenitz wrote: > Not much I suppose. :) OK, Thanks
Re: Cleaning up the bibtex inset
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> That's the idea. I am currently wrestling with what to do with Angus> $ export BSTINPUTS=foo/bar bstfile = foo/bar/bah/file.bst Angus> If I store bah/file.bst will kpsewhich find it? Are you talking about a relative path in BSTINPUTS? orget about such nastyness. You can assume that the search path is made of absolute paths, I think. JMarc
Re: UG + other slowness
On Fri, Aug 01, 2003 at 05:21:43AM -0300, Garst R. Reese wrote: > Andre Poenitz wrote: > > > But try recent CVS first. Maybe Sunday noon Greenwich time... > > > Thanks Andre' > I just finished compiling -D "2003-07-27 18:00" > I suppose that is 22:00 GMT if the 18:00 is my local time. > Loading time is now OK, typing is very slow. Would backing up to noon > GMT help that? Not much I suppose. 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: Cleaning up the bibtex inset
Andre Poenitz wrote:
> On Thu, Jul 31, 2003 at 10:29:19PM +, Angus Leeming wrote:
>> How the file is stored/output can be selected using the three check
>> buttons. The idea is to enable this on a file-by-file basis. Ie,
>> the database must be first selected in the browser for the buttons
>> to become active.
>>
>> ("TeX magic" might be better labelled as "Name only").
>
>> What d'ya think? Feel free to say it's rubbish ;-) Better yet, tell
>> me how it could all be improved.
>
> Maybe 'Absolute path', 'Relative path'?
Sure. I was more concerned with the overall logic behind the scheme.
--
Angus
Re: UG + other slowness
Andre Poenitz wrote: > But try recent CVS first. Maybe Sunday noon Greenwich time... > Thanks Andre' I just finished compiling -D "2003-07-27 18:00" I suppose that is 22:00 GMT if the 18:00 is my local time. Loading time is now OK, typing is very slow. Would backing up to noon GMT help that? Garst
Re: Cleaning up the bibtex inset
On Thu, Jul 31, 2003 at 10:29:19PM +, Angus Leeming wrote:
> How the file is stored/output can be selected using the three check buttons.
> The idea is to enable this on a file-by-file basis. Ie, the database must
> be first selected in the browser for the buttons to become active.
>
> ("TeX magic" might be better labelled as "Name only").
> What d'ya think? Feel free to say it's rubbish ;-) Better yet, tell me how
> it could all be improved.
Maybe 'Absolute path', 'Relative path'?
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: Cleaning up the bibtex inset
Juergen Spitzmueller wrote: > Angus Leeming wrote: >> Rather than have those check buttons, I was thinking about using >> the input widget: highlight the database in the browser and it is >> placed in the input box. Modify it to suit and then press "Modify" >> or similar. > > I'm not shure I'd like those mixing of input and modifying widget. I played with it. Getting the interation right is indeed a bit of a pain. On the other hand, not being able to type the file is also a pain. More playing needed ;-) > I think radiobuttons (not checkboxes) or a choice are o.k. > In Qt, John has placed the input widget on the add dialog too, > because it rather belongs there (strictly separating input and > edit). > > In most cases, the user should not care about "storage". Do you use > some default (e.g., filename only for those files that are found by > kpsewhich, absolute/relative for those out of PATH)? That's the idea. I am currently wrestling with what to do with $ export BSTINPUTS=foo/bar bstfile = foo/bar/bah/file.bst If I store bah/file.bst will kpsewhich find it? However, I think I'm going to ignore such a case. The check buttons and tooltips will be o Absolute (the file is output with an absolute path) o Relative (the file is output with a path relative to the buffer) o Name only (use TeX magic to find the file) I have yet to modify FileName to handle all three transparently, but that is the eventual goal. > BTW I noticed that the bst-files are not sorted in the style > combo/browser. I thought I fixed that once. Are you planning to > improve that script a bit? They are sorted now. I also added an empty entry for those textclasses that have a default style. -- Angus
Re: A plan for spam^Wmetrics
On Thu, Jul 31, 2003 at 07:06:54PM +0100, John Levon wrote: > On Thu, Jul 31, 2003 at 10:15:49AM +0200, Andre Poenitz wrote: > > > > o change all code (appendPar etc.) that calls rowBreakPoint to call > > > metrics() on the outmost lyxtext instead > > > > I am not too sure here. I think appendPar etc should just get the > > structure right and not care too much for metrics related problems. > > OK fine, but *something* is going to have to call metrics() on an event > like "insertChar" or paragraph breaking. The last line of some dispatch() method. LyXView::dispatch() or LyXFunc::dispatch() probably. 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...)
fonts & obsoletes
Is there any special reason why we still use old obsoleted font packages? - times has been superceeded by mathptmx (former mathptm) - palatino has been superceeded by mathpazo (former mathpple) (see psnfss documentation) Also, we should remove support for pslatex and ae, since they are really bad quality and we should not encourage users to use them. In the meantime, there are enough good type-1 fonts available (cm-super and lmodern for those who want cm postscript fonts). Also, we could add support for those fonts from psnfss: - chancery - charter and the new latin modern (lmodern) font family. Juergen. BTW: reading through the german document "mortal sins of LaTeX typesettings" (http://www.ctan.org/tex-archive/info/german/l2tabu/) I tend to removing support for a4.sty and a4wide.sty
Re: UG + other slowness
On Thu, Jul 31, 2003 at 01:32:01PM -0300, Garst R. Reese wrote: > Lars Gullik Bjønnes wrote: > > > It seems that you are the only one seeing this. > > > > Really strange. > > > > With debugging turned on, are you able to see in what phase it is > > slow? > I can't complile on this machine with -g, if that's what you mean. You could try'CXXFLAGS=-pg configure --disable-debug... ' to include profile, but no debug information. This links much faster than the debug-enabled version and should shoul the bottleneck nevertheless. But try recent CVS first. Maybe Sunday noon Greenwich time... 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...)
