Re: Fwd: Re: Mandrake and KDe frontend

[Asger K. Alstrup Nielsen]

On 28 Nov 2000, Jean-Marc Lasgouttes wrote:

 Nope. We have several things the provide dynamic menus:

I'm glad that the menu model in LyX is more complete than I thought.
Congratulations on some good work there.

Therefore, I must retract the argument that GUII will make the model more
basic, since obviously it isn't for the dialogs and the menus.

 Asger Also, you do not have the infrastructure to handle changing
 Asger toolbars on the fly.
 
 Having the infrastructure would be easy. The most difficult part is
 probably to implement that in the xforms frontend.

If you by infrastructure mean the model abstraction, yes, this will be
easy.  But once again, you basically just shove complexity into the
front-ends:  Each front-end has to implement the rest.

 I won't comment on MVC, since it's been something I'm very fuzzy
 about. 

Fair enough.
Here's a section from the book "Design Patterns" that explains the MVC
concept:

"1.2 Design Patterns in Smalltalk MVC

The Model/View/Controller (MVC) triad of classes is used to build user
interfaces in Smalltalk-80. Looking at the design patterns inside MVC
should help you see what we mean by the term "pattern."

MVC consists of three kinds of objects. The Model is the application
object, the View is its screen representation, and the Controller defines
the way the user interface reacts to user input. Before MVC, user
interface designs tended to lump these objects together. MVC decouples
them to increase flexibility and reuse.

MVC decouples views and models by establishing a subscribe/notify protocol
between them. A view must ensure that its appearance reflects the state of
the model. Whenever the Model's data changes, the model notifies views
that depend on it. In responce, each view gets an oppurtunity to update
itself. This approach lets you attach multiple views to a model to provide
different presentations. You can also create new views for a model without
rewriting it.

(I omit an example of this, an explanation of how MVC is applicable in
other contexts, and another example of how Model/VIew separate is useful
to enable nesting of views into a composed view.)

MVC also lets you change the way a view responds to user input without
changing its visual presentation. You might want to change the way it
responds to the keyboard, for example, or have it use a pop-up menu
instead of command keys. MVC encapsulates the response mechanism in a
Controller object. There is a class hierarchy of controllers, making it
easy to create a new controller as a variation on an existing one.

A view uses an instance of a Controller subclass to implement a particular
response strategy; to implement a different strategy, simply replace the
instance with a different kind of controller. It's even possible to change
a view's controller at run-time to let the view change the way it responds
to user input. For example, a view can be disabled so that it doesn't
accept input simply by givint it a controller that ignores input events.

(More details of which Design Patterns are used in a MVC separations)
"

Now I think you can see what I mean:  The task of separating the view and
controller from a combined ViewController is not done in the GUII effort.

That is acceptable, because the model/viewcontroller separation is the
most important separation. The view/controller separation is not as
crucial for a clean program.
But I must point it out to you:  By doing GUII, you will not be doing the
refactoring of separation the view/controller part at first, because that
is too hard.

When that is said, Allan did manage to separate some policy out in the
dialog GUII job:  The button policy classes represents a control component 
in a view/controller separation.

Summing up:

At this point, you have a clean separation of Model/View/Control in a GUII
fashion for the dialogs.
You have a clean separation of Model/ViewController for the menus. This
framework is suboptimally implemented for XForms only.

What you don't have:

1)  A separation of view and control for the menus
2)  A separation of M/VC for the toolbar
2b) A separation of V/C for the toolbar
3)  A separation of M/VC for the canvas
3b) A separation of V/C for the canvas

1) is what I argue is hard. Therefore, you probably won't do it, and just
leave each frontend as an integrated VC pair.
2) is relatively easy. You are already discussing it on the list at the
moment.
2b) is hard. Therefore you probably won't do it, but just leave each
front-end as an integrated VC pair.
3) is hard. Some work has been started to get a View abstraction (the
painter).
3b) is also hard, and will probably never be done in a GUII setting.

If you focused on one front-end only, the tasks of 1), 2b) and 3b) would
be easier.

So in conclusion, you have been making great progression in the GUII
job. In particular, you have demonstrated that it is possible to
develop the model components without dumbing them down.

But there still is a long way to go, and by 

Re: Fwd: Re: Mandrake and KDe frontend

[Marko Vendelin]

 I'm not sure what we gain with that. The problems which exist in some
 architectures (e.g. how do you update a dynamic menu when it is teared off)
 will continue to exist anyway. If you find a good solution for a
 frontend, I am sure it will work with the current scheme.

The only problem of dynamic menus/toolbars is the way they are supposed to
handle the changes in LyXFunc values. I think that the same problem will
show up much worser in server-client architecture (or client will have to
ask for the complete status update after any change of the document which
may hang your machine/network ...). This problem has been discussed
earlier and it has been demonstrated that it is relatively easy to resolve
this problem using signals that are emitted if some function state/value
changes. I guess that this mechanism has to be implemented anyway to allow
LyX to display dynamic content in any GUI.


[...]

 Concerning toolbars, I have the following scheme in mind:

 1/ give name to toolbars and have several of them (like menus): "main"
 "math" "table". In fact it may be possible to use the same backend for
 toolbar and menus, although I am not sure what the advantage will be.

 2/ In the code, add some showToolbar("math")/hideToolbar("math")

 3/ Let the front end do what it wants with it :)

Actually, the current implementation of menus may be utilized to implement
toolbars. We had a discussion on this topic before and I've even submitted
a screenshot of lyx gnome frontend with the toolbar corresponding to main
menu :).

Marko

lack of arbitrary cross-references

[s3236890]

(Please of course forgive/ignore if this is a repeat posting/stupid; My web access is 
down and I am limited to email.)

Applies to: LyX Version 1.1.5fix2

While it is nice that the insertcross-reference menu gives a list of all existing 
labels to insert, it does not appear to allow the manual insertion of arbitrary 
labels. This is a problem when using included/inputted lyx files, whose labels are not 
available in the cross-referncing sub-menu.

Thanks,
Dan(iel)

P.S. Was that succinct enough? Well, now that's over:

Thanks for an excellent program. LyX is neat-o.

[Rainer Hoffmann rainer.hoffmann@ops.de] Re: announce lyx-1.1.6pre2

[Lars Gullik Bjønnes]

Beaubert Francois schrieb:

 Rainer Hoffmann wrote:
 
 
  3) I tried the PDF-Export:
  The fonts on the screen with acrobat reader were ugly. Looked like bitmap fonts.
  Can that be changed?
 
  Bye,
 
  Rainer Hoffmann

 yes remove the T1 encoding in the preferences - output - misc popup

1) That gave an interesting reaction (together with a long long beep):

FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"linen".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"light blue".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"yellow".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"indian red".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"blue".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"gray80".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"linen".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"linen".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"violet".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"royal blue".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"blue4".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"antique white".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"magenta".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"blue".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"red4".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"gray60".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"indian red".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"gray60".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"indian red".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"red".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"brown".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"brown".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"brown".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"brown".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"light steel blue".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"gray40".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"royal blue".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"gray80".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"gray40".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"gray80".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"gray40".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"gray60".
Color inherit is undefined or may not be redefined

I didn't do anything else then you said!

Now there was also some reaction on the screen: For example the size of the section
headers was significantly smaller. But when I tried View PDF again the result wasn't
different 

Re: announce lyx-1.1.6pre2

[Bronek Baraniecki]

On wto, 28 lis 2000, Herbert wrote:

 "Lars Gullik Bjønnes" wrote:
  
  The second prerelease of 1.1.6 has been available for some days now,
  and this time it is also announced here and not just on the developers
  list.

H: when the printing menu is opened, by default the button
H: "all pages"  is valid. but it's not possible to click on
H: the ok-button, i had  to click on the
H: "all-pages-button" (or any other) and than   printing
H: is possible.  
 Herbert

Exactly the same is in my printing menu.

Rod Pinna wrote:

RP: Just had a quick look at the new release. A small bug
RP: seems to have crept  in. I can't access the "look 
RP: feel" and "language opts" menus. Instead,  clicking
RP: on those brings up the "screen fonts" and "language"
RP: menus  respectively.  
RP: I'm using xforms 0.89, which comes with debian potato.
  Rod.

Hmmm, interesting. I can access to all submenus in
a preferences without any problem.
I'm in RedHat 7.0 using xforms 0.88.
Bronek.
-- 
Bronek Baraniecki
[EMAIL PROTECTED]

Re: configuring 1.1.6pre2

[John Levon]

On Tue, 28 Nov 2000, Alvaro Tejero Cantero wrote:

 I wonder wether something I am unaware of has to be done.
 Also, pre2 is the release for po-updating, isn't it?

does this mean all text is frozen from here on in for 1.1.6 ?

john

-- 
"We signed to play until the day we died, and we did."
- Jimmy Greaves

Re: configuring 1.1.6pre2

[Lars Gullik Bjønnes]

John Levon [EMAIL PROTECTED] writes:

| On Tue, 28 Nov 2000, Alvaro Tejero Cantero wrote:
| 
|  I wonder wether something I am unaware of has to be done.
|  Also, pre2 is the release for po-updating, isn't it?
| 
| does this mean all text is frozen from here on in for 1.1.6 ?

No, I won't be that strict. Use good judgement and do not change l10n
strings unless needed.

Lgb

PATCH: bug fixes

[Angus Leeming]

Attached is a patch of assorted bug fixes.
Angus

 patch.diff.bz2

export - pdflatex (lyx 1.1.6pre2)

[RA]

First: it's nice now to have an export/view of a pdflatex'ed file. 

But there is a problem (or two) with inserted figures, if you want to use 
pdflatex.

There is no option 'pdftex' in Document Layout - Extra - PS Driver.
It would be very easy if lyx would create automatically a preamble like this:

\ifx\pdfoutput\undefined
  \usepackage[dvips]{graphicx} % or whatever PS Driver I want
\else
  \usepackage[pdftex]{graphicx} % We are running pdfLaTeX
  \pdfinfo{
/Title (Produced with LyX and pdfLaTeX)
/Author (...)
  }
\fi

Note: graphicX is necessary for pdftex (at least for my setup - tetex 1.0.7).

Another (more cosmetic) approvement would be if the known suffixes of the 
figures are extended to *.pdf *.mps *.png ...


Ralf.

Bug report ( in lyx code environment)

[ervandermeer]

Hi!

I have just upgraded to lyx 1.1.5fix2. It has a problem where my old lyx
(don't remember the version, sorry. An old one, 1.0.0 or 1.0.1, I think 1.0.1)
didn't.

Actually, it has two related problems:

1) It won't let me insert a double-quote in the lyx code environment. It will
only insert two apostrophes. I used to work around that by writing the code
sections in an editor, and then including the file. This works.

2) It used to typeset that just fine. The new version doesn't. LaTeX complains
with a message:

Missing number, treated as zero.
\char`
   \"{}False
A number should have been here; I inserted `0'.
(If you can't figure out why I needed to see a number,
  look up `weird error' in the index to the TeXbook.)

I don't know LaTeX, and I use lyx to do the dirty work for me. Could you
improve the situation so that I can just insert double-quotes in the lyx code
environment, and do some hack so that it will be typeset by LaTeX too?

By the way, congratulations with your excellent and badly needed piece of
software!

Erik van der Meer

Re: Strange Bibtex behaviour ?

[Lars Gullik Bjønnes]

Florian Schopper [EMAIL PROTECTED] writes:

| Dear Lyxers,
| 
| in the attachment I added an example file (some files actually) with
| a main lyx file mytest.lyx and some others which are included.
| My Problem is that lyx doesn´t run bibtex any more if these files are 
| included (whatever is the true reason). The lyx version I used was 
| 1.1.4fix1.

Turn off the subfigure in Titel.lyx
That makes it tex with out warnings.

Also you should not need to have
\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}

in the preamble.

Lgb

PATCH: Re: [Rainer Hoffmann rainer.hoffmann@ops.de] Re: announce lyx-1.1.6pre2

[Angus Leeming]

Attached is the patch to the Color inherit is undefined or may not be 
redefined when LANG!=C problem.

Many thanks for the bug report, Rainer

Angus


  yes remove the T1 encoding in the preferences - output - misc popup

 1) That gave an interesting reaction (together with a long long beep):

 FormPreferences::Colors::apply: resetting LColor =FCbernehmen from "black"
 = to
 "linen".
 Color inherit is undefined or may not be redefined
 FormPreferences::Colors::apply: resetting LColor =FCbernehmen from "black"
 = to
 "light blue".
 Color inherit is undefined or may not be redefined

 patch.diff.bz2

Re: announce lyx-1.1.6pre2

[John Levon]

On Wed, 29 Nov 2000, Allan Rae wrote:

 Hmmm... The only reason OK should be disabled is if there is an invalid
 input (no filename, a page-to entry but no page-from entry and other
 obvious things).  I'll take a look.
 
 Allan. (ARRae)
 

Allan, I fixed it with the attached patch. It seems safe to tell the
controller that what we picked up from the printer params is valid.

thanks
john

-- 
"We signed to play until the day we died, and we did."
- Jimmy Greaves


? patch.diff
? printenable.diff
? src/a.diff
Index: ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/ChangeLog,v
retrieving revision 1.704
diff -u -p -r1.704 ChangeLog
--- ChangeLog   2000/11/29 15:34:56 1.704
+++ ChangeLog   2000/11/29 16:06:41
@@ -1,5 +1,10 @@
 2000-11-29  John Levon  [EMAIL PROTECTED]
 
+   * src/frontends/xforms/FormPrint.C: set to valid()
+   when we update from the passed parameters.
+
+2000-11-29  John Levon  [EMAIL PROTECTED]
+
* src/lyx_rc.C: more detail for the printer program config
dialog.
 
Index: po/POTFILES.in
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/po/POTFILES.in,v
retrieving revision 1.105
diff -u -p -r1.105 POTFILES.in
--- po/POTFILES.in  2000/11/28 15:54:29 1.105
+++ po/POTFILES.in  2000/11/29 16:06:41
@@ -48,35 +48,35 @@ src/frontends/kde/refdlg.C
 src/frontends/kde/tocdlg.C
 src/frontends/kde/urldlg.C
 src/frontends/xforms/FormBase.h
-src/frontends/xforms/form_citation.C
 src/frontends/xforms/FormCitation.C
-src/frontends/xforms/form_copyright.C
+src/frontends/xforms/form_citation.C
 src/frontends/xforms/FormCopyright.C
-src/frontends/xforms/form_document.C
+src/frontends/xforms/form_copyright.C
 src/frontends/xforms/FormDocument.C
-src/frontends/xforms/form_error.C
+src/frontends/xforms/form_document.C
 src/frontends/xforms/FormError.C
-src/frontends/xforms/form_graphics.C
+src/frontends/xforms/form_error.C
 src/frontends/xforms/FormGraphics.C
-src/frontends/xforms/form_index.C
+src/frontends/xforms/form_graphics.C
 src/frontends/xforms/FormIndex.C
+src/frontends/xforms/form_index.C
 src/frontends/xforms/FormInset.h
-src/frontends/xforms/form_paragraph.C
 src/frontends/xforms/FormParagraph.C
-src/frontends/xforms/form_preferences.C
+src/frontends/xforms/form_paragraph.C
 src/frontends/xforms/FormPreferences.C
-src/frontends/xforms/form_print.C
+src/frontends/xforms/form_preferences.C
 src/frontends/xforms/FormPrint.C
-src/frontends/xforms/form_ref.C
+src/frontends/xforms/form_print.C
 src/frontends/xforms/FormRef.C
-src/frontends/xforms/form_tabular.C
+src/frontends/xforms/form_ref.C
 src/frontends/xforms/FormTabular.C
-src/frontends/xforms/form_tabular_create.C
+src/frontends/xforms/form_tabular.C
 src/frontends/xforms/FormTabularCreate.C
-src/frontends/xforms/form_toc.C
+src/frontends/xforms/form_tabular_create.C
 src/frontends/xforms/FormToc.C
-src/frontends/xforms/form_url.C
+src/frontends/xforms/form_toc.C
 src/frontends/xforms/FormUrl.C
+src/frontends/xforms/form_url.C
 src/frontends/xforms/Menubar_pimpl.C
 src/frontends/xforms/xform_helpers.C
 src/gettext.h
Index: src/frontends/xforms/FormPrint.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/FormPrint.C,v
retrieving revision 1.14
diff -u -p -r1.14 FormPrint.C
--- src/frontends/xforms/FormPrint.C2000/11/28 06:46:06 1.14
+++ src/frontends/xforms/FormPrint.C2000/11/29 16:06:43
@@ -194,6 +194,7 @@ void FormPrint::update()
 
fl_set_input(dialog_-input_count,
 tostr(pp.count_copies).c_str());
+   bc_.valid();
}
 }
 

Re: PATCH: Re: [Rainer Hoffmann rainer.hoffmann@ops.de] Re: announce lyx-1.1.6pre2

[Lars Gullik Bjønnes]

Angus Leeming [EMAIL PROTECTED] writes:

| Attached is the patch to the Color inherit is undefined or may not be 
| redefined when LANG!=C problem.

I'll apply this.

Lgb

Bug in configure.in?

[Michal Kuratczyk]

Hi,

I just updated my CVS:
kura@apokalipsa:~/soft/lyx-devel % make
...
checking for strerror... (cached) yes
checking for atexit... (cached) yes
./configure[11342]: syntax error: `mkstemp,unistd.h' unexpected
make: *** [config.status] Bd 1
kura@apokalipsa:~/soft/lyx-devel %

Best regards,
-- 
Michal Kuratczyk [EMAIL PROTECTED]

Re: Bug in configure.in?

[Kayvan A. Sylvan]

On Wed, Nov 29, 2000 at 05:54:47PM +0100, Michal Kuratczyk wrote:
 Hi,
 
 I just updated my CVS:
 kura@apokalipsa:~/soft/lyx-devel % make
 ...
 checking for strerror... (cached) yes
 checking for atexit... (cached) yes
 ./configure[11342]: syntax error: `mkstemp,unistd.h' unexpected
 make: *** [config.status] B??d 1
 kura@apokalipsa:~/soft/lyx-devel %
 
 Best regards,
 -- 
 Michal Kuratczyk [EMAIL PROTECTED]

Did you run ./autogen.sh ?

I recommend "make maintainer-clean; ./autogen.sh"

-- 
Kayvan A. Sylvan   | Proud husband of  | Father to my kids:
Sylvan Associates, Inc.| Laura Isabella Sylvan | Katherine Yelena
http://www.successlinks.com/kayvan | Reach your goals now! | Robin Gregory

Re: announce lyx-1.1.6pre2

[Kayvan A. Sylvan]

On Tue, Nov 28, 2000 at 11:37:04PM +0100, Lars Gullik Bjønnes wrote:
 Herbert Voss [EMAIL PROTECTED] writes:
 
 | "Lars Gullik Bjønnes" wrote:
 |  
 |  The second prerelease of 1.1.6 has been available for some days now,
 |  and this time it is also announced here and not just on the developers
 |  list.
 | 
 | when the printing menu is opened, by default the button "all pages"
 | is valid. but it's not possible to click on the ok-button, i had
 | to click on the "all-pages-button" (or any other) and than 
 | printing is possible.
 
 In addition to this it seems printing has a problem. I am not able to
 print to my postscript printer from inside lyx, but have to export to
 postscript first and run lpr manually

Oh really? I just click on the "file" box and back to the "printer" box
and then I can hit OK to print.

The validate() fix seems like a good idea.

-- 
Kayvan A. Sylvan   | Proud husband of  | Father to my kids:
Sylvan Associates, Inc.| Laura Isabella Sylvan | Katherine Yelena
http://www.successlinks.com/kayvan | Reach your goals now! | Robin Gregory

Re: UserGuide question

[Lars Gullik Bjønnes]

Angus Leeming [EMAIL PROTECTED] writes:

| In the UserGuide :
| 
| The undo-mechanism has been limited to 100 steps in the beta-version, as this 
| feature has not yet been properly tested out.
| 
| Is this still true?

Probably not.

| 
| In lyxfunc.C::Dispatch()
|   case LFUN_UNDO:
|   disable = buf-undostack.empty();
|   break;
| 
| I can see no limit here.

I think the limit was removed when we switched to std::containers.

Lgb

Re: announce lyx-1.1.6pre2

[Garst R. Reese]

"Kayvan A. Sylvan" wrote:

 Oh really? I just click on the "file" box and back to the "printer" box
 and then I can hit OK to print.
Just clicking on the already yellow "printer" box does it for me. If
neither box was already yellow, this would be clear. Most of the time I
print to file anyway, because I have work to do with psutils. It would
be nice if the psutils functionality was integrated into LyX.
Particularly -nup and output papersize. Over a year ago I e-mailed
Duggan about some updates to psutils and he said he was coming out with
a completely rewritten version in "a couple of months." It never
happened.
Garst

Re: UserGuide question

[Lars Gullik Bjønnes]

Angus Leeming [EMAIL PROTECTED] writes:

| In the UserGuide :
| 
| The undo-mechanism has been limited to 100 steps in the beta-version, as this 
| feature has not yet been properly tested out.
| 
| Is this still true?
| 
| In lyxfunc.C::Dispatch()
|   case LFUN_UNDO:
|   disable = buf-undostack.empty();
|   break;
| 
| I can see no limit here.

Actually we have a limit:

src/undo.C:83,92

This limit is initialized to 100.

There is a problem with having no limit... we will always keep undo
information from the momemnt when lyx was started and for long runs
this can be a long time and a lot of bits in the undo stack...

Lgb

Re: announce lyx-1.1.6pre2

[Lars Gullik Bjønnes]

"Garst R. Reese" [EMAIL PROTECTED] writes:

| "Kayvan A. Sylvan" wrote:
| 
|  Oh really? I just click on the "file" box and back to the "printer" box
|  and then I can hit OK to print.
| Just clicking on the already yellow "printer" box does it for me. If
| neither box was already yellow, this would be clear. Most of the time I
| print to file anyway, because I have work to do with psutils. It would
| be nice if the psutils functionality was integrated into LyX.

I have it on my list...

Lgb

Re: UserGuide question

[Angus Leeming]

Lars, 
Just read your mail saying that a limit does exist. Fair enough. I'll modify 
the UserGuide to say that this is so (ie, not a feature of the beta version, 
now superceeded.)

Next question. Just beneath this last statement in the UserGuide we have:

Notice that if you revert back all changes to arrive to the document as it 
was last saved, the "changed" status of the document is unfortunately not 
reset. This is a known bug.

I guess that this is a consequence of the above, no? We can't apply the 
following fix, because the limit means that changes will be popped off the 
stack.

case LFUN_UNDO:
disable = buf-undostack.empty();
+   if (disable)
+   buf-markLyxClean();
break;  

Is my reasoning correct here? I'll modify the documentation to reflect this.

Angus


On Wednesday 29 November 2000 17:42, Lars Gullik Bjønnes wrote:
 Angus Leeming [EMAIL PROTECTED] writes:
 | In the UserGuide :
 |
 | The undo-mechanism has been limited to 100 steps in the beta-version, as
 | this feature has not yet been properly tested out.
 |
 | Is this still true?

 Probably not.

 | In lyxfunc.C::Dispatch()
 | case LFUN_UNDO:
 | disable = buf-undostack.empty();
 | break;
 |
 | I can see no limit here.

 I think the limit was removed when we switched to std::containers.

 Lgb

Re: UserGuide question

[Lars Gullik Bjønnes]

Angus Leeming [EMAIL PROTECTED] writes:

| Next question. Just beneath this last statement in the UserGuide we have:
| 
| Notice that if you revert back all changes to arrive to the document as it 
| was last saved, the "changed" status of the document is unfortunately not 
| reset. This is a known bug.

It is a bug...

| I guess that this is a consequence of the above, no? We can't apply the 
| following fix, because the limit means that changes will be popped off the 
| stack.
| 
|   case LFUN_UNDO:
|   disable = buf-undostack.empty();
| + if (disable)
| + buf-markLyxClean();
|   break;

This patch would be wrong anyway...

To do anything else we would have to store the status in the undo
information, but only act upon it if there were no other undo objects
belonging to the same buffer.

And later when we have a "pick the undo you want to apply now" this
will be interesting.

That said I think we should support clearing of the changed flag if we
are sure about the state, but we are not there yet.

| Is my reasoning correct here? I'll modify the documentation to
|  reflect this.

I don't think you are far off...

Lgb

PATCH: FormRef

[Angus Leeming]

Attached is a tiny patch to FormRef. Clicking on different insets when the 
sort key was activated was a bit odd before this fix ;-)

Angus

 patch.diff.bz2

Re: PATCH: FormRef

[Lars Gullik Bjønnes]

Angus Leeming [EMAIL PROTECTED] writes:

| Attached is a tiny patch to FormRef. Clicking on different insets when the 
| sort key was activated was a bit odd before this fix ;-)

+   if (cit != keys.end()) {
+   int const i = static_castint(cit - keys.begin());


Not sure if I agree with this one (oh the patch is ok)

but ...

vectorstring::difference_type const i = cit - keys.begin();

seems better?

But then perhaps you will need casts otherplaces so I don't know...

Anyway keep all the typedefs for the different std::constainers in
mind when using them.

I'll apply the patch.

Lgb

Re: PATCH: FormRef

[Angus Leeming]

Well, it's always good to get hints on better practice, but in this case "i" 
is used only in calls to xforms routines and so an int is the required type.

Angus


On Wednesday 29 November 2000 19:37, Lars Gullik Bjønnes wrote:
 Angus Leeming [EMAIL PROTECTED] writes:
 | Attached is a tiny patch to FormRef. Clicking on different insets when
 | the sort key was activated was a bit odd before this fix ;-)

 +   if (cit != keys.end()) {
 +   int const i = static_castint(cit - keys.begin());


 Not sure if I agree with this one (oh the patch is ok)

 but ...

 vectorstring::difference_type const i = cit - keys.begin();

 seems better?

 But then perhaps you will need casts otherplaces so I don't know...

 Anyway keep all the typedefs for the different std::constainers in
 mind when using them.

 I'll apply the patch.

 Lgb

footnote

[Sencer Ecer]

Hi,

It seems footnotes don't wotk properly. They sometimes don't appear except
a line in the bottom of the text, otherwise without any numbers. 

Re: footnote

[Garst R. Reese]

Sencer Ecer wrote:
 
 Hi,
 
 It seems footnotes don't wotk properly. They sometimes don't appear except
 a line in the bottom of the text, otherwise without any numbers.
What version of LyX are you using? What platform?
Garst

Re: multicolumn in 1.1.6pre2

[Jürgen Vigna]

[EMAIL PROTECTED], [EMAIL PROTECTED] wrote:

On Mon, 27 Nov 2000, Jürgen Vigna wrote:

Sorry, I didn't realise you didn't have easy access to the source as
well. This is InsetTabular::draw(), inside the need_update == CELL
case. It comes *after* the code that does the

H I thought about the problem and probably it should be solved in the
Selection area (InsetButtonMotionNotify) and there if the selection goes
over one cell the inset should be unlocked so this type of stuff cannot happen!

GetWidthOfColumn() GetAscentOfRow() stuff - is that where you mean ?


No I thought it was in update() which calls the function to recalculate the
width of the columns (cells) CalculateWidthOfTabular (or something like that ;)

I'm not sure what you mean here, I can't select stuff without the text
cursor following. And shouldn't I be able to get it to redraw properly
later ?

Do you select with mouse or with cusor keys? Please try to do the same
(selecting more cells) but using Shift-CursorRight AND also enter the
tabular with the cursor (so you'll see the cursor inside the cell blinking
but no border around the cells text is written.

 void InsetTabular::UpdateLocal(BufferView * bv, UpdateCodes what,
bool mark_dirty) const
 {
 if ((what == INIT)  the_locking_inset) {
 the_locking_inset-InsetUnlock(bv);
 the_locking_inset = 0;
 }
 
 }
I had to make the_locking_inset member mutable as well. Unfortunately this
didn't help. I still get the ERROR every time I select "multicolumn". I
wish I could help further but I've never seen this code before ;)

You didn't look good IMO, you shouldn't put the above code in the draw() function
(which is const) but at the top of UpdateLocal! Please retry (althougth the above
mentioned solution would be the best one!)

Could you please try again?

Greets Jürgen

Re: [PATCH] cleanups

[Allan Rae]

On Wed, 29 Nov 2000, John Levon wrote:

 p.s. is there any chance POTFILES.in can get cvs removed ? It is very
 galling having to delete it each time from the diff

Then don't delete it.

It is possible to build POTFILES.in from autogen.sh (if we copy it back in
there from po/Makefile.in.in (note: I said copy not move)) from a clean
cvs checkout and then keep it up to date with the new additions to
po/Makefile.in.in. I don't think we need it in CVS anymore if that change
is made since when someone does a `make dist` they'll get an updated
POTFILES.in anyway.  Unless someone can think of a reason why we need it
in CVS I think we can now remove (once I copy the POTFILES.in generation
code back into autogen.sh -- I'll do some testing in my tree). 

The thing I find strange is why the sorted order of the files in
POTFILES.in changes depending on who is sending a patch.  What system are
you running?  Are you on an Alpha like Angus? (whose patches also seem to
change the sorted order)

Seems some systems implementation of sort respond slightly differently to
the -f and -d flags.

Allan.  (ARRae)

compile error

[Ron Peterson]

I'm such a newbie I haven't even _compiled_ LyX yet...

gcc version 2.96 2731 (Red Hat Linux 7.0)

I'm not doing anything fancy.  Just './configure --prefix=/foo/bar',
then 'make'.

Any suggestions?  Don't worry about wounding my pride. ;^)

make[3]: Entering directory `/usr/local/src/lyx-1.1.5fix2/src/mathed'
/bin/sh ../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I.
-I../../src -I../../images -I./../   -isystem /usr/X11R6/include  -g -O2
-fno-rtti -fno-exceptions -c formula.C
g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I../../images -I./../ -isystem
/usr/X11R6/include -g -O2 -fno-rtti -fno-exceptions -c formula.C -o
formula.o
In file included from formula.C:20:
/usr/include/g++-3/sstream: In method `string stringstreambase::str ()
const':
/usr/include/g++-3/sstream:102: taking dynamic typeid of object with
-fno-rtti
/usr/include/g++-3/sstream: In method `void stringstreambase::str
(const string )':
/usr/include/g++-3/sstream:107: taking dynamic typeid of object with
-fno-rtti
In file included from ../../src/lyxfont.h:22,
 from ../../src/insets/lyxinset.h:24,
 from formula.h:27,
 from formula.C:30:
../../src/LString.h: At top level:
../../src/LString.h:21: conflicting types for `typedef class lyxstring
string'
/usr/include/g++-3/string:9: previous declaration as `typedef class
basic_stringchar, string_char_traitschar,
__default_alloc_templatetrue, 0  string'
make[3]: *** [formula.lo] Error 1
make[3]: Leaving directory `/usr/local/src/lyx-1.1.5fix2/src/mathed'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/local/src/lyx-1.1.5fix2/src'
make[1]: *** [all-recursive-am] Error 2
make[1]: Leaving directory `/usr/local/src/lyx-1.1.5fix2/src'
make: *** [all-recursive] Error 1

-- 

Ron Peterson
9 Morgan Street, Apt. 'A'
South Hadley, MA  01075
413.536.1146 tel
[EMAIL PROTECTED]

Insert Figure

[Garst R. Reese]

Insert Figure still asks for a .EPS file
A .ps file works as well, but with all of the new converters, shouldn't
it be possible to insert other formats? e.g., .fig
Garst

Re: announce lyx-1.1.6pre2

[Martin Vermeer]

On Wed, Nov 29, 2000 at 08:45:36AM +0100, Rainer Hoffmann wrote:
 Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
 Precedence: bulk
 X-No-Archive: yes
 List-Post: mailto:[EMAIL PROTECTED]
 List-Help: mailto:[EMAIL PROTECTED]
 List-Unsubscribe: mailto:[EMAIL PROTECTED]
 Delivered-To: mailing list [EMAIL PROTECTED]
 X-Envelope-Sender-Is: [EMAIL PROTECTED] (at relayer oi419e.ops.de)
 X-Amavis-approved: Yes
 Date: Wed, 29 Nov 2000 08:45:36 +0100
 From: Rainer Hoffmann [EMAIL PROTECTED]
 Organization: Oce Printing Systems
 X-Mailer: Mozilla 4.5 [de] (WinNT; I)
 X-Accept-Language: de
 To: Lars Gullik Bjønnes [EMAIL PROTECTED]
 CC: [EMAIL PROTECTED], [EMAIL PROTECTED]
 Subject: Re: announce lyx-1.1.6pre2
 
 Hi all,
 
 1) I downloaded the .tar.gz-file, .configured, maked and started it with src/lyx
 Then the following messages came:
 LyX: Unknown LyX function `buffer-fax' [around line 60 of file
 ~/Software/lyx-1.1.6pre2/lib/bind/de_menus.bind]
 LyX: Unknown LyX function `layout-paper' [around line 114 of file
 ~/Software/lyx-1.1.6pre2/lib/bind/de_menus.bind]
 LyX: Unknown LyX function `layout-table' [around line 115 of file
 ~/Software/lyx-1.1.6pre2/lib/bind/de_menus.bind]
 LyX: Unknown LyX function `layout-quotes' [around line 116 of file
 ~/Software/lyx-1.1.6pre2/lib/bind/de_menus.bind]
 LyX: Unknown LyX function `buffer-itemize-bullets-select' [around line 125 of
 file ~/Software/lyx-1.1.6pre2/lib/bind/de_menus.bind]
 LyX: Unknown LyX function `table-insert' [around line 131 of file
 ~/Software/lyx-1.1.6pre2/lib/bind/de_menus.bind]

That's because the lyxrc format has changed.
 
 Lyx started nevertheless.
 
 2) Then I opened an old document from 1.1.5
 
 The messages were

... (postscript messages) ...
 
 Yet, the document was opened and displayed correctly
 
 3) I tried the PDF-Export:
 The fonts on the screen with acrobat reader were ugly. Looked like bitmap fonts.
 Can that be changed?

YES!! 

\usepackage{ae} 

in the preamble gives you "almost European", an outline version of Computer Modern.
(I find it less aestetic than CM, but in acroread it looks better)

Alternatively, use any of the other font packages like palatino.sty,
times.sty, bookman.sty, newcent.sty, ... most of them are outline IIRC.

 
 Bye,
 
 Rainer Hoffmann
 

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

Re: Fwd: Re: Mandrake and KDe frontend

[Asger K. Alstrup Nielsen]

On 28 Nov 2000, Jean-Marc Lasgouttes wrote:

> Nope. We have several things the provide dynamic menus:

I'm glad that the menu model in LyX is more complete than I thought.
Congratulations on some good work there.

Therefore, I must retract the argument that GUII will make the model more
basic, since obviously it isn't for the dialogs and the menus.

> Asger> Also, you do not have the infrastructure to handle changing
> Asger> toolbars on the fly.
> 
> Having the infrastructure would be easy. The most difficult part is
> probably to implement that in the xforms frontend.

If you by infrastructure mean the model abstraction, yes, this will be
easy.  But once again, you basically just shove complexity into the
front-ends:  Each front-end has to implement the rest.

> I won't comment on MVC, since it's been something I'm very fuzzy
> about. 

Fair enough.
Here's a section from the book "Design Patterns" that explains the MVC
concept:

"1.2 Design Patterns in Smalltalk MVC

The Model/View/Controller (MVC) triad of classes is used to build user
interfaces in Smalltalk-80. Looking at the design patterns inside MVC
should help you see what we mean by the term "pattern."

MVC consists of three kinds of objects. The Model is the application
object, the View is its screen representation, and the Controller defines
the way the user interface reacts to user input. Before MVC, user
interface designs tended to lump these objects together. MVC decouples
them to increase flexibility and reuse.

MVC decouples views and models by establishing a subscribe/notify protocol
between them. A view must ensure that its appearance reflects the state of
the model. Whenever the Model's data changes, the model notifies views
that depend on it. In responce, each view gets an oppurtunity to update
itself. This approach lets you attach multiple views to a model to provide
different presentations. You can also create new views for a model without
rewriting it.

(I omit an example of this, an explanation of how MVC is applicable in
other contexts, and another example of how Model/VIew separate is useful
to enable nesting of views into a composed view.)

MVC also lets you change the way a view responds to user input without
changing its visual presentation. You might want to change the way it
responds to the keyboard, for example, or have it use a pop-up menu
instead of command keys. MVC encapsulates the response mechanism in a
Controller object. There is a class hierarchy of controllers, making it
easy to create a new controller as a variation on an existing one.

A view uses an instance of a Controller subclass to implement a particular
response strategy; to implement a different strategy, simply replace the
instance with a different kind of controller. It's even possible to change
a view's controller at run-time to let the view change the way it responds
to user input. For example, a view can be disabled so that it doesn't
accept input simply by givint it a controller that ignores input events.

(More details of which Design Patterns are used in a MVC separations)
"

Now I think you can see what I mean:  The task of separating the view and
controller from a combined ViewController is not done in the GUII effort.

That is acceptable, because the model/viewcontroller separation is the
most important separation. The view/controller separation is not as
crucial for a clean program.
But I must point it out to you:  By doing GUII, you will not be doing the
refactoring of separation the view/controller part at first, because that
is too hard.

When that is said, Allan did manage to separate some policy out in the
dialog GUII job:  The button policy classes represents a control component 
in a view/controller separation.

Summing up:

At this point, you have a clean separation of Model/View/Control in a GUII
fashion for the dialogs.
You have a clean separation of Model/ViewController for the menus. This
framework is suboptimally implemented for XForms only.

What you don't have:

1)  A separation of view and control for the menus
2)  A separation of M/VC for the toolbar
2b) A separation of V/C for the toolbar
3)  A separation of M/VC for the canvas
3b) A separation of V/C for the canvas

1) is what I argue is hard. Therefore, you probably won't do it, and just
leave each frontend as an integrated VC pair.
2) is relatively easy. You are already discussing it on the list at the
moment.
2b) is hard. Therefore you probably won't do it, but just leave each
front-end as an integrated VC pair.
3) is hard. Some work has been started to get a View abstraction (the
painter).
3b) is also hard, and will probably never be done in a GUII setting.

If you focused on one front-end only, the tasks of 1), 2b) and 3b) would
be easier.

So in conclusion, you have been making great progression in the GUII
job. In particular, you have demonstrated that it is possible to
develop the model components without dumbing them down.

But there still is a long way to go, and 

Re: Fwd: Re: Mandrake and KDe frontend

[Marko Vendelin]

> I'm not sure what we gain with that. The problems which exist in some
> architectures (e.g. how do you update a dynamic menu when it is teared off)
> will continue to exist anyway. If you find a good solution for a
> frontend, I am sure it will work with the current scheme.

The only problem of dynamic menus/toolbars is the way they are supposed to
handle the changes in LyXFunc values. I think that the same problem will
show up much worser in server-client architecture (or client will have to
ask for the complete status update after any change of the document which
may hang your machine/network ...). This problem has been discussed
earlier and it has been demonstrated that it is relatively easy to resolve
this problem using signals that are emitted if some function state/value
changes. I guess that this mechanism has to be implemented anyway to allow
LyX to display dynamic content in any GUI.


[...]

> Concerning toolbars, I have the following scheme in mind:
>
> 1/ give name to toolbars and have several of them (like menus): "main"
> "math" "table". In fact it may be possible to use the same backend for
> toolbar and menus, although I am not sure what the advantage will be.
>
> 2/ In the code, add some showToolbar("math")/hideToolbar("math")
>
> 3/ Let the front end do what it wants with it :)

Actually, the current implementation of menus may be utilized to implement
toolbars. We had a discussion on this topic before and I've even submitted
a screenshot of lyx gnome frontend with the toolbar corresponding to main
menu :).

Marko

lack of arbitrary cross-references

[s3236890]

(Please of course forgive/ignore if this is a repeat posting/stupid; My web access is 
down and I am limited to email.)

Applies to: LyX Version 1.1.5fix2

While it is nice that the insert>cross-reference menu gives a list of all existing 
labels to insert, it does not appear to allow the manual insertion of arbitrary 
labels. This is a problem when using included/inputted lyx files, whose labels are not 
available in the cross-referncing sub-menu.

Thanks,
Dan(iel)

P.S. Was that succinct enough? Well, now that's over:

Thanks for an excellent program. LyX is neat-o.

[Rainer Hoffmann <rainer.hoffmann@ops.de>] Re: announce lyx-1.1.6pre2

[Lars Gullik Bjønnes]

Beaubert Francois schrieb:

> Rainer Hoffmann wrote:
> >
> >
> > 3) I tried the PDF-Export:
> > The fonts on the screen with acrobat reader were ugly. Looked like bitmap fonts.
> > Can that be changed?
> >
> > Bye,
> >
> > Rainer Hoffmann
>
> yes remove the T1 encoding in the preferences -> output -> misc popup

1) That gave an interesting reaction (together with a long long beep):

FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"linen".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"light blue".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"yellow".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"indian red".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"blue".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"gray80".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"linen".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"linen".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"violet".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"royal blue".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"blue4".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"antique white".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"magenta".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"blue".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"red4".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"gray60".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"indian red".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"gray60".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"indian red".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"red".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"brown".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"brown".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"brown".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"brown".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"light steel blue".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"gray40".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"royal blue".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"gray80".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"gray40".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"gray80".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"gray40".
Color inherit is undefined or may not be redefined
FormPreferences::Colors::apply: resetting LColor übernehmen from "black" to
"gray60".
Color inherit is undefined or may not be redefined

I didn't do anything else then you said!

Now there was also some reaction on the screen: For example the size of the section
headers was significantly smaller. But when I tried View PDF again the 

Re: announce lyx-1.1.6pre2

[Bronek Baraniecki]

On wto, 28 lis 2000, Herbert wrote:

> "Lars Gullik Bjønnes" wrote:
> > 
> > The second prerelease of 1.1.6 has been available for some days now,
> > and this time it is also announced here and not just on the developers
> > list.

H:> when the printing menu is opened, by default the button
H:> "all pages"  is valid. but it's not possible to click on
H:> the ok-button, i had  to click on the
H:> "all-pages-button" (or any other) and than  > printing
H:> is possible.  
> Herbert

Exactly the same is in my printing menu.

>>Rod Pinna wrote:

RP:>> Just had a quick look at the new release. A small bug
RP:>> seems to have crept  in. I can't access the "look &
RP:>> feel" and "language opts" menus. Instead, > clicking
RP:>> on those brings up the "screen fonts" and "language"
RP:>> menus > respectively. > 
RP:>> I'm using xforms 0.89, which comes with debian potato.
> > Rod.

Hmmm, interesting. I can access to all submenus in
a preferences without any problem.
I'm in RedHat 7.0 using xforms 0.88.
Bronek.
-- 
Bronek Baraniecki
[EMAIL PROTECTED]

Re: configuring 1.1.6pre2

[John Levon]

On Tue, 28 Nov 2000, Alvaro Tejero Cantero wrote:

> I wonder wether something I am unaware of has to be done.
> Also, pre2 is the release for po-updating, isn't it?

does this mean all text is frozen from here on in for 1.1.6 ?

john

-- 
"We signed to play until the day we died, and we did."
- Jimmy Greaves

Re: configuring 1.1.6pre2

[Lars Gullik Bjønnes]

John Levon <[EMAIL PROTECTED]> writes:

| On Tue, 28 Nov 2000, Alvaro Tejero Cantero wrote:
| 
| > I wonder wether something I am unaware of has to be done.
| > Also, pre2 is the release for po-updating, isn't it?
| 
| does this mean all text is frozen from here on in for 1.1.6 ?

No, I won't be that strict. Use good judgement and do not change l10n
strings unless needed.

Lgb

PATCH: bug fixes

[Angus Leeming]

Attached is a patch of assorted bug fixes.
Angus

 patch.diff.bz2

export -> pdflatex (lyx 1.1.6pre2)

[RA]

First: it's nice now to have an export/view of a pdflatex'ed file. 

But there is a problem (or two) with inserted figures, if you want to use 
pdflatex.

There is no option 'pdftex' in Document Layout -> Extra -> PS Driver.
It would be very easy if lyx would create automatically a preamble like this:

\ifx\pdfoutput\undefined
  \usepackage[dvips]{graphicx} % or whatever PS Driver I want
\else
  \usepackage[pdftex]{graphicx} % We are running pdfLaTeX
  \pdfinfo{
/Title (Produced with LyX and pdfLaTeX)
/Author (...)
  }
\fi

Note: graphicX is necessary for pdftex (at least for my setup - tetex 1.0.7).

Another (more cosmetic) approvement would be if the known suffixes of the 
figures are extended to *.pdf *.mps *.png ...


Ralf.

Bug report (" in lyx code environment)

[ervandermeer]

Hi!

I have just upgraded to lyx 1.1.5fix2. It has a problem where my old lyx
(don't remember the version, sorry. An old one, 1.0.0 or 1.0.1, I think 1.0.1)
didn't.

Actually, it has two related problems:

1) It won't let me insert a double-quote in the lyx code environment. It will
only insert two apostrophes. I used to work around that by writing the code
sections in an editor, and then including the file. This works.

2) It used to typeset that just fine. The new version doesn't. LaTeX complains
with a message:

Missing number, treated as zero.
\char`
   \"{}False
A number should have been here; I inserted `0'.
(If you can't figure out why I needed to see a number,
  look up `weird error' in the index to the TeXbook.)

I don't know LaTeX, and I use lyx to do the dirty work for me. Could you
improve the situation so that I can just insert double-quotes in the lyx code
environment, and do some hack so that it will be typeset by LaTeX too?

By the way, congratulations with your excellent and badly needed piece of
software!

Erik van der Meer

Re: Strange Bibtex behaviour ?

[Lars Gullik Bjønnes]

Florian Schopper <[EMAIL PROTECTED]> writes:

| Dear Lyxers,
| 
| in the attachment I added an example file (some files actually) with
| a main lyx file mytest.lyx and some others which are included.
| My Problem is that lyx doesn´t run bibtex any more if these files are 
| included (whatever is the true reason). The lyx version I used was 
| 1.1.4fix1.

Turn off the subfigure in Titel.lyx
That makes it tex with out warnings.

Also you should not need to have
\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}

in the preamble.

Lgb

PATCH: Re: [Rainer Hoffmann <rainer.hoffmann@ops.de>] Re: announce lyx-1.1.6pre2

[Angus Leeming]

Attached is the patch to the Color inherit is undefined or may not be 
redefined when LANG!=C problem.

Many thanks for the bug report, Rainer

Angus


> > yes remove the T1 encoding in the preferences -> output -> misc popup
>
> 1) That gave an interesting reaction (together with a long long beep):
>
> FormPreferences::Colors::apply: resetting LColor =FCbernehmen from "black"
> = to
> "linen".
> Color inherit is undefined or may not be redefined
> FormPreferences::Colors::apply: resetting LColor =FCbernehmen from "black"
> = to
> "light blue".
> Color inherit is undefined or may not be redefined

 patch.diff.bz2

Re: announce lyx-1.1.6pre2

[John Levon]

On Wed, 29 Nov 2000, Allan Rae wrote:

> Hmmm... The only reason OK should be disabled is if there is an invalid
> input (no filename, a page-to entry but no page-from entry and other
> obvious things).  I'll take a look.
> 
> Allan. (ARRae)
> 

Allan, I fixed it with the attached patch. It seems safe to tell the
controller that what we picked up from the printer params is valid.

thanks
john

-- 
"We signed to play until the day we died, and we did."
- Jimmy Greaves


? patch.diff
? printenable.diff
? src/a.diff
Index: ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/ChangeLog,v
retrieving revision 1.704
diff -u -p -r1.704 ChangeLog
--- ChangeLog   2000/11/29 15:34:56 1.704
+++ ChangeLog   2000/11/29 16:06:41
@@ -1,5 +1,10 @@
 2000-11-29  John Levon  <[EMAIL PROTECTED]>
 
+   * src/frontends/xforms/FormPrint.C: set to valid()
+   when we update from the passed parameters.
+
+2000-11-29  John Levon  <[EMAIL PROTECTED]>
+
* src/lyx_rc.C: more detail for the printer program config
dialog.
 
Index: po/POTFILES.in
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/po/POTFILES.in,v
retrieving revision 1.105
diff -u -p -r1.105 POTFILES.in
--- po/POTFILES.in  2000/11/28 15:54:29 1.105
+++ po/POTFILES.in  2000/11/29 16:06:41
@@ -48,35 +48,35 @@ src/frontends/kde/refdlg.C
 src/frontends/kde/tocdlg.C
 src/frontends/kde/urldlg.C
 src/frontends/xforms/FormBase.h
-src/frontends/xforms/form_citation.C
 src/frontends/xforms/FormCitation.C
-src/frontends/xforms/form_copyright.C
+src/frontends/xforms/form_citation.C
 src/frontends/xforms/FormCopyright.C
-src/frontends/xforms/form_document.C
+src/frontends/xforms/form_copyright.C
 src/frontends/xforms/FormDocument.C
-src/frontends/xforms/form_error.C
+src/frontends/xforms/form_document.C
 src/frontends/xforms/FormError.C
-src/frontends/xforms/form_graphics.C
+src/frontends/xforms/form_error.C
 src/frontends/xforms/FormGraphics.C
-src/frontends/xforms/form_index.C
+src/frontends/xforms/form_graphics.C
 src/frontends/xforms/FormIndex.C
+src/frontends/xforms/form_index.C
 src/frontends/xforms/FormInset.h
-src/frontends/xforms/form_paragraph.C
 src/frontends/xforms/FormParagraph.C
-src/frontends/xforms/form_preferences.C
+src/frontends/xforms/form_paragraph.C
 src/frontends/xforms/FormPreferences.C
-src/frontends/xforms/form_print.C
+src/frontends/xforms/form_preferences.C
 src/frontends/xforms/FormPrint.C
-src/frontends/xforms/form_ref.C
+src/frontends/xforms/form_print.C
 src/frontends/xforms/FormRef.C
-src/frontends/xforms/form_tabular.C
+src/frontends/xforms/form_ref.C
 src/frontends/xforms/FormTabular.C
-src/frontends/xforms/form_tabular_create.C
+src/frontends/xforms/form_tabular.C
 src/frontends/xforms/FormTabularCreate.C
-src/frontends/xforms/form_toc.C
+src/frontends/xforms/form_tabular_create.C
 src/frontends/xforms/FormToc.C
-src/frontends/xforms/form_url.C
+src/frontends/xforms/form_toc.C
 src/frontends/xforms/FormUrl.C
+src/frontends/xforms/form_url.C
 src/frontends/xforms/Menubar_pimpl.C
 src/frontends/xforms/xform_helpers.C
 src/gettext.h
Index: src/frontends/xforms/FormPrint.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/FormPrint.C,v
retrieving revision 1.14
diff -u -p -r1.14 FormPrint.C
--- src/frontends/xforms/FormPrint.C2000/11/28 06:46:06 1.14
+++ src/frontends/xforms/FormPrint.C2000/11/29 16:06:43
@@ -194,6 +194,7 @@ void FormPrint::update()
 
fl_set_input(dialog_->input_count,
 tostr(pp.count_copies).c_str());
+   bc_.valid();
}
 }
 

Re: PATCH: Re: [Rainer Hoffmann <rainer.hoffmann@ops.de>] Re: announce lyx-1.1.6pre2

[Lars Gullik Bjønnes]

Angus Leeming <[EMAIL PROTECTED]> writes:

| Attached is the patch to the Color inherit is undefined or may not be 
| redefined when LANG!=C problem.

I'll apply this.

Lgb

Bug in configure.in?

[Michal Kuratczyk]

Hi,

I just updated my CVS:
kura@apokalipsa:~/soft/lyx-devel % make
...
checking for strerror... (cached) yes
checking for atexit... (cached) yes
./configure[11342]: syntax error: `mkstemp,unistd.h' unexpected
make: *** [config.status] Bd 1
kura@apokalipsa:~/soft/lyx-devel %

Best regards,
-- 
Michal Kuratczyk <[EMAIL PROTECTED]>

Re: Bug in configure.in?

[Kayvan A. Sylvan]

On Wed, Nov 29, 2000 at 05:54:47PM +0100, Michal Kuratczyk wrote:
> Hi,
> 
> I just updated my CVS:
> kura@apokalipsa:~/soft/lyx-devel % make
> ...
> checking for strerror... (cached) yes
> checking for atexit... (cached) yes
> ./configure[11342]: syntax error: `mkstemp,unistd.h' unexpected
> make: *** [config.status] B??d 1
> kura@apokalipsa:~/soft/lyx-devel %
> 
> Best regards,
> -- 
> Michal Kuratczyk <[EMAIL PROTECTED]>

Did you run ./autogen.sh ?

I recommend "make maintainer-clean; ./autogen.sh"

-- 
Kayvan A. Sylvan   | Proud husband of  | Father to my kids:
Sylvan Associates, Inc.| Laura Isabella Sylvan | Katherine Yelena
http://www.successlinks.com/kayvan | Reach your goals now! | Robin Gregory

Re: announce lyx-1.1.6pre2

[Kayvan A. Sylvan]

On Tue, Nov 28, 2000 at 11:37:04PM +0100, Lars Gullik Bjønnes wrote:
> Herbert Voss <[EMAIL PROTECTED]> writes:
> 
> | "Lars Gullik Bjønnes" wrote:
> | > 
> | > The second prerelease of 1.1.6 has been available for some days now,
> | > and this time it is also announced here and not just on the developers
> | > list.
> | 
> | when the printing menu is opened, by default the button "all pages"
> | is valid. but it's not possible to click on the ok-button, i had
> | to click on the "all-pages-button" (or any other) and than 
> | printing is possible.
> 
> In addition to this it seems printing has a problem. I am not able to
> print to my postscript printer from inside lyx, but have to export to
> postscript first and run lpr manually

Oh really? I just click on the "file" box and back to the "printer" box
and then I can hit OK to print.

The validate() fix seems like a good idea.

-- 
Kayvan A. Sylvan   | Proud husband of  | Father to my kids:
Sylvan Associates, Inc.| Laura Isabella Sylvan | Katherine Yelena
http://www.successlinks.com/kayvan | Reach your goals now! | Robin Gregory

Re: UserGuide question

[Lars Gullik Bjønnes]

Angus Leeming <[EMAIL PROTECTED]> writes:

| In the UserGuide :
| 
| The undo-mechanism has been limited to 100 steps in the beta-version, as this 
| feature has not yet been properly tested out.
| 
| Is this still true?

Probably not.

| 
| In lyxfunc.C::Dispatch()
|   case LFUN_UNDO:
|   disable = buf->undostack.empty();
|   break;
| 
| I can see no limit here.

I think the limit was removed when we switched to std::containers.

Lgb

Re: announce lyx-1.1.6pre2

[Garst R. Reese]

"Kayvan A. Sylvan" wrote:

> Oh really? I just click on the "file" box and back to the "printer" box
> and then I can hit OK to print.
Just clicking on the already yellow "printer" box does it for me. If
neither box was already yellow, this would be clear. Most of the time I
print to file anyway, because I have work to do with psutils. It would
be nice if the psutils functionality was integrated into LyX.
Particularly -nup and output papersize. Over a year ago I e-mailed
Duggan about some updates to psutils and he said he was coming out with
a completely rewritten version in "a couple of months." It never
happened.
Garst

Re: UserGuide question

[Lars Gullik Bjønnes]

Angus Leeming <[EMAIL PROTECTED]> writes:

| In the UserGuide :
| 
| The undo-mechanism has been limited to 100 steps in the beta-version, as this 
| feature has not yet been properly tested out.
| 
| Is this still true?
| 
| In lyxfunc.C::Dispatch()
|   case LFUN_UNDO:
|   disable = buf->undostack.empty();
|   break;
| 
| I can see no limit here.

Actually we have a limit:

src/undo.C:83,92

This limit is initialized to 100.

There is a problem with having no limit... we will always keep undo
information from the momemnt when lyx was started and for long runs
this can be a long time and a lot of bits in the undo stack...

Lgb

Re: announce lyx-1.1.6pre2

[Lars Gullik Bjønnes]

"Garst R. Reese" <[EMAIL PROTECTED]> writes:

| "Kayvan A. Sylvan" wrote:
| 
| > Oh really? I just click on the "file" box and back to the "printer" box
| > and then I can hit OK to print.
| Just clicking on the already yellow "printer" box does it for me. If
| neither box was already yellow, this would be clear. Most of the time I
| print to file anyway, because I have work to do with psutils. It would
| be nice if the psutils functionality was integrated into LyX.

I have it on my list...

Lgb

Re: UserGuide question

[Angus Leeming]

Lars, 
Just read your mail saying that a limit does exist. Fair enough. I'll modify 
the UserGuide to say that this is so (ie, not a feature of the beta version, 
now superceeded.)

Next question. Just beneath this last statement in the UserGuide we have:

Notice that if you revert back all changes to arrive to the document as it 
was last saved, the "changed" status of the document is unfortunately not 
reset. This is a known bug.

I guess that this is a consequence of the above, no? We can't apply the 
following fix, because the limit means that changes will be popped off the 
stack.

case LFUN_UNDO:
disable = buf->undostack.empty();
+   if (disable)
+   buf->markLyxClean();
break;  

Is my reasoning correct here? I'll modify the documentation to reflect this.

Angus


On Wednesday 29 November 2000 17:42, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> | In the UserGuide :
> |
> | The undo-mechanism has been limited to 100 steps in the beta-version, as
> | this feature has not yet been properly tested out.
> |
> | Is this still true?
>
> Probably not.
>
> | In lyxfunc.C::Dispatch()
> | case LFUN_UNDO:
> | disable = buf->undostack.empty();
> | break;
> |
> | I can see no limit here.
>
> I think the limit was removed when we switched to std::containers.
>
> Lgb

Re: UserGuide question

[Lars Gullik Bjønnes]

Angus Leeming <[EMAIL PROTECTED]> writes:

| Next question. Just beneath this last statement in the UserGuide we have:
| 
| Notice that if you revert back all changes to arrive to the document as it 
| was last saved, the "changed" status of the document is unfortunately not 
| reset. This is a known bug.

It is a bug...

| I guess that this is a consequence of the above, no? We can't apply the 
| following fix, because the limit means that changes will be popped off the 
| stack.
| 
|   case LFUN_UNDO:
|   disable = buf->undostack.empty();
| + if (disable)
| + buf->markLyxClean();
|   break;

This patch would be wrong anyway...

To do anything else we would have to store the status in the undo
information, but only act upon it if there were no other undo objects
belonging to the same buffer.

And later when we have a "pick the undo you want to apply now" this
will be interesting.

That said I think we should support clearing of the changed flag if we
are sure about the state, but we are not there yet.

| Is my reasoning correct here? I'll modify the documentation to
|  reflect this.

I don't think you are far off...

Lgb

PATCH: FormRef

[Angus Leeming]

Attached is a tiny patch to FormRef. Clicking on different insets when the 
sort key was activated was a bit odd before this fix ;-)

Angus

 patch.diff.bz2

Re: PATCH: FormRef

[Lars Gullik Bjønnes]

Angus Leeming <[EMAIL PROTECTED]> writes:

| Attached is a tiny patch to FormRef. Clicking on different insets when the 
| sort key was activated was a bit odd before this fix ;-)

+   if (cit != keys.end()) {
+   int const i = static_cast(cit - keys.begin());


Not sure if I agree with this one (oh the patch is ok)

but ...

vector::difference_type const i = cit - keys.begin();

seems better?

But then perhaps you will need casts otherplaces so I don't know...

Anyway keep all the typedefs for the different std::constainers in
mind when using them.

I'll apply the patch.

Lgb

Re: PATCH: FormRef

[Angus Leeming]

Well, it's always good to get hints on better practice, but in this case "i" 
is used only in calls to xforms routines and so an int is the required type.

Angus


On Wednesday 29 November 2000 19:37, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> | Attached is a tiny patch to FormRef. Clicking on different insets when
> | the sort key was activated was a bit odd before this fix ;-)
>
> +   if (cit != keys.end()) {
> +   int const i = static_cast(cit - keys.begin());
>
>
> Not sure if I agree with this one (oh the patch is ok)
>
> but ...
>
> vector::difference_type const i = cit - keys.begin();
>
> seems better?
>
> But then perhaps you will need casts otherplaces so I don't know...
>
> Anyway keep all the typedefs for the different std::constainers in
> mind when using them.
>
> I'll apply the patch.
>
> Lgb

footnote

[Sencer Ecer]

Hi,

It seems footnotes don't wotk properly. They sometimes don't appear except
a line in the bottom of the text, otherwise without any numbers. 

Re: footnote

[Garst R. Reese]

Sencer Ecer wrote:
> 
> Hi,
> 
> It seems footnotes don't wotk properly. They sometimes don't appear except
> a line in the bottom of the text, otherwise without any numbers.
What version of LyX are you using? What platform?
Garst

Re: multicolumn in 1.1.6pre2

[Jürgen Vigna]

[EMAIL PROTECTED], [EMAIL PROTECTED] wrote:
>
>On Mon, 27 Nov 2000, Jürgen Vigna wrote:

>Sorry, I didn't realise you didn't have easy access to the source as
>well. This is InsetTabular::draw(), inside the need_update == CELL
>case. It comes *after* the code that does the

H I thought about the problem and probably it should be solved in the
Selection area (InsetButtonMotionNotify) and there if the selection goes
over one cell the inset should be unlocked so this type of stuff cannot happen!

>GetWidthOfColumn() GetAscentOfRow() stuff - is that where you mean ?
>

No I thought it was in update() which calls the function to recalculate the
width of the columns (cells) CalculateWidthOfTabular (or something like that ;)

>I'm not sure what you mean here, I can't select stuff without the text
>cursor following. And shouldn't I be able to get it to redraw properly
>later ?

Do you select with mouse or with cusor keys? Please try to do the same
(selecting more cells) but using Shift-CursorRight AND also enter the
tabular with the cursor (so you'll see the cursor inside the cell blinking
but no border around the cells text is written.

>> void InsetTabular::UpdateLocal(BufferView * bv, UpdateCodes what,
>>bool mark_dirty) const
>> {
>> if ((what == INIT) && the_locking_inset) {
>> the_locking_inset->InsetUnlock(bv);
>> the_locking_inset = 0;
>> }
>> 
>> }
>I had to make the_locking_inset member mutable as well. Unfortunately this
>didn't help. I still get the ERROR every time I select "multicolumn". I
>wish I could help further but I've never seen this code before ;)

You didn't look good IMO, you shouldn't put the above code in the draw() function
(which is const) but at the top of UpdateLocal! Please retry (althougth the above
mentioned solution would be the best one!)

Could you please try again?

Greets Jürgen

Re: [PATCH] cleanups

[Allan Rae]

On Wed, 29 Nov 2000, John Levon wrote:

> p.s. is there any chance POTFILES.in can get cvs removed ? It is very
> galling having to delete it each time from the diff

Then don't delete it.

It is possible to build POTFILES.in from autogen.sh (if we copy it back in
there from po/Makefile.in.in (note: I said copy not move)) from a clean
cvs checkout and then keep it up to date with the new additions to
po/Makefile.in.in. I don't think we need it in CVS anymore if that change
is made since when someone does a `make dist` they'll get an updated
POTFILES.in anyway.  Unless someone can think of a reason why we need it
in CVS I think we can now remove (once I copy the POTFILES.in generation
code back into autogen.sh -- I'll do some testing in my tree). 

The thing I find strange is why the sorted order of the files in
POTFILES.in changes depending on who is sending a patch.  What system are
you running?  Are you on an Alpha like Angus? (whose patches also seem to
change the sorted order)

Seems some systems implementation of sort respond slightly differently to
the -f and -d flags.

Allan.  (ARRae)

compile error

[Ron Peterson]

I'm such a newbie I haven't even _compiled_ LyX yet...

gcc version 2.96 2731 (Red Hat Linux 7.0)

I'm not doing anything fancy.  Just './configure --prefix=/foo/bar',
then 'make'.

Any suggestions?  Don't worry about wounding my pride. ;^)

make[3]: Entering directory `/usr/local/src/lyx-1.1.5fix2/src/mathed'
/bin/sh ../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I.
-I../../src -I../../images -I./../   -isystem /usr/X11R6/include  -g -O2
-fno-rtti -fno-exceptions -c formula.C
g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I../../images -I./../ -isystem
/usr/X11R6/include -g -O2 -fno-rtti -fno-exceptions -c formula.C -o
formula.o
In file included from formula.C:20:
/usr/include/g++-3/sstream: In method `string stringstreambase::str ()
const':
/usr/include/g++-3/sstream:102: taking dynamic typeid of object with
-fno-rtti
/usr/include/g++-3/sstream: In method `void stringstreambase::str
(const string &)':
/usr/include/g++-3/sstream:107: taking dynamic typeid of object with
-fno-rtti
In file included from ../../src/lyxfont.h:22,
 from ../../src/insets/lyxinset.h:24,
 from formula.h:27,
 from formula.C:30:
../../src/LString.h: At top level:
../../src/LString.h:21: conflicting types for `typedef class lyxstring
string'
/usr/include/g++-3/string:9: previous declaration as `typedef class
basic_string > string'
make[3]: *** [formula.lo] Error 1
make[3]: Leaving directory `/usr/local/src/lyx-1.1.5fix2/src/mathed'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/local/src/lyx-1.1.5fix2/src'
make[1]: *** [all-recursive-am] Error 2
make[1]: Leaving directory `/usr/local/src/lyx-1.1.5fix2/src'
make: *** [all-recursive] Error 1

-- 

Ron Peterson
9 Morgan Street, Apt. 'A'
South Hadley, MA  01075
413.536.1146 tel
[EMAIL PROTECTED]

Insert Figure

[Garst R. Reese]

Insert Figure still asks for a .EPS file
A .ps file works as well, but with all of the new converters, shouldn't
it be possible to insert other formats? e.g., .fig
Garst

Re: announce lyx-1.1.6pre2

[Martin Vermeer]

On Wed, Nov 29, 2000 at 08:45:36AM +0100, Rainer Hoffmann wrote:
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Precedence: bulk
> X-No-Archive: yes
> List-Post: 
> List-Help: 
> List-Unsubscribe: 
> Delivered-To: mailing list [EMAIL PROTECTED]
> X-Envelope-Sender-Is: [EMAIL PROTECTED] (at relayer oi419e.ops.de)
> X-Amavis-approved: Yes
> Date: Wed, 29 Nov 2000 08:45:36 +0100
> From: Rainer Hoffmann <[EMAIL PROTECTED]>
> Organization: Oce Printing Systems
> X-Mailer: Mozilla 4.5 [de] (WinNT; I)
> X-Accept-Language: de
> To: Lars Gullik Bjønnes <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: Re: announce lyx-1.1.6pre2
> 
> Hi all,
> 
> 1) I downloaded the .tar.gz-file, .configured, maked and started it with src/lyx
> Then the following messages came:
> LyX: Unknown LyX function `buffer-fax' [around line 60 of file
> ~/Software/lyx-1.1.6pre2/lib/bind/de_menus.bind]
> LyX: Unknown LyX function `layout-paper' [around line 114 of file
> ~/Software/lyx-1.1.6pre2/lib/bind/de_menus.bind]
> LyX: Unknown LyX function `layout-table' [around line 115 of file
> ~/Software/lyx-1.1.6pre2/lib/bind/de_menus.bind]
> LyX: Unknown LyX function `layout-quotes' [around line 116 of file
> ~/Software/lyx-1.1.6pre2/lib/bind/de_menus.bind]
> LyX: Unknown LyX function `buffer-itemize-bullets-select' [around line 125 of
> file ~/Software/lyx-1.1.6pre2/lib/bind/de_menus.bind]
> LyX: Unknown LyX function `table-insert' [around line 131 of file
> ~/Software/lyx-1.1.6pre2/lib/bind/de_menus.bind]

That's because the lyxrc format has changed.
 
> Lyx started nevertheless.
> 
> 2) Then I opened an old document from 1.1.5
> 
> The messages were

... (postscript messages) ...
 
> Yet, the document was opened and displayed correctly
> 
> 3) I tried the PDF-Export:
> The fonts on the screen with acrobat reader were ugly. Looked like bitmap fonts.
> Can that be changed?

YES!! 

\usepackage{ae} 

in the preamble gives you "almost European", an outline version of Computer Modern.
(I find it less aestetic than CM, but in acroread it looks better)

Alternatively, use any of the other font packages like palatino.sty,
times.sty, bookman.sty, newcent.sty, ... most of them are outline IIRC.

 
> Bye,
> 
> Rainer Hoffmann
> 

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