[fell@shore.net] Feedback from www.lyx.org

[Lars Gullik Bjønnes]

--- Start of forwarded message ---
Date: Fri, 19 May 2000 20:29:16 +0200
Message-Id: <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Feedback from www.lyx.org
FROM: [EMAIL PROTECTED]


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


I am trying to install Lyx on redhat linux 6.2 and find the following error 
messages :
cannot find libforms or libxforms. Please check that the xforms libray is 
correctly installed on your system.
Cannot find forms.h. Please check that the forms  libray etc.

Two questions. Where does lyx expect to find the xforms and forms libraries?
Where do I obtain these libraries as a search of my system came up negative?
Thanks very much. I hope to use lyx to help finish our latest paper to
be submitted to Physical Review.

Dick Fell

--- End of forwarded message ---

Re: TOC,LOT,LOF

[Lars Gullik Bjønnes]

Dekel Tsur <[EMAIL PROTECTED]> writes:

| On Thu, May 18, 2000 at 05:54:42PM -0300, Garst R. Reese wrote:
| > When I open a document with a Table of Contents, I can click and see it.
| > AIRC it was me who requested and got this neat feature.
| > It would be nice if List of Figures and ...Tables did the same.
| 
| Done.
| A patch will soon follows.

I like the new TOC menu, but am somewhat reluctant to the REFs one, I
belove the varioref and prettyref support is too crude.

Lgb

Re: Compilation of lyx-devel of May 16th

[Lars Gullik Bjønnes]

Michael Schmitt <[EMAIL PROTECTED]> writes:

| "../../src/lyxparagraph.h", line 531: Error: LyXParagraph::InsetTable is
| not accessible from LyXParagraph::matchIT.
| "../../src/lyxparagraph.h", line 538: Error: LyXParagraph::InsetTable is
| not accessible from LyXParagraph::matchIT.   

Can you check if 

friend LyXParagraph::matchIT;

or 

friend struct LyXParagraph::matchIT;

works better than:

friend struct matchIT;

| "math_iter.h", line 265: Warning: MathedXIter::SetData hides the
| function MathedIter::SetData(LyxArrayBase* ).

Probably ok.

| "../../src/vspace.h", line 157: Warning: LyXGlueLength::operator== hides
| the function LyXLength::operator== (const LyXLength&) const.

Ok, fixed.

| "formula.C", line 432: Warning: font hides the same name in an outer
| scope.

fixed.

| "formula.C", line 1050: Warning: result hides the same name in an outer
| scope.

This is weird.
Probably fixed.

| 
| "bindtextdom.c", line 116: warning: implicitly declaring function to
| return int: strdup()

Bug in C header files?

| "bindtextdom.c", line 116: warning: improper pointer/integer
| combination: op "="
| "bindtextdom.c", line 148: warning: improper pointer/integer
| combination: op "="
| "bindtextdom.c", line 164: warning: improper pointer/integer
| combination: op "="

What strange C compiler are you using?

| "loadmsgcat.c", line 65: warning: old style function definition

don't use C99 on these files stay with C89

Lgb

Re: Compilation with Sun CC 5.0 - Errors

[Lars Gullik Bjønnes]

schmitt <[EMAIL PROTECTED]> writes:

| ===
| RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
| retrieving revision 1.12
| diff -r1.12 BufferView_pimpl.C
| 472c472
| <   pair p = workarea->getScrollbarBounds();
| ---
| >   pair p = workarea->getScrollbarBounds();

As said earlier: This is only needed becasue of buggy C++ lib
but it is correct that getScrollbarBounds return a
pair... I consider that a bug in the XForms lib.

| Index: src/language.C
| ===
| RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/language.C,v
| retrieving revision 1.4
| diff -r1.4 language.C
| 9c9
| < Language ignore_lang = {"ignore", "Ignore", false};
| ---
| > Language ignore_lang( "ignore", "Ignore", false );

What error messages do you get from the compiler with the { ... }
initializer?

| Index: src/language.h
| ===
| RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/language.h,v
| retrieving revision 1.5
| diff -r1.5 language.h
| 8a9,12
| > Language() {};
| >   Language( string lang, string display, bool RightToLeft ) :
| >  lang( lang ), display( display ), RightToLeft( RightToLeft ) {};
| >
| Index:
| src/layout.C   
 
I'll do this change since it is cleaner than the initializer list
anyway.

| ===
| RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/layout.C,v
| retrieving revision 1.24
| diff -r1.24 layout.C
| 1330c1330
| <   return make_pair(true, cit - classlist.begin());
| ---
| >   return make_pair(true, static_cast( cit - 
|classlist.begin()));
| 1359c1359
| <   return make_pair(true, LYX_DUMMY_LAYOUT);
| ---
| >   return make_pair(true, static_cast< unsigned >(
| LYX_DUMMY_LAYOUT ) );

Note that "unsigned" is not a valid type anymore, "unsigned int" shold
be used.
We should probably se "size_type" instead anyway.
(This should really not be needed, it is your stupid C++ lib that
forces this cast upon us.)

| Index: src/lyx_gui_misc.C
| ===
| RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyx_gui_misc.C,v
| retrieving revision 1.20
| diff -r1.20 lyx_gui_misc.C
| 399c399
| < return make_pair(true, tmp);
| ---
| > return make_pair(true, string( tmp ));

ditto!

| Index: src/lyx_main.C
| ===
| RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyx_main.C,v
| retrieving revision 1.34
| diff -r1.34 lyx_main.C
| 35a36
| > using std::signal;
| Index: src/lyxparagraph.h

This will probably not work egcs, I'll check.

|  
| ===
| RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxparagraph.h,v
| retrieving revision 1.33
| diff -r1.33 lyxparagraph.h
| 515c515
| < private:
| ---
| > public:
| 525a526
| > private:
| Index: src/text2.C

The "friend struct matchIT;" are supposed to fix this.
Does your compiler have a problem with friends?

| RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_symbols.C,v
| retrieving revision 1.26
| diff -r1.26 math_symbols.C
| 546c546
| <   char * sx = strstr(data[2], "");
| ---
| >   char * sx = const_cast< char * >( strstr(data[2], "") );

Fair enough.

Lgb

Re: TOC,LOT,LOF

[Dekel Tsur]

On Thu, May 18, 2000 at 05:54:42PM -0300, Garst R. Reese wrote:
> When I open a document with a Table of Contents, I can click and see it.
> AIRC it was me who requested and got this neat feature.
> It would be nice if List of Figures and ...Tables did the same.

Done.
A patch will soon follows.

Re: Purify reports #3

[Lars Gullik Bjønnes]

Michael Schmitt <[EMAIL PROTECTED]> writes:

| Hi,
| 
| I opened a new file, entered a few characters and a figure (without
| specifying an eps file). When I added some more characters, I received
| the following messages:
| 
|   FMR: Free memory read
|   This is occurring while in:
| do_keyboard[libforms.a]

I don't think this is us. I'll blame XForms.

Lgb

Re: Bug in CVS 18/05/00 #2.2

[Lars Gullik Bjønnes]

Michael Schmitt <[EMAIL PROTECTED]> writes:

| I got another warning when clicking at the end of the loaded document:
| 
|   UMR: Uninitialized memory read
|   This is occurring while in:
| int
| WorkArea::work_area_handler(flobjs_*,int,int,int,int,void*)
| [WorkArea.C:299]

Hmm, this is either the X lib or XForms not initializing one or more
variables in the event struct. Strange.

Lgb
| ==

Re: Bug in CVS 18/05/00 #6

[Lars Gullik Bjønnes]

Michael Schmitt <[EMAIL PROTECTED]> writes:

|   UMR: Uninitialized memory read (2 times)
|   This is occurring while in:
| bool MathedXIter::Next() [math_iter.C:632]

Ok, should be fixed now.

Lgb

Re: Bug in CVS 18/05/00 #5

[Lars Gullik Bjønnes]

Michael Schmitt <[EMAIL PROTECTED]> writes:

| Hi,
| 
| yet another bug report. 

Can you have a look at this Jürgen?

Lgb

Re: Bug in CVS 18/05/00 #4

[Lars Gullik Bjønnes]

Michael Schmitt <[EMAIL PROTECTED]> writes:

| I opened a couple of files (it seems like two are not sufficient), made
| _no_ changes, then opened one of them again (reloaded).

Is this repeatable?
And this is the the cvs version, right?

|   FMR: Free memory read
|   This is occurring while in:
| bool text_fits::operator()(LyXText*&)
| [QCfYDL9Ishn54ITXVBUe.o]
| __type_0
| std::find_if(__type_0,__type_0,__type_1)
| [algorithm]

The only reason why this should happen is if there is a text* in the
TextCache that is not supposed to be there. (it would point into the
void), for the revert/reload I can't see how this can happen,
BufferStorage::release should take care of it.

What platform was this on?
Can this be a platform issue?

Jean-Marc, can you see this when you run purify?

Lgb

Re: parentheticals

[Garst R. Reese]

Dekel Tsur wrote:

> The following patch should work.
> 
Thanks, that told me what I needed to know.
I will make the appropriate changes.
FADE OUT btw does not take any arguments.
FADE IN: does, e.g., FADE IN: ON RINGING TELPHONE

Garst

Re: New citation dialog

[Dekel Tsur]

On Fri, May 19, 2000 at 05:10:22PM +0200, Jean-Marc Lasgouttes wrote:
> 
> If I see correctly, there is an error on the console when reading the
> file:
> 
> fantomas: src/lyx
> LyX: \end_deeper: depth is already null [around line 7992 of file 
>~/src/lyx/lyxdoc/UserGuide.lyx]
> LyX: \end_deeper: depth is already null [around line 9054 of file 
>~/src/lyx/lyxdoc/UserGuide.lyx]
> 
> Somehow, the reading of depth has been broken. Then, half of the
> document has depth 1, and of course, this is not a good test case for
> Dekel's code (even loading the UserGuide is horribly painful). First
> thing is to understand why there is a pb with UserGuide.

This is caused by a bug in InsetTabular (for a short period of time, the CVS
code used InsetTabular instead of LyXTable when reading a file. Do a cvs
update to fix this).

Re: SMALL & EASY proposal

[Angus Leeming]

Lars> just create a 

Lars> vector
Lars> stringToVector(string const & s, char delim = ' ') {
Lars>   ...
Lars> }

Lars> That you can use.

As you wish. Shall I place this in lstrings.[Ch] as its analogous to strToInt()?
A.

Re: www.devel.lyx.org

[Lars Gullik Bjønnes]

Angus Leeming <[EMAIL PROTECTED]> writes:

| is showing the contents of www.lyx.org

Hmm, is it? No, it is not.

your dns have baywatch.lyx.org on the wrong ip address

Lgb

Re: SMALL & EASY proposal

[Lars Gullik Bjønnes]

Angus Leeming <[EMAIL PROTECTED]> writes:

| Lars> Perhaps InsetCommand should not be used for these?
| 
| Lars> The InsetCommand was created to deal with simple latex commands, and
| Lars> not with more complex commands. 
| 
| Lars> Perhaps the InsetBibtex (++) should not subclass from InsetCommand.
| 
| Oh dear, I'm not doing very well today, am I!

You are pondering about in the code have questions we about stuff we
though was "working if not perfect" and you make us thing about
alternate aproaches, I'd call that.. hmm.. well.

| However, all I'm proposing is a little data hiding. 

I do not call this data hiding. To me it is more like haveing
InsetCommand::contens be a union.

| All child classes currently access "contents" through getContents().
| Why not access it through getContentsAsString() and
| getContentsAsVector() ?

So then you also need a setDelimForUseWithgetContensAsVector ?
Why can't you just split the contents in the subclass?
just create a 

vector
stringToVector(string const & s, char delim = ' ') {
...
}

That you can use.

I really think that InsetCommand should only be used for insets that
fit into the \command[options]{contents} where contents does not need
massgeing.

btw. setContents in InsetCommand should not be virtual and the
variables should be private.

Lgb

www.devel.lyx.org

[Angus Leeming]

is showing the contents of www.lyx.org

Re: SMALL & EASY proposal

[Angus Leeming]

Lars> Perhaps InsetCommand should not be used for these?

Lars> The InsetCommand was created to deal with simple latex commands, and
Lars> not with more complex commands. 

Lars> Perhaps the InsetBibtex (++) should not subclass from InsetCommand.

Oh dear, I'm not doing very well today, am I!
However, all I'm proposing is a little data hiding. 
All child classes currently access "contents" through getContents().
Why not access it through getContentsAsString() and getContentsAsVector() ?

Angus

Re: Layout menu patch

[Lars Gullik Bjønnes]

Dekel Tsur <[EMAIL PROTECTED]> writes:

| On Fri, May 19, 2000 at 03:00:21PM +0200, Juergen Vigna wrote:
| > > I guess we should have a "default" language. We already have an
| > > "ignore" language, I do not know what the difference is.
| > 
| > Agreed too! The default language in LaTeX terms is the language which my
| > LaTeX installation has as default. So "default" here means just ignore it
| 
| This is not a good thing. It means that the result of your tex/lyx file varies
| between different machines.

Yes. And this is how latex works with respect to language and hyphen
patterns.

| 
| > I don't care about that! So we should have this (we have it as selection
| > in the Document->Layout, so IMO that we should have this in the character
| > Layout too and it just says don't set the language let it as the document
| > default language! Some sort of reset it to default!)
| 
| I think that having the "default" option as a document language is
|confusing.

Not if you come from LaTex.

| For example, what happens if you write a document in the default language,
| and then add a paragraph in French. In the latex file, the languages used in
| the document should be given as optional arguments to the \documentclass 
| command, but what should be used instead of "default"?

You are doomed. Hopefully the user is smart enought to set the
language of the document.
 
| I think that a better option is to remove the "default" language from the
| document languages list, and add two lyxrc variables:
| default_language - the language which is given to new documents

No, not a lyxrc variable. This is more a default template thingie.
(jfr. save as default)

| latex_default_language - the default language of your latex installation.
|  If you have a document only with this language,
|  then in the generated tex file, the babel package is
|not loaded.

We should be able to discover this automatically.

Lgb

Re: Layout menu patch

[Dekel Tsur]

On Fri, May 19, 2000 at 03:00:21PM +0200, Juergen Vigna wrote:
> > I guess we should have a "default" language. We already have an
> > "ignore" language, I do not know what the difference is.
> 
> Agreed too! The default language in LaTeX terms is the language which my
> LaTeX installation has as default. So "default" here means just ignore it

This is not a good thing. It means that the result of your tex/lyx file varies
between different machines.

> I don't care about that! So we should have this (we have it as selection
> in the Document->Layout, so IMO that we should have this in the character
> Layout too and it just says don't set the language let it as the document
> default language! Some sort of reset it to default!)

I think that having the "default" option as a document language is confusing.
For example, what happens if you write a document in the default language,
and then add a paragraph in French. In the latex file, the languages used in
the document should be given as optional arguments to the \documentclass 
command, but what should be used instead of "default"?

I think that a better option is to remove the "default" language from the
document languages list, and add two lyxrc variables:
default_language - the language which is given to new documents
latex_default_language - the default language of your latex installation.
 If you have a document only with this language,
 then in the generated tex file, the babel package is
 not loaded.

Re: SMALL & EASY proposal

[Lars Gullik Bjønnes]

Angus Leeming <[EMAIL PROTECTED]> writes:

| Because my last proposal appeared too hard to implement ;-), I've got a far
| easier one. I've done my research and think I could implement it easily. Now I
| want to ask, do others think it a good idea:
| 
| InsetCommand contains the private variable
|   string contents;
| that is accessed by its daughter classes through
|   string const & getContents() const { return contents; }
|   void setContents( string const & c ) { contents = c; }
|   void addContents(string const & c) { contents += c; }


| 
| In many of these daughter classes (InsetBibtex, InsetCitation etc), contents is
| a comma-separated collection of keys.

Perhaps InsetCommand should not be used for these?

The InsetCommand was created to deal with simple latex commands, and
not with more complex commands. 

Perhaps the InsetBibtex (++) should not subclass from InsetCommand.

Lgb

Re: New citation dialog

[Jean-Marc Lasgouttes]

> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:

Juergen> And while we are on it: Did you try to change the depth of a
Juergen> paragraph in a document like the UserGuide? It takes up 100%
Juergen> of cpu and takes quite a while, I guess this is the code of
Juergen> the vertical depth lines, if yes I really would like to be
Juergen> able to deactivate them as one cannot work in a large
Juergen> document with such large updates on a single action!

If I see correctly, there is an error on the console when reading the
file:

fantomas: src/lyx
LyX: \end_deeper: depth is already null [around line 7992 of file 
~/src/lyx/lyxdoc/UserGuide.lyx]
LyX: \end_deeper: depth is already null [around line 9054 of file 
~/src/lyx/lyxdoc/UserGuide.lyx]

Somehow, the reading of depth has been broken. Then, half of the
document has depth 1, and of course, this is not a good test case for
Dekel's code (even loading the UserGuide is horribly painful). First
thing is to understand why there is a pb with UserGuide.

JMarc

RE: Suggestion

[Juergen Vigna]

On 19-May-2000 Michael Schmitt wrote:
> Hi,
> 
> have you ever noticed that if you enter CTRL-Return in a table cell in order to
> get new lines, you are not able to remove these additional lines any 
> more? If there is a simple way to overcome this problem I would like to see it
> fixed in 1.1.5. I think many users will try to use CTRL-Enter in a table and
> will be wondering what happens to the empty lines.
> 

Did you ever try "Remove Row" from the Table->Layout? ;)

> By the way: It is not possible to select all lines of one cell without
> selecting neighbor cells as well. I think selecting text should be handled
> differently. But, well, probably this feature involves too many changes to be
> integrated in the next release.

This will be fixed with the new tabular insets!

Greets Jürgen

-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Dr. Jürgen Vigna  E-Mail: [EMAIL PROTECTED]
Italienallee 13/N Tel:+39-0471-450260
I-39100 Bozen Fax:+39-0471-450296
ITALY Web:http://www.sad.it/~jug

The three best things about going to school are June, July, and August.

-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

decimal alignment in table

[Edwin Leuven]

perhaps you would like to add the attached to the extended user manual...

gr.ed.

 decimal.lyx

SMALL & EASY proposal

[Angus Leeming]

Because my last proposal appeared too hard to implement ;-), I've got a far
easier one. I've done my research and think I could implement it easily. Now I
want to ask, do others think it a good idea:

InsetCommand contains the private variable
string contents;
that is accessed by its daughter classes through
string const & getContents() const { return contents; }
void setContents( string const & c ) { contents = c; }
void addContents(string const & c) { contents += c; }

In many of these daughter classes (InsetBibtex, InsetCitation etc), contents is
a comma-separated collection of keys.

Sometimes, the keys have to be accessed individually, in which case the string
has to be broken up into individual keys. E.g., in InsetBibtex, the keys are
files whose contents are read.
Sometimes the string is accessed as a single entity. E.g. it is sent to xforms
as a comma-separated string.

There is a lot of code duplication that could be avoided by storing the
contents as
vector contents(1); // additional keys added with push_back
and then accessing it through two methods:
vector const & getContents() const { return contents; }

string getContentsString() const {
string c = contents[0];
for( vector::iterator   iter = ++contents.begin(); 
iter != contents.end(); ++iter ) {
c += ", ";
c += *iter;
}
return c;
}

Is this a Good Idea?
Angus

Re: "dialogbase" branch update and a rant...

[Jean-Marc Lasgouttes]

>>>>> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:

Allan> The update is attached. Someone please: cvs co -r dialogbase -d
Allan> dialogbase lyx-devel cd dialogbase zcat
Allan> ../arrae-2519.patch.gz | patch -p1 cvs add [a bunch of
Allan> files] cvs commit

OK, I just did it. The thing is currently trying to commit. I hope I
got it right. I'll try to compile later. Does it mean that the "rae"
branch is dead?

JMarc

Re: One for the inset gurus

[Lars Gullik Bjønnes]

Angus Leeming <[EMAIL PROTECTED]> writes:

| As a purely hypothetical point:
| It seems to me that the insets have two separate aims.
| 1. To contain some information (In InsetCommand this is cmdname, options, contents)
| 2. To draw the inset on the screen.

yes.

| 
| Would it not be possible to have 
| 
| template 
| class InsetCommand
| {
|   DrawInset di;
|   int ascent(Painter & p, LyXFont const & f) const { return di.ascent( p, f ); }
|   int descent(Painter & p, LyXFont const & f) const { return di.descent( p, f ); 
|}
|   int width(Painter & p, LyXFont const & f) const { return di.width( p, f ); }
|   void drawPainter & p, LyXFont const & f, int , float & x) const { di.draw( p, 
|f ); } }
| 

We don't want ot make InsetCommand a special case. All insets should
be have similary (form Coders POV), this means that if we split data
and view it, will have to be done for all insets.

Lgb

Suggestion

[Michael Schmitt]

Hi,

have you ever noticed that if you enter CTRL-Return in a table cell in order to
get new lines, you are not able to remove these additional lines any 
more? If there is a simple way to overcome this problem I would like to see it
fixed in 1.1.5. I think many users will try to use CTRL-Enter in a table and
will be wondering what happens to the empty lines.

By the way: It is not possible to select all lines of one cell without
selecting neighbor cells as well. I think selecting text should be handled
differently. But, well, probably this feature involves too many changes to be
integrated in the next release.

Michael

-- 
==
Michael Schmittphone: +49 451 500 3725
Institute for Telematics   secretary: +49 451 500 3721
Medical University of Luebeck  fax:   +49 451 500 3722
Ratzeburger Allee 160  eMail: [EMAIL PROTECTED]
D-23538 Luebeck, Germany   WWW:   http://www.itm.mu-luebeck.de
==

funny error message

[Yann MORERE]

Hello,

during the use of my prefered software i got :

i forgive easily don't be frigthened (shit i forgot how it spells)

lyx: SIGSEGV signal caught
Sorry, you have found a bug in LyX. If possible, please read 'Known
bugs'
under the Help menu and then send us a full bug report. Thanks!

lyx: Attempting to save document
/users/laih2/ymorere/lyx/publi/control_letters/control2000.lyx as...
  1)
/users/laih2/ymorere/lyx/publi/control_letters/control2000.lyx.emergency
  Save seems successful. Phew.

this particular message make me laugh "Phew" which spells "Pfiou" in
french

Bye.

[4]Abort processlyx (core dumped)

so i relyx. :-)

Ian

 
-- 
"Y faut liiirrreee, Arlequin, Champion de l'amou" Dany Boon
 ---
(Yann MORERE mailto:[EMAIL PROTECTED] )
(Doctorant Automatique   http://www.multimania.com/ymorere/ )

bug report: crash when pasting X selection from Exceed X server in version 1.1.4fix1

[Frank Dellaert]

Hi
I use Lyx 1.1.4fix1 on RedHat Linux 5.2
I use the PC-based X-server Exceed version 6.0.1.0 under Windows 98.
Pasting from the Exceed X-selection with the middle button invariably makes
Lyx crash.
The Exceed paste works fine in other applications.
I get around the bug by opening emacs and pasting there, then importing
ascii :-)

Message is

  Sorry, you have found a bug in LyX. If possible, please read 'Known bugs'
  under the Help menu and then send us a full bug report. Thanks!
  lyx: Attempting to save document /usr0/dellaert/papers/mcmc/nips2000.lyx
as...
1) /usr0/dellaert/papers/mcmc/nips2000.lyx.emergency
Save seems successful. Phew.
  Bye.

I apologize, but as I installed lyx using rpm, I only have a stripped
executable, and I have no time to download and compile the source, so there
is no backtrace.

Cheers
Frank

[EMAIL PROTECTED] 
Dept. of Computer Science, Carnegie Mellon University
Smith Hall 212, 5000 Forbes Avenue, Pittsburgh PA 15213
http://www.cs.cmu.edu/~dellaert/

Re: One for the inset gurus

[Angus Leeming]

Jürgen> Well to you Angus :), for now you have to live with it that you don't have
Jürgen> that form of half-row, you can only paint 1, 2 or more WHOLE rows. The inset
Jürgen> is always rectangular!

In that case, I see no point in having a multi-row button and will stick with
what we have at the moment. Its ugly but works fine. All other solutions would
also be ugly, so there is nothing to be gained by changing.

As a purely hypothetical point:
It seems to me that the insets have two separate aims.
1. To contain some information (In InsetCommand this is cmdname, options, contents)
2. To draw the inset on the screen.

Would it not be possible to have 

template 
class InsetCommand
{
DrawInset di;
int ascent(Painter & p, LyXFont const & f) const { return di.ascent( p, f ); }
int descent(Painter & p, LyXFont const & f) const { return di.descent( p, f ); 
}
int width(Painter & p, LyXFont const & f) const { return di.width( p, f ); }
void drawPainter & p, LyXFont const & f, int , float & x) const { di.draw( p, 
f ); } }

That way, you could easily (at least the concept is easy!) draw rectangular
insets, as now, or insets that wrap, such as the one I've proposed. I'm not
suggesting that it would be easy to implement; from what I've understood of the
discussion, it would not, however:

Is this an elegant approach or is it fatally flawed? My experience is limited
and I'm willing to learn from a master!

Angus

Re: Layout menu patch

[Juergen Vigna]

On 19-May-2000 Jean-Marc Lasgouttes wrote:
>> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes:
> 
> Dekel> Right now checking if a document has only one language is a
> Dekel> costly operation. However, I can add a boolean member variable
> Dekel> to class Buffer, which will store if the buffer is
> Dekel> multi-lingual or not (the variable will not be 100% accurate,
> Dekel> but it doesn't matter).
> 
> At least, the language should not be displayed if it is the
> document-wide language (like the font is not shown if it is the
> default font).
> 

Agreed!

>>> Also, I do not think that "american" is a proper default language.
>>> "English" would be better, but I really preferred the old
>>> "default". What was the problem with that?
> 
> Dekel> There is no language named "default". Maybe we should use
> Dekel> "English (American)" instead?
> 

And 'American' or 'English (American)' may by your default language it isn't
my for sure and for a whole lot of other people around the world #:O)

> I guess we should have a "default" language. We already have an
> "ignore" language, I do not know what the difference is.

Agreed too! The default language in LaTeX terms is the language which my
LaTeX installation has as default. So "default" here means just ignore it
I don't care about that! So we should have this (we have it as selection
in the Document->Layout, so IMO that we should have this in the character
Layout too and it just says don't set the language let it as the document
default language! Some sort of reset it to default!)

-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Dr. Jürgen Vigna  E-Mail: [EMAIL PROTECTED]
Italienallee 13/N Tel:+39-0471-450260
I-39100 Bozen Fax:+39-0471-450296
ITALY Web:http://www.sad.it/~jug

If I don't see you in the future, I'll see you in the pasture.

-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Re: New citation dialog

[Juergen Vigna]

On 19-May-2000 Dekel Tsur wrote:
> On Fri, May 19, 2000 at 12:02:30PM +0200, Juergen Vigna wrote:
>> 
>> 
>> And one more: I just read the whole UserGuide substituting LyXTable's with
>>   InsetTabular's and ..., it worked :)!
> 
> You got so excited with this, that you haven't noticed that you enabled it
> on the CVS! (line 232 in buffer.C)

#$%&*&* you're right I'll commit a fix immediately!!!

   Jürgen

-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Dr. Jürgen Vigna  E-Mail: [EMAIL PROTECTED]
Italienallee 13/N Tel:+39-0471-450260
I-39100 Bozen Fax:+39-0471-450296
ITALY Web:http://www.sad.it/~jug

Philosophy will clip an angel's wings.
-- John Keats

-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Re: New citation dialog

[Dekel Tsur]

On Fri, May 19, 2000 at 12:02:30PM +0200, Juergen Vigna wrote:
> 
> 
> And one more: I just read the whole UserGuide substituting LyXTable's with
>   InsetTabular's and ..., it worked :)!

You got so excited with this, that you haven't noticed that you enabled it
on the CVS! (line 232 in buffer.C)

Re: Layout menu patch

[Jean-Marc Lasgouttes]

> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes:

Dekel> Right now checking if a document has only one language is a
Dekel> costly operation. However, I can add a boolean member variable
Dekel> to class Buffer, which will store if the buffer is
Dekel> multi-lingual or not (the variable will not be 100% accurate,
Dekel> but it doesn't matter).

At least, the language should not be displayed if it is the
document-wide language (like the font is not shown if it is the
default font).

>> Also, I do not think that "american" is a proper default language.
>> "English" would be better, but I really preferred the old
>> "default". What was the problem with that?

Dekel> There is no language named "default". Maybe we should use
Dekel> "English (American)" instead?

I guess we should have a "default" language. We already have an
"ignore" language, I do not know what the difference is.

JMarc

Re: Layout menu patch

[Dekel Tsur]

On Wed, May 17, 2000 at 02:53:04PM +0200, Jean-Marc Lasgouttes wrote:
> > "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes:

> And Dekel, while I am at it, would it be possible to avoid displaying
> the language when there is only one language used (or when current
> language is document language)?

Right now checking if a document has only one language is a costly
operation. However, I can add a boolean member variable to class Buffer,
which will store if the buffer is multi-lingual or not (the variable will
not be 100% accurate, but it doesn't matter).

> Also, I do not think that "american"
> is a proper default language. "English" would be better, but I really
> preferred the old "default". What was the problem with that?

There is no language named "default".
Maybe we should use "English (American)" instead?

Another issue with multi-lingual support is that if you copy text from an all
English document, and paste it in an all French document, the text will remain
in English, so you get a French-English document.
Maybe we should have the following behavior:
  If the document contains only one language, convert the pasted text into
  the language of the document, and if the document is multi-lingual,
  keep the language of the pasted text unchanged.

Re: One for the inset gurus

[Jean-Marc Lasgouttes]

> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:

Angus> In my case, it would appear all the time. (This being multiple
Angus> citation keys in one citation inset. If the keys have easily
Angus> understandable names, then it only takes two or three to
Angus> produce quite a long inset.) If the key comes at the start of
Angus> the line, no problem. Often however, it comes near the end and
Angus> hence my desire to make it wrap. I was of the impression that
Angus> drawing multiple buttons would affect only
Angus> InsetCommand::draw().

Easy solution: if the width of the button is more that some fixed
value (or half the textwidth), chop the text off and add "...".

JMarc

Re: One for the inset gurus

[Juergen Vigna]

On 19-May-2000 Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> 
>| In my case, it would appear all the time. (This being multiple
>| citation keys in 
>| one citation inset. If the keys have easily understandable names,
>| then it only 
>| takes two or three to produce quite a long inset.) If the key comes at the
>| start of the line, no problem. Often however, it comes near the end and hence
>| my desire to make it wrap. I was of the impression that drawing multiple
>| buttons would affect only InsetCommand::draw().
> 
> Only when you use the whole width. Insets do not usually know how much
> space that is free on a line, not even the painter knows that. If the
> painter knew it would be "easy".
> 

Well they know in a way, but they shouldn't have to care about that! The
problem with insets is that we mix there realtive and absolut positions.
This may be good for the draw(x,baseline), but for example we have to maintain
a absolute x position for the cursor, while the y position is relative!

> Hmmm... otoh we know most of what we need to know throught the
> painter to place the break at the correct spot... the baseline will be
> harder to get right. ... And you also need this information to be in
> the lyxrows in lyxtext.
> 

I think that to be able to have this type of insets we would just have to
return also the value for the new baseline, but I think this is a really
bad move, as think of different fonts and how would you know inside the
inset that the second row of your inset should be higher because there is
a following text with higher font so that in this row ascent/descent change.

The real good move would be that the inset returns the rows it will span,
then LyXText can call a draw for the whole inset or a draw for single rows
(this obviouly only on inset-types with DO span multiple rows). This would
be a really needed change as then LyXText could do a really good work
drawing the insets row by row, and don't draw unneeded stuff. Think of a
tabular inset which spanns 3 whole pages. Think of 1 row as 1 tabular row,
now LyXText can construct it's row-structure also viewing a tabular as
single rows and so do a much better job when having to repaint part of it.

What do you think about this?

Well to you Angus :), for now you have to live with it that you don't have
that form of half-row, you can only paint 1, 2 or more WHOLE rows. The inset
is always rectangular!

Greets Jürgen

-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Dr. Jürgen Vigna  E-Mail: [EMAIL PROTECTED]
Italienallee 13/N Tel:+39-0471-450260
I-39100 Bozen Fax:+39-0471-450296
ITALY Web:http://www.sad.it/~jug

knowledge, n.:
Things you believe.

-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

"dialogbase" branch update and a rant...

[Allan Rae]

The update is attached.  Someone please:
cvs co -r dialogbase -d dialogbase lyx-devel
cd dialogbase
zcat ../arrae-2519.patch.gz | patch -p1
cvs add [a bunch of files]
cvs commit

All new files should be added (just run cvs update for a list)
Don't forget the .cvsignore files.  Then commit it.
Thanks heaps.

Now for the rant:

Next time you want to mess with the code for a dialog change the 
forms/x.fd file not the .C or .h files.  I've just spent a day 
fixing the frigging stuff so I could regenerate the files I had modified. 
Since I have now completely removed form_print and form_copyright from the 
old code.

Plenty of little changes that would have been easy to implement correctly in 
the first place instead of having to reverse engineer a correct solution.  
Devvies, do not ever, _ever_, EVER accept another patch changing gui code 
unless the corresponding *.fd file and possibly fdfix.sh is also updated so 
we can continue using "make updatesrc" in the forms/ subdirectory.

Are your ears red?

end of rant.

Having a good holiday so far.  Only a few days left till I'm in Paris!
Woo hoo!

Allan. (ARRae)
P.S.  CC me if you want me to read your reply.
P.P.S I added C-s and C-r to the key bindings for search/replace dialog
  for those of us who prefer emacs bindings.  This has probably slightly 
screwed the internationalisation -- my turn to stuff something!

Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

 arrae-2519.patch.gz

Re: One for the inset gurus

[Lars Gullik Bjønnes]

Angus Leeming <[EMAIL PROTECTED]> writes:

| In my case, it would appear all the time. (This being multiple
| citation keys in 
| one citation inset. If the keys have easily understandable names,
| then it only 
| takes two or three to produce quite a long inset.) If the key comes at the
| start of the line, no problem. Often however, it comes near the end and hence
| my desire to make it wrap. I was of the impression that drawing multiple
| buttons would affect only InsetCommand::draw().

Only when you use the whole width. Insets do not usually know how much
space that is free on a line, not even the painter knows that. If the
painter knew it would be "easy".

Hmmm... otoh we know most of what we need to know throught the
painter to place the break at the correct spot... the baseline will be
harder to get right. ... And you also need this information to be in
the lyxrows in lyxtext.

Lgb

Re: parentheticals

[Dekel Tsur]

On Thu, May 18, 2000 at 06:40:06PM -0300, Garst R. Reese wrote:
> Dekel Tsur wrote:
> > 
> > On Thu, May 18, 2000 at 05:54:50PM -0300, Garst R. Reese wrote:
> > 
> > > Sasa, I did some testing on using parentheticals at the end of a play or
> > > script.
> > > When you hit Enter, the closing ) goes to the next line and turns black,
> > > but at that point you can select dialogue, and the ) will go back where
> > > it belongs.
> > >
> > 
> > Why didn't you defined the parenthetical layout as a command?
> > And why the \fadein,\interiorshot etc. macros are defined without an argument?
> The best answer is that I didn't know how to put the ) at the end, which
> probably relates to your second question.
> Also, I find that I have set the right margin of the parenthetical to
> that of the dialogue (or less). I don't know how to do that inside a
> command.

The following patch should work.


--- /home/dekel/lyx/lib/tex/hollywood.cls   Wed May 17 19:37:06 2000
+++ hollywood.cls   Fri May 19 14:21:52 2000
@@ -176,10 +176,10 @@
   % hyphenation, but I do not remember how.
   % That's good because we -do not- want any hyphenation.
   \sloppy
-\newcommand{\fadein}{\filbreak\raggedright\par FADE IN: }%
-\newcommand{\fadeout}{\filbreak\raggedright\par FADE OUT }%
-\newcommand{\interiorshot}{\filbreak\raggedright\par INT. }%
-\newcommand{\exteriorshot}{\filbreak\raggedright\par EXT. }%
+\newcommand{\fadein}[1]{\filbreak\raggedright\par FADE IN: #1}%
+\newcommand{\fadeout}[1]{\filbreak\raggedright\par FADE OUT #1}%
+\newcommand{\interiorshot}[1]{\filbreak\raggedright\par INT. #1}%
+\newcommand{\exteriorshot}[1]{\filbreak\raggedright\par EXT. #1}%
 \newenvironment{dialogue}%
 {\raggedright
 \begin{list}{}{%
@@ -200,23 +200,21 @@
 \item[] \ignorespaces}
 {\unskip \end{list}}
 
-\newenvironment{speaker}%
+\newcommand{\speaker}[1]%
 {\filbreak
 \begin{list}{}{%
\setlength{\leftmargin}{2.5in}
 \setlength{\partopsep}{4mm}
 \setlength{\parsep}{0mm}
 \setlength{\topsep}{0mm}}
-\item[] \ignorespaces}
-{\unskip \end{list}}
+\item[] \ignorespaces #1 \unskip \end{list}}
 
-\newenvironment{parenthetical}%
+\newcommand{\parenthetical}[1]%
 {\begin{list}{}{%
\setlength{\leftmargin}{2in}
 \setlength{\parsep}{0mm}
 \setlength{\topsep}{0mm}}
-   \item[](\ignorespaces}
-{\unskip)\end{list}}
+\item[](\ignorespaces #1 \unskip)\end{list}}
 
 
 

Re: One for the inset gurus

[Angus Leeming]

In my case, it would appear all the time. (This being multiple citation keys in
one citation inset. If the keys have easily understandable names, then it only
takes two or three to produce quite a long inset.) If the key comes at the
start of the line, no problem. Often however, it comes near the end and hence
my desire to make it wrap. I was of the impression that drawing multiple
buttons would affect only InsetCommand::draw().

Lars> How often to you imagine that the keyinset will span a whole row?
Lars> If the answer is close to never, I'd prefere to just have a
Lars> simpleinset button and let the text line be ugly.

Lars> text   text   text texttext
Lars> |key1, key2, key3, key4, key5|
Lars> text text text text text

Lars> To support insets with complex shapes will need a lot of changes.

Re: One for the inset gurus

[Lars Gullik Bjønnes]

Angus Leeming <[EMAIL PROTECTED]> writes:

| Many thanks for the advice, Jürgen. It really is scary playing with something
| this complex!
| 
| I have one very simple question. What is your concept of a multirow button? I
| picture it as:
| 
| text text text | key1, key2, | text text 
| text text text | key3, key4, | text text 
| text text text | key5- | text text. (--- is space!)
| 
| whereas, I would like:
| 
| text text text | key1, key2, key3,
| key4 | text text text text text text
| text text text text text text text.

How often to you imagine that the keyinset will span a whole row?
If the answer is close to never, I'd prefere to just have a
simpleinset button and let the text line be ugly.

text   text   text texttext
|key1, key2, key3, key4, key5|
text text text text text

To support insets with complex shapes will need a lot of changes.

Lgb

RE: One for the inset gurus

[Angus Leeming]

Many thanks for the advice, Jürgen. It really is scary playing with something
this complex!

I have one very simple question. What is your concept of a multirow button? I
picture it as:

text text text | key1, key2, | text text 
text text text | key3, key4, | text text 
text text text | key5- | text text. (--- is space!)

whereas, I would like:

text text text | key1, key2, key3,
key4 | text text text text text text
text text text text text text text.

Can I achieve this with your multirow button, or do I really need one button
per row.

Angus

Re: New citation dialog

[Juergen Vigna]

On 19-May-2000 Juergen Vigna wrote:
> 
> On 19-May-2000 Juergen Vigna wrote:
>> 
>> BTW: Did you try to Preview the UserGuide? Please try, it gives 1 error!
>> 
> 
> And one more: I just read the whole UserGuide substituting LyXTable's with
>   InsetTabular's and ..., it worked :)!

And while we are on it: Did you try to change the depth of a paragraph in
a document like the UserGuide? It takes up 100% of cpu and takes quite a
while, I guess this is the code of the vertical depth lines, if yes I really
would like to be able to deactivate them as one cannot work in a large
document with such large updates on a single action!

   Jürgen

-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Dr. Jürgen Vigna  E-Mail: [EMAIL PROTECTED]
Italienallee 13/N Tel:+39-0471-450260
I-39100 Bozen Fax:+39-0471-450296
ITALY Web:http://www.sad.it/~jug

/earth is 98% full ... please delete anyone you can.

-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

RE: One for the inset gurus

[Juergen Vigna]

On 18-May-2000 Angus Leeming wrote:
[snip]
> 
> I looked in insettext.[Ch]. SCARY!
> 

#:O)

>>From what I can see, the methods of importance here are
>   int ascent(Painter &, LyXFont const &) const;
>   int descent(Painter &, LyXFont const &) const;
>   int width(Painter &, LyXFont const &) const;
>   void draw(Painter &, LyXFont const &, int baseline, float & x) const;
> 
> which exist in both InsetText and in the parent class to InsetCitation,
> InsetCommand.
> 
> In InsetCommand, the inset is a button.
> width() returns the width of the button.
> draw() draws the button and updates the current position, "x".
>>From what I can make out, ascent() and descent() return now much above and
> below some datum the button (or is it the font?) reaches.
> 
> So far so good?
> 
> So, if I want to draw an inset over more than one line, I need to draw multiple
> buttons?

Or draw 1 multirow button, but this is not supported now in the Painter, so
you would have to do it by hand! Something as:

vector s; // here are the row-strings I want to paint as button

//
// first calculate with and height
//
int height = 0;
int maxwidth = 0;
for (string::const_iterator sit = s.begin(); sit != s.end(); ++sit) {
height += lyxfont::maxAscent(font) + lyxfont::maxDescent(font) + 2;
maxwidth = max(width, lyxfont::width(sit, font);
}

// now draw

int asc = ascent(pain, font) + 3;

pain.button(x, baseline - asc, maxwidth + 8, height+6);

int cx = int(x) + 4;
int cy = baseline;

for (string::const_iterator sit = s.begin(); sit != s.end(); ++sit) {
text(cx, cy, sit, font);
cy += lyxfont::maxAscent(font) + lyxfont::maxDescent(font) + 2;
}

> 
> How do I proceed?
> I guess the first thing I have to do in InsetCommand::draw() is split
>   string s = getScreenLabel();
> up into its constituent parts (individual keys).
> 
> (A secondary point: getScreenLabel returns a comma separated list of keys.
> Would it be better to return a vector of keys and then insert the
> commas when drawing the label? I think it would. Comments?)
> 
> and then rebuild them so that the button will fit on the line with as many keys
> as possible. 
> This is a loop I guess: (psuedo code!)
> 
> while( keys ) {
>   build button;
>   draw button;
>   keys++
> }
> 

Well I would say first you have to make the width(), ascent() and descent()
functions. You have to think about how you want the inset displayed-vertically
and then divide the height of the inset between ascent and descent. The inset
should be relatively small and so you can recalculate all each time.

Look above then how to draw it (obviously you should then use the width()
ascent(), descent() functions to get the values for the drawing, without
duplicationg code ;)

> Searching further, I see that in InsetText::computeTextRows(), the max width
> available is determined with maxWidth = getMaxTextWidth(pain, this);
> 

Ok this fuction just splits the whole text up in rows depending on how much
space I have. You'll see that there is also the posibility that the inset
is not allowed to split up and so all is displayed on one row (autoBreakRows).
For getting the maximum allowed with you can draw in call getMaxWidth() as
that is an inset-function and returns you the maximum width you can use
(max is the page-width of the painter but you could be inside another inset
wich already sets its max width and so the width will be less).

> So, I can use this in InsetCommand::draw() to help me decide whether I need 
> more than one button:
>   maxWidth = getMaxTextWidth(pain, this);
>   if( x+width() > maxWidth )
>   draw multiple buttons;
>   else
>   draw one button;

Yes something like that only use getMaxWidth(pain, this)!

> 
> I know this isn't rigorous, but am I on the right track?

You are!

Hope this helps!

  Jürgen

-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Dr. Jürgen Vigna  E-Mail: [EMAIL PROTECTED]
Italienallee 13/N Tel:+39-0471-450260
I-39100 Bozen Fax:+39-0471-450296
ITALY Web:http://www.sad.it/~jug

Who dat who say "who dat" when I say "who dat"?
-- Hattie McDaniel

-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Re: New citation dialog

[Juergen Vigna]

On 19-May-2000 Juergen Vigna wrote:
> 
> BTW: Did you try to Preview the UserGuide? Please try, it gives 1 error!
> 

And one more: I just read the whole UserGuide substituting LyXTable's with
  InsetTabular's and ..., it worked :)!

-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Dr. Jürgen Vigna  E-Mail: [EMAIL PROTECTED]
Italienallee 13/N Tel:+39-0471-450260
I-39100 Bozen Fax:+39-0471-450296
ITALY Web:http://www.sad.it/~jug

Life is like a tin of sardines.  We're, all of us, looking for the key.
-- Beyond the Fringe

-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Re: New citation dialog

[Juergen Vigna]

> 
>| > I have no real objections to the patch, so I think I will just include
>| > it.
>| 
>| Well I don't know if I missed it but I didn't see changes for LatexConfig,
>| as we use new packages here this should also be reflected in the latex
>| configuration and also in the package list with help to find it if it
>| isn't available on the system, this should go in before we release final
>| 1.1.5 if we include this patch!
> 
> Sure. I think I will get a patch RSN now... (hint, hint)
> 

BTW: Did you try to Preview the UserGuide? Please try, it gives 1 error!

  Jürgen

-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Dr. Jürgen Vigna  E-Mail: [EMAIL PROTECTED]
Italienallee 13/N Tel:+39-0471-450260
I-39100 Bozen Fax:+39-0471-450296
ITALY Web:http://www.sad.it/~jug

You will reach the highest possible point in your business or profession.

-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Re: New citation dialog

[Lars Gullik Bjønnes]

Juergen Vigna <[EMAIL PROTECTED]> writes:

| On 18-May-2000 Lars Gullik Bjønnes wrote:
| > 
| > Also you only implement parts of what varioref provides, same for
| > pretty ref.
| > Otoh support for varioref and prettyref are long overdue, but we
| > should work to support them completely, also xr.sty should be worked
| > into the same ref support.
| > 
| 
| We always started with some support the rest can come in time :)

But should not be forgotten as we have a tendency to do...

| > I have no real objections to the patch, so I think I will just include
| > it.
| 
| Well I don't know if I missed it but I didn't see changes for LatexConfig,
| as we use new packages here this should also be reflected in the latex
| configuration and also in the package list with help to find it if it
| isn't available on the system, this should go in before we release final
| 1.1.5 if we include this patch!

Sure. I think I will get a patch RSN now... (hint, hint)

Lgb

Re: New citation dialog

[Juergen Vigna]

On 18-May-2000 Lars Gullik Bjønnes wrote:
> 
> Also you only implement parts of what varioref provides, same for
> pretty ref.
> Otoh support for varioref and prettyref are long overdue, but we
> should work to support them completely, also xr.sty should be worked
> into the same ref support.
> 

We always started with some support the rest can come in time :)

> I have no real objections to the patch, so I think I will just include
> it.

Well I don't know if I missed it but I didn't see changes for LatexConfig,
as we use new packages here this should also be reflected in the latex
configuration and also in the package list with help to find it if it
isn't available on the system, this should go in before we release final
1.1.5 if we include this patch!

Greets Jürgen

-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Dr. Jürgen Vigna  E-Mail: [EMAIL PROTECTED]
Italienallee 13/N Tel:+39-0471-450260
I-39100 Bozen Fax:+39-0471-450296
ITALY Web:http://www.sad.it/~jug

All phone calls are obscene.
-- Karen Elizabeth Gordon

-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._