Re: [PATCH] graphics

[Herbert Voss]

John Levon wrote:

 On Thu, Aug 08, 2002 at 09:34:16AM +0100, Angus Leeming wrote:
 
 
I meant the comments in the mail. I haven't got the patch. Since you started 
this thread, I guess you have it, so apply it.

 
 well I was after making sure it's reviewed ... I don't have it any more
 than you do


that is what I called the nice committing policy of LyX ...

Herbert




-- 
http://www.lyx.org/help/

Qt frontend trouble on FreeBSD /w qt3.

[R. Lahaye]

Hi,

I'm using the 2.53 and 1.5 autotools.

The qt3 package (from qt-x11-free-3.0.5.tar.bz2) on my FreeBSD PC, requires
following:
  includes-dir: /usr/X11R6/include
  libraries-dir: /usr/X11R6/lib
  linking: -lqui (linking with /usr/X11R6/lib/libqui.so)

The -lqui is tricky because I don't know how to modify the configure scripts in
order to correctly
pick up this library. As a temporary solution, I created a link to
/usr/X11R6/libqui.so by
/usr/X11R6/libqt.so and /usr/X11R6/libqt.so.3.

I then tried setenv QTDIR /usr/X11R6 before running configure, but that didn't
work:
  checking for Qt... configure: error: Qt2 (libraries) not found. Please check
your installation!
Why is QTDIR/lib and QTDIR/include not found?
So I ran configure with --with-qt-includes=/usr/X11R6/include
--with-qt-libraries=/usr/X11R6/lib,
which eventually makes the configure reach to the end safely.

A make in my case fails as soon as it reaches into src/frontends/qt2/ui
directory.
Gmake does a much better job, but I get stuck at
src/frontends/qt2/Toolbar_pimpl.C:
  Toolbar_pimpl.C: In function `class QPixmap {anonymous}::getIconPixmap(int)':
  Toolbar_pimpl.C:45: `tie' undeclared in namespace `boost'
When this file includes the line
  #include boost/tuple/tuple.hpp
the problem is solved, and compilation continues almost until the very end:

  [...]
  g++ -g -O -Wno-non-template-friend -W -Wall -o lyx BufferView.o BufferView2.o
BufferView_pimpl.o Bullet.o Chktex.o CutAndPaste.o DepTable.o FloatList.o
Floating.o FuncStatus.o LColor.o LaTeX.o LaTeXFeatures.o LyXAction.o
MenuBackend.o ParagraphParameters.o Spacing.o TextCache.o Thesaurus.o
ToolbarDefaults.o box.o buffer.o bufferlist.o bufferparams.o bufferview_funcs.o
chset.o converter.o counters.o debug.o encoding.o exporter.o gettext.o
importer.o intl.o iterators.o kbmap.o kbsequence.o language.o lastfiles.o
lengthcommon.o lyx_cb.o lyx_main.o lyx_sty.o lyxcursor.o lyxfont.o lyxfind.o
lyxfunc.o lyxgluelength.o lyxlayout.o lyxlength.o lyxlex.o lyxlex_pimpl.o
lyxrc.o lyxrow.o lyxserver.o lyxtextclass.o lyxtextclasslist.o lyxvc.o main.o
paragraph.o paragraph_pimpl.o ispell.o pspell.o tabular.o tabular-old.o
tabular_funcs.o tex-accent.o tex-strings.o texrow.o text.o text2.o toc.o trans.o
trans_mgr.o undo.o undo_funcs.o vc-backend.o version.o vspace.o 
mathed/.libs/libmathed.a  insets/.libs/libinsets.a
frontends/.libs/libfrontends.a -lqt graphics/.libs/libgraphics.a
support/.libs/libsupport.a ../boost/libs/regex/src/.libs/libboostregex.a
../boost/libs/signals/src/.libs/libboostsignals.a ../intl/libintl.a -lXpm -lSM
-lICE -lc -lm -L/usr/X11R6/lib -lX11
  /usr/X11R6/lib/libqt-mt.so.3: undefined reference to `pthread_attr_destroy'
  /usr/X11R6/lib/libqt-mt.so.3: undefined reference to `pthread_create'
  /usr/X11R6/lib/libqt-mt.so.3: undefined reference to `pthread_attr_init'
  /usr/X11R6/lib/libqt-mt.so.3: undefined reference to `pthread_exit'
  /usr/X11R6/lib/libqt-mt.so.3: undefined reference to
`pthread_mutexattr_destroy'
  /usr/X11R6/lib/libqt-mt.so.3: undefined reference to
`pthread_attr_setinheritsched'
  /usr/X11R6/lib/libqt-mt.so.3: undefined reference to
`pthread_mutexattr_settype'
  /usr/X11R6/lib/libqt-mt.so.3: undefined reference to `pthread_mutexattr_init'
  /usr/X11R6/lib/libqt-mt.so.3: undefined reference to `pthread_mutex_trylock'
  /usr/X11R6/lib/libqt-mt.so.3: undefined reference to
`pthread_attr_setdetachstate'
  /usr/X11R6/lib/libqt-mt.so.3: undefined reference to `pthread_cond_timedwait'
  gmake[3]: *** [lyx] Error 1

This is because -pthread is somewhere missing in the compilation process. This
is a typical FreeBSD issue.
Only on FreeBSD the compiler needs (sometimes?) the -pthread flag. man gcc:

  [...]
  -pthread   Link a user-threaded process against libc_r instead
 of libc. Objects linked into user-threaded processes
 should be compiled with -D_THREAD_SAFE.
  [...]

So I do setenv CPPFLAGS -pthread and once again configure/gmake.

OKAY!, but the executable only dumps core:

(gdb) run
Starting program: /home/lahaye/SOFTWARE/lyx-devel/src/lyx 

Program received signal SIGSEGV, Segmentation fault.
0x28704882 in xdr_u_int () from /usr/lib/libc.so.4
(gdb) bt
#0  0x28704882 in xdr_u_int () from /usr/lib/libc.so.4
#1  0x28704fe6 in xdr_bytes () from /usr/lib/libc.so.4
#2  0x287050b8 in xdr_netobj () from /usr/lib/libc.so.4
#3  0x2871b49a in .cerror () from /usr/lib/libc.so.4
#4  0x285cec39 in _X11TransSocketINETConnect () from /usr/X11R6/lib/libX11.so.6
#5  0x285cfd51 in _X11TransConnect () from /usr/X11R6/lib/libX11.so.6
#6  0x28598e66 in _X11TransConnectDisplay () from /usr/X11R6/lib/libX11.so.6
#7  0x285a7e9d in XOpenDisplay () from /usr/X11R6/lib/libX11.so.6
#8  0x2894e415 in qt_init_internal () from /usr/X11R6/lib/libqt-mt.so.3
#9  0x2894f534 in qt_init () from /usr/X11R6/lib/libqt-mt.so.3
#10 0x2899d383 in QApplication::construct () from /usr/X11R6/lib/libqt-mt.so.3
#11 0x2899d1ac in QApplication::QApplication () from

[Paolo.Saggese@libero.it] Feedback from www.lyx.org

[Lars Gullik Bjønnes]

I forwarded your message to the lyx mailinglist, to possibly get some
wider attention and discussion.


---BeginMessage---


Paolo Saggese ([EMAIL PROTECTED]) entered the 
following feedback message on the LyX home page:


Hi.

Congratulations for the job done. LyX is really a great piece of software. Here (see: 
http://borex.lngs.infn.it ) we are using it extensively to write scientific articles, 
reports, etc.

We have a problem, though. We have several collaborators from Russia who needs to 
write documents is Russian language (Cyrillic chars), usually mixed with some english 
text, math formulas, etc.

Problem is, it looks like it is really hard to properly set up  Russian (Cyrillic) 
keyboard map in LyX and, even worse, we have not been able to find any easy way to 
switch back and forth from english to russian when writing mixed language documents 
(almost all are such). 

Oddly enough, with some older versions of LyX we had found a way (although not 
perfect) to to that somehow,  while with the latest versions it seems to be just 
impossible! :-(

Why could not LyX just use the system's keyboard maps and encodings? 

In KDE, Gnome and even plain X with whatever wm on it there are several confortable 
utilities to simply switch keyboard maps back and forth on the fly to and from 
(almost) any language with just a mouse click or some hotkey combination.
Most applications works that way without any problem. If LyX could simply do the same, 
it would be great!

Instead, unfortunately, switching the keyboard layout that way  simply makes LyX input 
the wrong characters or none at all. :-(

What is the current situation and the plans for the near future?

Thanks for your attention.

Ciao e grazie,
Paolo.

--
http://borex.lngs.infn.it/saggese
You can still escape from the GATES of hell: Use Linux!


---End Message---



-- 
Lgb

Re: Support for LyX in design recovery tool?

[Angus Leeming]

On Friday 09 August 2002 6:32 am, Amir Michail wrote:

 Also, I tried changing the cursor color using the dialog in the GUI. 
 (Again, a unique cursor color makes it easier to track the cursor from
 screenshots.) For some reason, the cursor color changes were always ignored
 (lyx 1.2). The color sliders also had some problems.  For example, I
 couldn't pick 254 for red; it only gave me 253 or 255.  Perhaps there is a
 way to explicitly specify RGB values from the startup file?

Try saving the change you've made and then edit the resultant preferences 
file (~/.lyx/preferences) by hand.

Angus

Re: nasty eqns lead to crash

[Kornel Benko]

-BEGIN PGP SIGNED MESSAGE-

On Thursday 08 August 2002 15:06, Andre Poenitz wrote:
 On Thu, Aug 08, 2002 at 01:26:32PM +0100, Angus Leeming wrote:
  Kornel Benko sent me this file because we thought that the crash was
  caused by the previewing. However, I can't load it at all with current,
  with or without previews enabled.

 It loads here. I only problem seems to be underscores in labels (again).
 I'll have a look at that.

 Andre'

It loads here now, after making some scripts executable.
(Yes, I am using the non-installed version from the src-directory.
 I have seen the mails, which pointed out this problem, but I didn't pay
enough attention to it. Sorry)

Kornel
- -- 
Kornel Benko
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: PGP 6.5.8

iQCVAwUBPVOLGLewfbDGmeqhAQHeWwQA4FX+UPz71j+g2bQpDOsoKxolik4+CzKZ
vaRZXusIYrmB5t1VSvcJAd8bHPCVngpKe0zMlv3tjDSmUP7HxHcoLkS7BPu/yJr7
cepkEHZi6wtscCHCNelw6pdkVIE0a42Bt9iLWoGn2oS5Eibb5IOdVzuz0FO3runM
WTJTr0+fHu4=
=US00
-END PGP SIGNATURE-

Re: nasty eqns lead to crash

[Martin Vermeer]

On Thu, Aug 08, 2002 at 07:15:23PM +0100, John Levon wrote:
 
 On Thu, Aug 08, 2002 at 01:26:32PM +0100, Angus Leeming wrote:
 
  Kornel Benko sent me this file because we thought that the crash was caused 
  by the previewing. However, I can't load it at all with current, with or 
  without previews enabled. Since it is chock full of equations and little 
  else, I thought André might like a look ;-)
 
...
 
 ==9208==
 ==9208== Conditional jump or move depends on uninitialised value(s)
 ==9208==at 0x80C94FD: ??? (/usr/include/g++-3/std/bastring.cc:249)
 ==9208==by 0x80C907B: ??? (/usr/include/g++-3/std/bastring.h:352)
 ==9208==by 0x80C7A00: Counters::reset(basic_stringchar, 
string_char_traitschar, __default_alloc_templatetrue, 0  const ) 
(counters.C:206)
 ==9208==by 0x81387FB: LyXText::setCounter(Buffer const *, Paragraph *) const 
(text2.C:1235)
 ==9208==
 ==9208== Conditional jump or move depends on uninitialised value(s)
 ==9208==at 0x80C94FD: ??? (/usr/include/g++-3/std/bastring.cc:249)
 ==9208==by 0x80C907B: ??? (/usr/include/g++-3/std/bastring.h:352)
 ==9208==by 0x80C7AD0: Counters::copy(Counters , Counters , basic_stringchar, 
string_char_traitschar, __default_alloc_templatetrue, 0 
 const ) (counters.C:216)
 ==9208==by 0x81386A2: LyXText::setCounter(Buffer const *, Paragraph *) const 
(text2.C:1225)
 
 Andre ? Martin ?

Seems correct to me. The first dozen lines or so in LyXText::setCounter are: 
if a par has no previous(), it resets its counter array, otherwise it
copies the one of its predecessor. Should cover all cases.

Inside Counters::reset and copy, I don't see it either. What should be 
undefined? match, if it is the empty string? To my eyes, it looks OK.
Or is perhaps .find() not supposed to have an empty arg?

Martin
-- 
Martin Vermeer  [EMAIL PROTECTED]
Helsinki University of Technology 
Department of Surveying
P.O. Box 1200, FIN-02015 HUT, Finland
:wq



msg42278/pgp0.pgp
Description: PGP signature

Re: nasty eqns lead to crash

[Angus Leeming]

On Friday 09 August 2002 10:39 am, Martin Vermeer wrote:
 On Thu, Aug 08, 2002 at 07:15:23PM +0100, John Levon wrote:
  On Thu, Aug 08, 2002 at 01:26:32PM +0100, Angus Leeming wrote:
   Kornel Benko sent me this file because we thought that the crash was
   caused by the previewing. However, I can't load it at all with current,
   with or without previews enabled. Since it is chock full of equations
   and little else, I thought André might like a look ;-)

 ...

  ==9208==
  ==9208== Conditional jump or move depends on uninitialised value(s)
  ==9208==at 0x80C94FD: ??? (/usr/include/g++-3/std/bastring.cc:249)
  ==9208==by 0x80C907B: ??? (/usr/include/g++-3/std/bastring.h:352)
  ==9208==by 0x80C7A00: Counters::reset(basic_stringchar,
  string_char_traitschar, __default_alloc_templatetrue, 0  const )
  (counters.C:206) ==9208==by 0x81387FB: LyXText::setCounter(Buffer
  const *, Paragraph *) const (text2.C:1235) ==9208==
  ==9208== Conditional jump or move depends on uninitialised value(s)
  ==9208==at 0x80C94FD: ??? (/usr/include/g++-3/std/bastring.cc:249)
  ==9208==by 0x80C907B: ??? (/usr/include/g++-3/std/bastring.h:352)
  ==9208==by 0x80C7AD0: Counters::copy(Counters , Counters ,
  basic_stringchar, string_char_traitschar,
  __default_alloc_templatetrue, 0  const ) (counters.C:216)
  ==9208==by 0x81386A2: LyXText::setCounter(Buffer const *, Paragraph
  *) const (text2.C:1225)
 
  Andre ? Martin ?

 Seems correct to me. The first dozen lines or so in LyXText::setCounter
 are: if a par has no previous(), it resets its counter array, otherwise it
 copies the one of its predecessor. Should cover all cases.

 Inside Counters::reset and copy, I don't see it either. What should be
 undefined? match, if it is the empty string? To my eyes, it looks OK.
 Or is perhaps .find() not supposed to have an empty arg?

It doesn't, it has a string argument that just happens to be empty. That's 
fine and string::find will return string::npos (for which you already test).

That is assuming that you haven't populated your map with an empty string() 
as an index...

Incidentally, why not:

void Counters::reset(string const  match)
{
CounterList::iterator it = counterList.begin();
CounterList::iterator end = counterList.end();
if (match.empty()) {
for (; it != end; ++it) {
it-second.reset();
}
} else {
for (; it != end; ++it) {
if (it-first.find(match) != string::npos)
it-second.reset();
}
}
}

And whether you choose to use two loops or one, that should be match.empty(), 
not match == . 

If you choose to remain with a single loop then you should also move the 
match.empty() test to the front of the if statement as it's quicker than 
find... (I believe that they're executed in order).

Angus

Re: nasty eqns lead to crash

[Angus Leeming]

On Friday 09 August 2002 10:37 am, Angus Leeming wrote:

 Incidentally, why not:

 void Counters::reset(string const  match)
 {
   CounterList::iterator it = counterList.begin();
   CounterList::iterator end = counterList.end();
   if (match.empty()) {
   for (; it != end; ++it) {
   it-second.reset();
   }
   } else {
   for (; it != end; ++it) {
   if (it-first.find(match) != string::npos)
   it-second.reset();
   }
   }
 }

Actually, shouldn't that be:

void Counters::reset(string const  match)
{
if (match.empty()) {
CounterList::iterator it = counterList.begin();
CounterList::iterator end = counterList.end();
for (; it != end; ++it) {
it-second.reset();
}
} else {
CounterList::iterator it = counterList.find(match);
if (it != counterList.end())
it-second.reset();
}
}

?

Angus

Re: nasty eqns lead to crash

[Andre Poenitz]

On Fri, Aug 09, 2002 at 10:37:10AM +0100, Angus Leeming wrote:
 (I believe that they're executed in order).

They have to.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: nasty eqns lead to crash

[Lars Gullik Bjønnes]

Angus Leeming [EMAIL PROTECTED] writes:

| On Friday 09 August 2002 10:37 am, Angus Leeming wrote:

 Incidentally, why not:

 void Counters::reset(string const  match)
 {
  CounterList::iterator it = counterList.begin();
  CounterList::iterator end = counterList.end();
  if (match.empty()) {
  for (; it != end; ++it) {
  it-second.reset();
  }
  } else {
  for (; it != end; ++it) {
  if (it-first.find(match) != string::npos)
  it-second.reset();
  }
  }
 }

| Actually, shouldn't that be:

| void Counters::reset(string const  match)
| {
|   if (match.empty()) {
|   CounterList::iterator it = counterList.begin();
|   CounterList::iterator end = counterList.end();
|   for (; it != end; ++it) {
|   it-second.reset();
|   }
|   } else {
|   CounterList::iterator it = counterList.find(match);

Only if:
 - exact match is wanted.
 - only one element in counterList can match.

|   if (it != counterList.end())
|   it-second.reset();
|   }
| }

| ?

| Angus


-- 
Lgb

Re: nasty eqns lead to crash

[Martin Vermeer]

On Fri, Aug 09, 2002 at 10:37:10AM +0100, Angus Leeming wrote:

...

   Andre ? Martin ?
 
  Seems correct to me. The first dozen lines or so in LyXText::setCounter
  are: if a par has no previous(), it resets its counter array, otherwise it
  copies the one of its predecessor. Should cover all cases.
 
  Inside Counters::reset and copy, I don't see it either. What should be
  undefined? match, if it is the empty string? To my eyes, it looks OK.
  Or is perhaps .find() not supposed to have an empty arg?
 
 It doesn't, it has a string argument that just happens to be empty. That's 
 fine and string::find will return string::npos (for which you already test).

Unfortunately it didn't work properly. That's why I added the separate
empty test. (It returned haphazard, random-looking boolean values for

it-first.find(match) != string::npos

in case match was empty. That's gcc-2.95.2 on intel-linux.)
 
 That is assuming that you haven't populated your map with an empty string() 
 as an index...

Have I? :-)
 
...

 And whether you choose to use two loops or one, that should be match.empty(), 
 not match == . 

Be my guest.
 
 If you choose to remain with a single loop then you should also move the 
 match.empty() test to the front of the if statement as it's quicker than 
 find... (I believe that they're executed in order).

Yes, I agree.
 
 Angus
 

Martin




msg42284/pgp0.pgp
Description: PGP signature

Re: nasty eqns lead to crash

[Angus Leeming]

Amazing what happens if you dig deeper

aleem@pneumon:src- grep counters() *.C */*.C | grep copy
text2.C:par-counters().copy(par-previous()-counters(), 
par-counters(), );
aleem@pneumon:src- grep counters() *.C */*.C | grep reset
text2.C:par-counters().reset();
text2.C:par-counters().reset();
text2.C:par-counters().reset(enum);
text2.C:par-counters().reset(enum);

So, Counters::copy() is used only as 
Counters::copy(Counters  from, Counters  to);

and can therefore be simplified to

void Counters::copy(Counters  from, Counters  to)
{
CounterList::iterator it = counterList.begin();
CounterList::iterator end = counterList.end();
for (; it != end; ++it) {
to.set(it-first, from.value(it-first));
} 
}


whilst Counters::reset should be written as

void Counters::reset(string const  match)
{
CounterList::iterator it = counterList.begin();
CounterList::iterator end = counterList.end();
if (match.empty()) {
for (; it != end; ++it) {
it-second.reset();
}
} else {
// reset all counters whose index contains match as a
// sub-string
for (; it != end; ++it) {
if (it-first.find(match) != string::npos)
it-second.reset();
}
}
}

Angus

Re: nasty eqns lead to crash

[Lars Gullik Bjønnes]

Angus Leeming [EMAIL PROTECTED] writes:

| Amazing what happens if you dig deeper

| aleem@pneumon:src- grep counters() *.C */*.C | grep copy
| text2.C:par-counters().copy(par-previous()-counters(), 
| par-counters(), );
| aleem@pneumon:src- grep counters() *.C */*.C | grep reset
| text2.C:par-counters().reset();
| text2.C:par-counters().reset();
| text2.C:par-counters().reset(enum);
| text2.C:par-counters().reset(enum);

| So, Counters::copy() is used only as 
|   Counters::copy(Counters  from, Counters  to);

| and can therefore be simplified to

| void Counters::copy(Counters  from, Counters  to)
| {
|   CounterList::iterator it = counterList.begin();
|   CounterList::iterator end = counterList.end();
|   for (; it != end; ++it) {
|   to.set(it-first, from.value(it-first));
|   } 
| }


| whilst Counters::reset should be written as

| void Counters::reset(string const  match)
| {
|   CounterList::iterator it = counterList.begin();
|   CounterList::iterator end = counterList.end();
|   if (match.empty()) {
|   for (; it != end; ++it) {
|   it-second.reset();
|   }
|   } else {
|   // reset all counters whose index contains match as a
|   // sub-string
|   for (; it != end; ++it) {
|   if (it-first.find(match) != string::npos)
|   it-second.reset();
|   }
|   }
| }

Hmm I wonder if this reset function shouldn't be split into two
functions...


void Counters::reset()
{
CounterList::iterator it = counterList.begin();
CounterList::iterator end = counterList.end();
for (; it != end; ++it) {
it-second.reset();
}
}

Which could be simplified...

something similar to:

void Counters::reset()
{
std::for_each(counterList.begin(), counterList.end(),
  std::memfun(Counter::reset));
}


and

void Counters::reset(string const  match)
{
assert(!match.empty());

CounterList::iterator it = counterList.begin();
CounterList::iterator end = counterList.end();
for (; it != end; ++it) {
if (it-first.find(match) != string::npos)
it-second.reset();
}
}


Functions that do only one thing and that does not decide what to do
based on the value of arguments are a good thing.

-- 
Lgb

Re: nasty eqns lead to crash

[Andre Poenitz]

On Fri, Aug 09, 2002 at 11:36:13AM +0100, Angus Leeming wrote:
 and can therefore be simplified to
 
 void Counters::copy(Counters  from, Counters  to)
 {
   CounterList::iterator it = counterList.begin();
   CounterList::iterator end = counterList.end();
   for (; it != end; ++it) {
   to.set(it-first, from.value(it-first));
   } 
 }

Does this change 'from'?


Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: nasty eqns lead to crash

[Angus Leeming]

On Friday 09 August 2002 12:23 pm, Andre Poenitz wrote:
 On Fri, Aug 09, 2002 at 11:36:13AM +0100, Angus Leeming wrote:
  and can therefore be simplified to
 
  void Counters::copy(Counters  from, Counters  to)
  {
  CounterList::iterator it = counterList.begin();
  CounterList::iterator end = counterList.end();
  for (; it != end; ++it) {
  to.set(it-first, from.value(it-first));
  }
  }

 Does this change 'from'?

int Counters::value(string const  ctr) const
{
CounterList::const_iterator cit = counterList.find(ctr);
if (cit == counterList.end()) {
lyxerr  value: Counter does not exist:   ctr  endl;
return 0;
}
return cit-second.value();
}

No.

Re: nasty eqns lead to crash

[Angus Leeming]

On Friday 09 August 2002 11:59 am, Angus Leeming wrote:
 On Friday 09 August 2002 12:23 pm, Andre Poenitz wrote:
  On Fri, Aug 09, 2002 at 11:36:13AM +0100, Angus Leeming wrote:
   and can therefore be simplified to
  
   void Counters::copy(Counters  from, Counters  to)
   {
 CounterList::iterator it = counterList.begin();
 CounterList::iterator end = counterList.end();
 for (; it != end; ++it) {
 to.set(it-first, from.value(it-first));
 }
   }
 
  Does this change 'from'?

 int Counters::value(string const  ctr) const
 {
   CounterList::const_iterator cit = counterList.find(ctr);
   if (cit == counterList.end()) {
   lyxerr  value: Counter does not exist:   ctr  endl;
   return 0;
   }
   return cit-second.value();
 }

 No.

But you are right to notice that the semantics of this method are very 
confusing.

1. It's a member of Counters, but does not set *this.

Is this what is meant:
void Counters::copy(Counters const  from)
{
CounterList::iterator it = counterList.begin();
CounterList::iterator end = counterList.end();
for (; it != end; ++it) {
it-set(from.value(it-first));
}
}

?

2. Alternatively, it could be a non-member function

void Counters::copy(Counters const  from, Counters  to)
{
CounterList::iterator it = to.counterList.begin();
CounterList::iterator end = to.counterList.end();
for (; it != end; ++it) {
it-set(from.value(it-first));
}
}

As it is, I have no idea what it is meant to be doing, but it ain't doing it!

Angus


But is Counters::copy doing what it's meant to be doing?

Why is it a member variable that resets to

Re: nasty eqns lead to crash

[Angus Leeming]

On Friday 09 August 2002 12:14 pm, Angus Leeming wrote:
 2. Alternatively, it could be a non-member function

 void Counters::copy(Counters const  from, Counters  to)

That's 
void copy(Counters const  from, Counters  to)

Re: Qt frontend trouble on FreeBSD /w qt3.

[Rob Lahaye]

R. Lahaye wrote:
 
   /usr/X11R6/lib/libqt-mt.so.3: undefined reference to `pthread_cond_timedwait'
   gmake[3]: *** [lyx] Error 1
 
 This is because -pthread is somewhere missing in the compilation process. This
 is a typical FreeBSD issue.
 Only on FreeBSD the compiler needs (sometimes?) the -pthread flag. man gcc:
 
   [...]
   -pthread   Link a user-threaded process against libc_r instead
  of libc. Objects linked into user-threaded processes
  should be compiled with -D_THREAD_SAFE.
   [...]

In the configure script, I have to replace all -lc by -lc_r.
BTW config/gnome.m4 and config/ltmain.sh do already something is this direction,
but this is obviously not enough! ltmain.sh says somewhere:
 *-*-openbsd*)
 # Do not include libc due to us having libc/libc_r.
 [...]


In addition I have to set the following environment variables, before running 
configure:

CFLAGS=-D_THREAD_SAFE -pthread
CPPFLAGS=-D_THREAD_SAFE -pthread
CXXFLAGS=-D_THREAD_SAFE -pthread


Then everything is fine.

HOORAY: LyX runs wonderfully with Qt3 on my FreeBSD box!!! Nice, nice, nice!


Apparently, if LyX must work out-of-the-box with Qt, then (Free)BSD requires
some more tweeking of the scripts.

Regards,
Rob.

LFUNs for mouse events

[Andre Poenitz]

Has anybody any opinion on that topic?

I'd use such thing for interanal use in mathed but it looks as the real
inset could use them, too.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: nasty eqns lead to crash

[John Levon]

On Fri, Aug 09, 2002 at 11:27:52AM +0200, Kornel Benko wrote:

 It loads here now, after making some scripts executable.
 (Yes, I am using the non-installed version from the src-directory.

anyone remember how we get them +x in the repository ? Do we have to
re-add them or is there a cvs thingy ?

regards
john

-- 
It is unbecoming for young men to utter maxims.
- Aristotle

Re: [PATCH] graphics

[John Levon]

On Fri, Aug 09, 2002 at 08:30:09AM +0200, Herbert Voss wrote:

 that is what I called the nice committing policy of LyX ...

I don't like to apply patches that I don't understand of code I don't
know, that's all ... no need to get het up about it.

The stuff gets in eventually doesn't it ?

regards
john
-- 
It is unbecoming for young men to utter maxims.
- Aristotle

Re: nasty eqns lead to crash

[Angus Leeming]

On Friday 09 August 2002 1:18 pm, John Levon wrote:
 On Fri, Aug 09, 2002 at 11:27:52AM +0200, Kornel Benko wrote:
  It loads here now, after making some scripts executable.
  (Yes, I am using the non-installed version from the src-directory.

 anyone remember how we get them +x in the repository ? Do we have to
 re-add them or is there a cvs thingy ?

either way, LyX shouldn't crash...

Re: Qt frontend trouble on FreeBSD /w qt3.

[John Levon]

On Fri, Aug 09, 2002 at 05:05:25PM +0900, R. Lahaye wrote:

   linking: -lqui (linking with /usr/X11R6/lib/libqui.so)

Oh sweet. Really nice. What is it with FreeBSD and stupid renamings of
libraries ? Don't they realise how painful qt2.m4 is ?

   checking for Qt... configure: error: Qt2 (libraries) not found. Please check
 your installation!
 Why is QTDIR/lib and QTDIR/include not found?

You will have to look into config.log to tell me that.

   Toolbar_pimpl.C:45: `tie' undeclared in namespace `boost'

OK will fix.

   /usr/X11R6/lib/libqt-mt.so.3: undefined reference to `pthread_attr_destroy'

You can't use qt-mt. Why is it picking this version up ?

regards
john

-- 
It is unbecoming for young men to utter maxims.
- Aristotle

Re: LFUNs for mouse events

[John Levon]

On Fri, Aug 09, 2002 at 02:17:16PM +0200, Andre Poenitz wrote:

 Has anybody any opinion on that topic?
 
 I'd use such thing for interanal use in mathed but it looks as the real
 inset could use them, too.

Please. We have :

insetButtonPress
insetButtonRelease
edit() (1)
edit() (2)

and the interactions between them is thoroughly baffling. Feel free to
sort all this out.

regards
john

-- 
It is unbecoming for young men to utter maxims.
- Aristotle

Re: nasty eqns lead to crash

[Lars Gullik Bjønnes]

Angus Leeming [EMAIL PROTECTED] writes:

| On Friday 09 August 2002 12:14 pm, Angus Leeming wrote:
 2. Alternatively, it could be a non-member function

 void Counters::copy(Counters const  from, Counters  to)

| That's 
| void copy(Counters const  from, Counters  to)

How is this then different from a member function

void operator=(Counters const  from) ??

-- 
Lgb

Re: nasty eqns lead to crash

[John Levon]

On Fri, Aug 09, 2002 at 12:51:03PM +0100, Angus Leeming wrote:

 either way, LyX shouldn't crash...

That's true. It usually involves some horrid BadDrawable, as if the
execvp failure is still trying to draw a non-existent pixmap or
something

john

-- 
It is unbecoming for young men to utter maxims.
- Aristotle

Re: LFUNs for mouse events

[Andre Poenitz]

On Fri, Aug 09, 2002 at 01:28:26PM +0100, John Levon wrote:
  I'd use such thing for interanal use in mathed but it looks as the real
  inset could use them, too.
 
 Please. We have :
 
   insetButtonPress
   insetButtonRelease
   edit() (1)
   edit() (2)
 
 and the interactions between them is thoroughly baffling. Feel free to
 sort all this out.

But I have no strong opinion on how the lfuns should look like.

Maybe a single LFUN_MOUSE?

Maybe and additional ints  x,y,button in FuncRequest?

Or everything getting a single LFUN (MOUSE_1_RELEASE)  ?

Somethign in between?

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: nasty eqns lead to crash

[Angus Leeming]

On Friday 09 August 2002 1:30 pm, Lars Gullik Bjønnes wrote:
 Angus Leeming [EMAIL PROTECTED] writes:
 | On Friday 09 August 2002 12:14 pm, Angus Leeming wrote:
  2. Alternatively, it could be a non-member function
 
  void Counters::copy(Counters const  from, Counters  to)
 |
 | That's
 | void copy(Counters const  from, Counters  to)

 How is this then different from a member function

 void operator=(Counters const  from) ??

Well that would copy from.counterList to this-counterList which is different 
from what I believe it is meant to be doing:

void Counters::copy(Counters const  from)
{
CounterList::iterator it  = counterList.begin();
CounterList::iterator end = counterList.end();
for (; it != end; ++it) {
it-second.set(from.value(it-first));
}
}

Anyway, patch to follow.

Angus

[PATCH]: counters

[Angus Leeming]

I believe that this makes more sense (and in the case of copy is probably 
correct too ;-) than the current code.

Martin, since I don't know the code at all or even fully understand what it 
is meant to be doing, perhaps you could have a look at the patch and 
ascertain that it is doing what you meant it to be doing in the ffirst place?



Index: src/counters.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/counters.C,v
retrieving revision 1.10
diff -u -p -r1.10 counters.C
--- src/counters.C	9 Aug 2002 12:15:18 -	1.10
+++ src/counters.C	9 Aug 2002 12:19:12 -
 -18,6 +18,8 
 #include counters.h
 #include debug.h
 #include support/lstrings.h
+#include support/LAssert.h
+
 
 using std::endl;
 using std::vector;
 -111,6 +113,8  Counters::Counters()
 
 void Counters::newCounter(string const  newc)
 {
+	lyx::Assert(!newc.empty());
+
 	// First check if newc already exist
 	CounterList::iterator cit = counterList.find(newc);
 	// if already exist give warning and return
 -126,6 +130,8  void Counters::newCounter(string const 
 
 void Counters::newCounter(string const  newc, string const  masterc)
 {
+	lyx::Assert(!newc.empty()  !masterc.empty());
+
 	// First check if newc already exists
 	CounterList::iterator cit = counterList.find(newc);
 	// if already existant give warning and return
 -198,24 +204,38  void Counters::step(string const  ctr)
 	}
 }
 
+
+void Counters::reset()
+{
+	CounterList::iterator it  = counterList.begin();
+	CounterList::iterator end = counterList.end();
+
+	for (; it != end; ++it) {
+		it-second.reset();
+	}
+}
+
+
 void Counters::reset(string const  match)
 {
-	CounterList::iterator it = counterList.begin();
+	lyx::Assert(!match.empty());
+
+	CounterList::iterator it  = counterList.begin();
 	CounterList::iterator end = counterList.end();
+
 	for (; it != end; ++it) {
-		if (it-first.find(match) != string::npos || match == )
+		if (it-first.find(match) != string::npos)
 			it-second.reset();
 	}
 }
 
-void Counters::copy(Counters  from, Counters  to, string const  match)
+
+void Counters::copy(Counters const  from)
 {
-	CounterList::iterator it = counterList.begin();
+	CounterList::iterator it  = counterList.begin();
 	CounterList::iterator end = counterList.end();
 	for (; it != end; ++it) {
-		if (it-first.find(match) != string::npos || match == ) {
-			to.set(it-first, from.value(it-first));
-		}
+		it-second.set(from.value(it-first));
 	}
 }
 
Index: src/counters.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/counters.h,v
retrieving revision 1.9
diff -u -p -r1.9 counters.h
--- src/counters.h	7 Aug 2002 14:15:06 -	1.9
+++ src/counters.h	9 Aug 2002 12:19:12 -
 -75,12 +75,15  public:
 	/// NOTE sub-slaves not zeroed! That happens at slave's
 	/// first step 0-1. Seems to be sufficient.
 	void step(string const  ctr);
-	/// Reset counters matched by match string. Empty string matches
-	/// all.
-	void reset(string const  match = string());
-	/// Copy counters whose name matches match from the from to 
-	/// the to array of counters. Empty string matches all.
-	void copy(Counters  from, Counters  to, string const  match = string());
+	/// Reset all counters
+	void reset();
+	/// Reset counters that contain match as a sub-string.
+	/// Do not use match == string().
+	void reset(string const  match);
+
+	/// copy all counters from from to *this.
+	void copy(Counters const  from);
+
 	/// A numeric label's single item, like .1 for subsection number in
 	/// the 2.1.4 subsubsection number label. first indicates if this
 	/// is the first item to be displayed, usually chapter or section.
Index: src/text2.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text2.C,v
retrieving revision 1.243
diff -u -p -r1.243 text2.C
--- src/text2.C	7 Aug 2002 16:31:45 -	1.243
+++ src/text2.C	9 Aug 2002 12:19:13 -
 -1222,17 +1222,17  void LyXText::setCounter(Buffer const * 
 	// unless this is the first paragraph
 	if (par-previous()) {
 
-		par-counters().copy(par-previous()-counters(), par-counters(), );
+		par-counters().copy(par-previous()-counters());
 		
 		par-params().appendix(par-previous()-params().appendix());
 		if (!par-params().appendix()  par-params().startOfAppendix()) {
 			par-params().appendix(true);
-			par-counters().reset();
+			par-counters().reset();
 		}
 		par-enumdepth = par-previous()-enumdepth;
 		par-itemdepth = par-previous()-itemdepth;
 	} else {
-		par-counters().reset();
+		par-counters().reset();
 		par-params().appendix(par-params().startOfAppendix());
 		par-enumdepth = 0;
 		par-itemdepth = 0;

Re: nasty eqns lead to crash

[Angus Leeming]

On Friday 09 August 2002 1:30 pm, John Levon wrote:
 On Fri, Aug 09, 2002 at 12:51:03PM +0100, Angus Leeming wrote:
  either way, LyX shouldn't crash...

 That's true. It usually involves some horrid BadDrawable, as if the
 execvp failure is still trying to draw a non-existent pixmap or
 something

can I get you to investigate since I'm sort of busy and you have been 
experiencing the problem...

A

Re: [PATCH]: counters

[Lars Gullik Bjønnes]

Angus Leeming [EMAIL PROTECTED] writes:

| +void Counters::reset()
| +{
| + CounterList::iterator it  = counterList.begin();
| + CounterList::iterator end = counterList.end();
| +
| + for (; it != end; ++it) {
| + it-second.reset();
| + }
| +}

So my std::memfun didn't work?:-)

-- 
Lgb

Re: LFUNs for mouse events

[John Levon]

On Fri, Aug 09, 2002 at 02:34:28PM +0200, Andre Poenitz wrote:

 But I have no strong opinion on how the lfuns should look like.
 
 Maybe a single LFUN_MOUSE?

no

LFUN_PRESS(x,y,button,state)
LFUN_RELEASE(x,y,button,state)
LFUN_MOVE(x,y,...)

but with better names

IMO

regards
john

-- 
It is unbecoming for young men to utter maxims.
- Aristotle

Re: [PATCH]: counters

[Angus Leeming]

On Friday 09 August 2002 1:53 pm, Lars Gullik Bjønnes wrote:
 Angus Leeming [EMAIL PROTECTED] writes:
 | +void Counters::reset()
 | +{
 | +   CounterList::iterator it  = counterList.begin();
 | +   CounterList::iterator end = counterList.end();
 | +
 | +   for (; it != end; ++it) {
 | +   it-second.reset();
 | +   }
 | +}

 So my std::memfun didn't work?:-)

that's it-second-, not it- ...

I could have 

struct Reset() {
void operator()(std::map::iterator it) { it-second.reset(); }
};

std::for_each(counterList.begin(), counterList.end(), Reset());

but I dodn't think that was more transparent ;-)


Angus

Re: LFUNs for mouse events

[Andre Poenitz]

On Fri, Aug 09, 2002 at 02:06:00PM +0100, John Levon wrote:
  Maybe a single LFUN_MOUSE?
 
 no
 
 LFUN_PRESS(x,y,button,state)
 LFUN_RELEASE(x,y,button,state)
 LFUN_MOVE(x,y,...)
 
 but with better names

What is 'state'?

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: LFUNs for mouse events

[John Levon]

On Fri, Aug 09, 2002 at 03:17:31PM +0200, Andre Poenitz wrote:

 What is 'state'?

Actually we don't use it yet but it was going to be key state
(ctrl alt shift)

so scrub that

john

-- 
It is unbecoming for young men to utter maxims.
- Aristotle

Re: Qt frontend trouble on FreeBSD /w qt3.

[Rob Lahaye]

John Levon wrote:
 On Fri, Aug 09, 2002 at 05:05:25PM +0900, R. Lahaye wrote:
 
 
  linking: -lqui (linking with /usr/X11R6/lib/libqui.so)
 
 
 Oh sweet. Really nice. What is it with FreeBSD and stupid renamings of
 libraries ? Don't they realise how painful qt2.m4 is ?

Forwarded that to FreeBSD qt3 package maintainers. This is the response of
one of them:
Quote: As far as I know, and certainly on my FreeBSD computers, the library
 is named libqt-mt.so.  It's compiled as a multithreaded library, which
 is why the -mt is appended.
 libqui.so is another library, used by Designer, uic and friends, and
 is not the core qt library.

Does that make sense to you?

Why is QTDIR/lib and QTDIR/include not found?
 
 You will have to look into config.log to tell me that.

Sorry, false alarm. Works now.


  /usr/X11R6/lib/libqt-mt.so.3: undefined reference to `pthread_attr_destroy'
 
 You can't use qt-mt. Why is it picking this version up ?

I thought I wasn't. Hmmm, but according to Mr. FreeBSD a few line up, I *should*
use qt-mt !?!?!

This certainly needs more tweeking, since then the compilation on FreeBSD with qt3
needs specific compiler options: -pthread -D_THREAD_SAFE. And instead of linking
with -lc, it should be -lc_r !

THEN: it should work for FreeBSD with Qt3 :).

Rob.

Re: Qt frontend trouble on FreeBSD /w qt3.

[John Levon]

On Fri, Aug 09, 2002 at 10:22:50PM +0900, Rob Lahaye wrote:

 Forwarded that to FreeBSD qt3 package maintainers. This is the response of
 one of them:
 Quote: As far as I know, and certainly on my FreeBSD computers, the library
 is named libqt-mt.so.  It's compiled as a multithreaded library, 
 which
 is why the -mt is appended.

Yup.

 libqui.so is another library, used by Designer, uic and friends, and
 is not the core qt library.

Ah, never heard of it before. I understood you as saying this was the
name of the qt library on freeBsd. That's much saner then.

 This certainly needs more tweeking, since then the compilation on FreeBSD 
 with qt3
 needs specific compiler options: -pthread -D_THREAD_SAFE. And instead of 
 linking
 with -lc, it should be -lc_r !

Exactly. We don't want all this stuff. Seeing as I only loook for
libqt.so not qt-mt, I'm a bit lost as to how you managed to end up
linking against the mt version

regards
john (desparately trying to avoid touching qt2.m4)

-- 
It is unbecoming for young men to utter maxims.
- Aristotle

Kornel's example and lyxsize_type

[Angus Leeming]

Kornel, I notice that loading up your document gives an error

Unknown token, lyxsize_type, skipping.
Unknown token, 1, skipping.

You should fix this with

sed 's/lyxsize_type/lyxsize_kind/g'  ColMathXLII.lyx  temp
mv temp ColMathXLII.lyx

I know that you can now load the document fine, but you may have others where 
this occurs...

...of course, I still can't load the bugger ;-)

Angus

Fwd: Visitor ...

[Angus Leeming]

Look what I dug out of my mailbox. Did anything ever come of this?

Angus

--  Forwarded Message  --

Subject: Visitor ...
Date: Fri, 14 Dec 2001 05:15:44 +
From: John Levon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]

here's a working example of what Ben had designed (did this so I
could work out what he was saying :)

Dunno about others, but I prefer the name of visitInset to stay
the same no matter what ...

the two problems ben has been trying to fix with this (accompanied
by stupid questions from myself) are :

1) each inset has to be listed in InsetVisitor

2) each inset HAS to have an acceptVisitor() method

I still think it's worth it, even better if anyone can solve either
of these problems ...

regards
john

#include iostream

class Inset;
class InsetERT;

class InsetVisitor {
// blah blah
public:
// need every possible inset listed here
// for dynamic dispatch based on inset type,
// to be robust against future visitor classes
virtual void visitInset(Inset )  {};
virtual void visitInset(InsetERT ) {};
};

class Inset {
// blah blah
public:
virtual void acceptVisitor(InsetVisitor  iv) {
iv.visitInset(*this);
}
};

class InsetERT : public Inset {
// blah blah
private:
// need this here to get the right type for visitInset
virtual void acceptVisitor(InsetVisitor  iv) {
iv.visitInset(*this);
}
};

class SpellCheckInsetVisitor : public InsetVisitor {
public:
virtual void visitInset(Inset ) {
// do default spellcheck
std::cout  default spellcheck  std::endl;
}
virtual void visitInset(InsetERT ) {
// don't do any spellcheck !!
std::cout  ert no spellcheck  std::endl;
}

// this is the top-level code
void doSpellcheck() {
//for_each(bv.inset_iterator_begin(), bv.inset_iterator_end(),
 acceptVisitor(this)); Inset * ie = new InsetERT;
ie-acceptVisitor(*this);
}
};

int main() {
SpellCheckInsetVisitor v;
v.doSpellcheck();
}

PATCH latex fixes

[Herbert Voss]

this loads by default the _official_ latex fixes,
which will never get in the latex source.

Herbert


-- 
http://www.lyx.org/help/


Index: lib/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/ChangeLog,v
retrieving revision 1.264
diff -u -r1.264 ChangeLog
--- lib/ChangeLog   8 Aug 2002 13:01:08 -   1.264
+++ lib/ChangeLog   9 Aug 2002 13:30:10 -
@@ -1,3 +1,8 @@
+2002-08-09  Herbert Voss  [EMAIL PROTECTED]
+
+   * chkconfig.ltx: check for the official fixes of latex2e
+   fixltx2e.sty
+   
 2002-08-08  Herbert Voss  [EMAIL PROTECTED]
 
* ui/default.ui: put gather into math menu
Index: lib/chkconfig.ltx
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/chkconfig.ltx,v
retrieving revision 1.9
diff -u -r1.9 chkconfig.ltx
--- lib/chkconfig.ltx   1 Mar 2002 12:39:19 -   1.9
+++ lib/chkconfig.ltx   9 Aug 2002 13:30:10 -
@@ -213,6 +213,7 @@
 \TestPackage{babel}
 \TestPackage{color} % this one should be there if graphics.sty is there.
 \TestPackage{fancyhdr}
+\TestPackage{fixltx2e}
 \TestPackage{floatflt}
 \TestPackage{setspace}
 \TestPackage{subfigure}
Index: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.871
diff -u -r1.871 ChangeLog
--- src/ChangeLog   9 Aug 2002 02:50:19 -   1.871
+++ src/ChangeLog   9 Aug 2002 13:30:15 -
@@ -1,3 +1,8 @@
+2002-08-09  Herbert Voss  [EMAIL PROTECTED]
+
+   * buffer.C (makeLaTeXFile): add command \usepackage{fixltx2e}
+   to get the official fixes by default
+ 
 2002-08-09  John Levon  [EMAIL PROTECTED]
 
* lyxtext.h: remove unused refresh_height
Index: src/buffer.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/buffer.C,v
retrieving revision 1.364
diff -u -r1.364 buffer.C
--- src/buffer.C9 Aug 2002 00:42:10 -   1.364
+++ src/buffer.C9 Aug 2002 13:30:17 -
@@ -2301,6 +2315,12 @@
os  '{'  tclass.latexname()  }\n;
texrow.newline();
// end of \documentclass defs
+   
+   // at first we load the official fixes for LaTeX2e, which 
+   // should be part of any tex-installation, but a test is save
+   if (!findtexfile(fixltx2e.sty, tex).empty())
+   os  \\usepackage{fixltx2e} 
+%% the official fixes for LaTeX2e\n;
 
// font selection must be done before loading fontenc.sty
// The ae package is not needed when using OT1 font encoding.

Re: Qt frontend trouble on FreeBSD /w qt3.

[Rob Lahaye]

John Levon wrote:
 
 Ah, never heard of it before. I understood you as saying this was the
 name of the qt library on freeBsd. That's much saner then.

Yes, I was wrong. That info was also new to me.
Somehow, though, I managed to produce an executble that does not crash!


 Exactly. We don't want all this stuff. Seeing as I only loook for
 libqt.so not qt-mt, I'm a bit lost as to how you managed to end up
 linking against the mt version

by having following in /usr/X11R6/lib:

  libqt-mt.so - libqt-mt.so.3.0.5
  libqt-mt.so.3 - libqt-mt.so.3.0.5
  libqt-mt.so.3.0 - libqt-mt.so.3.0.5
  libqt-mt.so.3.0.5
  libqt.so.3 - libqt-mt.so
  libqt.so - libqt.so.3

The last two have I done manually (they do not come with the qt3 package!).

I'm afraid, all that pthread stuff is necessary on FreeBSD when the library is 
threaded.

Rob.

Re: Fwd: Visitor ...

[John Levon]

On Fri, Aug 09, 2002 at 02:07:04PM +0100, Angus Leeming wrote:

 Look what I dug out of my mailbox. Did anything ever come of this?

Not from me. Not sure about Ben.

He pops into to #lyx every now and then, but he's still busy writing up.
Maybe when he gets some free time again he might be interested in
reviving this idea. I forget how far he/we got.

   virtual void visitInset(Inset ) {
   // do default spellcheck
   std::cout  default spellcheck  std::endl;
   }
   virtual void visitInset(InsetERT ) {
   // don't do any spellcheck !!
   std::cout  ert no spellcheck  std::endl;
   }

this is so much better than the current virtual method everywhere mess,
IMHO.

I was expermenting with inset_traits yesterday, a realted topic. But hit
the snag of multiple multiple inheritance and ambiguity of resolution,
which I think Ben is referring to here :

http://marc.theaimsgroup.com/?l=lyx-develm=102748076625761w=2

Lars has on his immediate TODO list :

- try out the visitor pattern on the inset write methods.

(http://marc.theaimsgroup.com/?l=lyx-develm=102748013425456w=2)

which would certainly be nicer.

regards
john

-- 
It is unbecoming for young men to utter maxims.
- Aristotle

Re: Qt frontend trouble on FreeBSD /w qt3.

[John Levon]

On Fri, Aug 09, 2002 at 10:44:59PM +0900, Rob Lahaye wrote:

  libqt-mt.so - libqt-mt.so.3.0.5
 
 I'm afraid, all that pthread stuff is necessary on FreeBSD when the library 
 is threaded.

FreeBSD do not ship an unthreaded Qt library ?

Lars, what can we do about this ? Looks like we really need to handle
all this pthreads boomf

john

-- 
It is unbecoming for young men to utter maxims.
- Aristotle

Re: Qt frontend trouble on FreeBSD /w qt3.

[Rob Lahaye]

John Levon wrote:
 On Fri, Aug 09, 2002 at 10:44:59PM +0900, Rob Lahaye wrote:
 
 
 libqt-mt.so - libqt-mt.so.3.0.5

I'm afraid, all that pthread stuff is necessary on FreeBSD when the library 
is threaded.
 
 
 FreeBSD do not ship an unthreaded Qt library ?

Nope. Qt is considered to be closely engaged by KDE, which needs the threads.
Hence only threaded library is provided, to prevent confusion, or something
like that. Anyway, we're stuck with threaded Qt library on FreeBSD.

 Lars, what can we do about this ? Looks like we really need to handle
 all this pthreads boomf

Qt people suggest qmake could be of good help. Are you familiar with that?
(qmake seems to be a more intelligent version of tmake).

Rob.

Re: Fwd: Visitor ...

[Andre Poenitz]

On Fri, Aug 09, 2002 at 02:07:04PM +0100, Angus Leeming wrote:
 Look what I dug out of my mailbox. Did anything ever come of this?

Nothing that I am aware of.

And I am still undecided whether this regrouping of functionailty is
worthwhile...

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: Fwd: Visitor ...

[Andre Poenitz]

On Fri, Aug 09, 2002 at 02:48:06PM +0100, John Levon wrote:
 this is so much better than the current virtual method everywhere mess,
 IMHO.

This is not really different. You have an array Insets x Methods,
classical virtual functions group things by rows, Visitors by columns.

Only if #cols  #rows I see a real gain...

And I guess we have #cols ~= #rows  in LyX.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: Fwd: Visitor ...

[Angus Leeming]

On Friday 09 August 2002 3:42 pm, Andre Poenitz wrote:
 On Fri, Aug 09, 2002 at 02:07:04PM +0100, Angus Leeming wrote:
  Look what I dug out of my mailbox. Did anything ever come of this?

 Nothing that I am aware of.

 And I am still undecided whether this regrouping of functionailty is
 worthwhile...

I guess that that depends on what you think that a Buffer, or a Paragraph or 
indeed a TextInset should provide.

It seems to me that Buffer and Paragraph are horrible beasts because they do 
too much. If they became little more than dumn containers and provided the 
outside world with decent iterators, then the outside world could do far 
more. Spellcheck, for example.

Your argument about rows and cols would be stronger if we only tried to do 
one thing with each inset. Instead, however, we try and do many, many things, 
to the point where

One Thing, One File

starts to be at least an attractive alternative to 

One Class, One File

I ask myself how complicated is the concept of a Paragraph and then I ask 
myself how well I understand (even, how often have I ventured inside!) the 
current Paragraph code?

The answers, invariably, start with Not very!

Angus

Re: Support for LyX in design recovery tool?

[John Levon]

On Fri, Aug 09, 2002 at 03:32:56PM +1000, Amir Michail wrote:

 I looked into getting rid of cursor blinking for the design recovery tool. 
 (This makes it easier to track the cursor from screenshots.)  Apparently, 
 it's not easy to do since every inset has its own cursor blinking code, some 
 of which is not trivial (e.g., tabular inset).

It's a foul mess, isn't it ?

Attached is a patch to get rid of the blinks, but unfortunately it
leaves some trailing cursors in some tabular cases.
Amusingly the obvious fix of hideInsetCursor() before unlocking the
insettext (the thing with the red border in the cell) actually causes
MORE cursors to be drawn. That says a lot about the state of the code I
think ...

regards
john


? newfile6.lyx
? blink.diff
? cvs.log
? g.lyx
? g1.lyx
? g2.lyx
? lyx3.png
? newfile1.lyx
? newfile2.lyx
? newfile3.lyx
? newfile4.lyx
? newfile5.lyx
? frontends/qt2/cvs.log
? frontends/qt2/a.diff
? frontends/qt2/mb.diff
Index: frontends/screen.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/screen.C,v
retrieving revision 1.19
diff -u -r1.19 screen.C
--- frontends/screen.C  6 Aug 2002 13:00:50 -   1.19
+++ frontends/screen.C  9 Aug 2002 15:04:23 -
 -173,9 +173,11 
 }
 
 
+bool const blink = false;
+ 
 void LyXScreen::cursorToggle(BufferView * bv) const
 {
-   if (cursor_visible_)
+   if (cursor_visible_  blink)
bv-hideCursor();
else
bv-showCursor();
Index: insets/insettabular.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insettabular.C,v
retrieving revision 1.220
diff -u -r1.220 insettabular.C
--- insets/insettabular.C   7 Aug 2002 12:00:08 -   1.220
+++ insets/insettabular.C   9 Aug 2002 15:04:31 -
 -1417,6 +1417,7 
y = cursor_.y();
 }
 
+int const blink = false; 
 
 void InsetTabular::toggleInsetCursor(BufferView * bv)
 {
 -1435,11 +1436,13 
int const asc = font_metrics::maxAscent(font);
int const desc = font_metrics::maxDescent(font);
 
-   if (isCursorVisible())
+   if (isCursorVisible()  blink) {
bv-hideLockedInsetCursor();
-   else
+   toggleCursorVisible();
+   } else {
bv-showLockedInsetCursor(cursor_.x(), cursor_.y(), asc, desc);
-   toggleCursorVisible();
+   toggleCursorVisible();
+   }
 }
 
 
Index: insets/insettext.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insettext.C,v
retrieving revision 1.313
diff -u -r1.313 insettext.C
--- insets/insettext.C  9 Aug 2002 02:50:19 -   1.313
+++ insets/insettext.C  9 Aug 2002 15:04:37 -
 -1763,6 +1763,8 
 }
 
 
+int const blink = false;
+
 void InsetText::toggleInsetCursor(BufferView * bv)
 {
if (the_locking_inset) {
 -1775,11 +1777,13 
int const asc = font_metrics::maxAscent(font);
int const desc = font_metrics::maxDescent(font);
 
-   if (isCursorVisible())
+   if (isCursorVisible()  blink) {
bv-hideLockedInsetCursor();
-   else
+   toggleCursorVisible();
+   } else {
bv-showLockedInsetCursor(cx(bv), cy(bv), asc, desc);
-   toggleCursorVisible();
+   toggleCursorVisible();
+   } 
 }
 
 
Index: mathed/formulabase.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/formulabase.C,v
retrieving revision 1.196
diff -u -r1.196 formulabase.C
--- mathed/formulabase.C9 Aug 2002 08:24:34 -   1.196
+++ mathed/formulabase.C9 Aug 2002 15:04:39 -
 -220,10 +220,12 
 }
 
 
+int const blink = false;
+ 
 void InsetFormulaBase::toggleInsetCursor(BufferView * bv)
 {
//lyxerr  toggleInsetCursor:   isCursorVisible()  \n;
-   if (isCursorVisible())
+   if (isCursorVisible()  blink)
hideInsetCursor(bv);
else
showInsetCursor(bv);

Re: Kornel's example and lyxsize_type

[Kornel Benko]

-BEGIN PGP SIGNED MESSAGE-

On Friday 09 August 2002 14:57, Angus Leeming wrote:
 Kornel, I notice that loading up your document gives an error

 Unknown token, lyxsize_type, skipping.
 Unknown token, 1, skipping.

 You should fix this with

 sed 's/lyxsize_type/lyxsize_kind/g'  ColMathXLII.lyx  temp
 mv temp ColMathXLII.lyx

I am not very happy with this. This document is perfectly ok with lyx-1.2, as far as I 
can see.
And there are still problems with its math-labels and lyx-1.3.

As a consequence this is the output of lyx-1.2:
Token: 'lyxsize_kind'
Unknown token, lyxsize_kind, skipping.
Token: '1'

 I know that you can now load the document fine, but you may have others
 where this occurs...

Yes, and, until now, I have to load the most docs with 1.2 and save before reading 
them with 1.3.

 ...of course, I still can't load the bugger ;-)

Seems to be a pretty good test-file, isn't it?

Kornel

- -- 
Kornel Benko
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: PGP 6.5.8

iQCVAwUBPVPfN7ewfbDGmeqhAQFc9wQAyv70wqD1uSbYy6fZh00RlDfxtP+t8iAb
ChIfTi26+X5JiNhtOi4H9PoDZSuPYkr9lkDTNQ9OJK//83H3q8Fd0gD6FzDBo8q8
1TmGxg3YaITMJq66GY+vZxzrpkU3GEPjNQ24HxpO/syN9JYbd/qI+J9G882Nr6yw
dMhKPsir09k=
=MlQt
-END PGP SIGNATURE-

Re: Kornel's example and lyxsize_type

[Angus Leeming]

On Friday 09 August 2002 4:24 pm, Kornel Benko wrote:
 On Friday 09 August 2002 14:57, Angus Leeming wrote:
  Kornel, I notice that loading up your document gives an error
 
  Unknown token, lyxsize_type, skipping.
  Unknown token, 1, skipping.
 
  You should fix this with
 
  sed 's/lyxsize_type/lyxsize_kind/g'  ColMathXLII.lyx  temp
  mv temp ColMathXLII.lyx

 I am not very happy with this. This document is perfectly ok with lyx-1.2,
 as far as I can see. And there are still problems with its math-labels and
 lyx-1.3.

Me neither. A spurious and not-documented file format change.

Angus

Re: Kornel's example and lyxsize_type

[Herbert Voss]

Angus Leeming wrote:

 On Friday 09 August 2002 4:24 pm, Kornel Benko wrote:
 
On Friday 09 August 2002 14:57, Angus Leeming wrote:

Kornel, I notice that loading up your document gives an error

Unknown token, lyxsize_type, skipping.
Unknown token, 1, skipping.

You should fix this with

sed 's/lyxsize_type/lyxsize_kind/g'  ColMathXLII.lyx  temp
mv temp ColMathXLII.lyx

I am not very happy with this. This document is perfectly ok with lyx-1.2,
as far as I can see. And there are still problems with its math-labels and
lyx-1.3.

 
 Me neither. A spurious and not-documented file format change.


cool statement ...

http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg37514.html

and others ...

Herbert


-- 
http://www.lyx.org/help/

Re: Kornel's example and lyxsize_type

[Angus Leeming]

On Friday 09 August 2002 5:05 pm, Herbert Voss wrote:
 Angus Leeming wrote:
  On Friday 09 August 2002 4:24 pm, Kornel Benko wrote:
 On Friday 09 August 2002 14:57, Angus Leeming wrote:
 Kornel, I notice that loading up your document gives an error
 
 Unknown token, lyxsize_type, skipping.
 Unknown token, 1, skipping.
 
 You should fix this with
 
 sed 's/lyxsize_type/lyxsize_kind/g'  ColMathXLII.lyx  temp
 mv temp ColMathXLII.lyx
 
 I am not very happy with this. This document is perfectly ok with
  lyx-1.2, as far as I can see. And there are still problems with its
  math-labels and lyx-1.3.
 
  Me neither. A spurious and not-documented file format change.

 cool statement ...

It's not documented by being placed in the mail archive. It's not documented 
unless someone at some future date can deal with the difference between two 
versions of the LyX file format. 

Perhaps, since this one is yours, you'd add something to development/FORMAT?

Angus

Re: Kornel's example and lyxsize_type

[Herbert Voss]

Angus Leeming wrote:

 It's not documented by being placed in the mail archive. It's not documented 
 unless someone at some future date can deal with the difference between two 
 versions of the LyX file format. 
 
 Perhaps, since this one is yours, you'd add something to development/FORMAT?


there was no such file! and it's not documented, that someone
created in the meantime such a file ...

Herbert


-- 
http://www.lyx.org/help/

Re: Kornel's example and lyxsize_type

[Angus Leeming]

On Friday 09 August 2002 5:50 pm, Herbert Voss wrote:
 Angus Leeming wrote:
  It's not documented by being placed in the mail archive. It's not
  documented unless someone at some future date can deal with the
  difference between two versions of the LyX file format.
 
  Perhaps, since this one is yours, you'd add something to
  development/FORMAT?

 there was no such file! and it's not documented, that someone
 created in the meantime such a file ...

touché!

However, it looks to me like you forgot lyxsize_type when you added the 
compatibility stuff for 1.2.0 on 23 July

http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/src/insets/insetgraphicsParams.C.diff?r1=texttr1=1.45r2=texttr2=1.46diff_format=h

Do you agree?

I guess therefore that a similar piece of compatibility code is needed for 
lyxsize_type and that both pieces should be documented in development/FORMAT 
so that this code can be stripped out of insetgraphicsParams.C when José 
comes to write lyxconvert_221.py

Angus

Re: Kornel's example and lyxsize_type

[Herbert Voss]

Angus Leeming wrote:

 On Friday 09 August 2002 5:50 pm, Herbert Voss wrote:
 
Angus Leeming wrote:

It's not documented by being placed in the mail archive. It's not
documented unless someone at some future date can deal with the
difference between two versions of the LyX file format.

Perhaps, since this one is yours, you'd add something to
development/FORMAT?

there was no such file! and it's not documented, that someone
created in the meantime such a file ...

 
 touché!
 
 However, it looks to me like you forgot lyxsize_type when you added the 
 compatibility stuff for 1.2.0 on 23 July
 
 
http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/src/insets/insetgraphicsParams.C.diff?r1=texttr1=1.45r2=texttr2=1.46diff_format=h
 
 Do you agree?
 
 I guess therefore that a similar piece of compatibility code is needed for 
 lyxsize_type and that both pieces should be documented in development/FORMAT 
 so that this code can be stripped out of insetgraphicsParams.C when José 
 comes to write lyxconvert_221.py


http://marc.theaimsgroup.com/?l=lyx-develm=102737398526073w=2
http://marc.theaimsgroup.com/?l=lyx-develm=102741383822156w=2

Herbert



-- 
http://www.lyx.org/help/

Re: [PATCH]: counters

[Martin Vermeer]

On Fri, Aug 09, 2002 at 01:05:04PM +0100, Angus Leeming wrote:
 
 I believe that this makes more sense (and in the case of copy is probably 
 correct too ;-) than the current code.

I believe it is correct, though I had to re-read your use of *this's
it-second a few times before actually believing it. It's a bit like
replacing x = x + y by x += y IIUC, and equally not-immediately-obvious
the first time.

Separating out the match ==  case indeed makes it a lot clearer (and
not even needed for copy -- in the *current* state of text2.C).
 
 Martin, since I don't know the code at all or even fully understand what it 
 is meant to be doing, perhaps you could have a look at the patch and 
 ascertain that it is doing what you meant it to be doing in the ffirst place?

Does it work (i.e., do sectioning and enumeration counters count as they
should)? Looks like it ought to. Verify -- I can't easily from this home
dial-up until monday.

Ah, and thanks for cleaning up my empty string practices. Microsoft
Basic is a terrible thing to inflict upon one. 

Martin




msg42329/pgp0.pgp
Description: PGP signature

Re: Kornel's example and lyxsize_type

[Angus Leeming]

On Friday 09 August 2002 6:52 pm, Herbert Voss wrote:
 http://marc.theaimsgroup.com/?l=lyx-develm=102737398526073w=2

No, this one is already in.

I'm talking about lyxsize_kind, not size_kind.

Is the attached patch correct? I believe that it will do the trick.

Angus




Index: src/insets/insetgraphicsParams.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetgraphicsParams.C,v
retrieving revision 1.46
diff -u -p -r1.46 insetgraphicsParams.C
--- src/insets/insetgraphicsParams.C	23 Jul 2002 12:20:21 -	1.46
+++ src/insets/insetgraphicsParams.C	9 Aug 2002 18:06:52 -
 -197,6 +197,22  string const getSizeKindStr(InsetGraphic
 	return original;
 }	
 
+// compatibility-stuff 1.20-1.3.0
+InsetGraphicsParams::sizeKind getSizeKind(int type)
+{
+	switch (type) {
+	case 1:
+		return InsetGraphicsParams::WH;
+
+	case 2:
+		return InsetGraphicsParams::SCALE;
+
+	case 0:
+	default:
+		return InsetGraphicsParams::DEFAULT_SIZE;
+	}
+}
+
 } //anon
 
 
 -282,17 +298,7  bool InsetGraphicsParams::Read(LyXLex  
 	// compatibility-stuff 1.20-1.3.0
 	} else if (token == size_type) {
 		lex.next();
-		switch (lex.getInteger()) {
-		case 0:
-			size_kind = DEFAULT_SIZE;
-			break;
-		case 1:
-			size_kind = WH;
-			break;
-		case 2:
-			size_kind = SCALE;
-			break;
-		}
+		size_kind = getSizeKind(lex.getInteger());
 	} else if (token == width) {
 		lex.next();
 		width = LyXLength(lex.getString());
 -315,6 +321,10  bool InsetGraphicsParams::Read(LyXLex  
 	} else if (token == lyxsize_kind) {
 		lex.next();
 		lyxsize_kind = getSizeKind(lex.getString());
+	// compatibility-stuff 1.20-1.3.0
+	} else if (token == lyxsize_type) {
+		lex.next();
+		lyxsize_kind = getSizeKind(lex.getInteger());
 	} else if (token == lyxwidth) {
 		lex.next();
 		lyxwidth = LyXLength(lex.getString());

Re: [PATCH]: counters

[Angus Leeming]

On Friday 09 August 2002 6:50 pm, Martin Vermeer wrote:
 On Fri, Aug 09, 2002 at 01:05:04PM +0100, Angus Leeming wrote:
  I believe that this makes more sense (and in the case of copy is probably
  correct too ;-) than the current code.

 I believe it is correct, though I had to re-read your use of *this's
 it-second a few times before actually believing it. It's a bit like
 replacing x = x + y by x += y IIUC, and equally not-immediately-obvious
 the first time.

I come from the world of fortran myself, so know exactly what you're talking 
about ;-)

 Does it work (i.e., do sectioning and enumeration counters count as they
 should)? Looks like it ought to. Verify -- I can't easily from this home
 dial-up until monday.

it does in these cases, but I'll let you trial it properly before committing 
it. Wasn't there a case where it didn't work?

Angus

Re: Kornel's example and lyxsize_type

[Herbert Voss]

Angus Leeming wrote:

 On Friday 09 August 2002 6:52 pm, Herbert Voss wrote:
 
http://marc.theaimsgroup.com/?l=lyx-develm=102737398526073w=2

 
 No, this one is already in.
 
 I'm talking about lyxsize_kind, not size_kind.
 
 Is the attached patch correct? I believe that it will do the trick.


http://marc.theaimsgroup.com/?l=lyx-develm=102742975203614w=2

Herbert




-- 
http://www.lyx.org/help/

Short title inset: why doesn't this work?

[Martin Vermeer]

This should work, shouldn't it? Why doesn't it?

The conditional where the insets are created is 
entered as witnessed by the lyxerr.

The insets don't even show up on screen; yet they
appear to save correctly using the write method.
Also latex works, but not right.

I have experimented by creating the inset as a 
standalone, in an arbitrary text location, using a
minibuffer command; that works great. But now I want 
it tied to section etc. and make the label the
section number. But that seems to be an entirely 
different thing. I use insetbib/bibkey as my model,
but it appears not suitable.

What am I missing?

Martin



Index: text2.C
===
RCS file: /cvs/lyx/lyx-devel/src/text2.C,v
retrieving revision 1.243
diff -u -p -r1.243 text2.C
--- text2.C 2002/08/07 16:31:45 1.243
+++ text2.C 2002/08/09 18:04:25
 -39,6 +39,7 
 #include insets/insetspecialchar.h
 #include insets/insettext.h
 #include insets/insetfloat.h
+#include insets/insetshorttitle.h
 
 #include support/LAssert.h
 #include support/textutils.h
 -408,6 +409,8  Inset * LyXText::getInset() const
Inset * inset = 0;
if (cursor.pos() == 0  cursor.par()-bibkey) {
inset = cursor.par()-bibkey;
+   } else if (cursor.pos()== 0  cursor.par()-shorttitle) {
+   inset = cursor.par()-shorttitle;
} else if (cursor.pos()  cursor.par()-size()
cursor.par()-isInset(cursor.pos())) {
inset = cursor.par()-getInset(cursor.pos());
 -1313,7 +1319,13  void LyXText::setCounter(Buffer const * 
s  par-counters().numberLabel(par-counters().sects[i], 
numbertype, langtype, head);
 
-   par-params().labelString(par-params().labelString() 
+s.str().c_str());
+   if (!par-shorttitle) {
+   par-shorttitle = new InsetShortTitle(buf-params);
+   lyxerr  par-shorttitle   s.str()  endl;
+   par-shorttitle-setLabel(s.str());
+   }
+   
+   // par-params().labelString(par-params().labelString() + 
+s.str().c_str());
// We really want to remove the c_str as soon as
// possible...
 


// -*- C++ -*-
/* This file is part of*
 * ==
 *
 *   LyX, The Document Processor
 *
 *   Copyright 1995 Matthias Ettrich
 *   Copyright 1995-2001 The LyX Team
 *
 * == */

#ifndef INSETSHORTTITLE_H
#define INSETSHORTTITLE_H

#ifdef __GNUG__
#pragma interface
#endif

#include insettext.h
#include insetcollapsable.h

class InsetShortTitle : public InsetCollapsable {
public:
InsetShortTitle(BufferParams const );
///
InsetShortTitle(InsetShortTitle const , bool same_id = false);

Inset * clone(Buffer const , bool same_id = false) const;
///
void draw(BufferView *, LyXFont const , int, float , bool) ;
///
EDITABLE editable() const { return IS_EDITABLE; }
///
Inset::Code lyxCode() const { return Inset::SHORTTITLE_CODE; }
///
void edit(BufferView *, int, int, mouse_button::state);
///
void edit(BufferView * bv, bool front = true);
///
string const editMessage() const;
///
int latex(Buffer const *, std::ostream ) const;
///
void write(Buffer const * buf, ostream  os) const;
///
//int ascii(Buffer const *, std::ostream , int linelen) const;
///
//int linuxdoc(Buffer const *, std::ostream ) const;
///
//int docbook(Buffer const *, std::ostream ) const;
};

#endif


/* This file is part of
 * ==
 *
 *   LyX, The Document Processor
 *
 *  Copyright 1995 Matthias Ettrich
 *  Copyright 1995-2001 The LyX Team.
 *
 * == */

#include config.h

#ifdef __GNUG__
#pragma implementation
#endif

#include insetshorttitle.h
#include support/LOstream.h
#include frontends/Alert.h
#include support/lstrings.h //frontStrip, strip
#include lyxtext.h
#include buffer.h
#include gettext.h
#include BufferView.h
#include support/lstrings.h

using std::ostream;
using std::vector;
using std::pair;

/* Shorttitle. Used to insert a short version of sectioning header etc.
 *  automatically */


InsetShortTitle::InsetShortTitle(BufferParams const  ins)
: InsetCollapsable(ins, false)
{
}

InsetShortTitle::InsetShortTitle(InsetShortTitle const  in, bool same_id)
: InsetCollapsable(in, same_id)
{
}

Inset * InsetShortTitle::clone(Buffer const , bool same_id) const
{
return new InsetShortTitle(*this, same_id);

Re: Kornel's example and lyxsize_type

[Angus Leeming]

On Friday 09 August 2002 7:22 pm, Herbert Voss wrote:
 Angus Leeming wrote:
  On Friday 09 August 2002 6:52 pm, Herbert Voss wrote:
 http://marc.theaimsgroup.com/?l=lyx-develm=102737398526073w=2
 
  No, this one is already in.
 
  I'm talking about lyxsize_kind, not size_kind.
 
  Is the attached patch correct? I believe that it will do the trick.

 http://marc.theaimsgroup.com/?l=lyx-develm=102742975203614w=2

Herbert, this is fundamentally incompatible with the existing code which 
reads a string for size_kind.

} else if (token == size_kind)  {
lex.next();
size_kind = getSizeKind(lex.getString());

So, let me ask again, does the patch I sent you fix the problem? I believe it 
does, but am rapidly reaching the don't care point.

Angus

Re: [PATCH]: counters

[Martin Vermeer]

On Fri, Aug 09, 2002 at 06:55:22PM +0100, Angus Leeming wrote:
 
 On Friday 09 August 2002 6:50 pm, Martin Vermeer wrote:
  On Fri, Aug 09, 2002 at 01:05:04PM +0100, Angus Leeming wrote:
   I believe that this makes more sense (and in the case of copy is probably
   correct too ;-) than the current code.
 
  I believe it is correct, though I had to re-read your use of *this's
  it-second a few times before actually believing it. It's a bit like
  replacing x = x + y by x += y IIUC, and equally not-immediately-obvious
  the first time.
 
 I come from the world of fortran myself, so know exactly what you're talking 
 about ;-)

Grrr... satellite predictions in Fortran IV anyone?
 
  Does it work (i.e., do sectioning and enumeration counters count as they
  should)? Looks like it ought to. Verify -- I can't easily from this home
  dial-up until monday.
 
 it does in these cases, but I'll let you trial it properly before committing 
 it. Wasn't there a case where it didn't work?
 
 Angus

If it works for sectioning and enumeration, that's good enough for me,
as this proves you haven't done any damage (as Hippocrates would say).
Formally your patch is a clean transformation.

Float counters fail to count, but that is quite unrelated to this: I
believe it is due to float captions not being part of the same
linked list of paragraphs (as linear text with sectioning headers, or
even nested enumerated lists, are). I have to think of some other
copy-over mechanism than from previous().

Martin




msg42335/pgp0.pgp
Description: PGP signature

Re: Kornel's example and lyxsize_type

[Herbert Voss]

Angus Leeming wrote:

 So, let me ask again, does the patch I sent you fix the problem? I believe it 
 does, but am rapidly reaching the don't care point.


I can't see any problem


Herbert


-- 
http://www.lyx.org/help/

Re: Kornel's example and lyxsize_type

[Angus Leeming]

On Friday 09 August 2002 7:39 pm, Herbert Voss wrote:
 Angus Leeming wrote:
  So, let me ask again, does the patch I sent you fix the problem? I
  believe it does, but am rapidly reaching the don't care point.

 I can't see any problem

Let me spell it out then:

LyX 1.3 does not parse the lyxsize_type token that was present in Kornel's 
file.

It parse's the size_type token because of the patch of yours that Jean-Marc 
applied to insetgraphicsParams.C on 23 July.

You appear to have forgotten lyxsize_kind when you made that particular patch.

All other patches you've pointed out to me in the last half our are 
incompatible with the current code base.

I've asked you, politely, if the patch I posted to you 10 mins ago would fix 
this oversight, since you are 
a) the  guy who changed the file format
b) worried about user problems as you deal with then regularly on the LyX 
User list.

As you can't see the problem, I'll leave things as they are and allow you to 
field the inevitable questions.

Good night.
Angus

Re: [PATCH]: counters

[Angus Leeming]

On Friday 09 August 2002 7:24 pm, Martin Vermeer wrote:
 Float counters fail to count, but that is quite unrelated to this: I
 believe it is due to float captions not being part of the same
 linked list of paragraphs (as linear text with sectioning headers, or
 even nested enumerated lists, are). I have to think of some other
 copy-over mechanism than from previous().

Hmm. The more I look at this code, the less I follow it.

Let's start at the beginning. Why does a Paragraph own a Counters varaible 
not a single Counter?

I can imagine a Paragraph owning a Counter of type Section and that it could 
ascertain the value of this Counter by interrogating the Buffer that owned a 
Counters variable.

It seems daft to have a list in each paragraph when the paragraph uses only a 
single element of the list.

No doubt I'm confused and the current design is Good.

Angus

Re: Kornel's example and lyxsize_type

[Herbert Voss]

Angus Leeming wrote:

 On Friday 09 August 2002 7:39 pm, Herbert Voss wrote:
 
Angus Leeming wrote:

So, let me ask again, does the patch I sent you fix the problem? I
believe it does, but am rapidly reaching the don't care point.

I can't see any problem


I meant your patch ...

Herbert


-- 
http://www.lyx.org/help/

Re: [PATCH]: counters

[Martin Vermeer]

On Fri, Aug 09, 2002 at 08:09:19PM +0100, Angus Leeming wrote:
 
 On Friday 09 August 2002 7:24 pm, Martin Vermeer wrote:
  Float counters fail to count, but that is quite unrelated to this: I
  believe it is due to float captions not being part of the same
  linked list of paragraphs (as linear text with sectioning headers, or
  even nested enumerated lists, are). I have to think of some other
  copy-over mechanism than from previous().
 
 Hmm. The more I look at this code, the less I follow it.
 
 Let's start at the beginning. Why does a Paragraph own a Counters varaible 
 not a single Counter?

Because all counters have to be propagated through the paragraphs linked
list. If it is a standard layout, it should nevertheless hand though all 
sectioning counters to the sectioning headers that may follow -- of any 
level.

 I can imagine a Paragraph owning a Counter of type Section and that it could 
 ascertain the value of this Counter by interrogating the Buffer that owned a 
 Counters variable.

That could actually be better. For floats it is the solution I was
thinking of. But the logic will become a bit different then. 

So your paragraph would only touch the section counter from the buffer-wide
array, assign it to its own counter after stepping (incrementing) it.
Yes that works. 

Also the 'slave' counter (subsection) must then be reset in the Buffer array.
As the next subsection header is encountered in the text, it will be taken 
and incremented.

Hmmm yes, why not? This should work. It might even fix the floats 
problem as a side effect. But how would you set up the Buffer Counters?
I just didn't see how to do that.

 It seems daft to have a list in each paragraph when the paragraph uses only a 
 single element of the list.

Yes. But that's how it was before...
 
 No doubt I'm confused and the current design is Good.

Don't count on it. Your proposal makes sense.

 Angus
 
Martin




msg42340/pgp0.pgp
Description: PGP signature

Re: Short title inset: why doesn't this work?

[Martin Vermeer]

Sorry, forgot this:

Martin



Index: paragraph.h
===
RCS file: /cvs/lyx/lyx-devel/src/paragraph.h,v
retrieving revision 1.39
diff -u -p -r1.39 paragraph.h
--- paragraph.h 2002/08/07 16:31:45 1.39
+++ paragraph.h 2002/08/09 19:30:26
 -26,6 +27,7  class BufferParams;
 class BufferView;
 class Counters;
 class InsetBibKey;
+class InsetShortTitle;
 class Language;
 class LaTeXFeatures;
 class ParagraphParameters;
 -180,6 +182,8  public:
 
///
InsetBibKey * bibkey;  // ale970302
+   ///
+   InsetShortTitle * shorttitle;  // mv020809
 
///
void next(Paragraph *);




msg42341/pgp0.pgp
Description: PGP signature

Re: [PATCH]: counters

[Martin Vermeer]

 So your paragraph would only touch the section counter from the buffer-wide
 array, assign it to its own counter after stepping (incrementing) it.
 Yes that works. 

Actually even better: I don't think that a paragraph should have its own
counter at all. Just the buffer-wide counter array, used directly for
generating the number label string. Is there any reason to store a
number in the paragraph itself?

Martin



msg42342/pgp0.pgp
Description: PGP signature

mathed, support for Bmatrix

[Herbert Voss]

this gives support for missing Bmatrix, which is like {..}

Herbert


-- 
http://www.lyx.org/help/


Index: lib/symbols
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/symbols,v
retrieving revision 1.22
diff -u -r1.22 symbols
--- lib/symbols 5 Aug 2002 16:19:44 -   1.22
+++ lib/symbols 9 Aug 2002 20:13:26 -
 -69,6 +69,7 
 ttoldfont none
   
 # matrix environments
+Bmatrix   matrix  none
 Vmatrix   matrix  none
 bmatrix   matrix  none
 matrixmatrix  none
Index: src/mathed/math_amsarrayinset.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_amsarrayinset.C,v
retrieving revision 1.9
diff -u -r1.9 math_amsarrayinset.C
--- src/mathed/math_amsarrayinset.C 2 Aug 2002 14:04:16 -   1.9
+++ src/mathed/math_amsarrayinset.C 9 Aug 2002 20:13:48 -
 -33,6 +33,8 
 {
if (name_ == bmatrix)
return [;
+   if (name_ == Bmatrix)
+   return {;
if (name_ == vmatrix)
return |;
if (name_ == Vmatrix)
 -47,6 +49,8 
 {
if (name_ == bmatrix)
return ];
+   if (name_ == Bmatrix)
+   return };
if (name_ == vmatrix)
return |;
if (name_ == Vmatrix)

Re: [PATCH]: counters

[Angus Leeming]

On Friday 09 August 2002 8:41 pm, Martin Vermeer wrote:
 Hmmm yes, why not? This should work. It might even fix the floats
 problem as a side effect. But how would you set up the Buffer Counters?
 I just didn't see how to do that.

Well, a Counter, owned by a Paragraph would have 
type // Section, enum, Figure etc
value // given to it by the Buffer

and the buffer counters would just loop over all Paragraphs from the 
beginning and tell that counter its value.

Something like
SectionValue = 0;
Paragraph * par = buffer.firstParagraph();
while (par) {
// Only some Paragraphs will set their Counter variable.
Counter * counter = par-Counter();
if (Counter  Counter-type == Section) {
Counter-value = SectionValue;
++SectionValue;
}
par = par-next();
}

  It seems daft to have a list in each paragraph when the paragraph uses
  only a single element of the list.

 Yes. But that's how it was before...

There's a lot of code like that ;-)

  So your paragraph would only touch the section counter from the
  buffer-wide array, assign it to its own counter after stepping
  (incrementing) it. Yes that works.

 Actually even better: I don't think that a paragraph should have its own
 counter at all. Just the buffer-wide counter array, used directly for
 generating the number label string. Is there any reason to store a
 number in the paragraph itself?

Well you have to know that the Paragraph is of a certain type Section 
Figure Caption etc, but maybe you know this already?

It's probably less work if you store the Counter as then you need update it 
only when another Counter of the same type is inserted.

And, voilà! You have a CounterInset!

So you could loop over all insets
Buffer::inset_iterator it  = buffer.inset_const_iterator_begin();
Buffer::inset_iterator end = buffer.inset_const_iterator_end();

for (; it != end; ++it) {
if ((*it)-Code() != COUNTER_CODE)
continue;

Counter * counter = static_castInsetCounter *(*it);
// Set its value
...
}

Just thoughts.

Regards,
Angus

Qt vs. Xforms dialogs; lots of differences

[Rob Lahaye]

Hi,

I'm quite suprised how much the Qt dialogs differ from the Xform ones. I don't mean
the way they look, but their contents. Some Qt dialogs have a totally different
layout and arrangement of items.

This should be avoided. Explaining how to use LyX will be unnecessarily complicated:
if you use Xforms, do blablabla, however, in Qt you should do.

This UI layout definitely needs to be equalized eventually!

Rob.

Qt vs. Xforms dialogs; lots of differences

[Rob Lahaye]

Hi,

I'm quite suprised how much the Qt dialogs differ from the Xform ones. I don't mean
the way they look, but their contents. Some Qt dialogs have a totally different
layout and arrangement of items.

This should be avoided. Explaining how to use LyX will be unnecessarily complicated:
if you use Xforms, do blablabla, however, in Qt you should do.

This UI layout definitely needs to be equalized eventually!

Rob.

Re: Qt vs. Xforms dialogs; lots of differences

[John Levon]

On Sat, Aug 10, 2002 at 09:22:06AM +0900, Rob Lahaye wrote:

 This should be avoided. Explaining how to use LyX will be unnecessarily 
 complicated:
 if you use Xforms, do blablabla, however, in Qt you should do.
 
 This UI layout definitely needs to be equalized eventually!

This is up to the xforms people to do. Qt makes several things a LOT
easier to do. If you spot usability problems with the Qt dialogs,
please report them.

regards
john

-- 
It is unbecoming for young men to utter maxims.
- Aristotle

Re: Qt vs. Xforms dialogs; lots of differences

[Michael Koziarski]

On Sat, Aug 10, 2002 at 09:22:06AM +0900 or thereabouts, Rob Lahaye wrote:
 
 Hi,
 
 I'm quite suprised how much the Qt dialogs differ from the Xform
 ones. I don't mean the way they look, but their contents. Some Qt
 dialogs have a totally different layout and arrangement of items.
 
 This should be avoided. Explaining how to use LyX will be
 unnecessarily complicated: 
 
 if you use Xforms, do blablabla, however, in Qt you should do.
 
 This UI layout definitely needs to be equalized eventually!

I'm with john on this.  There's definitely a problem with respect to
documentation however some differences will be required.  To fit in
with the look and feel of the desktop, the required UI guidelines etc.

On the whole they will be similar, but they'll never be merely 'the
same with different buttons'.  Also I think the differences will lead
to a UI review (something LyX hasn't had so far) with the best
features of each frontend going into the others.

-- 

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

Re: [PATCH] graphics

[Herbert Voss]

John Levon wrote:

> On Thu, Aug 08, 2002 at 09:34:16AM +0100, Angus Leeming wrote:
> 
> 
>>I meant the comments in the mail. I haven't got the patch. Since you started 
>>this thread, I guess you have it, so apply it.
>>
> 
> well I was after making sure it's reviewed ... I don't have it any more
> than you do


that is what I called "the nice committing policy of LyX" ...

Herbert




-- 
http://www.lyx.org/help/

Qt frontend trouble on FreeBSD /w qt3.

[R. Lahaye]

Hi,

I'm using the "2.53" and "1.5" autotools.

The qt3 package (from qt-x11-free-3.0.5.tar.bz2) on my FreeBSD PC, requires
following:
  includes-dir: /usr/X11R6/include
  libraries-dir: /usr/X11R6/lib
  linking: -lqui (linking with /usr/X11R6/lib/libqui.so)

The -lqui is tricky because I don't know how to modify the configure scripts in
order to correctly
pick up this library. As a temporary solution, I created a link to
/usr/X11R6/libqui.so by
/usr/X11R6/libqt.so and /usr/X11R6/libqt.so.3.

I then tried "setenv QTDIR /usr/X11R6" before running configure, but that didn't
work:
  checking for Qt... configure: error: Qt2 (libraries) not found. Please check
your installation!
Why is QTDIR/lib and QTDIR/include not found?
So I ran configure with "--with-qt-includes=/usr/X11R6/include
--with-qt-libraries=/usr/X11R6/lib",
which eventually makes the configure reach to the end safely.

A "make" in my case fails as soon as it reaches into src/frontends/qt2/ui
directory.
Gmake does a much better job, but I get stuck at
src/frontends/qt2/Toolbar_pimpl.C:
  Toolbar_pimpl.C: In function `class QPixmap {anonymous}::getIconPixmap(int)':
  Toolbar_pimpl.C:45: `tie' undeclared in namespace `boost'
When this file includes the line
  #include 
the problem is solved, and compilation continues almost until the very end:

  [...]
  g++ -g -O -Wno-non-template-friend -W -Wall -o lyx BufferView.o BufferView2.o
BufferView_pimpl.o Bullet.o Chktex.o CutAndPaste.o DepTable.o FloatList.o
Floating.o FuncStatus.o LColor.o LaTeX.o LaTeXFeatures.o LyXAction.o
MenuBackend.o ParagraphParameters.o Spacing.o TextCache.o Thesaurus.o
ToolbarDefaults.o box.o buffer.o bufferlist.o bufferparams.o bufferview_funcs.o
chset.o converter.o counters.o debug.o encoding.o exporter.o gettext.o
importer.o intl.o iterators.o kbmap.o kbsequence.o language.o lastfiles.o
lengthcommon.o lyx_cb.o lyx_main.o lyx_sty.o lyxcursor.o lyxfont.o lyxfind.o
lyxfunc.o lyxgluelength.o lyxlayout.o lyxlength.o lyxlex.o lyxlex_pimpl.o
lyxrc.o lyxrow.o lyxserver.o lyxtextclass.o lyxtextclasslist.o lyxvc.o main.o
paragraph.o paragraph_pimpl.o ispell.o pspell.o tabular.o tabular-old.o
tabular_funcs.o tex-accent.o tex-strings.o texrow.o text.o text2.o toc.o trans.o
trans_mgr.o undo.o undo_funcs.o vc-backend.o version.o vspace.o 
mathed/.libs/libmathed.a  insets/.libs/libinsets.a
frontends/.libs/libfrontends.a -lqt graphics/.libs/libgraphics.a
support/.libs/libsupport.a ../boost/libs/regex/src/.libs/libboostregex.a
../boost/libs/signals/src/.libs/libboostsignals.a ../intl/libintl.a -lXpm -lSM
-lICE -lc -lm -L/usr/X11R6/lib -lX11
  /usr/X11R6/lib/libqt-mt.so.3: undefined reference to `pthread_attr_destroy'
  /usr/X11R6/lib/libqt-mt.so.3: undefined reference to `pthread_create'
  /usr/X11R6/lib/libqt-mt.so.3: undefined reference to `pthread_attr_init'
  /usr/X11R6/lib/libqt-mt.so.3: undefined reference to `pthread_exit'
  /usr/X11R6/lib/libqt-mt.so.3: undefined reference to
`pthread_mutexattr_destroy'
  /usr/X11R6/lib/libqt-mt.so.3: undefined reference to
`pthread_attr_setinheritsched'
  /usr/X11R6/lib/libqt-mt.so.3: undefined reference to
`pthread_mutexattr_settype'
  /usr/X11R6/lib/libqt-mt.so.3: undefined reference to `pthread_mutexattr_init'
  /usr/X11R6/lib/libqt-mt.so.3: undefined reference to `pthread_mutex_trylock'
  /usr/X11R6/lib/libqt-mt.so.3: undefined reference to
`pthread_attr_setdetachstate'
  /usr/X11R6/lib/libqt-mt.so.3: undefined reference to `pthread_cond_timedwait'
  gmake[3]: *** [lyx] Error 1

This is because -pthread is somewhere missing in the compilation process. This
is a typical FreeBSD issue.
Only on FreeBSD the compiler needs (sometimes?) the -pthread flag. man gcc:

  [...]
  -pthread   Link a user-threaded process against libc_r instead
 of libc. Objects linked into user-threaded processes
 should be compiled with -D_THREAD_SAFE.
  [...]

So I do "setenv CPPFLAGS -pthread" and once again configure/gmake.

OKAY!, but the executable only dumps core:

(gdb) run
Starting program: /home/lahaye/SOFTWARE/lyx-devel/src/lyx 

Program received signal SIGSEGV, Segmentation fault.
0x28704882 in xdr_u_int () from /usr/lib/libc.so.4
(gdb) bt
#0  0x28704882 in xdr_u_int () from /usr/lib/libc.so.4
#1  0x28704fe6 in xdr_bytes () from /usr/lib/libc.so.4
#2  0x287050b8 in xdr_netobj () from /usr/lib/libc.so.4
#3  0x2871b49a in .cerror () from /usr/lib/libc.so.4
#4  0x285cec39 in _X11TransSocketINETConnect () from /usr/X11R6/lib/libX11.so.6
#5  0x285cfd51 in _X11TransConnect () from /usr/X11R6/lib/libX11.so.6
#6  0x28598e66 in _X11TransConnectDisplay () from /usr/X11R6/lib/libX11.so.6
#7  0x285a7e9d in XOpenDisplay () from /usr/X11R6/lib/libX11.so.6
#8  0x2894e415 in qt_init_internal () from /usr/X11R6/lib/libqt-mt.so.3
#9  0x2894f534 in qt_init () from /usr/X11R6/lib/libqt-mt.so.3
#10 0x2899d383 in QApplication::construct () from /usr/X11R6/lib/libqt-mt.so.3
#11 0x2899d1ac in QApplication::QApplication () from
/usr/X11R6/lib/libqt-mt.so.3
#12 

[Paolo.Saggese@libero.it] Feedback from www.lyx.org

[Lars Gullik Bjønnes]

I forwarded your message to the lyx mailinglist, to possibly get some
wider attention and discussion.


--- Begin Message ---


Paolo Saggese ([EMAIL PROTECTED]) entered the 
following feedback message on the LyX home page:


Hi.

Congratulations for the job done. LyX is really a great piece of software. Here (see: 
http://borex.lngs.infn.it ) we are using it extensively to write scientific articles, 
reports, etc.

We have a problem, though. We have several collaborators from Russia who needs to 
write documents is Russian language (Cyrillic chars), usually mixed with some english 
text, math formulas, etc.

Problem is, it looks like it is really hard to properly set up  Russian (Cyrillic) 
keyboard map in LyX and, even worse, we have not been able to find any easy way to 
switch back and forth from english to russian when writing mixed language documents 
(almost all are such). 

Oddly enough, with some older versions of LyX we had found a way (although not 
perfect) to to that somehow,  while with the latest versions it seems to be just 
impossible! :-(

Why could not LyX just use the system's keyboard maps and encodings? 

In KDE, Gnome and even plain X with whatever wm on it there are several confortable 
utilities to simply switch keyboard maps back and forth on the fly to and from 
(almost) any language with just a mouse click or some hotkey combination.
Most applications works that way without any problem. If LyX could simply do the same, 
it would be great!

Instead, unfortunately, switching the keyboard layout that way  simply makes LyX input 
the wrong characters or none at all. :-(

What is the current situation and the plans for the near future?

Thanks for your attention.

Ciao e grazie,
Paolo.

--
http://borex.lngs.infn.it/saggese
You can still escape from the GATES of hell: Use Linux!


--- End Message ---



-- 
Lgb

Re: Support for LyX in design recovery tool?

[Angus Leeming]

On Friday 09 August 2002 6:32 am, Amir Michail wrote:

> Also, I tried changing the cursor color using the dialog in the GUI. 
> (Again, a unique cursor color makes it easier to track the cursor from
> screenshots.) For some reason, the cursor color changes were always ignored
> (lyx 1.2). The color sliders also had some problems.  For example, I
> couldn't pick 254 for red; it only gave me 253 or 255.  Perhaps there is a
> way to explicitly specify RGB values from the startup file?

Try saving the change you've made and then edit the resultant preferences 
file (~/.lyx/preferences) by hand.

Angus

Re: nasty eqns lead to crash

[Kornel Benko]

-BEGIN PGP SIGNED MESSAGE-

On Thursday 08 August 2002 15:06, Andre Poenitz wrote:
> On Thu, Aug 08, 2002 at 01:26:32PM +0100, Angus Leeming wrote:
> > Kornel Benko sent me this file because we thought that the crash was
> > caused by the previewing. However, I can't load it at all with current,
> > with or without previews enabled.
>
> It loads here. I only problem seems to be underscores in labels (again).
> I'll have a look at that.
>
> Andre'

It loads here now, after making some scripts executable.
(Yes, I am using the non-installed version from the src-directory.
 I have seen the mails, which pointed out this problem, but I didn't pay
enough attention to it. Sorry)

Kornel
- -- 
Kornel Benko
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: PGP 6.5.8

iQCVAwUBPVOLGLewfbDGmeqhAQHeWwQA4FX+UPz71j+g2bQpDOsoKxolik4+CzKZ
vaRZXusIYrmB5t1VSvcJAd8bHPCVngpKe0zMlv3tjDSmUP7HxHcoLkS7BPu/yJr7
cepkEHZi6wtscCHCNelw6pdkVIE0a42Bt9iLWoGn2oS5Eibb5IOdVzuz0FO3runM
WTJTr0+fHu4=
=US00
-END PGP SIGNATURE-

Re: nasty eqns lead to crash

[Martin Vermeer]

On Thu, Aug 08, 2002 at 07:15:23PM +0100, John Levon wrote:
> 
> On Thu, Aug 08, 2002 at 01:26:32PM +0100, Angus Leeming wrote:
> 
> > Kornel Benko sent me this file because we thought that the crash was caused 
> > by the previewing. However, I can't load it at all with current, with or 
> > without previews enabled. Since it is chock full of equations and little 
> > else, I thought André might like a look ;-)
 
...
 
> ==9208==
> ==9208== Conditional jump or move depends on uninitialised value(s)
> ==9208==at 0x80C94FD: ??? (/usr/include/g++-3/std/bastring.cc:249)
> ==9208==by 0x80C907B: ??? (/usr/include/g++-3/std/bastring.h:352)
> ==9208==by 0x80C7A00: Counters::reset(basic_stringstring_char_traits, __default_alloc_template > const &) 
>(counters.C:206)
> ==9208==by 0x81387FB: LyXText::setCounter(Buffer const *, Paragraph *) const 
>(text2.C:1235)
> ==9208==
> ==9208== Conditional jump or move depends on uninitialised value(s)
> ==9208==at 0x80C94FD: ??? (/usr/include/g++-3/std/bastring.cc:249)
> ==9208==by 0x80C907B: ??? (/usr/include/g++-3/std/bastring.h:352)
> ==9208==by 0x80C7AD0: Counters::copy(Counters &, Counters &, basic_stringstring_char_traits, __default_alloc_template >
> const &) (counters.C:216)
> ==9208==by 0x81386A2: LyXText::setCounter(Buffer const *, Paragraph *) const 
>(text2.C:1225)
> 
> Andre ? Martin ?

Seems correct to me. The first dozen lines or so in LyXText::setCounter are: 
if a par has no previous(), it resets its counter array, otherwise it
copies the one of its predecessor. Should cover all cases.

Inside Counters::reset and copy, I don't see it either. What should be 
undefined? match, if it is the empty string? To my eyes, it looks OK.
Or is perhaps .find() not supposed to have an empty arg?

Martin
-- 
Martin Vermeer  [EMAIL PROTECTED]
Helsinki University of Technology 
Department of Surveying
P.O. Box 1200, FIN-02015 HUT, Finland
:wq



msg42278/pgp0.pgp
Description: PGP signature

Re: nasty eqns lead to crash

[Angus Leeming]

On Friday 09 August 2002 10:39 am, Martin Vermeer wrote:
> On Thu, Aug 08, 2002 at 07:15:23PM +0100, John Levon wrote:
> > On Thu, Aug 08, 2002 at 01:26:32PM +0100, Angus Leeming wrote:
> > > Kornel Benko sent me this file because we thought that the crash was
> > > caused by the previewing. However, I can't load it at all with current,
> > > with or without previews enabled. Since it is chock full of equations
> > > and little else, I thought André might like a look ;-)
>
> ...
>
> > ==9208==
> > ==9208== Conditional jump or move depends on uninitialised value(s)
> > ==9208==at 0x80C94FD: ??? (/usr/include/g++-3/std/bastring.cc:249)
> > ==9208==by 0x80C907B: ??? (/usr/include/g++-3/std/bastring.h:352)
> > ==9208==by 0x80C7A00: Counters::reset(basic_string > string_char_traits, __default_alloc_template > const &)
> > (counters.C:206) ==9208==by 0x81387FB: LyXText::setCounter(Buffer
> > const *, Paragraph *) const (text2.C:1235) ==9208==
> > ==9208== Conditional jump or move depends on uninitialised value(s)
> > ==9208==at 0x80C94FD: ??? (/usr/include/g++-3/std/bastring.cc:249)
> > ==9208==by 0x80C907B: ??? (/usr/include/g++-3/std/bastring.h:352)
> > ==9208==by 0x80C7AD0: Counters::copy(Counters &, Counters &,
> > basic_string > __default_alloc_template > const &) (counters.C:216)
> > ==9208==by 0x81386A2: LyXText::setCounter(Buffer const *, Paragraph
> > *) const (text2.C:1225)
> >
> > Andre ? Martin ?
>
> Seems correct to me. The first dozen lines or so in LyXText::setCounter
> are: if a par has no previous(), it resets its counter array, otherwise it
> copies the one of its predecessor. Should cover all cases.
>
> Inside Counters::reset and copy, I don't see it either. What should be
> undefined? match, if it is the empty string? To my eyes, it looks OK.
> Or is perhaps .find() not supposed to have an empty arg?

It doesn't, it has a string argument that just happens to be empty. That's 
fine and string::find will return string::npos (for which you already test).

That is assuming that you haven't populated your map with an empty string() 
as an index...

Incidentally, why not:

void Counters::reset(string const & match)
{
CounterList::iterator it = counterList.begin();
CounterList::iterator end = counterList.end();
if (match.empty()) {
for (; it != end; ++it) {
it->second.reset();
}
} else {
for (; it != end; ++it) {
if (it->first.find(match) != string::npos)
it->second.reset();
}
}
}

And whether you choose to use two loops or one, that should be match.empty(), 
not match == "". 

If you choose to remain with a single loop then you should also move the 
match.empty() test to the front of the if statement as it's quicker than 
find... (I believe that they're executed in order).

Angus

Re: nasty eqns lead to crash

[Angus Leeming]

On Friday 09 August 2002 10:37 am, Angus Leeming wrote:

> Incidentally, why not:
>
> void Counters::reset(string const & match)
> {
>   CounterList::iterator it = counterList.begin();
>   CounterList::iterator end = counterList.end();
>   if (match.empty()) {
>   for (; it != end; ++it) {
>   it->second.reset();
>   }
>   } else {
>   for (; it != end; ++it) {
>   if (it->first.find(match) != string::npos)
>   it->second.reset();
>   }
>   }
> }

Actually, shouldn't that be:

void Counters::reset(string const & match)
{
if (match.empty()) {
CounterList::iterator it = counterList.begin();
CounterList::iterator end = counterList.end();
for (; it != end; ++it) {
it->second.reset();
}
} else {
CounterList::iterator it = counterList.find(match);
if (it != counterList.end())
it->second.reset();
}
}

?

Angus

Re: nasty eqns lead to crash

[Andre Poenitz]

On Fri, Aug 09, 2002 at 10:37:10AM +0100, Angus Leeming wrote:
> (I believe that they're executed in order).

They have to.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: nasty eqns lead to crash

[Lars Gullik Bjønnes]

Angus Leeming <[EMAIL PROTECTED]> writes:

| On Friday 09 August 2002 10:37 am, Angus Leeming wrote:
>
>> Incidentally, why not:
>>
>> void Counters::reset(string const & match)
>> {
>>  CounterList::iterator it = counterList.begin();
>>  CounterList::iterator end = counterList.end();
>>  if (match.empty()) {
>>  for (; it != end; ++it) {
>>  it->second.reset();
>>  }
>>  } else {
>>  for (; it != end; ++it) {
>>  if (it->first.find(match) != string::npos)
>>  it->second.reset();
>>  }
>>  }
>> }
>
| Actually, shouldn't that be:
>
| void Counters::reset(string const & match)
| {
|   if (match.empty()) {
|   CounterList::iterator it = counterList.begin();
|   CounterList::iterator end = counterList.end();
|   for (; it != end; ++it) {
|   it->second.reset();
|   }
|   } else {
|   CounterList::iterator it = counterList.find(match);

Only if:
 - exact match is wanted.
 - only one element in counterList can match.

|   if (it != counterList.end())
|   it->second.reset();
|   }
| }
>
| ?
>
| Angus
>

-- 
Lgb

Re: nasty eqns lead to crash

[Martin Vermeer]

On Fri, Aug 09, 2002 at 10:37:10AM +0100, Angus Leeming wrote:

...

> > > Andre ? Martin ?
> >
> > Seems correct to me. The first dozen lines or so in LyXText::setCounter
> > are: if a par has no previous(), it resets its counter array, otherwise it
> > copies the one of its predecessor. Should cover all cases.
> >
> > Inside Counters::reset and copy, I don't see it either. What should be
> > undefined? match, if it is the empty string? To my eyes, it looks OK.
> > Or is perhaps .find() not supposed to have an empty arg?
> 
> It doesn't, it has a string argument that just happens to be empty. That's 
> fine and string::find will return string::npos (for which you already test).

Unfortunately it didn't work properly. That's why I added the separate
empty test. (It returned haphazard, random-looking boolean values for

it->first.find(match) != string::npos

in case match was empty. That's gcc-2.95.2 on intel-linux.)
 
> That is assuming that you haven't populated your map with an empty string() 
> as an index...

Have I? :-)
 
...

> And whether you choose to use two loops or one, that should be match.empty(), 
> not match == "". 

Be my guest.
 
> If you choose to remain with a single loop then you should also move the 
> match.empty() test to the front of the if statement as it's quicker than 
> find... (I believe that they're executed in order).

Yes, I agree.
 
> Angus
> 

Martin




msg42284/pgp0.pgp
Description: PGP signature

Re: nasty eqns lead to crash

[Angus Leeming]

Amazing what happens if you dig deeper

aleem@pneumon:src-> grep "counters()" *.C */*.C | grep copy
text2.C:par->counters().copy(par->previous()->counters(), 
par->counters(), "");
aleem@pneumon:src-> grep "counters()" *.C */*.C | grep reset
text2.C:par->counters().reset("");
text2.C:par->counters().reset("");
text2.C:par->counters().reset("enum");
text2.C:par->counters().reset("enum");

So, Counters::copy() is used only as 
Counters::copy(Counters & from, Counters & to);

and can therefore be simplified to

void Counters::copy(Counters & from, Counters & to)
{
CounterList::iterator it = counterList.begin();
CounterList::iterator end = counterList.end();
for (; it != end; ++it) {
to.set(it->first, from.value(it->first));
} 
}


whilst Counters::reset should be written as

void Counters::reset(string const & match)
{
CounterList::iterator it = counterList.begin();
CounterList::iterator end = counterList.end();
if (match.empty()) {
for (; it != end; ++it) {
it->second.reset();
}
} else {
// reset all counters whose index contains match as a
// sub-string
for (; it != end; ++it) {
if (it->first.find(match) != string::npos)
it->second.reset();
}
}
}

Angus

Re: nasty eqns lead to crash

[Lars Gullik Bjønnes]

Angus Leeming <[EMAIL PROTECTED]> writes:

| Amazing what happens if you dig deeper
>
| aleem@pneumon:src-> grep "counters()" *.C */*.C | grep copy
| text2.C:par->counters().copy(par->previous()->counters(), 
| par->counters(), "");
| aleem@pneumon:src-> grep "counters()" *.C */*.C | grep reset
| text2.C:par->counters().reset("");
| text2.C:par->counters().reset("");
| text2.C:par->counters().reset("enum");
| text2.C:par->counters().reset("enum");
>
| So, Counters::copy() is used only as 
|   Counters::copy(Counters & from, Counters & to);
>
| and can therefore be simplified to
>
| void Counters::copy(Counters & from, Counters & to)
| {
|   CounterList::iterator it = counterList.begin();
|   CounterList::iterator end = counterList.end();
|   for (; it != end; ++it) {
|   to.set(it->first, from.value(it->first));
|   } 
| }
>
>
| whilst Counters::reset should be written as
>
| void Counters::reset(string const & match)
| {
|   CounterList::iterator it = counterList.begin();
|   CounterList::iterator end = counterList.end();
|   if (match.empty()) {
|   for (; it != end; ++it) {
|   it->second.reset();
|   }
|   } else {
|   // reset all counters whose index contains match as a
|   // sub-string
|   for (; it != end; ++it) {
|   if (it->first.find(match) != string::npos)
|   it->second.reset();
|   }
|   }
| }

Hmm I wonder if this reset function shouldn't be split into two
functions...


void Counters::reset()
{
CounterList::iterator it = counterList.begin();
CounterList::iterator end = counterList.end();
for (; it != end; ++it) {
it->second.reset();
}
}

Which could be simplified...

something similar to:

void Counters::reset()
{
std::for_each(counterList.begin(), counterList.end(),
  std::memfun(::reset));
}


and

void Counters::reset(string const & match)
{
assert(!match.empty());

CounterList::iterator it = counterList.begin();
CounterList::iterator end = counterList.end();
for (; it != end; ++it) {
if (it->first.find(match) != string::npos)
it->second.reset();
}
}


Functions that do only one thing and that does not decide what to do
based on the value of arguments are a good thing.

-- 
Lgb

Re: nasty eqns lead to crash

[Andre Poenitz]

On Fri, Aug 09, 2002 at 11:36:13AM +0100, Angus Leeming wrote:
> and can therefore be simplified to
> 
> void Counters::copy(Counters & from, Counters & to)
> {
>   CounterList::iterator it = counterList.begin();
>   CounterList::iterator end = counterList.end();
>   for (; it != end; ++it) {
>   to.set(it->first, from.value(it->first));
>   } 
> }

Does this change 'from'?


Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: nasty eqns lead to crash

[Angus Leeming]

On Friday 09 August 2002 12:23 pm, Andre Poenitz wrote:
> On Fri, Aug 09, 2002 at 11:36:13AM +0100, Angus Leeming wrote:
> > and can therefore be simplified to
> >
> > void Counters::copy(Counters & from, Counters & to)
> > {
> > CounterList::iterator it = counterList.begin();
> > CounterList::iterator end = counterList.end();
> > for (; it != end; ++it) {
> > to.set(it->first, from.value(it->first));
> > }
> > }
>
> Does this change 'from'?

int Counters::value(string const & ctr) const
{
CounterList::const_iterator cit = counterList.find(ctr);
if (cit == counterList.end()) {
lyxerr << "value: Counter does not exist: " << ctr << endl;
return 0;
}
return cit->second.value();
}

No.

Re: nasty eqns lead to crash

[Angus Leeming]

On Friday 09 August 2002 11:59 am, Angus Leeming wrote:
> On Friday 09 August 2002 12:23 pm, Andre Poenitz wrote:
> > On Fri, Aug 09, 2002 at 11:36:13AM +0100, Angus Leeming wrote:
> > > and can therefore be simplified to
> > >
> > > void Counters::copy(Counters & from, Counters & to)
> > > {
> > >   CounterList::iterator it = counterList.begin();
> > >   CounterList::iterator end = counterList.end();
> > >   for (; it != end; ++it) {
> > >   to.set(it->first, from.value(it->first));
> > >   }
> > > }
> >
> > Does this change 'from'?
>
> int Counters::value(string const & ctr) const
> {
>   CounterList::const_iterator cit = counterList.find(ctr);
>   if (cit == counterList.end()) {
>   lyxerr << "value: Counter does not exist: " << ctr << endl;
>   return 0;
>   }
>   return cit->second.value();
> }
>
> No.

But you are right to notice that the semantics of this method are very 
confusing.

1. It's a member of Counters, but does not set *this.

Is this what is meant:
void Counters::copy(Counters const & from)
{
CounterList::iterator it = counterList.begin();
CounterList::iterator end = counterList.end();
for (; it != end; ++it) {
it->set(from.value(it->first));
}
}

?

2. Alternatively, it could be a non-member function

void Counters::copy(Counters const & from, Counters & to)
{
CounterList::iterator it = to.counterList.begin();
CounterList::iterator end = to.counterList.end();
for (; it != end; ++it) {
it->set(from.value(it->first));
}
}

As it is, I have no idea what it is meant to be doing, but it ain't doing it!

Angus


But is Counters::copy doing what it's meant to be doing?

Why is it a member variable that resets to

Re: nasty eqns lead to crash

[Angus Leeming]

On Friday 09 August 2002 12:14 pm, Angus Leeming wrote:
> 2. Alternatively, it could be a non-member function
>
> void Counters::copy(Counters const & from, Counters & to)

That's 
void copy(Counters const & from, Counters & to)

Re: Qt frontend trouble on FreeBSD /w qt3.

[Rob Lahaye]

R. Lahaye wrote:
 >
>   /usr/X11R6/lib/libqt-mt.so.3: undefined reference to `pthread_cond_timedwait'
>   gmake[3]: *** [lyx] Error 1
> 
> This is because -pthread is somewhere missing in the compilation process. This
> is a typical FreeBSD issue.
> Only on FreeBSD the compiler needs (sometimes?) the -pthread flag. man gcc:
> 
>   [...]
>   -pthread   Link a user-threaded process against libc_r instead
>  of libc. Objects linked into user-threaded processes
>  should be compiled with -D_THREAD_SAFE.
>   [...]

In the configure script, I have to replace all "-lc" by "-lc_r".
BTW config/gnome.m4 and config/ltmain.sh do already something is this direction,
but this is obviously not enough! ltmain.sh says somewhere:
 *-*-openbsd*)
 # Do not include libc due to us having libc/libc_r.
 [...]


In addition I have to set the following environment variables, before running 
configure:

CFLAGS=-D_THREAD_SAFE -pthread
CPPFLAGS=-D_THREAD_SAFE -pthread
CXXFLAGS=-D_THREAD_SAFE -pthread


Then everything is fine.

HOORAY: LyX runs wonderfully with Qt3 on my FreeBSD box!!! Nice, nice, nice!


Apparently, if LyX must work "out-of-the-box" with Qt, then (Free)BSD requires
some more tweeking of the scripts.

Regards,
Rob.

LFUNs for mouse events

[Andre Poenitz]

Has anybody any opinion on that topic?

I'd use such thing for interanal use in mathed but it looks as the "real"
inset could use them, too.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: nasty eqns lead to crash

[John Levon]

On Fri, Aug 09, 2002 at 11:27:52AM +0200, Kornel Benko wrote:

> It loads here now, after making some scripts executable.
> (Yes, I am using the non-installed version from the src-directory.

anyone remember how we get them +x in the repository ? Do we have to
re-add them or is there a cvs thingy ?

regards
john

-- 
"It is unbecoming for young men to utter maxims."
- Aristotle

Re: [PATCH] graphics

[John Levon]

On Fri, Aug 09, 2002 at 08:30:09AM +0200, Herbert Voss wrote:

> that is what I called "the nice committing policy of LyX" ...

I don't like to apply patches that I don't understand of code I don't
know, that's all ... no need to get het up about it.

The stuff gets in eventually doesn't it ?

regards
john
-- 
"It is unbecoming for young men to utter maxims."
- Aristotle

Re: nasty eqns lead to crash

[Angus Leeming]

On Friday 09 August 2002 1:18 pm, John Levon wrote:
> On Fri, Aug 09, 2002 at 11:27:52AM +0200, Kornel Benko wrote:
> > It loads here now, after making some scripts executable.
> > (Yes, I am using the non-installed version from the src-directory.
>
> anyone remember how we get them +x in the repository ? Do we have to
> re-add them or is there a cvs thingy ?

either way, LyX shouldn't crash...

Re: Qt frontend trouble on FreeBSD /w qt3.

[John Levon]

On Fri, Aug 09, 2002 at 05:05:25PM +0900, R. Lahaye wrote:

>   linking: -lqui (linking with /usr/X11R6/lib/libqui.so)

Oh sweet. Really nice. What is it with FreeBSD and stupid renamings of
libraries ? Don't they realise how painful qt2.m4 is ?

>   checking for Qt... configure: error: Qt2 (libraries) not found. Please check
> your installation!
> Why is QTDIR/lib and QTDIR/include not found?

You will have to look into config.log to tell me that.

>   Toolbar_pimpl.C:45: `tie' undeclared in namespace `boost'

OK will fix.

>   /usr/X11R6/lib/libqt-mt.so.3: undefined reference to `pthread_attr_destroy'

You can't use qt-mt. Why is it picking this version up ?

regards
john

-- 
"It is unbecoming for young men to utter maxims."
- Aristotle

Re: LFUNs for mouse events

[John Levon]

On Fri, Aug 09, 2002 at 02:17:16PM +0200, Andre Poenitz wrote:

> Has anybody any opinion on that topic?
> 
> I'd use such thing for interanal use in mathed but it looks as the "real"
> inset could use them, too.

Please. We have :

insetButtonPress
insetButtonRelease
edit() (1)
edit() (2)

and the interactions between them is thoroughly baffling. Feel free to
sort all this out.

regards
john

-- 
"It is unbecoming for young men to utter maxims."
- Aristotle

Re: nasty eqns lead to crash

[Lars Gullik Bjønnes]

Angus Leeming <[EMAIL PROTECTED]> writes:

| On Friday 09 August 2002 12:14 pm, Angus Leeming wrote:
>> 2. Alternatively, it could be a non-member function
>>
>> void Counters::copy(Counters const & from, Counters & to)
>
| That's 
| void copy(Counters const & from, Counters & to)

How is this then different from a member function

void operator=(Counters const & from) ??

-- 
Lgb