Re: [Bug 3974] crash with user defined external templates
Bernhard Roider wrote: ... We have to decide what is our policy for handling stuff in system dir vs stuff in .lyx. We cannot decide file by file whether in one case the system version is read, but not in the other. The behaviour should be predictable. ... So what's the opinion now? JMarc? Others? Again, my opinion is that your patch does the right thing (preference of user_lyxdir over build_lyxdir over system_lyxdir). Any objections? If not, I'd say put your fix in branch and trunk. Jürgen
Re: 1.5.X patch candidates - next iteration
Jürgen Spitzmüller wrote: I'll comment only on those that I haven't approved last time. http://www.lyx.org/trac/changeset/20016 - optimization: avoid some font copying http://www.lyx.org/trac/changeset/20021 - enable some non-rtl optimization Alfredo asked for some expert review. After that, it can go in. (I've already approved that) They are safe IMHO. New --- http://www.lyx.org/trac/changeset/19867 - InsetCollapsable::setStatus(): remove the Buffer::changed() signal emission Already approved last time ... Yes, I know I promised to do that last time but I was waiting for my other patch to be committed. I'll try to backport it but this just a cosmetics change for branch, nothing critical. http://www.lyx.org/trac/changeset/19919 - Fix DEPM crash within inset. always clear the full text_metrics_ when doing a full update. Applicable to branch? In theory yes but this will have side effects within insets. OTOH, that may solve some of the not easily reproducible crashes that have been reported. http://www.lyx.org/trac/changeset/20102 - Fix y co-ordinate for Conglomerate-style inset http://www.lyx.org/trac/changeset/20103 - y-coord in Conglomerate, this time properly Not applicable to branch, I think. Remove both. Right. http://www.lyx.org/trac/changeset/20159 - remove recursive call Hm. Peter, is this something for branch? No. http://www.lyx.org/trac/changeset/20081 - TextMetrics::drawSelection(): use parMetrics() instead of direct access just in case. Should fix crash on selection with PageUp Abdel? No. http://www.lyx.org/trac/changeset/20082 - Fix drawing of collapsable inset without button. Not applicable to branch, I think. Remove. Right. http://www.lyx.org/trac/changeset/20083 - Fix alignment of text within insets. http://www.lyx.org/trac/changeset/20101 - Nicely align inset buttons with surrounding text. http://www.lyx.org/trac/changeset/20142 - Restore docked View source widget. http://www.lyx.org/trac/changeset/20143 - fix view source window title. http://www.lyx.org/trac/changeset/20144 - oups... http://www.lyx.org/trac/changeset/20146 - Dialog::name() is not really needed. http://www.lyx.org/trac/changeset/20147 - Restore docked outline widget. Warning: still instable! http://www.lyx.org/trac/changeset/20177 - TextMetrics::draw(): withdraw first row ascent before drawing because the convention is that the baseline of a multirow text is the baseline of the first row. http://www.lyx.org/trac/changeset/20178 - fix outline dialog for non-Mac platform. All not applicable to branch, I think. Remove. And right. Abdel.
Re: r20205 - /lyx-devel/branches/BRANCH_1_5_X/src/frontends/q...
[EMAIL PROTECTED] wrote: Author: spitz Date: Tue Sep 11 08:21:53 2007 New Revision: 20205 Thanks! URL: http://www.lyx.org/trac/changeset/20205 Log: Backport revision 19747: * src/frontends/qt4/GuiView.h: - Delete include of config.h. This was needed only for the qt3 port. Modified: lyx-devel/branches/BRANCH_1_5_X/src/frontends/qt4/GuiView.h Modified: lyx-devel/branches/BRANCH_1_5_X/src/frontends/qt4/GuiView.h URL: http://www.lyx.org/trac/file/lyx-devel/branches/BRANCH_1_5_X/src/frontends/qt4/GuiView.h?rev=20205 == --- lyx-devel/branches/BRANCH_1_5_X/src/frontends/qt4/GuiView.h (original) +++ lyx-devel/branches/BRANCH_1_5_X/src/frontends/qt4/GuiView.h Tue Sep 11 08:21:53 2007 @@ -14,9 +14,6 @@ #ifndef GUI_VIEW_H #define GUI_VIEW_H - -// Must be here because of moc. -#include config.h #include frontends/LyXView.h #include FuncRequest.h
Re: 1.5.X patch candidates - next iteration
Michael Gerz wrote: http://www.lyx.org/trac/changeset/19473 - more verbose message I have backported this now http://www.lyx.org/trac/changeset/19747 - Delete include of config.h. This was needed only for the qt3 port. an this. Jürgen
Re: r20202 [1/2] - in /lyx-devel/trunk/src/frontends: Dialogs...
[EMAIL PROTECTED] wrote:
Author: poenitz
Date: Tue Sep 11 00:32:59 2007
New Revision: 20202
URL: http://www.lyx.org/trac/changeset/20202
Log:
shuffle some frontend stuff around. merge controller(base) and Kernel. Make
frontend::Dialog pure virtual
Good move. I think you should also move Dialog.{cpp,h} to frontends/
Abdel.
Re: 1.5.X patch candidates - next iteration
Abdelrazak Younes wrote: http://www.lyx.org/trac/changeset/20016 - optimization: avoid some font copying http://www.lyx.org/trac/changeset/20021 - enable some non-rtl optimization Alfredo asked for some expert review. After that, it can go in. (I've already approved that) They are safe IMHO. Good. Alfredo, you can apply then. http://www.lyx.org/trac/changeset/19867 - InsetCollapsable::setStatus(): remove the Buffer::changed() signal emission Already approved last time ... Yes, I know I promised to do that last time but I was waiting for my other patch to be committed. I'll try to backport it but this just a cosmetics change for branch, nothing critical. Just to keep track, here are the fixes you still need to backport (and have OK to do so). No need to hurry, though: http://www.lyx.org/trac/changeset/19638 - redoParagraph() simplify the changed calculation http://www.lyx.org/trac/changeset/19868 - TextMetrics::redoParagraph(): we need to check the returned value of Inset::metrics() http://www.lyx.org/trac/changeset/19838 - Bug fix: correctly redraw a Row containing and inset which Dimension slightly changed http://www.lyx.org/trac/changeset/19867 - InsetCollapsable::setStatus(): remove the Buffer::changed() signal emission http://www.lyx.org/trac/changeset/19919 - Fix DEPM crash within inset. always clear the full text_metrics_ when doing a full update. Applicable to branch? In theory yes but this will have side effects within insets. What kind of side effects? OTOH, that may solve some of the not easily reproducible crashes that have been reported. Which ones? Jürgen
Re: Fwd: [Bug 4173] Middle-button paste between apps sometimes uses old selection.
On Mon, 2007-09-10 at 17:16 +0200, Jürgen Spitzmüller wrote: Jean-Marc Lasgouttes wrote: I am not sure which of your patches has not been put to branch, could you take care of this? I thought all patches were on the branch, and I am not sure what problems are remaining, actually. I'm not sure either, but I remember Darren reported that there are still unresolved issues. Darren? There is a patch floating around which still applies cleanly. I just haven't had a chance to verify the corner cases. Please go on without me :) Make sure it's in branch. Have fun, Darren
Re: Fwd: [Bug 4173] Middle-button paste between apps sometimes uses old selection.
Darren Freeman wrote: There is a patch floating around which still applies cleanly. I just haven't had a chance to verify the corner cases. Please go on without me :) Make sure it's in branch. It turned out this patch was superseded by some alternative approach. Jürgen
Re: 1.5.X patch candidates - next iteration
Jürgen Spitzmüller wrote: Abdelrazak Younes wrote: http://www.lyx.org/trac/changeset/19919 - Fix DEPM crash within inset. always clear the full text_metrics_ when doing a full update. Applicable to branch? In theory yes but this will have side effects within insets. What kind of side effects? I am not sure... maybe crashes, maybe cleared out text... In trunk, the only side effect (besides fixing the DEPM crash) was that I had to force full repaint in tabular cells. But a full repaint occurred anyway so no harm done. I'll tell you what, I'll produce a patch and let you test it and decide if it is safe or not. OTOH, that may solve some of the not easily reproducible crashes that have been reported. Which ones? Bo reported some crash IIRC. There were also problems with cursor positioning in table IIRC that may be solved by this. Abdel.
[patch] Re: Upgrading boost in branch
Jürgen Spitzmüller wrote: Does anybody feel confident enough to do this task? I'm a bit reluctant doing this myself. Since nobody stepped forward, I had a go myself and just copied the boost directory just after Lars' update in rev. 19398 (Update to latest from boost 1.34.x branch) to branch. Attached is what I came up with. Compiles fine here and looks sensible, AFAICT. Have I missed something obvious? If not I'm gonna commit that. Jürgen boost.diff.gz Description: GNU Zip compressed data
Re: 1.5.X patch candidates - next iteration
On Tue, 11 Sep 2007 07:58:09 +0200 [EMAIL PROTECTED] (Jürgen Spitzmüller) wrote: http://www.lyx.org/trac/changeset/20104 - Better error signaling Not applicable, I think. Martin? Not relevant, relates to inset configurability which is not in 1.5 - Martin
Re: [Patch] partial support for units
On Tue, 11 Sep 2007 08:15:11 +0300
Martin Vermeer [EMAIL PROTECTED] wrote:
On Mon, Sep 10, 2007 at 10:42:32PM +0200, Andre Poenitz wrote:
On Mon, Sep 10, 2007 at 10:44:01PM +0300, Martin Vermeer wrote:
OK for trunk?
Here's a better one.
- Martin
Index: src/mathed/InsetMathFrac.h
===
--- src/mathed/InsetMathFrac.h (revision 20193)
+++ src/mathed/InsetMathFrac.h (working copy)
@@ -27,7 +27,8 @@
FRAC,
OVER,
ATOP,
- NICEFRAC
+ NICEFRAC,
+ UNITFRAC
};
///
Index: src/mathed/MathFactory.cpp
===
--- src/mathed/MathFactory.cpp (revision 20193)
+++ src/mathed/MathFactory.cpp (working copy)
@@ -370,6 +370,8 @@
return MathAtom(new InsetMathFrac(InsetMathFrac::OVER));
if (s == nicefrac)
return MathAtom(new InsetMathFrac(InsetMathFrac::NICEFRAC));
+ if (s == unitfrac)
+ return MathAtom(new InsetMathFrac(InsetMathFrac::UNITFRAC));
//if (s == infer)
// return MathAtom(new MathInferInset);
if (s == atop)
Index: src/mathed/InsetMathFrac.cpp
===
--- src/mathed/InsetMathFrac.cpp (revision 20193)
+++ src/mathed/InsetMathFrac.cpp (working copy)
@@ -48,9 +48,11 @@
bool InsetMathFrac::metrics(MetricsInfo mi, Dimension dim) const
{
FracChanger dummy(mi.base);
+ if (kind_ == UNITFRAC)
+ ShapeChanger dummy2(mi.base.font, Font::UP_SHAPE);
cell(0).metrics(mi);
cell(1).metrics(mi);
- if (kind_ == NICEFRAC) {
+ if (kind_ == NICEFRAC || kind_ == UNITFRAC) {
dim.wid = cell(0).width() + cell(1).width() + 5;
dim.asc = cell(0).height() + 5;
dim.des = cell(1).height() - 5;
@@ -72,7 +74,9 @@
setPosCache(pi, x, y);
int m = x + dim_.wid / 2;
FracChanger dummy(pi.base);
- if (kind_ == NICEFRAC) {
+ if (kind_ == UNITFRAC)
+ ShapeChanger dummy2(pi.base.font, Font::UP_SHAPE);
+ if (kind_ == NICEFRAC || kind_ == UNITFRAC) {
cell(0).draw(pi, x + 2,
y - cell(0).descent() - 5);
cell(1).draw(pi, x + cell(0).width() + 5,
@@ -111,7 +115,7 @@
cell(0).drawT(pain, m - cell(0).width() / 2, y - cell(0).descent() - 1);
cell(1).drawT(pain, m - cell(1).width() / 2, y + cell(1).ascent());
// ASCII art: ignore niceties
- if (kind_ == FRAC || kind_ == OVER || kind_ == NICEFRAC)
+ if (kind_ == FRAC || kind_ == OVER || kind_ == NICEFRAC || kind_ == UNITFRAC)
pain.horizontalLine(x, y, dim_.width());
}
@@ -128,6 +132,7 @@
break;
case FRAC:
case NICEFRAC:
+ case UNITFRAC:
InsetMathNest::write(os);
break;
}
@@ -143,6 +148,8 @@
return from_ascii(over);
case NICEFRAC:
return from_ascii(nicefrac);
+ case UNITFRAC:
+ return from_ascii(unitfrac);
case ATOP:
return from_ascii(atop);
}
@@ -183,8 +190,8 @@
void InsetMathFrac::validate(LaTeXFeatures features) const
{
- if (kind_ == NICEFRAC)
- features.require(nicefrac);
+ if (kind == NICEFRAC || kind_ == UNITFRAC)
+ features.require(units);
InsetMathNest::validate(features);
}
Index: src/LaTeXFeatures.cpp
===
--- src/LaTeXFeatures.cpp (revision 20193)
+++ src/LaTeXFeatures.cpp (working copy)
@@ -405,7 +405,7 @@
dvipost,
fancybox,
calc,
- nicefrac,
+ units,
tipa,
framed,
pdfcolmk,
Index: lib/ui/stdtoolbars.inc
===
--- lib/ui/stdtoolbars.inc (revision 20175)
+++ lib/ui/stdtoolbars.inc (working copy)
@@ -273,7 +273,8 @@
Toolbar frac-square Fractions
Item Standard \\frac math-insert \frac
Item No hor. line \\atop math-insert \atop
- Item Nice \\nicefrac math-insert \nicefrac
+ Item Nice (3/4) \\nicefrac math-insert \nicefrac
+ Item Units (km/h) \\unitfrac math-insert \unitfrac
Item Text frac (amsmath) \\tfrac math-insert \tfrac
Item Display frac (amsmath) \\dfrac math-insert \dfrac
Item Binomial \\choose math-insert \choose
Re: [PATCH[ New LFUN: layout-reload
Richard Heck [EMAIL PROTECTED] writes: Oh, it's not as bad as that, really. If the layout file can't be read, LyX will switch to something else, like Article (SGML), which is kind of a hassle. But it's not a critical error, and anyone who's editing their layouts shouldn't simultaneously be doing any serious work. So there isn't any real risk, I think, of data loss, and an appropriate warning could be issued. That said, since we do have a Save All... LFUN (we do now, right?) that could simply be called right before layout-reload does its actual work. I am not sure I understand how it works: each paragraph has a Layout pointer, right? How is this kept working after reloading the class? JMarc
Re: 1.5.X patch candidates - next iteration
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes: Michael Gerz wrote: http://www.lyx.org/trac/changeset/19473 - more verbose message I have backported this now What happened to using documentation for such large explanations? Somebody thinks that configure --help is not unreadable enough? ;) Seriously, all help message would be candidate for the ame obfuscation. I do not really understand why boost has this special treatment. JMarc
Re: [Embedding PATCH] Add manifest to .lyx file itself.
On Monday 10 September 2007 19:58:29 Bo Peng wrote: Latest patch attached. Can I apply? OK. Cheers, Bo -- José Abílio
Re: [Bug 3974] crash with user defined external templates
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes: Again, my opinion is that your patch does the right thing (preference of user_lyxdir over build_lyxdir over system_lyxdir). Any objections? If not, I'd say put your fix in branch and trunk. I lost the patch. Where is it? JMarc
Re: [Bug 3974] crash with user defined external templates
Jean-Marc Lasgouttes wrote: I lost the patch. Where is it? http://bugzilla.lyx.org/attachment.cgi?id=1959action=view Jürgen
Re: lyx2lyx or toc building is broken after user's guide update.
On Sunday 09 September 2007 17:15:28 Bo Peng wrote: One of the problems is the title Índice general LyX documentation can not be encoded at line 279 of LyX.py. This should be a unicode string. I changed all strings in that position to be unicode even although only the Spanish (for the moment) needs that distinction. In python a unicode string is a string that starts with an u. :-) Example: uOlá In python 3.0+ this distinction will disappear in the sense that all strings will be unicode. :-) I will commit the fix to trunk. Bo -- José Abílio
Re: 1.5.X patch candidates - next iteration
On Monday 10 September 2007 21:30:11 Uwe Stöhr wrote: http://www.lyx.org/trac/changeset/20173 - doc_toc.py: remove non-ascii character since LyX.py can't encode it at the moment This is not a fix but a workaround. This problem was trunk only. doc_toc.py is nevertheless broken in trunk and branch when handling non-ascii characters. Fixed in http://www.lyx.org/trac/changeset/20207 regards Uwe -- José Abílio
Re: 1.5.X patch candidates - next iteration
José Matos wrote: doc_toc.py is nevertheless broken in trunk and branch when handling non-ascii characters. Fixed in http://www.lyx.org/trac/changeset/20207 How about branch? Jürgen
Re: 1.5.X patch candidates - next iteration
On Tuesday 11 September 2007 10:11:58 Jürgen Spitzmüller wrote: How about branch? The change is safe may I apply it to the stable branch? Jürgen -- José Abílio
Figure scaling in LyX display
Hi all, how does LyX know how to scale an EPS figure when viewing it on-screen? It's set to 100% and on my 16cm wide figure, it's more like 12.5cm. I'm used to my 16cm-wide PNG figures requiring a 30% scaling in the LyX display to end up with something much bigger. My display is 90DPI according to my calibration in Gimp. So it could be rendering at 70DPI by default and displaying 1:1 pixel wise. Or is it the PNG which displays wrong? They were 600DPI and if the figure size matadata were being ignored, instead using 1:1 pixel scaling, it would be huge and require scaling in LyX. Have fun, Darren
Re: 1.5.X patch candidates - next iteration
José Matos wrote: The change is safe may I apply it to the stable branch? Yes, please. Jürgen
Re: [Bug 3974] crash with user defined external templates
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes: Jean-Marc Lasgouttes wrote: I lost the patch. Where is it? http://bugzilla.lyx.org/attachment.cgi?id=1959action=view I have not see this patch before actually. Does the new libFileSearch have to build a vectorpair? We do not really care about user_lyxdir and such identifiers, IMO. If we insist on keeping this, a mapstring, FileName would make more sense. Other than that, this new function looks useful. So the new behaviour would be to merge the three template files (BTW, I am not sure the notion of build_dir is useful anymore, but this is a separate discussion). The code as it is written makes sense, but I do not like outputting error messages to the console. They should be turned into debug messages (if we keep them). Instead we could mark in the GUI where each template comes from. JMarc
Re: Figure scaling in LyX display
Darren Freeman [EMAIL PROTECTED] writes: Hi all, how does LyX know how to scale an EPS figure when viewing it on-screen? It's set to 100% and on my 16cm wide figure, it's more like 12.5cm. I'm used to my 16cm-wide PNG figures requiring a 30% scaling in the LyX display to end up with something much bigger. What DPI and zoom setting do you have in preferences? JMarc
Re: 1.5.X patch candidates - next iteration
On Tuesday 11 September 2007 10:31:55 Jürgen Spitzmüller wrote: Yes, please. Done. http://www.lyx.org/trac/changeset/20210 If other title translations are added to doc_toc.py that should be reported in status.15x. This patch is just an internal fix and since this does not change any output, I have not filled any new entry to status.15x. I hope this is OK. :-) Jürgen -- José Abílio
Re: 1.5.X patch candidates - next iteration
José Matos wrote: If other title translations are added to doc_toc.py that should be reported in status.15x. This patch is just an internal fix and since this does not change any output, I have not filled any new entry to status.15x. I hope this is OK. :-) Fine with me. Jürgen
Re: Notifying users during long tasks.
Tommaso Cucinotta wrote: Hi all, I'd like to know what is the most suitable way to notify users of the progress made during possibly long tasks, in LyX. The standard way would be to create a new thread, so to exit the Qt callback that started the long task, adding a progress bar or similar and updating it periodically, and a Cancel button that allows to stop the batch activity. Is there any reusable LyX component/code snippet for managing such situations ? If you di this - please make that a progress bar (or similiar) inside the main window - _not_ a popup thing. :-) Helge Hafting
Re: Idea: print via PDF preference
Helge Hafting wrote: Good idea, if only for print as file. I definitely meant print to printer, not print to file. Those who want a file can still use File-export-pdflatex. Why? We have print to file, which should provide at least these two options. (else, we should get rid of print to file completely). Not only is this noticeably faster, but it also support printing documents using the microtype package. Modern LaTeX distributions use pdflatex also for DVI output. Nice - that means the problem will go away. But what latex distributions are considered new? I am using texlive from debian unstable, which is usually recent enough. TeXLive 2007 has it, I think teTeX 3 as well. I can't remember when the change happened. Still, view-pdf and view-dvi comes up different when microtype is in use. I think some microtypographic features are disabled in pdftex's dvi mode. Jürgen
Re: question about PATH prefix under Linux and Mac
Richard Heck schrieb: On Linux, I would say something like the following: On *nix systems, the PATH will need to be set only if there are external programs you wish to use that are not in your normal system path ($PATH). Thanks for the infos, I'll add this today. regards Uwe
Re: 1.5.X patch candidates - next iteration
Fixed in http://www.lyx.org/trac/changeset/20207 thanks Uwe
Re: Compiling with --enable-shared leads to errors.
On Friday 07 September 2007 21:37:33 Tommaso Cucinotta wrote: Hi all, when compiling with --enable-shared (that would seem a good switch to enable at a first glance), On Linux yes, on other systems no. We tried this last month and result was not good. And, you know, not being able to compile is not the way to ask people test the new versions. linking fails due to a double inclusion of Dialog.o. Details follow (version from SVN). T. OK, after André last fix it works now. The next problem is due to the fact that I am compiling using share and without included boost. Make fails in the end by not linking with boost. (I am using the autotools*) I can improved the situation by adding -lboost_regex and -lboost_filesystem I get this: g++ -g -O -o .libs/lyx main.o ASpell.o ISpell.o SpellBase.o Box.o Dimension.o PrinterParams.o Thesaurus.o ./.libs/liblyxcore.so ./.libs/liblyxmathed.so ./.libs/liblyxinsets.so frontends/.libs/liblyxfrontends.so frontends/qt4/.libs/liblyxqt4.so -L/usr/X11R6/lib frontends/controllers/.libs/liblyxcontrollers.so ./.libs/liblyxgraphics.so support/.libs/liblyxsupport.so -lboost_signals -lAiksaurus -laspell -lSM -lICE -lz -lX11 -lQtGui -lQtCore -lboost_regex-mt -lboost_filesystem-mt -Wl,--rpath -Wl,/usr/local/lib/lyx-1.6.0svn /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libboost_regex-mt.so: undefined reference to `u_digit_3_7' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libboost_regex-mt.so: undefined reference to `u_isblank_3_7' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libboost_regex-mt.so: undefined reference to `u_isspace_3_7' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libboost_regex-mt.so: undefined reference to `u_tolower_3_7' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libboost_regex-mt.so: undefined reference to `u_charFromName_3_7' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libboost_regex-mt.so: undefined reference to `u_charType_3_7' collect2: ld returned 1 exit status -- José Abílio
ERT in title bug
In my title I tried to insert:
Revision ERT{\input{build_id}}
On the screen, it says: \INPUT{BUILD_ID}
because I'm using ams art, and title is caps.
I chose 'view source', it says:
\title{SCMA Design Document\\
Revision \input{build_id}}
\maketitle
OK, fine. Just a screen buglet. Wait, no!
lyx --export pdf file
! LaTeX Error: File `BUILD_ID.tex' not found.
Ouch!
Re: Notifying users during long tasks.
Helge Hafting ha scritto: If you di this - please make that a progress bar (or similiar) inside the main window - _not_ a popup thing. :-) Ok, guess smth. besides (or embedded into) the status bar. Despite the appearence, I guess the main problem is that LyX has a single thread design. So, if you have a long activity to be run externally to the current doc (let's say compiling a LaTeX/PS/PDF), it is safe to let the user keep modifying the doc. On the other hand, if the activity needs access to the doc, user activities should be inhibited (this is perfectly done by a very long Gui callback, even though it is not good to see), but at least there should be a way to cancel it if the user wants so (and this is not doable from within a long Gui callback). The best support for external (potentially long) activities I've ever seen within applications is the one of Eclipse, where user may even start or enqueue multiple activities, the system keeps track of dependencies among them, if any, and a progress dockable window may always be popped up by the user so to see what is not done yet and the state of advance of each activity. At last, if the user makes an operation that requires one of the activities to complete, then the user interaction is blocked until completition of that activity. But probably, I don't want to use a cannon to shoot to a fly. T. -- Tommaso Cucinotta, Computer Engineering PhD, Researcher ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy Tel +39 050 882 024, Fax +39 050 882 003 http://feanor.sssup.it/~tommaso
Re: ERT in title bug
Neal Becker wrote:
In my title I tried to insert:
Revision ERT{\input{build_id}}
On the screen, it says: \INPUT{BUILD_ID}
because I'm using ams art, and title is caps.
I chose 'view source', it says:
\title{SCMA Design Document\\
Revision \input{build_id}}
\maketitle
OK, fine. Just a screen buglet. Wait, no!
lyx --export pdf file
! LaTeX Error: File `BUILD_ID.tex' not found.
With ERT, you're on your own.
Try ERT{\MakeLowercase{\input{build_id}}}
Jürgen
Re: Notifying users during long tasks.
Tommaso Cucinotta wrote: Helge Hafting ha scritto: If you di this - please make that a progress bar (or similiar) inside the main window - _not_ a popup thing. :-) Ok, guess smth. besides (or embedded into) the status bar. Despite the appearence, I guess the main problem is that LyX has a single thread design. Yes, and this doesn't have to change to do what you envision. I had once a patch that used the forkedcall mechanism that is used for graphics conversion (and for instant preview). As you probably know, graphics are converted asynchronously before they are shown on screen. I had once a patch that did exactly that but I can't seem to find it :-( So, if you have a long activity to be run externally to the current doc (let's say compiling a LaTeX/PS/PDF), it is safe to let the user keep modifying the doc. On the other hand, if the activity needs access to the doc, user activities should be inhibited (this is perfectly done by a very long Gui callback, even though it is not good to see), No, only the export to latex needs be synchronous because this is done by LyX itself; all other conversion can be asynchronous. Abdel.
Re: Notifying users during long tasks.
Abdelrazak Younes ha scritto: Yes, and this doesn't have to change to do what you envision. I had once a patch that used the forkedcall mechanism that is used for graphics conversion (and for instant preview). As you probably know, graphics are converted asynchronously before they are shown on screen. I had once a patch that did exactly that but I can't seem to find it :-( Ok, infact the mechanism needs to be similar. Where are the points in the code where the graphics displaying activities are started and terminated/joined ? T. -- Tommaso Cucinotta, Computer Engineering PhD, Researcher ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy Tel +39 050 882 024, Fax +39 050 882 003 http://feanor.sssup.it/~tommaso
Re: 1.5.X patch candidates - next iteration
Jürgen Spitzmüller [EMAIL PROTECTED] writes: Alfredo asked for some expert review. After that, it can go in. (I've already approved that) They are safe IMHO. Good. Alfredo, you can apply then. Err, these went in some days ago (you said ok if IMO they were safe). So, in already. A/
Re: [PATCH[ New LFUN: layout-reload
Jean-Marc Lasgouttes wrote: Richard Heck [EMAIL PROTECTED] writes: Oh, it's not as bad as that, really. If the layout file can't be read, LyX will switch to something else, like Article (SGML), which is kind of a hassle. But it's not a critical error, and anyone who's editing their layouts shouldn't simultaneously be doing any serious work. So there isn't any real risk, I think, of data loss, and an appropriate warning could be issued. That said, since we do have a Save All... LFUN (we do now, right?) that could simply be called right before layout-reload does its actual work. I am not sure I understand how it works: each paragraph has a Layout pointer, right? How is this kept working after reloading the class? Whenever we reload the class, we do the update layout routine from CutAndPaste, which is what is used for any change of classes. So basically we're treating layout reload like change of class. The same thing gets done on loading of modules. So, basically, if the layout file can't be read, then you get switched to some other document class. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [Patch] partial support for units
On Tue, 11 Sep 2007 10:50:56 +0300
Martin Vermeer [EMAIL PROTECTED] wrote:
On Tue, 11 Sep 2007 08:15:11 +0300
Martin Vermeer [EMAIL PROTECTED] wrote:
On Mon, Sep 10, 2007 at 10:42:32PM +0200, Andre Poenitz wrote:
On Mon, Sep 10, 2007 at 10:44:01PM +0300, Martin Vermeer wrote:
OK for trunk?
Here's a better one.
- Martin
Grmf. Not my day. Here is one that actually, verifiedly, works (and not
only for a units fraction).
- Martin
Index: src/mathed/InsetMathFrac.h
===
--- src/mathed/InsetMathFrac.h (revision 20193)
+++ src/mathed/InsetMathFrac.h (working copy)
@@ -27,7 +27,8 @@
FRAC,
OVER,
ATOP,
- NICEFRAC
+ NICEFRAC,
+ UNITFRAC
};
///
Index: src/mathed/MathFactory.cpp
===
--- src/mathed/MathFactory.cpp (revision 20193)
+++ src/mathed/MathFactory.cpp (working copy)
@@ -370,6 +370,8 @@
return MathAtom(new InsetMathFrac(InsetMathFrac::OVER));
if (s == nicefrac)
return MathAtom(new InsetMathFrac(InsetMathFrac::NICEFRAC));
+ if (s == unitfrac)
+ return MathAtom(new InsetMathFrac(InsetMathFrac::UNITFRAC));
//if (s == infer)
// return MathAtom(new MathInferInset);
if (s == atop)
Index: src/mathed/InsetMathFrac.cpp
===
--- src/mathed/InsetMathFrac.cpp (revision 20193)
+++ src/mathed/InsetMathFrac.cpp (working copy)
@@ -54,6 +54,11 @@
dim.wid = cell(0).width() + cell(1).width() + 5;
dim.asc = cell(0).height() + 5;
dim.des = cell(1).height() - 5;
+ } else if (kind_ == UNITFRAC) {
+ ShapeChanger dummy2(mi.base.font, Font::UP_SHAPE);
+ dim.wid = cell(0).width() + cell(1).width() + 5;
+ dim.asc = cell(0).height() + 5;
+ dim.des = cell(1).height() - 5;
} else {
dim.wid = std::max(cell(0).width(), cell(1).width()) + 2;
dim.asc = cell(0).height() + 2 + 5;
@@ -77,16 +82,24 @@
y - cell(0).descent() - 5);
cell(1).draw(pi, x + cell(0).width() + 5,
y + cell(1).ascent() / 2);
- pi.pain.line(x + cell(0).width(),
-y + dim_.des - 2,
-x + cell(0).width() + 5,
-y - dim_.asc + 2, Color::math);
+ } else if (kind_ == UNITFRAC) {
+ ShapeChanger dummy2(pi.base.font, Font::UP_SHAPE);
+ cell(0).draw(pi, x + 2,
+y - cell(0).descent() - 5);
+ cell(1).draw(pi, x + cell(0).width() + 5,
+y + cell(1).ascent() / 2);
} else {
cell(0).draw(pi, m - cell(0).width() / 2,
y - cell(0).descent() - 2 - 5);
cell(1).draw(pi, m - cell(1).width() / 2,
y + cell(1).ascent() + 2 - 5);
}
+ if (kind_ == NICEFRAC || kind_ == UNITFRAC) {
+ pi.pain.line(x + cell(0).width(),
+y + dim_.des - 2,
+x + cell(0).width() + 5,
+y - dim_.asc + 2, Color::math);
+ }
if (kind_ == FRAC || kind_ == OVER)
pi.pain.line(x + 1, y - 5,
x + dim_.wid - 2, y - 5, Color::math);
@@ -111,7 +124,7 @@
cell(0).drawT(pain, m - cell(0).width() / 2, y - cell(0).descent() - 1);
cell(1).drawT(pain, m - cell(1).width() / 2, y + cell(1).ascent());
// ASCII art: ignore niceties
- if (kind_ == FRAC || kind_ == OVER || kind_ == NICEFRAC)
+ if (kind_ == FRAC || kind_ == OVER || kind_ == NICEFRAC || kind_ == UNITFRAC)
pain.horizontalLine(x, y, dim_.width());
}
@@ -128,6 +141,7 @@
break;
case FRAC:
case NICEFRAC:
+ case UNITFRAC:
InsetMathNest::write(os);
break;
}
@@ -143,6 +157,8 @@
return from_ascii(over);
case NICEFRAC:
return from_ascii(nicefrac);
+ case UNITFRAC:
+ return from_ascii(unitfrac);
case ATOP:
return from_ascii(atop);
}
@@ -183,8 +199,8 @@
void InsetMathFrac::validate(LaTeXFeatures features) const
{
- if (kind_ == NICEFRAC)
- features.require(nicefrac);
+ if (kind_ == NICEFRAC || kind_ == UNITFRAC)
+ features.require(units);
InsetMathNest::validate(features);
}
Index: src/LaTeXFeatures.cpp
===
--- src/LaTeXFeatures.cpp (revision 20193)
+++ src/LaTeXFeatures.cpp (working copy)
@@ -405,7 +405,7 @@
dvipost,
fancybox,
calc,
- nicefrac,
+ units,
tipa,
framed,
pdfcolmk,
Index: lib/ui/stdtoolbars.inc
===
--- lib/ui/stdtoolbars.inc (revision 20175)
+++ lib/ui/stdtoolbars.inc (working copy)
@@ -273,7 +273,8 @@
Toolbar frac-square Fractions
Item Standard \\frac math-insert \frac
Item No hor. line \\atop math-insert \atop
- Item Nice \\nicefrac math-insert \nicefrac
+ Item Nice (3/4) \\nicefrac math-insert \nicefrac
+ Item Units (km/h) \\unitfrac math-insert \unitfrac
Item Text frac (amsmath) \\tfrac math-insert \tfrac
Item Display frac (amsmath) \\dfrac math-insert \dfrac
Item Binomial \\choose math-insert \choose
Re: 1.5.X patch candidates - next iteration
Alfredo Braunstein wrote: Good. Alfredo, you can apply then. Err, these went in some days ago (you said ok if IMO they were safe). So, in already. Right, I remember now. You really need to fix the mailing list issue ... Jürgen
bug in lyx 1.5.1? notation* environment in book (AMS) documentclass
Hi, is this a bug in lyx 1.5.1?
I checked on bugzilla.lyx.org but found nothing corresponding, so I
decided to post this to the developers list.
When I try to use the Notation*-environment within the book (AMS)
documentclass and want to view DVI, I get the following error message
from latex:
---
LaTeX Error: Missing \begin{document}
\newtheorem*{notation*}[t
hm]{Notation}
You're in trouble here. Try typing return to proceed.
If that doesn't work, type X return to quit.
---
Isn't just the counter argument [thm] too much for the *-environment
creator \newtheorem*?
By the way, I'm really a fan of lyx, and lyx 1.5.1 is just great. I like
especially the new sidebar for the contents menu, makes working with big
documents so much easier...
Greets
Kai
PS: Would be great if you could respond to ALL (including
[EMAIL PROTECTED]), cause I'm not a member of the list.
Re: [PATCH[ New LFUN: layout-reload
Richard Heck [EMAIL PROTECTED] writes: Whenever we reload the class, we do the update layout routine from CutAndPaste, which is what is used for any change of classes. So basically we're treating layout reload like change of class. The same thing gets done on loading of modules. So, basically, if the layout file can't be read, then you get switched to some other document class. I see. Thanks. JMarc
Re: r20202 [1/2] - in /lyx-devel/trunk/src/frontends: Dialogs...
On Tue, Sep 11, 2007 at 08:37:12AM +0200, Abdelrazak Younes wrote:
[EMAIL PROTECTED] wrote:
Author: poenitz
Date: Tue Sep 11 00:32:59 2007
New Revision: 20202
URL: http://www.lyx.org/trac/changeset/20202
Log:
shuffle some frontend stuff around. merge controller(base) and Kernel.
Make frontend::Dialog pure virtual
Good move. I think you should also move Dialog.{cpp,h} to frontends/
I am on the way...
Andre'
Re: [Patch] partial support for units
On Tue, Sep 11, 2007 at 10:50:56AM +0300, Martin Vermeer wrote:
Here's a better one.
Not really ;-)
Index: src/mathed/InsetMathFrac.cpp
===
--- src/mathed/InsetMathFrac.cpp (revision 20193)
+++ src/mathed/InsetMathFrac.cpp (working copy)
@@ -48,9 +48,11 @@
bool InsetMathFrac::metrics(MetricsInfo mi, Dimension dim) const
{
FracChanger dummy(mi.base);
+ if (kind_ == UNITFRAC)
+ ShapeChanger dummy2(mi.base.font, Font::UP_SHAPE);
cell(0).metrics(mi);
cell(1).metrics(mi);
The ShapeChanger changes the Shape back to the original state when it is
destructed, i.e. the end of its scope. In this particular piece of code
the scope of 'dummy2' is the 'if' branch, i.e. the shape will already be
restored before cell(0).metrics() is called.
I am not sure that changing the shape is needed at all. Is the resulting
metrics visually different?
If so, something like
bool InsetMathFrac::metrics(MetricsInfo mi, Dimension dim) const
{
FracChanger dummy(mi.base);
std::auto_ptrShapeChanger dummy2;
if (kind_ == UNITFRAC)
dummy2.reset(new ShapeChanger(mi.base.font, Font::UP_SHAPE));
cell(0).metrics(mi);
cell(1).metrics(mi);
might help. I this case the ShapeChanger will be destroyed at the
end of the function body.
Andre'
Re: bug in lyx 1.5.1? notation* environment in book (AMS) documentclass
Kai Johannes Keller wrote: When I try to use the Notation*-environment within the book (AMS) documentclass and want to view DVI, I get the following error message from latex: Thanks for the report, I added it here: http://bugzilla.lyx.org/show_bug.cgi?id=4078#c15 Jürgen
Re: Compiling with --enable-shared leads to errors.
On Tue, Sep 11, 2007 at 12:32:52PM +0100, José Matos wrote: On Friday 07 September 2007 21:37:33 Tommaso Cucinotta wrote: Hi all, when compiling with --enable-shared (that would seem a good switch to enable at a first glance), On Linux yes, on other systems no. We tried this last month and result was not good. And, you know, not being able to compile is not the way to ask people test the new versions. linking fails due to a double inclusion of Dialog.o. Details follow (version from SVN). T. OK, after André last fix it works now. The next problem is due to the fact that I am compiling using share and without included boost. Make fails in the end by not linking with boost. (I am using the autotools*) --enable-shared is for people that do not ask questions ;-) I can improved the situation by adding -lboost_regex and -lboost_filesystem I get this: g++ -g -O -o .libs/lyx main.o ASpell.o ISpell.o SpellBase.o Box.o Dimension.o PrinterParams.o Thesaurus.o ./.libs/liblyxcore.so ./.libs/liblyxmathed.so ./.libs/liblyxinsets.so frontends/.libs/liblyxfrontends.so frontends/qt4/.libs/liblyxqt4.so -L/usr/X11R6/lib frontends/controllers/.libs/liblyxcontrollers.so ./.libs/liblyxgraphics.so support/.libs/liblyxsupport.so -lboost_signals -lAiksaurus -laspell -lSM -lICE -lz -lX11 -lQtGui -lQtCore -lboost_regex-mt -lboost_filesystem-mt -Wl,--rpath -Wl,/usr/local/lib/lyx-1.6.0svn /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libboost_regex-mt.so: undefined reference to `u_digit_3_7' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libboost_regex-mt.so: undefined reference to `u_isblank_3_7' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libboost_regex-mt.so: undefined reference to `u_isspace_3_7' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libboost_regex-mt.so: undefined reference to `u_tolower_3_7' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libboost_regex-mt.so: undefined reference to `u_charFromName_3_7' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libboost_regex-mt.so: undefined reference to `u_charType_3_7' collect2: ld returned 1 exit status Do we use --without-included-boost regularily? Andre'
Re: bug in lyx 1.5.1? notation* environment in book (AMS) documentclass
Jürgen Spitzmüller wrote:
Thanks for the report, I added it here:
http://bugzilla.lyx.org/show_bug.cgi?id=4078#c15
The fix, btw, is simple. Just change in amsmaths.inc, here:
Style Notation*
CopyStyle Remark*
LatexName notation*
LabelString Notation.
Preamble
\theoremstyle{remark}
\newtheorem*{notation*}[thm]{Notation}
EndPreamble
End
the preamble definition to
Preamble
\theoremstyle{remark}
\newtheorem*{notation*}{Notation}
EndPreamble
Jürgen
Re: [Patch] partial support for units
Andre Poenitz [EMAIL PROTECTED] writes: The ShapeChanger changes the Shape back to the original state when it is destructed, i.e. the end of its scope. In this particular piece of code the scope of 'dummy2' is the 'if' branch, i.e. the shape will already be restored before cell(0).metrics() is called. It would maybe be more useful to have a FontSaver, then, like: FontSaver dummy(mi.base.font); if (whatever) mi.base.font.setShape(Font::UP_SHAPE); and mi.base.font would be restored on scope exit. Actually, a generic Saver class would be enough to solve all needs and seems much simpler to me than all the hand-made FooChanger classes. JMarc
Embedding feature slows down updateLabels() very significantly!
I think... Abdel.
[Embedding PATCH] update insets after the embedding status is changed
The attached patch
1. add Inset::updateEmbeddedFile, that will be called after the
embedding status of a file is changed. A typical use is
+void InsetGraphics::updateEmbeddedFile(Buffer const buf,
+ EmbeddedFile const file)
+{
+ params_.filename.set(file.availableFile(buf), buf.filePath());
+}
The problem here is that even if the underlying filename is changed,
the Graphic dialog is not updated. Does anyone know how to do this?
2. add EmbeddedFile::updateInsets(Buffer) and
EmbeddedFiles::updateInsets() to update related insets.
+void EmbeddedFile::updateInsets(Buffer const * buf) const
+{
+ vectorInset const *::const_iterator it = inset_list_.begin();
+ vectorInset const *::const_iterator it_end = inset_list_.end();
+ for (; it != it_end; ++it)
+ const_castInset *(*it)-updateEmbeddedFile(*buf, *this);
+}
+
3. call updateInsets at appropriate times. Such as when embedding is
enabled, and when a file embedding status is changed. Because stored
inset pointers are not guranteed to be up to date,
EmbeddedFiles::update() is called before such calls.
This adds another virtual function to Inset, so I need at least one OK. Jose?
Bo
Index: src/insets/InsetGraphics.h
===
--- src/insets/InsetGraphics.h (revision 20211)
+++ src/insets/InsetGraphics.h (working copy)
@@ -80,6 +80,8 @@
bool getStatus(Cursor , FuncRequest const , FuncStatus ) const;
/// all graphics can be embedded
void registerEmbeddedFiles(Buffer const , EmbeddedFiles ) const;
+ ///
+ void updateEmbeddedFile(Buffer const , EmbeddedFile const );
protected:
InsetGraphics(InsetGraphics const );
///
Index: src/insets/InsetGraphics.cpp
===
--- src/insets/InsetGraphics.cpp (revision 20211)
+++ src/insets/InsetGraphics.cpp (working copy)
@@ -239,6 +239,20 @@
}
+void InsetGraphics::updateEmbeddedFile(Buffer const buf,
+ EmbeddedFile const file)
+{
+ BOOST_ASSERT(buf.embeddedFiles().enabled());
+ LYXERR(Debug::FILES) Update InsetGraphics file from
+ params_.filename.toFilesystemEncoding() std::endl;
+ params_.filename.set(file.availableFile(buf), buf.filePath());
+ LYXERR(Debug::FILES) to
+ params_.filename.toFilesystemEncoding() std::endl;
+ // FIXME: graphics dialog is not updated even if the underlying
+ // filename is updated. What should I do?
+}
+
+
void InsetGraphics::edit(Cursor cur, bool)
{
InsetGraphicsMailer(*this).showDialog(cur.bv());
Index: src/insets/Inset.h
===
--- src/insets/Inset.h (revision 20211)
+++ src/insets/Inset.h (working copy)
@@ -49,6 +49,7 @@
class ParIterator;
class Text;
class TocList;
+class EmbeddedFile;
class EmbeddedFiles;
@@ -441,6 +442,8 @@
virtual void addToToc(TocList , Buffer const , ParConstIterator const ) const {}
/// report files that can be embedded with the lyx file
virtual void registerEmbeddedFiles(Buffer const , EmbeddedFiles ) const {};
+ /// use embedded or external file after the embedding status of a file is changed
+ virtual void updateEmbeddedFile(Buffer const , EmbeddedFile const ) {}
/// Fill keys with BibTeX information
virtual void fillWithBibKeys(Buffer const ,
BiblioInfo , InsetIterator const ) const { return; }
Index: src/EmbeddedFiles.cpp
===
--- src/EmbeddedFiles.cpp (revision 20212)
+++ src/EmbeddedFiles.cpp (working copy)
@@ -225,6 +225,15 @@
}
+void EmbeddedFile::updateInsets(Buffer const * buf) const
+{
+ vectorInset const *::const_iterator it = inset_list_.begin();
+ vectorInset const *::const_iterator it_end = inset_list_.end();
+ for (; it != it_end; ++it)
+ const_castInset *(*it)-updateEmbeddedFile(*buf, *this);
+}
+
+
bool EmbeddedFiles::enabled() const
{
return buffer_-params().embedded;
@@ -241,6 +250,8 @@
// if operation is successful
buffer_-markDirty();
buffer_-params().embedded = flag;
+ if (flag)
+ updateInsets();
}
}
@@ -468,4 +479,14 @@
}
+void EmbeddedFiles::updateInsets() const
+{
+ EmbeddedFiles::EmbeddedFileList::const_iterator it = begin();
+ EmbeddedFiles::EmbeddedFileList::const_iterator it_end = end();
+ for (; it != it_end; ++it)
+ if (it-valid() it-refCount() 0)
+ it-updateInsets(buffer_);
}
+
+
+}
Index: src/frontends/controllers/ControlEmbeddedFiles.cpp
===
--- src/frontends/controllers/ControlEmbeddedFiles.cpp (revision 20213)
+++ src/frontends/controllers/ControlEmbeddedFiles.cpp (working copy)
@@ -89,6 +89,7 @@
item.updateFromExternalFile(buffer());
else
item.extract(buffer());
+ item.updateInsets(buffer());
}
}
Index: src/EmbeddedFiles.h
===
--- src/EmbeddedFiles.h (revision 20212)
+++ src/EmbeddedFiles.h (working copy)
@@
Re: Embedding feature slows down updateLabels() very significantly!
On 9/11/07, Abdelrazak Younes [EMAIL PROTECTED] wrote: I think... I have not done any profiling but this is possible. Because EmbeddedFiles now saves inset pointers (not ParConstIterator), EmbeddedFiles::update() should be moved out of updateLabels() and iscalled with inset addition and removal. I am not quite sure what is the best way to do this though. Cheers, Bo
Re: Embedding feature slows down updateLabels() very significantly!
I am not quite sure what is the best way to do this though. With a patch that I just submitted for review, this is the last major problem that needs to be resolved. Basically, I need to call EmbeddedFiles::update() (or emit embeddingChanged() signal) when an inset that has embedded files is created/removed/modified. Do you have any good idea? I am not against the idea of an 'update' button that forces the update. This will be most efficient. Cheers, Bo
Re: [Patch] partial support for units
On Tue, Sep 11, 2007 at 05:37:32PM +0200, Andre Poenitz wrote:
On Tue, Sep 11, 2007 at 10:50:56AM +0300, Martin Vermeer wrote:
Here's a better one.
Not really ;-)
Index: src/mathed/InsetMathFrac.cpp
===
--- src/mathed/InsetMathFrac.cpp (revision 20193)
+++ src/mathed/InsetMathFrac.cpp (working copy)
@@ -48,9 +48,11 @@
bool InsetMathFrac::metrics(MetricsInfo mi, Dimension dim) const
{
FracChanger dummy(mi.base);
+ if (kind_ == UNITFRAC)
+ ShapeChanger dummy2(mi.base.font, Font::UP_SHAPE);
cell(0).metrics(mi);
cell(1).metrics(mi);
The ShapeChanger changes the Shape back to the original state when it is
destructed, i.e. the end of its scope. In this particular piece of code
the scope of 'dummy2' is the 'if' branch, i.e. the shape will already be
restored before cell(0).metrics() is called.
I am not sure that changing the shape is needed at all. Is the resulting
metrics visually different?
Perhaps not, but would it be wise to count on that?
If so, something like
bool InsetMathFrac::metrics(MetricsInfo mi, Dimension dim) const
{
FracChanger dummy(mi.base);
std::auto_ptrShapeChanger dummy2;
if (kind_ == UNITFRAC)
dummy2.reset(new ShapeChanger(mi.base.font, Font::UP_SHAPE));
cell(0).metrics(mi);
cell(1).metrics(mi);
might help. I this case the ShapeChanger will be destroyed at the
end of the function body.
I was looking for something like this, but decided for another approach.
Andre'
- Martin
Re: [Patch] partial support for units
On Tue, Sep 11, 2007 at 05:58:56PM +0200, Jean-Marc Lasgouttes wrote: Andre Poenitz [EMAIL PROTECTED] writes: The ShapeChanger changes the Shape back to the original state when it is destructed, i.e. the end of its scope. In this particular piece of code the scope of 'dummy2' is the 'if' branch, i.e. the shape will already be restored before cell(0).metrics() is called. It would maybe be more useful to have a FontSaver, then, like: FontSaver dummy(mi.base.font); if (whatever) mi.base.font.setShape(Font::UP_SHAPE); and mi.base.font would be restored on scope exit. Actually, a generic Saver class would be enough to solve all needs and seems much simpler to me than all the hand-made FooChanger classes. Not a bad idea actually. - Martin
Re: Idea: print via PDF preference
Jürgen Spitzmüller wrote:
Helge Hafting wrote:
Good idea, if only for print as file.
I definitely meant print to printer, not print to file.
Those who want a file can still use File-export-pdflatex.
Why? We have print to file, which should provide at least these two options.
(else, we should get rid of print to file completely).
Sure, we could get rid of print to file because LyX have all that
functionality
and much more on File-Export The only reason I can see
for having print to file is that people coming over from other
word processors are used to having it. But that reason isn't very strong
all the time the export menu is just as easy to get at.
Well, you get to choose the filename which is useful occationally.
Not only is this noticeably faster, but it also
support printing documents using the microtype package.
Modern LaTeX distributions use pdflatex also for DVI output.
Nice - that means the problem will go away. But what latex
distributions are considered new? I am using texlive from
debian unstable, which is usually recent enough.
TeXLive 2007 has it, I think teTeX 3 as well. I can't remember when the change
happened.
Hm. My texlive is version 2007, but view-dvi still produces a lot
more hyphenations than view-PDF does, when I have \usepackage{microtype}
in the preamble.
Still, view-pdf and view-dvi comes up different when microtype
is in use.
I think some microtypographic features are disabled in pdftex's dvi mode.
Ok, so there is a difference and it is not going away.
Unless this disabling is configurable.
Then I need File-print-printer to use the pdflatex way,
so my printouts won't typeset differently from my PDFs.
I use microtype in most documents.
The current workaround is to export or view PDF, and then
print the PDF from the command line or from the viewer.
It'd sure be nice to just print it. The future will likely bring
document classes (or .layouts) that specify microtype.
Simpler users probably won't understand why File-Print
doesn't match their PDF.
I understand that many people still will need the postscript print,
due to pstricks and such. So the question is how to implement this.
I have some ideas:
* A setting in preferences deciding what kind of export should
be used (dvips/pdflatex) when producing a file to chuck at the printer.
Of course this will decide the type of file produced by print to file
if that option is kept.
This way assumes that people rarely needs to make a change,
and so the print dialog doesn't get cluttered with it.
* A combobox in the print dialog. This assumes people
find it useful to switch back and forth, for example people
who utilize both microtype and pstricks - although not at the same time.
Again, the combobox can decide the output type for the
print to file too - assuming it isn't removed.
* The document can contain information abot what kind of
print capability is necessary. (I.e. LyX supporting microtype, and
makes sure such documents prints using pdflatex. LyX could
also support pstricks, at the very least by ensuring
that printing happens via dvips.
This is more userfriendly, as people won't _have_ to make sure
they print the correct way.
I hope to add microtype support later, it'd be nice to have
such documents print correctly in one way or another.
Helge Hafting
Re: Importing {\tiny ... }
Tommaso Cucinotta wrote:
After importing a LaTeX doc with a {\tiny some text}
command within a table caption, the caption text is
shown on LyX tiny, but there is no way (AFAICS) to
change it to standard size. What is the LyX way of
setting/unsetting \tiny, \small, \big, etc ?
Using LyX 1.5.1 for Linux.
T.
Select the tiny text
Edit-Text STyle-Customized...
You get a dialog - change to whatever size you need.
Helge Hafting
1.5.X Patch Candidate List #1
Hi, thanks for clearing the list. This is what is left: Approved by Jürgen -- Update to Boost 1.34.1 http://www.lyx.org/trac/changeset/19638 - redoParagraph() simplify the changed calculation http://www.lyx.org/trac/changeset/19868 - TextMetrics::redoParagraph(): we need to check the returned value of Inset::metrics() http://www.lyx.org/trac/changeset/19838 - Bug fix: correctly redraw a Row containing and inset which Dimension slightly changed http://www.lyx.org/trac/changeset/20016 - optimization: avoid some font copying http://www.lyx.org/trac/changeset/20021 - enable some non-rtl optimization http://www.lyx.org/trac/changeset/19867 - InsetCollapsable::setStatus(): remove the Buffer::changed() signal emission http://www.lyx.org/trac/changeset/20195 - unicodesymbols: workaround fix for an encoding bug in teTeX 3 /TeXLive 2005 New --- http://www.lyx.org/trac/changeset/19919 - Fix DEPM crash within inset. always clear the full text_metrics_ when doing a full update. ??? http://www.lyx.org/trac/changeset/20153 - Fix crash when layout file cannot be read due to failure to call makeTextClass() in that case. Regards, Michael
Re: 1.5.X Patch Candidate List #1
Michael Gerz wrote: thanks for clearing the list. This is what is left: http://www.lyx.org/trac/changeset/20016 - optimization: avoid some font copying http://www.lyx.org/trac/changeset/20021 - enable some non-rtl optimization These two are in. Jürgen
Re: [Patch] partial support for units
On Tue, Sep 11, 2007 at 05:58:56PM +0200, Jean-Marc Lasgouttes wrote: Andre Poenitz [EMAIL PROTECTED] writes: The ShapeChanger changes the Shape back to the original state when it is destructed, i.e. the end of its scope. In this particular piece of code the scope of 'dummy2' is the 'if' branch, i.e. the shape will already be restored before cell(0).metrics() is called. It would maybe be more useful to have a FontSaver, then, like: FontSaver dummy(mi.base.font); if (whatever) mi.base.font.setShape(Font::UP_SHAPE); and mi.base.font would be restored on scope exit. Actually, a generic Saver class would be enough to solve all needs and seems much simpler to me than all the hand-made FooChanger classes. It used to be shorter for common cases. Of course it is not forbidden to copy the whole font. Andre'
Re: [Patch] partial support for units
On Tue, Sep 11, 2007 at 07:41:29PM +0300, Martin Vermeer wrote:
On Tue, Sep 11, 2007 at 05:37:32PM +0200, Andre Poenitz wrote:
On Tue, Sep 11, 2007 at 10:50:56AM +0300, Martin Vermeer wrote:
Here's a better one.
Not really ;-)
Index: src/mathed/InsetMathFrac.cpp
===
--- src/mathed/InsetMathFrac.cpp (revision 20193)
+++ src/mathed/InsetMathFrac.cpp (working copy)
@@ -48,9 +48,11 @@
bool InsetMathFrac::metrics(MetricsInfo mi, Dimension dim) const
{
FracChanger dummy(mi.base);
+ if (kind_ == UNITFRAC)
+ ShapeChanger dummy2(mi.base.font, Font::UP_SHAPE);
cell(0).metrics(mi);
cell(1).metrics(mi);
The ShapeChanger changes the Shape back to the original state when it is
destructed, i.e. the end of its scope. In this particular piece of code
the scope of 'dummy2' is the 'if' branch, i.e. the shape will already be
restored before cell(0).metrics() is called.
I am not sure that changing the shape is needed at all. Is the resulting
metrics visually different?
Perhaps not, but would it be wise to count on that?
*shrug* If it walks likes a duck...
Andre'
Re: ERT in title bug
Jürgen Spitzmüller wrote:
Neal Becker wrote:
In my title I tried to insert:
Revision ERT{\input{build_id}}
On the screen, it says: \INPUT{BUILD_ID}
because I'm using ams art, and title is caps.
I chose 'view source', it says:
\title{SCMA Design Document\\
Revision \input{build_id}}
\maketitle
OK, fine. Just a screen buglet. Wait, no!
lyx --export pdf file
! LaTeX Error: File `BUILD_ID.tex' not found.
With ERT, you're on your own.
Try ERT{\MakeLowercase{\input{build_id}}}
Jürgen
Actually, I'm pretty sure this is a regression, which is due to the
current_font text-cursor move. What happens is, ERT font used to be set
explicitly, but now since there's no place to set it, it just takes the
font from the surrounding text. So in an AMS title you'll apparently get
all-caps, in an emph environment the text will all be emph, in a
non-latin language you can't type latin text at all, which means ERT is
useless in this context.
See the thread http://permalink.gmane.org/gmane.editors.lyx.devel/93458.
Something really should be done about this, but I'm not sure what the
correct way to deal with this is... I suggested one approach in that
message, but it's just an idea, I don't know if it would work in practice...
Dov
Re: 1.5.X Patch Candidate List #1
Michael Gerz wrote: Approved by Jürgen -- http://www.lyx.org/trac/changeset/19867 - InsetCollapsable::setStatus(): remove the Buffer::changed() signal emission I'll put this one in shortly. Very simple. ??? http://www.lyx.org/trac/changeset/20153 - Fix crash when layout file cannot be read due to failure to call makeTextClass() in that case. Not needed. This is for modules. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [Bug 3974] crash with user defined external templates
Jean-Marc Lasgouttes schrieb: [EMAIL PROTECTED] (Jürgen Spitzmüller) writes: Jean-Marc Lasgouttes wrote: I lost the patch. Where is it? http://bugzilla.lyx.org/attachment.cgi?id=1959action=view I have not see this patch before actually. Does the new libFileSearch have to build a vectorpair? We do not really care about user_lyxdir and such identifiers, IMO. This used is only for the message. insist on keeping this, a mapstring, FileName would make more sense. That was also my first thought when i implemented this method, but with that approach we lose the order of the entries, which is essential for the logic. Other than that, this new function looks useful. So the new behaviour would be to merge the three template files (BTW, I am not sure the notion of build_dir is useful anymore, I don't know that either but i added it because it is used in the other libFileSearch method too. separate discussion). The code as it is written makes sense, but I do not like outputting error messages to the console. They should be turned into debug messages (if we keep them). Instead we could mark in the GUI where each template comes from. I think we need some kind of information for the user what is happening in this case, because if there is a problem because of one template hides another one the user should be able to find a hint about what's going on. bernhard
[Patch] Bug 3527 - Basic PDF support via hyperref
hi,
i have basic working skeleton for bug 3527; now there is only minimal set of
supported features, but i'll add others, when you won't opose the general
construction of this code. i would like to ask :
1) is it possible to add hyperref support to 1.6 series (Jose?)
2) can somebody review this code and comment what should be done
otherwise and mainly what i forgot to do.
3) what features you would like to have from hyperref ?
from my point of view these things need to be resolved:
1) afaiu strings entered into gui are in utf8; now they are pasted to output
.tex via from_utf8,
but i'm not sure how it works with current encodings. whats the best
solution for this ?
2) i know from my previous experience with hyperref, that there are options,
which are just fine for
pdflatex, but when i try to render it through ps2pdf, the whole compilation
fails.
howto treat these cases ? is it possible to generate different code for a
different targets ?
3) is there something needed for lyx2lyx support ?
4) adding others things like keywords, checkboxes for working bookmarks and
references.
any comments welcomed
pavel
diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index 9115877..60abd48 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -55,6 +55,7 @@
#include Undo.h
#include version.h
#include EmbeddedFiles.h
+#include PDFOptions.h
#include insets/InsetBibitem.h
#include insets/InsetBibtex.h
@@ -459,6 +460,7 @@ int Buffer::readHeader(Lexer lex)
params().footskip.erase();
params().listings_params.clear();
params().clearLayoutModules();
+ params().pdfoptions().clear();
for (int i = 0; i 4; ++i) {
params().user_defined_bullet(i) = ITEMIZE_DEFAULTS[i];
diff --git a/src/BufferParams.cpp b/src/BufferParams.cpp
index e566cdd..cfcfa30 100644
--- a/src/BufferParams.cpp
+++ b/src/BufferParams.cpp
@@ -37,6 +37,7 @@
#include Spacing.h
#include TexRow.h
#include VSpace.h
+#include PDFOptions.h
#include frontends/alert.h
#include insets/InsetListingsParams.h
@@ -290,6 +291,7 @@ public:
* and for detached paragraphs in indented documents.
*/
VSpace defskip;
+ PDFOptions pdfoptions;
};
@@ -435,6 +437,16 @@ Spacing const BufferParams::spacing() const
return pimpl_-spacing;
}
+PDFOptions BufferParams::pdfoptions()
+{
+ return pimpl_-pdfoptions;
+}
+
+
+PDFOptions const BufferParams::pdfoptions() const
+{
+ return pimpl_-pdfoptions;
+}
VSpace const BufferParams::getDefSkip() const
{
@@ -633,6 +645,12 @@ string const BufferParams::readToken(Lexer lex, string
const token)
spacing().set(spacetranslator().find(nspacing), tmp_val);
} else if (token == \\float_placement) {
lex float_placement;
+ } else if (token == \\pdf_author) {
+ lex pdfoptions().author;
+ } else if (token == \\pdf_title) {
+ lex pdfoptions().title;
+ } else if (token == \\pdf_subject) {
+ lex pdfoptions().subject;
} else {
lyxerr BufferParams::readToken(): Unknown token:
token endl;
@@ -694,6 +712,7 @@ void BufferParams::writeFile(ostream os) const
os \\paperfontsize fontsize '\n';
spacing().writeFile(os);
+ pdfoptions().writeFile(os);
os \\papersize string_papersize[papersize]
\n\\use_geometry convertstring(use_geometry)
@@ -939,6 +958,19 @@ bool BufferParams::writeLaTeX(odocstream os,
LaTeXFeatures features,
os }\n;
texrow.newline();
}
+
+ // PDF support
+ if (!pdfoptions().empty()) {
+ os \\usepackage[\n;
+if (!pdfoptions().author.empty())
+ os pdfauthor={ from_utf8(pdfoptions().author)
},\n;
+if (!pdfoptions().title.empty())
+ os pdftitle={ from_utf8(pdfoptions().title)
},\n;
+if (!pdfoptions().subject.empty())
+ os pdfsubject={ from_utf8(pdfoptions().subject)
},\n;
+ os ]{hyperref};
+ }
+
if (use_geometry || nonstandard_papersize) {
os \\usepackage{geometry}\n;
texrow.newline();
diff --git a/src/BufferParams.h b/src/BufferParams.h
index 620b78e..2745f66 100644
--- a/src/BufferParams.h
+++ b/src/BufferParams.h
@@ -42,6 +42,7 @@ class Spacing;
class TexRow;
class VSpace;
class Language;
+class PDFOptions;
/** Buffer parameters.
* This class contains all the parameters for this buffer's use. Some
@@ -292,6 +293,10 @@ public:
///
void setCiteEngine(biblio::CiteEngine const);
+ /// options for pdf output
+ PDFOptions pdfoptions();
+ PDFOptions const pdfoptions() const;
+
private:
///
void readPreamble(Lexer );
diff --git a/src/Makefile.am b/src/Makefile.am
index bf1af93..0f30115
Re: [Patch] Bug 3527 - Basic PDF support via hyperref
i have basic working skeleton for bug 3527; now there is only minimal set of supported features, but i'll add others, when you won't opose the general construction of this code. i would like to ask : Nice work! 1) is it possible to add hyperref support to 1.6 series (Jose?) As long as you can complete the feature before 1.6 is released, so I guess the answer is yes. 2) can somebody review this code and comment what should be done otherwise and mainly what i forgot to do. I have a quick look at the patch, and have one question though: why do you use separate file for PDFOptions.h|cpp? I guess it can be merged to BufferParams. 3) what features you would like to have from hyperref ? Have not tried your patch... 3) is there something needed for lyx2lyx support ? Remove these options with back conversion. 4) adding others things like keywords, checkboxes for working bookmarks and references. I guess I also want 'fullscreen' mode for presentation. Cheers, Bo
Re: [Patch] Bug 3527 - Basic PDF support via hyperref
Bo Peng wrote:
2) can somebody review this code and comment what should be done
otherwise and mainly what i forgot to do.
I have a quick look at the patch, and have one question though: why do
you use separate file for PDFOptions.h|cpp? I guess it can be merged
to BufferParams.
Yes, I think that would be preferable, unless this got a lot larger.
Pavel: Note that the point is that the definitions and code can all go
into BufferParams.{h,cpp}. It's fine to have this class.
Probably there should just be a use hyperref checkbox to turn this on
and off. You could then check that and get basic hyperref support
without actually having to fill out any of the fields. That is: You'd
just get \usepackage{hyperref}. As for other checkboxes, we should have
ones for backref and pagebackref, etc.
As Bo said, well done.
And if you're working on thisthe URL inset should become an \href
inset. (There are a billion bugs about this.) This would be very easy to
do, and it's probably what people really want from hyperref. The only
significant work will be the lyx2lyx. The \url command can be handled
via CharStyles (and there's in fact already a module in lib/layouts that
does this). Any (old) URL inset that didn't declare the name field---if
it does, maybe it should be left an href---would get converted to a URL
charstyle (or flex inset, as they're now called), with \usepackage{url}
added to the preamble.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: 1.5.X patch candidates - next iteration
Abdelrazak Younes wrote:
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
http://www.lyx.org/trac/changeset/19919 - Fix DEPM crash within inset.
always clear the full text_metrics_ when doing a full update.
Applicable to branch?
In theory yes but this will have side effects within insets.
What kind of side effects?
I am not sure... maybe crashes, maybe cleared out text... In trunk, the
only side effect (besides fixing the DEPM crash) was that I had to force
full repaint in tabular cells. But a full repaint occurred anyway so no
harm done.
I'll tell you what, I'll produce a patch and let you test it and decide
if it is safe or not.
Well, I verified that there is no apparent side effect and I cannot see
how it could have anyway so I just committed it. The patch is short so
it can be reverted easily in case of problems but I really don't expect
any. I didn't put an entry in status.15x because I don't know what to put...
Abdel.
Author: younes
Date: Tue Sep 11 22:09:36 2007
New Revision: 20220
URL: http://www.lyx.org/trac/changeset/20220
Log:
BufferView: Be on the safe side: clear out all of text_metrics_ when
doing a full update.
Modified:
lyx-devel/branches/BRANCH_1_5_X/src/BufferView.cpp
Modified: lyx-devel/branches/BRANCH_1_5_X/src/BufferView.cpp
URL:
http://www.lyx.org/trac/file/lyx-devel/branches/BRANCH_1_5_X/src/BufferView.cpp?rev=20220
==
--- lyx-devel/branches/BRANCH_1_5_X/src/BufferView.cpp (original)
+++ lyx-devel/branches/BRANCH_1_5_X/src/BufferView.cpp Tue Sep 11
22:09:36 2007
@@ -1097,9 +1097,6 @@
width_ = width;
height_ = height;
- // The complete text metrics will be redone.
- text_metrics_.clear();
-
if (buffer_)
resize();
}
@@ -1464,7 +1461,6 @@
void BufferView::updateMetrics(bool singlepar)
{
Text buftext = buffer_-text();
- TextMetrics tm = textMetrics(buftext);
pit_type size = int(buftext.paragraphs().size());
if (anchor_ref_ int(buftext.paragraphs().size() - 1)) {
@@ -1478,8 +1474,11 @@
// Clear out paragraph metrics to avoid having invalid metrics
// in the cache from paragraphs not relayouted below
- tm.clear();
- }
+ // The complete text metrics will be redone.
+ text_metrics_.clear();
+ }
+
+ TextMetrics tm = textMetrics(buftext);
// If the paragraph metrics has changed, we can not
// use the singlepar optimisation.
Re: 1.5.X patch candidates - next iteration
Jürgen Spitzmüller wrote: Just to keep track, here are the fixes you still need to backport (and have OK to do so). No need to hurry, though: http://www.lyx.org/trac/changeset/19868 - TextMetrics::redoParagraph(): we need to check the returned value of Inset::metrics() http://www.lyx.org/trac/changeset/19838 - Bug fix: correctly redraw a Row containing and inset which Dimension slightly changed I committed those two (in one commit because they are related). Abdel.
Re: [Patch] Bug 3527 - Basic PDF support via hyperref
2) can somebody review this code and comment what should be done otherwise and mainly what i forgot to do. I have a quick look at the patch, and have one question though: why do you use separate file for PDFOptions.h|cpp? I guess it can be merged basically because i mimic some other class ;) when the code will not increase, i'll merge it. pavel
Re: 1.5.X Patch Candidate List #1
Richard Heck wrote: Michael Gerz wrote: Approved by Jürgen -- http://www.lyx.org/trac/changeset/19867 - InsetCollapsable::setStatus(): remove the Buffer::changed() signal emission I'll put this one in shortly. Very simple. This is in now. I didn't add anything to status.15x because it's more of a technical fix and didn't go with a bug number. rh -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: 1.5.X Patch Candidate List #1
Michael Gerz wrote: Hi, thanks for clearing the list. This is what is left: Approved by Jürgen -- Update to Boost 1.34.1 http://www.lyx.org/trac/changeset/19638 - redoParagraph() simplify the changed calculation On second thought I don't think I will backport this one because I am pretty sure it will have side effects. As there is text drawing problem in 1.5 I prefer to not touch it. http://www.lyx.org/trac/changeset/19868 - TextMetrics::redoParagraph(): we need to check the returned value of Inset::metrics() http://www.lyx.org/trac/changeset/19838 - Bug fix: correctly redraw a Row containing and inset which Dimension slightly changed http://www.lyx.org/trac/changeset/20016 - optimization: avoid some font copying http://www.lyx.org/trac/changeset/20021 - enable some non-rtl optimization Those four are in now. http://www.lyx.org/trac/changeset/19867 - InsetCollapsable::setStatus(): remove the Buffer::changed() signal emission Richard will take care of that one. New --- http://www.lyx.org/trac/changeset/19919 - Fix DEPM crash within inset. always clear the full text_metrics_ when doing a full update. This one is in. Abdel.
Re: 1.5.X Patch Candidate List #1
Richard Heck wrote: Michael Gerz wrote: Approved by Jürgen -- http://www.lyx.org/trac/changeset/19867 - InsetCollapsable::setStatus(): remove the Buffer::changed() signal emission I'll put this one in shortly. Very simple. OK, I'll let you the honor ;-) Abdel.
Re: 1.5.X Patch Candidate List #1
http://www.lyx.org/trac/changeset/20195 - unicodesymbols: workaround fix for an encoding bug in teTeX 3 /TeXLive 2005 This is in now. regards Uwe
Re: ERT in title bug
On Tue, Sep 11, 2007 at 10:11:42PM +0300, Dov Feldstern wrote:
Jürgen Spitzmüller wrote:
Neal Becker wrote:
In my title I tried to insert:
Revision ERT{\input{build_id}}
On the screen, it says: \INPUT{BUILD_ID}
because I'm using ams art, and title is caps.
I chose 'view source', it says:
\title{SCMA Design Document\\
Revision \input{build_id}}
\maketitle
OK, fine. Just a screen buglet. Wait, no!
lyx --export pdf file
! LaTeX Error: File `BUILD_ID.tex' not found.
With ERT, you're on your own.
Try ERT{\MakeLowercase{\input{build_id}}}
Jürgen
Actually, I'm pretty sure this is a regression, which is due to the
current_font text-cursor move. What happens is, ERT font used to be set
explicitly, but now since there's no place to set it, it just takes the
font from the surrounding text. So in an AMS title you'll apparently get
all-caps, in an emph environment the text will all be emph, in a
non-latin language you can't type latin text at all, which means ERT is
useless in this context.
See the thread http://permalink.gmane.org/gmane.editors.lyx.devel/93458.
Something really should be done about this, but I'm not sure what the
correct way to deal with this is... I suggested one approach in that
message, but it's just an idea, I don't know if it would work in practice...
Dov
I don't get this effect at all. Tried with article (AMS) and title
layout. The title is in small caps, and no matter what I do, the ERT
inset content is in lower case, standard size, typewriter LaTeX red
text, just as it is supposed to be.
What should I do to see the bug?
- Martin
Re: [Patch] Bug 3527 - Basic PDF support via hyperref
Probably there should just be a use hyperref checkbox to turn this on and
off. You could then check that and get basic hyperref support without
actually having to fill out any of the fields. That is: You'd just get
\usepackage{hyperref}.
have never used this plain version. does it anything useful ?
As for other checkboxes, we should have ones for backref and pagebackref, etc.
ok, i go read the manual :)
pavel
Re: ERT in title bug
Neal Becker wrote:
In my title I tried to insert:
Revision ERT{\input{build_id}}
On the screen, it says: \INPUT{BUILD_ID}
because I'm using ams art, and title is caps.
I chose 'view source', it says:
\title{SCMA Design Document\\
Revision \input{build_id}}
\maketitle
OK, fine. Just a screen buglet. Wait, no!
Which version is that?
Abdel.
Re: [Patch] Bug 3527 - Basic PDF support via hyperref
Pavel Sanda wrote:
Probably there should just be a use hyperref checkbox to turn this on and
off. You could then check that and get basic hyperref support without
actually having to fill out any of the fields. That is: You'd just get
\usepackage{hyperref}.
have never used this plain version. does it anything useful ?
Yes: It activates links to the bibliography and such.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: ERT in title bug
Martin Vermeer wrote: I don't get this effect at all. Tried with article (AMS) and title layout. The title is in small caps, and no matter what I do, the ERT inset content is in lower case, standard size, typewriter LaTeX red text, just as it is supposed to be. What should I do to see the bug? Use 1.5 ;-) Abdel.
Re: [Patch] Bug 3527 - Basic PDF support via hyperref
And if you're working on thisthe URL inset should become an \href inset. (There are a billion bugs about this.) I also opted for this often in the past, but you need to take care then of several issues. Take for example the Algorithm floats: The EmbeddedObjects manual describes a lot of Preamle hooks that are needed when hyperref is used. There are a lot other cases where this is problematic, just search in the EmbeddedObjects manual for hyperref. regards Uwe
Re: 1.5.X Patch Candidate List #1
Abdelrazak Younes wrote: Richard Heck wrote: Michael Gerz wrote: Approved by Jürgen -- http://www.lyx.org/trac/changeset/19867 - InsetCollapsable::setStatus(): remove the Buffer::changed() signal emission I'll put this one in shortly. Very simple. OK, I'll let you the honor ;-) Just saving you some work. And it's about all the time I can spare now. rh -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [Patch] Bug 3527 - Basic PDF support via hyperref
Uwe Stöhr wrote: And if you're working on thisthe URL inset should become an \href inset. (There are a billion bugs about this.) I also opted for this often in the past, but you need to take care then of several issues. Take for example the Algorithm floats: The EmbeddedObjects manual describes a lot of Preamle hooks that are needed when hyperref is used. There are a lot other cases where this is problematic, just search in the EmbeddedObjects manual for hyperref. It might be that, if we load hyperref at the right point---and obviously, we have to figure out when that is---these sorts of issues will go away. The problem, at present, is that you can only load it manually now, so it gets loaded late. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
includes
Could people please try to keep an eye on unneeded includes? I just had two almost-full-recompiles just because BufferParams.h happened to include frontend_helper.h for no good reason... Thank you. Andre'
Build of lyx-1.5.1 on FreeBSD 6.2. fails in src/support/tests/test_filetools
Hi, I'm currently in the process of porting lyx-1.5.1 to FreeBSD. The build-process however fails on src/support/tests/test_filetools. In #lyx (on irc.debian.org) ps told me to contact the mailinglist about this problem. I've attached the relevant build logs. My system is: FreeBSD fbsd.Amnesiac.unsernet 6.2-STABLE FreeBSD 6.2-STABLE #0: Wed Jun 27 12:25:02 CEST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CKERN6 i386 Qt4 is installed as followes: qt4-corelib-4.3.1 Qt core library qt4-gui-4.3.1 Qt graphical user interface library qt4-moc-4.3.1 Qt meta object compiler qt4-qmake-4.3.1 The build utility of the Qt project qt4-rcc-4.3.1 Qt resource compiler qt4-uic-4.3.1 Qt user interface compiler === Building for lyx-1.5.1 Making all in config gmake[1]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/config' gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/config' Making all in development gmake[1]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/development' gmake[2]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/development' gmake[2]: Nothing to be done for `all-am'. gmake[2]: Leaving directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/development' gmake[1]: Leaving directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/development' Making all in intl gmake[1]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/intl' gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/intl' Making all in po gmake[1]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/po' gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/po' Making all in src gmake[1]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src' gmake all-recursive gmake[2]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src' Making all in mathed gmake[3]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/mathed' gmake all-am gmake[4]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/mathed' gmake[4]: Nothing to be done for `all-am'. gmake[4]: Leaving directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/mathed' gmake[3]: Leaving directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/mathed' Making all in insets gmake[3]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/insets' gmake all-am gmake[4]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/insets' gmake[4]: Nothing to be done for `all-am'. gmake[4]: Leaving directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/insets' gmake[3]: Leaving directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/insets' Making all in graphics gmake[3]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/graphics' gmake all-am gmake[4]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/graphics' gmake[4]: Nothing to be done for `all-am'. gmake[4]: Leaving directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/graphics' gmake[3]: Leaving directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/graphics' Making all in support gmake[3]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/support' gmake all-recursive gmake[4]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/support' Making all in . gmake[5]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/support' gmake[5]: Leaving directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/support' Making all in tests gmake[5]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/support/tests' gmake all-am gmake[6]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/support/tests' gmake[6]: Nothing to be done for `all-am'. gmake[6]: Leaving directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/support/tests' gmake[5]: Leaving directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/support/tests' gmake[4]: Leaving directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/support' gmake[3]: Leaving directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/support' Making all in frontends gmake[3]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/frontends' gmake all-recursive gmake[4]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/frontends' Making all in controllers gmake[5]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/frontends/controllers' gmake all-recursive gmake[6]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/frontends/controllers' Making all in tests gmake[7]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/frontends/controllers/tests' gmake all-am gmake[8]: Entering directory `/usr/ports/print/lyx.new/work/lyx-1.5.1/src/frontends/controllers/tests' gmake[8]: Nothing to be done for `all-am'. gmake[8]: Leaving directory
Re: Build of lyx-1.5.1 on FreeBSD 6.2. fails in src/support/tests/test_filetools
On Tuesday 11 September 2007 22:48:50 Ullrich Franke wrote: My system is: FreeBSD fbsd.Amnesiac.unsernet 6.2-STABLE FreeBSD 6.2-STABLE #0: Wed Jun 27 12:25:02 CEST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CKERN6 i386 Thank you for the report. This test fails on linux too (Fedora 7 here) with the same error, FWIW. In this case it is a matter of understanding if the test makes sense at all. We should rework this in 1.6 where I would like to see more (meaningful) tests. Regards, -- José Abílio
Re: Importing {\tiny ... }
Helge Hafting ha scritto:
Select the tiny text
Edit-Text STyle-Customized...
You get a dialog - change to whatever size you need.
Oops, you're right ! I opened that dialog so many times,
without seeing what was just there !!
On a related note, I have a similar issue with a \textsl{}
within every cell of a table. This time, whatever I choose
from the Text Style dialog, it is added within the \textsl{}
command, that remains there.
Any clue ? Thanx, bye,
T.
question about language preference option auto_begin/end
Can anybody explain me what does the option auto end do that is in the preferences dialog under
Language settings? The only code reference I found is this:
if (!lyxrc.language_auto_end
!params().language-babel().empty()) {
os from_utf8(subst(lyxrc.language_command_end,
$$lang,
params().language-babel()))
'\n';
texrow().newline();
}
But what is the difference to the case when auto_end is activated?
thanks and regards
Uwe
Re: [Patch] Bug 3527 - Basic PDF support via hyperref
Probably there should just be a use hyperref checkbox to turn this on
and off. You could then check that and get basic hyperref support
without actually having to fill out any of the fields. That is: You'd
just get \usepackage{hyperref}. As for other checkboxes, we should have
ones for backref and pagebackref, etc.
http://wiki.lyx.org/uploads/DevelDoc/pdfsupport.gif
that is the current state on my local branch. still receiving additional
requests :)
pavel
Re: [Patch] Bug 3527 - Basic PDF support via hyperref
http://wiki.lyx.org/uploads/DevelDoc/pdfsupport.gif that is the current state on my local branch. still receiving additional requests :) Nice dialog. I think 1. PDF support may not be the best name. I am thinking of Document Properties, but Hyperref Support may be clearer. 2. This page should be put before preamble, which means the *last* and ultimate method of customization. I am thinking of Document Properties after Document class or Hyperref Support after Bibliography. 3. pagebackref, pageref, bookmark etc should be more verbal. Cheers, Bo
Re: [Patch] Bug 3527 - Basic PDF support via hyperref
1. PDF support may not be the best name. I am thinking of Document Properties, but Hyperref Support may be clearer. users with a little knowledge of latex will not understand Hyperref Support. Document Properties is too general. we can change the naming, but still i think that the keyword pdf should be incorporated somehow. 2. This page should be put before preamble, which means the *last* and ultimate method of customization. I am thinking of Document Properties after Document class or Hyperref Support after Bibliography. yep. 3. pagebackref, pageref, bookmark etc should be more verbal. suggestions ? (there are already more verbal tooltips) pavel
Re: ERT in title bug
On Tue, Sep 11, 2007 at 11:06:55PM +0200, Abdelrazak Younes wrote: Martin Vermeer wrote: I don't get this effect at all. Tried with article (AMS) and title layout. The title is in small caps, and no matter what I do, the ERT inset content is in lower case, standard size, typewriter LaTeX red text, just as it is supposed to be. What should I do to see the bug? Use 1.5 ;-) But then Dov's speculations are irrelevant. - Martin
Re: [Patch] Bug 3527 - Basic PDF support via hyperref
On 9/11/07, Pavel Sanda [EMAIL PROTECTED] wrote: 1. PDF support may not be the best name. I am thinking of Document Properties, but Hyperref Support may be clearer. users with a little knowledge of latex will not understand Hyperref Support. Document Properties is too general. we can change the naming, but still i think that the keyword pdf should be incorporated somehow. PDF Properties? 3. pagebackref, pageref, bookmark etc should be more verbal. suggestions ? (there are already more verbal tooltips) Something like Add backlink to bibliographic items, Generate bookmark links etc. Cheers, Bo
Lyx/branch crashes during exit.
On linux, simply start and quit lyx.
Backtrace:
#0 0x003412512838 in FcConfigSetFonts ()
from /usr/lib64/libfontconfig.so.1
#1 0x002a95c67267 in QFontDatabase::removeApplicationFont (handle=0)
at text/qfontdatabase_x11.cpp:1959
#2 0x0086a7a6 in ~GuiFontLoader (this=0xf13cb8)
at src/frontends/qt4/GuiFontLoader.cpp:235
#3 0x00863ed9 in ~GuiApplication (this=0xf13bb0)
at
/usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../include/c++/3.4.6/bits/stl_tree.h:558
#4 0x00445aa1 in boost::scoped_ptrlyx::frontend::Application::reset
(this=0xf0e2b8, p=0x0) at boost/boost/checked_delete.hpp:34
#5 0x0042d15a in lyx::LyX::prepareExit (this=0x7fb380)
at boost/boost/scoped_ptr.hpp:93
#2 points to
GuiFontLoader::~GuiFontLoader()
{
#if QT_VERSION = 0x040200
for (int i = 0 ; i num_math_fonts; ++i) {
if (fontID[i] = 0)
QFontDatabase::removeApplicationFont(fontID[i]);
}
delete [] fontID;
#endif
}
Re: Lyx/branch crashes during exit.
On Tue, 2007-09-11 at 22:50 -0500, Bo Peng wrote: On linux, simply start and quit lyx. r20206 didn't do this. I just built r20235 and tried. Sorry but following your procedure I don't get a crash. OpenSUSE 10.2. Have fun, Darren
Re: Lyx/branch crashes during exit.
On Tue, 2007-09-11 at 22:50 -0500, Bo Peng wrote:
#2 points to
GuiFontLoader::~GuiFontLoader()
{
#if QT_VERSION = 0x040200
for (int i = 0 ; i num_math_fonts; ++i) {
if (fontID[i] = 0)
QFontDatabase::removeApplicationFont(fontID[i]);
}
delete [] fontID;
#endif
}
I should have said, using Qt 4.2.1, so this code is being compiled.
Have fun,
Darren
Re: Lyx/branch crashes during exit.
I should have said, using Qt 4.2.1, so this code is being compiled. Then this might be another gcc 3 / signals problem. :-) I will compile with gcc 4 and try again. Bo
Re: [Bug 3974] crash with user defined external templates
Bernhard Roider wrote: > > ... We have to decide what is our policy > > for handling stuff in system dir vs stuff in .lyx. We cannot decide > > file by file whether in one case the system version is read, but not > > in the other. The behaviour should be predictable. ... > > So what's the opinion now? JMarc? Others? Again, my opinion is that your patch does the right thing (preference of user_lyxdir over build_lyxdir over system_lyxdir). Any objections? If not, I'd say put your fix in branch and trunk. Jürgen
Re: 1.5.X patch candidates - next iteration
Jürgen Spitzmüller wrote: I'll comment only on those that I haven't approved last time. http://www.lyx.org/trac/changeset/20016 - optimization: avoid some font copying http://www.lyx.org/trac/changeset/20021 - enable some non-rtl optimization Alfredo asked for some expert review. After that, it can go in. (I've already approved that) They are safe IMHO. New --- http://www.lyx.org/trac/changeset/19867 - InsetCollapsable::setStatus(): remove the Buffer::changed() signal emission Already approved last time ... Yes, I know I promised to do that last time but I was waiting for my other patch to be committed. I'll try to backport it but this just a cosmetics change for branch, nothing critical. http://www.lyx.org/trac/changeset/19919 - Fix DEPM crash within inset. always clear the full text_metrics_ when doing a full update. Applicable to branch? In theory yes but this will have side effects within insets. OTOH, that may solve some of the not easily reproducible crashes that have been reported. http://www.lyx.org/trac/changeset/20102 - Fix y co-ordinate for Conglomerate-style inset http://www.lyx.org/trac/changeset/20103 - y-coord in Conglomerate, this time properly Not applicable to branch, I think. Remove both. Right. http://www.lyx.org/trac/changeset/20159 - remove recursive call Hm. Peter, is this something for branch? No. http://www.lyx.org/trac/changeset/20081 - TextMetrics::drawSelection(): use parMetrics() instead of direct access just in case. Should fix crash on selection with PageUp Abdel? No. http://www.lyx.org/trac/changeset/20082 - Fix drawing of collapsable inset without button. Not applicable to branch, I think. Remove. Right. http://www.lyx.org/trac/changeset/20083 - Fix alignment of text within insets. http://www.lyx.org/trac/changeset/20101 - Nicely align inset buttons with surrounding text. http://www.lyx.org/trac/changeset/20142 - Restore docked View source widget. http://www.lyx.org/trac/changeset/20143 - fix view source window title. http://www.lyx.org/trac/changeset/20144 - oups... http://www.lyx.org/trac/changeset/20146 - Dialog::name() is not really needed. http://www.lyx.org/trac/changeset/20147 - Restore docked outline widget. Warning: still instable! http://www.lyx.org/trac/changeset/20177 - TextMetrics::draw(): withdraw first row ascent before drawing because the convention is that the baseline of a multirow text is the baseline of the first row. http://www.lyx.org/trac/changeset/20178 - fix outline dialog for non-Mac platform. All not applicable to branch, I think. Remove. And right. Abdel.
Re: r20205 - /lyx-devel/branches/BRANCH_1_5_X/src/frontends/q...
[EMAIL PROTECTED] wrote: Author: spitz Date: Tue Sep 11 08:21:53 2007 New Revision: 20205 Thanks! URL: http://www.lyx.org/trac/changeset/20205 Log: Backport revision 19747: * src/frontends/qt4/GuiView.h: - Delete include of config.h. This was needed only for the qt3 port. Modified: lyx-devel/branches/BRANCH_1_5_X/src/frontends/qt4/GuiView.h Modified: lyx-devel/branches/BRANCH_1_5_X/src/frontends/qt4/GuiView.h URL: http://www.lyx.org/trac/file/lyx-devel/branches/BRANCH_1_5_X/src/frontends/qt4/GuiView.h?rev=20205 == --- lyx-devel/branches/BRANCH_1_5_X/src/frontends/qt4/GuiView.h (original) +++ lyx-devel/branches/BRANCH_1_5_X/src/frontends/qt4/GuiView.h Tue Sep 11 08:21:53 2007 @@ -14,9 +14,6 @@ #ifndef GUI_VIEW_H #define GUI_VIEW_H - -// Must be here because of moc. -#include #include "frontends/LyXView.h" #include "FuncRequest.h"
Re: 1.5.X patch candidates - next iteration
Michael Gerz wrote: > http://www.lyx.org/trac/changeset/19473 - more verbose message I have backported this now > http://www.lyx.org/trac/changeset/19747 - Delete include of config.h. > This was needed only for the qt3 port. an this. Jürgen
