date:20031029

On Tue, Oct 28, 2003 at 07:50:14PM +0100, Lars Gullik Bjønnes wrote:
> 
> 
> This replaces dispatch_result enum with a real type, forward declared
> when possible.
> 
> a couple of Mathed :: dispatch changed to priv_dispatch and a couple
> moved from public to protected.
> 
> This will go in unless I get objections really fast.

Fine with me.

Andre'


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

Re: [patch] more dispatch stuff

On Tue, Oct 28, 2003 at 08:31:04PM +0100, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> 
> | I don't see the point to the _fwd.h file. 
> >
> | #include "dispatchresult_fwd.h"
> >
> | is more typing than
> >
> | class DispatchResult;
> 
> Well... but now I can add other stuff to the header file wihtout
> touching a lot of files. (not that many in this case...)

But Angus has a point here.

> | and actually makes the header file that does the #including less 
> | understandable.
> 
> I disagree.
> 
> IMHO we should never manually forward declare, that should be the
> purpose of a header file instead.

OH, PLEASE, NO!

Not Yet Another Rule To Make Things More Complex.
 
> IMHO this is the same as with global variables and extern should not
> be done manually, but by the inclusion of header files.

Please not. Forward declaring a class be saying 'class Foo;' is standard
practice. It is cheap. And it is as explicit as it can get. Nothing
hidden, all clear. #include can mean everything.

Andre'

Re: Small docbook refactoring

2003-10-29 Thread Martin Vermeer

On Tue, Oct 28, 2003 at 01:10:39PM +, Angus Leeming spake thusly:

...
 
> The philosophy is that Buffer should be minimal but complete and that 
> we should provide free functions that operate on a Buffer instance. 
> Clearly this isn't the case at the moment but small steps...
> 
> In this instance the free fuction is specific to sgml, so I'd put it 
> in the sgml.[Ch] file.
> 
> -- 
> Angus

OK, so done.

I plan to commit the attached later today.

- Martin

BTW does anyone have a large and complex LyX source file in the
docbook class? The example is a bit thin :-(

-- 
Martin Vermeer  [EMAIL PROTECTED]
Helsinki University of Technology 
Dept. of Surveying, Inst. of Geodesy
P.O. Box 1200, FIN-02015 HUT, Finland
:wq
Index: sgml.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/sgml.C,v
retrieving revision 1.10
diff -u -p -r1.10 sgml.C
--- sgml.C  6 Oct 2003 15:42:32 -   1.10
+++ sgml.C  29 Oct 2003 08:06:29 -
@@ -115,4 +115,21 @@ int closeTag(ostream & os, Paragraph::de
return !mixcont;
 }
 
+
+unsigned int closeEnvTags(ostream & ofs, bool mixcont,
+   string const & environment_inner_depth,
+   lyx::depth_type total_depth)
+{
+   unsigned int lines;
+   if (environment_inner_depth != "!-- --") {
+   string item_name= "listitem";
+   lines += closeTag(ofs, total_depth, mixcont, item_name);
+   if (environment_inner_depth == "varlistentry")
+   lines += closeTag(ofs, total_depth, mixcont, 
+   environment_inner_depth);
+   }
+   return lines;
+}
+
+
 } // namespace sgml
Index: sgml.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/sgml.h,v
retrieving revision 1.9
diff -u -p -r1.9 sgml.h
--- sgml.h  6 Oct 2003 15:42:32 -   1.9
+++ sgml.h  29 Oct 2003 08:06:29 -
@@ -34,6 +34,13 @@ int openTag(std::ostream & os, lyx::dept
 /// FIXME
 int closeTag(std::ostream & os, lyx::depth_type depth,
bool mixcont, std::string const & latexname);
+
+///
+unsigned int closeEnvTags(std::ostream & os, 
+   bool mixcont,
+   std::string const & environment_inner_depth,
+   lyx::depth_type total_depth);
+
 }
 
 #endif // SGML_H
Index: buffer.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/buffer.C,v
retrieving revision 1.534
diff -u -p -r1.534 buffer.C
--- buffer.C22 Oct 2003 14:40:24 -  1.534
+++ buffer.C29 Oct 2003 08:06:29 -
@@ -1765,12 +1765,9 @@ void Buffer::makeDocBookFile(string cons
 
// environment tag closing
for (; depth > par->params().depth(); --depth) {
-   if (environment_inner[depth] != "!-- --" && 
!environment_inner[depth].empty()) {
-   item_name = "listitem";
-   sgml::closeTag(ofs, command_depth + depth, false, 
item_name);
-   if (environment_inner[depth] == "varlistentry")
-   sgml::closeTag(ofs, depth+command_depth, 
false, environment_inner[depth]);
-   }
+   if (!environment_inner[depth].empty()) 
+   sgml::closeEnvTags(ofs, false, environment_inner[depth], 
+   command_depth + depth);
sgml::closeTag(ofs, depth + command_depth, false, 
environment_stack[depth]);
environment_stack[depth].erase();
environment_inner[depth].erase();
@@ -1779,13 +1776,8 @@ void Buffer::makeDocBookFile(string cons
if (depth == par->params().depth()
   && environment_stack[depth] != style->latexname()
   && !environment_stack[depth].empty()) {
-   if (environment_inner[depth] != "!-- --") {
-   item_name= "listitem";
-   sgml::closeTag(ofs, command_depth+depth, false, 
item_name);
-   if (environment_inner[depth] == "varlistentry")
-   sgml::closeTag(ofs, depth + command_depth, 
false, environment_inner[depth]);
-   }
-
+   sgml::closeEnvTags(ofs, false, 
environment_inner[depth], 
+   command_depth + depth);
sgml::closeTag(ofs, depth + command_depth, false, 
environment_stack[depth]);
 
environment_stack[depth].erase();
@@ -1872,12 +1864,8 @@ void Buffer::makeDocBookFile(string cons
environment_inner[depth] = "!-- --";
sgml::openTag(ofs, depth + command_depth,

Re: [patch] more dispatch stuff

On Tue, Oct 28, 2003 at 08:31:04PM +0100, Lars Gullik Bjønnes wrote:
> IMHO we should never manually forward declare, that should be the
> purpose of a header file instead.

Could we try to reach an agreement that developers do not install there
personal pets in the source, especially if it is neither existing
practice in LyX nor considered "best practice" in the outside
world nor accepted Guru practice?

There are a few people trying to make LyX source easy to understand and
fast to compile. And every once in a while a torpedo hits the leaky
ship...

To be honest, I currently feel sick. And that's not because I haven't
had breakfast - I usually don't eat in the morning during the week.

Andre'

Re: [patch] more dispatch stuff

Andre Poenitz <[EMAIL PROTECTED]> writes:

| Please not. Forward declaring a class be saying 'class Foo;' is standard
| practice. It is cheap. And it is as explicit as it can get. Nothing
| hidden, all clear. #include can mean everything.

when the include has the postfix "_fwd.h" its intent is pretty clear,
but I am not going to do anything with existing "class Foo", I am only
doing it for dispatchresult.h

-- 
Lgb

Re: [patch] more dispatch stuff

Andre Poenitz <[EMAIL PROTECTED]> writes:

| On Tue, Oct 28, 2003 at 08:31:04PM +0100, Lars Gullik Bjønnes wrote:
>> IMHO we should never manually forward declare, that should be the
>> purpose of a header file instead.
>
| Could we try to reach an agreement that developers do not install there
| personal pets in the source, especially if it is neither existing
| practice in LyX nor considered "best practice" in the outside
| world nor accepted Guru practice?

what is it about IMHO you don't understand?

[rant deleted]

[rant about physical condition deleted]

-- 
Lgb

Re: [patch] more dispatch stuff

On Wed, Oct 29, 2003 at 09:17:40AM +0100, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
> 
> | Please not. Forward declaring a class be saying 'class Foo;' is standard
> | practice. It is cheap. And it is as explicit as it can get. Nothing
> | hidden, all clear. #include can mean everything.
> 
> when the include has the postfix "_fwd.h" its intent is pretty clear,

The intent might be clear, but if its purpose is only to declare 'Foo'
then 'class Foo;' makes the intend equally clear _and_ guarantees that
the implementation of the intend is correct.

Note that you stated you'd put 'other things' in that header as well -
so you already plan to implement something beyond the 'obvious'.

> but I am not going to do anything with existing "class Foo", I am only
> doing it for dispatchresult.h

Honestly: I don't trust you in such things in the long run. You
implement a bridgehead here and there and later refer to existing
practice. 

It's not that I don't do the same in similar situations. After all,
that's the way e.g. FuncRequest came into existence.

Andre'

Re: [patch] more dispatch stuff

On Wed, Oct 29, 2003 at 09:22:57AM +0100, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
> 
> | On Tue, Oct 28, 2003 at 08:31:04PM +0100, Lars Gullik Bjønnes wrote:
> >> IMHO we should never manually forward declare, that should be the
> >> purpose of a header file instead.
> >
> | Could we try to reach an agreement that developers do not install there
> | personal pets in the source, especially if it is neither existing
> | practice in LyX nor considered "best practice" in the outside
> | world nor accepted Guru practice?
> 
> what is it about IMHO you don't understand?

The missing part.

'IMHO it should generally done like A, but for LyX existing/best/Guru
practice B is fine'.

It's like saying:

'IMHO any superflous braces should be removed, but for LyX it is fine to
have some around blocks with more than one line, too'

or:

'IMHO header inclusion should be avoided whenever possible, but for LyX
it is fine to be not so strict'

or:

'IMHO structs should always be passed be reference instead of
returning them from a function, but for LyX it is fine to return
them'

or:

'IMHO one should never use non-standard libraries if using standard code
give a solution of equal length, but for LyX anything from boost is ok'

or:

'IMHO one should never try to guard against the unforeseen with extra
code but fix the bug once the appear, but for LyX it is ok to have a few
verbose safety belts'

I think there are a few more of them...


Andre'

Re: [patch] more dispatch stuff

Andre Poenitz <[EMAIL PROTECTED]> writes:

| On Wed, Oct 29, 2003 at 09:17:40AM +0100, Lars Gullik Bjønnes wrote:
>> Andre Poenitz <[EMAIL PROTECTED]> writes:
>> 
>> | Please not. Forward declaring a class be saying 'class Foo;' is standard
>> | practice. It is cheap. And it is as explicit as it can get. Nothing
>> | hidden, all clear. #include can mean everything.
>> 
>> when the include has the postfix "_fwd.h" its intent is pretty clear,
>
| The intent might be clear, but if its purpose is only to declare 'Foo'
| then 'class Foo;' makes the intend equally clear _and_ guarantees that
| the implementation of the intend is correct.

except for hassle if I want to change the 'Foo' into 'Bar' (or course
then I'll have other things to fix as well...
Most likely the whole _fwd file will go, but it is practical for my
when I work on the dispatch stuff.

| Note that you stated you'd put 'other things' in that header as well -
| so you already plan to implement something beyond the 'obvious'.

Other forward declarations...

-- 
Lgb

Re: [patch] more dispatch stuff

Andre Poenitz <[EMAIL PROTECTED]> writes:

[IMHOs]

But I don't claim to get sick by seeing your IMHOs.

And I disagree with several of them, both on subjective reason, but
also on technical reasons.

-- 
Lgb

prosper.layout



There is a prosper.layout from Dekel. Is there a specific reason we do
not distribute this?

Andre;

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

Re: Problem with hyperref and BibTeX

Kayvan A. Sylvan wrote:

Sorry, Kayvan, but I don't believe your assertion that Bernoulli said 
this:

...about the consumer to assess potential risks as well as to set 
prices. Insurance companies use a plethora of mathematical techniques 
in their Risk Management process, including the notion of a person s  
utility function  [Bernoulli, 1738].

> Look at the PDF file attached. Click on the Reference link page
> number (5) and you land on page 4. I also attac the LyX and bibtex
> files.
> 
> Any help would be greatly appreciated!

Ask on the users' list. Specifically ask Herbert ;-)

-- 
Angus

Re: [patch] more dispatch stuff

On Wed, Oct 29, 2003 at 09:44:46AM +0100, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
> 
> [IMHOs]
> 
> But I don't claim to get sick by seeing your IMHOs.

Well, your stomach seems to be better than mine then.

> And I disagree with several of them, both on subjective reason, but
> also on technical reasons.

I'd think so. That's one of the reasons I do not try to push them into
LyX.

Andre'

Re: Problem with hyperref and BibTeX

2003-10-29 Thread Kayvan A. Sylvan

On Wed, Oct 29, 2003 at 08:54:27AM +, Angus Leeming wrote:
> Kayvan A. Sylvan wrote:
> 
> Sorry, Kayvan, but I don't believe your assertion that Bernoulli said 
> this:
> 
> ...about the consumer to assess potential risks as well as to set 
> prices. Insurance companies use a plethora of mathematical techniques 
> in their Risk Management process, including the notion of a person s  
> utility function  [Bernoulli, 1738].

Heh! You are supposed to look there for the notion of "utility function".

> > Look at the PDF file attached. Click on the Reference link page
> > number (5) and you land on page 4. I also attac the LyX and bibtex
> > files.
> > 
> > Any help would be greatly appreciated!
> 
> Ask on the users' list. Specifically ask Herbert ;-)

Okay, thanks. I sent it to the User's list.

---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: prosper.layout

On Wednesday 29 October 2003 08:55, Andre Poenitz wrote:
> There is a prosper.layout from Dekel. Is there a specific reason we do
> not distribute this?

  And also another from John Weiss.
  Christian some more bits about this soomewhere in the wiki.

  I also intend to polish it and put it in the distribution.

> Andre;

-- 
José Abílio

LyX and docbook, a perfect match. :-)

Re: prosper.layout

Andre Poenitz wrote:
> There is a prosper.layout from Dekel. Is there a specific reason we
> do not distribute this?

There is also one from John Weiss. I don't think anyone's taken the 
time to ascertain why one and not the other, although I understand 
that Christian has used both in anger.

-- 
Angus

Re: [patch] more dispatch stuff

Lars Gullik Bjønnes wrote:

> except for hassle if I want to change the 'Foo' into 'Bar' (or
> course then I'll have other things to fix as well...
> Most likely the whole _fwd file will go, but it is practical for my
> when I work on the dispatch stuff.

Why not say this at the start and avoid raising André's blood pressure 
needlessly? It's hard to avoid the conclusion that you enjoy baiting 
him.

More generally, why submit a patch for inspection if you don't intend 
the final code to look anything like it?

Angus (a bit baffled)

Re: [patch] more dispatch stuff

Angus Leeming <[EMAIL PROTECTED]> writes:

| More generally, why submit a patch for inspection if you don't intend 
| the final code to look anything like it?

So that you can tell me if it collides with something you work on.

Also to make the process more visible.

-- 
Lgb

Re: [patch] more dispatch stuff

Lars Gullik Bjønnes wrote:
> Also to make the process more visible.
Well, that bit worked ;-)

-- 
Angus

Re: Small docbook refactoring

2003-10-29 Thread Martin Vermeer

On Tue, Oct 28, 2003 at 11:32:40AM +, Jose' Matos spake thusly:
 
>   This code is a mess (it is my code so I am allowed to say that). I have 
> discussed this two years ago with Jürgen Vigna and it appears that the latex 
> output code was redone to take in account the nested environments.

Speaking about which, looking at buffer.C:

   1794 case LATEX_COMMAND:
   1795 if (depth != 0)
   1796 error(ErrorItem(_("Error"), _("Wrong depth for LatexType 
Command."), par->id(), 0, par->size()));
   1797 

Apparently depth != 0 is not supposed to happen for a
(paragraph-style) command (apparently mostly sectioning headers,
right?)

Then a bit lower:

   1845 sgml::openTag(ofs, depth + command_depth, false, command_name);
   1846 
   1847 item_name = c_params.empty() ? "title" : c_params;
   1848 sgml::openTag(ofs, depth + 1 + command_depth, false, item_na

and 

   1901 // write closing SGML tags
   1902 switch (style->latextype) {
   1903 case LATEX_COMMAND:
   1904 end_tag = c_params.empty() ? "title" : c_params;
   1905 sgml::closeTag(ofs, depth + command_depth,
   1906  false, end_tag);
   1907 break;

Do we really need 'depth + command_depth' here, rather than just
'command_depth'? Apparently it only affects the indent in the .sgml
output file.

...and should we somehow get rid of the '// environment tag closing'
stanza at the beginning? Yes, this looks messy :-) but I don't dare to
touch it without a non-trivial DocBook LyX test file...

- Martin



pgp0.pgp
Description: PGP signature

Re: Small docbook refactoring

On Wednesday 29 October 2003 08:30, Martin Vermeer wrote:
> On Tue, Oct 28, 2003 at 01:10:39PM +, Angus Leeming spake thusly:
>
> OK, so done.
>
> I plan to commit the attached later today.

Ok.

> - Martin
>
> BTW does anyone have a large and complex LyX source file in the
> docbook class? The example is a bit thin :-(

I send you one example attached. I have another but it spans several dozens
of directories, really. :-)

--
José Abílio
#LyX 1.1 created this file. For more info see http://www.lyx.org/
\lyxformat 218
\textclass docbook
\begin_preamble

http://perso.libertysurf.fr/bgu/db2lyx";>
\end_preamble
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\spacing single
\papersize Default
\paperpackage a4
\use_geometry 0
\use_amsmath 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation skip
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default

\layout Title

DB2LyX
\newline
Install and Use
\layout Author

\latex latex

\latex default
B.
\latex latex

\latex default
Guillon
\latex latex

\layout Date

14 October 2001
\layout Section

\begin_inset LatexCommand \label{intro}

\end_inset

Introduction
\layout Standard

The DB2LyX package provides a set of XSL stylesheets to translate an XML
DocBook document into a LyX-1.1.6 or LyX-1.2.0 compliant file format.
This paper is intended to explain how to install and use it, and is the
first example of the translation process.
\layout Standard

Besides, while the XML format is not fully supported by LyX, a script is
provided by the package to translate easily SGML DocBook documents to XML
DocBook documents.
\layout Section

\begin_inset LatexCommand \label{release}

\end_inset

Release
\layout Standard

This paper is for release 0.1.5.
\layout Section

\begin_inset LatexCommand \label{content}

\end_inset

Content
\layout Standard

The package contains the following:
\layout Description

*.xsl: The DB2LyX XSL stylesheets.
\layout Description

format218: XSL stylesheets specific to the LyX-1.16 file format.
\layout Description

format220: XSL stylesheets specific to the LyX-1.2.0 file format.
\layout Description

template: Some templates used to build an entity file during the package
configuration.
\layout Description

catresolve: Program to resolve any Public or System ID from the catalogs
listed in the SGML_CATALOG_FILES variable.
The program is linked to the Gnome xml2 library during the configuration
step if xsltproc is available.

\layout Description

doc: Documentation.
\layout Description

script: Some scripts.
In particular it contains sgml2xml.pl
\layout Section

\begin_inset LatexCommand \label{install}

\end_inset

Installing the package
\layout Subsection

Dependencies
\layout Standard

The package needs the following features:
\layout Itemize

the XML DocBook DTD,
\layout Itemize

the Norman Walsh's DocBook XSL stylesheets,
\layout Itemize

the MathML ISO entities,
\layout Itemize

the DB2LyX stylesheets.
\layout Standard

Moreover, you need to install XML/XSLT tools.
There are two possibilities: using java tools or using the Gnome project
XML/XSLT libraries.
The java tools involve to have:
\layout Itemize

Java,
\layout Itemize

the
\begin_inset LatexCommand \url[Arbortext Catalog Classes]{http://www.arbortext.com/Customer_Support/Updates_and_Technical_Notes/java_form.html}

\end_inset

,
\layout Itemize

a java XSLT.

\layout Standard

If you choose to use the Gnome XML/XSLT libraries you need to install:
\layout Itemize

libxml2,
\layout Itemize

libxslt (and its related program, xsltproc).
\layout Subsection

Install procedure (java support)
\layout Standard

If nothing is installed, you can follow this default install procedure.

\layout Enumerate

Install the
\begin_inset LatexCommand \url[XML DocBook DTD]{http://www.oasis-open.org/docbook/xml/index.shtml}

\end_inset

.
\layout Enumerate

Install the
\begin_inset LatexCommand \url[Norman Walsh's DocBook XSL stylesheets]{http://sourceforge.net/projects/docbook}

\end_inset

.
\layout Enumerate

Download and install the
\begin_inset LatexCommand \url[MathML entities]{http://www.nag.co.uk/projects/OpenMath/mml-files/}

\end_inset

.
\layout Enumerate

Download the
\begin_inset LatexCommand \url[Arbortext Catalog Classes]{http://www.arbortext.com/Customer_Support/Updates_and_Technical_Notes/java_form.html}

\end_inset

distribution.
The Java catalog classes are used to resolve the file paths during configuratio
n by using the SGML catalogs.
\layout Enumerate

Install your favorite XSLT.
XT/XP is a translator that should work correctly with the stylesheets.
To install XT/XP look at the
\begin_inset LatexCommand \ref[XT/XP install]{sec-install-xtxp}

\end_inset

procedure.
\layout Enumerate

Update the CLASSPATH variable.
See the
\begin_inset LatexCommand \ref[CLASSPATH section]{sec-classpath}

\end_inset

Re: Small docbook refactoring

On Wednesday 29 October 2003 10:04, Martin Vermeer wrote:
> On Tue, Oct 28, 2003 at 11:32:40AM +, Jose' Matos spake thusly:
> >   This code is a mess (it is my code so I am allowed to say that). I have
> > discussed this two years ago with Jürgen Vigna and it appears that the
> > latex output code was redone to take in account the nested environments.
>
> Speaking about which, looking at buffer.C:
>
>1794 case LATEX_COMMAND:
>1795 if (depth != 0)
>1796 error(ErrorItem(_("Error"), _("Wrong depth for
> LatexType Command."), par->id(), 0, par->size())); 1797
>
> Apparently depth != 0 is not supposed to happen for a
> (paragraph-style) command (apparently mostly sectioning headers,
> right?)

  It shouldn't but it is possible. You put a chapter inside a list in lyx, the 
resulting document isn't valid, but it is possible. This is the case I want 
to catch.

> Then a bit lower:
>
>1845 sgml::openTag(ofs, depth + command_depth, false,
> command_name); 1846
>1847 item_name = c_params.empty() ? "title" : c_params;
>1848 sgml::openTag(ofs, depth + 1 + command_depth, false,
> item_na
>
> and
>
>1901 // write closing SGML tags
>1902 switch (style->latextype) {
>1903 case LATEX_COMMAND:
>1904 end_tag = c_params.empty() ? "title" : c_params;
>1905 sgml::closeTag(ofs, depth + command_depth,
>1906  false, end_tag);
>1907 break;
>
> Do we really need 'depth + command_depth' here, rather than just
> 'command_depth'? Apparently it only affects the indent in the .sgml
> output file.

  The second argument of open and closeTag are only related with indentation. 
The idea was to have a nice output. But sure we can get rid of them.

> ...and should we somehow get rid of the '// environment tag closing'
> stanza at the beginning? Yes, this looks messy :-) but I don't dare to
> touch it without a non-trivial DocBook LyX test file...

   Such as it is now no, for that we need to have in account the nested 
structure, I will have a look to the lastex export model and report it later.  

> - Martin

-- 
José Abílio

Re: Small docbook refactoring

On Wednesday 29 October 2003 10:04, Martin Vermeer wrote:
>
> ...and should we somehow get rid of the '// environment tag closing'
> stanza at the beginning? Yes, this looks messy :-) but I don't dare to
> touch it without a non-trivial DocBook LyX test file...

  Notice that now most of the code for latex generation is in 
src/paragraph_funcs.C so probably we should also move most of the docbook 
related files to there.

> - Martin

-- 
José Abílio

[patch] more 'global cursor' infrastructure


See attached.

Still inactive (but 'dispatch to tip' starts to become functional...)

Andr'e
-- 
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Index: cursor.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/cursor.C,v
retrieving revision 1.4
diff -u -p -r1.4 cursor.C
--- cursor.C29 Oct 2003 10:47:12 -  1.4
+++ cursor.C29 Oct 2003 11:01:44 -
@@ -22,12 +22,20 @@
 #include "insets/updatableinset.h"
 
 using std::vector;
+using endl;
 
 
-DispatchResult Cursor::dispatch(FuncRequest const &)
+DispatchResult Cursor::dispatch(FuncRequest const & cmd)
 {
for (int i = data_.size() - 1; i >= 0; --i) {
-   lyxerr << "trying to dispatch to " << data_[i].text_ << std::endl;
+   lyxerr << "trying to dispatch to inset" << data_[i].inset_ << endl;
+   DispatchResult result = data_[i].inset_->dispatch(cmd);
+   lyxerr << "   result: " << result << endl;
+   if (result == DISPATCHED)
+   return result;
+   if (result == DISPATCHED_NOUPDATE)
+   return result;
+   lyxerr << "# unhandled result: " << result << endl;
}
return UNDISPATCHED;
 }
@@ -36,7 +44,7 @@ DispatchResult Cursor::dispatch(FuncRequ
 void buildCursor(Cursor & cursor, BufferView & bv)
 {
UpdatableInset * inset = bv.theLockingInset();
-   lyxerr << "\nbuildCursor: " << inset << std::endl;
+   lyxerr << "\nbuildCursor: " << inset << endl;
if (!inset)
return;
 
@@ -54,26 +62,17 @@ void buildCursor(Cursor & cursor, Buffer
}
 
if (!ok) {
-   lyxerr << " tli not found! inset: " << inset << std::endl;
+   lyxerr << " tli not found! inset: " << inset << endl;
return;
}
 
-   vector pits;
-   vector   plists;
-   vector   texts;
-/*
-   pit.getPits(pits, plists, texts);
-
-   cursor.data_.resize(pits.size());
-   for (size_t i = 0, n = pits.size(); i != n; ++i) {
-   cursor.data_[i].text_ = texts[i];
-   cursor.data_[i].pit_  = pits[i];
-   //cursor.data_[i].pos_ = texts[i]->cursor.pos();
-   cursor.data_[i].pos_ = 0;
-   lyxerr << " text: " << cursor.data_[i].text_
-  << " pit: " << cursor.data_[i].pit_->id()
+   pit.asCursor(cursor);
+   for (size_t i = 0, n = cursor.data_.size(); i != n; ++i) {
+   lyxerr << " inset: " << cursor.data_[i].inset_
+  << " idx: " << cursor.data_[i].idx_
+  << " text: " << cursor.data_[i].text_
+  << " par: " << cursor.data_[i].par_
   << " pos: " << cursor.data_[i].pos_
-  << std::endl;
+  << endl;
}
-*/
 }
Index: cursor.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/cursor.h,v
retrieving revision 1.2
diff -u -p -r1.2 cursor.h
--- cursor.h18 Sep 2003 11:21:53 -  1.2
+++ cursor.h29 Oct 2003 11:01:44 -
@@ -12,7 +12,6 @@
 #ifndef CURSOR_H
 #define CURSOR_H
 
-#include "ParagraphList_fwd.h"
 #include "textcursor.h"
 
 #include "support/types.h"
@@ -20,6 +19,7 @@
 #include 
 
 class BufferView;
+class InsetOld;
 class DispatchResult;
 class FuncRequest;
 class LyXText;
@@ -32,12 +32,16 @@ class LyXText;
 class CursorItem : public TextCursor {
 public:
///
-   CursorItem() : text_(0) {}
+   CursorItem() : inset_(0), text_(0), idx_(0), par_(0), pos_(0) {}
 public:
///
+   InsetOld * inset_;
+   ///
LyXText * text_;
///
-   ParagraphList::iterator pit_;
+   int idx_;
+   ///
+   int par_;
///
int pos_;
 };
Index: iterators.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/iterators.C,v
retrieving revision 1.22
diff -u -p -r1.22 iterators.C
--- iterators.C 15 Oct 2003 08:49:42 -  1.22
+++ iterators.C 29 Oct 2003 11:01:44 -
@@ -13,16 +13,13 @@
 
 #include "iterators.h"
 #include "paragraph.h"
-#include "debug.h"
+#include "cursor.h"
 
 #include "insets/inset.h"
 
 #include 
 #include 
 
-// it's conceptionally a stack, but undo needs random access...
-//#include 
-
 using boost::next;
 using boost::optional;
 using std::vector;
@@ -175,6 +172,22 @@ int ParIterator::index() const
return 0;
 
return *(pimpl_->positions[pimpl_->positions.size() - 2].index);
+}
+
+
+void ParIterator::asCursor(Cursor & cursor) const
+{
+   cursor.data_.clear();
+   for (size_t i = 1, n = size(); i < n; ++i) {
+   ParPosition const & pos = pimpl_->positions[i - 1];
+

Re: Small docbook refactoring

Jose' Matos wrote:

> On Wednesday 29 October 2003 10:04, Martin Vermeer wrote:
>>
>> ...and should we somehow get rid of the '// environment tag
>> closing' stanza at the beginning? Yes, this looks messy :-) but I
>> don't dare to touch it without a non-trivial DocBook LyX test
>> file...
> 
>   Notice that now most of the code for latex generation is in
> src/paragraph_funcs.C so probably we should also move most of the
> docbook related files to there.

or move the latex generation stuff out...

-- 
Angus

Re: Small docbook refactoring

Angus Leeming <[EMAIL PROTECTED]> writes:

| Jose' Matos wrote:
>
>> On Wednesday 29 October 2003 10:04, Martin Vermeer wrote:
>>>
>>> ...and should we somehow get rid of the '// environment tag
>>> closing' stanza at the beginning? Yes, this looks messy :-) but I
>>> don't dare to touch it without a non-trivial DocBook LyX test
>>> file...
>> 
>>   Notice that now most of the code for latex generation is in
>> src/paragraph_funcs.C so probably we should also move most of the
>> docbook related files to there.
>
| or move the latex generation stuff out...

out where?

I worked pretty hard to get it out of Paragraph and Buffer.

-- 
Lgb

Re: [patch] more 'global cursor' infrastructure

Andre Poenitz wrote:

> 
> See attached.
> 
> Still inactive (but 'dispatch to tip' starts to become
> functional...)

I see that your are using 'buildCursor' within lyxfunc.C, but why do 
you need 'buildCursor' as well as 'ParIterator::asCursor' It seems 
like one of them does nothing more than call the other.

Apart from that, it seems to make sense, although it'll be fun to see 
(perhaps dummy) handlers for the LFUN in the insets.

-- 
Angus

Re: [patch] more 'global cursor' infrastructure

On Wed, Oct 29, 2003 at 11:42:47AM +, Angus Leeming wrote:
> Andre Poenitz wrote:
> 
> > 
> > See attached.
> > 
> > Still inactive (but 'dispatch to tip' starts to become
> > functional...)
> 
> I see that your are using 'buildCursor' within lyxfunc.C, but why do 
> you need 'buildCursor' as well as 'ParIterator::asCursor' It seems 
> like one of them does nothing more than call the other.

That's not final structure. In the end the 'cursor' will just be there
and only modified, not created every time. Both buildCursor and asCursor
are hacks.

>From the code shown, only the loop that dispatches the Lfun from
innermost to outermost until something handled it  will remain.

> Apart from that, it seems to make sense, although it'll be fun to see 
> (perhaps dummy) handlers for the LFUN in the insets.

?

Which LFUN?

[And note that inserting chars and other simple operations already work
if the facility is activated]

Andre'

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

Re: [patch] more 'global cursor' infrastructure

On Wed, Oct 29, 2003 at 12:49:03PM +0100, Andre' Poenitz wrote:
> That's not final structure. In the end the 'cursor' will just be there
> and only modified, not created every time. Both buildCursor and asCursor
> are hacks.

... that will go again...

Andre'

Re: Small docbook refactoring

Lars Gullik Bjønnes wrote:
> | or move the latex generation stuff out...
> 
> out where?
> 
> I worked pretty hard to get it out of Paragraph and Buffer.

latex_generation.[Ch] perhaps? I was just thinking that 
paragraph_funcs.C would start to get pretty cluttered if a whole heap 
of sgml_generation stuff went in there too.

-- 
Angus

Re: [patch] more 'global cursor' infrastructure

Andre Poenitz wrote:
>> Apart from that, it seems to make sense, although it'll be fun to
>> see (perhaps dummy) handlers for the LFUN in the insets.
> 
> ?
> Which LFUN?

Whatever LFUN is passed to the inset stored in Cursor in
this call I guess. I thought that you'd need new handling code in
the insets to make them cursor-aware?

#if 0
{
Cursor cursor;
buildCursor(cursor, *view());
if (cursor.dispatch(FuncRequest(func, view())) == DISPATCHED) {
lyxerr << "dispatched by Cursor::dispatch()\n";
goto exit_with_message;
}
}
#endif

> 
> [And note that inserting chars and other simple operations already
> [work
> if the facility is activated]

Very impressive!

--

Re: [patch] more 'global cursor' infrastructure

Andre Poenitz <[EMAIL PROTECTED]> writes:

| On Wed, Oct 29, 2003 at 11:42:47AM +, Angus Leeming wrote:
>> Andre Poenitz wrote:
>> 
>> > 
>> > See attached.
>> > 
>> > Still inactive (but 'dispatch to tip' starts to become
>> > functional...)
>> 
>> I see that your are using 'buildCursor' within lyxfunc.C, but why do 
>> you need 'buildCursor' as well as 'ParIterator::asCursor' It seems 
>> like one of them does nothing more than call the other.
>
| That's not final structure. In the end the 'cursor' will just be there
| and only modified, not created every time. Both buildCursor and asCursor
| are hacks.
>
| From the code shown, only the loop that dispatches the Lfun from
| innermost to outermost until something handled it  will remain.

Hmm... this kindo goes againt what I am working on. But that should be
possible to resolve.

It seems that we will need two "ways" into the dispatch machinery:

   1. through the cursor
   2. through the lyxview (lyxfunc)

(or we could make it so that the lyxview dispatch only is used if no
documents are loaded, so that as long we have a cursor we use that for
dispatch.) 

One thing that I'l like to do is to make the result of a Dispatch only
have to values: DISPATCHED and UNDISPATCHED.
In addition to these I want to add a status field. This will be a
"binary enum" with values such as UPDATE,POP,FINISH_LEFT,FINISH_RIGHT
etc.

And I want these status to be handled in one place, f.ex. so that if
UPDATE is set we only update once.

-- 
Lgb

Re: [patch] more 'global cursor' infrastructure

On Wed, Oct 29, 2003 at 11:56:46AM +, Angus Leeming wrote:
> Andre Poenitz wrote:
> >> Apart from that, it seems to make sense, although it'll be fun to
> >> see (perhaps dummy) handlers for the LFUN in the insets.
> > 
> > ?
> > Which LFUN?
> 
> Whatever LFUN is passed to the inset stored in Cursor in
> this call I guess. I thought that you'd need new handling code in
> the insets to make them cursor-aware?

No.

On the contrary, all the code not strictly doing LFUN handling in
dispatch() (i.e. inset locking & Co) will be removed.

The cursor just serves as a means to feed the FuncRequest to the first
inset (or the global text) that is able to handle it.

So you can think of it as a replacement for inset locking. (

Andre'

DISPATCHED_POP - explanation


Can someone (Andre), please explain do me what DISPATCHED_POP is used
for? And add some documentation for it to dispatchresult.h?

In the vein of the other dispatch_result_t values... would
FINISHED_POP be a better name?

-- 
Lgb

Re: [patch] more 'global cursor' infrastructure

Andre Poenitz wrote:

> On Wed, Oct 29, 2003 at 11:56:46AM +, Angus Leeming wrote:
>> Andre Poenitz wrote:
>> >> Apart from that, it seems to make sense, although it'll be fun
>> >> to see (perhaps dummy) handlers for the LFUN in the insets.
>> > 
>> > ?
>> > Which LFUN?
>> 
>> Whatever LFUN is passed to the inset stored in Cursor in
>> this call I guess. I thought that you'd need new handling code in
>> the insets to make them cursor-aware?
> 
> No.
> 
> On the contrary, all the code not strictly doing LFUN handling in
> dispatch() (i.e. inset locking & Co) will be removed.
> 
> The cursor just serves as a means to feed the FuncRequest to the
> first inset (or the global text) that is able to handle it.
> 
> So you can think of it as a replacement for inset locking. (

Ok. I think I get the big picture.

So each 'positioning action' (left arrow, up arrow, page down,
mouse click etc) will cause the contents of the cursor to be updated
(the idx, inset member variables etc). Thereafter, any call to
cursor.dispatch will just find the right object to dispatch to.

Right?

--

Re: Small docbook refactoring

On Wednesday 29 October 2003 11:44, Angus Leeming wrote:
> >
> > I worked pretty hard to get it out of Paragraph and Buffer.
>
> latex_generation.[Ch] perhaps? I was just thinking that
> paragraph_funcs.C would start to get pretty cluttered if a whole heap
> of sgml_generation stuff went in there too.

  Moving all the stuff that doesn't belong to buffer.C to there I get:

   1092 lyx-devel/src/paragraph_funcs.C
   1788 lyx-devel-exp/src/paragraph_funcs.C

  reordering the code I expect the number to decrease slightly. Is this ok, or 
too much bloat? :-)

  And please do not separate the latex, linuxdoc and docbook generation.

  This is also one of the reasons I don't like the visitor pattern for adding 
new backends. The code for backend generation should, IMHO, stay together.

-- 
José Abílio

LyX and docbook, a perfect match. :-)

Re: DISPATCHED_POP - explanation

On Wed, Oct 29, 2003 at 01:07:44PM +0100, Lars Gullik Bjønnes wrote:
> 
> Can someone (Andre), please explain do me what DISPATCHED_POP is used
> for?

The inset has handled the request, but the the cursor must leave the
inset now. 

The name originated from removing one 'cursor slice' from the top of the
cursor (which is a stack of such slices).

> In the vein of the other dispatch_result_t values... would
> FINISHED_POP be a better name?

Hm... yes.

Andre'

Re: DISPATCHED_POP - explanation

Andre Poenitz <[EMAIL PROTECTED]> writes:

| On Wed, Oct 29, 2003 at 01:07:44PM +0100, Lars Gullik Bjønnes wrote:
>> 
>> Can someone (Andre), please explain do me what DISPATCHED_POP is used
>> for?
>
| The inset has handled the request, but the the cursor must leave the
| inset now. 

Ok, in what way is this different from FINISHED?

-- 
Lgb

Re: prosper.layout

On Wed, 29 Oct 2003, Jose' Matos wrote:

> On Wednesday 29 October 2003 08:55, Andre Poenitz wrote:
> > There is a prosper.layout from Dekel. Is there a specific reason we do
> > not distribute this?
> 
>   And also another from John Weiss.
>   Christian some more bits about this soomewhere in the wiki.

Uh.. I get "syntax error" on the sentence above, but I don't think I've 
put it in the wiki (yet), instead see 
http://www.md.kth.se/~chr/lyx/examples/prosper/

/Christian

-- 
Christian Ridderström   http://www.md.kth.se/~chr

Re: cvs complie error

2003-10-29 Thread John Levon

On Mon, Oct 27, 2003 at 01:11:00PM +0100, Gandalf GreyHair wrote:

> LyX name is some internal name in LyX
> Displayed name and numbers tells what is printed first in the theorem, for 
> example, Lemma 2.7.1322 means  we have chapter+section numbers, and 1322 
> lemmas in that section!
> Theorem textstyle, if you want your theorem in emph size.

What would be in "placement" ??

I think the way that we specify the numbering could be improved (perhaps
a slider or something ? ). Not sure.

> Connect to subtheorem. Well, this is  another thing I would like to see 
> better support for in LyX (or I just have to start read documentation about 
> how to do it). My thought was that if you write a theorem, then you would 
> in most cases also put a theorem afterwards. The in the "connect to 
> subtheorem" you could tell that there should be a proof (selected in the 
> list) placed afterwards, and they should have the same number (perhaps that 
> also shoudl be an option?). The other subtheorems, like answer could be 
> connected to exercises, and they get the same number, and you can also 
> change the placement, by telling latex to put all latexcode in the 
> foobar.ins file (to be inserted at the end of the file) or to put in 
> #chapter.ins files (to put answers at the end of each chapter).
> 
> (perhaps this whole idea is better done with latex commands in the 
> preamble...)

This doesn't sound like a suitable thing to have in this dialog IMHO. 

We'd probably be able to do the preview easily enough (dunno: does
xforms do rich text markup ?)

(Trivial: the dialog needs cleaning up in terms of layout)

regards
john

Compile error in cursor.C


I get this error:

g++ -DHAVE_CONFIG_H -I. -I. -I. -I../boost  -I/usr/X11R6/include  -O
-fno-exceptions -W -Wall -c -o cursor.o `test -f 'cursor.C' || echo './'`cursor.C
cursor.C: In member function `DispatchResult Cursor::dispatch(const
   FuncRequest&)':
cursor.C:36: `update' undeclared (first use this function)


-- 
Lgb

Re: Compile error in cursor.C

On Wed, Oct 29, 2003 at 01:49:51PM +0100, Lars Gullik Bjønnes wrote:
> 
> I get this error:
> 
> g++ -DHAVE_CONFIG_H -I. -I. -I. -I../boost  -I/usr/X11R6/include  -O
> -fno-exceptions -W -Wall -c -o cursor.o `test -f 'cursor.C' || echo './'`cursor.C
> cursor.C: In member function `DispatchResult Cursor::dispatch(const
>FuncRequest&)':
> cursor.C:36: `update' undeclared (first use this function)

YACFTWT (Yet another commit from the wrong tree).

Just removing that line should work. I currently can't reach aussie.

Andre'

Re: DISPATCHED_POP - explanation

On Wed, Oct 29, 2003 at 01:21:51PM +0100, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
> 
> | On Wed, Oct 29, 2003 at 01:07:44PM +0100, Lars Gullik Bjønnes wrote:
> >> 
> >> Can someone (Andre), please explain do me what DISPATCHED_POP is used
> >> for?
> >
> | The inset has handled the request, but the the cursor must leave the
> | inset now. 
> 
> Ok, in what way is this different from FINISHED?

The one is used in src/mathed and the other in src/insets ;-}

Note that the common dispatch() for mathed and insets is a fairly recent
invention...

Andre'

Re: [patch] more 'global cursor' infrastructure

On Wed, Oct 29, 2003 at 12:11:57PM +, Angus Leeming wrote:
> So each 'positioning action' (left arrow, up arrow, page down,
> mouse click etc) will cause the contents of the cursor to be updated
> (the idx, inset member variables etc). Thereafter, any call to
> cursor.dispatch will just find the right object to dispatch to.
> 
> Right?

Bingo.

Andre'

Re: [patch] more 'global cursor' infrastructure

On Wed, Oct 29, 2003 at 12:58:13PM +0100, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
> 
> | On Wed, Oct 29, 2003 at 11:42:47AM +, Angus Leeming wrote:
> >> Andre Poenitz wrote:
> >> 
> >> > 
> >> > See attached.
> >> > 
> >> > Still inactive (but 'dispatch to tip' starts to become
> >> > functional...)
> >> 
> >> I see that your are using 'buildCursor' within lyxfunc.C, but why do 
> >> you need 'buildCursor' as well as 'ParIterator::asCursor' It seems 
> >> like one of them does nothing more than call the other.
> >
> | That's not final structure. In the end the 'cursor' will just be there
> | and only modified, not created every time. Both buildCursor and asCursor
> | are hacks.
> >
> | From the code shown, only the loop that dispatches the Lfun from
> | innermost to outermost until something handled it  will remain.
> 
> Hmm... this kindo goes againt what I am working on.

I thought we already agreed that it isn't as I am working only on what
happens below the main text (i.e. the inset hierarchiy) and you are
working on the LyXView/LyXFunc/BV interaction.

That I currently have a few lines in LyXFunc is just to get started. In
the end it is completely irrelevant who calls Cursor::dispatch.

> But that should be possible to resolve.
> 
> It seems that we will need two "ways" into the dispatch machinery:
> 
>1. through the cursor
>2. through the lyxview (lyxfunc)
> 
> (or we could make it so that the lyxview dispatch only is used if no
> documents are loaded, so that as long we have a cursor we use that for
> dispatch.)

Something like that.

> One thing that I'l like to do is to make the result of a Dispatch only
> have to values: DISPATCHED and UNDISPATCHED.

Fine with me. And feasible as the other stuff is handled within the
cursor machinery..

> In addition to these I want to add a status field. This will be a
> "binary enum" with values such as UPDATE,POP,FINISH_LEFT,FINISH_RIGHT
> etc.

Fine. Go for it if you wish.

> And I want these status to be handled in one place, f.ex. so that if
> UPDATE is set we only update once.

They will be handled in  Cursor::dispatch and the update call is at the
end of this.

Andre'

[patch] More dispatch work - DISPATCH_POP -> FINISHED_POP


Slowly - slowly getting there.

? doit.sh
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.448
diff -u -p -r1.448 BufferView_pimpl.C
--- BufferView_pimpl.C	29 Oct 2003 10:47:11 -	1.448
+++ BufferView_pimpl.C	29 Oct 2003 12:52:28 -
@@ -1279,7 +1279,7 @@ bool BufferView::Pimpl::dispatch(FuncReq
 		break;
 
 	default:
-		return bv_->getLyXText()->dispatch(FuncRequest(ev, bv_));
+		return bv_->getLyXText()->dispatch(FuncRequest(ev, bv_)) >= DISPATCHED;
 	} // end of switch
 
 	return true;
Index: cursor.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/cursor.C,v
retrieving revision 1.5
diff -u -p -r1.5 cursor.C
--- cursor.C	29 Oct 2003 12:18:06 -	1.5
+++ cursor.C	29 Oct 2003 12:52:28 -
@@ -30,17 +30,17 @@ DispatchResult Cursor::dispatch(FuncRequ
 	for (int i = data_.size() - 1; i >= 0; --i) {
 		lyxerr << "trying to dispatch to inset" << data_[i].inset_ << endl;
 		DispatchResult res = data_[i].inset_->dispatch(cmd);
-		lyxerr << "   result: " << result << endl;
+		lyxerr << "   result: " << res.val() << endl;
 
 		if (res == DISPATCHED) {
-			update();
+			//update();
 			return DISPATCHED;
 		}
-	
+
 		if (res == DISPATCHED_NOUPDATE)
 			return DISPATCHED;
 
-		lyxerr << "# unhandled result: " << res << endl;
+		lyxerr << "# unhandled result: " << res.val() << endl;
 	}
 	return UNDISPATCHED;
 }
Index: dispatchresult.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/dispatchresult.h,v
retrieving revision 1.1
diff -u -p -r1.1 dispatchresult.h
--- dispatchresult.h	29 Oct 2003 10:47:12 -	1.1
+++ dispatchresult.h	29 Oct 2003 12:52:28 -
@@ -36,7 +36,7 @@ enum dispatch_result_t {
 	FINISHED_RIGHT,
 	FINISHED_UP,
 	FINISHED_DOWN,
-	DISPATCHED_POP
+	FINISHED_POP
 };
 
 /** \c DispatchResult is a wrapper for dispatch_result_t.
@@ -44,12 +44,36 @@ enum dispatch_result_t {
  *  having to expose insetbase.h.
  */
 class DispatchResult {
-	dispatch_result_t val_;
 public:
 	DispatchResult()
 		: val_(UNDISPATCHED) {}
 	DispatchResult(dispatch_result_t val) : val_(val) {}
-	operator dispatch_result_t() const{ return val_; }
+	dispatch_result_t val() const { return val_; }
+private:
+	dispatch_result_t val_;
 };
+
+
+inline
+bool operator==(DispatchResult const & lhs, DispatchResult const & rhs)
+{
+	return lhs.val() == rhs.val();
+}
+
+
+inline
+bool operator!=(DispatchResult const & lhs, DispatchResult const & rhs)
+{
+	return !(lhs == rhs);
+}
+
+
+// This operator is temporary, will be removed with the introduction of
+// a status field in DispatchResult.
+inline
+bool operator>=(DispatchResult const & lhs, DispatchResult const & rhs)
+{
+	return lhs.val() >= rhs.val();
+}
 
 #endif // DISPATCH_RESULT_H
Index: insets/insettabular.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insettabular.C,v
retrieving revision 1.356
diff -u -p -r1.356 insettabular.C
--- insets/insettabular.C	29 Oct 2003 10:47:18 -	1.356
+++ insets/insettabular.C	29 Oct 2003 12:52:29 -
@@ -598,18 +598,18 @@ void InsetTabular::lfunMousePress(FuncRe
 
 bool InsetTabular::lfunMouseRelease(FuncRequest const & cmd)
 {
-	bool ret = false;
+	DispatchResult ret = UNDISPATCHED;
 	if (the_locking_inset) {
 		FuncRequest cmd1 = cmd;
 		cmd1.x -= inset_x;
 		cmd1.y -= inset_y;
 		ret = the_locking_inset->dispatch(cmd1);
 	}
-	if (cmd.button() == mouse_button::button3 && !ret) {
+	if (cmd.button() == mouse_button::button3 && ret == UNDISPATCHED) {
 		InsetTabularMailer(*this).showDialog(cmd.view());
 		return true;
 	}
-	return ret;
+	return ret >= DISPATCHED;
 }
 
 
@@ -,7 +,7 @@ InsetTabular::priv_dispatch(FuncRequest 
 		}
 		break;
 	}
-	if (result < FINISHED) {
+	if (!(result >= FINISHED)) {
 		if (!the_locking_inset && bv->fitCursor())
 			updateLocal(bv);
 	} else
Index: insets/insettext.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insettext.C,v
retrieving revision 1.515
diff -u -p -r1.515 insettext.C
--- insets/insettext.C	29 Oct 2003 10:47:19 -	1.515
+++ insets/insettext.C	29 Oct 2003 12:52:30 -
@@ -547,7 +547,7 @@ bool InsetText::lfunMouseRelease(FuncReq
 
 	no_selection = true;
 	if (the_locking_inset)
-		return the_locking_inset->dispatch(cmd1);
+		return the_locking_inset->dispatch(cmd1) >= DISPATCHED;
 
 	int tmp_x = cmd.x;
 	int tmp_y = cmd.y + dim_.asc - bv->top_y();
@@ -557,7 +557,7 @@ bool InsetText::lfunMouseRelease(FuncReq
 
 	// We still need to deal properly with the whole relative vs.
 	// absolute mouse co-ords thing in a realiable, sensible way
-	bool ret = inset->dispatch(cmd1);
+	bool ret = inset->dispatch(cmd1) >= DISPATCHED;
 	updateLocal(bv, false);
 	return ret;
 }
@@

Re: Compile error in cursor.C

Andre Poenitz <[EMAIL PROTECTED]> writes:

| Just removing that line should work. I currently can't reach aussie.

I just commented it out.

-- 
Lgb

Re: prosper.layout

On Wed, 29 Oct 2003, Angus Leeming wrote:

> Andre Poenitz wrote:
> > There is a prosper.layout from Dekel. Is there a specific reason we
> > do not distribute this?
> 
> There is also one from John Weiss. I don't think anyone's taken the 
> time to ascertain why one and not the other, although I understand 
> that Christian has used both in anger.

Quoting myself: "... Weiss's layout seems to work best at the moment."

That probably refers to this layout: 
http://www.md.kth.se/~chr/lyx/examples/prosper/layouts/prosper-by-Weiss.layout

I also think people on the user's list have had some success using 
lyx/prosper, so you should send a question to them, asking:
* Have they modified the layout?
* Any ideas for suggestions?
before you put it in the distribution.

/Christian

-- 
Christian Ridderström   http://www.md.kth.se/~chr

Re: cvs complie error

2003-10-29 Thread Gandalf GreyHair

> I think the way that we specify the numbering could be improved (perhaps
> a slider or something ? ). Not sure.
That might be more affordable.

> What would be in "placement" ??
> This doesn't sound like a suitable thing to have in this dialog IMHO.
Well, let's skip it then. 

> (Trivial: the dialog needs cleaning up in terms of layout)
You would cry if you saw my webpages :-)

Re: DISPATCHED_POP - explanation

Andre Poenitz <[EMAIL PROTECTED]> writes:

| On Wed, Oct 29, 2003 at 01:21:51PM +0100, Lars Gullik Bjønnes wrote:
>> Andre Poenitz <[EMAIL PROTECTED]> writes:
>> 
>> | On Wed, Oct 29, 2003 at 01:07:44PM +0100, Lars Gullik Bjønnes wrote:
>> >> 
>> >> Can someone (Andre), please explain do me what DISPATCHED_POP is used
>> >> for?
>> >
>> | The inset has handled the request, but the the cursor must leave the
>> | inset now. 
>> 
>> Ok, in what way is this different from FINISHED?
>
| The one is used in src/mathed and the other in src/insets ;-}

I know, and I am working slowly to unify things (as are you I belive).

| Note that the common dispatch() for mathed and insets is a fairly recent
| invention...

right.

I just changed DISPATCHED_POP to FINISHED_POP. (and will commit that)

But you are saying that my next patch just as well can change
FINISHED_POP to just FINISHED?

-- 
Lgb

Re: DISPATCHED_POP - explanation

On Wed, Oct 29, 2003 at 02:01:21PM +0100, Lars Gullik Bjønnes wrote:
> But you are saying that my next patch just as well can change
> FINISHED_POP to just FINISHED?

Presumably.

Andre'

[patch] dispatch 3

? Config
? dispatchresult-2.diff
? dispatchresult-3.diff
? dispatchresult.diff
? src/doit.sh
Index: src/dispatchresult.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/dispatchresult.h,v
retrieving revision 1.2
diff -u -p -r1.2 dispatchresult.h
--- src/dispatchresult.h	29 Oct 2003 13:24:55 -	1.2
+++ src/dispatchresult.h	29 Oct 2003 13:27:47 -
@@ -35,8 +35,7 @@ enum dispatch_result_t {
 	FINISHED,
 	FINISHED_RIGHT,
 	FINISHED_UP,
-	FINISHED_DOWN,
-	FINISHED_POP
+	FINISHED_DOWN
 };
 
 /** \c DispatchResult is a wrapper for dispatch_result_t.
Index: src/mathed/math_cursor.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_cursor.C,v
retrieving revision 1.365
diff -u -p -r1.365 math_cursor.C
--- src/mathed/math_cursor.C	29 Oct 2003 13:24:57 -	1.365
+++ src/mathed/math_cursor.C	29 Oct 2003 13:27:47 -
@@ -1439,7 +1439,7 @@ DispatchResult MathCursor::dispatch(Func
 		CursorPos & pos = Cursor_[i];
 		DispatchResult res = pos.inset_->dispatch(cmd, pos.idx_, pos.pos_);
 		if (res != UNDISPATCHED) {
-			if (res == FINISHED_POP) {
+			if (res == FINISHED) {
 Cursor_.shrink(i + 1);
 selClear();
 			}
Index: src/mathed/math_gridinset.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_gridinset.C,v
retrieving revision 1.128
diff -u -p -r1.128 math_gridinset.C
--- src/mathed/math_gridinset.C	29 Oct 2003 13:24:57 -	1.128
+++ src/mathed/math_gridinset.C	29 Oct 2003 13:27:48 -
@@ -1072,12 +1072,12 @@ DispatchResult MathGridInset::priv_dispa
 idx = nargs() - 1;
 			if (pos > cell(idx).size())
 pos = cell(idx).size();
-			return FINISHED_POP;
+			return FINISHED;
 
 		case LFUN_CELL_SPLIT:
 			//recordUndo(bv, Undo::ATOMIC);
 			splitCell(idx, pos);
-			return FINISHED_POP;
+			return FINISHED;
 
 		case LFUN_BREAKLINE: {
 			//recordUndo(bv, Undo::INSERT);
@@ -1096,7 +1096,7 @@ DispatchResult MathGridInset::priv_dispa
 			pos = cell(idx).size();
 
 			//mathcursor->normalize();
-			return FINISHED_POP;
+			return FINISHED;
 		}
 
 		case LFUN_TABULAR_FEATURE: {
@@ -1152,8 +1152,8 @@ DispatchResult MathGridInset::priv_dispa
 swapCol(col(idx));
 			else
 return UNDISPATCHED;
-			lyxerr << "returning DISPATCHED_POP" << endl;
-			return FINISHED_POP;
+			lyxerr << "returning FINISHED" << endl;
+			return FINISHED;
 		}
 
 		case LFUN_PASTE: {
@@ -1184,7 +1184,7 @@ DispatchResult MathGridInset::priv_dispa
 	for (col_type c = 0; c < grid.ncols(); ++c)
 		cell(i).append(grid.cell(grid.index(r, c)));
 			}
-			return FINISHED_POP;
+			return FINISHED;
 		}
 
 		default:
Index: src/mathed/math_hullinset.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_hullinset.C,v
retrieving revision 1.99
diff -u -p -r1.99 math_hullinset.C
--- src/mathed/math_hullinset.C	29 Oct 2003 13:24:57 -	1.99
+++ src/mathed/math_hullinset.C	29 Oct 2003 13:27:48 -
@@ -782,7 +782,7 @@ DispatchResult MathHullInset::priv_dispa
 mutate("eqnarray");
 idx = 1;
 pos = 0;
-return FINISHED_POP;
+return FINISHED;
 			}
 			return MathGridInset::priv_dispatch(cmd, idx, pos);
 
@@ -837,7 +837,7 @@ DispatchResult MathHullInset::priv_dispa
 
 		case LFUN_MATH_EXTERN:
 			doExtern(cmd, idx, pos);
-			return FINISHED_POP;
+			return FINISHED;
 
 		case LFUN_MATH_MUTATE: {
 			lyxerr << "Hull: MUTATE: " << cmd.argument << endl;
@@ -849,14 +849,14 @@ DispatchResult MathHullInset::priv_dispa
 idx = nargs() - 1;
 			if (pos > cell(idx).size())
 pos = cell(idx).size();
-			return FINISHED_POP;
+			return FINISHED;
 		}
 
 		case LFUN_MATH_DISPLAY: {
 			mutate(type_ == "simple" ? "equation" : "simple");
 			idx = 0;
 			pos = cell(idx).size();
-			return FINISHED_POP;
+			return FINISHED;
 		}
 
 		default:

-- 
Lgb

Re: [patch] dispatch 3

On Wed, Oct 29, 2003 at 02:33:40PM +0100, Lars Gullik Bjønnes wrote:

Ok...

Andre'

Re: ostream v.s. ostream.h

On Tue, 28 Oct 2003, Jose' Matos wrote:

> > Unless you are ranting, I was mainly thinking about users who would like
> > to be able to install lyx 1.4 on RH 7.3...
> > (it's strange, but later versions of RH need better hardware...)
> 
>   What is strange here?

I was being ironic... 

>   Obviously you put this script in wiki, I suppose? ;-)

Bah.. now you made me do it... I even documented the bloody thing.

  http://wiki.lyx.org/pmwiki.php/DevelScriptBuildLyx/DevelScriptBuildLyx

/Christian

-- 
Christian Ridderström   http://www.md.kth.se/~chr

Re: prosper.layout

On Wednesday 29 October 2003 12:47, Christian Ridderström wrote:
> >
> >   And also another from John Weiss.
> >   Christian some more bits about this soomewhere in the wiki.
>
> Uh.. I get "syntax error" on the sentence above, but I don't think I've

  How many should we tell you to upgrade your compiler? ;-)

> put it in the wiki (yet), instead see
>   http://www.md.kth.se/~chr/lyx/examples/prosper/

  Would it be too difficult to put there just a link?
  Please. :-)

> /Christian

-- 
José Abílio

LyX and docbook, a perfect match. :-)

Re: ostream v.s. ostream.h

On Wednesday 29 October 2003 13:58, Christian Ridderström wrote:

> I was being ironic...

  Oh, ok. :-)

> >   Obviously you put this script in wiki, I suppose? ;-)
>
> Bah.. now you made me do it... I even documented the bloody thing.

  I learned with the masters. (Are you hearing Jean-Marc? ;-)

>   http://wiki.lyx.org/pmwiki.php/DevelScriptBuildLyx/DevelScriptBuildLyx

  Thanks. :-)

> /Christian

-- 
José Abílio

LyX and docbook, a perfect match. :-)

Re: prosper.layout

On Wed, 29 Oct 2003, Jose' Matos wrote:

> > Uh.. I get "syntax error" on the sentence above, but I don't think I've
> 
>   How many should we tell you to upgrade your compiler? ;-)

This one is internal unfortunately :-)

>   Would it be too difficult to put there just a link?
>   Please. :-)

I might as well move it to the wiki now, since I'll loose the area where 
the example is stored eventually anyway.

/C

-- 
Christian Ridderström   http://www.md.kth.se/~chr

Re: ostream v.s. ostream.h

2003-10-29 Thread Jean-Marc Lasgouttes

> "Jose'" == Jose' Matos <[EMAIL PROTECTED]> writes:

>> > Obviously you put this script in wiki, I suppose? ;-)
>> 
>> Bah.. now you made me do it... I even documented the bloody thing.

Jose'>   I learned with the masters. (Are you hearing Jean-Marc? ;-)

I did not know I was as annoying as that :)

JMarc

Account

Hi Lars

I hope it's you I'm supposed to talk about accounts. 
I'd like to get a CVS-account (mainly so that I can use 'cvs add').

If possible, I'd also like an account that allows me to modify the 
pmwiki/local.php-file (I want to change it so that I can upload examples 
in PDF).

Oh, given my mail adress, it shouldn't be surprsining that I prefer 'chr' 
as username...

regards,
Christian

-- 
Christian Ridderström   http://www.md.kth.se/~chr

Re: http://www.lyx.org/

2003-10-29 Thread Jean-Marc Lasgouttes

> "Hartmut" == Hartmut Haase <[EMAIL PROTECTED]> writes:

Hartmut> Hi Jean-marc, why is http://www.lyx.org/ NOT displayed
Hartmut> correcty with Opera7.1? 

I _really_ do not know. I added lyx-devel in cc:, since presumably sme
people there will know more about it. What is wrong with opera?

JMarc

Re: http://www.lyx.org/

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

>> "Hartmut" == Hartmut Haase <[EMAIL PROTECTED]> writes:
>
| Hartmut> Hi Jean-marc, why is http://www.lyx.org/ NOT displayed
| Hartmut> correcty with Opera7.1? 
>
| I _really_ do not know. I added lyx-devel in cc:, since presumably sme
| people there will know more about it. What is wrong with opera?

Do we still validate as xhtml? Does our css still validate?

Could be opera bugs...

-- 
Lgb

Re: ostream v.s. ostream.h

On Wednesday 29 October 2003 17:08, Jean-Marc Lasgouttes wrote:
>
> Jose'>   I learned with the masters. (Are you hearing Jean-Marc? ;-)
>
> I did not know I was as annoying as that :)

  Not annoying but persuasive. :-)
> JMarc

-- 
José Abílio

LyX and docbook, a perfect match. :-)

Re: [patch] Wild dispatch patch - non-working

Lars Gullik Bjønnes wrote:

> This patch is too bid, too full of errors to go in, but shows a bit
> the direction I am going in. I am going to do this is smaller steps,
> and the result will hopefulle be a bit better than this...

I _think_ I like it, but it's too big to take in in one go.

However, I think that I'd prefer
return DispatchResult(false);
rather than
return DispatchResult();

Also call the Cursor member function statusSet rather than statSet.

Have a good evening,

[Patch] are mice mouses if buttoned?

2003-10-29 Thread Martin Vermeer

If so, then ignore this patch. If not, please apply :-)

This makes my toes curl upward.

- Martin

Index: dispatchresult.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/dispatchresult.h,v
retrieving revision 1.1
diff -u -p -r1.1 dispatchresult.h
--- dispatchresult.h29 Oct 2003 10:47:12 -  1.1
+++ dispatchresult.h29 Oct 2003 18:34:24 -
@@ -14,18 +14,18 @@
 #define DISPATCH_RESULT_H
 
 /** Dispatch result codes
-   DISPATCHED  = the inset catched the action
-   DISPATCHED_NOUPDATE = the inset catched the action and no update
+   DISPATCHED  = the inset caught the action
+   DISPATCHED_NOUPDATE = the inset caught the action and no update
is needed here to redraw the inset
FINISHED= the inset must be unlocked as a result
of the action
FINISHED_RIGHT  = FINISHED, but put the cursor to the RIGHT of
the inset.
-   FINISHED_UP = FINISHED, but put the cursor UP of
+   FINISHED_UP = FINISHED, but put the cursor UP from
the inset.
-   FINISHED_DOWN   = FINISHED, but put the cursor DOWN of
+   FINISHED_DOWN   = FINISHED, but put the cursor DOWN from
the inset.
-   UNDISPATCHED= the action was not catched, it should be
+   UNDISPATCHED= the action was not caught, it should be
dispatched by lower level insets
 */
 enum dispatch_result_t {


pgp0.pgp
Description: PGP signature

Re: http://www.lyx.org/

On Wed, 29 Oct 2003, Lars Gullik Bjønnes wrote:

> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
> 
> >> "Hartmut" == Hartmut Haase <[EMAIL PROTECTED]> writes:
> >
> | Hartmut> Hi Jean-marc, why is http://www.lyx.org/ NOT displayed
> | Hartmut> correcty with Opera7.1? 
> >
> | I _really_ do not know. I added lyx-devel in cc:, since presumably sme
> | people there will know more about it. What is wrong with opera?
> 
> Do we still validate as xhtml? Does our css still validate?
> 
> Could be opera bugs...

I've been using Opera for a long time, but I can't remember any problems 
with www.lyx.org? Just checked with 7.21 and the first page looks fine...
But I didn't have any problems with 7.11 either...

/Christian

-- 
Christian Ridderström   http://www.md.kth.se/~chr

Re: [patch] Wild dispatch patch - non-working

Angus Leeming <[EMAIL PROTECTED]> writes:

| Lars Gullik Bjønnes wrote:
>
>> This patch is too bid, too full of errors to go in, but shows a bit
>> the direction I am going in. I am going to do this is smaller steps,
>> and the result will hopefulle be a bit better than this...
>
| I _think_ I like it, but it's too big to take in in one go.
c>
| However, I think that I'd prefer
|   return DispatchResult(false);
| rather than
|   return DispatchResult();

yeah, I thought about this also.

The worst error in this patch is the fact that FINISHED is somethimes
used as DISPATCHED|FINISHED_XXX and other times as
UNDISPATCHED|FINISHED_XXX. You have to check where and how functions
are called to figure out which variant. I have made it bee
DISPATCHED|FINISHED_XXX all over.

Also DISPATCHED should transform to DispatchResult(true,
DispatchResult::UPDATE), and not just DisaptchResult(true) as I have
done.

| Also call the Cursor member function statusSet rather than statSet.

Or something completely different :-)

I'll continue with the small step approach...

-- 
Lgb

Re: [Patch] are mice mouses if buttoned?

Martin Vermeer <[EMAIL PROTECTED]> writes:

| If so, then ignore this patch. If not, please apply :-)
>
| This makes my toes curl upward.

I won't apply this just know. Hopefully int the near futurue the whole
dispatch_result_t will be gone.

-- 
Lgb

linuxdoc and docbook cleanup.

Hello,
I am cleaning the linuxdoc and docbook code.

Attached follows a path, where I move some functions and factorise code like 
it is done with the latex backend.

+720 lines
- 816 lines

This bit intends to catch André's attention. ;-)

After this I intend to work further in the linuxdocParagraph and 
docbookParagraph to make the code easier to understand. It will follow a 
recursive scheme instead of the present iterative approach. This will prove 
to be easier to understand and debug. Again this will mimic the latex code.

Comments.
-- 
José Abílio

LyX and docbook, a perfect match. :-)


patch-lyx.gz
Description: GNU Zip compressed data

Re: [patch] more 'global cursor' infrastructure

2003-10-29 Thread Alfredo Braunstein

Andre Poenitz wrote:

> See attached.
> 
> Still inactive (but 'dispatch to tip' starts to become functional...)

Cool. Does it still have problems with "insets embedded in insets" etc?
(There seems to exist code in cursor.C that suggest that)

Alfredo

Re: InseetExternal can now preview stuff too

This patch allows me to see external tgif insets on screen and as dvi.

An annoying problem was that you are not allowed to have comments inside 
items... i.e. it breaks if you have something like:

Template Tgif
# a comment
GuiName "Tgif: $$Basename"
...



/Christian

-- 
Christian Ridderström   http://www.md.kth.se/~chr
Index: external_templates
===
RCS file: /cvs/lyx/lyx-devel/lib/external_templates,v
retrieving revision 1.21
diff -u -r1.21 external_templates
--- external_templates  2003/10/07 22:59:56 1.21
+++ external_templates  2003/10/29 20:42:35
@@ -142,6 +142,31 @@
 TemplateEnd
 
 
+Template Tgif
+   GuiName "Tgif: $$Basename"
+   HelpText
+   A Tgif figure.
+   This template uses Tgif for editing.
+   HelpTextEnd
+   InputFormat tgif
+   FileFilter "*.(obj|gif)"
+   EditCommand "tgif $$FName"
+   AutomaticProduction true
+   Transform Rotate
+   Transform Resize
+   Format LaTeX
+   TransformCommand Rotate RotationLatexCommand
+   TransformCommand Resize ResizeLatexCommand
+   Product 
"$$RotateFront$$ResizeFront\\input{$$Basename.pstex_t}$$ResizeBack$$RotateBack"
+   UpdateFormat pstex
+   UpdateResult "$$Basename.pstex_t"
+   Requirement "graphicx"
+   Preamble WarnNotFound
+   Preamble InputOrWarn
+   FormatEnd
+TemplateEnd
+
+
 Template ChessDiagram
GuiName "Chess: $$Basename"
HelpText

Re: linuxdoc and docbook cleanup.

"Jose' Matos" <[EMAIL PROTECTED]> writes:

| Hello,
|   I am cleaning the linuxdoc and docbook code.
>
|   Attached follows a path, where I move some functions and factorise code like 
| it is done with the latex backend.
>
|   +720 lines
|   - 816 lines
>
|   This bit intends to catch André's attention. ;-)
>
|   After this I intend to work further in the linuxdocParagraph and 
| docbookParagraph to make the code easier to understand. It will follow a 
| recursive scheme instead of the present iterative approach. This will prove 
| to be easier to understand and debug. Again this will mimic the latex code.
>
|   Comments.

Step in the right direction.

I am not sure about adding the funcs to Paragraph, if possible we
should keep them as free funcs. (also the latex code if practical)

But yes, this moves us forward.

-- 
Lgb

Re: InseetExternal can now preview stuff too

Christian Ridderström wrote:

> This patch allows me to see external tgif insets on screen and as
> dvi.

Fantastic effort!
However, the stuff within the LaTeXblock looks wrong.
1. Is the UpdateResult really "$$Basename.pstex_t"?
2. '\input' doesn't require 'InputOrWarn' or 'WarnNotFound'.
'\inputOrWarn' would though.

> An annoying problem was that you are not allowed to have comments
> inside items... i.e. it breaks if you have something like:
> 
> Template Tgif
> # a comment
> GuiName "Tgif: $$Basename"
> ...

That should not be so. In fact, I have no problems adding comments at 
all. Try running 'lyx -dbg lyxlex' to see if you can track down the 
problem. Here, this :

Template RasterImage
# This is what is displayed on the LyX screen.
GuiName "Bitmap: $$Basename"
...

Results in this output:

Comment read: `# part of the official LyX distribution.'
Comment read: `# Feel free to create your own External Templates, 
storing them in'
Comment read: `# .lyx/external_templates'
Comment read: `# This is what is displayed on the LyX screen.'
text not available!
no text in cache!
Redraw screen

-- 
Angus

Re: InseetExternal can now preview stuff too

On Thu, 23 Oct 2003, Angus Leeming wrote:

> I guess that one of these templates needs extensive in-place 
> documentation (to act as a template for the template?)

I created an area where you can add some documentation/comments on the 
templates...

http://wiki.lyx.org/pmwiki.php/ExternalTemplates/ExternalTemplates

/Christian

-- 
Christian Ridderström   http://www.md.kth.se/~chr

Re: InseetExternal can now preview stuff too

Christian Ridderström wrote:

> On Thu, 23 Oct 2003, Angus Leeming wrote:
> 
>> I guess that one of these templates needs extensive in-place
>> documentation (to act as a template for the template?)
> 
> I created an area where you can add some documentation/comments on
> the templates...
> 
> 
http://wiki.lyx.org/pmwiki.php/ExternalTemplates/ExternalTemplates

Well I've made a start, but really I think that this info should go in 
the external_templates file itself.

-- 
Angus

Re: [patch] dispatch-5.diff - beware

Lars Gullik Bjønnes wrote:

> This patch introduces the DispatchResult::dispatched() function and
> removes DISPATCHED, UNDISPATCHED from dispatch_result_t, and changes
> DISPATCHED_NOUPDATE to NOUPDATE in dispatch_reuslt_t,

The comment in dispatchresult.h still refers to DISPATCHED_NOUPDATE.

Do you still need the default constructor for DispatchResult?

This is a bit ugly, don't you think?
cursor.dispatch(FuncRequest(func, view())).dispatched()

As dispatched() now returns a bool, why not rename it as success()? 
The code above is then very elegant.

Ditto, here
result = inset->dispatch(FuncRequest(view(), action, argument));
if (result.dispatched()) {

If you were to change 'result' to 'dispatch', the code would read
if (dispatch.success()) {

(Don't get me wrong; I think your code is a change for the good. I'm 
just commenting on it since you posted it.)

Staying on the subject of names:
if (result.val() == FINISHED) {

why not rename val() as status()?
if (dispatch.status() == FINISHED) {

-- 
Angus

Re: [patch] dispatch-5.diff - beware

2003-10-29 Thread Kuba Ober

> As dispatched() now returns a bool, why not rename it as success()?
> The code above is then very elegant.
[...]
> Staying on the subject of names:
> if (result.val() == FINISHED) {
>
> why not rename val() as status()?
> if (dispatch.status() == FINISHED) {

Just by looking at the proposed change, I second Angus. It sounds better and I 
admit if I were to start working on that source, I would catch meaning of 
status() and success() immediately, while val() is very cryptic and 
dispatched() only slightly less so.

Just an independent opinion in our opinionated world :)

Cheers, Kuba

Re: [patch] dispatch-5.diff - beware

Angus Leeming <[EMAIL PROTECTED]> writes:

| Lars Gullik Bjønnes wrote:
>
>> This patch introduces the DispatchResult::dispatched() function and
>> removes DISPATCHED, UNDISPATCHED from dispatch_result_t, and changes
>> DISPATCHED_NOUPDATE to NOUPDATE in dispatch_reuslt_t,
>
| The comment in dispatchresult.h still refers to DISPATCHED_NOUPDATE.

I almost changed it, and I almost deleted it, so I decided to leave it
for the time being.

| Do you still need the default constructor for DispatchResult?

probably not
later patch

| This is a bit ugly, don't you think?
| cursor.dispatch(FuncRequest(func, view())).dispatched()

| As dispatched() now returns a bool, why not rename it as success()? 
| The code above is then very elegant.

Well it depends... remember that we are executing a FuncRequest, if it
were dispatched or not does not _really_ mean that is was successful
or unsuccessful.

f.ex. if cursor at the last position in the doc and then LFUN_RIGHT.
Then LFUN was dispatched alright, but it was not successful.

a better name could be "handled" perhaps.

| Ditto, here
| result = inset->dispatch(FuncRequest(view(), action, argument));
| if (result.dispatched()) {
>
| If you were to change 'result' to 'dispatch', the code would read
| if (dispatch.success()) {

This would then be:

 if (result.handled()) {

(but then the variable should probably change name again)

I have some notion to rename DispatchResult to FuncResult as well...
(but this should really only be a member of DispatchResult...)

| (Don't get me wrong; I think your code is a change for the good. I'm 
| just commenting on it since you posted it.)
>
| Staying on the subject of names:
| if (result.val() == FINISHED) {
>
| why not rename val() as status()?
| if (dispatch.status() == FINISHED) {

later patch.

-- 
Lgb

Re: InseetExternal can now preview stuff too