Re: Command buffer
On Mon, Apr 12, 2004 at 06:02:05PM +0100, John Levon wrote: On Sat, Apr 10, 2004 at 11:34:43PM +0200, Andre Poenitz wrote: Well, if this would be done, I could live with it. Until then I'd prefer a visible mini-buffer. Makes debugging a bit easier. We could probably enable it by default for development versions or something I certainly wouldn't mind... Andre'
Re: update
Andre Poenitz wrote: It still looks as if update() has a tendency to get expensive if certain nice-to-have or necessary features are triggered from there. A good part of the complications come from top_y() which needs to be more or less up-to-date as it is used in: 1 LyXText::checkInsetHit(int x, int y) for finding the visible paragraphs (as an indication where to search for visible insets that might have been hit) 2 LyXText::cursorPrevious()/cursorNext(), the MOUSE_MOTION handler for setCursorFromCoordinates(cur, x, y); 3 rowpainter: paintPars() for putting a paragraph/row at a certain y-coordinate 4 rowpainter: paintText() for finding the visible paragraphs 5 BufferView_pimpl::update() for finding the visible paragraphs (to re-break them) 6 BufferView_pimpl::scrollDocView() for calling text-setCursorFromCoordinates(bv_-cursor(), 0, y); 7 BufferView::Pimpl::scroll(int lines) for calling crollDocView and workarea().setScrollbarParams() 8 LyXScreen::showCursor() for showing the cursor at a certain position 9 LyXScreen::fitCursor() for putting the cursor at a certain position 10 InsetCollapsablei/Tabular::draw() for some fancy coordinate correction Now, is this needed? I don't think so, but I might be wrong. Let's consider the cursor itself as well as a y-offset 'new_top_y' from top of the visible screen as primary information. Now: 1 LyXText::checkInsetHit(int x, int y) for finding the visible paragraphs (as an indication where to search for visible insets that might have been hit) 2 LyXText::cursorPrevious()/cursorNext(), the MOUSE_MOTION handler for setCursorFromCoordinates(cur, x, y); could be solved by checking a few paragraphs in the vicinity of the cursor. Of course, these better should have been rebroken lately, but even if not we could do so in O(1) by re-breaking the current par, and possibly the par above if this is visible and possibly the par above ... etc. There's a limited number of them as each row has a positive height. 3 rowpainter: paintPars() for putting a paragraph/row at a certain y-coordinate Well, we are given new_top_y, so we know where to draw things. 4 rowpainter: paintText() for finding the visible paragraphs 5 BufferView_pimpl::update() for finding the visible paragraphs (to re-break them) Same as 1 and 2. 6 BufferView_pimpl::scrollDocView() for calling text-setCursorFromCoordinates(bv_-cursor(), 0, y); 7 BufferView::Pimpl::scroll(int lines) for calling crollDocView and workarea().setScrollbarParams() That's interesting as this is the place where we actually would need absolute heights in the whole document. However, as this only affects the scrollbar, some approximation should be in order. Using the count of visible toplevel paragraphs in relation to the total number of toplevel paragraphs as well as well as the offset of the cursor's toplevel par in relation to the total is such approximation and I claim this is good enough. Agreed. 8 LyXScreen::showCursor() for showing the cursor at a certain position We are given new_top_y. 9 LyXScreen::fitCursor() for putting the cursor at a certain position As simple as setting new_top_y to a new value. 10 InsetCollapsable/Tabular::draw() for some fancy coordinate correction No need for correction in screen-absolute coordinates. Note that the dreaded 'put cursor into never explored land' problem would be magically solved. We put the cursor physically there (by assigning from a DocIterator or similar) and set new_top_y to, well, 100 or so. Now it's update time: rebreak all visible outerlevel pars starting with the cursor par and going up and down as needed. And we are done. So now the interesting question: What do I miss? Nothing comes to my mind rigth now, but as you know problems come when you have started implementing... ;-) PS: There'll still be O(n) parts for updateCounters() and similar. However, those have been there before and were tolerable in 1.3.x. I agree that it's doable. I do think that it's more complex than what we have now. Before getting into details, what exactly are we avoiding, updateParPositions? Are you sure that this is the bottleneck? Alfredo
Re: My next target?
Angus Leeming wrote:
Question 2
==
Is this safe? What happens if command.size() 50?
+ bformat(_(An error occurred whilst running %1$s),
+ command.substr(0, 50)));
I have replaced it with MakeDisplayPath, which works well.
Question 4
==
Why is LyXRC::RC_EDITOR needed? Isn't this just part of the format
definition? Ie, why not extend RC_FORMAT? (And ditch RC_VIEWER also.)
I did that. I also removed EditCommand from the external templates, it
turned out to be rather easy. Updated patch attached.
Georg
Index: lib/ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/lib/ChangeLog,v
retrieving revision 1.579
diff -u -p -r1.579 ChangeLog
--- lib/ChangeLog 2004/04/06 21:07:26 1.579
+++ lib/ChangeLog 2004/04/12 19:38:50
@@ -1,3 +1,9 @@
+2004-04-12 Georg Baum [EMAIL PROTECTED]
+
+ * configure.m4: merge \viewer and \format. Add editor to \format
+ * configure.m4: check for more viewers and editors
+ * external_templates: remove EditCommand
+
2004-04-06 Georg Baum [EMAIL PROTECTED]
* external_templates: use some new variables instead of $$Basename
Index: lib/configure.m4
===
RCS file: /cvs/lyx/lyx-devel/lib/configure.m4,v
retrieving revision 1.75
diff -u -p -r1.75 configure.m4
--- lib/configure.m4 2004/03/22 16:22:52 1.75
+++ lib/configure.m4 2004/04/12 19:38:54
@@ -237,6 +237,20 @@ fi
test $latex_to_dvi != none latex_to_dvi=$latex_to_dvi \$\$i
test $latex_to_pdf != none latex_to_pdf=$latex_to_pdf \$\$i
+SEARCH_PROG([for a TGIF viewer and editor], TGIF_EDITOR, tgif)
+TGIF_VIEWER=$TGIF_EDITOR
+
+SEARCH_PROG([for a FIG viewer and editor], FIG_EDITOR, xfig)
+FIG_VIEWER=$FIG_EDITOR
+
+SEARCH_PROG([for a FEN viewer and editor], FEN_EDITOR, xboard)
+test $FEN = xboard FEN_EDITOR=xboard -lpf \$\$i -mode EditPosition
+FEN_VIEWER=$FEN_EDITOR
+
+SEARCH_PROG([for a raster image viewer], RASTERIMAGE_VIEWER, xv kview gimp)
+
+SEARCH_PROG([for a raster image editor], RASTERIMAGE_EDITOR, gimp)
+
# Search for an installed reLyX or a ready-to-install one
save_PATH=${PATH}
PATH=${PATH}:./reLyX/
@@ -492,113 +560,102 @@
# want to customize LyX, make a copy of the file LYXDIR/lyxrc as
# ~/.lyx/lyxrc and edit this file instead. Any setting in lyxrc will
# override the values given here.
-\\Format asciichess asc ASCII (chess output)
-\\Format asciiimage asc ASCII (image)
-\\Format asciixfig asc ASCII (xfig output)
-\\Format agr agr GRACE
-\\Format bmp bmp BMP
-\\Format date date command
-\\Format dateout tmp date (output)
-\\Format docbook sgml DocBook B
-\\Format dvi dvi DVI D
-\\Format eps eps EPS
-\\Format fax Fax
-\\Format fen fen FEN
-\\Format fig fig XFig
-\\Format gif gif GIF
-\\Format html html HTML H
-\\Format jpg jpg JPG
-\\Format latex tex LaTeX L
-\\Format linuxdoc sgml LinuxDoc x
-\\Format lyx lyx LyX
-\\Format lyxpreview lyxpreview LyX Preview
-\\Format literate nw NoWeb N
-\\Format pbm pbm PBM
-\\Format pdf pdf PDF (ps2pdf) P
-\\Format pdf2 pdf PDF (pdflatex) F
-\\Format pdf3 pdf PDF (dvipdfm) m
-\\Format pdftex pdftex_t PDFTEX
-\\Format pgm pgm PGM
-\\Format png png PNG
-\\Format ppm ppm PPM
-\\Format program Program
-\\Format ps ps Postscript t
-\\Format pstexpstex_t PSTEX
-\\Format text txt ASCII A
-\\Format textparagraph txt ASCII(paragraphs)
-\\Format tgif obj TGIF
-\\Format tiff tif TIFF
-\\Format word doc Word W
-\\Format xbm xbm XBM
-\\Format xpm xpm XPM
-
-\\converter date dateout date +%d-%m-%Y \$\$o
-\\converter docbook dvi $docbook_to_dvi_command
-\\converter docbook html $docbook_to_html_command
-\\converter dvi pdf3 $dvi_to_pdf_command
-\\converter dvi ps $dvi_to_ps_command
-\\converter fen asciichess python \$\$s/fen2ascii.py \$\$i \$\$o
-\\converter fig pdftex sh \$\$s/fig2pdftex.sh \$\$i \$\$o
-\\converter fig pstex sh \$\$s/fig2pstex.sh \$\$i \$\$o
-\\converter html latex $html_to_latex_command
-\\converter latex html $latex_to_html_command originaldir,needaux
-\\converter latex dvi $latex_to_dvi latex
-\\converter latex lyx $tex_to_lyx_command
-\\converter latex pdf2 $latex_to_pdf latex
-\\converter linuxdoc dvi $linuxdoc_to_dvi_command
-\\converter linuxdoc html $linuxdoc_to_html_command
-\\converter linuxdoc latex $linuxdoc_to_latex_command
-\\converter linuxdoc lyx $linuxdoc_to_lyx_command
-\\converter literate latex $literate_to_tex_command
-\\converter literate lyx $literate_to_lyx_command
-\\converter lyxpreview ppm $lyxpreview_to_bitmap_command
-\\converter ps fax $fax_command
-\\converter ps pdf $ps_to_pdf_command
-\\converter word latex $word_to_latex_command
-
-\\viewer dvi $DVI_VIEWER
-\\viewer html $HTML_VIEWER
-\\viewer pdf $PDF_VIEWER
-\\viewer pdf2 $PDF_VIEWER
-\\viewer pdf3 $PDF_VIEWER
-\\viewer ps $PS_VIEWER
Re: Bug: Formulas in Description?
Peter Hutnick wrote:
First, I'd like to thank each of you for dedicating his or her time
to writing and/or supporting Free Software.
Now, I /think/ I've hit a bug. Initially it was with an old
version, but I have upgraded to the lyx-1.3.4-1rh9_qt.i386.rpm.
I have a .lyx file with a block of descriptions. I have simplified
the problem to a very short .lyx file that I attached.
The problem might be related to a description that contains two
formulas
joined by ctrl-spaces. It is pretty hard to explain, but you can
reproduce it by:
1. Open the attached file in LyX.
2. Hit view DVI (or view anything, really).
3. Watch error boxes pop up.
Even simpler:
\begin{description}
\item [$]$]blah
\end{description}
LaTeX gets confused. The appropriate entry from the log file:
l.20 \item [$]
$]blah\end{description}
I've deleted a group-closing symbol because it seems to be
spurious, as in `$x}$'. But perhaps the } is legitimate and
you forgot something else, as in `\hbox{$x}'. In such cases
the way to recover is to insert both the forgotten and the
deleted material, e.g., by typing `I$}'.
! LaTeX Error: Something's wrong--perhaps a missing \item.
See the LaTeX manual or LaTeX Companion for explanation.
Type H return for immediate help.
...
Personally, I think you've been unfortunate, but LyX's mathed editor
has never prevented you from generating incorrect latex, nor could it
without being a fully fledged latex compiler.
Just my 2 pennies of opinion of course.
Angus
Math macros ---- Woooooo!
Andre, thank you, thank you, thank you!
However, the new scheme appears to produce an extra, unnecessary set
of red braces. Try the attached, 13x file with lyx 13x and with
current cvs.
The good news is that the latex exported by both versions is
identical:
\newcommand{\Vector}[1]{\boldsymbol{#1}}
$\Vector{V}_{0}=V_{x0}\Vector{i}$
--
Angus
trial.lyx
Description: application/lyx
Re: macros
Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre Now, what should we do? I could declare math macros (with Andre arguments, macros without arguments are no problem) a 'Power Andre User Feature' and require basic TeX knowledge from people that Andre wish to use it. Or we could live with the mess as we did up to Andre now. I am not sure that macros with argument should be a power-user only thing. In particular, we might want one days to declare in .layout files some macros that are defined by the documentclass. We should make sure that these are as easy as possible to handle. JMarc
mathed cursor y-position is off
Enter a math inset and the cursor is positioned visibly half a screen above the correct location. Navigation works fine, but the cursor remains half a screen above the inset. -- Angus
Re: update
Andre Poenitz wrote: It still looks as if update() has a tendency to get expensive if certain nice-to-have or necessary features are triggered from there. Also note that we don't need to fire an update on every cursor movement, which is the biggest problem. I've just seen your #warning, but I've no clue of what's the problem. Ah, maybe entering/exiting insets should fire an update nevertheless? So should we add some checks directly in the lfun handlers? Alfredo
Re: [patch] cursor position inside math insets
Alfredo Braunstein wrote: Not sure if this is the correct solution though. The top_y habdling should be probably completely centralized in some setCachePos like in insets/, but I've lost track inside the math/ hierarchy. Andre', could you have a look? It just adds top_y in a couple of places. Thanks, Alfredo
Re: New lyx2lyx.
On Monday 12 April 2004 19:49, Georg Baum wrote: Am Montag, 12. April 2004 12:07 schrieb Jose' Matos: I will fix those. Fine! In the meantime, I found more. Just in case you did not notice already: - conversion to e.g. format 225 does not work: There is no check if the desired format is reached in convert() and revert() in lyx_1_4.py I said that in the first message, I will do it now as it is quite easy. :-) - the chain order is wrong for revert (1_3 1_4 instead of 1_4 1_3) Ok. - Why do you attempt to read the version from the comment line? This does not work with tex2lyx: For And also it does not work with reLyX. The fact is that the header carries some information regarding the file format. Notice that LyX versions 0.12, 1.0.0, 1.0.1, 1.0.4 although saying that the fileformat is 2.15 it is a different 2.15 for each. This is not nice, but we can't change it;-( True, that is why I have those file with an empty content there. Some of the conversion functions belong to later files. I need to take some time to see which. It is for this case that I want to read the version. But as you can see in the code the file format is always the definitive guide for the convertion. If the lyx versions doesn't match the file format then forget it. Now I understand. I think it would be better to suppress the warning then. In my case, the real error was something else, but I thought it guessed the file format wrong. I think that here it makes sense the warning level. This should be reported only in the most verbose debug mode, as it is otherwise useless. I will have a go today. Does this makes sense now? What would you like to change in the implementation? Only this: Suppress the warning if it is irrelevant, i.e. the fileformat is not 2.15. This will be necessary also for 2.10, but you right I will supress the warning if the fileformat is = 215, that should take care of it. Georg Thanks for your feedback. -- José Abílio LyX and docbook, a perfect match. :-)
Re: My next target?
Georg Baum wrote: Angus Leeming wrote: Question 2 == Is this safe? What happens if command.size() 50? + bformat(_(An error occurred whilst running %1$s), + command.substr(0, 50))); I have replaced it with MakeDisplayPath, which works well. Question 4 == Why is LyXRC::RC_EDITOR needed? Isn't this just part of the format definition? Ie, why not extend RC_FORMAT? (And ditch RC_VIEWER also.) I did that. I also removed EditCommand from the external templates, it turned out to be rather easy. Updated patch attached. W, you've been careful in lyxrc::read! I've committed your changes, having moved the edit button to somewhere more meaningful (I hope). Pressing it no longer activates Ok/Apply either. The Qt layout is probably broken. It always is after I muck around :-( -- Angus
Re: macros
On Mon, Apr 12, 2004 at 08:01:37PM +0100, Angus Leeming wrote: Andre Poenitz wrote: Now, what should we do? I could declare math macros (with arguments, macros without arguments are no problem) a 'Power User Feature' and require basic TeX knowledge from people that wish to use it. Or we could live with the mess as we did up to now. Do it the latex way. We can put time and effort into designing a GUI that makes the thing fool-proof to use. That way the core remains clean and flexible and we make use of a proven design. Done. Andre'
Re: Math macros ---- Woooooo!
On Tue, Apr 13, 2004 at 11:06:28AM +0100, Angus Leeming wrote:
Andre, thank you, thank you, thank you!
However, the new scheme appears to produce an extra, unnecessary set
of red braces. Try the attached, 13x file with lyx 13x and with
current cvs.
The good news is that the latex exported by both versions is
identical:
\newcommand{\Vector}[1]{\boldsymbol{#1}}
$\Vector{V}_{0}=V_{x0}\Vector{i}$
A more serious problem with the screen display is if the \Vector macro is
changed to
\newcommand{\Vector}[1]{[#1]}
Re: [patch] cursor position inside math insets
On Tue, Apr 13, 2004 at 11:24:08AM +0200, Alfredo Braunstein wrote: Alfredo Braunstein wrote: Not sure if this is the correct solution though. The top_y habdling should be probably completely centralized in some setCachePos like in insets/, but I've lost track inside the math/ hierarchy. Btw: there's a README file in mathed containing a (really small) overview on the math hierarchy. Andre'
Re: mathed cursor y-position is off
On Tue, Apr 13, 2004 at 11:15:51AM +0100, Angus Leeming wrote: Enter a math inset and the cursor is positioned visibly half a screen above the correct location. Navigation works fine, but the cursor remains half a screen above the inset. Probably some getCursorPos()/top_y() issue. Adding top_y() to y in MathNestInset::getCursorPos() might help. For this it is probably necessary to change the parameter from CursorSlice to Cursor to have a means to access the BufferView. Andre' PS: Would go magically away if we had screen-absolute coordinates ;-)
Re: My next target?
On Tue, Apr 13, 2004 at 09:35:48AM +0200, Georg Baum wrote: Angus Leeming wrote: Question 2 == Is this safe? What happens if command.size() 50? + bformat(_(An error occurred whilst running %1$s), + command.substr(0, 50))); I have replaced it with MakeDisplayPath, which works well. Since you mention MakeDisplayPath: Whenever anybody touches this kind of code, please make sure to change the naming to 'LyX style', i.e. camelBumpWithLowerCaseInitial() for functions. No need to do it now in a rush, but please keep it in mind. Thanks, Andre'
Re: macros
On Tue, Apr 13, 2004 at 11:08:30AM +0200, Jean-Marc Lasgouttes wrote: Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre Now, what should we do? I could declare math macros (with Andre arguments, macros without arguments are no problem) a 'Power Andre User Feature' and require basic TeX knowledge from people that Andre wish to use it. Or we could live with the mess as we did up to Andre now. I am not sure that macros with argument should be a power-user only thing. In particular, we might want one days to declare in .layout files some macros that are defined by the documentclass. We should make sure that these are as easy as possible to handle. But first of all they should work, shouldn't they? Up to now opening two documents with user defined macros had a decent potential to screw either document. I think Angus was right with his remark to get the structure right first and build a decent GUI later. I think we've got a suitable structure now. Pretty close to what TeX does with all the flexibility (needed or not...). And no document destroys another one anymore just because they happen to contain macros of the same name but different definitions... Andre'
Re: update
On Tue, Apr 13, 2004 at 08:54:38AM +0200, Alfredo Braunstein wrote: So now the interesting question: What do I miss? Nothing comes to my mind rigth now, but as you know problems come when you have started implementing... ;-) I think the crucial translation is top_y - new_top_y (buffer absolute to screen absolute) which should be PS: There'll still be O(n) parts for updateCounters() and similar. However, those have been there before and were tolerable in 1.3.x. I agree that it's doable. I do think that it's more complex than what we have now. Before getting into details, what exactly are we avoiding, updateParPositions? Are you sure that this is the bottleneck? We are avoiding several things. First is updateParPositions(), second (and more important) is the need to have a (semi-)correct row cache at all. So we would basically never have to call redoParagraph() manually. And we would not need redoParagraph() in e.g. LyXText::init... Andre'
Re: update
On Tue, Apr 13, 2004 at 11:20:06AM +0200, Alfredo Braunstein wrote: It still looks as if update() has a tendency to get expensive if certain nice-to-have or necessary features are triggered from there. Also note that we don't need to fire an update on every cursor movement, which is the biggest problem. I've just seen your #warning, but I've no clue of what's the problem. Ah, maybe entering/exiting insets should fire an update nevertheless? Entering/leaving insets toggles e.g. the pink corners in math. But we'd need a more stable mechanism for these anyway as we'd like to trigger preview too. So should we add some checks directly in the lfun handlers? That's the way to go I am afraid. Only call noUpdate() whenever you are really sure that no update is needed. I think it'd be sufficient for the simple cursor left/right movements for starters as these are a big part of the user's 'performance experience' Andre'
Re: Math macros ---- Woooooo!
On Tue, Apr 13, 2004 at 11:06:28AM +0100, Angus Leeming wrote: Andre, thank you, thank you, thank you! However, the new scheme appears to produce an extra, unnecessary set of red braces. Try the attached, 13x file with lyx 13x and with current cvs. Hm... parser problem... Too much cleverness to avoid 'extra' braces. I don't think I will have time to investigate this before Friday. Andre'
Re: Command buffer
Andre Poenitz [EMAIL PROTECTED] writes: | On Mon, Apr 12, 2004 at 06:02:05PM +0100, John Levon wrote: On Sat, Apr 10, 2004 at 11:34:43PM +0200, Andre Poenitz wrote: Well, if this would be done, I could live with it. Until then I'd prefer a visible mini-buffer. Makes debugging a bit easier. We could probably enable it by default for development versions or something | I certainly wouldn't mind... Is the argument for not having it visible always, valid? -- Lgb
Re: Math macros ---- Woooooo!
On Tue, Apr 13, 2004 at 11:06:28AM +0100, Angus Leeming wrote:
Andre, thank you, thank you, thank you!
However, the new scheme appears to produce an extra, unnecessary set
of red braces. Try the attached, 13x file with lyx 13x and with
current cvs.
The good news is that the latex exported by both versions is
identical:
\newcommand{\Vector}[1]{\boldsymbol{#1}}
$\Vector{V}_{0}=V_{x0}\Vector{i}$
Urgs.
The problem here is that '_' attaches to the last thing in front of it.
In the everything-is-an-inset, this is the whole ('expanded') macro,
i.e.[Vector V]_0
Now macros are only expanded for drawing, so the _0 attaches to the last
item on the left which is the 'V', i.e. to the macro argument. When the
thing is drawn, the macro reads one argument, which is now V_0.
Sh**, sh**, sh**.
TeX doesn't have this problem as it attaches the subscript only after
the Vector V has already been processed and put into a box.
Well, looks as if the two worlds don't fit together too well. To go the
TeX route we'd need to defer the attaching of the subscript to drawing
time, too, i.e. no nice MathScriptInset. Sh... But we can't do this.
And that's not just when reading a buffer (we could probably work around
there somehow), but all the time we translate between MathArrays and
string, i.e. always.
Looks like a real dilemma.
Andre'
Re: mathed cursor y-position is off
On Tue, Apr 13, 2004 at 11:15:51AM +0100, Angus Leeming wrote: Enter a math inset and the cursor is positioned visibly half a screen above the correct location. Navigation works fine, but the cursor remains half a screen above the inset. Should bne fixed now. Andre'
Re: macros
Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre But first of all they should work, shouldn't they? Up to now Andre opening two documents with user defined macros had a decent Andre potential to screw either document. I think Angus was right Andre with his remark to get the structure right first and build a Andre decent GUI later. I think we've got a suitable structure now. Andre Pretty close to what TeX does with all the flexibility (needed Andre or not...). And no document destroys another one anymore just Andre because they happen to contain macros of the same name but Andre different definitions... I agree of course. I just did not agree with your comment on ``since macros with arguments are a power-user thing, they might as well be ugly to use''. JMarc
Re: Command buffer
Lars Gullik Bjønnes wrote: Well, if this would be done, I could live with it. Until then I'd prefer a visible mini-buffer. Makes debugging a bit easier. We could probably enable it by default for development versions or something | I certainly wouldn't mind... Is the argument for not having it visible always, valid? I think so. Here's why. The command buffer performs two roles: 1. It provides us with state information. (All those useful 'Running latex' etc messages.) 2. It gives us a means to enter lfuns from 'by hand'. The xforms frontend follows emacs by incorporating both functionalities in a single bar. The Qt frontend, on the other hand, has separate widgets (and bars) for each. The 'information widget' is always visible in all frontends. It certainly would not be valid to hide it. The 'command input widget' is hidden by default in the Qt frontend. The argument is that only 'experts' use it. It's this that I'd like to trigger visible with M-x. This is a non-issue with the xforms frontend, as the widget is visible always. -- Angus
Re: Command buffer
On Tue, Apr 13, 2004 at 03:14:11PM +0200, Lars Gullik Bjønnes wrote: Is the argument for not having it visible always, valid? I don't think so. Personnaly I'd like to have the minibuffer always visible. But I don't care too much about UI issues as long as it does not interfere with the way I am used to using LyX... Andre'
RE: Command buffer
Is the argument for not having it visible always, valid? I think so. Here's why. The command buffer performs two roles: maybe time to implement a status bar to separate the two? ed.
RE: Command buffer
Leuven, E. wrote: Is the argument for not having it visible always, valid? I think so. Here's why. The command buffer performs two roles: maybe time to implement a status bar to separate the two? Let's fix existing bugs rather than create new ones. It'd be nice to get 14x out of the door in 2004. -- Angus
Re: Command buffer
On Tue, Apr 13, 2004 at 03:32:32PM +0100, Angus Leeming wrote: I think so. Here's why. The command buffer performs two roles: 1. It provides us with state information. (All those useful 'Running latex' etc messages.) 2. It gives us a means to enter lfuns from 'by hand'. The xforms frontend follows emacs by incorporating both functionalities in a single bar. The Qt frontend, on the other hand, has separate widgets (and bars) for each. In case anyone's interested, the rationale is simple - nobody* knew that you could type into the minibuffer. This was partly due to visual decoration in the xforms frontend, and partly due to its status bar behaviour. And once we've separated the two, there's little argument for taking up vertical space by default for something that is difficult to use, essentially undocumented, and only used by a few people. regards, john
Re-enabling previews for mathed
Ok, Andre,
this patch re-enables previewing of math insets. Well, it doesn't
actually alter the MathHullInset::metrics, draw routines, but they're
trivial. It does everything else though, leading to some...
design questions.
1. Triggering the request to generate a preview.
Two possible scenarios:
a) Just loaded a new buffer, so loop over all insets calling
'addPreview' for each. Throw this latex file out to the tmp directory
and generate previews of each and every inset. No problems there.
b) Edited an inset, so trigger preview generation when leaving the
inset. I've gone the LFUN way:
void LyXText::dispatch(LCursor cur, FuncRequest cmd) {
...
case LFUN_MOUSE_PRESS: {
...
// Has the cursor just left the inset?
if (bv-cursor().inMathed() !cur.inMathed())
bv-cursor().inset().notifyCursorLeaves(bv-cursor());
...
}
...
}
void MathHullInset::priv_dispatch(LCursor cur, FuncRequest cmd)
{
switch (cmd.action) {
case LFUN_FINISHED_LEFT:
case LFUN_FINISHED_RIGHT:
case LFUN_FINISHED_UP:
case LFUN_FINISHED_DOWN:
MathGridInset::priv_dispatch(cur, cmd);
notifyCursorLeaves(cur);
break;
...
}
I tried the update way, but it seems to me that LyXText::dispatch is
the only place that knows that the cursor was in an inset but is in
one no more.
2. Embedding the RenderPreview object in the MathHullInset.
a) Should I store a pointer to a RenderPreview or a RenderPreview
itself? I've chosen to store a pointer to minimize header file
dependencies, but this is 'your code' so it's also 'your call'.
b) The RenderPreview object tells the MathHullInset that the preview
is ready for display by calling MathHullInset::statusChanged.
Unfortunately, boost::bind is noncopyable, so we have to set the
connection from signal to slot explicitly. Hence the hand-coded
MathHullInset copy constructor and operator=.
I'm not happy about them at all.
Since MathHullInset::statusChanged does nothing but invoke
'LyX::cref().updateInset(this)', it would be possible to invoke this
from the RenderPreview object itself. That would require it to store
an InsetBase pointer though...
Feedback welcomed...
--
AngusIndex: src/text3.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text3.C,v
retrieving revision 1.248
diff -u -p -r1.248 text3.C
--- src/text3.C 13 Apr 2004 06:27:28 - 1.248
+++ src/text3.C 13 Apr 2004 13:11:23 -
@@ -1148,6 +1148,13 @@ void LyXText::dispatch(LCursor cur, Fu
finishUndo();
cur.x_target() = cursorX(cur.top());
+ // Has the cursor just left the inset?
+ if (bv-cursor().inMathed() !cur.inMathed()) {
+ lyxerr \n\n\n\t\tHELLOO!
+ endl;
+ bv-cursor().inset().notifyCursorLeaves(bv-cursor());
+ }
+
// Set cursor here.
bv-cursor() = cur;
Index: src/mathed/math_hullinset.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_hullinset.C,v
retrieving revision 1.132
diff -u -p -r1.132 math_hullinset.C
--- src/mathed/math_hullinset.C 13 Apr 2004 06:27:28 - 1.132
+++ src/mathed/math_hullinset.C 13 Apr 2004 13:11:26 -
@@ -26,15 +26,22 @@
#include gettext.h
#include LaTeXFeatures.h
#include LColor.h
+#include lyx_main.h
#include lyxrc.h
#include outputparams.h
#include textpainter.h
#include undo.h
+#include insets/render_preview.h
+
#include frontends/Alert.h
+#include graphics/PreviewLoader.h
+
#include support/std_sstream.h
+#include boost/bind.hpp
+
using std::endl;
using std::max;
@@ -114,8 +121,10 @@ namespace {
MathHullInset::MathHullInset()
- : MathGridInset(1, 1), type_(none), nonum_(1), label_(1)
+ : MathGridInset(1, 1), type_(none), nonum_(1), label_(1),
+ preview_(new RenderPreview)
{
+ preview_-connect(boost::bind(MathHullInset::statusChanged, this));
//lyxerr sizeof MathInset: sizeof(MathInset) endl;
//lyxerr sizeof MetricsInfo: sizeof(MetricsInfo) endl;
//lyxerr sizeof MathCharInset: sizeof(MathCharInset) endl;
@@ -125,18 +134,53 @@ MathHullInset::MathHullInset()
MathHullInset::MathHullInset(string const type)
- : MathGridInset(getCols(type), 1), type_(type), nonum_(1), label_(1)
+ : MathGridInset(getCols(type), 1), type_(type), nonum_(1), label_(1),
+ preview_(new RenderPreview)
{
+ preview_-connect(boost::bind(MathHullInset::statusChanged, this));
setDefaults();
}
+MathHullInset::MathHullInset(MathHullInset const other)
+ : MathGridInset(other),
+ type_(other.type_), nonum_(other.nonum_), label_(other.label_),
+ preview_(new RenderPreview)
+{
+ preview_-connect(boost::bind(MathHullInset::statusChanged, this));
+}
+
+
+MathHullInset::~MathHullInset()
+{}
+
+
auto_ptrInsetBase MathHullInset::clone() const
{
return
Re: update
Andre Poenitz wrote: I think the crucial translation is top_y - new_top_y (buffer absolute to screen absolute) which should be PS: There'll still be O(n) parts for updateCounters() and similar. However, those have been there before and were tolerable in 1.3.x. I agree that it's doable. I do think that it's more complex than what we have now. Before getting into details, what exactly are we avoiding, updateParPositions? Are you sure that this is the bottleneck? We are avoiding several things. First is updateParPositions(), second I may be wrong, but I don't think this is the bottleneck. (and more important) is the need to have a (semi-)correct row cache at all. So we would basically never have to call redoParagraph() manually. ... which is not really expensive IMO And we would not need redoParagraph() in e.g. LyXText::init... ...but this has nothing to do with editing slowdown... So: I may agree that its a reasonable change (I even remember proposing something along the lines last year), but I don't think we are solving any performance problem... Alfredo
Re: update
Braunstein Alfredo wrote: So: I may agree that its a reasonable change (I even remember proposing something along the lines last year), but I don't think we are solving any performance problem... OTOH, doing this will nicely reimplement the anchor_row behaviour... (do not move the screen even if size of previous pars changed) Alfredo
Re: My next target?
Angus Leeming wrote: W, you've been careful in lyxrc::read! IMO existing user preferences files should be read even if they are in the old format, and the extra effort is small. I've committed your changes, having moved the edit button to somewhere more meaningful (I hope). Pressing it no longer activates Ok/Apply either. Good! The Qt layout is probably broken. It always is after I muck around :-( I'll have a look tonight. Georg
Re: My next target?
Georg Baum wrote: The Qt layout is probably broken. It always is after I muck around :-( I'll have a look tonight. Resizing the Qt frontend dialog has no effect on the tabs :-( I'm sure it is something trivial, but I'm blowed if I know what. Incidentally, it'd be good if the External dialog 'Edit' button was placed similarly to that of the Graphics dialog. At least on the Qt frontend they differ and IMO the Graphics dialog is the pattern to follow. -- Angus
Re: New lyx2lyx.
Here comes the second version. I have added an error/warning scheme as proposed by Angus. *) opt.warning(message, debug_level = 10) this means that we can choose the level of the warning with the default being 10 (show all). *) opt.error(message) prints this message and exits with error code 1 I have fixed those bugs detected by Georg. If I don't get any objections I will apply this today. -- José Abílio LyX and docbook, a perfect match. :-) lyx2lyx.tgz Description: application/tgz
Re: My next target?
On Tue, Apr 13, 2004 at 05:02:59PM +0100, Angus Leeming wrote: Resizing the Qt frontend dialog has no effect on the tabs :-( I'm sure it is something trivial, but I'm blowed if I know what. You broke the layout (added something ?). You need to group stuff again (select the objects then use the right mouse button menu) And of course you still need to use Qt 2 john
macros
Well... as I said I have (in theory...) no time until Friday to even
spend a thought on this problem. So I'll just revert most of this stuff
and have a look at it later.
I'll try to create a diff and attach this to this mail, would be nice if
someone could attach it to one of the macor related bugs on bugzilla
lest it gets lost.
The version I commit now should have old behaviour (i.e. all bug and
niceties present), but already decouples macro definition and usage, so
this is about half of the needed work in either direection.
Andre'
? .lyxfunc.C.swo
? .lyxlength.h.swp
? 1
? 1.diff
? insets/C
? mathed/1.diff
Index: buffer.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/buffer.C,v
retrieving revision 1.572
diff -u -p -r1.572 buffer.C
--- buffer.C13 Apr 2004 06:27:25 - 1.572
+++ buffer.C13 Apr 2004 13:46:44 -
@@ -641,6 +641,9 @@ bool Buffer::readFile(LyXLex lex, stri
}
bool the_end = readBody(lex);
+ //lyxerr removing MacroTable::localMacros().size()
+ //temporary macro entries endl;
+ //MacroTable::localMacros().clear();
params().setPaperStuff();
#ifdef WITH_WARNINGS
@@ -1499,6 +1502,7 @@ bool Buffer::hasMacro(string const nam
void Buffer::insertMacro(string const name, MacroData const data)
{
+ MacroTable::globalMacros().insert(name, data);
pimpl_-macros.insert(name, data);
}
Index: cursor.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/cursor.C,v
retrieving revision 1.96
diff -u -p -r1.96 cursor.C
--- cursor.C13 Apr 2004 12:47:48 - 1.96
+++ cursor.C13 Apr 2004 13:46:54 -
@@ -870,12 +870,7 @@ void LCursor::macroModeClose()
if (macro macro-getInsetName() == name)
lyxerr can't enter recursive macro endl;
- plainInsert(createMathInset(name));
- if (buffer().hasMacro(name)) {
- MacroData const tmpl = buffer().getMacro(name);
- for (int i = 0; i tmpl.numargs(); ++i)
- cell().insert(pos(), MathAtom(new MathBraceInset));
- }
+ niceInsert(createMathInset(name));
}
Index: factory.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/factory.C,v
retrieving revision 1.90
diff -u -p -r1.90 factory.C
--- factory.C 13 Apr 2004 06:27:26 - 1.90
+++ factory.C 13 Apr 2004 13:47:02 -
@@ -469,6 +469,15 @@ InsetBase * readInset(LyXLex lex, Buff
}
inset-read(buf, lex);
+
+#warning hack..
+ if (inset-lyxCode() == InsetBase::MATHMACRO_CODE) {
+ MathMacroTemplate const * tmpl =
+ static_castMathMacroTemplate*(inset.get());
+ MacroTable::globalMacros().insert
+ (tmpl-name(), tmpl-asMacroData());
+ lyxerr creating local macro tmpl-name() endl;
+ }
}
return inset.release();
Index: mathed/math_data.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_data.C,v
retrieving revision 1.50
diff -u -p -r1.50 math_data.C
--- mathed/math_data.C 13 Apr 2004 06:27:28 - 1.50
+++ mathed/math_data.C 13 Apr 2004 13:48:23 -
@@ -249,10 +249,11 @@ void MathArray::metrics(MetricsInfo mi
dim_.wid = 0;
Dimension d;
- BufferView bv = *mi.base.bv;
- Buffer const buf = *bv.buffer();
+ //BufferView bv = *mi.base.bv;
+ //Buffer const buf = *bv.buffer();
for (size_t i = 0, n = size(); i != n; ++i) {
MathAtom const at = operator[](i);
+#if 0
MathMacro const * mac = at-asMacro();
if (mac buf.hasMacro(mac-name())) {
MacroData const tmpl = buf.getMacro(mac-name());
@@ -272,6 +273,7 @@ void MathArray::metrics(MetricsInfo mi
continue;
}
}
+#endif
at-metrics(mi, d);
dim_ += d;
}
@@ -300,10 +302,11 @@ void MathArray::draw(PainterInfo pi, i
|| x = pi.pain.paperWidth())
return;
- BufferView bv = *pi.base.bv;
- Buffer const buf = *bv.buffer();
+ //BufferView bv = *pi.base.bv;
for (size_t i = 0, n = size(); i != n; ++i) {
MathAtom const at = operator[](i);
+#if 0
+ Buffer const buf = *bv.buffer();
// special macro handling
MathMacro const * mac = at-asMacro();
if (mac buf.hasMacro(mac-name())) {
@@ -318,6 +321,7 @@ void MathArray::draw(PainterInfo pi, i
continue;
}
Re: My next target?
John Levon wrote: Resizing the Qt frontend dialog has no effect on the tabs :-( I'm sure it is something trivial, but I'm blowed if I know what. You broke the layout (added something ?). You need to group stuff again (select the objects then use the right mouse button menu) Good man! Got it! And of course you still need to use Qt 2 Yes, I knew that bit. -- Angus
Re: Command buffer
On Tue, Apr 13, 2004 at 02:52:59PM +0100, John Levon wrote: In case anyone's interested, the rationale is simple - nobody* knew that you could type into the minibuffer. This was partly due to visual decoration in the xforms frontend, and partly due to its status bar behaviour. And once we've separated the two, there's little argument for taking up vertical space by default for something that is difficult to use, essentially undocumented, and only used by a few people. So, if I understand correctly, the argument goes as follows. - nobody but a few knew of the command line - so we separated it from the status display to make them more visible - now it takes too much space - so we hide it Well, it looks as if this solution is uniformly worse than what was there before: - People who did not know that there was a commandline won't know it now, either. So this is a draw. - People who did know of the commandline are divided into two groups: + those who will find the hidden commandline (giving almost a draw) and + people who knew the commandline but won't find it anymore (clearly worse) Actually, I'd don't believe anybody that used to use the commandline has a problem with it 'abuse' as status bar. At least vi does exactly the same. So this is a known concept potential 'power users' will be aware of. Andre'
Re: update
On Tue, Apr 13, 2004 at 04:07:34PM +0200, Braunstein Alfredo wrote: We are avoiding several things. First is updateParPositions(), second I may be wrong, but I don't think this is the bottleneck. It was at some point of time. Went mostly away when going from per-row y caches to per-paragraph y caches plus row-in-par offset, remember? This saved about a factor of ten, but it still looms. (and more important) is the need to have a (semi-)correct row cache at all. So we would basically never have to call redoParagraph() manually. ... which is not really expensive IMO But hard to find the right places to call it. And we would not need redoParagraph() in e.g. LyXText::init... ...but this has nothing to do with editing slowdown... But with e.g. buffer loading and buffer switching? [Not sure here, don't have the sources at hand] So: I may agree that its a reasonable change (I even remember proposing something along the lines last year), but I don't think we are solving any performance problem... So you claim that the only reason of the perceived cursor-right performance problem is redrawing a single full screen full of 2-d data? I am not saying this is impossible, but I'd rather expect a larger part of the problem in the 99 other pages the are not drawn yet touched in update. Andre'
Re: Command buffer
On Tue, Apr 13, 2004 at 06:09:27PM +0200, Andre Poenitz wrote: So, if I understand correctly, the argument goes as follows. - nobody but a few knew of the command line - so we separated it from the status display to make them more visible - now it takes too much space - so we hide it No, the argument goes as follows: - all else being equal, the thing should be separate from the status bar for reasons I have given a long time ago - both the status bar and the command line take up valuable real estate - the status bar cannot and should not be hidden - the command line is useful to a few (notable sub-category - developers) who can work out how to use it - ergo, the command line can be hidden by default - People who did not know that there was a commandline won't know it now, either. So this is a draw. Correct. - People who did know of the commandline are divided into two groups: + those who will find the hidden commandline (giving almost a draw) and + people who knew the commandline but won't find it anymore (clearly worse) Correct (see below). You managed to leave out: + people will recognise the Qt status bar *as* a status bar - it's painted like one, and it looks like one. And yes, this matters - I've seen user queries on this issue before on the users list (since your metric seems to be did anybody complain?) Now, onto what we really want, namely: o minimal screen estate wasted by default o standardised widgets in the standardised places with the standardised look o a way for power users (a terrible phrase) to easily enter commands Currently, we can improve the last case. In particular: o Add a View-Toolbars-[ ] Command Line (or whatever) o Angus's M-x This supports both discoverability for new users and convenience for existing ones. Actually, I'd don't believe anybody that used to use the commandline has a problem with it 'abuse' as status bar. At least vi does exactly the same. We are not vi, or emacs. regards john
[patch]: re-enable previews for mathed.
I moved the 'connect' stuff inside the preview code, so the
MathHullInset doesn't look too bad.
Committing now...
--
AngusIndex: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.1893
diff -u -p -r1.1893 ChangeLog
--- src/ChangeLog 13 Apr 2004 13:10:32 - 1.1893
+++ src/ChangeLog 13 Apr 2004 17:33:44 -
@@ -1,5 +1,10 @@
2004-04-13 Angus Leeming [EMAIL PROTECTED]
+ * text3.C (dispatch): call Inset::.notifyCursorLeaves when the
+ cursor is clicked out of an inset.
+
+2004-04-13 Angus Leeming [EMAIL PROTECTED]
+
* lyx_main.[Ch] (updateInset): pass it an InsetBase pointer rather
than an InsetOld one.
Index: src/text3.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text3.C,v
retrieving revision 1.248
diff -u -p -r1.248 text3.C
--- src/text3.C 13 Apr 2004 06:27:28 - 1.248
+++ src/text3.C 13 Apr 2004 17:33:45 -
@@ -1148,6 +1148,10 @@ void LyXText::dispatch(LCursor cur, Fu
finishUndo();
cur.x_target() = cursorX(cur.top());
+ // Has the cursor just left the inset?
+ if (bv-cursor().inMathed() !cur.inMathed())
+ bv-cursor().inset().notifyCursorLeaves(bv-cursor());
+
// Set cursor here.
bv-cursor() = cur;
Index: src/mathed/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/ChangeLog,v
retrieving revision 1.420
diff -u -p -r1.420 ChangeLog
--- src/mathed/ChangeLog 5 Apr 2004 14:01:29 - 1.420
+++ src/mathed/ChangeLog 13 Apr 2004 17:33:48 -
@@ -1,3 +1,12 @@
+2004-04-13 Angus Leeming [EMAIL PROTECTED]
+
+ * math_hullinset.[Ch]: add a RenderPreview variable.
+ (copy c-tor, copy assignment operator, d-tor, notifyCursorLeaves,
+ addPreview): new member functions. The copy c-tor and assignment op
+ could be replaced by the compiler-generated defaults if preview_
+ was stored as a RenderPreview var rather than a scoped pointer.
+ (metrics, draw): use the preview renderer if previewing is turned on.
+
2004-04-05 Angus Leeming [EMAIL PROTECTED]
* math_scriptinset.C (up, down, notifyCursorLeaves): ensure that
Index: src/mathed/math_hullinset.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_hullinset.C,v
retrieving revision 1.132
diff -u -p -r1.132 math_hullinset.C
--- src/mathed/math_hullinset.C 13 Apr 2004 06:27:28 - 1.132
+++ src/mathed/math_hullinset.C 13 Apr 2004 17:33:49 -
@@ -26,15 +26,22 @@
#include gettext.h
#include LaTeXFeatures.h
#include LColor.h
+#include lyx_main.h
#include lyxrc.h
#include outputparams.h
#include textpainter.h
#include undo.h
+#include insets/render_preview.h
+
#include frontends/Alert.h
+#include graphics/PreviewLoader.h
+
#include support/std_sstream.h
+#include boost/bind.hpp
+
using std::endl;
using std::max;
@@ -114,7 +121,8 @@ namespace {
MathHullInset::MathHullInset()
- : MathGridInset(1, 1), type_(none), nonum_(1), label_(1)
+ : MathGridInset(1, 1), type_(none), nonum_(1), label_(1),
+ preview_(new RenderPreview(this))
{
//lyxerr sizeof MathInset: sizeof(MathInset) endl;
//lyxerr sizeof MetricsInfo: sizeof(MetricsInfo) endl;
@@ -125,18 +133,42 @@ MathHullInset::MathHullInset()
MathHullInset::MathHullInset(string const type)
- : MathGridInset(getCols(type), 1), type_(type), nonum_(1), label_(1)
+ : MathGridInset(getCols(type), 1), type_(type), nonum_(1), label_(1),
+ preview_(new RenderPreview(this))
{
setDefaults();
}
+MathHullInset::MathHullInset(MathHullInset const other)
+ : MathGridInset(other),
+ type_(other.type_), nonum_(other.nonum_), label_(other.label_),
+ preview_(new RenderPreview(this))
+{}
+
+
+MathHullInset::~MathHullInset()
+{}
+
+
auto_ptrInsetBase MathHullInset::clone() const
{
return auto_ptrInsetBase(new MathHullInset(*this));
}
+void MathHullInset::operator=(MathHullInset const other)
+{
+ if (this == other)
+ return;
+ *static_castMathGridInset*(this) = MathGridInset(other);
+ type_ = other.type_;
+ nonum_ = other.nonum_;
+ label_ = other.label_;
+ preview_.reset(new RenderPreview(*other.preview_, this));
+}
+
+
MathInset::mode_type MathHullInset::currentMode() const
{
if (type_ == none)
@@ -194,6 +226,20 @@ char const * MathHullInset::standardFont
void MathHullInset::metrics(MetricsInfo mi, Dimension dim) const
{
+ bool const use_preview = (!editing(mi.base.bv)
+ RenderPreview::activated()
+ preview_-previewReady());
+
+ if (use_preview) {
+ preview_-metrics(mi, dim);
+ // insert a one pixel gap in front of the formula
+ dim.wid += 1;
+ if (display())
+ dim.des += 12;
+ dim_ = dim;
+ return;
+ }
+
FontSetChanger dummy1(mi.base, standardFont());
StyleChanger dummy2(mi.base, display() ? LM_ST_DISPLAY : LM_ST_TEXT);
@@ -228,6 +274,18 @@ void
Collapsable insets *still* extending beyond the rh margin
Alfredo, I thought that you'd fixed this one? -- Angusattachment: snapshot1.png
Re: macros
Andre Poenitz wrote: I'll try to create a diff and attach this to this mail, would be nice if someone could attach it to one of the macor related bugs on bugzilla lest it gets lost. Ok, this is down attached to bug #1552. -- Angus
Re: Collapsable insets *still* extending beyond the rh margin
Angus Leeming wrote: Alfredo, I thought that you'd fixed this one? No. We never decided really what to do. Alfredo
Re: update
Andre Poenitz wrote: ...but this has nothing to do with editing slowdown... But with e.g. buffer loading and buffer switching? [Not sure here, don't have the sources at hand] Probably, I agree. So: I may agree that its a reasonable change (I even remember proposing something along the lines last year), but I don't think we are solving any performance problem... So you claim that the only reason of the perceived cursor-right performance problem is redrawing a single full screen full of 2-d data? I am not saying this is impossible, but I'd rather expect a larger part of the problem in the 99 other pages the are not drawn yet touched in update. 1) Just uncomment the code you have commented out in selHandle and try cursor right. There is at least one call to updateParPositions (called from fitCursor - redoParagraph - updateParPositions) for every movement. Compare with cvs. (I've used UserGuide4 which I think is quite larger than Kayvan's document) 2) updateParPositions is the lightest immaginable O(n) algorithm. If we are going to have O(n) in updateCounters and the macro stuff, it will be with a much larger constant... 3) what happened to the O(n) per user interaction is ok karma? I've never agreed completely, but I would expect at least to follow it yoursef :-P Alfredo
Re: Command buffer
On Mon, Apr 12, 2004 at 06:02:05PM +0100, John Levon wrote: > On Sat, Apr 10, 2004 at 11:34:43PM +0200, Andre Poenitz wrote: > > > Well, if this would be done, I could live with it. Until then I'd > > prefer a visible mini-buffer. Makes debugging a bit easier. > > We could probably enable it by default for development versions or > something I certainly wouldn't mind... Andre'
Re: update
Andre Poenitz wrote: > > It still looks as if update() has a tendency to get expensive if certain > nice-to-have or necessary features are triggered from there. > > A good part of the complications come from top_y() which needs to be > more or less up-to-date as it is used in: > > 1 LyXText::checkInsetHit(int x, int y) > for finding the visible paragraphs (as an indication where to > search for visible insets that might have been hit) > 2 LyXText::cursorPrevious()/cursorNext(), the MOUSE_MOTION handler > for setCursorFromCoordinates(cur, x, y); > 3 rowpainter: paintPars() > for putting a paragraph/row at a certain y-coordinate > 4 rowpainter: paintText() > for finding the visible paragraphs > 5 BufferView_pimpl::update() > for finding the visible paragraphs (to re-break them) > 6 BufferView_pimpl::scrollDocView() > for calling text->setCursorFromCoordinates(bv_->cursor(), 0, y); > 7 BufferView::Pimpl::scroll(int lines) > for calling crollDocView and > workarea().setScrollbarParams() > 8 LyXScreen::showCursor() > for showing the cursor at a certain position > 9 LyXScreen::fitCursor() > for putting the cursor at a certain position > 10 InsetCollapsablei/Tabular::draw() > for some fancy coordinate correction > > Now, is this needed? > > I don't think so, but I might be wrong. > > Let's consider the cursor itself as well as a y-offset 'new_top_y' > from top of the visible screen as "primary" information. Now: > > 1 LyXText::checkInsetHit(int x, int y) > for finding the visible paragraphs (as an indication where to > search for visible insets that might have been hit) > 2 LyXText::cursorPrevious()/cursorNext(), the MOUSE_MOTION handler > for setCursorFromCoordinates(cur, x, y); > > could be solved by checking a few paragraphs in the vicinity of the > cursor. Of course, these better should have been rebroken lately, but > even if not we could do so in O(1) by re-breaking the current par, and > possibly the par above if this is visible and possibly the par above ... > etc. There's a limited number of them as each row has a positive height. > > 3 rowpainter: paintPars() > for putting a paragraph/row at a certain y-coordinate > > Well, we are given new_top_y, so we know where to draw things. > > 4 rowpainter: paintText() > for finding the visible paragraphs > 5 BufferView_pimpl::update() > for finding the visible paragraphs (to re-break them) > > Same as 1 and 2. > > 6 BufferView_pimpl::scrollDocView() > for calling text->setCursorFromCoordinates(bv_->cursor(), 0, y); > 7 BufferView::Pimpl::scroll(int lines) > for calling crollDocView and > workarea().setScrollbarParams() > > That's interesting as this is the place where we actually would need > absolute heights in the whole document. However, as this only affects > the scrollbar, some approximation should be in order. Using the count of > visible toplevel paragraphs in relation to the total number of toplevel > paragraphs as well as well as the offset of the cursor's toplevel par > in relation to the total is such approximation and I claim this is good > enough. Agreed. > 8 LyXScreen::showCursor() > for showing the cursor at a certain position > > We are given new_top_y. > > 9 LyXScreen::fitCursor() > for putting the cursor at a certain position > > As simple as setting new_top_y to a new value. > > 10 InsetCollapsable/Tabular::draw() > for some fancy coordinate correction > > No need for correction in screen-absolute coordinates. > > Note that the dreaded 'put cursor into never explored land' problem > would be magically solved. We put the cursor physically there (by > assigning from a DocIterator or similar) and set new_top_y to, well, > 100 or so. > > Now it's update time: rebreak all visible outerlevel pars starting with > the cursor par and going up and down as needed. And we are done. > > So now the interesting question: What do I miss? Nothing comes to my mind rigth now, but as you know problems come when you have started implementing... ;-) > PS: There'll still be O(n) parts for updateCounters() and similar. > However, those have been there before and were tolerable in 1.3.x. I agree that it's doable. I do think that it's more complex than what we have now. Before getting into details, what exactly are we avoiding, updateParPositions? Are you sure that this is the bottleneck? Alfredo
Re: My next target?
Angus Leeming wrote:
> Question 2
> ==
> Is this safe? What happens if command.size() < 50?
>
> + bformat(_("An error occurred whilst running %1$s"),
> + command.substr(0, 50)));
I have replaced it with MakeDisplayPath, which works well.
> Question 4
> ==
> Why is LyXRC::RC_EDITOR needed? Isn't this just part of the format
> definition? Ie, why not extend RC_FORMAT? (And ditch RC_VIEWER also.)
I did that. I also removed EditCommand from the external templates, it
turned out to be rather easy. Updated patch attached.
Georg
Index: lib/ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/lib/ChangeLog,v
retrieving revision 1.579
diff -u -p -r1.579 ChangeLog
--- lib/ChangeLog 2004/04/06 21:07:26 1.579
+++ lib/ChangeLog 2004/04/12 19:38:50
@@ -1,3 +1,9 @@
+2004-04-12 Georg Baum <[EMAIL PROTECTED]>
+
+ * configure.m4: merge \viewer and \format. Add editor to \format
+ * configure.m4: check for more viewers and editors
+ * external_templates: remove EditCommand
+
2004-04-06 Georg Baum <[EMAIL PROTECTED]>
* external_templates: use some new variables instead of $$Basename
Index: lib/configure.m4
===
RCS file: /cvs/lyx/lyx-devel/lib/configure.m4,v
retrieving revision 1.75
diff -u -p -r1.75 configure.m4
--- lib/configure.m4 2004/03/22 16:22:52 1.75
+++ lib/configure.m4 2004/04/12 19:38:54
@@ -237,6 +237,20 @@ fi
test $latex_to_dvi != "none" && latex_to_dvi="$latex_to_dvi \$\$i"
test $latex_to_pdf != "none" && latex_to_pdf="$latex_to_pdf \$\$i"
+SEARCH_PROG([for a TGIF viewer and editor], TGIF_EDITOR, tgif)
+TGIF_VIEWER="$TGIF_EDITOR"
+
+SEARCH_PROG([for a FIG viewer and editor], FIG_EDITOR, xfig)
+FIG_VIEWER="$FIG_EDITOR"
+
+SEARCH_PROG([for a FEN viewer and editor], FEN_EDITOR, xboard)
+test "$FEN" = "xboard" && FEN_EDITOR="xboard -lpf \$\$i -mode EditPosition"
+FEN_VIEWER="$FEN_EDITOR"
+
+SEARCH_PROG([for a raster image viewer], RASTERIMAGE_VIEWER, xv kview gimp)
+
+SEARCH_PROG([for a raster image editor], RASTERIMAGE_EDITOR, gimp)
+
# Search for an installed reLyX or a ready-to-install one
save_PATH=${PATH}
PATH=${PATH}:./reLyX/
@@ -492,113 +560,102 @@
# want to customize LyX, make a copy of the file LYXDIR/lyxrc as
# ~/.lyx/lyxrc and edit this file instead. Any setting in lyxrc will
# override the values given here.
-\\Format asciichess asc "ASCII (chess output)" ""
-\\Format asciiimage asc "ASCII (image)" ""
-\\Format asciixfig asc "ASCII (xfig output)" ""
-\\Format agr agr GRACE ""
-\\Format bmp bmp BMP ""
-\\Format date """date command" ""
-\\Format dateout "tmp" "date (output)" ""
-\\Format docbook sgml DocBook B
-\\Format dvi dvi DVI D
-\\Format eps eps EPS ""
-\\Format fax "" Fax ""
-\\Format fen fen FEN ""
-\\Format fig fig XFig ""
-\\Format gif gif GIF ""
-\\Format html html HTML H
-\\Format jpg jpg JPG ""
-\\Format latex tex LaTeX L
-\\Format linuxdoc sgml LinuxDoc x
-\\Format lyx lyx LyX ""
-\\Format lyxpreview lyxpreview "LyX Preview" ""
-\\Format literate nw NoWeb N
-\\Format pbm pbm PBM ""
-\\Format pdf pdf "PDF (ps2pdf)" P
-\\Format pdf2 pdf "PDF (pdflatex)" F
-\\Format pdf3 pdf "PDF (dvipdfm)" m
-\\Format pdftex pdftex_t PDFTEX ""
-\\Format pgm pgm PGM ""
-\\Format png png PNG ""
-\\Format ppm ppm PPM ""
-\\Format program "" Program ""
-\\Format ps ps Postscript t
-\\Format pstexpstex_t PSTEX ""
-\\Format text txt ASCII A
-\\Format textparagraph txt ASCII(paragraphs) ""
-\\Format tgif obj TGIF ""
-\\Format tiff tif TIFF ""
-\\Format word doc Word W
-\\Format xbm xbm XBM ""
-\\Format xpm xpm XPM ""
-
-\\converter date dateout "date +%d-%m-%Y > \$\$o" ""
-\\converter docbook dvi "$docbook_to_dvi_command" ""
-\\converter docbook html "$docbook_to_html_command" ""
-\\converter dvi pdf3 "$dvi_to_pdf_command" ""
-\\converter dvi ps "$dvi_to_ps_command" ""
-\\converter fen asciichess "python \$\$s/fen2ascii.py \$\$i \$\$o" ""
-\\converter fig pdftex "sh \$\$s/fig2pdftex.sh \$\$i \$\$o" ""
-\\converter fig pstex "sh \$\$s/fig2pstex.sh \$\$i \$\$o" ""
-\\converter html latex "$html_to_latex_command" ""
-\\converter latex html "$latex_to_html_command" "originaldir,needaux"
-\\converter latex dvi "$latex_to_dvi" "latex"
-\\converter latex lyx "$tex_to_lyx_command" ""
-\\converter latex pdf2 "$latex_to_pdf" "latex"
-\\converter linuxdoc dvi "$linuxdoc_to_dvi_command" ""
-\\converter linuxdoc html "$linuxdoc_to_html_command" ""
-\\converter linuxdoc latex "$linuxdoc_to_latex_command" ""
-\\converter linuxdoc lyx "$linuxdoc_to_lyx_command" ""
-\\converter literate latex "$literate_to_tex_command" ""
-\\converter literate lyx "$literate_to_lyx_command" ""
-\\converter lyxpreview ppm "$lyxpreview_to_bitmap_command" ""
-\\converter ps fax "$fax_command" ""
-\\converter ps pdf "$ps_to_pdf_command"
Re: Bug: Formulas in Description?
Peter Hutnick wrote:
> First, I'd like to thank each of you for dedicating his or her time
> to writing and/or supporting Free Software.
>
> Now, I /think/ I've hit a bug. Initially it was with an old
> version, but I have upgraded to the lyx-1.3.4-1rh9_qt.i386.rpm.
>
> I have a .lyx file with a block of descriptions. I have simplified
> the problem to a very short .lyx file that I attached.
>
> The problem might be related to a description that contains two
> formulas
> joined by ctrl-spaces. It is pretty hard to explain, but you can
> reproduce it by:
>
> 1. Open the attached file in LyX.
> 2. Hit view DVI (or view anything, really).
> 3. Watch error boxes pop up.
Even simpler:
\begin{description}
\item [$]$]blah
\end{description}
LaTeX gets confused. The appropriate entry from the log file:
l.20 \item [$]
$]blah\end{description}
I've deleted a group-closing symbol because it seems to be
spurious, as in `$x}$'. But perhaps the } is legitimate and
you forgot something else, as in `\hbox{$x}'. In such cases
the way to recover is to insert both the forgotten and the
deleted material, e.g., by typing `I$}'.
! LaTeX Error: Something's wrong--perhaps a missing \item.
See the LaTeX manual or LaTeX Companion for explanation.
Type H for immediate help.
...
Personally, I think you've been unfortunate, but LyX's mathed editor
has never prevented you from generating incorrect latex, nor could it
without being a fully fledged latex compiler.
Just my 2 pennies of opinion of course.
Angus
Math macros ---- Woooooo!
Andre, thank you, thank you, thank you!
However, the new scheme appears to produce an extra, unnecessary set
of red braces. Try the attached, 13x file with lyx 13x and with
current cvs.
The good news is that the latex exported by both versions is
identical:
\newcommand{\Vector}[1]{\boldsymbol{#1}}
$\Vector{V}_{0}=V_{x0}\Vector{i}$
--
Angus
trial.lyx
Description: application/lyx
Re: macros
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> Now, what should we do? I could declare math macros (with Andre> arguments, macros without arguments are no problem) a 'Power Andre> User Feature' and require basic TeX knowledge from people that Andre> wish to use it. Or we could live with the mess as we did up to Andre> now. I am not sure that macros with argument should be a power-user only thing. In particular, we might want one days to declare in .layout files some macros that are defined by the documentclass. We should make sure that these are as easy as possible to handle. JMarc
mathed cursor y-position is off
Enter a math inset and the cursor is positioned visibly half a screen above the correct location. Navigation works fine, but the cursor remains half a screen above the inset. -- Angus
Re: update
Andre Poenitz wrote: > It still looks as if update() has a tendency to get expensive if certain > nice-to-have or necessary features are triggered from there. Also note that we don't need to fire an update on every cursor movement, which is the biggest problem. I've just seen your #warning, but I've no clue of what's the problem. Ah, maybe entering/exiting insets should fire an update nevertheless? So should we add some checks directly in the lfun handlers? Alfredo
Re: [patch] cursor position inside math insets
Alfredo Braunstein wrote: > Not sure if this is the "correct" solution though. The top_y habdling > should be probably completely centralized in some setCachePos like in > insets/, but I've lost track inside the math/ hierarchy. Andre', could you have a look? It just adds top_y in a couple of places. Thanks, Alfredo
Re: New lyx2lyx.
On Monday 12 April 2004 19:49, Georg Baum wrote: > Am Montag, 12. April 2004 12:07 schrieb Jose' Matos: > > I will fix those. > > Fine! In the meantime, I found more. Just in case you did not notice > already: > > - conversion to e.g. format 225 does not work: There is no check if > the desired format is reached in convert() and revert() in lyx_1_4.py I said that in the first message, I will do it now as it is quite easy. :-) > - the chain order is wrong for revert (1_3 1_4 instead of 1_4 1_3) Ok. > > > - Why do you attempt to read the version from the comment line? > > > This does not work with tex2lyx: For > > > > And also it does not work with reLyX. The fact is that the header > > carries some information regarding the file format. > > > > Notice that LyX versions 0.12, 1.0.0, 1.0.1, 1.0.4 although > > saying that the fileformat is 2.15 it is a different 2.15 for each. > > This is not nice, but we can't change it;-( True, that is why I have those file with an empty content there. Some of the conversion functions belong to later files. I need to take some time to see which. > > It is for this case that I want to read the version. But as you > > can see in the code the file format is always the definitive guide > > for the convertion. If the lyx versions doesn't match the file > > format then forget it. > > Now I understand. I think it would be better to suppress the warning > then. In my case, the real error was something else, but I thought it > guessed the file format wrong. I think that here it makes sense the warning level. This should be reported only in the most verbose debug mode, as it is otherwise useless. I will have a go today. > > Does this makes sense now? What would you like to change in the > > implementation? > > Only this: Suppress the warning if it is irrelevant, i.e. the > fileformat is not 2.15. This will be necessary also for 2.10, but you right I will supress the warning if the fileformat is <= 215, that should take care of it. > Georg Thanks for your feedback. -- José Abílio LyX and docbook, a perfect match. :-)
Re: My next target?
Georg Baum wrote:
> Angus Leeming wrote:
>
>> Question 2
>> ==
>> Is this safe? What happens if command.size() < 50?
>>
>> + bformat(_("An error occurred whilst running %1$s"),
>> + command.substr(0, 50)));
>
> I have replaced it with MakeDisplayPath, which works well.
>
>> Question 4
>> ==
>> Why is LyXRC::RC_EDITOR needed? Isn't this just part of the format
>> definition? Ie, why not extend RC_FORMAT? (And ditch RC_VIEWER
>> also.)
>
> I did that. I also removed EditCommand from the external templates,
> it turned out to be rather easy. Updated patch attached.
W, you've been careful in lyxrc::read!
I've committed your changes, having moved the edit button to somewhere
more meaningful (I hope). Pressing it no longer activates Ok/Apply
either.
The Qt layout is probably broken. It always is after I muck around :-(
--
Angus
Re: macros
On Mon, Apr 12, 2004 at 08:01:37PM +0100, Angus Leeming wrote: > Andre Poenitz wrote: > > Now, what should we do? I could declare math macros (with arguments, > > macros without arguments are no problem) a 'Power User Feature' and > > require basic TeX knowledge from people that wish to use it. Or we > > could live with the mess as we did up to now. > > Do it the latex way. We can put time and effort into designing a GUI > that makes the thing fool-proof to use. That way the core remains > clean and flexible and we make use of a proven design. Done. Andre'
Re: Math macros ---- Woooooo!
On Tue, Apr 13, 2004 at 11:06:28AM +0100, Angus Leeming wrote:
> Andre, thank you, thank you, thank you!
>
> However, the new scheme appears to produce an extra, unnecessary set
> of red braces. Try the attached, 13x file with lyx 13x and with
> current cvs.
>
> The good news is that the latex exported by both versions is
> identical:
>
> \newcommand{\Vector}[1]{\boldsymbol{#1}}
>
> $\Vector{V}_{0}=V_{x0}\Vector{i}$
A more serious problem with the screen display is if the \Vector macro is
changed to
\newcommand{\Vector}[1]{[#1]}
Re: [patch] cursor position inside math insets
On Tue, Apr 13, 2004 at 11:24:08AM +0200, Alfredo Braunstein wrote: > Alfredo Braunstein wrote: > > > Not sure if this is the "correct" solution though. The top_y habdling > > should be probably completely centralized in some setCachePos like in > > insets/, but I've lost track inside the math/ hierarchy. Btw: there's a README file in mathed containing a (really small) overview on the math hierarchy. Andre'
Re: mathed cursor y-position is off
On Tue, Apr 13, 2004 at 11:15:51AM +0100, Angus Leeming wrote: > Enter a math inset and the cursor is positioned visibly half a screen > above the correct location. Navigation works fine, but the cursor > remains half a screen above the inset. Probably some getCursorPos()/top_y() issue. Adding top_y() to y in MathNestInset::getCursorPos() might help. For this it is probably necessary to change the parameter from CursorSlice to Cursor to have a means to access the BufferView. Andre' PS: Would go magically away if we had screen-absolute coordinates ;-)
Re: My next target?
On Tue, Apr 13, 2004 at 09:35:48AM +0200, Georg Baum wrote:
> Angus Leeming wrote:
>
> > Question 2
> > ==
> > Is this safe? What happens if command.size() < 50?
> >
> > + bformat(_("An error occurred whilst running %1$s"),
> > + command.substr(0, 50)));
>
> I have replaced it with MakeDisplayPath, which works well.
Since you mention MakeDisplayPath:
Whenever anybody touches this kind of code, please make sure to
change the naming to 'LyX style', i.e. camelBumpWithLowerCaseInitial()
for functions.
No need to do it now in a rush, but please keep it in mind.
Thanks,
Andre'
Re: macros
On Tue, Apr 13, 2004 at 11:08:30AM +0200, Jean-Marc Lasgouttes wrote: > > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: > > Andre> Now, what should we do? I could declare math macros (with > Andre> arguments, macros without arguments are no problem) a 'Power > Andre> User Feature' and require basic TeX knowledge from people that > Andre> wish to use it. Or we could live with the mess as we did up to > Andre> now. > > I am not sure that macros with argument should be a power-user only > thing. In particular, we might want one days to declare in .layout > files some macros that are defined by the documentclass. We should > make sure that these are as easy as possible to handle. But first of all they should work, shouldn't they? Up to now opening two documents with user defined macros had a decent potential to screw either document. I think Angus was right with his remark to get the structure right first and build a decent GUI later. I think we've got a suitable structure now. Pretty close to what TeX does with all the flexibility (needed or not...). And no document destroys another one anymore just because they happen to contain macros of the same name but different definitions... Andre'
Re: update
On Tue, Apr 13, 2004 at 08:54:38AM +0200, Alfredo Braunstein wrote: > > So now the interesting question: What do I miss? > > Nothing comes to my mind rigth now, but as you know problems come when you > have started implementing... ;-) I think the crucial translation is top_y -> new_top_y (buffer absolute to screen absolute) which should be > > PS: There'll still be O(n) parts for updateCounters() and similar. > > However, those have been there before and were tolerable in 1.3.x. > > I agree that it's doable. I do think that it's more complex than what we > have now. Before getting into details, what exactly are we avoiding, > updateParPositions? Are you sure that this is the bottleneck? We are avoiding several things. First is updateParPositions(), second (and more important) is the need to have a (semi-)correct row cache at all. So we would basically never have to call redoParagraph() manually. And we would not need redoParagraph() in e.g. LyXText::init... Andre'
Re: update
On Tue, Apr 13, 2004 at 11:20:06AM +0200, Alfredo Braunstein wrote: > > It still looks as if update() has a tendency to get expensive if certain > > nice-to-have or necessary features are triggered from there. > > Also note that we don't need to fire an update on every cursor movement, > which is the biggest problem. I've just seen your #warning, but I've no > clue of what's the problem. Ah, maybe entering/exiting insets should fire > an update nevertheless? Entering/leaving insets toggles e.g. the pink corners in math. But we'd need a more stable mechanism for these anyway as we'd like to trigger preview too. > So should we add some checks directly in the lfun handlers? That's the way to go I am afraid. Only call noUpdate() whenever you are really sure that no update is needed. I think it'd be sufficient for the simple cursor left/right movements for starters as these are a big part of the user's 'performance experience' Andre'
Re: Math macros ---- Woooooo!
On Tue, Apr 13, 2004 at 11:06:28AM +0100, Angus Leeming wrote: > Andre, thank you, thank you, thank you! > > However, the new scheme appears to produce an extra, unnecessary set > of red braces. Try the attached, 13x file with lyx 13x and with > current cvs. Hm... parser problem... Too much cleverness to avoid 'extra' braces. I don't think I will have time to investigate this before Friday. Andre'
Re: Command buffer
Andre Poenitz <[EMAIL PROTECTED]> writes: | On Mon, Apr 12, 2004 at 06:02:05PM +0100, John Levon wrote: >> On Sat, Apr 10, 2004 at 11:34:43PM +0200, Andre Poenitz wrote: >> >> > Well, if this would be done, I could live with it. Until then I'd >> > prefer a visible mini-buffer. Makes debugging a bit easier. >> >> We could probably enable it by default for development versions or >> something > | I certainly wouldn't mind... Is the argument for not having it visible always, valid? -- Lgb
Re: Math macros ---- Woooooo!
On Tue, Apr 13, 2004 at 11:06:28AM +0100, Angus Leeming wrote:
> Andre, thank you, thank you, thank you!
>
> However, the new scheme appears to produce an extra, unnecessary set
> of red braces. Try the attached, 13x file with lyx 13x and with
> current cvs.
>
> The good news is that the latex exported by both versions is
> identical:
>
> \newcommand{\Vector}[1]{\boldsymbol{#1}}
>
> $\Vector{V}_{0}=V_{x0}\Vector{i}$
Urgs.
The problem here is that '_' attaches to the last thing in front of it.
In the everything-is-an-inset, this is the whole ('expanded') macro,
i.e.[Vector V]_0
Now macros are only expanded for drawing, so the _0 attaches to the last
item on the left which is the 'V', i.e. to the macro argument. When the
thing is drawn, the macro reads one argument, which is now V_0.
Sh**, sh**, sh**.
TeX doesn't have this problem as it attaches the subscript only after
the Vector V has already been processed and put into a box.
Well, looks as if the two worlds don't fit together too well. To go the
TeX route we'd need to defer the attaching of the subscript to drawing
time, too, i.e. no nice MathScriptInset. Sh... But we can't do this.
And that's not just when reading a buffer (we could probably work around
there somehow), but all the time we translate between MathArrays and
string, i.e. "always".
Looks like a real dilemma.
Andre'
Re: mathed cursor y-position is off
On Tue, Apr 13, 2004 at 11:15:51AM +0100, Angus Leeming wrote: > Enter a math inset and the cursor is positioned visibly half a screen > above the correct location. Navigation works fine, but the cursor > remains half a screen above the inset. Should bne fixed now. Andre'
Re: macros
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> But first of all they should work, shouldn't they? Up to now Andre> opening two documents with user defined macros had a decent Andre> potential to screw either document. I think Angus was right Andre> with his remark to get the structure right first and build a Andre> decent GUI later. I think we've got a suitable structure now. Andre> Pretty close to what TeX does with all the flexibility (needed Andre> or not...). And no document destroys another one anymore just Andre> because they happen to contain macros of the same name but Andre> different definitions... I agree of course. I just did not agree with your comment on ``since macros with arguments are a power-user thing, they might as well be ugly to use''. JMarc
Re: Command buffer
Lars Gullik Bjønnes wrote: >>> > Well, if this would be done, I could live with it. Until then >>> > I'd prefer a visible mini-buffer. Makes debugging a bit easier. >>> >>> We could probably enable it by default for development versions or >>> something >> > | I certainly wouldn't mind... > > Is the argument for not having it visible always, valid? I think so. Here's why. The command buffer performs two roles: 1. It provides us with state information. (All those useful 'Running latex' etc messages.) 2. It gives us a means to enter lfuns from 'by hand'. The xforms frontend follows emacs by incorporating both functionalities in a single bar. The Qt frontend, on the other hand, has separate widgets (and bars) for each. The 'information widget' is always visible in all frontends. It certainly would not be valid to hide it. The 'command input widget' is hidden by default in the Qt frontend. The argument is that only 'experts' use it. It's this that I'd like to trigger visible with M-x. This is a non-issue with the xforms frontend, as the widget is visible always. -- Angus
Re: Command buffer
On Tue, Apr 13, 2004 at 03:14:11PM +0200, Lars Gullik Bjønnes wrote: > Is the argument for not having it visible always, valid? I don't think so. Personnaly I'd like to have the minibuffer always visible. But I don't care too much about UI issues as long as it does not interfere with the way I am used to using LyX... Andre'
RE: Command buffer
>> Is the argument for not having it visible always, valid? > I think so. Here's why. > The command buffer performs two roles: maybe time to implement a status bar to separate the two? ed.
RE: Command buffer
Leuven, E. wrote: >>> Is the argument for not having it visible always, valid? >> I think so. Here's why. >> The command buffer performs two roles: > > maybe time to implement a status bar to separate the two? Let's fix existing bugs rather than create new ones. It'd be nice to get 14x out of the door in 2004. -- Angus
Re: Command buffer
On Tue, Apr 13, 2004 at 03:32:32PM +0100, Angus Leeming wrote: > I think so. Here's why. > > The command buffer performs two roles: > 1. It provides us with state information. (All those useful 'Running > latex' etc messages.) > 2. It gives us a means to enter lfuns from 'by hand'. > > The xforms frontend follows emacs by incorporating both > functionalities in a single bar. The Qt frontend, on the other hand, > has separate widgets (and bars) for each. In case anyone's interested, the rationale is simple - nobody* knew that you could type into the minibuffer. This was partly due to visual decoration in the xforms frontend, and partly due to its "status bar" behaviour. And once we've separated the two, there's little argument for taking up vertical space by default for something that is difficult to use, essentially undocumented, and only used by a few people. regards, john
Re-enabling previews for mathed
Ok, Andre,
this patch re-enables previewing of math insets. Well, it doesn't
actually alter the MathHullInset::metrics, draw routines, but they're
trivial. It does everything else though, leading to some...
design questions.
1. Triggering the request to generate a preview.
Two possible scenarios:
a) Just loaded a new buffer, so loop over all insets calling
'addPreview' for each. Throw this latex file out to the tmp directory
and generate previews of each and every inset. No problems there.
b) Edited an inset, so trigger preview generation when leaving the
inset. I've gone the LFUN way:
void LyXText::dispatch(LCursor & cur, FuncRequest & cmd) {
...
case LFUN_MOUSE_PRESS: {
...
// Has the cursor just left the inset?
if (bv->cursor().inMathed() && !cur.inMathed())
bv->cursor().inset().notifyCursorLeaves(bv->cursor());
...
}
...
}
void MathHullInset::priv_dispatch(LCursor & cur, FuncRequest & cmd)
{
switch (cmd.action) {
case LFUN_FINISHED_LEFT:
case LFUN_FINISHED_RIGHT:
case LFUN_FINISHED_UP:
case LFUN_FINISHED_DOWN:
MathGridInset::priv_dispatch(cur, cmd);
notifyCursorLeaves(cur);
break;
...
}
I tried the update way, but it seems to me that LyXText::dispatch is
the only place that knows that the cursor was in an inset but is in
one no more.
2. Embedding the RenderPreview object in the MathHullInset.
a) Should I store a pointer to a RenderPreview or a RenderPreview
itself? I've chosen to store a pointer to minimize header file
dependencies, but this is 'your code' so it's also 'your call'.
b) The RenderPreview object tells the MathHullInset that the preview
is ready for display by calling MathHullInset::statusChanged.
Unfortunately, boost::bind is noncopyable, so we have to set the
connection from signal to slot explicitly. Hence the hand-coded
MathHullInset copy constructor and operator=.
I'm not happy about them at all.
Since MathHullInset::statusChanged does nothing but invoke
'LyX::cref().updateInset(this)', it would be possible to invoke this
from the RenderPreview object itself. That would require it to store
an InsetBase pointer though...
Feedback welcomed...
--
AngusIndex: src/text3.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text3.C,v
retrieving revision 1.248
diff -u -p -r1.248 text3.C
--- src/text3.C 13 Apr 2004 06:27:28 - 1.248
+++ src/text3.C 13 Apr 2004 13:11:23 -
@@ -1148,6 +1148,13 @@ void LyXText::dispatch(LCursor & cur, Fu
finishUndo();
cur.x_target() = cursorX(cur.top());
+ // Has the cursor just left the inset?
+ if (bv->cursor().inMathed() && !cur.inMathed()) {
+ lyxerr << "\n\n\n\t\tHELLOO!"
+ << endl;
+ bv->cursor().inset().notifyCursorLeaves(bv->cursor());
+ }
+
// Set cursor here.
bv->cursor() = cur;
Index: src/mathed/math_hullinset.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_hullinset.C,v
retrieving revision 1.132
diff -u -p -r1.132 math_hullinset.C
--- src/mathed/math_hullinset.C 13 Apr 2004 06:27:28 - 1.132
+++ src/mathed/math_hullinset.C 13 Apr 2004 13:11:26 -
@@ -26,15 +26,22 @@
#include "gettext.h"
#include "LaTeXFeatures.h"
#include "LColor.h"
+#include "lyx_main.h"
#include "lyxrc.h"
#include "outputparams.h"
#include "textpainter.h"
#include "undo.h"
+#include "insets/render_preview.h"
+
#include "frontends/Alert.h"
+#include "graphics/PreviewLoader.h"
+
#include "support/std_sstream.h"
+#include
+
using std::endl;
using std::max;
@@ -114,8 +121,10 @@ namespace {
MathHullInset::MathHullInset()
- : MathGridInset(1, 1), type_("none"), nonum_(1), label_(1)
+ : MathGridInset(1, 1), type_("none"), nonum_(1), label_(1),
+ preview_(new RenderPreview)
{
+ preview_->connect(boost::bind(::statusChanged, this));
//lyxerr << "sizeof MathInset: " << sizeof(MathInset) << endl;
//lyxerr << "sizeof MetricsInfo: " << sizeof(MetricsInfo) << endl;
//lyxerr << "sizeof MathCharInset: " << sizeof(MathCharInset) << endl;
@@ -125,18 +134,53 @@ MathHullInset::MathHullInset()
MathHullInset::MathHullInset(string const & type)
- : MathGridInset(getCols(type), 1), type_(type), nonum_(1), label_(1)
+ : MathGridInset(getCols(type), 1), type_(type), nonum_(1), label_(1),
+ preview_(new RenderPreview)
{
+ preview_->connect(boost::bind(::statusChanged, this));
setDefaults();
}
+MathHullInset::MathHullInset(MathHullInset const & other)
+ : MathGridInset(other),
+ type_(other.type_), nonum_(other.nonum_), label_(other.label_),
+ preview_(new RenderPreview)
+{
+ preview_->connect(boost::bind(::statusChanged, this));
+}
+
+
+MathHullInset::~MathHullInset()
+{}
+
+
auto_ptr MathHullInset::clone() const
{
Re: update
Andre Poenitz wrote: > I think the crucial translation is top_y -> new_top_y (buffer absolute > to screen absolute) which should be > >> > PS: There'll still be O(n) parts for updateCounters() and similar. >> > However, those have been there before and were tolerable in 1.3.x. >> >> I agree that it's doable. I do think that it's more complex than what we >> have now. Before getting into details, what exactly are we avoiding, >> updateParPositions? Are you sure that this is the bottleneck? > > We are avoiding several things. First is updateParPositions(), second I may be wrong, but I don't think this is the bottleneck. > (and more important) is the need to have a (semi-)correct row cache > at all. So we would basically never have to call redoParagraph() > manually. ... which is not really expensive IMO > And we would not need redoParagraph() in e.g. LyXText::init... ...but this has nothing to do with "editing slowdown"... So: I may agree that its a reasonable change (I even remember proposing something along the lines last year), but I don't think we are solving any performance problem... Alfredo
Re: update
Braunstein Alfredo wrote: > So: I may agree that its a reasonable change (I even remember proposing > something along the lines last year), but I don't think we are solving any > performance problem... OTOH, doing this will nicely reimplement the anchor_row behaviour... (do not move the screen even if size of previous pars changed) Alfredo
Re: My next target?
Angus Leeming wrote: > W, you've been careful in lyxrc::read! IMO existing user preferences files should be read even if they are in the old format, and the extra effort is small. > I've committed your changes, having moved the edit button to somewhere > more meaningful (I hope). Pressing it no longer activates Ok/Apply > either. Good! > The Qt layout is probably broken. It always is after I muck around :-( I'll have a look tonight. Georg
Re: My next target?
Georg Baum wrote: >> The Qt layout is probably broken. It always is after I muck around >> :-( > > I'll have a look tonight. Resizing the Qt frontend dialog has no effect on the tabs :-( I'm sure it is something trivial, but I'm blowed if I know what. Incidentally, it'd be good if the External dialog 'Edit' button was placed similarly to that of the Graphics dialog. At least on the Qt frontend they differ and IMO the Graphics dialog is the pattern to follow. -- Angus
Re: New lyx2lyx.
Here comes the second version. I have added an error/warning scheme as proposed by Angus. *) opt.warning(message, debug_level = 10) this means that we can choose the level of the warning with the default being 10 (show all). *) opt.error(message) prints this message and exits with error code 1 I have fixed those bugs detected by Georg. If I don't get any objections I will apply this today. -- José Abílio LyX and docbook, a perfect match. :-) lyx2lyx.tgz Description: application/tgz
Re: My next target?
On Tue, Apr 13, 2004 at 05:02:59PM +0100, Angus Leeming wrote: > Resizing the Qt frontend dialog has no effect on the tabs :-( I'm sure > it is something trivial, but I'm blowed if I know what. You broke the layout (added something ?). You need to group stuff again (select the objects then use the right mouse button menu) And of course you still need to use Qt 2 john
macros
Well... as I said I have (in theory...) no time until Friday to even
spend a thought on this problem. So I'll just revert most of this stuff
and have a look at it later.
I'll try to create a diff and attach this to this mail, would be nice if
someone could attach it to one of the macor related bugs on bugzilla
lest it gets lost.
The version I commit now should have old behaviour (i.e. all bug and
niceties present), but already decouples macro definition and usage, so
this is about half of the needed work in either direection.
Andre'
? .lyxfunc.C.swo
? .lyxlength.h.swp
? 1
? 1.diff
? insets/C
? mathed/1.diff
Index: buffer.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/buffer.C,v
retrieving revision 1.572
diff -u -p -r1.572 buffer.C
--- buffer.C13 Apr 2004 06:27:25 - 1.572
+++ buffer.C13 Apr 2004 13:46:44 -
@@ -641,6 +641,9 @@ bool Buffer::readFile(LyXLex & lex, stri
}
bool the_end = readBody(lex);
+ //lyxerr << "removing " << MacroTable::localMacros().size()
+ // << " temporary macro entries" << endl;
+ //MacroTable::localMacros().clear();
params().setPaperStuff();
#ifdef WITH_WARNINGS
@@ -1499,6 +1502,7 @@ bool Buffer::hasMacro(string const & nam
void Buffer::insertMacro(string const & name, MacroData const & data)
{
+ MacroTable::globalMacros().insert(name, data);
pimpl_->macros.insert(name, data);
}
Index: cursor.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/cursor.C,v
retrieving revision 1.96
diff -u -p -r1.96 cursor.C
--- cursor.C13 Apr 2004 12:47:48 - 1.96
+++ cursor.C13 Apr 2004 13:46:54 -
@@ -870,12 +870,7 @@ void LCursor::macroModeClose()
if (macro && macro->getInsetName() == name)
lyxerr << "can't enter recursive macro" << endl;
- plainInsert(createMathInset(name));
- if (buffer().hasMacro(name)) {
- MacroData const & tmpl = buffer().getMacro(name);
- for (int i = 0; i < tmpl.numargs(); ++i)
- cell().insert(pos(), MathAtom(new MathBraceInset));
- }
+ niceInsert(createMathInset(name));
}
Index: factory.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/factory.C,v
retrieving revision 1.90
diff -u -p -r1.90 factory.C
--- factory.C 13 Apr 2004 06:27:26 - 1.90
+++ factory.C 13 Apr 2004 13:47:02 -
@@ -469,6 +469,15 @@ InsetBase * readInset(LyXLex & lex, Buff
}
inset->read(buf, lex);
+
+#warning hack..
+ if (inset->lyxCode() == InsetBase::MATHMACRO_CODE) {
+ MathMacroTemplate const * tmpl =
+ static_cast(inset.get());
+ MacroTable::globalMacros().insert
+ (tmpl->name(), tmpl->asMacroData());
+ lyxerr << "creating local macro " << tmpl->name() << endl;
+ }
}
return inset.release();
Index: mathed/math_data.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_data.C,v
retrieving revision 1.50
diff -u -p -r1.50 math_data.C
--- mathed/math_data.C 13 Apr 2004 06:27:28 - 1.50
+++ mathed/math_data.C 13 Apr 2004 13:48:23 -
@@ -249,10 +249,11 @@ void MathArray::metrics(MetricsInfo & mi
dim_.wid = 0;
Dimension d;
- BufferView & bv = *mi.base.bv;
- Buffer const & buf = *bv.buffer();
+ //BufferView & bv = *mi.base.bv;
+ //Buffer const & buf = *bv.buffer();
for (size_t i = 0, n = size(); i != n; ++i) {
MathAtom const & at = operator[](i);
+#if 0
MathMacro const * mac = at->asMacro();
if (mac && buf.hasMacro(mac->name())) {
MacroData const & tmpl = buf.getMacro(mac->name());
@@ -272,6 +273,7 @@ void MathArray::metrics(MetricsInfo & mi
continue;
}
}
+#endif
at->metrics(mi, d);
dim_ += d;
}
@@ -300,10 +302,11 @@ void MathArray::draw(PainterInfo & pi, i
|| x >= pi.pain.paperWidth())
return;
- BufferView & bv = *pi.base.bv;
- Buffer const & buf = *bv.buffer();
+ //BufferView & bv = *pi.base.bv;
for (size_t i = 0, n = size(); i != n; ++i) {
MathAtom const & at = operator[](i);
+#if 0
+ Buffer const & buf = *bv.buffer();
// special macro handling
MathMacro const * mac = at->asMacro();
if (mac && buf.hasMacro(mac->name())) {
@@ -318,6 +321,7 @@ void MathArray::draw(PainterInfo & pi, i
Re: My next target?
John Levon wrote: >> Resizing the Qt frontend dialog has no effect on the tabs :-( I'm >> sure it is something trivial, but I'm blowed if I know what. > > You broke the layout (added something ?). You need to group stuff > again (select the objects then use the right mouse button menu) Good man! Got it! > And of course you still need to use Qt 2 Yes, I knew that bit. -- Angus
Re: Command buffer
On Tue, Apr 13, 2004 at 02:52:59PM +0100, John Levon wrote: > In case anyone's interested, the rationale is simple - nobody* knew that > you could type into the minibuffer. This was partly due to visual > decoration in the xforms frontend, and partly due to its "status bar" > behaviour. > > And once we've separated the two, there's little argument for taking up > vertical space by default for something that is difficult to use, > essentially undocumented, and only used by a few people. So, if I understand correctly, the argument goes as follows. - nobody but a few knew of the command line - so we separated it from the status display to make them more visible - now it takes too much space - so we hide it Well, it looks as if this solution is uniformly worse than what was there before: - People who did not know that there was a commandline won't know it now, either. So this is a draw. - People who did know of the commandline are divided into two groups: + those who will find the hidden commandline (giving almost a draw) and + people who knew the commandline but won't find it anymore (clearly worse) Actually, I'd don't believe anybody that used to use the commandline has a problem with it 'abuse' as status bar. At least vi does exactly the same. So this is a known concept potential 'power users' will be aware of. Andre'
Re: update
On Tue, Apr 13, 2004 at 04:07:34PM +0200, Braunstein Alfredo wrote: > > We are avoiding several things. First is updateParPositions(), second > > I may be wrong, but I don't think this is the bottleneck. It was at some point of time. Went mostly away when going from per-row y caches to per-paragraph y caches plus row-in-par offset, remember? This saved about a factor of ten, but it still looms. > > (and more important) is the need to have a (semi-)correct row cache > > at all. So we would basically never have to call redoParagraph() > > manually. > > ... which is not really expensive IMO But hard to find the right places to call it. > > And we would not need redoParagraph() in e.g. LyXText::init... > > ...but this has nothing to do with "editing slowdown"... But with e.g. buffer loading and buffer switching? [Not sure here, don't have the sources at hand] > So: I may agree that its a reasonable change (I even remember proposing > something along the lines last year), but I don't think we are solving any > performance problem... So you claim that the only reason of the perceived cursor-right performance problem is redrawing a single full screen full of 2-d data? I am not saying this is impossible, but I'd rather expect a larger part of the problem in the 99 other pages the are not drawn yet touched in update. Andre'
Re: Command buffer
On Tue, Apr 13, 2004 at 06:09:27PM +0200, Andre Poenitz wrote: > So, if I understand correctly, the argument goes as follows. > > - nobody but a few knew of the command line > - so we separated it from the status display to make them more visible > - now it takes too much space > - so we hide it No, the argument goes as follows: - all else being equal, the thing should be separate from the status bar for reasons I have given a long time ago - both the status bar and the command line take up valuable real estate - the status bar cannot and should not be hidden - the command line is useful to a few (notable sub-category - developers) who can work out how to use it - ergo, the command line can be hidden by default > - People who did not know that there was a commandline won't know >it now, either. So this is a draw. Correct. > - People who did know of the commandline are divided into two groups: >+ those who will find the hidden commandline (giving almost a draw) > and >+ people who knew the commandline but won't find it anymore (clearly > worse) Correct (see below). You managed to leave out: + people will recognise the Qt status bar *as* a status bar - it's painted like one, and it looks like one. And yes, this matters - I've seen user queries on this issue before on the users list (since your metric seems to be "did anybody complain?") Now, onto what we really want, namely: o minimal screen estate wasted by default o standardised widgets in the standardised places with the standardised look o a way for "power users" (a terrible phrase) to easily enter commands Currently, we can improve the last case. In particular: o Add a View->Toolbars->[ ] Command Line (or whatever) o Angus's M-x This supports both discoverability for new users and convenience for existing ones. > Actually, I'd don't believe anybody that used to use the commandline has > a problem with it 'abuse' as status bar. At least vi does exactly the same. We are not vi, or emacs. regards john
[patch]: re-enable previews for mathed.
I moved the 'connect' stuff inside the preview code, so the
MathHullInset doesn't look too bad.
Committing now...
--
AngusIndex: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.1893
diff -u -p -r1.1893 ChangeLog
--- src/ChangeLog 13 Apr 2004 13:10:32 - 1.1893
+++ src/ChangeLog 13 Apr 2004 17:33:44 -
@@ -1,5 +1,10 @@
2004-04-13 Angus Leeming <[EMAIL PROTECTED]>
+ * text3.C (dispatch): call Inset::.notifyCursorLeaves when the
+ cursor is clicked out of an inset.
+
+2004-04-13 Angus Leeming <[EMAIL PROTECTED]>
+
* lyx_main.[Ch] (updateInset): pass it an InsetBase pointer rather
than an InsetOld one.
Index: src/text3.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text3.C,v
retrieving revision 1.248
diff -u -p -r1.248 text3.C
--- src/text3.C 13 Apr 2004 06:27:28 - 1.248
+++ src/text3.C 13 Apr 2004 17:33:45 -
@@ -1148,6 +1148,10 @@ void LyXText::dispatch(LCursor & cur, Fu
finishUndo();
cur.x_target() = cursorX(cur.top());
+ // Has the cursor just left the inset?
+ if (bv->cursor().inMathed() && !cur.inMathed())
+ bv->cursor().inset().notifyCursorLeaves(bv->cursor());
+
// Set cursor here.
bv->cursor() = cur;
Index: src/mathed/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/ChangeLog,v
retrieving revision 1.420
diff -u -p -r1.420 ChangeLog
--- src/mathed/ChangeLog 5 Apr 2004 14:01:29 - 1.420
+++ src/mathed/ChangeLog 13 Apr 2004 17:33:48 -
@@ -1,3 +1,12 @@
+2004-04-13 Angus Leeming <[EMAIL PROTECTED]>
+
+ * math_hullinset.[Ch]: add a RenderPreview variable.
+ (copy c-tor, copy assignment operator, d-tor, notifyCursorLeaves,
+ addPreview): new member functions. The copy c-tor and assignment op
+ could be replaced by the compiler-generated defaults if preview_
+ was stored as a RenderPreview var rather than a scoped pointer.
+ (metrics, draw): use the preview renderer if previewing is turned on.
+
2004-04-05 Angus Leeming <[EMAIL PROTECTED]>
* math_scriptinset.C (up, down, notifyCursorLeaves): ensure that
Index: src/mathed/math_hullinset.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_hullinset.C,v
retrieving revision 1.132
diff -u -p -r1.132 math_hullinset.C
--- src/mathed/math_hullinset.C 13 Apr 2004 06:27:28 - 1.132
+++ src/mathed/math_hullinset.C 13 Apr 2004 17:33:49 -
@@ -26,15 +26,22 @@
#include "gettext.h"
#include "LaTeXFeatures.h"
#include "LColor.h"
+#include "lyx_main.h"
#include "lyxrc.h"
#include "outputparams.h"
#include "textpainter.h"
#include "undo.h"
+#include "insets/render_preview.h"
+
#include "frontends/Alert.h"
+#include "graphics/PreviewLoader.h"
+
#include "support/std_sstream.h"
+#include
+
using std::endl;
using std::max;
@@ -114,7 +121,8 @@ namespace {
MathHullInset::MathHullInset()
- : MathGridInset(1, 1), type_("none"), nonum_(1), label_(1)
+ : MathGridInset(1, 1), type_("none"), nonum_(1), label_(1),
+ preview_(new RenderPreview(this))
{
//lyxerr << "sizeof MathInset: " << sizeof(MathInset) << endl;
//lyxerr << "sizeof MetricsInfo: " << sizeof(MetricsInfo) << endl;
@@ -125,18 +133,42 @@ MathHullInset::MathHullInset()
MathHullInset::MathHullInset(string const & type)
- : MathGridInset(getCols(type), 1), type_(type), nonum_(1), label_(1)
+ : MathGridInset(getCols(type), 1), type_(type), nonum_(1), label_(1),
+ preview_(new RenderPreview(this))
{
setDefaults();
}
+MathHullInset::MathHullInset(MathHullInset const & other)
+ : MathGridInset(other),
+ type_(other.type_), nonum_(other.nonum_), label_(other.label_),
+ preview_(new RenderPreview(this))
+{}
+
+
+MathHullInset::~MathHullInset()
+{}
+
+
auto_ptr MathHullInset::clone() const
{
return auto_ptr(new MathHullInset(*this));
}
+void MathHullInset::operator=(MathHullInset const & other)
+{
+ if (this == )
+ return;
+ *static_cast(this) = MathGridInset(other);
+ type_ = other.type_;
+ nonum_ = other.nonum_;
+ label_ = other.label_;
+ preview_.reset(new RenderPreview(*other.preview_, this));
+}
+
+
MathInset::mode_type MathHullInset::currentMode() const
{
if (type_ == "none")
@@ -194,6 +226,20 @@ char const * MathHullInset::standardFont
void MathHullInset::metrics(MetricsInfo & mi, Dimension & dim) const
{
+ bool const use_preview = (!editing(mi.base.bv) &&
+ RenderPreview::activated() &&
+ preview_->previewReady());
+
+ if (use_preview) {
+ preview_->metrics(mi, dim);
+ // insert a one pixel gap in front of the formula
+ dim.wid += 1;
+ if (display())
+ dim.des += 12;
+ dim_ = dim;
+ return;
+ }
+
FontSetChanger dummy1(mi.base, standardFont());
StyleChanger dummy2(mi.base, display() ? LM_ST_DISPLAY : LM_ST_TEXT);
Collapsable insets *still* extending beyond the rh margin
Alfredo, I thought that you'd fixed this one? -- Angus<>
Re: macros
Andre Poenitz wrote: > I'll try to create a diff and attach this to this mail, would be > nice if someone could attach it to one of the macor related bugs on > bugzilla lest it gets lost. Ok, this is down attached to bug #1552. -- Angus
Re: Collapsable insets *still* extending beyond the rh margin
Angus Leeming wrote: > Alfredo, I thought that you'd fixed this one? No. We never decided really what to do. Alfredo
Re: update
Andre Poenitz wrote: >> ...but this has nothing to do with "editing slowdown"... > > But with e.g. buffer loading and buffer switching? [Not sure here, don't > have the sources at hand] Probably, I agree. >> So: I may agree that its a reasonable change (I even remember proposing >> something along the lines last year), but I don't think we are solving >> any performance problem... > > So you claim that the only reason of the perceived cursor-right > performance problem is redrawing a single full screen full of 2-d data? > > I am not saying this is impossible, but I'd rather expect a larger part > of the problem in the 99 other pages the are not drawn yet touched in > update. 1) Just uncomment the code you have commented out in selHandle and try cursor right. There is at least one call to updateParPositions (called from fitCursor -> redoParagraph -> updateParPositions) for every movement. Compare with cvs. (I've used UserGuide4 which I think is quite larger than Kayvan's document) 2) updateParPositions is the lightest immaginable O(n) algorithm. If we are going to have O(n) in updateCounters and the macro stuff, it will be with a much larger constant... 3) what happened to the "O(n) per user interaction is ok" karma? I've never agreed completely, but I would expect at least to follow it yoursef :-P Alfredo
