[PATCH] More GNOME frontend cleanups

[Michael Koziarski]

Hey guys,

I've made a few changes to the structure of the gnome frontend.
Simplified the constructor, moved common functionality into the
GnomeBase class.  This patch doesn't fix the problem I've been having
with OK being called twice, I hope to have another look at that this
weekend, but it simplifies and cleans everything a bit.

The diff is attached.

The new files required are available at:
http://www.koziarski.org/new-files.tar.gz

Could someone apply it and add the new files?

Cheers


-- 

| Michael Koziarski   |Conventional wisdom is often   |
| Data Engineer, Linux user   | long on convention and short   |
|  Objectivist.  | on wisdom --  |
| http://www.koziarski.com| Warren E. Buffett, BRK.A   |

[PATCH] Really this time

[Michael Koziarski]

Managed to miss out attaching the patch.

Here it is,  the url for the new files is still 

http://www.koziarski.org/new-files.tar.gz

Cheers


-- 

| Michael Koziarski   |Conventional wisdom is often   |
| Data Engineer, Linux user   | long on convention and short   |
|  Objectivist.  | on wisdom --  |
| http://www.koziarski.com| Warren E. Buffett, BRK.A   |



new-files.tar.gz
Description: GNU Zip compressed data

Re: 10 more bugs now...

[Allan Rae]

On Tue, 15 Jan 2002, Allan Rae wrote:


 Take a look at Bugzilla #174.  I have attached an insure++ report with
 details of dangling pointers and where they were released.

I have a fix for #174 but sadly it seems that another crash can result
elsewhere.  It looks like something at a higher level may make a
similar mistake to the below.  I'll investigate that now -- may as
well use insure again and see what it says about my fix.


Index: text.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text.C,v
retrieving revision 1.224
diff -u -p -u -p -r1.224 text.C
--- text.C  2002/01/15 11:44:16 1.224
+++ text.C  2002/01/16 09:11:45
@@ -485,9 +485,12 @@ void LyXText::drawInset(DrawRowParams 
Row * prev = p.row-previous();
if (prev  prev-par() == p.row-par()) {
breakAgainOneRow(p.bv, prev);
-   }
+   // breakAgainOneRow() may have removed p.row
+   need_break_row = prev-next();
+   } else {
+   need_break_row = p.row;
+   }
setCursor(p.bv, cursor.par(), cursor.pos());
-   need_break_row = p.row;
}
 }

Allan. (ARRae)

Re: reducing compile times

[Angus Leeming]

On Wednesday 16 January 2002 7:25 am, Andre Poenitz wrote:
 On Tue, Jan 15, 2002 at 06:16:34PM +, Angus Leeming wrote:
  It works like a dream here and I can see no issues associated with this. 
Do 
  those more knowledgable than I have any problems with it? If not, I'd 
like to 
  submit the change.
 
 You are able to put templated _definitions_ in the .C and it works? 
 
 Andre', slightly astonished.

Sure, because these classes are base classes for 8 others. If, when I make 
these 8 classes I also make the template base classes, then all is fine.

Make sense?

Angus

Re: lib/examples/mathed.lyx

[Angus Leeming]

On Tuesday 15 January 2002 8:05 pm, Dekel Tsur wrote:
 On Tue, Jan 15, 2002 at 04:29:50PM +, Angus Leeming wrote:
  
  José, I've just improved mathed.lyx so that the fonts-xlfd file how 
contains 
  the right fonts. Perhaps you'd throw in a few lines about what you had to 
do 
  to get things working under redhat?
 
 I want to move the script out of mathed.lyx into a file.
 Where should I put it: lib/scripts or lib/ ?
 Also, we currently use font names like -bluesky-cmr-*
 It has suggested that we use more meaningful names: e.g.
   -bluesky-Computer Modern Roman-*
 Any thoughts on this ?

None from me. I just wanted all this documented somewhere.
Makes a lot of sense though.

Angus

Re: [PATCH] Really this time

[Michael Koziarski]

 I think you attached the new files tarball, rather than the patch.
 
 
 -- 
 Kayvan A. Sylvan  | Proud husband of   | Father to my kids:
 Sylvan Associates, Inc.   | Laura Isabella Sylvan  | Katherine Yelena (8/8/89)
 http://sylvan.com/~kayvan | crown of her husband | Robin Gregory (2/28/92)

Third time's a charm.

I blame work.



-- 

| Michael Koziarski   |Conventional wisdom is often   |
| Data Engineer, Linux user   | long on convention and short   |
|  Objectivist.  | on wisdom --  |
| http://www.koziarski.com| Warren E. Buffett, BRK.A   |



gnome.diff.gz
Description: GNU Zip compressed data

Re: reducing compile times

[Andre Poenitz]

On Wed, Jan 16, 2002 at 09:34:38AM +, Angus Leeming wrote:
  Andre', slightly astonished.
 
 Sure, because these classes are base classes for 8 others. If, when I make 
 these 8 classes I also make the template base classes, then all is fine.
 
 Make sense?

Now that I read in Lars' reply that you #include the full definition when
needed, it makes sense.

I thought your compiler was implements 'export' and uses it even without
being told so. And that would have been close to a wonder.  Of course,
splitting the templated stuff into a .h and some .t or .tmpl and including
the .tmpl only if needed is fine.

andre'

-- 
André Pönitz .. [EMAIL PROTECTED]

Re: Look Ma, no macros! (Re: Brush-up on Blackboard Bold)

[Dekel Tsur]

On Wed, Jan 16, 2002 at 08:57:32AM +0200, Martin Vermeer wrote:
  Using ps2epsi+imagemagick, you can convert directly from Postscript to a
  bitmap format with anti-aliasing, with no need for manual fix.
 
 Thanks! I'll try that.

Actually, imagemagick uses Ghostscript, and Ghostscript doesn't do a good
work at low res rendering.
A better option may be to capture the lyx screen (assuming that you use the
latex Postscript font. However, this method is not scriptable ) or to write
a C program that uses freetype in order to render the images.

  Does the xbm format support grey-scale images ?
 
 No.
 
  If not, can we use xpm ?
 
 Actually I am happy with xbm for this use... in the xforms front-end I
 think it is OK.

If you use xpm, you have a decent result from imagemagic due to anti-aliasing.
See attached files.



test.xbm
Description: X bitmap


test.xpm
Description: X pixmap

Re: Three radiobuttons on delim pop-up

[Martin Vermeer]

On Tue, Jan 15, 2002 at 04:44:11PM +0200, Martin Vermeer wrote:
 On Tue, Jan 15, 2002 at 12:56:39PM +, Angus Leeming wrote:
  
  On Tuesday 15 January 2002 9:52 am, Martin Vermeer wrote:

...
 
 Otherwise I think both patches can go into CVS as they do not touch deep
 functionality, just user interface. The only wart as I said is that you don't
 get latexed your mathbb's or mathcals without AmsMath turned on -- this may
 bite a few inexperienced users. 
 
 
 -- Martin
 
Answering to myself, the attached patch fixes this problem for me. There seemed 
to be a bug in thne auto-usepackage-include thingy, which leads to the inclusion 
of amsmath, when in fact amssymb is need for \mathbb (for \mathcal, either will do).

Before committing this, I would like to hear from whoever wrote this code originally 
(André?) that this is indeed a simple mistake or human logic bug, and won't have 
repercussions elsewhere.

Note that amssymb also allows the use of the huge number of AMS symbols listed in
the LaTeX Companion. Expect a patch at some time in the future :-)

-- Martin



Index: math_hullinset.C
===
RCS file: /cvs/lyx/lyx-devel/src/mathed/math_hullinset.C,v
retrieving revision 1.14
diff -u -p -r1.14 math_hullinset.C
--- math_hullinset.C2002/01/10 10:05:45 1.14
+++ math_hullinset.C2002/01/16 10:48:31
@@ -261,7 +261,7 @@ bool MathHullInset::numberedType() const
 void MathHullInset::validate(LaTeXFeatures  features) const
 {
if (ams())
-   features.require(amsmath);
+   features.require(amssymb);
 
 
// Validation is necessary only if not using AMS math.



msg31593/pgp0.pgp
Description: PGP signature

Request to our TeXperts!

[Juergen Vigna]

There is a problem when using multiple paragraphs inside a multicolumn cell.
Is this not permitted? Or how is the right LaTeX code to do this?
Well I investigated a bit and it seems that latex produces errors only if
we have the tabular inside a f.ex.: \textsf{tabular}. Actually the
whole stuff has nothing to do with multicolumns. This is just a problem
of the above font-family change and having multiple paragraphs inside a
tabular cell!

Have a look at: http://cvs.koziarski.com/show_bug.cgi?id=172
and download the testcase lyx-file to have a example of the bug.

Gratefull for any hint!

   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
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

That's the thing about people who think they hate computers.  What they
really hate is lousy programmers.
- Larry Niven and Jerry Pournelle in Oath of Fealty

Re: Look Ma, no macros! (Re: Brush-up on Blackboard Bold)

[Jules Bean]

On Wed, Jan 16, 2002 at 12:42:40PM +0200, Dekel Tsur wrote:
 On Wed, Jan 16, 2002 at 08:57:32AM +0200, Martin Vermeer wrote:
   Using ps2epsi+imagemagick, you can convert directly from Postscript to a
   bitmap format with anti-aliasing, with no need for manual fix.
  
  Thanks! I'll try that.
 
 Actually, imagemagick uses Ghostscript, and Ghostscript doesn't do a good
 work at low res rendering.

Even with -dTextAlphaBits=4 ?

Jules

Re: Request to our TeXperts!

[Jules Bean]

On Wed, Jan 16, 2002 at 12:19:02PM +0100, Juergen Vigna wrote:
 There is a problem when using multiple paragraphs inside a multicolumn cell.
 Is this not permitted? Or how is the right LaTeX code to do this?
 Well I investigated a bit and it seems that latex produces errors only if
 we have the tabular inside a f.ex.: \textsf{tabular}. Actually the
 whole stuff has nothing to do with multicolumns. This is just a problem
 of the above font-family change and having multiple paragraphs inside a
 tabular cell!

I don't have CVS LyX, but I'm happy to look at LaTeX.  If you email me
a minimal .tex exhibiting the bug, I'll try to fix it.

Jules

[PATCH]: reducing file dependencies in the frontends

[Angus Leeming]

The patch attached reduces file dependencies in the frontends enormously by 
moving template class declarations into three new .tmpl files and only 
including these files in the .C files of the derived classes.

Changing anything in ButtonController.h, ControlDialogs.h or ControlInset.h 
results in the recompilation of 56, 29 and 31 files, respectively! Since 
these files contained not only the class definition, but the class 
declaration also, such changes occurred relatively frequently. Now that the 
declaration of the functions has been moved into the .tmpl files, here are 
the stats:

touch frontends/controllers/ButtonController.tmpl and recompile
frontends/xforms/Dialogs.C
frontends/xforms/xformsBC.C

touch frontends/controllers/ControlDialog.tmpl and recompile
frontends/controllers/ControlDialog_impl.C

touch frontends/controllers/ControlInset.tmpl and recompile
frontends/controllers/ControlCommand.C
frontends/controllers/ControlError.C
frontends/controllers/ControlERT.C
frontends/controllers/ControlExternal.C
frontends/controllers/ControlFloat.C
frontends/controllers/ControlGraphics.C
frontends/controllers/ControlInclude.C
frontends/controllers/ControlMinipage.C

So the advantage is clear. Nonetheless, I attach the patch, rather than 
submit immediately, so that the experts can have a look first. Please do so!

Note that the changes to the gui-specific frontends code is minimal. See the 
xforms ChangeLog entry.

One small question. Should I put the three .tmpl files in 
frontends/controllers/Makefile.am?

Regards,
Angus



dependencies.diff.bz2
Description: BZip2 compressed data

Re: Request to our TeXperts!

[Juergen Vigna]

On 16-Jan-2002 Jules Bean wrote:
 On Wed, Jan 16, 2002 at 12:19:02PM +0100, Juergen Vigna wrote:
 There is a problem when using multiple paragraphs inside a multicolumn cell.
 Is this not permitted? Or how is the right LaTeX code to do this?
 Well I investigated a bit and it seems that latex produces errors only if
 we have the tabular inside a f.ex.: \textsf{tabular}. Actually the
 whole stuff has nothing to do with multicolumns. This is just a problem
 of the above font-family change and having multiple paragraphs inside a
 tabular cell!
 
 I don't have CVS LyX, but I'm happy to look at LaTeX.  If you email me
 a minimal .tex exhibiting the bug, I'll try to fix it.

Well here it is! If you remove \texttt{ before \begin{tabular} and the
} after \end{tabular} all is ok but asis it will give errors.

Thanks for your help!

   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
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Love is a grave mental disease.
-- Plato



%% LyX 1.2 created this file.  For more info, see http://www.lyx.org/.
%% Do not edit unless you really know what you are doing.
\documentclass[12pt,a4paper,german]{article}
\usepackage[T1]{fontenc}
\usepackage[latin2]{inputenc}
\setlength\parskip{\medskipamount}
\setlength\parindent{0pt}

\makeatletter

%% LyX specific LaTeX commands.
\providecommand{\LyX}{L\kern-.1667em\lower.25em\hbox{Y}\kern-.125emX\@}

\makeatother
\usepackage{babel}
\begin{document}
\texttt{\begin{tabular}{|p{6cm}|c|}
\hline 
\texttt{dfasdfasdf sdf asdf}

\texttt{sdf asdfasdf asdf}

\texttt{sdf asdfasdfasdf}
\\
\hline
\hline 

\\
\hline
\end{tabular}}
\end{document}

Re: [PATCH]: reducing file dependencies in the frontends

[Allan Rae]

Nice work.

Although just looking at the diff there seems to be a lot of this
going on:

-   ///
-   BP bp_;
+   ///
+   BP bp_;

They should just be tabs so what is changing?

I'm also glad that there aren't any _(blah blah) strings in the
.tmpl files otherwise we'd need some wacky changes to the
po/Makefile.in.in (in which case a .T extension might be better).

 One small question. Should I put the three .tmpl files in
 frontends/controllers/Makefile.am?

Like Lars said.

Allan. (ARRae)

Re: reducing compile times

[Angus Leeming]

On Wednesday 16 January 2002 3:33 am, Allan Rae wrote:
[snip my original message]
 Maybe ControlDialog_impl.[Ch] instead (like a _pimpl only different).

Nice. Done.

 Secondly, I think we should wait with this change (the other is
 probably okay) until after 1.2.0 and we've have time to discuss
 reorganizing the GUII hierarchy.  We may well do something like this
 then anyway.

Nah! I've just been trying to track down Michael Koziarski's problems with 
the gnome frontend and any change I made to ControlInset.h required the 
recompilation of vast numbers of files. Since I can't compile gnome on this 
box I didn't track down his problem (although I did find a bug!) so he's 
going to have to do the tracking himself. He's not going to be happy printing 
out things in the methods of CntrolInset if he has to recompile the entire 
frontend each time, now is he?

Anyway, the change I've made changes none of the classes at all, and 
therefore cannot break anything. If the code compiles and links, then all is 
Ok.

 Take a few minutes to draw out the GUII hierarchy (or work from
 doxygen) and you'll see it is a great big long thin vine.  It is
 possible to rearrange this into a broad flat tree -- fewer intervening
 classes needing recompiles.

Sure. I understand this.

Coping in the heat Ok?

Regards,
Angus

Re: [PATCH]: reducing file dependencies in the frontends

[Angus Leeming]

On Wednesday 16 January 2002 12:58 pm, Allan Rae wrote:
 Nice work.
 
 Although just looking at the diff there seems to be a lot of this
 going on:
 
 -   ///
 -   BP bp_;
 +   ///
 +   BP bp_;
 
 They should just be tabs so what is changing?

Well spotted. They are no longer tabs. I'll fix those.

 I'm also glad that there aren't any _(blah blah) strings in the
 .tmpl files otherwise we'd need some wacky changes to the
 po/Makefile.in.in (in which case a .T extension might be better).
 
  One small question. Should I put the three .tmpl files in
  frontends/controllers/Makefile.am?
 
 Like Lars said.

Done that.

Thanks both.
Angus

bug #174

[Allan Rae]

I've just checked in a fix.

Two fixes actually, and one of them I'd have thought we'd hit by now.

LyXText::deleteRow() forgot to check refresh_row.  I set this to:
refresh_row = row_prev ? row_prev : row-next();

since I figure there must be some reason why refresh_row was set and
it would be unlikely that we'd delete the first row of a multirow
paragraph.

Anyway the interesting part is in LyXText::drawInset() where we got
partly screwed because p.row just got deleted so I changed it to a
valid row -- what else could I do?  Should I also try to fix the p.x
and p.y values?  Seems to work without doing that.

If someone more familiar with rebreaking could take a look and decide
whether I should/could set need_break_row differently if p.row was
just removed:

if (prev  prev-par() == p.row-par()) {
breakAgainOneRow(p.bv, prev);
// breakAgainOneRow() may have removed p.row
// What about the x and y coordinates? par  pos ok.
if (prev-next() != p.row) {
p.row = prev;
}
// If there's only one row (after p.row was deleted)
// prev-next() == 0 and no breaking is required.
// Otherwise, check the new next row.
== need_break_row = prev-next();
} else {
need_break_row = p.row;
}

If p.row was deleted it must have been the last row of a paragraph so
we could set need_break_row = 0 couldn't we?  As in:

if (prev  prev-par() == p.row-par()) {
breakAgainOneRow(p.bv, prev);
// breakAgainOneRow() may have removed p.row
// What about the x and y coordinates? par  pos ok.
if (prev-next() != p.row) {
p.row = prev;
need_break_row = 0;
} else {
need_break_row = p.row;
}
} else {
need_break_row = p.row;
}

Allan. (ARRae)

Re: Look Ma, no macros! (Re: Brush-up on Blackboard Bold)

[Dekel Tsur]

On Wed, Jan 16, 2002 at 11:52:29AM +, Jules Bean wrote:
  Actually, imagemagick uses Ghostscript, and Ghostscript doesn't do a good
  work at low res rendering.
 
 Even with -dTextAlphaBits=4 ?

What is it supposed to do ?

Re: reducing compile times

[Allan Rae]

On Wed, 16 Jan 2002, Angus Leeming wrote:
[...agree with the rest...]

 Coping in the heat Ok?

Guess what!  It bucketed down rain and is now somewhat cooler.
Mind you those couple of really hot days I just hid here at uni in the
airconditioning.

Allan. (ARRae)

Re: Three radiobuttons on delim pop-up

[Dekel Tsur]

On Wed, Jan 16, 2002 at 01:09:33PM +0200, Martin Vermeer wrote:

 Index: math_hullinset.C
 ===
 RCS file: /cvs/lyx/lyx-devel/src/mathed/math_hullinset.C,v
 retrieving revision 1.14
 diff -u -p -r1.14 math_hullinset.C
 --- math_hullinset.C  2002/01/10 10:05:45 1.14
 +++ math_hullinset.C  2002/01/16 10:48:31
 @@ -261,7 +261,7 @@ bool MathHullInset::numberedType() const
  void MathHullInset::validate(LaTeXFeatures  features) const
  {
   if (ams())
 - features.require(amsmath);
 + features.require(amssymb);

No, it should be amsmath.
Enabling amssymb should be done in the ::validate methods of 
MathStringInset and MathSymbolInset (which don't exist yet).

Re: [PATCH]: reducing file dependencies in the frontends

[Andre Poenitz]

On Wed, Jan 16, 2002 at 10:58:45PM +1000, Allan Rae wrote:
 They should just be tabs so what is changing?

White space on the end of the line perhaps?

Andre'
 
-- 
André Pönitz .. [EMAIL PROTECTED]

Re: ControlInset failling Assert()

[Allan Rae]

On Tue, 15 Jan 2002, Angus Leeming wrote:
[...]
 Nonetheless, I think you've hit on a bug. Well done! Although I don't think
 it'll help solve your problem, the fix to that particular problem is:

 template class Inset, class Params
 void ControlInsetInset, Params::apply()
 {
   if (lv_.buffer()-isReadonly())
   return;

   view().apply();

 - if (inset_  params() != getParams(*inset_))
 + if (inset_)
 + if (params() != getParams(*inset_))
   applyParamsToInset();
   else
   applyParamsNoInset();

I hope you realise you just made another bug with nested else because
that will be interpreted as:

if (inset_) {
if (params() != getParams(*inset_)) {
applyParamsToInset();
} else {
applyParamsNoInset();
}
}

instead of what you really wanted:

if (inset_) {
if (params() != getParams(*inset_)) {
applyParamsToInset();
}
} else {
applyParamsNoInset();
}

Allan. (ARRae)

Re: [PATCH]: reducing file dependencies in the frontends

[Allan Rae]

On Wed, 16 Jan 2002, Andre Poenitz wrote:

 On Wed, Jan 16, 2002 at 10:58:45PM +1000, Allan Rae wrote:
  They should just be tabs so what is changing?

 White space on the end of the line perhaps?

That would show up by selecting the area with your mouse. However, tab
to space conversions usually don't show up when viewing a diff with
more or less.

Allan. (ARRae)

Re: ControlInset failling Assert()

[Angus Leeming]

On Wednesday 16 January 2002 1:37 pm, Allan Rae wrote:
 On Tue, 15 Jan 2002, Angus Leeming wrote:
 [...]
  Nonetheless, I think you've hit on a bug. Well done! Although I don't 
think
  it'll help solve your problem, the fix to that particular problem is:
 
  template class Inset, class Params
  void ControlInsetInset, Params::apply()
  {
  if (lv_.buffer()-isReadonly())
  return;
 
  view().apply();
 
  -   if (inset_  params() != getParams(*inset_))
  +   if (inset_)
  +   if (params() != getParams(*inset_))
  applyParamsToInset();
  else
  applyParamsNoInset();
 
 I hope you realise you just made another bug with nested else because
 that will be interpreted as:
 
   if (inset_) {
   if (params() != getParams(*inset_)) {
   applyParamsToInset();
   } else {
   applyParamsNoInset();
   }
   }
 
 instead of what you really wanted:
 
   if (inset_) {
   if (params() != getParams(*inset_)) {
   applyParamsToInset();
   }
   } else {
   applyParamsNoInset();
   }
 
 Allan. (ARRae)

Smart-arse!

Thanks,
Angus (who's fxing it now).

Re: Request to our TeXperts!

[Jules Bean]

On Wed, Jan 16, 2002 at 01:15:42PM +0100, Juergen Vigna wrote:
 \begin{document}
 \texttt{\begin{tabular}{|p{6cm}|c|}
 \hline 
 \texttt{dfasdfasdf sdf asdf}
 
 \texttt{sdf asdfasdf asdf}
 
 \texttt{sdf asdfasdfasdf}
 \\
 \hline
 \hline 
 
 \\
 \hline
 \end{tabular}}
 \end{document}


OK.  Basically you're not allowed to put environments inside \texttt.
\texttt is designed for small amounts of tt text: large amounts of tt
text are expected to be set up with the \ttfamily declaration.

Note that with a \ttfamily before the \begin, the \texttt commands all 
become unnecessary.

Note further that, as a declaration, \ttfamily persists until the end
of the current group (environment, row, or explicit group) or until is 
it counteracted (e.g. by \rmfamily or \sffamily).

Jules

Re: Look Ma, no macros! (Re: Brush-up on Blackboard Bold)

[Jules Bean]

On Wed, Jan 16, 2002 at 03:14:28PM +0200, Dekel Tsur wrote:
 On Wed, Jan 16, 2002 at 11:52:29AM +, Jules Bean wrote:
   Actually, imagemagick uses Ghostscript, and Ghostscript doesn't do a good
   work at low res rendering.
  
  Even with -dTextAlphaBits=4 ?
 
 What is it supposed to do ?

 (it's a gs option, not a convert option)

It puts text-antialiasing to the maximum degree.  Should look quite
nice, in most cases.

Jules

Re: [PATCH]: reducing file dependencies in the frontends

[Angus Leeming]

Well the experts (in this case Lars, André and Alan) have commented and 
nobody's objected. Guess that means it must be a good patch. I'll commit it.

Angus

Re: Insure++ evaluation

[Allan Rae]

On Mon, 14 Jan 2002, Allan Rae wrote:

 I have an evaluation copy of Insure++-5.2 for Linux with a license
 that arrived this morning and expires on Thursday 17th January -- they
 don't want you to take too long in deciding apparently.

I don't know what time today the license expires (hopefully midnight)
so if you have any testcases send them in RSN.

I'll take a look at what Michael has listed in case Insure++ offers
some help for anything there.

So who's going to download a trial version and get an evaluation
license next time?

;-)
Allan. (ARRae)

Re: [PATCH]: reducing file dependencies in the frontends

[Juergen Spitzmueller]

Angus Leeming wrote:
 Well the experts (in this case Lars, André and Alan) have commented
 and nobody's objected. Guess that means it must be a good patch.
 I'll commit it.

Am I supposed to rediff my unapplied ui-(poweruser)work after your 
changes are in (for it changes code in a lot of Form*.C files)?

Juergen.

Re: Bug 141

[Andre Poenitz]

On Wed, Jan 16, 2002 at 11:59:03PM +1000, Allan Rae wrote:
 Wouldn't a simple fix for now be to not expand the macro if it is
 recursive?

 Since you would be up there and could see that you were
 self-referencial.

Not exactly. At a given point of time you are either up there or down
there and currently there is not enough information kept over time...

I'll have a look.

Andre'

-- 
André Pönitz .. [EMAIL PROTECTED]

Re: [PATCH]: reducing file dependencies in the frontends

[Angus Leeming]

On Wednesday 16 January 2002 2:14 pm, Juergen Spitzmueller wrote:
 Angus Leeming wrote:
  Well the experts (in this case Lars, André and Alan) have commented
  and nobody's objected. Guess that means it must be a good patch.
  I'll commit it.
 
 Am I supposed to rediff my unapplied ui-(poweruser)work after your 
 changes are in (for it changes code in a lot of Form*.C files)?

Sorry, Jürgen, I must have lost that one. Could you send it again, please. 
Just to me, rather than to the list. You shouldn't need to rediff at all, as 
my changes are almost all in the controllers directory.

Angus

Re: Request to our TeXperts!

[Juergen Vigna]

On 16-Jan-2002 Jules Bean wrote:

 OK.  Basically you're not allowed to put environments inside \texttt.
 \texttt is designed for small amounts of tt text: large amounts of tt
 text are expected to be set up with the \ttfamily declaration.
 
 Note that with a \ttfamily before the \begin, the \texttt commands all 
 become unnecessary.
 
 Note further that, as a declaration, \ttfamily persists until the end
 of the current group (environment, row, or explicit group) or until is 
 it counteracted (e.g. by \rmfamily or \sffamily).

Thanks for your hints.

So basically we now have 2 solutions.

1. Use the \ttfamily (heed that we have the same problem with SanSerif too!)
   or more generally we would have to use a familychange command supporting
   environments. But this probably will lead to a lot of rewriting and I don't
   know why we didn't do this in the first time.

2. We closee the \texttt before a tabular and reopen it afterwards. But then
   we will probably have the same problem for minipages too and maybe for other
   TextInset we use inside which we can have multiple paragraphs.

Anyway people now have the solution to fix this bug and IMO most of the core
developer could fix this. So please choose the one you like more. I'm sorry
but actually I'm very busy and if I find some time to do something I'll rather
fix the undo stuff and or other serious crashes.

  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
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

When the going gets tough, everyone leaves.
-- Lynch

Re: Look Ma, no macros! (Re: Brush-up on Blackboard Bold)

[Dekel Tsur]

On Wed, Jan 16, 2002 at 01:49:08PM +, Jules Bean wrote:
 On Wed, Jan 16, 2002 at 03:14:28PM +0200, Dekel Tsur wrote:
  On Wed, Jan 16, 2002 at 11:52:29AM +, Jules Bean wrote:
Actually, imagemagick uses Ghostscript, and Ghostscript doesn't do a good
work at low res rendering.
   
   Even with -dTextAlphaBits=4 ?
  
  What is it supposed to do ?
 
  (it's a gs option, not a convert option)
 
 It puts text-antialiasing to the maximum degree.  Should look quite
 nice, in most cases.

But .xbm files are monochrome, hence no anti-aliasing.

Re: Bug 141

[Dekel Tsur]

On Wed, Jan 16, 2002 at 03:21:52PM +0100, Andre Poenitz wrote:
 On Wed, Jan 16, 2002 at 11:59:03PM +1000, Allan Rae wrote:
  Wouldn't a simple fix for now be to not expand the macro if it is
  recursive?
 
  Since you would be up there and could see that you were
  self-referencial.
 
 Not exactly. At a given point of time you are either up there or down
 there and currently there is not enough information kept over time...

How about just keeping the macro expansion depth, and not expand past, say,
depth 100 ?

Re: Three radiobuttons on delim pop-up

[Martin Vermeer]

On Wed, Jan 16, 2002 at 03:18:35PM +0200, Dekel Tsur wrote:
 
 On Wed, Jan 16, 2002 at 01:09:33PM +0200, Martin Vermeer wrote:
 
  Index: math_hullinset.C
  ===
  RCS file: /cvs/lyx/lyx-devel/src/mathed/math_hullinset.C,v
  retrieving revision 1.14
  diff -u -p -r1.14 math_hullinset.C
  --- math_hullinset.C2002/01/10 10:05:45 1.14
  +++ math_hullinset.C2002/01/16 10:48:31
  @@ -261,7 +261,7 @@ bool MathHullInset::numberedType() const
   void MathHullInset::validate(LaTeXFeatures  features) const
   {
  if (ams())
  -   features.require(amsmath);
  +   features.require(amssymb);
 
 No, it should be amsmath.
 Enabling amssymb should be done in the ::validate methods of 
 MathStringInset and MathSymbolInset (which don't exist yet).

Ah, damn. That sounds like work.

-- Martin



msg31621/pgp0.pgp
Description: PGP signature

[PATCH] qt2 stuff, clues for gnome

[Angus Leeming]

Having broken the frontends other than xforms, here's my feeble attempt at 
sorry!

I can't compile the gnome frontend, but here is the qt2 stuff needed to 
compile. The gnome changes should be similar.

Note that the Thesaurus was already broken, so I've just commented it out of 
Makefile.dialogs.

Angus



qt2.diff.bz2
Description: BZip2 compressed data

Re: Three radiobuttons on delim pop-up

[Andre Poenitz]

  No, it should be amsmath.
  Enabling amssymb should be done in the ::validate methods of 
  MathStringInset and MathSymbolInset (which don't exist yet).
 
 Ah, damn. That sounds like work.

Three lines in the .C, two in the .h.

Andre'

-- 
André Pönitz .. [EMAIL PROTECTED]

[PATCH] cosmetics

[Juergen Spitzmueller]

The text_info field in form_tabular is too small for the warning 
messages of the length filters (at least for the german translation).

This patch enlarges it. Please apply.

Thanks,
Juergen. 

Index: src/frontends/xforms/ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/src/frontends/xforms/ChangeLog,v
retrieving revision 1.248
diff -u -r1.248 ChangeLog
--- src/frontends/xforms/ChangeLog	2002/01/16 16:34:03	1.248
+++ src/frontends/xforms/ChangeLog	2002/01/16 16:53:44
@@ -1,3 +1,7 @@
+2002-01-16  Jürgen Spitzmüller  [EMAIL PROTECTED]
+
+	* forms/form_tabular.fd: text_info field was too small. Enlarge it.
+
 2002-01-15  Jürgen Spitzmüller  [EMAIL PROTECTED]

 	* xforms_helpers.C: modify getLengthFromWidgets to ignore the unit
Index: src/frontends/xforms/form_tabular.C
===
RCS file: /cvs/lyx/lyx-devel/src/frontends/xforms/form_tabular.C,v
retrieving revision 1.23
diff -u -r1.23 form_tabular.C
--- src/frontends/xforms/form_tabular.C	2002/01/07 11:28:09	1.23
+++ src/frontends/xforms/form_tabular.C	2002/01/16 16:53:46
@@ -22,25 +22,25 @@
   FL_OBJECT *obj;
   FD_form_tabular *fdui = new FD_form_tabular;
 
-  fdui-form = fl_bgn_form(FL_NO_BOX, 510, 295);
+  fdui-form = fl_bgn_form(FL_NO_BOX, 510, 325);
   fdui-form-u_vdata = this;
-  obj = fl_add_box(FL_FLAT_BOX, 0, 0, 510, 295, );
+  obj = fl_add_box(FL_FLAT_BOX, 0, 0, 510, 325, );
   fdui-tabFolder = obj = fl_add_tabfolder(FL_TOP_TABFOLDER, 0, 0, 505, 250, _(Tabbed folder));
 fl_set_object_resize(obj, FL_RESIZE_ALL);
   {
 char const * const dummy = N_(Close|^[);
-fdui-button_close = obj = fl_add_button(FL_NORMAL_BUTTON, 415, 260, 90, 30, idex(_(dummy)));
+fdui-button_close = obj = fl_add_button(FL_NORMAL_BUTTON, 415, 290, 90, 30, idex(_(dummy)));
 fl_set_button_shortcut(obj, scex(_(dummy)), 1);
   }
 fl_set_object_lsize(obj, FL_NORMAL_SIZE);
 fl_set_object_callback(obj, C_FormBaseDeprecatedInputCB, 0);
-  fdui-input_tabular_column = obj = fl_add_input(FL_NORMAL_INPUT, 65, 260, 60, 30, );
+  fdui-input_tabular_column = obj = fl_add_input(FL_NORMAL_INPUT, 65, 290, 60, 30, );
 fl_set_object_lsize(obj, FL_NORMAL_SIZE);
 fl_set_object_lalign(obj, FL_ALIGN_TOP_LEFT);
-  fdui-input_tabular_row = obj = fl_add_input(FL_NORMAL_INPUT, 5, 260, 60, 30, );
+  fdui-input_tabular_row = obj = fl_add_input(FL_NORMAL_INPUT, 5, 290, 60, 30, );
 fl_set_object_lsize(obj, FL_NORMAL_SIZE);
 fl_set_object_lalign(obj, FL_ALIGN_TOP_LEFT);
-  fdui-text_warning = obj = fl_add_text(FL_NORMAL_TEXT, 125, 260, 290, 30, );
+  fdui-text_warning = obj = fl_add_text(FL_NORMAL_TEXT, 5, 255, 500, 30, );
 fl_set_object_lsize(obj, FL_NORMAL_SIZE);
 fl_set_object_lalign(obj, FL_ALIGN_LEFT|FL_ALIGN_INSIDE);
 fl_set_object_lstyle(obj, FL_BOLD_STYLE);
Index: src/frontends/xforms/forms/form_tabular.fd
===
RCS file: /cvs/lyx/lyx-devel/src/frontends/xforms/forms/form_tabular.fd,v
retrieving revision 1.16
diff -u -r1.16 form_tabular.fd
--- src/frontends/xforms/forms/form_tabular.fd	2002/01/07 11:28:09	1.16
+++ src/frontends/xforms/forms/form_tabular.fd	2002/01/16 16:53:48
@@ -10,13 +10,13 @@
 === FORM ===
 Name: form_tabular
 Width: 510
-Height: 295
+Height: 325
 Number of Objects: 6
 
 
 class: FL_BOX
 type: FLAT_BOX
-box: 0 0 510 295
+box: 0 0 510 325
 boxtype: FL_FLAT_BOX
 colors: FL_COL1 FL_COL1
 alignment: FL_ALIGN_CENTER
@@ -52,7 +52,7 @@
 
 class: FL_BUTTON
 type: NORMAL_BUTTON
-box: 415 260 90 30
+box: 415 290 90 30
 boxtype: FL_UP_BOX
 colors: FL_COL1 FL_COL1
 alignment: FL_ALIGN_CENTER
@@ -70,7 +70,7 @@
 
 class: FL_INPUT
 type: NORMAL_INPUT
-box: 65 260 60 30
+box: 65 290 60 30
 boxtype: FL_DOWN_BOX
 colors: FL_COL1 FL_MCOL
 alignment: FL_ALIGN_TOP_LEFT
@@ -88,7 +88,7 @@
 
 class: FL_INPUT
 type: NORMAL_INPUT
-box: 5 260 60 30
+box: 5 290 60 30
 boxtype: FL_DOWN_BOX
 colors: FL_COL1 FL_MCOL
 alignment: FL_ALIGN_TOP_LEFT
@@ -106,7 +106,7 @@
 
 class: FL_TEXT
 type: NORMAL_TEXT
-box: 125 260 290 30
+box: 5 255 500 30
 boxtype: FL_FLAT_BOX
 colors: FL_COL1 FL_MCOL
 alignment: FL_ALIGN_LEFT|FL_ALIGN_INSIDE

Re: [PATCH] cosmetics

[Angus Leeming]

On Wednesday 16 January 2002 5:02 pm, Juergen Spitzmueller wrote:
 The text_info field in form_tabular is too small for the warning 
 messages of the length filters (at least for the german translation).
 
 This patch enlarges it. Please apply.

Have done so.
A

Re: [PATCH]: reducing file dependencies in the frontends

[Martin Vermeer]

Your patch of course messed up what I was doing, building mathed menus for
the ams symbols. It worked very well until I decided to update CVS...
now it won't link. Doing a clean recompile and holding my fingers
crossed.

Here is the patch anyway for you to play with, it should apply still as 
there is nothing mysterious happening. This still would benefit from having 
a validation for amssymb implemented, the 3 + 2 lines that André so playfully 
referred to...

-- Martin



Index: FormMathsPanel.C
===
RCS file: /cvs/lyx/lyx-devel/src/frontends/xforms/FormMathsPanel.C,v
retrieving revision 1.18
diff -u -B -p -r1.18 FormMathsPanel.C
--- FormMathsPanel.C2002/01/15 15:31:18 1.18
+++ FormMathsPanel.C2002/01/16 17:31:03
@@ -55,6 +55,12 @@
 #include misc.xbm
 #include varsz.xbm
 
+#include ams_misc.xbm
+#include ams_arrows.xbm
+#include ams_rel.xbm
+#include ams_nrel.xbm
+#include ams_ops.xbm
+
 using std::vector;
 using SigC::slot;
 
@@ -113,6 +119,36 @@ FormMathsPanel::FormMathsPanel(LyXView *
}
varsize_.reset(new FormMathsBitmap(lv, d, *this, latex));
 
+   latex.resize(nr_latex_ams_misc);
+   for (StringVec::size_type i = 0; i  latex.size(); ++i) {
+   latex[i] = latex_ams_misc[i];
+   }
+   ams_misc_.reset(new FormMathsBitmap(lv, d, *this, latex));
+
+   latex.resize(nr_latex_ams_arrows);
+   for (StringVec::size_type i = 0; i  latex.size(); ++i) {
+   latex[i] = latex_ams_arrows[i];
+   }
+   ams_arrows_.reset(new FormMathsBitmap(lv, d, *this, latex));
+
+   latex.resize(nr_latex_ams_rel);
+   for (StringVec::size_type i = 0; i  latex.size(); ++i) {
+   latex[i] = latex_ams_rel[i];
+   }
+   ams_rel_.reset(new FormMathsBitmap(lv, d, *this, latex));
+
+   latex.resize(nr_latex_ams_nrel);
+   for (StringVec::size_type i = 0; i  latex.size(); ++i) {
+   latex[i] = latex_ams_nrel[i];
+   }
+   ams_nrel_.reset(new FormMathsBitmap(lv, d, *this, latex));
+
+   latex.resize(nr_latex_ams_ops);
+   for (StringVec::size_type i = 0; i  latex.size(); ++i) {
+   latex[i] = latex_ams_ops[i];
+   }
+   ams_ops_.reset(new FormMathsBitmap(lv, d, *this, latex));
+
d-showMathPanel.connect(slot(this, FormMathsPanel::show));
 }
 
@@ -180,6 +216,18 @@ void FormMathsPanel::build()
 
varsize_-addBitmap(14, 3, 5, varsz_width, varsz_height, varsz_bits);
 
+   ams_misc_-addBitmap(9, 5, 2, ams1_width, ams1_height, ams1_bits);
+   ams_misc_-addBitmap(26, 3, 9, ams7_width, ams7_height, ams7_bits);
+   
+   ams_arrows_-addBitmap(32, 3, 11, ams2_width, ams2_height, ams2_bits);
+   ams_arrows_-addBitmap(6, 3, 2, ams3_width, ams3_height, ams3_bits);
+
+   ams_rel_-addBitmap(66, 3, 22, ams_rel_width, ams_rel_height, ams_rel_bits);
+
+   ams_nrel_-addBitmap(51, 3, 17, ams_nrel_width, ams_nrel_height, 
+ams_nrel_bits);
+   
+   ams_ops_-addBitmap(23, 3, 8, ams_ops_width, ams_ops_height, ams_ops_bits);
+
bc().setCancel(dialog_-button_close);
 }
 
@@ -228,6 +276,36 @@ bool FormMathsPanel::input(FL_OBJECT *, 
if (active_  active_ != varsize_.get())
active_-hide();
varsize_-show();
+   break;
+
+   case MM_AMS_MISC:
+   if (active_  active_ != ams_misc_.get())
+   active_-hide();
+   ams_misc_-show();
+   break;
+   
+   case MM_AMS_ARROWS:
+   if (active_  active_ != ams_arrows_.get())
+   active_-hide();
+   ams_arrows_-show();
+   break;
+
+   case MM_AMS_BREL:
+   if (active_  active_ != ams_rel_.get())
+   active_-hide();
+   ams_rel_-show();
+   break;
+
+   case MM_AMS_NREL:
+   if (active_  active_ != ams_nrel_.get())
+   active_-hide();
+   ams_nrel_-show();
+   break;
+
+   case MM_AMS_OPS:
+   if (active_  active_ != ams_ops_.get())
+   active_-hide();
+   ams_ops_-show();
break;
 
case MM_FRAC:
Index: FormMathsPanel.h
===
RCS file: /cvs/lyx/lyx-devel/src/frontends/xforms/FormMathsPanel.h,v
retrieving revision 1.11
diff -u -B -p -r1.11 FormMathsPanel.h
--- FormMathsPanel.h2002/01/15 15:31:18 1.11
+++ FormMathsPanel.h2002/01/16 17:31:04
@@ -50,6 +50,11 @@ enum MathsCallbackValues {
MM_SPACE,
MM_STYLE,
MM_DOTS,
+   MM_AMS_MISC,
+   MM_AMS_ARROWS,
+   MM_AMS_BREL,
+   MM_AMS_NREL,
+   MM_AMS_OPS,
MM_FUNC
 };
  
@@ -100,6 +105,11 @@ private:
boost::scoped_ptrFormMathsBitmap misc_;
boost::scoped_ptrFormMathsBitmap dots_;

make fails

[Juergen Spitzmueller]

This happens after a complete 
- make distclean
- ./autogen.sh
etc., too.

gcc 2.95.3

---

[...]

M -lICE -liberty -lc -lm -L/usr/X11R6/lib -lX11
frontends/.libs/libfrontends.a(FormMathsPanel.o): In function 
`FormMathsSub::FormMathsSub(int, LyXView *, Dialogs *, FormMathsPanel 
const , basic_stringchar, string_char_traitschar, 
__default_alloc_templatetrue, 0  const , bool)':
/home/juergen/lyx-devel/src/frontends/xforms/FormMathsPanel.C:326: 
undefined reference to `ButtonControllerIgnorantPolicy, 
xformsBC::ButtonController(basic_stringchar, 
string_char_traitschar, __default_alloc_templatetrue, 0  const 
, basic_stringchar, string_char_traitschar, 
__default_alloc_templatetrue, 0 const )'
frontends/.libs/libfrontends.a(FormPreferences.o): In function 
`queueint, deque
int, allocatorint, 0 ::operator=(queueint, dequeint, 
allocatorint, 0 
 const )':
/usr/include/g++/sstream(.text+0x327): undefined reference to 
`ButtonController
PreferencesPolicy, xformsBC::ButtonController(basic_stringchar, 
string_char_traitschar, __default_alloc_templatetrue, 0  const , 
basic_stringchar, string_char_traitschar, 
__default_alloc_templatetrue, 0  const )'
frontends/.libs/libfrontends.a(ControlBibitem.o): In function 
`ControlInsetInsetCommand, 
InsetCommandParams::disconnectOnApply(void)':
/home/juergen/lyx-devel/src/frontends/controllers/ControlInset.h(.text+0x54): 
undefined reference to `ControlInsetInsetCommand, 
InsetCommandParams::showInset(InsetCommand *)'
frontends/.libs/libfrontends.a(ControlBibtex.o): In function 
`ControlInsetInsetCommand, 
InsetCommandParams::disconnectOnApply(void)':
/home/juergen/lyx-devel/src/frontends/controllers/ControlInset.h(.text+0x54): 
undefined reference to `ControlInsetInsetCommand, 
InsetCommandParams::showInset(InsetCommand *)'
frontends/.libs/libfrontends.a(ControlCitation.o): In function 
`mapbasic_stringchar, string_char_traitschar, 
__default_alloc_templatetrue, 0 , basic_stringchar, 
string_char_traitschar, __default_alloc_templatetrue, 0 , lessbas
ic_stringchar, string_char_traitschar, 
__default_alloc_templatetrue, 0  ,
 allocatorbasic_stringchar, string_char_traitschar, 
__default_alloc_templatetrue, 0   ::~map(void)':
/usr/include/g++/stl_construct.h(.text+0xeb): undefined reference to 
`ControlInsetInsetCommand, InsetCommandParams::showInset(InsetCommand 
*)'
/usr/include/g++/stl_construct.h(.text+0x243): undefined reference to 
`ControlInsetInsetCommand, 
InsetCommandParams::createInset(basic_stringchar, string_cha
r_traitschar, __default_alloc_templatetrue, 0  const )'
frontends/.libs/libfrontends.a(ControlIndex.o): In function 
`ControlInsetInsetCommand, 
InsetCommandParams::disconnectOnApply(void)':
/home/juergen/lyx-devel/src/frontends/controllers/ControlInset.h:72: 
undefined reference to `ControlInsetInsetCommand, 
InsetCommandParams::showInset(InsetCommand *)'
/home/juergen/lyx-devel/src/frontends/controllers/ControlInset.h:72: 
undefined reference to `ControlInsetInsetCommand, 
InsetCommandParams::createInset(basic_stringchar, 
string_char_traitschar, __default_alloc_templatetrue, 0  const
)'
frontends/.libs/libfrontends.a(ControlRef.o): In function 
`ControlInsetInsetCommand, 
InsetCommandParams::clearDaughterParams(void)':
/home/juergen/lyx-devel/src/frontends/controllers/ControlInset.h(.text+0x57): 
undefined reference to `ControlInsetInsetCommand, 
InsetCommandParams::showInset(InsetCommand *)'
/home/juergen/lyx-devel/src/frontends/controllers/ControlInset.h(.text+0x1b2): 
undefined reference to `ControlInsetInsetCommand, 
InsetCommandParams::createInset(basic_stringchar, 
string_char_traitschar, __default_alloc_templatetrue, 0
  const )'
frontends/.libs/libfrontends.a(ControlToc.o): In function 
`stringbuf::stringbuf_sync(int, int)':
/home/juergen/lyx-devel/src/frontends/controllers/ControlInset.h(.text+0x57): 
undefined reference to `ControlInsetInsetCommand, 
InsetCommandParams::showInset(InsetCommand *)'
/home/juergen/lyx-devel/src/frontends/controllers/ControlInset.h(.text+0x1b2): 
undefined reference to `ControlInsetInsetCommand, 
InsetCommandParams::createInset(basic_stringchar, 
string_char_traitschar, __default_alloc_templatetrue, 0
  const )'
frontends/.libs/libfrontends.a(ControlUrl.o): In function 
`ControlInsetInsetCommand, 
InsetCommandParams::disconnectOnApply(void)':
/home/juergen/lyx-devel/src/frontends/controllers/ControlInset.h:72: 
undefined reference to `ControlInsetInsetCommand, 
InsetCommandParams::showInset(InsetComm
and *)'
/home/juergen/lyx-devel/src/frontends/controllers/ControlInset.h:72: 
undefined reference to `ControlInsetInsetCommand, 
InsetCommandParams::createInset(basic_stringchar, 
string_char_traitschar, __default_alloc_templatetrue, 0  const
)'
collect2: ld returned 1 exit status
make[3]: *** [lyx] Error 1
make[3]: Leaving directory `/home/juergen/lyx-devel/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/juergen/lyx-devel/src'
make[1]: *** [all-recursive-am] Error 2
make[1]: Leaving 

Re: [PATCH]: reducing file dependencies in the frontends

[Angus Leeming]

On Wednesday 16 January 2002 5:46 pm, Martin Vermeer wrote:
 Your patch of course messed up what I was doing, building mathed menus for
 the ams symbols. It worked very well until I decided to update CVS...
 now it won't link. Doing a clean recompile and holding my fingers
 crossed.
 
 Here is the patch anyway for you to play with, it should apply still as 
 there is nothing mysterious happening. This still would benefit from having 
 a validation for amssymb implemented, the 3 + 2 lines that André so 
playfully 
 referred to...
 
 -- Martin

I will do so. Thanks.

It's very possible that the .deps files have been confused by all this. It is 
pretty brutal. If I were you, therefore, I would make sure that the .deps 
directories in both the controllers and xforms directories were wiped clean 
as well as doing a make clean in these two dirs.

Time will tell if this is necessary or not.

Angus

Re: [PATCH]: reducing file dependencies in the frontends

[Angus Leeming]

On Wednesday 16 January 2002 5:46 pm, Martin Vermeer wrote:
 Your patch of course messed up what I was doing, building mathed menus for
 the ams symbols. It worked very well until I decided to update CVS...
 now it won't link. Doing a clean recompile and holding my fingers
 crossed.
 
 Here is the patch anyway for you to play with, it should apply still as 
 there is nothing mysterious happening. This still would benefit from having 
 a validation for amssymb implemented, the 3 + 2 lines that André so 
playfully 
 referred to...

ChangeLogs please!!

It's nice to know what the patch is meant to do without gooing through every 
line of the source.

Angus

Re: [PATCH]: reducing file dependencies in the frontends

[Angus Leeming]

On Wednesday 16 January 2002 5:46 pm, Martin Vermeer wrote:
 Your patch of course messed up what I was doing, building mathed menus for
 the ams symbols. It worked very well until I decided to update CVS...
 now it won't link. Doing a clean recompile and holding my fingers
 crossed.
 
 Here is the patch anyway for you to play with, it should apply still as 
 there is nothing mysterious happening. This still would benefit from having 
 a validation for amssymb implemented, the 3 + 2 lines that André so 
playfully 
 referred to...

Can we have these files too please?
A

+#include ams_misc.xbm
+#include ams_arrows.xbm
+#include ams_rel.xbm
+#include ams_nrel.xbm
+#include ams_ops.xbm
+

Re: dummy layout and how to get it!

[Jose Abilio Oliveira Matos]

On Tuesday 08 January 2002 11:11, Juergen Vigna wrote:
 And one other question couldn't we just have Standard layout defaulting
 to layout-no == 0? This would simplify things (when for example I want to
 force Standard layout on a paragraph how can I do this now?) IMO.

  I'm glad that you ask this although you will be soon on vacations.

  I have been fixing some bugs related with docbook that Ben G. sent me, some 
months ago. Ben, I promisse that they will be all fixed before 1.2 (more or 
less :-).

 Also Standard should IMO be forced to be in all possible textclasses at
 least I cannot see a textclass without default paragraph textclass (I
 call it 'Standard' but it name could be another in some other textclasses I
 just don't care about the name it HAS to be no == 0). We could do this by
 forcing a Default Layout in the textclasses. But well we don't have this
 now but I have to force a Standard layout on all paragraphs inside
 normal tabular cells (without width!).

  Between the lyx-latex and lyx-docbook there are lots of common stuff, but 
the one where we differ the most is with Standard layout style.

  For latex Standard can have two different meanings. Sometimes it acts as a 
paragraph, and sometimes as a place to put latex code. That is one of the 
reason why Allan is always worried about the possibility that an extra 
newline is inserted. ;-) Where in docbook that is a non-issue.

  For docbook I have attributed to Standard its usual role and that is 
paragraph - para/para

  For the other role I created another layout style that I'm tempted to call 
Empty. Initially I thought of it as SGML, the equivalent of Latex, but as 
Lars noted it doesn't make sense to have several ways to do the same thing.
This means that Empty != SGML, if you want the old SGML, you should use 
Empty+ERT.

  Using Juergen's notation Empty is my dummy paragraph.

  The question is that there isn't any method to distinguish between the two 
roles for Standard. All the possible solutions involve some hacks that aren't 
worth it. One of the possible solutions that I have discussed with Jean-Marc 
regarding the inset include involved to have elements that would appear 
outside a paragraph... that would solve partially that case but would leave 
all the others, where Empty is the alternative.

  So I propose to split this two different meanings in docbook, Standard and 
Empty for those different purposes.

  I intend to provide better documentation so that the users are not taken by 
surprise with this behaviour. What is my problem then?

  Inside tables I would like to be able to select between Standard and Empty, 
and by default I would like to have Empty.

  So I would like to have that choice. Is that to ask too much? ;-)

 Please give me enlightment!

  Not enlightment, only troubles. :-)

   Jug

  I know that my writing is confuse sometimes, but I would like to hear from 
you all.

--
José Abílio

error compiling lyx cvs with qt2 front end

[Xavier Helluy]

Hello,

I just tryed to compile lyx-devel with frontend=qt2. I get the following 
compilation error : syntax error before const  in a vector definition.
I am all but not a c++ expert. Is it possible to solve the problem ?

thank you (I've used lyx to write my phd thesis, and it did a really good job)

salut


xavier helluy



/bin/sh ../../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. 
-I../../../src -I../../../src/ -I../../../src/frontends/-
I../../.. -I../../.. -I./qt2 -I/usr/lib/qt2/include -I../../../boost
-I../../../src/frontends/controllers  -isystem /usr/X11R6
/include -DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -g -O -fno-exceptions -W -Wall 
-c QCharacter.C
g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -I../../../src/ 
-I../../../src/frontends/ -I../../.. -I../../.. -I./qt2 -I/usr/lib/qt2
/include -I../../../boost -I../../../src/frontends/controllers -isystem 
/usr/X11R6/include -DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR   -g -O 
-fno-exceptions -W -Wall -Wp,-MD,.deps/QCharacter.pp -c QCharacter.C
In file included from 
../../../src/frontends/controllers/ControlCharacter.h:20,
 from QCharacter.C:15:
../../../src/frontends/controllers/character.h:55: syntax error before `const'
../../../src/frontends/controllers/character.h:57: `SeriesPair' was not 
declared in this scope
../../../src/frontends/controllers/character.h:57: syntax error before `const'
../../../src/frontends/controllers/character.h:59: `ShapePair' was not 
declared in this scope
../../../src/frontends/controllers/character.h:59: syntax error before `const'
../../../src/frontends/controllers/character.h:61: `SizePair' was not declared 
in this scope
../../../src/frontends/controllers/character.h:61: syntax error before `const'
../../../src/frontends/controllers/character.h:63: `BarPair' was not declared 
in this scope
../../../src/frontends/controllers/character.h:63: syntax error before `const'
../../../src/frontends/controllers/character.h:65: `ColorPair' was not 
declared in this scope
../../../src/frontends/controllers/character.h:65: syntax error before `const'
../../../src/frontends/controllers/character.h:67: syntax error before `const'
../../../boost/boost/smart_ptr.hpp: In method `void
boost::scoped_ptrT::scoped_ptr () [with T = QCharacterDialog]':
QCharacter.C:30:   instantiated from here
../../../boost/boost/smart_ptr.hpp:99: `checked_delete' undeclared
(first use this function)
../../../boost/boost/smart_ptr.hpp:99: (Each undeclared identifier is
reported only once for each function it appears in.)
QCharacter.C: In method `void QCharacter::build_dialog ()':
QCharacter.C:38: `getFamilyData' undeclared (first use this function)
QCharacter.C:39: `getSeriesData' undeclared (first use this function)
QCharacter.C:40: `getShapeData' undeclared (first use this function)
QCharacter.C:41: `getSizeData' undeclared (first use this function)
QCharacter.C:42: `getBarData' undeclared (first use this function)
QCharacter.C:43: `getColorData' undeclared (first use this function)
QCharacter.C:44: `getLanguageData' undeclared (first use this function)
make[5]: *** [QCharacter.lo] Error 1
make[5]: Leaving directory `/home/xavier/lyx-devel/src/frontends/qt2'
make[4]: *** [all-recursive] Error 1

Re: CVS Update: lyx-devel

[Herbert Voss]

Angus, I have three more insets in my own cvs, but they
make some problems after your changes. What have I to do
that it will compile again. Here the error messages for
the first inset, the other two have the same.

HErbert

In file included from Dialogs.C:20:
../../../src/frontends/controllers/GUI.h:133: type/value mismatch at 
argument 1 in template parameter list for `template class Controller, 
class GUIview, class Policy, class GUIbc 
GUIController,GUIview,Policy,GUIbc'
../../../src/frontends/controllers/GUI.h:133:   expected a type, got 
`ControlCreateFloat'
../../../src/frontends/controllers/GUI.h: In method 
`GUICreateFloatGUIview,GUIbc::GUICreateFloat(LyXView , Dialogs )':
../../../src/frontends/controllers/GUI.h:137: type/value mismatch at 
argument 1 in template parameter list for `template class Controller, 
class GUIview, class Policy, class GUIbc 
GUIController,GUIview,Policy,GUIbc'
../../../src/frontends/controllers/GUI.h:137:   expected a type, got 
`ControlCreateFLoat'
../../../src/frontends/controllers/GUI.h:137: class 
`GUICreateFloatGUIview,GUIbc' does not have any field named

Re: make fails

[Juergen Spitzmueller]

Angus Leeming wrote:
 The patch, attached, will cure your linking woes.

Indeed it does.

Thanks,
Juergen.

Re: [PATCH] qt2 stuff, clues for gnome

[John Levon]

On Wed, Jan 16, 2002 at 04:06:24PM +, Angus Leeming wrote:

 I can't compile the gnome frontend, but here is the qt2 stuff needed to 
 compile. The gnome changes should be similar.

I'm dealing with this since I have the thesaurus update in my tree.

regards
john



-- 
Now why did you have to go and mess up the child's head, so you can get another gold 
waterbed ?
 You fake-hair contact-wearing liposuction carnival exhibit, listen to my rhyme ...

Re: error compiling lyx cvs with qt2 front end

[John Levon]

On Wed, Jan 16, 2002 at 11:17:46PM +0100, Xavier Helluy wrote:

 I just tryed to compile lyx-devel with frontend=qt2. I get the following 
 compilation error : syntax error before const  in a vector definition.
 I am all but not a c++ expert. Is it possible to solve the problem ?

I am you are talking about CVS lyx :)

I'm committing fixes now for the frontend, hold tight.

regards
john
-- 
Now why did you have to go and mess up the child's head, so you can get another gold 
waterbed ?
 You fake-hair contact-wearing liposuction carnival exhibit, listen to my rhyme ...

Re: error compiling lyx cvs with qt2 front end

[John Levon]

On Wed, Jan 16, 2002 at 11:17:46PM +0100, Xavier Helluy wrote:

 Hello,
 
 I just tryed to compile lyx-devel with frontend=qt2. I get the following 

forgot to mention, at the moment, the qt2 version can and will crash randomly, there
is nothing I can do about this for now.

regards
john

-- 
Now why did you have to go and mess up the child's head, so you can get another gold 
waterbed ?
 You fake-hair contact-wearing liposuction carnival exhibit, listen to my rhyme ...

Re: bug #174

[Allan Rae]

John, can you give me something more to go on about the updating
problem you are seeing?

It works fine for me in all sorts of variations -- I wouldn't have
checked it in otherwise.

The only problem I see is if I collapse the first minipage and have
the second set to 45%:

[minipage][minipage
  [ ]

and then open the first minipage.  Sometimes, but not everytime, the
second minipage extends to the right border (if not beyond).

I'll try again with an updated cvs and see if that changes anything.

Allan. (ARRae)

Re: bug #174

[John Levon]

On Thu, Jan 17, 2002 at 11:59:15AM +1000, Allan Rae wrote:

 John, can you give me something more to go on about the updating
 problem you are seeing?

new doc
insert minipage
set to 45%
position cursor to right of minipage
insert minipage
set to 45%

- the second minipage can't be seen

this is from current CVS, maybe I shuold try a make clean ...

regards
john

-- 
Hey, we could invent a programming paradigm where the program is expressed as
a series of statements to be executed in a fixed order.
- Khendon

Re: bug #174

[Allan Rae]

On Thu, 17 Jan 2002, John Levon wrote:

 On Thu, Jan 17, 2002 at 11:59:15AM +1000, Allan Rae wrote:

  John, can you give me something more to go on about the updating
  problem you are seeing?

 new doc
 insert minipage
 set to 45%
 position cursor to right of minipage
 insert minipage
 set to 45%

 - the second minipage can't be seen

Yes, I see something like this now -- I just open a different document
and found the ERTs weren't being redrawn properly.

I was loading the existing document and it seemed fine.  Maybe I
should have tested a different document also :-)

 this is from current CVS, maybe I shuold try a make clean ...

You can if you want.  But I don't think that's necessary now.

Allan. (ARRae)

Re: #188

[John Levon]

[Cc:ed to lyx-devel]

On Thu, Jan 17, 2002 at 02:00:30PM +1000, Allan Rae wrote:

 I ran the crash test through Insure and it only provides a backtrace
 no extra info.  So for now I will look at fixing the rendering error
 from #174 and try to find some other test cases from Michaels list.

I have found a problem, but I'm not sure if it's related. Trying njamd
with these files crashes for me with a bad pointer inside libXpm anyway
so it's hard for me to check the problems.

But I think this is needed anyway :

Index: graphics/ImageLoaderXPM.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/graphics/ImageLoaderXPM.C,v
retrieving revision 1.12
diff -u -r1.12 ImageLoaderXPM.C
--- graphics/ImageLoaderXPM.C   2001/09/21 16:24:28 1.12
+++ graphics/ImageLoaderXPM.C   2002/01/17 04:49:23
@@ -77,7 +77,7 @@
xpm_col.pixel = lyxColorHandler-colorPixel(LColor::graphicsbg);
 
XpmAttributes attrib;
-   attrib.valuemask = XpmCloseness | XpmColorSymbols | XpmColorKey;
+   attrib.valuemask = XpmCloseness | XpmColorSymbols;
 
attrib.closeness = 1;

(look at the warning below, did you get that warning ?)

I am using libXpm 4.11


Anyway, I looked at the backtrace with gdb and the problem is :

(converter.C)

643 lyxerr[Debug::FILES]  Calling   command  endl;
644 if (buffer)
645 ShowMessage(buffer, _(Executing command:), 
command);

ShowMessage assumes a BufferView has been generated. buffer-getUser() is 0 - boom

Now the question is, where to put the fix ? We could do above (buffer  
buffer-getUser()),
we could change ShowMessage to deal with it etc. Advice please !

I think the problem is converter.C was never really generalised enough for
use by insetgraphics, there are other problems as well in this area.

Also, with the fix to converter.C, the loaded document is all blue-language-line. The 
doc's
language is english, which is my default. so that's another bug.

insetgraphics still needs a lot of work IMHO, but I don't know who's going to do it. I 
had
a trawl of freshmeat, and it looks like imlib2 and libafterimage are our best choices 
for
implementing scaling etc. At least of one these offers line-by-line decoding, which we 
can do
in an xforms idle callback I think.

regards
john


-- 
Hey, we could invent a programming paradigm where the program is expressed as
a series of statements to be executed in a fixed order.
- Khendon

Re: #188

[Allan Rae]

On Thu, 17 Jan 2002, John Levon wrote:

 [Cc:ed to lyx-devel]

 On Thu, Jan 17, 2002 at 02:00:30PM +1000, Allan Rae wrote:

  I ran the crash test through Insure and it only provides a backtrace
  no extra info.  So for now I will look at fixing the rendering error
  from #174 and try to find some other test cases from Michaels list.

 I have found a problem, but I'm not sure if it's related. Trying njamd
 with these files crashes for me with a bad pointer inside libXpm anyway
 so it's hard for me to check the problems.

Yeah, this is what insure++ calls a FREE_BODY where libXpm is freeing
part of the buffer it malloced.  This seems to be okay in that case.
Can you tell njamd to ignore certain libraries or something?  (this
would help me too)

 But I think this is needed anyway :
 -   attrib.valuemask = XpmCloseness | XpmColorSymbols | XpmColorKey;
 +   attrib.valuemask = XpmCloseness | XpmColorSymbols;
 (look at the warning below, did you get that warning ?)

 I am using libXpm 4.11

[...]
 ShowMessage assumes a BufferView has been generated. buffer-getUser() is 0 - boom

 Now the question is, where to put the fix ? We could do above (buffer  
buffer-getUser()),
 we could change ShowMessage to deal with it etc. Advice please !

This would hide the problem nicely but I think we should instead make
sure that when we are exporting we should probably have
InsetInclude::latex() not only load the file if it isn't already but
it should create a BufferView for it also -- I think that should just
require a change of buffers (I don't know if this is easy with LyXFunc
or we have to do it directly).

 I think the problem is converter.C was never really generalised enough for
 use by insetgraphics, there are other problems as well in this area.

 Also, with the fix to converter.C, the loaded document is all blue-language-line. 
The doc's
 language is english, which is my default. so that's another bug.

I get this also if I just Insert-Include the file and press Load from
the dialog. Or just open it (IIRC).

 insetgraphics still needs a lot of work IMHO, but I don't know who's going to do it. 
I had
 a trawl of freshmeat, and it looks like imlib2 and libafterimage are our best 
choices for
 implementing scaling etc. At least of one these offers line-by-line decoding, which 
we can do
 in an xforms idle callback I think.

I think Baruch was hoping to use anything that was available but it
would be preferable that the same toolkit was used whether scaling was
needed or not.

Allan. (ARRae)

Re: finish this patch

[John Levon]

On Mon, Jan 14, 2002 at 03:14:28AM +, John Levon wrote:

 navigation to inside insets. Someone finish this patch purleaassse, this
 bug is too old by now.

does nobody care or am I insane or what ?

john

Re: feature request: open a new file in lyx from the shell

[John Levon]

On Wed, Jan 16, 2002 at 06:28:35PM +1100, matthew arnison wrote:

 matthewa@focus:~/local/lyx$ echo \
 LYXCMD:hello:buffer-open:/full/path/to/file.lyx  lyxpipe.in
 
 and I still get the File Open dialog.

try

LYXCMD:hello:file-open:file.lyx

 Then you could ship lyx with a little script that opens new documents in a
 running lyx from the command line. You could call it lyxopen or something.

perhaps.

 Perhaps you could rename this option to Rescale bitmap fonts. Or inverse

I agree. Who else does ?

regards
john

-- 
Hey, we could invent a programming paradigm where the program is expressed as
a series of statements to be executed in a fixed order.
- Khendon

Re: #188

[John Levon]

On Thu, Jan 17, 2002 at 03:18:44PM +1000, Allan Rae wrote:

 Yeah, this is what insure++ calls a FREE_BODY where libXpm is freeing
 part of the buffer it malloced.  This seems to be okay in that case.

it's not, it's trying to strcasecmp the name string with a string at 0xb

 Can you tell njamd to ignore certain libraries or something?  (this
 would help me too)

dunno ...

 This would hide the problem nicely but I think we should instead make
 sure that when we are exporting we should probably have
 InsetInclude::latex() not only load the file if it isn't already but

eek, a view-dvi has to load 20 chapters ??

  insetgraphics still needs a lot of work IMHO, but I don't know who's going to do 
it. I had
  a trawl of freshmeat, and it looks like imlib2 and libafterimage are our best 
choices for
  implementing scaling etc. At least of one these offers line-by-line decoding, 
which we can do
  in an xforms idle callback I think.
 
 I think Baruch was hoping to use anything that was available but it
 would be preferable that the same toolkit was used whether scaling was
 needed or not.

what do you mean ?

regards
john

-- 
Hey, we could invent a programming paradigm where the program is expressed as
a series of statements to be executed in a fixed order.
- Khendon

Re: feature request: open a new file in lyx from the shell

[Allan Rae]

On Thu, 17 Jan 2002, John Levon wrote:
[...]
  Perhaps you could rename this option to Rescale bitmap fonts. Or inverse

 I agree. Who else does ?

Pick me.  So long as it only affects bitmap fonts -- do scalable fonts
come in fixed sizes?  Or do we handle scalable fonts any differently
with this option?

Allan. (ARRae)

Re: #188

[Allan Rae]

On Thu, 17 Jan 2002, John Levon wrote:

 On Thu, Jan 17, 2002 at 03:18:44PM +1000, Allan Rae wrote:

  Yeah, this is what insure++ calls a FREE_BODY where libXpm is freeing
  part of the buffer it malloced.  This seems to be okay in that case.

 it's not, it's trying to strcasecmp the name string with a string at 0xb

Then njamd is complaining about something that is suppressed within
insure++ (since it isn't in the code I'm checking).

  This would hide the problem nicely but I think we should instead make
  sure that when we are exporting we should probably have
  InsetInclude::latex() not only load the file if it isn't already but

 eek, a view-dvi has to load 20 chapters ??

It does this anyway since it has to generate the latex from the lyx
files.  On the other hand we don't really want to have to render those
files if we can get away without doing so -- what happens now.

So if we could just get our hands on a minibuffer some other way we'd
be right.

   insetgraphics still needs a lot of work IMHO, but I don't know who's going to do 
it. I had
   a trawl of freshmeat, and it looks like imlib2 and libafterimage are our best 
choices for
   implementing scaling etc. At least of one these offers line-by-line decoding, 
which we can do
   in an xforms idle callback I think.
 
  I think Baruch was hoping to use anything that was available but it
  would be preferable that the same toolkit was used whether scaling was
  needed or not.

 what do you mean ?

Use the same toolkit/library to do the conversion and the scaling if
possible.  And don't tie ourselves to any particular toolkit/library.

Allan. (ARRae)

Re: feature request: open a new file in lyx from the shell

[John Levon]

On Thu, Jan 17, 2002 at 03:40:55PM +1000, Allan Rae wrote:

   Perhaps you could rename this option to Rescale bitmap fonts. Or inverse
 
  I agree. Who else does ?
 
 Pick me.  So long as it only affects bitmap fonts -- do scalable fonts
 come in fixed sizes?  Or do we handle scalable fonts any differently
 with this option?

All this means is we'll request an exact size. Some font servers can scale bitmap
fonts to that size, but it's also the only way of getting the /real/ rasterized font
of a scalable font if that's what we're using. So all it does is turn off the request
for the scaling so we end up using the nearest one when it's a bitmap font and the
server does resizing.

Or so I understand.

regards
john
-- 
Hey, we could invent a programming paradigm where the program is expressed as
a series of statements to be executed in a fixed order.
- Khendon

Re: #188

[Allan Rae]

On Thu, 17 Jan 2002, John Levon wrote:

 Index: graphics/ImageLoaderXPM.C
 ===
 RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/graphics/ImageLoaderXPM.C,v
 retrieving revision 1.12
 diff -u -r1.12 ImageLoaderXPM.C
 --- graphics/ImageLoaderXPM.C   2001/09/21 16:24:28 1.12
 +++ graphics/ImageLoaderXPM.C   2002/01/17 04:49:23
 @@ -77,7 +77,7 @@
 xpm_col.pixel = lyxColorHandler-colorPixel(LColor::graphicsbg);

 XpmAttributes attrib;
 -   attrib.valuemask = XpmCloseness | XpmColorSymbols | XpmColorKey;
 +   attrib.valuemask = XpmCloseness | XpmColorSymbols;

 attrib.closeness = 1;

You meant this warning?

lyxerr  Warning in ImageLoaderXPM::runImageLoader
lyxrc.display_graphics == \
lyxrc.display_graphics

No I didn't see it.  I also have 4.11.

This made no difference to the conversion load errors I got before
either.

 Anyway, I looked at the backtrace with gdb and the problem is :

 (converter.C)

 643 lyxerr[Debug::FILES]  Calling   command  
endl;
 644 if (buffer)
 645 ShowMessage(buffer, _(Executing command:), 
command);

 ShowMessage assumes a BufferView has been generated. buffer-getUser() is 0 - boom

Actually, it should be ShowMessage() that does the check.

Allan. (ARRae)

Re: #188

[Allan Rae]

On Thu, 17 Jan 2002, Allan Rae wrote:

  ShowMessage assumes a BufferView has been generated. buffer-getUser() is 0 - boom

 Actually, it should be ShowMessage() that does the check.

Like this so we at least get it to lyxerr:

diff -u -p -u -p -r1.166 lyx_cb.C
--- lyx_cb.C2002/01/14 23:31:20 1.166
+++ lyx_cb.C2002/01/17 06:10:19
@@ -121,9 +121,10 @@ void ShowMessage(Buffer const * buf,
 string const  msg2,
 string const  msg3)
 {
-   if (lyxrc.use_gui) {
-   string const str = msg1 + ' ' + msg2 + ' ' + msg3;
-   buf-getUser()-owner()-message(str);
+   if (lyxrc.use_gui
+buf  buf-getUser()  buf-getUser()-owner()) {
+   string const str = msg1 + ' ' + msg2 + ' ' + msg3;
+   buf-getUser()-owner()-message(str);
} else
lyxerr  msg1  msg2  msg3  endl;
 }



Allan. (ARRae)

Re: feature request: open a new file in lyx from the shell

[John Levon]

On Thu, Jan 17, 2002 at 03:40:55PM +1000, Allan Rae wrote:

 Pick me.  So long as it only affects bitmap fonts -- do scalable fonts
 come in fixed sizes?  Or do we handle scalable fonts any differently
 with this option?

patch attached, I'll commit to the docs after this is applied

thanks
john

-- 
Hey, we could invent a programming paradigm where the program is expressed as
a series of statements to be executed in a fixed order.
- Khendon


Index: src/frontends/xforms/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/ChangeLog,v
retrieving revision 1.250
diff -u -r1.250 ChangeLog
--- src/frontends/xforms/ChangeLog  2002/01/16 19:24:23 1.250
+++ src/frontends/xforms/ChangeLog  2002/01/17 06:12:44
@@ -1,3 +1,8 @@
+2002-01-17  John Levon  [EMAIL PROTECTED]
+
+   * forms/form_preferences.fd: change Use Scalable Fonts
+ to Rescale bitmap fonts
+ 
 2002-01-16  Angus Leeming  [EMAIL PROTECTED]
 
* FormMathsPanel.C:
Index: src/frontends/xforms/form_preferences.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/form_preferences.C,v
retrieving revision 1.49
diff -u -r1.49 form_preferences.C
--- src/frontends/xforms/form_preferences.C 2002/01/10 15:14:22 1.49
+++ src/frontends/xforms/form_preferences.C 2002/01/17 06:12:46
@@ -81,6 +81,7 @@
   obj = fl_add_box(FL_FLAT_BOX, 0, 0, 455, 375, );
   fdui-tabfolder_outer = obj = fl_add_tabfolder(FL_TOP_TABFOLDER, 0, 0, 455, 375, 
);
 fl_set_object_boxtype(obj, FL_FLAT_BOX);
+fl_set_object_lstyle(obj, FL_BOLD_STYLE);
   fl_end_form();
 
   fdui-form-fdui = fdui;
@@ -116,7 +117,7 @@
   fdui-input_screen_encoding = obj = fl_add_input(FL_NORMAL_INPUT, 145, 130, 140, 
30, _(Encoding));
 fl_set_object_lsize(obj, FL_NORMAL_SIZE);
 fl_set_object_callback(obj, C_FormBaseDeprecatedInputCB, 0);
-  fdui-check_scalable = obj = fl_add_checkbutton(FL_PUSH_BUTTON, 20, 190, 34, 41, 
_(Use scalable fonts));
+  fdui-check_scalable = obj = fl_add_checkbutton(FL_PUSH_BUTTON, 20, 190, 34, 41, 
+_(Rescale bitmap fonts));
 fl_set_object_lsize(obj, FL_NORMAL_SIZE);
 fl_set_object_lalign(obj, FL_ALIGN_RIGHT);
 fl_set_object_callback(obj, C_FormBaseDeprecatedInputCB, 0);
Index: src/frontends/xforms/forms/form_preferences.fd
===
RCS file: 
/usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/forms/form_preferences.fd,v
retrieving revision 1.42
diff -u -r1.42 form_preferences.fd
--- src/frontends/xforms/forms/form_preferences.fd  2002/01/10 15:14:22 1.42
+++ src/frontends/xforms/forms/form_preferences.fd  2002/01/17 06:12:47
@@ -188,7 +188,7 @@
 boxtype: FL_FLAT_BOX
 colors: FL_COL1 FL_COL1
 alignment: FL_ALIGN_TOP_LEFT
-style: FL_NORMAL_STYLE
+style: FL_BOLD_STYLE
 size: FL_DEFAULT_SIZE
 lcol: FL_BLACK
 label: 
@@ -305,7 +305,7 @@
 style: FL_NORMAL_STYLE
 size: FL_NORMAL_SIZE
 lcol: FL_BLACK
-label: Use scalable fonts
+label: Rescale bitmap fonts
 shortcut: 
 resize: FL_RESIZE_ALL
 gravity: FL_NoGravity FL_NoGravity

Re: feature request: open a new file in lyx from the shell

[matthew arnison]

On Thu, 17 Jan 2002, John Levon wrote:

 try

 LYXCMD:hello:file-open:file.lyx

that works. thanks!

in which case, that triggers a bug report: the file-open command isn't
documented or even mentioned in Help - Reference Manual (alteast not in
1.1.6fix3).

  Then you could ship lyx with a little script that opens new documents in a
  running lyx from the command line. You could call it lyxopen or something.

 perhaps.

Maybe this idea could be added as an example in the manual that talks
about the lyxpipes?

Here's how I've just implemented it in bash:

# open a file from the command line in a running lyx
# (spawn a new lyx if needed)
# depends on realpath, a small bianry that returns the full path
# of the given file (realpath is part of the dwww package on debian)
# [EMAIL PROTECTED] jan 02
function lyxopen () { \
lyxpipe=$HOME/local/lyx/lyxpipe.in;
fullpath=`realpath $*`;
if [ -p $lyxpipe ]; then \
command echo LYXCMD:lyxopen:file-open:$fullpath \
 $lyxpipe; \
else \
command lyx $fullpath \
fi \
}

It works, but it depends on a little program called realpath (part of the
dwww debian package) to get the full path of the file concerned. I guess
this could be done instead with perl or something.

But this works for me anyway. :) Because I use pybliographic with lyx to
insert citations (using lyxpipe), it's important for me to only have one
lyx at a time, atleast for documents I'm changing.

Cheers,
Matthew.

Re: feature request: open a new file in lyx from the shell

[Allan Rae]

On Thu, 17 Jan 2002, John Levon wrote:

 On Thu, Jan 17, 2002 at 03:40:55PM +1000, Allan Rae wrote:

  Pick me.  So long as it only affects bitmap fonts -- do scalable fonts
  come in fixed sizes?  Or do we handle scalable fonts any differently
  with this option?

 patch attached, I'll commit to the docs after this is applied

Will commit shortly but I won't let the inner tab have bold headings.
That just takes us back to the problem we had before where people
thought that the tabs were just two levels of tabs rather than an
inner and an outer set.

Allan. (ARRae)

Re: [PATCH]: reducing file dependencies in the frontends

[Martin Vermeer]

On Wed, Jan 16, 2002 at 05:49:56PM +, Angus Leeming wrote:
 
 ChangeLogs please!!
 
 It's nice to know what the patch is meant to do without gooing through every 
 line of the source.
 
 Angus


2002-01-17  Martin Vermeer [EMAIL PROTECTED]

* FormMathPanel.[hC]:
* MathsSymbols.[hC]:
* form_math_panel.[hC]:
* form_math_panel.fd: Modified. Added five symbol sub-panels
to the math panel containing AMS math symbols: arrows, relations,
negated relation, operators and miscellaneous (also containing some
hebrew and corner symbols).

* ams_arrows.xbm:
* ams_rel.xbm:
* ams_nrel.xbm:
* ams_misc.xbm:
* ams_ops.xbm: The bitmap files for the sub-panels. To be ADDED.

Bitmaps attached. This must be freudian, as I am not yet quite happy with 
what they look like (like, should I change the long and narrow 3x22 to a
6x11?)

-- Martin




ams_bitmaps.tar.gz
Description: application/tar-gz


msg31658/pgp0.pgp
Description: PGP signature

Re: feature request: open a new file in lyx from the shell

[John Levon]

On Thu, Jan 17, 2002 at 05:38:58PM +1100, matthew arnison wrote:

 in which case, that triggers a bug report: the file-open command isn't
 documented or even mentioned in Help - Reference Manual (alteast not in
 1.1.6fix3).

The reference manual is sadly out of date, and is likely to remain so (unless you
want to help out ?)

hopefully one day it will be auto-generated.

 Maybe this idea could be added as an example in the manual that talks
 about the lyxpipes?

It should be on Herbert's help pages I think. Herbert ?

   command echo LYXCMD:lyxopen:file-open:$fullpath \

hmm do we require fullpath then ?

regards
john

-- 
Hey, we could invent a programming paradigm where the program is expressed as
a series of statements to be executed in a fixed order.
- Khendon

Re: feature request: open a new file in lyx from the shell

[John Levon]

On Thu, Jan 17, 2002 at 04:40:46PM +1000, Allan Rae wrote:

  On Thu, Jan 17, 2002 at 03:40:55PM +1000, Allan Rae wrote:
 
   Pick me.  So long as it only affects bitmap fonts -- do scalable fonts
   come in fixed sizes?  Or do we handle scalable fonts any differently
   with this option?
 
  patch attached, I'll commit to the docs after this is applied
 
 Will commit shortly but I won't let the inner tab have bold headings.
 That just takes us back to the problem we had before where people
 thought that the tabs were just two levels of tabs rather than an
 inner and an outer set.

oops, didn't mean to include that ( thought I changed outer_tab anyway ??)

regards
john

-- 
Hey, we could invent a programming paradigm where the program is expressed as
a series of statements to be executed in a fixed order.
- Khendon

Re: #188

[Allan Rae]

I've commited a fix to ShowMessage(). This will stop the crash and
still give us a message -- but it will go to the console if it can't
reach a mini-buffer.

This is now a problem with either Minibuffer or InsetInclude depending
upon your POV:  should we ensure a buffer has a BufferView when
loading it as part of a multipart doc (InsetInclude problem) or should
we find a different way to access the minibuffer if we haven't got a
BufferView yet?

Can we access the parent documents BufferView to get its minibuffer
instead? This would save a lot of hassle since that buffer was almost
certainly already visible.

Allan. (ARRae)

Re: feature request: open a new file in lyx from the shell

[Allan Rae]

On Thu, 17 Jan 2002, John Levon wrote:

 oops, didn't mean to include that ( thought I changed outer_tab anyway ??)

You did but maybe we should change the names of the tabs because
currently we have:
prefs_tab
outer_tab

and maybe that should be:

outer_tab
inner_tab

ie.  rename outer_tab to inner_tab (to what it actually is).

Allan. (ARRae)

Re: feature request: open a new file in lyx from the shell

[John Levon]

On Thu, Jan 17, 2002 at 04:57:45PM +1000, Allan Rae wrote:

 ie.  rename outer_tab to inner_tab (to what it actually is).

please :)

john

-- 
Hey, we could invent a programming paradigm where the program is expressed as
a series of statements to be executed in a fixed order.
- Khendon

Re: feature request: open a new file in lyx from the shell

[Allan Rae]

On Thu, 17 Jan 2002, John Levon wrote:

 patch attached, I'll commit to the docs after this is applied

Actually, the help message that appears when the cursor is over the
checkbox is very misleading.  Care to rewrite that as well?

Allan. (ARRae)

[PATCH] More GNOME frontend cleanups

[Michael Koziarski]

Hey guys,

I've made a few changes to the structure of the gnome frontend.
Simplified the constructor, moved common functionality into the
GnomeBase class.  This patch doesn't fix the problem I've been having
with OK being called twice, I hope to have another look at that this
weekend, but it simplifies and cleans everything a bit.

The diff is attached.

The new files required are available at:
http://www.koziarski.org/new-files.tar.gz

Could someone apply it and add the new files?

Cheers


-- 

| Michael Koziarski   |"Conventional wisdom is often   |
| Data Engineer, Linux user   | long on convention and short   |
| & Objectivist.  | on wisdom" --  |
| http://www.koziarski.com| Warren E. Buffett, BRK.A   |

[PATCH] Really this time

[Michael Koziarski]

Managed to miss out attaching the patch.

Here it is,  the url for the new files is still 

http://www.koziarski.org/new-files.tar.gz

Cheers


-- 

| Michael Koziarski   |"Conventional wisdom is often   |
| Data Engineer, Linux user   | long on convention and short   |
| & Objectivist.  | on wisdom" --  |
| http://www.koziarski.com| Warren E. Buffett, BRK.A   |



new-files.tar.gz
Description: GNU Zip compressed data

Re: 10 more bugs now...

[Allan Rae]

On Tue, 15 Jan 2002, Allan Rae wrote:

>
> Take a look at Bugzilla #174.  I have attached an insure++ report with
> details of dangling pointers and where they were released.

I have a fix for #174 but sadly it seems that another crash can result
elsewhere.  It looks like something at a higher level may make a
similar mistake to the below.  I'll investigate that now -- may as
well use insure again and see what it says about my fix.


Index: text.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text.C,v
retrieving revision 1.224
diff -u -p -u -p -r1.224 text.C
--- text.C  2002/01/15 11:44:16 1.224
+++ text.C  2002/01/16 09:11:45
@@ -485,9 +485,12 @@ void LyXText::drawInset(DrawRowParams &
Row * prev = p.row->previous();
if (prev && prev->par() == p.row->par()) {
breakAgainOneRow(p.bv, prev);
-   }
+   // breakAgainOneRow() may have removed p.row
+   need_break_row = prev->next();
+   } else {
+   need_break_row = p.row;
+   }
setCursor(p.bv, cursor.par(), cursor.pos());
-   need_break_row = p.row;
}
 }

Allan. (ARRae)

Re: reducing compile times

[Angus Leeming]

On Wednesday 16 January 2002 7:25 am, Andre Poenitz wrote:
> On Tue, Jan 15, 2002 at 06:16:34PM +, Angus Leeming wrote:
> > It works like a dream here and I can see no issues associated with this. 
Do 
> > those more knowledgable than I have any problems with it? If not, I'd 
like to 
> > submit the change.
> 
> You are able to put templated _definitions_ in the .C and it works? 
> 
> Andre', slightly astonished.

Sure, because these classes are base classes for 8 others. If, when I make 
these 8 classes I also make the template base classes, then all is fine.

Make sense?

Angus

Re: lib/examples/mathed.lyx

[Angus Leeming]

On Tuesday 15 January 2002 8:05 pm, Dekel Tsur wrote:
> On Tue, Jan 15, 2002 at 04:29:50PM +, Angus Leeming wrote:
> > 
> > José, I've just improved mathed.lyx so that the fonts-xlfd file how 
contains 
> > the right fonts. Perhaps you'd throw in a few lines about what you had to 
do 
> > to get things working under redhat?
> 
> I want to move the script out of mathed.lyx into a file.
> Where should I put it: lib/scripts or lib/ ?
> Also, we currently use font names like -bluesky-cmr-*
> It has suggested that we use more meaningful names: e.g.
>   -bluesky-Computer Modern Roman-*
> Any thoughts on this ?

None from me. I just wanted all this documented somewhere.
Makes a lot of sense though.

Angus

Re: [PATCH] Really this time

[Michael Koziarski]

> I think you attached the new files tarball, rather than the patch.
> 
> 
> -- 
> Kayvan A. Sylvan  | Proud husband of   | Father to my kids:
> Sylvan Associates, Inc.   | Laura Isabella Sylvan  | Katherine Yelena (8/8/89)
> http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92)

Third time's a charm.

I blame work.



-- 

| Michael Koziarski   |"Conventional wisdom is often   |
| Data Engineer, Linux user   | long on convention and short   |
| & Objectivist.  | on wisdom" --  |
| http://www.koziarski.com| Warren E. Buffett, BRK.A   |



gnome.diff.gz
Description: GNU Zip compressed data

Re: reducing compile times

[Andre Poenitz]

On Wed, Jan 16, 2002 at 09:34:38AM +, Angus Leeming wrote:
> > Andre', slightly astonished.
> 
> Sure, because these classes are base classes for 8 others. If, when I make 
> these 8 classes I also make the template base classes, then all is fine.
> 
> Make sense?

Now that I read in Lars' reply that you #include the full definition when
needed, it makes sense.

I thought your compiler was implements 'export' and uses it even without
being told so. And that would have been close to a wonder.  Of course,
splitting the templated stuff into a .h and some .t or .tmpl and including
the .tmpl only if needed is fine.

andre'

-- 
André Pönitz .. [EMAIL PROTECTED]

Re: Look Ma, no macros! (Re: Brush-up on Blackboard Bold)

[Dekel Tsur]

On Wed, Jan 16, 2002 at 08:57:32AM +0200, Martin Vermeer wrote:
> > Using ps2epsi+imagemagick, you can convert directly from Postscript to a
> > bitmap format with anti-aliasing, with no need for manual fix.
> 
> Thanks! I'll try that.

Actually, imagemagick uses Ghostscript, and Ghostscript doesn't do a good
work at low res rendering.
A better option may be to capture the lyx screen (assuming that you use the
latex Postscript font. However, this method is not scriptable ) or to write
a C program that uses freetype in order to render the images.

> > Does the xbm format support grey-scale images ?
> 
> No.
> 
> > If not, can we use xpm ?
> 
> Actually I am happy with xbm for this use... in the xforms front-end I
> think it is OK.

If you use xpm, you have a decent result from imagemagic due to anti-aliasing.
See attached files.



test.xbm
Description: X bitmap


test.xpm
Description: X pixmap

Re: Three radiobuttons on delim pop-up

[Martin Vermeer]

On Tue, Jan 15, 2002 at 04:44:11PM +0200, Martin Vermeer wrote:
> On Tue, Jan 15, 2002 at 12:56:39PM +, Angus Leeming wrote:
>  
> > On Tuesday 15 January 2002 9:52 am, Martin Vermeer wrote:

...
 
> Otherwise I think both patches can go into CVS as they do not touch "deep"
> functionality, just user interface. The only wart as I said is that you don't
> get latexed your mathbb's or mathcals without AmsMath turned on -- this may
> bite a few inexperienced users. 
> 
> 
> -- Martin
 
Answering to myself, the attached patch fixes this problem for me. There seemed 
to be a bug in thne auto-usepackage-include thingy, which leads to the inclusion 
of amsmath, when in fact amssymb is need for \mathbb (for \mathcal, either will do).

Before committing this, I would like to hear from whoever wrote this code originally 
(André?) that this is indeed a simple mistake or "human logic bug", and won't have 
repercussions elsewhere.

Note that amssymb also allows the use of the huge number of AMS symbols listed in
the LaTeX Companion. Expect a patch at some time in the future :-)

-- Martin



Index: math_hullinset.C
===
RCS file: /cvs/lyx/lyx-devel/src/mathed/math_hullinset.C,v
retrieving revision 1.14
diff -u -p -r1.14 math_hullinset.C
--- math_hullinset.C2002/01/10 10:05:45 1.14
+++ math_hullinset.C2002/01/16 10:48:31
@@ -261,7 +261,7 @@ bool MathHullInset::numberedType() const
 void MathHullInset::validate(LaTeXFeatures & features) const
 {
if (ams())
-   features.require("amsmath");
+   features.require("amssymb");
 
 
// Validation is necessary only if not using AMS math.



msg31593/pgp0.pgp
Description: PGP signature

Request to our TeXperts!

[Juergen Vigna]

There is a problem when using multiple paragraphs inside a multicolumn cell.
Is this not permitted? Or how is the right LaTeX code to do this?
Well I investigated a bit and it seems that latex produces errors only if
we have the tabular inside a f.ex.: \textsf{}. Actually the
whole stuff has nothing to do with multicolumns. This is just a problem
of the above font-family change and having multiple paragraphs inside a
tabular cell!

Have a look at: http://cvs.koziarski.com/show_bug.cgi?id=172
and download the testcase lyx-file to have a example of the bug.

Gratefull for any hint!

   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
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

That's the thing about people who think they hate computers.  What they
really hate is lousy programmers.
- Larry Niven and Jerry Pournelle in "Oath of Fealty"

Re: Look Ma, no macros! (Re: Brush-up on Blackboard Bold)

[Jules Bean]

On Wed, Jan 16, 2002 at 12:42:40PM +0200, Dekel Tsur wrote:
> On Wed, Jan 16, 2002 at 08:57:32AM +0200, Martin Vermeer wrote:
> > > Using ps2epsi+imagemagick, you can convert directly from Postscript to a
> > > bitmap format with anti-aliasing, with no need for manual fix.
> > 
> > Thanks! I'll try that.
> 
> Actually, imagemagick uses Ghostscript, and Ghostscript doesn't do a good
> work at low res rendering.

Even with -dTextAlphaBits=4 ?

Jules

Re: Request to our TeXperts!

[Jules Bean]

On Wed, Jan 16, 2002 at 12:19:02PM +0100, Juergen Vigna wrote:
> There is a problem when using multiple paragraphs inside a multicolumn cell.
> Is this not permitted? Or how is the right LaTeX code to do this?
> Well I investigated a bit and it seems that latex produces errors only if
> we have the tabular inside a f.ex.: \textsf{}. Actually the
> whole stuff has nothing to do with multicolumns. This is just a problem
> of the above font-family change and having multiple paragraphs inside a
> tabular cell!

I don't have CVS LyX, but I'm happy to look at LaTeX.  If you email me
a minimal .tex exhibiting the bug, I'll try to fix it.

Jules

[PATCH]: reducing file dependencies in the frontends

[Angus Leeming]

The patch attached reduces file dependencies in the frontends enormously by 
moving template class declarations into three new .tmpl files and only 
including these files in the .C files of the derived classes.

Changing anything in ButtonController.h, ControlDialogs.h or ControlInset.h 
results in the recompilation of 56, 29 and 31 files, respectively! Since 
these files contained not only the class definition, but the class 
declaration also, such changes occurred relatively frequently. Now that the 
declaration of the functions has been moved into the .tmpl files, here are 
the stats:

touch frontends/controllers/ButtonController.tmpl and recompile
frontends/xforms/Dialogs.C
frontends/xforms/xformsBC.C

touch frontends/controllers/ControlDialog.tmpl and recompile
frontends/controllers/ControlDialog_impl.C

touch frontends/controllers/ControlInset.tmpl and recompile
frontends/controllers/ControlCommand.C
frontends/controllers/ControlError.C
frontends/controllers/ControlERT.C
frontends/controllers/ControlExternal.C
frontends/controllers/ControlFloat.C
frontends/controllers/ControlGraphics.C
frontends/controllers/ControlInclude.C
frontends/controllers/ControlMinipage.C

So the advantage is clear. Nonetheless, I attach the patch, rather than 
submit immediately, so that the experts can have a look first. Please do so!

Note that the changes to the gui-specific frontends code is minimal. See the 
xforms ChangeLog entry.

One small question. Should I put the three .tmpl files in 
frontends/controllers/Makefile.am?

Regards,
Angus



dependencies.diff.bz2
Description: BZip2 compressed data

Re: Request to our TeXperts!

[Juergen Vigna]

On 16-Jan-2002 Jules Bean wrote:
> On Wed, Jan 16, 2002 at 12:19:02PM +0100, Juergen Vigna wrote:
>> There is a problem when using multiple paragraphs inside a multicolumn cell.
>> Is this not permitted? Or how is the right LaTeX code to do this?
>> Well I investigated a bit and it seems that latex produces errors only if
>> we have the tabular inside a f.ex.: \textsf{}. Actually the
>> whole stuff has nothing to do with multicolumns. This is just a problem
>> of the above font-family change and having multiple paragraphs inside a
>> tabular cell!
> 
> I don't have CVS LyX, but I'm happy to look at LaTeX.  If you email me
> a minimal .tex exhibiting the bug, I'll try to fix it.

Well here it is! If you remove \texttt{ before \begin{tabular} and the
} after \end{tabular} all is ok but asis it will give errors.

Thanks for your help!

   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
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Love is a grave mental disease.
-- Plato



%% LyX 1.2 created this file.  For more info, see http://www.lyx.org/.
%% Do not edit unless you really know what you are doing.
\documentclass[12pt,a4paper,german]{article}
\usepackage[T1]{fontenc}
\usepackage[latin2]{inputenc}
\setlength\parskip{\medskipamount}
\setlength\parindent{0pt}

\makeatletter

%% LyX specific LaTeX commands.
\providecommand{\LyX}{L\kern-.1667em\lower.25em\hbox{Y}\kern-.125emX\@}

\makeatother
\usepackage{babel}
\begin{document}
\texttt{\begin{tabular}{|p{6cm}|c|}
\hline 
\texttt{dfasdfasdf sdf asdf}

\texttt{sdf asdfasdf asdf}

\texttt{sdf asdfasdfasdf}&
\\
\hline
\hline 
&
\\
\hline
\end{tabular}}
\end{document}

Re: [PATCH]: reducing file dependencies in the frontends

[Allan Rae]

Nice work.

Although just looking at the diff there seems to be a lot of this
going on:

-   ///
-   BP bp_;
+   ///
+   BP bp_;

They should just be tabs so what is changing?

I'm also glad that there aren't any _("blah blah") strings in the
.tmpl files otherwise we'd need some wacky changes to the
po/Makefile.in.in (in which case a .T extension might be better).

> One small question. Should I put the three .tmpl files in
> frontends/controllers/Makefile.am?

Like Lars said.

Allan. (ARRae)

Re: reducing compile times

[Angus Leeming]

On Wednesday 16 January 2002 3:33 am, Allan Rae wrote:
[snip my original message]
> Maybe ControlDialog_impl.[Ch] instead (like a _pimpl only different).

Nice. Done.

> Secondly, I think we should wait with this change (the other is
> probably okay) until after 1.2.0 and we've have time to discuss
> reorganizing the GUII hierarchy.  We may well do something like this
> then anyway.

Nah! I've just been trying to track down Michael Koziarski's problems with 
the gnome frontend and any change I made to ControlInset.h required the 
recompilation of vast numbers of files. Since I can't compile gnome on this 
box I didn't track down his problem (although I did find a bug!) so he's 
going to have to do the tracking himself. He's not going to be happy printing 
out things in the methods of CntrolInset if he has to recompile the entire 
frontend each time, now is he?

Anyway, the change I've made changes none of the classes at all, and 
therefore cannot break anything. If the code compiles and links, then all is 
Ok.

> Take a few minutes to draw out the GUII hierarchy (or work from
> doxygen) and you'll see it is a great big long thin vine.  It is
> possible to rearrange this into a broad flat tree -- fewer intervening
> classes needing recompiles.

Sure. I understand this.

Coping in the heat Ok?

Regards,
Angus

Re: [PATCH]: reducing file dependencies in the frontends

[Angus Leeming]

On Wednesday 16 January 2002 12:58 pm, Allan Rae wrote:
> Nice work.
> 
> Although just looking at the diff there seems to be a lot of this
> going on:
> 
> -   ///
> -   BP bp_;
> +   ///
> +   BP bp_;
> 
> They should just be tabs so what is changing?

Well spotted. They are no longer tabs. I'll fix those.

> I'm also glad that there aren't any _("blah blah") strings in the
> .tmpl files otherwise we'd need some wacky changes to the
> po/Makefile.in.in (in which case a .T extension might be better).
> 
> > One small question. Should I put the three .tmpl files in
> > frontends/controllers/Makefile.am?
> 
> Like Lars said.

Done that.

Thanks both.
Angus

bug #174

[Allan Rae]

I've just checked in a fix.

Two fixes actually, and one of them I'd have thought we'd hit by now.

LyXText::deleteRow() forgot to check refresh_row.  I set this to:
refresh_row = row_prev ? row_prev : row->next();

since I figure there must be some reason why refresh_row was set and
it would be unlikely that we'd delete the first row of a multirow
paragraph.

Anyway the interesting part is in LyXText::drawInset() where we got
partly screwed because p.row just got deleted so I changed it to a
valid row -- what else could I do?  Should I also try to fix the p.x
and p.y values?  Seems to work without doing that.

If someone more familiar with rebreaking could take a look and decide
whether I should/could set need_break_row differently if p.row was
just removed:

if (prev && prev->par() == p.row->par()) {
breakAgainOneRow(p.bv, prev);
// breakAgainOneRow() may have removed p.row
// What about the x and y coordinates? par & pos ok.
if (prev->next() != p.row) {
p.row = prev;
}
// If there's only one row (after p.row was deleted)
// prev->next() == 0 and no breaking is required.
// Otherwise, check the new next row.
==> need_break_row = prev->next();
} else {
need_break_row = p.row;
}

If p.row was deleted it must have been the last row of a paragraph so
we could set need_break_row = 0 couldn't we?  As in:

if (prev && prev->par() == p.row->par()) {
breakAgainOneRow(p.bv, prev);
// breakAgainOneRow() may have removed p.row
// What about the x and y coordinates? par & pos ok.
if (prev->next() != p.row) {
p.row = prev;
need_break_row = 0;
} else {
need_break_row = p.row;
}
} else {
need_break_row = p.row;
}

Allan. (ARRae)

Re: Look Ma, no macros! (Re: Brush-up on Blackboard Bold)

[Dekel Tsur]

On Wed, Jan 16, 2002 at 11:52:29AM +, Jules Bean wrote:
> > Actually, imagemagick uses Ghostscript, and Ghostscript doesn't do a good
> > work at low res rendering.
> 
> Even with -dTextAlphaBits=4 ?

What is it supposed to do ?

Re: reducing compile times

[Allan Rae]

On Wed, 16 Jan 2002, Angus Leeming wrote:
[...agree with the rest...]

> Coping in the heat Ok?

Guess what!  It bucketed down rain and is now somewhat cooler.
Mind you those couple of really hot days I just hid here at uni in the
airconditioning.

Allan. (ARRae)

Re: Three radiobuttons on delim pop-up

[Dekel Tsur]

On Wed, Jan 16, 2002 at 01:09:33PM +0200, Martin Vermeer wrote:

> Index: math_hullinset.C
> ===
> RCS file: /cvs/lyx/lyx-devel/src/mathed/math_hullinset.C,v
> retrieving revision 1.14
> diff -u -p -r1.14 math_hullinset.C
> --- math_hullinset.C  2002/01/10 10:05:45 1.14
> +++ math_hullinset.C  2002/01/16 10:48:31
> @@ -261,7 +261,7 @@ bool MathHullInset::numberedType() const
>  void MathHullInset::validate(LaTeXFeatures & features) const
>  {
>   if (ams())
> - features.require("amsmath");
> + features.require("amssymb");

No, it should be amsmath.
Enabling amssymb should be done in the ::validate methods of 
MathStringInset and MathSymbolInset (which don't exist yet).

Re: [PATCH]: reducing file dependencies in the frontends

[Andre Poenitz]

On Wed, Jan 16, 2002 at 10:58:45PM +1000, Allan Rae wrote:
> They should just be tabs so what is changing?

White space on the end of the line perhaps?

Andre'
 
-- 
André Pönitz .. [EMAIL PROTECTED]

Re: ControlInset failling Assert()

[Allan Rae]

On Tue, 15 Jan 2002, Angus Leeming wrote:
[...]
> Nonetheless, I think you've hit on a bug. Well done! Although I don't think
> it'll help solve your problem, the fix to that particular problem is:
>
> template 
> void ControlInset::apply()
> {
>   if (lv_.buffer()->isReadonly())
>   return;
>
>   view().apply();
>
> - if (inset_ && params() != getParams(*inset_))
> + if (inset_)
> + if (params() != getParams(*inset_))
>   applyParamsToInset();
>   else
>   applyParamsNoInset();

I hope you realise you just made another bug with nested else because
that will be interpreted as:

if (inset_) {
if (params() != getParams(*inset_)) {
applyParamsToInset();
} else {
applyParamsNoInset();
}
}

instead of what you really wanted:

if (inset_) {
if (params() != getParams(*inset_)) {
applyParamsToInset();
}
} else {
applyParamsNoInset();
}

Allan. (ARRae)

Re: [PATCH]: reducing file dependencies in the frontends

[Allan Rae]

On Wed, 16 Jan 2002, Andre Poenitz wrote:

> On Wed, Jan 16, 2002 at 10:58:45PM +1000, Allan Rae wrote:
> > They should just be tabs so what is changing?
>
> White space on the end of the line perhaps?

That would show up by selecting the area with your mouse. However, tab
to space conversions usually don't show up when viewing a diff with
more or less.

Allan. (ARRae)

Re: ControlInset failling Assert()

[Angus Leeming]

On Wednesday 16 January 2002 1:37 pm, Allan Rae wrote:
> On Tue, 15 Jan 2002, Angus Leeming wrote:
> [...]
> > Nonetheless, I think you've hit on a bug. Well done! Although I don't 
think
> > it'll help solve your problem, the fix to that particular problem is:
> >
> > template 
> > void ControlInset::apply()
> > {
> > if (lv_.buffer()->isReadonly())
> > return;
> >
> > view().apply();
> >
> > -   if (inset_ && params() != getParams(*inset_))
> > +   if (inset_)
> > +   if (params() != getParams(*inset_))
> > applyParamsToInset();
> > else
> > applyParamsNoInset();
> 
> I hope you realise you just made another bug with nested else because
> that will be interpreted as:
> 
>   if (inset_) {
>   if (params() != getParams(*inset_)) {
>   applyParamsToInset();
>   } else {
>   applyParamsNoInset();
>   }
>   }
> 
> instead of what you really wanted:
> 
>   if (inset_) {
>   if (params() != getParams(*inset_)) {
>   applyParamsToInset();
>   }
>   } else {
>   applyParamsNoInset();
>   }
> 
> Allan. (ARRae)

Smart-arse!

Thanks,
Angus (who's fxing it now).