Re: de.po

[Juergen Spitzmueller]

Andre Poenitz wrote:
  Caption - Legende (not Überschrift)

 Legende would confuse me...

But Überschrift is definitly wrong. First, it is not always above the 
picture (the contrary is true). Second, I think on header when I read 
Überschrift, and third, the typographic term is Legende. 
Bildunterschrift is the only alternative I can think of, but what is with 
tabulars?

(In general I'm rather reluctant on the idea of translating the LaTeX terms)

Jürgen.

Re: de.po

[Moritz Moeller-Herrmann]

Juergen Spitzmueller wrote:

 Andre Poenitz wrote:
  Caption - Legende (not Überschrift)

 Legende would confuse me...
 
 But Überschrift is definitly wrong. First, it is not always above the
 picture (the contrary is true). Second, I think on header when I read
 Überschrift, and third, the typographic term is Legende.
 Bildunterschrift is the only alternative I can think of, but what is
 with tabulars?

I think »Bezeichnung« would be a good term. Unterschrift suggests, that it 
has to be placed below the table or image.

-- 
Moritz Moeller-Herrmann [EMAIL PROTECTED] wiss. Mitarbeiter, IMGB
La loi, dans un grand souci d'égalité, interdit aux riches comme aux
pauvres de coucher sous les ponts, de mendier dans les rues et de voler
du pain. 
(ANATOLE FRANCE)
 

Re: de.po

[Andre Poenitz]

On Wed, Feb 19, 2003 at 09:07:44AM +0100, Juergen Spitzmueller wrote:
 But Überschrift is definitly wrong. First, it is not always above the 
 picture (the contrary is true). Second, I think on header when I read 
 Überschrift, and third, the typographic term is Legende. 
 Bildunterschrift is the only alternative I can think of, but what is with 
 tabulars?

Beschreibung/Beschriftung?

I'd even accept Bildunterschrift for tabulars, even if it is formally not
correct, whereas Legende might be formally correct but pretty unusual.

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: de.po

[Juergen Spitzmueller]

Andre Poenitz wrote:
 Beschreibung/Beschriftung?

Beschriftung is not bad actually. But I let Michael decide.

Jürgen.

www/cvs down?

[Andre Poenitz]

Can't connect. The machine seems to be running, though.

Andre'

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

Graphics Loader

[Alfredo Braunstein]

I'm fiddling a little with the graphics loader, and I started to implement a
pseudo threaded version of it (patch attached).

It works as follows: there is this LoaderQueue class (I think every
BufferView should have one, right now is simply a global class), which
implements a queue with a twist:

1) Elements are unique
2) Reinserting an element reprioritizes it to the top

I.e. it sort of works like the 'touch' command.

Right now it's implemented as a queue + a set, so it's O(ln n) for the
'first time insert' case, and O(n) for the 'already have it' case.
I plan to make it O(ln n) always.

His loadNext method should run in an independent thread, right now it runs
with a timer that comes back every .1 seconds. I've put a minimal locking
mecanism. Should be trivial to convert to a real thread once boost.threads
is installed on the LyX tree.

This LoaderQueue is called from Loader::startLoading, i.e. from there we
'touch' the graphic. Nothing is really loaded on screen yet. The real
loading is done on the loadNext method (the 'threaded' one).

It works pretty nicely I think (except for the O(n) thingie and some other
details). And the patch is very minimal.

I know that the coding style is broken, please correct me without mercy.
Anyway of course it's not to be applied, It's only a proof of concept.

I have some questions about when these Loadings are called, so if someone
thinks that this is not a complete trash then I go on and ask them.

Please be nice.

Regards, Alfredo

? patch.diff
Index: GraphicsLoader.C
===
RCS file: /cvs/lyx/lyx-devel/src/graphics/GraphicsLoader.C,v
retrieving revision 1.12
diff -u -r1.12 GraphicsLoader.C
--- GraphicsLoader.C	2003/02/13 16:53:00	1.12
+++ GraphicsLoader.C	2003/02/19 08:11:58
@@ -28,9 +28,60 @@
 #include boost/signals/trackable.hpp
 
 #include list
+#include set
 
 namespace grfx {
 
+class LoaderQueue {
+public:
+	LoaderQueue():timer( 100 , Timeout::ONETIME )
+	{
+		timer.timeout.connect( boost::bind( LoaderQueue::loadNext, this));
+		locked = false;
+		timer.start();
+	}
+	void touch(Cache::ItemPtr item) {
+
+		if(locked)
+			return;
+
+		locked = true;
+
+		if( !cache_set_.insert(item).second ) {
+
+			listCache::ItemPtr::iterator 
+it = cache_queue_.begin();
+			listCache::ItemPtr::iterator 
+end = cache_queue_.end();
+
+			it = std::find( it, end, item );
+			cache_queue_.erase( it );
+		} 
+		cache_queue_.push_front( item );
+		locked = false;
+	}
+private:
+	bool locked;
+	std::listCache::ItemPtr cache_queue_;
+	std::setCache::ItemPtr cache_set_;
+	Timeout timer;
+	void loadNext() {
+		if(locked)
+			return;
+		locked = true;
+		int counter = 10;
+		while (cache_queue_.size()  --counter) {
+			cout  cache_queue_.size()
+			   items in the queue  endl; 
+			cache_queue_.front()-startLoading();
+			cache_set_.erase(cache_queue_.front());
+			cache_queue_.pop_front();
+		}
+		locked = false;
+		timer.start();
+	};
+} LQ;
+
 struct Loader::Impl : boost::signals::trackable {
 	///
 	Impl(Params const );
@@ -66,8 +117,6 @@
 	///
 	Params params_;
 
-	///
-	Timeout timer;
 	// Multiple Insets can share the same image
 	typedef std::listInset const * InsetList;
 	///
@@ -196,10 +245,8 @@
 
 
 Loader::Impl::Impl(Params const  params)
-	: status_(WaitingToLoad), params_(params),
-	  timer(2000, Timeout::ONETIME)
+	: status_(WaitingToLoad), params_(params)
 {
-	timer.timeout.connect(boost::bind(Impl::checkedLoading, this));
 }
 
 
@@ -266,7 +313,6 @@
 	signal_();
 }
 
-
 void Loader::Impl::createPixmap()
 {
 	if (!cached_item_.get() ||
@@ -293,7 +339,7 @@
 
 void Loader::Impl::startLoading(Inset const  inset, BufferView const  bv)
 {
-	if (status_ != WaitingToLoad || timer.running())
+	if (status_ != WaitingToLoad)
 		return;
 
 	InsetList::const_iterator it  = insets.begin();
@@ -302,8 +348,7 @@
 	if (it == end)
 		insets.push_back(inset);
 	view = bv.owner()-view();
-
-	timer.start();
+	LQ.touch(cached_item_);
 }
 
 
Index: GraphicsSupport.C
===
RCS file: /cvs/lyx/lyx-devel/src/graphics/GraphicsSupport.C,v
retrieving revision 1.7
diff -u -r1.7 GraphicsSupport.C
--- GraphicsSupport.C	2003/02/13 16:53:00	1.7
+++ GraphicsSupport.C	2003/02/19 08:11:58
@@ -33,7 +33,7 @@
 	VPList vps;
 	Row const * last_row = 0;
 
-	for (int height = 0; row  height  bv_height; row = row-next()) {
+	for (int height = 0; row  height  2 *bv_height; row = row-next()) {
 		height += row-height();
 
 		if (vps.empty() || vps.back().par != row-par()) {
Index: PreviewImage.C
===
RCS file: /cvs/lyx/lyx-devel/src/graphics/PreviewImage.C,v
retrieving revision 1.11
diff -u -r1.11 PreviewImage.C
--- PreviewImage.C	2003/02/13 16:53:00	1.11
+++ PreviewImage.C	2003/02/19 08:11:58
@@ -33,7 +33,6 @@
 	Image const * image(Inset const , BufferView const );
 	///
 	void statusChanged();
-
 	///
 	PreviewImage 

Re: Graphics Loader

[Andre Poenitz]

On Wed, Feb 19, 2003 at 09:43:09AM +0100, Alfredo Braunstein wrote:
 Right now it's implemented as a queue + a set, so it's O(ln n) for the
 'first time insert' case, and O(n) for the 'already have it' case.
 I plan to make it O(ln n) always.

Good idea, but we do pretty expensive things in othe places, so I don't
think this hurts.

 I know that the coding style is broken, please correct me without mercy.
 [...] Please be nice.

Hm?


+class LoaderQueue {
+public:
+   LoaderQueue():timer( 100 , Timeout::ONETIME )
+   {
+   timer.timeout.connect( boost::bind( LoaderQueue::loadNext, 
this));
+   locked = false;
+   timer.start();
+   }

LoaderQueue() : timer(100, Timeout::ONETIME), locked(false)
{
timer.timeout.connect(boost::bind(LoaderQueue::loadNext, this));
timer.start();
}

+   void touch(Cache::ItemPtr item) {
+
+   if(locked)

if (locked)
  [etc]

+   timer.start();
+   };
+} LQ;

};

LoaderQueue LQ;



@@ -266,7 +313,6 @@
signal_();
 }
 
-
 void Loader::Impl::createPixmap()

Two empty lines are pretty common in LyX sources.


iff -u -r1.11 PreviewImage.C
--- PreviewImage.C  2003/02/13 16:53:00 1.11
+++ PreviewImage.C  2003/02/19 08:11:58
@@ -33,7 +33,6 @@
Image const * image(Inset const , BufferView const );
///
void statusChanged();
-
///
PreviewImage const  parent_;
///

As is separating member functions from member variables or blocks of them.

I have not checked for functionality, I cannot connect to cvs right now,
but it does not look bad.

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: a random thought on UI in general

[Jean-Marc Lasgouttes]

 Christian == Christian Ridderström [EMAIL PROTECTED] writes:

Christian Actually, Document-Layout-Preamble could be replaced by
Christian an external inset, that either connects to lyx and modifies
Christian the document preamble, or by returning latex that is
Christian inserted in the document preamble.

If the problem you are trying to solve is how to have child documents
be typeset like when they are part of the master, it seems that you
are trying to find an overly complicated solution. Rather than add
hooks that nobody will use except for some wicked applications, it
might be better to think about the real problem (i.e. devise a really
useful solution, not just give people enough rope to hang themselves)
:)

JMarc

problems with relyx and wvCleanLatex

[Karsten Heymann]

Hello,

(could someone please tell me how to subscribe. The www.lyx.org seems to
be unreachable (again... -- aren't there any mirrors?) so I don't know how to 
subscribe. Thanks.)

I'm using LyX for some time now (it's really a time saver!). While
preparing to promote LyX at work (university), I came about some
problems with the LaTeX (MS Word) import of (re)LyX (wvCleanLatex). I'll
list them here to find out wether they are well-known
bugs^H^H^H^Hfeatures or wether I should file a bug report. I'm using
wvWare 0.7.4 and reLyX from 1.3.0.

1. what LaTeX code can be used so that reLyX produces the 'quote
glq/grq'   insets? wvWare produces \quotedblbase{} and ''. '' is mapped
to 'quote elq' insets which is quite ok, but ERT:\quotedblbase{} looks
very ugly (and it's quite common in german texts). I've tried \glqq  as
well, but (as far as I can read the reLyX code), there's no way to 
reach 'quote glq/grq'. Am I right?  (and while i'm at that topic: why
does LyX use ,, and '' to export  'quote glq/grq'? \glqq resp.
\grqq would seem the right thing to  me.)

2. Should reLyX ignore 1-cell-multicolumns? wvCleanLatex makes every   
cell of a tabular (I've patched it to produce tabular instead of  
longtable - maybe I did something wrong during that) a multicolumn  
which makes editing annoying (esp. adding frames). Most probably a  
wvWare bug, but could reLyX handle it?

3. reLyX improperly parses $a$$b$ (which is $ab$ but reLyX makes $a\[b$
from it). Of course noone sensible would write that, but it's correct
LaTeX-code (at least LaTeX compiles it without problems) and should
stay that. wvCleanLatex creates such code.

4. reLyX doesn't handle \newpage. Almost never needed in LyX, but maybe reLyX could 
make a LyX-Pagebreak from that.

That's all regarding reLyX (so far). There's certainly a lot more but I'll wait until 
I'm subscribed :) 

I'd be happy to help out with solving these problems (I know a bit perl, quite a bit 
python but unfortunately nearly no c++) but would need some pointers how help would be 
helpfull.

Yours,

Karsten

PS: Has someone built debian (woody) packages with qt-support from 1.3.0?

PPS: My mom wrote her final exam with LyX a year ago. And it looks  great!

Re: problems with relyx and wvCleanLatex

[Andre Poenitz]

On Wed, Feb 19, 2003 at 10:23:55AM +0100, Karsten Heymann wrote:
 (could someone please tell me how to subscribe. The www.lyx.org seems
 to be unreachable (again... -- aren't there any mirrors?) so I don't know
 how to subscribe. Thanks.)

List-Help: mailto:[EMAIL PROTECTED]

 I'm using LyX for some time now (it's really a time saver!). While
 preparing to promote LyX at work (university), I came about some problems
 with the LaTeX (MS Word) import of (re)LyX (wvCleanLatex). I'll list them
 here to find out wether they are well-known bugs^H^H^H^Hfeatures or
 wether I should file a bug report. I'm using wvWare 0.7.4 and reLyX from
 1.3.0.

Send me please an example .tex directly and I'll try to make tex2lyx work
on it.

 3. reLyX improperly parses $a$$b$ (which is $ab$ but reLyX makes $a\[b$
 from it). Of course noone sensible would write that, but it's correct
 LaTeX-code (at least LaTeX compiles it without problems) and should stay
 that. wvCleanLatex creates such code.

This is a known reLyX bug.

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: a random thought on UI in general

[Jean-Marc Lasgouttes]

 Christian == Christian Ridderström [EMAIL PROTECTED] writes:

Christian To conclude, I think that for the medium-level user, it'd
Christian be enough to specify the name of another .lyx-file in a
Christian dialog and choose some pre-defined sets of settings that
Christian he'd like imported.

Or we could chose ourselves what settings should be taken from master
doc, and which ones should not. 

JMarc

Re: Graphics Loader

[Alfredo Braunstein]

Andre Poenitz wrote:

 On Wed, Feb 19, 2003 at 09:43:09AM +0100, Alfredo Braunstein wrote:
 Right now it's implemented as a queue + a set, so it's O(ln n) for the
 'first time insert' case, and O(n) for the 'already have it' case.
 I plan to make it O(ln n) always.
 
 Good idea, but we do pretty expensive things in othe places, so I don't
 think this hurts.

I think it does now, because all graphics all added to the queue at startup
time, so you get a short freeze while they are at it (specially with
previews). Another option would be to make the adding part also threaded.
That's it: on touch() to add it to some tmp queue (without checkin) and
return inmediately, and then on loadNext() load this tmp queue into the
good one before proceding.

 
 I know that the coding style is broken, please correct me without mercy.
 [...] Please be nice.

I known. It's called sado-masochim. Thanks for the corrections.

 I have not checked for functionality, I cannot connect to cvs right now,
 but it does not look bad.
 
 Andre'
 

Thanks, Alfredo

Changing article to report/book, math+\text{} problem

[Karsten Heymann]

Hi,

1. are there plans to support changing chapter-section when changing the 
documentclass from article to report/book or back? It's a bit annoying to change all 
sectionsco when changing from article to report. Wouldn't that be nice?

2. (1.3.0:) when I type in the following in math mode:
  \textSPACEHRIGHT_xy
  then xy is roman too although RIGHT should move out of the \text
  inset. I  have to do
  \textSPACEHRIGHTX_xy
  and delete the X afterwards instead. 

Yours,

Karsten

Update pl.po

[Tomasz Luczak]

Hello

I enclose updated pl.po file

Best Regards

Tomasz

--
   Tomasz Luczak
-| TECHNODAT Sp. z o.o. | +48 32 2382337
 http://212.106.135.195/~tlu | PL 44-100 Gliwice| +48 32 3314484
 http://www.technodat.com.pl | ul. Kosciuszki 1c| +48 602 524713



pl.po.zip
Description: Zip compressed data

Re: Graphics Loader

[Angus Leeming]

Alfredo Braunstein wrote:

 I'm fiddling a little with the graphics loader, and I started to
 implement a pseudo threaded version of it (patch attached).
 
 It works as follows: there is this LoaderQueue class (I think every
 BufferView should have one, right now is simply a global class),
 which implements a queue with a twist:
 
 1) Elements are unique
 2) Reinserting an element reprioritizes it to the top
 
 I.e. it sort of works like the 'touch' command.
 
 Right now it's implemented as a queue + a set, so it's O(ln n) for
 the 'first time insert' case, and O(n) for the 'already have it'
 case. I plan to make it O(ln n) always.
 
 His loadNext method should run in an independent thread, right now
 it runs with a timer that comes back every .1 seconds. I've put a
 minimal locking mecanism. Should be trivial to convert to a real
 thread once boost.threads is installed on the LyX tree.
 
 This LoaderQueue is called from Loader::startLoading, i.e. from
 there we 'touch' the graphic. Nothing is really loaded on screen
 yet. The real loading is done on the loadNext method (the 'threaded'
 one).
 
 It works pretty nicely I think (except for the O(n) thingie and some
 other details). And the patch is very minimal.
 
 I know that the coding style is broken, please correct me without
 mercy. Anyway of course it's not to be applied, It's only a proof of
 concept.
 
 I have some questions about when these Loadings are called, so if
 someone thinks that this is not a complete trash then I go on and
 ask them.

I can answer that. Three classes are interested in graphics. 
insets/insetgraphics.C together with mathed/formula.C and 
insets/insetinclude.C for the previews. These latter two have 
instances of a class PreviewImpl that derives from  
grfx::PreviewedInset. InsetGraphics has an instance of a Cache class.

In all cases the loading of the image is triggered by the Inset's 
draw() method. Eg InsetGraphics::draw has 
   if (cache_-loader.status() == grfx::WaitingToLoad)
cache_-loader.startLoading(*this, *bv);

 Please be nice.

We're always nice ;-) Seriously, this is very clever of you and 
surprisingly non-invasive. Where/who would call loadNext?

Did you find the graphics code understandable or did you find it to 
be a convoluted mess? What could be done to improve the architecture?

I have a question/suggestion for you myself. (Thinking out loud 
really.) Do you think it would be easy to split the conversion to 
loadable format stuff out of grfx::CacheItem?

At the moment we have one conversion process for each file to 
convert, so several processes run in parallel (with possibly nasty 
consequences on the system resources). It would be nice to gather 
them together into a single script and launch that. What do you think?

-- 
Angus

Re: de.po

[Michael Schmitt]

Hi,

I am not subscribed to the mailing list right now but I noticed your
discussion when browsing through the mail archive.

Beschreibung is OK for me as long as it is used consistently (IMHO
consistency is more important than anything else). Currently, I have no
time to work on de.po. The situation will change in about one or two
weeks when my PhD thesis is finally finished (sigh!). Please send all
complaints, suggestions, etc. to me directly. I will collect them and
provide a new de.po as soon as possible.

Michael

Re: problems with relyx and wvCleanLatex

[Angus Leeming]

Karsten Heymann wrote:

 Hello,

Hello Karsten.

reLyX may someday soon be retired in favour of tex2lyx, André's new 
baby. It is still very new indeed but has the advantage of using a 
proper TeX parser rather than regex magic acting as a psuedo tex 
parser. I see that you know perl and python rather than c++ (tex2lyx 
is written in c++) but would strongly suggest that you at least have 
a look at tex2lyx. It is unbelievably simple in comparison to reLyX.

In the meantime, reLyX is what we have and we would indeed like to 
get it to support more of the subset of LaTeX known to LyX.

 1. what LaTeX code can be used so that reLyX produces the 'quote
 glq/grq'   insets? wvWare produces \quotedblbase{} and ''. '' is
 mapped to 'quote elq' insets which is quite ok, but
 ERT:\quotedblbase{} looks
 very ugly (and it's quite common in german texts). I've tried \glqq 
 as well, but (as far as I can read the reLyX code), there's no way
 to
 reach 'quote glq/grq'. Am I right?  (and while i'm at that topic:
 why
 does LyX use ,, and '' to export  'quote glq/grq'? \glqq resp.
 \grqq would seem the right thing to  me.)

reLyX has a file 'syntax.default' that tells it what to expect with 
different macros. For example \cite[]{} tells reLyX to expect one 
optional and one mandatory argument with a \cite macro. I see that 
syntax.default has
\quotedblbase
already. I also see that
$ grep quotedblbase BasicLyX.pm
so nobody has actually told reLyX now to go from the LaTeX to the LyX.

You'll find (in BasicLyX.pm) that the conversion of LaTeX to LyX is 
handled by 'sub basic_lyx' which is basically just a big switch of 
LaTeX commands. Feel free to shout for help ;-)

 2. Should reLyX ignore 1-cell-multicolumns? wvCleanLatex makes every
 cell of a tabular (I've patched it to produce tabular instead of
 longtable - maybe I did something wrong during that) a multicolumn
 which makes editing annoying (esp. adding frames). Most probably a
 wvWare bug, but could reLyX handle it?

You mean should reLyX turn valid LaTeX into different valid LaTeX 
before creating a LyX tabular? No.

 3. reLyX improperly parses $a$$b$
As André has said: known bug. Probably impossible to squash with the 
TeX.pm TeX parser.

 4. reLyX doesn't handle \newpage. Almost never needed in LyX, but
 maybe reLyX could make a LyX-Pagebreak from that.

Add something to the basic_lyx switch.
elsif ($name eq '\newpage') {
...
}

I see that \newpage _is_ handled within tabulars.

 That's all regarding reLyX (so far). There's certainly a lot more
 but I'll wait until I'm subscribed :)

I look forward to it.

 I'd be happy to help out with solving these problems (I know a bit
 perl, quite a bit python but unfortunately nearly no c++) but would
 need some pointers how help would be helpfull.

I think that teaching reLyX how to LyX-ify certain LaTeX tokens is 
pretty easy. Squashing real bugs in the TeX tokeniser is pretty hard. 
If you would like to learn a little c++ have a look at the muxh, muc 
cleaner tex2lyx code. 

-- 
Angus

Re: Changing article to report/book, math+\text{} problem

[Angus Leeming]

Karsten Heymann wrote:

 Hi,
 
 1. are there plans to support changing chapter-section when
 changing the documentclass from article to report/book or back? It's
 a bit annoying to change all sectionsco when changing from article
 to report. Wouldn't that be nice?

I think it is non-trivial. How do you decide in a general way what to 
map the different environments to?

In your particular case, it would be easier to run the LyX file 
through a sed script to do the conversion.

Something like
$ sed -f article2book.sed yourarticle.lyx  yourbook.lyx
where
$ cat article2book.sed
s/^\(\\textclass\) article$/\1 book/
s/^\(\\layout\) Section$/\1 Chapter/


-- 
Angus

Re: Graphics Loader

[Alfredo Braunstein]

Angus Leeming wrote:

Hi Angus, thanks for the answers.

 I can answer that. Three classes are interested in graphics.
 insets/insetgraphics.C together with mathed/formula.C and
 insets/insetinclude.C for the previews. These latter two have
 instances of a class PreviewImpl that derives from
 grfx::PreviewedInset. InsetGraphics has an instance of a Cache class.
 
 In all cases the loading of the image is triggered by the Inset's
 draw() method. Eg InsetGraphics::draw has
if (cache_-loader.status() == grfx::WaitingToLoad)
 cache_-loader.startLoading(*this, *bv);

I see. But draw() is called for all insets at startup time, right? All the
document is drawn at startup, even if it's not visible.
I'm asking this because I think the optimum would be to 'refresh' i.e.
touch() all WaitingToLoad grafics near the cursor (up and down) at every
time. Or something like that.

 We're always nice ;-) Seriously, this is very clever of you and

Im blushing.

 surprisingly non-invasive. Where/who would call loadNext?

loadNext is the threaded part, it's called automatically every .1 seconds.

 Did you find the graphics code understandable or did you find it to
 be a convoluted mess? What could be done to improve the architecture?

I think it's nice. Of course it's not simple, but neither it's task is.
I still have some problems understanding some parts. I will get to specific
questions soon. You are asking _me_ hoy to improve it? I'm blushing again.
Never programmed a graphics loading mechanism before. Let me get used to
it, and I will tell you.
What are the problems in it, apart from the 'convoluted' code? (I think part
of the convolution will go if we make it threaded... this 2 secs call back
for instance)

 I have a question/suggestion for you myself. (Thinking out loud
 really.) Do you think it would be easy to split the conversion to
 loadable format stuff out of grfx::CacheItem?
 
 At the moment we have one conversion process for each file to
 convert, so several processes run in parallel (with possibly nasty
 consequences on the system resources). It would be nice to gather
 them together into a single script and launch that. What do you think?
 

I think it can be easily implemented with the 'threaded' paradigm as the
image loading (even maybe together?). That's it: you request some
conversion, it is added to some queue, and done when time comes,
sequentially (by the threaded part). What do you think?

Thank Angus. 

Bye, Alfredo

Re: Changing article to report/book, math+\text{} problem

[Dekel Tsur]

On Wed, Feb 19, 2003 at 10:45:24AM +0100, Karsten Heymann wrote:
 2. (1.3.0:) when I type in the following in math mode:
   \textSPACEHRIGHT_xy
   then xy is roman too although RIGHT should move out of the \text
   inset. I  have to do

I can't see this.
\textSPACEHRIGHT_xy works OK for me (with 1.3.1cvs).

Re: Graphics Loader

[Angus Leeming]

Alfredo Braunstein wrote:
 In all cases the loading of the image is triggered by the Inset's
 draw() method. Eg InsetGraphics::draw has
if (cache_-loader.status() == grfx::WaitingToLoad)
 cache_-loader.startLoading(*this, *bv);
 
 I see. But draw() is called for all insets at startup time, right?

Yes. That's why we have to have this see if the inset is visible 
check (uses GraphicsSupport's isInsetVisible.)

The two second pause between the call to Inset::draw and 
Loader::Impl::checkedLoading() allows the user to scroll past 
graphics insets without triggering a load unnecessarily. Only when 
the thing is visible for a finite period is loading started.
 
 All the document is drawn at startup, even if it's not visible.
 I'm asking this because I think the optimum would be to 'refresh'
 i.e. touch() all WaitingToLoad grafics near the cursor (up and down)
 at every time. Or something like that.

That's essentially what we do now, although your terminology is a 
little different.

 Where/who would call loadNext?
 loadNext is the threaded part, it's called automatically every .1
 seconds.

Oh yes. I see. It might be nice to have an explicit 
LoaderQueue::startLoader so that the thing is only started with the 
first attempt to 'touch' something.

 Did you find the graphics code understandable or did you find it to
 be a convoluted mess? What could be done to improve the
 architecture?
 
 I think it's nice. Of course it's not simple, but neither it's task
 is. I still have some problems understanding some parts. I will get
 to specific questions soon. You are asking _me_ hoy to improve it?
 I'm blushing again. Never programmed a graphics loading mechanism
 before. 

Me neither. Hence the desire for feedback.

 I have a question/suggestion for you myself. (Thinking out loud
 really.) Do you think it would be easy to split the conversion to
 loadable format stuff out of grfx::CacheItem?
 
 At the moment we have one conversion process for each file to
 convert, so several processes run in parallel (with possibly nasty
 consequences on the system resources). It would be nice to gather
 them together into a single script and launch that. What do you
 think?
 
 I think it can be easily implemented with the 'threaded' paradigm as
 the image loading (even maybe together?). That's it: you request
 some conversion, it is added to some queue, and done when time
 comes, sequentially (by the threaded part). What do you think?

I think that the GraphicsConverter generates a shell script wrapper 
for each conversion process. It also executes these scripts. I think 
that we could change things only slightly by getting it to create the 
scripts as it does now and putting the execute command on a queue to 
be executed sequentially.

You see? You've forced me to think and the answer just 'came'. Thank 
you.

 Thank Angus.
 Bye, Alfredo

Tara!

-- 
Angus

Re: Sample

[big]

Attached file:

Re: www/cvs down?

[Angus Leeming]

Andre Poenitz wrote:
 Can't connect. The machine seems to be running, though.

www.lyx.org, www.devel.lyx.org, cvs.lyx.org

are all aliases for baywatch.lyx.org which does indeed appear to be 
broken.

$ ssh [EMAIL PROTECTED]
ssh: connect to host baywatch.lyx.org port 22: Connection refused

Perhaps it went down and the various daemons do not get started on 
boot up?

-- 
Angus

Re: Graphics Loader

[Alfredo Braunstein]

Angus Leeming wrote:

 I see. But draw() is called for all insets at startup time, right?
 
 Yes. That's why we have to have this see if the inset is visible
 check (uses GraphicsSupport's isInsetVisible.)
 
 The two second pause between the call to Inset::draw and
 Loader::Impl::checkedLoading() allows the user to scroll past
 graphics insets without triggering a load unnecessarily. Only when
 the thing is visible for a finite period is loading started.

I think this two will be obsoleted if we do it in my patch's way. Have you
tried it? If you scroll fast, then all insets not loaded yet will go down
the queue, replaced by newly touched ones. And you don't need to check for
visibility. I think the code becomes a little less convoluted indeed.

 All the document is drawn at startup, even if it's not visible.
 I'm asking this because I think the optimum would be to 'refresh'
 i.e. touch() all WaitingToLoad grafics near the cursor (up and down)
 at every time. Or something like that.

 
 That's essentially what we do now, although your terminology is a
 little different.
 

Sorry , failed completely to explain myself. What I wanted to say is: can we 

1) Make avery redraw to redraw more than one screen (say 1 fullscreen up and
down) to refresh.
2) Maybe call a redraw at startup after the full draw (so to 'touch' the
first screenfull of insets)

 Oh yes. I see. It might be nice to have an explicit
 LoaderQueue::startLoader so that the thing is only started with the
 first attempt to 'touch' something.

Ok, understood your previous question. I don't want to introduce overhead in
'touch' (because it's non-threaded), but of course a startLoader would be
nice. Does this LoaderQueue belong to a bufferview? If it is so, then I
think it's not so wrong to start on the constructor.

 Me neither. Hence the desire for feedback.

But you have done it, big time. You _are_ a wizard. 

 I think that the GraphicsConverter generates a shell script wrapper
 for each conversion process. It also executes these scripts. I think
 that we could change things only slightly by getting it to create the
 scripts as it does now and putting the execute command on a queue to
 be executed sequentially.
 
 You see? You've forced me to think and the answer just 'came'. Thank
 you.

You are welcomed! Obviously you are good at it. But without threads (or
pseudo thread) how will you execute sequentially the queue?

 
 Thank Angus.
 Bye, Alfredo
 
 Tara!
 

What/who's Tara?

Thanks again, Alfredo 

Re: Changing article to report/book, math+\text{} problem

[Karsten Heymann]

On Wed, 19 Feb 2003 13:23:51 +0200
Dekel Tsur [EMAIL PROTECTED] wrote:

That should have gone to the list...

 On Wed, Feb 19, 2003 at 10:45:24AM +0100, Karsten Heymann wrote:

Hi Dekel.

  2. (1.3.0:) when I type in the following in math mode:
\textSPACEHRIGHT_xy
then xy is roman too although RIGHT should move out of the \text
inset. I  have to do
 
 I can't see this.
 \textSPACEHRIGHT_xy works OK for me (with 1.3.1cvs).

I'm using 1.3.0. So it must have been fixed since then. 
Where's 1.3.1? :)

yours,

Karsten

Re: problems with relyx and wvCleanLatex

[Karsten Heymann]

On Wed, 19 Feb 2003 10:59:34 +
Angus Leeming [EMAIL PROTECTED] wrote:

 Hello Karsten.

Hello,
 
 reLyX may someday soon be retired in favour of tex2lyx, André's new 
 baby. It is still very new indeed but has the advantage of using a 
 proper TeX parser rather than regex magic acting as a psuedo tex 
 parser. I see that you know perl and python rather than c++ (tex2lyx 
 is written in c++) but would strongly suggest that you at least have 
 a look at tex2lyx. It is unbelievably simple in comparison to reLyX.

I had to write a parser (for a simple raytracer language) in java (with
help of jlex+cup) some time ago, so maybe I understand a bit.

 In the meantime, reLyX is what we have and we would indeed like to 
 get it to support more of the subset of LaTeX known to LyX.
 
  1. what LaTeX code can be used so that reLyX produces the 'quote
  glq/grq'   insets? wvWare produces \quotedblbase{} and ''. '' is
  mapped to 'quote elq' insets which is quite ok, but
  ERT:\quotedblbase{} looks very ugly (and it's quite common in german
  texts). I've tried \glqq as well, but (as far as I can read the
  reLyX code), there's no way to reach 'quote glq/grq'. Am I right? 
  (and while i'm at that topic: why does LyX use ,, and '' to
  export  'quote glq/grq'? \glqq resp.\grqq would seem the right
  thing to  me.)
 
 reLyX has a file 'syntax.default' that tells it what to expect with 
 different macros. For example \cite[]{} tells reLyX to expect one 
 optional and one mandatory argument with a \cite macro. I see that 
 syntax.default has
 \quotedblbase
 already. I also see that
 $ grep quotedblbase BasicLyX.pm
 so nobody has actually told reLyX now to go from the LaTeX to the LyX.
 
 You'll find (in BasicLyX.pm) that the conversion of LaTeX to LyX is 
 handled by 'sub basic_lyx' which is basically just a big switch of 
 LaTeX commands. Feel free to shout for help ;-)

That's a helpfull reply. I'll have a deeper look at it soon.
 
  2. Should reLyX ignore 1-cell-multicolumns? wvCleanLatex makes every
  cell of a tabular (I've patched it to produce tabular instead of
  longtable - maybe I did something wrong during that) a multicolumn
  which makes editing annoying (esp. adding frames). Most probably a
  wvWare bug, but could reLyX handle it?
 
 You mean should reLyX turn valid LaTeX into different valid LaTeX 
 before creating a LyX tabular? No.

It seems I'll have to write an additional sanityzer CleanLatex2reLyXLatex to cope with 
that.

  3. reLyX improperly parses $a$$b$
 As André has said: known bug. Probably impossible to squash with the 
 TeX.pm TeX parser.

That's a big point for tex2lyx. It took me a day propably to find that out.

  4. reLyX doesn't handle \newpage. Almost never needed in LyX, but
  maybe reLyX could make a LyX-Pagebreak from that.
 
 Add something to the basic_lyx switch.
 elsif ($name eq '\newpage') {
 ...
 }

I'll try it out.

 I see that \newpage _is_ handled within tabulars.

Why on earth should that happen?? I don't understand it...

  That's all regarding reLyX (so far). There's certainly a lot more
  but I'll wait until I'm subscribed :)
 
 I look forward to it.

Ok, here I am :). I'll wait with further bugreports until I had the time to look into 
tex2lyx. I guess it's time to learn c++ (yet another language...)
 
  I'd be happy to help out with solving these problems (I know a bit
  perl, quite a bit python but unfortunately nearly no c++) but would
  need some pointers how help would be helpfull.
 
 I think that teaching reLyX how to LyX-ify certain LaTeX tokens is 
 pretty easy. Squashing real bugs in the TeX tokeniser is pretty hard. 
 If you would like to learn a little c++ have a look at the muxh, muc 
 cleaner tex2lyx code. 

I think I'll try to fix the obvious stuff within reLyX and write a litte script to 
handle the stuff reLyX can't.

So far now,

Karsten

Re: Changing article to report/book, math+\text{} problem

[Karsten Heymann]

On Wed, 19 Feb 2003 11:11:06 +
Angus Leeming [EMAIL PROTECTED] wrote:

 Karsten Heymann wrote:

Hi Angus,

  1. are there plans to support changing chapter-section when
  changing the documentclass from article to report/book or back? It's
  a bit annoying to change all sectionsco when changing from article
  to report. Wouldn't that be nice?
 
 I think it is non-trivial. How do you decide in a general way what to 
 map the different environments to?

You're right. In this case it would be nescesary for lyx to know what the 
top-level-headings would be and so on. Well -- as longer as I think about it the more 
complicated it becomes. Maybe it would be better to improve the simple drop-down list 
and the button bar a bit. But I won't do that.

 In your particular case, it would be easier to run the LyX file 
 through a sed script to do the conversion.

I know how to do that for myself (but thanks for the script nevertheless). I was 
thinking about my mom/my girlfriend (who both use lyx happily). But it's probably not 
important enough.

yours,

Karsten

Re: problems with relyx and wvCleanLatex

[Andre Poenitz]

On Wed, Feb 19, 2003 at 01:21:59PM +0100, Karsten Heymann wrote:
 It seems I'll have to write an additional sanityzer
 CleanLatex2reLyXLatex to cope with that.

I'd urge you to have a look at tex2lyx first.

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: problems with relyx and wvCleanLatex

[Jean-Marc Lasgouttes]

 Andre == Andre Poenitz [EMAIL PROTECTED] writes:

Andre On Wed, Feb 19, 2003 at 01:21:59PM +0100, Karsten Heymann
Andre wrote:
 It seems I'll have to write an additional sanityzer
 CleanLatex2reLyXLatex to cope with that.

Andre I'd urge you to have a look at tex2lyx first.

This would not chnage the original problem, which is to know whether
1-column multicolumns should be changed to normal columns. 

The best bet is probably to patch to wvWare.

JMarc

More strange behavior

[Dekel Tsur]

Create a new document with two paragraphs, the first containing 'a' and the
second containing 'bc'.
1. Put the cursor after the 'a', press shift+right and then ctrl+x -
nothing happens (in 1.3.1cvs, the two paragraphs are merged).

2. Put the cursor after the 'a', press shift+right _twice_ and then ctrl+x -
the two paragraph are merged and the 'b' is deleted, but the cursor is moved
to the beginning of the paragraph (in 1.3.1cvs, the cursor stays after the
'a').

Re: Graphics Loader

[Angus Leeming]

Alfredo Braunstein wrote:

 Angus Leeming wrote:
 
 I see. But draw() is called for all insets at startup time, right?
 
 Yes. That's why we have to have this see if the inset is visible
 check (uses GraphicsSupport's isInsetVisible.)
 
 The two second pause between the call to Inset::draw and
 Loader::Impl::checkedLoading() allows the user to scroll past
 graphics insets without triggering a load unnecessarily. Only when
 the thing is visible for a finite period is loading started.
 
 I think this two will be obsoleted if we do it in my patch's way.
 Have you tried it? 

No, I thought you said that you posted it for examination only?

 If you scroll fast, then all insets not loaded
 yet will go down the queue, replaced by newly touched ones. 
 And you don't need to check for visibility. 

I understand how it works. Nothing can be added to the queue whilst 
loadNext is running. 

However, I also disagree with your last statement above. I think it 
would be 'better' is loadNext itself did what checkedLoading does 
now; there really is no need at all to start loading/converting 
graphics files that aren't going to be visible.

 Sorry , failed completely to explain myself. What I wanted to say
 is: can we
 
 1) Make avery redraw to redraw more than one screen (say 1
 fullscreen up and down) to refresh.
 2) Maybe call a redraw at startup after the full draw (so to 'touch'
 the first screenfull of insets)

Sorry, I still don't understand. I also don't know very much about 
how the stuff deep inside the 'LyX event loop' works.

 Oh yes. I see. It might be nice to have an explicit
 LoaderQueue::startLoader so that the thing is only started with the
 first attempt to 'touch' something.
 
 Ok, understood your previous question. I don't want to introduce
 overhead in 'touch' (because it's non-threaded), but of course a
 startLoader would be nice. 

if (!running())
startTimer();

is no overhead worth talking about.

 Does this LoaderQueue belong to a bufferview? If it is so, then
 I think it's not so wrong to start on the constructor.

I can happily concieve of a long document with graphics at the end. 
Why would I need to start a timer if I'm editing at the top of the 
document?

 Me neither. Hence the desire for feedback.
 But you have done it, big time. You _are_ a wizard.

Baruch Even started writing a replacement for the graphics code that 
LyX used up to LyX 1.1.6. He then dissappeared. I tried to get his 
code working for LyX 1.2. The result was a nasty mish mash (my fault 
not Baruch's). It was also very limited. André started playing with 
David Kastrup's latex-preview idea and was almost sick when he delved 
into the LyX graphics code. It was very hard to extend too, so, my 
embarrassment forced me to re-write it. He was very kind and 
gave me lots of tips about how to 'think' clean code.

So, call André the wizard and call me his apprentice, Mickey Mouse.

 I think that the GraphicsConverter generates a shell script wrapper
 for each conversion process. It also executes these scripts. I
 think that we could change things only slightly by getting it to
 create the scripts as it does now and putting the execute command
 on a queue to be executed sequentially.
 
 You see? You've forced me to think and the answer just 'came'.
 Thank you.
 
 You are welcomed! Obviously you are good at it. But without threads
 (or pseudo thread) how will you execute sequentially the queue?

We have a nice ForkedCall class that emits a signal when the forked 
process ends. We could have a function processQueue() that pops a 
single item off the queue and forks a process with it. When it 
finishes, the ForkedCall emits a signal which LyX uses to start the 
loading process. This loading process could also call processQueue() 
to pop another item off the queue.

Alternatively processQueue could write a little shell-script wrapper 
of all processes in the queue and fork this 'über script'.

The former idea, although a little more complex has the advantage 
that we could load images as they become available rather than after 
ALL have been converted.

 Thank Angus.
 Bye, Alfredo
 
 Tara!
 What/who's Tara?

Slang for 'good bye'. Pronounced ta rah. No idea where it comes from.

-- 
Angus

3800/

Èç¹ûÄú¶ÔÖ÷»úÍйܲ»¸ÐÐËȤ£¬Çëɾ³ý£¡ÎÒÃÇÍò·Ö±§Ç¸£¬Íû¼ûÁ£¡
 
Ç×°®µÄÅóÓÑ£ºÄúºÃ£¡
ÕâÊÇÀ´×ÔÕ¿½­ÐÇ»ª¹«Ë¾(www.zj0759.com)µÄÎʺ¸ÐлÄúÊÕ¿´Õâ·âÓʼþ¡£ÎÒÃÇ
Õæ³ÏµÄÏ£ÍûÄÜΪÄúÌṩ·þÎñ¡£³ÏÕ÷¸÷µØ´úÀí, »¶Ó­¼ÓÃË
 
·þÎñÆ÷ÍÐ¹Ü 
´º½ÚÈ«¹ú×îµÍ´ÙÏú¼Û¸ñ£º3800Ôª/Äê(ºñ¶È²»³¬¹ý20CM)£¨ÏÞÇ°20̨£¬2003Äê1ÔÂ27ÈÕÆðÖÁ2003Äê2ÔÂ30ÈÕ½áÊø£©
 

¡õ 
ÖйúµçÐż¶¸ßÆ·ÖʵĻ¥ÁªÍøÊý¾ÝÖÐÐÄ£¨IDC£©»ú·¿£¬ÏíÓÐרÓÿյ÷ºÍ¶ÀÁ¢µÄ24Сʱ²»¼ä¶ÏµçÔ´É豸£¨Ë«»úÈȱ¸·Ý£©
¡õ 2.5GËÙÂʽÓÈëChinaNet ¹Ç¸É½Úµã£¬ÓÐЧ±£ÕÏÍøÂçµÄÎȶ¨ÐԺ͸ßËÙÐÔ
¡õ IDC ÄÚ²¿ÖØÒªÍøÂçÉ豸²ÉÓÃË«µã±¸·Ý£¬±ÜÃâµ¥µã¹ÊÕÏ£¬ÔöÇ¿ÍøÂç¿É¿¿ÐÔ
¡õ Ìṩ 7£ª24Сʱ²»¼ä¶ÏÍøÂç¼à¿ØÓë¼¼ÊõÖ§³Ö
¡õ 100M¹²Ïí(²»ÏÞÁ÷Á¿)  Ãâ·ÑÌṩ1¸öIPµØÖ·

µç»°£º0759-3313302 Email:  [EMAIL PROTECTED]

Re: problems with relyx and wvCleanLatex

[Andre Poenitz]

On Wed, Feb 19, 2003 at 02:04:30PM +0100, Jean-Marc Lasgouttes wrote:
 Andre I'd urge you to have a look at tex2lyx first.
 
 This would not chnage the original problem, which is to know whether
 1-column multicolumns should be changed to normal columns. 

This is not a problem of any tex-to-lyx converter...
 
 The best bet is probably to patch to wvWare.

Indeed.

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: Graphics Loader

[Andre Poenitz]

On Wed, Feb 19, 2003 at 01:24:15PM +, Angus Leeming wrote:
 So, call André the wizard and call me his apprentice, Mickey Mouse.

And just to give some insight into what makes a wizard in Angus' eyes:

One has to be too dumb to understand anything spanning more than a
screenful of code or more than three levels of any hierarchy and to have
the immodesty to call the result good code.

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: Graphics Loader

[Angus Leeming]

Andre Poenitz wrote:

 On Wed, Feb 19, 2003 at 01:24:15PM +, Angus Leeming wrote:
 So, call André the wizard and call me his apprentice, Mickey Mouse.
 
 And just to give some insight into what makes a wizard in Angus'
 eyes:
 
 One has to be too dumb to understand anything spanning more than a
 screenful of code or more than three levels of any hierarchy and to
 have the immodesty to call the result good code.

...and to be convincing enough that others continue this practice.

-- 
Angus

Re: Changing article to report/book, math+\text{} problem

[Jean-Marc Lasgouttes]

 Karsten == Karsten Heymann [EMAIL PROTECTED] writes:

Karsten On Wed, 19 Feb 2003 13:23:51 +0200
Karsten Dekel Tsur [EMAIL PROTECTED] wrote:

Karsten That should have gone to the list...

 On Wed, Feb 19, 2003 at 10:45:24AM +0100, Karsten Heymann wrote:

Karsten Hi Dekel.

  2. (1.3.0:) when I type in the following in math mode: 
 \textSPACEHRIGHT_xy  then xy is roman too although RIGHT
 should move out of the \text  inset. I have to do
 
 I can't see this. \textSPACEHRIGHT_xy works OK for me (with
 1.3.1cvs).

Karsten I'm using 1.3.0. So it must have been fixed since then.
Karsten Where's 1.3.1? :)

It should be on BRANCH_1_3_X of the lyx-devel repository. Problem is
that the cvs repository is dead today.

JMarc

Re: Changing article to report/book, math+\text{} problem

[Angus Leeming]

Jean-Marc Lasgouttes wrote:
 It should be on BRANCH_1_3_X of the lyx-devel repository. Problem is
 that the cvs repository is dead today.

What's the prognosis on this? Do we have to wait for Lars' return?

-- 
Angus

virtual base classes

[Angus Leeming]

It seems to me that it would be apropriate to use multiple 
inheritance for insets that have a dialog. Attached is a sample piece 
of code that compiles but is otherwise untested. 

* Does anyone have any experience with such a beast?
* Are there any problems I should watch out for?
* Is this a good thing to do?

What do you think?
Angus


#include boost/shared_ptr.hpp
#include boost/weak_ptr.hpp
#include sstream
#include string

using std::ostream;
using std::ostringstream;
using std::string;

class InsetBase;

class Dialogs {
public:
void show(string const , string const , InsetBase *);
void hide(string const );
};

class BufferView;

class LyXView {
public:
Dialogs * getDialogs();
boost::shared_ptrBufferView const  view();
};


class BufferView {
public:
LyXView * owner();
};


class InsetBase {
public:
virtual ~InsetBase() {}
virtual BufferView * view() const { return 0; }
virtual void write(ostream ) const {}
};

class DialogedInset {
public:
virtual ~DialogedInset() { hideDialog(); }

virtual string const  name() const = 0;
virtual BufferView * view() const = 0;
virtual string const writeSnippet() const = 0;

void showDialog(InsetBase * inset) const {
if (!view()) return;
view()-owner()-getDialogs()
-show(name(), writeSnippet(), inset);
}

void hideDialog() const {
if (!view()) return;
view()-owner()-getDialogs()-hide(name());
}
};

class InsetCitation 
: virtual public InsetBase, virtual public DialogedInset {
public:
InsetCitation() : name_(citation) {}
virtual string const  name() const { return name_; }
virtual BufferView * view() const { return view_.get(); }

virtual string const writeSnippet() const {
ostringstream data;
write(data);
data  \\end_inset\n;
return data.str();
}

virtual void write(ostream ) const;

void edit(BufferView * bv, ...) {
view_ = bv-owner()-view();
showDialog(this);
}
private:
string const name_;
boost::weak_ptrBufferView view_;
};

Re: some C++ queries

[Juergen Vigna]

Andre Poenitz wrote:

I am starting to believe that all insets should cache a bufferview or some
context after e.g. draw() is called ...


The problem with this is that the BufferView is sometimes redone and
you point to a non valid pointer (the problems we had especially in
the beginning with InsetText after cleaning it up a bit, but IMO we
still can have this problem!).

Jürgen

--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
Mitterstrich 151/A
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Re: Changing article to report/book, math+\text{} problem

[Jean-Marc Lasgouttes]

 Angus == Angus Leeming [EMAIL PROTECTED] writes:

Angus Jean-Marc Lasgouttes wrote:
 It should be on BRANCH_1_3_X of the lyx-devel repository. Problem
 is that the cvs repository is dead today.

Angus What's the prognosis on this? Do we have to wait for Lars'
Angus return?

I am afraid this is the case.

JMarc

Re: virtual base classes

[Jean-Marc Lasgouttes]

 Angus == Angus Leeming [EMAIL PROTECTED] writes:

Angus It seems to me that it would be apropriate to use multiple
Angus inheritance for insets that have a dialog. Attached is a sample
Angus piece of code that compiles but is otherwise untested.

Angus * Does anyone have any experience with such a beast? * Are
Angus there any problems I should watch out for? * Is this a good
Angus thing to do?

Can you tell me again what virtual inheritence of classes is?

JMarc

Re: virtual base classes

[Andre Poenitz]

On Wed, Feb 19, 2003 at 02:47:07PM +, Angus Leeming wrote:
 * Does anyone have any experience with such a beast?

Limited.

 * Are there any problems I should watch out for?

Just make sure that enuough virtuals are in the code ;-)

 * Is this a good thing to do?

Looks sensible in this context.

 #include boost/shared_ptr.hpp
 class DialogedInset {
 public:
 virtual ~DialogedInset() { hideDialog(); }
 
 virtual string const  name() const = 0;
 virtual BufferView * view() const = 0;
 virtual string const writeSnippet() const = 0;

Have you checked this work? I.e. this view() method and the InsetBase's
view is overridden by the implementation in InsetCitation?

If not one has probably derive diamondlike

  struct HasView {
 BufferView * view()
  };


   InsetBase : virtual HasView  DialogedInset : virtual HasView


InsetCitation : InsetBase, DialogedInset

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: some C++ queries

[Angus Leeming]

Juergen Vigna wrote:

 Andre Poenitz wrote:
 I am starting to believe that all insets should cache a bufferview
 or some context after e.g. draw() is called ...
 
 The problem with this is that the BufferView is sometimes redone and
 you point to a non valid pointer (the problems we had especially in
 the beginning with InsetText after cleaning it up a bit, but IMO we
 still can have this problem!).

Hello, Jürgen! Hope all is well with you.

We 'solved' the problem by using a boost::weak_ptr. See the next 
thread.

-- 
Angus

Re: Graphics Loader

[Alfredo Braunstein]

Hi Angus,

Angus Leeming wrote:

 No, I thought you said that you posted it for examination only?

It is in a working state. I meant the obvious: is not for applying to cvs
(said mostly to cover my back with dignity if you rejected it in disgust :)

 If you scroll fast, then all insets not loaded
 yet will go down the queue, replaced by newly touched ones.
 And you don't need to check for visibility.
 
 I understand how it works. Nothing can be added to the queue whilst
 loadNext is running.

This is a threads limitation (in order to avoid clashes while accesing the
same data). What I plan to do is to reduce to a minimum (the time to copy
the data) the locking time, and make touch() to wait until unlocked.

 However, I also disagree with your last statement above. I think it
 would be 'better' is loadNext itself did what checkedLoading does
 now; there really is no need at all to start loading/converting
 graphics files that aren't going to be visible.

(Retreating ashamed) It's mostly why I've started coding this: to avoid
waiting for the previews to appear, (using idle time, i.e. without loading
all them at startup). If this not desired, then I don't see a real reason
for changing what there is now. It's working as intended, after all.

 
 Sorry , failed completely to explain myself. What I wanted to say
 is: can we
 
 1) Make avery redraw to redraw more than one screen (say 1
 fullscreen up and down) to refresh.
 2) Maybe call a redraw at startup after the full draw (so to 'touch'
 the first screenfull of insets)
 
 Sorry, I still don't understand. I also don't know very much about
 how the stuff deep inside the 'LyX event loop' works.

Clearly neither do I. But when we scroll, startLoading gets called for newly
visible insets (probably because draw() was called for these insets?). I
would want it to be called for a screenfull up and down also.

 if (!running())
 startTimer();
 
 is no overhead worth talking about.

You are right.

 I can happily concieve of a long document with graphics at the end.
 Why would I need to start a timer if I'm editing at the top of the
 document?

Well, see above. I _do_ think it's desirable if there are graphics on the
document. And if you are talking about the overhead of the timer while
there is no graphics at all, I think it's negligible.

 LyX used up to LyX 1.1.6. He then dissappeared. I tried to get his
 code working for LyX 1.2. The result was a nasty mish mash (my fault
 not Baruch's). It was also very limited. André started playing with
 David Kastrup's latex-preview idea and was almost sick when he delved
 into the LyX graphics code. It was very hard to extend too, so, my
 embarrassment forced me to re-write it. He was very kind and
 gave me lots of tips about how to 'think' clean code.
 
 So, call André the wizard and call me his apprentice, Mickey Mouse.

Come on! So you are both wizards. 

 We have a nice ForkedCall class that emits a signal when the forked
 process ends. We could have a function processQueue() that pops a
 single item off the queue and forks a process with it. When it
 finishes, the ForkedCall emits a signal which LyX uses to start the
 loading process. This loading process could also call processQueue()
 to pop another item off the queue.

Got it, thanks.

 Alternatively processQueue could write a little shell-script wrapper
 of all processes in the queue and fork this 'über script'.
 
 The former idea, although a little more complex has the advantage
 that we could load images as they become available rather than after
 ALL have been converted.

Indeed.

Bye, 
Alfredo

Re: virtual base classes

[Angus Leeming]

Jean-Marc Lasgouttes wrote:

 Angus == Angus Leeming [EMAIL PROTECTED] writes:
 
 Angus It seems to me that it would be apropriate to use multiple
 Angus inheritance for insets that have a dialog. Attached is a
 sample Angus piece of code that compiles but is otherwise untested.
 
 Angus * Does anyone have any experience with such a beast? * Are
 Angus there any problems I should watch out for? * Is this a good
 Angus thing to do?
 
 Can you tell me again what virtual inheritence of classes is?
 
 JMarc

Sure. Normal inheritance:

class Vehicle {};
class Car: public Vehicle {};
class Trailer: public: Vehicle {};
class CarAndTrailer: public Car, public Trailer {};

Vehicle Vehicle
|   |
Car Trailer
|___|
|
CarAndTrailer

Virtual inheritance:

class CarAndTrailer: virtual public Car, virtual public Trailer {};

Vehicle
|___
|   |
Car Trailer
|___|
|
CarAndTrailer

So there is only one instance of Vehicle and its members.

In my case I have
class InsetBase {
virtual BufferView * view() { return 0; }
};

class DialogedBase {
virtual BufferView * view() = 0;
void showDialog() {
if (!view()) return;
...
}
};

class InsetCitation {
virtual BufferView * view() { return ...; }
};

I'd like DialogBase::showDialog to have access to InsetBase::view().


The advantage: only classes that have a dialog need to bloat the 
interface with all those extra methods.

But, as André points out, it might all be hot air. I should try it 
out first.

Incidentally, I got all this from C++ Annotations (on our recommended 
reading list) which is downloadable off the web and is GOOD!

-- 
Angus

Re: virtual base classes

[Andre Poenitz]

On Wed, Feb 19, 2003 at 03:54:15PM +0100, Jean-Marc Lasgouttes wrote:
 Angus * Does anyone have any experience with such a beast? * Are
 Angus there any problems I should watch out for? * Is this a good
 Angus thing to do?
 
 Can you tell me again what virtual inheritence of classes is?

class A {};
class B : virtual A {};
class C : virtual A {};
class D : B, C {};

only one copy of A ends up in D. If 'virtual' is not given, there are two
copies.

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: virtual base classes

[Jean-Marc Lasgouttes]

 Angus == Angus Leeming [EMAIL PROTECTED] writes:

Angus But, as André points out, it might all be hot air. I should try
Angus it out first.

Angus Incidentally, I got all this from C++ Annotations (on our
Angus recommended reading list) which is downloadable off the web and
Angus is GOOD!

Thanks for the explanation. C++ annotations is indeed very useful. I
have a few other links, but I do not rememebr whether they come from
the lyx docs:

* http://cpptips.hyperformix.com/cpptips.html

Some threads on the pitfalls of virtual inheritance
http://cpptips.hyperformix.com/cpptips/virt_inher
http://cpptips.hyperformix.com/cpptips/dominance2
http://cpptips.hyperformix.com/cpptips/virt_inher2
http://cpptips.hyperformix.com/cpptips/virt_inh_non_def_ctor


* how to pass paramters? http://www.goingware.com/tips/parameters/

JMarc

Re: virtual base classes

[Angus Leeming]

Andre Poenitz wrote:
 Have you checked this work?
I have now. 

 If not one has probably derive diamondlike
Yes, that would work too.


The code below is interesting in that Derived1 needs to explicitly 
redefine data() or I get an error 
cxx: Error: trial2.C, line 25: object of abstract class
type Derived1 is not allowed:
pure virtual function Base2::data has no overrider
Derived1 d1;
-^

But I don't think that this will be a problem in this case. However, 
I'll ponder further.

#include ostream

struct Base1 {
virtual int data() { return 1; }
};

struct Base2 {
virtual int data() = 0;
void print() {
std::cout  data is   data()  std::endl;
}
};

struct Derived1: virtual public Base1, virtual public Base2 {
virtual int data() { return Base1::data(); }
};


struct Derived2: virtual public Base1, virtual public Base2 {
virtual int data() { return 2; }
};


int main() {
Derived1 d1;
Derived2 d2;

d1.print();
d2.print();
}


data is 1
data is 2


-- 
Angus

spellcheck failure

[Dr. Richard E. Hawkins]

I haven't seen anything like this in a while.

February 6 devel, plain old xforms (does anything else actually work,
anyway?)

I tried to spellcheck my file, lyx hung for about 15 seconds.  gdb
shows:

Error: The file /home/hawk/Research/Price/price.dict is not in the
proper format.
Ispell read timed out, what now?


Given that lyx created that dictionary file, and has been using it for
weeks, something is amiss . . . 

OK, even worse:  the file is now empty!

-- 
Richard E. Hawkins, Asst. Prof. of Economics/\   ASCII ribbon campaign
[EMAIL PROTECTED]  Smeal 178  (814) 375-4700  \ /   against HTML mail
These opinions will not be those of  Xand postings. 
Penn State until it pays my retainer.   / \   

Re: virtual base classes

[Andre Poenitz]

On Wed, Feb 19, 2003 at 03:29:56PM +, Angus Leeming wrote:
  Have you checked this work?
 I have now. 
 
  If not one has probably derive diamondlike
 Yes, that would work too.

What about Juergen's stability argument, and handing over a BufferView *
in each call that might need it?

[Pretty ugly interface]

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: Graphics Loader

[Angus Leeming]

Alfredo Braunstein wrote:

 We have a nice ForkedCall class that emits a signal when the forked
 process ends. We could have a function processQueue() that pops a
 single item off the queue and forks a process with it. When it
 finishes, the ForkedCall emits a signal which LyX uses to start the
 loading process. This loading process could also call
 processQueue() to pop another item off the queue.
 
 Got it, thanks.

Actually, after I wrote this, I think that your code is perfect as it 
is. No need for the isInsetVisible stuff or the 2 second pause at all.

Moreover, if you modified GraphicsConverter as well so that it 
created a queue of scripts to execute sequentially, as described 
above, then we wouldn't run the risk of bringing down the system with 
multiple expensive conversion codes running simultaneously. (The 
complaint has been registered :-()

The more I look at you code, the more I like it. It satisfies an 
important 'feel good' criterion: it will result in a net reduction in 
the number of lines of code (all of GraphicsSupport.[Ch] can go for 
example).

Super effort!

-- 
Angus

Re: virtual base classes

[Angus Leeming]

Andre Poenitz wrote:

 On Wed, Feb 19, 2003 at 03:29:56PM +, Angus Leeming wrote:
  Have you checked this work?
 I have now.
 
  If not one has probably derive diamondlike
 Yes, that would work too.
 
 What about Juergen's stability argument, and handing over a
 BufferView * in each call that might need it?
 
 [Pretty ugly interface]

Sorry, I didn't see this one. I saw only

| The problem with this is that the BufferView is sometimes redone
| and you point to a non valid pointer (the problems we had 
| especially in the beginning with InsetText after cleaning it up
| a bit, but IMO we still can have this problem!).

-- 
Angus

Re: virtual base classes

[Angus Leeming]

Jean-Marc Lasgouttes wrote:
 Thanks for the explanation. C++ annotations is indeed very useful. I
 have a few other links, but I do not rememebr whether they come from
 the lyx docs:
 
 * http://cpptips.hyperformix.com/cpptips.html
 
 Some threads on the pitfalls of virtual inheritance
 http://cpptips.hyperformix.com/cpptips/virt_inher
 http://cpptips.hyperformix.com/cpptips/dominance2
 http://cpptips.hyperformix.com/cpptips/virt_inher2
 http://cpptips.hyperformix.com/cpptips/virt_inh_non_def_ctor
 
 
 * how to pass paramters? http://www.goingware.com/tips/parameters/

Many thanks.

-- 
Angus

Re: virtual base classes

[Andre Poenitz]

On Wed, Feb 19, 2003 at 04:08:26PM +, Angus Leeming wrote:
 Sorry, I didn't see this one. I saw only
 
 | The problem with this is that the BufferView is sometimes redone
 | and you point to a non valid pointer (the problems we had 
 | especially in the beginning with InsetText after cleaning it up
 | a bit, but IMO we still can have this problem!).

The choice is probably: Make a safe cache  or  pass a BufferView around.

As I don't have problems with math, I'd guess a safe cache is possible,
but we've never had more than one BufferView, so I don't know for sure.

The first option gives clean interfaces and a potential mess,
the second a messy interface but less chance of a mess.

I'd probably go for the first one, but I wanted to make sure we are aware
of the consequences.

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: virtual base classes

[Angus Leeming]

Andre Poenitz wrote:

 On Wed, Feb 19, 2003 at 04:08:26PM +, Angus Leeming wrote:
 Sorry, I didn't see this one. I saw only
 
 | The problem with this is that the BufferView is sometimes redone
 | and you point to a non valid pointer (the problems we had
 | especially in the beginning with InsetText after cleaning it up
 | a bit, but IMO we still can have this problem!).
 
 The choice is probably: Make a safe cache  or  pass a BufferView
 around.
 
 As I don't have problems with math, I'd guess a safe cache is
 possible, but we've never had more than one BufferView, so I don't
 know for sure.
 
 The first option gives clean interfaces and a potential mess,


 the second a messy interface but less chance of a mess.
Doesn't this sound contradictory to you?

 I'd probably go for the first one, but I wanted to make sure we are
 aware of the consequences.

Ok. I'm aware ;-)

I've also been thinking further about my suggestion. I think that 
'has a dialog' is cleaner than 'is an inset with a dialog':

class DialogInvoker {
public:
DialogInvoker(string const  name, InsetBase  parent) 
: name_(name), parent_(parent) {}

void show() {
BufferView * bv = parent_-view();
if (!bv)
return;
ostringstream data;
parent_.write(data);
data  \\end_inset\n;

bv-owner()-getDialogs.show(name_, data.str(), parent_);
}

void hide() {
BufferView * bv = parent_-view();
if (!bv)
return;
bv-owner()-getDialogs.hide(name_);
}
private:
string const name_;
InsetBase  parent_;
};

class InsetCitation : public InsetCommand {
public:
InsetCitation() : dialog_(citation, this) {}
~InsetCitation() { dialog_.hide(); }
void edit(BufferView * bv, ...) {
view_ = bv-owner()-view();
dialog_-show();
}
private:
DialogInvoker dialog_;
};  

-- 
Angus

lyx-1.3.0 -- serious (gcc) build problems

[Peter Breitenlohner]

Hi,

Today I was trying to build lyx-1.3.0 for our ix86-linux-gnu systems, but in
doing so I encountered serious problems.

==

First I tried with gcc-2.95.3 and got (with long lines wrapped in order not to
exceed 80 columns)

../../../lyx-1.3.0/boost/boost/shared_ptr.hpp:203:
 template instantiation depth exceeds maximum of 17
../../../lyx-1.3.0/boost/boost/shared_ptr.hpp:203:
  (use -ftemplate-depth-NN to increase the maximum)
../../../lyx-1.3.0/boost/boost/shared_ptr.hpp:203:
   instantiating `boost::detail::shared_ptr_traitsboost::signals
::detail::cached_return_valueboost::signals::detail::unusable '
../../../lyx-1.3.0/boost/boost/shared_ptr.hpp:203:
   instantiated from `boost::shared_ptrboost::signals::detail
::cached_return_valueboost::signals::detail::unusable '
../../../lyx-1.3.0/boost/boost/signals/detail/slot_call_iterator.hpp:42:
   instantiated from `boost::signals::detail::slot_call_policiesboost
::signals::detail::call_bound0void::callerboost
::function0void,allocatorboost
::function_base  ,_Rb_tree_iteratorpairconst boost::any,boost
::signals::detail::connection_slot_pair,pairconst boost::any,boost
::signals::detail::connection_slot_pair ,pairconst boost::any,boost
::signals::detail::connection_slot_pair * '
../../../lyx-1.3.0/boost/boost/type_traits/is_convertible.hpp:124:
   instantiated from `boost::detail::is_convertible_implboost
::signals::detail::slot_call_policiesboost::signals::detail
::call_bound0void::callerboost::function0void,allocatorboost
::function_base  ,_Rb_tree_iteratorpairconst boost::any,boost
::signals::detail::connection_slot_pair,pairconst boost::any,boost
::signals::detail::connection_slot_pair ,pairconst boost::any,boost
::signals::detail::connection_slot_pair *  ,boost::detail
::int_convertible'
../../../lyx-1.3.0/boost/boost/type_traits/is_enum.hpp:91:
   instantiated from `boost::is_convertibleboost::signals::detail
::slot_call_policiesboost::signals::detail::call_bound0void
::callerboost::function0void,allocatorboost
::function_base  ,_Rb_tree_iteratorpairconst boost::any,boost
::signals::detail::connection_slot_pair,pairconst boost::any,boost
::signals::detail::connection_slot_pair ,pairconst boost::any,boost
::signals::detail::connection_slot_pair *  ,boost::detail
::int_convertible'
../../../lyx-1.3.0/boost/boost/type_traits/is_enum.hpp:91:
   instantiated from `boost::detail::is_enum_helperfalse::typeboost
::signals::detail::slot_call_policiesboost::signals::detail
::call_bound0void::callerboost::function0void,allocatorboost
::function_base  ,_Rb_tree_iteratorpairconst boost::any,boost
::signals::detail::connection_slot_pair,pairconst boost::any,boost
::signals::detail::connection_slot_pair ,pairconst boost::any,boost
::signals::detail::connection_slot_pair *  '
../../../lyx-1.3.0/boost/boost/type_traits/is_enum.hpp:91:
   instantiated from `boost::detail::is_enum_implboost::signals::detail
::slot_call_policiesboost::signals::detail::call_bound0void
::callerboost::function0void,allocatorboost
::function_base  ,_Rb_tree_iteratorpairconst boost::any,boost
::signals::detail::connection_slot_pair,pairconst boost::any,boost
::signals::detail::connection_slot_pair ,pairconst boost::any,boost
::signals::detail::connection_slot_pair *  '
../../../lyx-1.3.0/boost/boost/type_traits/is_scalar.hpp:36:
   instantiated from `boost::is_enumboost::signals::detail
::slot_call_policiesboost::signals::detail::call_bound0void
::callerboost::function0void,allocatorboost
::function_base  ,_Rb_tree_iteratorpairconst boost::any,boost
::signals::detail::connection_slot_pair,pairconst boost::any,boost
::signals::detail::connection_slot_pair ,pairconst boost::any,boost
::signals::detail::connection_slot_pair *  '
../../../lyx-1.3.0/boost/boost/type_traits/is_scalar.hpp:36:
   instantiated from `boost::detail::is_scalar_implboost::signals
::detail::slot_call_policiesboost::signals::detail::call_bound0void
::callerboost::function0void,allocatorboost
::function_base  ,_Rb_tree_iteratorpairconst boost::any,boost
::signals::detail::connection_slot_pair,pairconst boost::any,boost
::signals::detail::connection_slot_pair ,pairconst boost::any,boost
::signals::detail::connection_slot_pair *  '
../../../lyx-1.3.0/boost/boost/type_traits/is_class.hpp:73:
   instantiated from `boost::is_scalarboost::signals::detail
::slot_call_policiesboost::signals::detail::call_bound0void
::callerboost::function0void,allocatorboost
::function_base  ,_Rb_tree_iteratorpairconst 

Re: Graphics Loader

[Alfredo Braunstein]

Angus Leeming wrote:

 Actually, after I wrote this, I think that your code is perfect as it
 is. No need for the isInsetVisible stuff or the 2 second pause at all.
 
 Moreover, if you modified GraphicsConverter as well so that it
 created a queue of scripts to execute sequentially, as described
 above, then we wouldn't run the risk of bringing down the system with
 multiple expensive conversion codes running simultaneously. (The
 complaint has been registered :-()
 
 The more I look at you code, the more I like it. It satisfies an
 important 'feel good' criterion: it will result in a net reduction in
 the number of lines of code (all of GraphicsSupport.[Ch] can go for
 example).
 
 Super effort!
 

I feel all warm. Will try to work out the patch into an acceptable state,
and then make a stab at the GraphicsConverter stuff.

PS: using previews with current cvs, I get a strange behaviour. In a new
document, make a math inset (like... C-m 1 esc). Then Latex and dvipsk are
called twice. Does anyone else see it? Is it intended? Why?


Thanks!
Alfredo

Re: CVS LyX compile fails

[Kayvan A. Sylvan]

On Tue, Feb 18, 2003 at 12:10:08PM +0100, Jean-Marc Lasgouttes wrote:
  Kayvan == Kayvan A Sylvan [EMAIL PROTECTED] writes:
 
 Kayvan g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../../boost
 Kayvan -I/usr/X11R6/include -O2 -fpermissive -ftemplate-depth-30 -W
 Kayvan -Wall -c -o tex2lyx.o `test -f tex2lyx.C || echo
 Kayvan './'`tex2lyx.C tex2lyx.C:13: sstream: No such file or
 Kayvan directory
 
 I have the same problem with gcc 2.95.2. I tried to fix it, but then
 gcc 3.2 users could not compile. The fix I tried was to replace
 sstream with Lsstream.h, but for some reason this did not work.

Replacing the sstream with Lsstream.h does get past the compile
problem for me. I am compiling now, so I will know if the whole thing
works shortly.

-- 
Kayvan A. Sylvan  | Proud husband of   | Father to my kids:
Sylvan Associates, Inc.   | Laura Isabella Sylvan  | Katherine Yelena (8/8/89)
http://sylvan.com/~kayvan | crown of her husband | Robin Gregory (2/28/92)

Re: lyx-1.3.0 -- serious (gcc) build problems

[John Levon]

On Wed, Feb 19, 2003 at 06:26:28PM +0100, Peter Breitenlohner wrote:

 ../../../lyx-1.3.0/boost/boost/shared_ptr.hpp:203:
template instantiation depth exceeds maximum of 17
 
 It seems that somewhere there is a C++ construct misunderstood by
 gcc-2.95.3, or do you really need more than 17 template instantiation
 levels? If so please note (quoted from gcc-info, gcc-3.2):

We do. The other gcc versions define this already.

 Adding '#define HAVE_STRERROR 1' by hand in the 'src/config.h' generated by
 configure did the job. Please FIX your configure and config.h.in
 accordingly.

It has already  been fixed.

 It seems that the detection of libflimage in configre is broken. Please FIX

It works for me.

john

queue

[Alfredo Braunstein]

Sorry for the dumb question, but why is it that a std::queue doesn't have a
swap() method while list, map, set and vector all have it ?

Alfredo

Re: queue

[Kuba Ober]

On roda 19 luty 2003 01:47 pm, Alfredo Braunstein wrote:
 Sorry for the dumb question, but why is it that a std::queue doesn't have a
 swap() method while list, map, set and vector all have it ?

Maybe because when one is waiting in a line (a queue!), one doesn't like other 
people getting in front of him ;-)

OK, that was a lame excuse, I know ;-)

Cheers, Kuba Ober

Re: kmap quote character doesn't work

[Zvezdan Petkovic]

I repeat my question from the last week since nobody bothered to reply.

Why the quote character doesn't get remaped properly?

See the explanation below.  This has worked in 1.1.6.  It doesn't in
1.2.3 and 1.3.0 (neither xforms nor qt)

On Thu, Feb 13, 2003 at 11:02:52PM -0500, Zvezdan Petkovic wrote:
 \kmap @ \
 \kmap \ \\'{C}
 
 On pressing @, I get  and I should be getting the quotation sign 
 and , and on pressing  I get quotation signs  , instead of
 capital C' (C acute).

-- 
Zvezdan Petkovic [EMAIL PROTECTED]
http://www.cs.wm.edu/~zvezdan/

Re: Graphics Loader

[Angus Leeming]

Alfredo Braunstein wrote:
 PS: using previews with current cvs, I get a strange behaviour. In a new
 document, make a math inset (like... C-m 1 esc). Then Latex and dvipsk are
 called twice. Does anyone else see it? Is it intended? Why?

Yes I see it. No it's not. Don't know.

-- 
Angus

Re: CVS LyX compile fails

[Kayvan A. Sylvan]

On Wed, Feb 19, 2003 at 10:41:35AM -0800, Kayvan A. Sylvan wrote:
 
 Replacing the sstream with Lsstream.h does get past the compile
 problem for me. I am compiling now, so I will know if the whole thing
 works shortly.
 

Yes, this does work. I now have the latest daily CVS tarball and RPMS in
the usual place.

What is the problem with making this change? What happens with gcc-3.2
users?

-- 
Kayvan A. Sylvan  | Proud husband of   | Father to my kids:
Sylvan Associates, Inc.   | Laura Isabella Sylvan  | Katherine Yelena (8/8/89)
http://sylvan.com/~kayvan | crown of her husband | Robin Gregory (2/28/92)

lyx-qt does not work in command line mode

[Loïc]

  Hello!
  I'm using  lyx-qt-1.3.0  (standard).
  I've been trying to execute commands such as
'lyx -e  '  
 and get the error message  (more or less)
 'QFont : must create a QApplication before a QFont'

so  I've backed to lyx-xforms, which works.
 
Bye,
Loïc Teyssier

Re: lyx-qt does not work in command line mode

[Alfredo Braunstein]

Loïc wrote:

   Hello!
   I'm using  lyx-qt-1.3.0  (standard).
   I've been trying to execute commands such as
 'lyx -e  '
  and get the error message  (more or less)
  'QFont : must create a QApplication before a QFont'
 
 so  I've backed to lyx-xforms, which works.
  
 Bye,
 Loïc Teyssier

I think that Dekel Tsur has fixed this in current cvs. 
Regards, Alfredo

Re: lyx-qt does not work in command line mode

[Angus Leeming]

Loïc wrote:
 I'm using  lyx-qt-1.3.0  (standard).
 I've been trying to execute commands such as
 'lyx -e  '
 and get the error message  (more or less)
 'QFont : must create a QApplication before a QFont'
 so  I've backed to lyx-xforms, which works.

Thanks for the report Loïc. This has been fixed already in cvs, both in head 
and in the stable 1.3.x branch.

Regards,
-- 
Angus

Lost for LFUN names...

[Angus Leeming]

The inset dialogs now have this interface in frontends/Dialogs.h:

class Dialogs {
public:
/** name == bibtex, citation etc
data is generated by the Inset::write method, to be read by the
Inset::read method in the frontends.
inset is stored. On a subsequent Apply from the frontends, the
stored inset will be modified. If no inset is stored, then a
new one will be created at the current cursor position.
 */
void show(string const  name, string const  data, InsetBase * inset);
/** name == citation, bibtex etc.
Update the contents of the dialog.
 */
void update(string const  name, string const  data);
///
void Dialogs::hide(string const  name);
/// If the dialog is connected to an inset, then diaconnect it.
void disconnect(string const  name);
///
InsetBase * getOpenInset(string const  name) const;
};

which suggests the corresponding LFUNs
LFUN_DIALOG_SHOW name
LFUN_DIALOG_UPDATE name
LFUN_DIALOG_HIDE name
LFUN_DIALOG_DISCONNECT name
(getOpenInset is used by the core only; it shouldn't have an LFUN.)

All fine and dandy. However, I'm unhappy with the name for this because 
Apply suggests that the inset exists already and, as you can see, 
sometimes we create one, sometimes we modify one. The functionality is 
correct; it's not the frontends business what we do here but I would like a 
more elgant name.

Any suggestions?

case LFUN_CITATION_APPLY:
{
stringstream data(ev.argument);
LyXLex lex(0,0);
lex.setStream(data);
InsetCommandParams params;
params.read(lex);

InsetBase * base =
owner_-getDialogs().getOpenDialog(citation);
InsetCitation * inset = static_castInsetCitation *(base);
if (inset) {
inset-setParams(params);
} else {
inset = new InsetCitation(params);
if (!insertInset(inset)) {
delete inset;
break;
} else {
inset-setLoadingBuffer(bv_-buffer(), false);
}
}
updateInset(inset, true);
}
break;

Also, the dialog can be opened in two different circumstances; to show the 
contents of an existing inset and to enable the user to input the params 
for a new inset. 'LFUN_DIALOG_SHOW name' is unable to differentiate. 
Should I have 'LFUN_DIALOG_SHOW name next/new' to open the next inset 
after the current cursor position/an empty dialog. Or should I have two 
separate LFUNs?

An uninspired,
-- 
Angus

patch for lyx.spec

[Zvezdan Petkovic]

Please, find attached the patch for lyx.spec file used for building
RPMs.  I have introduced two new macros at the top which enable the
creation of new RPM with a different frontend by simply changing their
definition.  For example, to build xforms frontend (since the original
spec file used Qt frontend), one just needs to redefine:

%define frontend xforms
%define frontdep libforms = 1.0

The rest of the spec file stays untouched and everything works great!
I've built xforms and qt rpms without a problem.

I had to enforce the consistent use of macros to achieve this though.
I urge you to accept the patch -- it will make rpm builder's life
much easier.

One thing I have in my personal lyx.spec file that I didn't put here is
the creation of lyx.desktop file, which creates a menu entry for both
Gnome and KDE.  It resides in %{_sysconfdir}/X11/applnk/Applications.
However, I didn't know whether other Linux distributions use the same
place to store .desktop files (on Red Hat it is /etc/X11/applnk), so I
left it out.  If you think it can be useful I can send the patch for
that too.

Best regards,
-- 
Zvezdan Petkovic [EMAIL PROTECTED]
http://www.cs.wm.edu/~zvezdan/

--- lyx.spec.orig   Fri Feb  7 03:58:10 2003
+++ lyx.specWed Feb 19 17:51:37 2003
@@ -1,16 +1,19 @@
+%define frontend qt
+%define frontdep qt = 2.2.1
+
 Summary: A WYSIWYM (What You See Is What You Mean) frontend to LaTeX
 Name: lyx
 Version: 1.3.0
-Release: 1qt
+Release: 1_%{frontend}
 License: see COPYING file
-Group: X11/Editors
-Url: http://www.lyx.org/
+Group: Applications/Publishing
+URL: http://www.lyx.org/
 Packager: Kayvan A. Sylvan [EMAIL PROTECTED]
-Source: ftp://ftp.lyx.org/pub/lyx/stable/lyx-%{PACKAGE_VERSION}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-root
-Icon: lyx.xpm
-Prefix: /usr
-Requires: qt = 2.2.1, pspell, tetex-xdvi, tetex, tetex-latex
+Source: ftp://ftp.lyx.org/pub/lyx/stable/%{name}-%{version}.tar.gz
+BuildRoot: %{_tmppath}/%{name}-%{version}-root
+Icon: %{name}.xpm
+Prefix: %{_prefix}
+Requires: %{frontdep}, pspell, tetex-xdvi, tetex, tetex-latex
 Obsoletes: tetex-lyx
 
 %description
@@ -30,14 +33,15 @@
 With LyX, the author can concentrate on the contents of his writing,
 and let the computer take care of the rest.
 
-This is LyX built with the Qt frontend.
+This is LyX built with the %{frontend} frontend.
+
 %prep
 %setup
 
 %build
 unset LINGUAS || true
-./configure --with-pspell --with-frontend=qt --prefix=%{_prefix} --mandir=%{_mandir} \
-   --bindir=%{_bindir} --datadir=%{_datadir} \
+./configure --with-pspell --with-frontend=%{frontend} --prefix=%{_prefix} \
+   --mandir=%{_mandir} --bindir=%{_bindir} --datadir=%{_datadir} \
--without-warnings --disable-debug --enable-optimization=-O2
 make
 
@@ -53,13 +57,13 @@
 #
 TEXMF=%{_datadir}/texmf
 mkdir -p ${RPM_BUILD_ROOT}${TEXMF}/tex/latex
-mv ${RPM_BUILD_ROOT}%{_datadir}/lyx/tex \
-  ${RPM_BUILD_ROOT}/${TEXMF}/tex/latex/lyx
+mv ${RPM_BUILD_ROOT}%{_datadir}/%{name}/tex \
+  ${RPM_BUILD_ROOT}/${TEXMF}/tex/latex/%{name}
 
 #
 # Miscellaneous files
 #
-cp -a lib/images/lyx.xpm ${RPM_BUILD_ROOT}%{_datadir}/lyx/images/
+cp -a lib/images/%{name}.xpm ${RPM_BUILD_ROOT}%{_datadir}/%{name}/images/
 cp lib/reLyX/README README.reLyX
 
 %clean
@@ -78,14 +82,13 @@
 # Now configure LyX
 #
 echo Configuring LyX for your system...
-cd %{_datadir}/lyx
+cd %{_datadir}/%{name}
 ./configure --srcdir
 
 # Fix reLyX perl program if the prefix is non-standard
 if [ %{_prefix} != /usr ]
 then
-perl -pi -e s!/usr/share/lyx!%{_datadir}/lyx! \
-%{_bindir}/reLyX
+perl -pi -e s!/usr/share/%{name}!%{_datadir}/%{name}! %{_bindir}/reLyX
 fi
 
 %postun

xforms.spec file

[Zvezdan Petkovic]

Please find attached the xforms.spec file.  The changes I did are
described in its changelog.

Best regards,
-- 
Zvezdan Petkovic [EMAIL PROTECTED]
http://www.cs.wm.edu/~zvezdan/

%define libname libforms
%define rel release
%define xdirX11R6

Summary: XForms library
Name: xforms
Version: 1.0
Release: %{rel}
License: LGPL
Group: System/Libraries
Source0: ftp://ncmir.ucsd.edu/pub/xforms/OpenSource/%{name}-%{version}-%{rel}.tgz
Patch: %{name}-%{version}.patch
URL: http://world.std.com/~xforms/
BuildRequires: xpm
BuildRequires: xpm-devel
BuildRoot: %{_tmppath}/%{name}-%{version}-root
Prefix: %{_prefix}

%description
XForms is a GUI toolkit based on Xlib for X Window Systems.  It features
a rich set of objects, such as buttons, sliders, menus, etc., integrated
into an easy and efficient object/event callback execution model that
allows fast and easy construction of X-applications. In addition, the
library is extensible and new objects can easily be created and added to
the library.

%package -n %{libname}
Summary: XForms Library
Group: System/Libraries
Provides: %{name}

%description -n %{libname}
XForms libraries.

%package -n %{libname}-devel
Summary: XForms development header files
Group: System/Libraries
Requires: %{libname}
Provides: %{name}

%description -n %{libname}-devel
XForms header files for development.

%prep
%setup -q -n %{name}-%{version}-%{rel}
%patch -p0

%build
xmkmf -a
make

%install
rm -rf $RPM_BUILD_ROOT
#%makeinstall_std DESTDIR=$RPM_BUILD_ROOT OWNER=$UID GROUP=$GROUPS
make install DESTDIR=$RPM_BUILD_ROOT
make install.man DESTDIR=$RPM_BUILD_ROOT

%post -n %{libname}
/sbin/ldconfig

%postun -n %{libname}
/sbin/ldconfig

%clean
rm -rf $RPM_BUILD_ROOT

%files -n %{libname}
%defattr(-,root,root)
%doc COPYING Copyright Changes 00README README.OS2
%attr(755,root,root) %{_prefix}/%{xdir}/bin/*
%attr(755,root,root) %{_prefix}/%{xdir}/lib/*.so.*

%files -n %{libname}-devel
%defattr(-,root,root)
%attr(755,root,root) %{_prefix}/%{xdir}/lib/*.a
%attr(644,root,root) %{_prefix}/%{xdir}/include/X11/*

%changelog
* Mon Feb 10 2003 Zvezdan Petkovic [EMAIL PROTECTED]
- Commented out makeinstall_std because of use of fg without job control error.
- Fixed the permissions for include files to 644 instead of 755.
- Added Requires to devel package to make it depend on libforms.
- Added xdir macro so that package can be moved easier.
- Used macros consistently.

* Sat Dec 21 2002 Kayvan A. Sylvan [EMAIL PROTECTED] 1.0-release
- Fixed up patch from 1.0-RC5.

* Sun Oct 6 2002 Kayvan A. Sylvan [EMAIL PROTECTED] 1.0-RC5
- Changed /usr/local to /usr/X11R6 and set BuildGL to NO.
- Added %post and %postun section for /sbin/ldconfig.

* Sun Jul 14 2002 Greg Hosler [EMAIL PROTECTED] 1.0-RC4
- Pass DESTDIR to makeinstall_std.

* Thu Jul 11 2002 Peter Galbraith [EMAIL PROTECTED] 1.0-RC4
- Move from libxforms to libforms to match other distros.

* Tue Jul 8 2002 Chris Freeze [EMAIL PROTECTED] 1.0-RC4
- First stab at spec file.

Re: patch for lyx.spec

[Kayvan A. Sylvan]

I am looking over this patch.

I don't think that the default lyx.spec should be qt-enabled. I will
submit a patch which includes most (if not all) of Zvezdan's changes.

---Kayvan
-- 
Kayvan A. Sylvan  | Proud husband of   | Father to my kids:
Sylvan Associates, Inc.   | Laura Isabella Sylvan  | Katherine Yelena (8/8/89)
http://sylvan.com/~kayvan | crown of her husband | Robin Gregory (2/28/92)

Re: de.po

[Juergen Spitzmueller]

Andre Poenitz wrote:
> > Caption -> Legende (not "Überschrift")
>
> "Legende" would confuse me...

But "Überschrift" is definitly wrong. First, it is not always above the 
picture (the contrary is true). Second, I think on "header" when I read 
"Überschrift", and third, the typographic term is "Legende". 
"Bildunterschrift" is the only alternative I can think of, but what is with 
tabulars?

(In general I'm rather reluctant on the idea of translating the LaTeX terms)

Jürgen.

Re: de.po

[Moritz Moeller-Herrmann]

Juergen Spitzmueller wrote:

> Andre Poenitz wrote:
>> > Caption -> Legende (not "Überschrift")

>> "Legende" would confuse me...
 
> But "Überschrift" is definitly wrong. First, it is not always above the
> picture (the contrary is true). Second, I think on "header" when I read
> "Überschrift", and third, the typographic term is "Legende".
> "Bildunterschrift" is the only alternative I can think of, but what is
> with tabulars?

I think »Bezeichnung« would be a good term. Unterschrift suggests, that it 
has to be placed below the table or image.

-- 
Moritz Moeller-Herrmann [EMAIL PROTECTED] wiss. Mitarbeiter, IMGB
La loi, dans un grand souci d'égalité, interdit aux riches comme aux
pauvres de coucher sous les ponts, de mendier dans les rues et de voler
du pain. 
(ANATOLE FRANCE)
 

Re: de.po

[Andre Poenitz]

On Wed, Feb 19, 2003 at 09:07:44AM +0100, Juergen Spitzmueller wrote:
> But "Überschrift" is definitly wrong. First, it is not always above the 
> picture (the contrary is true). Second, I think on "header" when I read 
> "Überschrift", and third, the typographic term is "Legende". 
> "Bildunterschrift" is the only alternative I can think of, but what is with 
> tabulars?

"Beschreibung"/"Beschriftung"?

I'd even accept "Bildunterschrift" for tabulars, even if it is formally not
correct, whereas "Legende" might be formally correct but pretty unusual.

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: de.po

[Juergen Spitzmueller]

Andre Poenitz wrote:
> "Beschreibung"/"Beschriftung"?

Beschriftung is not bad actually. But I let Michael decide.

Jürgen.

www/cvs down?

[Andre Poenitz]

Can't connect. The machine seems to be running, though.

Andre'

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

Graphics Loader

[Alfredo Braunstein]

I'm fiddling a little with the graphics loader, and I started to implement a
pseudo threaded version of it (patch attached).

It works as follows: there is this LoaderQueue class (I think every
BufferView should have one, right now is simply a global class), which
implements a queue with a twist:

1) Elements are unique
2) Reinserting an element reprioritizes it to the top

I.e. it sort of works like the 'touch' command.

Right now it's implemented as a queue + a set, so it's O(ln n) for the
'first time insert' case, and O(n) for the 'already have it' case.
I plan to make it O(ln n) always.

His loadNext method should run in an independent thread, right now it runs
with a timer that comes back every .1 seconds. I've put a minimal locking
mecanism. Should be trivial to convert to a real thread once boost.threads
is installed on the LyX tree.

This LoaderQueue is called from Loader::startLoading, i.e. from there we
'touch' the graphic. Nothing is really loaded on screen yet. The real
loading is done on the loadNext method (the 'threaded' one).

It works pretty nicely I think (except for the O(n) thingie and some other
details). And the patch is very minimal.

I know that the coding style is broken, please correct me without mercy.
Anyway of course it's not to be applied, It's only a proof of concept.

I have some questions about when these Loadings are called, so if someone
thinks that this is not a complete trash then I go on and ask them.

Please be nice.

Regards, Alfredo

? patch.diff
Index: GraphicsLoader.C
===
RCS file: /cvs/lyx/lyx-devel/src/graphics/GraphicsLoader.C,v
retrieving revision 1.12
diff -u -r1.12 GraphicsLoader.C
--- GraphicsLoader.C	2003/02/13 16:53:00	1.12
+++ GraphicsLoader.C	2003/02/19 08:11:58
@@ -28,9 +28,60 @@
 #include 
 
 #include 
+#include 
 
 namespace grfx {
 
+class LoaderQueue {
+public:
+	LoaderQueue():timer( 100 , Timeout::ONETIME )
+	{
+		timer.timeout.connect( boost::bind( ::loadNext, this));
+		locked = false;
+		timer.start();
+	}
+	void touch(Cache::ItemPtr item) {
+
+		if(locked)
+			return;
+
+		locked = true;
+
+		if( !cache_set_.insert(item).second ) {
+
+			list::iterator 
+it = cache_queue_.begin();
+			list::iterator 
+end = cache_queue_.end();
+
+			it = std::find( it, end, item );
+			cache_queue_.erase( it );
+		} 
+		cache_queue_.push_front( item );
+		locked = false;
+	}
+private:
+	bool locked;
+	std::list cache_queue_;
+	std::set cache_set_;
+	Timeout timer;
+	void loadNext() {
+		if(locked)
+			return;
+		locked = true;
+		int counter = 10;
+		while (cache_queue_.size() && --counter) {
+			cout << cache_queue_.size()
+			 << " items in the queue" << endl; 
+			cache_queue_.front()->startLoading();
+			cache_set_.erase(cache_queue_.front());
+			cache_queue_.pop_front();
+		}
+		locked = false;
+		timer.start();
+	};
+} LQ;
+
 struct Loader::Impl : boost::signals::trackable {
 	///
 	Impl(Params const &);
@@ -66,8 +117,6 @@
 	///
 	Params params_;
 
-	///
-	Timeout timer;
 	// Multiple Insets can share the same image
 	typedef std::list InsetList;
 	///
@@ -196,10 +245,8 @@
 
 
 Loader::Impl::Impl(Params const & params)
-	: status_(WaitingToLoad), params_(params),
-	  timer(2000, Timeout::ONETIME)
+	: status_(WaitingToLoad), params_(params)
 {
-	timer.timeout.connect(boost::bind(::checkedLoading, this));
 }
 
 
@@ -266,7 +313,6 @@
 	signal_();
 }
 
-
 void Loader::Impl::createPixmap()
 {
 	if (!cached_item_.get() ||
@@ -293,7 +339,7 @@
 
 void Loader::Impl::startLoading(Inset const & inset, BufferView const & bv)
 {
-	if (status_ != WaitingToLoad || timer.running())
+	if (status_ != WaitingToLoad)
 		return;
 
 	InsetList::const_iterator it  = insets.begin();
@@ -302,8 +348,7 @@
 	if (it == end)
 		insets.push_back();
 	view = bv.owner()->view();
-
-	timer.start();
+	LQ.touch(cached_item_);
 }
 
 
Index: GraphicsSupport.C
===
RCS file: /cvs/lyx/lyx-devel/src/graphics/GraphicsSupport.C,v
retrieving revision 1.7
diff -u -r1.7 GraphicsSupport.C
--- GraphicsSupport.C	2003/02/13 16:53:00	1.7
+++ GraphicsSupport.C	2003/02/19 08:11:58
@@ -33,7 +33,7 @@
 	VPList vps;
 	Row const * last_row = 0;
 
-	for (int height = 0; row && height < bv_height; row = row->next()) {
+	for (int height = 0; row && height < 2 *bv_height; row = row->next()) {
 		height += row->height();
 
 		if (vps.empty() || vps.back().par != row->par()) {
Index: PreviewImage.C
===
RCS file: /cvs/lyx/lyx-devel/src/graphics/PreviewImage.C,v
retrieving revision 1.11
diff -u -r1.11 PreviewImage.C
--- PreviewImage.C	2003/02/13 16:53:00	1.11
+++ PreviewImage.C	2003/02/19 08:11:58
@@ -33,7 +33,6 @@
 	Image const * image(Inset const &, BufferView const &);
 	///
 	void statusChanged();
-
 	///
 	PreviewImage const & parent_;
 	///

Re: Graphics Loader

[Andre Poenitz]

On Wed, Feb 19, 2003 at 09:43:09AM +0100, Alfredo Braunstein wrote:
> Right now it's implemented as a queue + a set, so it's O(ln n) for the
> 'first time insert' case, and O(n) for the 'already have it' case.
> I plan to make it O(ln n) always.

Good idea, but we do pretty expensive things in othe places, so I don't
think this hurts.

> I know that the coding style is broken, please correct me without mercy.
> [...] Please be nice.

Hm?


+class LoaderQueue {
+public:
+   LoaderQueue():timer( 100 , Timeout::ONETIME )
+   {
+   timer.timeout.connect( boost::bind( ::loadNext, 
this));
+   locked = false;
+   timer.start();
+   }

LoaderQueue() : timer(100, Timeout::ONETIME), locked(false)
{
timer.timeout.connect(boost::bind(::loadNext, this));
timer.start();
}

+   void touch(Cache::ItemPtr item) {
+
+   if(locked)

if (locked)
  [etc]

+   timer.start();
+   };
+} LQ;

};

LoaderQueue LQ;



@@ -266,7 +313,6 @@
signal_();
 }
 
-
 void Loader::Impl::createPixmap()

Two empty lines are pretty common in LyX sources.


iff -u -r1.11 PreviewImage.C
--- PreviewImage.C  2003/02/13 16:53:00 1.11
+++ PreviewImage.C  2003/02/19 08:11:58
@@ -33,7 +33,6 @@
Image const * image(Inset const &, BufferView const &);
///
void statusChanged();
-
///
PreviewImage const & parent_;
///

As is separating member functions from member variables or blocks of them.

I have not checked for functionality, I cannot connect to cvs right now,
but it does not look bad.

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: a random thought on UI in general

[Jean-Marc Lasgouttes]

> "Christian" == Christian Ridderström <[EMAIL PROTECTED]> writes:

Christian> Actually, Document->Layout->Preamble could be replaced by
Christian> an external inset, that either connects to lyx and modifies
Christian> the document preamble, or by returning latex that is
Christian> inserted in the document preamble.

If the problem you are trying to solve is how to have child documents
be typeset like when they are part of the master, it seems that you
are trying to find an overly complicated solution. Rather than add
hooks that nobody will use except for some wicked applications, it
might be better to think about the real problem (i.e. devise a really
useful solution, not just give people enough rope to hang themselves)
:)

JMarc

problems with relyx and wvCleanLatex

[Karsten Heymann]

Hello,

(could someone please tell me how to subscribe. The www.lyx.org seems to
be unreachable (again... -- aren't there any mirrors?) so I don't know how to 
subscribe. Thanks.)

I'm using LyX for some time now (it's really a time saver!). While
preparing to promote LyX at work (university), I came about some
problems with the LaTeX (MS Word) import of (re)LyX (wvCleanLatex). I'll
list them here to find out wether they are well-known
bugs^H^H^H^Hfeatures or wether I should file a bug report. I'm using
wvWare 0.7.4 and reLyX from 1.3.0.

1. what LaTeX code can be used so that reLyX produces the 'quote
glq/grq'   insets? wvWare produces \quotedblbase{} and ''. '' is mapped
to 'quote elq' insets which is quite ok, but ERT:\quotedblbase{} looks
very ugly (and it's quite common in german texts). I've tried \glqq  as
well, but (as far as I can read the reLyX code), there's no way to 
reach 'quote glq/grq'. Am I right?  (and while i'm at that topic: why
does LyX use ",," and "''" to export  'quote glq/grq'? "\glqq" resp.
"\grqq" would seem the right thing to  me.)

2. Should reLyX ignore 1-cell-multicolumns? wvCleanLatex makes every   
cell of a tabular (I've patched it to produce tabular instead of  
longtable - maybe I did something wrong during that) a multicolumn  
which makes editing annoying (esp. adding frames). Most probably a  
wvWare bug, but could reLyX handle it?

3. reLyX improperly parses $a$$b$ (which is $ab$ but reLyX makes $a\[b$
from it). Of course noone sensible would write that, but it's correct
LaTeX-code (at least LaTeX compiles it without problems) and should
stay that. wvCleanLatex creates such code.

4. reLyX doesn't handle \newpage. Almost never needed in LyX, but maybe reLyX could 
make a LyX-Pagebreak from that.

That's all regarding reLyX (so far). There's certainly a lot more but I'll wait until 
I'm subscribed :) 

I'd be happy to help out with solving these problems (I know a bit perl, quite a bit 
python but unfortunately nearly no c++) but would need some pointers how help would be 
helpfull.

Yours,

Karsten

PS: Has someone built debian (woody) packages with qt-support from 1.3.0?

PPS: My mom wrote her final exam with LyX a year ago. And it looks  great!

Re: problems with relyx and wvCleanLatex

[Andre Poenitz]

On Wed, Feb 19, 2003 at 10:23:55AM +0100, Karsten Heymann wrote:
> (could someone please tell me how to subscribe. The www.lyx.org seems
> to be unreachable (again... -- aren't there any mirrors?) so I don't know
> how to subscribe. Thanks.)

List-Help: 

> I'm using LyX for some time now (it's really a time saver!). While
> preparing to promote LyX at work (university), I came about some problems
> with the LaTeX (MS Word) import of (re)LyX (wvCleanLatex). I'll list them
> here to find out wether they are well-known bugs^H^H^H^Hfeatures or
> wether I should file a bug report. I'm using wvWare 0.7.4 and reLyX from
> 1.3.0.

Send me please an example .tex directly and I'll try to make tex2lyx work
on it.

> 3. reLyX improperly parses $a$$b$ (which is $ab$ but reLyX makes $a\[b$
> from it). Of course noone sensible would write that, but it's correct
> LaTeX-code (at least LaTeX compiles it without problems) and should stay
> that. wvCleanLatex creates such code.

This is a known reLyX bug.

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: a random thought on UI in general

[Jean-Marc Lasgouttes]

> "Christian" == Christian Ridderström <[EMAIL PROTECTED]> writes:

Christian> To conclude, I think that for the "medium-level" user, it'd
Christian> be enough to specify the name of another .lyx-file in a
Christian> dialog and choose some pre-defined sets of settings that
Christian> he'd like imported.

Or we could chose ourselves what settings should be taken from master
doc, and which ones should not. 

JMarc

Re: Graphics Loader

[Alfredo Braunstein]

Andre Poenitz wrote:

> On Wed, Feb 19, 2003 at 09:43:09AM +0100, Alfredo Braunstein wrote:
>> Right now it's implemented as a queue + a set, so it's O(ln n) for the
>> 'first time insert' case, and O(n) for the 'already have it' case.
>> I plan to make it O(ln n) always.
> 
> Good idea, but we do pretty expensive things in othe places, so I don't
> think this hurts.

I think it does now, because all graphics all added to the queue at startup
time, so you get a short freeze while they are at it (specially with
previews). Another option would be to make the adding part also threaded.
That's it: on touch() to add it to some tmp queue (without checkin) and
return inmediately, and then on loadNext() load this tmp queue into the
good one before proceding.

> 
>> I know that the coding style is broken, please correct me without mercy.
>> [...] Please be nice.

I known. It's called sado-masochim. Thanks for the corrections.

> I have not checked for functionality, I cannot connect to cvs right now,
> but it does not look bad.
> 
> Andre'
> 

Thanks, Alfredo

Changing article to report/book, math+\text{} problem

[Karsten Heymann]

Hi,

1. are there plans to support changing chapter<->section when changing the 
documentclass from article to report/book or back? It's a bit annoying to change all 
sections when changing from article to report. Wouldn't that be nice?

2. (1.3.0:) when I type in the following in math mode:
  \textH_xy
  then xy is roman too although  should move out of the \text
  inset. I  have to do
  \textHX_xy
  and delete the "X" afterwards instead. 

Yours,

Karsten

Update pl.po

[Tomasz Luczak]

Hello

I enclose updated pl.po file

Best Regards

Tomasz

--
   Tomasz Luczak
-| TECHNODAT Sp. z o.o. | +48 32 2382337
 http://212.106.135.195/~tlu | PL 44-100 Gliwice| +48 32 3314484
 http://www.technodat.com.pl | ul. Kosciuszki 1c| +48 602 524713



pl.po.zip
Description: Zip compressed data

Re: Graphics Loader

[Angus Leeming]

Alfredo Braunstein wrote:

> I'm fiddling a little with the graphics loader, and I started to
> implement a pseudo threaded version of it (patch attached).
> 
> It works as follows: there is this LoaderQueue class (I think every
> BufferView should have one, right now is simply a global class),
> which implements a queue with a twist:
> 
> 1) Elements are unique
> 2) Reinserting an element reprioritizes it to the top
> 
> I.e. it sort of works like the 'touch' command.
> 
> Right now it's implemented as a queue + a set, so it's O(ln n) for
> the 'first time insert' case, and O(n) for the 'already have it'
> case. I plan to make it O(ln n) always.
> 
> His loadNext method should run in an independent thread, right now
> it runs with a timer that comes back every .1 seconds. I've put a
> minimal locking mecanism. Should be trivial to convert to a real
> thread once boost.threads is installed on the LyX tree.
> 
> This LoaderQueue is called from Loader::startLoading, i.e. from
> there we 'touch' the graphic. Nothing is really loaded on screen
> yet. The real loading is done on the loadNext method (the 'threaded'
> one).
> 
> It works pretty nicely I think (except for the O(n) thingie and some
> other details). And the patch is very minimal.
> 
> I know that the coding style is broken, please correct me without
> mercy. Anyway of course it's not to be applied, It's only a proof of
> concept.
> 
> I have some questions about when these Loadings are called, so if
> someone thinks that this is not a complete trash then I go on and
> ask them.

I can answer that. Three classes are interested in graphics. 
insets/insetgraphics.C together with mathed/formula.C and 
insets/insetinclude.C for the previews. These latter two have 
instances of a class PreviewImpl that derives from  
grfx::PreviewedInset. InsetGraphics has an instance of a Cache class.

In all cases the loading of the image is triggered by the Inset's 
draw() method. Eg InsetGraphics::draw has 
   if (cache_->loader.status() == grfx::WaitingToLoad)
cache_->loader.startLoading(*this, *bv);

> Please be nice.

We're always nice ;-) Seriously, this is very clever of you and 
surprisingly non-invasive. Where/who would call loadNext?

Did you find the graphics code understandable or did you find it to 
be a convoluted mess? What could be done to improve the architecture?

I have a question/suggestion for you myself. (Thinking out loud 
really.) Do you think it would be easy to split the "conversion to 
loadable format" stuff out of grfx::CacheItem?

At the moment we have one conversion process for each file to 
convert, so several processes run in parallel (with possibly nasty 
consequences on the system resources). It would be nice to gather 
them together into a single script and launch that. What do you think?

-- 
Angus

Re: de.po

[Michael Schmitt]

Hi,

I am not subscribed to the mailing list right now but I noticed your
discussion when browsing through the mail archive.

"Beschreibung" is OK for me as long as it is used consistently (IMHO
consistency is more important than anything else). Currently, I have no
time to work on de.po. The situation will change in about one or two
weeks when my PhD thesis is finally finished (sigh!). Please send all
complaints, suggestions, etc. to me directly. I will collect them and
provide a new de.po as soon as possible.

Michael

Re: problems with relyx and wvCleanLatex

[Angus Leeming]

Karsten Heymann wrote:

> Hello,

Hello Karsten.

reLyX may "someday soon" be retired in favour of tex2lyx, André's new 
baby. It is still very new indeed but has the advantage of using a 
proper TeX parser rather than regex magic acting as a psuedo tex 
parser. I see that you know perl and python rather than c++ (tex2lyx 
is written in c++) but would strongly suggest that you at least have 
a look at tex2lyx. It is unbelievably simple in comparison to reLyX.

In the meantime, reLyX is what we have and we would indeed like to 
get it to support more of the subset of LaTeX known to LyX.

> 1. what LaTeX code can be used so that reLyX produces the 'quote
> glq/grq'   insets? wvWare produces \quotedblbase{} and ''. '' is
> mapped to 'quote elq' insets which is quite ok, but
> ERT:\quotedblbase{} looks
> very ugly (and it's quite common in german texts). I've tried \glqq 
> as well, but (as far as I can read the reLyX code), there's no way
> to
> reach 'quote glq/grq'. Am I right?  (and while i'm at that topic:
> why
> does LyX use ",," and "''" to export  'quote glq/grq'? "\glqq" resp.
> "\grqq" would seem the right thing to  me.)

reLyX has a file 'syntax.default' that tells it what to expect with 
different macros. For example \cite[]{} tells reLyX to expect one 
optional and one mandatory argument with a \cite macro. I see that 
syntax.default has
\quotedblbase
already. I also see that
$ grep quotedblbase BasicLyX.pm
so nobody has actually told reLyX now to go from the LaTeX to the LyX.

You'll find (in BasicLyX.pm) that the conversion of LaTeX to LyX is 
handled by 'sub basic_lyx' which is basically just a big switch of 
LaTeX commands. Feel free to shout for help ;-)

> 2. Should reLyX ignore 1-cell-multicolumns? wvCleanLatex makes every
> cell of a tabular (I've patched it to produce tabular instead of
> longtable - maybe I did something wrong during that) a multicolumn
> which makes editing annoying (esp. adding frames). Most probably a
> wvWare bug, but could reLyX handle it?

You mean should reLyX turn valid LaTeX into different valid LaTeX 
before creating a LyX tabular? No.

> 3. reLyX improperly parses $a$$b$
As André has said: known bug. Probably impossible to squash with the 
TeX.pm TeX parser.

> 4. reLyX doesn't handle \newpage. Almost never needed in LyX, but
> maybe reLyX could make a LyX-Pagebreak from that.

Add something to the basic_lyx switch.
elsif ($name eq '\newpage') {
...
}

I see that \newpage _is_ handled within tabulars.

> That's all regarding reLyX (so far). There's certainly a lot more
> but I'll wait until I'm subscribed :)

I look forward to it.

> I'd be happy to help out with solving these problems (I know a bit
> perl, quite a bit python but unfortunately nearly no c++) but would
> need some pointers how help would be helpfull.

I think that teaching reLyX how to LyX-ify certain LaTeX tokens is 
pretty easy. Squashing real bugs in the TeX tokeniser is pretty hard. 
If you would like to learn a little c++ have a look at the "muxh, muc 
cleaner" tex2lyx code. 

-- 
Angus

Re: Changing article to report/book, math+\text{} problem

[Angus Leeming]

Karsten Heymann wrote:

> Hi,
> 
> 1. are there plans to support changing chapter<->section when
> changing the documentclass from article to report/book or back? It's
> a bit annoying to change all sections when changing from article
> to report. Wouldn't that be nice?

I think it is non-trivial. How do you decide in a general way what to 
map the different environments to?

In your particular case, it would be easier to run the LyX file 
through a sed script to do the conversion.

Something like
$ sed -f article2book.sed yourarticle.lyx > yourbook.lyx
where
$ cat article2book.sed
s/^\(\\textclass\) article$/\1 book/
s/^\(\\layout\) Section$/\1 Chapter/


-- 
Angus

Re: Graphics Loader

[Alfredo Braunstein]

Angus Leeming wrote:

Hi Angus, thanks for the answers.

> I can answer that. Three classes are interested in graphics.
> insets/insetgraphics.C together with mathed/formula.C and
> insets/insetinclude.C for the previews. These latter two have
> instances of a class PreviewImpl that derives from
> grfx::PreviewedInset. InsetGraphics has an instance of a Cache class.
> 
> In all cases the loading of the image is triggered by the Inset's
> draw() method. Eg InsetGraphics::draw has
>if (cache_->loader.status() == grfx::WaitingToLoad)
> cache_->loader.startLoading(*this, *bv);

I see. But draw() is called for all insets at startup time, right? All the
document is drawn at startup, even if it's not visible.
I'm asking this because I think the optimum would be to 'refresh' i.e.
touch() all WaitingToLoad grafics near the cursor (up and down) at every
time. Or something like that.

> We're always nice ;-) Seriously, this is very clever of you and

Im blushing.

> surprisingly non-invasive. Where/who would call loadNext?

loadNext is the threaded part, it's called automatically every .1 seconds.

> Did you find the graphics code understandable or did you find it to
> be a convoluted mess? What could be done to improve the architecture?

I think it's nice. Of course it's not simple, but neither it's task is.
I still have some problems understanding some parts. I will get to specific
questions soon. You are asking _me_ hoy to improve it? I'm blushing again.
Never programmed a graphics loading mechanism before. Let me get used to
it, and I will tell you.
What are the problems in it, apart from the 'convoluted' code? (I think part
of the convolution will go if we make it threaded... this 2 secs call back
for instance)

> I have a question/suggestion for you myself. (Thinking out loud
> really.) Do you think it would be easy to split the "conversion to
> loadable format" stuff out of grfx::CacheItem?
> 
> At the moment we have one conversion process for each file to
> convert, so several processes run in parallel (with possibly nasty
> consequences on the system resources). It would be nice to gather
> them together into a single script and launch that. What do you think?
> 

I think it can be easily implemented with the 'threaded' paradigm as the
image loading (even maybe together?). That's it: you request some
conversion, it is added to some queue, and done when time comes,
sequentially (by the threaded part). What do you think?

Thank Angus. 

Bye, Alfredo

Re: Changing article to report/book, math+\text{} problem

[Dekel Tsur]

On Wed, Feb 19, 2003 at 10:45:24AM +0100, Karsten Heymann wrote:
> 2. (1.3.0:) when I type in the following in math mode:
>   \textH_xy
>   then xy is roman too although  should move out of the \text
>   inset. I  have to do

I can't see this.
\textH_xy works OK for me (with 1.3.1cvs).

Re: Graphics Loader

[Angus Leeming]

Alfredo Braunstein wrote:
>> In all cases the loading of the image is triggered by the Inset's
>> draw() method. Eg InsetGraphics::draw has
>>if (cache_->loader.status() == grfx::WaitingToLoad)
>> cache_->loader.startLoading(*this, *bv);
> 
> I see. But draw() is called for all insets at startup time, right?

Yes. That's why we have to have this "see if the inset is visible" 
check (uses GraphicsSupport's isInsetVisible.)

The two second pause between the call to Inset::draw and 
Loader::Impl::checkedLoading() allows the user to scroll past 
graphics insets without triggering a load unnecessarily. Only when 
the thing is visible for a finite period is loading started.
 
> All the document is drawn at startup, even if it's not visible.
> I'm asking this because I think the optimum would be to 'refresh'
> i.e. touch() all WaitingToLoad grafics near the cursor (up and down)
> at every time. Or something like that.

That's essentially what we do now, although your terminology is a 
little different.

>> Where/who would call loadNext?
> loadNext is the threaded part, it's called automatically every .1
> seconds.

Oh yes. I see. It might be nice to have an explicit 
LoaderQueue::startLoader so that the thing is only started with the 
first attempt to 'touch' something.

>> Did you find the graphics code understandable or did you find it to
>> be a convoluted mess? What could be done to improve the
>> architecture?
> 
> I think it's nice. Of course it's not simple, but neither it's task
> is. I still have some problems understanding some parts. I will get
> to specific questions soon. You are asking _me_ hoy to improve it?
> I'm blushing again. Never programmed a graphics loading mechanism
> before. 

Me neither. Hence the desire for feedback.

>> I have a question/suggestion for you myself. (Thinking out loud
>> really.) Do you think it would be easy to split the "conversion to
>> loadable format" stuff out of grfx::CacheItem?
>> 
>> At the moment we have one conversion process for each file to
>> convert, so several processes run in parallel (with possibly nasty
>> consequences on the system resources). It would be nice to gather
>> them together into a single script and launch that. What do you
>> think?
>> 
> I think it can be easily implemented with the 'threaded' paradigm as
> the image loading (even maybe together?). That's it: you request
> some conversion, it is added to some queue, and done when time
> comes, sequentially (by the threaded part). What do you think?

I think that the GraphicsConverter generates a shell script wrapper 
for each conversion process. It also executes these scripts. I think 
that we could change things only slightly by getting it to create the 
scripts as it does now and putting the execute command on a queue to 
be executed sequentially.

You see? You've forced me to think and the answer just 'came'. Thank 
you.

> Thank Angus.
> Bye, Alfredo

Tara!

-- 
Angus

Re: Sample

[big]

Attached file:

Re: www/cvs down?

[Angus Leeming]

Andre Poenitz wrote:
> Can't connect. The machine seems to be running, though.

www.lyx.org, www.devel.lyx.org, cvs.lyx.org

are all aliases for baywatch.lyx.org which does indeed appear to be 
broken.

$ ssh [EMAIL PROTECTED]
ssh: connect to host baywatch.lyx.org port 22: Connection refused

Perhaps it went down and the various daemons do not get started on 
boot up?

-- 
Angus

Re: Graphics Loader

[Alfredo Braunstein]

Angus Leeming wrote:

>> I see. But draw() is called for all insets at startup time, right?
> 
> Yes. That's why we have to have this "see if the inset is visible"
> check (uses GraphicsSupport's isInsetVisible.)
> 
> The two second pause between the call to Inset::draw and
> Loader::Impl::checkedLoading() allows the user to scroll past
> graphics insets without triggering a load unnecessarily. Only when
> the thing is visible for a finite period is loading started.

I think this two will be obsoleted if we do it in my patch's way. Have you
tried it? If you scroll fast, then all insets not loaded yet will go down
the queue, replaced by newly touched ones. And you don't need to check for
visibility. I think the code becomes a little less convoluted indeed.

>> All the document is drawn at startup, even if it's not visible.
>> I'm asking this because I think the optimum would be to 'refresh'
>> i.e. touch() all WaitingToLoad grafics near the cursor (up and down)
>> at every time. Or something like that.

> 
> That's essentially what we do now, although your terminology is a
> little different.
> 

Sorry , failed completely to explain myself. What I wanted to say is: can we 

1) Make avery redraw to redraw more than one screen (say 1 fullscreen up and
down) to refresh.
2) Maybe call a redraw at startup after the full draw (so to 'touch' the
first screenfull of insets)

> Oh yes. I see. It might be nice to have an explicit
> LoaderQueue::startLoader so that the thing is only started with the
> first attempt to 'touch' something.

Ok, understood your previous question. I don't want to introduce overhead in
'touch' (because it's non-threaded), but of course a startLoader would be
nice. Does this LoaderQueue belong to a bufferview? If it is so, then I
think it's not so wrong to start on the constructor.

> Me neither. Hence the desire for feedback.

But you have done it, big time. You _are_ a wizard. 

> I think that the GraphicsConverter generates a shell script wrapper
> for each conversion process. It also executes these scripts. I think
> that we could change things only slightly by getting it to create the
> scripts as it does now and putting the execute command on a queue to
> be executed sequentially.
> 
> You see? You've forced me to think and the answer just 'came'. Thank
> you.

You are welcomed! Obviously you are good at it. But without threads (or
pseudo thread) how will you execute sequentially the queue?

> 
>> Thank Angus.
>> Bye, Alfredo
> 
> Tara!
> 

What/who's Tara?

Thanks again, Alfredo 

Re: Changing article to report/book, math+\text{} problem

[Karsten Heymann]

On Wed, 19 Feb 2003 13:23:51 +0200
Dekel Tsur <[EMAIL PROTECTED]> wrote:

That should have gone to the list...

> On Wed, Feb 19, 2003 at 10:45:24AM +0100, Karsten Heymann wrote:

Hi Dekel.

> > 2. (1.3.0:) when I type in the following in math mode:
> >   \textH_xy
> >   then xy is roman too although  should move out of the \text
> >   inset. I  have to do
> 
> I can't see this.
> \textH_xy works OK for me (with 1.3.1cvs).

I'm using 1.3.0. So it must have been fixed since then. 
Where's 1.3.1? :)

yours,

Karsten

Re: problems with relyx and wvCleanLatex

[Karsten Heymann]

On Wed, 19 Feb 2003 10:59:34 +
Angus Leeming <[EMAIL PROTECTED]> wrote:

> Hello Karsten.

Hello,
 
> reLyX may "someday soon" be retired in favour of tex2lyx, André's new 
> baby. It is still very new indeed but has the advantage of using a 
> proper TeX parser rather than regex magic acting as a psuedo tex 
> parser. I see that you know perl and python rather than c++ (tex2lyx 
> is written in c++) but would strongly suggest that you at least have 
> a look at tex2lyx. It is unbelievably simple in comparison to reLyX.

I had to write a parser (for a simple raytracer language) in java (with
help of jlex+cup) some time ago, so maybe I understand a bit.

> In the meantime, reLyX is what we have and we would indeed like to 
> get it to support more of the subset of LaTeX known to LyX.
> 
> > 1. what LaTeX code can be used so that reLyX produces the 'quote
> > glq/grq'   insets? wvWare produces \quotedblbase{} and ''. '' is
> > mapped to 'quote elq' insets which is quite ok, but
> > ERT:\quotedblbase{} looks very ugly (and it's quite common in german
> > texts). I've tried \glqq as well, but (as far as I can read the
> > reLyX code), there's no way to reach 'quote glq/grq'. Am I right? 
> > (and while i'm at that topic: why does LyX use ",," and "''" to
> > export  'quote glq/grq'? "\glqq" resp."\grqq" would seem the right
> > thing to  me.)
> 
> reLyX has a file 'syntax.default' that tells it what to expect with 
> different macros. For example \cite[]{} tells reLyX to expect one 
> optional and one mandatory argument with a \cite macro. I see that 
> syntax.default has
> \quotedblbase
> already. I also see that
> $ grep quotedblbase BasicLyX.pm
> so nobody has actually told reLyX now to go from the LaTeX to the LyX.
> 
> You'll find (in BasicLyX.pm) that the conversion of LaTeX to LyX is 
> handled by 'sub basic_lyx' which is basically just a big switch of 
> LaTeX commands. Feel free to shout for help ;-)

That's a helpfull reply. I'll have a deeper look at it soon.
 
> > 2. Should reLyX ignore 1-cell-multicolumns? wvCleanLatex makes every
> > cell of a tabular (I've patched it to produce tabular instead of
> > longtable - maybe I did something wrong during that) a multicolumn
> > which makes editing annoying (esp. adding frames). Most probably a
> > wvWare bug, but could reLyX handle it?
> 
> You mean should reLyX turn valid LaTeX into different valid LaTeX 
> before creating a LyX tabular? No.

It seems I'll have to write an additional sanityzer CleanLatex2reLyXLatex to cope with 
that.

> > 3. reLyX improperly parses $a$$b$
> As André has said: known bug. Probably impossible to squash with the 
> TeX.pm TeX parser.

That's a big point for tex2lyx. It took me a day propably to find that out.

> > 4. reLyX doesn't handle \newpage. Almost never needed in LyX, but
> > maybe reLyX could make a LyX-Pagebreak from that.
> 
> Add something to the basic_lyx switch.
> elsif ($name eq '\newpage') {
> ...
> }

I'll try it out.

> I see that \newpage _is_ handled within tabulars.

Why on earth should that happen?? I don't understand it...

> > That's all regarding reLyX (so far). There's certainly a lot more
> > but I'll wait until I'm subscribed :)
> 
> I look forward to it.

Ok, here I am :). I'll wait with further bugreports until I had the time to look into 
tex2lyx. I guess it's time to learn c++ (yet another language...)
 
> > I'd be happy to help out with solving these problems (I know a bit
> > perl, quite a bit python but unfortunately nearly no c++) but would
> > need some pointers how help would be helpfull.
> 
> I think that teaching reLyX how to LyX-ify certain LaTeX tokens is 
> pretty easy. Squashing real bugs in the TeX tokeniser is pretty hard. 
> If you would like to learn a little c++ have a look at the "muxh, muc 
> cleaner" tex2lyx code. 

I think I'll try to fix the obvious stuff within reLyX and write a litte script to 
handle the stuff reLyX can't.

So far now,

Karsten

Re: Changing article to report/book, math+\text{} problem

[Karsten Heymann]

On Wed, 19 Feb 2003 11:11:06 +
Angus Leeming <[EMAIL PROTECTED]> wrote:

> Karsten Heymann wrote:

Hi Angus,

> > 1. are there plans to support changing chapter<->section when
> > changing the documentclass from article to report/book or back? It's
> > a bit annoying to change all sections when changing from article
> > to report. Wouldn't that be nice?
> 
> I think it is non-trivial. How do you decide in a general way what to 
> map the different environments to?

You're right. In this case it would be nescesary for lyx to know what the 
top-level-headings would be and so on. Well -- as longer as I think about it the more 
complicated it becomes. Maybe it would be better to improve the simple drop-down list 
and the button bar a bit. But I won't do that.

> In your particular case, it would be easier to run the LyX file 
> through a sed script to do the conversion.

I know how to do that for myself (but thanks for the script nevertheless). I was 
thinking about my mom/my girlfriend (who both use lyx happily). But it's probably not 
important enough.

yours,

Karsten

Re: problems with relyx and wvCleanLatex

[Andre Poenitz]

On Wed, Feb 19, 2003 at 01:21:59PM +0100, Karsten Heymann wrote:
> It seems I'll have to write an additional sanityzer
> CleanLatex2reLyXLatex to cope with that.

I'd urge you to have a look at tex2lyx first.

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: problems with relyx and wvCleanLatex

[Jean-Marc Lasgouttes]

> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:

Andre> On Wed, Feb 19, 2003 at 01:21:59PM +0100, Karsten Heymann
Andre> wrote:
>> It seems I'll have to write an additional sanityzer
>> CleanLatex2reLyXLatex to cope with that.

Andre> I'd urge you to have a look at tex2lyx first.

This would not chnage the original problem, which is to know whether
1-column multicolumns should be changed to normal columns. 

The best bet is probably to patch to wvWare.

JMarc