bug with longtable
hi,
when using the option longtable for a table (inside a table float) the
numbering of tables is multiplied by two, such that it goes table 2, table 4,
table 6,... instead of 1,2,3,...
the reason may be that the tex output says
\begin{table}
\begin{longtable}
...
\end{longtable}
\caption{}
\end{table}
but not
\begin{longtable}
...
\caption{}
\end{longtable}
as it should imho.
happened with lyx 1.1.6fix4 from jan 11 2002.
thanks for your great work! knue
Re: bug with longtable
On Wed, Feb 20, 2002 at 09:48:55AM +0100, Andreas Knüpfer wrote: hi, when using the option longtable for a table (inside a table float) the numbering of tables is multiplied by two, such that it goes table 2, table 4, table 6,... instead of 1,2,3,... A longtable should not be used inside a float!
Re: bug with longtable
On Wed, 20 Feb 2002, Andreas [iso-8859-1] Knüpfer wrote:
when using the option longtable for a table (inside a table float) the
numbering of tables is multiplied by two, such that it goes table 2, table 4,
table 6,... instead of 1,2,3,...
the reason may be that the tex output says
\begin{table}
\begin{longtable}
...
\end{longtable}
\caption{}
\end{table}
but not
\begin{longtable}
...
\caption{}
\end{longtable}
as it should imho.
http://www.lyx.org/help/table/longtable.php#caption
Herbert
Re: bug with longtable
On 20-Feb-2002 Herbert Voss wrote:
http://www.lyx.org/help/table/longtable.php#caption
Nice! You'll have a type in there
\myFoothote{...blah...}
\myFoothote{...blah...}
caption and counting
Longtable uses the same counter than tabular. Therefore counting of tables is wrong
if
you use a longtable without a caption. In this case write in preamble:
\let\myEnd\endlongtable
\renewcommand\endlongtable{\myEnd\addtocounter{table}{-1}}
if you have a mix of longtable with and without captions, than write after every
longtable:
\addtocounter{table}{-1}
I don't understand this one. What happens if you don't have a caption does
it increase the counter anyway? Could we have this as a rule and put it always
after a longtable or is there some drawback?
Jürgen
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39100 Bozen Web: http://www.sad.it/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Office Automation:
The use of computers to improve efficiency in the office
by removing anyone you would want to talk with over coffee.
Re: CVS Update: lyx-devel
On Tuesday 19 February 2002 8:45 pm, [EMAIL PROTECTED] wrote: CVSROOT: /usr/local/lyx/cvsroot Module name: lyx-devel Repository: lyx-devel/src/frontends/ Changes by: [EMAIL PROTECTED] 02/02/19 20:45:53 Modified files: lyx-devel/src/frontends/: Makefile.am Log message: better dep tracking I take it there was something wrong after all? Anyway, things still aren't right. Try changing something in the xforms directory. The file is remade, the lib is remade, but thereafter neither the frontends lib not lyx itself are linked in. Regards, Angus Making all in xforms make[4]: Entering directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/src/frontends/xforms' deccxx -DHAVE_CONFIG_H -I. -I. -I../../../src -I../../../images -I../../../src/-I../../../src/frontends/ -I../../../src/frontends/controllers-I../../.. -I../../.. -I../../../boost -I../../../src/cheaders -I/usr/local/include -msg_display_number -msg_disable 11,193,236,261,401,611 -w0 -ptr /usr/users/aleem/OTHERS_CODE/lyx/devel/lyx_cxx_repository -O2 -c FormForks.C cxx -std strict_ansi -nocleanup -DHAVE_CONFIG_H -I. -I. -I../../../src -I../../../images -I../../../src/ -I../../../src/frontends/ -I../../../src/frontends/controllers -I../../.. -I../../.. -I../../../boost -I../../../src/cheaders -I/usr/local/include -msg_display_number -msg_disable 11,193,236,261,401,611 -w0 -ptr /usr/users/aleem/OTHERS_CODE/lyx/devel/lyx_cxx_repository -O2 -MD -c FormForks.C cxx: Warning: /usr/include/cxx/algorithm.cc, line 110: #1115-D external routine uses unnamed type or namespace. InputIterator find_if (InputIterator first, InputIterator last, Predicate pred) --^ rm -f ../libxforms.objects.new for fil in Alert_pimpl.o bmtable.o Color.o combox.o Dialogs.o DropDown.o FileDialog.o FormFiledialog.o form_filedialog.o GUIRunTime.o FormAboutlyx.o form_aboutlyx.o FormBase.o FormBaseDeprecated.o FormBibitem.o form_bibitem.o FormBibtex.o form_bibtex.o FormBrowser.o form_browser.o FormCharacter.o form_character.o FormCitation.o form_citation.o FormDocument.o form_document.o FormError.o form_error.o FormERT.o form_ert.o FormExternal.o form_external.o FormFloat.o form_float.o FormForks.o form_forks.o FormGraphics.o form_graphics.o FormInclude.o form_include.o FormIndex.o form_index.o FormInset.o FormLog.o FormMathsBitmap.o FormMathsDeco.o form_maths_deco.o FormMathsDelim.o form_maths_delim.o FormMathsMatrix.o form_maths_matrix.o FormMathsPanel.o form_maths_panel.o FormMathsSpace.o form_maths_space.o FormMathsStyle.o form_maths_style.o FormMinipage.o form_minipage.o FormParagraph.o form_paragraph.o FormPreamble.o form_preamble.o FormPreferences.o form_preferences.o FormPrint.o form_print.o FormRef.o form_ref.o FormSearch.o form_search.o FormShowFile.o FormSpellchecker.o form_spellchecker.o FormTabular.o form_tabular.o FormTabularCreate.o form_tabular_create.o FormTexinfo.o form_texinfo.o FormThesaurus.o form_thesaurus.o FormToc.o form_toc.o FormUrl.o form_url.o FormVCLog.o input_validators.o MathsSymbols.o Menubar_pimpl.o RadioButtonGroup.o Timeout_pimpl.o Toolbar_pimpl.o Tooltips.o xforms_helpers.o xformsBC.o ; do \ echo xforms/$fil ../libxforms.objects.new ; \ done if [ -f ../libxforms.objects ] ; then \ cmp -s ../libxforms.objects ../libxforms.objects.new || mv ../libxforms.objects.new ../libxforms.objects ; \ else \ mv ../libxforms.objects.new ../libxforms.objects ; \ fi make[4]: Leaving directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/src/frontends/xforms' make[4]: Entering directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/src/frontends' make[4]: Nothing to be done for `all-am'. make[4]: Leaving directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/src/frontends' make[3]: Leaving directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/src/frontends' make[3]: Entering directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/src' make[3]: Nothing to be done for `all-am'. make[3]: Leaving directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/src' make[2]: Leaving directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/src' make[1]: Leaving directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/src' Making all in lib make[1]: Entering directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/lib' Making all in reLyX make[2]: Entering directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/lib/reLyX' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/lib/reLyX' make[2]: Entering directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/lib' make[2]: Nothing to be done for `all-am'. make[2]: Leaving directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/lib' make[1]: Leaving directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/lib' make[1]: Entering directory `/usr/users/aleem/OTHERS_CODE/lyx/devel' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/usr/users/aleem/OTHERS_CODE/lyx/devel' aleem@pneumon:devel-
syscall.[Ch] ???
Why are the two files in the repository but not used? Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Abraham Lincoln didn't die in vain. He died in Washington, D.C.
Re: layout.diff (layout as string)
On Tue, Feb 19, 2002 at 08:43:58PM +0100, Lars Gullik Bjønnes wrote: [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | And it still crashes, but should be better... | I know there is some small stupid thing in there somewhere, but cannot | see it. I'd be really grateful if someone else coule have a look at | this (not cleaned up) patch, and perhaps try it too. Hopefully that | should flush out the remaining (small) problems. All the above still applies. This patch also handles some of J-M's concerns. Still not cleaned up. Please help find the stupid problem. First-off, I see that it trips over the first starred layout (Part*) that it encounters. The non-starred ones before that are processed OK. The search continues :-) Martin msg33238/pgp0.pgp Description: PGP signature
Forked call question
I have asynchronous conversion of graphics files to a loadable format working
here beautifully. They don't display, because I don't explicitly tell LyX
that they've loaded (that ol' dispatch question). I have to enter something
on the paragraph to force a redraw. Anyway, that's not the main point of this
mail. This is:
I find that the conversion process works about 50% of the time. The rest of
the time, the forked call controller thinks that the child dies and I get the
message: LyX: Error waiting for child: No child processes. the relevant
code is:
void ForkedcallsController::timer()
{
ListType::size_type start_size = forkedCalls.size();
for (ListType::iterator it = forkedCalls.begin();
it != forkedCalls.end(); ++it) {
Forkedcall * actCall = *it;
pid_t pid = actCall-pid();
int stat_loc;
int const waitrpid = waitpid(pid, stat_loc, WNOHANG);
bool remove_it = false;
if (waitrpid == -1) {
lyxerr LyX: Error waiting for child:
strerror(errno) endl;
// Child died, so pretend it returned 1
actCall-setRetValue(1);
remove_it = true;
}
}
}
Is there a knowledgeable person out there who can tell me what I'm doing
wrong? Is it just that I'm not polling the process often enough? (The timer
is currently set to 500ms.) Or is this symptomatic of something more serious?
Angus
Re: syscall.[Ch] ???
On Wednesday 20 February 2002 10:42 am, Juergen Vigna wrote: Why are the two files in the repository but not used? I think that they are removed from the repository. I replaced them with systemcall.[Ch]. Angus
Re: syscall.[Ch] ???
On 20-Feb-2002 Angus Leeming wrote: On Wednesday 20 February 2002 10:42 am, Juergen Vigna wrote: Why are the two files in the repository but not used? I think that they are removed from the repository. I replaced them with systemcall.[Ch]. Seems you're right. Maybe there was a Clash before in that file and so the cvs update didn't remove it. I removed it by hand and now cvs update did tell me that it isn't pertinent anymore. Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ You don't become a failure until you're satisfied with being one.
Re: Forked call question
On Wed, Feb 20, 2002 at 10:48:07AM +, Angus Leeming wrote: I find that the conversion process works about 50% of the time. The rest of the time, the forked call controller thinks that the child dies and I get the message: LyX: Error waiting for child: No child processes. the relevant code is: what happens if you waitpid(-1, ...) ? regards john -- They eat cold meat for breakfast and make jokes about gzip. - Rik Hemsley on KDE developers
Re: ERT patch
Juergen == Juergen Vigna [EMAIL PROTECTED] writes: Juergen For all of you who didn't look at it in short it does leave Juergen the Paragraph (Character) Params unchanged when copiing them Juergen inside an ERT and ONLY the display is changed. This is done Juergen by calling a function which changes the Font of the chars Juergen when they are drawed on screen. Juergen Anyway all of you should already have had a look at the patch Juergen and tried it out. So if I don't get any serious complaints I Juergen will commit my tree soon! I did not have time to actually try it out, but as I said in bug 143, you should really rename getFontSettings to something else because it does not have the same semantics as the other getFontSettings. What about adaptFont or filterFont? And what is this HARD_FONTS thing? Could you clean it up before commiting? As it stands the code is a bit difficult to follow. JMarc
Re: ERT patch
On Wed, Feb 20, 2002 at 11:51:33AM +0100, Juergen Vigna wrote: Anyway all of you should already have had a look at the patch and tried it out. So if I don't get any serious complaints I will commit my tree soon! see jmarc's comments on bugzilla ! also there is another patch of yours on bugzilla that you need to apply I suppose regards john -- They eat cold meat for breakfast and make jokes about gzip. - Rik Hemsley on KDE developers
Re: ERT patch
On 20-Feb-2002 Jean-Marc Lasgouttes wrote: I did not have time to actually try it out, but as I said in bug 143, you should really rename getFontSettings to something else because it does not have the same semantics as the other getFontSettings. What about adaptFont or filterFont? getDrawFont() ? And what is this HARD_FONTS thing? Could you clean it up before commiting? As it stands the code is a bit difficult to follow. Well I just didn't want to remove code I would need afterwards and I had to have a look in which places I needed the font changes. But all the code inside a #ifdef HARD_FONTS can be removed as soon as we're sure the thing works as wanted. Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Without followers, evil cannot spread. -- Spock, And The Children Shall Lead, stardate 5029.5
Re: ERT patch
On 20-Feb-2002 John Levon wrote: also there is another patch of yours on bugzilla that you need to apply I suppose Did you see my recent commit ;) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ The ripest fruit falls first. -- William Shakespeare, Richard II
Re: layout.diff (layout as string)
On Wed, Feb 20, 2002 at 11:54:04AM +0100, Lars Gullik Bjønnes wrote:
Martin Vermeer [EMAIL PROTECTED] writes:
...
Please help find the stupid problem.
| First-off, I see that it trips over the first starred layout (Part*) that
| it encounters. The non-starred ones before that are processed OK.
the question is if this is because of the '*' or something else...
--
Lgb
Think I got it (famous last words :-), or at least part of the problem.
When compiling lyxlayout, I get
lyxlayout.C: In method `const class string LyXLayout::name() const':
lyxlayout.C:740: warning: returning reference to temporary
lyxlayout.C: In method `const class string LyXLayout::obsoleted_by() const':
lyxlayout.C:752: warning: returning reference to temporary
Perhaps we should heed these warnings.
I believe that in lyxtextclass.C on line 268 below, lay.name()
returns pølse, the content of a pointer to an evaporated temp.
257 case TC_STYLE:
258 if (lexrc.next()) {
259 string const name = subst(lowercase(lexrc.getString()),
260 '_', ' ');
261 if (hasLayout(name)) {
262 LyXLayout lay = GetLayout(name);
263 error = do_readStyle(lexrc, lay);
264 } else {
265 LyXLayout lay;
266 lyxerr Name before: name endl;
267 lay.setName(name);
268 lyxerr lay.name() after: lay.name() endl;
269 if (!(error = do_readStyle(lexrc, lay))) {
270 layoutlist.push_back(lay);
271 }
272 }
How to fix it is another story...
Martin
msg33248/pgp0.pgp
Description: PGP signature
Re: ERT patch
Juergen == Juergen Vigna [EMAIL PROTECTED] writes: Juergen On 20-Feb-2002 Jean-Marc Lasgouttes wrote: I did not have time to actually try it out, but as I said in bug 143, you should really rename getFontSettings to something else because it does not have the same semantics as the other getFontSettings. What about adaptFont or filterFont? Juergen getDrawFont() ? I can live with that. The most important is that the name is not getFontSettings. We used to have a convertFont doing exactly what you need BTW. And what is this HARD_FONTS thing? Could you clean it up before commiting? As it stands the code is a bit difficult to follow. Juergen Well I just didn't want to remove code I would need Juergen afterwards and I had to have a look in which places I needed Juergen the font changes. But all the code inside a #ifdef HARD_FONTS Juergen can be removed as soon as we're sure the thing works as Juergen wanted. OK. JMarc
Re: CVS Update: lyx-devel
On Wednesday 20 February 2002 11:25 am, Lars Gullik Bjønnes wrote: | On Tuesday 19 February 2002 8:45 pm, [EMAIL PROTECTED] wrote: CVSROOT: /usr/local/lyx/cvsroot Module name: lyx-devel Repository:lyx-devel/src/frontends/ Changes by:[EMAIL PROTECTED] 02/02/19 20:45:53 Modified files: lyx-devel/src/frontends/: Makefile.am Log message: better dep tracking | I take it there was something wrong after all? | Anyway, things still aren't right. Try changing something in the xforms | directory. The file is remade, the lib is remade, but thereafter neither the | frontends lib not lyx itself are linked in. Can you try this patch? You have to be in src/frontends when patching So you're basically reverting the changes you made to Makefile.ams in the frontends? Yes, this appears to work. Angus
Re: CVS Update: lyx-devel
On Wednesday 20 February 2002 12:18 pm, Lars Gullik Bjønnes wrote: Angus Leeming [EMAIL PROTECTED] writes: | On Wednesday 20 February 2002 11:25 am, Lars Gullik Bjønnes wrote: | On Tuesday 19 February 2002 8:45 pm, [EMAIL PROTECTED] wrote: CVSROOT:/usr/local/lyx/cvsroot Module name:lyx-devel Repository: lyx-devel/src/frontends/ Changes by: [EMAIL PROTECTED] 02/02/19 20:45:53 Modified files: lyx-devel/src/frontends/: Makefile.am Log message: better dep tracking | I take it there was something wrong after all? | Anyway, things still aren't right. Try changing something in the xforms | directory. The file is remade, the lib is remade, but thereafter neither | the | frontends lib not lyx itself are linked in. Can you try this patch? You have to be in src/frontends when patching | So you're basically reverting the changes you made to Makefile.ams in the | frontends? No, not quite. Simplifying is a better word. | Yes, this appears to work. also the dependency tracking? Seems to. I'll keep an eye out for things going wrong. Needless to say, you're a b-tard for making me rebuild practically the whole tree for the Xth time in a week! ;-) Angus
Re: ERT patch
On 20-Feb-2002 Juergen Vigna wrote: the paragraphs should be forced left aligned, IMO. And also we should disable the whole Paragraph-Layout for paragraphs inside an I've just seen that the Layout-Paragraph is disabled if I'm inside an ERT, but if I have the layout already open I'm able to apply the changes still to the paragraph inside the ERT, this is wrong IMO. And IMO the Layout-Character Menu should also be disabled. Here it is the other way round the changes I make will not be applied and I get an error message that it isn't possible, but I can open the Layout which I shouldn't IMO. BTW.: People who use a lot of ERT am I right to assume that alignment of the paragraphs inside a ERT inset should be left aligned? Or do you prefer leave it as is? Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ The meeting of two personalities is like the contact of two chemical substances: if there is any reaction, both are transformed. -- Carl Jung
string - pointer question
When the loading status of a graphics file changes, I need to inform LyX. I
do this with:
LyXFunc::dispatch(LFUN_GRAPHICS_CHANGED_STATE, argument);
where argument is a list of insets as a space-separated string.
I split the string up and convert each substring back to a pointer with:
bool isStrPtr(string const str)
{
return isStrUnsignedInt(str);
}
void * strToPtr(string const str)
{
return (void *)strToUnsignedInt(str);
}
Is there a better way?
Angus
Re: string - pointer question
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus When the loading status of a graphics file changes, I need to Angus inform LyX. I do this with: Angus LyXFunc::dispatch(LFUN_GRAPHICS_CHANGED_STATE, argument); Angus where argument is a list of insets as a space-separated string. Angus I split the string up and convert each substring back to a Angus pointer with: Why can't you signal the insets directly? It looks like a case where the lyxfunc think is really not appropriate... It looks like you could just call some InsetGraphics::fileChanged method directly. JMarc
Re: string - pointer question
On Wednesday 20 February 2002 1:32 pm, Angus Leeming wrote:
Actually, that was a bit premature. This doesn't work! Has anybody any idea
about how to write isStrPtr(str), strToPtr(str)? Should I use the C library
function strtoul?
Angus
When the loading status of a graphics file changes, I need to inform LyX. I
do this with:
LyXFunc::dispatch(LFUN_GRAPHICS_CHANGED_STATE, argument);
where argument is a list of insets as a space-separated string.
I split the string up and convert each substring back to a pointer with:
bool isStrPtr(string const str)
{
return isStrUnsignedInt(str);
}
void * strToPtr(string const str)
{
return (void *)strToUnsignedInt(str);
}
Is there a better way?
Angus
Re: ERT patch
Juergen == Juergen Vigna [EMAIL PROTECTED] writes: Juergen On 20-Feb-2002 Juergen Vigna wrote: the paragraphs should be forced left aligned, IMO. And also we should disable the whole Paragraph-Layout for paragraphs inside an Juergen I've just seen that the Layout-Paragraph is disabled if I'm Juergen inside an ERT, but if I have the layout already open I'm able Juergen to apply the changes still to the paragraph inside the ERT, Juergen this is wrong IMO. This is bug #229. John had a patch for this, but it did not work for some reason. Juergen And IMO the Layout-Character Menu should also be disabled. Juergen Here it is the other way round the changes I make will not be Juergen applied and I get an error message that it isn't possible, Juergen but I can open the Layout which I shouldn't IMO. Actually we have to decide whether it should be possible to open these read-only for inspection purpose, or whether they should just be disabled. I think that the document menu has code to work for a read-only doc, for example. Juergen BTW.: People who use a lot of ERT am I right to assume that Juergen alignment of the paragraphs inside a ERT inset should be left Juergen aligned? Or do you prefer leave it as is? I'd say that we don't care for now. JMArc
Re: ERT patch
On 20-Feb-2002 Jean-Marc Lasgouttes wrote: Juergen And IMO the Layout-Character Menu should also be disabled. Juergen Here it is the other way round the changes I make will not be Juergen applied and I get an error message that it isn't possible, Juergen but I can open the Layout which I shouldn't IMO. Actually we have to decide whether it should be possible to open these read-only for inspection purpose, or whether they should just be disabled. How would you inspect character stuff with the Character layout??? And for the paragraph Layout I REALLY think that you don't have to inspect anything regarding the paragraph Layout of an ERT Inset as all settings there are dummy for such a paragraph. Juergen BTW.: People who use a lot of ERT am I right to assume that Juergen alignment of the paragraphs inside a ERT inset should be left Juergen aligned? Or do you prefer leave it as is? I'd say that we don't care for now. Well I would care if it's easy enough to fix. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Mother told me to be good but she's been wrong before.
Re: string - pointer question
On 20-Feb-2002 Jean-Marc Lasgouttes wrote:
Why can't you signal the insets directly? It looks like a case where
the lyxfunc think is really not appropriate... It looks like you could
just call some InsetGraphics::fileChanged method directly.
You got a point there, but we have to provide a function for this then IMO.
Well for now Angus could just add that function to InsetGraphics (I would
call the function redrawInset(BufferView *) and then you could directly call
InsetGraphics * myinset = *it;
myinset-redrawInset(bview);
and the function should be somethink like
void redrawInset(BufferView * bv)
{
bv-updateInset(this, false);
}
Hmm or just without adding any functions why not directly call
bview-updateInset(myinset, false) where you check for the changes.
But I assume that you probably don't have the BufferView there or do you?
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39100 Bozen Web: http://www.sad.it/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
A robin redbreast in a cage
Puts all Heaven in a rage.
-- Blake
Re: string - pointer question
On Wednesday 20 February 2002 2:45 pm, Jean-Marc Lasgouttes wrote: Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus When the loading status of a graphics file changes, I need to Angus inform LyX. I do this with: Angus LyXFunc::dispatch(LFUN_GRAPHICS_CHANGED_STATE, argument); Angus where argument is a list of insets as a space-separated string. Angus I split the string up and convert each substring back to a Angus pointer with: Why can't you signal the insets directly? It looks like a case where the lyxfunc think is really not appropriate... It looks like you could just call some InsetGraphics::fileChanged method directly. Ok. I thought it was ugly. So how should I proceed. Somehow I need to tell the underlying bufferview that the inset has changed. That is, I'll have to call BufferView::updateInset(Inset *, false) The question is how? Should I modify GCache::update from void GCache::update(InsetGraphics const ); to void GCache::update(InsetGraphics const , BufferView const *); and store which BufferView the inset is to be found in. Only this won't work when we have multiple BufferViews. Alternatively, I should store the BufferView in the inset, but this also seems very ugly. I have _really_ no clue about this and I am rapidly running out of time to fix it. Perhaps I'll just post a copy of what I have and let you play? As far as I can see, this is the only show stopper left for asynchronous graphics conversion. Angus
Re: string - pointer question
On 20-Feb-2002 Angus Leeming wrote: So how should I proceed. Somehow I need to tell the underlying bufferview that the inset has changed. That is, I'll have to call BufferView::updateInset(Inset *, false) The question is how? I would say as proove of concept you can use current_view (VERY EVIL ;) and see if it works the way you expect it if you HAVE the BufferView pointer actually. We still have to remove the current_view pointers completely from the source but IMO we can only do it if we somewhere have a list which tells us the BufferViews for a certain buffer and IMO this could be inside buffer.h vectorBufferView * bufferviews. Then if you have to update a certain thing you can iterate over the vector and update it on all BufferViews! But we still have to decide about that. As I told you for now and for you to be sure it will work try current_view for now. Jug P.S.: I should have sent this privately as I will get hit on my head (virtually) for proposing it, but well I like the danger #:O) -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ History is curious stuff You'd think by now we had enough Yet the fact remains I fear They make more of it every year.
Re: ERT patch
Juergen == Juergen Vigna [EMAIL PROTECTED] writes: Juergen How would you inspect character stuff with the Character Juergen layout??? And for the paragraph Layout I REALLY think that Juergen you don't have to inspect anything regarding the paragraph Juergen Layout of an ERT Inset as all settings there are dummy for Juergen such a paragraph. The problem is to know what you do when the popup is already open adn you place cursor to an ert inset 1/ close the popup. This is conssitent with disabling of the menu entry, but it _may_ seem weird to soe people 2/ keep the popup, but with all buttons disabled. This makes sense, but in this case, the menu entry should not be disabled. Things would be much simpler with modal dialogs... Juergen Well I would care if it's easy enough to fix. But is it really? You will have to add kludges in the code. JMarc
Re: string - pointer question
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Should I modify GCache::update from void Angus GCache::update(InsetGraphics const ); to void Angus GCache::update(InsetGraphics const , BufferView const *); Angus and store which BufferView the inset is to be found in. Only Angus this won't work when we have multiple BufferViews. Angus Alternatively, I should store the BufferView in the inset, but Angus this also seems very ugly. What bufferview would you use with your lfun solution? If you know that, you can just use the same... JMarc
Re: string - pointer question
On Wednesday 20 February 2002 2:16 pm, Juergen Vigna wrote: On 20-Feb-2002 Angus Leeming wrote: So how should I proceed. Somehow I need to tell the underlying bufferview that the inset has changed. That is, I'll have to call BufferView::updateInset(Inset *, false) The question is how? I would say as proove of concept you can use current_view (VERY EVIL ;) and see if it works the way you expect it if you HAVE the BufferView pointer actually. We still have to remove the current_view pointers completely from the source but IMO we can only do it if we somewhere have a list which tells us the BufferViews for a certain buffer and IMO this could be inside buffer.h vectorBufferView * bufferviews. Then if you have to update a certain thing you can iterate over the vector and update it on all BufferViews! But we still have to decide about that. As I told you for now and for you to be sure it will work try current_view for now. Jug P.S.: I should have sent this privately as I will get hit on my head (virtually) for proposing it, but well I like the danger #:O) Man, you're evil! I'd forgotten all about this beast! Yes, proof of concept works. As you told me earlier, it doesn't work if the inset is in a table of a float, but IMO that's for an expert such as yourself! I'll clean up my code and then put the (enormous) patch in www.devel.lyx.org/~aleem Angus
Re: string - pointer question
On Wednesday 20 February 2002 3:30 pm, Jean-Marc Lasgouttes wrote: Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Should I modify GCache::update from void Angus GCache::update(InsetGraphics const ); to void Angus GCache::update(InsetGraphics const , BufferView const *); Angus and store which BufferView the inset is to be found in. Only Angus this won't work when we have multiple BufferViews. Angus Alternatively, I should store the BufferView in the inset, but Angus this also seems very ugly. What bufferview would you use with your lfun solution? If you know that, you can just use the same... I had LyX as a singleton class and gave it a dispatch method. The idea was that eventually it could iterate over all LyXViews. I suspect that we'll need something like this eventually. For example, it's currently impossible to modify a bunch of the preferences settings in a running LyX. For now, I'll use Jürgen's kludge. Angus
Re: string - pointer question
On 20-Feb-2002 Jean-Marc Lasgouttes wrote: What bufferview would you use with your lfun solution? If you know that, you can just use the same... This doesn't matter as in the case of multiple bufferviews the lyxfunc aproach would also be wrong: owner()-view() which view??? We now have only ONE VISIBLE view, while obviously taking care that maybe one time we could have multiple I think we should try to solve one problem at a time ;) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Bernard Shaw is an excellent man; he has not an enemy in the world, and none of his friends like him either. -- Oscar Wilde
Fix? (Re: layout.diff (layout as string))
I have it like this in my tree now:
string const LyXLayout::name() const
{
name_ = lowercase(name_);
return name_;
}
string const LyXLayout::obsoleted_by() const
{
obsololeted_by_ = lowercase(obsoleted_by_);
return obsoleted_by_;
}
You should try this:
---
string const LyXLayout::name() const
{
string * name = new string(lowercase(name_));
return * name;
}
---
...
---
string const LyXLayout::obsoleted_by() const
{
string * obsoleted_by = new string (lowercase(obsoleted_by_));
return * obsoleted_by;
}
---
Surprise, it works!
... And bug 221 is gone. And John's cut-change-textclass-undo bug
is gone. It just seems to work, i.e. there seemingly are no further
serious errors!
I *hate* the above code. It demonstrates that the problem apparently was
lack of allocated memory to hold the string in question, but the above
is ugly. And undoubtedly leaks like a sieve. Feel free to come up with
something better!
Martin
msg33267/pgp0.pgp
Description: PGP signature
Re: string - pointer question
Juergen == Juergen Vigna [EMAIL PROTECTED] writes: Juergen On 20-Feb-2002 Jean-Marc Lasgouttes wrote: What bufferview would you use with your lfun solution? If you know that, you can just use the same... Juergen This doesn't matter as in the case of multiple bufferviews Juergen the lyxfunc aproach would also be wrong: owner()-view() Juergen which view??? This is what I had in mind, indeed. You've got to find a bufferview somewhere. And probably an inset should be able to know in which bufferviews it belongs (I assume it could do that by knowing in which document it belongs) JMarc
Re: string - pointer question
On 20-Feb-2002 Jean-Marc Lasgouttes wrote: This is what I had in mind, indeed. You've got to find a bufferview somewhere. And probably an inset should be able to know in which bufferviews it belongs (I assume it could do that by knowing in which document it belongs) Yes document or we would say buffer, wouldn't we? But do we really want to store the BufferPointer inside the single insets? I would do this only if really necessary (I hate it for insettabular but I cannot find another way to do it there). Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ memo, n.: An interoffice communication too often written more for the benefit of the person who sends it than the person who receives it.
Re: layout.diff (layout as string)
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Martin Vermeer [EMAIL PROTECTED] writes: | lyxlayout.C: In Lars method `const class string LyXLayout::name() const': | Lars lyxlayout.C:740: warning: returning reference to temporary | Lars lyxlayout.C: In method `const class string Lars LyXLayout::obsoleted_by() const': | lyxlayout.C:752: warning: Lars returning reference to temporary Lars Fixing these fixed the problem. Lars I have now a patch that apperars to be working, but I have not Lars tested switching layout-layout, reading nonexistant layout Lars etc. Basically, I like what I see. Probablt all the explicit calls to textclasslist should be encapsulatead in some TextClass BufferParam::getTClass() and maybe also TextClass Buffer::getTClass() This would make code more readable and avoid including useless headers. Lars The pach has been cleaned up a bit and is closer to ready for Lars inclusion. Yes. JMarc
Re: layout.diff (layout as string)
On Wed, Feb 20, 2002 at 04:15:48PM +0100, Lars Gullik Bjønnes wrote:
Martin Vermeer [EMAIL PROTECTED] writes:
| lyxlayout.C: In method `const class string LyXLayout::name() const':
| lyxlayout.C:740: warning: returning reference to temporary
| lyxlayout.C: In method `const class string LyXLayout::obsoleted_by() const':
| lyxlayout.C:752: warning: returning reference to temporary
Fixing these fixed the problem.
I have now a patch that apperars to be working, but I have not tested
switching layout-layout, reading nonexistant layout etc.
The pach has been cleaned up a bit and is closer to ready for
inclusion.
People, please test (and be careful)
Report any and all problems to me...
Yes, sure... using a static works too. Not pretty... but what's a man to
do ;-)
Please put the following also in your local tree, or I suspect Bug 221
will still be alive.
Martin
Index: CutAndPaste.C
===
RCS file: /cvs/lyx/lyx-devel/src/CutAndPaste.C,v
retrieving revision 1.46
diff -u -b -B -p -r1.46 CutAndPaste.C
--- CutAndPaste.C 2002/01/17 10:54:30 1.46
+++ CutAndPaste.C 2002/02/20 15:17:48
@@ -223,37 +225,6 @@ bool CutAndPaste::pasteSelection(Paragra
Paragraph * tmppar = *par;
int tmppos = pos;
- // There are two cases: cutbuffer only one paragraph or many
- if (!buf-next()) {
- // only within a paragraph
- Paragraph * tmpbuf = new Paragraph(*buf, false);
-
- // Some provisions should be done here for checking
- // if we are inserting at the beginning of a
- // paragraph. If there are a space at the beginning
- // of the text to insert and we are inserting at
- // the beginning of the paragraph the space should
- // be removed.
- while (buf-size()) {
- // This is an attempt to fix the
- // never insert a space at the
- // beginning of a paragraph problem.
- if (!tmppos buf-isLineSeparator(0)) {
- buf-erase(0);
- } else {
- buf-cutIntoMinibuffer(current_view-buffer()-params,
0);
- buf-erase(0);
- if (tmppar-insertFromMinibuffer(tmppos))
- ++tmppos;
- }
- }
- delete buf;
- buf = tmpbuf;
- *endpar = tmppar-next();
- pos = tmppos;
- } else {
- // many paragraphs
-
// make a copy of the simple cut_buffer
Paragraph * tmpbuf = buf;
Paragraph * simple_cut_clone = new Paragraph(*tmpbuf, false);
@@ -345,7 +316,6 @@ bool CutAndPaste::pasteSelection(Paragra
}
// restore the simple cut buffer
buf = simple_cut_clone;
- }
return true;
}
msg33271/pgp0.pgp
Description: PGP signature
wirte_attribute and template using
We have this in tabular_funcs.h:
templateclass T
string const write_attribute(string const name, T const t)
{
string str = + name + =\ + tostr(t) + \;
return str;
}
template
string const write_attribute(string const name, bool const b);
template
string const write_attribute(string const name, LyXLength const value);
Now I would assume that write_attribure(string, bool) would call the second
function, but it seems this is not true :(. I debugged this with gdb and ONLY
the first one (the template one) is called.
Why I looked at this code. Well I did it to fix the problem with the file
format bloat requested by some people and to write out only true values
and ignore false values.
I could do this also be having a if (bool) write_attribute() but this seems
pretty stupid to me as it can be solved inside the write_attribute function.
So could somebody help me out here. I'll attach the diff so you can see
what I did and comment on it.
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39100 Bozen Web: http://www.sad.it/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Got Mole problems? Call Avogadro at 6.02 x 10^23.
? src/frontends/libcontrollers.objects
? src/frontends/libcontrollers.objects.new
? src/frontends/libxforms.objects
? src/frontends/libxforms.objects.new
Index: src/tabular_funcs.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/tabular_funcs.C,v
retrieving revision 1.5
diff -u -p -r1.5 tabular_funcs.C
--- src/tabular_funcs.C 2002/02/16 15:59:43 1.5
+++ src/tabular_funcs.C 2002/02/20 15:37:28
@@ -30,12 +30,21 @@ using std::getline;
template
string const write_attribute(string const name, bool const b)
{
+ // we write only true attribute values so we remove a bit of the
+ // file format bloat for tabulars.
+ if (!b)
+ return string();
+
return write_attribute(name, int(b));
}
template
string const write_attribute(string const name, LyXLength const value)
{
+ // we write only the value if we really have one same reson as above.
+ if (value.zero())
+ return string();
+
return write_attribute(name, value.asString());
}
@@ -210,6 +219,9 @@ bool getTokenValue(string const str, c
bool getTokenValue(string const str, const char * token, bool flag)
{
+ // set the flag always to false as this should be the default for bools
+ // not in the file-format.
+ flag = false;
string tmp;
if (!getTokenValue(str, token, tmp))
return false;
@@ -219,6 +231,9 @@ bool getTokenValue(string const str, c
bool getTokenValue(string const str, const char * token, LyXLength len)
{
+ // set the lenght to be zero() as default as this it should be if not
+ // in the file format.
+ len = LyXLength();
string tmp;
if (!getTokenValue(str, token, tmp))
return false;
Re: layout.diff (layout as string)
Please put the following also in your local tree, or I suspect Bug 221 will still be alive. This was already fixed this morning. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ The problem with this country is that there is no death penalty for incompetence.
BadWindows
Am I really the only one getting badwindows pretty reliably when inserting graphics ?? The window is the dialog window for FormGraphics. Inserting XSync()s in relevant places doesn't help. The interesting thing is, if you don't open the file dialog, but enter the name in the dialog, it won't BadWindow on us, but we still get the unhandled X event message. Anyone for ignoring BadWindow in lyx X handler ? worried, john -- They eat cold meat for breakfast and make jokes about gzip. - Rik Hemsley on KDE developers
Re: layout.diff (layout as string)
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars mmm but there will be a lot of places that does not have a Lars BufferParam? Not sure. Lars I am not sure if we should do this cleanup now. The patch does Lars not exacly make things more unclean that in already is. Agreed. JMarc
Re: Fix? (Re: layout.diff (layout as string))
By accident, I saw your message with the following code:
string const LyXLayout::name() const
{
string * name = new string(lowercase(name_));
return * name;
}
This code produces a memory leak each time it is invoked!
Using a static function variable could help but it is not safe, too!
IMHO you should definitely return a real copy of the string! What's
wrong with that?
Michael
Re: layout.diff (layout as string)
On Wed, Feb 20, 2002 at 04:15:48PM +0100, Lars Gullik Bjønnes wrote: Martin Vermeer [EMAIL PROTECTED] writes: | lyxlayout.C: In method `const class string LyXLayout::name() const': | lyxlayout.C:740: warning: returning reference to temporary | lyxlayout.C: In method `const class string LyXLayout::obsoleted_by() const': | lyxlayout.C:752: warning: returning reference to temporary Fixing these fixed the problem. I have now a patch that apperars to be working, but I have not tested switching layout-layout, reading nonexistant layout etc. The pach has been cleaned up a bit and is closer to ready for inclusion. People, please test (and be careful) Report any and all problems to me... I am still left with one nagging question... it was your patch that moved name() and setName(...) of LyXLayout from inline in the .h file to the .C file. Why? Does that make any difference for the bug, in other words, did this cause the bug to appear? If so, how? Martin msg33278/pgp0.pgp Description: PGP signature
Re: BadWindows
On Wed, Feb 20, 2002 at 05:22:20PM +0100, Lars Gullik Bjønnes wrote: Anyone for ignoring segfaults? there's a big difference ;) will ignoring BW actually work? yes. I've investigated further, and I know now a) what the xforms bug is and b) how to reproduce it I haven't yet connected b) to a), and I have no idea for a workaround. It may be possible that it's only an xforms 0.88.9 bug, in which case it can be ignored I suppose. Can people try : 1. insert inset graphics, choose a filename via the file dialog 2. click OK and (while it's loading) quickly move the mouse up to hover over the graphics inset. Hopefully (!) you will get a BadWindow. Now, this comes from xforms compressing motion events by picking them from the queue without regard to whether the window has actually died in the meantime or not. This sequence of events tickles this bug it seems. If we have an event queue like this : MotionNotify (win 4) MotionNotify (win 4) MotionNotify (win 4) DestroyNotify (win 4) we remove the motion notifies to leave : DestroyNotify (win 4) /Before/ seeing this, it will remove all the motion notifies, then if one of them is_hint, then it does an XQueryPointer(), which causes the BadWindow, because it is destroyed !! I've Cc:ed the xforms list in the hope Steve or someone else can tell us that this bug isn't in other xforms versions, or come up with a work around regards john p.s. I'll be happy to fix the problem myself if xforms was open source by now :) -- They eat cold meat for breakfast and make jokes about gzip. - Rik Hemsley on KDE developers
Re: BadWindows
On Wed, Feb 20, 2002 at 04:46:07PM +, John Levon wrote: On Wed, Feb 20, 2002 at 05:22:20PM +0100, Lars Gullik Bjønnes wrote: Anyone for ignoring segfaults? there's a big difference ;) will ignoring BW actually work? yes. I've investigated further, and I know now a) what the xforms bug is and b) how to reproduce it I haven't yet connected b) to a), and I have no idea for a workaround. It may be possible that it's only an xforms 0.88.9 bug, in which case it can be ignored I suppose. No, I have 0.88.1-1 and it does this too. Can people try : 1. insert inset graphics, choose a filename via the file dialog 2. click OK and (while it's loading) quickly move the mouse up to hover over the graphics inset. No, you don't have to hover over the graphic, just the LyX window. In fact you don't even have to have a successful graphics conversion/display. It still crashes: --- try to convert image file: /home/mv/lyx-devel/src/pnlg.eps GetExtension: eps GetExtFromContents: eps from: eps - xpm imageConverted, conversion succeeded. Loading XPM Image... No XPM file found. Loading /tmp/lyx_tmpdir30604utKQMz/pnlg30604x2qi80.xpmFailed Received unhandled X11 event Type: 0x7Target: 0x4c000cf lyx: Attempting to save document newfile11.lyx as... /home/mv/newfile11.lyx.emergency Save seems successful. Phew. BadWindow (invalid Window parameter) Aborted (core dumped) --- Hopefully (!) you will get a BadWindow. Easily :-( regards john p.s. I'll be happy to fix the problem myself if xforms was open source by now :) Martin msg33280/pgp0.pgp Description: PGP signature
Re: BadWindows
Hopefully (!) you will get a BadWindow. lyx: Attempting to save document /home/leuven/newfile2.lyx as... /home/leuven/newfile2.lyx.emergency Save seems successful. Phew. BadWindow (invalid Window parameter) Aborted (core dumped) and a crash!
[GRAPHICS PATCH]: Call for testers
My hacking on the graphics inset has come to the end for the time being I hope. I have something that now loads asynchronously and has hooks in place to modify the LyX view of the image. The zipped file is 33kB in size, so I've shoved it here http://www.devel.lyx.org/~leeming/graphics.diff.bz2 Please try it out. I propose committing this to cvs but testing never hurts! Angus
Re: [GRAPHICS PATCH]: Call for testers
On Wed, Feb 20, 2002 at 05:10:15PM +, Angus Leeming wrote: http://www.devel.lyx.org/~leeming/graphics.diff.bz2 cool I'll look and test. Please try it out. I propose committing this to cvs but testing never hurts! we need to resolve the badwindow issue before committing anything in this area IMHO regards john -- They eat cold meat for breakfast and make jokes about gzip. - Rik Hemsley on KDE developers
Re: BadWindows
Edwin Leuven wrote: Hopefully (!) you will get a BadWindow. lyx: Attempting to save document /home/leuven/newfile2.lyx as... /home/leuven/newfile2.lyx.emergency Save seems successful. Phew. BadWindow (invalid Window parameter) Aborted (core dumped) and a crash! Me too! xforms 0.89.6 Regards, Juergen. - This message was sent using Endymion MailMan. http://www.endymion.com/products/mailman/
Re: [GRAPHICS PATCH]: Call for testers
On Wed, Feb 20, 2002 at 05:10:15PM +, Angus Leeming wrote: http://www.devel.lyx.org/~leeming/graphics.diff.bz2 support/libsupport.o: In function `Forkedcall::kill(int)': /home/moz/src/lyx/lyx-devel/src/support/forkedcall.C:159: undefined reference to `Forkedcall::pid(void) const' /home/moz/src/lyx/lyx-devel/src/support/forkedcall.C:167: undefined reference to `Forkedcall::pid(void) const' /home/moz/src/lyx/lyx-devel/src/support/forkedcall.C:170: undefined reference to `Forkedcall::pid(void) const' /home/moz/src/lyx/lyx-devel/src/support/forkedcall.C:176: undefined reference to `Forkedcall::pid(void) const' support/libsupport.o: In function `ForkedcallsController::timer(void)': /home/moz/src/lyx/lyx-devel/src/support/forkedcontr.C:91: undefined reference to `Forkedcall::pid(void) const' /home/moz/src/lyx/lyx-devel/src/support/forkedcontr.C:101: undefined reference to `Forkedcall::setRetValue(int)' /home/moz/src/lyx/lyx-devel/src/support/forkedcontr.C:110: undefined reference to `Forkedcall::setRetValue(int)' /home/moz/src/lyx/lyx-devel/src/support/forkedcontr.C:115: undefined reference to `Forkedcall::setRetValue(int)' /home/moz/src/lyx/lyx-devel/src/support/forkedcontr.C:129: undefined reference to `Forkedcall::setRetValue(int)' support/libsupport.o: In function `ForkedcallsController::getPIDs(void) const': /home/moz/src/lyx/lyx-devel/src/support/forkedcontr.C:168: undefined reference to `Forkedcall::pid(void) const' support/libsupport.o: In function `ForkedcallsController::getCommand(int) const': /home/moz/src/lyx/lyx-devel/src/support/forkedcontr.C:181: undefined reference to `Forkedcall::pid(void) const' /home/moz/src/lyx/lyx-devel/src/support/forkedcontr.C:186: undefined reference to `Forkedcall::command(void) const' support/libsupport.o: In function `ForkedcallsController::kill(int, int)': /home/moz/src/lyx/lyx-devel/src/support/forkedcontr.C:196: undefined reference to `Forkedcall::pid(void) const' indeed regards john -- They eat cold meat for breakfast and make jokes about gzip. - Rik Hemsley on KDE developers
Re: [GRAPHICS PATCH]: Call for testers
On Wednesday 20 February 2002 5:36 pm, John Levon wrote:
On Wed, Feb 20, 2002 at 05:10:15PM +, Angus Leeming wrote:
http://www.devel.lyx.org/~leeming/graphics.diff.bz2
support/libsupport.o: In function `Forkedcall::kill(int)':
/home/moz/src/lyx/lyx-devel/src/support/forkedcall.C:159: undefined
reference to `Forkedcall::pid(void) const'
???
Do you not have
pid_t pid() const { return pid_; }
in Forkedcall.h?
support/libsupport.o: In function `ForkedcallsController::timer(void)':
/home/moz/src/lyx/lyx-devel/src/support/forkedcontr.C:91: undefined
reference to `Forkedcall::pid(void) const'
ditto.
/home/moz/src/lyx/lyx-devel/src/support/forkedcontr.C:101: undefined
reference to `Forkedcall::setRetValue(int)'
???
Do you not have
void setRetValue(int r) { retval_ = r; }
in Forkedcall.h?
/home/moz/src/lyx/lyx-devel/src/support/forkedcontr.C:186: undefined
reference to `Forkedcall::command(void) const'
???
Do you not have
string const command() const { return command_; }
in Forkedcall.h?
indeed
This looks jolly wierd. All works beautifully here. Could you investigate a
little further for me. Please!
Angus
Re: [GRAPHICS PATCH]: Call for testers
On Wed, Feb 20, 2002 at 05:53:38PM +, Angus Leeming wrote: This looks jolly wierd. All works beautifully here. Could you investigate a little further for me. Please! ok probably the build fuckups we've come to know and love these past few days :) rebuilding now, if I don't moan it's worked regards john -- They eat cold meat for breakfast and make jokes about gzip. - Rik Hemsley on KDE developers
Re: [GRAPHICS PATCH]: Call for testers
On Wed, Feb 20, 2002 at 05:10:15PM +, Angus Leeming wrote: My hacking on the graphics inset has come to the end for the time being I hope. I have something that now loads asynchronously and has hooks in place to modify the LyX view of the image. The zipped file is 33kB in size, so I've shoved it here http://www.devel.lyx.org/~leeming/graphics.diff.bz2 Please try it out. I propose committing this to cvs but testing never hurts! make[3]: Entering directory `/home/dekel/Lyx/lyx-devel2/src/graphics' g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../.. -I../.. -I../../boost -isystem /usr/X11R6/include -O -fno-rtti -fno-exceptions -W -Wall -c GraphicsCache.C In file included from GraphicsCache.C:16: GraphicsCache.h:94: warning: `class ::grfx::GCache' only defines a private destructor and has no friends GraphicsCache.h: In function `void __tcf_0()': GraphicsCache.h:73: `::grfx::GCache::~GCache()' is private GraphicsCache.C:34: within this context make[3]: *** [GraphicsCache.o] Error 1
Re: [GRAPHICS PATCH]: Call for testers
On Wednesday 20 February 2002 6:11 pm, Dekel Tsur wrote: On Wed, Feb 20, 2002 at 05:10:15PM +, Angus Leeming wrote: My hacking on the graphics inset has come to the end for the time being I hope. I have something that now loads asynchronously and has hooks in place to modify the LyX view of the image. The zipped file is 33kB in size, so I've shoved it here http://www.devel.lyx.org/~leeming/graphics.diff.bz2 Please try it out. I propose committing this to cvs but testing never hurts! make[3]: Entering directory `/home/dekel/Lyx/lyx-devel2/src/graphics' g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../.. -I../.. -I../../boost -isystem /usr/X11R6/include -O -fno-rtti -fno-exceptions -W -Wall -c GraphicsCache.C In file included from GraphicsCache.C:16: GraphicsCache.h:94: warning: `class ::grfx::GCache' only defines a private destructor and has no friends GraphicsCache.h: In function `void __tcf_0()': GraphicsCache.h:73: `::grfx::GCache::~GCache()' is private GraphicsCache.C:34: within this context make[3]: *** [GraphicsCache.o] Error 1 Thanks, Dekel. I think this means that your compiler is crap! You'll find this error occuring more than once, I suspect. Just make the d-tor public. Regards, Angus
Re: [GRAPHICS PATCH]: Call for testers
On Wed, Feb 20, 2002 at 06:21:10PM +, Angus Leeming wrote: make[3]: *** [GraphicsCache.o] Error 1 Thanks, Dekel. I think this means that your compiler is crap! You'll find this error occuring more than once, I suspect. Just make the d-tor public. isn't boost::noncopyable good enough ??? john -- They eat cold meat for breakfast and make jokes about gzip. - Rik Hemsley on KDE developers
Re: [GRAPHICS PATCH]: Call for testers
On Wednesday 20 February 2002 5:10 pm, Angus Leeming wrote: My hacking on the graphics inset has come to the end for the time being I hope. I have something that now loads asynchronously and has hooks in place to modify the LyX view of the image. The zipped file is 33kB in size, so I've shoved it here http://www.devel.lyx.org/~leeming/graphics.diff.bz2 Please try it out. I propose committing this to cvs but testing never hurts! Angus I've uploaded a new version where the d-tors of the singleton classes grfx::GCache and grfx::GConverter are public. Should make gcc 2.95 happier. No other changes, so if you have something that's compiled, don't throw it away. Regards, Angus
Re: [GRAPHICS PATCH]: Call for testers
On Wednesday 20 February 2002 6:28 pm, John Levon wrote: On Wed, Feb 20, 2002 at 06:21:10PM +, Angus Leeming wrote: make[3]: *** [GraphicsCache.o] Error 1 Thanks, Dekel. I think this means that your compiler is crap! You'll find this error occuring more than once, I suspect. Just make the d-tor public. isn't boost::noncopyable good enough ??? Yes, probably! Thanks, A
Re: [GRAPHICS PATCH]: Call for testers
On Wed, Feb 20, 2002 at 05:10:15PM +, Angus Leeming wrote: http://www.devel.lyx.org/~leeming/graphics.diff.bz2 nope, still errors out. moz src 149 nm support/libsupport.o --demangle | grep Forkedcall::kill 6670 T Forkedcall::kill(int) moz src 150 nm support/libsupport.o --demangle | grep setRetVal U Forkedcall::setRetValue(int) Basically the inlines from Forkedcall.h don't ever get generated when making forkedcontr.o moz src 161 nm support/forkedcontr.o --demangle | grep Forkedcall::setRet U Forkedcall::setRetValue(int) Looks like (yet again) the new build (since it doesn't make any sense). Perhaps there is a very good reason automake complains at us, i.e. it doesn't work. Can we back the build changes out now please ? regards john -- They eat cold meat for breakfast and make jokes about gzip. - Rik Hemsley on KDE developers
Re: [GRAPHICS PATCH]: Call for testers
On Wed, Feb 20, 2002 at 05:53:38PM +, Angus Leeming wrote:
On Wednesday 20 February 2002 5:36 pm, John Levon wrote:
On Wed, Feb 20, 2002 at 05:10:15PM +, Angus Leeming wrote:
http://www.devel.lyx.org/~leeming/graphics.diff.bz2
support/libsupport.o: In function `Forkedcall::kill(int)':
/home/moz/src/lyx/lyx-devel/src/support/forkedcall.C:159: undefined
reference to `Forkedcall::pid(void) const'
???
Do you not have
pid_t pid() const { return pid_; }
in Forkedcall.h?
find_if(forkedCalls.begin(), forkedCalls.end(),
lyx::compare_memfun(Forkedcall::pid, pid));
Perhaps the problem is that *it is of type 'Forkedcall *' and not of type
Forkedcall.
Math parsing bug.
Hello.
I'm using the latest 1.2.0cvs. The fragments
\begin_inset Formula \[
\frac{3} {2}\]
\end_inset
and
\begin_inset Formula \[
\frac{3}
{2}\]
\end_inset
are not parsed correctly. The space or the newline between the two
arguments of \frac should have no effect, but they get parsed as
\begin_inset Formula \[
\frac{3}{}{2}\]
\end_inset
The same occours with
\begin_inset Formula \[
\sqrt[3] {2}\]
\end_inset
and
\begin_inset Formula \[
\sqrt[3]
{2}\]
\end_inset
but not with
\begin_inset Formula \[
\sqrt {3}\]
\end_inset
or
\begin_inset Formula \[
\sqrt
{3}\]
\end_inset
so it seems to be a problem with latex functions with two arguments. Can
someone work on this problem or should I repost this when André is back?
Regards,
João.
LyX 1.2.0 and CJK
Thank you very much for providing me with a superior text editor. I use it a lot and my wife even wrote her 45 page presentation to be accepted as diabetes nurse. As she is Korean (and also teaches Korean for children here) I need to provide a possibility for her to write everything under our Debian GNU/Linus system in order to get rid of our Mac. I tried to use LyX-CJK (1.1.6fix4) and it works for article, but not DocBook/LinuxDoc documents. But these are precisely the classes I would like to use to write a Korean HowTo. As I vaguely remember there were plans to merge CJK-LyX into the main version 1.2.0. So I downloaded the 1.2.0cvs, compiled it, but it did not display any korean characters at all and says on the console Received unhandled X11 event Type: 0x21Target: 0x280009d each time I try to switch the Ami (X Input Method) into korean. Two question: - Are your planning to integrate CJK-LYX? When? - Can I help to fix the SGML problem with CJK-LYX ? Thank you in advance. Regards -- Niklaus Giger Wieshoschet 6 CH-8753 Mollis [EMAIL PROTECTED] Tel. G: +41 55 618 64 68, P: +41 55 612 20 54
Re: BadWindows
Hi, yet another confirmation. Yesterday I received a BadWindow console message (after yet another Received unhandled X11 event message) when closing the preferences dialog. My LyX runs on SuSE Linux 7.3, gcc-2.95.3 and xforms 0.89.6. These X window bugs happen now and then in different dialogs and valgrind dies without a comment. Personally, I think both unhandled X11 events and BadWindow errors appeared first about 2 months ago. John, you said it is an xforms bug. Could it be that someone removed a workaround in LyX? (Just an idea...) Michael
Re: LyX 1.2.0 and CJK
On Wed, Feb 20, 2002 at 09:44:58PM +0100, Niklaus Giger wrote: As I vaguely remember there were plans to merge CJK-LyX into the main version 1.2.0. So I downloaded the 1.2.0cvs, compiled it, but it did not display any korean characters at all and says on the console Received unhandled X11 event Type: 0x21Target: 0x280009d each time I try to switch the Ami (X Input Method) into korean. Two question: - Are your planning to integrate CJK-LYX? Yes. When? I don't know.
Re: [Devel] Re: Fix? (Re: layout.diff (layout as string))
Lars Gullik Bjønnes wrote: | What happens if the result is stored in yet another reference and the | function is invoked several times? - Nasty problems! | const string ref1 = foo1.name(); | const string ref2 = foo1.name(); | if ( ref1 == ref2 ) /* ref1 == ref2!!! */ I see... No, not a real problem. the reference is to the static string, not to the allocated memory inside the static string. Well, there is no memory access problem but is the programmer aware that ref1 changes if the method is called another time? Sometimes, you don't even notice that the method in called in between. Michael
Re: bug with longtable
Juergen Vigna wrote:
if you have a mix of longtable with and without captions, than write after every
longtable:
\addtocounter{table}{-1}
I don't understand this one. What happens if you don't have a caption does
it increase the counter anyway? Could we have this as a rule and put it always
after a longtable or is there some drawback?
you need this only for longtables without a caption.
Herbert
--
http://www.lyx.org/help/
Bugreport: crash after copying figure
Hi My installation of lyx-1.1.6-fix4 crashes after copying a figure from one document to another. This is what I do that leads to the crash 1. Start lyx and getting a new document 2. Open an existing document in the same catalog 3. Marking a figure in the old document and copying it with C-c 4. Going back to the new document and pasts it with C-v 5. Clicking at the pasted figure (it renders fine in the document) and click at the Full screen preview. Result: a crash with the information: Executing command: gv 'plasticBrittleExample.ps' lyx: SIGSEGV signal caught Sorry, you have found a bug in LyX. If possible, please read 'Known bugs' under the Help menu and then send us a full bug report. Thanks! lyx: Attempting to save document newfile1.lyx as... /home/ingvast/newfile1.lyx.emergency Save seems successful. Phew. Bye. Abort There is no problem with previewing from the old document. I run RH7.2 kernel 2.4.9-21. gs version 7.00 gv version gv 3.5.8 /johan -- Johan Ingvast, PhD student http://www.md.kth.se/~ingvast/mypage.shtml Department of Machine Design, Royal Institute of Technology, Sweden http://www.md.kth.se, http://www.md.kth.se/~cas --- Walking robot proj tel +46 (0)8 790 95 36 mob. +46 (0)70 34 34 498
New bug list
Hello,
I have set up a new bug list.
Except for the nasty X Window problems, things have become much better.
I haven't checked the status of undo/redo this time. According to
bugzilla, half of all show stoppers are related to these operations. I
will have a look at them occasionally. But thanks to valgrind everybody
can become a beta tester nowadays :-)
Go on with your excellent work!
Michael
@STRING{ ITU-T = {ITU-T, International Telecommunication Union ---
Telecommunication Standardization Sector} }
@Misc{ASN.1:1997,
author = ITU-T,
title ={{R}ecommendation {X.680} (12/97) --- {A}bstract
{S}yntax {N}otation {O}ne (ASN.1): {S}pecification
of {B}asic {N}otation},
howpublished = {{ITU}, {G}eneva},
month =dec,
year = 1997
}
% Net unfolding; finite complex prefixes:
% See WWW page of Esparza, Melzer, Romer, Vogler, Wallner
LyX 1.2.0cvs - Bug list
Please help me to keep this list up to date.
Report new or fixed bugs *directly* to '[EMAIL PROTECTED]'
***
Checked last time on 2002/02/20:
- On SPARC Solaris: LyX cannot be invoked via a symlink unless you are
either in the directory in which the symlink is placed or you are root.
In all other cases:
Initializing LyXGUI...
Initializing LyXGUI...done
Initializing LyX::init...
Name of binary: lyx-1.2.0cvs
Path of binary: /home/neukirchen/local/bin/
binary is a link
Abort
- faulty.bib is not parsed correctly and causes a problem (console message) when
choosing a different natbib style for entry ASN.1:1997
- Insert an External inset (Chess) without actually specifying anything the
dialog (close immediately); then select the inset and cut it
==13866== Use of uninitialised CPU condition code
==13866==at 0x814426C: InsetExternal::doSubstitution(Buffer const *, lyxstring
const ) const (insetexternal.C:238)
==13866==by 0x81447ED: InsetExternal::updateExternal(lyxstring const , Buffer
const *) const (insetexternal.C:290)
==13866==by 0x8143CD1: InsetExternal::write(lyxstring const , Buffer const *,
ostream ) const (insetexternal.C:149)
==13866==by 0x8143DC3: InsetExternal::ascii(Buffer const *, ostream , int)
const (insetexternal.C:164)
- When I change the text of an existing label in a float, there's still the old name
on the canvas (#243)
- Miscellaneous X problems (I am glad that finally others notice them as well):
BadDrawable (invalid Pixmap or Window parameter) (when changing LyX window size,
when closing preferences dialog)
Received unhandled X11 event Type: 0x7Target: 0x20001e8 (when closing the
graphics dialog)
- Please add the following two converters to complete Tgif support
Tgif - EPS:tgif -print -eps $$i
Tgif - PDF:tgif -print -pdf $$i
When starting with a tgif file, pdflatex produces bad output; starting with an
eps file (generated by tgif), pdflatex output looks OK; why? which converters
are actually invoked? Are bitmap formats involved?
- Create note/ERT/some_inset; paste some text inside the inset with the middle mouse
button
(text is selected; OK); press return; cursor moves to next line but - text is still
selected!
- If the LyX window size changes, the red boxes of insets are updated but the line
breaks
of text inside any inset are not updated (#234)
- The measures t%, c%, p%, and l% are not easy to interpret (even for
an old LaTeX user); couldn't we afford a longer description (e.g. column%) in the
minipage and graphics dialog? (and maybe some other dialogs that I forgot)
- New buffer; create ERT with a few pars; (add a few pars after the ERT if you
like - doesn't matter); switch to inlined view; switch back to
open status - only one par anymore!
- Create new article (koma-script) document; insert a minipage; add three pars of
text
into the minipage; set the second par to minisec layout; set document to SGML
article;
remove all error boxes - the error box is deleted logically but not on screen (#210)
- If paragraph separation is set to indentation in the document layout,
the paragraphs within a fixed width cell are indented, too. Looks
reasonable at first glance but LaTeX does not consider this indentation.
Is there a simple way to ignore indentation within table cells? (#208)
- Insert a figure float into an empty document; insert a _large_ table
( screen size) into the figure float; add some text right after the
table (in a separate par); select the text - it is not highlighted! (#127)
- Select a set of cells in a table where the selection covers a cell with a long text;
press a key when the cursor is in an non-empty cell below which text is not as long
- the blue
background of the former selection is not cleared (#213)
- PageUp does not work well in a
Re: [GRAPHICS PATCH]: Call for testers
On Wed, Feb 20, 2002 at 08:47:18PM +0100, Lars Gullik Bjønnes wrote: Have you tried the patch that I sent? I think this one passed me by ... regards john -- They eat cold meat for breakfast and make jokes about gzip. - Rik Hemsley on KDE developers
Re: [Devel] Re: BadWindows
On Wed, Feb 20, 2002 at 09:54:00PM +0100, Michael Schmitt wrote: Personally, I think both unhandled X11 events and BadWindow errors appeared first about 2 months ago. the unhandled events have probably /always/ been there. What got added was extra debug code. Whilst they're probably not a major problem, they're not good either. John, you said it is an xforms bug. Could it be that someone removed a workaround in LyX? (Just an idea...) it is a possibility but I can't think what offhand. It's also possible that we have just happened to start hitting the problem by accident. regards john -- They eat cold meat for breakfast and make jokes about gzip. - Rik Hemsley on KDE developers
Graphics: Grace/user files not loaded with latest CVS
Hi, As of my download today (Feb 21), Grace files don't load anymore, though I have defined the conversion in Preferences as user, which we have discussed on this mailing list before. The message in the terminal is: try to convert image file: /home/lahaye/paper/figures/cid_cia.agr GetExtension: agr GetExtFromContents: agr ERROR: Do not know how to convert image. from: agr - With yesterday's CVS, this was still working; so it's a very recent problem. Regards, Rob.
Re: [GRAPHICS PATCH]: Call for testers
On Wed, Feb 20, 2002 at 05:10:15PM +, Angus Leeming wrote: http://www.devel.lyx.org/~leeming/graphics.diff.bz2 OK lars from a make distclean of the latest CVS I still get build problems with this patch. I don't know what more I can do - can you try the patch ? john -- They eat cold meat for breakfast and make jokes about gzip. - Rik Hemsley on KDE developers
Math parsing diff (math_parser.diff).
Hello.
On Wed, 20 Feb 2002, Joao Luis Meloni Assirati wrote:
\begin_inset Formula \[
\frac{3} {2}\]
\end_inset
\begin_inset Formula \[
\frac{3}
{2}\]
\end_inset
are not parsed correctly. The space or the newline between the two
arguments of \frac should have no effect, but they get parsed as
\begin_inset Formula \[
\frac{3}{}{2}\]
\end_inset
This tiny patch fixes the problem.
--- cvs/lyx-devel/src/mathed/math_parser.C Sun Feb 17 19:48:14 2002
+++ work/lyx/src/mathed/math_parser.C Wed Feb 20 23:06:12 2002
@@ -890,6 +890,7 @@ bool Parser::parse_normal(MathAtom mat
void Parser::parse_into(MathArray array, unsigned flags, MathTextCodes code)
{
+ skipSpaces();
parse_into1(array, flags, code);
// remove 'unnecessary' braces:
if (array.size() == 1 array.back()-asBraceInset()) {
Regards,
João.
--- cvs/lyx-devel/src/mathed/math_parser.C Sun Feb 17 19:48:14 2002
+++ work/lyx/src/mathed/math_parser.C Wed Feb 20 23:06:12 2002
@@ -890,6 +890,7 @@ bool Parser::parse_normal(MathAtom mat
void Parser::parse_into(MathArray array, unsigned flags, MathTextCodes code)
{
+ skipSpaces();
parse_into1(array, flags, code);
// remove 'unnecessary' braces:
if (array.size() == 1 array.back()-asBraceInset()) {
Re: [GRAPHICS PATCH]: Call for testers
On Wed, 20 Feb 2002, Angus Leeming wrote: The zipped file is 33kB in size, so I've shoved it here http://www.devel.lyx.org/~leeming/graphics.diff.bz2 Please try it out. I propose committing this to cvs but testing never hurts! Can't we just put this in a BRANCH and work on that instead? We have tool, so let's use it. Allan. (ARRae)
Re: Graphics: Grace/user files not loaded with latest CVS
Garst R. Reese wrote: Could you be just a tad more explicit about as Grace requires :) is it still: xmgrace -hardcopy -hdevice EPS $$i ? Yes. I have removed that user thing in Preferences all together (see earlier thread on the Grace issue) and replaced that by Formats: Format: agr GUI name: Grace Extension: agr Converters: From: Grace To: EPS Converter: xmgrace -hardcopy -hdevice EPS $$i All non-mentioned fields I left blank. Be sure xmgrace is in your path :) was my problem earlier! I hope that helps. Rob.
Re: New bug list
On Thu, Feb 21, 2002 at 12:14:13AM +0100, Michael Schmitt wrote: Wow your list is getting pretty short ! solaris symlink problem odd - faulty.bib is not parsed correctly and causes a problem (console message) when choosing a different natbib style for entry ASN.1:1997 added to bug #109 - Insert an External inset (Chess) without actually specifying anything the dialog (close immediately); then select the inset and cut it ==13866== Use of uninitialised CPU condition code ==13866==at 0x814426C: InsetExternal::doSubstitution(Buffer const *, lyxstring const ) const (insetexternal.C:238) ==13866==by 0x81447ED: InsetExternal::updateExternal(lyxstring const , Buffer const *) const (insetexternal.C:290) ==13866==by 0x8143CD1: InsetExternal::write(lyxstring const , Buffer const *, ostream ) const (insetexternal.C:149) ==13866==by 0x8143DC3: InsetExternal::ascii(Buffer const *, ostream , int) const (insetexternal.C:164) this looks to me like we need to set buffer-niceFile in buffer c-tor. Anyone yes ? Of course this raises the question of why/if the insetexternal should be looking there then ! - Miscellaneous X problems (I am glad that finally others notice them as well): BadDrawable (invalid Pixmap or Window parameter) (when changing LyX window size, when closing preferences dialog) Received unhandled X11 event Type: 0x7Target: 0x20001e8 (when closing the graphics dialog) bug #245 the BadDrawable I haven't seen yet - any ideas on what to try ? - Create note/ERT/some_inset; paste some text inside the inset with the middle mouse button (text is selected; OK); press return; cursor moves to next line but - text is still selected! Not for me ! I've found a problem doing this though that is different, which is bug #250 - New buffer; create ERT with a few pars; (add a few pars after the ERT if you like - doesn't matter); switch to inlined view; switch back to open status - only one par anymore! ouch ! bug #251 - When changing some font property for a set of table cells, the cell selection is revoked. (#217) this partially works (i.e. from dialog) - Juergen fixed this bit. - While playing with an include inset (e.g. testing files with invalid name), I got the following console message: OkCancelReadOnlyPolicy: No transition for input 2 from state 0 can't reproduce this ! (I did fix the bad english in the error box though ;) regards john -- Oh dear, more knobs. - David Chase
Re: LyX 1.2.0 and CJK
On Wed, 20 Feb 2002, Niklaus Giger wrote: Thank you very much for providing me with a superior text editor. I use it a lot and my wife even wrote her 45 page presentation to be accepted as diabetes nurse. As she is Korean (and also teaches Korean for children here) I need to provide a possibility for her to write everything under our Debian GNU/Linus system in order to get rid of our Mac. I tried to use LyX-CJK (1.1.6fix4) and it works for article, but not DocBook/LinuxDoc documents. But these are precisely the classes I would like to use to write a Korean HowTo. As I vaguely remember there were plans to merge CJK-LyX into the main version 1.2.0. So I downloaded the 1.2.0cvs, compiled it, but it did not display any korean characters at all and says on the console Received unhandled X11 event Type: 0x21Target: 0x280009d each time I try to switch the Ami (X Input Method) into korean. This bug is my fault. I do not use LinuxDoc and the bug apparently has escaped my attention. I'll try to fix the bug and as soon as it is done, I'll let you know. Two question: - Are your planning to integrate CJK-LYX? When? - Can I help to fix the SGML problem with CJK-LYX ? Thank you in advance. Regards -- Niklaus Giger Wieshoschet 6 CH-8753 Mollis [EMAIL PROTECTED] Tel. G: +41 55 618 64 68, P: +41 55 612 20 54 regards, cghan
A bug in DocBook class?
Hello,
When I try to view a lyx file with DocBook article class, which also
contains tex style files in the Layout-LaTeX Preamble, it gives me, while
executing db2dvi, the error,
character \ not allowed in declaration subset'.
Is this a bug, or am I doing something wrong here ?
The exported sgml file is the following:
!doctype article public -//OASIS//DTD DocBook V3.1//EN
[ \usepackage{revtex}
]
article lang=en
!-- DocBook file was created by LyX 1.1
See http://www.lyx.org/ for more information --
para
blah blah
/para
/article
--cghan
Remarks about graphics in lyx1.2.0cvs
Hello lyx developpers, I'm compiling oftently the 1.2 cvs release of lyx on my sparcstation 5 under linux debian sparc 2.2r3 All compile fines, but there is a small strange things about recompiling after a cvs update, the ./configure tells me that xxx is not a standard libtool... In fact a new cvs checkout or a make clean solves the problem, but i waste a lot of time recompiling things which don't need to be recompiled. Is there a solution? in fact i made a cvs update, and just a make this morning, all seems to be fine... great!!! The second thing concerns the graphics in lyx. Ok the work made to render eps files in lyx is amazing, but i encounter errors using this on mys small sparc station with 256 colors (and less)... in fact when lyx can't allocate color to a it says i can't read and doesn't display the graphics. The problem is solve if i use lyx (on the sparc) from a pc (with a lot of colors 32bits) via an X Client. But it isn't a solution for me. The solution is perhaps to view my graphics in BlackWhite or grayscale... Finally, the conversion from eps to xpm is incredibly long, there was no problem with the 1.1.6 release, the graphics were less smart but the file loaded quickly... Is there some solutions for that. And the last question, where are hidden the conversion command line (not in the GUI but in the prefs files), because on a linux box (p200mmx debian linux 2.2r3), lyx cvs doesn't want to convert the eps, in fact it answers me that he doesn't know how to convert??? Did i forget something in the install I would all thank you for the grat work you make around this software. I use it since the 1.0.3 release and its a great program, and for me, fully fonctionning since the 1.1.3 release The -- No more blah, blah, blah! -- Kirk, Miri, stardate 2713.6 --- ( Yann MORERE ICQ=#97130491 mailto:[EMAIL PROTECTED] ) ( Tel.: 33 (0)3 87 54 70 87 Fax.: 33 (0)3 87 31 53 33) ( Maitre de Conférences http://ymorere.multimania.com/ )
bug with longtable
hi,
when using the option longtable for a table (inside a table float) the
numbering of tables is multiplied by two, such that it goes table 2, table 4,
table 6,... instead of 1,2,3,...
the reason may be that the tex output says
\begin{table}
\begin{longtable}
...
\end{longtable}
\caption{}
\end{table}
but not
\begin{longtable}
...
\caption{}
\end{longtable}
as it should imho.
happened with lyx 1.1.6fix4 from jan 11 2002.
thanks for your great work! knue
Re: bug with longtable
On Wed, Feb 20, 2002 at 09:48:55AM +0100, Andreas Knüpfer wrote: > hi, > > when using the option longtable for a table (inside a table float) the > numbering of tables is multiplied by two, such that it goes table 2, table 4, > table 6,... instead of 1,2,3,... A longtable should not be used inside a float!
Re: bug with longtable
On Wed, 20 Feb 2002, Andreas [iso-8859-1] Knüpfer wrote:
> when using the option longtable for a table (inside a table float) the
> numbering of tables is multiplied by two, such that it goes table 2, table 4,
> table 6,... instead of 1,2,3,...
>
> the reason may be that the tex output says
>
> \begin{table}
> \begin{longtable}
> ...
> \end{longtable}
> \caption{}
> \end{table}
>
> but not
>
> \begin{longtable}
> ...
> \caption{}
> \end{longtable}
>
> as it should imho.
http://www.lyx.org/help/table/longtable.php#caption
Herbert
Re: bug with longtable
On 20-Feb-2002 Herbert Voss wrote:
> http://www.lyx.org/help/table/longtable.php#caption
Nice! You'll have a type in there
> \myFoothote{...blah...}
> \myFoothote{...blah...}
> caption and counting
> Longtable uses the same counter than tabular. Therefore counting of tables is wrong
>if
> you use a longtable without a caption. In this case write in preamble:
>
> \let\myEnd\endlongtable
> \renewcommand\endlongtable{\myEnd\addtocounter{table}{-1}}
>
> if you have a mix of longtable with and without captions, than write after every
> longtable:
>
> \addtocounter{table}{-1}
I don't understand this one. What happens if you don't have a caption does
it increase the counter anyway? Could we have this as a rule and put it always
after a longtable or is there some drawback?
Jürgen
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39100 Bozen Web: http://www.sad.it/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Office Automation:
The use of computers to improve efficiency in the office
by removing anyone you would want to talk with over coffee.
Re: CVS Update: lyx-devel
On Tuesday 19 February 2002 8:45 pm, [EMAIL PROTECTED] wrote: > CVSROOT: /usr/local/lyx/cvsroot > Module name: lyx-devel > Repository: lyx-devel/src/frontends/ > Changes by: [EMAIL PROTECTED] 02/02/19 20:45:53 > > Modified files: > lyx-devel/src/frontends/: Makefile.am > > Log message: > better dep tracking I take it there was something wrong after all? Anyway, things still aren't right. Try changing something in the xforms directory. The file is remade, the lib is remade, but thereafter neither the frontends lib not lyx itself are linked in. Regards, Angus Making all in xforms make[4]: Entering directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/src/frontends/xforms' deccxx -DHAVE_CONFIG_H -I. -I. -I../../../src -I../../../images -I../../../src/-I../../../src/frontends/ -I../../../src/frontends/controllers-I../../.. -I../../.. -I../../../boost -I../../../src/cheaders -I/usr/local/include -msg_display_number -msg_disable 11,193,236,261,401,611 -w0 -ptr /usr/users/aleem/OTHERS_CODE/lyx/devel/lyx_cxx_repository -O2 -c FormForks.C cxx -std strict_ansi -nocleanup -DHAVE_CONFIG_H -I. -I. -I../../../src -I../../../images -I../../../src/ -I../../../src/frontends/ -I../../../src/frontends/controllers -I../../.. -I../../.. -I../../../boost -I../../../src/cheaders -I/usr/local/include -msg_display_number -msg_disable 11,193,236,261,401,611 -w0 -ptr /usr/users/aleem/OTHERS_CODE/lyx/devel/lyx_cxx_repository -O2 -MD -c FormForks.C cxx: Warning: /usr/include/cxx/algorithm.cc, line 110: #1115-D external routine uses unnamed type or namespace. InputIterator find_if (InputIterator first, InputIterator last, Predicate pred) --^ rm -f ../libxforms.objects.new for fil in Alert_pimpl.o bmtable.o Color.o combox.o Dialogs.o DropDown.o FileDialog.o FormFiledialog.o form_filedialog.o GUIRunTime.o FormAboutlyx.o form_aboutlyx.o FormBase.o FormBaseDeprecated.o FormBibitem.o form_bibitem.o FormBibtex.o form_bibtex.o FormBrowser.o form_browser.o FormCharacter.o form_character.o FormCitation.o form_citation.o FormDocument.o form_document.o FormError.o form_error.o FormERT.o form_ert.o FormExternal.o form_external.o FormFloat.o form_float.o FormForks.o form_forks.o FormGraphics.o form_graphics.o FormInclude.o form_include.o FormIndex.o form_index.o FormInset.o FormLog.o FormMathsBitmap.o FormMathsDeco.o form_maths_deco.o FormMathsDelim.o form_maths_delim.o FormMathsMatrix.o form_maths_matrix.o FormMathsPanel.o form_maths_panel.o FormMathsSpace.o form_maths_space.o FormMathsStyle.o form_maths_style.o FormMinipage.o form_minipage.o FormParagraph.o form_paragraph.o FormPreamble.o form_preamble.o FormPreferences.o form_preferences.o FormPrint.o form_print.o FormRef.o form_ref.o FormSearch.o form_search.o FormShowFile.o FormSpellchecker.o form_spellchecker.o FormTabular.o form_tabular.o FormTabularCreate.o form_tabular_create.o FormTexinfo.o form_texinfo.o FormThesaurus.o form_thesaurus.o FormToc.o form_toc.o FormUrl.o form_url.o FormVCLog.o input_validators.o MathsSymbols.o Menubar_pimpl.o RadioButtonGroup.o Timeout_pimpl.o Toolbar_pimpl.o Tooltips.o xforms_helpers.o xformsBC.o ; do \ echo xforms/$fil >> ../libxforms.objects.new ; \ done if [ -f ../libxforms.objects ] ; then \ cmp -s ../libxforms.objects ../libxforms.objects.new || mv ../libxforms.objects.new ../libxforms.objects ; \ else \ mv ../libxforms.objects.new ../libxforms.objects ; \ fi make[4]: Leaving directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/src/frontends/xforms' make[4]: Entering directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/src/frontends' make[4]: Nothing to be done for `all-am'. make[4]: Leaving directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/src/frontends' make[3]: Leaving directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/src/frontends' make[3]: Entering directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/src' make[3]: Nothing to be done for `all-am'. make[3]: Leaving directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/src' make[2]: Leaving directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/src' make[1]: Leaving directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/src' Making all in lib make[1]: Entering directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/lib' Making all in reLyX make[2]: Entering directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/lib/reLyX' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/lib/reLyX' make[2]: Entering directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/lib' make[2]: Nothing to be done for `all-am'. make[2]: Leaving directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/lib' make[1]: Leaving directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/lib' make[1]: Entering directory `/usr/users/aleem/OTHERS_CODE/lyx/devel' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/usr/users/aleem/OTHERS_CODE/lyx/devel' aleem@pneumon:devel->
syscall.[Ch] ???
Why are the two files in the repository but not used? Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Abraham Lincoln didn't die in vain. He died in Washington, D.C.
Re: layout.diff (layout as string)
On Tue, Feb 19, 2002 at 08:43:58PM +0100, Lars Gullik Bjønnes wrote: > [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: > > | And it still crashes, but should be better... > | I know there is some small stupid thing in there somewhere, but cannot > | see it. I'd be really grateful if someone else coule have a look at > | this (not cleaned up) patch, and perhaps try it too. Hopefully that > | should flush out the remaining (small) problems. > > All the above still applies. > This patch also handles some of J-M's concerns. Still not cleaned up. > > Please help find the stupid problem. First-off, I see that it trips over the first starred layout (Part*) that it encounters. The non-starred ones before that are processed OK. The search continues :-) Martin msg33238/pgp0.pgp Description: PGP signature
Forked call question
I have asynchronous conversion of graphics files to a loadable format working
here beautifully. They don't display, because I don't explicitly tell LyX
that they've loaded (that ol' dispatch question). I have to enter something
on the paragraph to force a redraw. Anyway, that's not the main point of this
mail. This is:
I find that the conversion process works about 50% of the time. The rest of
the time, the forked call controller thinks that the child dies and I get the
message: "LyX: Error waiting for child: No child processes". the relevant
code is:
void ForkedcallsController::timer()
{
ListType::size_type start_size = forkedCalls.size();
for (ListType::iterator it = forkedCalls.begin();
it != forkedCalls.end(); ++it) {
Forkedcall * actCall = *it;
pid_t pid = actCall->pid();
int stat_loc;
int const waitrpid = waitpid(pid, _loc, WNOHANG);
bool remove_it = false;
if (waitrpid == -1) {
lyxerr << "LyX: Error waiting for child: "
<< strerror(errno) << endl;
// Child died, so pretend it returned 1
actCall->setRetValue(1);
remove_it = true;
}
}
}
Is there a knowledgeable person out there who can tell me what I'm doing
wrong? Is it just that I'm not polling the process often enough? (The timer
is currently set to 500ms.) Or is this symptomatic of something more serious?
Angus
Re: syscall.[Ch] ???
On Wednesday 20 February 2002 10:42 am, Juergen Vigna wrote: > Why are the two files in the repository but not used? I think that they are removed from the repository. I replaced them with systemcall.[Ch]. Angus
Re: syscall.[Ch] ???
On 20-Feb-2002 Angus Leeming wrote: > On Wednesday 20 February 2002 10:42 am, Juergen Vigna wrote: >> Why are the two files in the repository but not used? > > I think that they are removed from the repository. I replaced them with > systemcall.[Ch]. Seems you're right. Maybe there was a "C"lash before in that file and so the cvs update didn't remove it. I removed it by hand and now cvs update did tell me that it isn't pertinent anymore. Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ You don't become a failure until you're satisfied with being one.
Re: Forked call question
On Wed, Feb 20, 2002 at 10:48:07AM +, Angus Leeming wrote: > I find that the conversion process works about 50% of the time. The rest of > the time, the forked call controller thinks that the child dies and I get the > message: "LyX: Error waiting for child: No child processes". the relevant > code is: what happens if you waitpid(-1, ...) ? regards john -- "They eat cold meat for breakfast and make jokes about gzip." - Rik Hemsley on KDE developers
Re: ERT patch
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes: Juergen> For all of you who didn't look at it in short it does leave Juergen> the Paragraph (Character) Params unchanged when copiing them Juergen> inside an ERT and ONLY the display is changed. This is done Juergen> by calling a function which changes the Font of the chars Juergen> when they are drawed on screen. Juergen> Anyway all of you should already have had a look at the patch Juergen> and tried it out. So if I don't get any serious complaints I Juergen> will commit my tree soon! I did not have time to actually try it out, but as I said in bug 143, you should really rename getFontSettings to something else because it does not have the same semantics as the other getFontSettings. What about adaptFont or filterFont? And what is this HARD_FONTS thing? Could you clean it up before commiting? As it stands the code is a bit difficult to follow. JMarc
Re: ERT patch
On Wed, Feb 20, 2002 at 11:51:33AM +0100, Juergen Vigna wrote: > Anyway all of you should already have had a look at the patch and tried it > out. So if I don't get any serious complaints I will commit my tree soon! see jmarc's comments on bugzilla ! also there is another patch of yours on bugzilla that you need to apply I suppose regards john -- "They eat cold meat for breakfast and make jokes about gzip." - Rik Hemsley on KDE developers
Re: ERT patch
On 20-Feb-2002 Jean-Marc Lasgouttes wrote: > I did not have time to actually try it out, but as I said in bug 143, > you should really rename getFontSettings to something else because it > does not have the same semantics as the other getFontSettings. What > about adaptFont or filterFont? getDrawFont() ? > And what is this HARD_FONTS thing? Could you clean it up before > commiting? As it stands the code is a bit difficult to follow. Well I just didn't want to remove code I would need afterwards and I had to have a look in which places I needed the font changes. But all the code inside a #ifdef HARD_FONTS can be removed as soon as we're sure the thing works as wanted. Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Without followers, evil cannot spread. -- Spock, "And The Children Shall Lead", stardate 5029.5
Re: ERT patch
On 20-Feb-2002 John Levon wrote: > also there is another patch of yours on bugzilla that you need to > apply I suppose Did you see my recent commit ;) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ The ripest fruit falls first. -- William Shakespeare, "Richard II"
Re: layout.diff (layout as string)
On Wed, Feb 20, 2002 at 11:54:04AM +0100, Lars Gullik Bjønnes wrote:
> Martin Vermeer <[EMAIL PROTECTED]> writes:
...
> >>
> >> Please help find the stupid problem.
> >
> | First-off, I see that it trips over the first starred layout (Part*) that
> | it encounters. The non-starred ones before that are processed OK.
>
> the question is if this is because of the '*' or something else...
>
> --
> Lgb
Think I got it (famous last words :-), or at least part of the problem.
When compiling lyxlayout, I get
lyxlayout.C: In method `const class string & LyXLayout::name() const':
lyxlayout.C:740: warning: returning reference to temporary
lyxlayout.C: In method `const class string & LyXLayout::obsoleted_by() const':
lyxlayout.C:752: warning: returning reference to temporary
Perhaps we should heed these warnings.
I believe that in lyxtextclass.C on line 268 below, lay.name()
returns "pølse", the content of a pointer to an evaporated temp.
257 case TC_STYLE:
258 if (lexrc.next()) {
259 string const name = subst(lowercase(lexrc.getString()),
260 '_', ' ');
261 if (hasLayout(name)) {
262 LyXLayout & lay = GetLayout(name);
263 error = do_readStyle(lexrc, lay);
264 } else {
265 LyXLayout lay;
266 lyxerr << "Name before:" << name << endl;
267 lay.setName(name);
268 lyxerr << "lay.name() after:" << lay.name() << endl;
269 if (!(error = do_readStyle(lexrc, lay))) {
270 layoutlist.push_back(lay);
271 }
272 }
How to fix it is another story...
Martin
msg33248/pgp0.pgp
Description: PGP signature
Re: ERT patch
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes: Juergen> On 20-Feb-2002 Jean-Marc Lasgouttes wrote: >> I did not have time to actually try it out, but as I said in bug >> 143, you should really rename getFontSettings to something else >> because it does not have the same semantics as the other >> getFontSettings. What about adaptFont or filterFont? Juergen> getDrawFont() ? I can live with that. The most important is that the name is not getFontSettings. We used to have a convertFont doing exactly what you need BTW. >> And what is this HARD_FONTS thing? Could you clean it up before >> commiting? As it stands the code is a bit difficult to follow. Juergen> Well I just didn't want to remove code I would need Juergen> afterwards and I had to have a look in which places I needed Juergen> the font changes. But all the code inside a #ifdef HARD_FONTS Juergen> can be removed as soon as we're sure the thing works as Juergen> wanted. OK. JMarc
Re: CVS Update: lyx-devel
On Wednesday 20 February 2002 11:25 am, Lars Gullik Bjønnes wrote: > | On Tuesday 19 February 2002 8:45 pm, [EMAIL PROTECTED] wrote: > >> CVSROOT: /usr/local/lyx/cvsroot > >> Module name: lyx-devel > >> Repository:lyx-devel/src/frontends/ > >> Changes by:[EMAIL PROTECTED] 02/02/19 20:45:53 > >> > >> Modified files: > >>lyx-devel/src/frontends/: Makefile.am > >> > >> Log message: > >>better dep tracking > > > | I take it there was something wrong after all? > > > | Anyway, things still aren't right. Try changing something in the xforms > | directory. The file is remade, the lib is remade, but thereafter neither the > | frontends lib not lyx itself are linked in. > > Can you try this patch? > You have to be in src/frontends when patching So you're basically reverting the changes you made to Makefile.ams in the frontends? Yes, this appears to work. Angus
Re: CVS Update: lyx-devel
On Wednesday 20 February 2002 12:18 pm, Lars Gullik Bjønnes wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > > | On Wednesday 20 February 2002 11:25 am, Lars Gullik Bjønnes wrote: > >> | On Tuesday 19 February 2002 8:45 pm, [EMAIL PROTECTED] wrote: > >> >> CVSROOT:/usr/local/lyx/cvsroot > >> >> Module name:lyx-devel > >> >> Repository: lyx-devel/src/frontends/ > >> >> Changes by: [EMAIL PROTECTED] 02/02/19 20:45:53 > >> >> > >> >> Modified files: > >> >> lyx-devel/src/frontends/: Makefile.am > >> >> > >> >> Log message: > >> >> better dep tracking > >> > > >> | I take it there was something wrong after all? > >> > > >> | Anyway, things still aren't right. Try changing something in the xforms > >> | directory. The file is remade, the lib is remade, but thereafter neither > | the > >> | frontends lib not lyx itself are linked in. > >> > >> Can you try this patch? > >> You have to be in src/frontends when patching > > > | So you're basically reverting the changes you made to Makefile.ams in the > | frontends? > > No, not quite. Simplifying is a better word. > > | Yes, this appears to work. > > also the dependency tracking? Seems to. I'll keep an eye out for things going wrong. Needless to say, you're a b-tard for making me rebuild practically the whole tree for the Xth time in a week! ;-) Angus
Re: ERT patch
On 20-Feb-2002 Juergen Vigna wrote: > the paragraphs should be "forced" left aligned, IMO. And also we > should disable the whole Paragraph-Layout for paragraphs inside an I've just seen that the Layout->Paragraph is disabled if I'm inside an ERT, but if I have the layout already open I'm able to apply the changes still to the paragraph inside the ERT, this is wrong IMO. And IMO the Layout->Character Menu should also be disabled. Here it is the other way round the changes I make will not be applied and I get an error message that it isn't possible, but I can open the Layout which I shouldn't IMO. BTW.: People who use a lot of ERT am I right to assume that alignment of the paragraphs inside a ERT inset should be left aligned? Or do you prefer leave it as is? Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ The meeting of two personalities is like the contact of two chemical substances: if there is any reaction, both are transformed. -- Carl Jung
string -> pointer question
When the loading status of a graphics file changes, I need to inform LyX. I
do this with:
LyXFunc::dispatch(LFUN_GRAPHICS_CHANGED_STATE, argument);
where argument is a list of insets as a space-separated string.
I split the string up and convert each substring back to a pointer with:
bool isStrPtr(string const & str)
{
return isStrUnsignedInt(str);
}
void * strToPtr(string const & str)
{
return (void *)strToUnsignedInt(str);
}
Is there a better way?
Angus
