input of cjk characters crashes lyx.exe
Hello, The current window version(07-01-15) of lyx1.5svn crashes when I try to input Korean characters, with the following error messages, "Assertion triggered in unsigned int __thiscall lyx::QLyXKeySym::getUCSEncoded const by failing check "text_.size()==1" in file C:\lyx-devel\src\frontends\qt4\QLyXKeySym.C:209" Can anybody help? Regards, --cghan
Re: Input of CJK characters is O.K. but view fails
Hello Jean-Marc, Sorry for my late reply. - Original Message - >> From: Jean-Marc Lasgouttes <[EMAIL PROTECTED]> >> To: 한창길 <[EMAIL PROTECTED]> >> Cc: lyx-devel@lists.lyx.org >> Date: 2006-12-29 21:13:56 >> Subject: Re: Input of CJK characters is O.K. but view fails >> Hello cghan, >> >> Did you make some progress about LyX 1.5 and cjk? Yes, I have a success, but with the addition of the (tex-)encoding, "utf8x" instead of "utf8". The reason is that our local character macro style files use "utf8x" as the inputencoding def file. So I had to add one line in "lib/encodings" as "Encoding utf8x utf8x UTF-8 End" This enables me to set " Document -> Settings -> Language -> Encoding -> utf8x" for korean character viewing. --cghan
Re: Bugzilla broken
>> I get some error message (security warning) when adding a new bug to >> our bugzilla system. Something is wrong with bugzilla's post-bug >> script. >> >> Have you changed the perl/python/whatever settings or made an update >> to them? Please have a look. > I have not changed a thing. > I'll try to have a look. I only have problems whe somebody is added to CC when reporting the bug. To reproduce: Create a new bug report and before committing it add somebody to the CC-filed of the bug report form. Lars, if you have a look at bugzilla, could you perhaps update it to an newer version? This would not inly fix the usual potential security problems but also the very annoying attachment problem decribed in bug 2260 http://bugzilla.lyx.org/show_bug.cgi?id=2260 and furthermore also bug 2216 http://bugzilla.lyx.org/show_bug.cgi?id=2216 I think. regards Uwe
Re: [part 1] again about LyX's default settings
Uwe Stöhr schrieb: >> Btw. do we have other positions for the toolbars than "top" and "bottom"; >> I mean something like "left" and "right"? > > yes. "left" and "right" should just work. But they don't, I get an error message in the console that left or right is unknown. I deleted my existing session file and now it works. >> OK, can the attached patch go in? > > IMO yes. It's in now. OK, but due to this problem: > (I noticed that the patch does only work when I change the toolbar name from "view" to something > different, why?) I have to change the name of the toolbar from "view" to "preview" or something similar. Perhaps this was a problem too of my old session file. But anyway its name is now "view/update" regards uwe
Re: [PATCH] Fix bug 3114 reated to windows path.
Andre Poenitz <[EMAIL PROTECTED]> writes: | On Thu, Jan 18, 2007 at 06:11:37PM +0100, Lars Gullik Bjønnes wrote: | > Abdelrazak Younes <[EMAIL PROTECTED]> writes: | > | > | | > | So I suggest that we do the extra step and finish the Filename class | > | instead of moving little by little everytime a bug is discovered. | > | > I suggest using boost::fs as the underlying mech. for filesystem work. | | Are there any specific reasons to prefer boost::fs over QFile? | | I know I had troubles with boost::fs two years or so ago and QFile just | worked for *nix and Win* out of the box. Only that we go further into the Qt pit. Also QFile will never get standarized, boost::fs might be. -- Lgb
Re: Mac problems resolved?
On Jan 20, 2007, at 9:36 AM, Michael Gerz wrote: Bennett, Status.15x is full of Mac/performance-specific problems. Could you please tell me, whether some of them have been resolved in the mean- time? Thanks, Michael I'm working on it. The trouble is that although things seem to work well on Intel Macs, I don't know whether it also works well on PowerPC Macs. I also need to make sure I know how to compile LyX-1.5 on PPC Mac, which doesn't work with gcc-4.0 (which is the latest version that Apple provides). I'm currently compiling gcc-4.1 to see if it works, but with a slow dial-up line and a slow processor, it's taking forever. If things go well, I should know tomorrow. Bennett
Re: What is needed to develop LyX 1.5 on Windows machine?
Andre Poenitz wrote:
> On Sat, Jan 20, 2007 at 12:25:36PM +1800, Bo Peng wrote:
>>> i tried the cmake thing, but an attempt to build lyx from the created
>>> lyx-qt4.sln with msvc produced
>>> the following error:
>> version.C needs to be generated from version.C.in and MSVS Gui does
>> not know this. I guess you need to first build lyx from command line
>> the first time to obtain this file, and then fire up msvs.
>>
>> Peter, am I right?
version.C and package.C are created by the cmake script with the same
process when the project files are generated. The command therefore is
configure_file:
configure_file(${TOP_SRC_DIR}/src/version.C.in
${CMAKE_CURRENT_BINARY_DIR}/version.C)
>
> I think the .vcproj generator should insert proper custom build steps.
After a new checkout Bernhard has no problems any more, so I assume
it was due to a version.C file in the source tree.
Peter
>
> Andre'
>
Re: [Cvslog] r16780 - /lyx-devel/trunk/src/output_plaintext.C
> The implications of this fix are marginal. I don't see any
> difference in a typical document.
Maybe not. But the translation changes you've made are absolutely
wrong.
> - docstring const abst = _("Abstract: ");
> + docstring const abst = _("Abstract") + from_ascii(": ");
Not all languages will use ':' in the same way as the English and in
RtL languages the thing won't go to the right of the word either...
Angus
[EMAIL PROTECTED] schrieb:
> Author: schmitt
> Date: Sat Jan 20 17:14:39 2007
> New Revision: 16780
>
> URL: http://www.lyx.org/trac/changeset/16780
> Log:
> * src/output_plaintext.C: save two *.po entries;
> output label+space only if label is not empty
>
> Modified:
> lyx-devel/trunk/src/output_plaintext.C
>
> Modified: lyx-devel/trunk/src/output_plaintext.C
> URL:
http://www.lyx.org/trac/file/lyx-devel/trunk/src/output_plaintext.C?rev=16780
>
==
> --- lyx-devel/trunk/src/output_plaintext.C (original)
> +++ lyx-devel/trunk/src/output_plaintext.C Sat Jan 20 17:14:39 2007
> @@ -152,7 +152,7 @@
> os << _("Abstract") << "\n\n";
> currlinelen = 0;
> } else {
> - docstring const abst = _("Abstract: ");
> + docstring const abst = _("Abstract") + from_ascii(": ");
> os << abst;
> currlinelen += abst.length();
> }
> @@ -164,7 +164,7 @@
> os << _("References") << "\n\n";
> currlinelen = 0;
> } else {
> - docstring const refs = _("References: ");
> + docstring const refs = _("References") +
> from_ascii(": ");
> os << refs;
> currlinelen += refs.length();
> }
> @@ -174,14 +174,16 @@
Re: [PATCH] Branches and ToC bug
Great, thanks! - Martin On Fri, 19 Jan 2007, Jean-Marc Lasgouttes wrote: "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: Jean-Marc> OK, the trivial version is what I propose for 1.4.x: Jean-Marc> besides implementing InsetBranch::textString, it fixes an Jean-Marc> output order bug in writePlaintextParagraph. Jean-Marc> The 1.5 version is more complicated because I took the Jean-Marc> liberty to cleanup Paragraph::asString (remove two useless Jean-Marc> versions) and to simplify the InsetBase::textString method. I applied both. JMarc
Re: About bug 3118: editing first row of long math insets is impossible
On Fri, Jan 19, 2007 at 12:18:35PM +0100, Abdelrazak Younes wrote: > Georg Baum wrote: > >Abdelrazak Younes wrote: > > > >>Indeed but first we have to make sure that the CoordCache is properly > >>filled in for all insets. We can do that recursively as is done in the > >>rowpainter. One have to extract the part that calls setPosCache() and > >>transfer that in BufferView::updateMetris(). > > > >setPoscache is called in draw() for each inset. Do I understand you right > >the now the coord cache needs to be filled when the metrics are calculated? > > Yes. > > >If that is the case we should simply transfer this call to the metrics() > >method of each inset > > That's what I said yes. How come the metrics() phase knows about positions? Andre'
Re: What is needed to develop LyX 1.5 on Windows machine?
On Sat, Jan 20, 2007 at 12:25:36PM +1800, Bo Peng wrote: > >i tried the cmake thing, but an attempt to build lyx from the created > >lyx-qt4.sln with msvc produced > >the following error: > > version.C needs to be generated from version.C.in and MSVS Gui does > not know this. I guess you need to first build lyx from command line > the first time to obtain this file, and then fire up msvs. > > Peter, am I right? I think the .vcproj generator should insert proper custom build steps. Andre'
Re: [PATCH] Fix bug 3114 reated to windows path.
On Thu, Jan 18, 2007 at 06:11:37PM +0100, Lars Gullik Bjønnes wrote: > Abdelrazak Younes <[EMAIL PROTECTED]> writes: > > | > | So I suggest that we do the extra step and finish the Filename class > | instead of moving little by little everytime a bug is discovered. > > I suggest using boost::fs as the underlying mech. for filesystem work. Are there any specific reasons to prefer boost::fs over QFile? I know I had troubles with boost::fs two years or so ago and QFile just worked for *nix and Win* out of the box. Andre'
Re: Cannot compile. Latest in trunk
On Fri, Jan 19, 2007 at 07:31:45PM +0100, Andre' Poenitz wrote: > string a(); > > is a declaration of a function called 'a' taking no argument and > returning a string. Hmpf... and everyone knew already. I was pretty sure I was up-to-date when writng this mail. Andre'
Re: About bug 3118: editing first row of long math insets is impossible
On Fri, Jan 19, 2007 at 11:39:40AM +0100, Georg Baum wrote: > If we make sure that the coord cache is always > set in the metrics method as Abdel suggests, There must be a misunderstanding somewhere. The metrics phase only determines _sizes_. The coord cache records _positions_. Andre'
Re: [Cvslog] r16785 - /lyx-devel/trunk/src/paragraph_pimpl.C
Sure? Looks like 4.
Michael
[EMAIL PROTECTED] schrieb:
Author: baum
Date: Sat Jan 20 18:21:52 2007
New Revision: 16785
URL: http://www.lyx.org/trac/changeset/16785
Log:
count correctly
Modified:
lyx-devel/trunk/src/paragraph_pimpl.C
Modified: lyx-devel/trunk/src/paragraph_pimpl.C
URL:
http://www.lyx.org/trac/file/lyx-devel/trunk/src/paragraph_pimpl.C?rev=16785
==
--- lyx-devel/trunk/src/paragraph_pimpl.C (original)
+++ lyx-devel/trunk/src/paragraph_pimpl.C Sat Jan 20 18:21:52 2007
@@ -607,12 +607,13 @@
&& i <= size() - 2
&& getChar(i + 1) == c) {
//os << "\\textcompwordmark{}";
+ //column += 19;
// Jean-Marc, have a look at
// this. I think this works
// equally well:
os << "\\,{}";
// Lgb
- column += 19;
+ column += 3;
}
break;
}
___
Cvslog mailing list
[EMAIL PROTECTED]
http://www.lyx.org/mailman/listinfo/cvslog
Re: Problem stripLeadingSpaces()
Abdelrazak Younes schrieb: Michael Gerz wrote: Abdelrazak Younes schrieb: Michael Gerz wrote: Abdelrazak Younes schrieb: I don't understand, why the space in the first line should be deleted? means a space that was marked as deleted. Use the attached lyx file. Press return after "hello". The leading spaces are marked as deleted but the screen is not updated. Well, I still don't understand because the screen seems fine here, see attached. No, the screen is not fine: the second space should be marked as deleted! Why is that? Before I hit "Enter", the second space was not deleted; was should it be deleted after? The semantics of stripLeadingSpaces() is, well, to strip _all_ leading spaces. Since the second space is a leading space, too, it is marked as deleted in CT mode. stripLeadingSpaces() works as intended but the screen is not updated afterwards. Right now, stripLeadingSpaces() returns the number of _physically_ deleted spaces. I can change this to return the number of physically and logically characters. This may help but may also prevent some optimizations in DEPM. I also don't understand why we return false at the end of deleteEmptyParMech() even if stripLeadingSpaces returns !0. Ah, and we should clarify/document the meaning of the return value of deleteEmptyParMech... What do you think? I am a bit lost without your assistance... Michael
Re: [Cvslog] r16783 - /lyx-devel/trunk/src/text.C
Next bug fix... this time regarding change tracking.
Michael
[EMAIL PROTECTED] schrieb:
Author: schmitt
Date: Sat Jan 20 17:59:13 2007
New Revision: 16783
URL: http://www.lyx.org/trac/changeset/16783
Log:
* src/text.C: move forward when logically deleting character
(previously broken; the cursor was even moved forward if
the character was physically removed and the next character was
marked as deleted)
Modified:
lyx-devel/trunk/src/text.C
Modified: lyx-devel/trunk/src/text.C
URL: http://www.lyx.org/trac/file/lyx-devel/trunk/src/text.C?rev=16783
==
--- lyx-devel/trunk/src/text.C (original)
+++ lyx-devel/trunk/src/text.C Sat Jan 20 17:59:13 2007
@@ -1042,9 +1042,10 @@
// this is the code for a normal delete, not pasting
// any paragraphs
recordUndo(cur, Undo::DELETE);
- par.eraseChar(cur.pos(), cur.buffer().params().trackChanges);
- if (par.isDeleted(cur.pos()))
+ if(!par.eraseChar(cur.pos(),
cur.buffer().params().trackChanges)) {
+ // the character has been logically deleted only =>
skip it
cur.forwardPosNoDescend();
+ }
needsUpdate = true;
} else {
if (cur.pit() == cur.lastpit())
___
Cvslog mailing list
[EMAIL PROTECTED]
http://www.lyx.org/mailman/listinfo/cvslog
Re: [Cvslog] r16782 - /lyx-devel/trunk/src/output_plaintext.C
Up to now, max line length hasn't really been max line length. This
plain text output code is just scary
Michael
[EMAIL PROTECTED] schrieb:
Author: schmitt
Date: Sat Jan 20 17:38:58 2007
New Revision: 16782
URL: http://www.lyx.org/trac/changeset/16782
Log:
* src/output_plaintext.C: fix line break handling;
don't stop 10 characters before max line length
Modified:
lyx-devel/trunk/src/output_plaintext.C
Modified: lyx-devel/trunk/src/output_plaintext.C
URL:
http://www.lyx.org/trac/file/lyx-devel/trunk/src/output_plaintext.C?rev=16782
==
--- lyx-devel/trunk/src/output_plaintext.C (original)
+++ lyx-devel/trunk/src/output_plaintext.C Sat Jan 20 17:38:58 2007
@@ -215,7 +215,7 @@
case ' ':
if (runparams.linelen > 0 &&
- currlinelen + word.length() > runparams.linelen -
10) {
+ currlinelen + word.length() > runparams.linelen) {
os << '\n';
pair p = addDepth(depth,
ltype_depth);
os << p.second;
@@ -233,16 +233,16 @@
default:
word += c;
- if (runparams.linelen > 0 &&
- currlinelen + word.length() > runparams.linelen)
- {
- os << '\n';
- pair p = addDepth(depth,
ltype_depth);
- os << p.second;
- currlinelen = p.first;
- }
- break;
- }
+ break;
+ }
+ }
+
+ if (runparams.linelen > 0 &&
+ currlinelen + word.length() > runparams.linelen) {
+ os << '\n';
+ pair p = addDepth(depth, ltype_depth);
+ os << p.second;
+ currlinelen = p.first;
}
os << word;
}
___
Cvslog mailing list
[EMAIL PROTECTED]
http://www.lyx.org/mailman/listinfo/cvslog
Re: Bugzilla broken
Michael Gerz <[EMAIL PROTECTED]> writes: | Lars, | | I get some error message (security warning) when adding a new bug to | our bugzilla system. Something is wrong with bugzilla's post-bug | script. | | Have you changed the perl/python/whatever settings or made an update | to them? Please have a look. | | Thanks in advance! I have not changed a thing. I'll try to have a look. -- Lgb
Re: [Cvslog] r16781 - /lyx-devel/trunk/src/output_plaintext.C
Another bug in plain text output. Has anybody ever used this feature?
(This is not the last commit!)
Michael
[EMAIL PROTECTED] schrieb:
Author: schmitt
Date: Sat Jan 20 17:25:52 2007
New Revision: 16781
URL: http://www.lyx.org/trac/changeset/16781
Log:
* src/output_plaintext.C: remove cryptic comment;
do not output deleted characters in plain text output
Modified:
lyx-devel/trunk/src/output_plaintext.C
Modified: lyx-devel/trunk/src/output_plaintext.C
URL:
http://www.lyx.org/trac/file/lyx-devel/trunk/src/output_plaintext.C?rev=16781
==
--- lyx-devel/trunk/src/output_plaintext.C (original)
+++ lyx-devel/trunk/src/output_plaintext.C Sat Jan 20 17:25:52 2007
@@ -189,20 +189,21 @@
currlinelen += p.first;
}
- // this is to change the linebreak to do it by word a bit more
- // intelligent hopefully! (only in the case where we have a
- // max runparams.linelength!) (Jug)
-
docstring word;
for (pos_type i = 0; i < par.size(); ++i) {
+ if (par.isDeleted(i)) // deleted characters don't make much
sense in plain text output
+ continue;
+
char_type c = par.getUChar(buf.params(), i);
switch (c) {
case Paragraph::META_INSET: {
InsetBase const * inset = par.getInset(i);
+
os << word;
currlinelen += word.length();
word.erase();
+
OutputParams rp = runparams;
rp.depth = par.params().depth();
if (inset->plaintext(buf, os, rp)) {
___
Cvslog mailing list
[EMAIL PROTECTED]
http://www.lyx.org/mailman/listinfo/cvslog
Re: [Cvslog] r16780 - /lyx-devel/trunk/src/output_plaintext.C
The implications of this fix are marginal. I don't see any difference in
a typical document.
Michael
[EMAIL PROTECTED] schrieb:
Author: schmitt
Date: Sat Jan 20 17:14:39 2007
New Revision: 16780
URL: http://www.lyx.org/trac/changeset/16780
Log:
* src/output_plaintext.C: save two *.po entries;
output label+space only if label is not empty
Modified:
lyx-devel/trunk/src/output_plaintext.C
Modified: lyx-devel/trunk/src/output_plaintext.C
URL:
http://www.lyx.org/trac/file/lyx-devel/trunk/src/output_plaintext.C?rev=16780
==
--- lyx-devel/trunk/src/output_plaintext.C (original)
+++ lyx-devel/trunk/src/output_plaintext.C Sat Jan 20 17:14:39 2007
@@ -152,7 +152,7 @@
os << _("Abstract") << "\n\n";
currlinelen = 0;
} else {
- docstring const abst = _("Abstract: ");
+ docstring const abst = _("Abstract") + from_ascii(": ");
os << abst;
currlinelen += abst.length();
}
@@ -164,7 +164,7 @@
os << _("References") << "\n\n";
currlinelen = 0;
} else {
- docstring const refs = _("References: ");
+ docstring const refs = _("References") +
from_ascii(": ");
os << refs;
currlinelen += refs.length();
}
@@ -174,14 +174,16 @@
default: {
docstring const label = par.params().labelString();
- os << label << ' ';
- currlinelen += label.length() + 1;
- break;
- }
-
- }
-
- if (!currlinelen) {
+ if (!label.empty()) {
+ os << label << ' ';
+ currlinelen += label.length() + 1;
+ }
+ break;
+ }
+
+ }
+
+ if (currlinelen == 0) {
pair p = addDepth(depth, ltype_depth);
os << p.second;
currlinelen += p.first;
___
Cvslog mailing list
[EMAIL PROTECTED]
http://www.lyx.org/mailman/listinfo/cvslog
Re: [Cvslog] r16779 - /lyx-devel/trunk/src/output_plaintext.C
The plain text bug fixing continues...
Michael
[EMAIL PROTECTED] schrieb:
Author: schmitt
Date: Sat Jan 20 16:35:39 2007
New Revision: 16779
URL: http://www.lyx.org/trac/changeset/16779
Log:
* src/output_plaintext.C: fix line breaks in plain text output;
add a line break at the end of each paragraph; add a second line break
if maximum line length is > 0
Modified:
lyx-devel/trunk/src/output_plaintext.C
Modified: lyx-devel/trunk/src/output_plaintext.C
URL:
http://www.lyx.org/trac/file/lyx-devel/trunk/src/output_plaintext.C?rev=16779
==
--- lyx-devel/trunk/src/output_plaintext.C (original)
+++ lyx-devel/trunk/src/output_plaintext.C Sat Jan 20 16:35:39 2007
@@ -59,8 +59,10 @@
ParagraphList::const_iterator it = beg;
for (; it != end; ++it) {
writePlaintextParagraph(buf, *it, os, runparams, ref_printed);
- }
- os << "\n";
+ os << "\n";
+ if (runparams.linelen > 0)
+ os << "\n";
+ }
}
@@ -130,9 +132,6 @@
// runparams.linelen == 0 is special and means we don't have paragraph
breaks
string::size_type currlinelen = 0;
-
- if (runparams.linelen > 0)
- os << "\n\n";
os << docstring(depth * 2, ' ');
currlinelen += depth * 2;
Re: [Cvslog] r16778 - /lyx-devel/trunk/src/paragraph_pimpl.C
[EMAIL PROTECTED] schrieb: Author: schmitt Date: Sat Jan 20 16:07:20 2007 New Revision: 16778 URL: http://www.lyx.org/trac/changeset/16778 Log: * src/paragraph_pimpl.C: check for linelen == 0 in LaTeX output; otherwise, every word in printed on a separate line Modified: lyx-devel/trunk/src/paragraph_pimpl.C Modified: lyx-devel/trunk/src/paragraph_pimpl.C URL: http://www.lyx.org/trac/file/lyx-devel/trunk/src/paragraph_pimpl.C?rev=16778 == --- lyx-devel/trunk/src/paragraph_pimpl.C (original) +++ lyx-devel/trunk/src/paragraph_pimpl.C Sat Jan 20 16:07:20 2007 @@ -390,7 +390,8 @@ if (style.pass_thru) return; - if (column > lyxrc.plaintext_linelen + if (lyxrc.plaintext_linelen > 0 + && column > lyxrc.plaintext_linelen && i && getChar(i - 1) != ' ' && (i < size() - 1) If the line length is set to zero, the complete paragraph is printed in a single line. Michael
Mac problems resolved?
Bennett, Status.15x is full of Mac/performance-specific problems. Could you please tell me, whether some of them have been resolved in the mean-time? Thanks, Michael
Re: About bug 3118: editing first row of long math insets is impossible
Abdelrazak Younes wrote: > Georg Baum wrote: > > I am not going to rip the draw machinery apart right now, because I don't > > know enough about it and I also think that now is not the right moment to > > do so. > > Well, your patch is much riskier believe me. I don't think so: I added the ClearCoordCache flag in _all_ places where any update flag apart from None was set. Then I added the calls in InsetMathNest that disable this flag, and I changed the update logic to only clear the coord cache if the flag is set. That means that apart from the lfuns in InsetMathNest the behaviour is identical with and without the patch. > Please wait as this seems clearly a wrong solution to me. I'll try to > finish the patch, and I don't think it will be big either. Since you know this area much better than me I am not going to push my solution in, especially since your solution works at least as well :-) I came to my solution because even with my limited knowledge I could be sure that it will not break anything. > > case LFUN_CHAR_FORWARD: > > - // FIXME: we have to enable full redraw here because of the > > - // visual box corners that define the inset. If we know for > > - // sure that we stay within the same cell we can optimize for > > - // that using: > > - //cur.updateFlags(Update::FitCursor); > > Hum, even if you commit your patch the FIXME above is still true. Almost. I added a comment that describes the situation better IMO ;-) Georg
Re: Omega
Gudjon I. Gudjonsson wrote: > Hi >I have just updated to the latest svn on my Debian computer and the >Greek > letter Omega is not visible but it prints perfectly in postscript. The > other Greek letters seem to be visible. This is a known problem, see Status.15x. Georg
Re: Cannot compile 1.5.x_svn
This appears to be the result of some qt4 not being installed, but configure does not complain. Hi, John. This is indeed your problem. This is also our problem. Configure should stop without qt4. Bo
Re: What is needed to develop LyX 1.5 on Windows machine?
Bernhard Roider wrote:
> Hello,
>>
>> Does this file resides in the source tree (trunk/src/version.C)?
>> Then delete it and call cmake again ('cmake .' in the build
>> folder is enough). There must only be a version.C in your build
>> folder.
>>
>> Peter
>>
>
> after fetching the fresh source from trunk it now works here also. the
> only remaining problem is that no "resources" directory is created
> (found?) and so lyx bails out at package.C line 575. I copied the .dll
> files that lyx needs to the directory build\bin\debug and started lyx
> from there (default if starting the debugger from within msvc).
>
> Bernhard
>
Good to hear. When you create the new environment variable
LYX_DIR_15x=YOUR_PATH_TO_TRUNK\trunk\lib
then you don't need to copy anything.
--
Peter Kümmel
Bugzilla broken
Lars, I get some error message (security warning) when adding a new bug to our bugzilla system. Something is wrong with bugzilla's post-bug script. Have you changed the perl/python/whatever settings or made an update to them? Please have a look. Thanks in advance! Michael
Re: What is needed to develop LyX 1.5 on Windows machine?
Hello,
Does this file resides in the source tree (trunk/src/version.C)?
Then delete it and call cmake again ('cmake .' in the build
folder is enough). There must only be a version.C in your build
folder.
Peter
after fetching the fresh source from trunk it now works here also. the only remaining problem is
that no "resources" directory is created (found?) and so lyx bails out at package.C line 575. I
copied the .dll files that lyx needs to the directory build\bin\debug and started lyx from there
(default if starting the debugger from within msvc).
Bernhard
Re: another attempt to install 1.50-svn-3.04
>> This one is weird, False is a keyword of python... > > But only after python 2.2.3, right? > > Which version of python are you (Philip) using? He's using python 2.1 that was the problem. regards Uwe
Re: Drawing woes
Abdelrazak Younes wrote: > Please try again. Fixed in r16775. Thanks. Jürgen
Re: Drawing woes
Jürgen Spitzmüller wrote: This is what I get when opening a new buffer. Typing solves it. Please try again. Abdel.
Re: Tabs + TOC Dialog
Angus Leeming wrote:
> Peter Kümmel wrote:
>> Peter Kümmel wrote:
>>
>>
>>> Does any expert have an idea?
>>
>>
>> "The Usual Suspects" ;)
>>
>> (sorry for the breaking-the-rules smiley)
>>
>> Peter
>>
>
> See frontends/Dialogs.C:
>
> void Dialogs::updateBufferDependent(bool switched) const
> 211 {
> 212 std::map::const_iterator it =
> dialogs_.begin();
> 213 std::map::const_iterator end =
> dialogs_.end();
> 214
> 215 for(; it != end; ++it) {
> 216 Dialog * dialog = it->second.get();
> 217 if (switched &&
> dialog->controller().isBufferDependent()) {
> 218 dialog->hide();
> 219 } else {
> 220 // A bit clunky, but the dialog will
> request
> 221 // that the kernel provides it with the
> necessary
> 222 // data.
> 223 dialog->RestoreButton();
> 224 }
> 225 }
> 226 }
>
> Hm. I could have sworn that updateBufferDependent used to call
> dialog->update(); Ah well...
>
> Angus
>
I've also found the dialog->hide() which is called when switching,
but it doesn't update to the current TOC.
--
Peter Kümmel
Re: [Cvslog] r16765 - /lyx-devel/trunk/src/output_plaintext.C
Michael Gerz wrote: > I think the fix is not complete. I will provide details tomorrow. Maybe you can also fix the ascii export of tables, which is completely broken: http://bugzilla.lyx.org/show_bug.cgi?id=2515 Jürgen
Drawing woes
This is what I get when opening a new buffer. Typing solves it. Jürgen lyx.png Description: PNG image
