Re: Allan: follow up on build problems for Solaris

[Lars Gullik Bjønnes]

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

| Roland Krause wrote:
|  
|  I'd say, lets move on from this crap. Require make-3.79 on solaris. Be
|  done with it.
|  
|  Roland
| Do everybody a favour and require it across the board. We won't be
| alone. I already had to ugrade for some other pkg.
| Garst

I agree. 

Saves us a lot of troble.

Lgb

Re: ButtonController and ButtonPolicy

[Angus Leeming]

Hello, Allan.

Let me start with a justification of all this: I'd like to ease the pain of 
porting the dialogs to other GUIs by ensuring that they have only a minimum 
of things to do. We have occasional complaints from John and Marco about 
breaking their ports. Matthias Ettrich was rather more vocal. They are 
expressing a valid point. It's hard to keep up when the rules keep changing.

Each dialog exists to change some variables. Nothing more. It should, 
therefore, be passed only those variables (preferably as a Param struct). It 
should also have access to functions linked to the four Apply, Ok, Cancel, 
Reset buttons. Nothing more.

Everything else about the dialog, the signals it connects and disconnects to 
etc, should be controlled by a common Controller class. The GUIs need not 
worry about this. I've implemented this successfully.

In the same way, we can define a subset of the ButtonController class that is 
GUI-I. The GUI View need know about only the BC::valid() method called when 
an input is made and in the xforms case, about methods passed an FL_OBJECT *. 
You've written the Controller beautifully (serious here) so that the 
BC::apply(), ok() etc buttons know nothing about the xforms implementation.

I have it all working here. A ButtonController base class and a 
FormButtonController derived class containing xforms-specific stuff. I have a 
ControlledButtonDialog abstract class that has a ButtonController * and 4 
methods, ApplyButton(), OkButton, CancelButton() and RestoreButton() that 
does exactly as the static ApplyBC() etc used to do. All dialog-specific 
controllers can be derived from this.

It looks and feels clean and elegant and MINIMAL. That means, it should be 
readily understandable to John, Marco, whoever wants to implement another GUI.

If you want a look, just ask. Otherwise, I'll post when it's clean. I send 
enough junk to this list as-is!

Angus


On Saturday 13 January 2001 04:45, Allan Rae wrote:
 On Fri, 12 Jan 2001, Angus Leeming wrote:
  Allan,
 
  I've worked out how to put an abstract ButtonControllerBase in the
  ControlCitation class, or rather in a class that ControlCitation can be
  derived from.

 Are you sure you want an inheritance relationship?

 I'm not sure what sort of separations you are hoping to achieve here.  At
 this point in time I'd prefer to continue with what we already have and
 then develop a separation later if it really is necessary.  Are you sure
 that what you are doing is actually going to be reusable by either John
 or Marko or any other port for that matter?  If there is a good chance
 that it won't, then steady your beating heart and direct your passions
 elsewhere ;-)

 Perhaps now would be a good time to explain in detail what you are
 separating and why.  Or maybe I should read that other email from earlier
 in the week if I can find it in the mess that is my mailbox.

  I have one question regarding your ButtonController class. In the header
  file there is:
 
  // Somebody else owns the FL_OBJECTs we just manipulate them.
  // so? (Lgb)
  //~ButtonController() {}
 
  Well and good. But SURELY the ButtonController owns its ButtonPolicy and
  so this pointer should be deleted by the ButtonController d-tor?

 Yes.  This will soon spot anyone who is doing it wrong.

 Allan. (ARRae)

Re: Bug. Using Spanish

[Jean-Marc Lasgouttes]

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

 http://sourceforge.net/bugs/?func=detailbugbug_id=125614group_id=15212

Dekel Yes, this is the same "bug", but it not a bug in LyX, but a
Dekel problem with the Spanish babel file which redefine thes ~ char,
Dekel and gives no way of deactivating this brilliant feature (as far
Dekel as I could tell).

In fact, spanish.ldf should have a \noextrasspanish macro. It may
exist in recent babel versions...

Dekel Howeevr, I think that this problem should be automatically
Dekel solved by LyX. I can either add a Spanish specific code, or add
Dekel an extra-options field in the language class (are there any
Dekel other cases in which some language requires putting extra
Dekel commands in the preamble ?).

Dekel PS: The solution I wrote above will not work in multi-lingual
Dekel docs. Does anyone have a better solution ?

Maybe
  \addto\extrasspanish{\def~{\nobreakspace{}}}
which fits better with babel structure.

JMarc

Re: Babel in LyX 1.1.6

[Jean-Marc Lasgouttes]

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

Dekel The following was posted in lyx-users: On Fri, Jan 12, 2001 at
Dekel 03:53:21PM -0700, Matthew Lovell wrote:
 Lyx1.1.6 seems to be including the babel package in the resulting
 LaTeX code. Is there a way to turn off this behavior? It doesn't
 appear that I can select "none" for a language in the document
 settings. :)
 
 I have a thesis class which is not compatible with the babel
 package. All nifty features deserve an off switch, after all.

Dekel I think that we should add a boolean lyxrc variable, called
Dekel default_language_use_babel so if
Dekel lyxrc.default_language_use_babel = true, and the document
Dekel language == lyxrc.default_language, then the babel package will
Dekel not be loaded.

Why load babel if languag is default language, anyway? I think this
shows why having a default language was good...

JMarc

Re: Allan: follow up on build problems for Solaris

[Jean-Marc Lasgouttes]

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

Allan On Sat, 13 Jan 2001, Roland Krause wrote:
 Allan, a quick follow up.
 
 The generic solaris make definitely does not work. Upgrading gmake
 to version 3.79 finally solved the problem.

Allan According to other reports we have, we only had to remove the
Allan ':' for Sun's make to be happy. It may be a version thing I
Allan suppose.

The := syntax is a GNU make extension.

 Further, Solaris generic grep (/usr/bin/grep) does not know the
 option -E, /usr/xpg/bin/grep does.

Allan Does everyone have an egrep?

Why do you need this -E?

JMarc

Re: Allan: follow up on build problems for Solaris

[Jean-Marc Lasgouttes]

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

Allan That's the way someone wrote it originally. egrep or `grep -E`
Allan is the best tool for the job given that we want to find files
Allan with "_(\".*\")" in them. `grep grep po/Makefile.in.in` to see
Allan why.

What's wrong with 
  grep '_(".*")' ...

Am I just being dense?

JMarc

Re: Release LyX 1.1.6

[Jean-Marc Lasgouttes]

 "Frank" == Frank Derichsweiler [EMAIL PROTECTED] 
writes:

Frank On Mon, Jan 15, 2001 at 04:01:31PM +0900, R. Lahaye wrote:
 Date: Mon, 15 Jan 2001 16:01:31 +0900 From: "R. Lahaye"
 [EMAIL PROTECTED] To: Frank Derichsweiler
 [EMAIL PROTECTED] CC:
 [EMAIL PROTECTED] Subject: Re: Release LyX 1.1.6
 
 Frank Derichsweiler wrote:  A little problem within a linux
 environment: Having no kernel header  files (within
 /usr/src/linux) the configure script runs and produces  the error
 forms.h not found, which is IMHO misleading. Perhaps the 
 configure can be adopted to check for the kernel include files 
 separatly.
 
 forms.h is part of the development package of xforms, the one you
 need when compiling LyX yourself.
 
Frank Yes, I know that. To me a little bit clearer: I installed the
Frank xforms development stuff and all the other necessary libs and
Frank headers. Only the linux *kernel* headers were missing. 

We have something related in the INSTALL file, section "Problems":

  o Configure will seemingly fail to find xpm.h and forms.h on linux if
you did a 'make mrproper' in the kernel directory, because this
removes some symbolic links that are needed for compilation. A 'make
symlinks' in linux kernel sources fixes that.

However, having a header file which relies on kernel headers is a BUG
in itself (according to Linus himself). You should probably find out
which headers do that, and see whether an upgrade would be a proper
cure.

JMarc

Re: Bug. Using Spanish

[Dekel Tsur]

On Mon, Jan 15, 2001 at 11:18:32AM +0100, Jean-Marc Lasgouttes wrote:
 Dekel Yes, this is the same "bug", but it not a bug in LyX, but a
 Dekel problem with the Spanish babel file which redefine thes ~ char,
 Dekel and gives no way of deactivating this brilliant feature (as far
 Dekel as I could tell).
 
 In fact, spanish.ldf should have a \noextrasspanish macro. It may
 exist in recent babel versions...

Yes, but it doesn't deactivate the ~ char (I checked the latest beta version).

 Dekel Howeevr, I think that this problem should be automatically
 Dekel solved by LyX. I can either add a Spanish specific code, or add
 Dekel an extra-options field in the language class (are there any
 Dekel other cases in which some language requires putting extra
 Dekel commands in the preamble ?).
 
 Dekel PS: The solution I wrote above will not work in multi-lingual
 Dekel docs. Does anyone have a better solution ?
 
 Maybe
   \addto\extrasspanish{\def~{\nobreakspace{}}}
 which fits better with babel structure.

Or
\addto\extrasspanish{\bbl@deactivate{~}}

Re: Babel in LyX 1.1.6

[Dekel Tsur]

On Mon, Jan 15, 2001 at 11:24:42AM +0100, Jean-Marc Lasgouttes wrote:
 Dekel I think that we should add a boolean lyxrc variable, called
 Dekel default_language_use_babel so if
 Dekel lyxrc.default_language_use_babel = true, and the document
 Dekel language == lyxrc.default_language, then the babel package will
 Dekel not be loaded.
 
 Why load babel if languag is default language, anyway? I think this
 shows why having a default language was good...

Check the archive to see why we decided to remove it.

PS: Please send your emails only to lyx-devel. I'm getting your messages twice.

Re: Allan: follow up on build problems for Solaris

[Jean-Marc Lasgouttes]

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

  What's wrong with grep '_(".*")' ...

Allan Aren't regular expressions like above a GNU extension for grep.
Allan That's why I asked about egrep which I think (hope) is
Allan "standard". You gotta love Unix, there are so many standards to
Allan choose from.

What part of the regexp is an extension according to you? The use of
parenthesis? 

JMarc

Re: Babel in LyX 1.1.6

[Jean-Marc Lasgouttes]

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

  Why load babel if languag is default language, anyway? I think
 this shows why having a default language was good...

Dekel Check the archive to see why we decided to remove it.

I remember the messages, but I have to admit it did not get the point
at the time. I guess I should re-read them...

Dekel PS: Please send your emails only to lyx-devel. I'm getting your
Dekel messages twice.

I'm getting lazier since I configure GNUS to delete duplicated
messages :)

JMarc

Re: Release LyX 1.1.6

[Frank Derichsweiler]

On Mon, Jan 15, 2001 at 12:26:32PM +0100, Jean-Marc Lasgouttes wrote:
 We have something related in the INSTALL file, section "Problems":
 
   o Configure will seemingly fail to find xpm.h and forms.h on linux if
 you did a 'make mrproper' in the kernel directory, because this
 removes some symbolic links that are needed for compilation. A 'make
 symlinks' in linux kernel sources fixes that.
 
 However, having a header file which relies on kernel headers is a BUG
 in itself (according to Linus himself). You should probably find out
 which headers do that, and see whether an upgrade would be a proper
 cure.
 

Situation: /usr/src/linux is *not* existent (for reasons of space),
i.e. no kernel header files at all. The lyx configure script fails
with the error message "forms.h" not found. That message is false,
because the forms.h is found but the test code cannot be compiled
because of the missing kernel header files.
Reproducing /usr/src/linux form the .tar.gz and starting again the
configure works fine as lyx also does.
My idea is to put a *new test*  into the lyx configure script for just
testing the availability of the required kernel header
files. (Unfortunaltey I do not know which files exactly are relevant).
That is just a suggestion to improve the configure script. 

Frank

Re: Release LyX 1.1.6

[Jean-Marc Lasgouttes]

 "Frank" == Frank Derichsweiler [EMAIL PROTECTED] 
writes:

Frank Situation: /usr/src/linux is *not* existent (for reasons of
Frank space), i.e. no kernel header files at all. 

I understand that. I was just pointing out that the problems were
related and that we could probably change the description to fit your
problem (supposing people actually read INSTALL, of course ;).

Frank The lyx configure
Frank script fails with the error message "forms.h" not found. That
Frank message is false, because the forms.h is found but the test
Frank code cannot be compiled because of the missing kernel header
Frank files. 

Could you show us the relevant part of config.log? Before writing
configure test blindly, one has to know what header file decided that
it should have access to kernel headers.

JMarc

Re: Allan: follow up on build problems for Solaris

[Allan Rae]

On 15 Jan 2001, Jean-Marc Lasgouttes wrote:

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

   What's wrong with grep '_(".*")' ...

 Allan Aren't regular expressions like above a GNU extension for grep.
 Allan That's why I asked about egrep which I think (hope) is
 Allan "standard". You gotta love Unix, there are so many standards to
 Allan choose from.

 What part of the regexp is an extension according to you? The use of
 parenthesis?

I thought, perhaps mistakenly, that grep didn't do ".*" matching except in
GNU form.  Anyway as I said I didn't write this but figured someone, maybe
Lars, had a reason for using `grep -E` in the first place.

Just change it then and if someone screams we'll know better next time ;-)

Allan. (ARRae)

Re: fax support, dead keys and i18n (1.1.6)

[John Levon]

On Sat, 13 Jan 2001, Thorsten Mika wrote:

 1. why did you remove the fax support? is it that big? dont you feel like 
 putting an option in the configure script to give the opportunity to enable it  
 again? i really felt comfortable with it, using any other program or doing the 
 stuff by hand is (though i got to admit only a tiny little) drag. if not, where 
 do i have to remove comments to enable it again?

I think it was removed because the code was out of date, and there was no
one to update it ... I could be wrong though

 2. the dead keys work, but they are not displayed correctly on the screen. is 
 this my fault, fault of xfs, or libforms (0.89) problem?

pass

 3. i cant get the international menus to work (i am german, my LANG is set to 
 DE, the help docs are selected correctly, but the menus stay english)?
 

The i18n of menus apparently only works now after a "make install"

john

-- 
"Threads are for people who can't program state machines."
- Alan Cox

Re: ButtonController and ButtonPolicy

[Allan Rae]

On Mon, 15 Jan 2001, Angus Leeming wrote:

 Hello, Allan.

Hi Angus!

 Let me start with a justification of all this: I'd like to ease the pain of
 porting the dialogs to other GUIs by ensuring that they have only a minimum
 of things to do. We have occasional complaints from John and Marco about
 breaking their ports. Matthias Ettrich was rather more vocal. They are
 expressing a valid point. It's hard to keep up when the rules keep changing.

 Each dialog exists to change some variables. Nothing more. It should,
 therefore, be passed only those variables (preferably as a Param struct). It
 should also have access to functions linked to the four Apply, Ok, Cancel,
 Reset buttons. Nothing more.

 Everything else about the dialog, the signals it connects and disconnects to
 etc, should be controlled by a common Controller class. The GUIs need not
 worry about this. I've implemented this successfully.

 In the same way, we can define a subset of the ButtonController class that is
 GUI-I. The GUI View need know about only the BC::valid() method called when
 an input is made and in the xforms case, about methods passed an FL_OBJECT *.
 You've written the Controller beautifully (serious here) so that the
 BC::apply(), ok() etc buttons know nothing about the xforms implementation.

Okay, sounds reasonable.

 I have it all working here. A ButtonController base class and a
 FormButtonController derived class containing xforms-specific stuff. I have a

Please change the name from FormButtonController.  Only dialogs (or forms
in XForms speak) should be called FormXxxx.

 ControlledButtonDialog abstract class that has a ButtonController * and 4
 methods, ApplyButton(), OkButton, CancelButton() and RestoreButton() that
 does exactly as the static ApplyBC() etc used to do. All dialog-specific
 controllers can be derived from this.

 It looks and feels clean and elegant and MINIMAL. That means, it should be
 readily understandable to John, Marco, whoever wants to implement another GUI.

 If you want a look, just ask. Otherwise, I'll post when it's clean. I send
 enough junk to this list as-is!

I won't be able to look at it for two weeks at least so take your time and
get it really pretty.  Right now I gotta stop reading my email and get
this LDN finished so I can get some sleep tonight.

Allan. (ARRae)

Re: Release LyX 1.1.6

[John Levon]

On 15 Jan 2001, Jean-Marc Lasgouttes wrote:

 Could you show us the relevant part of config.log? Before writing
 configure test blindly, one has to know what header file decided that
 it should have access to kernel headers.
 
 JMarc

No, I think this is definitely a broken distribution, if it has symlinks
into /usr/src/linux, and the packaging system doesn't require
kernel-headers package for compilation.

As JMarc points out, these symlinks are officially deprecated anyway, and
in fact, most modern distributions don't have them.

So, this is NOT something LyX should care about. This is a distribution
problem (in that it didn't require kernel-headers as a dependency of
development headers, OR not need kernel-headers at all)

IMHO
john

-- 
"Threads are for people who can't program state machines."
- Alan Cox

Re: NEW_INSETS

[Lars Gullik Bjønnes]

John Levon [EMAIL PROTECTED] writes:

|  I know of only a couple of problems:
|  
|  - floats support are a bit lacking, specially algoritm will
|have problems.
| 
| does this also include the fact that getTocList() doesn't work (generating
| no contents for the dialog to read) ?
| 
| should I log it as a reminder bug ?

I'd rather you fixed it :-)

Lgb

Re: Allan: follow up on build problems for Solaris

[John Levon]

On Tue, 16 Jan 2001, Allan Rae wrote:

 On 15 Jan 2001, Jean-Marc Lasgouttes wrote:
 
   "Allan" == Allan Rae [EMAIL PROTECTED] writes:
 
  Allan I thought, perhaps mistakenly, that grep didn't do ".*"
  Allan matching except in GNU form. Anyway as I said I didn't write
  Allan this but figured someone, maybe Lars, had a reason for using
  Allan `grep -E` in the first place.
 
  You mean you thought grep did not do regular expressions? So, what
  does the 're' stand for?
 
 Sure but there are re's and re's.   * and .* may be different things
 depending on whos re-engine you are using.
 
 I thought egrep handled '.*' as grep handles '*'.  If they are in fact the
 same then WTF does egrep really do?
 
 Allan. (ARRae)

I thought the sole difference of egrep was '|', i.e. I can do :

egrep 'KERN|STACK' /usr/src/linux/include/linux/kernel.h

try it with normal grep, and '|' isn't a special character any more ...

john

-- 
"Threads are for people who can't program state machines."
- Alan Cox

Re: Allan: follow up on build problems for Solaris

[Jean-Marc Lasgouttes]

 "John" == John Levon [EMAIL PROTECTED] writes:

John try it with normal grep, and '|' isn't a special character any
John more ...

But \| is a special character.

JMarc

Re: Proposed LyXFunc reworking

[Lars Gullik Bjønnes]

John Levon [EMAIL PROTECTED] writes:

| o no longer is the various parts of a new function spread in four or five
|   different places. To add a new function means adding it to functions.C,
|   and (if necessary) a status tester to status_functions.C

but that is almost true today as well. To add a new lyxfund you add to
the enum in commandtags.h, add  an item in LyXAction.C and a case in
LyXFunc. Ecerything else is just to make thins easier or localized in
another way.

| o several files are auto-generated with a perl script. This helps
|   centralise the details of each lyxfunc

We we need autogeneration for that?
 
| o each lyxfunc has doxygen-style commentary (which is also interpreted to
|   generate the automatic files)
| 
| o lyxaction is gone, replaced with lf_container, which is a little more
|   container-y, and contains no special code for handling the functions (it
|   is basically a look-up facility)

Couln't much of what you do be done with added some more fields to the
LyXAction lfun_item?
(In your case a function pointer) 

| o each lyxfunction handles itself, include pseudo-action functions

I didn't see how you handled pseudo actions.
Can you explain.
 
| o there's no extra expensive lookup for static functions on dispatch

??
 
| I would appreciate any comments anyone has got. Is this workable or am I
| crazy ? How do people feel about auto-generating files ?

I don't like the auto-generation.

Also I feel you use pointer too much, but that should be a detail.
(you also pass objects by value, should be passed by const reference)


But: something like this is needed.

Lgb

Re: Proposed LyXFunc reworking

[Jean-Marc Lasgouttes]

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

Lars Couln't much of what you do be done with added some more fields
Lars to the LyXAction lfun_item? (In your case a function pointer)

That would probably be a good idea. One thing which would be nice too
is to declare the arguments expected by the func and maybe their type. 

What is nice however in John's scheme is that the
documentation/definition of the func is at the same place as its
implementation. It is helpful when tracing function.

Lars I don't like the auto-generation.

In this case the code in functions.C looks good and would give good
documentation. 

JMarc

Re: Proposed LyXFunc reworking

[John Levon]

On 15 Jan 2001, Lars Gullik Bjønnes wrote:

 John Levon [EMAIL PROTECTED] writes:
 
 | o no longer is the various parts of a new function spread in four or five
 |   different places. To add a new function means adding it to functions.C,
 |   and (if necessary) a status tester to status_functions.C
 
 but that is almost true today as well. To add a new lyxfund you add to
 the enum in commandtags.h, add  an item in LyXAction.C and a case in
 LyXFunc.

exactly ! It is *much* nicer to have it all in exactly one place IMHO

 Ecerything else is just to make thins easier or localized in
 another way.

could you expand ?

 | o several files are auto-generated with a perl script. This helps
 |   centralise the details of each lyxfunc
 
 We we need autogeneration for that?

at the very least, without auto generation, you need :

1 place for the commandtag (commandtags.h)
1 place for the invoke method (lyxfunc.C)
1 place for the instantiation of the lyxfunc (LyXAction.C)

I don't see how these can be centralised into a single file (+ header
file) w/o auto-gen

 Couln't much of what you do be done with added some more fields to the
 LyXAction lfun_item?
 (In your case a function pointer) 

sure, if you think lfun_item items[] is readable (I don't). And also this
requires me to manually split up the Dispatch() switch, and then add the
various bits in the right place in items[]. No thanks ...

 I didn't see how you handled pseudo actions.
 Can you explain.

This is the vague part (I only spent a short while messing with this). I
think what happens is that the code creating the pseudo-action
(i.e. similar to existing getPseudoAction()) will ask the lf_container
addAction(), which will instantiate a newly create lyxfunction object. The
lyxfunction is generated and the real action + its argument is stored
inside that lyxfunction (see second lyxfunction c-tor).

At invoke time, the operator() will pick up the real action + argument,
and invoke that instead.

Access to the pseudo action is vi lf_container maps.

 | o there's no extra expensive lookup for static functions on dispatch
 
 ??

... I mean as in the old code. e.g. LFUN_RIGHT dispatch is just an array
offset rather than some map lookup or something. This needs to be as fast
as possible, right ?

 Also I feel you use pointer too much, but that should be a detail.
 (you also pass objects by value, should be passed by const reference)

yes, all the C++ good practice stuff should be shaken out if the code gets
worked out

thanks
john

-- 
"Threads are for people who can't program state machines."
- Alan Cox

Re: Proposed LyXFunc reworking

[John Levon]

On 15 Jan 2001, Jean-Marc Lasgouttes wrote:

 That would probably be a good idea. One thing which would be nice too
 is to declare the arguments expected by the func and maybe their type. 

Any suggestions on how this might work ?

thanks
john

-- 
"Threads are for people who can't program state machines."
- Alan Cox

Website links

[Andre Ulrich]

Hej LyX Team!

There is no link working on the LyX homepage. Neither the announcement nor 
the File is accessable. The whole ftp tree seems to be broken(only unrelated 
stuff on it).

Cant wait to try out the new Jpeg and PNG import :)

Regards

Andre

Re: Proposed LyXFunc reworking

[Jean-Marc Lasgouttes]

 "John" == John Levon [EMAIL PROTECTED] writes:

John On 15 Jan 2001, Jean-Marc Lasgouttes wrote:
 That would probably be a good idea. One thing which would be nice
 too is to declare the arguments expected by the func and maybe
 their type.

John Any suggestions on how this might work ?

Maybe something based on signals and templates? Would sigc++ be useful
in this case? Really, I do not know. My knowledge of C++ is too weak
when it comes to that.

JMarc

Re: Website links

[Jean-Marc Lasgouttes]

 "Andre" == Andre Ulrich [EMAIL PROTECTED] writes:

Andre Hej LyX Team! There is no link working on the LyX homepage.
Andre Neither the announcement nor the File is accessable. The whole
Andre ftp tree seems to be broken(only unrelated stuff on it).

Yes, it seems that the ftp site is down. You can try
ftp.devel.lyx.org/pub/lyx instead.

Lars, the announce/ directory has not been created on the web site (I
looked on aussie in /home/httpd/html/lyx-user). Can you do something
about it?

JMarc

Re: Proposed LyXFunc reworking

[Andre Poenitz]

 at the very least, without auto generation, you need :
 
 1 place for the commandtag (commandtags.h)
 1 place for the invoke method (lyxfunc.C)
 1 place for the instantiation of the lyxfunc (LyXAction.C)

What about nuking the commandtags and putting everything in a
std::mapstring, whatever, where the index is the (first word of)
the command?

Comparing strings instead numbers should cost only a constant factor of
time more than comparing enums, starting off from a very tiny amount.
Morover, lookup in the map is O(ln n) compared to O(n) in the
big case scwitch. So it shold not really be noticable.

The "big loss" is "type safety": We don't notice at compile time a
misspelled command. OTOH at some time we might wish to dynamically 
extend lyx - say by a newly installed converter - without quitting the
current work. In this case the infrastructure would be in place already.

I have a similar scheme working in my current project: There everything is
pretty modular and I can get different versions off the program simply by
linking different sets of modules. Every modul has a global static object
which registers on construction the modules' commands with a big
central dispatcher (basically a mapstring, command).

Dependencies are basically resolved by the linker and the dynamic loader.
Upon entrace of main() the central dispatcher knows exactly the commands of
the available modules without the need to query them individually.

I don't have any performance problems in this corner of the program.

Andre'

-- 
Andr Pnitz  [EMAIL PROTECTED]

Re: Proposed LyXFunc reworking

[John Levon]

On Mon, 15 Jan 2001, Andre Poenitz wrote:

  at the very least, without auto generation, you need :
  
  1 place for the commandtag (commandtags.h)
  1 place for the invoke method (lyxfunc.C)
  1 place for the instantiation of the lyxfunc (LyXAction.C)
 
 What about nuking the commandtags and putting everything in a
 std::mapstring, whatever, where the index is the (first word of)
 the command?
 
 Comparing strings instead numbers should cost only a constant factor of
 time more than comparing enums, starting off from a very tiny amount.
 Morover, lookup in the map is O(ln n) compared to O(n) in the
 big case scwitch. So it shold not really be noticable.

you are forgetting the constants of the complexity equation. I bet the
compiler does a better job of the case() { } construct than it does of the
STL header code. (Of course, this argument is pointless w/o measurement to
back it up). And I don't see any real purpose to removing the array-based
approach ?

 The "big loss" is "type safety": We don't notice at compile time a
 misspelled command. OTOH at some time we might wish to dynamically 
 extend lyx - say by a newly installed converter - without quitting the
 current work. In this case the infrastructure would be in place already.

would we really ever want to do this ? I don't see a good reason to lose
compile-time type safety, and this doesn't really help at all in terms of
readability of each function. Think about how we would add the author's
name and creation date, detailed usage instructions for the developer etc.

In my proposed scheme this all comes "for free" (with some nice doxygen
documentation to go along with it).

john

-- 
"Threads are for people who can't program state machines."
- Alan Cox

Re: Proposed LyXFunc reworking

[Lars Gullik Bjønnes]

John Levon [EMAIL PROTECTED] writes:

| On 15 Jan 2001, Lars Gullik Bjnnes wrote:
| 
|  John Levon [EMAIL PROTECTED] writes:
|  
|  | o no longer is the various parts of a new function spread in four or five
|  |   different places. To add a new function means adding it to functions.C,
|  |   and (if necessary) a status tester to status_functions.C
|  
|  but that is almost true today as well. To add a new lyxfund you add to
|  the enum in commandtags.h, add  an item in LyXAction.C and a case in
|  LyXFunc.
| 
| exactly ! It is *much* nicer to have it all in exactly one place
| IMHO

mmm, and I am not sure that I agree completely... I had one thing
planned: get rid of LFUN and the commandtags, and just use strings instead.

I also planned on adding a register method to LyXAction or LyXFunc to
that lyxfunc could register themselves.

(this would also open up for dynamic creations fo lyxfunc through
script language or dynamic loaded functions)


namespace LFUN {
bool insert_string(lyxfunc  lf) {
// do the stuff
}
}

lyxfunc.register("insert-string", LFUN::insert_string, NEEDS_BUFFER);

lyxfunc.register_pseudo("insert-666", "insert-string", "666");


lyxfunc.dispatch("insert-666");

| could you expand ?
| 
|  | o several files are auto-generated with a perl script. This helps
|  |   centralise the details of each lyxfunc
|  
|  We we need autogeneration for that?
| 
| at the very least, without auto generation, you need :
| 
| 1 place for the commandtag (commandtags.h)

we can probalby drop the command tags.

| 1 place for the invoke method (lyxfunc.C)

this can be generic and needs to be written only once.

| 1 place for the instantiation of the lyxfunc (LyXAction.C)

multiple places... if wanted or all in the same location.

| I don't see how these can be centralised into a single file (+ header
| file) w/o auto-gen

I think it is doable.

|  Couln't much of what you do be done with added some more fields to the
|  LyXAction lfun_item?
|  (In your case a function pointer) 
| 
| sure, if you think lfun_item items[] is readable (I don't). And also this
| requires me to manually split up the Dispatch() switch, and then add the
| various bits in the right place in items[]. No thanks ...

Note that lfun_item items[] is the way it is to speed up
initialization.

|  I didn't see how you handled pseudo actions.
|  Can you explain.
| 
| This is the vague part (I only spent a short while messing with this). I
| think what happens is that the code creating the pseudo-action
| (i.e. similar to existing getPseudoAction()) will ask the lf_container
| addAction(), which will instantiate a newly create lyxfunction object. The
| lyxfunction is generated and the real action + its argument is stored
| inside that lyxfunction (see second lyxfunction c-tor).

Yes. A wrapper around he real func + arg.


| 
|  | o there's no extra expensive lookup for static functions on dispatch
|  
|  ??
| 
| ... I mean as in the old code. e.g. LFUN_RIGHT dispatch is just an array
| offset rather than some map lookup or something. This needs to be as fast
| as possible, right ?

Well in a way yes, but _speed_ should /not/ be our main concern, clear
and easy to follow code should.
 
|  Also I feel you use pointer too much, but that should be a detail.
|  (you also pass objects by value, should be passed by const reference)
| 
| yes, all the C++ good practice stuff should be shaken out if the code gets
| worked out

You really should go to the boost site (www.boost.org) and see if you
can find anything usefull there.

Lgb

Re: Proposed LyXFunc reworking

[Jean-Marc Lasgouttes]

 "John" == John Levon [EMAIL PROTECTED] writes:

John how do strings fit in with the frontend menus ? Must I really
John have some extra store of integers (the menu ID tags from the GUI
John library) to strings ?

The functions could be allocated a number when they are registered, or
something like that [although I kind of prefer your scheme]

JMarc

Re: Proposed LyXFunc reworking

[Andre Poenitz]

  the command?
  
  Comparing strings instead numbers should cost only a constant factor of
  time more than comparing enums, starting off from a very tiny amount.
  Morover, lookup in the map is O(ln n) compared to O(n) in the
  big case scwitch. So it shold not really be noticable.
 
 you are forgetting the constants of the complexity equation.

No. I am not. First of all I mentiond the existence of a constant factor
and second, it does not matter. Even if the factor was 1000.

How many lyx-functions are called per second? 1000? Likely less.
Now, how long take 1000 string lookups in a map with 100 entries? 
Relate this to the work done by a complete table-redraw.

Got it? ;-)

 And I don't see any real purpose to removing the array-based approach ?

Code decoupling. LyX still takes ages to compile even after tiny changes.
 
 would we really ever want to do this ?

Why not? Most larger apps come with dynamically lodable modules.
I don't see any reason e.g. to carry all SGML stuff in a monolithic binary
if I don't need it most of the time.

 I don't see a good reason to lose
 compile-time type safety, and this doesn't really help at all in terms of
 readability of each function.

Could you explain that? The function tags will go away entirely.
The commands are pretty invisible to "user code".

 Think about how we would add the author's
 name and creation date, detailed usage instructions for the developer etc.

The creation date of the lyxfunc? You lost me.

Andre'

-- 
Andr Pnitz  [EMAIL PROTECTED]

Re: Proposed LyXFunc reworking

[John Levon]

On 15 Jan 2001, Jean-Marc Lasgouttes wrote:

  "John" == John Levon [EMAIL PROTECTED] writes:
 
 John how do strings fit in with the frontend menus ? Must I really
 John have some extra store of integers (the menu ID tags from the GUI
 John library) to strings ?
 
 The functions could be allocated a number when they are registered, or
 something like that [although I kind of prefer your scheme]
 
 JMarc

But the communication between the frontends and the kernel would still be
in terms of integers (otherwise I would have to lookup by integer, to get
a string, to do the Dispatch()).

IOW, it just doubles up the "naming scheme" for functions to little or no
benefit AFAICS. Note that the auto-gen source I wrote has a trivial thing
to allow lyx functions to be accessible by name (see the command name
thing, generated as "LFUN_MENU_OPEN" in the c-tors in auto-init.C).

But it is obviously not gaining favour as an approach, so...

john



-- 
"Threads are for people who can't program state machines."
- Alan Cox

Re: Proposed LyXFunc reworking

[John Levon]

On Mon, 15 Jan 2001, Andre Poenitz wrote:

 No. I am not. First of all I mentiond the existence of a constant factor
 and second, it does not matter. Even if the factor was 1000.
 
 How many lyx-functions are called per second? 1000? Likely less.
 Now, how long take 1000 string lookups in a map with 100 entries? 
 Relate this to the work done by a complete table-redraw.

make that 250+ entries, but yes, maybe it's OK performance-wise (although
picking something as slow as table redraw is cheating :)

 Code decoupling. LyX still takes ages to compile even after tiny changes.

I'd rather wait longer and have less bugs ;)

 Why not? Most larger apps come with dynamically lodable modules.
 I don't see any reason e.g. to carry all SGML stuff in a monolithic binary
 if I don't need it most of the time.

yep OK.

 The creation date of the lyxfunc? You lost me.

see the user names and dates in commandtags.h

john

-- 
"Threads are for people who can't program state machines."
- Alan Cox

Re: Proposed LyXFunc reworking

[Andre Poenitz]

 John Levon [EMAIL PROTECTED] writes:
 
 | On 15 Jan 2001, Jean-Marc Lasgouttes wrote:
 | 
 |  That would probably be a good idea. One thing which would be nice too
 |  is to declare the arguments expected by the func and maybe their type. 
 | 
 | Any suggestions on how this might work ?
 
 
 for one arg LFUN (all LFUN's return what? bool?)

A lyxfunc could take a stream argument from which it reads the actual
arguments. Most commands are passed around as strings anyway so it makes no
difference where it is converted to int/double/whatwever.

If anything goes wrong, it simply throws. The dispatcher
catches and reports the problem. To the Gui, if available. To cerr, if not.

The lyxfunc itself can be pretty dumb concernig error handling.

If there really was a performance problem (which I seriously doubt) the
lyxfunc could come as a "core" function taking the correct arguments and a
wrapper, that reads the stream and feeds the core function. Other core
functions could use the "fast" interface.

Andre'


-- 
Andr Pnitz  [EMAIL PROTECTED]

Re: fax support, dead keys and i18n (1.1.6)

[Jean-Marc Lasgouttes]

 "Thorsten" == Thorsten Mika [EMAIL PROTECTED] writes:

Thorsten 1. why did you remove the fax support? is it that big? dont
Thorsten you feel like putting an option in the configure script to
Thorsten give the opportunity to enable it again? i really felt
Thorsten comfortable with it, using any other program or doing the
Thorsten stuff by hand is (though i got to admit only a tiny little)
Thorsten drag. if not, where do i have to remove comments to enable
Thorsten it again? 

It is currently only disabled (I think). Sending faxes is not LyX's
job (why not something for sending as e-mail) and is better done from
an external application (the unix philosophy: "one tool one job" or
whatever). Actually, somebody could probably take the old code and
make it compile as a standalone application and have exactly the same
functionnality. If we do not build a dvi viewer into LyX, we have no
reason to built-in a fax sending program (OK, this is not a fair
comment, I do not need fax :). By installing a _real_ fax frontend,
you will have much better functionality, and LyX code will become
cleaner (which is really needed).

Thorsten 2. the dead keys work, but they are not displayed
Thorsten correctly on the screen. is this my fault, fault of xfs, or
Thorsten libforms (0.89) problem? 

As far as I know, the dead keys done via keymaps do not work at all.
This needs fixing soon.

Thorsten 3. i cant get the international
Thorsten menus to work (i am german, my LANG is set to DE, the help
Thorsten docs are selected correctly, but the menus stay english)?

Did you install LyX?

JMarc

Re: Proposed LyXFunc reworking

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

|  "John" == John Levon [EMAIL PROTECTED] writes:
| 
| John how do strings fit in with the frontend menus ? Must I really
| John have some extra store of integers (the menu ID tags from the GUI
| John library) to strings ?
| 
| The functions could be allocated a number when they are registered, or
| something like that [although I kind of prefer your scheme]

My problem with Levons code that I feel it is too static. With the
scheme Andre and I propose it is very easy to load function os demand
or have them created in a scriptlanguage. (or as a named keyboard macro).

This is probably possible with Levons scheme as well...but...

Lgb

Re: Proposed LyXFunc reworking

[Jean-Marc Lasgouttes]

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

Lars My problem with Levons code that I feel it is too static. With
Lars the scheme Andre and I propose it is very easy to load function
Lars os demand or have them created in a scriptlanguage. (or as a
Lars named keyboard macro).

Then we should come up with a scheme which makes documentation and
debugging as easy as what John proposes. Let's face it: the current
scheme is awful debugging-wise. Every time I need to find a function
do-foo, I go in lyxaction to find what the LFUN name is (of course, it
is LFUN_BAR, not LFUN_FOO), then go in LyXFunc where there is only a
small wrapper around something which is somewhere else...

One could mostly try to auto-generate a reference manual from a format
similar to what John proposes.

JMarc

Re: Proposed LyXFunc reworking

[John Levon]

On 15 Jan 2001, Lars Gullik Bjønnes wrote:

 My problem with Levons code that I feel it is too static. With the
 scheme Andre and I propose it is very easy to load function os demand
 or have them created in a scriptlanguage. (or as a named keyboard macro).
 
 This is probably possible with Levons scheme as well...but...
 
 Lgb

sure it is, that's what the lyxfunction constructor is for ! Just add
another add() method to lf_container for non-pseudo-action functions (and
maybe the special casing of functions  LFUN_LAST_STATIC should go, and
just use a container).

You can have dynamically-numbered functions, you can reference them by
string name, etc. still. It's trivial in fact.

But I am clearly on the losing side of a battle here, so I think I'll move
on ;)

thanks
john

-- 
"Threads are for people who can't program state machines."
- Alan Cox

Re: Proposed LyXFunc reworking

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

|  "Lars" == Lars Gullik Bjnnes [EMAIL PROTECTED] writes:
| 
| Lars My problem with Levons code that I feel it is too static. With
| Lars the scheme Andre and I propose it is very easy to load function
| Lars os demand or have them created in a scriptlanguage. (or as a
| Lars named keyboard macro).
| 
| Then we should come up with a scheme which makes documentation and
| debugging as easy as what John proposes. Let's face it: the current
| scheme is awful debugging-wise. Every time I need to find a function
| do-foo, I go in lyxaction to find what the LFUN name is (of course, it
| is LFUN_BAR, not LFUN_FOO), then go in LyXFunc where there is only a
| small wrapper around something which is somewhere else...
| 
| One could mostly try to auto-generate a reference manual from a format
| similar to what John proposes.

I think that can be just as easily don in the scheme I propose.

Each LFUN is a function Levon and I agree on that, afaisi we disagree
on how to store the LFUNS and how to dispatch them.

Lgb

Re: Proposed LyXFunc reworking

[John Levon]

On 15 Jan 2001, Lars Gullik Bjønnes wrote:

 Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
 
 |  "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
 | 
 | Lars My problem with Levons code that I feel it is too static. With
 | Lars the scheme Andre and I propose it is very easy to load function
 | Lars os demand or have them created in a scriptlanguage. (or as a
 | Lars named keyboard macro).
 | 
 | Then we should come up with a scheme which makes documentation and
 | debugging as easy as what John proposes. Let's face it: the current
 | scheme is awful debugging-wise. Every time I need to find a function
 | do-foo, I go in lyxaction to find what the LFUN name is (of course, it
 | is LFUN_BAR, not LFUN_FOO), then go in LyXFunc where there is only a
 | small wrapper around something which is somewhere else...
 | 
 | One could mostly try to auto-generate a reference manual from a format
 | similar to what John proposes.
 
 I think that can be just as easily don in the scheme I propose.
 
 Each LFUN is a function Levon and I agree on that, afaisi we disagree
 on how to store the LFUNS and how to dispatch them.
 
 Lgb

I don't even disagree on that !

Dispatch("menu-open eric-bristow") is perfectly possible in my
proposal. If you want it like that, fine (but you will have to solve the
frontend menu case as I mentioned - what is your suggestion here).

Rather it seems the disagreement is you don't like auto-generation,
whereas I consider it necessary for debugging and documentation [1]
purposes.

I'm not sure where the disagreement on the storage system is though ?

thanks
john

p.s. my name is John ...

[1] and not just developer docs, as JMarc points out

-- 
"Threads are for people who can't program state machines."
- Alan Cox

Re: Proposed LyXFunc reworking

[Andre Poenitz]

 | A lyxfunc could take a stream argument from which it reads the actual
 | arguments. Most commands are passed around as strings anyway so it makes no
 | difference where it is converted to int/double/whatwever.
 
 I'd rather have the real lyxfunc the the correct paramters from the
 beginning, and have a wrapper that create those argumetns from the
 supplied stream.

Unless the lyxfunc is called from a tight loop (say, a millisecond per
iteration) or in used in many places where the correct parameters are
known, the version with proper parameters is not really needed. 

And the stream version offers a pretty uniform interface that can hide
the implementation almost completely. With templates this is a bit
trickier, at least until compilers implement "export" or if we want to
support an arbitrary number of arguments.

Anyway: I have no strong feelings on what should be the "primary" or
"secondary" interface, as long as it is easy to use and uniform. I am just
saying that the stream interface works in a similar setting very well,
better than everything I tried before. I tried, however, not something 
closely resembling your templatized version.

Andre'

-- 
Andr Pnitz  [EMAIL PROTECTED]

Re: Proposed LyXFunc reworking

[Lars Gullik Bjønnes]

John Levon [EMAIL PROTECTED] writes:

| On 15 Jan 2001, Lars Gullik Bjnnes wrote:
| 
|  My problem with Levons code that I feel it is too static. With the
|  scheme Andre and I propose it is very easy to load function os demand
|  or have them created in a scriptlanguage. (or as a named keyboard macro).
|  
|  This is probably possible with Levons scheme as well...but...
|  
|  Lgb
| 
| sure it is, that's what the lyxfunction constructor is for ! Just add
| another add() method to lf_container for non-pseudo-action functions (and
| maybe the special casing of functions  LFUN_LAST_STATIC should go, and
| just use a container).

I would have wanted this as a container anyway...

| You can have dynamically-numbered functions, you can reference them by
| string name, etc. still. It's trivial in fact.

but this would be the case for the string based approach also I think.
 
| But I am clearly on the losing side of a battle here, so I think I'll move
| on ;)

Let's not kill this discussion too soon. I am open to arguments.

Lgb

Re: Proposed LyXFunc reworking

[Andre Poenitz]

 I'd rather have the real lyxfunc the the correct paramters from the
 beginning, and have a wrapper that create those argumetns from the
 supplied stream.
  ...
 | If there really was a performance problem (which I seriously doubt) the
 | lyxfunc could come as a "core" function taking the correct arguments and a
 | wrapper, that reads the stream and feeds the core function. Other core
 | functions could use the "fast" interface.
 

Forget my last mail. I am just a bit slow. Currently I think we mean
exactly the same kind of architecture.

Andre'

-- 
Andr Pnitz  [EMAIL PROTECTED]

Re: Release LyX 1.1.6

[Garst R. Reese]

Jean-Marc Lasgouttes wrote:
 
  "Frank" == Frank Derichsweiler 
[EMAIL PROTECTED] writes:
 
 Frank On Mon, Jan 15, 2001 at 04:01:31PM +0900, R. Lahaye wrote:
  Date: Mon, 15 Jan 2001 16:01:31 +0900 From: "R. Lahaye"
  [EMAIL PROTECTED] To: Frank Derichsweiler
  [EMAIL PROTECTED] CC:
  [EMAIL PROTECTED] Subject: Re: Release LyX 1.1.6
 
  Frank Derichsweiler wrote:  A little problem within a linux
  environment: Having no kernel header  files (within
  /usr/src/linux) the configure script runs and produces  the error
  forms.h not found, which is IMHO misleading. Perhaps the 
  configure can be adopted to check for the kernel include files 
  separatly.
 
  forms.h is part of the development package of xforms, the one you
  need when compiling LyX yourself.
 
 Frank Yes, I know that. To me a little bit clearer: I installed the
 Frank xforms development stuff and all the other necessary libs and
 Frank headers. Only the linux *kernel* headers were missing.
 
 We have something related in the INSTALL file, section "Problems":
 
   o Configure will seemingly fail to find xpm.h and forms.h on linux if
 you did a 'make mrproper' in the kernel directory, because this
 removes some symbolic links that are needed for compilation. A 'make
 symlinks' in linux kernel sources fixes that.
 
 However, having a header file which relies on kernel headers is a BUG
 in itself (according to Linus himself). You should probably find out
 which headers do that, and see whether an upgrade would be a proper
 cure.
 
 JMarc
The problem comes from signal.h and bits/sigcontext.h. There is an
include asm/signal.h
This dependancy was just recently introduced--I think in FormButton
something.

It is true that most dists do not have symbolic links, but they get
around this by copying those headers to /usr/include/asm so that you
have the kernel headers that libc was compiled with. If you compile a
new libc, as I am going to do today, you need to do something like cp -a
/usr/src/linux/include/asm /usr/include/asm or risk having a new kernel
screw up your libc installation.
And yes, when lyx encounters this problem is says that xforms.h is
missing.
Garst

Re: Proposed LyXFunc reworking

[Lars Gullik Bjønnes]

John Levon [EMAIL PROTECTED] writes:


|  Each LFUN is a function Levon and I agree on that, afaisi we disagree
|  on how to store the LFUNS and how to dispatch them.
|  
|  Lgb
| 
| I don't even disagree on that !

very well
 
| Dispatch("menu-open eric-bristow") is perfectly possible in my
| proposal. If you want it like that, fine (but you will have to solve the
| frontend menu case as I mentioned - what is your suggestion here).

You want an unique number for each LFUN (dynamic from each run of Lyx
of course)?

This can easily be done by having a separate method for this. From the
menu code you ask for a "LFUN" number and you can use that to
access/dispatch the LFUN later.

This will also mean that we only store as many number as there will be
different requests for the "LFUN"s. (Not something I care a lot
about). (we store this in a vector f.ex. that contains iterators into
the real LFUN map.) (actually by this you get O(1) access to numbered
LFUNs.)

Access by LFUN name and you get O(ln) access.

How is it done now? We read a ui file that has the LFUN's as strings
 
| Rather it seems the disagreement is you don't like auto-generation,
| whereas I consider it necessary for debugging and documentation [1]
| purposes.

Oh, autogeneration of documentation is ok, but now of source files (I
even have problems with .fd and .moc :-), but I won't object to those)
 
| I'm not sure where the disagreement on the storage system is though ?

Perhaps we really agree.

| john
| 
| p.s. my name is John ...

Sorry.
(Levon is just easier to remember)

| [1] and not just developer docs, as JMarc points out

I am well aware of this, and this has been in the plan from when we
decided that the LyXFunc needed a rework.

Lgb

new lyxfunc

[John Levon]

OK, in fact I think we agree on almost everything. Let me try and
summarise a little :

1) everyone agrees that each lyxfunction should look after itself. This
   includes pseudo-actions, which should be able to invoke their real
   action *themselves*

2) everyone agrees there is a need for some object to contain every
lyxfunction, and provide various methods of looking it up

3) Lars and Andre argue for a string-based lookup. This shouldn't cause
any performance problems, and has the advantage of making
dynamically-added lyxfunctions easier. I agree, after consideration, that
string-based lookup as the primary method is good

4) There needs to be some way to deal with the frontend menus. These are
integer-based. There are only two options here :

i) each frontend has a container mapping from integer values to
   strings, used on dispatch

ii) each lyxfunctions is assigned an integer ID, and the ability
to lookup in the container by ID is added.

Lars must be suggesting option i). This has the disadvantage that
similar management code must be replicated in each frontend, and
there needs to be logic for handling pseudo-actions etc. Why not
just centralise this code (and keep the data close to the object
!) by letting each lyxfunction know about its own numeric ID in
the kernel code ? This *doesn't* mean any code other than the
frontend/ code would use numeric lookup method.

5) Lars doesn't like the idea of generated code. John does ;) because

   a) centralisation of all aspects of a lyxfunction. Lars previously
  stated this wasn't of much concern to him, but I *definitely* agree
  with JMarc that jumping all over the place when debugging is a pain
  (along with hoping to increase my understanding of the lyx code,
  this is my major motivation of the re-working).

   b) the array in LyXAction.C does not give scope for adding
  documentation, in an easy and readable way. The separation of the
  method code (currently in the LyXFunc.C switch) from the lyxfunction
  properties is a BAD thing.

   c) Reference.lyx. 'Nuff said.

   d) doxygen output. Oh I would like a developer's description of what
  each LyXFunction does. Keeping it in the new functions.C would be
  very nice

   e) some other things I've forgotten


Comments ?

thanks
john



-- 
"Threads are for people who can't program state machines."
- Alan Cox

Re: Proposed LyXFunc reworking

[John Levon]

argh, I've just sent a summary. I'll address the additional things below
here.

On 15 Jan 2001, Lars Gullik Bjønnes wrote:

 You want an unique number for each LFUN (dynamic from each run of Lyx
 of course)?
 
 This can easily be done by having a separate method for this. From the
 menu code you ask for a "LFUN" number and you can use that to
 access/dispatch the LFUN later.
 
 This will also mean that we only store as many number as there will be
 different requests for the "LFUN"s. (Not something I care a lot
 about). (we store this in a vector f.ex. that contains iterators into
 the real LFUN map.) (actually by this you get O(1) access to numbered
 LFUNs.)

This is very very close to what I'm suggesting anyway. I could live with
this approach (the crucial thing is allowing integer-based Dispatch
lookup). Ok, so the enum is dead.

 Oh, autogeneration of documentation is ok, but now of source files (I
 even have problems with .fd and .moc :-), but I won't object to those)

yikes !

 Perhaps we really agree.

most of it I think

 (Levon is just easier to remember)

no problem :)

 I am well aware of this, and this has been in the plan from when we
 decided that the LyXFunc needed a rework.

ok

thanks
john

-- 
"Threads are for people who can't program state machines."
- Alan Cox

Re: new lyxfunc

[Allan Rae]

On Mon, 15 Jan 2001, John Levon wrote:

 5) Lars doesn't like the idea of generated code. John does ;) because

So do I.  Running around between the three or four files is a pain in the
fingers.  Is it Friday yet?  It feels like Friday.

If you use m4 for this then we won't be adding yet another requirement
since we already use it for sigc++.  And it does avery good job there.

 Comments ?

I've been awake for the whole thing but not read a single email in the
thread yet.  I guess you can add me as another of those "everyone is in
agreement" though based on your summary.

Allan. (ARRae)

P.S. Good night sweet dreams.

Re: new lyxfunc

[Lars Gullik Bjønnes]

John Levon [EMAIL PROTECTED] writes:

| OK, in fact I think we agree on almost everything. Let me try and
| summarise a little :

:-)
 
| 1) everyone agrees that each lyxfunction should look after itself. This
|includes pseudo-actions, which should be able to invoke their real
|action *themselves*

I am not quite sure what you mean with "should look after itself".
 
| 2) everyone agrees there is a need for some object to contain every
| lyxfunction, and provide various methods of looking it up

Yes, a std::map would be my choice.
 
| 3) Lars and Andre argue for a string-based lookup. This shouldn't cause
| any performance problems, and has the advantage of making
| dynamically-added lyxfunctions easier. I agree, after consideration, that
| string-based lookup as the primary method is good

jupp
 
| 4) There needs to be some way to deal with the frontend menus. These are
| integer-based. There are only two options here :
| 
|   i) each frontend has a container mapping from integer values to
|strings, used on dispatch
| 
| ii) each lyxfunctions is assigned an integer ID, and the ability
|   to lookup in the container by ID is added.
| 
| Lars must be suggesting option i).

No, nor really. Closer to ii).

The problem with ii) as I read it is O(n), and we can easily make this
O(1) by having a second container with pointer (iterators) into the
real functionmap. This alos means that the func number is not stored
explicitly anywere.

[some snip]

| 5) Lars doesn't like the idea of generated code. John does ;) because
| 
|a) centralisation of all aspects of a lyxfunction. Lars previously
|   stated this wasn't of much concern to him, but I *definitely* agree
|   with JMarc that jumping all over the place when debugging is a pain
|   (along with hoping to increase my understanding of the lyx code,
|   this is my major motivation of the re-working).

oh, I agree with both you and JM on this.

|b) the array in LyXAction.C does not give scope for adding
|   documentation, in an easy and readable way. The separation of the
|   method code (currently in the LyXFunc.C switch) from the lyxfunction
|   properties is a BAD thing.

the LyXAction aray will go, regardsless of the, but will perhaps be
replaced by a new array :-)

|c) Reference.lyx. 'Nuff said.

agree
 
|d) doxygen output. Oh I would like a developer's description of what
|   each LyXFunction does. Keeping it in the new functions.C would be
|   very nice

but this has certainly nothing to do with autogeneration of files.
 
|e) some other things I've forgotten

I think the only issue now is how to register LFUNs in LyXFunc.

| Comments ?

You, got them.

Lgb

Support for multline/align (patch)

[Dekel Tsur]

The following patch adds support for the ams environments multline and align.
Currently, only align with one alignment point is supported, but
this should be hard to change.
To add an align/multline, insert a display formula, and do 'M-x break-line 1'
or 'M-x break-line 2'.
Please check if the changes I made doesn't break anything.

 patch.gz

Re: Support for multline/align (patch)

[Dekel Tsur]

On Mon, Jan 15, 2001 at 11:13:32PM +0200, Dekel Tsur wrote:
 The following patch adds support for the ams environments multline and align.
 Currently, only align with one alignment point is supported, but
 this should be hard to change.
   ^^
I meant should NOT ...

paragraph alignment in 1.1.6

[Herbert Voss]

maybe that this also happens in 1.1.5 ...
when i define a lyx layout with a strict flushright

...
  Align Right
  AlignPossible Right
...

lyx should also inactivate the radio buttons in
layout-paragraph-alignment

it's right, that nothing happens, when you click on
the left alignment-button, the text is always flush
right, in lyx and in dvi, too. if it's possible and
not too much work, it's a good thing when the alignment
buttons corresponds to the given lyx-layout.

Herbert

--
[EMAIL PROTECTED]
http://perce.de/lyx/

Re: fax support, dead keys and i18n (1.1.6)

[Thorsten Mika]

hi, jean-marc

 
 It is currently only disabled (I think). Sending faxes is not LyX's
 job (why not something for sending as e-mail) and is better done from
 an external application (the unix philosophy: "one tool one job" or
 whatever). Actually, somebody could probably take the old code and
 make it compile as a standalone application and have exactly the same
 functionnality. If we do not build a dvi viewer into LyX, we have no
 reason to built-in a fax sending program (OK, this is not a fair
 comment, I do not need fax :). By installing a _real_ fax frontend,
 you will have much better functionality, and LyX code will become
 cleaner (which is really needed).

oh yes, i mean i was aware of efax doing the job. i just liked he phonebook 
function. meanwhile i found a way that was discusse earlier in the list, by a 
small python script and using the format converters. but i still miss the 
phonebook...

 
 Thorsten 2. the dead keys work, but they are not displayed
 Thorsten correctly on the screen. is this my fault, fault of xfs, or
 Thorsten libforms (0.89) problem? 
 
 As far as I know, the dead keys done via keymaps do not work at all.
 This needs fixing soon.

i do not use a keymap. i see the acute and the grave, but they are strangely 
enough in the middle of the line (vertical) and not above the rest...any other 
idea?

 
 Thorsten 3. i cant get the international
 Thorsten menus to work (i am german, my LANG is set to DE, the help
 Thorsten docs are selected correctly, but the menus stay english)?
 
 Did you install LyX?
 
 JMarc

sorry, i was too dumb. i found my mistake yesterday :)

thx,

thorsten

Thorsten Mika   mailto:[EMAIL PROTECTED]
Hamm / GermanyTM5173-RIPE

Ordering the Layout list alphabetically.

[R. Lahaye]

Hi,

The layout list in the toolbar (Standard, Itemize, Numerize ...)
is getting longer and longer. I'm continuesly searching for the
item I need.

I would suggest to have the list ordered alphabetically; maybe
"Standard" can stay at the top, but the rest would be better
organized if it was in alphabetical order.

Rob.

no textclasses found

[Garst R. Reese]

I seem to have bungled something up. When 1.2.0cvs did not work for me,
I downloaded 1.1.6 and I cannot get it to compile.
configure never looks at latex stuff.
I also noticed that it compiles with -g, which takes a huge ammount of
disk space.

Garst

bash$ lyx
LyXTextClassList::Read: no textclasses found!

LyX wasn't able to find any layout description!
Check the contents of  the file "textclass.lst"
Sorry, has to exit :-(
-

LyX Development News for 20010117

[Allan Rae]

http://www.lyx.org/news/20010117.php3

You know what to do -- go read it!

Allan. (ARRae)

Re: no textclasses found

[Garst R. Reese]

"Garst R. Reese" wrote:
 
 I seem to have bungled something up. When 1.2.0cvs did not work for me,
 I downloaded 1.1.6 and I cannot get it to compile.
 configure never looks at latex stuff.
 I also noticed that it compiles with -g, which takes a huge ammount of
 disk space.
 
 Garst
 
 bash$ lyx
 LyXTextClassList::Read: no textclasses found!
 
 LyX wasn't able to find any layout description!
 Check the contents of  the file "textclass.lst"
 Sorry, has to exit :-(
 -
Sorry for the noise. Somehow I ended up with zero length files in my
home .lyx
Probably from running out of disk space.
Fixed now.
Garst

Re: new lyxfunc

[John Weiss]

On Mon, Jan 15, 2001 at 06:05:00PM +, John Levon wrote:
 
 4) There needs to be some way to deal with the frontend menus. These are
 integer-based. There are only two options here :

Hmmm why not generate the integer ID# for each lyxfunc from some
string-hashing function?  A hash-via-string-mem-location would produce
unique ID#'s (and it's a fairly common hash strategy for hash-tables
with string keys), and could do so when you register the lyxfunc's
name.

Just something to consider.

c) Reference.lyx. 'Nuff said.

I second and third this!  ;)

-- 
John Weiss

"Not through coersion.  Not by force.  But by compassion.  By
affection.  And, a small fish."  -His Holiness, the 14th Dalai Lama 

Re: Proposed LyXFunc reworking

[John Weiss]

On Mon, Jan 15, 2001 at 06:06:31PM +0100, Lars Gullik Bjnnes wrote:
 Andre Poenitz [EMAIL PROTECTED] writes:
 | 
 | A lyxfunc could take a stream argument from which it reads the actual
 | arguments. Most commands are passed around as strings anyway so it makes no
 | difference where it is converted to int/double/whatwever.
 
 I'd rather have the real lyxfunc the the correct paramters from the
 beginning, and have a wrapper that create those argumetns from the
 supplied stream.

Having a lyxfunc take a stream argument has a major disadvantage:  it
transforms a compile-time error into a runtime one.  Having a template
class for lyxfunc's, as Lars initially proposed, won't compile if
someone feeds it the wrong arguments.  I'm talking developers here,
not users.  Catching programming errors during the build is much
easier to debug than runtime errors.

This leaves only parsing the minibuffer/keybinding defns. for runtime
errors.  That parsing, however, can perform typechecking before
calling the actual lyxfunc.

-- 
John Weiss

"Not through coersion.  Not by force.  But by compassion.  By
affection.  And, a small fish."  -His Holiness, the 14th Dalai Lama 

Re: LyX Development News for 20010117

[Allan Rae]

Can someone try submitting the LDN URL to Linux Today, and other news
services please.  I just haven't time at the moment.

TIA,
Allan. (ARRae)

Re: Ordering the Layout list alphabetically.

[Allan Rae]

On Tue, 16 Jan 2001, R. Lahaye wrote:


 Hi,

 The layout list in the toolbar (Standard, Itemize, Numerize ...)
 is getting longer and longer. I'm continuesly searching for the
 item I need.

In the classes I've converted to layouts I've tried to organize the
entries by type/class eg. sections togethera nd so on.

 I would suggest to have the list ordered alphabetically; maybe
 "Standard" can stay at the top, but the rest would be better
 organized if it was in alphabetical order.

Yuck.  Sorry but I like the classes I use the way they are.
Maybe we really need to start looking at the layout abstraction idea we've
discussed before. Such that LyX knows what styles are of similar types --
sections etc. can then be grouped together in a drop down menu rather
than a combo.  This would at least keep the styles in a more sensible
grouping and should minize searching.

Allan. (ARRae)

 This is like having a LyX DTD that abstracts all the different styles so
that we can easily change document classes and match abstract styles
together rather than relying on the style names being identical.
Such as s1, s2, ...sN for the different depths of sectioning and so on.
Heck, it might even be feasible to use docbook XML as a basis (just subset
out what we need for the time being and add on from there).

Re: Ordering the Layout list alphabetically.

[R. Lahaye]

Allan Rae wrote:
 On Tue, 16 Jan 2001, R. Lahaye wrote:
  I would suggest to have the layout list ordered alphabetically;
  maybe "Standard" can stay at the top, but the rest would be better
  organized if it was in alphabetical order.
 
 Yuck.  Sorry but I like the classes I use the way they are.
 Maybe we really need to start looking at the layout abstraction
 idea we've discussed before. Such that LyX knows what styles are
 of similar types -- sections etc. can then be grouped together in
 a drop down menu rather than a combo.  This would at least keep
 the styles in a more sensible grouping and should minize searching.

1) What if the layout list would be user-configurable, like the
   menu bar is at present?
   Ship LyX with a default layout list, but let the user define
   his/her own when desired.

2) Slightly distantly related to this:
   Is there a plan to include right-mouse-click-contex-sensitive
   menus? (Does XForms allow this technique?)
   For example, marking text and right-mouse-click in the marked
   area, would popup a menu that applies to the marked text.

Rob.

double quotes are displayed as

[Thorsten Mika]

hi again,

there is another problem of which i do not know whether it is xfs-related or a 
lyx problem.
since upgrading, lyx sometimes displays the "french" quotes as two "greater" 
signs, i.e.  instead of the character lyx 1.1.2 used, which was correct. 
strange thing: sometimes it works, esp. after changing the display font for 
standard text, sometimes it does not. any idea? i am sorry, but i cannot really 
reprodzue this "bug".

my setup: Xsun and Solaris xfs.

thorsten

Thorsten Mika   mailto:[EMAIL PROTECTED]
Hamm / GermanyTM5173-RIPE

Re: new lyxfunc

[Andre Poenitz]

Agreed to this point.

 | 4) There needs to be some way to deal with the frontend menus. These are
 | integer-based. There are only two options here :
 | 
 | i) each frontend has a container mapping from integer values to
 |strings, used on dispatch
 | 
 | ii) each lyxfunctions is assigned an integer ID, and the ability
 | to lookup in the container by ID is added.
 | 
 | Lars must be suggesting option i).
 
 No, nor really. Closer to ii).

Note that the container mapping from menu position to the lyxfunc could be
as simple as a vectorstring for each container (I presume the integers
are the positions in the menu and therefore small).

 The problem with ii) as I read it is O(n), and we can easily make this
 O(1) by having a second container with pointer (iterators) into the
 real functionmap.

Naah. I'd store the index string. Negligible overhead. Oh wait. Maybe
again a factor of 1. I.e. from 0.05 microsecond for a pointer
dereference to 0.5 millisecond for the map lookup. And that each time a
user clicks on a menu... Users are pretty fast nowadays with the mouse
given the average 10 years of Windows conditioning ;-}

Map iterators are invalidated by quite a few operations on maps so we
should avoid to hand them out. 
 
Andre'

-- 
Andr Pnitz  [EMAIL PROTECTED]

Re: fax support, dead keys and i18n (1.1.6)

[Martin Vermeer]

On Mon, Jan 15, 2001 at 09:04:13PM +0100, Thorsten Mika wrote:
 Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
 Precedence: bulk
 X-No-Archive: yes
 List-Post: mailto:[EMAIL PROTECTED]
 List-Help: mailto:[EMAIL PROTECTED]
 List-Unsubscribe: mailto:[EMAIL PROTECTED]
 Delivered-To: mailing list [EMAIL PROTECTED]
 Date: Mon, 15 Jan 2001 21:04:13 +0100 (MET)
 From: Thorsten Mika [EMAIL PROTECTED]
 Reply-To: Thorsten Mika [EMAIL PROTECTED]
 Subject: Re: fax support, dead keys and i18n (1.1.6)
 To: [EMAIL PROTECTED], [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4c sparc 
 
 hi, jean-marc
 
  
  It is currently only disabled (I think). Sending faxes is not LyX's
  job (why not something for sending as e-mail) and is better done from
  an external application (the unix philosophy: "one tool one job" or
  whatever). Actually, somebody could probably take the old code and
  make it compile as a standalone application and have exactly the same
  functionnality. If we do not build a dvi viewer into LyX, we have no
  reason to built-in a fax sending program (OK, this is not a fair
  comment, I do not need fax :). By installing a _real_ fax frontend,
  you will have much better functionality, and LyX code will become
  cleaner (which is really needed).
 
 oh yes, i mean i was aware of efax doing the job. i just liked he phonebook 
 function. meanwhile i found a way that was discusse earlier in the list, by a 
 small python script and using the format converters. but i still miss the 
 phonebook...
 
You may want to look at FaxView 

http://www.netby.net/Oest/Europa-Alle/vermeer/

(shameless plug!) which is a tcl/tk script supporting efax.

It uses currently Ted as its fax editor, but it shouldn't be a big problem to
replace that by LyX. And it has a phone book... integration is not as nice, 
though.

...
 
 thx,
 
 thorsten
 
 Thorsten Mika   mailto:[EMAIL PROTECTED]
 Hamm / GermanyTM5173-RIPE
 
Martin
-- 
Martin Vermeer  [EMAIL PROTECTED]
Helsinki University of Technology 
Department of Surveying
P.O. Box 1200, FIN-02015 HUT, Finland
:wq

Re: Allan: follow up on build problems for Solaris

[Lars Gullik Bjønnes]

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

| Roland Krause wrote:
| > 
| > I'd say, lets move on from this crap. Require make-3.79 on solaris. Be
| > done with it.
| > 
| > Roland
| Do everybody a favour and require it across the board. We won't be
| alone. I already had to ugrade for some other pkg.
| Garst

I agree. 

Saves us a lot of troble.

Lgb

Re: ButtonController and ButtonPolicy

[Angus Leeming]

Hello, Allan.

Let me start with a justification of all this: I'd like to ease the pain of 
porting the dialogs to other GUIs by ensuring that they have only a minimum 
of things to do. We have occasional complaints from John and Marco about 
breaking their ports. Matthias Ettrich was rather more vocal. They are 
expressing a valid point. It's hard to keep up when the rules keep changing.

Each dialog exists to change some variables. Nothing more. It should, 
therefore, be passed only those variables (preferably as a Param struct). It 
should also have access to functions linked to the four Apply, Ok, Cancel, 
Reset buttons. Nothing more.

Everything else about the dialog, the signals it connects and disconnects to 
etc, should be controlled by a common Controller class. The GUIs need not 
worry about this. I've implemented this successfully.

In the same way, we can define a subset of the ButtonController class that is 
GUI-I. The GUI View need know about only the BC::valid() method called when 
an input is made and in the xforms case, about methods passed an FL_OBJECT *. 
You've written the Controller beautifully (serious here) so that the 
BC::apply(), ok() etc buttons know nothing about the xforms implementation.

I have it all working here. A ButtonController base class and a 
FormButtonController derived class containing xforms-specific stuff. I have a 
ControlledButtonDialog abstract class that has a ButtonController * and 4 
methods, ApplyButton(), OkButton, CancelButton() and RestoreButton() that 
does exactly as the static ApplyBC() etc used to do. All dialog-specific 
controllers can be derived from this.

It looks and feels clean and elegant and MINIMAL. That means, it should be 
readily understandable to John, Marco, whoever wants to implement another GUI.

If you want a look, just ask. Otherwise, I'll post when it's clean. I send 
enough junk to this list as-is!

Angus


On Saturday 13 January 2001 04:45, Allan Rae wrote:
> On Fri, 12 Jan 2001, Angus Leeming wrote:
> > Allan,
> >
> > I've worked out how to put an abstract ButtonControllerBase in the
> > ControlCitation class, or rather in a class that ControlCitation can be
> > derived from.
>
> Are you sure you want an inheritance relationship?
>
> I'm not sure what sort of separations you are hoping to achieve here.  At
> this point in time I'd prefer to continue with what we already have and
> then develop a separation later if it really is necessary.  Are you sure
> that what you are doing is actually going to be reusable by either John
> or Marko or any other port for that matter?  If there is a good chance
> that it won't, then steady your beating heart and direct your passions
> elsewhere ;-)
>
> Perhaps now would be a good time to explain in detail what you are
> separating and why.  Or maybe I should read that other email from earlier
> in the week if I can find it in the mess that is my mailbox.
>
> > I have one question regarding your ButtonController class. In the header
> > file there is:
> >
> > // Somebody else owns the FL_OBJECTs we just manipulate them.
> > // so? (Lgb)
> > //~ButtonController() {}
> >
> > Well and good. But SURELY the ButtonController owns its ButtonPolicy and
> > so this pointer should be deleted by the ButtonController d-tor?
>
> Yes.  This will soon spot anyone who is doing it wrong.
>
> Allan. (ARRae)

Re: Bug. Using Spanish

[Jean-Marc Lasgouttes]

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

>> http://sourceforge.net/bugs/?func=detailbug_id=125614_id=15212

Dekel> Yes, this is the same "bug", but it not a bug in LyX, but a
Dekel> problem with the Spanish babel file which redefine thes ~ char,
Dekel> and gives no way of deactivating this brilliant feature (as far
Dekel> as I could tell).

In fact, spanish.ldf should have a \noextrasspanish macro. It may
exist in recent babel versions...

Dekel> Howeevr, I think that this problem should be automatically
Dekel> solved by LyX. I can either add a Spanish specific code, or add
Dekel> an extra-options field in the language class (are there any
Dekel> other cases in which some language requires putting extra
Dekel> commands in the preamble ?).

Dekel> PS: The solution I wrote above will not work in multi-lingual
Dekel> docs. Does anyone have a better solution ?

Maybe
  \addto\extrasspanish{\def~{\nobreakspace{}}}
which fits better with babel structure.

JMarc

Re: Babel in LyX 1.1.6

[Jean-Marc Lasgouttes]

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

Dekel> The following was posted in lyx-users: On Fri, Jan 12, 2001 at
Dekel> 03:53:21PM -0700, Matthew Lovell wrote:
>> Lyx1.1.6 seems to be including the babel package in the resulting
>> LaTeX code. Is there a way to turn off this behavior? It doesn't
>> appear that I can select "none" for a language in the document
>> settings. :)
>> 
>> I have a thesis class which is not compatible with the babel
>> package. All nifty features deserve an off switch, after all.

Dekel> I think that we should add a boolean lyxrc variable, called
Dekel> default_language_use_babel so if
Dekel> lyxrc.default_language_use_babel = true, and the document
Dekel> language == lyxrc.default_language, then the babel package will
Dekel> not be loaded.

Why load babel if languag is default language, anyway? I think this
shows why having a default language was good...

JMarc

Re: Allan: follow up on build problems for Solaris

[Jean-Marc Lasgouttes]

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

Allan> On Sat, 13 Jan 2001, Roland Krause wrote:
>> Allan, a quick follow up.
>> 
>> The generic solaris make definitely does not work. Upgrading gmake
>> to version 3.79 finally solved the problem.

Allan> According to other reports we have, we only had to remove the
Allan> ':' for Sun's make to be happy. It may be a version thing I
Allan> suppose.

The := syntax is a GNU make extension.

>> Further, Solaris generic grep (/usr/bin/grep) does not know the
>> option -E, /usr/xpg/bin/grep does.

Allan> Does everyone have an egrep?

Why do you need this -E?

JMarc

Re: Allan: follow up on build problems for Solaris

[Jean-Marc Lasgouttes]

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

Allan> That's the way someone wrote it originally. egrep or `grep -E`
Allan> is the best tool for the job given that we want to find files
Allan> with "_(\".*\")" in them. `grep grep po/Makefile.in.in` to see
Allan> why.

What's wrong with 
  grep '_(".*")' ...

Am I just being dense?

JMarc

Re: Release LyX 1.1.6

[Jean-Marc Lasgouttes]

> "Frank" == Frank Derichsweiler <[EMAIL PROTECTED]> 
>writes:

Frank> On Mon, Jan 15, 2001 at 04:01:31PM +0900, R. Lahaye wrote:
>> Date: Mon, 15 Jan 2001 16:01:31 +0900 From: "R. Lahaye"
>> <[EMAIL PROTECTED]> To: Frank Derichsweiler
>> <[EMAIL PROTECTED]> CC:
>> [EMAIL PROTECTED] Subject: Re: Release LyX 1.1.6
>> 
>> Frank Derichsweiler wrote: > A little problem within a linux
>> environment: Having no kernel header > files (within
>> /usr/src/linux) the configure script runs and produces > the error
>> forms.h not found, which is IMHO misleading. Perhaps the >
>> configure can be adopted to check for the kernel include files >
>> separatly.
>> 
>> forms.h is part of the development package of xforms, the one you
>> need when compiling LyX yourself.
>> 
Frank> Yes, I know that. To me a little bit clearer: I installed the
Frank> xforms development stuff and all the other necessary libs and
Frank> headers. Only the linux *kernel* headers were missing. 

We have something related in the INSTALL file, section "Problems":

  o Configure will seemingly fail to find xpm.h and forms.h on linux if
you did a 'make mrproper' in the kernel directory, because this
removes some symbolic links that are needed for compilation. A 'make
symlinks' in linux kernel sources fixes that.

However, having a header file which relies on kernel headers is a BUG
in itself (according to Linus himself). You should probably find out
which headers do that, and see whether an upgrade would be a proper
cure.

JMarc

Re: Bug. Using Spanish

[Dekel Tsur]

On Mon, Jan 15, 2001 at 11:18:32AM +0100, Jean-Marc Lasgouttes wrote:
> Dekel> Yes, this is the same "bug", but it not a bug in LyX, but a
> Dekel> problem with the Spanish babel file which redefine thes ~ char,
> Dekel> and gives no way of deactivating this brilliant feature (as far
> Dekel> as I could tell).
> 
> In fact, spanish.ldf should have a \noextrasspanish macro. It may
> exist in recent babel versions...

Yes, but it doesn't deactivate the ~ char (I checked the latest beta version).

> Dekel> Howeevr, I think that this problem should be automatically
> Dekel> solved by LyX. I can either add a Spanish specific code, or add
> Dekel> an extra-options field in the language class (are there any
> Dekel> other cases in which some language requires putting extra
> Dekel> commands in the preamble ?).
> 
> Dekel> PS: The solution I wrote above will not work in multi-lingual
> Dekel> docs. Does anyone have a better solution ?
> 
> Maybe
>   \addto\extrasspanish{\def~{\nobreakspace{}}}
> which fits better with babel structure.

Or
\addto\extrasspanish{\bbl@deactivate{~}}

Re: Babel in LyX 1.1.6

[Dekel Tsur]

On Mon, Jan 15, 2001 at 11:24:42AM +0100, Jean-Marc Lasgouttes wrote:
> Dekel> I think that we should add a boolean lyxrc variable, called
> Dekel> default_language_use_babel so if
> Dekel> lyxrc.default_language_use_babel = true, and the document
> Dekel> language == lyxrc.default_language, then the babel package will
> Dekel> not be loaded.
> 
> Why load babel if languag is default language, anyway? I think this
> shows why having a default language was good...

Check the archive to see why we decided to remove it.

PS: Please send your emails only to lyx-devel. I'm getting your messages twice.

Re: Allan: follow up on build problems for Solaris

[Jean-Marc Lasgouttes]

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

>>  What's wrong with grep '_(".*")' ...

Allan> Aren't regular expressions like above a GNU extension for grep.
Allan> That's why I asked about egrep which I think (hope) is
Allan> "standard". You gotta love Unix, there are so many standards to
Allan> choose from.

What part of the regexp is an extension according to you? The use of
parenthesis? 

JMarc

Re: Babel in LyX 1.1.6

[Jean-Marc Lasgouttes]

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

>>  Why load babel if languag is default language, anyway? I think
>> this shows why having a default language was good...

Dekel> Check the archive to see why we decided to remove it.

I remember the messages, but I have to admit it did not get the point
at the time. I guess I should re-read them...

Dekel> PS: Please send your emails only to lyx-devel. I'm getting your
Dekel> messages twice.

I'm getting lazier since I configure GNUS to delete duplicated
messages :)

JMarc

Re: Release LyX 1.1.6

[Frank Derichsweiler]

On Mon, Jan 15, 2001 at 12:26:32PM +0100, Jean-Marc Lasgouttes wrote:
> We have something related in the INSTALL file, section "Problems":
> 
>   o Configure will seemingly fail to find xpm.h and forms.h on linux if
> you did a 'make mrproper' in the kernel directory, because this
> removes some symbolic links that are needed for compilation. A 'make
> symlinks' in linux kernel sources fixes that.
> 
> However, having a header file which relies on kernel headers is a BUG
> in itself (according to Linus himself). You should probably find out
> which headers do that, and see whether an upgrade would be a proper
> cure.
> 

Situation: /usr/src/linux is *not* existent (for reasons of space),
i.e. no kernel header files at all. The lyx configure script fails
with the error message "forms.h" not found. That message is false,
because the forms.h is found but the test code cannot be compiled
because of the missing kernel header files.
Reproducing /usr/src/linux form the .tar.gz and starting again the
configure works fine as lyx also does.
My idea is to put a *new test*  into the lyx configure script for just
testing the availability of the required kernel header
files. (Unfortunaltey I do not know which files exactly are relevant).
That is just a suggestion to improve the configure script. 

Frank

Re: Release LyX 1.1.6

[Jean-Marc Lasgouttes]

> "Frank" == Frank Derichsweiler <[EMAIL PROTECTED]> 
>writes:

Frank> Situation: /usr/src/linux is *not* existent (for reasons of
Frank> space), i.e. no kernel header files at all. 

I understand that. I was just pointing out that the problems were
related and that we could probably change the description to fit your
problem (supposing people actually read INSTALL, of course ;).

Frank> The lyx configure
Frank> script fails with the error message "forms.h" not found. That
Frank> message is false, because the forms.h is found but the test
Frank> code cannot be compiled because of the missing kernel header
Frank> files. 

Could you show us the relevant part of config.log? Before writing
configure test blindly, one has to know what header file decided that
it should have access to kernel headers.

JMarc

Re: Allan: follow up on build problems for Solaris

[Allan Rae]

On 15 Jan 2001, Jean-Marc Lasgouttes wrote:

> > "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
>
> >>  What's wrong with grep '_(".*")' ...
>
> Allan> Aren't regular expressions like above a GNU extension for grep.
> Allan> That's why I asked about egrep which I think (hope) is
> Allan> "standard". You gotta love Unix, there are so many standards to
> Allan> choose from.
>
> What part of the regexp is an extension according to you? The use of
> parenthesis?

I thought, perhaps mistakenly, that grep didn't do ".*" matching except in
GNU form.  Anyway as I said I didn't write this but figured someone, maybe
Lars, had a reason for using `grep -E` in the first place.

Just change it then and if someone screams we'll know better next time ;-)

Allan. (ARRae)

Re: fax support, dead keys and i18n (1.1.6)

[John Levon]

On Sat, 13 Jan 2001, Thorsten Mika wrote:

> 1. why did you remove the fax support? is it that big? dont you feel like 
> putting an option in the configure script to give the opportunity to enable it  
> again? i really felt comfortable with it, using any other program or doing the 
> stuff by hand is (though i got to admit only a tiny little) drag. if not, where 
> do i have to remove comments to enable it again?

I think it was removed because the code was out of date, and there was no
one to update it ... I could be wrong though

> 2. the dead keys work, but they are not displayed correctly on the screen. is 
> this my fault, fault of xfs, or libforms (0.89) problem?

pass

> 3. i cant get the international menus to work (i am german, my LANG is set to 
> DE, the help docs are selected correctly, but the menus stay english)?
> 

The i18n of menus apparently only works now after a "make install"

john

-- 
"Threads are for people who can't program state machines."
- Alan Cox

Re: ButtonController and ButtonPolicy

[Allan Rae]

On Mon, 15 Jan 2001, Angus Leeming wrote:

> Hello, Allan.

Hi Angus!

> Let me start with a justification of all this: I'd like to ease the pain of
> porting the dialogs to other GUIs by ensuring that they have only a minimum
> of things to do. We have occasional complaints from John and Marco about
> breaking their ports. Matthias Ettrich was rather more vocal. They are
> expressing a valid point. It's hard to keep up when the rules keep changing.
>
> Each dialog exists to change some variables. Nothing more. It should,
> therefore, be passed only those variables (preferably as a Param struct). It
> should also have access to functions linked to the four Apply, Ok, Cancel,
> Reset buttons. Nothing more.
>
> Everything else about the dialog, the signals it connects and disconnects to
> etc, should be controlled by a common Controller class. The GUIs need not
> worry about this. I've implemented this successfully.
>
> In the same way, we can define a subset of the ButtonController class that is
> GUI-I. The GUI View need know about only the BC::valid() method called when
> an input is made and in the xforms case, about methods passed an FL_OBJECT *.
> You've written the Controller beautifully (serious here) so that the
> BC::apply(), ok() etc buttons know nothing about the xforms implementation.

Okay, sounds reasonable.

> I have it all working here. A ButtonController base class and a
> FormButtonController derived class containing xforms-specific stuff. I have a

Please change the name from FormButtonController.  Only dialogs (or forms
in XForms speak) should be called FormXxxx.

> ControlledButtonDialog abstract class that has a ButtonController * and 4
> methods, ApplyButton(), OkButton, CancelButton() and RestoreButton() that
> does exactly as the static ApplyBC() etc used to do. All dialog-specific
> controllers can be derived from this.
>
> It looks and feels clean and elegant and MINIMAL. That means, it should be
> readily understandable to John, Marco, whoever wants to implement another GUI.
>
> If you want a look, just ask. Otherwise, I'll post when it's clean. I send
> enough junk to this list as-is!

I won't be able to look at it for two weeks at least so take your time and
get it really pretty.  Right now I gotta stop reading my email and get
this LDN finished so I can get some sleep tonight.

Allan. (ARRae)

Re: Release LyX 1.1.6

[John Levon]

On 15 Jan 2001, Jean-Marc Lasgouttes wrote:

> Could you show us the relevant part of config.log? Before writing
> configure test blindly, one has to know what header file decided that
> it should have access to kernel headers.
> 
> JMarc

No, I think this is definitely a broken distribution, if it has symlinks
into /usr/src/linux, and the packaging system doesn't require
kernel-headers package for compilation.

As JMarc points out, these symlinks are officially deprecated anyway, and
in fact, most modern distributions don't have them.

So, this is NOT something LyX should care about. This is a distribution
problem (in that it didn't require kernel-headers as a dependency of
development headers, OR not need kernel-headers at all)

IMHO
john

-- 
"Threads are for people who can't program state machines."
- Alan Cox

Re: NEW_INSETS

[Lars Gullik Bjønnes]

John Levon <[EMAIL PROTECTED]> writes:

| > I know of only a couple of problems:
| > 
| > - floats support are a bit lacking, specially algoritm will
| >   have problems.
| 
| does this also include the fact that getTocList() doesn't work (generating
| no contents for the dialog to read) ?
| 
| should I log it as a reminder bug ?

I'd rather you fixed it :-)

Lgb

Re: Allan: follow up on build problems for Solaris

[John Levon]

On Tue, 16 Jan 2001, Allan Rae wrote:

> On 15 Jan 2001, Jean-Marc Lasgouttes wrote:
> 
> > > "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
> >
> > Allan> I thought, perhaps mistakenly, that grep didn't do ".*"
> > Allan> matching except in GNU form. Anyway as I said I didn't write
> > Allan> this but figured someone, maybe Lars, had a reason for using
> > Allan> `grep -E` in the first place.
> >
> > You mean you thought grep did not do regular expressions? So, what
> > does the 're' stand for?
> 
> Sure but there are re's and re's.   * and .* may be different things
> depending on whos re-engine you are using.
> 
> I thought egrep handled '.*' as grep handles '*'.  If they are in fact the
> same then WTF does egrep really do?
> 
> Allan. (ARRae)

I thought the sole difference of egrep was '|', i.e. I can do :

egrep 'KERN|STACK' /usr/src/linux/include/linux/kernel.h

try it with normal grep, and '|' isn't a special character any more ...

john

-- 
"Threads are for people who can't program state machines."
- Alan Cox

Re: Allan: follow up on build problems for Solaris

[Jean-Marc Lasgouttes]

> "John" == John Levon <[EMAIL PROTECTED]> writes:

John> try it with normal grep, and '|' isn't a special character any
John> more ...

But \| is a special character.

JMarc

Re: Proposed LyXFunc reworking

[Lars Gullik Bjønnes]

John Levon <[EMAIL PROTECTED]> writes:

| o no longer is the various parts of a new function spread in four or five
|   different places. To add a new function means adding it to functions.C,
|   and (if necessary) a status tester to status_functions.C

but that is almost true today as well. To add a new lyxfund you add to
the enum in commandtags.h, add  an item in LyXAction.C and a case in
LyXFunc. Ecerything else is just to make thins easier or localized in
another way.

| o several files are auto-generated with a perl script. This helps
|   centralise the details of each lyxfunc

We we need autogeneration for that?
 
| o each lyxfunc has doxygen-style commentary (which is also interpreted to
|   generate the automatic files)
| 
| o lyxaction is gone, replaced with lf_container, which is a little more
|   container-y, and contains no special code for handling the functions (it
|   is basically a look-up facility)

Couln't much of what you do be done with added some more fields to the
LyXAction lfun_item?
(In your case a function pointer) 

| o each lyxfunction handles itself, include pseudo-action functions

I didn't see how you handled pseudo actions.
Can you explain.
 
| o there's no extra expensive lookup for static functions on dispatch

??
 
| I would appreciate any comments anyone has got. Is this workable or am I
| crazy ? How do people feel about auto-generating files ?

I don't like the auto-generation.

Also I feel you use pointer too much, but that should be a detail.
(you also pass objects by value, should be passed by const reference)


But: something like this is needed.

Lgb

Re: Proposed LyXFunc reworking

[Jean-Marc Lasgouttes]

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

Lars> Couln't much of what you do be done with added some more fields
Lars> to the LyXAction lfun_item? (In your case a function pointer)

That would probably be a good idea. One thing which would be nice too
is to declare the arguments expected by the func and maybe their type. 

What is nice however in John's scheme is that the
documentation/definition of the func is at the same place as its
implementation. It is helpful when tracing function.

Lars> I don't like the auto-generation.

In this case the code in functions.C looks good and would give good
documentation. 

JMarc

Re: Proposed LyXFunc reworking

[John Levon]

On 15 Jan 2001, Lars Gullik Bjønnes wrote:

> John Levon <[EMAIL PROTECTED]> writes:
> 
> | o no longer is the various parts of a new function spread in four or five
> |   different places. To add a new function means adding it to functions.C,
> |   and (if necessary) a status tester to status_functions.C
> 
> but that is almost true today as well. To add a new lyxfund you add to
> the enum in commandtags.h, add  an item in LyXAction.C and a case in
> LyXFunc.

exactly ! It is *much* nicer to have it all in exactly one place IMHO

> Ecerything else is just to make thins easier or localized in
> another way.

could you expand ?

> | o several files are auto-generated with a perl script. This helps
> |   centralise the details of each lyxfunc
> 
> We we need autogeneration for that?

at the very least, without auto generation, you need :

1 place for the commandtag (commandtags.h)
1 place for the invoke method (lyxfunc.C)
1 place for the instantiation of the lyxfunc (LyXAction.C)

I don't see how these can be centralised into a single file (+ header
file) w/o auto-gen

> Couln't much of what you do be done with added some more fields to the
> LyXAction lfun_item?
> (In your case a function pointer) 

sure, if you think lfun_item items[] is readable (I don't). And also this
requires me to manually split up the Dispatch() switch, and then add the
various bits in the right place in items[]. No thanks ...

> I didn't see how you handled pseudo actions.
> Can you explain.

This is the vague part (I only spent a short while messing with this). I
think what happens is that the code creating the pseudo-action
(i.e. similar to existing getPseudoAction()) will ask the lf_container
addAction(), which will instantiate a newly create lyxfunction object. The
lyxfunction is generated and the real action + its argument is stored
inside that lyxfunction (see second lyxfunction c-tor).

At invoke time, the operator() will pick up the real action + argument,
and invoke that instead.

Access to the pseudo action is vi lf_container maps.

> | o there's no extra expensive lookup for static functions on dispatch
> 
> ??

... I mean as in the old code. e.g. LFUN_RIGHT dispatch is just an array
offset rather than some map lookup or something. This needs to be as fast
as possible, right ?

> Also I feel you use pointer too much, but that should be a detail.
> (you also pass objects by value, should be passed by const reference)

yes, all the C++ good practice stuff should be shaken out if the code gets
worked out

thanks
john

-- 
"Threads are for people who can't program state machines."
- Alan Cox

Re: Proposed LyXFunc reworking

[John Levon]

On 15 Jan 2001, Jean-Marc Lasgouttes wrote:

> That would probably be a good idea. One thing which would be nice too
> is to declare the arguments expected by the func and maybe their type. 

Any suggestions on how this might work ?

thanks
john

-- 
"Threads are for people who can't program state machines."
- Alan Cox

Website links

[Andre Ulrich]

Hej LyX Team!

There is no link working on the LyX homepage. Neither the announcement nor 
the File is accessable. The whole ftp tree seems to be broken(only unrelated 
stuff on it).

Can´t wait to try out the new Jpeg and PNG import :)

Regards

Andre´

Re: Proposed LyXFunc reworking

[Jean-Marc Lasgouttes]

> "John" == John Levon <[EMAIL PROTECTED]> writes:

John> On 15 Jan 2001, Jean-Marc Lasgouttes wrote:
>> That would probably be a good idea. One thing which would be nice
>> too is to declare the arguments expected by the func and maybe
>> their type.

John> Any suggestions on how this might work ?

Maybe something based on signals and templates? Would sigc++ be useful
in this case? Really, I do not know. My knowledge of C++ is too weak
when it comes to that.

JMarc

Re: Website links

[Jean-Marc Lasgouttes]

> "Andre" == Andre Ulrich <[EMAIL PROTECTED]> writes:

Andre> Hej LyX Team! There is no link working on the LyX homepage.
Andre> Neither the announcement nor the File is accessable. The whole
Andre> ftp tree seems to be broken(only unrelated stuff on it).

Yes, it seems that the ftp site is down. You can try
ftp.devel.lyx.org/pub/lyx instead.

Lars, the announce/ directory has not been created on the web site (I
looked on aussie in /home/httpd/html/lyx-user). Can you do something
about it?

JMarc

Re: Proposed LyXFunc reworking

[Andre Poenitz]

> at the very least, without auto generation, you need :
> 
> 1 place for the commandtag (commandtags.h)
> 1 place for the invoke method (lyxfunc.C)
> 1 place for the instantiation of the lyxfunc (LyXAction.C)

What about nuking the commandtags and putting everything in a
std::map, where the index is the (first word of)
the command?

Comparing strings instead numbers should cost only a constant factor of
time more than comparing enums, starting off from a very tiny amount.
Morover, lookup in the map is O(ln n) compared to O(n) in the
big case scwitch. So it shold not really be noticable.

The "big loss" is "type safety": We don't notice at compile time a
misspelled command. OTOH at some time we might wish to dynamically 
extend lyx - say by a newly installed converter - without quitting the
current work. In this case the infrastructure would be in place already.

I have a similar scheme working in my current project: There everything is
pretty modular and I can get different versions off the program simply by
linking different sets of modules. Every modul has a global static object
which registers on construction the modules' commands with a big
central dispatcher (basically a map).

Dependencies are basically resolved by the linker and the dynamic loader.
Upon entrace of main() the central dispatcher knows exactly the commands of
the available modules without the need to query them individually.

I don't have any performance problems in this corner of the program.

Andre'

-- 
André Pönitz  [EMAIL PROTECTED]

Re: Proposed LyXFunc reworking

[John Levon]

On Mon, 15 Jan 2001, Andre Poenitz wrote:

> > at the very least, without auto generation, you need :
> > 
> > 1 place for the commandtag (commandtags.h)
> > 1 place for the invoke method (lyxfunc.C)
> > 1 place for the instantiation of the lyxfunc (LyXAction.C)
> 
> What about nuking the commandtags and putting everything in a
> std::map, where the index is the (first word of)
> the command?
> 
> Comparing strings instead numbers should cost only a constant factor of
> time more than comparing enums, starting off from a very tiny amount.
> Morover, lookup in the map is O(ln n) compared to O(n) in the
> big case scwitch. So it shold not really be noticable.

you are forgetting the constants of the complexity equation. I bet the
compiler does a better job of the case() { } construct than it does of the
STL header code. (Of course, this argument is pointless w/o measurement to
back it up). And I don't see any real purpose to removing the array-based
approach ?

> The "big loss" is "type safety": We don't notice at compile time a
> misspelled command. OTOH at some time we might wish to dynamically 
> extend lyx - say by a newly installed converter - without quitting the
> current work. In this case the infrastructure would be in place already.

would we really ever want to do this ? I don't see a good reason to lose
compile-time type safety, and this doesn't really help at all in terms of
readability of each function. Think about how we would add the author's
name and creation date, detailed usage instructions for the developer etc.

In my proposed scheme this all comes "for free" (with some nice doxygen
documentation to go along with it).

john

-- 
"Threads are for people who can't program state machines."
- Alan Cox

Re: Proposed LyXFunc reworking

[Lars Gullik Bjønnes]

John Levon <[EMAIL PROTECTED]> writes:

| On 15 Jan 2001, Lars Gullik Bjønnes wrote:
| 
| > John Levon <[EMAIL PROTECTED]> writes:
| > 
| > | o no longer is the various parts of a new function spread in four or five
| > |   different places. To add a new function means adding it to functions.C,
| > |   and (if necessary) a status tester to status_functions.C
| > 
| > but that is almost true today as well. To add a new lyxfund you add to
| > the enum in commandtags.h, add  an item in LyXAction.C and a case in
| > LyXFunc.
| 
| exactly ! It is *much* nicer to have it all in exactly one place
| IMHO

mmm, and I am not sure that I agree completely... I had one thing
planned: get rid of LFUN and the commandtags, and just use strings instead.

I also planned on adding a register method to LyXAction or LyXFunc to
that lyxfunc could register themselves.

(this would also open up for dynamic creations fo lyxfunc through
script language or dynamic loaded functions)


namespace LFUN {
bool insert_string(lyxfunc & lf) {
// do the stuff
}
}

lyxfunc.register("insert-string", LFUN::insert_string, NEEDS_BUFFER);

lyxfunc.register_pseudo("insert-666", "insert-string", "666");


lyxfunc.dispatch("insert-666");

| could you expand ?
| 
| > | o several files are auto-generated with a perl script. This helps
| > |   centralise the details of each lyxfunc
| > 
| > We we need autogeneration for that?
| 
| at the very least, without auto generation, you need :
| 
| 1 place for the commandtag (commandtags.h)

we can probalby drop the command tags.

| 1 place for the invoke method (lyxfunc.C)

this can be generic and needs to be written only once.

| 1 place for the instantiation of the lyxfunc (LyXAction.C)

multiple places... if wanted or all in the same location.

| I don't see how these can be centralised into a single file (+ header
| file) w/o auto-gen

I think it is doable.

| > Couln't much of what you do be done with added some more fields to the
| > LyXAction lfun_item?
| > (In your case a function pointer) 
| 
| sure, if you think lfun_item items[] is readable (I don't). And also this
| requires me to manually split up the Dispatch() switch, and then add the
| various bits in the right place in items[]. No thanks ...

Note that lfun_item items[] is the way it is to speed up
initialization.

| > I didn't see how you handled pseudo actions.
| > Can you explain.
| 
| This is the vague part (I only spent a short while messing with this). I
| think what happens is that the code creating the pseudo-action
| (i.e. similar to existing getPseudoAction()) will ask the lf_container
| addAction(), which will instantiate a newly create lyxfunction object. The
| lyxfunction is generated and the real action + its argument is stored
| inside that lyxfunction (see second lyxfunction c-tor).

Yes. A wrapper around he real func + arg.


| 
| > | o there's no extra expensive lookup for static functions on dispatch
| > 
| > ??
| 
| ... I mean as in the old code. e.g. LFUN_RIGHT dispatch is just an array
| offset rather than some map lookup or something. This needs to be as fast
| as possible, right ?

Well in a way yes, but _speed_ should /not/ be our main concern, clear
and easy to follow code should.
 
| > Also I feel you use pointer too much, but that should be a detail.
| > (you also pass objects by value, should be passed by const reference)
| 
| yes, all the C++ good practice stuff should be shaken out if the code gets
| worked out

You really should go to the boost site (www.boost.org) and see if you
can find anything usefull there.

Lgb

Re: Proposed LyXFunc reworking

[Jean-Marc Lasgouttes]

> "John" == John Levon <[EMAIL PROTECTED]> writes:

John> how do strings fit in with the frontend menus ? Must I really
John> have some extra store of integers (the menu ID tags from the GUI
John> library) to strings ?

The functions could be allocated a number when they are registered, or
something like that [although I kind of prefer your scheme]

JMarc

Re: Proposed LyXFunc reworking

[Andre Poenitz]

> > the command?
> > 
> > Comparing strings instead numbers should cost only a constant factor of
> > time more than comparing enums, starting off from a very tiny amount.
> > Morover, lookup in the map is O(ln n) compared to O(n) in the
> > big case scwitch. So it shold not really be noticable.
> 
> you are forgetting the constants of the complexity equation.

No. I am not. First of all I mentiond the existence of a constant factor
and second, it does not matter. Even if the factor was 1000.

How many lyx-functions are called per second? 1000? Likely less.
Now, how long take 1000 string lookups in a map with 100 entries? 
Relate this to the work done by a complete table-redraw.

Got it? ;-)

> And I don't see any real purpose to removing the array-based approach ?

Code decoupling. LyX still takes ages to compile even after tiny changes.
 
> would we really ever want to do this ?

Why not? Most larger apps come with dynamically lodable modules.
I don't see any reason e.g. to carry all SGML stuff in a monolithic binary
if I don't need it most of the time.

> I don't see a good reason to lose
> compile-time type safety, and this doesn't really help at all in terms of
> readability of each function.

Could you explain that? The function tags will go away entirely.
The commands are pretty invisible to "user code".

> Think about how we would add the author's
> name and creation date, detailed usage instructions for the developer etc.

The creation date of the lyxfunc? You lost me.

Andre'

-- 
André Pönitz  [EMAIL PROTECTED]

Re: Proposed LyXFunc reworking

[John Levon]

On 15 Jan 2001, Jean-Marc Lasgouttes wrote:

> > "John" == John Levon <[EMAIL PROTECTED]> writes:
> 
> John> how do strings fit in with the frontend menus ? Must I really
> John> have some extra store of integers (the menu ID tags from the GUI
> John> library) to strings ?
> 
> The functions could be allocated a number when they are registered, or
> something like that [although I kind of prefer your scheme]
> 
> JMarc

But the communication between the frontends and the kernel would still be
in terms of integers (otherwise I would have to lookup by integer, to get
a string, to do the Dispatch()).

IOW, it just doubles up the "naming scheme" for functions to little or no
benefit AFAICS. Note that the auto-gen source I wrote has a trivial thing
to allow lyx functions to be accessible by name (see the command name
thing, generated as "LFUN_MENU_OPEN" in the c-tors in auto-init.C).

But it is obviously not gaining favour as an approach, so...

john



-- 
"Threads are for people who can't program state machines."
- Alan Cox

Re: Proposed LyXFunc reworking

[John Levon]

On Mon, 15 Jan 2001, Andre Poenitz wrote:

> No. I am not. First of all I mentiond the existence of a constant factor
> and second, it does not matter. Even if the factor was 1000.
> 
> How many lyx-functions are called per second? 1000? Likely less.
> Now, how long take 1000 string lookups in a map with 100 entries? 
> Relate this to the work done by a complete table-redraw.

make that 250+ entries, but yes, maybe it's OK performance-wise (although
picking something as slow as table redraw is cheating :)

> Code decoupling. LyX still takes ages to compile even after tiny changes.

I'd rather wait longer and have less bugs ;)

> Why not? Most larger apps come with dynamically lodable modules.
> I don't see any reason e.g. to carry all SGML stuff in a monolithic binary
> if I don't need it most of the time.

yep OK.

> The creation date of the lyxfunc? You lost me.

see the user names and dates in commandtags.h

john

-- 
"Threads are for people who can't program state machines."
- Alan Cox