LyX Version 1.1.6fix2 - Einstellungen -> Farbe
2 suggestions:
- the field "LyX Objekte" should be sorted alphabetically to find objects easier
- the field with the RGB values should be editable because small changes are not easy
to achieve with sliding
--
Regards,
Hartmut Haase
Hungerhilfe: http://www.thehungersite.com
ATTAC - für eine solidarische Weltwirtschaft
gegen neoliberale Globalisierung: http://www.attac-netzwerk.de
www
(o o)
+---oOO--(_)--OOo---+
| Hartmut Haase | Tel/Fax:|
| Im Bild 3 | {49|0}7544-3117 |
| D-88697 Bermatingen | |
|---|
| Dummheit und Stolz sind aus gleichem Holz |
+---+
__
Keinen Jackpot mehr verpassen! Mit dem Dauerschein des WEB.DE Lottoservice.
Einfach und bequem Lotto tippen! http://tippen2.web.de/?x=4
LyX Version 1.1.6fix2 - Einstellungen -> Farbe
2 suggestions:
- the field "LyX Objekte" should be sorted alphabetically to find objects easier
- the field with the RGB values should be editable because small changes are not easy
to achieve with sliding
--
Regards,
Hartmut Haase
Hungerhilfe: http://www.thehungersite.com
ATTAC - für eine solidarische Weltwirtschaft
gegen neoliberale Globalisierung: http://www.attac-netzwerk.de
www
(o o)
+---oOO--(_)--OOo---+
| Hartmut Haase | Tel/Fax:|
| Im Bild 3 | {49|0}7544-3117 |
| D-88697 Bermatingen | |
|---|
| Dummheit und Stolz sind aus gleichem Holz |
+---+
Berufsunfähigskeitversicherung von Mamax bei WEB.DE.
Jetzt informieren! http://bu.web.de
Re: Bug list - Update again
This bug is a lot harder to trigger now after my recent fixes but it is still there just harder to trigger. I have noticed though that either cut or copy or both (common code?) doesn't seem to be copying insets (either at all or at least not in a way that is past[e?]able _or_ paste can't paste insets anymore -- this is _not_ due to my changes it existed previously also). So, who wants to answer some of the questions below? Allan. On Thu, 15 Nov 2001, Allan Rae wrote: > > - Cut all text from a note with two paragraphs and paste it right in > front of the now empty note (same par!) -> Stack overflow > > This is true for any InsetText-based inset (eg. figure float) and you > don't have to cut you can copy and paste also. The part about pasting > into the same paragraph is significant though. > > Can someone (Juergen?) tell me the purpose of the inset parameter for > InsetText::getMaxWidth (bv, inset) at insettext.C:1901 > > Nothing uses it. So was it leftover from previous code or added but > incomplete? Is there any reason why recursive code was used? Or was > someone planning on replacing it with an iterative solution? (Is this > where the discussions about paragraph/inset iterators I've seen but > not really read come in?) > > There is also an interesting pattern in the backtrace below which was > generated by starting a new document, insert a figure float, write one > word in the float, select with left mouse button and paste with > middle mouse button just before the inset (you can close it first if > you want to, it doesn't make any difference) > > UpdateableInset::getMaxWidth is where we're hoping the recursion will > stop -- since owner() should be 0x0 at some stage (hopefully in the > outermost InsetText which is also where we start the sequence...) > > It would seem from inset.C:315/316 that someone is hoping to be > calling UpdateableInset::getMaxWidth but gdb is reporting that > InsetCollapsible::getMaxWidth is getting called instead. IIRC, > Juergen was complaining about this sometime ago but I only skimmed > through those discussions. > > Any hints? > > #209593 0x081167a1 in UpdatableInset::getMaxWidth (this=0x82ec538, bv=0x82a77a8) at >inset.C:316 > #209594 0x08137942 in InsetCollapsable::getMaxWidth (this=0x82ec538, bv=0x82a77a8, >in=0x82ec590) at insetcollapsable.C:395 > #209595 0x081167a1 in UpdatableInset::getMaxWidth (this=0x82ec590, bv=0x82a77a8) at >inset.C:316 > #209596 0x08133e4a in InsetText::getMaxWidth (this=0x82ec590, bv=0x82a77a8, >inset=0x82ec538) at insettext.C:1915 > #209597 0x081167a1 in UpdatableInset::getMaxWidth (this=0x82ec538, bv=0x82a77a8) at >inset.C:316 > #209598 0x08137942 in InsetCollapsable::getMaxWidth (this=0x82ec538, bv=0x82a77a8, >in=0x82ec590) at insetcollapsable.C:395 > #209599 0x081167a1 in UpdatableInset::getMaxWidth (this=0x82ec590, bv=0x82a77a8) at >inset.C:316 > #209600 0x08133e4a in InsetText::getMaxWidth (this=0x82ec590, bv=0x82a77a8, >inset=0x82ec538) at insettext.C:1915 > #209601 0x081167a1 in UpdatableInset::getMaxWidth (this=0x82ec538, bv=0x82a77a8) at >inset.C:316 > #209602 0x08137942 in InsetCollapsable::getMaxWidth (this=0x82ec538, bv=0x82a77a8, >in=0x82ec590) at insetcollapsable.C:395 > #209603 0x081167a1 in UpdatableInset::getMaxWidth (this=0x82ec590, bv=0x82a77a8) at >inset.C:316 > #209604 0x08133e4a in InsetText::getMaxWidth (this=0x82ec590, bv=0x82a77a8, >inset=0x82ec590) at insettext.C:1915 > #209605 0x0812eef1 in InsetText::textWidth (this=0x82ec590, bv=0x82a77a8, >fordraw=false) at insettext.C:330 > #209606 0x080d1483 in LyXText::workWidth (this=0x82edba0, bview=0x82a77a8) at >text.C:60 > #209607 0x080d78c0 in LyXText::prepareToPrint (this=0x82edba0, bview=0x82a77a8, >row=0x82d1ed0, x=@0xbfffefc0, fill_separator=@0xbfffefc4, fill_hfill=@0xbfffefc8, >fill_label_hfill=@0xbfffefcc, bidi=true) at text.C:2044 > #209608 0x080e39de in LyXText::setCursor (this=0x82edba0, bview=0x82a77a8, >cur=@0x82edc2c, par=0x82ca1d0, pos=4, boundary=false) at text2.C:2123 > #209609 0x080e3f31 in LyXText::setCursorIntern (this=0x82edba0, bview=0x82a77a8, >par=0x82ca1d0, pos=4, setfont=true, boundary=false) at text2.C:2214 > #209610 0x080e3f0c in LyXText::setCursorIntern (this=0x82eaf98, bview=0x82a77a8, >par=0x82ca1d0, pos=4, setfont=true, boundary=false) at text2.C:2209 > #209611 0x080e3922 in LyXText::setCursor (this=0x82eaf98, bview=0x82a77a8, >par=0x82ca1d0, pos=4, setfont=true, boundary=false) at text2.C:2097 > #209612 0x080e2dfc in LyXText::pasteSelection (this=0x82eaf98, bview=0x82a77a8) at >text2.C:1849 > #209613 0x0805128d in BufferView::paste (this=0x82a77a8) at BufferView2.C:324 > #209614 0x08057246 in BufferView::Pimpl::Dispatch (this=0x82a7e58, >action=LFUN_PASTE, argument=@0xb530) at BufferView_pimpl.C:1509 > #209615 0x08050145 in BufferView::Dispatch (this=0x82a77a8, action=LFUN_PASTE, >argument=@0xb530) at BufferView.C:294 > #209616 0x080ac5ba in LyXFunc::dispatch (this=0x8273c90, ac=19, >do_not
Re: reliability of par->getInset()
On Thu, 22 Nov 2001, John Levon wrote: > is getInset still failing to find insets after a par->isInset returns true ? > > There is still a lot of code that checks getInset return is non-null before > using it, and it looks ugly. > > How old is the code that could cause this to happen; is it still there ? Good questions. I did manage to get an abort() in getInset from the lyx::Assert(pos < size()) I'm not if this is my newest changes triggering something else or what. I think I'll still commit them anyway because they appear to work correctly. I couldn't find anything useful when trying to debug it. And I'm not even sure what I did to trigger it because I had opened the Documents menu and then selected some file and the menu was only partly cleared and then I thought "I'll click it again and see what happens." The mouse must have been over an inset, probably a figure float, when I clicked on what was the partly cleared Documents menu. Result: Program received signal SIGABRT, Aborted. 0x0036f2d1 in kill () from /lib/libc.so.6 (gdb) bt #0 0x0036f2d1 in kill () from /lib/libc.so.6 #1 0x0036f0d5 in raise () from /lib/libc.so.6 #2 0x00370703 in abort () from /lib/libc.so.6 #3 0x0819f0ab in Letext () at abort.C:9 #4 0x080bd065 in Paragraph::getInset (this=0x83e83d8, pos=63) at support/LAssert.h:24 #5 0x08132c91 in InsetText::lockInsetInInset (this=0x83df040, bv=0x82aa2b0, inset=0x83defe8) at insettext.C:779 #6 0x0813a3ad in InsetCollapsable::lockInsetInInset (this=0x83defe8, bv=0x82aa2b0, in=0x83defe8) at insetcollapsable.C:434 #7 0x08051554 in BufferView::lockInset (this=0x82aa2b0, inset=0x83defe8) at BufferView2.C:405 #8 0x08139dfd in InsetCollapsable::edit (this=0x83defe8, bv=0x82aa2b0, xp=159, yp=0, button=0) at insetcollapsable.C:249 #9 0x08056053 in BufferView::Pimpl::insetWakeup (this=0x82aa410) at BufferView_pimpl.C:1236 #10 0x080533f0 in BufferView::Pimpl::buffer (this=0x82aa410, b=0x82d4710) at BufferView_pimpl.C:212 #11 0x0804fc59 in BufferView::buffer (this=0x82aa2b0, b=0x82d4710) at BufferView.C:70 #12 0x080abebd in LyXFunc::dispatch (this=0x82761d0, ac=655, do_not_use_this_arg=@0xb57c) at lyxfunc.C:1282 #13 0x0818203a in Menubar::Pimpl::MenuCallback (ob=0x82a5a50, button=1) at Menubar_pimpl.C:575 #14 0x0817ed86 in C_Menubar_Pimpl_MenuCallback (ob=0x82a5a50, button=1) at Menubar_pimpl.C:79 #15 0x001568bf in fl_object_qread () from /usr/local/lib/libforms.so.0.88 #16 0x00164b79 in fl_check_forms () from /usr/local/lib/libforms.so.0.88 #17 0x081436fd in GUIRunTime::runTime () at GUIRunTime.C:86 #18 0x080a14b8 in LyXGUI::runTime (this=0x8265e68) at lyx_gui.C:315 #19 0x080a2518 in LyX::LyX (this=0xb6f0, argc=0xb710, argv=0xb774) at ../src/lyx_main.C:176 #20 0x080ba9f1 in main (argc=1, argv=0xb774) at ../src/main.C:38 #21 0x0035e1f0 in __libc_start_main () from /lib/libc.so.6 Allan. (ARRae)
changes
hi again so sorry,i forgot to send send u the persian keymap i attached it and also others again ... Mehdi Adibi patch.tar.gz Description: GNU Zip compressed data
Re: problem with pdf file generated using LyX
Aah.. thanks a lot.. I just read section 3.3.6 of Extended features and now it works beautifully! Thanks again.. nirmal Dekel Tsur wrote: > On Wed, Nov 21, 2001 at 11:26:57AM -0500, Nirmal Govind wrote: > > >>The pdf file generated using LyX has all the characters showing up very >>poorly - the fonts are messed up and so the document looks very shabby. >>I know that the pdflatex on my machine (windows2000) works fine cos any >>tex file that I edit myself and use pdflatex on produces a good looking >>pdf file whereas if I use LyX directly or convert the LyX file to Tex >>and use pdflatex, I get a horrible looking document. >> >>Anyone know a fix to this problem? I assume it has something to do with >>the packages that LyX uses by default? >> > > Read section 3.3.6 of Extended.lyx > If you are lazy to read it, then all you need to do is either > - Select ae font in the document dialog > or > - Change font encoding to default in the preferences dialog. > > >
make doxydoc
I just upgraded to doxygen 1.2.12 (from 1.2.6) and can now see "Collaboration diagrams." Shit we have some messy looking interactions between some classes. At least now, doxygen provides some interesting help in visualising what the hell is going on. Allan. (ARRae)
[PATCH] isInset()
clean up to use isInset()
thanks
john
--
"Your superior intellect is no match for our puny weapons."
Index: src/BufferView2.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView2.C,v
retrieving revision 1.95
diff -u -r1.95 BufferView2.C
--- src/BufferView2.C 2001/10/01 15:31:57 1.95
+++ src/BufferView2.C 2001/11/22 02:01:45
@@ -415,8 +415,7 @@
Inset * locking_inset = theLockingInset()->getLockingInset();
if ((cursor.pos() - 1 >= 0) &&
- (cursor.par()->getChar(cursor.pos() - 1) ==
-Paragraph::META_INSET) &&
+ cursor.par()->isInset(cursor.pos() - 1) &&
(cursor.par()->getInset(cursor.pos() - 1) ==
locking_inset))
text->setCursor(this, cursor,
Index: src/BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.173
diff -u -r1.173 BufferView_pimpl.C
--- src/BufferView_pimpl.C 2001/11/13 14:47:32 1.173
+++ src/BufferView_pimpl.C 2001/11/22 02:01:57
@@ -855,7 +855,7 @@
if (cursor.pos() < cursor.par()->size()
- && isMetaInset(cursor.par(), cursor.pos())
+ && cursor.par()->isInset(cursor.pos())
&& isEditableInset(cursor.par()->getInset(cursor.pos( {
// Check whether the inset really was hit
@@ -880,7 +880,7 @@
}
if ((cursor.pos() - 1 >= 0) &&
- isMetaInset(cursor.par(), cursor.pos() - 1) &&
+ cursor.par()->isInset(cursor.pos() - 1) &&
isEditableInset(cursor.par()->getInset(cursor.pos() - 1))) {
Inset * tmpinset = cursor.par()->getInset(cursor.pos()-1);
LyXFont font = text->getFont(buffer_, cursor.par(),
@@ -1833,7 +1833,7 @@
if (is_rtl)
lt->cursorLeft(bv_, false);
if (lt->cursor.pos() < lt->cursor.par()->size()
- && isMetaInset(lt->cursor.par(), lt->cursor.pos())
+ && lt->cursor.par()->isInset(lt->cursor.pos())
&&
isHighlyEditableInset(lt->cursor.par()->getInset(lt->cursor.pos( {
Inset * tmpinset =
lt->cursor.par()->getInset(lt->cursor.pos());
owner_->getLyXFunc()->setMessage(tmpinset->editMessage());
@@ -1865,7 +1865,7 @@
lt->cursorLeft(bv_, false);
if ((is_rtl || cur != lt->cursor) && // only if really moved!
lt->cursor.pos() < lt->cursor.par()->size() &&
- isMetaInset(lt->cursor.par(), lt->cursor.pos()) &&
+ lt->cursor.par()->isInset(lt->cursor.pos()) &&
isHighlyEditableInset(lt->cursor.par()->getInset(lt->cursor.pos( {
Inset * tmpinset =
lt->cursor.par()->getInset(lt->cursor.pos());
owner_->getLyXFunc()->setMessage(tmpinset->editMessage());
@@ -3410,7 +3410,7 @@
string contents;
if (same_content &&
- isMetaInset(cursor.par(), cursor.pos())) {
+ cursor.par()->isInset(cursor.pos())) {
Inset const * inset = cursor.par()->getInset(cursor.pos());
if (find(codes.begin(), codes.end(), inset->lyxCode())
!= codes.end())
Index: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.397
diff -u -r1.397 ChangeLog
--- src/ChangeLog 2001/11/20 08:54:09 1.397
+++ src/ChangeLog 2001/11/22 02:02:12
@@ -1,3 +1,12 @@
+2001-11-22 John Levon <[EMAIL PROTECTED]>
+
+ * BufferView2.C:
+ * BufferView_pimpl.C:
+ * buffer.C:
+ * paragraph.h:
+ * text.C:
+ * text2.C: use par->isInset()
+
2001-11-20 Allan Rae <[EMAIL PROTECTED]>
* paragraph.C (insertFromMinibuffer): Fix for inset related crashes.
Index: src/buffer.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/buffer.C,v
retrieving revision 1.264
diff -u -r1.264 buffer.C
--- src/buffer.C2001/11/19 15:34:09 1.264
+++ src/buffer.C2001/11/22 02:02:25
@@ -2574,7 +2574,7 @@
par->layout);
// treat as a special case for compatibility with old code
- if (par->getChar(0) == Paragraph::META_INSET) {
+ if (par->isInset(0)) {
Inset * inset = par->getInset(0);
Inset::Code lyx_code = inset->lyxCode();
if (lyx_code == Inset::TOC_CODE){
@@ -3105,7 +3105,7 @@
// treat label as a special case for
reliability of par->getInset()
is getInset still failing to find insets after a par->isInset returns true ? There is still a lot of code that checks getInset return is non-null before using it, and it looks ugly. How old is the code that could cause this to happen; is it still there ? thanks john -- "Your superior intellect is no match for our puny weapons."
Re: Inset in inset crashes
On Wed, 21 Nov 2001, Juergen Vigna wrote: > On 21-Nov-2001 Allan Rae wrote: > > > It seems we need to get: > > Inset::checkInsertChar() to return false. > > UpdatableInset::checkInsertChar() to return true. > > IMO the Inset::checkInsertChar() should be removed. I added this when > I had the problems that the function was not called. But it's just stupid > as normal Insets can't have put charaters into them in any case otherwise > they would be UpdatableInsets! Hmmm... Is it remotely possible that LyX might attempt to insert a character into an inset other than an UpdatableInset? There are no checks of inset type (other than this). Suppose some dufus botches a hand edit of the LyX file. Would it be better to silently drop the characters or crash or whatever undefined behaviour might eventuate. > > (Why is this named differently to the rest of the insets?) > > IMO because it's THE base insets, therefore I would like to have a > ContainerInset to (not InsetContainer), but if you think the idea > behind is wrong we could change it ;) Fair enough I think. But that should be mentioned in CodeRules as a possibility. > > I suspect that InsetTabular probably only accepts other insets into > > which chars can be inserted rather than chars directly. Juergen? > > Well InsetTabular passes the question directly to the InsetText where > the cursor is actually in. Okay, then it does do what I silently hoped it would. Allan. (ARRae)
Re: Inset in inset crashes
On Wed, 21 Nov 2001, Larry Kollar wrote: > > Allan Rae wrote: > > > P.S. I tawt I taw a meteor shower: I did! I did! > > Actually, this is what you saw: > http://www.geekculture.com/joyoftech/joyarchives/260.html There must have a been a whole alien invasion fleet up there to be chucking down the number of flaming bags of poop I saw! Bring it on aliens! We want more! Allan. (ARRae)
Re: problem with pdf file generated using LyX
On Wed, Nov 21, 2001 at 11:26:57AM -0500, Nirmal Govind wrote: > The pdf file generated using LyX has all the characters showing up very > poorly - the fonts are messed up and so the document looks very shabby. > I know that the pdflatex on my machine (windows2000) works fine cos any > tex file that I edit myself and use pdflatex on produces a good looking > pdf file whereas if I use LyX directly or convert the LyX file to Tex > and use pdflatex, I get a horrible looking document. > > Anyone know a fix to this problem? I assume it has something to do with > the packages that LyX uses by default? Read section 3.3.6 of Extended.lyx If you are lazy to read it, then all you need to do is either - Select ae font in the document dialog or - Change font encoding to default in the preferences dialog.
Re: Inset in inset crashes
Allan Rae wrote: > P.S. I tawt I taw a meteor shower: I did! I did! Actually, this is what you saw: http://www.geekculture.com/joyoftech/joyarchives/260.html :-) Larry
problem with pdf file generated using LyX
Hi, The pdf file generated using LyX has all the characters showing up very poorly - the fonts are messed up and so the document looks very shabby. I know that the pdflatex on my machine (windows2000) works fine cos any tex file that I edit myself and use pdflatex on produces a good looking pdf file whereas if I use LyX directly or convert the LyX file to Tex and use pdflatex, I get a horrible looking document. Anyone know a fix to this problem? I assume it has something to do with the packages that LyX uses by default? Thanks, nirmal
Slashdot article
Hello See http://slashdot.org/askslashdot/01/11/19/1933214.shtml Lyx seems to be a good example (the original author have droped it and started a miserable little desktop interface project (c; ) Any developper post its story ? -- Emmanuel |\ _,,,---,,_ Emmanuel GUREGHIAN ZZZzz /,`.-'`'-. ;-;;,_ mailto:[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' '---''(_/--' `-'\_) "La peine de mort est le prix Nobel des assassins." L.F.Celine.
Re: quotation marks ...
On Tue, Nov 20, 2001 at 08:46:37PM +0100, Dr. Ing. Dieter Jurzitza wrote:
> What about defining such things in a header by newcommand and
> changing it by changing the declaration of newcommand? I. e. say
> \newcommand{\leftquote}{\glqq} for german double left style and
> \newcommand{\leftquote}{\glq} for german single left style or alike?
> You do write latex headers anyway, don't you?
This is probably how we'd implement a "document-wide quotation mark
style". The exception would be the name of the quote command. We
would want to use something unique; if "\leftquote" is an existing
command, you'd have to create an alias for it (using TeX commands, not
LaTeX), then redefine it. Or, just define a new "\lyxquote" command,
which is cleaner IMO.
> I am only dreaming of a word processor that is easy to
> use and works like charm - not like M$Word.
...which, Microsoft flunkies would argue, is what Word tries to do.
I, for my part am *extremely* leery of any software that tries to
"make everything easy for me". I don't want everything easy, I only
want the most frequent, tedious operations simplified and readily
accessible. If I need to change a style document-wide, I'll do the
extra steps to say "apply this to the whole document." Don't
second-guess me or what I'm doing.
No software exists that can think for you. Any software that tries
will operate eratically.
--
John Weiss
Re: selection
On Wed, Nov 21, 2001 at 07:48:55PM +0100, Lars Gullik Bjønnes wrote: > We do not know how long it will take to make an ascii representation > of an external inset. So, because of that we decided to only create > teh X selection when the user explictly asked for a copy. I thought X selections were pull-mode, ie. we get XSelectionEvent when another application requests a selection. As far as I see it works like this : lyx - end selection - call XSetSelectionOwner to own the X clipboard otherclient - ctrl-v - XConvertSelection ->lyx - XSelectionEvent convert selection into requested format and send an event to the other client so we would only need to pull a selection on the 3rd time. However I don't see an XSelectionEvent in the lyx source. How is this working now in lyx ? regards john -- "Your superior intellect is no match for our puny weapons."
Re: Sectioning.[Ch]
On Wed, Nov 21, 2001 at 07:43:50PM +0100, Lars Gullik Bjønnes wrote: > I am pretty sure that I saw a > > Makefile.am: > - sectioning.C > - sectioning.h I think I did this. I suppose it got dropped on the floor at some point... john -- "Your superior intellect is no match for our puny weapons."
Re: Mathed buglet
On Wed, Nov 21, 2001 at 06:49:19PM +0100, Andre Poenitz wrote: > > If I'm outside a math-inset (ie, it's not "active") and click inside to make > > it active, then the cursor is always positioned at the end of the formula, > > rather than at the point where I clicked. Now that I'm inside the active > > inset, any subsequent clicking will place me exactly where I want to be. > > I noticed that. The problem is that mathed gets passed the click > before its 'edit' method is called, so the first click gets lost. > > I recently changed something to make selection with the mouse working again > and removed a some code with no obvious use - which was probably there to > work around this "order problem". I'll put in again something with the same > effect as soon as I am bak on a "real computer"... good. check to see if insetert still expands/collapses/inlines properly too ... currently I couldn't get a click into an inlined ERT to position itself at the right point (so it sounds /really/ similar problem). thanks john -- "Your superior intellect is no match for our puny weapons."
Re: getRowNearY
On Tue, Nov 20, 2001 at 07:25:02PM +0100, Andre Poenitz wrote: > Has anybody hard data that inlining this is (a) happening and (b) has > significant impact? > > If not, I'd move it to some .C, and replace the #include "lyxrow.h" by > "class Row;"... isn't this one of the "low-hanging fruit" from some time ago (search archive for similar "fruit" topic) ? If so, yes, it make a big difference on real stuff, it was near the top of the report. regards john -- "Your superior intellect is no match for our puny weapons."
Re: inset question
On Tue, Nov 20, 2001 at 02:37:56PM +0100, Andre Poenitz wrote: > > if you're REALLY sure that it does not change semantics in some insets! > > I am not going to do anything there, I was just poking around a bit. And I > have admit that I have serious problems understanding these things out > there... those two calls are mostly mutually exclusive in whether an inset is "listening" to them. Some complex insets need the details on a button presses (the first call), and some only care that they have been clicked (edited). Some are a bit of both, for example the ERT inset which is only interested in being edited when it is collapsed, but needs more details when it is expanded. Shouldn't that whole thing be done via signal/slot ??? john -- "Your superior intellect is no match for our puny weapons."
Re: selection
On Tue, Nov 20, 2001 at 03:04:08PM +0100, Lars Gullik Bjønnes wrote: > | It just occured to me that LyX selection behaviour is pretty inconsistent > | with any other application. Why do I have to press Ctrl-C to make the "LyX > | selection" available as "X selection"? > > This was up on the mailinglist a couple of weeks ago: External Insets. I missed this - can you explain ? john -- "Your superior intellect is no match for our puny weapons."
Re: Paragraph::Pimpl::size()
On Tue, Nov 20, 2001 at 06:43:37PM +1000, Allan Rae wrote: > I have a small change there to test and then I hope to figure out > where the best place for a checkInsertChar() that returns true should > be. I guess it should go in the suggested new InsetContainer ... john -- "Your superior intellect is no match for our puny weapons."
Re: The new minibuffer drop down stuff.
On Tue, Nov 20, 2001 at 06:07:43PM +, Angus Leeming wrote: > > it would, wouldn't it ! Like to get it working ? > > Oh that's not fair! For the time being, I'll have to decline; two weeks off > means that real work piles up I'm afraid. ;) > I was playing with before I left. You never know, it might lead to a > genuinely useful graphics inset! that would be good ;) you can even solve insets resizing problems with their owner too ! > Great to see you doing this clever stuff though. *cough*. It's hardly clever. I am tempted to find out why the stuff doesn't work now though ... john -- "Your superior intellect is no match for our puny weapons."
Re: Sectioning.[Ch]
> | What about removing them from the Makefile.am as long as they are > | not used? > > Haven't you already done that? I my tree, yes. I did not think that I was going to commit anything from it, at least not soon? Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: LyXText::setHeightOfRow weirdness
> The only change I noticed is that, for a very large file, total time > counted by gprof goes from 5.68s to 3.26s :) Uuh... that is really bad... this goes exactly into the opposite direction than the one 1.2.0 development has followed all the time (apart from temporary dark times in Bozano or so, of course...) Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: everything in one batch
> | struct BufferView::Pimpl : public SigC::Object {
> | + /// copied from paragraph.h even if it does not look overly sensible
> | + typedef std::vector::difference_type pos_type;
>
> Does not look sensible at all.
Would it look more sensible (possibly even to the extend of being
acceptable) if I created a 'postype.h', put the declaration there, and
included it in the relevenat headers? Maybe within the 'lyx' namespace?
(Jean-Marc suggested this if I understood him correctly if that helps...)
Andre'
PS:
>
> etc etc.
No 'etc' left. The other things were quite different. And it would be
nice if you commented on the tiny patches if you brush away the large one.
--
André Pönitz .. [EMAIL PROTECTED]
Re: LyX Version 1.1.6fix2 - German Layout [w/ PATCH]
Jean-Marc Lasgouttes wrote: > It applied flawlessly. I am currently compiling, and will commit it > afterwards. Phew... thanks. Jürgen > JMarc
Re: Mathed buglet
> If I'm outside a math-inset (ie, it's not "active") and click inside to make > it active, then the cursor is always positioned at the end of the formula, > rather than at the point where I clicked. Now that I'm inside the active > inset, any subsequent clicking will place me exactly where I want to be. I noticed that. The problem is that mathed gets passed the click before its 'edit' method is called, so the first click gets lost. I recently changed something to make selection with the mouse working again and removed a some code with no obvious use - which was probably there to work around this "order problem". I'll put in again something with the same effect as soon as I am bak on a "real computer"... Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: everything in one batch
> How much faster is the compile? This obviously depends on the file you are touching. Which one do you mean? Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: everything in one batch
> Andre> Small changes in order to reduce include file dependency. The
> Andre> "most intrusive" parts are "localized typedefs" for
> Andre> Paragraph::size_type plus some whitespace changes (mostly
> Andre> spaces -> tab for indentation)
>
> I do not really like the changes to Paragraph::size_type. This means
> that we have several places where the same information is duplicated.
> This is not very robust IMO. Do you have an estimate of the compile
> time you gain by this?
5 seconds on a full recompile time of 13 minutes... Not exactly rocket
science, but note that the main win stems from less dependencies when you
do small changes to _one_ file that is high up in the tree, not when
recomipiling everything. You do not expect a full analysis, do you?
> What about a header file lyxtypes.h like
>
> #include
>
> namespace lyx {
> typedef vector paragraph_type;
> }
>
> and other types too, that woulf be included whenever needed?
That's ok. That's better, actually.
Andre'
--
André Pönitz .. [EMAIL PROTECTED]
Re: Sectioning.[Ch]
> | This is not used at all, it simply bloats the binary... > > they are going to be used Sure they will... What about removing them from the Makefile.am as long as they are not used? Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: Inset in inset crashes
> I *think* the formula insets should be able to handle insertion of > chars (probably with a change of font but not necessarily -- ideas?) > Andre'? I do not really understand what you are talking about. I am just learning to crawl in the outside world... Last time I looked I could insert some chars in formulas... But there is certainly a problem with inserting "cooked" chars like '"u' in formulas since I get passed only a '[' (which is the key on an US keyboard that is at the same place like the '"u' on a German keyboard) and I have no way to tell whether this is a real ']' or a '"u' in disguise. So I just insert a ']' and let people invent strange hacks to get German letters into formulas... Are you talking about something that would make this problem go away? Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: Sectioning.[Ch]
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Andre Poenitz <[EMAIL PROTECTED]> writes: | This is not used at Lars> all, it simply bloats the binary... Lars> they are going to be used Yes, but they should not be compiled/distributed right now. JMarc
Re: LyX Version 1.1.6fix2 - German Layout [w/ PATCH]
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes: Juergen> Jean-Marc Lasgouttes wrote: >> Use directly cvs diff -uR >patch.diff Juergen> Thank you all very much for your patient instructions. I Juergen> didn't know this indeed %-| Here's the (unmodified) patch Juergen> against recent cvs. Note that the changes to po/POTFILES.in Juergen> and the first lines beginning with '?' look suspicious to me Juergen> (this is something I would have deleted). Juergen> The patch comes with my fingers crossed ;-) It applied flawlessly. I am currently compiling, and will commit it afterwards. JMarc
Re: LyX Version 1.1.6fix2 - German Layout [w/ PATCH]
> You can indeed delete such things, but patch should be able to cope. As for > the POTFILES.in, it's fine but does look a little perverse. My box does > something similar. Generally speaking, I delete it too, or at a pinch edit it > by hand. > To make a clean patch, I do: rm po/*.po po/POTFILE* cvs update -dP cvs diff -u > PATCHFILE That eliminates the po.* and POTFILE* diffs. -- 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)
Re: 1.1.6fix3 pictures no longer display ( eps ghostscript preview )
On 21-11-2001 at 13:45, Kornel Benko wrote: > > > On my system lyx 1.1.6-fix3 works with Ghostscript 6.51 when setting > > \ps_command to "/usr/bin/gs " > > in lyxrc.defaults or equivalent > > No help here with this configuration. > The execvp + " " also seemed to bet ustable on my system, so I guess the workaround is to have a separate gs5.50 installation and then setting the gs interpreter for lyx to be gs5.50. Morten -- - The Penguin's 1. We are better together than alone - Postulate 2. If you push something hard enough it will fall over - Morten S. Nielsen Dept. of Manuf. Engineering and Management - mailto:[EMAIL PROTECTED] Building 425, 2. floor, DK-2800 Lyngby
Re: LyXText::setHeightOfRow weirdness
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> On Tue, Nov 20, 2001 at 04:39:32PM +0100, Jean-Marc Lasgouttes Andre> wrote: >> What does this do??? As far as I can read, getRow does not modify >> anything but unused_y (which is truly unused). It does return a >> row, but this is just lost. Andre> Does it sill work if you throw it out? *grin innocently* I've done so, and it still _seems_ to work. However, I'd rather have a confirmation from Lars/Juergen that this is indeed bogus, because it seems very strange to have this code without reason. The only change I noticed is that, for a very large file, total time counted by gprof goes from 5.68s to 3.26s :) The next big hit is Paragraph::getFont. JMarc
Re: German locale segfault (?!)
On Wednesday 21 November 2001 12:44 pm, Peter Suetterlin wrote: > Angus Leeming wrote: > > On Wednesday 21 November 2001 11:00 am, Jules Bean wrote: > > > Can we get a fix backported to 1.1.6? Even if it's just patching the > > > .po files to use shorter strings? I'd rather not have the debian > > > package crashing for germans... > > > > Get in touch with the appropriate translators! > > Hm, this is the general problem of longer words in german (and other > languages) again, isn't it? Of course you could use abbreviated words - > just, you probably will only understand them if you already know what it > is :-( > > But tell me which tabs you were talking about, and I'll try to find a > better translation... These things. Only a few of the dialogs have tabbed folders. Angus tabs.png Description: PNG image
Re: whitespace changes to layout.h
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> but ok.. but the first pass was only e preprocessor pass? Yes, I think. I did not try to compare the compile times with both version, though. Also, with automake 1.5, I occasionally run into cases where dependencies go wrong (link error), mostly in mathed. JMarc
Re: LyX Version 1.1.6fix2 - German Layout [w/ PATCH]
Am Mittwoch, 21. November 2001 13:16 schrieb Angus Leeming: > You can indeed delete such things, but patch should be able to cope. > As for the POTFILES.in, it's fine but does look a little perverse. My > box does something similar. Generally speaking, I delete it too, or > at a pinch edit it by hand. > > You only really need to take care is to respect line numbers: > @@ -29,6 +32,8 @@ > > The problem that we've been experiencing with your patches to date is > no doubt because these line numbers have become incorrect because > writing to console can lead to line-wrap. I see! Many thanks, I will take this into account in the future and try to avoid any hassles for you. Jürgen > Angus
Re: German locale segfault (?!)
Angus Leeming wrote: > On Wednesday 21 November 2001 11:00 am, Jules Bean wrote: > > Can we get a fix backported to 1.1.6? Even if it's just patching the > > .po files to use shorter strings? I'd rather not have the debian > > package crashing for germans... > > Get in touch with the appropriate translators! Hm, this is the general problem of longer words in german (and other languages) again, isn't it? Of course you could use abbreviated words - just, you probably will only understand them if you already know what it is :-( But tell me which tabs you were talking about, and I'll try to find a better translation... Pit -- Peter "Pit" Suetterlin http://www.uni-sw.gwdg.de/~pit Universitaets-Sternwarte Goettingen Tel.: +49 551 39-5048 [EMAIL PROTECTED]
Re: 1.1.6fix3 pictures no longer display ( eps ghostscript preview )
On Wednesday, 7. November 2001 15:08, you wrote: > On Mon, 24 Sep 2001 07:25:08 -0700 john wrote: > > well as someone said that doesn't work for everyone. > > > > If I could reproduce the problem I could debug it :( > > > > john > > Sorry if this is a bit outdated, but this bug still seems to exist. > > In figinset.C there seems to be a problem with execlp if one uses > ghostscript 6.51 + > > The gs process starts but never exits. Why I don't know. One can go > into /proc and see the commandline arguments, but this doesn't explain > where it hangs. If you're curious I could try to strace gs. But for now > I'll just report the workaround. > Confirmed. On my system the backtrace of gs looks like: ... (gdb) symbol-file /usr/bin/gs_x11 Reading symbols from /usr/bin/gs_x11...(no debugging symbols found)...done. (gdb) attach 6343 Attaching to process 6343 0x4035a47e in ?? () (gdb) bt #0 0x4035a47e in ?? () #1 0x400e61da in ?? () #2 0x400e5fa6 in ?? () #3 0x400d8482 in ?? () #4 0x080fb8d3 in gdev_x_send_event () #5 0x081bc43a in gs_output_page () #6 0x080d240b in zflushpage () #7 0x080b962d in gs_errorinfo_put_string () #8 0x080b7aa1 in gs_interpret () #9 0x080b7990 in gs_interpret () #10 0x080b183a in gs_main_run_string_end () #11 0x080b1730 in gs_main_run_string_with_length () #12 0x080b16d1 in gs_main_run_string () #13 0x080b33d5 in gs_main_run_start () #14 0x080b3354 in gs_main_run_start () #15 0x080b3128 in gs_main_run_start () #16 0x080b2270 in gs_main_init_with_args () #17 0x0806ead1 in main () #18 0x402a57ee in ?? () > If using ghostscript 5.50 it always works fine. Here too, but other programs like kghostview not working anymore. > On my system lyx 1.1.6-fix3 works with Ghostscript 6.51 when setting > \ps_command to "/usr/bin/gs " > in lyxrc.defaults or equivalent No help here with this configuration. > It's the first argument to execlp which must end with a space (works > also when setting the first string to " ") Playing with execlp() didn't help me. Seem to be the standard for SuSE 7.3 update, at least all of my colleagues have the same effect. Kornel -- Kornel Benko [EMAIL PROTECTED]
Mathed buglet
This one is tiny but... If I'm outside a math-inset (ie, it's not "active") and click inside to make it active, then the cursor is always positioned at the end of the formula, rather than at the point where I clicked. Now that I'm inside the active inset, any subsequent clicking will place me exactly where I want to be. Angus
Re: LyX Version 1.1.6fix2 - German Layout [w/ PATCH]
On Wednesday 21 November 2001 11:47 am, Juergen Spitzmueller wrote: > Jean-Marc Lasgouttes wrote: > > Use directly > > cvs diff -uR >patch.diff > > Thank you all very much for your patient instructions. I didn't know > this indeed %-| > Here's the (unmodified) patch against recent cvs. Note that the changes > to po/POTFILES.in and the first lines beginning with '?' look > suspicious to me (this is something I would have deleted). You can indeed delete such things, but patch should be able to cope. As for the POTFILES.in, it's fine but does look a little perverse. My box does something similar. Generally speaking, I delete it too, or at a pinch edit it by hand. You only really need to take care is to respect line numbers: @@ -29,6 +32,8 @@ The problem that we've been experiencing with your patches to date is no doubt because these line numbers have become incorrect because writing to console can lead to line-wrap. Angus
patches 4 lyx persian support
hi i didn,t have enough time to add ISIRI3342 to lyx in these days. but i attached some basic changes i made in lyx source code . i compiled it again just now.there were no problem in my sys;) i used persian encoding and persian kmap.i'm now working on persiantex and also im trying to add other related encodings to lyx. thanks a lot Mehdi Adibi [EMAIL PROTECTED] patch.tar.gz Description: GNU Zip compressed data
Re: LyX Version 1.1.6fix2 - German Layout [w/ PATCH]
Jean-Marc Lasgouttes wrote: > Use directly > cvs diff -uR >patch.diff Thank you all very much for your patient instructions. I didn't know this indeed %-| Here's the (unmodified) patch against recent cvs. Note that the changes to po/POTFILES.in and the first lines beginning with '?' look suspicious to me (this is something I would have deleted). The patch comes with my fingers crossed ;-) Many thanks, Jürgen browse3.diff.gz Description: GNU Zip compressed data
Re: whitespace changes to layout.h
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> | What automake version are you using? With 1.5, it is supposed Lars> to | compile every file once instead of twice :) Lars> We already did that with prev. version. That's not what I read here: http://sources.redhat.com/automake/dependencies.html JMarc
Re: German locale segfault (?!)
On Wednesday 21 November 2001 11:00 am, Jules Bean wrote: > On Wed, Nov 21, 2001 at 11:05:24AM +, Angus Leeming wrote: > > On Wednesday 21 November 2001 10:38 am, Jules Bean wrote: > > > http://bugs.debian.org/120450 > > > > > > I haven't tried to reproduce it yet, any comments? > > > > > > Jules > > > > Trust him, it happens! > > > > In xforms, the tabs expand in size automatically to accommodate the title > > string. If these strings are long, then the right-most tabs may expand beyond > > the edge of the dialog. Click on such a partially diaplayed tab and you'll > > get an xforms crash. > > > > Maybe you'd like to hassle the xforms people to fix it / release the xforms > > source ;-) > > Can we get a fix backported to 1.1.6? Even if it's just patching the > .po files to use shorter strings? I'd rather not have the debian > package crashing for germans... Get in touch with the appropriate translators! Angus
Re: German locale segfault (?!)
On Wed, Nov 21, 2001 at 11:05:24AM +, Angus Leeming wrote: > On Wednesday 21 November 2001 10:38 am, Jules Bean wrote: > > http://bugs.debian.org/120450 > > > > I haven't tried to reproduce it yet, any comments? > > > > Jules > > Trust him, it happens! > > In xforms, the tabs expand in size automatically to accommodate the title > string. If these strings are long, then the right-most tabs may expand beyond > the edge of the dialog. Click on such a partially diaplayed tab and you'll > get an xforms crash. > > Maybe you'd like to hassle the xforms people to fix it / release the xforms > source ;-) Can we get a fix backported to 1.1.6? Even if it's just patching the .po files to use shorter strings? I'd rather not have the debian package crashing for germans... Jules
Re: German locale segfault (?!)
On Wednesday 21 November 2001 10:38 am, Jules Bean wrote: > http://bugs.debian.org/120450 > > I haven't tried to reproduce it yet, any comments? > > Jules Trust him, it happens! In xforms, the tabs expand in size automatically to accommodate the title string. If these strings are long, then the right-most tabs may expand beyond the edge of the dialog. Click on such a partially diaplayed tab and you'll get an xforms crash. Maybe you'd like to hassle the xforms people to fix it / release the xforms source ;-) Angus
German locale segfault (?!)
http://bugs.debian.org/120450 I haven't tried to reproduce it yet, any comments? Jules
Re: LyX Version 1.1.6fix2 - German Layout [w/ PATCH]
On Wednesday 21 November 2001 9:51 am, Juergen Spitzmueller wrote: > Jean-Marc Lasgouttes wrote: > > Does not work: > > Arghh!!! > > > patch: malformed patch at line 266: @@ -632,7 +648,7 @@ > > > > Do you really have to hand-edit your patches before sending them? > > Well, I used to create patches with a cvs-frontend tool (Cervisia) > which was very comfortable and never caused trouble. > Unfortunately, this doesn't work anymore after an upgrade (for unknown > reasons), so I run 'cvs diff -uR' manually in the console and > copy/paste that into an editor (is there a better way?). Try cvs diff -uR > juergen.diff And just send that.
Re: LyX Version 1.1.6fix2 - German Layout [w/ PATCH]
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes: Juergen> I have to admit that I don't like this kind of work, but I Juergen> have no idea how to do it better. Maybe I'm just too stupid, Juergen> so hints are *very* welcome. Use directly cvs diff -uR >patch.diff Note that a .cvsrc like -- cvs -z6 diff -u rdiff -u update -dP -- will provide the right default options to the cvs commands. JMarc
Re: LyX Version 1.1.6fix2 - German Layout [w/ PATCH]
Jean-Marc Lasgouttes wrote: > Does not work: Arghh!!! > patch: malformed patch at line 266: @@ -632,7 +648,7 @@ > > Do you really have to hand-edit your patches before sending them? Well, I used to create patches with a cvs-frontend tool (Cervisia) which was very comfortable and never caused trouble. Unfortunately, this doesn't work anymore after an upgrade (for unknown reasons), so I run 'cvs diff -uR' manually in the console and copy/paste that into an editor (is there a better way?). I think I have to delete lines like cvs server: Diffing src/frontends/xforms I have to admit that I don't like this kind of work, but I have no idea how to do it better. Maybe I'm just too stupid, so hints are *very* welcome. Sorry for the inconvenience. Jürgen. > JMarc
Re: LyX Version 1.1.6fix2 - German Layout [w/ PATCH]
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes: Juergen> Please try this one (including all my changes from today Juergen> since my first patch seems not to be committed). I really Juergen> hope it works. Please tell me, if not! Does not work: patch: malformed patch at line 266: @@ -632,7 +648,7 @@ Do you really have to hand-edit your patches before sending them? JMarc
Re: New chess updates
> "Kayvan" == Kayvan A Sylvan <[EMAIL PROTECTED]> writes: Kayvan> Just as soon as I sent this, I thought of a couple of Kayvan> improvements... Applied. JMarc
Re: everything in one batch
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> ... and a bit more.
Andre> Small changes in order to reduce include file dependency. The
Andre> "most intrusive" parts are "localized typedefs" for
Andre> Paragraph::size_type plus some whitespace changes (mostly
Andre> spaces -> tab for indentation)
I do not really like the changes to Paragraph::size_type. This means
that we have several places where the same information is duplicated.
This is not very robust IMO. Do you have an estimate of the compile
time you gain by this?
What about a header file lyxtypes.h like
#include
namespace lyx {
typedef vector paragraph_type;
}
and other types too, that woulf be included whenever needed?
JMarc
Re: whitespace changes to layout.h
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> Well, this way I cannot check that it still compiles, can I? Andre> ;-) I'd rather have decent compile times... What automake version are you using? With 1.5, it is supposed to compile every file once instead of twice :) JMarc
Re: The new minibuffer drop down stuff.
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> On Mon, Nov 19, 2001 at 04:20:15PM +0100, Jean-Marc Lasgouttes John> wrote: >> A third one: if I type a character, it closes the drop-down, but is >> ignored. It would be better to have it inserted in minibuffer. John> I can't get this to work using any combination of XSendEvent, John> fl_XPutBackEvent etc. John> I did spend some time on it :/ I hav to admit I know nothing about how to get it to work... JMarc
Re: Inset in inset crashes
On 21-Nov-2001 Allan Rae wrote: > It seems we need to get: > Inset::checkInsertChar() to return false. > UpdatableInset::checkInsertChar() to return true. IMO the Inset::checkInsertChar() should be removed. I added this when I had the problems that the function was not called. But it's just stupid as normal Insets can't have put charaters into them in any case otherwise they would be UpdatableInsets! > (Why is this named differently to the rest of the insets?) IMO because it's THE base insets, therefore I would like to have a ContainerInset to (not InsetContainer), but if you think the idea behind is wrong we could change it ;) > I suspect that InsetTabular probably only accepts other insets into > which chars can be inserted rather than chars directly. Juergen? Well InsetTabular passes the question directly to the InsetText where the cursor is actually in. Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ If people drank ink instead of Schlitz, they'd be better off. -- Edward E. Hippensteel [What brand of ink? Ed.]
Re: lyxtext.h
On Tue, Nov 20, 2001 at 07:18:48PM +0100, Andre Poenitz wrote: > This replaces an #include by a forward declaration. (Sorry. Pretend it's Friday). Good work. Reminds me of my early days in C++: I had no idea about forward declarations, so every single class had to #include the header for every file it referenced. Apart from endless circularity, it also made compile times quite absurd (this on a 16Mz 68020..) Jules
