Re: current_font in ERT insets
Martin Vermeer wrote: On Fri, Sep 21, 2007 at 01:19:48AM +0200, Dov Feldstern wrote: Now there's a follow-up issue: when leaving the ERT inset by pressing right-arrow at the end of the inset, to get back outside after the inset, the language is remaining latex_language, which is wrong (for example, if you view source you'll see that the encoding is being set to latin1). So we're going to need some reverse mechanism of what your current fix did. Yes, I see that too, but only if the ERT is at end of paragraph. So here's my question: is there any function for jumping out of an inset to immediately after the inset? from anywhere inside the inset? is there an lfun/key-binding to such a function? LFUN_CHAR_FORWARD. But I suspect this is due to something Abdel removed... perhaps you should go though his patches here to find the culprit. It was probably part of the transition of current_font to Cursor. A call to setCurrentFont is probably missing in LFUN_CHAR_FORWARD. Abdel.
Re: PDF Options for 1.5.X?
Michael Gerz wrote: Is PDFOptions a potential candidate for 1.5.x? Not for 1.5.2 anyway. Jürgen
PDF Options for 1.5.X?
Hi, before I add lots of new patches to my list: Is PDFOptions a potential candidate for 1.5.x? Regards, Michael
Re: LyX svn crashes on ViewPDF (pdflatex)
Roger Mc Murtrie wrote: Problem finally found to be due to boost/libs/regex/src precompiled headers. The problem no longer occurs when all lines of boost/libs/regex/src/ pch.h are commented out. I could not identify any particular header file causing the problem. The bug is only cured by commenting out ALL headers in boost/libs/ regex/src/pch.h. Build experts: is there something we can do to fix this properly in 1.5.2? Jürgen
[patch] bug 3133: Beamer layout: change the title slide layout
http://bugzilla.lyx.org/show_bug.cgi?id=3133
The attached patch adds a Title (Plain Frame) style that can
be used instead of Title to get a plain title frame (no head-/footlines
and navigation bars). This is somewhat hackish, as a big part of the beamer
implementation in LyX is, but it's as good as it gets, IMHO, since we only
can define TitleLaTeXName once currently.
Comments?
Jürgen
P.S.: José, I'm unsure about the file format policy in this specific case.
Would it require a file format change? If not, I'd like to commit this to
branch as well.
Index: lib/layouts/beamer.layout
===
--- lib/layouts/beamer.layout (Revision 20240)
+++ lib/layouts/beamer.layout (Arbeitskopie)
@@ -746,7 +746,14 @@
Series Bold
Color Blue
EndFont
+End
+Style Title_(Plain_Frame)
+ CopyStyleTitle
+ Preamble
+ % plain title style, override default
+ \renewcommand\makelyxbeamertitle{\frame[plain]{\maketitle}}%
+ EndPreamble
End
Style Subtitle
@@ -1094,10 +1101,13 @@
LaTeXBuiltin true
End
-TitleLaTeXName frame{\maketitle}
+# to give users the choice of a title frame with and without
+# head-/footline, we define our own maketitle command
+TitleLaTeXName makelyxbeamertitle
-
Preamble
+ % this default might be overridden by plain title style
+ \newcommand\makelyxbeamertitle{\frame{\maketitle}}%
\AtBeginDocument{
\let\origtableofcontents=\tableofcontents
[EMAIL PROTECTED]
Re: current_font in ERT insets
On Fri, 21 Sep 2007 08:32:39 +0200 Abdelrazak Younes [EMAIL PROTECTED] wrote: Martin Vermeer wrote: On Fri, Sep 21, 2007 at 01:19:48AM +0200, Dov Feldstern wrote: Now there's a follow-up issue: when leaving the ERT inset by pressing right-arrow at the end of the inset, to get back outside after the inset, the language is remaining latex_language, which is wrong (for example, if you view source you'll see that the encoding is being set to latin1). So we're going to need some reverse mechanism of what your current fix did. Yes, I see that too, but only if the ERT is at end of paragraph. So here's my question: is there any function for jumping out of an inset to immediately after the inset? from anywhere inside the inset? is there an lfun/key-binding to such a function? LFUN_CHAR_FORWARD. But I suspect this is due to something Abdel removed... perhaps you should go though his patches here to find the culprit. It was probably part of the transition of current_font to Cursor. A call to setCurrentFont is probably missing in LFUN_CHAR_FORWARD. Abdel, do you have an easy fix handy ;-) - Martin
Re: LyX svn crashes on ViewPDF (pdflatex)
Juergen Spitzmueller [EMAIL PROTECTED] writes: Roger Mc Murtrie wrote: Problem finally found to be due to boost/libs/regex/src precompiled headers. The problem no longer occurs when all lines of boost/libs/regex/src/ pch.h are commented out. I could not identify any particular header file causing the problem. The bug is only cured by commenting out ALL headers in boost/libs/ regex/src/pch.h. Build experts: is there something we can do to fix this properly in 1.5.2? A shot in the dark: this problem typically looks like having part of the code forget to use #include config.h. When this happens and stdlib-debug is on, the mamory layout of std::string (for example) is not the same in different parts of LyX code. So, why is this related to pch.h? Perhaps because the first time where pch.h is used/created, config.h has not been loaded and the wrong options are used. I note that boost/libs/regex/src/pch.h is the only pch file that does not load any boost header, and thus no boost/config.hpp. Roger, does adding #include boost/config.hpp at the top of this file help? JMarc
Re: current_font in ERT insets
Martin Vermeer wrote:
On Fri, 21 Sep 2007 08:32:39 +0200
Abdelrazak Younes [EMAIL PROTECTED] wrote:
Martin Vermeer wrote:
On Fri, Sep 21, 2007 at 01:19:48AM +0200, Dov Feldstern wrote:
Now there's a follow-up issue: when leaving the ERT inset by pressing
right-arrow at the end of the inset, to get back outside after the
inset, the language is remaining latex_language, which is wrong (for
example, if you view source you'll see that the encoding is being set to
latin1). So we're going to need some reverse mechanism of what your
current fix did.
Yes, I see that too, but only if the ERT is at end of paragraph.
So here's my question: is there any function for jumping out of an inset
to immediately after the inset? from anywhere inside the inset? is there
an lfun/key-binding to such a function?
LFUN_CHAR_FORWARD. But I suspect this is due to something Abdel
removed... perhaps you should go though his patches here to find the
culprit.
It was probably part of the transition of current_font to Cursor. A call
to setCurrentFont is probably missing in LFUN_CHAR_FORWARD.
Abdel,
do you have an easy fix handy ;-)
What about this... could you try please?
Abdel.
Index: Text3.cpp
===
--- Text3.cpp (revision 20371)
+++ Text3.cpp (working copy)
@@ -384,7 +384,8 @@
cur.boundary() == oldBoundary) {
cur.undispatched();
cmd = FuncRequest(LFUN_FINISHED_RIGHT);
- }
+ } else
+ cur.setCurrentFont();
break;
case LFUN_CHAR_BACKWARD:
@@ -400,7 +401,8 @@
cur.boundary() == oldBoundary) {
cur.undispatched();
cmd = FuncRequest(LFUN_FINISHED_LEFT);
- }
+ } else
+ cur.setCurrentFont();
break;
case LFUN_UP_SELECT:
Re: [PATCH] Remove LFUN_FONT_CODE
Martin Vermeer [EMAIL PROTECTED] writes: Actually I'm not too sure we should re-package font attributes as insets. They should remain themselves, only their direct use discouraged. Well, we shall definitely keep a separation (at least in the UI) between fonts and char styles, if only to make sure that people do not start to use them too much. However, this is othogonal to the discussion about changing fonts to insets (although I am not a proponent of this change, as some people know). JMarc
Re: InsetCommand[Params]
Juergen Spitzmueller [EMAIL PROTECTED] writes: Fonts, btw, should go down the same route eventually (however, we should take care that we don't end up with 173 configuration files). What do you mean? What I'm suggesting is that command insets should behave the same way. So we'd have: \begin_inset Citation command citet key etctec \end_inset More or less. This looks reasonable, in general. A question: how will the parser know that this is an insetcommand? Still hardcoded? JMarc
Re: PDF Options for 1.5.X?
Michael Gerz [EMAIL PROTECTED] writes: Hi, before I add lots of new patches to my list: Is PDFOptions a potential candidate for 1.5.x? No, it is a format change. JMarc
Re: [patch] bug 3133: Beamer layout: change the title slide layout
On Friday 21 September 2007 08:12:49 Juergen Spitzmueller wrote: P.S.: José, I'm unsure about the file format policy in this specific case. Would it require a file format change? If not, I'd like to commit this to branch as well. This means that if you a previous version of 1.5 (1.5.1) for all purposes you will not be able to work with that file if you use the new style as it will be converted to the default layout style. OTHO this is some kind of weak bondage in the sense that the files loads and you can work with it. The strong version would be that the previous version would not be able to load the version at all. We care, and the rules are clear, about the later case. I think that we can discuss things on a case to case scenario regarding the weak bondage. What do others think? I think that we should start adding this analysis to wiki to avoid having to think about every time one of this cases arrive. :-) -- José Abílio
Re: [patch] bug 3133: Beamer layout: change the title slide layout
José Matos wrote: This means that if you a previous version of 1.5 (1.5.1) for all purposes you will not be able to work with that file if you use the new style as it will be converted to the default layout style. OTHO this is some kind of weak bondage in the sense that the files loads and you can work with it. And you can easily upgrade the layout file (which is not possible if there are file format changes that are bound to changes in the source of LyX). Jürgen
Re: InsetCommand[Params]
Jean-Marc Lasgouttes wrote: Fonts, btw, should go down the same route eventually (however, we should take care that we don't end up with 173 configuration files). What do you mean? The fonts we support are hardcoded in LyX. This means that new fonts (such as the TeXGyre fonts) need to be added to BufferParams::loadFonts (which always entails a file format change currently). I'd like to outsource this to some configuration file (or engine, as Richard calls it), where the parameters of fonts can be specified and where new fonts can be added easily. This would mean, for instance, that I wouldn't have to use the preamble when I use commercial fonts. I could simply add these to the file and use it from the Documents dialog. Having said this, we will have to rethink anyway what we're gonna do with the new and upcoming possibilities to use OpenType fonts directly (in XeTeX and presumerably also in LuaTeX/pdftex 2). However, I'm not yet familiar with this methods, so I don't know how easy it is to implement it. Jürgen
Re: current_font in ERT insets
Abdelrazak Younes [EMAIL PROTECTED] writes: do you have an easy fix handy ;-) What about this... could you try please? How come cursorLeft does not set the font correctly? I tried to follow that code, but I am not sure I understand. Ideally, the call to setCurrentFont should be automatic. JMarc
Re: current_font in ERT insets
On Fri, 21 Sep 2007 10:29:17 +0200 Abdelrazak Younes [EMAIL PROTECTED] wrote: Martin Vermeer wrote: On Fri, 21 Sep 2007 08:32:39 +0200 Abdelrazak Younes [EMAIL PROTECTED] wrote: Martin Vermeer wrote: On Fri, Sep 21, 2007 at 01:19:48AM +0200, Dov Feldstern wrote: Now there's a follow-up issue: when leaving the ERT inset by pressing right-arrow at the end of the inset, to get back outside after the inset, the language is remaining latex_language, which is wrong (for example, if you view source you'll see that the encoding is being set to latin1). So we're going to need some reverse mechanism of what your current fix did. Yes, I see that too, but only if the ERT is at end of paragraph. So here's my question: is there any function for jumping out of an inset to immediately after the inset? from anywhere inside the inset? is there an lfun/key-binding to such a function? LFUN_CHAR_FORWARD. But I suspect this is due to something Abdel removed... perhaps you should go though his patches here to find the culprit. It was probably part of the transition of current_font to Cursor. A call to setCurrentFont is probably missing in LFUN_CHAR_FORWARD. Abdel, do you have an easy fix handy ;-) What about this... could you try please? Abdel. Nope... does not help. - Martin
Re: InsetCommand[Params]
Juergen Spitzmueller [EMAIL PROTECTED] writes: The fonts we support are hardcoded in LyX. This means that new fonts (such as the TeXGyre fonts) need to be added to BufferParams::loadFonts (which always entails a file format change currently). OK, you mean font packages. Yes, something could be done, but some hardcoding is often necessary. Example I found yesterday and did not report yet: when using almost EC fonts, I need to use aeguill.sty too if I want to use french guillemets (otherwise all I get is black squares). Either we always load it (but I suspect there is a reason why the ae style file does not do it by itself), or I should add aeguill only when a french quote character is used in the document. JMarc
Re: [Patch#4] Bug 3527 - Basic PDF support via hyperref
On Fri, Sep 21, 2007 at 03:53:52AM +0200, Pavel Sanda wrote: can you add this small polish ? pavel diff --git a/src/PDFOptions.cpp b/src/PDFOptions.cpp index d16b9cd..0bf5a0d 100644 --- a/src/PDFOptions.cpp +++ b/src/PDFOptions.cpp @@ -76,7 +76,7 @@ void PDFOptions::writeFile(ostream os) const } -void PDFOptions::writeLaTeX(odocstream os) const +void PDFOptions::writeLaTeX(odocstringstream os) const Why this restriction to stringstream? [Apart from that: space after ''] Andre'
Re: [patch] bug 3133: Beamer layout: change the title slide layout
José Matos [EMAIL PROTECTED] writes: On Friday 21 September 2007 08:12:49 Juergen Spitzmueller wrote: P.S.: José, I'm unsure about the file format policy in this specific case. Would it require a file format change? If not, I'd like to commit this to branch as well. This means that if you a previous version of 1.5 (1.5.1) for all purposes you will not be able to work with that file if you use the new style as it will be converted to the default layout style. Note that a 1.5.1 user can just get the updated layout file and it will 100% work. I think it is an error to bind layout files to LyX version. A nice solution would be to have a version number in the layout file itself and make lyx2lyx able to translate documents based on that. But this is is probably too difficult to do in practice. JMarc
Re: [PATCH] Remove LFUN_FONT_CODE
On Fri, 21 Sep 2007 10:35:04 +0200 Jean-Marc Lasgouttes [EMAIL PROTECTED] wrote: Martin Vermeer [EMAIL PROTECTED] writes: Actually I'm not too sure we should re-package font attributes as insets. They should remain themselves, only their direct use discouraged. Well, we shall definitely keep a separation (at least in the UI) between fonts and char styles, if only to make sure that people do not start to use them too much. Yes, I agree with that (but think it is self-evident) However, this is othogonal to the discussion about changing fonts to insets (although I am not a proponent of this change, as some people know). Yes, what I was trying to argue is that I am against that too. Reason: it adds one extra layer of complexity in-between, for no good reason that I can see. - Martin
Re: [Patch#4] Bug 3527 - Basic PDF support via hyperref
On Fri, Sep 21, 2007 at 02:43:48AM +0200, Pavel Sanda wrote: - less than 80 - \epsilon chars per line. - no tabs after the first non-tab on the line. - Two empty lines between function definitions. - includes roughly from most-specific to least-specific. In any case ours before system headers/. - A .cpp must have #include config.h as first include. - no using in headers. maybe these should be added to coding style. - no using in headers. just to learn, why ? Because the whole idea of namespaces is defeated if early in the process everything is dumped in the global namespace. - no unneeded includes, especially in headers (there was a spurious #include debug.h. Apart from that our headers would use ..., not ... ugh, sorry. - A .cpp must have #include config.h as first include. again, why ? Because config.h contains some #defines that might influence everything that is included afterwards. The patch as-is does not even link for me. hmm. it did for me before i posted. maybe something changed in trunk meanwhile, maybe you forget to add PDFOptions.h/cpp (you forget to commit them). Urps. But that what not the reason. I'll commit a modified version of your patch shortly nevertheless. thanks. Please check that everything still works as intended. not at all, quick scan of current trunk reveal that the patch was not correctly applied or/and commited. Please try again. Andre'
Re: [Cvslog] r20406 - in /lyx-devel/trunk/src: PDFOptions.cpp PDFOptio...
On Fri, Sep 21, 2007 at 02:10:56AM -, [EMAIL PROTECTED] wrote: Author: rgheck Date: Fri Sep 21 04:10:50 2007 New Revision: 20406 URL: http://www.lyx.org/trac/changeset/20406 Log: Fix from Pavel. Modified: lyx-devel/trunk/src/PDFOptions.cpp lyx-devel/trunk/src/PDFOptions.h Modified: lyx-devel/trunk/src/PDFOptions.cpp URL: http://www.lyx.org/trac/file/lyx-devel/trunk/src/PDFOptions.cpp?rev=20406 == --- lyx-devel/trunk/src/PDFOptions.cpp (original) +++ lyx-devel/trunk/src/PDFOptions.cpp Fri Sep 21 04:10:50 2007 @@ -77,7 +77,7 @@ os \\pdf_quoted_options \ quoted_options \\n; } -void PDFOptions::writeLaTeX(odocstream os) const +void PDFOptions::writeLaTeX(odocstringstream os) const Why? A odocstringstream _is_a_ odocstream. Andre'
Re: InsetCommand[Params]
Jean-Marc Lasgouttes wrote: Example I found yesterday and did not report yet: when using almost EC fonts, I need to use aeguill.sty too if I want to use french guillemets (otherwise all I get is black squares). Either we always load it (but I suspect there is a reason why the ae style file does not do it by itself), or I should add aeguill only when a french quote character is used in the document. aeguill.sty should be loaded (and it used to be loaded). If this doesn't happen anymore, then this is a bug. Jürgen (such things could also be defined in the config files, with a Requires flag or somesuch).
Re: InsetCommand[Params]
Jean-Marc Lasgouttes wrote: Example I found yesterday and did not report yet: when using almost EC fonts, I need to use aeguill.sty too if I want to use french guillemets (otherwise all I get is black squares). Either we always load it (but I suspect there is a reason why the ae style file does not do it by itself), or I should add aeguill only when a french quote character is used in the document. I checked again: we only load aecompl. I don't know if there's a reason to not load aeguill, or if it has just been forgotten. Jürgen
Re: InsetCommand[Params]
On Friday 21 September 2007 10:28:06 Jean-Marc Lasgouttes wrote: OK, you mean font packages. Yes, something could be done, but some hardcoding is often necessary. Example I found yesterday and did not report yet: when using almost EC fonts, I need to use aeguill.sty too if I want to use french guillemets (otherwise all I get is black squares). Either we always load it (but I suspect there is a reason why the ae style file does not do it by itself), or I should add aeguill only when a french quote character is used in the document. If we identify chars ranges that require other needs we should add code to support that, there is no need to hardwire this in the code. And I imagine that this case is not unique in that sense. -- José Abílio
Re: LyX svn crashes on ViewPDF (pdflatex)
On Fri, Sep 21, 2007 at 09:01:32AM +0200, Juergen Spitzmueller wrote: Roger Mc Murtrie wrote: Problem finally found to be due to boost/libs/regex/src precompiled headers. The problem no longer occurs when all lines of boost/libs/regex/src/ pch.h are commented out. I could not identify any particular header file causing the problem. The bug is only cured by commenting out ALL headers in boost/libs/ regex/src/pch.h. Build experts: is there something we can do to fix this properly in 1.5.2? I guess we should disable pch by default. From what I see right now they hurt more than they help. Andre'
Re: cross referencing sections
[EMAIL PROTECTED] wrote: On Tue, 18 Sep 2007, Yann Disser wrote: It would be nice if you considered implementing the possibility of cross-referencing to sections etc without the need of inserting ugly labels - the use of labels should in my opinion be reduced to an absolute minimum. My works are often full of labels for cross-referencing to other parts of themselves (and equations and figures and tables etc). This makes the text less readable. Similar issues were discussed a while back. So as a user, I think your input would be appreciated. What's your tought on thinks like these: * Is the problem that the labels are shown, or that they exist? For me, the problem is the hassle of having to insert them. This is very occationally useful, e.g. when referring to the fifth paragraph of some section. It _may_ fall on another page than the section heading, so it is then necessary to insert a label to get the page number right. Visible labels is also a problem, but auto-labels for all numbered entities should leave so few visible labels that we probably want to have them. * What would you think of an easy way to enable/disable the display of (all) labels? Possibly something similar for other disturbing elements such as ERT insets. No need - make LyX work (mostly) without inserted labels. LyX can autogenerate a latex label during latex code export, when some entity happens to have a reference. * How do you envison a user referring to a section? This is the case when cross-referencing it without (exlicitly) using a label. Insert-reference, using the normal dialog. But now the dialog will list every referable entity in the entire document. I.e. all headings, enumerations and so on. Of course this could get a bit cluttered for a big book, so a nice implementation ought to have buttons for turning categories on/off. Someone who usually refer to sections will turn off display of headings below section, as well as enums. There could be lots of enums, so default them to off. This can probably be taken further, but is merely UI refinement. For sectioning, the default could be to display down to the sectioning level that actually will be numbered in the output. * Is it problematic having to come up with names for the labels? * If labels are generated automatically, how should they get their name? A LyX user won't see the label name at all, so it doesn't matter much. For the benefit of latex users, perhaps some simple scheme based on category, i.e. sect1, sect2, subsect5, part9, enum12, formula67, ... * What should happen if for instance a label is automatically inserted in a section heading based on the title of that heading, and the heading is subsequently deleted? You can do that today with manual labels, and LyX will then leave a xref to a label that doesn't exist. Latex will then print ??. I wouldn't want auto-deletion of the xref, as I might want to paste that heading somewhere else and still have it referenced. Or even worse, if that section is deleted and another section is created later that happen to have the same heading? I think an auto-label should behave very much like an explicit label, except that you don't actally see it. Well, LyX could put a tiny label icon in the margin next to the heading to indicate the fact. It might be useful, and won't clutter up the main window. So, if the section is deleted, the label dies with it. If it is pasted once, then the autolabel is pasted too. If it is pasted more, then LyX should refrain from creating an identical label. The easy way is to just drop the label then. The advanced way will be to check if a reference exists inside the pasted content, and then create a new label/reference pair. (Similiar to how spreadsheets paste formulas with cell references.) But this part can wait, it is only UI refinement. Finally, if a section is created manually with identical text to some previous section, then of course no label is created. Helge Hafting
Re: Small puzzle.
Andre Poenitz wrote: Little puzzle for you: What belongs together? Configurations: (A) current svn, --enable-pch (B) current svn, --disable-pch At some point, pch defaulted to on, and it broke the build for me. I have used --disable-pch since then. Is it problem-free to use these days? Helge Hafting
Re: LyX svn crashes on ViewPDF (pdflatex)
On 21/09/2007, at 6:26 PM, Jean-Marc Lasgouttes wrote: A shot in the dark: this problem typically looks like having part of the code forget to use #include config.h. When this happens and stdlib-debug is on, the mamory layout of std::string (for example) is not the same in different parts of LyX code. So, why is this related to pch.h? Perhaps because the first time where pch.h is used/created, config.h has not been loaded and the wrong options are used. I note that boost/libs/regex/src/pch.h is the only pch file that does not load any boost header, and thus no boost/config.hpp. Roger, does adding #include boost/config.hpp at the top of this file help? JMarc Excellent shot in the dark. Adding #include boost/config.hpp at the top of the original regex/ src/pch.h file fixes the problem. Roger
Re: InsetCommand[Params]
Richard Heck wrote:
The change should be fairly simple, both in the code and in lyx2lyx:
It's mostly a matter of file format, not so much of internal
representation. Internal code concerned with writing and reading will be
all that changes. This will significantly simplify factory.cpp's
readInset() routine.
Only slightly: A few lines of hardcoded ref commands would vanish.
In particular, things like this:
// This strange command allows LyX to recognize natbib style
// citations: citet, citep, Citet etc.
// FIXME: We already have partial support for \\fullcite and
// the various \\footcite commands. We should increase the
// file format number and read these commands here, too.
// Then we should use is_possible_cite_command() in
// InsetCitation to test for valid cite commands.
if (compare_ascii_no_case(cmdName.substr(0,4), cite) == 0) {
inset.reset(new InsetCitation(inscmd));
} else...
go away.
That is a separate issue that can be solved independently. Having said that,
the proposed change InsetCommand-InsetCitation makes much sense, but not
because of the factory.cpp simplification (it would still need two lines
per inset which is OK IMHO), but because of the added flexibility.
The bad news is that this change will require one controller class for each
inset. Currently there is only one command controller, used by all command
insets. That is the only reason I did not do this change already during the
InsetCommandParams rewrite.
Note that the issue with is_possible_cite_command() is
essentially the one I've been discussing: Right now, it's hardcoded; and
if it isn't, you might find yourself reading a LyX file that contains a
cite command you didn't know about, so you misread the inset.
Comments?
I guess you probably know that already, but please keep in mind that
InsetCommandParams/InsetCommand is in a state of flux: The goal was to
decouple the children of InsetCommand from LaTeX, use the name/value
interface exlusively in LyX, and concentrate all LaTeX stuff in
InsetCommandParams. This was not finished because of the freeze.
IMHO the legacy code using the old interface (marked withg FIXME remove)
should be converted to the new one. That alone gets rid of quite a bit of
ugly code.
Another planned, but not implemented bit is support for keyval options
(currently not used): An inset does not need to know that they need to be
exported to TeX as [a=A,b=B]. It could use the same existing interface for
setting/getting these options in InsetCommandParams. Only in the definition
of the inset (currently in InsetCommandParams.cpp, but it should be
straightforward to read this info from a text file) the type of these
parameters would be specified. Then you would never need to parse a
a=A,b=B string (which is quite complicated if you want to do it correctly
with escaping), because in .lyx files these values would be written as
separate parameters.
Georg
Re: [Patch#4] Bug 3527 - Basic PDF support via hyperref
I tried to play with the PDF property feature. 1. view source dialog is still broken (Can not update). Can anyone fix it? i will look. 2. I only checked two items but your hyperref output has two lines of options. Can you remove some of them that are using their default values? i was thinking about that some time. the only clean way i saw was to use tristate attributes yes/no/not used. but this also means you have use this three state in gui dialog, which will be in contrast with the rest of gui. finally i decided not to do it. what do others think about this ? 3. Should other items be disabled when 'use hyperref' is not checked? also was not sure about that. but its trivial to change it if you think it should. 4. I select 'no frames around links' but I still see red frames around my TOC items. this was added for someone request with advice what should be in tex output. i dont use it myself - what tex output would you expect for this ? pavel
external boost crashes lyx on startup
Hi, when compiling lyx with external boost when I start lyx it immediately crashes. The backtrace follows attached. Any suggestion? -- José Abílio [?1034hUsing host libthread_db library /lib/libthread_db.so.1. [Thread debugging using libthread_db enabled] [New process 28078] [New Thread -1219799344 (LWP 28078)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1219799344 (LWP 28078)] 0x00c1b9fe in __gnu_debug::_Safe_iterator_base::_M_detach () from /usr/lib/libstdc++.so.6 #0 0x00c1b9fe in __gnu_debug::_Safe_iterator_base::_M_detach () from /usr/lib/libstdc++.so.6 #1 0x00c1baaf in __gnu_debug::_Safe_iterator_base::_M_attach () from /usr/lib/libstdc++.so.6 #2 0x00c1bc4d in __gnu_debug::_Safe_sequence_base::_M_detach_all () from /usr/lib/libstdc++.so.6 #3 0x08380c3a in boost::detail::sp_counted_impl_pboost::signals::detail::slot_base::data_t::dispose (this=0xa8732a0) at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/debug/safe_base.h:170 #4 0x086c2281 in LyXView (this=0xa8728f4, id=0) at /usr/include/boost/detail/sp_counted_base_gcc_x86.hpp:145 #5 0x0886c840 in GuiViewBase (this=0xa8728e0, id=0) at GuiView.cpp:214 #6 0x087a9f5e in lyx::frontend::GuiImplementation::createRegisteredView (this=0xa7ca090) at GuiImplementation.cpp:51 #7 0x086b55e1 in lyx::frontend::Application::createView (this=0xa7ca088, width=690, height=510, posx=-1, posy=-1, maximized=0, iconSizeXY=0, [EMAIL PROTECTED]) at Application.cpp:54 #8 0x08133d0b in lyx::LyX::newLyXView (this=0xbf9bb73c) at LyX.cpp:724 #9 0x08140729 in lyx::LyX::restoreGuiSession (this=0xbf9bb73c) at LyX.cpp:631 #10 0x081414f6 in lyx::LyX::execBatchCommands (this=0xbf9bb73c) at LyX.cpp:616 #11 0x086d7f7b in lyx::frontend::GuiApplication::execBatchCommands (this=0xa7ca080) at GuiApplication.cpp:217 #12 0x086d822c in lyx::frontend::GuiApplication::qt_metacall (this=0xa7ca080, _c=QMetaObject::InvokeMetaMethod, _id=176632504, _a=0xbf9ba34c) at GuiApplication_moc.cpp:68 #13 0x00b4969a in QMetaObject::activate () from /usr/lib/libQtCore.so.4 #14 0x00b49f82 in QMetaObject::activate () from /usr/lib/libQtCore.so.4 #15 0x00b4f097 in ?? () from /usr/lib/libQtCore.so.4 #16 0x00b4f0dc in ?? () from /usr/lib/libQtCore.so.4 #17 0x00b45cb5 in QObject::event () from /usr/lib/libQtCore.so.4 #18 0x00436d50 in QApplicationPrivate::notify_helper () from /usr/lib/libQtGui.so.4 #19 0x0043cc99 in QApplication::notify () from /usr/lib/libQtGui.so.4 #20 0x086d8cd0 in lyx::frontend::GuiApplication::notify (this=0xa7ca080, receiver=0xa82d6c0, event=0xbf9bac28) at GuiApplication.cpp:284 #21 0x00b37cdb in QCoreApplication::notifyInternal () from /usr/lib/libQtCore.so.4 #22 0x00b5b51d in ?? () from /usr/lib/libQtCore.so.4 #23 0x00b58c80 in ?? () from /usr/lib/libQtCore.so.4 #24 0x07d7a0fc in g_main_context_dispatch () from /lib/libglib-2.0.so.0 #25 0x07d7d53f in ?? () from /lib/libglib-2.0.so.0 #26 0x07d7daa5 in g_main_context_iteration () from /lib/libglib-2.0.so.0 #27 0x00b591e8 in QEventDispatcherGlib::processEvents () from /usr/lib/libQtCore.so.4 #28 0x004afff5 in ?? () from /usr/lib/libQtGui.so.4 #29 0x00b37201 in QEventLoop::processEvents () from /usr/lib/libQtCore.so.4 #30 0x00b3730c in QEventLoop::exec () from /usr/lib/libQtCore.so.4 #31 0x00b396aa in QCoreApplication::exec () from /usr/lib/libQtCore.so.4 #32 0x00436357 in QApplication::exec () from /usr/lib/libQtGui.so.4 #33 0x086d7fb8 in lyx::frontend::GuiApplication::exec (this=0xa7ca080) at GuiApplication.cpp:205 #34 0x0813ff3b in lyx::LyX::exec (this=0xbf9bb73c, [EMAIL PROTECTED], argv=0xbf9bb7f4) at LyX.cpp:484 #35 0x0806f5f2 in main (argc=1, argv=) at main.cpp:48
Re: external boost crashes lyx on startup
José Matos [EMAIL PROTECTED] writes: Hi, when compiling lyx with external boost when I start lyx it immediately crashes. The backtrace follows attached. Any suggestion? Lokks again like a missing config.h. Does disabling pch change something? JMarc
Re: external boost crashes lyx on startup
On Friday 21 September 2007 11:47:26 Jean-Marc Lasgouttes wrote: Lokks again like a missing config.h. Does disabling pch change something? This is already with --disable-pch. JMarc -- José Abílio
Re: LyX svn crashes on ViewPDF (pdflatex)
Roger Mc Murtrie wrote: Excellent shot in the dark. Adding #include boost/config.hpp at the top of the original regex/ src/pch.h file fixes the problem. Great. Jean-Marc, can you please commit this to branch? The bug in question is http://bugzilla.lyx.org/show_bug.cgi?id=4014 Jürgen
Re: external boost crashes lyx on startup
José Matos [EMAIL PROTECTED] writes: On Friday 21 September 2007 11:47:26 Jean-Marc Lasgouttes wrote: Lokks again like a missing config.h. Does disabling pch change something? This is already with --disable-pch. It seems that there are a few files in trunk that do not include config.h as first header, but I do not think it is related: pegase: grep -r -m1 '^#include' src |grep '\.c'|grep -v config.h src/support/tests/check_filetools.cpp:#include ../filetools.h src/support/minizip/ioapi.c:#include stdio.h src/support/minizip/zip.c:#include stdio.h src/support/minizip/unzip.c:#include stdio.h src/support/minizip/iowin32.c:#include stdlib.h src/tex2lyx/lengthcommon.cpp:#include ../lengthcommon.cpp [the last one is clearly OK] I think we should fix them nevertheless. JMarc
[PATCH] uninitialized variable
Juergen, gcc complains about this variable, and I think it is right. Shall I apply to branch and trunk? JMarc svndiff src/LaTeX.cpp Index: src/LaTeX.cpp === --- src/LaTeX.cpp (révision 20408) +++ src/LaTeX.cpp (copie de travail) @@ -610,7 +610,7 @@ int LaTeX::scanLogFile(TeXErrors terr) LYXERR(Debug::LATEX) Log file: tmp endl; FileName const fn = FileName(makeAbsPath(tmp)); ifstream ifs(fn.toFilesystemEncoding().c_str()); - bool fle_style; + bool fle_style = false; static regex file_line_error(.+\\.\\D+:[0-9]+: (.+)); string token;
Re: LyX svn crashes on ViewPDF (pdflatex)
Juergen Spitzmueller [EMAIL PROTECTED] writes: Great. Jean-Marc, can you please commit this to branch? The bug in question is http://bugzilla.lyx.org/show_bug.cgi?id=4014 Done. JMarc
Re: [patch] bug 3133: Beamer layout: change the title slide layout
Juergen Spitzmueller [EMAIL PROTECTED] writes: http://bugzilla.lyx.org/show_bug.cgi?id=3133 The attached patch adds a Title (Plain Frame) style that can be used instead of Title to get a plain title frame (no head-/footlines and navigation bars). This is somewhat hackish, as a big part of the beamer implementation in LyX is, but it's as good as it gets, IMHO, since we only can define TitleLaTeXName once currently. Comments? \makelyxbeamertitle is an horrible name... \lyxbeamermaketitle would be better, but I think you can at least drop 'lyx' or 'beamer' from there. Otherwise, it is very slightly less hackish than it was :) JMarc
Re: Installing libraries
Andre Poenitz [EMAIL PROTECTED] writes: Yes. We can do that. Should even. Tell me what to do... First, replace all instances of pkglib_LTLIBRARIES by noinst_LTLIBRARIES. I did not find where you set static/shared depending on the platform, but you should add a test for '$lyx_devel_version = yes' there. JMarc
Re: [Cvslog] r20130 - in /lyx-devel/trunk/po: Makefile.in.in postats.py
[EMAIL PROTECTED] writes: Author: jamatos Date: Fri Sep 7 18:37:38 2007 New Revision: 20130 URL: http://www.lyx.org/trac/changeset/20130 Log: Convert postats to python Juergen, can I apply that to 1.5 too? It is only a maintainer tool. JMarc
Re: [PATCH] fix M-Return
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes: Actually, it could be renamed to something like break-paragraph-special, or an 'inverse' option could be added to break-paragraph. Yes, the current name is certainly misleading. I would prefer to merge the two lfuns and add an option (I don't like inverse. How about parentlayout?). parentlayout is definitely wrong, I really want to convey the idea 'do it, but differently as you would do by default'. Ideas include: break-paragraph special break-paragraph inverse break-paragraph alt break-paragraph 1 So, what name shall I give to this thing? JMarc
Re: [Cvslog] r20366 - in /lyx-devel/trunk: lib/bind/cua.bind src/LyXAc...
[EMAIL PROTECTED] writes: Author: rgheck Date: Thu Sep 20 07:00:23 2007 New Revision: 20366 URL: http://www.lyx.org/trac/changeset/20366 Log: Introduce LFUN_MASTER_BUFFER_VIEW and UPDATE. Code by Tommaso Cucinotta. Modified: lyx-devel/trunk/lib/bind/cua.bind lyx-devel/trunk/src/LyXAction.cpp lyx-devel/trunk/src/LyXFunc.cpp lyx-devel/trunk/src/lfuns.h Bennett, you will not that mac.bind has not been updated. Feel free to provide bindings of your own. JMarc
Re: [Patch#4] Bug 3527 - Basic PDF support via hyperref
1. view source dialog is still broken (Can not update). Can anyone fix it? i will look. ahh, i misread your post thinking that pdf stuff broke source dialog, which is not the case. seems ControlViewSource::updateContent is not entered at all. pavel
Re: [PATCH] uninitialized variable
Juergen Spitzmueller [EMAIL PROTECTED] writes: Jean-Marc Lasgouttes wrote: Juergen, gcc complains about this variable, and I think it is right. Shall I apply to branch and trunk? Yes, please. Done. JMarc
postat.py bug? (was Re: [Cvslog] r20130 - in /lyx-devel/trunk/po: Makefile.in.in postats.py)
Juergen Spitzmueller [EMAIL PROTECTED] writes: Jean-Marc Lasgouttes wrote: Juergen, can I apply that to 1.5 too? It is only a maintainer tool. Sure. Jose, now that I try it, it seems that it does not work at all :) pegase: python postats.py fr.po ?php // The current version \$lyx_version = 1.6.0svn; // The branch tag \$branch_tag = trunk; // The data itself \$podata = array ( array ( 'langcode' = 'fr', date = 2007-07-18, msg_tr = 0, msg_fu = 0, msg_nt = 0, translator = Adrien Rebollo, email = [EMAIL PROTECTED]) )? First, why these '\$' instead of '$'? Second, all numbers are set to 0... Did you actually test it? JMarc
Re: [Cvslog] r20406 - in /lyx-devel/trunk/src: PDFOptions.cpp PDFOptio...
-void PDFOptions::writeLaTeX(odocstream os) const +void PDFOptions::writeLaTeX(odocstringstream os) const Why? my fault. PDFOptions::writeLaTeX is called with odocstringstream param elsewhere and when we were haunting strange bug yesterday i was not sure whether this couldnt make some side-effects i'm unaware. pavel
Re: Installing libraries (was: Re: Small puzzle.)
On Fri, Sep 21, 2007 at 02:13:55AM +0200, Andre Poenitz wrote: On Thu, Sep 20, 2007 at 02:23:28PM +0200, Enrico Forestieri wrote: What about deciding that we do not install the libraries? Of course, this would imply that an installable LyX is a static one, but I am not sure we care much about distributing dynamic versions anyway. We could for example decide that shared is turned on only for development unix builds. Agreed. And I am not even sure of the usefulness of a dynamic build when you gain 15 seconds or so. static: touch Text.cpp time make: real1m4.922s user0m8.145s sys 0m2.404s dynamic: touch Text.cpp time make: real0m27.072s user0m15.045s sys 0m1.552s Thank you for demonstrating that a dynamic build is slower than a static one. Indeed, the real field gives the elapsed (real) time between invocation of the command and its termination. This means that it is a varying quantity depending on the system load. The useful information comes from the user and sys fields and their sum demonstrates that a static build is faster. So it reduces simple roundtrip times byh more than a factor of 2. Try again. Hrmpf. -- Enrico
Re: [patch] bug 3133: Beamer layout: change the title slide layout
Jean-Marc Lasgouttes wrote: \makelyxbeamertitle is an horrible name... \lyxbeamermaketitle would be better, but I think you can at least drop 'lyx' or 'beamer' from there. Fine. I just wanted to make sure that we are on the safe side, if Till Tantau decides to implement a \beamermaketitle command. I'll rename it. Otherwise, it is very slightly less hackish than it was :) In the context of the beamer layout, it's not very much hackish indeed ... Jürgen
Re: [PATCH] uninitialized variable
Jean-Marc Lasgouttes wrote: Juergen, gcc complains about this variable, and I think it is right. Shall I apply to branch and trunk? Yes, please. Jürgen
Re: [Cvslog] r20130 - in /lyx-devel/trunk/po: Makefile.in.in postats.py
Jean-Marc Lasgouttes wrote: Juergen, can I apply that to 1.5 too? It is only a maintainer tool. Sure. Jürgen
Re: [PATCH] fix M-Return
Jean-Marc Lasgouttes wrote: Ideas include: break-paragraph special break-paragraph inverse break-paragraph alt break-paragraph 1 So, what name shall I give to this thing? From these, inverse is surely the least confusing one. Jürgen
Re: [PATCH] fix M-Return
Juergen Spitzmueller [EMAIL PROTECTED] writes:
So, what name shall I give to this thing?
From these, inverse is surely the least confusing one.
So this patch would be OK for trunk and branch?
JMarc
svndiff src lib/bind
Index: src/LyXAction.cpp
===
--- src/LyXAction.cpp (révision 20407)
+++ src/LyXAction.cpp (copie de travail)
@@ -105,7 +105,6 @@ void LyXAction::init()
{ LFUN_BOOKMARK_CLEAR, bookmark-clear, NoBuffer },
{ LFUN_BREAK_LINE, break-line, Noop },
{ LFUN_BREAK_PARAGRAPH, break-paragraph, Noop },
- { LFUN_BREAK_PARAGRAPH_KEEP_LAYOUT, break-paragraph-keep-layout, Noop },
{ LFUN_BREAK_PARAGRAPH_SKIP, break-paragraph-skip, Noop },
{ LFUN_BUILD_PROGRAM, build-program, ReadOnly },
{ LFUN_BUFFER_AUTO_SAVE, buffer-auto-save, Noop },
Index: src/insets/InsetCaption.cpp
===
--- src/insets/InsetCaption.cpp (révision 20407)
+++ src/insets/InsetCaption.cpp (copie de travail)
@@ -195,7 +195,6 @@ bool InsetCaption::getStatus(Cursor cu
switch (cmd.action) {
case LFUN_BREAK_PARAGRAPH:
- case LFUN_BREAK_PARAGRAPH_KEEP_LAYOUT:
case LFUN_BREAK_PARAGRAPH_SKIP:
status.enabled(false);
return true;
Index: src/insets/InsetFlex.cpp
===
--- src/insets/InsetFlex.cpp (révision 20407)
+++ src/insets/InsetFlex.cpp (copie de travail)
@@ -137,7 +137,6 @@ bool InsetFlex::getStatus(Cursor cur,
switch (cmd.action) {
// paragraph breaks not allowed in flex insets
case LFUN_BREAK_PARAGRAPH:
- case LFUN_BREAK_PARAGRAPH_KEEP_LAYOUT:
case LFUN_BREAK_PARAGRAPH_SKIP:
status.enabled(false);
return true;
Index: src/insets/InsetTabular.cpp
===
--- src/insets/InsetTabular.cpp (révision 20407)
+++ src/insets/InsetTabular.cpp (copie de travail)
@@ -3734,7 +3734,6 @@ bool InsetTabular::getStatus(Cursor cu
// disable in non-fixed-width cells
case LFUN_BREAK_LINE:
case LFUN_BREAK_PARAGRAPH:
- case LFUN_BREAK_PARAGRAPH_KEEP_LAYOUT:
case LFUN_BREAK_PARAGRAPH_SKIP: {
if (tabular.getPWidth(cur.idx()).zero()) {
status.enabled(false);
Index: src/Text.cpp
===
--- src/Text.cpp (révision 20407)
+++ src/Text.cpp (copie de travail)
@@ -356,7 +356,7 @@ double Text::spacing(Buffer const buff
}
-void Text::breakParagraph(Cursor cur, bool keep_layout)
+void Text::breakParagraph(Cursor cur, bool inverse_logic)
{
BOOST_ASSERT(this == cur.text());
@@ -381,11 +381,9 @@ void Text::breakParagraph(Cursor cur,
cpar.eraseChar(cur.pos(), cur.buffer().params().trackChanges);
// What should the layout for the new paragraph be?
- int preserve_layout = 0;
- if (keep_layout)
- preserve_layout = 2;
- else
- preserve_layout = layout-isEnvironment();
+ bool keep_layout = inverse_logic ?
+ !layout-isEnvironment()
+ : layout-isEnvironment();
// We need to remember this before we break the paragraph, because
// that invalidates the layout variable
@@ -395,7 +393,7 @@ void Text::breakParagraph(Cursor cur,
bool const isempty = cpar.allowEmpty() cpar.empty();
lyx::breakParagraph(cur.buffer().params(), paragraphs(), cpit,
- cur.pos(), preserve_layout);
+ cur.pos(), keep_layout);
// After this, neither paragraph contains any rows!
Index: src/Text3.cpp
===
--- src/Text3.cpp (révision 20407)
+++ src/Text3.cpp (copie de travail)
@@ -573,13 +573,7 @@ void Text::dispatch(Cursor cur, FuncRe
case LFUN_BREAK_PARAGRAPH:
cap::replaceSelection(cur);
- breakParagraph(cur, false);
- cur.resetAnchor();
- break;
-
- case LFUN_BREAK_PARAGRAPH_KEEP_LAYOUT:
- cap::replaceSelection(cur);
- breakParagraph(cur, true);
+ breakParagraph(cur, cmd.argument() == inverse);
cur.resetAnchor();
break;
@@ -1860,7 +1854,6 @@ bool Text::getStatus(Cursor cur, FuncR
case LFUN_CHAR_DELETE_BACKWARD:
case LFUN_DELETE_BACKWARD_SKIP:
case LFUN_BREAK_PARAGRAPH:
- case LFUN_BREAK_PARAGRAPH_KEEP_LAYOUT:
case LFUN_BREAK_PARAGRAPH_SKIP:
case LFUN_PARAGRAPH_SPACING:
case LFUN_INSET_INSERT:
Index: src/paragraph_funcs.h
===
--- src/paragraph_funcs.h (révision 20407)
+++ src/paragraph_funcs.h (copie de travail)
@@ -27,9 +27,9 @@ class ParagraphList;
/**
* This breaks a paragraph at the specified position.
* The new paragraph will:
- * get the default layout, when flag == 0
- * will inherit the existing one, except for depth, when flag == 1
- * will inherit the existing one, including depth, when flag == 2
+ * - Decrease depth by one (or chenge layout to default layout when
+ *keep_layout == false
+ * - keep current depth and layout when keep_layout == true
* Be aware that the old or new paragraph does not contain any
Re: postat.py bug? (was Re: [Cvslog] r20130 - in /lyx-devel/trunk/po: Makefile.in.in postats.py)
On Friday 21 September 2007 14:40:11 Jean-Marc Lasgouttes wrote: Juergen Spitzmueller [EMAIL PROTECTED] writes: Jean-Marc Lasgouttes wrote: Juergen, can I apply that to 1.5 too? It is only a maintainer tool. Sure. Jose, now that I try it, it seems that it does not work at all :) pegase: python postats.py fr.po ?php // The current version \$lyx_version = 1.6.0svn; // The branch tag \$branch_tag = trunk; // The data itself \$podata = array ( array ( 'langcode' = 'fr', date = 2007-07-18, msg_tr = 0, msg_fu = 0, msg_nt = 0, translator = Adrien Rebollo, email = [EMAIL PROTECTED]) )? First, why these '\$' instead of '$'? That was a direct cut and paste. Fixed. Second, all numbers are set to 0... This is what I get: [EMAIL PROTECTED] po]$ python postats.py fr.po ?php // The current version $lyx_version = 1.6.0svn; // The branch tag $branch_tag = trunk; // The data itself $podata = array ( array ( 'langcode' = 'fr', date = 2007-07-18, msg_tr = 2402, msg_fu = 728, msg_nt = 487, translator = Adrien Rebollo, email = [EMAIL PROTECTED]) )? Did you actually test it? JMarc -- José Abílio
Re: postat.py bug?
José Matos [EMAIL PROTECTED] writes: That was a direct cut and paste. Fixed. Thanks. This is what I get: Yes, but you are probably aware that: pegase: msgfmt --statistics -o fr.gmo fr.po 2402 messages traduits, 728 traductions approximatives, 487 messages non-traduits. You need to reset the locale. JMarc
Re: cross referencing sections
On Fri, 21 Sep 2007, Helge Hafting wrote: [EMAIL PROTECTED] wrote: On Tue, 18 Sep 2007, Yann Disser wrote: It would be nice if you considered implementing the possibility of cross-referencing to sections etc without the need of inserting ugly labels - the use of labels should in my opinion be reduced to an absolute minimum. My works are often full of labels for cross-referencing to other parts of themselves (and equations and figures and tables etc). This makes the text less readable. Similar issues were discussed a while back. So as a user, I think your input would be appreciated. What's your tought on thinks like these: * Is the problem that the labels are shown, or that they exist? For me, the problem is the hassle of having to insert them. This is very occationally useful. Hi Helge, I agree, having to insert and having to come up with a name. snip No need - make LyX work (mostly) without inserted labels. LyX can autogenerate a latex label during latex code export, when some entity happens to have a reference. I haven't thought about it yet, but would this work with a multi-file document? Isn't it a problem if label names are regenerated all the time? I'm also worried about silent errors, where a reference suddenly goes to a completely different label that suddenly happens to have matching name. * How do you envison a user referring to a section? This is the case when cross-referencing it without (exlicitly) using a label. Insert-reference, using the normal dialog. But now the dialog will list every referable entity in the entire document. I.e. all headings, enumerations and so on. Hmm... I'm not sure how you'd list an entity such as an enumeration..? When I asked the question, I actually had another idea that I didn't mention so as to be impartial. The user would have the dialog for inserting references open, but be able to navigate the document and 'drag' a label into the document at the desired location. Alternatively, he could place the cursor at the desired location and press a button in the dialog that says something like Insert label at cursor location. With a ToC dialog automatically popped up, I was hoping that navigating to a specific section would be very quick. To be really useful, the name of the label should be created automatically. * Is it problematic having to come up with names for the labels? * If labels are generated automatically, how should they get their name? A LyX user won't see the label name at all, so it doesn't matter much. For the benefit of latex users, perhaps some simple scheme based on category, i.e. sect1, sect2, subsect5, part9, enum12, formula67, ... * What should happen if for instance a label is automatically inserted in a section heading based on the title of that heading, and the heading is subsequently deleted? You can do that today with manual labels, and LyX will then leave a xref to a label that doesn't exist. Latex will then print ??. I wouldn't want auto-deletion of the xref, as I might want to paste that heading somewhere else and still have it referenced. I don't understand: as I might want to paste that heading somewhere else and still have it referenced. Does this imply that the hidden label in the part that was cut should keep it's automatically generated label? Or even worse, if that section is deleted and another section is created later that happen to have the same heading? I think an auto-label should behave very much like an explicit label, except that you don't actally see it. Well, LyX could put a tiny label icon in the margin next to the heading to indicate the fact. It might be useful, and won't clutter up the main window. A small icon is a good idea. Then, clicking on this icon could take you to the cross reference. Or pop up a dialog with several cross references to choose from. So, if the section is deleted, the label dies with it. If it is pasted once, then the autolabel is pasted too. If it is pasted more, then LyX should refrain from creating an identical label. The easy way is to just drop the label then. The advanced way will be to check if a reference exists inside the pasted content, and then create a new label/reference pair. (Similiar to how spreadsheets paste formulas with cell references.) But this part can wait, it is only UI refinement. Finally, if a section is created manually with identical text to some previous section, then of course no label is created. I think the user might get a bit confused in this last example. What about the following scenario: * I have a section 'A' that I refer to from section 'B'. * I remove section 'A'. * I (manually) write a new section 'A' with the same text, perhaps in a new location. There is now a xref in section B that's not working. I click on it and ... what will the dialog tell me? To where is it referring? If the label name can
Re: [Patch#4] Bug 3527 - Basic PDF support via hyperref
Pavel Sanda wrote: 1. view source dialog is still broken (Can not update). Can anyone fix it? i will look. ahh, i misread your post thinking that pdf stuff broke source dialog, which is not the case. seems ControlViewSource::updateContent is not entered at all. This is probably a problem similar to one I've seen elsewhere. Andre's kill-the-controller changes caused certain functions which had previously been virtual to become non-virtual, with the result that they are never called. I'll guess that's what's happening here, too, though it may not be updateContent() that is the ultimate root of the problem. Richard pavel
Re: InsetCommand[Params]
Juergen Spitzmueller wrote:
Richard Heck wrote:
I'm looking now at re-working some of the code surrounding InsetCommand
and its derivatives. The motivation here is, ultimately, BibLaTeX
support
\begin{praise}
You're going to make me blush.
Richard
Re: [PATCH] Remove LFUN_FONT_CODE
Martin Vermeer wrote:
However, this is othogonal to the
discussion about changing fonts to insets (although I am not a
proponent of this change, as some people know).
Yes, what I was trying to argue is that I am against that too. Reason:
it adds one extra layer of complexity in-between, for no good reason
that I can see.
OK. At least we're clear now what the issue is. (I agree completely
about the need to separate fonts from charstyles, of course.) But here's
what's moving me: Turning fonts into insets solves all kinds of problems
involving nesting, as well as problems involving communication with the
user. As things are, it can be very hard to tell where font changes
begin and where they end, indeed, even where they are in effect and
where they are not (emph plus ital, e.g.). And the possibility of
constructs like the one Martin mentioned earlier:
ab{ab[cd}ef]
where the brackets indicate font changes, causes nasty complexities in
the code. Plus, there are bugs related to the fact that
a[{bc}]d
and
a{[bc]}d
either can't be told apart or get forced one way or the other by magic.
And maybe we even see this monstrosity:
a{[bc}]d
True, there may be other ways to solve those problems, but I guess I'd
like to see or hear what they are.
And by the way, if the User's Guide is---as I believe it is---using
hard-coded font changes for things like menu items, that should be
changed to charstyles. At least we can show new users, by example, the
right way to do things.
Richard
Re: InsetCommand[Params]
Jean-Marc Lasgouttes wrote: What I'm suggesting is that command insets should behave the same way. So we'd have: \begin_inset Citation command citet key etctec \end_inset More or less. This looks reasonable, in general. A question: how will the parser know that this is an insetcommand? Still hardcoded? More or less, yes. The action here is in readInset() in factory.cpp. At the moment, there's a special branch for command insets: ones where you see \begin_inset LatexCommand. Having the separate branch is useful but, so far as I can see, not essential, and if we want to keep it, we can just check against a list of the command insets first before entering the long if..else if..else construct. Alternatively, we could have a form like this: \begin_inset CommandInset citation command citet key etctec \end_inset Speaking of which, I realized that all the inset types already have been given names in the giant translator in Inset.cpp. So I'll use those. What it'd be really nice to do is something like this: insetName = string-following-\begin_inset; foreach insetType if insetType-name() == insetName; newInset = insetType(..) But there's no natural way to recurse through the inset types in C++, is there? Richard
Re: InsetCommand[Params]
Georg Baum wrote: The bad news is that this change will require one controller class for each inset. Currently there is only one command controller, used by all command insets. That is the only reason I did not do this change already during the InsetCommandParams rewrite. Sorry, could you explain this? I'm not sure I understand which part of what I'm proposing affects the frontend. It's not that I'm skeptical. I just don't immediately see why, e.g., GuiBibitem can't still use ControlCommand. And GuiCitation already has its own controller. InsetCommandParams/InsetCommand is in a state of flux: The goal was to decouple the children of InsetCommand from LaTeX, use the name/value interface exlusively in LyX, and concentrate all LaTeX stuff in InsetCommandParams. This was not finished because of the freeze. IMHO the legacy code using the old interface (marked withg FIXME remove) should be converted to the new one. That alone gets rid of quite a bit of ugly code. Yes, in fact, I kind of got started on this when I was looking at removing the legacy code---something you and I discussed a while ago. Most of that is concentrated in InsetInclude now, which is the only inset that still uses the old format. (There are a handful of remnants elsewhere, they're easily replaced.) Unfortunately, when Bo did the listings include, he of course used the old interface, since that's what InsetInclude uses, and so things are slightly worse than they were before. But not terribly. Another planned, but not implemented bit is support for keyval options (currently not used): An inset does not need to know that they need to be exported to TeX as [a=A,b=B]. It could use the same existing interface for setting/getting these options in InsetCommandParams. Only in the definition of the inset (currently in InsetCommandParams.cpp, but it should be straightforward to read this info from a text file) the type of these parameters would be specified. Then you would never need to parse a a=A,b=B string (which is quite complicated if you want to do it correctly with escaping), because in .lyx files these values would be written as separate parameters. Yes, this would be very useful indeed. There's been some discussion of this in connection with listings, the new hyperref support, etc, namely: If you have a whole ton of optional arguments, what's a decent UI? The backend support is simple enough. Richard
Re: [PATCH] Remove LFUN_FONT_CODE
Richard Heck [EMAIL PROTECTED] writes: OK. At least we're clear now what the issue is. (I agree completely about the need to separate fonts from charstyles, of course.) But here's what's moving me: Turning fonts into insets solves all kinds of problems involving nesting, as well as problems involving communication with the user. But unfortunately, the nest-all approach complicates the use wrt font-painting for no gain in 90% of the cases (IMO). BTW, you should try to grep for font-code in lib/bind... JMarc
Re: postat.py bug?
On Friday 21 September 2007 15:03:23 Jean-Marc Lasgouttes wrote: Yes, but you are probably aware that: pegase: msgfmt --statistics -o fr.gmo fr.po 2402 messages traduits, 728 traductions approximatives, 487 messages non-traduits. I was not aware. You need to reset the locale. Sure the reason that postats.sh gave was different, and incorrect at least for modern systems. I will fix this next week. JMarc -- José Abílio
Re: cross referencing sections
[EMAIL PROTECTED] wrote: On Fri, 21 Sep 2007, Helge Hafting wrote: For me, the problem is the hassle of having to insert them. This is very occationally useful. Hi Helge, I agree, having to insert and having to come up with a name. Hello to both, When you're done with the discussion, please write down everything you come up with. When a design is agreed on and properly described somewhere, I'll help make this feature a reality. Abdel.
Re: [Patch#4] Bug 3527 - Basic PDF support via hyperref
Pavel, please attach patches the next time as unified diff as email attachment, this makes life much easier. This seems to be our popular issue :) Of course, because I cannot apply your patches but has to copy and paste them manually. And I meant that whitespace issues can be avoided when you attach large patches to your post instead of sending them in the mail. (OK, there is an attachment limit of about 50 kB or so.) AFAIK this patch was unified. There maybe some special parameter for Windows version of svn, to make equivalent of unix patch --strip 1? SVN is platform independent. The LyX development guideline says that patchs should be in unified format, see the Intro manual. So why not just use diff -u or directly the SVN programm to create diffs? ps: Uwe, is the following patch usable by your svn ? No, see the attached image. regards Uwe inline: SNV-Error.png
Re: cross referencing sections
Hi, I agree with Christian's objections/comments in general. What would be the problem of having normal labels automatically inserted by LyX when one refers to a section etc in an appropriately enhanced insert-cross-reference dialog? In this way, 1) one doesn't have to insert them manually 2) LyX comes up with a good name 3) no artificial strange copy-paste semantics is needed, they are just normal labels. Additionally, a) an easy way to go to referers of a label and b) missing label latex warnings being catch by the errorlist, would make working with cross references much nicer. Sorry if some/everything of this was already proposed :-} A/
Re: InsetCommand[Params]
Richard Heck wrote: Georg Baum wrote: The bad news is that this change will require one controller class for each inset. Currently there is only one command controller, used by all command insets. That is the only reason I did not do this change already during the InsetCommandParams rewrite. Sorry, could you explain this? I'm not sure I understand which part of what I'm proposing affects the frontend. The connection lies in the Mailer interface: Every inset that needs to pass data between kernel and frontend has a mailer, and this mailer exchanges the data in the same format that is used in .lyx files and naturally uses the same classes to read and write this data (in this case InsetCommandParams). Since the inset name is part of the mailer interface you would need a new mailer and a new controller if you changed the inset name to individual names. Maybe it would also be possible to change InsetCommandMailer to recognize the other names. I don't think so, but I do remember this only vaguely. It's not that I'm skeptical. I just don't immediately see why, e.g., GuiBibitem can't still use ControlCommand. And GuiCitation already has its own controller. Yes, some insets already have their own controller, but currently that is not required. Most of that is concentrated in InsetInclude now, which is the only inset that still uses the old format. (There are a handful of remnants elsewhere, they're easily replaced.) Unfortunately, when Bo did the listings include, he of course used the old interface, since that's what InsetInclude uses, and so things are slightly worse than they were before. But not terribly. That's what always happens with compatibility layers: You can write in big red letters not to use them for new stuff, but if they exist they get used. Yes, this would be very useful indeed. There's been some discussion of this in connection with listings, the new hyperref support, etc, namely: If you have a whole ton of optional arguments, what's a decent UI? The backend support is simple enough. The most important ones should probably be handled individually, but for the not so important ones it should be simple, e.g. a listbox and a text edit: The listbox contains all argument names, and if you select one the corresponding value appears in the text edit. The only problem with this approach is that in some cases there is a difference between an empty parameter and a parameter that is not given at all. But this could be solved with two listboxes: Onwe contains all possible parameters , and the other one contains the selected ones (similar to the citation dialog). If you want to be really fancy you could associate a type to each parameter (string, integer, LaTeX length etc), and instead of a text edit the input field would change dynamically to a sepcialized one for that type. Georg
Re: cross referencing sections
Alfredo Braunstein wrote: Hi, I agree with Christian's objections/comments in general. What would be the problem of having normal labels automatically inserted by LyX when one refers to a section etc in an appropriately enhanced insert-cross-reference dialog? In this way, 1) one doesn't have to insert them manually 2) LyX comes up with a good name 3) no artificial strange copy-paste semantics is needed, they are just normal labels. Additionally, a) an easy way to go to referers of a label and b) missing label latex warnings being catch by the errorlist, would make working with cross references much nicer. Let me just add my agreement with this proposal. And if it's a problem, as I know it is in part, that labels get annoying to look at, surely it'd be possible to display the labels differently from how we now do, say, as little icons, and then you mouse over it and see what's in it, or you click on it and it changes form (like collapsable insets will), or whatever. So this looks to me like a great combination of all the proposals. 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: r20420 [1/2] - in /lyx-devel/trunk/src: BufferView.cpp Pa...
[EMAIL PROTECTED] wrote: Author: younes Date: Fri Sep 21 22:39:47 2007 New Revision: 20420 URL: http://www.lyx.org/trac/changeset/20420 Log: * Inset: - get rid of the cached Dimension. Text inset dimensions are saved in ParagraphMetrics and mathed maintain their own dimension where needed. - width(), ascent(), descent(): deleted. - dimension(): now needs a valid BufferView. - metrics(): now void. * BufferView::getCoveringInset(): simplify. * ParagraphMetrics(): now cache inset dimensions. Dear Martin, I am sorry but I'm affraid I broke InsetCollapsable (again!) for SubLabel and Corner. If you tell me how to test these I'll fix them. Sorry about that, Abdel.
Re: [Patch#4] Bug 3527 - Basic PDF support via hyperref
Pavel, please attach patches the next time as unified diff as email attachment, this makes life much easier. This seems to be our popular issue :) Of course, because I cannot apply your patches but has to copy and paste them manually. I'm sorry about that. And I meant that whitespace issues can be avoided when you attach large patches to your post instead of sending them in the mail. I _do_ send them as an attachment _always_. If some web archives corrupt it, its not my fault. But I can CC you which should solve this issue. AFAIK this patch was unified. There maybe some special parameter for Windows version of svn, to make equivalent of unix patch --strip 1? SVN is platform independent. The LyX development guideline says that patchs should be in unified format, see the Intro manual. So why not just use diff -u ? I have already written and will continue to write, that the original patch _was_ in unified format and thus I'm not violating LyX guidelines. That Index line you demand is product of svn itself and has nothing to do with diff unified format. I guess that Tortoise svn will swear even if I send plain diff -u. But lets try - does your svn eat the patch I am sending now ? or directly the SVN programm to create diffs? Because I don't use it. Pavel diff -ur /installer/lyx/trunk/src/frontends/qt4/ui/PDFSupportUi.ui ./src/frontends/qt4/ui/PDFSupportUi.ui --- /installer/lyx/trunk/src/frontends/qt4/ui/PDFSupportUi.ui 2007-09-21 03:31:33.0 +0200 +++ ./src/frontends/qt4/ui/PDFSupportUi.ui 2007-09-21 23:29:28.0 +0200 @@ -232,7 +232,7 @@ property name=geometry rect x10/x - y360/y + y340/y width431/width height51/height /rect
Re: [Patch#4] Bug 3527 - Basic PDF support via hyperref
I _do_ send them as an attachment _always_. If some web archives corrupt it, its not my fault. But I can CC you which should solve this issue. I guess you have the same problem as Abdel once had. Your attachment should be coded as attachment. Cheers, Bo
Re: r20420 [1/2] - in /lyx-devel/trunk/src: BufferView.cpp Pa...
Abdelrazak Younes wrote: [EMAIL PROTECTED] wrote: Author: younes Date: Fri Sep 21 22:39:47 2007 New Revision: 20420 URL: http://www.lyx.org/trac/changeset/20420 Log: * Inset: - get rid of the cached Dimension. Text inset dimensions are saved in ParagraphMetrics and mathed maintain their own dimension where needed. - width(), ascent(), descent(): deleted. - dimension(): now needs a valid BufferView. - metrics(): now void. * BufferView::getCoveringInset(): simplify. * ParagraphMetrics(): now cache inset dimensions. I am sorry but I'm affraid I broke InsetCollapsable (again!) for SubLabel and Corner. If you tell me how to test these I'll fix them. Load the logicalmkup module in DocumentSettings. That will give you access to some charstyles. Using them will exercise those two geometries. 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] Remove LFUN_FONT_CODE
Jean-Marc Lasgouttes wrote: But unfortunately, the nest-all approach complicates the use wrt font-painting for no gain in 90% of the cases (IMO). Well, I'm no expert whatsoever on that. I stay as far from painting as possible. BTW, you should try to grep for font-code in lib/bind... Did. 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#4] Bug 3527 - Basic PDF support via hyperref
I _do_ send them as an attachment _always_. If some web archives corrupt it, its not my fault. But I can CC you which should solve this issue. I guess you have the same problem as Abdel once had. Your attachment should be coded as attachment. can you be more verbose what you mean or give me some link ? somehow i'm reluctant to believe that mutt would break any RFC. pavel
Re: [Patch#4] Bug 3527 - Basic PDF support via hyperref
Pavel Sanda wrote: or directly the SVN programm to create diffs? Because I don't use it. How do you update your tree then? Abdel.
Re: [Patch#4] Bug 3527 - Basic PDF support via hyperref
Pavel Sanda wrote: or directly the SVN programm to create diffs? Because I don't use it. How do you update your tree then? git-svn rebase pavel
Re: [Patch#4] Bug 3527 - Basic PDF support via hyperref
can you be more verbose what you mean or give me some link ? somehow i'm reluctant to believe that mutt would break any RFC. pavel http://marc.info/?t=11835435303r=1w=2 especially http://marc.info/?l=lyx-develm=118366121102662w=2 I would not blame mutt, but a line may be needed to muttrc to change the way it handles pure-text attachments. Bo
Re: [Patch#4] Bug 3527 - Basic PDF support via hyperref
can you be more verbose what you mean or give me some link ? somehow i'm reluctant to believe that mutt would break any RFC. pavel http://marc.info/?t=11835435303r=1w=2 especially http://marc.info/?l=lyx-develm=118366121102662w=2 I would not blame mutt, but a line may be needed to muttrc to change the way it handles pure-text attachments. when i look on my raw message in mailbox i see : --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=n.patch .. with corresponding Content-Type boundary in header. so its not inlined. i took the survey with the results that gmane and mail-list doesnt identify that while marc does. i will reread the thread from links above. pavel
Good processor for compiling LyX but not too power hungry?
Does anyone know roughly how long it takes to build LyX on a machine with one of these processors: * Core 2 Duo E4300 * AMD Athlon 64 X2 4000+ * AMD Athlon X2 BE-2400 (or BE-2350) The reason for my strange question is that I'm going to buy a server to have at home, and I'm using LyX development as my personal motivation for getting hardware that's more powerful than I really need... The server will act as my PVR, personal wiki, file server etc, but in addition I'm going to use it for LyX development. Compiling LyX will the most heavy task of the server. Actually, my plan is to install one or more virtual machines in it and then do LyX compilations there - so the next time Andre' breaks the build process, I'll give him an account and he can look at the problem directly. So, going back to my original question, does anyone have an estimate of the build time with these? A somewhat related question: Is a quad core an advantage when it comes to building LyX? Is the linking stage multi-threaded? As a side note, the server will be running 24/7, so to be environmentally friendly my favourite choice is the BE-2400, as it at most consumes 45W, and an idle server would only use about 60W. The question is if it's fast enough when it comes to building LyX. Regards, /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: [Patch#4] Bug 3527 - Basic PDF support via hyperref
Pavel Sanda schrieb: I _do_ send them as an attachment _always_. If some web archives corrupt it, its not my fault. But I can CC you which should solve this issue. Yes I see now that mail-archive.com has some problems recently. I have already written and will continue to write, that the original patch _was_ in unified format and thus I'm not violating LyX guidelines. That Index line you demand is product of svn itself and has nothing to do with diff unified format. I guess that Tortoise svn will swear even if I send plain diff -u. Yes, I see now. Since a long time I haven't used diff directly and thought SVN's diff is eaqual to 'diff -u'. Sorry for my noise. or directly the SVN programm to create diffs? Because I don't use it. But you already use it to check out the SVN repository. Working with SVN is the easiest way: You can change the files directly in the SVN repository and create there the diffs and patches. When you update the repository, your changes will be merged with the ones from SVN, so that your files and therefore patches will alwas be up to date. There are also graphical SVN tools avaliable that comes with diff tools, repository repair tools, etc. With them you also don't need to use a console and learn SVN commands. regards Uwe
Re: [Patch#4] Bug 3527 - Basic PDF support via hyperref
Uwe Stöhr wrote: But you already use it to check out the SVN repository. No, he's using git, which is a different kind of VCS. In this case, the advantage is that it's easy to maintain a local repository, to apply VC to your own work. To do that with svn, the easiest way is to create a branch, but then there are hassles with that. 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#4] Bug 3527 - Basic PDF support via hyperref
Pavel Sanda schrieb: I _do_ send them as an attachment _always_. If some web archives corrupt it, its not my fault. But I can CC you which should solve this issue. Yes I see now that mail-archive.com has some problems recently. I studied meanwhile why it is so; there is way how to bypass it through changing mime type. But if you are able (do you?) to read it correctly when I post the patch directly to your mail I would rather let it the way it is. or directly the SVN programm to create diffs? Because I don't use it. But you already use it to check out the SVN repository. No, I dont even touch the svn command. Working with SVN is the easiest way: You can change the files directly in the SVN repository and create there the diffs and patches. When you update the repository, your changes will be merged with the ones from SVN, so that your files and therefore patches will alwas be up to date. There are also graphical SVN tools avaliable that comes with diff tools, repository repair tools, etc. With them you also don't need to use a console and learn SVN commands. This is misunderstanding. I have something far better :) Anyway, as we want to cooperate, I will write some scripts that do the job and give me svn output for you. Howg. Pavel
Hyperref
I haven't looked into this in detail, but I strongly suspect that we do now need to do something about bug 2154. As JMarc warned, having \label commands inside \sections (e.g.) will cause LaTeX to choke when hyperref is loaded, in certain cases, crucially, when you also have a TOC. Abdel had a hackish fix for this in Text3.cpp, which is still noted there, but something more robust needs doing. 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: InsetCommand[Params]
Georg Baum wrote: Richard Heck wrote: Georg Baum wrote: The bad news is that this change will require one controller class for each inset. Currently there is only one command controller, used by all command insets. That is the only reason I did not do this change already during the InsetCommandParams rewrite. Sorry, could you explain this? I'm not sure I understand which part of what I'm proposing affects the frontend. The connection lies in the Mailer interface: Every inset that needs to pass data between kernel and frontend has a mailer, and this mailer exchanges the data in the same format that is used in .lyx files and naturally uses the same classes to read and write this data (in this case InsetCommandParams). Since the inset name is part of the mailer interface you would need a new mailer and a new controller if you changed the inset name to individual names. Maybe it would also be possible to change InsetCommandMailer to recognize the other names. I don't think so, but I do remember this only vaguely. OK, thanks. I'd certainly have overlooked that, at least initially. I think it is possible to get the mailer to do the work, though. This involves getting some consistency between dialog names and inset names, which isn't exactly wonderful, but I think it will be OK, at least initially. We'll see. Yes, this would be very useful indeed. There's been some discussion of this in connection with listings, the new hyperref support, etc, namely: If you have a whole ton of optional arguments, what's a decent UI? The backend support is simple enough. The most important ones should probably be handled individually, but for the not so important ones it should be simple, e.g. a listbox and a text edit: The listbox contains all argument names, and if you select one the corresponding value appears in the text edit. The only problem with this approach is that in some cases there is a difference between an empty parameter and a parameter that is not given at all. But this could be solved with two listboxes: Onwe contains all possible parameters , and the other one contains the selected ones (similar to the citation dialog). If you want to be really fancy you could associate a type to each parameter (string, integer, LaTeX length etc), and instead of a text edit the input field would change dynamically to a sepcialized one for that type. Good. I had somewhat similar ideas, and I think Edwin's been thinking about this kind of thing, too. I'm going to cc him on this, and Bo, in case they're still thinking about it. 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
Dead Code?
Inset * readInset(Lexer lex, Buffer const buf)
{
...
// test the different insets
if (tmptok == LatexCommand) {
lex.next();
string const cmdName = lex.getString();
lex.pushToken(cmdName);
...
} else if (cmdName == listofalgorithms) {
inset.reset(new InsetFloatList(algorithm));
} else if (cmdName == listoffigures) {
inset.reset(new InsetFloatList(figure));
} else if (cmdName == listoftables) {
inset.reset(new InsetFloatList(table));
So far as I can see, the above can never be reached, because float lists
don't appear in the form:
\begin_inset LatexCommand
but rather as:
\begin_inset FloatList figure
Is it there for some actual reason? Should it be removed, or should
InsetFloatList behave better?
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#4] Bug 3527 - Basic PDF support via hyperref
Concerning the current state of the PDF support: There are three remaining open issues: thanks for report. - the bookmark level field is not working: - No matter what you insert, it is converted to False or True. - There is also no default value (should be 1). - It is possible to enter there other characters than the allowed numbers 0-9. going to look on these. btw disagreement with your last fix - opt += (pdfborder ?'1':'0'); + opt += (pdfborder ?'0':'1'); havent tried but expect it will break elsewhere and also reverts the semantics. - The dialog is smaller than the form, see the attached image: The aditional options field and the right border are hidden. thats the patch we are flaming the whole day :) moreover, it wont be enough, as windows dialog seems to be rendered in slightly different size. - The placement of the hyperref call is not correct. E.g. we have to load it after the URL-package but before algorithm floats are defined. The list is long and it will take a while until we found out the correct position. For now it would help if you place the hyperref call before babel. you are the expert here. pavel
Re: [Patch#4] Bug 3527 - Basic PDF support via hyperref
- the bookmark level field is not working: - No matter what you insert, it is converted to False or True. my trunk is in complete rebuild and it will take years.. can you try this one ? - There is also no default value (should be 1). i regarded it as string, which can be empty, i.e. no default value. but we can change it if you disagree. - It is possible to enter there other characters than the allowed numbers 0-9. shouldn't be the user responsible ? pavel Index: src/PDFOptions.cpp === --- src/PDFOptions.cpp (revision 20426) +++ src/PDFOptions.cpp (working copy) @@ -60,7 +60,7 @@ os \\pdf_bookmarks convertstring(bookmarks) '\n'; os \\pdf_bookmarksnumbered convertstring(bookmarksnumbered) '\n'; os \\pdf_bookmarksopen convertstring(bookmarksopen) '\n'; - if (bookmarksopenlevel.empty()) + if (!bookmarksopenlevel.empty()) os \\pdf_bookmarksopenlevel \ bookmarksopenlevel \\n; os \\pdf_breaklinksconvertstring(breaklinks) '\n';
Re: [Patch#4] Bug 3527 - Basic PDF support via hyperref
- The dialog is smaller than the form, see the attached image: The aditional options field and the right border are hidden. your change make it work under win, but broke right box width under linux. so next iteration, diffed against last state. pavel Index: src/frontends/qt4/ui/PDFSupportUi.ui === --- src/frontends/qt4/ui/PDFSupportUi.ui(revision 20426) +++ src/frontends/qt4/ui/PDFSupportUi.ui(working copy) @@ -44,70 +44,92 @@ widget class=QGroupBox name=groupBox_4 property name=geometry rect - x220/x + x209/x y180/y - width210/width + width221/width height148/height /rect /property property name=title stringLinks/string /property - layout class=QGridLayout -property name=margin - number9/number + widget class=QCheckBox name=breaklinksCB +property name=geometry + rect + x11/x + y27/y + width188/width + height18/height + /rect /property -property name=spacing - number6/number +property name=toolTip + stringAllows link text to break across lines./string /property -item row=0 column=0 - widget class=QCheckBox name=breaklinksCB - property name=toolTip - stringAllows link text to break across lines./string - /property - property name=text - stringBreak links over lines/string - /property - /widget -/item -item row=2 column=0 - widget class=QCheckBox name=colorlinksCB - property name=text - stringColor links/string - /property - /widget -/item -item row=3 column=0 - widget class=QCheckBox name=backrefCB - property name=toolTip - stringAdds backlink text to the end of each item in the bibliography/string - /property - property name=text - stringamp;Bibliographical backreferences/string - /property - /widget -/item -item row=4 column=0 - widget class=QCheckBox name=pagebackrefCB - property name=toolTip - stringAdds backlink text to the end of each item in the bibliography/string - /property - property name=text - stringBackreference by paamp;ge number/string - /property - /widget -/item -item row=1 column=0 - widget class=QCheckBox name=pdfborderCB - property name=text - stringNo frames around links/string - /property - property name=tristate - boolfalse/bool - /property - /widget -/item - /layout +property name=text + stringBreak links over lines/string +/property + /widget + widget class=QCheckBox name=colorlinksCB +property name=geometry + rect + x11/x + y74/y + width188/width + height17/height + /rect +/property +property name=text + stringColor links/string +/property + /widget + widget class=QCheckBox name=backrefCB +property name=geometry + rect + x11/x + y97/y + width201/width + height17/height + /rect +/property +property name=toolTip + stringAdds backlink text to the end of each item in the bibliography/string +/property +property name=text + stringamp;Bibliographical backreferences/string +/property + /widget + widget class=QCheckBox name=pagebackrefCB +property name=geometry + rect + x11/x + y120/y + width201/width + height17/height + /rect +/property +property name=toolTip + stringAdds backlink text to the end of each item in the bibliography/string +/property +property name=text + stringBackreference by paamp;ge number/string +/property + /widget + widget class=QCheckBox name=pdfborderCB +property name=geometry + rect + x11/x + y51/y + width188/width + height17/height + /rect +/property +property name=text + stringNo frames around links/string +/property +property name=tristate + boolfalse/bool +/property + /widget /widget widget class=QGroupBox name=groupBox_2 property name=geometry @@ -122,12 +144,24 @@ stringHeader Information/string /property layout class=QGridLayout -property name=margin +property name=leftMargin number9/number /property -property name=spacing +property name=topMargin + number9/number +/property +property name=rightMargin + number9/number +/property +property name=bottomMargin + number9/number +/property +property name=horizontalSpacing number6/number /property +property name=verticalSpacing + number6/number +/property item row=2 column=1 widget class=QLineEdit name=subjectLE / /item @@ -187,7 +221,7 @@ rect x10/x y180/y - width191/width + width181/width height121/height
Re: [Patch#4] Bug 3527 - Basic PDF support via hyperref
Pavel Sanda schrieb: btw disagreement with your last fix - opt += (pdfborder ?'1':'0'); + opt += (pdfborder ?'0':'1'); havent tried but expect it will break elsewhere and also reverts the semantics. This fix is correct: the option is no border, therefore when it is checked, there must be a '0', not a '1'. regards Uwe
Re: [Patch#4] Bug 3527 - Basic PDF support via hyperref
Pavel Sanda schrieb: btw disagreement with your last fix - opt += (pdfborder ?'1':'0'); + opt += (pdfborder ?'0':'1'); havent tried but expect it will break elsewhere and also reverts the semantics. This fix is correct: the option is no border, therefore when it is checked, there must be a '0', not a '1'. you are right, it wont break. the bookmark level fix is on the way. pavel
Re: [Patch#4] Bug 3527 - Basic PDF support via hyperref
Anyway, as we want to cooperate, I will write some scripts that do the job and give me svn output for you. done. can you please try this version ? :) pavel Index: src/frontends/qt4/ui/PDFSupportUi.ui === --- src/frontends/qt4/ui/PDFSupportUi.ui(revision 20425) +++ src/frontends/qt4/ui/PDFSupportUi.ui(working copy) @@ -232,7 +232,7 @@ property name=geometry rect x10/x - y360/y + y340/y width431/width height51/height /rect
Re: [Patch#4] Bug 3527 - Basic PDF support via hyperref
Concerning the current state of the PDF support: There are three remaining open issues: - the bookmark level field is not working: - No matter what you insert, it is converted to False or True. - There is also no default value (should be 1). - It is possible to enter there other characters than the allowed numbers 0-9. - The dialog is smaller than the form, see the attached image: The aditional options field and the right border are hidden. - The placement of the hyperref call is not correct. E.g. we have to load it after the URL-package but before algorithm floats are defined. The list is long and it will take a while until we found out the correct position. For now it would help if you place the hyperref call before babel. regards Uwe inline: PDF-UI.png
Re: Hyperref
As JMarc warned, having \label commands inside \sections (e.g.) will cause LaTeX to choke when hyperref is loaded, in certain cases, crucially, when you also have a TOC. This is not the case as the UserGuide and other manuals use already hyperref. JMarc, could you give an example where tihs doesn't work? regards Uwe
Re: [Patch#4] Bug 3527 - Basic PDF support via hyperref
Pavel Sanda schrieb: Anyway, as we want to cooperate, I will write some scripts that do the job and give me svn output for you. done. can you please try this version ? :) Works, thanks. Uwe
Re: Hyperref
Uwe Stöhr wrote: As JMarc warned, having \label commands inside \sections (e.g.) will cause LaTeX to choke when hyperref is loaded, in certain cases, crucially, when you also have a TOC. This is not the case as the UserGuide and other manuals use already hyperref. JMarc, could you give an example where tihs doesn't work? Hmm. I had a minimal text file that was generating errors, but now I don't. 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#4] Bug 3527 - Basic PDF support via hyperref
- There is also no default value (should be 1). i regarded it as string, which can be empty, i.e. no default value. but we can change it if you disagree. - It is possible to enter there other characters than the allowed numbers 0-9. shouldn't be the user responsible ? This could be solved by making it a spin box. rh
Re: [Cvslog] r20346 - /lyx-devel/branches/BRANCH_1_5_X/status.15x
Juergen Spitzmueller wrote:
(btw if anyone notices style issues, feel free to improve the wording.
Where's Angus when you need him?)
Ich bin hier, mein freund, aber ich auch sehr beschäftigt bin. Sie
schreiben soviel, es sind schwierig zu folgen.
Anyway, attached is a slightly re-worked version of status.15x.
Apologies for the bad German; next time I'll try and mangle Italian ;-)
Note that I didn't actually know what the two statements below
actually meant. That makes it difficult to make the meaning clear ;-)
- On all supported platforms, allow Qt 4.2 or higher to use the math
fonts in sysdir/fonts without the need to install them. (Install
in the TeX tree?)
- Clarify an error message for --without-included-boost. (When would
this error message appear; I thought I saw that José was at least
trying to compile using an external boost?)
Regards,
Angus
-*- text -*-
This file describes what has been done in the preparation of LyX 1.5.2
All comments are welcome.
I'd be glad if some of you could take the time to check it out (or fix
a bug or two if you are feeling adventurous). Let me recall that all
these fixes have been checked into the BRANCH_1_5_X branch, which you
can get with the command
svn co svn://svn.lyx.org/lyx/lyx-devel/branches/BRANCH_1_5_X lyx-1.5.x
Juergen
[In this list, I try to group things by topic and in decreasing
order of importance. This is, of course, subjective...]
What's new
==
** Updates:
***
* DOCUMENTATION AND LOCALIZATION
- The LyX User Guide has been revised completely.
It is now up to date and describes all of LyX 1.5's main features
For a detailed changelog, see
http://wiki.lyx.org/LyX/DocumentationDevelopment#Status
- The LyX User Guide has been translated into Spanish.
- Embedded Objects manual now contains two new sections:
* longtable alignment.
* scaled and rotated material.
- Many improvements to the translation of the user interface on the Mac.
In particular, LyX automatically uses the language of the interface for
all of its menus and for the help files. Documents strings like
Chapter are correctly translated on screen too.
- New translations of the user interface into Finnish, Portuguese and
Simplified Chinese.
- Updated Czech and Italian translations of the user interface.
* USER INTERFACE
- Add a pixmap cache to speed up text drawing on screen. This cache is
enabled on Mac and Windows platforms using Qt 4.2 or higher.
- Add a Save all menu entry, to save all modified files (bug 2840).
- Mark modified files in the View menu with an asterisk (bug 2876).
- Add a paragraph-params LFUN, used for updating paragraph parameters
(bug 2714).
- Add a Save all on log-out or cancel feature (bug 1656).
- Improved on screen rendering of some toolbar images.
- The dialogs of editable insets (such as index entries, URLs or
citations) are now opened by the next-inset-toggle LFUN (bug
2907).
- The screen label of index insets now displays their content.
- Floats comes now with fixed width on screen (bug 4002).
** Bug fixes:
*
* DOCUMENT INPUT/OUTPUT
- Check if the .lyx file has been externally modified when a buffer is saved.
- Fix conversion from older documents if koi8 is used as the document
encoding (bug 4158).
- Handle array column specifiers @{decl.}, p{width} and the extensions by
array.sty in mathed (bug 4132).
- Detect (pdf)tex's file:line:error style messages that are used by some
distributions and that caused LyX to ignore LaTeX errors (bug 4222).
* USER INTERFACE:
- Fix a crash when closing a LyX window with document tabs (bug 4123).
- Fix a crash when clicking in a tabular cell and the delete empty paragraph
mechanism triggers (bug 4133).
- Fix a crash when using the LFUN 'buffer-write-as' with an argument
that is not an absolute path (bug 4135).
- Fix a crash when a user removes the underlying figure of a graphic inset
that has been copied and pasted (bug 4108).
- Fix a crash when inserting a float.
- Fix a crash on quitting if graphics were selected (bug 4178).
- Fix a crash when a user removes a formula when its preview is being
generated (gcc 3 only).
- Fix a crash when using the down arrow in an empty math subscript (bug 4117).
- Fix a crash when logging out from within the Gnome desktop (bug 1656).
- Fix a crash with ViewPDF on the Mac. This occurred only when LyX was
compiled with gcc's stdlib-debug option (bug 4014).
- Fix the loading of non-LyX child documents with relative path names. Change
'Load' to 'Edit' in the child document dialog (bugs 4107 and 4111).
- Allow roman numerals beyond 20 (bug 4112).
- Render malformed tables correctly (bug 580).
- Enable FileRevert when the file is externally modified, and rename
this menu item to FileRevert to saved (bugs 3766 and 4114).
- Update the screen when leaving a 'wide' inset using the up- and down-arrows.
- Fix a problem where the Delete button in the citation dialog was
Re: current_font in ERT insets
Martin Vermeer wrote: On Fri, Sep 21, 2007 at 01:19:48AM +0200, Dov Feldstern wrote: Now there's a follow-up issue: when leaving the ERT inset by pressing right-arrow at the end of the inset, to get back outside after the inset, the language is remaining "latex_language", which is wrong (for example, if you view source you'll see that the encoding is being set to latin1). So we're going to need some reverse mechanism of what your current fix did. Yes, I see that too, but only if the ERT is at end of paragraph. So here's my question: is there any function for jumping out of an inset to immediately after the inset? from anywhere inside the inset? is there an lfun/key-binding to such a function? LFUN_CHAR_FORWARD. But I suspect this is due to something Abdel removed... perhaps you should go though his patches here to find the culprit. It was probably part of the transition of current_font to Cursor. A call to setCurrentFont is probably missing in LFUN_CHAR_FORWARD. Abdel.
Re: PDF Options for 1.5.X?
Michael Gerz wrote: > Is PDFOptions a potential candidate for 1.5.x? Not for 1.5.2 anyway. Jürgen
PDF Options for 1.5.X?
Hi, before I add lots of new patches to my list: Is PDFOptions a potential candidate for 1.5.x? Regards, Michael
