[patch] support for \makebox

2010-06-26 Thread Uwe Stöhr
The attached patch adds support for \makebox (box without frame and inner box). This fixes http://www.lyx.org/trac/ticket/2956 and is a fileformat change. You might think that such a box is useless. But we should leave the decision to the user. LaTeX is offering \makebox for good reasons and ex

Re: [patch] support for \makebox

2010-06-26 Thread Uwe Stöhr
Am 26.06.2010 18:56, schrieb Jürgen Spitzmüller: I wonder why the \makebox is an "outer" box, while \parbox is an "inner" box. Shouldn't they both be of the same type? \makebox is the same as \framebox, except that the line width is zero. So it can be treated as outer box. But in our current

Re: [patch] support for \makebox

2010-06-27 Thread Uwe Stöhr
Am 27.06.2010 10:41, schrieb Jürgen Spitzmüller: But the logic remains odd. In our dialog, inner boxes are nested in outer boxes. You can nest a parbox in a framebox by selecting outer "Simple Frame" and inner "Parbox". You cannot -- with your patch -- nest a parbox in a makebox. Notwithstanding

Re: [patch] support for \makebox

2010-06-27 Thread Uwe Stöhr
Am 26.06.2010 20:13, schrieb Vincent van Ravesteijn: Besides this, wwe have a new major regression due to the new "apply immediately" dialog optio What exactly is major about it ? Because this affected all dialogs here. Moreover, I can't even reproduce it. I did now a fresh recompilatio

Re: r34721 - lyx-devel/trunk/src/support

2010-07-02 Thread Uwe Stöhr
> Launch external Windows processes for e.g. display image conversion using > CreateProcess with a CREATE_NO_WINDOW flag, allowing LyX to be compiled as a > GUI application without console windows popping up. Hi Joost, Where can I specify this option? I cannot find any further documentation of t

Re: [patch] support for \makebox

2010-07-03 Thread Uwe Stöhr
Am 28.06.2010 07:46, schrieb Jürgen Spitzmüller: 1. add makebox permanently to the inner box combo box 2. add makebox only to the inner combo box if no outer box is set I much prefer the second option because a framed outer box with an inner makebox is senseless - LaTeX internally already adds

Re: r34753 - lyx-devel/trunk/lib/lyx2lyx

2010-07-06 Thread Uwe Stöhr
Am 06.07.2010 00:31, schrieb Richard Heck: There is a lot you do not cover in these routines, e.g., math. Hmm, but math and other insets like nomenclature work for me. But the good news is that there is already a lyx2latex routine that you can use here. Look at how it is used, for example, i

Re: r34753 - lyx-devel/trunk/lib/lyx2lyx

2010-07-07 Thread Uwe Stöhr
Am 07.07.2010 03:59, schrieb Richard Heck: I eventually realized what you were doing, which does seem right. I wonder if it would have been easier to do it this way for Index entries, too, rather than use the complicated method we did. I'll have a look. One thing you might want to check. Rig

new compilation warning

2010-07-07 Thread Uwe Stöhr
Compiling todays' SVN trunk pops up this warning: D:\LyXSVN\lyx-devel\src\LyXRC.cpp(289) : warning C4067: unexpected tokens following preprocessor directive - expected a newline Can this be ignored as MAC-specific? regards Uwe

Re: new compilation warning

2010-07-07 Thread Uwe Stöhr
Am 08.07.2010 03:06, schrieb Uwe Stöhr: Compiling todays' SVN trunk pops up this warning: D:\LyXSVN\lyx-devel\src\LyXRC.cpp(289) : warning C4067: unexpected tokens following preprocessor directive - expected a newline Another occurence: LyX.cpp(1331) : warning C4067: unexpected t

CMake compilation errors

2010-07-07 Thread Uwe Stöhr
When compiling todays' trunk using CMake I get a whole bunch of errors: 9>d:\lyxsvn\lyx-devel\intl\gettextP.h(109) : error C2054: expected '(' to follow 'inline' 9>d:\lyxsvn\lyx-devel\intl\gettextP.h(110) : error C2085: 'SWAP' : not in formal parameter list 9>d:\lyxsvn\lyx-devel\intl\gettextP.h

AppleSpellChecker not compilable

2010-07-07 Thread Uwe Stöhr
I cannot compile LyX including the new AppleSpellChecker: Creating library release\lyx.lib and object release\lyx.exp AppleSpellChecker.obj : error LNK2019: unresolved external symbol _newAppleSpeller referenced in function "public: __thiscall lyx::AppleSpellChecker::Private::Private(void)"

Re: AppleSpellChecker not compilable

2010-07-07 Thread Uwe Stöhr
Am 08.07.2010 03:19, schrieb Uwe Stöhr: I cannot compile LyX including the new AppleSpellChecker: Sorry for the noise. It was my mistake; I fixed now SCons accordingly. (I'll test the compilation again when CMake is working for me.) regards Uwe

[patch for branch] fix LFUN_BREAK_PARAGRAPH for boxes

2010-07-07 Thread Uwe Stöhr
This small patch fixes the following bug: LyX allows to create \frameboxes with multiple paragraph if there is no inner box. But this is only possible for shaded boxes. OK? regards Uwe Index: InsetBox.cpp === --- InsetBox.cpp (rev

Re: r34753 - lyx-devel/trunk/lib/lyx2lyx

2010-07-07 Thread Uwe Stöhr
Am 08.07.2010 01:23, schrieb Richard Heck: No, but it's not a matter of more than one paragraph, necessarily. Can you do a makebox with a list in LyX? No, this is only possible for parbox, minipage and shaded. I just fixed some remaining issues in the makebox routine and it now works for all

Re: [patch for branch] fix LFUN_BREAK_PARAGRAPH for boxes

2010-07-07 Thread Uwe Stöhr
Am 08.07.2010 04:46, schrieb Uwe Stöhr: This small patch fixes the following bug: LyX allows to create \frameboxes with multiple paragraph if there is no inner box. But this is only possible for shaded boxes. Attached is a better patch that additionally fixes this issue: If you have a shaded

Re: r34753 - lyx-devel/trunk/lib/lyx2lyx

2010-07-10 Thread Uwe Stöhr
Am 08.07.2010 15:02, schrieb Kornel Benko: Open this document. Setting of "hello2"-box indicates horizontal right alignement. But View->[PDF (pdflatex)] gives text aligned left. GMANE swallowed your attachment. Can you please send me the file as attachment to a private mail? thanks and rega

Re: LyX 1.6.7

2010-07-11 Thread Uwe Stöhr
> We can go on ... I've uploaded my installer: https://developer.berlios.de/project/showfiles.php?group_id=5117&release_id=17719 Can you please put them on ftp.lyx.org? thanks and regards Uwe

Re: LyX 1.6.7

2010-07-11 Thread Uwe Stöhr
Am 11.07.2010 16:47, schrieb Jürgen Spitzmüller: I do not think, though, that the binaries that do not use cmake (i.e., yours, Enrico's and Bennett's) need to be rebuilt. Fine. I use MSVC 2008 and am therefore not affected by the MSVC problems. regards Uwe

changeset/34855

2010-07-11 Thread Uwe Stöhr
Hi Richard, you forgot to commit the file theorems-refprefix.inc regards Uwe

[patch] support for the DIN ISO C paper format series

2010-07-11 Thread Uwe Stöhr
The new geometry version now also allows to use DIN-ISO C paper sizes for documents. The attached patch implements them for LyX. This will be a fileformat change. regards Uwe Index: lib/lyx2lyx/lyx_2_0.py === --- lib/lyx2lyx/lyx_2_0

Re: [patch] support for the DIN ISO C paper format series

2010-07-12 Thread Uwe Stöhr
> i miss FORMAT entry and version should incerease too. I don't increase the fileformat in these patches to be able to apply the patch and test it without having conflicts with other patches you might have in your tree. As no one is opposed to this patch and as it is straight forward, I have p

Re: r34866 - lyx-devel/branches/BRANCH_1_6_X/development

2010-07-12 Thread Uwe Stöhr
> Uwe, is it really necessary to rename this file at every release? No. I'll rename it for the next version. > I have to fix the Makefile at every release at make dist step; this is quite annoying. I wasn't aware that you also take care about the Windows installer files. sorry and regards Uwe

Re: LyX 1.6.7

2010-07-12 Thread Uwe Stöhr
> With the latest updates in trunk it's now possible to run LyX by just clicking lyx.exe, > without the need for a launcher or any registry keys or environment variables. Very nice! Can you please tell me how to compile LyX to achieve this? I'm still stuck with your new compilation option and

Bug #3221: nameref support

2010-07-12 Thread Uwe Stöhr
> The only thing I'm not sure about, which Uwe mentioned in the bug, is the precise loading order > of packages. This doesn't seem to be an issue with the new nameref version because the former conflicts with memoir and varioref are resolved. I did some test and your implementation works fine f

Re: Bug #3221: nameref support

2010-07-12 Thread Uwe Stöhr
There is another issue: The text "on page" is not yet translated to the document language. One manually has to add this preamble code: \renewcommand*\Nameref[1]{`\nameref{#1}' auf Seite~\pageref{#1}} "auf Seite" is hereby the German translation of "on page". As this is no solution for us I pro

Re: Bug #3221: nameref support

2010-07-13 Thread Uwe Stöhr
Am 13.07.2010 05:13, schrieb Richard Heck: I did some test and your implementation works fine for me except of these: 1. insert a reference, select the style "Textual reference" and press APPLY (don't close the dialog) 2. change the style to e.g. "Textual reference plus " Result: the apply butt

Re: Bug #3221: nameref support

2010-07-13 Thread Uwe Stöhr
Am 13.07.2010 05:23, schrieb Richard Heck: There is another issue: The text "on page" is not yet translated to the document language. One manually has to add this preamble code: \renewcommand*\Nameref[1]{`\nameref{#1}' auf Seite~\pageref{#1}} "auf Seite" is hereby the German translation of "on

Re: Bug #3221: nameref support

2010-07-13 Thread Uwe Stöhr
Am 13.07.2010 13:59, schrieb Uwe Stöhr: We can easily convert this to: \begin_inset ERT status collapsed \begin_layout Plain Layout \backslash vref{ \end_layout \end_inset sec:dsf \begin_inset ERT status collapsed \begin_layout Plain Layout } \end_layout \end_inset Sorry, I meant to convert

Re: Bug #3221: nameref support

2010-07-13 Thread Uwe Stöhr
Am 13.07.2010 15:47, schrieb Richard Heck: Again, this isn't the issue. What I do has the same effect, No, it has not, the suer gets a number instead of the name of the reference. is simpler, and doesn't use ERT: I just convert the command from \nameref to \ref or \Nameref to \vref. The poin

Re: Bug #3221: nameref support

2010-07-13 Thread Uwe Stöhr
Am 13.07.2010 15:50, schrieb Richard Heck: There's no lyx2lyx issue, There is, see my previous mail! OK, I'll change the lyx2lyx routine so that the result gives the same output for the user. and the translation issue can be addressed independently. You're welcome to add your code if you w

Re: Bug #3221: nameref support

2010-07-14 Thread Uwe Stöhr
Am 13.07.2010 23:10, schrieb Richard Heck: So now we just have to figure out the translation issue. Are you sure the nameref folks have no interest in fixing this? Yes, because I asked them to add this feature some time ago when i met the hyperref developer personally. But it is OK that the

Re: Bug #3221: nameref support

2010-07-14 Thread Uwe Stöhr
Am 14.07.2010 22:41, schrieb Richard Heck: p.s. sorry for my harsh words in my previous email No problem, Uwe. I know you get over-animated sometimes. But you do owe me a beer. What, what, what? You do the mistakes, I correct them, I'm the brave one speaking out the truth, fix all problems,

Re: [patch for branch] fix LFUN_BREAK_PARAGRAPH for boxes

2010-07-15 Thread Uwe Stöhr
>> > This small patch fixes the following bug: >> > LyX allows to create \frameboxes with multiple paragraph if there is no >> > inner box. But this is only possible for shaded boxes. >> >> Attached is a better patch that additionally fixes this issue: >> If you have a shaded box and no inner box,

Re: Bug #3221: nameref support

2010-07-15 Thread Uwe Stöhr
>> Why not >> >> {\nameref{#1}~\vpageref{#1}} >> >> This will use all variants of varioref page handling. > > Rather {\nameref{#1} \vpageref{#1}}, the unbrealkable space is not necessary > here (nor with \reftextfaraway in fact, page~xxx can be on the nest line). Yes, this is the better so

Re: Bug #3221: nameref support

2010-07-16 Thread Uwe Stöhr
Am 16.07.2010 05:28, schrieb Richard Heck: I'm starting to think that maybe \Nameref isn't worth supporting and we should just support \nameref. I agree. It is impossible to support \Nameref for all languages. As it is, the output is only correct for (British) English documents and cannot be

[patch] support for math formal script - fixes #2340

2010-07-17 Thread Uwe Stöhr
The attached patch is an updated version of Georg Baum's patch for #2340. It provides support for formal math script (LaTeX command \mathrsfs). This would be a fileformat change. The only missing thing is the file "rsfs10.ttf" to display the script within LyX on Windows. Can somebody do me the

Re: [patch] support for math formal script - fixes #2340

2010-07-17 Thread Uwe Stöhr
Am 17.07.2010 16:16, schrieb Uwe Stöhr: The attached patch is an updated version of Georg Baum's patch for #2340. There as a small bug in there. Attached is a fixed version. When I commit, I will of course also add some notes in LaTeXConfig.lyx. OK to proceed? regards Uwe Index

Re: [patch] support for math formal script - fixes #2340

2010-07-17 Thread Uwe Stöhr
>> thats probably the ttf you want right? ;) trying fontforge now... > committed Man thanks! I committed the patch and LyX displays the \mathscr characters in the desired font you created. > isn't icon for toolbar missing? Where should I add one? Currently we don't have icons for math font st

Re: use_makebox problems - lyx2lyx

2010-07-17 Thread Uwe Stöhr
> open math manual. > on console i see: > Lexer.cpp(937): Missing 'use_makebox'-tag in InsetBoxParams::read. I missed to add a conversion routine that adds use_makebox 0 to every file containing boxes. Attached is a patch that should do this but doesn't. I'm unable to figure out the problem be

Re: [patch] support for math formal script - fixes #2340

2010-07-17 Thread Uwe Stöhr
> aha. so what is the point of having fonts toolbar at all - should we we remove it? I don't understand. The math toolbar has one button to select the font style. Its subtoolbar has no icons. Do I miss something? regards Uwe

changeset/3495 - trunk uncompilable

2010-07-18 Thread Uwe Stöhr
Hello Stephan, your new code does not compile, neither with CMake nor SCons: D:\LyXSVN\lyx-devel\src\frontends\qt4\GuiWorkArea.cpp(824) : error C2666: 'QFlag s::operator &' : 3 overloads have similar conversions with [ Enum=Qt::KeyboardModifier ] d:\qt

Re: use_makebox problems - lyx2lyx

2010-07-18 Thread Uwe Stöhr
Am 17.07.2010 20:09, schrieb Richard Heck: I see the warnings here. But the problem is that you're mixing up the i's and j's. I've fixed it, tested, and committed. Thanks for fixing my mistake, but the problem that thw lyxl2yxl warnings are not output in conversion routines remain. José? r

Re: ANNOUNCE: LyX version 2.0.0 (alpha 5)

2010-07-20 Thread Uwe Stöhr
Am 20.07.2010 23:59, schrieb Pavel Sanda: Binaries should follow soon. Hi Pavel, I put my binary here: https://developer.berlios.de/project/showfiles.php?group_id=5117&release_id=17753 Can you please put it on ftp.lyx.org? thanks and regards Uwe

[patch] support for \baselineskip

2010-07-20 Thread Uwe Stöhr
The attached simple patch adds \baselineskip as length for \vspace. \baselineskip is exactly the distance between two baselines of consecutive text lines. If the line spacing is default, \bigskip is equal to \baselineskip. If not one needs \baselineskip as length to get the space between lines.

Re: LaTeX Error: Too deeply nested.

2010-07-22 Thread Uwe Stöhr
> I am writing a document with a number of people with varying level of > LyX and LaTeX skills. The biggest issue is that some co-authors are > breaking the document by nesting itemize or enumerate environments > too deep. This is a known LaTeX limitation. LyX is not yet able to prevent such case

Re: [patch] support for \\baselineskip

2010-07-24 Thread Uwe Stöhr
> IMHO \baselineskip is a very useful unit, I use it frequently. However, I > think we should put baselineskip rather to the unit combo and make it > accessible via "custom" vspace. Often, one needs a value such as > \vspace{3\baselineskip} or even \vspace{0.5\baselineskip}. Good idea. Attached i

Re: [patch] support for \\baselineskip

2010-07-24 Thread Uwe Stöhr
Am 25.07.2010 05:57, schrieb Uwe Stöhr: In my patch I failed to look in Length.cpp what is the current fontsize. Calling bv.buffer().params().fontsize doesn't work. Can you please help me here? All other things work as they should. There was also a bug in the lyx2lyx routine. Better

Re: [patch] support for \\baselineskip

2010-07-25 Thread Uwe Stöhr
Am 25.07.2010 16:17, schrieb Jürgen Spitzmüller: In my patch I failed to look in Length.cpp what is the current fontsize. Calling bv.buffer().params().fontsize doesn't work. Can you please help me here? All other things work as they should. No idea either. Too bad. I only want to have a look

Re: [patch] support for \\\\baselineskip

2010-07-25 Thread Uwe Stöhr
>> Its in ofer 90% the exact value in pt. So my reversion keeps the size the >> users wanted. > > I don't understand. How can you find out the exact value of \baselineskip if > the font size and linespread are defined in a class file? This is not > possible. That's why I wrote in 90%. Usually you

Re: [patch] support for \\\\baselineskip

2010-07-25 Thread Uwe Stöhr
Am 26.07.2010 00:32, schrieb Richard Heck: That's why I wrote in 90%. Usually you have single line space and nearly all document classes use 1.2 for the baselineskip then. I thought the worry was that there is no way to determine the fontsize. If it's default, which it is in most cases by fa

Re: [patch] support for \\\\baselineskip

2010-07-26 Thread Uwe Stöhr
Am 26.07.2010 08:02, schrieb Jürgen Spitzmüller: But all insets have different syntax. That would mean that I have to write a detection routine foe every inst. E.g. when I find baselineskip in a box I need to revert the whole box as TeX-code. This is a horror. I think this can be done. We hav

Re: [patch] support for \\\\baselineskip

2010-07-26 Thread Uwe Stöhr
Am 26.07.2010 14:45, schrieb Richard Heck: The class the defines the possible font sizes. You specify the font size in the document settings. But one option is "default", i.e., not to specify it. How do you know what that means? Default is in almost all classes, except of the presentation

changeset/35060 - color regressions

2010-08-06 Thread Uwe Stöhr
Hi JMarc, your recent color resetting commit doesn't work on Windows. It looks horrible, see the attached screenshot. I see that you changed the RGB values of your standard colors. E.g. our default background color is 250,240,230 (r,g,b) and you changed it to 236,233,216. Why that? The new co

Re: Fwd: Command + S + D = crash

2010-08-06 Thread Uwe Stöhr
> I've been crashing Lyx 1.6.5 by accidentally pressing Command + S + D > instead of just Command + S to save... > This highlights the "View" menu then hangs until I need to force quit. Command + S + D creates a DVI preview of your file. This might take some time because if you have many images

Re: changeset/35060 - color regressions

2010-08-07 Thread Uwe Stöhr
Am 07.08.2010 11:22, schrieb Jean-Marc Lasgouttes: Le 7 août 10 à 04:52, Uwe Stöhr a écrit : your recent color resetting commit doesn't work on Windows. It looks horrible, see the attached screenshot. I misread the documentation. Is it better now? Of course not, because you rese

Re: changeset/35060 - color regressions

2010-08-07 Thread Uwe Stöhr
Am 07.08.2010 18:16, schrieb Jean-Marc Lasgouttes: I do that because it is an idea that has been in the air for some time. It is actually a bit tasteless for an application to have an color theme different from everyone else. Do you tolerate that firefox or openoffice have white text backgroun

Re: changeset/35060 - color regressions

2010-08-09 Thread Uwe Stöhr
> If you try to google for this problem, you will also find people who > explain that using a dark background is a better solution (not that I > agree with that, sincerely I do not know). A nice property of my > patch is that, if you select such an inverted theme in gnome, LyX > will inherit it

Re: changeset/35060 - color regressions

2010-08-09 Thread Uwe Stöhr
While we are at the color stuff, there is a general issue we should try to solve to support per-document color settings: http://www.lyx.org/trac/ticket/6626 regards Uwe

Re: changeset/35060 - color regressions

2010-08-10 Thread Uwe Stöhr
>> I don't agree that every program should inherit the system-wide colors. Every program has its own >> purpose and thus needs different ergonomics settings. > > I agree that some programs require that, but the point where we disagree is that LyX is so > `special'. I don't see that LyX is so sp

Re: changeset/35060 - color regressions

2010-08-12 Thread Uwe Stöhr
>> I don't see that LyX is so special. It uses its own colors like nearly >> every program I have installed on my Windows. > > You mean word, openoffice, firefox, chrome, outlook, photoshop? Browsers are not for looking at text for hours. Photoshop has a dark gray background. That Word and OpenO

Re: changeset/35060 - color regressions

2010-08-12 Thread Uwe Stöhr
>> Photoshop has a dark gray background. > > Dark gray? Attached is a screenshot. >> Btw. all those programs use their own default font and not the system >> default (which is here Arial). > > Arial is system default for the dialogs. Are you saying that these > programs use other fonts than the

Re: [patch] support for \\\\baselineskip

2010-08-12 Thread Uwe Stöhr
Am 26.07.2010 15:06, schrieb Jürgen Spitzmüller: I cannot agree to this. LyX is not there to tell the user what to use. We should provide what LaTeX provides. We therefore already provide vertical lengths for horizontal features. There is no reason why we should not do the same for baselineskip

Re: [patch] support for \\\\baselineskip

2010-08-12 Thread Uwe Stöhr
Am 26.07.2010 15:12, schrieb Jürgen Spitzmüller: Default is in almost all classes, except of the presentation classes, "10". Well, at least for the KOMA classes, it is "11". I'm sure there are many more variations if you go through the hundreds of classes available at CTAN. Thanks for the hi

Re: Fwd: [Customization] Suggestions about v. 2.0.0

2010-08-19 Thread Uwe Stöhr
>> have you seen this post from Ignacio?: > > was this processed in the end? Not yet. Richard will you have time for this or should Pavel or I take over? regards Uwe

Re: r35122 - lyx-devel/trunk/lib

2010-08-19 Thread Uwe Stöhr
> maybe i'm missing something, but why dont we use our own html export? The user can choose what method he want to use the generate HTML. My patch is only an add-on to what we already have when the user don't use LyX's internal HTML conversion. regards Uwe

Re: changeset/35060 - color regressions

2010-08-19 Thread Uwe Stöhr
> as an example Uwe wants to kill graphics background color because he > has no idea what it does, which is just irresponsible. in such case > you need to associate it with one fixed color, so all my png images > with alpha channel are going to have fixed background. if it merges > with the foregr

[patch] for branch - fix #6872

2010-08-29 Thread Uwe Stöhr
Jürgen, OK to go in? regards Uwe Index: lib/symbols === --- lib/symbols (revision 35227) +++ lib/symbols (working copy) @@ -7,7 +7,7 @@ bar decoration none breve decoration none check d

Re: [patch] for branch - fix #6872

2010-08-29 Thread Uwe Stöhr
Am 30.08.2010 01:06, schrieb Uwe Stöhr: OK to go in? This patch doesn't work because there is a bug in InsetMathDecoration. Moreover we don#t ship a toolbar icon for \dddot although we support this command since a long time. The attached patch fully fixes http://www.lyx.org/trac/t

what does the local layout in the document settings do?

2010-08-29 Thread Uwe Stöhr
What exactly does the local layout feature in the document settings? I tried to use it but don't understand how it works. Here are my annotations and bug reports: - The user has to read the documentation to understand what this feature might be for -> having a context help (like for listings)

[patch] backport support for \ddddot to branch

2010-08-29 Thread Uwe Stöhr
The attached patch backports the support for the math command \ot. (Requires the patch for #6872 that I just sent.) OK? regards Uwe Index: development/scons/scons_manifest.py === --- development/scons/scons_manifest.py (revisio

[patch] support or the mathdots package - fix for #5373

2010-08-29 Thread Uwe Stöhr
From time to time users request to support the mathdots package (e.g. #5373). We already support this package internally by providing visual support for its commands (\adots and \iddots). The remaining problem is that we cannot simply load the mathdots package when the user uses e.g. \adots in h

Re: what does the local layout in the document settings do?

2010-08-29 Thread Uwe Stöhr
Am 30.08.2010 03:48, schrieb Richard Heck: - The user has to read the documentation to understand what this feature might be for -> having a context help (like for listings) would improve the situation a lot If you have suggestions about how to do this, I'd love to hear them. But reading our

LyX 2.0 compilation errors using CMAKE

2010-08-30 Thread Uwe Stöhr
I am not able to compile LyX 2.0 using CMAKE. I get these errors: 2>..\..\..\src\support\environment.cpp(65) : error C2039: 'setenv' : is not a member of '`global namespace'' 2>..\..\..\src\support\environment.cpp(65) : error C3861: 'setenv': identifier not found 10>..\..\src\LyX.cpp(288) : e

Re: LyX 2.0 compilation errors using CMAKE

2010-08-30 Thread Uwe Stöhr
Am 31.08.2010 03:04, schrieb Uwe Stöhr: I am not able to compile LyX 2.0 using CMAKE. I get these errors: I forgot to say that I'm using - Microsoft Visual C++ 2008 Express Edition with SP1 - Qt 4.6.3 - Windows XP 64bit (a.k.a. Windows 2003 Server) - CMake 2.8.2 and build with this batch

Re: [patch] support or the mathdots package - fix for #5373

2010-08-30 Thread Uwe Stöhr
> there must be simple string there. i guess you use too new designer? Thanks for the hint. I'm using designer from Qt 4.6.3 and this version uses by default rich text when editing the tooltip. One has to edit the tooltip directly in the "result" window to get plain text. regards Uwe

Re: LyX 2.0 compilation errors using CMAKE

2010-08-31 Thread Uwe Stöhr
Am 31.08.2010 08:02, schrieb Stephan Witt: I guess it's my change r35193. Please try attached patch. This fixes the setenv compilation errors -> I committed it. However, this compilation error remains: 10>..\..\src\LyX.cpp(288) : error C4101: 'message' : unreferenced local variable The att

Re: LyX 2.0 compilation errors using CMAKE

2010-09-01 Thread Uwe Stöhr
> using msvc this warning as handled as error. > but it's fixed now. Many thanks! regards Uwe

Re: changeset/35060 - color regressions

2010-09-03 Thread Uwe Stöhr
> philosophically, this looks good. is the default white background > necessary consequence (i think this was the main point raised, not > the machinery behind)? Yes, my main objection was against white as default background color. regards Uwe

[patch] support for customizable horizontal lines

2010-09-04 Thread Uwe Stöhr
The attached patch adds support for horizontal lines via the LaTeX command \rule. It furthermore provides: - remove the \lyxline command because this line had a fixed width and height and it was surrounded by a paragraph. Now the user can customize the height, width and decide if it should go i

Re: [patch] support for customizable horizontal lines

2010-09-05 Thread Uwe Stöhr
>> current_ls_ = line_solid; >> - current_lw_ = line_thin; >> + current_lw_ = 0.5; > > on many places you use int lw, while trying to store float... Thanks. I fixed this now and committed the painter stuff. >> void InsetLine::validate(LaTeXFeatures & features) const >> { >> -

Re: [patch] support for customizable horizontal lines

2010-09-05 Thread Uwe Stöhr
Am 05.09.2010 09:05, schrieb Abdelrazak Younes: Could you please try to use InsetParamsWidget for new dialogs instead of GuiDialog? Each time I migrate a dialog, some others are popping up... InsetParamsWidget is easier to use and will results in much less lines of code. Look at GuiHSpace or G

Re: r35283 - in lyx-devel/trunk/src/frontends: . qt4

2010-09-05 Thread Uwe Stöhr
Am 05.09.2010 17:03, schrieb Vincent van Ravesteijn: Isn't it better to make a function GuiPainter::thinline or so, instead of everywhere specifying the 0.5 ? Currently there are only 3 places in the code (all in rowpainter.cpp) where the former Painter::line_thin was used. Therefore I did n

Re: r35283 - in lyx-devel/trunk/src/frontends: . qt4

2010-09-05 Thread Uwe Stöhr
Am 05.09.2010 18:51, schrieb Stephan Witt: I think Vincent is right here, it isn't a good idea to place 0.5 here and there. Convinced. However, I don't know how to implement this: I added this to the public section of Painter.h: float const thinline = 0.5; and used thinline instead of 0.5 in

Re: r35283 - in lyx-devel/trunk/src/frontends: . qt4

2010-09-05 Thread Uwe Stöhr
This doesn't work. I still get: Painter::thin_line' : only static const integral data members can be initialized within a class Using in Painter.h static const float thin_line; and set its value in GuiPainter.cpp to 0.5 works, but I get a lot of compiler errors like InsetVSpace.obj : error L

Re: patches for branch

2010-09-05 Thread Uwe Stöhr
Am 06.09.2010 01:33, schrieb Uwe Stöhr: can these commits also go to branch?: http://www.lyx.org/trac/changeset/35286 My mistake - this cannot be backported because in LyX 1.6.x we use a LyXRC color value for lyxlines. regards Uwe

Re: [patch] support for customizable horizontal lines

2010-09-05 Thread Uwe Stöhr
Attached is a revised patch where everything should be in shape (including lyx2lyx). There now only one remaining problem: In InsetLine::metrics I can successfully calculate the width in pixels but I need to have this information in InsetLine::draw. My attempt there with int const w =

Re: [patch] support for customizable horizontal lines

2010-09-05 Thread Uwe Stöhr
Am 06.09.2010 05:09, schrieb Uwe Stöhr: Attached is a revised patch That patch was corrupted, attached is a working one. regards Uwe Index: development/FORMAT === --- development/FORMAT (revision 35287) +++ development/FORMAT

Re: [patch] support for customizable horizontal lines

2010-09-06 Thread Uwe Stöhr
Am 06.09.2010 10:48, schrieb Jean-Marc LASGOUTTES: Can't you just use the Dimension object to infer the width of the line? All the computations have been made already. This only works for the width via dim.wid, but I also need to know the offset and the height inPxiels in InsetLine::draw. r

Re: [patch] support for customizable horizontal lines

2010-09-06 Thread Uwe Stöhr
Am 06.09.2010 15:14, schrieb Jean-Marc LASGOUTTES: Can't you just use the Dimension object to infer the width of the line? All the computations have been made already. This only works for the width via dim.wid, but I also need to know the offset and the height inPxiels in InsetLine::draw. Bu

Re: [patch] support for customizable horizontal lines

2010-09-06 Thread Uwe Stöhr
Am 06.09.2010 17:14, schrieb Jean-Marc LASGOUTTES: I do need it because my patch currently only works for real units. Length::inPixels calculates the length for non-real units via the textwidth. offset and height can have all kind of units, e.g. a height of 1\textheight is sensible and inPixels

Re: [patch] support for customizable horizontal lines

2010-09-06 Thread Uwe Stöhr
Am 06.09.2010 08:22, schrieb Abdelrazak Younes: I started the dialog from GuiHspace but the result was much more code than that I have now. This is really weird... if you still have it could you post the patch? I don't have this anymore. My main problem with using InsetLineParams (new param

Re: r35295 - lyx-devel/trunk/src/frontends/qt4

2010-09-06 Thread Uwe Stöhr
> This is a (small) hack, but it should solve the biggest issue with system > colors, while still honoring non-trivial system-provided backgrounds. > > Pavel, Uwe, is that OK with you? Yes and it works fine for me here on Windows. regards Uwe

Re: r35283 - in lyx-devel/trunk/src/frontends: . qt4

2010-09-06 Thread Uwe Stöhr
> why in cpp and not in header? Because the compiler doesn't accept this. > the following patch doesn't link for you? > > - line_style = line_solid, float line_width = 0.5) = 0; > + line_style = line_solid, float line_width = thin_line) = 0; > > bool drawing_e

Re: r35283 - in lyx-devel/trunk/src/frontends: . qt4

2010-09-07 Thread Uwe Stöhr
Am 07.09.2010 07:16, schrieb Peter Kümmel: Fixed it: you must instantiate static members in the cpp file. Thanks! regards Uwe

Re: r35301 - in lyx-devel/branches/BRANCH_1_6_X: . development/Win32/packaging/AltInstaller development/scons lib lib/layouts lib/templates

2010-09-07 Thread Uwe Stöhr
>> +Style "Glossary term" >> + CopyStyle Subsection* >> + CategoryBackMatter >> + LatexName paragraph >> +End > > Uwe, what's this? This is no specific command provided by agutex. > Is there a special reason why you added this? I added

Re: use_makebox problems - lyx2lyx

2010-09-07 Thread Uwe Stöhr
>> Thanks for fixing my mistake, but the problem that thw lyxl2yx >> warnings are not output in conversion routines remain. José? > > do you still have this problem? Yes, warnings in convert routines are not output to the LyX console window. For reversion routines this works. regards Uwe

changeset 35316 was:Re: Missing include, trunk

2010-09-07 Thread Uwe Stöhr
> No, I had to include cmath _and_ cast some values in this statement. > > dim.wid = max(minw, (int) abs((double) w)); Abdel fixed this in r35316 as > - dim.wid = max(minw, abs(w)); > + dim.wid = max(minw, max(w, -w)); So far so good, but we have exactly the same code in line 233 of Ins

Re: [patch] support for customizable horizontal lines

2010-09-07 Thread Uwe Stöhr
Am 07.09.2010 16:14, schrieb Abdelrazak Younes: On 09/07/2010 03:03 AM, Uwe Stöhr wrote: I understand. For now I nevertheless have put it in as InsetCommand because I'm technically too limites to get it working with short code as InsetParamsWidget. Feel free to transform

the LyX Wiki is heavily spammed - Christian?

2010-09-07 Thread Uwe Stöhr
I have seen by chance that our Wiki has been spammed heavily the last days. (I therefore protected now the pages http://wiki.lyx.org/LyX/NewInLyX16 and http://wiki.lyx.org/LyX/NewInLyX20 .) The problem is that the lyx-docs mailing list no longer gets an email when a Wiki page has been changed.

<    1   2   3   4   5   6   7   8   9   10   >