Re: Dead keys kill lyx

[Juergen Vigna]

On 28-Oct-2000 Lars Gullik Bjønnes wrote:

| Is this a known problem with a fix?  Or should I try to do
| something myself?
| I don't know how hard it is to fix, but a lyx that don't die
| from a unexpected key would be nice.  Having the key perform
| correctly would be even better of course.
 
 Sure, even if we can't make it work we should absolutely not crash.

IMO I've a partial fix for this and will commit it now, as I've had
a crash at home using an american-2.kmap (reading it on startup) and
I've seen that this is due to changes from char array to string array!

Please have a look at this as I really don't like the fix I made but
it was the fastest way and I'm not that used to this code-part!

  Jürgen


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

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

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

Goodbye, cool world.

Re: language settings vs. spell checker

[Juergen Vigna]

On 29-Oct-2000 Dekel Tsur wrote:
 
 Why not add new fields to the languages file (ispell name, keymap name) ?
 The only drawback is decreasing the readability of this file.

No we don't want this! It is much easier to just do a symlink from your
dictionary in "native language" to the one in english (and we don't know
how someone calls the dictionary on his filesystem!).

ln -s deutsch german
ln -s italiano italian
ln -s nederland dutch

...

And you'll see you'll find all you want!

 Jürgen

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

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

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

Where am I?  Who am I?  Am I?  I

Re: thesis cont.

[Jean-Marc Lasgouttes]

 "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

Lars Juergen Vigna [EMAIL PROTECTED] writes: | Yesterday I thought about
Lars this (actually because of caption and captions | in longtabulars
Lars ;) and this will be fairly easy IMO, just create an inset | with
Lars 2 textinsets one for entering the "short description" one for
Lars entering | the "long description" that's it. IMO we could also
Lars make this more general | quite easily.

Lars Something _very_ like this is the plan... :-)

I am not sure that this is the best way: IMO, a section heading,
theorem or list item (all these will need an extra text inset) are
first of all a normal paragraph. So the 'long description' should not
be put in a special place, but rather be the paragraph content. 

However, all these examples have in common that they need a special
label. Therefore, it seems to me that the extra text inset should be
related to the label of paragraph (the LabelType in layout files). I
believe that it is better than having everything in insets (would you
ever want to insert a section 'inset' in the middle of a sentence??).

JMarc

Re: Problem compiling lyx 1.1.6 on OSF 4 alpha

[Jean-Marc Lasgouttes]

 "Yann" == Yann MORERE [EMAIL PROTECTED] writes:

 This might work: confiugre lyx with --with-inluded-string, that
 will make the mangled name of a lot of functions be a lot a
 shorter.


Yann sorry but it doesn't work, all same errors...

Are you sure?? First remove config.cache, and then reconfigure with
--with-included-string. Then 'make clean' 'make'. This works for me on
my alpha.

JMarc

Re: FormPreferences patch

[Jean-Marc Lasgouttes]

 "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

Lars Imho bindings should go into their own file, why they can very
Lars well be edited from preferences.

I'll reiterate the opinion that they should go in ui/. THey are just
another (non-graphical) way for the user to access lyxfuncs.

JMarc

Re: docbook support for insettabular.

[Jose Abilio Oliveira Matos]

On Fri, Oct 27, 2000 at 05:49:13PM +0200, Dekel Tsur wrote:
 
 This happens if your temp. directory is on a different filesystem than the lyx
 file directory (as the converter try to _move_ the file between these
 directories, which fails), or if the converter creates multiple output files 
 (e.g. foo.html, foo_1.html, foo_2.html...).
 I'll fix these problems soon.

  Yes, that is the case. /tmp is in a different fs that /home.
  And yes the converter also creates multiple files in a it's own directory.
  
  Thanks.
-- 
José

Re: language settings vs. spell checker

[Jean-Marc Lasgouttes]

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

Dekel Why not add new fields to the languages file (ispell name,
Dekel keymap name) ? The only drawback is decreasing the readability
Dekel of this file. 

If readability is a problem, it should be turned into

Language "canadien"
  Description "French Canadian"
  RTL false
  Encoding iso8859-1
  Code fr_CA
  BabelName frenchb
  IspellDict french
End

Much more readable, IMO.

JMarc

Re: language settings vs. spell checker

[Jean-Marc Lasgouttes]

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

Juergen No we don't want this! It is much easier to just do a symlink
Juergen from your dictionary in "native language" to the one in
Juergen english (and we don't know how someone calls the dictionary
Juergen on his filesystem!).

We certainly do not want to force users to do symlinks just for LyX...
We can at least have defaults which are the names of the distributed
ispell dictionaries.

JMarc

Re: Preferences dialog: Save = Close ??

[Angus Leeming]

On Sun, 29 Oct 2000, R. Lahaye wrote:
 Hi,

 The Save button in the Preferences dialog
 does the save, but also closes the dialog.

 Is that appropriate?

 I myself do not expect the dialog to close
 automagically after a save.

This is what might be called a bug. I'm not sure.

The idea behind the buttons in the preferences dialog is 
"Close/Cancel": self explanatory?
"Apply":apply these changes for this session only.
"Save": save these changes so that they can be applied next time also.

Would you rather press Save and then Close or have the button called 
SaveClose?

Angus

Re: Reference dialog has two different appearances?

[Angus Leeming]

On Sat, 28 Oct 2000, R. Lahaye wrote:
 Hi,

 I discovered that the Reference dialog has two faces:
 (1) When performing a Insert-Cross reference.
 (2) When Left-Mouse-Clicking on an existing reference.

 The appearance in (2) looks like a stripped version of (1).
 (the selection field, Update and Sort buttons have
 been removed).

 However, I would strongly prefer to have the same (full)
 dialog in both cases (for (2) you may force a highlight
 of the corresponding reference in the selection field).

 The stripped dialog does not allow me to change an existing
 reference to another one. Why? To do that now, I have to
 first delete the existing one, then Insert-Reference a new
 one. The full dialog popup with an existing reference,
 would allow me to do the two steps in just one!

Because they are conceptually different things. Changing the reference is 
equivalent to entering a new one. This will not change.

 A bug is in the (two) reference dialogs:

 - Do an "Insert-Cross reference".
   This will popup the full Reference dialog.

 - Leave the previous Reference dialog open, but now
   also Left-Mouse-Click on an existing reference in
   the text. The already open Reference dialog is resized,
   but filled with "blank space" (nothing in it).

Thanks, Rob. This is a bug. I'll have a look.
Angus

Re: FormPreferences patch

[Jean-Marc Lasgouttes]

Angus, it would be much better to use a combox for the list of
languages (it is too long here). Moreover, the old way of using the
list of languages for kmaps is plain wrong. You should get (in some
way) the list of available kmap files (either hardcoded or from
a text file).

JMarc

Re: Patch: tiny typo in lyx.man

[Jean-Marc Lasgouttes]

 "R" == R Lahaye [EMAIL PROTECTED] writes:

R This only removes a return and space so that "X (1)", becomes
R "X(1)" in the man pages.

Applied. Thanks.

JMarc

Re: gnome: cleanup and update() to updateSlot()

[Jean-Marc Lasgouttes]

 "Marko" == Marko Vendelin [EMAIL PROTECTED] writes:

Marko the attached patch replaces NULL with 0 in the gnome frontend
Marko code and makes the frontend to compile again by
Marko replacing/adding update() with updateSlot() where appropriate.
Marko It seems that DialogBase is changing its methods quite often
Marko which is one more good reason to establish class hierarchy
Marko among gnome frontend classes.

Hi,

Is there a particular reason why you use:
  if (search_text_ != 0) search_text_-save_history();
instead of
  if (search_text_) search_text_-save_history();

The second form is used commonly in LyX code.

I'll apply the patch.

JMarc

Re: gnome: cleanup and update() to updateSlot()

[Marko Vendelin]

On 30 Oct 2000, Jean-Marc Lasgouttes wrote:

  "Marko" == Marko Vendelin [EMAIL PROTECTED] writes:
 
 Marko the attached patch replaces NULL with 0 in the gnome frontend
 Marko code and makes the frontend to compile again by
 Marko replacing/adding update() with updateSlot() where appropriate.
 Marko It seems that DialogBase is changing its methods quite often
 Marko which is one more good reason to establish class hierarchy
 Marko among gnome frontend classes.
 
 Hi,
 
 Is there a particular reason why you use:
   if (search_text_ != 0) search_text_-save_history();
 instead of
   if (search_text_) search_text_-save_history();
 
 The second form is used commonly in LyX code.

That what hapens if you replace NULL with 0. I'll replace "if
(search_text_ != 0) " with "if (search_text_)" in the code later.

Marko

Re: FormPreferences patch

[Juergen Vigna]

On 30-Oct-2000 Angus Leeming wrote:
 Angus, it would be much better to use a combox for the list of
 languages (it is too long here).
 
 How would using a combox make it shorter? I'm happy to make it a combox, but 
 this just seems to be style rather than substance.
 

Well have a look at the document-languages combox ;), it doen't make the
list shorter only the combox is scrollable!

  Jürgen

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

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

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

One advantage of talking to yourself is that you know at least somebody's
listening.
-- Franklin P. Jones

Re: FormPreferences patch

[Angus Leeming]

On Mon, 30 Oct 2000, Juergen Vigna wrote:
 On 30-Oct-2000 Angus Leeming wrote:
  Angus, it would be much better to use a combox for the list of
  languages (it is too long here).
 
  How would using a combox make it shorter? I'm happy to make it a combox,
  but this just seems to be style rather than substance.

 Well have a look at the document-languages combox ;), it doen't make the
 list shorter only the combox is scrollable!

   Jürgen

H! But I can not use the key shortcut #L to "launch" the combox (try!) 
and then use the arrow keys to scroll through it. I can do this with the 
current set up. 

This isn't to say that the current set up is better, (clearly it isn't), but 
combox should be extended so that the user can use shortcuts to navigate it. 

Thanks for the info.
Angus

Re: lyx-1.1.6pre1 is out

[Juergen Vigna]

On 26-Oct-2000 Garst R. Reese wrote:

 I'm beginning to wonder if this is a bug or a feature, but at least it
 is surprising behaviour :)

It was obviously a feature!

 I have two tables in a row. When I load the file and page down it gets
 to the tables and then alternates between the two until I use the scroll
 bar to move further down.

But as you don't like it I decided to change it and so you can scroll now
also down/up with this keys. #:O)

Jürgen

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

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

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

I judge a religion as being good or bad based on whether its adherents
become better people as a result of practicing it.
- Joe Mullally, computer salesman

RE: jumping math-cursor in table

[Juergen Vigna]

On 27-Oct-2000 R. Lahaye wrote:
 
 When I go into math mode in a tabular cell, the
 cursor all of a sudden jumps up a line or two.
 Typed characters still appear in the tabular cell,
 but the blinking cursor is elsewhere!

Fixed!

Thanks,

  Jürgen

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

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

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

Bower's Law:
Talent goes where the action is.

Re: Preferences dialog: Save = Close ??

[Angus Leeming]

On Mon, 30 Oct 2000, R. Lahaye wrote:
 Angus Leeming wrote:
  The idea behind the buttons in the preferences dialog is
  "Close/Cancel": self explanatory?
  "Apply":apply these changes for this session only.
  "Save": save these changes so that they can be applied
  next time also.
  Would you rather press Save and then Close or have the button called
  SaveClose?

 I would then use merely three buttons in this dialog:
 OK: apply the preferences to the current document(s)
   (do NOT save them for a next session).
   Close also the preferences dialog.

 Save: save the the settings to file and *apply* also
 to current document(s); these settings will
 also be used next time LyX is started.
 Do NOT close the dialog.

 Cancel: close the window without saving or applying anything.

Well now. You are merely introducing a slightly different way of doing 
things. One way is no better than the other IMO. Users will soon learn what 
happens.

 I would strongly recommend to drop the Restore button.
 What does it restore? The saved settings, or the 'OK'ed
 settings? Or the system-wide settings? Far too un-intuitive!

This is now it works.
You play with the settings, but decide that you don't want to apply them, so 
"Restore" the settings to the current contents of lyxrc (ie, what are 
displayed should you press Cancel and then launch the dialog again).

A

Error in Sides with Document Layout dialog?

[R. Lahaye]

Hi,

The "Sides = Two" check box can't be saved.
Whatever I do, it always shows up as "One".

Is this a bug?

Rob.

Re: warning from FormPreferences.C

[Angus Leeming]

On Mon, 30 Oct 2000, R. Lahaye wrote:
 FormPreferences.C: In method `void FormPreferences::applyScreenFonts()':
 FormPreferences.C:1141: warning: initialization to `int' from `double'

 int ivalue = fl_get_counter_value(screen_fonts_-counter_zoom);

 Rob.

Thanks. Fixed.
A.

Re: lyx-1.1.5fix2 on irix 6.5

[Jean-Marc Lasgouttes]

 "Eli" == Eli Tziperman [EMAIL PROTECTED] writes:

Eli Hello Lyx experts, Like in 1.1.5fix1, version 1.1.5fix2 still has
Eli problems compiling on irix 6.5. Actually the linking seems to be
Eli the problem now. Am I doing something wrong?

It seems that you have to remove the -L/usr/lib from the library list.
The following message gives an alternate solution (but you probably
already know that). There is no generic fix that I know of that we
could apply for irix 6.5...

http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg15131.html

JMarc

Re: FormPreferences patch

[Lars Gullik Bjønnes]

Angus Leeming [EMAIL PROTECTED] writes:

| H! But I can not use the key shortcut #L to "launch" the combox (try!) 
| and then use the arrow keys to scroll through it. I can do this with the 
| current set up. 

Probably missing from the combox code... patches will be accepted.

| This isn't to say that the current set up is better, (clearly it isn't), but 
| combox should be extended so that the user can use shortcuts to
| navigate it. 

as said...

Lgb

Re: FormPreferences patch

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

|  "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
| 
| Lars Imho bindings should go into their own file, why they can very
| Lars well be edited from preferences.
| 
| I'll reiterate the opinion that they should go in ui/. THey are just
| another (non-graphical) way for the user to access lyxfuncs.

I can agree on that, but they should _not_ be in defult.ui.

besides I don't think we should put too many levels of directories in
.lyx but rather keep it as flat as possible.

Lgb

Re: FormPreferences patch

[Angus Leeming]

Thanks for the various bits of feedback.

Attached is a patch that adds one or two missing variables to FormPreferences.
It also cleans up the existing code:
* I've moved the various Feedback messages into LyXRC to avoid duplication in 
the other frontends.
* We select the languages using a Combox, rather than a choice.
* feedback is now output via a timer callback loop that is functionally 
identical to that in Toolbar_pimpl. No longer any need to change an entry to 
get feedback. The only items not providing feedback are the new Comboxes!

All changes follow suggestions by JMarc!
Angus


Below is an updated list of what needs doing in FormPreferences.

Main Dialog-LookFeel-Colours
Ability to set colours of background, text, notes etc.
\set_color

Main Dialog-I/O  // New Tab, because converters cover Input AND Output.
\converter
\Format

Main Dialog-Outputs-Fax
string fax_command; * Are these still needed?
string phone_book;
string fax_program;

Main Dialog-Outputs-Viewers
\viewer

In addition, we need to add the ability to edit individual \bind entries. (Or 
at least input the file containing the users choices.)

Multiple \converter, \viewer (and \bind) commands will be input using 
tabs of the format suggested by Dekel:

+--+++
|dvi   | format |dvi |
|ps|++
|  |++
|  | viewer |xdvi|

+--+++
+---+--+---+
|Add|Delete|Replace|

+---+--+---+



 patch_preferences.bz2

Re: language settings vs. spell checker

[Lars Gullik Bjønnes]

Dekel Tsur [EMAIL PROTECTED] writes:

| On Sun, Oct 29, 2000 at 08:28:22AM +0100, Lars Gullik Bjønnes wrote:
|  
|  | 2) Another solution for 1) could be changing the
|  |language file, that comes with LyX. The first
|  |and second column in this file are ALWAYS the
|  |same. Why is that? We could use the second column
|  |for an equivalent language name, for example:
|  
|  Did you check the meanings of the fields?
| 
| The second field is the babel name of the language, and it is not always
| equal to the first field (the LyX name).
| 
|  I'd rather remove one of the fields instead of adding more.
|  (but then we would need a "babel" module.
| 
| Why not add new fields to the languages file (ispell name, keymap name) ?
| The only drawback is decreasing the readability of this file.

And imposing addtional dependencies... it is ok for the ispell/babel
modules to depend on the language struct in LyX, but not ok for the
language struct to depend upon the ispell/babel module.

Lgb

Re: Dead keys kill lyx

[Lars Gullik Bjønnes]

Juergen Vigna [EMAIL PROTECTED] writes:

| IMO I've a partial fix for this and will commit it now, as I've had
| a crash at home using an american-2.kmap (reading it on startup) and
| I've seen that this is due to changes from char array to string array!
| 
| Please have a look at this as I really don't like the fix I made but
| it was the fastest way and I'm not that used to this code-part!

I altered your fix a bit, a bit cleaner but not perfect.

Lgb

Re: thesis cont.

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

|  "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
| 
| Lars Juergen Vigna [EMAIL PROTECTED] writes: | Yesterday I thought about
| Lars this (actually because of caption and captions | in longtabulars
| Lars ;) and this will be fairly easy IMO, just create an inset | with
| Lars 2 textinsets one for entering the "short description" one for
| Lars entering | the "long description" that's it. IMO we could also
| Lars make this more general | quite easily.
| 
| Lars Something _very_ like this is the plan... :-)
| 
| I am not sure that this is the best way: IMO, a section heading,
| theorem or list item (all these will need an extra text inset) are
| first of all a normal paragraph.

Actually they are normal paragraps only because LyXParagraph contains
special code to deal with them.

We want them moved into insets.

| So the 'long description' should not
| be put in a special place, but rather be the paragraph content. 
| 
| However, all these examples have in common that they need a special
| label. Therefore, it seems to me that the extra text inset should be
| related to the label of paragraph (the LabelType in layout files). I
| believe that it is better than having everything in insets (would you
| ever want to insert a section 'inset' in the middle of a
| sentence??).

Why should a paragraph containa LabelType at all?

and I disagree.

Lgb

Re: Fun with wdiff

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

| I have been playing a bit with wdiff 
|   http://www.iro.umontreal.ca/~pinard/wdiff/HTML/
| to see whether we can compare two versions of the same file. It turns
| out that this is possible, although a lot of work still has to be
| done.
| 
| I took revision 1.23 of BUGS.lyx from cvs, along with latest version.
| I edited the language of the former because preambles were different.
| Then running
| 
| wdiff -w'\color red ' -x'\color default ' -y'\color green ' -z'\color default ' 
|BUGS-1.23.lyx BUGS.lyx BUGS-diff.lyx
| 
| I get the following file:
|   http://www-rocq.inria.fr/~lasgoutt/lyx/BUGS-diff.lyx
| 
| Of course, this is not usable for real work now:
| 
| - we should have real markers for deleted/added entries, not color
|   change as we have now. And then support for accepting/rejecting
|   modifcations, like in word.

We need insets for that.

| - currently, if there is a change in a math formula, for example, ugly
|   things will happen. We should have a (perl?) postprocessor to fix
|   those marks.
| 
| However, I find the result to be rather interesting.

Yes, I have been thinking about this also, but have put of any work
until we get the core of lyx cleaned up a bit.

Lgb

Re: FormPreferences patch

[Lars Gullik Bjønnes]

Angus Leeming [EMAIL PROTECTED] writes:

| Thanks for the various bits of feedback.
| 
| Attached is a patch that adds one or two missing variables to
| FormPreferences. 
| It also cleans up the existing code:
| * I've moved the various Feedback messages into LyXRC to avoid
| duplication in 

I think you used the wrong name for getFeedback, imho it should have
been getDescription.


| * We select the languages using a Combox, rather than a choice.

good.

| * feedback is now output via a timer callback loop that is functionally 
| identical to that in Toolbar_pimpl. No longer any need to change an entry to 
| get feedback. The only items not providing feedback are the new
| Comboxes!

I never liked the hidden timers.

| Main Dialog-Outputs-Fax
|   string fax_command; * Are these still needed?
|   string phone_book;
|   string fax_program;

No, we want to set this code inactive. I'll do that.
We will only enable it if a lot of users complain.

| 
| Main Dialog-Outputs-Viewers
|   \viewer
| 
| In addition, we need to add the ability to edit individual \bind
| entries. (Or| at least input the file containing the users choices.)

Yes, we don't need the full fledged online bind editing now.
Actually we have all we need already since you can name your own bind
file in the bind input and from that file inlucde the bind file that
you base it on.

Lgb

Re: Math editor patches

[Dekel Tsur]

On Tue, Oct 24, 2000 at 08:44:14PM +0200, Stephen Reindl wrote:

 If I switch to math-text mode (via M-m m) I cannot enter digits and
 special characters in
 text mode. Everytime I enter a Digit or a closing paren (e.g. "2.2.3)")
 these digits are
 displayed and printed in math mode.
 
 As an attachment I've included a patch which will stay in text mode
 until the user switches
 back to math mode via M-m m again.

This is very nice but there are few problems with your patch:

1. Special chars like $,%,{,etc. are not quoted when generating the latex
file, causing latex errors.

2. The special chars also cause problem when saving/loading the LyX file:
For example, after saving a file with a % in math text mode, when trying
to load the file LyX hangs.
Also, a file with {,} chars in math text mode will not load correctly.

3. If I go into math text mode, enter some chars, press backspace, and then
press a digit, the digit will not be in math text mode which is not what I
expect. In fact, if I have some text in math text mode, and I move the
cursor to the middle of the text and press a digit, it will not be in math
text mode.

4. Your patch also correct the indentation in several places. It might be
better to break your patch into two (one "real" patch, and an indentation
patch).

Re: bug in lyx1.1.6pre1 - include file..

[Lars Gullik Bjønnes]

Kees van Wijk [EMAIL PROTECTED] writes:

| Yes, manually editing works fine and \include didn't change back into 
| \Include. The other (old) \incude included files were OK from the start 
| anyway. I found the problem by looking directly at the .lyx file with a 
| "normal" editor in the first place. (After lyx gave some errors concerning 
| the \Include when view ps was invoked.)

Ok so I will put this down as "not a bug", but somehow the "Include"
was ouputted earlier and that can have been a bug at that time... I do
not think that bug is present any more.

Lgb

CVS broken?

[R. Lahaye]

Hi,

I've just downloaded CVS (Oct 31st) and the
make ended with:

trans.C: In method `void Trans::AddDeadkey(enum tex_accent, const class string , 
const class string )':
trans.C:175: no matching function for call to 
`basic_stringchar,string_char_traitschar,__default_alloc_templatetrue,0 
::push_back (int)'
trans.C:176: no matching function for call to 
`basic_stringchar,string_char_traitschar,__default_alloc_templatetrue,0 
::push_back (tex_accent )'
make[3]: *** [trans.o] Error 1
make[3]: Leaving directory `/local/software/LyX/lyx-devel/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/local/software/LyX/lyx-devel/src'
make[1]: *** [all-recursive-am] Error 2
make[1]: Leaving directory `/local/software/LyX/lyx-devel/src'
make: *** [all-recursive] Error 1

Regards,
Rob.

Re: CVS broken?

[Lars Gullik Bjønnes]

"R. Lahaye" [EMAIL PROTECTED] writes:

| Hi,
| 
| I've just downloaded CVS (Oct 31st) and the
| make ended with:

Arrghh those stupid compiers that you use...
it should at least manage a implicit cast from int - char or
tex_accent - char. but ok I'll make the casts explicit.

(btw. what compiler do you use?)

Lgb

Re: lyx-1.1.6pre1 is out

[Garst R. Reese]

Juergen Vigna wrote:
 
 On 26-Oct-2000 Garst R. Reese wrote:
 
  I'm beginning to wonder if this is a bug or a feature, but at least it
  is surprising behaviour :)
 
 It was obviously a feature!
 
  I have two tables in a row. When I load the file and page down it gets
  to the tables and then alternates between the two until I use the scroll
  bar to move further down.
 
 But as you don't like it I decided to change it and so you can scroll now
 also down/up with this keys. #:O)
 
 Jürgen
Works, thanks, but did I say I didn't like suprises ?;)
Garst

Re: CVS broken?

[R. Lahaye]

"Lars Gullik Bjnnes" wrote:
 
 "R. Lahaye" [EMAIL PROTECTED] writes:
 
 | Hi,
 |
 | I've just downloaded CVS (Oct 31st) and the
 | make ended with:
 
 Arrghh those stupid compiers that you use...
 it should at least manage a implicit cast from int - char or
 tex_accent - char. but ok I'll make the casts explicit.
 
 (btw. what compiler do you use?)
 
 Lgb

Sorry!
But I can't help (I'm willing to ignore warning
messages, but this one ends with an error!)

My compiler:
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
(default compiler that comes with RedHat Linux 6.2)


Rob.

the .str().c_str() trick

[Lars Gullik Bjønnes]

Is the .str().c_str() trick needed anymore?

It seems that we have just plain .str() several places in the code and
have not got any failure reports about this yet?

Unless I get objections I will change .str().c_str() into just .str()
where approp. (if objections we should change .str() to str.().c_str()
to be safe)

Lgb

Better use of CVS

[Lars Gullik Bjønnes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


We have used CVS for some time now, and I think we can said to be
generally happy about it. However, until now we have only had small
organizational problems due to the small number of developers with
write access to the repository. This is now beginning to change,
currently we have four(three?) developers that sould get write access.

To make the use of CVS easier for everybody we need to use some of
CVS' featues more, in particular _branching_. We should, when creating
a new feature or makeing extensive modifications to the currect ones,
always do this in a branch. Current projects that could be done in a
branch: new importer, the pointer - reference switch, NEW_INSETS etc.

What we now need is a document describing how to do this, we also need
to lay down the guidelies for when and how to do this.

I propose this:
1 - developers can generate branches as they see fit. (after a
small discussion)
2 - merging from HEAD can be done by the developer responsible
for te branch as the need arises (read: whenever)
3 - mergint _to_ HEAD should never be done before it has been
approved by the other developers, (read: peer review) and
deemed acceptable.


In more detail:

1. When a developer has some significant changes¹ that needs to be
   done, just want to make some experimental changes, he should create
   a new branch² to do this in. By doing this he declares himself
   "branch maintainer"³. One thing to be very clear about is that
   branches should never be long lived.

¹ a sinificant change is a completely new feature, extensive changes
to core structures, or just large changes to existing features/code.

² There will be more on the scheme to name branches later in the
document.

³ We will have a web/txt page describing all branches and their curent
status.

2. When working on a branch the development on HEAD does not stop, so
   from time to time the branch maintainer will have to merge the
   changes on HEAD into the branch. The branch maintainer does this
   whenever deemed needed. The exact procedure for this is described
   in detail later in this document.

3. When a branch has fullfilled its task, or has come to a stable
   point, we need to merge the branch into HEAD. We should be very
   careful about this, because:
- the branch code might have serious impact/interactions on
   other code.
- the branch has most likely only been reviewed/tested by a
   few.
- the code/implementation in the branch might be non-optimal
   and changes might be needed (and those changes are best made in the
   branch) 

   So before the merge a diff to the HEAD should be created so that
   the others can have a look at what has been done and comment on it.
   Think of this as a Peer Review. Only when the other developers are
   satisfied about the code should the merge be done.


[Much of what follows is more or less directly form an article in
Dr.Dobbs Journal #317 octover 2000 p. 108: CVS version control and
branch management]

Naming of branches.
- ---

Releases will follow the current scheme, with some small changes. 
Branches will have BRANCH_ prepended
Tags will have TAG prepended
Merges will have MERGE in them.

lyx-1_2_0
TAG_CREATE_BRANCH_NEW_INSETS
BRANCH_NEW_INSETS
TAG_HEAD_MERGE_TO_NEW_INSETS
TAG_NEW_INSETS_MERGE_FROM_HEAD
TAG_NEW_INSETS_MERGE_TO_HEAD
TAG_HEAD_MERGE_FROM_NEW_INSETS
lyx-1_3_0

let me try to ascii-draw this example
 TAG_NEW_INSETS_MERGE_FROM_HEAD
|
  --|-
  BRANCH_NEW_INSETS X   X
  |-|-
  |^|
  || TAG_NEW_INSETS_MERGE_TO_HEAD
  |||
   branchmergemerge
  ||| 
lyx-1_2_0 |||
 |||v lyx_1_3_0
- -|||--|
 XX HEAD   X XX
- --||-|-
  || |
  TAG_CREATE_BRANCH_NEW_INSETS | |
   | TAG_HEAD_MERGE_FROM_NEW
TAG_HEAD_MERGE_TO_NEW



This is the algorithm:

1. Create your branch and begin working on it
2. Merge changes in the HEAD the first time
3. Corrent conficts and commit
4. Continue working
5. Merge changes in the HEAD that occurred between
   your last merge and now.
6. Go to Step 4 if more work is to be done.
7. When done with the branch, merge 

Re: bug in lyx1.1.6pre1 - include file..

[Kees van Wijk]

On Monday 30 October 2000 21:02, Lars Gullik Bjønnes wrote:
 Kees van Wijk [EMAIL PROTECTED] writes:
 | When I do a
 |
 | Insert-Include file
 | and insert an other lyx file this information is written like this in the
 | lyx-file format:
 |
 | \layout Standard
 |
 | \begin_inset Include \Include{file.lyx}
 |
 | \end_inset
 |
 | It should be without a capital in the second Include:
 |
 | \begin_inset Include \include{file.lyx}
 |
 |
 | Probably a very easy to fix bug!
 |
 | BTW. Is this a good way to post bugs, or should I send this to an
 | official bug list to have this bug being processed?

 You should at least use [EMAIL PROTECTED]

 Can you try this: manually edit the .lyx file and change \Include to
 \include, load the file into lyx, save the file. Has \include changed
 back to \Include?

 Lgb

Yes, manually editing works fine and \include didn't change back into 
\Include. The other (old) \incude included files were OK from the start 
anyway. I found the problem by looking directly at the .lyx file with a 
"normal" editor in the first place. (After lyx gave some errors concerning 
the \Include when view ps was invoked.)

Re: bug in lyx1.1.6pre1 - include file..

[Lars Gullik Bjønnes]

Kees van Wijk [EMAIL PROTECTED] writes:

| When I do a 
| 
| Insert-Include file
| and insert an other lyx file this information is written like this in the 
| lyx-file format:
| 
| \layout Standard
| 
| \begin_inset Include \Include{file.lyx}
| 
| \end_inset
| 
| It should be without a capital in the second Include:
| 
| \begin_inset Include \include{file.lyx}
| 
| 
| Probably a very easy to fix bug!
| 
| BTW. Is this a good way to post bugs, or should I send this to an official 
| bug list to have this bug being processed?

You should at least use [EMAIL PROTECTED]

Can you try this: manually edit the .lyx file and change \Include to
\include, load the file into lyx, save the file. Has \include changed
back to \Include?

Lgb

Re: Dead keys kill lyx

[Juergen Vigna]

On 28-Oct-2000 Lars Gullik Bjønnes wrote:

>| Is this a known problem with a fix?  Or should I try to do
>| something myself?
>| I don't know how hard it is to fix, but a lyx that don't die
>| from a unexpected key would be nice.  Having the key perform
>| correctly would be even better of course.
> 
> Sure, even if we can't make it work we should absolutely not crash.

IMO I've a partial fix for this and will commit it now, as I've had
a crash at home using an american-2.kmap (reading it on startup) and
I've seen that this is due to changes from char array to string array!

Please have a look at this as I really don't like the fix I made but
it was the fastest way and I'm not that used to this code-part!

  Jürgen


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

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

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

Goodbye, cool world.

Re: language settings vs. spell checker

[Juergen Vigna]

On 29-Oct-2000 Dekel Tsur wrote:
> 
> Why not add new fields to the languages file (ispell name, keymap name) ?
> The only drawback is decreasing the readability of this file.

No we don't want this! It is much easier to just do a symlink from your
dictionary in "native language" to the one in english (and we don't know
how someone calls the dictionary on his filesystem!).

ln -s deutsch german
ln -s italiano italian
ln -s nederland dutch

...

And you'll see you'll find all you want!

 Jürgen

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

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

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

Where am I?  Who am I?  Am I?  I

Re: thesis cont.

[Jean-Marc Lasgouttes]

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:

Lars> Juergen Vigna <[EMAIL PROTECTED]> writes: | Yesterday I thought about
Lars> this (actually because of caption and captions | in longtabulars
Lars> ;) and this will be fairly easy IMO, just create an inset | with
Lars> 2 textinsets one for entering the "short description" one for
Lars> entering | the "long description" that's it. IMO we could also
Lars> make this more general | quite easily.

Lars> Something _very_ like this is the plan... :-)

I am not sure that this is the best way: IMO, a section heading,
theorem or list item (all these will need an extra text inset) are
first of all a normal paragraph. So the 'long description' should not
be put in a special place, but rather be the paragraph content. 

However, all these examples have in common that they need a special
label. Therefore, it seems to me that the extra text inset should be
related to the label of paragraph (the LabelType in layout files). I
believe that it is better than having everything in insets (would you
ever want to insert a section 'inset' in the middle of a sentence??).

JMarc

Re: Problem compiling lyx 1.1.6 on OSF 4 alpha

[Jean-Marc Lasgouttes]

> "Yann" == Yann MORERE <[EMAIL PROTECTED]> writes:

>> This might work: confiugre lyx with --with-inluded-string, that
>> will make the mangled name of a lot of functions be a lot a
>> shorter.


Yann> sorry but it doesn't work, all same errors...

Are you sure?? First remove config.cache, and then reconfigure with
--with-included-string. Then 'make clean' 'make'. This works for me on
my alpha.

JMarc

Re: FormPreferences patch

[Jean-Marc Lasgouttes]

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:

Lars> Imho bindings should go into their own file, why they can very
Lars> well be edited from preferences.

I'll reiterate the opinion that they should go in ui/. THey are just
another (non-graphical) way for the user to access lyxfuncs.

JMarc

Re: docbook support for insettabular.

[Jose Abilio Oliveira Matos]

On Fri, Oct 27, 2000 at 05:49:13PM +0200, Dekel Tsur wrote:
> 
> This happens if your temp. directory is on a different filesystem than the lyx
> file directory (as the converter try to _move_ the file between these
> directories, which fails), or if the converter creates multiple output files 
> (e.g. foo.html, foo_1.html, foo_2.html...).
> I'll fix these problems soon.

  Yes, that is the case. /tmp is in a different fs that /home.
  And yes the converter also creates multiple files in a it's own directory.
  
  Thanks.
-- 
José

Re: language settings vs. spell checker

[Jean-Marc Lasgouttes]

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

Dekel> Why not add new fields to the languages file (ispell name,
Dekel> keymap name) ? The only drawback is decreasing the readability
Dekel> of this file. 

If readability is a problem, it should be turned into

Language "canadien"
  Description "French Canadian"
  RTL false
  Encoding iso8859-1
  Code fr_CA
  BabelName frenchb
  IspellDict french
End

Much more readable, IMO.

JMarc

Re: language settings vs. spell checker

[Jean-Marc Lasgouttes]

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

Juergen> No we don't want this! It is much easier to just do a symlink
Juergen> from your dictionary in "native language" to the one in
Juergen> english (and we don't know how someone calls the dictionary
Juergen> on his filesystem!).

We certainly do not want to force users to do symlinks just for LyX...
We can at least have defaults which are the names of the distributed
ispell dictionaries.

JMarc

Re: Preferences dialog: Save = Close ??

[Angus Leeming]

On Sun, 29 Oct 2000, R. Lahaye wrote:
> Hi,
>
> The  button in the Preferences dialog
> does the save, but also closes the dialog.
>
> Is that appropriate?
>
> I myself do not expect the dialog to close
> automagically after a save.

This is what might be called a bug. I'm not sure.

The idea behind the buttons in the preferences dialog is 
"Close/Cancel": self explanatory?
"Apply":apply these changes for this session only.
"Save": save these changes so that they can be applied next time also.

Would you rather press Save and then Close or have the button called 
Save?

Angus

Re: Reference dialog has two different appearances?

[Angus Leeming]

On Sat, 28 Oct 2000, R. Lahaye wrote:
> Hi,
>
> I discovered that the Reference dialog has two faces:
> (1) When performing a Insert->Cross reference.
> (2) When Left-Mouse-Clicking on an existing reference.
>
> The appearance in (2) looks like a stripped version of (1).
> (the selection field,  and  buttons have
> been removed).
>
> However, I would strongly prefer to have the same (full)
> dialog in both cases (for (2) you may force a highlight
> of the corresponding reference in the selection field).
>
> The stripped dialog does not allow me to change an existing
> reference to another one. Why? To do that now, I have to
> first delete the existing one, then Insert->Reference a new
> one. The full dialog popup with an existing reference,
> would allow me to do the two steps in just one!

Because they are conceptually different things. Changing the reference is 
equivalent to entering a new one. This will not change.

> A bug is in the (two) reference dialogs:
>
> - Do an "Insert->Cross reference".
>   This will popup the full Reference dialog.
>
> - Leave the previous Reference dialog open, but now
>   also Left-Mouse-Click on an existing reference in
>   the text. The already open Reference dialog is resized,
>   but filled with "blank space" (nothing in it).

Thanks, Rob. This is a bug. I'll have a look.
Angus

Re: FormPreferences patch

[Jean-Marc Lasgouttes]

Angus, it would be much better to use a combox for the list of
languages (it is too long here). Moreover, the old way of using the
list of languages for kmaps is plain wrong. You should get (in some
way) the list of available kmap files (either hardcoded or from
a text file).

JMarc

Re: Patch: tiny typo in lyx.man

[Jean-Marc Lasgouttes]

> "R" == R Lahaye <[EMAIL PROTECTED]> writes:

R> This only removes a  and  so that "X (1)", becomes
R> "X(1)" in the man pages.

Applied. Thanks.

JMarc

Re: gnome: cleanup and update() to updateSlot()

[Jean-Marc Lasgouttes]

> "Marko" == Marko Vendelin <[EMAIL PROTECTED]> writes:

Marko> the attached patch replaces NULL with 0 in the gnome frontend
Marko> code and makes the frontend to compile again by
Marko> replacing/adding update() with updateSlot() where appropriate.
Marko> It seems that DialogBase is changing its methods quite often
Marko> which is one more good reason to establish class hierarchy
Marko> among gnome frontend classes.

Hi,

Is there a particular reason why you use:
  if (search_text_ != 0) search_text_->save_history();
instead of
  if (search_text_) search_text_->save_history();

The second form is used commonly in LyX code.

I'll apply the patch.

JMarc

Re: gnome: cleanup and update() to updateSlot()

[Marko Vendelin]

On 30 Oct 2000, Jean-Marc Lasgouttes wrote:

> > "Marko" == Marko Vendelin <[EMAIL PROTECTED]> writes:
> 
> Marko> the attached patch replaces NULL with 0 in the gnome frontend
> Marko> code and makes the frontend to compile again by
> Marko> replacing/adding update() with updateSlot() where appropriate.
> Marko> It seems that DialogBase is changing its methods quite often
> Marko> which is one more good reason to establish class hierarchy
> Marko> among gnome frontend classes.
> 
> Hi,
> 
> Is there a particular reason why you use:
>   if (search_text_ != 0) search_text_->save_history();
> instead of
>   if (search_text_) search_text_->save_history();
> 
> The second form is used commonly in LyX code.

That what hapens if you replace NULL with 0. I'll replace "if
(search_text_ != 0) " with "if (search_text_)" in the code later.

Marko

Re: FormPreferences patch

[Juergen Vigna]

On 30-Oct-2000 Angus Leeming wrote:
>> Angus, it would be much better to use a combox for the list of
>> languages (it is too long here).
> 
> How would using a combox make it shorter? I'm happy to make it a combox, but 
> this just seems to be style rather than substance.
> 

Well have a look at the document->languages combox ;), it doen't make the
list shorter only the combox is scrollable!

  Jürgen

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

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

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

One advantage of talking to yourself is that you know at least somebody's
listening.
-- Franklin P. Jones

Re: FormPreferences patch

[Angus Leeming]

On Mon, 30 Oct 2000, Juergen Vigna wrote:
> On 30-Oct-2000 Angus Leeming wrote:
> >> Angus, it would be much better to use a combox for the list of
> >> languages (it is too long here).
> >
> > How would using a combox make it shorter? I'm happy to make it a combox,
> > but this just seems to be style rather than substance.
>
> Well have a look at the document->languages combox ;), it doen't make the
> list shorter only the combox is scrollable!
>
>   Jürgen

H! But I can not use the key shortcut #L to "launch" the combox (try!) 
and then use the arrow keys to scroll through it. I can do this with the 
current set up. 

This isn't to say that the current set up is better, (clearly it isn't), but 
combox should be extended so that the user can use shortcuts to navigate it. 

Thanks for the info.
Angus

Re: lyx-1.1.6pre1 is out

[Juergen Vigna]

On 26-Oct-2000 Garst R. Reese wrote:

> I'm beginning to wonder if this is a bug or a feature, but at least it
> is surprising behaviour :)

It was obviously a feature!

> I have two tables in a row. When I load the file and page down it gets
> to the tables and then alternates between the two until I use the scroll
> bar to move further down.

But as you don't like it I decided to change it and so you can scroll now
also down/up with this keys. #:O)

Jürgen

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

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

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

I judge a religion as being good or bad based on whether its adherents
become better people as a result of practicing it.
- Joe Mullally, computer salesman

RE: jumping math-cursor in table

[Juergen Vigna]

On 27-Oct-2000 R. Lahaye wrote:
> 
> When I go into math mode in a tabular cell, the
> cursor all of a sudden jumps up a line or two.
> Typed characters still appear in the tabular cell,
> but the blinking cursor is elsewhere!

Fixed!

Thanks,

  Jürgen

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

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

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

Bower's Law:
Talent goes where the action is.

Re: Preferences dialog: Save = Close ??

[Angus Leeming]

On Mon, 30 Oct 2000, R. Lahaye wrote:
> Angus Leeming wrote:
> > The idea behind the buttons in the preferences dialog is
> > "Close/Cancel": self explanatory?
> > "Apply":apply these changes for this session only.
> > "Save": save these changes so that they can be applied
> > next time also.
> > Would you rather press Save and then Close or have the button called
> > Save?
>
> I would then use merely three buttons in this dialog:
> : apply the preferences to the current document(s)
>   (do NOT save them for a next session).
>   Close also the preferences dialog.
>
> : save the the settings to file and *apply* also
> to current document(s); these settings will
> also be used next time LyX is started.
> Do NOT close the dialog.
>
> : close the window without saving or applying anything.

Well now. You are merely introducing a slightly different way of doing 
things. One way is no better than the other IMO. Users will soon learn what 
happens.

> I would strongly recommend to drop the  button.
> What does it restore? The saved settings, or the 'OK'ed
> settings? Or the system-wide settings? Far too un-intuitive!

This is now it works.
You play with the settings, but decide that you don't want to apply them, so 
"Restore" the settings to the current contents of lyxrc (ie, what are 
displayed should you press Cancel and then launch the dialog again).

A

Error in "Sides" with Document Layout dialog?

[R. Lahaye]

Hi,

The "Sides = Two" check box can't be saved.
Whatever I do, it always shows up as "One".

Is this a bug?

Rob.

Re: warning from FormPreferences.C

[Angus Leeming]

On Mon, 30 Oct 2000, R. Lahaye wrote:
> FormPreferences.C: In method `void FormPreferences::applyScreenFonts()':
> FormPreferences.C:1141: warning: initialization to `int' from `double'
>
> int ivalue = fl_get_counter_value(screen_fonts_->counter_zoom);
>
> Rob.

Thanks. Fixed.
A.

Re: lyx-1.1.5fix2 on irix 6.5

[Jean-Marc Lasgouttes]

> "Eli" == Eli Tziperman <[EMAIL PROTECTED]> writes:

Eli> Hello Lyx experts, Like in 1.1.5fix1, version 1.1.5fix2 still has
Eli> problems compiling on irix 6.5. Actually the linking seems to be
Eli> the problem now. Am I doing something wrong?

It seems that you have to remove the -L/usr/lib from the library list.
The following message gives an alternate solution (but you probably
already know that). There is no generic fix that I know of that we
could apply for irix 6.5...

http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg15131.html

JMarc

Re: FormPreferences patch

[Lars Gullik Bjønnes]

Angus Leeming <[EMAIL PROTECTED]> writes:

| H! But I can not use the key shortcut #L to "launch" the combox (try!) 
| and then use the arrow keys to scroll through it. I can do this with the 
| current set up. 

Probably missing from the combox code... patches will be accepted.

| This isn't to say that the current set up is better, (clearly it isn't), but 
| combox should be extended so that the user can use shortcuts to
| navigate it. 

as said...

Lgb

Re: FormPreferences patch

[Lars Gullik Bjønnes]

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

| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| 
| Lars> Imho bindings should go into their own file, why they can very
| Lars> well be edited from preferences.
| 
| I'll reiterate the opinion that they should go in ui/. THey are just
| another (non-graphical) way for the user to access lyxfuncs.

I can agree on that, but they should _not_ be in defult.ui.

besides I don't think we should put too many levels of directories in
.lyx but rather keep it as flat as possible.

Lgb

Re: FormPreferences patch

[Angus Leeming]

Thanks for the various bits of feedback.

Attached is a patch that adds one or two missing variables to FormPreferences.
It also cleans up the existing code:
* I've moved the various Feedback messages into LyXRC to avoid duplication in 
the other frontends.
* We select the languages using a Combox, rather than a choice.
* feedback is now output via a timer callback loop that is functionally 
identical to that in Toolbar_pimpl. No longer any need to change an entry to 
get feedback. The only items not providing feedback are the new Comboxes!

All changes follow suggestions by JMarc!
Angus


Below is an updated list of what needs doing in FormPreferences.

Main Dialog->Look>Colours
Ability to set colours of background, text, notes etc.
\set_color

Main Dialog->I/O  // New Tab, because converters cover Input AND Output.
\converter
\Format

Main Dialog->Outputs->Fax
string fax_command; * Are these still needed?
string phone_book;
string fax_program;

Main Dialog->Outputs->Viewers
\viewer

In addition, we need to add the ability to edit individual \bind entries. (Or 
at least input the file containing the users choices.)

Multiple \converter, \viewer (and \bind) commands will be input using 
tabs of the format suggested by Dekel:

+--+++
|dvi   | format |dvi |
|ps|++
|  |++
|  | viewer |xdvi|

+--+++
+---+--+---+
|Add|Delete|Replace|

+---+--+---+



 patch_preferences.bz2

Re: language settings vs. spell checker

[Lars Gullik Bjønnes]

Dekel Tsur <[EMAIL PROTECTED]> writes:

| On Sun, Oct 29, 2000 at 08:28:22AM +0100, Lars Gullik Bjønnes wrote:
| > 
| > | 2) Another solution for 1) could be changing the
| > |language file, that comes with LyX. The first
| > |and second column in this file are ALWAYS the
| > |same. Why is that? We could use the second column
| > |for an equivalent language name, for example:
| > 
| > Did you check the meanings of the fields?
| 
| The second field is the babel name of the language, and it is not always
| equal to the first field (the LyX name).
| 
| > I'd rather remove one of the fields instead of adding more.
| > (but then we would need a "babel" module.
| 
| Why not add new fields to the languages file (ispell name, keymap name) ?
| The only drawback is decreasing the readability of this file.

And imposing addtional dependencies... it is ok for the ispell/babel
modules to depend on the language struct in LyX, but not ok for the
language struct to depend upon the ispell/babel module.

Lgb

Re: Dead keys kill lyx

[Lars Gullik Bjønnes]

Juergen Vigna <[EMAIL PROTECTED]> writes:

| IMO I've a partial fix for this and will commit it now, as I've had
| a crash at home using an american-2.kmap (reading it on startup) and
| I've seen that this is due to changes from char array to string array!
| 
| Please have a look at this as I really don't like the fix I made but
| it was the fastest way and I'm not that used to this code-part!

I altered your fix a bit, a bit cleaner but not perfect.

Lgb

Re: thesis cont.

[Lars Gullik Bjønnes]

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

| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| 
| Lars> Juergen Vigna <[EMAIL PROTECTED]> writes: | Yesterday I thought about
| Lars> this (actually because of caption and captions | in longtabulars
| Lars> ;) and this will be fairly easy IMO, just create an inset | with
| Lars> 2 textinsets one for entering the "short description" one for
| Lars> entering | the "long description" that's it. IMO we could also
| Lars> make this more general | quite easily.
| 
| Lars> Something _very_ like this is the plan... :-)
| 
| I am not sure that this is the best way: IMO, a section heading,
| theorem or list item (all these will need an extra text inset) are
| first of all a normal paragraph.

Actually they are normal paragraps only because LyXParagraph contains
special code to deal with them.

We want them moved into insets.

| So the 'long description' should not
| be put in a special place, but rather be the paragraph content. 
| 
| However, all these examples have in common that they need a special
| label. Therefore, it seems to me that the extra text inset should be
| related to the label of paragraph (the LabelType in layout files). I
| believe that it is better than having everything in insets (would you
| ever want to insert a section 'inset' in the middle of a
| sentence??).

Why should a paragraph containa LabelType at all?

and I disagree.

Lgb

Re: Fun with wdiff

[Lars Gullik Bjønnes]

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

| I have been playing a bit with wdiff 
|   http://www.iro.umontreal.ca/~pinard/wdiff/HTML/
| to see whether we can compare two versions of the same file. It turns
| out that this is possible, although a lot of work still has to be
| done.
| 
| I took revision 1.23 of BUGS.lyx from cvs, along with latest version.
| I edited the language of the former because preambles were different.
| Then running
| 
| wdiff -w'\color red ' -x'\color default ' -y'\color green ' -z'\color default ' 
|BUGS-1.23.lyx BUGS.lyx >BUGS-diff.lyx
| 
| I get the following file:
|   http://www-rocq.inria.fr/~lasgoutt/lyx/BUGS-diff.lyx
| 
| Of course, this is not usable for real work now:
| 
| - we should have real markers for deleted/added entries, not color
|   change as we have now. And then support for accepting/rejecting
|   modifcations, like in word.

We need insets for that.

| - currently, if there is a change in a math formula, for example, ugly
|   things will happen. We should have a (perl?) postprocessor to fix
|   those marks.
| 
| However, I find the result to be rather interesting.

Yes, I have been thinking about this also, but have put of any work
until we get the core of lyx cleaned up a bit.

Lgb

Re: FormPreferences patch

[Lars Gullik Bjønnes]

Angus Leeming <[EMAIL PROTECTED]> writes:

| Thanks for the various bits of feedback.
| 
| Attached is a patch that adds one or two missing variables to
| FormPreferences. 
| It also cleans up the existing code:
| * I've moved the various Feedback messages into LyXRC to avoid
| duplication in 

I think you used the wrong name for getFeedback, imho it should have
been getDescription.


| * We select the languages using a Combox, rather than a choice.

good.

| * feedback is now output via a timer callback loop that is functionally 
| identical to that in Toolbar_pimpl. No longer any need to change an entry to 
| get feedback. The only items not providing feedback are the new
| Comboxes!

I never liked the hidden timers.

| Main Dialog->Outputs->Fax
|   string fax_command; * Are these still needed?
|   string phone_book;
|   string fax_program;

No, we want to set this code inactive. I'll do that.
We will only enable it if a lot of users complain.

| 
| Main Dialog->Outputs->Viewers
|   \viewer
| 
| In addition, we need to add the ability to edit individual \bind
| entries. (Or| at least input the file containing the users choices.)

Yes, we don't need the full fledged online bind editing now.
Actually we have all we need already since you can name your own bind
file in the bind input and from that file inlucde the bind file that
you base it on.

Lgb

Re: Math editor patches

[Dekel Tsur]

On Tue, Oct 24, 2000 at 08:44:14PM +0200, Stephen Reindl wrote:

> If I switch to math-text mode (via M-m m) I cannot enter digits and
> special characters in
> text mode. Everytime I enter a Digit or a closing paren (e.g. "2.2.3)")
> these digits are
> displayed and printed in math mode.
> 
> As an attachment I've included a patch which will stay in text mode
> until the user switches
> back to math mode via M-m m again.

This is very nice but there are few problems with your patch:

1. Special chars like $,%,{,etc. are not quoted when generating the latex
file, causing latex errors.

2. The special chars also cause problem when saving/loading the LyX file:
For example, after saving a file with a % in math text mode, when trying
to load the file LyX hangs.
Also, a file with {,} chars in math text mode will not load correctly.

3. If I go into math text mode, enter some chars, press backspace, and then
press a digit, the digit will not be in math text mode which is not what I
expect. In fact, if I have some text in math text mode, and I move the
cursor to the middle of the text and press a digit, it will not be in math
text mode.

4. Your patch also correct the indentation in several places. It might be
better to break your patch into two (one "real" patch, and an indentation
patch).

Re: bug in lyx1.1.6pre1 -> include file..

[Lars Gullik Bjønnes]

Kees van Wijk <[EMAIL PROTECTED]> writes:

| Yes, manually editing works fine and \include didn't change back into 
| \Include. The other (old) \incude included files were OK from the start 
| anyway. I found the problem by looking directly at the .lyx file with a 
| "normal" editor in the first place. (After lyx gave some errors concerning 
| the \Include when view ps was invoked.)

Ok so I will put this down as "not a bug", but somehow the "Include"
was ouputted earlier and that can have been a bug at that time... I do
not think that bug is present any more.

Lgb

CVS broken?

[R. Lahaye]

Hi,

I've just downloaded CVS (Oct 31st) and the
make ended with:

trans.C: In method `void Trans::AddDeadkey(enum tex_accent, const class string &, 
const class string &)':
trans.C:175: no matching function for call to 
`basic_string 
>::push_back (int)'
trans.C:176: no matching function for call to 
`basic_string 
>::push_back (tex_accent &)'
make[3]: *** [trans.o] Error 1
make[3]: Leaving directory `/local/software/LyX/lyx-devel/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/local/software/LyX/lyx-devel/src'
make[1]: *** [all-recursive-am] Error 2
make[1]: Leaving directory `/local/software/LyX/lyx-devel/src'
make: *** [all-recursive] Error 1

Regards,
Rob.

Re: CVS broken?

[Lars Gullik Bjønnes]

"R. Lahaye" <[EMAIL PROTECTED]> writes:

| Hi,
| 
| I've just downloaded CVS (Oct 31st) and the
| make ended with:

Arrghh those stupid compiers that you use...
it should at least manage a implicit cast from int -> char or
tex_accent -> char. but ok I'll make the casts explicit.

(btw. what compiler do you use?)

Lgb

Re: lyx-1.1.6pre1 is out

[Garst R. Reese]

Juergen Vigna wrote:
> 
> On 26-Oct-2000 Garst R. Reese wrote:
> 
> > I'm beginning to wonder if this is a bug or a feature, but at least it
> > is surprising behaviour :)
> 
> It was obviously a feature!
> 
> > I have two tables in a row. When I load the file and page down it gets
> > to the tables and then alternates between the two until I use the scroll
> > bar to move further down.
> 
> But as you don't like it I decided to change it and so you can scroll now
> also down/up with this keys. #:O)
> 
> Jürgen
Works, thanks, but did I say I didn't like suprises ?;)
Garst

Re: CVS broken?

[R. Lahaye]

"Lars Gullik Bjnnes" wrote:
> 
> "R. Lahaye" <[EMAIL PROTECTED]> writes:
> 
> | Hi,
> |
> | I've just downloaded CVS (Oct 31st) and the
> | make ended with:
> 
> Arrghh those stupid compiers that you use...
> it should at least manage a implicit cast from int -> char or
> tex_accent -> char. but ok I'll make the casts explicit.
> 
> (btw. what compiler do you use?)
> 
> Lgb

Sorry!
But I can't help (I'm willing to ignore warning
messages, but this one ends with an error!)

My compiler:
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
(default compiler that comes with RedHat Linux 6.2)


Rob.

the .str().c_str() trick

[Lars Gullik Bjønnes]

Is the .str().c_str() trick needed anymore?

It seems that we have just plain .str() several places in the code and
have not got any failure reports about this yet?

Unless I get objections I will change .str().c_str() into just .str()
where approp. (if objections we should change .str() to str.().c_str()
to be safe)

Lgb

Better use of CVS

[Lars Gullik Bjønnes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


We have used CVS for some time now, and I think we can said to be
generally happy about it. However, until now we have only had small
organizational problems due to the small number of developers with
write access to the repository. This is now beginning to change,
currently we have four(three?) developers that sould get write access.

To make the use of CVS easier for everybody we need to use some of
CVS' featues more, in particular _branching_. We should, when creating
a new feature or makeing extensive modifications to the currect ones,
always do this in a branch. Current projects that could be done in a
branch: new importer, the pointer -> reference switch, NEW_INSETS etc.

What we now need is a document describing how to do this, we also need
to lay down the guidelies for when and how to do this.

I propose this:
1 - developers can generate branches as they see fit. (after a
small discussion)
2 - merging from HEAD can be done by the developer responsible
for te branch as the need arises (read: whenever)
3 - mergint _to_ HEAD should never be done before it has been
approved by the other developers, (read: peer review) and
deemed acceptable.


In more detail:

1. When a developer has some significant changes¹ that needs to be
   done, just want to make some experimental changes, he should create
   a new branch² to do this in. By doing this he declares himself
   "branch maintainer"³. One thing to be very clear about is that
   branches should never be long lived.

¹ a sinificant change is a completely new feature, extensive changes
to core structures, or just large changes to existing features/code.

² There will be more on the scheme to name branches later in the
document.

³ We will have a web/txt page describing all branches and their curent
status.

2. When working on a branch the development on HEAD does not stop, so
   from time to time the branch maintainer will have to merge the
   changes on HEAD into the branch. The branch maintainer does this
   whenever deemed needed. The exact procedure for this is described
   in detail later in this document.

3. When a branch has fullfilled its task, or has come to a stable
   point, we need to merge the branch into HEAD. We should be very
   careful about this, because:
- the branch code might have serious impact/interactions on
   other code.
- the branch has most likely only been reviewed/tested by a
   few.
- the code/implementation in the branch might be non-optimal
   and changes might be needed (and those changes are best made in the
   branch) 

   So before the merge a diff to the HEAD should be created so that
   the others can have a look at what has been done and comment on it.
   Think of this as a Peer Review. Only when the other developers are
   satisfied about the code should the merge be done.


[Much of what follows is more or less directly form an article in
Dr.Dobbs Journal #317 octover 2000 p. 108: CVS version control and
branch management]

Naming of branches.
- ---

Releases will follow the current scheme, with some small changes. 
Branches will have BRANCH_ prepended
Tags will have TAG prepended
Merges will have MERGE in them.

lyx-1_2_0
TAG_CREATE_BRANCH_NEW_INSETS
BRANCH_NEW_INSETS
TAG_HEAD_MERGE_TO_NEW_INSETS
TAG_NEW_INSETS_MERGE_FROM_HEAD
TAG_NEW_INSETS_MERGE_TO_HEAD
TAG_HEAD_MERGE_FROM_NEW_INSETS
lyx-1_3_0

let me try to ascii-draw this example
 TAG_NEW_INSETS_MERGE_FROM_HEAD
|
  --|-
  BRANCH_NEW_INSETS X   X
  |-|-
  |^|
  || TAG_NEW_INSETS_MERGE_TO_HEAD
  |||
   branchmergemerge
  ||| 
lyx-1_2_0 |||
 |||v lyx_1_3_0
- -|||--|
 XX HEAD   X XX
- --||-|-
  || |
  TAG_CREATE_BRANCH_NEW_INSETS | |
   | TAG_HEAD_MERGE_FROM_NEW
TAG_HEAD_MERGE_TO_NEW



This is the algorithm:

1. Create your branch and begin working on it
2. Merge changes in the HEAD the first time
3. Corrent conficts and commit
4. Continue working
5. Merge changes in the HEAD that occurred between
   your last merge and now.
6. Go to Step 4 if more work is to be done.
7. When done with the branch, merge 

Re: bug in lyx1.1.6pre1 -> include file..

[Kees van Wijk]

On Monday 30 October 2000 21:02, Lars Gullik Bjønnes wrote:
> Kees van Wijk <[EMAIL PROTECTED]> writes:
> | When I do a
> |
> | Insert->Include file
> | and insert an other lyx file this information is written like this in the
> | lyx-file format:
> |
> | \layout Standard
> |
> | \begin_inset Include \Include{file.lyx}
> |
> | \end_inset
> |
> | It should be without a capital in the second Include:
> |
> | \begin_inset Include \include{file.lyx}
> |
> |
> | Probably a very easy to fix bug!
> |
> | BTW. Is this a good way to post bugs, or should I send this to an
> | official bug list to have this bug being processed?
>
> You should at least use [EMAIL PROTECTED]
>
> Can you try this: manually edit the .lyx file and change \Include to
> \include, load the file into lyx, save the file. Has \include changed
> back to \Include?
>
> Lgb

Yes, manually editing works fine and \include didn't change back into 
\Include. The other (old) \incude included files were OK from the start 
anyway. I found the problem by looking directly at the .lyx file with a 
"normal" editor in the first place. (After lyx gave some errors concerning 
the \Include when view ps was invoked.)

Re: bug in lyx1.1.6pre1 -> include file..

[Lars Gullik Bjønnes]

Kees van Wijk <[EMAIL PROTECTED]> writes:

| When I do a 
| 
| Insert->Include file
| and insert an other lyx file this information is written like this in the 
| lyx-file format:
| 
| \layout Standard
| 
| \begin_inset Include \Include{file.lyx}
| 
| \end_inset
| 
| It should be without a capital in the second Include:
| 
| \begin_inset Include \include{file.lyx}
| 
| 
| Probably a very easy to fix bug!
| 
| BTW. Is this a good way to post bugs, or should I send this to an official 
| bug list to have this bug being processed?

You should at least use [EMAIL PROTECTED]

Can you try this: manually edit the .lyx file and change \Include to
\include, load the file into lyx, save the file. Has \include changed
back to \Include?

Lgb