Re: new FormPreferences crash

[Garst R. Reese]

Allan Rae wrote:
 
 I'll remove that check in my tree although it may not be committed for a
 day or so since I'm partway through expanding Preferences.
 
 Allan. (ARRae)
Thanks, no rush.
Garst

Re: new FormPreferences crash

[Allan Rae]

On Wed, 11 Oct 2000, Garst R. Reese wrote:

 Allan Rae wrote:
  
  I'll remove that check in my tree although it may not be committed for a
  day or so since I'm partway through expanding Preferences.
  
  Allan. (ARRae)
 Thanks, no rush.

Well I've just committed it ;-)

The Preferences dialog now has space for messages under the OK,Apply,
Cancel buttons but I haven't got any messages yet.  I'd like to put
warnings and context-sensitive help messages there (or have tooltip help)
but I'll have to make the dialog wider and shorter to get it workable in a
640x480 screen.

Allan. (ARRae)

Small error in encoding file (probably)

[Juergen Vigna]

I get this message when fireing up todays cvs:

LyX: Encodings::read: Unknown tag: `' [around line 214 of file
/nfs/sinco/source/lyx/lyx-devel/lib/encodings]

I think I'm save to blame Dekel about this #: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

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

Every time I look at you I am more convinced of Darwin's theory.

gnome: FormRef and FormError

[Marko Vendelin]

Hi!

this patch adds FormRef and FormError to fine family of the dialogs ported
to Gnome frontend. These dialogs are implemented using an "action" area
to make the work with references as fast and convenient as possible and
scanning error messages less disturbing.

Marko 

 formcitation.gnome.patch.gz
 formref.gnome.newfiles.tar.gz

C-home etc not working 1.1.6cvs

[Garst R. Reese]

None of Control functions seem to be working.
The Ctrl key does function
Workarea event: KEYBOARD
WorkArea: Key is `Home' [65360]
WorkArea: Keysym is `Home' [65360]
Workarea Diff: 4301
KeySym is Home[65360]
Key [-1][C-Home]
Empty argument!
Running QuitLyX.

Garst

Re: gnome: FormRef and FormError

[Jean-Marc Lasgouttes]

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

Marko this patch adds FormRef and FormError to fine family of the
Marko dialogs ported to Gnome frontend. These dialogs are implemented
Marko using an "action" area to make the work with references as fast
Marko and convenient as possible and scanning error messages less
Marko disturbing.

Marko,

are you sure you posted the right patches? You sent
formcitation.gnome.patch.gz, which is an old already applied patch,
and formref.gnome.newfiles.tar.gz. 

JMarc

Re: gnome: FormRef and FormError

[Marko Vendelin]

On 11 Oct 2000, Jean-Marc Lasgouttes wrote:

  "Marko" == Marko Vendelin [EMAIL PROTECTED] writes:
 
 Marko this patch adds FormRef and FormError to fine family of the
 Marko dialogs ported to Gnome frontend. These dialogs are implemented
 Marko using an "action" area to make the work with references as fast
 Marko and convenient as possible and scanning error messages less
 Marko disturbing.
 
 Marko,
 
 are you sure you posted the right patches? You sent
 formcitation.gnome.patch.gz, which is an old already applied patch,
 and formref.gnome.newfiles.tar.gz. 

Sorry! I hope this time I am sending the right one.

Marko

 formref.gnome.newfiles.tar.gz
 formref.gnome.patch.gz

Re: C-home etc not working 1.1.6cvs

[Garst R. Reese]

"Garst R. Reese" wrote:
 
 None of Control functions seem to be working.
 The Ctrl key does function
 Workarea event: KEYBOARD
 WorkArea: Key is `Home' [65360]
 WorkArea: Keysym is `Home' [65360]
 Workarea Diff: 4301
 KeySym is Home[65360]
 Key [-1][C-Home]
 Empty argument!
 Running QuitLyX.
 
 Garst
Answering my own mail, but only after talking to myself.
The above problem only happens if I save a preferences file.
Garst

Re: gnome: FormRef and FormError

[John Levon]

On Wed, 11 Oct 2000, Marko Vendelin wrote:

 
 
 On 11 Oct 2000, Jean-Marc Lasgouttes wrote:
 
   "Marko" == Marko Vendelin [EMAIL PROTECTED] writes:
  
  Marko this patch adds FormRef and FormError to fine family of the
  Marko dialogs ported to Gnome frontend. These dialogs are implemented
  Marko using an "action" area to make the work with references as fast
  Marko and convenient as possible and scanning error messages less
  Marko disturbing.
  
  Marko,
  
  are you sure you posted the right patches? You sent
  formcitation.gnome.patch.gz, which is an old already applied patch,
  and formref.gnome.newfiles.tar.gz. 
 
 Sorry! I hope this time I am sending the right one.
 
 Marko
 

Any chance you can update the guii matrix as well ? There's not much point
having it if it's not going to be used :)

thanks
john

-- 
"Do you mean to tell me that "The Prince" is not the set textbook for
CS1072 Professional Issues ? What on earth do you learn in that course ?"
- David Lester

Re: gnome: FormRef and FormError

[Jean-Marc Lasgouttes]

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

Marko Sorry! I hope this time I am sending the right one.

This looks better indeed :)

JMarc

Re: gnome: FormRef and FormError

[Jean-Marc Lasgouttes]

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

Marko On Wed, 11 Oct 2000, John Levon wrote:
 Any chance you can update the guii matrix as well ? There's not
 much point having it if it's not going to be used :)

Marko John, how should I do it? Where can I find file "guii.php3"?
Marko 'locate guii.php3' gives nothing...

Get www-devel from the cvs server. This is the developpers web site
(and www-user is www.lyx.org).

JMarc

Re: C-home etc not working 1.1.6cvs

[Allan Rae]

On Wed, 11 Oct 2000, Garst R. Reese wrote:

 "Garst R. Reese" wrote:
  
  None of Control functions seem to be working.
  The Ctrl key does function
  Workarea event: KEYBOARD
  WorkArea: Key is `Home' [65360]
  WorkArea: Keysym is `Home' [65360]
  Workarea Diff: 4301
  KeySym is Home[65360]
  Key [-1][C-Home]
  Empty argument!
  Running QuitLyX.
  
  Garst
 Answering my own mail, but only after talking to myself.
 The above problem only happens if I save a preferences file.

Oh come on! No fair blaming me when I can't repeat problem.
What's in your preferences file that is saved?

Does it occur straight away after you restart lyx when you a preferences
file?  Or only in a given session after saving preferences?

Allan. (ARRae)

Re: gnome: FormRef and FormError

[Marko Vendelin]

On 11 Oct 2000, Jean-Marc Lasgouttes wrote:

 Get www-devel from the cvs server. This is the developpers web site
 (and www-user is www.lyx.org).

Here is the update of guii.php3. 

Marko

 www.gnome.patch.gz

Re: C-home etc not working 1.1.6cvs

[Garst R. Reese]

Allan Rae wrote:
 
 On Wed, 11 Oct 2000, Garst R. Reese wrote:
 
  "Garst R. Reese" wrote:
  
   None of Control functions seem to be working.
   The Ctrl key does function
   Workarea event: KEYBOARD
   WorkArea: Key is `Home' [65360]
   WorkArea: Keysym is `Home' [65360]
   Workarea Diff: 4301
   KeySym is Home[65360]
   Key [-1][C-Home]
   Empty argument!
   Running QuitLyX.
  
   Garst
  Answering my own mail, but only after talking to myself.
  The above problem only happens if I save a preferences file.
 
 Oh come on! No fair blaming me when I can't repeat problem.

I didn't blame you :) 

 What's in your preferences file that is saved?

Attached

 Does it occur straight away after you restart lyx when you a preferences
 file?  Or only in a given session after saving preferences?
 
 Allan. (ARRae)
It happens after I save preferences, quit LyX, restart LyX -- no Ctrl.
Garst

### This file is part of
### 
###  LyX, The Document Processor
###
###  Copyright 1995 Matthias Ettrich
###  Copyright 1995-2000 The LyX Team.
###
### 

# This file is written by LyX, if you want to make your own
# modifications you should do them from inside LyX and save

\bind_file menus.bind

#
# MISC SECTION ##
#


#
# SCREEN  FONTS SECTION 
#

\screen_font_roman "-*-utopia"

#
# PRINTER SECTION ###
#


#
# EXPORT SECTION 
#


#
# TEX SECTION ###
#


#
# LINUXDOC SECTION ##
#


#
# FILE SECTION ##
#

\document_path "/home/garst/lyxdocs/"
\num_lastfiles 9
\template_path "/home/garst/.lyx/templates/"

#
# FAX SECTION ###
#


#
# ASCII EXPORT SECTION ##
#


#
# SPELLCHECKER SECTION ##
#

\spell_command "aspell"

#
# LANGUAGE SUPPORT SECTION ##
#


#
# 2nd MISC SUPPORT SECTION ##
#

\screen_font_encoding_menu "iso8859-1"

Re: You only fix twice (status update #2)

[Baruch Even]

On 10 Oct 2000, Jean-Marc Lasgouttes wrote:

 - mangled minibuffer after resizing the main window. I can't find a
   reference, but the effect is obvious (and recent). Could it be a
   consequence of Lars' recent changes to scrollbars? Or simply a flaw
   of the WorkArea? More generally, the minibuffer is strange since
   when you click in it, the text does not disappear.

Attached is the patch to make the minibuffer clear when clicked on. I
could not get a situation where it gets mangled, if you have a sequence
that causes it it would help.

--
  Baruch Even

http://techst02.technion.ac.il/~sbaruch/   (My Site)
http://www.redrival.com/jindor/(My brothers ADD site)

" Learn to laugh ... it's the path to true love! " 
   - The Angel in the movie Michael



 patch.diff.gz

Re: gnome: FormRef and FormError

[Jean-Marc Lasgouttes]

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

Marko Content-Type: TEXT/PLAIN; charset=US-ASCII On 11 Oct 2000,
Marko Jean-Marc Lasgouttes wrote:

 Get www-devel from the cvs server. This is the developpers web site
 (and www-user is www.lyx.org).

Marko Here is the update of guii.php3.

Thanks, it is in now.

JMarc

Making LyX work on different screens.

[Jean-Marc Lasgouttes]

I think we should probably cleanup the use of screens (in the X sense)
by LyX. We've had reports that LyX crashes when used on a different
screen of a given display (meaning somebody have two graphic cards on
one system). I took a quick look at the source, and it seems to me
that we are using indifferently
  DefaultScreenOfDisplay(fl_get_display())
and 
  DefaultScreen(fl_get_display())
which are different things, if I read correctly the relevant man
pages. BTW, we also use indifferently fl_display and fl_get_display(),
which are the same thing indeed. It would be better to settle on one.

It seems to me that the right one to use is
DefaultScreen(fl_get_display()), which is in fact defined in forms.h
as fl_screen. So we might also want to use fl_screen. 

I'll let those who care for correct GUI-I stuff decide how we should
get hold of the screen and display we are using (maybe members of
LyXGUI). Anyway, if nobody does anything, I plan at least to change
each occurence of DefaultScreenOfDisplay to DefaultScreen.

JMarc

Re: You only fix twice (status update #2)

[Baruch Even]

On 10 Oct 2000, Jean-Marc Lasgouttes wrote:

 Remaining problems
 ==

 - we should check when writing to a stream failed due to not enough
   disk space (how?)
   http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg13483.html
   http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg12733.html
 
 - mangled minibuffer after resizing the main window. I can't find a
   reference, but the effect is obvious (and recent). Could it be a
   consequence of Lars' recent changes to scrollbars? Or simply a flaw
   of the WorkArea? More generally, the minibuffer is strange since
   when you click in it, the text does not disappear.

This now includes patches for this both problems. The patches are done
against 1.1.6cvs but I have no reason to believe it won't apply to
1.1.5fix1, anyway I dont want to believe otherwise :-)

The patch to the file system full gives detection but it creates another
bug which is that the file is created with size 0 and is not deleted. This
was noticed when using the SaveAs function. I'm not well versed in the
chain of work in the core so I'm sending the patch as it is and will try
hunting the new bug, but no promises implied.

-- 
  Baruch Even

http://techst02.technion.ac.il/~sbaruch/   (My Site)
http://www.redrival.com/jindor/(My brothers ADD site)

" Learn to laugh ... it's the path to true love! " 
   - The Angel in the movie Michael



 patch.diff.gz

Re: Compiling LyX using AthlonGCC

[Lars Gullik Bjønnes]

Juergen Vigna [EMAIL PROTECTED] writes:

| On 10-Oct-2000 Baruch Even wrote:
|  
|  OK, I'll try that later.
|  In the InsetGraphics patch I also put the de-inline of these functions it
|  might be desirable to remove them from the patch.
|  
|  Jurgen: Let me know if you'll do it or if I need to provide a new patch.
|  
| 
| I guess we can let them de-inlined!

As a guideline we should inline as _few_ functions/methods as
possible. _Unless_ we can show by profiling that it will have a large
effect and that the current code is too slow because of out-of-line
code.

If I do not already mention this in developmetn/Code_rules/Rules, I
will add it there. Also if it is a long time since you read this file
last, please read it again now. I have added quite a lot lately.

Lgb

Re: Compiling LyX using AthlonGCC

[Lars Gullik Bjønnes]

Juergen Vigna [EMAIL PROTECTED] writes:

| On 09-Oct-2000 Lars Gullik Bjønnes wrote:
|  
|  You are allowed to post some compiler messages...
|  
|  Seems to me to be a compiler bug.
|  And we don't want ANY defined like that...
| 
| I get NO compiler errors and get this on linking:
| 
| debug.o: In function `Debug::showLevel(ostream , Debug::type)':
| /usr/include/g++-3/stl_relops.h:37: undefined reference to `Debug::ANY'
| collect2: ld returned 1 exit status 
Ok, your fix is just very wrong. I have put in what I belive to be the
correct fix instead.

Lgb

Re: Compiling LyX using AthlonGCC

[Jean-Marc Lasgouttes]

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

Lars As a guideline we should inline as _few_ functions/methods as
Lars possible. _Unless_ we can show by profiling that it will have a
Lars large effect and that the current code is too slow because of
Lars out-of-line code.

BTW, Lars, could we remove -Winline from the default CXXFLAGS at least
for gcc 2.95.2? It generates a bunch of warnings always in the same
place in map (a bug in the library, it seems), and makes compilation
a bit painful...

Also, did you see the pointer in lyx-users to the bug report for
redhat 7.0 explaining that our flags for 2.96 are a bit overdone? It
like to fix that in 1.1.5fix2, so that it compiles cleanly on redhat
7.0.

JMarc

Re: You only fix twice (status update #2)

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

| Hello,
| 
| I finally (think we have) fixed the locale problem which has been
| plaguing german users. Therefore, I think it will be nice to release
| 1.1.5fix2 as soon as possible. 

Also note that this code might play tricks wit oter float values that
we ouput. In particular in figinset, for the control file to gs.
(I am not sure if this is a problem in 1.1.5, but it certainly is in
1.1.6cvs)

Lgb

Re: Vfill not working 1.1.6cvs

[Lars Gullik Bjønnes]

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

| Layout Paragraph Above/Below Vfill does nothing.

Have you checked the LaTeX output too? vfill is not mentioned at all?
Or is it just a display problem?

Lgb

Re: C-home etc not working 1.1.6cvs

[Lars Gullik Bjønnes]

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


| It happens after I save preferences, quit LyX, restart LyX -- no Ctrl.
| Garst### This file is part of
| ### 
| ###  LyX, The Document Processor
| ###
| ###  Copyright 1995 Matthias Ettrich
| ###  Copyright 1995-2000 The LyX Team.
| ###
| ### 
| 
| # This file is written by LyX, if you want to make your own
| # modifications you should do them from inside LyX and save
| 
| \bind_file menus.bind

Why do you use this bind file?
Use emacs.bind or cua.bind instead.

We need a way to edit bindings from inside LyX...

Lgb

Re: You only fix twice (status update #2)

[Jean-Marc Lasgouttes]

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

Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: |
Lars Hello, | | I finally (think we have) fixed the locale problem
Lars which has been | plaguing german users. Therefore, I think it
Lars will be nice to release | 1.1.5fix2 as soon as possible.

Lars Also note that this code might play tricks wit oter float values
Lars that we ouput. In particular in figinset, for the control file
Lars to gs. (I am not sure if this is a problem in 1.1.5, but it
Lars certainly is in 1.1.6cvs)

I have added in 1.1.5 a
  setlocale(LC_NUMERIC, "C");
in main(). This probably not the right place, but isn't it the
simplest solution?

JMarc

Re: Message translation related bug.

[Dekel Tsur]

On Tue, Oct 10, 2000 at 07:00:16PM +0200, Dekel Tsur wrote:
 I think that the attached patch will fix the problem (this fix is already
 present in 1.1.6).

 diff -u -p -r1.37.2.1 lyx_gui.C
 --- src/lyx_gui.C   2000/07/10 14:14:18 1.37.2.1
 +++ src/lyx_gui.C   2000/10/10 16:57:09
 @@ -404,7 +404,7 @@ void LyXGUI::create_forms()
 combo_language-addto((*cit).second.lang.c_str());
 combo_language2-addto((*cit).second.lang.c_str());
 }
 -   combo_language2-select_text("No change");
 +   combo_language2-select_text(_("No change"));
 

Perhaps it is better to use combo_language2-select(1) instead of
combo_language2-select_text(..), 
or use the addline method instead of the addto method
(the addline method selects automatically the first added line).

--- src/lyx_gui.C   2000/07/10 14:14:18 1.37.2.1
+++ src/lyx_gui.C   2000/10/10 16:57:09
@@ -396,15 +396,14 @@ void LyXGUI::create_forms()
fl_end_form();
 
// "default" is not part of the languages array any more.
-   combo_language-addto("default");
-   combo_language2-addto(_("No change"));
-   combo_language2-addto(_("Reset"));
+   combo_language-addline("default");
+   combo_language2-addline(_("No change"));
+   combo_language2-addline(_("Reset"));
for(Languages::const_iterator cit = languages.begin();
cit != languages.end(); ++cit) {
combo_language-addto((*cit).second.lang.c_str());
combo_language2-addto((*cit).second.lang.c_str());
}
-   combo_language2-select_text("No change");
 
// not really necessary, but we can do it anyway.

Re: Making LyX work on different screens.

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

| I think we should probably cleanup the use of screens (in the X sense)
| by LyX. We've had reports that LyX crashes when used on a different
| screen of a given display (meaning somebody have two graphic cards on
| one system). I took a quick look at the source, and it seems to me
| that we are using indifferently
|   DefaultScreenOfDisplay(fl_get_display())
| and 
|   DefaultScreen(fl_get_display())
| which are different things, if I read correctly the relevant man
| pages. BTW, we also use indifferently fl_display and fl_get_display(),
| which are the same thing indeed. It would be better to settle on one.

Let's settle for fl_get_display()
I changed this.

| It seems to me that the right one to use is
| DefaultScreen(fl_get_display()), which is in fact defined in forms.h
| as fl_screen. So we might also want to use fl_screen. 

Yes, let's use fl_screen
For now I changed it to use DefaultScreen(fl_get_display()), will
switch to fl_screen later.

| I'll let those who care for correct GUI-I stuff decide how we should
| get hold of the screen and display we are using (maybe members of
| LyXGUI). Anyway, if nobody does anything, I plan at least to change
| each occurence of DefaultScreenOfDisplay to DefaultScreen.

All this should be written to just be dependant on the _GUI lib_ not
on X... but I guess that will be a bit hard to do in one go.

Lgb

Re: Making LyX work on different screens.

[Jean-Marc Lasgouttes]

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

Lars Yes, let's use fl_screen For now I changed it to use
Lars DefaultScreen(fl_get_display()), will switch to fl_screen later.

I'll do this minimal chnage to 1.1.5 too.

Lars All this should be written to just be dependant on the _GUI lib_
Lars not on X... but I guess that will be a bit hard to do in one go.

What I meant is that we should avoid explicit references to
fl_display/fl_screen.

JMarc

new xforms patch

[Angus Leeming]

Attached is a patch implementing Allan's suggestions about a FormInset base 
class. I've actually implemented three small new classes:

FormBaseBI and FormBaseBD are base classes for Buffer Independent and Buffer 
Dependent dialogs respectively. FormInset is, in turn, derived from 
FormBaseBD. I've also got my head around overloading connect() and 
disconnect() in the daughter classes. 

Incidentally, Allan, I think that the names of these methods are fine. Think 
of them as meaning "things to be done on connection" rather than simply 
"connect signals".

All this gives no new functionality, just cleans up the code base. Hope that 
its now logical.

One new piece of functioality has been added, however. I've used some of 
Baruch's code from FormGraphics in the FormInset-derived classes. If a dialog 
is open and recieves a new "Show" or "Create" signal from another inset, then 
the dialog is updated with the new inset's data. No need to first close the 
dialog to one inset before opening it for another.

Angus

ps. The attached tar file will expand to
PATCH11Oct2000/patch
PATCH11Oct2000/src/frontends/xforms/FormInset.[Ch]

FormInset.[Ch] are replacements for FormCommand.[Ch]. Please remove 
FormCommand.[Ch].

A.



 patch11Oct2000.tar.bz2

Re: Making LyX work on different screens.

[Jean-Marc Lasgouttes]

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

Lars Yes, let's use fl_screen For now I changed it to use
Lars DefaultScreen(fl_get_display()), will switch to fl_screen later.

Hmm, maybe I spoke too fast. It seems that DefaultScreen returns an
int, while DefaultScreenOfDisplay returns a Screen*. And, judging from
Xlib.h (and not only from the man page), they should be the same
thing... 

So this was not the problem we were looking for. Another suspicious
thing is 
 Display * tempdisp = XOpenDisplay(XDisplayName(0));

Are we guarranteed that this uses the right screen?

JMarc

Re: Compiling LyX using AthlonGCC

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

|  "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
| 
| Lars As a guideline we should inline as _few_ functions/methods as
| Lars possible. _Unless_ we can show by profiling that it will have a
| Lars large effect and that the current code is too slow because of
| Lars out-of-line code.
| 
| BTW, Lars, could we remove -Winline from the default CXXFLAGS at least
| for gcc 2.95.2? It generates a bunch of warnings always in the same
| place in map (a bug in the library, it seems), and makes compilation
| a bit painful...

I really don't want to...

| Also, did you see the pointer in lyx-users to the bug report for
| redhat 7.0 explaining that our flags for 2.96 are a bit overdone? It
| like to fix that in 1.1.5fix2, so that it compiles cleanly on redhat
| 7.0.

You can at least remove pedantic if that is present.

What flags are used for 2.96 at present? (I really hate Redhat for
releasing an 2.96 which is not endoresed by the gcc team.)

Lgb

Re: You only fix twice (status update #2)

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

|  "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
| 
| Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: |
| Lars Hello, | | I finally (think we have) fixed the locale problem
| Lars which has been | plaguing german users. Therefore, I think it
| Lars will be nice to release | 1.1.5fix2 as soon as possible.
| 
| Lars Also note that this code might play tricks wit oter float values
| Lars that we ouput. In particular in figinset, for the control file
| Lars to gs. (I am not sure if this is a problem in 1.1.5, but it
| Lars certainly is in 1.1.6cvs)
| 
| I have added in 1.1.5 a
|   setlocale(LC_NUMERIC, "C");
| in main(). This probably not the right place, but isn't it the
| simplest solution?

If this takes care of everything then yes.

Note however that we really want to switch to C++ locale when that is
possible.

Lgb

Re: Making LyX work on different screens.

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

|  "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
| 
| Lars Yes, let's use fl_screen For now I changed it to use
| Lars DefaultScreen(fl_get_display()), will switch to fl_screen later.
| 
| I'll do this minimal chnage to 1.1.5 too.

I actually it is a bit more complicated DefaultScreen and
DefaultScreenOfDisplay does not return the same type, in several
places I used this:

ScreenOfDisplay(fl_get_display(), fl_screen);

| Lars All this should be written to just be dependant on the _GUI lib_
| Lars not on X... but I guess that will be a bit hard to do in one go.
| 
| What I meant is that we should avoid explicit references to
| fl_display/fl_screen.

Yes, unless in the XForms dir. My comment was aimed to that we should
never have explicit references to _any_ X functions, be it in src
xform, qt, gnome or whatever. (unless someone writes an athena
port...)

Lgb

Re: You only fix twice (status update #2)

[Jean-Marc Lasgouttes]

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

Lars If this takes care of everything then yes.

This takes care of writing. For reading, I have hidden a small hack in
LyXLex::GetFloat to convert ',' to '.' :)

Lars Note however that we really want to switch to C++ locale when
Lars that is possible.

Sure.

JMarc

Re: Compiling LyX using AthlonGCC

[Jean-Marc Lasgouttes]

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

Lars What flags are used for 2.96 at present? (I really hate Redhat
Lars for releasing an 2.96 which is not endoresed by the gcc team.)

See the report at
  http://www.redhat.com/bugzilla/show_bug.cgi?id=18166

Basically, lyx assumes that 2.96==listdc++-3

JMarc

Re: Making LyX work on different screens.

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

|  "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
| 
| Lars Yes, let's use fl_screen For now I changed it to use
| Lars DefaultScreen(fl_get_display()), will switch to fl_screen later.
| 
| Hmm, maybe I spoke too fast. It seems that DefaultScreen returns an
| int, while DefaultScreenOfDisplay returns a Screen*. And, judging from
| Xlib.h (and not only from the man page), they should be the same
| thing... 

For Screen* I think we should use ScreenOfDisplay(fl_get_display(),
fl_screen)
for int screen we should use fl_screen
for Display * display we use fl_get_display();

| So this was not the problem we were looking for. Another suspicious
| thing is 
|  Display * tempdisp = XOpenDisplay(XDisplayName(0));

Hmm... perhaps not... kan we det the display name from DISPLAY?
XOpenDisplay(0) can probably be used then. (actually XDisplayName(0)
returns DISPLAY as well. so this should already be correct.)

Does xforms change the DISPLAY when the --display is passed?

| Are we guarranteed that this uses the right screen?

Yes, if xforms sets the DISPLAT when -display is used.

Lgb

Re: Compiling LyX using AthlonGCC

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

|  "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
| 
| Lars What flags are used for 2.96 at present? (I really hate Redhat
| Lars for releasing an 2.96 which is not endoresed by the gcc team.)
| 
| See the report at
|   http://www.redhat.com/bugzilla/show_bug.cgi?id=18166
| 
| Basically, lyx assumes that 2.96==listdc++-3

Yes, and that is what we should do since libstdc++-v3 is not released
yet.

(libstdc++-3 is just a patched version of libstdc++-2)

Lgb

Re: First attempt at using SAX for XML output.

[Lars Gullik Bjønnes]

Gaillard Pierre-Olivier [EMAIL PROTECTED] writes:

| "Lars Gullik Bjønnes" wrote:
|  
|  Gaillard Pierre-Olivier [EMAIL PROTECTED] writes:
|  
|  |  XMLAttributes is a subclass of mapstring,string that defines a method
|  | "set(string name, int value)".
|  
|  By adding a [] operator you can at least make things a bit nicer.
|  
|  I tried this (see lower) but since it is a conversion problem is seems
| I should redefine "=" operator 
| or define a converter from int to string.

Hmmm, yes... this should be possible by not inheriting from map, but
instead use map as a member variable. I belive that will make the
design better too.

|  |  What do you think, may I write new Lyx 'Write' methods in the same
|  | style ? In languages like Python the
|  |  code is even nicer, but maybe Lars would know how to make this code
|  | nicer in C++.
|  
|  How is it done in Python?
|  
|  In Python dictionnaries (maps) are native, so you can write something
| like :
|   xmlOut.startElement("LyxTabular", {"version" : "1.0", "option" :
| "xml"})
|  Also you don't need to manage your memory and you can put any type of
| data 
| in your dictionnary. So that ints work as well as strings without any
| effort.

So we should be albe to have something like:

xmlOut.startElement("LyxTabular").subE("version", "1.0").subE("option", "xml");

if we want to. And if we make subE an template member we can use it to
insert types of any kind. (as long as they can be converted to string
with tostr (support/lstrings.h))


|  that method 'set' was OK. I believe I need a subclass of string (e.g.
| ValueString) that provides a constructor :
|   ValueString(int i). 
|  But I am not used to C++ so I did not do that. If you think I should I
| can do it on wednesday evening.

This should not be needed, and is not adviced anyway.

|  Or is set a template?
|  What is XMLAttributes really?
| 
|  Well just a mapstring, string with an additional 'set' method that
| uses strstream to build a string from the int value it was passed. You
| can check this in the files I sent to you and Juergen ).

I did right after reading your patch. (tar.gz)

|  As far as release-time is concerned, I need this XML file-format at
| work (I need to emulate some Interleaf features soon, so I need to be
| able to manage LyX files in Python scripts) but I am afraid that 1.1.6
| would not be ready in-time anyway (that is even if XML file-format did
| not introduce any delay... which is questionable), so that I will have
| to make the scripts for the current LyX format. Then when the XML format
| is available I can upgrade my scripts easily and make them robust.
|  
|   Thanks for your help, I expect to write other XML write methods on
| wednesday but if you have comments I will 
| rewrite the things until we get something clean. 

Ok.

Lgb

Re: C-home etc not working 1.1.6cvs

[Garst R. Reese]

"Lars Gullik Bjønnes" wrote:
 
 "Garst R. Reese" [EMAIL PROTECTED] writes:
 
 | It happens after I save preferences, quit LyX, restart LyX -- no Ctrl.
 | Garst### This file is part of
 | ### 
 | ###  LyX, The Document Processor
 | ###
 | ###  Copyright 1995 Matthias Ettrich
 | ###  Copyright 1995-2000 The LyX Team.
 | ###
 | ### 
 |
 | # This file is written by LyX, if you want to make your own
 | # modifications you should do them from inside LyX and save
 |
 | \bind_file menus.bind
 
 Why do you use this bind file?
 Use emacs.bind or cua.bind instead.
 
 We need a way to edit bindings from inside LyX...
 
 Lgb
I use cua.bind, but it includes menus.bind. The preferences file
apparently picks up mylyxrc, which says it defaults to cua.bind and I do
not change that.
I don't know where I got the idea that cua.bind should include
menus.bind, but I think it always has. It also includes math.bind and
hollywood.bind. Should I remove all of those?
Garst

Re: C-home etc not working 1.1.6cvs

[Lars Gullik Bjønnes]

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

|  | \bind_file menus.bind
|  
|  Why do you use this bind file?
|  Use emacs.bind or cua.bind instead.
|  
|  We need a way to edit bindings from inside LyX...
|  
|  Lgb
| I use cua.bind, but it includes menus.bind. The preferences file
| apparently picks up mylyxrc, which says it defaults to cua.bind and I do
| not change that.
| I don't know where I got the idea that cua.bind should include
| menus.bind, but I think it always has. It also includes math.bind and
| hollywood.bind. Should I remove all of those?

No, but when preferences is in use lyxrc is ignored. So if you have
menus.bind in preferences you will only get the bindings defined
there.

Lgb

Re: C-home etc not working 1.1.6cvs

[Garst R. Reese]

"Lars Gullik Bjønnes" wrote:
 
 "Garst R. Reese" [EMAIL PROTECTED] writes:

 | I don't know where I got the idea that cua.bind should include
 | menus.bind, but I think it always has. It also includes math.bind and
 | hollywood.bind. Should I remove all of those?
 
 No, but when preferences is in use lyxrc is ignored. So if you have
 menus.bind in preferences you will only get the bindings defined
 there.
 
 Lgb
No bind files were defined in preferences, but when I changed lyxrc, the
stuff that did come up in preferences changed with it, so I don't think
it is totally ignored. I don't have a clue as to why preferences listed
menus.bind as the bind file, but that is probably why I lost my Ctrl key
functions.
Garst

Re: Small error in encoding file (probably)

[Dekel Tsur]

On Wed, Oct 11, 2000 at 10:54:49AM +0200, Juergen Vigna wrote:
 
 I get this message when fireing up todays cvs:
 
 LyX: Encodings::read: Unknown tag: `' [around line 214 of file
 /nfs/sinco/source/lyx/lyx-devel/lib/encodings]
 
 I think I'm save to blame Dekel about this #:O)

I've already fixed this in my tree.

Re: C-home etc not working 1.1.6cvs

[Garst R. Reese]

"Lars Gullik Bjønnes" wrote:
 
 "Garst R. Reese" [EMAIL PROTECTED] writes:
 
 | "Lars Gullik Bjønnes" wrote:
 | 
 |  "Garst R. Reese" [EMAIL PROTECTED] writes:
 |
 |  | I don't know where I got the idea that cua.bind should include
 |  | menus.bind, but I think it always has. It also includes math.bind and
 |  | hollywood.bind. Should I remove all of those?
 | 
 |  No, but when preferences is in use lyxrc is ignored. So if you have
 |  menus.bind in preferences you will only get the bindings defined
 |  there.
 | 
 |  Lgb
 | No bind files were defined in preferences, but when I changed lyxrc, the
 | stuff that did come up in preferences changed with it, so I don't think
 | it is totally ignored. I don't have a clue as to why preferences listed
 | menus.bind as the bind file, but that is probably why I lost my Ctrl key
 | functions.
 | Garst
 
 // If there is a preferences file we read that instead
 // of the old lyxrc file.
 if (!ReadRcFile("preferences"))
 ReadRcFile("lyxrc");
 
 lyxrc is not supposed to be read if a read of preferences is
 successful.
 
 Lgb
Yes, but if lyxrc is not there to start with preferences cannot be
saved, so there will not be a preferences. Once preferences gets saved
then the lyxrc is not read anymore, but preferences got the wrong bind
file.
Garst

[PATCH] Small additions for the win32 port

[Ruurd A Reitsma]

At this momemt, lyx compiles almost out of the box on win32 using the cygwin
environement, except for one little detail:

--- lyxserver.C Wed Oct 11 20:47:48 2000
+++ lyx-devel/src/lyxserver.C   Wed Oct 11 13:51:18 2000
@@ -72,7 +72,7 @@
 // provide an empty mkfifo() if we do not have one. This disables the
 // lyxserver.
 #ifndef HAVE_MKFIFO
-intmkfifo( char *__path, mode_t __mode ) {
+intmkfifo(const char *__path, mode_t __mode ) {
return 0;
 }
 #endif

Which seems to be more compliant with the lyxstring class...(?)

I've made a small patch to get lyx to set some environement vars by itself,
i.e. reading them from the windows registry. This enables lyx to stand on
it's own, not using any shell scripts to start. Linking with the

-mwindows -e _mainCRTStartup

flags gets rid of the console window. I would be usefull to add an autoconf
option to do this, but I actually don't know how to do this.
Besides that, there are probably a few more patches needed to get the whole
thing to work under win32. Claus, could you post the changes you've made? I
wasn't able to find them on the list/source/your homepage.

--Ruurd


 cygwin_1.1.6.patch
 cygwin_1.1.5fix1.patch

Re: [PATCH] Small additions for the win32 port

[Lars Gullik Bjønnes]

"Ruurd A Reitsma" [EMAIL PROTECTED] writes:

| At this momemt, lyx compiles almost out of the box on win32 using the cygwin
| environement, except for one little detail:
| 
| --- lyxserver.C   Wed Oct 11 20:47:48 2000
| +++ lyx-devel/src/lyxserver.C Wed Oct 11 13:51:18 2000
| @@ -72,7 +72,7 @@
|  // provide an empty mkfifo() if we do not have one. This disables the
|  // lyxserver.
|  #ifndef HAVE_MKFIFO
| -int  mkfifo( char *__path, mode_t __mode ) {
| +int  mkfifo(const char *__path, mode_t __mode ) {
|   return 0;
|  }
|  #endif

I'll add this.

| Which seems to be more compliant with the lyxstring class...(?)
| 
| I've made a small patch to get lyx to set some environement vars by itself,
| i.e. reading them from the windows registry. This enables lyx to stand on
| it's own, not using any shell scripts to start. Linking with the
| 
| -mwindows -e _mainCRTStartup

Hmm, you chould be able to do this with CXXFLAGS?
Actualy there should be no problem for us to add this to configure.
Is this always wanted? Or are there situations were you want the
console?

| flags gets rid of the console window. I would be usefull to add an autoconf
| option to do this, but I actually don't know how to do this.
| Besides that, there are probably a few more patches needed to get the whole
| thing to work under win32. Claus, could you post the changes you've made? I
| wasn't able to find them on the list/source/your homepage.
| 
| --Ruurd

--- main.C  Wed Oct 11 17:46:57 2000
+++ lyx-devel/src/main.CWed Oct 11 19:11:52 2000
@@ -16,6 +16,12 @@
 #include "support/filetools.h"
 #include "frontends/GUIRunTime.h"
 
+#ifdef __CYGWIN__
+#include stdio.h
+#include windows.h
+#include io.h
+#endif
+

I can ensure you that we don't want this one :-)
 
 int main(int argc, char * argv[])
 {
@@ -35,6 +41,44 @@
 
 #ifdef __EMX__
_wildcard(argc, argv);
+#endif
+
+#ifdef __CYGWIN__
+
+static char display[100];
+static char home[100];
+static char value[100];
+HKEY reg_key = NULL;
+DWORD type;
+DWORD nbytes = sizeof (value);
+
+if (RegOpenKeyEx (HKEY_LOCAL_MACHINE, "Software\\Lyx", 0,
+   KEY_QUERY_VALUE, reg_key) != ERROR_SUCCESS
+  || RegQueryValueEx (reg_key, "DISPLAY", 0,
+ type, (BYTE *) value, nbytes) != ERROR_SUCCESS
+  || type != REG_SZ)
+{
+  /* Use the default value */
+  sprintf (value, "localhost:0.0");
+}
+
+sprintf(display,"DISPLAY=%s",value);
+PutEnv(display);
+   
+if (RegQueryValueEx (reg_key, "HOME", 0,
+ type, (BYTE *) value, nbytes) != ERROR_SUCCESS
+  || type != REG_SZ)
+{
+  /* Use the default value */
+  sprintf (value, "//c");
+}
+
+if (reg_key != NULL)
+RegCloseKey (reg_key);
+
+sprintf(home,"HOME=%s",value);
+PutEnv(home);
+

All this should be moved to some support file, that only gets
included/built when we are compiling on a __CYGWIN__ environment.

I guess we could add a src/os/ directory similar to src/frontends to
take care of things like this.

from int main(...) we can then just call something like:

os::init(...)

This should also work for the OS2 _wildcard stuff.

If we have other cases like this other places in the code we can add
more functions to os::

Lgb

Re: C-home etc not working 1.1.6cvs

[Lars Gullik Bjønnes]

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

| Yes, but if lyxrc is not there to start with preferences cannot be
| saved, so there will not be a preferences.

What do you mean?
Sure we can write a preferences without ever having a .lyx/lyxrc?

| Once preferences gets saved
| then the lyxrc is not read anymore, but preferences got the wrong bind
| file.

From lyxrc.defaults or lyxrc or inputed in the FormPreferences.

Lgb

lib/Makefile.am dist patch

[Kayvan A. Sylvan]

Here's a quick oversight.

-- 
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


Index: lib/Makefile.am
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/Makefile.am,v
retrieving revision 1.17
diff -u -r1.17 Makefile.am
--- lib/Makefile.am 2000/10/10 12:36:34 1.17
+++ lib/Makefile.am 2000/10/11 22:55:21
@@ -33,7 +33,8 @@
  templates tex ui
 
 EXTRA_DIST = CREDITS chkconfig.ltx configure.cmd lyxrc.example \
-   external_templates $(LYXLIBDIRS) build-listerrors
+   external_templates $(LYXLIBDIRS) build-listerrors \
+   encodings languages
 
 libinstalldirs:
for dir in $(LYXLIBDIRS) ; do \

Re: lib/Makefile.am dist patch

[Lars Gullik Bjønnes]

"Kayvan A. Sylvan" [EMAIL PROTECTED] writes:

| Here's a quick oversight.

Ok, I added that.

Lgb

Re: C-home etc not working 1.1.6cvs

[Allan Rae]

On 11 Oct 2000, Lars Gullik Bjønnes wrote:

 "Garst R. Reese" [EMAIL PROTECTED] writes:
 | Once preferences gets saved
 | then the lyxrc is not read anymore, but preferences got the wrong bind
 | file.
 
 From lyxrc.defaults or lyxrc or inputed in the FormPreferences.

Preferences only saves the differences between the system lyxrc
(for example, /usr/local/share/lyx/lyxrc) and user changes in ~/.lyx/lyxrc
or ~/.lyx/preferences if one existed and whatever changes a user made in
the Preferences dialog.

Somewhere along the line the global variable lyxrc had its bind_file
member set to "menus".  So the question is how did this happen?

It would seem to me that somewhere along the line Garst has a line like:
\bind_file menus.bind

in either ~/.lyx/lyxrc or added it to Preferences dialog.  I certainly
don't see any problem here using the xemacs bind -- it includes other
bind files within it but they don't change the value of lyxrc.bind_file.
Does anyone else use cua.bind like Garst does?  Do you see anything like
this?

Lars, wrt editing bindings this is something I have also considered and
think we'll probably need a similar scheme to what I do with lyxrc -- keep
both a system and a user binding global variable and only save the
difference to preferences otherwise we have to introduce some way of
storing _all_ the users bindings to a single file and set \bind_file in
preferences to refer to that file.  Anyway editing bindings isn't
difficult since the function names are available in the source in a
convenient array.  This is something I was considering adding in the
longer term.

The hard part may be to add editing for \converter and \viewer commands.  
I've only skimmed over the headers for that and am unsure of how it all
works.

Allan. (ARRae)

Re: new xforms patch

[Allan Rae]

On Wed, 11 Oct 2000, Angus Leeming wrote:

 Attached is a patch implementing Allan's suggestions about a FormInset base 
 class. I've actually implemented three small new classes:
 
 FormBaseBI and FormBaseBD are base classes for Buffer Independent and Buffer 
 Dependent dialogs respectively. FormInset is, in turn, derived from 
 FormBaseBD.

[sigh] Didn't I tell you not to run off and implement this stuff for a few
days so we could have time to think about it. ;-)

It occured to me that we could make things clearer by just merging the two
enums in FormBase to:
enum BufferDependency {
BUFFER_UPDATE,  // always update
BUFFER_CHECK,   // same buffer then update else hide
INDEPENDENT
}

This removes the confusion I mentioned in FormPreferences, although it
still leaves the buffer check problem.

An alternative fix would be by making
Signal1void, bool updateBufferDependent;

Such that true == "buffer change", and false == "same buffer". This is
simple enough and we could then eliminate the keeping of a Buffer*
anywhere.  We wouldn't need the updateOrHide() stuff at all.  We wouldn't
need the modified BufferDependency enum above or the ChangedBufferAction
enum.  The various update() members would need to change to accept a bool
but they could/should also default to false.  The testing of whether to
hide or update can then be done in the update() where it belongs.  (It'd
also mean we wouldn't need most of your patch -- see why I told you not to
run off and implement the FormInset stuff: some other idea came up)

What do you think of this?

I'll take a look at your patch and see what I think of that.
Frustrating aren't I?

 I've also got my head around overloading connect() and disconnect() in
 the daughter classes.  Incidentally, Allan, I think that the names of
 these methods are fine. Think of them as meaning "things to be done on
 connection" rather than simply "connect signals".

Fair enough.  I'll add a longer comment to that effect to FormBase.
 
 All this gives no new functionality, just cleans up the code base. Hope that 
 its now logical.

We probably still want a FormInset anyway.  Although if we adopt my
suggestion for changing the updateBufferDependent signal much of what you
have written will need to be rewritten (or just culled).  I'm inclinded to
just leave the BufferDependency stuff in FormBase rather than add another
layer in the form of FormBaseB[DI].

 One new piece of functioality has been added, however. I've used some of 
 Baruch's code from FormGraphics in the FormInset-derived classes. If a dialog 
 is open and recieves a new "Show" or "Create" signal from another inset, then 
 the dialog is updated with the new inset's data. No need to first close the 
 dialog to one inset before opening it for another.

Yay!

Allan. (ARRae)

why fmt was added...

[Lars Gullik Bjønnes]

from man 3 printf:

   Many countries use the day-month-year  order.   Hence,  an
   internationalized  version must be able to print the argu­
   ments in an order specified by the format:
  #include stdio.h
  fprintf(stdout, format,
   weekday, month, day, hour, min);
   where format depends on locale, and may permute the  argu­
   ments. With the value
  "%1$s, %3$d. %2$s, %4$d:%5$.2d\n"
   one might obtain `Sonntag, 3. Juli, 10:02'.

To be able to do things like this we need to have a printf style of
declaring user/i18n/l10n strings

"LyX failed to save file %1$s in %2$s dir."

can be altered in po files to f.ex:

"Dir %2$s is not open for writing for file %1$s"

I am sure this can be useful.

Lgb
 

cvs 1.1.6 compile errors

[Garst R. Reese]

attached
Garst

make[3]: Entering directory `/usr/local/garst/lyx-devel/src'
g++ -DHAVE_CONFIG_H -I. -I. -I. -I.. -I.. -I../boost-isystem /usr/X11R6/include  
-g -O -fno-rtti -fno-exceptions -W -Wall -Wconversion -Winline -c gettext.C
gettext.C:7: parse error before `char'
gettext.C:13: parse error before `const'
gettext.C:16: `s' was not declared in this scope
gettext.C:17: syntax error before `.'
gettext.C:18: `s' was not declared in this scope
gettext.C:18: ANSI C++ forbids declaration `tmp' with no type
gettext.C:18: assignment (not initialization) in declaration
gettext.C:20: parse error before `delete'
make[3]: *** [gettext.o] Error 1
make[3]: Leaving directory `/usr/local/garst/lyx-devel/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/local/garst/lyx-devel/src'
make[1]: *** [all-recursive-am] Error 2
make[1]: Leaving directory `/usr/local/garst/lyx-devel/src'
make: *** [all-recursive] Error 1

Re: cvs 1.1.6 compile errors

[Lars Gullik Bjønnes]

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

| attached

Try this patch:

Index: gettext.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/gettext.C,v
retrieving revision 1.1
diff -u -p -r1.1 gettext.C
--- gettext.C   2000/10/11 21:06:39 1.1
+++ gettext.C   2000/10/12 02:07:11
@@ -3,6 +3,7 @@
 #include "LString.h"
 #include "gettext.h"
 
+#ifdef ENABLE_NLS
 
 char const * _(char const * str)
 {
@@ -20,3 +21,5 @@ string const _(string const  str)
delete [] tmp;
return ret;
 }
+
+#endif   

Lgb

Re: cvs 1.1.6 compile errors

[Garst R. Reese]

"Lars Gullik Bjønnes" wrote:
 
 "Garst R. Reese" [EMAIL PROTECTED] writes:
 
 | attached
 
 Are you configuring --disable-nls ?
 
 (if you don't you have a _very_ strange compiler...)
 
 Lgb
Yes, I was having problems earlier with compiling with nls enabled. I'll
check the patch. Thanks

Re: cvs 1.1.6 compile errors

[Garst R. Reese]

"Lars Gullik Bjønnes" wrote:
 
 "Garst R. Reese" [EMAIL PROTECTED] writes:
 
 | attached
 
 Try this patch:
 
 Lgb
Worked.

Re: new xforms patch

[Allan Rae]

On Thu, 12 Oct 2000, Allan Rae wrote:

 On Wed, 11 Oct 2000, Angus Leeming wrote:
 
  Attached is a patch implementing Allan's suggestions about a FormInset base 
  class. I've actually implemented three small new classes:
  
  FormBaseBI and FormBaseBD are base classes for Buffer Independent and Buffer 
  Dependent dialogs respectively. FormInset is, in turn, derived from 
  FormBaseBD.
 
 [sigh] Didn't I tell you not to run off and implement this stuff for a few
 days so we could have time to think about it. ;-)
[...]

Good news... I'll apply it to my tree. 

and then I'll do the stuff below:

 An alternative fix would be by making
   Signal1void, bool updateBufferDependent;
 
 Such that true == "buffer change", and false == "same buffer".

[...]

  I've also got my head around overloading connect() and disconnect() in
  the daughter classes.  Incidentally, Allan, I think that the names of
  these methods are fine. Think of them as meaning "things to be done on
  connection" rather than simply "connect signals".

Why is it then that you wanted to add an ihSignal_ in FormInset when it
would make more sense to just make the connection in the appropriate
showInset() like it used to be done?  Over zealous perhaps?

There are a few things that'll be easy to clean up before I commit it.
(mostly related to redefining the updateBufferDepedent signal)

Allan. (ARRae)

Re: new FormPreferences crash

[Garst R. Reese]

Allan Rae wrote:
 
> I'll remove that check in my tree although it may not be committed for a
> day or so since I'm partway through expanding Preferences.
> 
> Allan. (ARRae)
Thanks, no rush.
Garst

Re: new FormPreferences crash

[Allan Rae]

On Wed, 11 Oct 2000, Garst R. Reese wrote:

> Allan Rae wrote:
>  
> > I'll remove that check in my tree although it may not be committed for a
> > day or so since I'm partway through expanding Preferences.
> > 
> > Allan. (ARRae)
> Thanks, no rush.

Well I've just committed it ;-)

The Preferences dialog now has space for messages under the OK,Apply,
Cancel buttons but I haven't got any messages yet.  I'd like to put
warnings and context-sensitive help messages there (or have tooltip help)
but I'll have to make the dialog wider and shorter to get it workable in a
640x480 screen.

Allan. (ARRae)

Small error in encoding file (probably)

[Juergen Vigna]

I get this message when fireing up todays cvs:

LyX: Encodings::read: Unknown tag: `' [around line 214 of file
/nfs/sinco/source/lyx/lyx-devel/lib/encodings]

I think I'm save to blame Dekel about this #: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

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

Every time I look at you I am more convinced of Darwin's theory.

gnome: FormRef and FormError

[Marko Vendelin]

Hi!

this patch adds FormRef and FormError to fine family of the dialogs ported
to Gnome frontend. These dialogs are implemented using an "action" area
to make the work with references as fast and convenient as possible and
scanning error messages less disturbing.

Marko 

 formcitation.gnome.patch.gz
 formref.gnome.newfiles.tar.gz

C-home etc not working 1.1.6cvs

[Garst R. Reese]

None of Control functions seem to be working.
The Ctrl key does function
Workarea event: KEYBOARD
WorkArea: Key is `Home' [65360]
WorkArea: Keysym is `Home' [65360]
Workarea Diff: 4301
KeySym is Home[65360]
Key [-1][C-Home]
Empty argument!
Running QuitLyX.

Garst

Re: gnome: FormRef and FormError

[Jean-Marc Lasgouttes]

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

Marko> this patch adds FormRef and FormError to fine family of the
Marko> dialogs ported to Gnome frontend. These dialogs are implemented
Marko> using an "action" area to make the work with references as fast
Marko> and convenient as possible and scanning error messages less
Marko> disturbing.

Marko,

are you sure you posted the right patches? You sent
formcitation.gnome.patch.gz, which is an old already applied patch,
and formref.gnome.newfiles.tar.gz. 

JMarc

Re: gnome: FormRef and FormError

[Marko Vendelin]

On 11 Oct 2000, Jean-Marc Lasgouttes wrote:

> > "Marko" == Marko Vendelin <[EMAIL PROTECTED]> writes:
> 
> Marko> this patch adds FormRef and FormError to fine family of the
> Marko> dialogs ported to Gnome frontend. These dialogs are implemented
> Marko> using an "action" area to make the work with references as fast
> Marko> and convenient as possible and scanning error messages less
> Marko> disturbing.
> 
> Marko,
> 
> are you sure you posted the right patches? You sent
> formcitation.gnome.patch.gz, which is an old already applied patch,
> and formref.gnome.newfiles.tar.gz. 

Sorry! I hope this time I am sending the right one.

Marko

 formref.gnome.newfiles.tar.gz
 formref.gnome.patch.gz

Re: C-home etc not working 1.1.6cvs

[Garst R. Reese]

"Garst R. Reese" wrote:
> 
> None of Control functions seem to be working.
> The Ctrl key does function
> Workarea event: KEYBOARD
> WorkArea: Key is `Home' [65360]
> WorkArea: Keysym is `Home' [65360]
> Workarea Diff: 4301
> KeySym is Home[65360]
> Key [-1][C-Home]
> Empty argument!
> Running QuitLyX.
> 
> Garst
Answering my own mail, but only after talking to myself.
The above problem only happens if I save a preferences file.
Garst

Re: gnome: FormRef and FormError

[John Levon]

On Wed, 11 Oct 2000, Marko Vendelin wrote:

> 
> 
> On 11 Oct 2000, Jean-Marc Lasgouttes wrote:
> 
> > > "Marko" == Marko Vendelin <[EMAIL PROTECTED]> writes:
> > 
> > Marko> this patch adds FormRef and FormError to fine family of the
> > Marko> dialogs ported to Gnome frontend. These dialogs are implemented
> > Marko> using an "action" area to make the work with references as fast
> > Marko> and convenient as possible and scanning error messages less
> > Marko> disturbing.
> > 
> > Marko,
> > 
> > are you sure you posted the right patches? You sent
> > formcitation.gnome.patch.gz, which is an old already applied patch,
> > and formref.gnome.newfiles.tar.gz. 
> 
> Sorry! I hope this time I am sending the right one.
> 
> Marko
> 

Any chance you can update the guii matrix as well ? There's not much point
having it if it's not going to be used :)

thanks
john

-- 
"Do you mean to tell me that "The Prince" is not the set textbook for
CS1072 Professional Issues ? What on earth do you learn in that course ?"
- David Lester

Re: gnome: FormRef and FormError

[Jean-Marc Lasgouttes]

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

Marko> Sorry! I hope this time I am sending the right one.

This looks better indeed :)

JMarc

Re: gnome: FormRef and FormError

[Jean-Marc Lasgouttes]

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

Marko> On Wed, 11 Oct 2000, John Levon wrote:
>> Any chance you can update the guii matrix as well ? There's not
>> much point having it if it's not going to be used :)

Marko> John, how should I do it? Where can I find file "guii.php3"?
Marko> 'locate guii.php3' gives nothing...

Get www-devel from the cvs server. This is the developpers web site
(and www-user is www.lyx.org).

JMarc

Re: C-home etc not working 1.1.6cvs

[Allan Rae]

On Wed, 11 Oct 2000, Garst R. Reese wrote:

> "Garst R. Reese" wrote:
> > 
> > None of Control functions seem to be working.
> > The Ctrl key does function
> > Workarea event: KEYBOARD
> > WorkArea: Key is `Home' [65360]
> > WorkArea: Keysym is `Home' [65360]
> > Workarea Diff: 4301
> > KeySym is Home[65360]
> > Key [-1][C-Home]
> > Empty argument!
> > Running QuitLyX.
> > 
> > Garst
> Answering my own mail, but only after talking to myself.
> The above problem only happens if I save a preferences file.

Oh come on! No fair blaming me when I can't repeat problem.
What's in your preferences file that is saved?

Does it occur straight away after you restart lyx when you a preferences
file?  Or only in a given session after saving preferences?

Allan. (ARRae)

Re: gnome: FormRef and FormError

[Marko Vendelin]

On 11 Oct 2000, Jean-Marc Lasgouttes wrote:

> Get www-devel from the cvs server. This is the developpers web site
> (and www-user is www.lyx.org).

Here is the update of guii.php3. 

Marko

 www.gnome.patch.gz

Re: C-home etc not working 1.1.6cvs

[Garst R. Reese]

Allan Rae wrote:
> 
> On Wed, 11 Oct 2000, Garst R. Reese wrote:
> 
> > "Garst R. Reese" wrote:
> > >
> > > None of Control functions seem to be working.
> > > The Ctrl key does function
> > > Workarea event: KEYBOARD
> > > WorkArea: Key is `Home' [65360]
> > > WorkArea: Keysym is `Home' [65360]
> > > Workarea Diff: 4301
> > > KeySym is Home[65360]
> > > Key [-1][C-Home]
> > > Empty argument!
> > > Running QuitLyX.
> > >
> > > Garst
> > Answering my own mail, but only after talking to myself.
> > The above problem only happens if I save a preferences file.
> 
> Oh come on! No fair blaming me when I can't repeat problem.

I didn't blame you :) 

> What's in your preferences file that is saved?

Attached

> Does it occur straight away after you restart lyx when you a preferences
> file?  Or only in a given session after saving preferences?
> 
> Allan. (ARRae)
It happens after I save preferences, quit LyX, restart LyX -- no Ctrl.
Garst

### This file is part of
### 
###  LyX, The Document Processor
###
###  Copyright 1995 Matthias Ettrich
###  Copyright 1995-2000 The LyX Team.
###
### 

# This file is written by LyX, if you want to make your own
# modifications you should do them from inside LyX and save

\bind_file menus.bind

#
# MISC SECTION ##
#


#
# SCREEN & FONTS SECTION 
#

\screen_font_roman "-*-utopia"

#
# PRINTER SECTION ###
#


#
# EXPORT SECTION 
#


#
# TEX SECTION ###
#


#
# LINUXDOC SECTION ##
#


#
# FILE SECTION ##
#

\document_path "/home/garst/lyxdocs/"
\num_lastfiles 9
\template_path "/home/garst/.lyx/templates/"

#
# FAX SECTION ###
#


#
# ASCII EXPORT SECTION ##
#


#
# SPELLCHECKER SECTION ##
#

\spell_command "aspell"

#
# LANGUAGE SUPPORT SECTION ##
#


#
# 2nd MISC SUPPORT SECTION ##
#

\screen_font_encoding_menu "iso8859-1"

Re: You only fix twice (status update #2)

[Baruch Even]

On 10 Oct 2000, Jean-Marc Lasgouttes wrote:

> - mangled minibuffer after resizing the main window. I can't find a
>   reference, but the effect is obvious (and recent). Could it be a
>   consequence of Lars' recent changes to scrollbars? Or simply a flaw
>   of the WorkArea? More generally, the minibuffer is strange since
>   when you click in it, the text does not disappear.

Attached is the patch to make the minibuffer clear when clicked on. I
could not get a situation where it gets mangled, if you have a sequence
that causes it it would help.

--
  Baruch Even

http://techst02.technion.ac.il/~sbaruch/   (My Site)
http://www.redrival.com/jindor/(My brothers AD site)

" Learn to laugh ... it's the path to true love! " 
   - The Angel in the movie Michael



 patch.diff.gz

Re: gnome: FormRef and FormError

[Jean-Marc Lasgouttes]

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

Marko> Content-Type: TEXT/PLAIN; charset=US-ASCII On 11 Oct 2000,
Marko> Jean-Marc Lasgouttes wrote:

>> Get www-devel from the cvs server. This is the developpers web site
>> (and www-user is www.lyx.org).

Marko> Here is the update of guii.php3.

Thanks, it is in now.

JMarc

Making LyX work on different screens.

[Jean-Marc Lasgouttes]

I think we should probably cleanup the use of screens (in the X sense)
by LyX. We've had reports that LyX crashes when used on a different
screen of a given display (meaning somebody have two graphic cards on
one system). I took a quick look at the source, and it seems to me
that we are using indifferently
  DefaultScreenOfDisplay(fl_get_display())
and 
  DefaultScreen(fl_get_display())
which are different things, if I read correctly the relevant man
pages. BTW, we also use indifferently fl_display and fl_get_display(),
which are the same thing indeed. It would be better to settle on one.

It seems to me that the right one to use is
DefaultScreen(fl_get_display()), which is in fact defined in forms.h
as fl_screen. So we might also want to use fl_screen. 

I'll let those who care for correct GUI-I stuff decide how we should
get hold of the screen and display we are using (maybe members of
LyXGUI). Anyway, if nobody does anything, I plan at least to change
each occurence of DefaultScreenOfDisplay to DefaultScreen.

JMarc

Re: You only fix twice (status update #2)

[Baruch Even]

On 10 Oct 2000, Jean-Marc Lasgouttes wrote:

> Remaining problems
> ==
>
> - we should check when writing to a stream failed due to not enough
>   disk space (how?)
>   http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg13483.html
>   http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg12733.html
> 
> - mangled minibuffer after resizing the main window. I can't find a
>   reference, but the effect is obvious (and recent). Could it be a
>   consequence of Lars' recent changes to scrollbars? Or simply a flaw
>   of the WorkArea? More generally, the minibuffer is strange since
>   when you click in it, the text does not disappear.

This now includes patches for this both problems. The patches are done
against 1.1.6cvs but I have no reason to believe it won't apply to
1.1.5fix1, anyway I dont want to believe otherwise :-)

The patch to the file system full gives detection but it creates another
bug which is that the file is created with size 0 and is not deleted. This
was noticed when using the SaveAs function. I'm not well versed in the
chain of work in the core so I'm sending the patch as it is and will try
hunting the new bug, but no promises implied.

-- 
  Baruch Even

http://techst02.technion.ac.il/~sbaruch/   (My Site)
http://www.redrival.com/jindor/(My brothers AD site)

" Learn to laugh ... it's the path to true love! " 
   - The Angel in the movie Michael



 patch.diff.gz

Re: Compiling LyX using AthlonGCC

[Lars Gullik Bjønnes]

Juergen Vigna <[EMAIL PROTECTED]> writes:

| On 10-Oct-2000 Baruch Even wrote:
| > 
| > OK, I'll try that later.
| > In the InsetGraphics patch I also put the de-inline of these functions it
| > might be desirable to remove them from the patch.
| > 
| > Jurgen: Let me know if you'll do it or if I need to provide a new patch.
| > 
| 
| I guess we can let them de-inlined!

As a guideline we should inline as _few_ functions/methods as
possible. _Unless_ we can show by profiling that it will have a large
effect and that the current code is too slow because of out-of-line
code.

If I do not already mention this in developmetn/Code_rules/Rules, I
will add it there. Also if it is a long time since you read this file
last, please read it again now. I have added quite a lot lately.

Lgb

Re: Compiling LyX using AthlonGCC

[Lars Gullik Bjønnes]

Juergen Vigna <[EMAIL PROTECTED]> writes:

| On 09-Oct-2000 Lars Gullik Bjønnes wrote:
| > 
| > You are allowed to post some compiler messages...
| > 
| > Seems to me to be a compiler bug.
| > And we don't want ANY defined like that...
| 
| I get NO compiler errors and get this on linking:
| 
| debug.o: In function `Debug::showLevel(ostream &, Debug::type)':
| /usr/include/g++-3/stl_relops.h:37: undefined reference to `Debug::ANY'
| collect2: ld returned 1 exit status 
Ok, your fix is just very wrong. I have put in what I belive to be the
correct fix instead.

Lgb

Re: Compiling LyX using AthlonGCC

[Jean-Marc Lasgouttes]

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

Lars> As a guideline we should inline as _few_ functions/methods as
Lars> possible. _Unless_ we can show by profiling that it will have a
Lars> large effect and that the current code is too slow because of
Lars> out-of-line code.

BTW, Lars, could we remove -Winline from the default CXXFLAGS at least
for gcc 2.95.2? It generates a bunch of warnings always in the same
place in  (a bug in the library, it seems), and makes compilation
a bit painful...

Also, did you see the pointer in lyx-users to the bug report for
redhat 7.0 explaining that our flags for 2.96 are a bit overdone? It
like to fix that in 1.1.5fix2, so that it compiles cleanly on redhat
7.0.

JMarc

Re: You only fix twice (status update #2)

[Lars Gullik Bjønnes]

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

| Hello,
| 
| I finally (think we have) fixed the locale problem which has been
| plaguing german users. Therefore, I think it will be nice to release
| 1.1.5fix2 as soon as possible. 

Also note that this code might play tricks wit oter float values that
we ouput. In particular in figinset, for the control file to gs.
(I am not sure if this is a problem in 1.1.5, but it certainly is in
1.1.6cvs)

Lgb

Re: Vfill not working 1.1.6cvs

[Lars Gullik Bjønnes]

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

| Layout Paragraph Above/Below Vfill does nothing.

Have you checked the LaTeX output too? vfill is not mentioned at all?
Or is it just a display problem?

Lgb

Re: C-home etc not working 1.1.6cvs

[Lars Gullik Bjønnes]

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


| It happens after I save preferences, quit LyX, restart LyX -- no Ctrl.
| Garst### This file is part of
| ### 
| ###  LyX, The Document Processor
| ###
| ###  Copyright 1995 Matthias Ettrich
| ###  Copyright 1995-2000 The LyX Team.
| ###
| ### 
| 
| # This file is written by LyX, if you want to make your own
| # modifications you should do them from inside LyX and save
| 
| \bind_file menus.bind

Why do you use this bind file?
Use emacs.bind or cua.bind instead.

We need a way to edit bindings from inside LyX...

Lgb

Re: You only fix twice (status update #2)

[Jean-Marc Lasgouttes]

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

Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: |
Lars> Hello, | | I finally (think we have) fixed the locale problem
Lars> which has been | plaguing german users. Therefore, I think it
Lars> will be nice to release | 1.1.5fix2 as soon as possible.

Lars> Also note that this code might play tricks wit oter float values
Lars> that we ouput. In particular in figinset, for the control file
Lars> to gs. (I am not sure if this is a problem in 1.1.5, but it
Lars> certainly is in 1.1.6cvs)

I have added in 1.1.5 a
  setlocale(LC_NUMERIC, "C");
in main(). This probably not the right place, but isn't it the
simplest solution?

JMarc

Re: Message translation related bug.

[Dekel Tsur]

On Tue, Oct 10, 2000 at 07:00:16PM +0200, Dekel Tsur wrote:
> I think that the attached patch will fix the problem (this fix is already
> present in 1.1.6).
>
> diff -u -p -r1.37.2.1 lyx_gui.C
> --- src/lyx_gui.C   2000/07/10 14:14:18 1.37.2.1
> +++ src/lyx_gui.C   2000/10/10 16:57:09
> @@ -404,7 +404,7 @@ void LyXGUI::create_forms()
> combo_language->addto((*cit).second.lang.c_str());
> combo_language2->addto((*cit).second.lang.c_str());
> }
> -   combo_language2->select_text("No change");
> +   combo_language2->select_text(_("No change"));
> 

Perhaps it is better to use combo_language2->select(1) instead of
combo_language2->select_text(..), 
or use the addline method instead of the addto method
(the addline method selects automatically the first added line).

--- src/lyx_gui.C   2000/07/10 14:14:18 1.37.2.1
+++ src/lyx_gui.C   2000/10/10 16:57:09
@@ -396,15 +396,14 @@ void LyXGUI::create_forms()
fl_end_form();
 
// "default" is not part of the languages array any more.
-   combo_language->addto("default");
-   combo_language2->addto(_("No change"));
-   combo_language2->addto(_("Reset"));
+   combo_language->addline("default");
+   combo_language2->addline(_("No change"));
+   combo_language2->addline(_("Reset"));
for(Languages::const_iterator cit = languages.begin();
cit != languages.end(); ++cit) {
combo_language->addto((*cit).second.lang.c_str());
combo_language2->addto((*cit).second.lang.c_str());
}
-   combo_language2->select_text("No change");
 
// not really necessary, but we can do it anyway.

Re: Making LyX work on different screens.

[Lars Gullik Bjønnes]

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

| I think we should probably cleanup the use of screens (in the X sense)
| by LyX. We've had reports that LyX crashes when used on a different
| screen of a given display (meaning somebody have two graphic cards on
| one system). I took a quick look at the source, and it seems to me
| that we are using indifferently
|   DefaultScreenOfDisplay(fl_get_display())
| and 
|   DefaultScreen(fl_get_display())
| which are different things, if I read correctly the relevant man
| pages. BTW, we also use indifferently fl_display and fl_get_display(),
| which are the same thing indeed. It would be better to settle on one.

Let's settle for fl_get_display()
I changed this.

| It seems to me that the right one to use is
| DefaultScreen(fl_get_display()), which is in fact defined in forms.h
| as fl_screen. So we might also want to use fl_screen. 

Yes, let's use fl_screen
For now I changed it to use DefaultScreen(fl_get_display()), will
switch to fl_screen later.

| I'll let those who care for correct GUI-I stuff decide how we should
| get hold of the screen and display we are using (maybe members of
| LyXGUI). Anyway, if nobody does anything, I plan at least to change
| each occurence of DefaultScreenOfDisplay to DefaultScreen.

All this should be written to just be dependant on the _GUI lib_ not
on X... but I guess that will be a bit hard to do in one go.

Lgb

Re: Making LyX work on different screens.

[Jean-Marc Lasgouttes]

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

Lars> Yes, let's use fl_screen For now I changed it to use
Lars> DefaultScreen(fl_get_display()), will switch to fl_screen later.

I'll do this minimal chnage to 1.1.5 too.

Lars> All this should be written to just be dependant on the _GUI lib_
Lars> not on X... but I guess that will be a bit hard to do in one go.

What I meant is that we should avoid explicit references to
fl_display/fl_screen.

JMarc

new xforms patch

[Angus Leeming]

Attached is a patch implementing Allan's suggestions about a FormInset base 
class. I've actually implemented three small new classes:

FormBaseBI and FormBaseBD are base classes for Buffer Independent and Buffer 
Dependent dialogs respectively. FormInset is, in turn, derived from 
FormBaseBD. I've also got my head around overloading connect() and 
disconnect() in the daughter classes. 

Incidentally, Allan, I think that the names of these methods are fine. Think 
of them as meaning "things to be done on connection" rather than simply 
"connect signals".

All this gives no new functionality, just cleans up the code base. Hope that 
its now logical.

One new piece of functioality has been added, however. I've used some of 
Baruch's code from FormGraphics in the FormInset-derived classes. If a dialog 
is open and recieves a new "Show" or "Create" signal from another inset, then 
the dialog is updated with the new inset's data. No need to first close the 
dialog to one inset before opening it for another.

Angus

ps. The attached tar file will expand to
PATCH11Oct2000/patch
PATCH11Oct2000/src/frontends/xforms/FormInset.[Ch]

FormInset.[Ch] are replacements for FormCommand.[Ch]. Please remove 
FormCommand.[Ch].

A.



 patch11Oct2000.tar.bz2

Re: Making LyX work on different screens.

[Jean-Marc Lasgouttes]

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

Lars> Yes, let's use fl_screen For now I changed it to use
Lars> DefaultScreen(fl_get_display()), will switch to fl_screen later.

Hmm, maybe I spoke too fast. It seems that DefaultScreen returns an
int, while DefaultScreenOfDisplay returns a Screen*. And, judging from
Xlib.h (and not only from the man page), they should be the same
thing... 

So this was not the problem we were looking for. Another suspicious
thing is 
 Display * tempdisp = XOpenDisplay(XDisplayName(0));

Are we guarranteed that this uses the right screen?

JMarc

Re: Compiling LyX using AthlonGCC

[Lars Gullik Bjønnes]

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

| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| 
| Lars> As a guideline we should inline as _few_ functions/methods as
| Lars> possible. _Unless_ we can show by profiling that it will have a
| Lars> large effect and that the current code is too slow because of
| Lars> out-of-line code.
| 
| BTW, Lars, could we remove -Winline from the default CXXFLAGS at least
| for gcc 2.95.2? It generates a bunch of warnings always in the same
| place in  (a bug in the library, it seems), and makes compilation
| a bit painful...

I really don't want to...

| Also, did you see the pointer in lyx-users to the bug report for
| redhat 7.0 explaining that our flags for 2.96 are a bit overdone? It
| like to fix that in 1.1.5fix2, so that it compiles cleanly on redhat
| 7.0.

You can at least remove pedantic if that is present.

What flags are used for 2.96 at present? (I really hate Redhat for
releasing an 2.96 which is not endoresed by the gcc team.)

Lgb

Re: You only fix twice (status update #2)

[Lars Gullik Bjønnes]

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

| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| 
| Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: |
| Lars> Hello, | | I finally (think we have) fixed the locale problem
| Lars> which has been | plaguing german users. Therefore, I think it
| Lars> will be nice to release | 1.1.5fix2 as soon as possible.
| 
| Lars> Also note that this code might play tricks wit oter float values
| Lars> that we ouput. In particular in figinset, for the control file
| Lars> to gs. (I am not sure if this is a problem in 1.1.5, but it
| Lars> certainly is in 1.1.6cvs)
| 
| I have added in 1.1.5 a
|   setlocale(LC_NUMERIC, "C");
| in main(). This probably not the right place, but isn't it the
| simplest solution?

If this takes care of everything then yes.

Note however that we really want to switch to C++ locale when that is
possible.

Lgb

Re: Making LyX work on different screens.

[Lars Gullik Bjønnes]

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

| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| 
| Lars> Yes, let's use fl_screen For now I changed it to use
| Lars> DefaultScreen(fl_get_display()), will switch to fl_screen later.
| 
| I'll do this minimal chnage to 1.1.5 too.

I actually it is a bit more complicated DefaultScreen and
DefaultScreenOfDisplay does not return the same type, in several
places I used this:

ScreenOfDisplay(fl_get_display(), fl_screen);

| Lars> All this should be written to just be dependant on the _GUI lib_
| Lars> not on X... but I guess that will be a bit hard to do in one go.
| 
| What I meant is that we should avoid explicit references to
| fl_display/fl_screen.

Yes, unless in the XForms dir. My comment was aimed to that we should
never have explicit references to _any_ X functions, be it in src
xform, qt, gnome or whatever. (unless someone writes an athena
port...)

Lgb

Re: You only fix twice (status update #2)

[Jean-Marc Lasgouttes]

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

Lars> If this takes care of everything then yes.

This takes care of writing. For reading, I have hidden a small hack in
LyXLex::GetFloat to convert ',' to '.' :)

Lars> Note however that we really want to switch to C++ locale when
Lars> that is possible.

Sure.

JMarc

Re: Compiling LyX using AthlonGCC

[Jean-Marc Lasgouttes]

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

Lars> What flags are used for 2.96 at present? (I really hate Redhat
Lars> for releasing an 2.96 which is not endoresed by the gcc team.)

See the report at
  http://www.redhat.com/bugzilla/show_bug.cgi?id=18166

Basically, lyx assumes that 2.96==>listdc++-3

JMarc

Re: Making LyX work on different screens.

[Lars Gullik Bjønnes]

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

| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| 
| Lars> Yes, let's use fl_screen For now I changed it to use
| Lars> DefaultScreen(fl_get_display()), will switch to fl_screen later.
| 
| Hmm, maybe I spoke too fast. It seems that DefaultScreen returns an
| int, while DefaultScreenOfDisplay returns a Screen*. And, judging from
| Xlib.h (and not only from the man page), they should be the same
| thing... 

For Screen* I think we should use ScreenOfDisplay(fl_get_display(),
fl_screen)
for int screen we should use fl_screen
for Display * display we use fl_get_display();

| So this was not the problem we were looking for. Another suspicious
| thing is 
|  Display * tempdisp = XOpenDisplay(XDisplayName(0));

Hmm... perhaps not... kan we det the display name from DISPLAY?
XOpenDisplay(0) can probably be used then. (actually XDisplayName(0)
returns DISPLAY as well. so this should already be correct.)

Does xforms change the DISPLAY when the --display is passed?

| Are we guarranteed that this uses the right screen?

Yes, if xforms sets the DISPLAT when -display is used.

Lgb

Re: Compiling LyX using AthlonGCC

[Lars Gullik Bjønnes]

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

| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| 
| Lars> What flags are used for 2.96 at present? (I really hate Redhat
| Lars> for releasing an 2.96 which is not endoresed by the gcc team.)
| 
| See the report at
|   http://www.redhat.com/bugzilla/show_bug.cgi?id=18166
| 
| Basically, lyx assumes that 2.96==>listdc++-3

Yes, and that is what we should do since libstdc++-v3 is not released
yet.

(libstdc++-3 is just a patched version of libstdc++-2)

Lgb

Re: First attempt at using SAX for XML output.

[Lars Gullik Bjønnes]

Gaillard Pierre-Olivier <[EMAIL PROTECTED]> writes:

| "Lars Gullik Bjønnes" wrote:
| > 
| > Gaillard Pierre-Olivier <[EMAIL PROTECTED]> writes:
| > 
| > |  XMLAttributes is a subclass of map that defines a method
| > | "set(string name, int value)".
| > 
| > By adding a [] operator you can at least make things a bit nicer.
| > 
|  I tried this (see lower) but since it is a conversion problem is seems
| I should redefine "=" operator 
| or define a converter from int to string.

Hmmm, yes... this should be possible by not inheriting from map, but
instead use map as a member variable. I belive that will make the
design better too.

| > |  What do you think, may I write new Lyx 'Write' methods in the same
| > | style ? In languages like Python the
| > |  code is even nicer, but maybe Lars would know how to make this code
| > | nicer in C++.
| > 
| > How is it done in Python?
| > 
|  In Python dictionnaries (maps) are native, so you can write something
| like :
|   xmlOut.startElement("LyxTabular", {"version" : "1.0", "option" :
| "xml"})
|  Also you don't need to manage your memory and you can put any type of
| data 
| in your dictionnary. So that ints work as well as strings without any
| effort.

So we should be albe to have something like:

xmlOut.startElement("LyxTabular").subE("version", "1.0").subE("option", "xml");

if we want to. And if we make subE an template member we can use it to
insert types of any kind. (as long as they can be converted to string
with tostr (support/lstrings.h))


|  that method 'set' was OK. I believe I need a subclass of string (e.g.
| ValueString) that provides a constructor :
|   ValueString(int i). 
|  But I am not used to C++ so I did not do that. If you think I should I
| can do it on wednesday evening.

This should not be needed, and is not adviced anyway.

| > Or is set a template?
| > What is XMLAttributes really?
| >
|  Well just a map with an additional 'set' method that
| uses strstream to build a string from the int value it was passed. You
| can check this in the files I sent to you and Juergen ).

I did right after reading your patch. (tar.gz)

|  As far as release-time is concerned, I need this XML file-format at
| work (I need to emulate some Interleaf features soon, so I need to be
| able to manage LyX files in Python scripts) but I am afraid that 1.1.6
| would not be ready in-time anyway (that is even if XML file-format did
| not introduce any delay... which is questionable), so that I will have
| to make the scripts for the current LyX format. Then when the XML format
| is available I can upgrade my scripts easily and make them robust.
|  
|   Thanks for your help, I expect to write other XML write methods on
| wednesday but if you have comments I will 
| rewrite the things until we get something clean. 

Ok.

Lgb

Re: C-home etc not working 1.1.6cvs

[Garst R. Reese]

"Lars Gullik Bjønnes" wrote:
> 
> "Garst R. Reese" <[EMAIL PROTECTED]> writes:
> 
> | It happens after I save preferences, quit LyX, restart LyX -- no Ctrl.
> | Garst### This file is part of
> | ### 
> | ###  LyX, The Document Processor
> | ###
> | ###  Copyright 1995 Matthias Ettrich
> | ###  Copyright 1995-2000 The LyX Team.
> | ###
> | ### 
> |
> | # This file is written by LyX, if you want to make your own
> | # modifications you should do them from inside LyX and save
> |
> | \bind_file menus.bind
> 
> Why do you use this bind file?
> Use emacs.bind or cua.bind instead.
> 
> We need a way to edit bindings from inside LyX...
> 
> Lgb
I use cua.bind, but it includes menus.bind. The preferences file
apparently picks up mylyxrc, which says it defaults to cua.bind and I do
not change that.
I don't know where I got the idea that cua.bind should include
menus.bind, but I think it always has. It also includes math.bind and
hollywood.bind. Should I remove all of those?
Garst

Re: C-home etc not working 1.1.6cvs

[Lars Gullik Bjønnes]

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

| > | \bind_file menus.bind
| > 
| > Why do you use this bind file?
| > Use emacs.bind or cua.bind instead.
| > 
| > We need a way to edit bindings from inside LyX...
| > 
| > Lgb
| I use cua.bind, but it includes menus.bind. The preferences file
| apparently picks up mylyxrc, which says it defaults to cua.bind and I do
| not change that.
| I don't know where I got the idea that cua.bind should include
| menus.bind, but I think it always has. It also includes math.bind and
| hollywood.bind. Should I remove all of those?

No, but when preferences is in use lyxrc is ignored. So if you have
menus.bind in preferences you will only get the bindings defined
there.

Lgb

Re: C-home etc not working 1.1.6cvs

[Garst R. Reese]

"Lars Gullik Bjønnes" wrote:
> 
> "Garst R. Reese" <[EMAIL PROTECTED]> writes:

> | I don't know where I got the idea that cua.bind should include
> | menus.bind, but I think it always has. It also includes math.bind and
> | hollywood.bind. Should I remove all of those?
> 
> No, but when preferences is in use lyxrc is ignored. So if you have
> menus.bind in preferences you will only get the bindings defined
> there.
> 
> Lgb
No bind files were defined in preferences, but when I changed lyxrc, the
stuff that did come up in preferences changed with it, so I don't think
it is totally ignored. I don't have a clue as to why preferences listed
menus.bind as the bind file, but that is probably why I lost my Ctrl key
functions.
Garst

Re: Small error in encoding file (probably)

[Dekel Tsur]

On Wed, Oct 11, 2000 at 10:54:49AM +0200, Juergen Vigna wrote:
> 
> I get this message when fireing up todays cvs:
> 
> LyX: Encodings::read: Unknown tag: `' [around line 214 of file
> /nfs/sinco/source/lyx/lyx-devel/lib/encodings]
> 
> I think I'm save to blame Dekel about this #:O)

I've already fixed this in my tree.

Re: C-home etc not working 1.1.6cvs

[Garst R. Reese]

"Lars Gullik Bjønnes" wrote:
> 
> "Garst R. Reese" <[EMAIL PROTECTED]> writes:
> 
> | "Lars Gullik Bjønnes" wrote:
> | >
> | > "Garst R. Reese" <[EMAIL PROTECTED]> writes:
> |
> | > | I don't know where I got the idea that cua.bind should include
> | > | menus.bind, but I think it always has. It also includes math.bind and
> | > | hollywood.bind. Should I remove all of those?
> | >
> | > No, but when preferences is in use lyxrc is ignored. So if you have
> | > menus.bind in preferences you will only get the bindings defined
> | > there.
> | >
> | > Lgb
> | No bind files were defined in preferences, but when I changed lyxrc, the
> | stuff that did come up in preferences changed with it, so I don't think
> | it is totally ignored. I don't have a clue as to why preferences listed
> | menus.bind as the bind file, but that is probably why I lost my Ctrl key
> | functions.
> | Garst
> 
> // If there is a preferences file we read that instead
> // of the old lyxrc file.
> if (!ReadRcFile("preferences"))
> ReadRcFile("lyxrc");
> 
> lyxrc is not supposed to be read if a read of preferences is
> successful.
> 
> Lgb
Yes, but if lyxrc is not there to start with preferences cannot be
saved, so there will not be a preferences. Once preferences gets saved
then the lyxrc is not read anymore, but preferences got the wrong bind
file.
Garst

[PATCH] Small additions for the win32 port

[Ruurd A Reitsma]

At this momemt, lyx compiles almost out of the box on win32 using the cygwin
environement, except for one little detail:

--- lyxserver.C Wed Oct 11 20:47:48 2000
+++ lyx-devel/src/lyxserver.C   Wed Oct 11 13:51:18 2000
@@ -72,7 +72,7 @@
 // provide an empty mkfifo() if we do not have one. This disables the
 // lyxserver.
 #ifndef HAVE_MKFIFO
-intmkfifo( char *__path, mode_t __mode ) {
+intmkfifo(const char *__path, mode_t __mode ) {
return 0;
 }
 #endif

Which seems to be more compliant with the lyxstring class...(?)

I've made a small patch to get lyx to set some environement vars by itself,
i.e. reading them from the windows registry. This enables lyx to stand on
it's own, not using any shell scripts to start. Linking with the

-mwindows -e _mainCRTStartup

flags gets rid of the console window. I would be usefull to add an autoconf
option to do this, but I actually don't know how to do this.
Besides that, there are probably a few more patches needed to get the whole
thing to work under win32. Claus, could you post the changes you've made? I
wasn't able to find them on the list/source/your homepage.

--Ruurd


 cygwin_1.1.6.patch
 cygwin_1.1.5fix1.patch