Re: View Menu proposal
Darren Freeman wrote: On Fri, 2007-09-14 at 09:29 +0200, Jean-Marc Lasgouttes wrote: Darren Freeman [EMAIL PROTECTED] writes: Add three radio buttons to the configuration dialogue, under Action to perform when a preview is still open, which would be Ask what to do, Always update the existing preview, and Always open a new preview. Ugh. Not really a simplification of the use of LyX, is it? I think it is, actually. Half as many menu entries and less key bindings. Come to think of it, how come only DVI and PS have keyboard shortcuts? Are we all supposed to bind our favourite PDF method or could there be a default one chosen for a shortcut (to aid newbies in choosing one for example)? I've been wondering the same thing... I am not using PS at all and I guess neither are all Windows and Mac users. Could we just replace the binding for PS with PDF? If you closed the old preview, no change in behaviour. After the first time the dialogue appears, you either get your favourite action from now on, or you get asked each time the existing preview is open. This is very much like the UI of other popular apps. With shortcuts for the buttons on the dialogue, this is speedy from the keyboard too. (replace an extra shift modifier with a trailing Enter etc.) Perhaps there can be a statement next to the Don't ask me again box which lets you know the setting can be changed later in the appropriate configuration dialogue. It is just a matter of implementing it... Abdel.
Re: [Cvslog] r20315 - in /lyx-devel/branches/BRANCH_1_5_X: src/insets/...
Martin Vermeer wrote: On Mon, Sep 17, 2007 at 01:17:18AM +0200, Uwe Stöhr wrote: Bo Peng schrieb: This is not what I meant. Idx: is not translateable because it is not a word. The label should have the name Index not Idx. This could then be translated to different languages, e.g to Índice when you use Spanish menus. You have complained that the label of index inset is too long now, and you want to change 'Idx: ' to 'Index: '? Exactly. After your explanation, I think that the first part is OK now as you implemented it, but Idx should be changed to Index. I do not actually mind the change, so you can change it if Jurgen (and Jose for trunk) agrees. Jürgen? regards Uwe I would suggest (think I did) to completely leave Idx: off, and make the appearance of the button distinctive. People are curious and will click if they wonder what it is, and will quickly learn. Agreed. A different background and/or text color should be enough. Abdel.
Re: [Cvslog] r20315 - in /lyx-devel/branches/BRANCH_1_5_X: src/insets/...
Uwe Stöhr wrote: Besides this, I don't know why this could go to branch since there was no need for this change. Because it was trivial and I agree with Bo that it is helpful. Jürgen
Re: [Cvslog] r20315 - in /lyx-devel/branches/BRANCH_1_5_X: src/insets/...
Martin Vermeer wrote: Jürgen? I think Index: plus a 25-char-string is too long (I actually think the string should be shortened to 20 chars anyway). And I don't understand why Idx isn't a suitable abbreviation (and also why it shouldn't be translatable; the abbreviation in other languages could be completely different). regards Uwe I would suggest (think I did) to completely leave Idx: off, and make the appearance of the button distinctive. People are curious and will click if they wonder what it is, and will quickly learn. This would be an option. Jürgen
Re: ERT in title bug
Martin Vermeer wrote: Not needed... the fix replaces something that Abdel removed ;-) I'm confused. I thought this ERT in titel bug is something that appeared in 1.5.x? Jürgen
Re: ERT in title bug
Jürgen Spitzmüller wrote: Martin Vermeer wrote: Not needed... the fix replaces something that Abdel removed ;-) I'm confused. I thought this ERT in titel bug is something that appeared in 1.5.x? Yes, but the thread was hijacked by a different problem in trunk. The 1.5.x is different but still present AFAIU. Abdel.
Re: Box menu entry
Pavel Sanda wrote: i would like to propose this small patch for box menu entry, as i want to distinguish between inset and menu occurence of this string for translation (for shortcut occurence to be more explicit). I think the proposal makes sense. I'm gonna put it in branch and trunk if I get no objections. Jürgen
Re: ERT in title bug
Abdelrazak Younes wrote: Yes, but the thread was hijacked by a different problem in trunk. The 1.5.x is different but still present AFAIU. OK. Thanks for the clarification. Jürgen
Re: [Cvslog] r20304 - in /lyx-devel/trunk/src: Converter.cpp Converter...
[EMAIL PROTECTED] writes:
bool dummy = conv.To-dummy() conv.to != program;
- if (!dummy)
+ if (!dummy) {
LYXERR(Debug::FILES) Converting from
conv.from to conv.to endl;
+ }
infile = outfile;
So the code is like
if (!dummy)
if (!lyxerr.debugging(Debug::FILES)) ; else lyxerr Converting from
conv.from to conv.to endl;
Isn't there some documented trick that avoids this warning? Having to
add braces around the second if is not nice.
Is there a way with gcc to silence a warning at a given place?
JMarc
Re: r20310 - in /lyx-devel/branches/BRANCH_1_5_X/boost/boost:...
Abdelrazak Younes [EMAIL PROTECTED] writes: Is it our job to fix boost warnings? The benefit is that they do not hide our real warnings anymore. JMarc
Re: tex as lyx native file format
On Saturday 15 September 2007 22:10:07 Roberto Franceschini wrote:
I'm just saying that one side LyX is the best word processor, but on
the other side most of the people, dumb like mule, stick to LaTeX just
because it's the standard de-facto.
What is a standard depends a lot on what people are used to. IMHO there is no
such a thing as a latex standard there are instead lots of local standards.
I have see people using \be for \begin{equation}, \ee for \end{equation} and
for languages that use accents lots of other funny (and weird) definitions to
allow the use of accented characters.
So for me a standard latex is a urban legend, everyone talks about it but no
one ever saw it. ;-)
--
José Abílio
Re: [Cvslog] r20304 - in /lyx-devel/trunk/src: Converter.cpp Converter...
Jean-Marc Lasgouttes wrote:
[EMAIL PROTECTED] writes:
bool dummy = conv.To-dummy() conv.to != program;
- if (!dummy)
+ if (!dummy) {
LYXERR(Debug::FILES) Converting from
conv.from to conv.to endl;
+ }
infile = outfile;
So the code is like
if (!dummy)
if (!lyxerr.debugging(Debug::FILES)) ; else lyxerr Converting from
conv.from to conv.to endl;
Isn't there some documented trick that avoids this warning? Having to
add braces around the second if is not nice.
What about enclosing the macro with {}?
{if (!lyxerr.debugging(Debug::FILES)) ; else lyxerr Converting from
conv.from to conv.to endl; }
Abdel.
Re: [Patch#3] Bug 3527 - Basic PDF support via hyperref
Pavel Sanda [EMAIL PROTECTED] writes:
i tried to incorporate the comments, now sending the resulting patch
and propose to merge it into trunk.
More comments:
+ } else if (token == \\use_hyperref) {
+ lex pdfoptions().use_hyperref;
+ } else if (token == \\pdf_title) {
+ lex pdfoptions().title;
+ } else if (token == \\pdf_author) {
+ lex pdfoptions().author;
Just a suggestion: in order to keep everything in one place, what
about doing
} else if (prefixIs(token, \\pdf_)
pdfoptions().read(token, lex);
and move the long string of tests to PDFOptions.cpp?
@@ -1176,6 +1223,12 @@ bool BufferParams::writeLaTeX(odocstream os,
LaTeXFeatures features,
}
os lyxpreamble;
+
+ // PDF support. Hypreref manual: Make sure it comes last of your loaded
+ // packages, to give it a fighting chance of not being over-written,
+ // since its job is to redefine many LATEX commands.
+ pdfoptions().writeLatex(os);
+
return use_babel;
}
This one is wrong: you should find a way to add your code to
lyxpreamble, because as it is you break the line counting (for error
parsing) that is done a few lines above. Something like:
odocstringstream pos;
pdfOptions.writeLatex(pos);
os pos.str();
Alternatively, turn PDFOptions::writeLatex (that should be renamed to
writeLaTeX anyway) into something that returns a docstring.
I am glad somebody finally decided to make this work.
JMarc
Re: r20313 - /lyx-devel/trunk/src/insets/InsetIndex.cpp
Bo Peng [EMAIL PROTECTED] writes: I needed to change some index labels from 'a b' to 'b!a' for my document and I quickly lost track of which indexes have been updated and which have not. The ability to make this change in 5 minutes demonstrates the real benefit of using an open source program. (Ohmm, normal users need to wait longer.. :-) I did not have the time to chime in the allotted time, but I can say that the short version of index has been added after having a user remark astutely that displaying foo[idx: foo] was really a waste of UI space. I do not think that the example of changing 'a b' to 'b!a' rapidly is the best possible reason for making this change (how many times per year does this situation happen?). Some other solutions could have been considered: - have insets implement a description() method that returns a somewhat longer label that can be used to * display a tooltip on hover * set the status bar when the cursor is in front of the inset (we have that for math already). [*] - add index entries to yet another TOC and use that to both navigate and get a clear view of the index. - what would be even better would be to have the index inset display its contents only if it is different from the default label. It would mean however that the cursor should be known at the point where getScreenLabel is invoked, which does not seem feasible right now. JMarc [*] this would be pretty handy with an additional index-next lfun that would go to the next inset of same type than the one at cursor. This would replace advantageously note-next and allow to go from index entry to index entry effortlessly (and see the complete index in status bar)
Re: Master Preview
Tommaso Cucinotta [EMAIL PROTECTED] writes: That would then be opened whenever the child was, and the various settings imported (which, in the code, may mean no more than giving the two documents the same BufferParams). Infact, I was just thinking at smth. like that. The main point I think would be avoiding replication of information between the master and child. Their infos are merged only by LyX at run-time for the various purposes (at least previewing and macro expansion). We discussed several times the idea of giving the child document the same bufferparams as its master. This is quite easy to do, but I would be surprised to see that it works without hurdles... We should do it anyway. From a UI POV, we could disable DocumentSettings for the child to show what happens in an obvious way (and maybe add a DocumentMaster settings...).
Re: View Menu proposal
Abdelrazak Younes [EMAIL PROTECTED] writes: I've been wondering the same thing... I am not using PS at all and I guess neither are all Windows and Mac users. Could we just replace the binding for PS with PDF? Adding a shortcut for PDF does not mean that the PS one should be removed (in particular Ctrl+t is a weird choice for PDF). Then for pdf, we need to query the exporter to list all the ways to produce PDF and let the user choose its preferred one. This would allow to get rid of pdf[123], but should be done carefully to avoid hardcoding. JMarc
Re: trac
Pavel Sanda [EMAIL PROTECTED] writes: hello, am i the only one, who does not see trac timeline anymore ? It seems to work now. JMarc
Re: static_mutex.hpp
Roger Mc Murtrie [EMAIL PROTECTED] writes: svn branch 1.5 boost/boost/regex/v4/cpp_regex_traits.hpp contains the lines #ifdef BOOST_HAS_THREADS #include boost/regex/pending/static_mutex.hpp #endif but boost/boost/regex/pending/ only seems to contain the file object_cache.hpp Can anyone tell me why this is? Because BOOST_HAS_THREADS is undefined for LyX? JMarc
Re: r20313 - /lyx-devel/trunk/src/insets/InsetIndex.cpp
Jean-Marc Lasgouttes wrote: I did not have the time to chime in the allotted time, but I can say that the short version of index has been added after having a user remark astutely that displaying foo[idx: foo] was really a waste of UI space. I do not think that the example of changing 'a b' to 'b!a' rapidly is the best possible reason for making this change (how many times per year does this situation happen?). OK, I learned from this that adding an ui change on Sunday is not a good idea, even though the change looked straightforward to me. Having said that, there's still plenty of time to discuss this. If the majority thinks that the old behaviour is better until we have some more fancy means (as outlined by JMarc), we will revert. So please add your vote now, or remain silent: + Bo* + Jürgen* - Uwe - Jean-Marc Jürgen * including the possibility to change the appearance of the label
Re: static_mutex.hpp
On 17/09/2007, at 7:27 PM, Jean-Marc Lasgouttes wrote: Roger Mc Murtrie [EMAIL PROTECTED] writes: svn branch 1.5 boost/boost/regex/v4/cpp_regex_traits.hpp contains the lines #ifdef BOOST_HAS_THREADS #include boost/regex/pending/static_mutex.hpp #endif but boost/boost/regex/pending/ only seems to contain the file object_cache.hpp Can anyone tell me why this is? Because BOOST_HAS_THREADS is undefined for LyX? JMarc OK if this is so. I did find definitions in: /boost/boost/config/platform/macos.hpp /boost/boost/config/compiler/gcc.hpp But I guess these are not used by LyX? Thanks, Roger
Re: r20313 - /lyx-devel/trunk/src/insets/InsetIndex.cpp
On Mon, 17 Sep 2007 10:53:30 +0200 Jean-Marc Lasgouttes [EMAIL PROTECTED] wrote: Bo Peng [EMAIL PROTECTED] writes: I needed to change some index labels from 'a b' to 'b!a' for my document and I quickly lost track of which indexes have been updated and which have not. The ability to make this change in 5 minutes demonstrates the real benefit of using an open source program. (Ohmm, normal users need to wait longer.. :-) I did not have the time to chime in the allotted time, but I can say that the short version of index has been added after having a user remark astutely that displaying foo[idx: foo] was really a waste of UI space. I do not think that the example of changing 'a b' to 'b!a' rapidly is the best possible reason for making this change (how many times per year does this situation happen?). Some other solutions could have been considered: - have insets implement a description() method that returns a somewhat longer label that can be used to * display a tooltip on hover * set the status bar when the cursor is in front of the inset (we have that for math already). [*] Another alternative is to introduce closed and open versions of the inset, like we have for collapsable insets. Then you can close and open them all together. Tooltip would be best though if easy to do. - add index entries to yet another TOC and use that to both navigate and get a clear view of the index. - what would be even better would be to have the index inset display its contents only if it is different from the default label. It would mean however that the cursor should be known at the point where getScreenLabel is invoked, which does not seem feasible right now. JMarc [*] this would be pretty handy with an additional index-next lfun that would go to the next inset of same type than the one at cursor. This would replace advantageously note-next and allow to go from index entry to index entry effortlessly (and see the complete index in status bar)
Re: r20313 - /lyx-devel/trunk/src/insets/InsetIndex.cpp
On Mon, 17 Sep 2007 11:47:37 +0200 [EMAIL PROTECTED] (Jürgen Spitzmüller) wrote: Jean-Marc Lasgouttes wrote: I did not have the time to chime in the allotted time, but I can say that the short version of index has been added after having a user remark astutely that displaying foo[idx: foo] was really a waste of UI space. I do not think that the example of changing 'a b' to 'b!a' rapidly is the best possible reason for making this change (how many times per year does this situation happen?). OK, I learned from this that adding an ui change on Sunday is not a good idea, even though the change looked straightforward to me. Having said that, there's still plenty of time to discuss this. If the majority thinks that the old behaviour is better until we have some more fancy means (as outlined by JMarc), we will revert. So please add your vote now, or remain silent: + Bo* + Jürgen* - Uwe - Jean-Marc + Martin* (until a better solution, e.g., tooltip) Jürgen * including the possibility to change the appearance of the label
Re: static_mutex.hpp
Roger Mc Murtrie [EMAIL PROTECTED] writes: I did find definitions in: /boost/boost/config/platform/macos.hpp /boost/boost/config/compiler/gcc.hpp Note that we do #define BOOST_DISABLE_THREADS 1 in src/config.h.in. JMarc
Re: [PATCH] fix M-Return
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes: Jean-Marc Lasgouttes wrote: The behaviour of M-Return is the exact symmetry of what Return would do: I see. I'm fine with that (though I still prefer the old behaviour, i.e. swap Return and M-Return). Could you be more precise? I do not think the behaviour of Return has been changed recently. What would you like to see? I'm not sure I like this. Why should we double the functionality of depth-decrement? Currently, pressing Return on an empty paragraph does nothing. The idea is for example, at the end of an enumeration, one types return twice and LyX is back to top level standard style. JMarc
Re: [Patch] Re: [Patch] partial support for units
Martin Vermeer wrote:
On Fri, Sep 14, 2007 at 03:36:10PM +0200, Helge Hafting wrote:
\unitfrac supports a similiar optional argument for the number, but
that capability is not used in lyx. So we can now write
$35\unitfrac{km}{h}$
but not
$\unitfrac[35]{km}{h}$
The latter looks better, with better spacing. One can insert
the missing space explicitly, and get $35\,\unitfrac{km}{h}
which looks the same in the dvi.
The attached supports now all these alternatives. As a bonus, we have
now the option of varying numbers of cells. Also cursor motion should
now be OK.
I will commit this if I don't hear an outcry. Suggestions for better
toolbar pop-up texts are especially welcome.
I was unable to test because the patch did not apply. Too
many other patches going in probably. I guess this stuff
is fine anyway.
Helge Hafting
Re: [PATCH] fix M-Return
Jean-Marc Lasgouttes wrote: Could you be more precise? I do not think the behaviour of Return has been changed recently. What would you like to see? I'm referring to the old behaviour where M-return was necessary to preserve the nesting level. I'm not sure I like this. Why should we double the functionality of depth-decrement? Currently, pressing Return on an empty paragraph does nothing. The idea is for example, at the end of an enumeration, one types return twice and LyX is back to top level standard style. I see. But this could be implemented in a second step. Jürgen
Re: [Patch] Re: [Patch] partial support for units
On Mon, 17 Sep 2007 13:53:03 +0200
Helge Hafting [EMAIL PROTECTED] wrote:
Martin Vermeer wrote:
On Fri, Sep 14, 2007 at 03:36:10PM +0200, Helge Hafting wrote:
\unitfrac supports a similiar optional argument for the number, but
that capability is not used in lyx. So we can now write
$35\unitfrac{km}{h}$
but not
$\unitfrac[35]{km}{h}$
The latter looks better, with better spacing. One can insert
the missing space explicitly, and get $35\,\unitfrac{km}{h}
which looks the same in the dvi.
The attached supports now all these alternatives. As a bonus, we have
now the option of varying numbers of cells. Also cursor motion should
now be OK.
I will commit this if I don't hear an outcry. Suggestions for better
toolbar pop-up texts are especially welcome.
I was unable to test because the patch did not apply. Too
many other patches going in probably. I guess this stuff
is fine anyway.
Helge Hafting
The patch is already in (perhaps that's why it didn't apply :-)
- Martin
Re: View Menu proposal
On Sep 17, 2007, at 5:25 AM, Jean-Marc Lasgouttes wrote: Abdelrazak Younes [EMAIL PROTECTED] writes: I've been wondering the same thing... I am not using PS at all and I guess neither are all Windows and Mac users. Could we just replace the binding for PS with PDF? I think this would be preferable. Adding a shortcut for PDF does not mean that the PS one should be removed (in particular Ctrl+t is a weird choice for PDF). I don't think it's weird: doesn't the t stand for typeset? It's also the keybinding in other Mac programs to generate typeset output from a .tex file (such as TeXShop.app). Bennett
bug in lyx 1.5.1? translation of abstractname
Hello,
is this a bug? Haven't found anything on bugzilla.
I have installed a German LyX 1.5.1 on gentoo Linux. In article (RevTeX)
class I want to write an English article (I set Language to English in
Document - Preferences) but the \abstractname shows as
Zusammenfassung (German term) rather than Abstract in the final pdf
or dvi output. I tried
\def\abstractname{Abstract},
\renewcommand\abstractname{Abstract}
and even
\AtBeginDocument{%
\addto\captionsyour language{%
\renewcommand{\abstractname}{In nuce}%
}}
in the preamble, but nothing helped.
What is even more puzzling is, that the Acknowledgements term is spelled
correctly (in English).
Including my Emailaddress in the answer (since I'm not member of the
list) would be appreciated.
Thanks in advance
Kai
Re: [PATCH] fix M-Return
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes: Jean-Marc Lasgouttes wrote: Could you be more precise? I do not think the behaviour of Return has been changed recently. What would you like to see? I'm referring to the old behaviour where M-return was necessary to preserve the nesting level. Bu currently with environments (itemize, etc.) both return and M-return keep the nesting level. How do you go to a lower level usually? JMarc
Re: [PATCH] fix M-Return
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes: Jean-Marc Lasgouttes wrote: Bu currently with environments (itemize, etc.) both return and M-return keep the nesting level. Yes (which is bad). How do you go to a lower level usually? M-S-leftarrow. Which is less fun than pressing Return repeatedly, you'll admit :) So, what would be your preferred behaviour? JMarc
Re: [PATCH] fix M-Return
Jean-Marc Lasgouttes wrote: Bu currently with environments (itemize, etc.) both return and M-return keep the nesting level. Yes (which is bad). How do you go to a lower level usually? M-S-leftarrow. Jürgen
Re: [PATCH] fix M-Return
Jean-Marc Lasgouttes wrote: Which is less fun than pressing Return repeatedly, you'll admit :) Well, let's say you get used to it ... So, what would be your preferred behaviour? Let's forget about my (personal) preferred behaviour (I am obviously a minority here). I think your patch is a step in the right direction, and I also agree that your return-in-an-empty-nested-paragraph idea would be an improvement. So I'd be both fine with applying your patch now and the return thing later or implementing both at once, if you come up with a sensible patch. Jürgen
Re: r20313 - /lyx-devel/trunk/src/insets/InsetIndex.cpp
+ Martin* (until a better solution, e.g., tooltip) I agree. The easiest solution might be to add a checkbox somewhere to the preference dialog ... Bo
Re: [Cvslog] r20315 - in /lyx-devel/branches/BRANCH_1_5_X: src/insets/...
I think Index: plus a 25-char-string is too long (I actually think the string should be shortened to 20 chars anyway). And remove the space after :. Bo
Re: Compiling with --enable-shared leads to errors.
On Tuesday 11 September 2007 16:41:03 Andre Poenitz wrote: --enable-shared is for people that do not ask questions ;-) Don't worry I _will_ forget that rule. :-) [...] /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libboost_regex-mt.so: undefined reference to `u_charType_3_7' collect2: ld returned 1 exit status Do we use --without-included-boost regularily? I intend to. :-) OK, the above is a problem with Fedora implementation. The boost library there needs to be rebuilt against the latest icu(-3.8). Yet, I need the following patch to be able to compile lyx without an included boost. Any objection? The patch seems to be a good first step. Eventually, if we stay with autotools, we need something like: http://viewmtn.angrygoats.net/revision/file/6eb785c496e3973605995ca5d5777cc1879d56da/m4/boost.m4 Andre' -- José Abílio Index: src/tex2lyx/Makefile.am === --- src/tex2lyx/Makefile.am (revision 20319) +++ src/tex2lyx/Makefile.am (working copy) @@ -63,8 +63,7 @@ tex2lyx_LDADD = \ $(top_builddir)/src/support/liblyxsupport.la \ - $(top_builddir)/boost/liblyxboost.la \ - $(LIBICONV) @LIBS@ + $(LIBICONV) $(BOOST_LIBS) @LIBS@ tex2lyx.1: cp -p $(srcdir)/tex2lyx.man tex2lyx.1 Index: config/common.am === --- config/common.am (revision 20319) +++ config/common.am (working copy) @@ -37,6 +37,7 @@ BOOST_REGEX = -lboost_regex BOOST_SIGNALS = -lboost_signals BOOST_IOSTREAMS = -lboost_iostreams +BOOST_LIBS = $(BOOST_FILESYSTEM) $(BOOST_REGEX) $(BOOST_SIGNALS) $(BOOST_IOSTREAMS) endif LIBS =
Re: View Menu proposal
Bennett Helm [EMAIL PROTECTED] writes: I don't think it's weird: doesn't the t stand for typeset? It's also the keybinding in other Mac programs to generate typeset output from a .tex file (such as TeXShop.app). I think it was the 't' of postscript (as you know, Ctrl+P, Ctrl+O and Ctrl+S were already taken). In this case, Ctrl+T should not be bound to pdf, but we need a pref to set the preferred preview format and buffer-preview (without argument could default to that). JMarc
Re: Master Preview
Tommaso Cucinotta wrote: But this won't be a problem at all with Stefan's new code, which should go into 1.6.svn soon. How will that work ? He's got a complete, and much more flexible, re-write of the macro code on the way. I can't remember the details, but it is very, very cool. Richard
Re: Master Preview
Jean-Marc Lasgouttes wrote: Tommaso Cucinotta [EMAIL PROTECTED] writes: That would then be opened whenever the child was, and the various settings imported (which, in the code, may mean no more than giving the two documents the same BufferParams). Infact, I was just thinking at smth. like that. The main point I think would be avoiding replication of information between the master and child. Their infos are merged only by LyX at run-time for the various purposes (at least previewing and macro expansion). We discussed several times the idea of giving the child document the same bufferparams as its master. This is quite easy to do, but I would be surprised to see that it works without hurdles... We should do it anyway. From a UI POV, we could disable DocumentSettings for the child to show what happens in an obvious way (and maybe add a DocumentMaster settings...). It seems early enough in the 1.6.x cycle to do this if someone has the time. I'm afraid I don't. Richard
Re: [Cvslog] r20315 - in /lyx-devel/branches/BRANCH_1_5_X: src/insets/...
I would suggest (think I did) to completely leave Idx: off, and make the appearance of the button distinctive. People are curious and will click if they wonder what it is, and will quickly learn. This would be an option. This would indeed be a solution, together with a limit for the label length of 20 chars. regards Uwe
Re: [Cvslog] r20304 - in /lyx-devel/trunk/src: Converter.cpp Converter...
On Mon, Sep 17, 2007 at 10:23:06AM +0200, Jean-Marc Lasgouttes wrote:
[EMAIL PROTECTED] writes:
bool dummy = conv.To-dummy() conv.to != program;
- if (!dummy)
+ if (!dummy) {
LYXERR(Debug::FILES) Converting from
conv.from to conv.to endl;
+ }
infile = outfile;
So the code is like
if (!dummy)
if (!lyxerr.debugging(Debug::FILES)) ; else lyxerr Converting from
conv.from to conv.to endl;
Isn't there some documented trick that avoids this warning? Having to
add braces around the second if is not nice.
Actually the 'if (!...); else ' is there to make exactly the use without
braces woring in a robust manner. There's nothing wrong with if if else.
The else always binds to the innermost acceptable if, and with the macro
we provide this if. So it's slightly annoying to have gcc compile in
this case.
Is there a way with gcc to silence a warning at a given place?
Good question.
Andre'
Re: r20290 - in /lyx-devel/trunk: lib/ui/stdtoolbars.inc src/...
[EMAIL PROTECTED] wrote:
Modified: lyx-devel/trunk/src/mathed/MathFactory.cpp
URL:
http://www.lyx.org/trac/file/lyx-devel/trunk/src/mathed/MathFactory.cpp?rev=20290
==
--- lyx-devel/trunk/src/mathed/MathFactory.cpp (original) +++
lyx-devel/trunk/src/mathed/MathFactory.cpp Sat Sep 15 18:39:51 2007 @@
-260,7 +260,7 @@
MathAtom createInsetMath(docstring const s)
{
- //lyxerr creating inset with name: ' s '\'' endl;
+ //lyxerr creating inset with name: ' to_utf8(s) '\'' endl;
latexkeys const * l = in_word_set(s);
if (l) {
docstring const inset = l-inset;
@@ -372,6 +372,10 @@
return MathAtom(new InsetMathFrac(InsetMathFrac::NICEFRAC));
if (s == unitfrac)
return MathAtom(new InsetMathFrac(InsetMathFrac::UNITFRAC));
+ if (s == unitfracthree)
+ return MathAtom(new InsetMathFrac(InsetMathFrac::UNITFRAC3, 3));
+ if (s == unit)
+ return MathAtom(new InsetMathFrac(InsetMathFrac::UNIT));
Mathed does not work like this, you cannot use \unitfracthree here. What you
did created a new command \unitfracthree that can be read from .lyx files,
but that is never written. And I would be surprised if \unit[a]{b}{c} is
read correctly from LyX files.
To fix this, you need to remove _all_ occurences of \unitfracthree from the
code and create a special case for \unit in MathParser.cpp (see \sqrt for
an example, although a separate inset is probably not needed).
In general, if you implement a new math command you have no choice but to
handle all possible arguments. Otherwise you get a nasty situation that
certain things are impossible to enter, see the xymatrix bugs in bugzilla.
Georg
Re: r20290 - in /lyx-devel/trunk: lib/ui/stdtoolbars.inc src/...
Martin Vermeer wrote:
Oops. Too difficult.
I don't think so. Just look how the two variants of sqrt (\sqrt{a}{b} and
\sqrt[a]{b}{c}) are handled and copy the relevant portions of code. If you
think that you do not really understand how the different parts of mathed
work together make Andre write some documentation :-)
Probably best to revert it.
If you revert, then please remove all \unitfrac variants. Otherwise you
create a regression, because \unitfrac[a]{b}{c} in 1.4 works fine as ERT,
and it would not if you only kept the short variant.
Georg
Re: [IDEAS] Bugs 4082 and 4178
Andre Poenitz wrote: On Sat, Sep 15, 2007 at 12:40:35PM -0400, Richard Heck wrote: A better fix would be to transfer the graphics::Cache singleton to LyX::Singletons. I.e., do this. But it may be that there are other ways you could see this problem. What about making the loader a shared_ptr rather than deleting it explicitly? Using shared_ptr does not magically solves problems we don't understand. Sorry, I was thinking about a different possible problem, not the one Abdel actually discovered. Richard
Re: View Menu proposal
Abdelrazak Younes ha scritto: It is just a matter of implementing it... Why don't you just start from embedding the patch I sent you for the LFUN + not-so-definitive key bindings ? It's just a few lines of harmless code. The GUI part might be addressed later (and I could take care of doing it, probably after I finished with this damn crazy scrolling...). T.
Re: [Cvslog] r20304 - in /lyx-devel/trunk/src: Converter.cpp Converter...
On Mon, Sep 17, 2007 at 10:44:49AM +0200, Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
[EMAIL PROTECTED] writes:
bool dummy = conv.To-dummy() conv.to != program;
- if (!dummy)
+ if (!dummy) {
LYXERR(Debug::FILES) Converting from
conv.from to conv.to endl;
+ }
infile = outfile;
So the code is like
if (!dummy)
if (!lyxerr.debugging(Debug::FILES)) ; else lyxerr Converting
from
conv.from to conv.to endl;
Isn't there some documented trick that avoids this warning? Having to
add braces around the second if is not nice.
What about enclosing the macro with {}?
No good idea. The current macro requires an open end that can have
attached.
Even if it weren't: Just try to compile:
if (...)
{...};
else
...
If LYXERR usage would be something like
LYXERR(Debug::FILES, Converting from
conv.from to conv.to endl);
we could have
#define LYXERR(type, what) \
do { if (!lyx::lyxerr.debugging(type)) ; else lyx::lyxerr what; } \
while (0)
(and we could even include the endl in the macro, we use it anyway in
all cases)
But last time I proposed to use the two-argument version the proposal
was shot down because people consider the version more stylish.
Andre'
Re: r20290 - in /lyx-devel/trunk: lib/ui/stdtoolbars.inc src/...
On Mon, Sep 17, 2007 at 06:49:00PM +0200, Georg Baum wrote:
Martin Vermeer wrote:
Oops. Too difficult.
I don't think so. Just look how the two variants of sqrt (\sqrt{a}{b} and
\sqrt[a]{b}{c}) are handled and copy the relevant portions of code. If you
think that you do not really understand how the different parts of mathed
work together make Andre write some documentation :-)
You already gave all the documentation that's needed: Look through the
insets to find something similar and just copy it. In this particular
case 'grep -i sqrt' in src/mathed indeed does all the relevant places:
InsetMathSqrt, MathParser and MathFactory.
Andre'
PS: That's not to say that some documentation won't help. But it's
certainly one of there areas of LyX where missing documentation does
not hurt as much as in other places.
Re: View Menu proposal
Tommaso Cucinotta wrote: Abdelrazak Younes ha scritto: It is just a matter of implementing it... Why don't you just start from embedding the patch I sent you for the LFUN + not-so-definitive key bindings ? It's just a few lines of harmless code. Which one? The GUI part might be addressed later (and I could take care of doing it, probably after I finished with this damn crazy scrolling...). I am sorry, I have little time available and when I get some I try to fix the metrics stuff (including scrolling). Abdel.
Re: r20290 - in /lyx-devel/trunk: lib/ui/stdtoolbars.inc src/...
On Mon, 17 Sep 2007 18:21:11 +0200
Georg Baum [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Modified: lyx-devel/trunk/src/mathed/MathFactory.cpp
URL:
http://www.lyx.org/trac/file/lyx-devel/trunk/src/mathed/MathFactory.cpp?rev=20290
==
--- lyx-devel/trunk/src/mathed/MathFactory.cpp (original) +++
lyx-devel/trunk/src/mathed/MathFactory.cpp Sat Sep 15 18:39:51 2007 @@
-260,7 +260,7 @@
MathAtom createInsetMath(docstring const s)
{
- //lyxerr creating inset with name: ' s '\'' endl;
+ //lyxerr creating inset with name: ' to_utf8(s) '\''
endl;
latexkeys const * l = in_word_set(s);
if (l) {
docstring const inset = l-inset;
@@ -372,6 +372,10 @@
return MathAtom(new InsetMathFrac(InsetMathFrac::NICEFRAC));
if (s == unitfrac)
return MathAtom(new InsetMathFrac(InsetMathFrac::UNITFRAC));
+ if (s == unitfracthree)
+ return MathAtom(new InsetMathFrac(InsetMathFrac::UNITFRAC3,
3));
+ if (s == unit)
+ return MathAtom(new InsetMathFrac(InsetMathFrac::UNIT));
Mathed does not work like this, you cannot use \unitfracthree here. What you
did created a new command \unitfracthree that can be read from .lyx files,
but that is never written. And I would be surprised if \unit[a]{b}{c} is
read correctly from LyX files.
To fix this, you need to remove _all_ occurences of \unitfracthree from the
code and create a special case for \unit in MathParser.cpp (see \sqrt for
an example, although a separate inset is probably not needed).
In general, if you implement a new math command you have no choice but to
handle all possible arguments. Otherwise you get a nasty situation that
certain things are impossible to enter, see the xymatrix bugs in bugzilla.
Georg
Oops. Too difficult.
Probably best to revert it.
- Martin
Re: View Menu proposal
Abdelrazak Younes ha scritto:
Tommaso Cucinotta wrote:
Why don't you just start from embedding the patch
I sent you for the LFUN + not-so-definitive key bindings ?
It's just a few lines of harmless code.
Which one?
Here you go.
T.
Index: src/LyXAction.cpp
===
--- src/LyXAction.cpp (revisione 20259)
+++ src/LyXAction.cpp (copia locale)
@@ -128,6 +128,8 @@
{ LFUN_BUFFER_TOGGLE_READ_ONLY, buffer-toggle-read-only, ReadOnly },
{ LFUN_BUFFER_UPDATE, buffer-update, ReadOnly },
{ LFUN_BUFFER_VIEW, buffer-view, ReadOnly },
+ { LFUN_MASTER_BUFFER_UPDATE, master-buffer-update, ReadOnly },
+ { LFUN_MASTER_BUFFER_VIEW, master-buffer-view, ReadOnly },
{ LFUN_BUFFER_WRITE, buffer-write, ReadOnly },
{ LFUN_BUFFER_WRITE_AS, buffer-write-as, ReadOnly },
{ LFUN_BUFFER_WRITE_ALL, buffer-write-all, ReadOnly },
Index: src/LyXFunc.cpp
===
--- src/LyXFunc.cpp (revisione 20259)
+++ src/LyXFunc.cpp (copia locale)
@@ -695,6 +695,8 @@
case LFUN_BUFFER_WRITE_AS:
case LFUN_BUFFER_UPDATE:
case LFUN_BUFFER_VIEW:
+ case LFUN_MASTER_BUFFER_UPDATE:
+ case LFUN_MASTER_BUFFER_VIEW:
case LFUN_BUFFER_IMPORT:
case LFUN_BUFFER_AUTO_SAVE:
case LFUN_RECONFIGURE:
@@ -999,6 +1001,16 @@
Exporter::preview(lyx_view_-buffer(), argument);
break;
+ case LFUN_MASTER_BUFFER_UPDATE:
+ BOOST_ASSERT(lyx_view_ lyx_view_-buffer() lyx_view_-buffer()-getMasterBuffer());
+ Exporter::Export(lyx_view_-buffer()-getMasterBuffer(), argument, true);
+ break;
+
+ case LFUN_MASTER_BUFFER_VIEW:
+ BOOST_ASSERT(lyx_view_ lyx_view_-buffer() lyx_view_-buffer()-getMasterBuffer());
+ Exporter::preview(lyx_view_-buffer()-getMasterBuffer(), argument);
+ break;
+
case LFUN_BUILD_PROGRAM:
BOOST_ASSERT(lyx_view_ lyx_view_-buffer());
Exporter::Export(lyx_view_-buffer(), program, true);
Index: src/lfuns.h
===
--- src/lfuns.h (revisione 20259)
+++ src/lfuns.h (copia locale)
@@ -398,11 +398,14 @@
LFUN_LISTING_INSERT, // Herbert 2000, bpeng 20070502
LFUN_TOOLBAR_TOGGLE, // Edwin 20070521
LFUN_BUFFER_WRITE_ALL, // rgh, gpothier 200707XX
- //290
+ // 290
LFUN_PARAGRAPH_PARAMS, // rgh, 200708XX
LFUN_LAYOUT_MODULES_CLEAR, // rgh, 20070825
LFUN_LAYOUT_MODULE_ADD, // rgh, 20070825
LFUN_LAYOUT_RELOAD, // rgh, 20070903
+ LFUN_MASTER_BUFFER_VIEW, // Tommaso
+ // 295
+ LFUN_MASTER_BUFFER_UPDATE, // Tommaso
LFUN_LASTACTION // end of the table
};
Index: lib/bind/cua.bind
===
--- lib/bind/cua.bind (revisione 20259)
+++ lib/bind/cua.bind (copia locale)
@@ -43,8 +43,12 @@
\bind C-p dialog-show print
\bind C-d buffer-view dvi # 'd' for dvi
\bind C-t buffer-view ps
+\bind C-M-t master-buffer-view ps
+\bind C-M-d master-buffer-view dvi
\bind C-S-D buffer-update dvi # 'd' for dvi
\bind C-S-T buffer-update ps
+\bind C-M-S-t master-buffer-update ps
+\bind C-M-S-d master-buffer-update dvi
\bind C-q lyx-quit
\bind C-Next buffer-next
\bind C-Tab buffer-next
LYXERR
Should I replace 'LYXERR(a) stuff' by 'LYXERR(a, stuff)' so we can
have the 'do { } while (0)' version of the macro?
Andre'
trunk does no longer compile
Since last thursday I can't compile the trunk. I'm using MSVC and get now this error message: D:\LyXSVN\lyx-devel\src\frontends\qt4\GuiTexinfo.cpp(162) : error C2039: 'sort': Ist kein Element von 'std' (is no element of 'std') D:\LyXSVN\lyx-devel\src\frontends\qt4\GuiTexinfo.cpp(162) : error C3861: sort: Bezeichner wurde nicht gefunden. (identifier was not found) What is wrong? thanks and regards Uwe
Re: r20290 - in /lyx-devel/trunk: lib/ui/stdtoolbars.inc src/...
On Mon, Sep 17, 2007 at 06:49:00PM +0200, Georg Baum wrote:
Martin Vermeer wrote:
Oops. Too difficult.
I don't think so. Just look how the two variants of sqrt (\sqrt{a}{b} and
\sqrt[a]{b}{c}) are handled and copy the relevant portions of code. If you
think that you do not really understand how the different parts of mathed
work together make Andre write some documentation :-)
Probably best to revert it.
If you revert, then please remove all \unitfrac variants. Otherwise you
create a regression, because \unitfrac[a]{b}{c} in 1.4 works fine as ERT,
and it would not if you only kept the short variant.
OK, the attached. Wasn't too hard, but I couldn't really spare the time.
Seems to work.
- Martin
Index: InsetMathFrac.h
===
--- InsetMathFrac.h (revision 20290)
+++ InsetMathFrac.h (working copy)
@@ -29,8 +29,7 @@
ATOP,
NICEFRAC,
UNITFRAC,
- UNIT,
- UNITFRAC3
+ UNIT
};
///
Index: MathFactory.cpp
===
--- MathFactory.cpp (revision 20290)
+++ MathFactory.cpp (working copy)
@@ -372,8 +372,9 @@
return MathAtom(new InsetMathFrac(InsetMathFrac::NICEFRAC));
if (s == unitfrac)
return MathAtom(new InsetMathFrac(InsetMathFrac::UNITFRAC));
+ // This string value is only for math toolbar use. Not a LaTeX name
if (s == unitfracthree)
- return MathAtom(new InsetMathFrac(InsetMathFrac::UNITFRAC3, 3));
+ return MathAtom(new InsetMathFrac(InsetMathFrac::UNIT, 3));
if (s == unit)
return MathAtom(new InsetMathFrac(InsetMathFrac::UNIT));
//if (s == infer)
Index: InsetMathFrac.cpp
===
--- InsetMathFrac.cpp (revision 20290)
+++ InsetMathFrac.cpp (working copy)
@@ -49,11 +49,12 @@
bool InsetMathFrac::idxRight(Cursor cur) const
{
InsetMath::idx_type target;
- if (kind_ == UNITFRAC3)
- target = 0;
- else if (kind_ == UNIT)
- target = 1;
- else
+ if (kind_ == UNIT) {
+ if (nargs() == 3)
+ target = 0;
+ else
+ target = 1;
+ } else
return false;
if (cur.idx() == target)
return false;
@@ -66,11 +67,12 @@
bool InsetMathFrac::idxLeft(Cursor cur) const
{
InsetMath::idx_type target;
- if (kind_ == UNITFRAC3)
- target = 2;
- else if (kind_ == UNIT)
- target = 0;
- else
+ if (kind_ == UNIT) {
+ if (nargs() == 3)
+ target = 2;
+ else
+ target = 0;
+ } else
return false;
if (cur.idx() == target)
return false;
@@ -83,21 +85,23 @@
bool InsetMathFrac::metrics(MetricsInfo mi, Dimension dim) const
{
if (kind_ == UNIT) {
- cell(0).metrics(mi);
- ShapeChanger dummy2(mi.base.font, Font::UP_SHAPE);
- cell(1).metrics(mi);
- dim.wid = cell(0).width() + cell(1).width() + 5;
- dim.asc = std::max(cell(0).ascent(), cell(1).ascent());
- dim.des = std::max(cell(0).descent(), cell(1).descent());
- } else if (kind_ == UNITFRAC3) {
- cell(2).metrics(mi);
- ShapeChanger dummy2(mi.base.font, Font::UP_SHAPE);
- FracChanger dummy(mi.base);
- cell(0).metrics(mi);
- cell(1).metrics(mi);
- dim.wid = cell(0).width() + cell(1).width() + cell(2).width() + 10;
- dim.asc = std::max(cell(2).ascent(), cell(0).height() + 5);
- dim.des = std::max(cell(2).descent(), cell(1).height() - 5);
+ if (nargs() == 2) {
+ cell(0).metrics(mi);
+ ShapeChanger dummy2(mi.base.font, Font::UP_SHAPE);
+ cell(1).metrics(mi);
+ dim.wid = cell(0).width() + cell(1).width() + 5;
+ dim.asc = std::max(cell(0).ascent(), cell(1).ascent());
+ dim.des = std::max(cell(0).descent(), cell(1).descent());
+ } else {
+ cell(2).metrics(mi);
+ ShapeChanger dummy2(mi.base.font, Font::UP_SHAPE);
+ FracChanger dummy(mi.base);
+ cell(0).metrics(mi);
+ cell(1).metrics(mi);
+ dim.wid = cell(0).width() + cell(1).width() + cell(2).width() + 10;
+ dim.asc = std::max(cell(2).ascent(), cell(0).height() + 5);
+ dim.des = std::max(cell(2).descent(), cell(1).height() - 5);
+ }
} else {
FracChanger dummy(mi.base);
cell(0).metrics(mi);
@@ -130,18 +134,20 @@
setPosCache(pi, x, y);
int m = x + dim_.wid / 2;
if (kind_ == UNIT) {
- cell(0).draw(pi, x + 1, y);
- ShapeChanger dummy2(pi.base.font, Font::UP_SHAPE);
- cell(1).draw(pi, x + cell(0).width() + 5, y);
- } else if (kind_ == UNITFRAC3) {
- cell(2).draw(pi, x + 1, y);
- ShapeChanger dummy2(pi.base.font, Font::UP_SHAPE);
- FracChanger dummy(pi.base);
- int xx = x + cell(2).width() + 5;
- cell(0).draw(pi, xx + 2,
- y - cell(0).descent() - 5);
- cell(1).draw(pi, xx + cell(0).width() + 5,
- y + cell(1).ascent() / 2);
+ if (nargs() == 2) {
+ cell(0).draw(pi, x + 1, y);
+ ShapeChanger dummy2(pi.base.font, Font::UP_SHAPE);
+ cell(1).draw(pi, x + cell(0).width() + 5, y);
+ } else {
+ cell(2).draw(pi, x + 1, y);
+ ShapeChanger dummy2(pi.base.font, Font::UP_SHAPE);
+ FracChanger dummy(pi.base);
+ int xx = x + cell(2).width() + 5;
+ cell(0).draw(pi, xx + 2,
+ y - cell(0).descent() -
Re: trunk does no longer compile
On Tue, Sep 18, 2007 at 12:24:35AM +0200, Uwe Stöhr wrote: Since last thursday I can't compile the trunk. I'm using MSVC and get now this error message: D:\LyXSVN\lyx-devel\src\frontends\qt4\GuiTexinfo.cpp(162) : error C2039: 'sort': Ist kein Element von 'std' (is no element of 'std') D:\LyXSVN\lyx-devel\src\frontends\qt4\GuiTexinfo.cpp(162) : error C3861: sort: Bezeichner wurde nicht gefunden. (identifier was not found) What is wrong? Missing #include algorithm. Fix committed. I probably should reconfigure --without-pch to chatch this kind of errors. Andre'
Re: r20313 - /lyx-devel/trunk/src/insets/InsetIndex.cpp
On Mon, Sep 17, 2007 at 01:16:21PM +0300, Martin Vermeer wrote: On Mon, 17 Sep 2007 11:47:37 +0200 [EMAIL PROTECTED] (Jürgen Spitzmüller) wrote: Jean-Marc Lasgouttes wrote: I did not have the time to chime in the allotted time, but I can say that the short version of index has been added after having a user remark astutely that displaying foo[idx: foo] was really a waste of UI space. I do not think that the example of changing 'a b' to 'b!a' rapidly is the best possible reason for making this change (how many times per year does this situation happen?). OK, I learned from this that adding an ui change on Sunday is not a good idea, even though the change looked straightforward to me. Having said that, there's still plenty of time to discuss this. If the majority thinks that the old behaviour is better until we have some more fancy means (as outlined by JMarc), we will revert. So please add your vote now, or remain silent: + Bo* + Jürgen* - Uwe - Jean-Marc + Martin* (until a better solution, e.g., tooltip) - Enrico -- Enrico
not possible to fix the g-brief layout
Concerning bug 4037:
g-brief is unusable since about a year. The reason is this entry in g-brief.cls:
\IfFileExists{marvosym.sty}
{\RequirePackage{marvosym}}
{}
\def\Telefon#1{\def\telefon{#1}} \def\telefon{}
But marvosym has already defined the command \Telefon. There is no way I know to avoid the LaTeX
command clash.
g-brief is furthermore out of date and not supported since years. There is only support for g-brief2
that also supports English directly.
So the correct fix is to drop the two g-brief layouts and add a routine in lyx2lyx that converts
files from g-brief to g-brief2. This is a file format change so I would say wontfix for LyX 1.5.x.
Besides this, tables work fine with g-brief2, see the latest attachment to
http://bugzilla.lyx.org/show_bug.cgi?id=4037
regards Uwe
Re: [Patch#4] Bug 3527 - Basic PDF support via hyperref
More comments:
+ } else if (token == \\use_hyperref) {
+ lex pdfoptions().use_hyperref;
+ } else if (token == \\pdf_title) {
+ lex pdfoptions().title;
+ } else if (token == \\pdf_author) {
+ lex pdfoptions().author;
Just a suggestion: in order to keep everything in one place, what
about doing
} else if (prefixIs(token, \\pdf_)
pdfoptions().read(token, lex);
and move the long string of tests to PDFOptions.cpp?
in fact, i'll be more happy to have all the code inside PDFOptions,
but i have seen that all other tokens are done there, so didnt want
to disturb the logic. i move it now.
@@ -1176,6 +1223,12 @@ bool BufferParams::writeLaTeX(odocstream os,
LaTeXFeatures features,
}
os lyxpreamble;
+
+ // PDF support. Hypreref manual: Make sure it comes last of your loaded
+ // packages, to give it a fighting chance of not being over-written,
+ // since its job is to redefine many LATEX commands.
+ pdfoptions().writeLatex(os);
+
return use_babel;
}
This one is wrong: you should find a way to add your code to
lyxpreamble, because as it is you break the line counting (for error
parsing) that is done a few lines above. Something like:
didnt know that, now i added a comment and moved the code. look into attachment
-
is it ok now ?
pavel
diff --git a/development/qmake/src/src.pro b/development/qmake/src/src.pro
index 2c44a0a..2a5c65c 100644
--- a/development/qmake/src/src.pro
+++ b/development/qmake/src/src.pro
@@ -69,6 +69,7 @@ HPP += Messages.h
HPP += MetricsInfo.h
HPP += Mover.h
HPP += OutputParams.h
+HPP += PDFOptions.h
HPP += PSpell.h
HPP += ParIterator.h
HPP += Paragraph.h
@@ -178,6 +179,7 @@ CPP += Messages.cpp
CPP += MetricsInfo.cpp
CPP += Mover.cpp
CPP += OutputParams.cpp
+CPP += PDFOptions.cpp
#CPP += PSpell.cpp
CPP += ParIterator.cpp
CPP += Paragraph.cpp
diff --git a/development/scons/scons_manifest.py
b/development/scons/scons_manifest.py
index b7b612b..e52a0a5 100644
--- a/development/scons/scons_manifest.py
+++ b/development/scons/scons_manifest.py
@@ -92,6 +92,7 @@ src_header_files = Split('''
ModuleList.h
Mover.h
OutputParams.h
+PDFOptions.h
PSpell.h
ParIterator.h
Paragraph.h
@@ -201,6 +202,7 @@ src_pre_files = Split('''
MetricsInfo.cpp
Mover.cpp
OutputParams.cpp
+PDFOptions.cpp
ParIterator.cpp
Paragraph.cpp
ParagraphMetrics.cpp
diff --git a/lib/CREDITS b/lib/CREDITS
index 33544f6..9c6df57 100644
--- a/lib/CREDITS
+++ b/lib/CREDITS
@@ -240,7 +240,7 @@
Support for kluwer and ijmpd document classes
@bSanda Pavel
@iE-mail: [EMAIL PROTECTED] !cz
- Czech translation
+ Czech translation, pdf support
@bBo Peng
@iE-mail: [EMAIL PROTECTED]
Conversion of all shell scripts to Python, session, view-source, auto-view
features and scons build system.
diff --git a/lib/lyx2lyx/lyx_1_6.py b/lib/lyx2lyx/lyx_1_6.py
index 84f8ba6..3506b4f 100644
--- a/lib/lyx2lyx/lyx_1_6.py
+++ b/lib/lyx2lyx/lyx_1_6.py
@@ -178,6 +178,24 @@ def remove_manifest(document):
Remove the manifest section
document.manifest = None
+##
+# Discard PDF options for hyperref
+#
+
+def revert_pdf_options(document):
+Revert PDF options for hyperref.
+i = 0
+while 1:
+i = find_tokens(document.header, [ \\use_hyperref, \\pdf_title,
\\pdf_author, \\pdf_subject,
+ \\pdf_keywords,
\\pdf_bookmarks, \\pdf_bookmarksnumbered,
+ \\pdf_bookmarksopen,
\\pdf_bookmarksopenlevel, \\pdf_breaklinks,
+ \\pdf_border, \\pdf_colorlinks,
\\pdf_backref, \\pdf_pagebackref,
+ \\pdf_fullscreen,
\\pdf_quoted_options, \\pdf_store_options ], i)
+if i == -1:
+return
+document.body[i] =
+i = i + 1
+
def remove_inzip_options(document):
Remove inzipName and embed options from the Graphics inset
diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index 19d479c..75799f7 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -55,6 +55,7 @@
#include Undo.h
#include version.h
#include EmbeddedFiles.h
+#include PDFOptions.h
#include insets/InsetBibitem.h
#include insets/InsetBibtex.h
@@ -459,6 +460,7 @@ int Buffer::readHeader(Lexer lex)
params().footskip.erase();
params().listings_params.clear();
params().clearLayoutModules();
+ params().pdfoptions().clear();
for (int i = 0; i 4; ++i) {
params().user_defined_bullet(i) = ITEMIZE_DEFAULTS[i];
diff --git a/src/BufferParams.cpp b/src/BufferParams.cpp
index 65195e5..62fd7b6 100644
--- a/src/BufferParams.cpp
+++ b/src/BufferParams.cpp
@@ -37,6 +37,7 @@
#include Spacing.h
#include TexRow.h
#include VSpace.h
+#include PDFOptions.h
#include frontends/alert.h
#include
Inset(Box) with fixed width
hello, i'm trying to derive new kind of inset, which would be similar to InsetBox, but i need it to be fixed-width (i mean really fixed, not that after reaching .width the inset is magnified to wider text). is this somehow possible to do just by deriving from eg InsetBox/InsetText with just adjusted parameters ? up to know i tried to clone insetbox and play with metrics written similarly to insetbox but it seems not easy to make it work. single touch and many things get broken with no obvious fix. btw it is know the painting bug of insetbox, when set to fixed width ? when typing gets over the width painting starts to be garbled, but it gets ok when moving mouse over it or make it somehow repainted with keyborad. pavel
Re: [Patch#4] Bug 3527 - Basic PDF support via hyperref
Pavel Sanda wrote: This one is wrong: you should find a way to add your code to lyxpreamble, because as it is you break the line counting (for error parsing) that is done a few lines above. Something like: didnt know that, now i added a comment and moved the code. look into attachment - is it ok now ? This is not the most obvious feature of the code. 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: r20313 - /lyx-devel/trunk/src/insets/InsetIndex.cpp
+ Bo* + Jürgen* - Uwe - Jean-Marc + Martin* (until a better solution, e.g., tooltip) - Enrico + Abdel There was a positive vote from Abdel. Bo
Re: [Cvslog] r20315 - in /lyx-devel/branches/BRANCH_1_5_X: src/insets/...
On 9/17/07, Uwe Stöhr [EMAIL PROTECTED] wrote:
I would suggest (think I did) to completely leave Idx: off, and make the
appearance of the button distinctive. People are curious and will click
if they wonder what it is, and will quickly learn.
This would be an option.
This would indeed be a solution, together with a limit for the label length
of 20 chars.
I quickly hacked something like the attached (screenshot and patch).
If people like it, I can implement it seriously later on (I will be
quite busy in the next two weeks, and this will have low priority). I
am be happy if someone (Uwe?) can take it over. The obvious things to
add may be a separate index background color, or something to the left
of the box to make it look like a P shape with | meaning Index.
I suspect that it would be difficult to satisfy everyone with the new
look of this index inset.
Cheers,
Bo
attachment: index.pngIndex: src/insets/RenderButton.cpp
===
--- src/insets/RenderButton.cpp (revision 20333)
+++ src/insets/RenderButton.cpp (working copy)
@@ -23,7 +23,7 @@
RenderButton::RenderButton()
- : editable_(false)
+ : editable_(false), type_(Regular)
{}
@@ -43,20 +43,37 @@
bool RenderButton::metrics(MetricsInfo , Dimension dim) const
{
Font font(Font::ALL_SANE);
- font.decSize();
- frontend::FontMetrics const fm =
- theFontMetrics(font);
+ if (type_ == Regular) {
+ font.decSize();
+ frontend::FontMetrics const fm =
+ theFontMetrics(font);
- if (editable_)
- fm.buttonText(text_, dim.wid, dim.asc, dim.des);
- else
- fm.rectText(text_, dim.wid, dim.asc, dim.des);
+ if (editable_)
+ fm.buttonText(text_, dim.wid, dim.asc, dim.des);
+ else
+ fm.rectText(text_, dim.wid, dim.asc, dim.des);
- dim.wid += 4;
- if (dim_ == dim)
- return false;
- dim_ = dim;
- return true;
+ dim.wid += 4;
+ if (dim_ == dim)
+ return false;
+ dim_ = dim;
+ return true;
+ } else if (type_ == UpperCorner) {
+ font.setSize(Font::SIZE_TINY);
+ frontend::FontMetrics const fm =
+ theFontMetrics(font);
+
+ if (editable_)
+ fm.buttonText(text_, dim.wid, dim.asc, dim.des);
+ else
+ fm.rectText(text_, dim.wid, dim.asc, dim.des);
+
+ dim.wid += 2;
+ if (dim_ == dim)
+ return false;
+ dim_ = dim;
+ return true;
+ }
}
@@ -65,13 +82,22 @@
// Draw it as a box with the LaTeX text
Font font(Font::ALL_SANE);
font.setColor(Color::command);
- font.decSize();
-
- if (editable_) {
- pi.pain.buttonText(x + 2, y, text_, font, renderState());
- } else {
- pi.pain.rectText(x + 2, y, text_, font,
- Color::commandbg, Color::commandframe);
+ if (type_ == Regular) {
+ font.decSize();
+ if (editable_) {
+ pi.pain.buttonText(x + 2, y, text_, font, renderState());
+ } else {
+ pi.pain.rectText(x + 2, y, text_, font,
+ Color::commandbg, Color::commandframe);
+ }
+ } else if (type_ == UpperCorner) {
+ font.setSize(Font::SIZE_TINY);
+ if (editable_) {
+ pi.pain.buttonText(x + 2, y - 8, text_, font, renderState());
+ } else {
+ pi.pain.rectText(x + 2, y - 8, text_, font,
+ Color::commandbg, Color::commandframe);
+ }
}
}
Index: src/insets/InsetIndex.cpp
===
--- src/insets/InsetIndex.cpp (revision 20333)
+++ src/insets/InsetIndex.cpp (working copy)
@@ -29,14 +29,16 @@
InsetIndex::InsetIndex(InsetCommandParams const p)
: InsetCommand(p, index)
-{}
+{
+ setButtonType(RenderButton::UpperCorner);
+}
docstring const InsetIndex::getScreenLabel(Buffer const ) const
{
size_t const maxLabelChars = 25;
- docstring label = _(Idx: ) + getParam(name);
+ docstring label = getParam(name);
if (label.size() maxLabelChars) {
label.erase(maxLabelChars - 3);
label += ...;
Index: src/insets/InsetCommand.h
===
--- src/insets/InsetCommand.h (revision 20333)
+++ src/insets/InsetCommand.h (working copy)
@@ -109,7 +109,8 @@
void setParams(InsetCommandParams const );
/// This should provide the text for the button
virtual docstring const getScreenLabel(Buffer const ) const = 0;
-
+ ///
+ void setButtonType(RenderButton::ButtonType type) { button_.setType(type); }
private:
///
InsetCommandParams p_;
Index: src/insets/RenderButton.h
===
--- src/insets/RenderButton.h (revision 20333)
+++ src/insets/RenderButton.h (working copy)
@@ -23,6 +23,12 @@
class RenderButton : public RenderBase
{
public:
+
+ enum ButtonType {
+ Regular,
+ UpperCorner,
+ };
+
RenderButton();
RenderBase * clone(Inset const *) const;
@@ -43,11 +49,13 @@
/// equivalent to dynamic_cast
virtual RenderButton * asButton() { return this; }
+ void setType(ButtonType type) { type_ = type; }
private:
/// The stored data.
docstring text_;
bool editable_;
Box button_box_;
+ ButtonType type_;
};
Re: [Cvslog] r20315 - in /lyx-devel/branches/BRANCH_1_5_X: src/insets/...
On Mon, Sep 17, 2007 at 10:27:22PM -0500, Bo Peng wrote:
On 9/17/07, Uwe Stöhr [EMAIL PROTECTED] wrote:
I would suggest (think I did) to completely leave Idx: off, and make the
appearance of the button distinctive. People are curious and will click
if they wonder what it is, and will quickly learn.
This would be an option.
This would indeed be a solution, together with a limit for the label length
of 20 chars.
I quickly hacked something like the attached (screenshot and patch).
If people like it, I can implement it seriously later on (I will be
quite busy in the next two weeks, and this will have low priority). I
am be happy if someone (Uwe?) can take it over. The obvious things to
add may be a separate index background color, or something to the left
of the box to make it look like a P shape with | meaning Index.
I suspect that it would be difficult to satisfy everyone with the new
look of this index inset.
Cheers,
Bo
A nice idea!
The y - 8 looks a bit arbitrary... shouldn't this be done using metrics
parameters?
- Martin
+ } else if (type_ == UpperCorner) {
+ font.setSize(Font::SIZE_TINY);
+ if (editable_) {
+ pi.pain.buttonText(x + 2, y - 8, text_, font,
renderState());
+ } else {
+ pi.pain.rectText(x + 2, y - 8, text_, font,
+ Color::commandbg, Color::commandframe);
+ }
Re: View Menu proposal
Darren Freeman wrote: On Fri, 2007-09-14 at 09:29 +0200, Jean-Marc Lasgouttes wrote: Darren Freeman <[EMAIL PROTECTED]> writes: Add three radio buttons to the configuration dialogue, under "Action to perform when a preview is still open", which would be "Ask what to do", "Always update the existing preview", and "Always open a new preview". Ugh. Not really a simplification of the use of LyX, is it? I think it is, actually. Half as many menu entries and less key bindings. Come to think of it, how come only DVI and PS have keyboard shortcuts? Are we all supposed to bind our favourite PDF method or could there be a default one chosen for a shortcut (to aid newbies in choosing one for example)? I've been wondering the same thing... I am not using PS at all and I guess neither are all Windows and Mac users. Could we just replace the binding for PS with PDF? If you closed the old preview, no change in behaviour. After the first time the dialogue appears, you either get your favourite action from now on, or you get asked each time the existing preview is open. This is very much like the UI of other popular apps. With shortcuts for the buttons on the dialogue, this is speedy from the keyboard too. (replace an extra shift modifier with a trailing Enter etc.) Perhaps there can be a statement next to the "Don't ask me again" box which lets you know the setting can be changed later in the appropriate configuration dialogue. It is just a matter of implementing it... Abdel.
Re: [Cvslog] r20315 - in /lyx-devel/branches/BRANCH_1_5_X: src/insets/...
Martin Vermeer wrote: On Mon, Sep 17, 2007 at 01:17:18AM +0200, Uwe Stöhr wrote: Bo Peng schrieb: This is not what I meant. "Idx: " is not translateable because it is not a word. The label should have the name "Index" not "Idx". This could then be translated to different languages, e.g to "Índice" when you use Spanish menus. You have complained that the label of index inset is too long now, and you want to change 'Idx: ' to 'Index: '? Exactly. After your explanation, I think that the first part is OK now as you implemented it, but Idx should be changed to Index. I do not actually mind the change, so you can change it if Jurgen (and Jose for trunk) agrees. Jürgen? regards Uwe I would suggest (think I did) to completely leave Idx: off, and make the appearance of the button distinctive. People are curious and will click if they wonder what it is, and will quickly learn. Agreed. A different background and/or text color should be enough. Abdel.
Re: [Cvslog] r20315 - in /lyx-devel/branches/BRANCH_1_5_X: src/insets/...
Uwe Stöhr wrote: > Besides this, I don't know why this could go to branch since there was no > need for this change. Because it was trivial and I agree with Bo that it is helpful. Jürgen
Re: [Cvslog] r20315 - in /lyx-devel/branches/BRANCH_1_5_X: src/insets/...
Martin Vermeer wrote: > > Jürgen? I think "Index: " plus a 25-char-string is too long (I actually think the string should be shortened to 20 chars anyway). And I don't understand why "Idx" isn't a suitable abbreviation (and also why it shouldn't be translatable; the abbreviation in other languages could be completely different). > > regards Uwe > > I would suggest (think I did) to completely leave Idx: off, and make the > appearance of the button distinctive. People are curious and will click > if they wonder what it is, and will quickly learn. This would be an option. Jürgen
Re: ERT in title bug
Martin Vermeer wrote: > Not needed... the fix replaces something that Abdel removed ;-) I'm confused. I thought this "ERT in titel bug" is something that appeared in 1.5.x? Jürgen
Re: ERT in title bug
Jürgen Spitzmüller wrote: Martin Vermeer wrote: Not needed... the fix replaces something that Abdel removed ;-) I'm confused. I thought this "ERT in titel bug" is something that appeared in 1.5.x? Yes, but the thread was hijacked by a different problem in trunk. The 1.5.x is different but still present AFAIU. Abdel.
Re: Box menu entry
Pavel Sanda wrote: > i would like to propose this small patch for box menu entry, as i want to > distinguish between inset and menu occurence of this string for translation > (for shortcut occurence to be more explicit). I think the proposal makes sense. I'm gonna put it in branch and trunk if I get no objections. Jürgen
Re: ERT in title bug
Abdelrazak Younes wrote: > Yes, but the thread was hijacked by a different problem in trunk. The > 1.5.x is different but still present AFAIU. OK. Thanks for the clarification. Jürgen
Re: [Cvslog] r20304 - in /lyx-devel/trunk/src: Converter.cpp Converter...
[EMAIL PROTECTED] writes:
> bool dummy = conv.To->dummy() && conv.to != "program";
> - if (!dummy)
> + if (!dummy) {
> LYXERR(Debug::FILES) << "Converting from "
> << conv.from << " to " << conv.to << endl;
> + }
> infile = outfile;
So the code is like
if (!dummy)
if (!lyxerr.debugging(Debug::FILES)) ; else lyxerr << "Converting from "
<< conv.from << " to " << conv.to << endl;
Isn't there some documented trick that avoids this warning? Having to
add braces around the second if is not nice.
Is there a way with gcc to silence a warning at a given place?
JMarc
Re: r20310 - in /lyx-devel/branches/BRANCH_1_5_X/boost/boost:...
Abdelrazak Younes <[EMAIL PROTECTED]> writes: > Is it our job to fix boost warnings? The benefit is that they do not hide our real warnings anymore. JMarc
Re: tex as lyx native file format
On Saturday 15 September 2007 22:10:07 Roberto Franceschini wrote:
> I'm just saying that one side LyX is the best word processor, but on
> the other side most of the people, dumb like mule, stick to LaTeX just
> because it's the standard de-facto.
What is a standard depends a lot on what people are used to. IMHO there is no
such a thing as a latex standard there are instead lots of local standards.
I have see people using \be for \begin{equation}, \ee for \end{equation} and
for languages that use accents lots of other funny (and weird) definitions to
allow the use of accented characters.
So for me a standard latex is a urban legend, everyone talks about it but no
one ever saw it. ;-)
--
José Abílio
Re: [Cvslog] r20304 - in /lyx-devel/trunk/src: Converter.cpp Converter...
Jean-Marc Lasgouttes wrote:
[EMAIL PROTECTED] writes:
bool dummy = conv.To->dummy() && conv.to != "program";
- if (!dummy)
+ if (!dummy) {
LYXERR(Debug::FILES) << "Converting from "
<< conv.from << " to " << conv.to << endl;
+ }
infile = outfile;
So the code is like
if (!dummy)
if (!lyxerr.debugging(Debug::FILES)) ; else lyxerr << "Converting from "
<< conv.from << " to " << conv.to << endl;
Isn't there some documented trick that avoids this warning? Having to
add braces around the second if is not nice.
What about enclosing the macro with {}?
{if (!lyxerr.debugging(Debug::FILES)) ; else lyxerr << "Converting from "
> << conv.from << " to " << conv.to << endl; }
Abdel.
Re: [Patch#3] Bug 3527 - Basic PDF support via hyperref
Pavel Sanda <[EMAIL PROTECTED]> writes:
> i tried to incorporate the comments, now sending the resulting patch
> and propose to merge it into trunk.
More comments:
> + } else if (token == "\\use_hyperref") {
> + lex >> pdfoptions().use_hyperref;
> + } else if (token == "\\pdf_title") {
> + lex >> pdfoptions().title;
> + } else if (token == "\\pdf_author") {
> + lex >> pdfoptions().author;
Just a suggestion: in order to keep everything in one place, what
about doing
} else if (prefixIs(token, "\\pdf_")
pdfoptions().read(token, lex);
and move the long string of tests to PDFOptions.cpp?
> @@ -1176,6 +1223,12 @@ bool BufferParams::writeLaTeX(odocstream & os,
> LaTeXFeatures & features,
> }
>
> os << lyxpreamble;
> +
> + // PDF support. Hypreref manual: "Make sure it comes last of your loaded
> + // packages, to give it a fighting chance of not being over-written,
> + // since its job is to redefine many LATEX commands."
> + pdfoptions().writeLatex(os);
> +
> return use_babel;
> }
This one is wrong: you should find a way to add your code to
lyxpreamble, because as it is you break the line counting (for error
parsing) that is done a few lines above. Something like:
odocstringstream pos;
pdfOptions.writeLatex(pos);
os << pos.str();
Alternatively, turn PDFOptions::writeLatex (that should be renamed to
writeLaTeX anyway) into something that returns a docstring.
I am glad somebody finally decided to make this work.
JMarc
Re: r20313 - /lyx-devel/trunk/src/insets/InsetIndex.cpp
"Bo Peng" <[EMAIL PROTECTED]> writes: > I needed to change some index labels from 'a b' to 'b!a' for my > document and I quickly lost track of which indexes have been updated > and which have not. The ability to make this change in 5 minutes > demonstrates the real benefit of using an open source program. (Ohmm, > normal users need to wait longer.. :-) I did not have the time to chime in the allotted time, but I can say that the short version of index has been added after having a user remark astutely that displaying "foo[idx: foo]" was really a waste of UI space. I do not think that the example of changing 'a b' to 'b!a' rapidly is the best possible reason for making this change (how many times per year does this situation happen?). Some other solutions could have been considered: - have insets implement a description() method that returns a somewhat longer label that can be used to * display a tooltip on hover * set the status bar when the cursor is in front of the inset (we have that for math already). [*] - add index entries to yet another TOC and use that to both navigate and get a clear view of the index. - what would be even better would be to have the index inset display its contents only if it is different from the default label. It would mean however that the cursor should be known at the point where getScreenLabel is invoked, which does not seem feasible right now. JMarc [*] this would be pretty handy with an additional index-next lfun that would go to the next inset of same type than the one at cursor. This would replace advantageously note-next and allow to go from index entry to index entry effortlessly (and see the complete index in status bar)
Re: Master Preview
Tommaso Cucinotta <[EMAIL PROTECTED]> writes: >> That would then be opened whenever the child was, and the various >> settings imported (which, in the code, may mean no more than giving >> the two documents the same BufferParams). > Infact, I was just thinking at smth. like that. The main point I > think would be avoiding replication of information between the > master and child. Their infos are merged only by LyX at run-time for > the various purposes (at least previewing and macro expansion). We discussed several times the idea of giving the child document the same bufferparams as its master. This is quite easy to do, but I would be surprised to see that it works without hurdles... We should do it anyway. >From a UI POV, we could disable Document>Settings for the child to show what happens in an obvious way (and maybe add a Document>Master settings...).
Re: View Menu proposal
Abdelrazak Younes <[EMAIL PROTECTED]> writes: > I've been wondering the same thing... I am not using PS at all and I > guess neither are all Windows and Mac users. Could we just replace the > binding for PS with PDF? Adding a shortcut for PDF does not mean that the PS one should be removed (in particular Ctrl+t is a weird choice for PDF). Then for pdf, we need to query the exporter to list all the ways to produce PDF and let the user choose its preferred one. This would allow to get rid of pdf[123], but should be done carefully to avoid hardcoding. JMarc
Re: trac
Pavel Sanda <[EMAIL PROTECTED]> writes: > hello, > am i the only one, who does not see trac timeline anymore ? It seems to work now. JMarc
Re: static_mutex.hpp
Roger Mc Murtrie <[EMAIL PROTECTED]> writes: > svn branch 1.5 > > boost/boost/regex/v4/cpp_regex_traits.hpp contains the lines > #ifdef BOOST_HAS_THREADS > #include > #endif > > but boost/boost/regex/pending/ only seems to contain the file > object_cache.hpp > > Can anyone tell me why this is? Because BOOST_HAS_THREADS is undefined for LyX? JMarc
Re: r20313 - /lyx-devel/trunk/src/insets/InsetIndex.cpp
Jean-Marc Lasgouttes wrote: > I did not have the time to chime in the allotted time, but I can say > that the short version of index has been added after having a user > remark astutely that displaying "foo[idx: foo]" was really a waste of > UI space. I do not think that the example of changing 'a b' to 'b!a' > rapidly is the best possible reason for making this change (how many > times per year does this situation happen?). OK, I learned from this that adding an ui change on Sunday is not a good idea, even though the change looked straightforward to me. Having said that, there's still plenty of time to discuss this. If the majority thinks that the old behaviour is better until we have some more fancy means (as outlined by JMarc), we will revert. So please add your vote now, or remain silent: + Bo* + Jürgen* - Uwe - Jean-Marc Jürgen * including the possibility to change the appearance of the label
Re: static_mutex.hpp
On 17/09/2007, at 7:27 PM, Jean-Marc Lasgouttes wrote: Roger Mc Murtrie <[EMAIL PROTECTED]> writes: svn branch 1.5 boost/boost/regex/v4/cpp_regex_traits.hpp contains the lines #ifdef BOOST_HAS_THREADS #include #endif but boost/boost/regex/pending/ only seems to contain the file object_cache.hpp Can anyone tell me why this is? Because BOOST_HAS_THREADS is undefined for LyX? JMarc OK if this is so. I did find definitions in: /boost/boost/config/platform/macos.hpp /boost/boost/config/compiler/gcc.hpp But I guess these are not used by LyX? Thanks, Roger
Re: r20313 - /lyx-devel/trunk/src/insets/InsetIndex.cpp
On Mon, 17 Sep 2007 10:53:30 +0200 Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote: > "Bo Peng" <[EMAIL PROTECTED]> writes: > > > I needed to change some index labels from 'a b' to 'b!a' for my > > document and I quickly lost track of which indexes have been updated > > and which have not. The ability to make this change in 5 minutes > > demonstrates the real benefit of using an open source program. (Ohmm, > > normal users need to wait longer.. :-) > > I did not have the time to chime in the allotted time, but I can say > that the short version of index has been added after having a user > remark astutely that displaying "foo[idx: foo]" was really a waste of > UI space. I do not think that the example of changing 'a b' to 'b!a' > rapidly is the best possible reason for making this change (how many > times per year does this situation happen?). > > Some other solutions could have been considered: > > - have insets implement a description() method that returns a somewhat > longer label that can be used to > * display a tooltip on hover > * set the status bar when the cursor is in front of the inset (we >have that for math already). [*] Another alternative is to introduce "closed" and "open" versions of the inset, like we have for collapsable insets. Then you can close and open them all together. Tooltip would be best though if easy to do. > - add index entries to yet another TOC and use that to both navigate > and get a clear view of the index. > > - what would be even better would be to have the index inset display > its contents only if it is different from the default label. It > would mean however that the cursor should be known at the point > where getScreenLabel is invoked, which does not seem feasible right now. > > JMarc > > [*] this would be pretty handy with an additional index-next lfun that > would go to the next inset of same type than the one at cursor. This > would replace advantageously note-next and allow to go from index > entry to index entry effortlessly (and see the complete index in > status bar) >
Re: r20313 - /lyx-devel/trunk/src/insets/InsetIndex.cpp
On Mon, 17 Sep 2007 11:47:37 +0200 [EMAIL PROTECTED] (Jürgen Spitzmüller) wrote: > Jean-Marc Lasgouttes wrote: > > I did not have the time to chime in the allotted time, but I can say > > that the short version of index has been added after having a user > > remark astutely that displaying "foo[idx: foo]" was really a waste of > > UI space. I do not think that the example of changing 'a b' to 'b!a' > > rapidly is the best possible reason for making this change (how many > > times per year does this situation happen?). > > OK, I learned from this that adding an ui change on Sunday is not a good > idea, > even though the change looked straightforward to me. > > Having said that, there's still plenty of time to discuss this. If the > majority thinks that the old behaviour is better until we have some more > fancy means (as outlined by JMarc), we will revert. > > So please add your vote now, or remain silent: > > + Bo* > + Jürgen* > - Uwe > - Jean-Marc + Martin* (until a better solution, e.g., tooltip) > Jürgen > > * including the possibility to change the appearance of the label
Re: static_mutex.hpp
Roger Mc Murtrie <[EMAIL PROTECTED]> writes: > I did find definitions in: > /boost/boost/config/platform/macos.hpp > /boost/boost/config/compiler/gcc.hpp Note that we do #define BOOST_DISABLE_THREADS 1 in src/config.h.in. JMarc
Re: [PATCH] fix M-Return
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes: > Jean-Marc Lasgouttes wrote: >> The behaviour of M-Return is the exact symmetry of what Return would >> do: > > I see. I'm fine with that (though I still prefer the old behaviour, i.e. swap > Return and M-Return). Could you be more precise? I do not think the behaviour of Return has been changed recently. What would you like to see? > I'm not sure I like this. Why should we double the functionality of > depth-decrement? Currently, pressing Return on an empty paragraph does nothing. The idea is for example, at the end of an enumeration, one types return twice and LyX is back to top level standard style. JMarc
Re: [Patch] Re: [Patch] partial support for units
Martin Vermeer wrote:
On Fri, Sep 14, 2007 at 03:36:10PM +0200, Helge Hafting wrote:
"\unitfrac" supports a similiar optional argument for the number, but
that capability is not used in lyx. So we can now write
$35\unitfrac{km}{h}$
but not
$\unitfrac[35]{km}{h}$
The latter looks better, with better spacing. One can insert
the missing space explicitly, and get $35\,\unitfrac{km}{h}
which looks the same in the dvi.
The attached supports now all these alternatives. As a bonus, we have
now the option of varying numbers of cells. Also cursor motion should
now be OK.
I will commit this if I don't hear an outcry. Suggestions for better
toolbar pop-up texts are especially welcome.
I was unable to test because the patch did not apply. Too
many other patches going in probably. I guess this stuff
is fine anyway.
Helge Hafting
Re: [PATCH] fix M-Return
Jean-Marc Lasgouttes wrote: > Could you be more precise? I do not think the behaviour of Return has > been changed recently. What would you like to see? I'm referring to the old behaviour where M-return was necessary to preserve the nesting level. > > I'm not sure I like this. Why should we double the functionality of > > depth-decrement? > > Currently, pressing Return on an empty paragraph does nothing. The > idea is for example, at the end of an enumeration, one types return > twice and LyX is back to top level standard style. I see. But this could be implemented in a second step. Jürgen
Re: [Patch] Re: [Patch] partial support for units
On Mon, 17 Sep 2007 13:53:03 +0200
Helge Hafting <[EMAIL PROTECTED]> wrote:
> Martin Vermeer wrote:
> > On Fri, Sep 14, 2007 at 03:36:10PM +0200, Helge Hafting wrote:
> >
> >> "\unitfrac" supports a similiar optional argument for the number, but
> >> that capability is not used in lyx. So we can now write
> >> $35\unitfrac{km}{h}$
> >> but not
> >> $\unitfrac[35]{km}{h}$
> >> The latter looks better, with better spacing. One can insert
> >> the missing space explicitly, and get $35\,\unitfrac{km}{h}
> >> which looks the same in the dvi.
> >>
> >
> > The attached supports now all these alternatives. As a bonus, we have
> > now the option of varying numbers of cells. Also cursor motion should
> > now be OK.
> >
> > I will commit this if I don't hear an outcry. Suggestions for better
> > toolbar pop-up texts are especially welcome.
> >
> I was unable to test because the patch did not apply. Too
> many other patches going in probably. I guess this stuff
> is fine anyway.
>
> Helge Hafting
The patch is already in (perhaps that's why it didn't apply :-)
- Martin
Re: View Menu proposal
On Sep 17, 2007, at 5:25 AM, Jean-Marc Lasgouttes wrote: Abdelrazak Younes <[EMAIL PROTECTED]> writes: I've been wondering the same thing... I am not using PS at all and I guess neither are all Windows and Mac users. Could we just replace the binding for PS with PDF? I think this would be preferable. Adding a shortcut for PDF does not mean that the PS one should be removed (in particular Ctrl+t is a weird choice for PDF). I don't think it's weird: doesn't the "t" stand for "typeset"? It's also the keybinding in other Mac programs to generate typeset output from a .tex file (such as TeXShop.app). Bennett
bug in lyx 1.5.1? translation of abstractname
Hello,
is this a bug? Haven't found anything on bugzilla.
I have installed a German LyX 1.5.1 on gentoo Linux. In article (RevTeX)
class I want to write an English article (I set Language to English in
Document -> Preferences) but the \abstractname shows as
"Zusammenfassung" (German term) rather than "Abstract" in the final pdf
or dvi output. I tried
\def\abstractname{Abstract},
\renewcommand\abstractname{Abstract}
and even
\AtBeginDocument{%
\addto\captions{%
\renewcommand{\abstractname}{In nuce}%
}}
in the preamble, but nothing helped.
What is even more puzzling is, that the Acknowledgements term is spelled
correctly (in English).
Including my Emailaddress in the answer (since I'm not member of the
list) would be appreciated.
Thanks in advance
Kai
Re: [PATCH] fix M-Return
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes: > Jean-Marc Lasgouttes wrote: >> Could you be more precise? I do not think the behaviour of Return has >> been changed recently. What would you like to see? > > I'm referring to the old behaviour where M-return was necessary to preserve > the nesting level. Bu currently with environments (itemize, etc.) both return and M-return keep the nesting level. How do you go to a lower level usually? JMarc
Re: [PATCH] fix M-Return
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes: > Jean-Marc Lasgouttes wrote: >> Bu currently with environments (itemize, etc.) both return and >> M-return keep the nesting level. > > Yes (which is bad). > >> How do you go to a lower level usually? > > M-S-. Which is less fun than pressing Return repeatedly, you'll admit :) So, what would be your preferred behaviour? JMarc
Re: [PATCH] fix M-Return
Jean-Marc Lasgouttes wrote: > Bu currently with environments (itemize, etc.) both return and > M-return keep the nesting level. Yes (which is bad). > How do you go to a lower level usually? M-S-. Jürgen
Re: [PATCH] fix M-Return
Jean-Marc Lasgouttes wrote: > Which is less fun than pressing Return repeatedly, you'll admit :) Well, let's say you get used to it ... > So, what would be your preferred behaviour? Let's forget about my (personal) preferred behaviour (I am obviously a minority here). I think your patch is a step in the right direction, and I also agree that your return-in-an-empty-nested-paragraph idea would be an improvement. So I'd be both fine with applying your patch now and the return thing later or implementing both at once, if you come up with a sensible patch. Jürgen
Re: r20313 - /lyx-devel/trunk/src/insets/InsetIndex.cpp
> + Martin* (until a better solution, e.g., tooltip) I agree. The easiest solution might be to add a checkbox somewhere to the preference dialog ... Bo
Re: [Cvslog] r20315 - in /lyx-devel/branches/BRANCH_1_5_X: src/insets/...
> I think "Index: " plus a 25-char-string is too long (I actually think the > string should be shortened to 20 chars anyway). And remove the space after :. Bo
Re: Compiling with --enable-shared leads to errors.
On Tuesday 11 September 2007 16:41:03 Andre Poenitz wrote: > > --enable-shared is for people that do not ask questions ;-) Don't worry I _will_ forget that rule. :-) [...] > > /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libboost_regex-mt.so: > > undefined reference to `u_charType_3_7' > > collect2: ld returned 1 exit status > > Do we use --without-included-boost regularily? I intend to. :-) OK, the above is a problem with Fedora implementation. The boost library there needs to be rebuilt against the latest icu(-3.8). Yet, I need the following patch to be able to compile lyx without an included boost. Any objection? The patch seems to be a good first step. Eventually, if we stay with autotools, we need something like: http://viewmtn.angrygoats.net/revision/file/6eb785c496e3973605995ca5d5777cc1879d56da/m4/boost.m4 > Andre' -- José Abílio Index: src/tex2lyx/Makefile.am === --- src/tex2lyx/Makefile.am (revision 20319) +++ src/tex2lyx/Makefile.am (working copy) @@ -63,8 +63,7 @@ tex2lyx_LDADD = \ $(top_builddir)/src/support/liblyxsupport.la \ - $(top_builddir)/boost/liblyxboost.la \ - $(LIBICONV) @LIBS@ + $(LIBICONV) $(BOOST_LIBS) @LIBS@ tex2lyx.1: cp -p $(srcdir)/tex2lyx.man tex2lyx.1 Index: config/common.am === --- config/common.am (revision 20319) +++ config/common.am (working copy) @@ -37,6 +37,7 @@ BOOST_REGEX = -lboost_regex BOOST_SIGNALS = -lboost_signals BOOST_IOSTREAMS = -lboost_iostreams +BOOST_LIBS = $(BOOST_FILESYSTEM) $(BOOST_REGEX) $(BOOST_SIGNALS) $(BOOST_IOSTREAMS) endif LIBS =
Re: View Menu proposal
Bennett Helm <[EMAIL PROTECTED]> writes: > I don't think it's weird: doesn't the "t" stand for "typeset"? It's > also the keybinding in other Mac programs to generate typeset output > from a .tex file (such as TeXShop.app). I think it was the 't' of postscript (as you know, Ctrl+P, Ctrl+O and Ctrl+S were already taken). In this case, Ctrl+T should not be bound to pdf, but we need a pref to set the preferred preview format and buffer-preview (without argument could default to that). JMarc
Re: Master Preview
Tommaso Cucinotta wrote: But this won't be a problem at all with Stefan's new code, which should go into 1.6.svn soon. How will that work ? He's got a complete, and much more flexible, re-write of the macro code on the way. I can't remember the details, but it is very, very cool. Richard
