Re: [patch] new scrollbar code

[Asger Alstrup]

Alfredo Braunstein wrote:
I'm not sure about that. Specially since there's no difference in the
scrollbar size in a mid-sized document vs a big document like UG, because
most toolkits have a minimum size for the widget.
Small documents are important too.
It shouldn't jump at all (otherwise is just a bug).
The size should not change more than a few pixels either.
Constant time per paragraph, O(number of paragraphs) total time
And can't we afford this? If so, our paragraph list traversal sucks and 
should be changed.

The biggest problem seems to be very high insets, like long tabulars
Great, then try to address those, and see what is the next problem. This is 
exactly the approach I'm advocating.

This could be, the question is how to do this consistently.
Otherwise we will always have problems with corner cases.
It is still monotoneously better than ignoring the problem.
Ultimately, if such patching up does not fix the problem, we have to admit
that it was a mistake, and introduce full document word breaking again.
It may be, but I am afraid that we cannot afford this.
We used to be able to afford it, so it is affordable. It might not be 
feasible with the current rewritten core, but then the rewrite is not 
complete or a failure.

An alternative you didn't mention would be to have background computation of
the exact size (including full rebreak etc).
This is similar to what web-browsers do as they receive the data, so that 
might be acceptable. But I thought the problem was that keeping the data 
up-to-date as the document changes is the problem? You will not avoid that 
can of worms with background rebreak.

Regards,
Asger

Re: [patch] new scrollbar code

[Asger Alstrup]

Alfredo Braunstein wrote:
Small documents are important too.
Sure, I am only noting that it is a feature that only *exists* in small
documents. Thus, it cannot be so fundamentally important.
It serves as important feedback on the size of the document.
Well, we could just keep (maybe outdated) paragraphs sizes, and just update
on-screen ones when drawing. Then the scrollbar computation would be only a
loop over all outer paragraphs. 
Since you mentioned that tables are the biggest problem, I would suggest to 
 come up with a light-weight improved estimate for those, and see how much 
that helps.

Then address images next.
I.e. go down the path outlined in my earlier mail, except that the 
priorities are:

- Tables
- Images
- Paragraph text size
- Other stuff
Only looking at outer paragraphs ignores the two most important ones.
Regards,
Asger

Re: [patch] new scrollbar code

[Asger Alstrup]

Alfredo Braunstein wrote:
I think you didn't understand what I suggested. 

I suggested to do a fullrebreak on start (foreground or background) and then
keep outer paragraphs sizes. Only update sizes when drawing paragraphs
on-screen, and live with outdated sizes for out-of-screen outer paragraphs.
I think that this may work very well.
I agree that this will help a lot, especially if the clipboard does not
throw away the sizes of full paragraphs copied/pasted. And when the window
is resized, we need a full rebreak like in the old days.
Regards,
Asger

Re: [patch] new scrollbar code

[Asger Alstrup]

I believe that a fixed sized scroll bar is a significant regression in 
terms of usability.

Also, I think that a very unreliable scroll bar is a problem. The scroll 
bar can change a few pixels, but if it jumps much more than that, it is 
confusing.

I did not test the new scrollbar, but if you use a uniform estimated size 
on all paragraphs, I think the obvious thing is to improve this by 
estimating the height as a function of the number of characters in the 
paragraph and the width available for the paragraph. You can define a 
function for this which calculates in constant time by using mean values 
for the character width and word length.

To improve further, consider the insets in the paragraph by having a 
default size for each type and take that into account. Now, we are linear 
time in the number of insets, but no loading or rendering of insets are 
necessary to get the estimate, so it is still very fast.

If this is still not accurate enough, then I'd go for better handling of 
the biggest elements that can appear in a document: images, tables and such.

Ultimately, if such patching up does not fix the problem, we have to admit 
that it was a mistake, and introduce full document word breaking again.

The scrollbar is one of the single most important features in a word 
processor. You use it all the time. You want that to be reliable and not 
seem strange.

Regards,
Asger

Re: Towards LyX 1.3.6 [status update #1]

[Asger Alstrup]

The tradition about displaying nice paths on windows does not exist: Either 
you do the complicated:

  C:\Documents and settings\alstrup\My documents\My file.lyx
  C:\Documents and settings\alstrup\Desktop\My second file.lyx
  C:\My third file.lyx
or you ignore the path and just do (like all the Microsoft tools including 
Office does)

  My file.lyx
  My second file.lyx
  My third file.lyx
You never want to present the 8.3 name.
Regards,
Asger

Re: [patch] new scrollbar code

[Asger Alstrup]

John Levon wrote:
To improve further, consider the insets in the paragraph by having a 
default size for each type and take that into account. Now, we are linear 
There's no such thing as a linear size for figures, so this is
guaranteed to go wrong in the worst possible cases (very large figures).
I believe it is monotoneously better to estimate all figures at say 200x200 
pixels, rather than at 0x0 pixels like it does now.

The linear bit in my sentence refers to the time it takes to estimate the 
height of a paragraph: The algorithm is roughly something like this:

  int x = 0;
  int y = average-character-height;
  for (int i = 0; i != numberOfInsets-in-paragraph; ++i) {
// First estimate size of the text
x += average-character-width
* number-of-characters-in-paragraph
/   numberOfInsets-in-paragraph;
y += (x / width-available) * average-character-height;
x = x % width-available;
// Next estimate size of the insets
x += average-width-of-inset-at-position(i);
if (x > width-available) {
y += average-height;
x = x % width-available;
}
  }
Notice small constant factors and linear time in number of insets. That 
should be fast enough, and improve tremendously on a totally static estimate.

My point is that this estimation routine can be continuously refined until 
it represents a complete rendering of the paragraph. We need to try and 
find out how fine-grained the estimate has to be in order for the scroll 
bar to be usable.

Regards,
Asger

Re: Towards LyX 1.3.6 [status update #1]

[Asger Alstrup]

Angus Leeming wrote:
Asger Alstrup wrote:
The tradition about displaying nice paths on windows does not exist:
So you think that having such functionality is a bad thing for LyX/Win? 
The only real problem here seems to be the ~ abbreviation.
Well, it is not necessarily a bad thing, but it is not a tradition, and 
therefore people will find it strange. I think we should go for the second 
option.

or you ignore the path and just do (like all the Microsoft tools
including Office does)
  My file.lyx
  My second file.lyx
  My third file.lyx
And if there are two different "My file.lyx" with different paths? I'd 
suggest doing as emacs does in such a case and display

 My file.lyx
 My file.lyx<2>
The convention is to use "My file.lyx (2)", but this is best.
Excel for instance simply disallows opening a second document with the same 
name, although the path is different. I guess they have found that people 
mix up and ruin their work when they have two identically named documents open.

Regards,
Asger

Re: [patch] new scrollbar code

[Asger Alstrup]

Alfredo Braunstein wrote:
I'm not sure about that. Specially since there's no difference in the
scrollbar size in a mid-sized document vs a big document like UG, because
most toolkits have a minimum size for the widget.
Small documents are important too.
It shouldn't jump at all (otherwise is just a bug).
The size should not change more than a few pixels either.
Constant time per paragraph, O(number of paragraphs) total time
And can't we afford this? If so, our paragraph list traversal sucks and 
should be changed.

The biggest problem seems to be very high insets, like long tabulars
Great, then try to address those, and see what is the next problem. This is 
exactly the approach I'm advocating.

This could be, the question is how to do this consistently.
Otherwise we will always have problems with corner cases.
It is still monotoneously better than ignoring the problem.
Ultimately, if such patching up does not fix the problem, we have to admit
that it was a mistake, and introduce full document word breaking again.
It may be, but I am afraid that we cannot afford this.
We used to be able to afford it, so it is affordable. It might not be 
feasible with the current rewritten core, but then the rewrite is not 
complete or a failure.

An alternative you didn't mention would be to have background computation of
the exact size (including full rebreak etc).
This is similar to what web-browsers do as they receive the data, so that 
might be acceptable. But I thought the problem was that keeping the data 
up-to-date as the document changes is the problem? You will not avoid that 
can of worms with background rebreak.

Regards,
Asger

Re: [patch] new scrollbar code

[Asger Alstrup]

Alfredo Braunstein wrote:
Small documents are important too.
Sure, I am only noting that it is a feature that only *exists* in small
documents. Thus, it cannot be so fundamentally important.
It serves as important feedback on the size of the document.
Well, we could just keep (maybe outdated) paragraphs sizes, and just update
on-screen ones when drawing. Then the scrollbar computation would be only a
loop over all outer paragraphs. 
Since you mentioned that tables are the biggest problem, I would suggest to 
 come up with a light-weight improved estimate for those, and see how much 
that helps.

Then address images next.
I.e. go down the path outlined in my earlier mail, except that the 
priorities are:

- Tables
- Images
- Paragraph text size
- Other stuff
Only looking at outer paragraphs ignores the two most important ones.
Regards,
Asger

Re: [patch] new scrollbar code

[Asger Alstrup]

Alfredo Braunstein wrote:
I think you didn't understand what I suggested. 

I suggested to do a fullrebreak on start (foreground or background) and then
keep outer paragraphs sizes. Only update sizes when drawing paragraphs
on-screen, and live with outdated sizes for out-of-screen outer paragraphs.
I think that this may work very well.
I agree that this will help a lot, especially if the clipboard does not
throw away the sizes of full paragraphs copied/pasted. And when the window
is resized, we need a full rebreak like in the old days.
Regards,
Asger

Re: LyX archaeology

[Asger Alstrup]

I liked it better with the TOC, and then all the details in one big page, 
without any need for clicking hundreds of small checkboxes and all that.

Regards,
Asger

Re: LyX archaeology

[Asger Alstrup]

I liked it better with the TOC, and then all the details in one big page, 
without any need for clicking hundreds of small checkboxes and all that.

Regards,
Asger

Re: Licensing of tex2lyx (and perhaps LyX itself?)

[Asger Alstrup]

I grant permission to license any and all contributions I've made to LyX 
under any open source license.

Regards,
Asger

Re: Licensing of tex2lyx (and perhaps LyX itself?)

[Asger Alstrup]

John Levon wrote:
On Mon, Feb 21, 2005 at 03:33:23PM +0100, Asger Alstrup wrote:
I grant permission to license any and all contributions I've made to LyX 
under any open source license.
I think you shouuld be a bit more specific (at least, any current and
future licenses accepted as open source by the OSI)
In Denmark, the legal system works in a way where the intent of the 
statement and the context is taken into account when judging a statement in 
a court, so it is strictly not necessary to be more specific.

But I understand that the American and English legal system is different, 
so explicitly, I grant permission to license any and all contributions I've 
made to LyX under the GPL, version 2, or any other current or future 
license accepted as open source by the OSI.

Regards,
Asger

Re: Licensing of tex2lyx (and perhaps LyX itself?)

[Asger Alstrup]

I grant permission to license any and all contributions I've made to LyX 
under any open source license.

Regards,
Asger

Re: Licensing of tex2lyx (and perhaps LyX itself?)

[Asger Alstrup]

John Levon wrote:
On Mon, Feb 21, 2005 at 03:33:23PM +0100, Asger Alstrup wrote:
I grant permission to license any and all contributions I've made to LyX 
under any open source license.
I think you shouuld be a bit more specific (at least, "any current and
future licenses accepted as open source by the OSI")
In Denmark, the legal system works in a way where the intent of the 
statement and the context is taken into account when judging a statement in 
a court, so it is strictly not necessary to be more specific.

But I understand that the American and English legal system is different, 
so explicitly, I grant permission to license any and all contributions I've 
made to LyX under the GPL, version 2, or any other current or future 
license accepted as open source by the OSI.

Regards,
Asger

Re: Change to lyxserver.C breaks win32_kludge.diff patch

[Asger Alstrup]

Here are patches representing the above; it would be helpful if these
could be committed if approved. I've built fresh successfully with these
patches applied.
Maybe you could get karma to commit yourself to the 
lyx-devel\development\win32 directory?

Regards,
Asger

Re: Change to lyxserver.C breaks win32_kludge.diff patch

[Asger Alstrup]

Here are patches representing the above; it would be helpful if these
could be committed if approved. I've built fresh successfully with these
patches applied.
Maybe you could get karma to commit yourself to the 
lyx-devel\development\win32 directory?

Regards,
Asger

Re: What are the main problems in CVS now?

[Asger Alstrup]

Andre Poenitz wrote:
On Mon, Feb 14, 2005 at 05:17:49PM +0100, Jean-Marc Lasgouttes wrote:
If there is interest and if things evolve positively, I may be able to
propose Paris 
Both sound nice. [And in case it matters: I am a bit biased towards
France outside Paris...]
Paris sounds great!
Regards,
Asger

Re: C++ question. Is this safe?

[Asger Alstrup]

Angus Leeming wrote:
That will require an MSVC user (Asger) to check his
std::map::const_iterator implementation.
I'm not sure this is what you are looking for, but here is some of the code 
for the map::const_iterator in MSVC 7.1:

class const_iterator
: public _Biditvalue_type, _Dift, _Ctptr, const_reference
{   // iterator for nonmutable _Tree
public:
_Ctptr operator-() const
{   // return pointer to class object
return (**this);
}
};
where _Ctptr is a constant pointer to the value type of the map (except for 
some voodoo to convert between different allocator types).

Regards,
Asger

Re: C++ question. Is this safe?

[Asger Alstrup]

Angus Leeming wrote:
I read that as saying that the code in the mail at the start of this thread
is perfectly safe, don't you?
Well, we also have:
templateclass _Traits
class _Tree
{
const_iterator find(const key_type _Keyval) const
{   // find an element in nonmutable sequence that matches 
_Keyval
const_iterator _Where = lower_bound(_Keyval);
return (_Where == end() || this-comp(_Keyval, 
_Key(_Where._Mynode()))
? end() : _Where);
}
}
The find method might return a temporary const_iterator, but I can't tell 
whether this is a problem or not.

Regards,
Asger

Re: Squashing some MSVC warnings compiling LyX

[Asger Alstrup]

Angus wrote:
 I wonder if the attached patch will make MSVC happy. Could you test it
 for me?
The result is below.
Regards,
Asger
Compiling...
ExternalTransforms.C
\lyx\lyx-devel\src\insets\ExternalTransforms.C(345) : warning C4239: 
nonstandard extension used : 'argument' : conversion from 
'boost::function1R,T0,Allocator::result_type' to 'std::auto_ptr_Ty '
with
[
R=lyx::external::TransformCommand::ptr_type,
T0=const lyx::external::RotationData ,
Allocator=std::allocatorvoid
]
and
[
_Ty=const lyx::external::TransformCommand
]
A reference that is not to 'const' cannot be bound to a 
non-lvalue; assigment operator takes a reference to non-const
\lyx\lyx-devel\src\insets\ExternalTransforms.C(356) : see 
reference to function template instantiation 'void 
lyx::external::`anonymous-namespace'::extractItlyx::external::RotationCommandFactory,lyx::external::RotationData,lyx::external::TransformCommand::ptr_type(const 
boost::any ,const Data ,Transformer )' being compiled
with
[
Data=lyx::external::RotationData,
Transformer=lyx::external::TransformCommand::ptr_type
]
\lyx\lyx-devel\src\insets\ExternalTransforms.C(345) : warning C4239: 
nonstandard extension used : 'argument' : conversion from 
'boost::function1R,T0,Allocator::result_type' to 'std::auto_ptr_Ty '
with
[
R=lyx::external::TransformCommand::ptr_type,
T0=const lyx::external::ResizeData ,
Allocator=std::allocatorvoid
]
and
[
_Ty=const lyx::external::TransformCommand
]
A reference that is not to 'const' cannot be bound to a 
non-lvalue; assigment operator takes a reference to non-const
\lyx\lyx-devel\src\insets\ExternalTransforms.C(366) : see 
reference to function template instantiation 'void 
lyx::external::`anonymous-namespace'::extractItlyx::external::ResizeCommandFactory,lyx::external::ResizeData,lyx::external::TransformCommand::ptr_type(const 
boost::any ,const Data ,Transformer )' being compiled
with
[
Data=lyx::external::ResizeData,
Transformer=lyx::external::TransformCommand::ptr_type
]
\lyx\lyx-devel\src\insets\ExternalTransforms.C(345) : warning C4239: 
nonstandard extension used : 'argument' : conversion from 
'boost::function1R,T0,Allocator::result_type' to 'std::auto_ptr_Ty '
with
[
R=lyx::external::TransformOption::ptr_type,
T0=const lyx::external::RotationData ,
Allocator=std::allocatorvoid
]
and
[
_Ty=const lyx::external::TransformOption
]
A reference that is not to 'const' cannot be bound to a 
non-lvalue; assigment operator takes a reference to non-const
\lyx\lyx-devel\src\insets\ExternalTransforms.C(376) : see 
reference to function template instantiation 'void 
lyx::external::`anonymous-namespace'::extractItlyx::external::RotationOptionFactory,lyx::external::RotationData,lyx::external::TransformOption::ptr_type(const 
boost::any ,const Data ,Transformer )' being compiled
with
[
Data=lyx::external::RotationData,
Transformer=lyx::external::TransformOption::ptr_type
]
\lyx\lyx-devel\src\insets\ExternalTransforms.C(345) : warning C4239: 
nonstandard extension used : 'argument' : conversion from 
'boost::function1R,T0,Allocator::result_type' to 'std::auto_ptr_Ty '
with
[
R=lyx::external::TransformOption::ptr_type,
T0=const lyx::external::ResizeData ,
Allocator=std::allocatorvoid
]
and
[
_Ty=const lyx::external::TransformOption
]
A reference that is not to 'const' cannot be bound to a 
non-lvalue; assigment operator takes a reference to non-const
\lyx\lyx-devel\src\insets\ExternalTransforms.C(386) : see 
reference to function template instantiation 'void 
lyx::external::`anonymous-namespace'::extractItlyx::external::ResizeOptionFactory,lyx::external::ResizeData,lyx::external::TransformOption::ptr_type(const 
boost::any ,const Data ,Transformer )' being compiled
with
[
Data=lyx::external::ResizeData,
Transformer=lyx::external::TransformOption::ptr_type
]
\lyx\lyx-devel\src\insets\ExternalTransforms.C(345) : warning C4239: 
nonstandard extension used : 'argument' : conversion from 
'boost::function1R,T0,Allocator::result_type' to 'std::auto_ptr_Ty '
with
[
R=lyx::external::TransformOption::ptr_type,
T0=const lyx::external::ClipData ,
Allocator=std::allocatorvoid
]
and
[
_Ty=const lyx::external::TransformOption
]
A reference that is not to 'const' cannot be bound to a 
non-lvalue; assigment operator takes a 

Re: Change to lyxserver.C breaks win32_kludge.diff patch

[Asger Alstrup]

A fixed VS lyxserver.C is attached. When I find the time, I'll update the 
patch.

Regards,
Asger
/**
 * \file lyxserver.C
 * This file is part of LyX, the document processor.
 * Licence details can be found in the file COPYING.
 *
 * \author Lars Gullik Bjønnes
 * \author Jean-Marc Lasgouttes
 * \author Angus Leeming
 * \author John Levon
 *
 * Full author contact details are available in file CREDITS.
 */

/**
  Docu   : To use the lyxserver define the name of the pipe in your
   lyxrc:
   \serverpipe /home/myhome/.lyxpipe
   Then use .lyxpipe.in and .lyxpipe.out to communicate to LyX.
   Each message consists of a single line in ASCII. Input lines
   (client - LyX) have the following format:
LYXCMD:clientname:functionname:argument
   Answers from LyX look like this:
   INFO:clientname:functionname:data
 [asierra970531] Or like this in case of error:
   ERROR:clientname:functionname:error message
   where clientname and functionname are just echoed.
   If LyX notifies about a user defined extension key-sequence,
   the line looks like this:
   NOTIFY:key-sequence
 [asierra970531] New server-only messages to implement a simple protocol
   LYXSRV:clientname:protocol message
   where protocol message can be hello or bye. If hello is
   received LyX will inform the client that it's listening its
   messages, and 'bye' will inform that lyx is closing.

   See development/server_monitor.c for an example client.
  Purpose: implement a client/server lib for LyX
*/

#include config.h

#include lyxserver.h
#include debug.h
#include funcrequest.h
#include LyXAction.h
#include lyxfunc.h
#include support/lstrings.h
#include support/lyxlib.h
#include frontends/lyx_gui.h

#include boost/bind.hpp

#include cerrno
#include sys/stat.h
#include fcntl.h

#ifdef _WIN32
# include support/os_win32.h // F_SETFL, O_NONBLOCK, fcntl
#endif

#ifdef __EMX__
#include cstdlib
#include io.h
#define OS2EMX_PLAIN_CHAR
#define INCL_DOSNMPIPES
#define INCL_DOSERRORS
#include os2.h
#include support/os2_errortable.h
#endif

using lyx::support::compare;
using lyx::support::rtrim;
using lyx::support::split;
using lyx::support::unlink;

using std::endl;
using std::string;


// provide an empty mkfifo() if we do not have one. This disables the
// lyxserver.
#ifndef HAVE_MKFIFO
int mkfifo(char const * __path, mode_t __mode) {
return 0;
}
#endif


void LyXComm::openConnection()
{
lyxerr[Debug::LYXSERVER]  LyXComm: Opening connection  endl;

// If we are up, that's an error
if (ready) {
lyxerr  LyXComm: Already connected  endl;
return;
}
// We assume that we don't make it
ready = false;

if (pipename.empty()) {
lyxerr[Debug::LYXSERVER]
 LyXComm: server is disabled, nothing to do
 endl;
return;
}

if ((infd = startPipe(inPipeName(), false)) == -1)
return;

if ((outfd = startPipe(outPipeName(), true)) == -1) {
endPipe(infd, inPipeName(), false);
return;
}

if (fcntl(outfd, F_SETFL, O_NONBLOCK)  0) {
lyxerr  LyXComm: Could not set flags on pipe   
outPipeName()
'\n'  strerror(errno)  endl;
return;
}

// We made it!
ready = true;
lyxerr[Debug::LYXSERVER]  LyXComm: Connection established  endl;
}


/// Close pipes
void LyXComm::closeConnection()
{
lyxerr[Debug::LYXSERVER]  LyXComm: Closing connection  endl;

if (pipename.empty()) {
lyxerr[Debug::LYXSERVER]
 LyXComm: server is disabled, nothing to do
 endl;
return;
}

if (!ready) {
lyxerr  LyXComm: Already disconnected  endl;
return;
}

endPipe(infd, inPipeName(), false);
endPipe(outfd, outPipeName(), true);

ready = false;
}


int LyXComm::startPipe(string const  filename, bool write)
{
#ifdef __EMX__
HPIPE os2fd;
APIRET rc;
int errnum;
// Try create one instance of named pipe with the mode 
O_RDONLY|O_NONBLOCK.
// The current emx implementation of access() won't work with pipes.
rc = DosCreateNPipe(filename.c_str(), os2fd, NP_ACCESS_INBOUND,
NP_NOWAIT|0x01, 0600, 0600, 0);
if (rc == ERROR_PIPE_BUSY) {
lyxerr  LyXComm: Pipe   filename   already exists.\n
If no other LyX program is active, please delete
 the pipe by hand and try again.  endl;
pipename.erase();
return -1;
}

if (rc != NO_ERROR) {
errnum = TranslateOS2Error(rc);

Re: What are the main problems in CVS now?

[Asger Alstrup]

Andre Poenitz wrote:
On Mon, Feb 14, 2005 at 05:17:49PM +0100, Jean-Marc Lasgouttes wrote:
If there is interest and if things evolve positively, I may be able to
propose Paris 
Both sound nice. [And in case it matters: I am a bit biased towards
France outside Paris...]
Paris sounds great!
Regards,
Asger

Re: C++ question. Is this safe?

[Asger Alstrup]

Angus Leeming wrote:
That will require an MSVC user (Asger) to check his
std::map::const_iterator implementation.
I'm not sure this is what you are looking for, but here is some of the code 
for the map::const_iterator in MSVC 7.1:

class const_iterator
: public _Bidit
{   // iterator for nonmutable _Tree
public:
_Ctptr operator->() const
{   // return pointer to class object
return (&**this);
}
};
where _Ctptr is a constant pointer to the value type of the map (except for 
some voodoo to convert between different allocator types).

Regards,
Asger

Re: C++ question. Is this safe?

[Asger Alstrup]

Angus Leeming wrote:
I read that as saying that the code in the mail at the start of this thread
is perfectly safe, don't you?
Well, we also have:
template
class _Tree
{
const_iterator find(const key_type& _Keyval) const
{   // find an element in nonmutable sequence that matches 
_Keyval
const_iterator _Where = lower_bound(_Keyval);
return (_Where == end() || this->comp(_Keyval, 
_Key(_Where._Mynode()))
? end() : _Where);
}
}
The find method might return a temporary const_iterator, but I can't tell 
whether this is a problem or not.

Regards,
Asger

Re: Squashing some MSVC warnings compiling LyX

[Asger Alstrup]

Angus wrote:
> I wonder if the attached patch will make MSVC happy. Could you test it
> for me?
The result is below.
Regards,
Asger
Compiling...
ExternalTransforms.C
\lyx\lyx-devel\src\insets\ExternalTransforms.C(345) : warning C4239: 
nonstandard extension used : 'argument' : conversion from 
'boost::function1::result_type' to 'std::auto_ptr<_Ty> &'
with
[
R=lyx::external::TransformCommand::ptr_type,
T0=const lyx::external::RotationData &,
Allocator=std::allocator
]
and
[
_Ty=const lyx::external::TransformCommand
]
A reference that is not to 'const' cannot be bound to a 
non-lvalue; assigment operator takes a reference to non-const
\lyx\lyx-devel\src\insets\ExternalTransforms.C(356) : see 
reference to function template instantiation 'void 
lyx::external::`anonymous-namespace'::extractIt(const 
boost::any &,const Data &,Transformer &)' being compiled
with
[
Data=lyx::external::RotationData,
Transformer=lyx::external::TransformCommand::ptr_type
]
\lyx\lyx-devel\src\insets\ExternalTransforms.C(345) : warning C4239: 
nonstandard extension used : 'argument' : conversion from 
'boost::function1::result_type' to 'std::auto_ptr<_Ty> &'
with
[
R=lyx::external::TransformCommand::ptr_type,
T0=const lyx::external::ResizeData &,
Allocator=std::allocator
]
and
[
_Ty=const lyx::external::TransformCommand
]
A reference that is not to 'const' cannot be bound to a 
non-lvalue; assigment operator takes a reference to non-const
\lyx\lyx-devel\src\insets\ExternalTransforms.C(366) : see 
reference to function template instantiation 'void 
lyx::external::`anonymous-namespace'::extractIt(const 
boost::any &,const Data &,Transformer &)' being compiled
with
[
Data=lyx::external::ResizeData,
Transformer=lyx::external::TransformCommand::ptr_type
]
\lyx\lyx-devel\src\insets\ExternalTransforms.C(345) : warning C4239: 
nonstandard extension used : 'argument' : conversion from 
'boost::function1::result_type' to 'std::auto_ptr<_Ty> &'
with
[
R=lyx::external::TransformOption::ptr_type,
T0=const lyx::external::RotationData &,
Allocator=std::allocator
]
and
[
_Ty=const lyx::external::TransformOption
]
A reference that is not to 'const' cannot be bound to a 
non-lvalue; assigment operator takes a reference to non-const
\lyx\lyx-devel\src\insets\ExternalTransforms.C(376) : see 
reference to function template instantiation 'void 
lyx::external::`anonymous-namespace'::extractIt(const 
boost::any &,const Data &,Transformer &)' being compiled
with
[
Data=lyx::external::RotationData,
Transformer=lyx::external::TransformOption::ptr_type
]
\lyx\lyx-devel\src\insets\ExternalTransforms.C(345) : warning C4239: 
nonstandard extension used : 'argument' : conversion from 
'boost::function1::result_type' to 'std::auto_ptr<_Ty> &'
with
[
R=lyx::external::TransformOption::ptr_type,
T0=const lyx::external::ResizeData &,
Allocator=std::allocator
]
and
[
_Ty=const lyx::external::TransformOption
]
A reference that is not to 'const' cannot be bound to a 
non-lvalue; assigment operator takes a reference to non-const
\lyx\lyx-devel\src\insets\ExternalTransforms.C(386) : see 
reference to function template instantiation 'void 
lyx::external::`anonymous-namespace'::extractIt(const 
boost::any &,const Data &,Transformer &)' being compiled
with
[
Data=lyx::external::ResizeData,
Transformer=lyx::external::TransformOption::ptr_type
]
\lyx\lyx-devel\src\insets\ExternalTransforms.C(345) : warning C4239: 
nonstandard extension used : 'argument' : conversion from 
'boost::function1::result_type' to 'std::auto_ptr<_Ty> &'
with
[
R=lyx::external::TransformOption::ptr_type,
T0=const lyx::external::ClipData &,
Allocator=std::allocator
]
and
[
_Ty=const lyx::external::TransformOption
]
A reference that is not to 'const' cannot be bound to a 
non-lvalue; 

Re: Change to lyxserver.C breaks win32_kludge.diff patch

[Asger Alstrup]

A fixed VS lyxserver.C is attached. When I find the time, I'll update the 
patch.

Regards,
Asger
/**
 * \file lyxserver.C
 * This file is part of LyX, the document processor.
 * Licence details can be found in the file COPYING.
 *
 * \author Lars Gullik Bjønnes
 * \author Jean-Marc Lasgouttes
 * \author Angus Leeming
 * \author John Levon
 *
 * Full author contact details are available in file CREDITS.
 */

/**
  Docu   : To use the lyxserver define the name of the pipe in your
   lyxrc:
   \serverpipe "/home/myhome/.lyxpipe"
   Then use .lyxpipe.in and .lyxpipe.out to communicate to LyX.
   Each message consists of a single line in ASCII. Input lines
   (client -> LyX) have the following format:
"LYXCMD:::"
   Answers from LyX look like this:
   "INFO:::"
 [asierra970531] Or like this in case of error:
   "ERROR:::"
   where  and  are just echoed.
   If LyX notifies about a user defined extension key-sequence,
   the line looks like this:
   "NOTIFY:"
 [asierra970531] New server-only messages to implement a simple protocol
   "LYXSRV::"
   where  can be "hello" or "bye". If hello is
   received LyX will inform the client that it's listening its
   messages, and 'bye' will inform that lyx is closing.

   See development/server_monitor.c for an example client.
  Purpose: implement a client/server lib for LyX
*/

#include 

#include "lyxserver.h"
#include "debug.h"
#include "funcrequest.h"
#include "LyXAction.h"
#include "lyxfunc.h"
#include "support/lstrings.h"
#include "support/lyxlib.h"
#include "frontends/lyx_gui.h"

#include 

#include 
#include 
#include 

#ifdef _WIN32
# include "support/os_win32.h" // F_SETFL, O_NONBLOCK, fcntl
#endif

#ifdef __EMX__
#include 
#include 
#define OS2EMX_PLAIN_CHAR
#define INCL_DOSNMPIPES
#define INCL_DOSERRORS
#include 
#include "support/os2_errortable.h"
#endif

using lyx::support::compare;
using lyx::support::rtrim;
using lyx::support::split;
using lyx::support::unlink;

using std::endl;
using std::string;


// provide an empty mkfifo() if we do not have one. This disables the
// lyxserver.
#ifndef HAVE_MKFIFO
int mkfifo(char const * __path, mode_t __mode) {
return 0;
}
#endif


void LyXComm::openConnection()
{
lyxerr[Debug::LYXSERVER] << "LyXComm: Opening connection" << endl;

// If we are up, that's an error
if (ready) {
lyxerr << "LyXComm: Already connected" << endl;
return;
}
// We assume that we don't make it
ready = false;

if (pipename.empty()) {
lyxerr[Debug::LYXSERVER]
<< "LyXComm: server is disabled, nothing to do"
<< endl;
return;
}

if ((infd = startPipe(inPipeName(), false)) == -1)
return;

if ((outfd = startPipe(outPipeName(), true)) == -1) {
endPipe(infd, inPipeName(), false);
return;
}

if (fcntl(outfd, F_SETFL, O_NONBLOCK) < 0) {
lyxerr << "LyXComm: Could not set flags on pipe " << 
outPipeName()
   << '\n' << strerror(errno) << endl;
return;
}

// We made it!
ready = true;
lyxerr[Debug::LYXSERVER] << "LyXComm: Connection established" << endl;
}


/// Close pipes
void LyXComm::closeConnection()
{
lyxerr[Debug::LYXSERVER] << "LyXComm: Closing connection" << endl;

if (pipename.empty()) {
lyxerr[Debug::LYXSERVER]
<< "LyXComm: server is disabled, nothing to do"
<< endl;
return;
}

if (!ready) {
lyxerr << "LyXComm: Already disconnected" << endl;
return;
}

endPipe(infd, inPipeName(), false);
endPipe(outfd, outPipeName(), true);

ready = false;
}


int LyXComm::startPipe(string const & filename, bool write)
{
#ifdef __EMX__
HPIPE os2fd;
APIRET rc;
int errnum;
// Try create one instance of named pipe with the mode 
O_RDONLY|O_NONBLOCK.
// The current emx implementation of access() won't work with pipes.
rc = DosCreateNPipe(filename.c_str(), , NP_ACCESS_INBOUND,
NP_NOWAIT|0x01, 0600, 0600, 0);
if (rc == ERROR_PIPE_BUSY) {
lyxerr << "LyXComm: Pipe " << filename << " already exists.\n"
   << "If no other LyX program is active, please delete"
" the pipe by hand and try again." << endl;
pipename.erase();
return -1;
}

if (rc != NO_ERROR) {
errnum = TranslateOS2Error(rc);
lyxerr <<"LyXComm: Could not create pipe " << filename
   << strerror(errnum) << endl;

Re: [PATCH] (Re: [PATCH] UI: matrix partitioning)

[Asger Alstrup]

Martin Vermeer wrote:
See attached patch, which has been on the list for a few days.
Technically, you posted the first version of this before the freeze was 
announced, so I think it's fair to put it in, also considering the number 
of revisions you have made.

Regards,
Asger

Re: [PATCH] (Re: [PATCH] UI: matrix partitioning)

[Asger Alstrup]

Martin Vermeer wrote:
See attached patch, which has been on the list for a few days.
Technically, you posted the first version of this before the freeze was 
announced, so I think it's fair to put it in, also considering the number 
of revisions you have made.

Regards,
Asger

Re: [Patch] Make vector a member of doiterator

[Asger Alstrup]

Lars Gullik Bjønnes wrote:
This patch changes dociterator to not inherit from vector, the vector
is now a private member instead.
I agree, this is a step forward.
Regards,
Asger

Re: [Patch] Make vector a member of doiterator

[Asger Alstrup]

Lars Gullik Bjønnes wrote:
This patch changes dociterator to not inherit from vector, the vector
is now a private member instead.
I agree, this is a step forward.
Regards,
Asger

Real fake leaks

[Asger Alstrup]

Hi,
I ran BoundsChecker on the LyX executable loading the user guide and then 
exiting.

There are many problems in Qt free, but also some in LyX itself.
Qt free has thousands of GDI problems, but since I did not compile Qt with 
debugging info, I do not have any call stacks for those.

Regarding memory reports, there are also a lot. Most of the reports are 
probably fakes, though. It seems that Boundschecker does not really 
understand boost::smart_ptr, but if you care, take a look.

Regards,
Asger


leaks.txt.bz2
Description: Binary data

Real & fake leaks

[Asger Alstrup]

Hi,
I ran BoundsChecker on the LyX executable loading the user guide and then 
exiting.

There are many problems in Qt free, but also some in LyX itself.
Qt free has thousands of GDI problems, but since I did not compile Qt with 
debugging info, I do not have any call stacks for those.

Regarding memory reports, there are also a lot. Most of the reports are 
probably fakes, though. It seems that Boundschecker does not really 
understand boost::smart_ptr, but if you care, take a look.

Regards,
Asger


leaks.txt.bz2
Description: Binary data

Re: Current LyX 1.4.0 crashes with preview

[Asger Alstrup]

Andreas Vox wrote:
MacAqua crashes without user intervention when I open a file
with math previews. Appearently BufferView::pimpl::update()
calls itself indirectly between startUpdating() and doneUpdating().
Which propagates the imageReady()-events to RenderPreview
which in turn calls updateInset() ...
I triggered this yesterday as well. I have a fix handy, which I'll commit 
shortly.
Until then, you can safely remove the assert in CoordCache::doneUpdating.

Regards,
Asger

Re: Current LyX 1.4.0 crashes with preview

[Asger Alstrup]

Andreas Vox wrote:
MacAqua crashes without user intervention when I open a file
with math previews. Appearently BufferView::pimpl::update()
calls itself indirectly between startUpdating() and doneUpdating().
Which propagates the imageReady()-events to RenderPreview
which in turn calls updateInset() ...
I triggered this yesterday as well. I have a fix handy, which I'll commit 
shortly.
Until then, you can safely remove the assert in CoordCache::doneUpdating.

Regards,
Asger

Re:

[Asger Alstrup]

Andre Poenitz wrote:
I the long run I think the coord cache should really be cache. It isn't
right now as we sometimes depend on certain values being present. 
I have added some logic so it is easier to detect such errors. I see that 
during update, we rely on some coordinates to be there, when the cursor is 
drawn. Other than that, it seems that the usage of coordCache is pretty 
good. (I did not try with the user guide, because noone sent me one in the 
latest format, and I'm too lazy to install Python.)

To find all these places and replace them by sensible code is no 1.4
business as far as I am concerned, so at the moment, DEPM probably has
to make sure that the cache is in no worse condition then before the
DEPM call.
OK, I propose to add an invalidate method to the cache, and use this to 
flag whether a refresh is needed. The DEPM will set this flag. When I find 
time, I'll implement such a fix, unless someone else beats me to it.

Regards,
Asger

Re:

[Asger Alstrup]

Andre Poenitz wrote:
I the long run I think the coord cache should really be cache. It isn't
right now as we sometimes depend on certain values being present. 
I have added some logic so it is easier to detect such errors. I see that 
during update, we rely on some coordinates to be there, when the cursor is 
drawn. Other than that, it seems that the usage of coordCache is pretty 
good. (I did not try with the user guide, because noone sent me one in the 
latest format, and I'm too lazy to install Python.)

To find all these places and replace them by sensible code is no 1.4
business as far as I am concerned, so at the moment, DEPM probably has
to make sure that the cache is in no worse condition then before the
DEPM call.
OK, I propose to add an "invalidate" method to the cache, and use this to 
flag whether a refresh is needed. The DEPM will set this flag. When I find 
time, I'll implement such a fix, unless someone else beats me to it.

Regards,
Asger

[Fwd: Help]

[Asger Alstrup Nielsen]

 


dear sir,

what must I do that upgrade my LyX 1.0.3 to LyX 1.1.5Pre1?
FreeBSD 3.3 Stable
I've unpacked and begun "make install",it was writenn "don't how make"
I 've begun "./configure",I've got next
that libXpm and libxforms(libforms) is not on this operating system.
I check and find taht all libs was installed.Libforms 0.88

What can I do?

Yours sincerelly Alex

[Fwd: Help]

[Asger Alstrup Nielsen]

 


dear sir,

what must I do that upgrade my LyX 1.0.3 to LyX 1.1.5Pre1?
FreeBSD 3.3 Stable
I've unpacked and begun "make install",it was writenn "don't how make"
I 've begun "./configure",I've got next
that libXpm and libxforms(libforms) is not on this operating system.
I check and find taht all libs was installed.Libforms 0.88

What can I do?

Yours sincerelly Alex

README is out of date

[Asger Alstrup Nielsen]

Hi,

My attention was brought to the fact that the README in 1.1.4 is
out-of-date. It says that even version numbers are stable, and odd
numbers are development versions.

That causes some confusing, so maybe somebody will mend that when they
do a maintaince commit anyway.

Greets,

Asger

README is out of date

[Asger Alstrup Nielsen]

Hi,

My attention was brought to the fact that the README in 1.1.4 is
out-of-date. It says that even version numbers are stable, and odd
numbers are development versions.

That causes some confusing, so maybe somebody will mend that when they
do a maintaince commit anyway.

Greets,

Asger

[Fwd: links on lyx-homepage]

[Asger Alstrup Nielsen]

 


hey,

somebody told you, that the links to the 1.1.4-patches on the
lyx-homepage are wrong??
they are pointing to .../pub/lyx/devel/..., but i found the patches on
.../pub/lyx/stable/...

just an info

greetings
Jörg

[Fwd: links on lyx-homepage]

[Asger Alstrup Nielsen]

 


hey,

somebody told you, that the links to the 1.1.4-patches on the
lyx-homepage are wrong??
they are pointing to .../pub/lyx/devel/..., but i found the patches on
.../pub/lyx/stable/...

just an info

greetings
Jörg

[Fwd: problem with lyx1.1.4]

[Asger Alstrup Nielsen]

 


hello,
   I' m an italian user of lyx. During lyx 1.1.4 configuration onto
linux Red Hat 6.1 i discovered that may system doesn' t have the
- libforms or libxforms
- forms.h
If you have understand my problem please send me the complete web
address where I can take them from...
In the Install Guide there are a lot of ftp address but I can' t find
them.
Please Help Me because I need Lyx to Write my Doctorand Degree.
Sincerely
S. G.

[Fwd: problem with lyx1.1.4]

[Asger Alstrup Nielsen]

 


hello,
   I' m an italian user of lyx. During lyx 1.1.4 configuration onto
linux Red Hat 6.1 i discovered that may system doesn' t have the
- libforms or libxforms
- forms.h
If you have understand my problem please send me the complete web
address where I can take them from...
In the Install Guide there are a lot of ftp address but I can' t find
them.
Please Help Me because I need Lyx to Write my Doctorand Degree.
Sincerely
S. G.

[Fwd: LyX on Debian]

[Asger Alstrup Nielsen]

 


Hi,

I used LyX on RedHat without problems, but on Debian it works as well, but can't use 
Latex. 
It says while compiling that latex was found (it is there) but it is not usable.

Do you know that as common problem ?

Every thing is installed fine regarding my Debian system.


Marko

[Fwd: LyX on Debian]

[Asger Alstrup Nielsen]

 


Hi,

I used LyX on RedHat without problems, but on Debian it works as well, but can't use 
Latex. 
It says while compiling that latex was found (it is there) but it is not usable.

Do you know that as common problem ?

Every thing is installed fine regarding my Debian system.


Marko

[Fwd: LyX customisation]

[Asger Alstrup Nielsen]

 Original Message 
Subject: LyX customisation
Date: Tue, 16 Nov 1999 14:09:31 +0200
From: Akos Maroy [EMAIL PROTECTED]
Organization: Innovative Ideas Oy
To: [EMAIL PROTECTED]

Hi,

I'm using LyX for a variaty of purposes. So far, the document types
included have been enough for me, but now I need to get beyond that.
Unfortunately I can't find any documenation on how to make my own
document type, how to define them, etc.

Am I missing something?

[Fwd: LyX customisation]

[Asger Alstrup Nielsen]

 Original Message 
Subject: LyX customisation
Date: Tue, 16 Nov 1999 14:09:31 +0200
From: Akos Maroy <[EMAIL PROTECTED]>
Organization: Innovative Ideas Oy
To: [EMAIL PROTECTED]

Hi,

I'm using LyX for a variaty of purposes. So far, the document types
included have been enough for me, but now I need to get beyond that.
Unfortunately I can't find any documenation on how to make my own
document type, how to define them, etc.

Am I missing something?

[Fwd: how to compile]

[Asger Alstrup Nielsen]

 


Dear Sir , I was trying to compile the lyx from sources; downloading the
xforms, too, from the official site. Here there are two .tar files for
the 0.88 version, one for the libc, and the other for the libc2,
libraries. So, in a linux/debian/slink, and with the first xforms
version the compiling of lyx works, but that is not true with the second
xforms release. With the binaries of lyx downloaded and this second file
of xforms the system cries. (It doesn't resolve a symbol from the
xforms, it seems to me). I presume I did a mistake in the compiling but
I would like to known, if it is possible, wich one.
Could you help me?.

yours faithfully.

Juan S. Medina-Alvarez.

[EMAIL PROTECTED]

[Fwd: how to compile]

[Asger Alstrup Nielsen]

 


Dear Sir , I was trying to compile the lyx from sources; downloading the
xforms, too, from the official site. Here there are two .tar files for
the 0.88 version, one for the libc, and the other for the libc2,
libraries. So, in a linux/debian/slink, and with the first xforms
version the compiling of lyx works, but that is not true with the second
xforms release. With the binaries of lyx downloaded and this second file
of xforms the system cries. (It doesn't resolve a symbol from the
xforms, it seems to me). I presume I did a mistake in the compiling but
I would like to known, if it is possible, wich one.
Could you help me?.

yours faithfully.

Juan S. Medina-Alvarez.

[EMAIL PROTECTED]

[Fwd: Fancyboxes in LyX?]

[Asger Alstrup Nielsen]

 


Dear Sir/Madam

Is it possible to have fanyboxes in LyX?  Like what one can get with the
style file fancybox.sty?  Actually I tried, and got it as long as there
is no power or fraction inside the box, but as soon as one of them is
included, it doesn't work.

Sincerely,
Amir M. Abolghasem

[Fwd: Fancyboxes in LyX?]

[Asger Alstrup Nielsen]

 


Dear Sir/Madam

Is it possible to have fanyboxes in LyX?  Like what one can get with the
style file fancybox.sty?  Actually I tried, and got it as long as there
is no power or fraction inside the box, but as soon as one of them is
included, it doesn't work.

Sincerely,
Amir M. Abolghasem

Re: install of cvs tree - autoconf/make problems

[Asger Alstrup Nielsen]

 I checked out the latest cvs version.
 After a cd config the readme tells me not to try
 to run it manually, though the makefile it
 talks about is not distributed via cvs.

In the INSTALL file, it tells to run the "autogen.sh" script when you
use the lyx-devel cvs checkout.
In order for this script to work, you have to have autoconf, automake
and gettext installed correctly.

 Probably I'm just disqualifying myself to further cvs checkout
 lyx-_devel_ ... anyway

Not at all.  Please give it a spin and report bugs here.  We rely on
volunteers to help out testing LyX.

Greets,

Asger

Re: install of cvs tree - autoconf/make problems

[Asger Alstrup Nielsen]

> I checked out the latest cvs version.
> After a cd config the readme tells me not to try
> to run it manually, though the makefile it
> talks about is not distributed via cvs.

In the INSTALL file, it tells to run the "autogen.sh" script when you
use the lyx-devel cvs checkout.
In order for this script to work, you have to have autoconf, automake
and gettext installed correctly.

> Probably I'm just disqualifying myself to further cvs checkout
> lyx-_devel_ ... anyway

Not at all.  Please give it a spin and report bugs here.  We rely on
volunteers to help out testing LyX.

Greets,

Asger

Re: Kernel 0.7: Last release before ~M

[Asger Alstrup Nielsen]

 All good reasons but make sure you give consideration to _why_ you
 need to identify insets.  And then think long and hard about what
 happens when you add a new inset.  How will that affect the code?  If
 you find you are using dynamic_cast as a sort of switch statement or
 if..else if..else if.. structure then we need a better scheme.

Well, I think this scheme is the simplest imaginable. We do not require
any special things in the insets (called elements now ;-), and it works
with a class hierarchy.

 I'll again recommend trying to find a copy of "More Effective C++" by
 Scoot Meyers.  He covers several schemes to mimimise the need for
 rtti.  These mainly involve demonstrating how to view the problem from
 a different angle so that rtti is either no longer necessary or is
 more maintainable.  I'm pretty sure its item 31.

If we assume that compilers can handle RTTI, I think this is the best
solution for the problem at hand. Scott Meyers deals with a different
situation where RTTI is not implemented efficiently. In that case, some
of his methods might make sense.
For LyX, I think we should stick with RTTI simply because it is the
simplest solution, provided that we solve the portability problem.

Greets,

Asger
P.S. Kernel 0.7 is not the most current one. We fixed some bugs in that
in the version that was introduced into the LyX development version. In
that process, we had to rename Inset to Element in order to avoid name
clashes, and thus, the Insets in the data structure are now called
Elements.  That also makes the Inset term free for the more specific
concept similar to what we have in the 1.0.x branch.

Re: Kernel 0.7: Last release before ~M

[Asger Alstrup Nielsen]

> All good reasons but make sure you give consideration to _why_ you
> need to identify insets.  And then think long and hard about what
> happens when you add a new inset.  How will that affect the code?  If
> you find you are using dynamic_cast<> as a sort of switch statement or
> if..else if..else if.. structure then we need a better scheme.

Well, I think this scheme is the simplest imaginable. We do not require
any special things in the insets (called elements now ;-), and it works
with a class hierarchy.

> I'll again recommend trying to find a copy of "More Effective C++" by
> Scoot Meyers.  He covers several schemes to mimimise the need for
> rtti.  These mainly involve demonstrating how to view the problem from
> a different angle so that rtti is either no longer necessary or is
> more maintainable.  I'm pretty sure its item 31.

If we assume that compilers can handle RTTI, I think this is the best
solution for the problem at hand. Scott Meyers deals with a different
situation where RTTI is not implemented efficiently. In that case, some
of his methods might make sense.
For LyX, I think we should stick with RTTI simply because it is the
simplest solution, provided that we solve the portability problem.

Greets,

Asger
P.S. Kernel 0.7 is not the most current one. We fixed some bugs in that
in the version that was introduced into the LyX development version. In
that process, we had to rename Inset to Element in order to avoid name
clashes, and thus, the Insets in the data structure are now called
Elements.  That also makes the Inset term free for the more specific
concept similar to what we have in the 1.0.x branch.

Re: handling evil stuff in mathed (and simplifying the lexer too :-).

[Asger Alstrup Nielsen]

 mathed's lexer has some really stupid hacks in it. Following TeX on what is a

 macro makes the code *much* simpler and would eliminate even more if I could 
 rebuild math_hash.C (the CVS sources seem to lack to input to gperf). All the

 change required is to put the first character after the \ in the macro name 
 before checking whether it is a letter (just like TeX does). Doing this
allows 
 the special cases handling things like \, to be nuked and , to be placed in 
 math_hash.C's list instead.

Alejandro has spoken of rewriting the math parser in LyX for some time, and a
few years back, we planned to built a completely new C++ parser for LaTeX in
LyX, and even started some of the work using PCCTS.
In the meantime, Amir Karger started to write reLyX, and showed significant
progress very fast. So the math parser rewrite never got finished because it
wasn't that important any longer.
Maybe things in that area died too much.  We have been following other
objectives, and Alejandro has done some terrific work to improve other areas of
mathed that needed more focus.  Now mathed has matured substantially in
general, and the original parser is starting to become a priority area worth
improving, when you have to point at something that needs improvement (along
with better fonts on the screen, but that's scheduled to be addressed in the
kernel rewrite.  The design is more or less done, but the implementation still
lacking.)
You are more than welcome to start improving that parser, if you have the time.
I don't know if Alejandro still have the files for gperf, but if not, it should
hopefuly not be too hard to reconstruct them.

Alejandro, any thoughts on mathed parser work?  Do you have any hints for
Duncan that could make things easier?

Greets,

Asger

Re: lyxserver development

[Asger Alstrup Nielsen]

 I am working on a LyX client, and I have suggested a small change in the
 LyX server in order to make client implementation easier. 

 If you think it's worth it, I will submit the following to this list:

[Lots of great stuff]

Of course it is worth it!  The earlier you send this, the better ;-)
If the patch looks good, I still think we should put it into 1.0.4, along with
the SGML export José is working on. Then the 1.0.x series will be very feature
complete, and hopefully good enough to last the long time it will take to
develop the next generation LyX.

 I still have one concern with the LyX server code but I don't want to
 abuse of your patience any longer. I will speak of this another time.

I have patience to hear what the problem is now.  I see no reason to hold
anything relevant back.

Greets,

Asger

Re: handling evil stuff in mathed (and simplifying the lexer too :-).

[Asger Alstrup Nielsen]

> mathed's lexer has some really stupid hacks in it. Following TeX on what is a

> macro makes the code *much* simpler and would eliminate even more if I could 
> rebuild math_hash.C (the CVS sources seem to lack to input to gperf). All the

> change required is to put the first character after the \ in the macro name 
> before checking whether it is a letter (just like TeX does). Doing this
allows 
> the special cases handling things like \, to be nuked and , to be placed in 
> math_hash.C's list instead.

Alejandro has spoken of rewriting the math parser in LyX for some time, and a
few years back, we planned to built a completely new C++ parser for LaTeX in
LyX, and even started some of the work using PCCTS.
In the meantime, Amir Karger started to write reLyX, and showed significant
progress very fast. So the math parser rewrite never got finished because it
wasn't that important any longer.
Maybe things in that area died too much.  We have been following other
objectives, and Alejandro has done some terrific work to improve other areas of
mathed that needed more focus.  Now mathed has matured substantially in
general, and the original parser is starting to become a priority area worth
improving, when you have to point at something that needs improvement (along
with better fonts on the screen, but that's scheduled to be addressed in the
kernel rewrite.  The design is more or less done, but the implementation still
lacking.)
You are more than welcome to start improving that parser, if you have the time.
I don't know if Alejandro still have the files for gperf, but if not, it should
hopefuly not be too hard to reconstruct them.

Alejandro, any thoughts on mathed parser work?  Do you have any hints for
Duncan that could make things easier?

Greets,

Asger

Re: lyxserver development

[Asger Alstrup Nielsen]

> I am working on a LyX client, and I have suggested a small change in the
> LyX server in order to make client implementation easier. 

> If you think it's worth it, I will submit the following to this list:

[Lots of great stuff]

Of course it is worth it!  The earlier you send this, the better ;-)
If the patch looks good, I still think we should put it into 1.0.4, along with
the SGML export José is working on. Then the 1.0.x series will be very feature
complete, and hopefully good enough to last the long time it will take to
develop the next generation LyX.

> I still have one concern with the LyX server code but I don't want to
> abuse of your patience any longer. I will speak of this another time.

I have patience to hear what the problem is now.  I see no reason to hold
anything relevant back.

Greets,

Asger

Re: Y2k Status of Lyx

[Asger Alstrup Nielsen]

 When you say "We..." are you talking to the lyx-devel team or are you
 including me in that pronoun?

I'm talking everybody.  If you are ready to audit LyX, go ahead and tell us the
result.

If not, maybe one of the team will do it at some point.  It will take a few
hours, and we have more than half a year, so it's not urgent, IMO. It think it
will happen before Y2K.

Greets,

Asger

Re: Y2k Status of Lyx

[Asger Alstrup Nielsen]

> When you say "We..." are you talking to the lyx-devel team or are you
> including me in that pronoun?

I'm talking everybody.  If you are ready to audit LyX, go ahead and tell us the
result.

If not, maybe one of the team will do it at some point.  It will take a few
hours, and we have more than half a year, so it's not urgent, IMO. It think it
will happen before Y2K.

Greets,

Asger

Re: Y2k Status of Lyx

[Asger Alstrup Nielsen]

 Only any it inherits from the underlying OS :)

In theory, LyX could implement Y2K problems of it's own.  That's not hard to do
;-)

We should do an audit on all date/time handling in the source.  It's a small
job to do, because LyX does not use dates for much. I think the only potential
places are regarding auto-save, emergency saves, and other areas where we look
at the timestamps of files. I would be surprised if we had any Y2K problems
there, but of course we should check.

Without an audit, you can't be sure, and if you really want to be sure, you
should do your own auditing and testing.

My personal belief is that we are Y2K safe, but I'm not ready to take the blame
if something turns up.

Greets,

Asger

Re: lyx-1.0.3 compile fails on Solaris 2.6 with Sun CC 5.0

[Asger Alstrup Nielsen]

 Jochen "../src/lyx_main.C", line 148: Warning (Anachronism): Formal
 Jochen argument 2 of type extern "C" void(*)(int) in call to
 Jochen signal(int, extern "C" void(*)(int)) is being passed
 Jochen void(*)(int).  [...]  "lyxvc.C", line 337: Warning
 Jochen (Anachronism): Formal argument 2 of type extern "C"
 Jochen int(*)(forms_*,void*) in call to fl_set_form_atclose(forms_*,
 Jochen extern "C" int(*)(forms_*,void*), void*) is being passed
 Jochen int(*)(forms_*,void*).
 
 I do not really know what to do with those.

Judging from the warning text, it seems we are passing C++ functions as C
functions.  I suppose that might not work on some platforms, so we should
define C style linking for those callback functions.

I.e. if we have 

--
int foo(int bar) {
...
}

fl_set_form_atclose(blah, foo);
--

we should do

--
extern "C" int foo(int bar) {

}

fl_set_form_atclose(blah, foo);
--

instead.


In theory, the function start and exit code for a C function could be different
from the C++ equivalent one, but I doubt this happens in practice.  But I'm not
sure whether or not the C++ language should be able to perform the proper
wrapping (if needed) by itself or not, but it would not harm if we fixed this.
(Provided that the functions are global, and not member functions in which case
we are in trouble.)

Greets,

Asger

Re: Y2k Status of Lyx

[Asger Alstrup Nielsen]

> Only any it inherits from the underlying OS :)

In theory, LyX could implement Y2K problems of it's own.  That's not hard to do
;-)

We should do an audit on all date/time handling in the source.  It's a small
job to do, because LyX does not use dates for much. I think the only potential
places are regarding auto-save, emergency saves, and other areas where we look
at the timestamps of files. I would be surprised if we had any Y2K problems
there, but of course we should check.

Without an audit, you can't be sure, and if you really want to be sure, you
should do your own auditing and testing.

My personal belief is that we are Y2K safe, but I'm not ready to take the blame
if something turns up.

Greets,

Asger

Re: lyx-1.0.3 compile fails on Solaris 2.6 with Sun CC 5.0

[Asger Alstrup Nielsen]

> Jochen> "../src/lyx_main.C", line 148: Warning (Anachronism): Formal
> Jochen> argument 2 of type extern "C" void(*)(int) in call to
> Jochen> signal(int, extern "C" void(*)(int)) is being passed
> Jochen> void(*)(int).  [...]  "lyxvc.C", line 337: Warning
> Jochen> (Anachronism): Formal argument 2 of type extern "C"
> Jochen> int(*)(forms_*,void*) in call to fl_set_form_atclose(forms_*,
> Jochen> extern "C" int(*)(forms_*,void*), void*) is being passed
> Jochen> int(*)(forms_*,void*).
> 
> I do not really know what to do with those.

Judging from the warning text, it seems we are passing C++ functions as C
functions.  I suppose that might not work on some platforms, so we should
define C style linking for those callback functions.

I.e. if we have 

--
int foo(int bar) {
...
}

fl_set_form_atclose(blah, );
--

we should do

--
extern "C" int foo(int bar) {

}

fl_set_form_atclose(blah, );
--

instead.


In theory, the function start and exit code for a C function could be different
from the C++ equivalent one, but I doubt this happens in practice.  But I'm not
sure whether or not the C++ language should be able to perform the proper
wrapping (if needed) by itself or not, but it would not harm if we fixed this.
(Provided that the functions are global, and not member functions in which case
we are in trouble.)

Greets,

Asger

Re: LyX crash

[Asger Alstrup Nielsen]

 On the other hand, the LString class could try to test when this count
 becomes too large and create a new string instance.

Fixing the bug will add a little run-time overhead, but string assignment will
still be constant time, so I think it's safe to fix this. I don't have time
these days.

For starters, it could be added to BUGS. After all, it only affects power users
that use huge documents. This is the first report where it struck in real life,
and not as a stress test, AFAIK.

Herbert, how big are those documents?  ;-)

Greets,

Asger

Re: FAQ sort of question

[Asger Alstrup Nielsen]

 On a 640x480 pixel display running at a virtual size 1024x900, the lyx
 screen is too large, so the right margin is not visible. I can resize
 the screen, losing a few buttons after start-up, but can't find a way to
 get it to start up at that size. No help from INSTALL or Customization,
 Introduction, Reference, Extended, or Tutorial. -geometry does not work.
 This is on Alice's box, which seh likes because it has a BW display. If
 anybody has any ideas, I really need them.

man lyx.

I forget the exact syntax, but LyX does support setting the size of the
start-up window, and also the position. You can even do it using the X11
resource database.

Maybe we should add the -geometry command line variant as well? After all, this
is a FAQ.

Greets,

Asger

Re: [pinard@progiciels-bpi.ca: Release: Free recode 3.5]

[Asger Alstrup Nielsen]

 Could this be of some help for the encoding business? In particular,
 reocde can emit header files which may be useful.

Yes, this looks good.  I'll look into it when I get the time.

Greets,

Asger

Re: LyX crash

[Asger Alstrup Nielsen]

> On the other hand, the LString class could try to test when this count
> becomes too large and create a new string instance.

Fixing the bug will add a little run-time overhead, but string assignment will
still be constant time, so I think it's safe to fix this. I don't have time
these days.

For starters, it could be added to BUGS. After all, it only affects power users
that use huge documents. This is the first report where it struck in real life,
and not as a stress test, AFAIK.

Herbert, how big are those documents?  ;-)

Greets,

Asger

Re: FAQ sort of question

[Asger Alstrup Nielsen]

> On a 640x480 pixel display running at a virtual size 1024x900, the lyx
> screen is too large, so the right margin is not visible. I can resize
> the screen, losing a few buttons after start-up, but can't find a way to
> get it to start up at that size. No help from INSTALL or Customization,
> Introduction, Reference, Extended, or Tutorial. -geometry does not work.
> This is on Alice's box, which seh likes because it has a B display. If
> anybody has any ideas, I really need them.

man lyx.

I forget the exact syntax, but LyX does support setting the size of the
start-up window, and also the position. You can even do it using the X11
resource database.

Maybe we should add the -geometry command line variant as well? After all, this
is a FAQ.

Greets,

Asger

Re: [pinard@progiciels-bpi.ca: Release: Free recode 3.5]

[Asger Alstrup Nielsen]

> Could this be of some help for the encoding business? In particular,
> reocde can emit header files which may be useful.

Yes, this looks good.  I'll look into it when I get the time.

Greets,

Asger

Re: lyxserver bug (maybe) and thoughts

[Asger Alstrup Nielsen]

 This would be perfectly ok for me. BTW, since you speak of backward
 compatibility, I assume that people have written other lyx clients (apart
 from servermonitor.c in the lyx sources). I would like very much to see
 the code of some of them so I can improve my code, e.g. when it comes to
 error checking, portability or simply cleanness. 

Check the How To Get it page at http://www.lyx.org/getit.html and check out
gBib and tclBibText (or something like that.)
Both of these connect to LyX to insert Bibtex references.

 Otherwise, I could simply conform to what the lyxserver does now, i.e. not
 writing anything in the out pipe if a command that returns no data
 succeeds. In this case, I do not fully understand how to check wheter a
 command returning no data has succeeded or not. The only way I know of is
 using select(2) to watch status changes in .lyxpipe.out, is that right?
 If the status has not changed, than lyx hasn't written anything, therefore
 no error occurred. 

You could do a hack:  Send a command to LyX that has no ill side-effects, but
returns something (like where the cursor is), and if you get the result
immediately, you know that the previous command succeeded.
Actually, this trick could spare us from modifying the protocol.

Greets,

Asger

Re: lyxserver bug (maybe) and thoughts

[Asger Alstrup Nielsen]

 What I gathered upon first reading of the Lyx Server chapter in the
 customization docs was indeed that a message was always issued to notify
 clients. From that document:

   
 "The answer from LyX will arrive in the output pipe and be of the form
 
 INFO:clientname:function:data

Don't put too much credit to the documentation :-)  
I know it might have bugs, because I rewrote most of it when I cleaned up the
LyX server, and before I did that, the documentation for sure had lots of bugs.
;-)

But, if gBib and the tclBib tool does not rely on the pipe-out, I say just
change the code to always send something out.

Like Lgb says:  Let's focus on getting the sockets one right in 1.1, and just
get on with life.

So my opinion is this:  I don't really care provided that we don't break any
applications.  If you feel like changing it, do it.  If you think you can
manage with the query-hack, do that.  Just update the documentation accordingly
;-)

So, it's up to Stefano and Jean-Marc, IMO.

Greets,

Asger

Re: lyxserver bug (maybe) and thoughts

[Asger Alstrup Nielsen]

 bla bla safe change bla bla... how many times have we said that made
 the fix and then we discovers bugs because of it?

Many times.

Also, many times, good things have come.  We make mistakes from time to time. 
But that should not stop us from making changes, IMO.  If we are too afraid to
change the code, nothing will happen, or at least things will go slow.  Compare
with the egcs/gcc development models.

I understand that 1.0.3 is important because 1.0.2 is bugged.  So release 1.0.3
now as it is, and we'll have more time to consider the lyx-server-stuff for
1.0.4 when we have the patch.  1.0.4 will require a long debugging period
anyway.

 then what is the real proplem.

Stefano can't build the library in a clean way.

Greets,

Asger

Re: lyxserver bug (maybe) and thoughts

[Asger Alstrup Nielsen]

 We should be very restrictive on what we call a bug at this point, the
 '\n' that Jean-Marc added is obvious, changing _any_ part of the
 protocol is not.

Well, I consider the change a bug-fix. The protocol is after all broken, and
should be fixed.

Also, it is a safe change.  The two main existing LyX-server applications are
unaffected, and we have the perspective of getting many more LyX server
applications with a Perl module.

So, all in all, I think it's sensible to apply this when Stefano has it done. 
Obviously, the best would be that we don't need this change, but since we do
have a problem, we should address it.

Actually, I considered whether we should do a CORBA interface in 1.1.x, rather
than a sockets interface.  Anyone got any experience with CORBA?

Greets,

Asger

Re: VNC X Server and LyX on a WinNT

[Asger Alstrup Nielsen]

> This same message greets me when I say "lyx -Mono"

The Mono switch is not of any use here.  The switch is -depth or -visual,
AFAIR.
Or, as I wrote, try the "vncserver -depth 16" trick.

Greets,

Asger

Re: lyxserver bug (maybe) and thoughts

[Asger Alstrup Nielsen]

> This would be perfectly ok for me. BTW, since you speak of backward
> compatibility, I assume that people have written other lyx clients (apart
> from servermonitor.c in the lyx sources). I would like very much to see
> the code of some of them so I can improve my code, e.g. when it comes to
> error checking, portability or simply cleanness. 

Check the How To Get it page at http://www.lyx.org/getit.html and check out
gBib and tclBibText (or something like that.)
Both of these connect to LyX to insert Bibtex references.

> Otherwise, I could simply conform to what the lyxserver does now, i.e. not
> writing anything in the out pipe if a command that returns no data
> succeeds. In this case, I do not fully understand how to check wheter a
> command returning no data has succeeded or not. The only way I know of is
> using select(2) to watch status changes in .lyxpipe.out, is that right?
> If the status has not changed, than lyx hasn't written anything, therefore
> no error occurred. 

You could do a hack:  Send a command to LyX that has no ill side-effects, but
returns something (like where the cursor is), and if you get the result
immediately, you know that the previous command succeeded.
Actually, this trick could spare us from modifying the protocol.

Greets,

Asger

Re: lyxserver bug (maybe) and thoughts

[Asger Alstrup Nielsen]

> What I gathered upon first reading of the Lyx Server chapter in the
> customization docs was indeed that a message was always issued to notify
> clients. From that document:
>
>   
> "The answer from LyX will arrive in the output pipe and be of the form
> 
> INFO:clientname:function:data

Don't put too much credit to the documentation :-)  
I know it might have bugs, because I rewrote most of it when I cleaned up the
LyX server, and before I did that, the documentation for sure had lots of bugs.
;-)

But, if gBib and the tclBib tool does not rely on the pipe-out, I say just
change the code to always send something out.

Like Lgb says:  Let's focus on getting the sockets one right in 1.1, and just
get on with life.

So my opinion is this:  I don't really care provided that we don't break any
applications.  If you feel like changing it, do it.  If you think you can
manage with the query-hack, do that.  Just update the documentation accordingly
;-)

So, it's up to Stefano and Jean-Marc, IMO.

Greets,

Asger

Re: lyxserver bug (maybe) and thoughts

[Asger Alstrup Nielsen]

> bla bla safe change bla bla... how many times have we said that made
> the fix and then we discovers bugs because of it?

Many times.

Also, many times, good things have come.  We make mistakes from time to time. 
But that should not stop us from making changes, IMO.  If we are too afraid to
change the code, nothing will happen, or at least things will go slow.  Compare
with the egcs/gcc development models.

I understand that 1.0.3 is important because 1.0.2 is bugged.  So release 1.0.3
now as it is, and we'll have more time to consider the lyx-server-stuff for
1.0.4 when we have the patch.  1.0.4 will require a long debugging period
anyway.

> then what is the real proplem.

Stefano can't build the library in a clean way.

Greets,

Asger

Re: lyxserver bug (maybe) and thoughts

[Asger Alstrup Nielsen]

> We should be very restrictive on what we call a bug at this point, the
> '\n' that Jean-Marc added is obvious, changing _any_ part of the
> protocol is not.

Well, I consider the change a bug-fix. The protocol is after all broken, and
should be fixed.

Also, it is a safe change.  The two main existing LyX-server applications are
unaffected, and we have the perspective of getting many more LyX server
applications with a Perl module.

So, all in all, I think it's sensible to apply this when Stefano has it done. 
Obviously, the best would be that we don't need this change, but since we do
have a problem, we should address it.

Actually, I considered whether we should do a CORBA interface in 1.1.x, rather
than a sockets interface.  Anyone got any experience with CORBA?

Greets,

Asger

Re: lyxserver bug (maybe) and thoughts

[Asger Alstrup Nielsen]

 Concerning the thought part below, I just reproduced it so that others
 can comment on it. Personnally, I agree that some message should be
 returned on success, but there may be some applications which rely on
 the fact that nothing is returned.
 
 So, fellow developpers, any idea?

In order to keep backwards compatibility, we can just introduce a certain
command that will enable the "error messages" on success.

Greets,

Asger

Re: lyxserver bug (maybe) and thoughts

[Asger Alstrup Nielsen]

 I think we should not keep backwards compatibility for the lyxserver.
 We need to think out a decent protocol with commands _and_ responses.
 Also we should switch to using sockets instead of namedpipes.

Agreed, but only for 1.1.x.  And therefore, for 1.0.x, I think we should just
do a hack to get the Perl module going.

Greets,

Asger

Re: [apinkus@xs4all.nl] LyX Feedback

[Asger Alstrup Nielsen]

 Hi,is it possible to create plugins for LyX? 

Unfortunately, there is no fixed architechture for this kind of thing, yet.

 I was thinking along the lines of adding a plugin that interfaces 
 with the CAS I am currently making (http://www.xs4all.nl/~apinkus/yacas.html)

 and can then be loaded as a plugin in LyX. This will not create a new 
 dependency for LyX, just an additional plugin the user can use.
 This could greatly ease the use of my CAS, using your formula editor for 
 instance, and using LyX as a notepad for doing calculations. I think it 
 is a perfect user interface for a CAS (apart from being a good tool for 
 creating documents of course :-)What dou you think of this idea?

You are more than welcome to go ahead and try to get something going!

One approach could be similar to how the Literate Programming support in LyX is
implemented.
Another could be similar to the SGML support we will get soon:  A custom export
filter.

Obviously, you would know how best to do this, so please post your ideas to the
mailing list at [EMAIL PROTECTED]
If you need help to find the right direction in the source code, just ask.

Greets,

Asger

Re: OF-OD-MB:what that means? (was Re: [BUG] One page only!)

[Asger Alstrup Nielsen]

 LyX uses another paradighm I call "MF-OD-OB"
 it means: "More File for One Document in One Buffer"
 For example Mico$oft Xord and others traditional WYSIWYG editors
 use "One File for One Document in One Buffer"

Actually, it's possible to do more file for one document with Microsoft Word as
well.

 "One File" could be obtained in two way:
 1) (simple) using tar file: Add to "File" menu "save as tar..."
 so will be create "foo.lyx.tar" containing "foo.lyx" and other files
 referred in ".lyx" :

I considered adding this at some point, but never got around to it. It would
also require the reverse operation: Opening a tar.gz file, but I agree that it
would be a great tool to have.

 2) Restructure the ".lyx" file format such that binary data
 (read .eps file) and other file could be included in some way
 I known this is not very simple.

This is not a good solution, because we want to be able to manipulate the
figures and other external files in other programs.
BTW, Microsoft Word supports this in the sense that pictures, figures and even
fonts can be embedded in the .doc file.  I think we want to avoid this
complexity.

 [Letting the documents menu become an on-line TOC]

That's a nice idea -- a bit similar to the file system browser in KDE 1.1.
I like that -- something worth implementing some day.

Greets,

Asger

Re: lyxserver bug (maybe) and thoughts

[Asger Alstrup Nielsen]

> Concerning the thought part below, I just reproduced it so that others
> can comment on it. Personnally, I agree that some message should be
> returned on success, but there may be some applications which rely on
> the fact that nothing is returned.
> 
> So, fellow developpers, any idea?

In order to keep backwards compatibility, we can just introduce a certain
command that will enable the "error messages" on success.

Greets,

Asger

Re: lyxserver bug (maybe) and thoughts

[Asger Alstrup Nielsen]

> I think we should not keep backwards compatibility for the lyxserver.
> We need to think out a decent protocol with commands _and_ responses.
> Also we should switch to using sockets instead of namedpipes.

Agreed, but only for 1.1.x.  And therefore, for 1.0.x, I think we should just
do a hack to get the Perl module going.

Greets,

Asger

Re: [apinkus@xs4all.nl] LyX Feedback

[Asger Alstrup Nielsen]

> Hi,is it possible to create plugins for LyX? 

Unfortunately, there is no fixed architechture for this kind of thing, yet.

> I was thinking along the lines of adding a plugin that interfaces 
> with the CAS I am currently making (http://www.xs4all.nl/~apinkus/yacas.html)

> and can then be loaded as a plugin in LyX. This will not create a new 
> dependency for LyX, just an additional plugin the user can use.
> This could greatly ease the use of my CAS, using your formula editor for 
> instance, and using LyX as a notepad for doing calculations. I think it 
> is a perfect user interface for a CAS (apart from being a good tool for 
> creating documents of course :-)What dou you think of this idea?

You are more than welcome to go ahead and try to get something going!

One approach could be similar to how the Literate Programming support in LyX is
implemented.
Another could be similar to the SGML support we will get soon:  A custom export
filter.

Obviously, you would know how best to do this, so please post your ideas to the
mailing list at [EMAIL PROTECTED]
If you need help to find the right direction in the source code, just ask.

Greets,

Asger

Re: OF-OD-MB:what that means? (was Re: [BUG] One page only!)

[Asger Alstrup Nielsen]

> LyX uses another paradighm I call "MF-OD-OB"
> it means: "More File for One Document in One Buffer"
> For example Mico$oft Xord and others traditional WYSIWYG editors
> use "One File for One Document in One Buffer"

Actually, it's possible to do more file for one document with Microsoft Word as
well.

> "One File" could be obtained in two way:
> 1) (simple) using tar file: Add to "File" menu "save as tar..."
> so will be create "foo.lyx.tar" containing "foo.lyx" and other files
> referred in ".lyx" :

I considered adding this at some point, but never got around to it. It would
also require the reverse operation: Opening a tar.gz file, but I agree that it
would be a great tool to have.

> 2) Restructure the ".lyx" file format such that binary data
> (read .eps file) and other file could be included in some way
> I known this is not very simple.

This is not a good solution, because we want to be able to manipulate the
figures and other external files in other programs.
BTW, Microsoft Word supports this in the sense that pictures, figures and even
fonts can be embedded in the .doc file.  I think we want to avoid this
complexity.

> [Letting the documents menu become an on-line TOC]

That's a nice idea -- a bit similar to the file system browser in KDE 1.1.
I like that -- something worth implementing some day.

Greets,

Asger

Re: LyX Japanese Documents

[Asger Alstrup Nielsen]

 karger You provide a link to the Japanese patch at
http://cgi.din.or.jp/~kawakami/.
 
 I think good thing My web site is mentioned on the LyX home page.
 To use Japanese on LyX, I do not use XFontStruct but XFontSet.
 I change char *text into wchar_t on class LyXParagraph, and so on.

I added the link to the http://www.lyx.org/getit.html page.

Sorry it took so long.

Greets,

Asger
P.S. I also added links to tkbibtex, fixed the link to the chinesewraplyx page,
fixed the link to the lyx2mml converter, and finally the link to gBib.

Re: LyX Japanese Documents

[Asger Alstrup Nielsen]

> karger> You provide a link to the Japanese patch at
http://cgi.din.or.jp/~kawakami/.
> 
> I think good thing My web site is mentioned on the LyX home page.
> To use Japanese on LyX, I do not use XFontStruct but XFontSet.
> I change char *text into wchar_t on class LyXParagraph, and so on.

I added the link to the http://www.lyx.org/getit.html page.

Sorry it took so long.

Greets,

Asger
P.S. I also added links to tkbibtex, fixed the link to the chinesewraplyx page,
fixed the link to the lyx2mml converter, and finally the link to gBib.

Kernel 0.6: No more segfaults

[Asger Alstrup Nielsen]

Hi!

Kernel 0.6 is attached. The segfault has been fixed properly, and insert and
erase is done. I only need to implement "clone" and test/debug everything in
order to reach milestone 1: Design, implementation and documentation of the
data structure layer.
This will surely be done before ~M.  

Comments on documentation, design, or implementation welcome.

Greets,

Asger

 kernel-0.6.tar.gz (WinZip File)

Kernel 0.6: No more segfaults

[Asger Alstrup Nielsen]

Hi!

Kernel 0.6 is attached. The segfault has been fixed properly, and insert and
erase is done. I only need to implement "clone" and test/debug everything in
order to reach milestone 1: Design, implementation and documentation of the
data structure layer.
This will surely be done before ~M.  

Comments on documentation, design, or implementation welcome.

Greets,

Asger

 kernel-0.6.tar.gz (WinZip File)

Re: hebrew

[Asger Alstrup Nielsen]

[Requests for RTL text]
 Hey, if I request it too, does that help? I didn't think so. I suspect that
 what you mean is "requests for this from people who will actually work on
 the coding have been very few, so it won't get done until someone has lots
 of free time."

It does help if more people say that they want it. 

For instance, personally I don't need Unicode support, but I design the new
kernel with Unicode support in mind because this is a frequently requested
thing (indirectly.)  Another factor in this decision is that we have several
different patches that enable LyX to be used with wide encodings, and obviously
it's advantageous to merge in all branches to one common code base.

Yes, the primary thing that makes thing happen is someone willing and able to
do it.  Motivation mostly comes from own needs, but other things play a part. 
One of these things is common feature requests.  Others can be things like the
personal satisfaction of building something cool, eventhough you don't really
need it.  Contrary to the commercial world, money does not play a significant
role in motivation -- often we even spend money in order to build things; it
costs money to host and attend ~M.

Having said that, I noticed that the Bazaar has $200 up for an WYSIWYG editor
that can write Hebrew (http://visar.csustan.edu/bazaar/bazaar_catoffers.html).
I guess that LyX would be close if we had full Unicode and RTL, and that could
be a well contribution to the LyX funds.  But I wouldn't hold my breath.

Personally, I haven't even started struggling with LTR yet.  The data structure
layer implementation turns out to be harder than I expected.  
The fix for the segfault from Kayvan turned out to be no good -- the problem
was much more fundamental, and the segfault only a symptom of those flaws. The
fix was only a work around.
I've spent most of today fixing things properly (the interface has not changed
-- it's only the implementation.)  Now, things are working as they should, and
I've made some significant progress so that the "insert" operation is
completely implemented now (but still not throughly tested.)  However, the
"erase" method has taken a step back, and some of it has to be reimplemented. 
When the "erase" method is done, I only need to do the "clone" method to reach
milestone 1.
I'll keep you posted on progress.  After M1, the fun part will begin: 
Displaying on screen!  Nothing motivates better than the thrill of the first
pixels on screen after lots of hard work building the engine.

Greets,

Asger

Re: hebrew

[Asger Alstrup Nielsen]

[Requests for RTL text]
> Hey, if I request it too, does that help? I didn't think so. I suspect that
> what you mean is "requests for this from people who will actually work on
> the coding have been very few, so it won't get done until someone has lots
> of free time."

It does help if more people say that they want it. 

For instance, personally I don't need Unicode support, but I design the new
kernel with Unicode support in mind because this is a frequently requested
thing (indirectly.)  Another factor in this decision is that we have several
different patches that enable LyX to be used with wide encodings, and obviously
it's advantageous to merge in all branches to one common code base.

Yes, the primary thing that makes thing happen is someone willing and able to
do it.  Motivation mostly comes from own needs, but other things play a part. 
One of these things is common feature requests.  Others can be things like the
personal satisfaction of building something cool, eventhough you don't really
need it.  Contrary to the commercial world, money does not play a significant
role in motivation -- often we even spend money in order to build things; it
costs money to host and attend ~M.

Having said that, I noticed that the Bazaar has $200 up for an WYSIWYG editor
that can write Hebrew (http://visar.csustan.edu/bazaar/bazaar_catoffers.html).
I guess that LyX would be close if we had full Unicode and RTL, and that could
be a well contribution to the LyX funds.  But I wouldn't hold my breath.

Personally, I haven't even started struggling with LTR yet.  The data structure
layer implementation turns out to be harder than I expected.  
The fix for the segfault from Kayvan turned out to be no good -- the problem
was much more fundamental, and the segfault only a symptom of those flaws. The
fix was only a work around.
I've spent most of today fixing things properly (the interface has not changed
-- it's only the implementation.)  Now, things are working as they should, and
I've made some significant progress so that the "insert" operation is
completely implemented now (but still not throughly tested.)  However, the
"erase" method has taken a step back, and some of it has to be reimplemented. 
When the "erase" method is done, I only need to do the "clone" method to reach
milestone 1.
I'll keep you posted on progress.  After M1, the fun part will begin: 
Displaying on screen!  Nothing motivates better than the thrill of the first
pixels on screen after lots of hard work building the engine.

Greets,

Asger

Math editor in Mozilla

[Asger Alstrup Nielsen]

Hi!

The editor in Mozilla is getting math capabilities.  Check out:

http://www.mozilla.org/projects/mathml/

Greets,

Asger

Re: Third International LyX Developer's meeting!

[Asger Alstrup Nielsen]

 The Third International LyX Developer Meeting in Italy 1999!
  
 So this is the invitation let me know!!!

I'll be there!

Greets,

Asger

Math editor in Mozilla

[Asger Alstrup Nielsen]

Hi!

The editor in Mozilla is getting math capabilities.  Check out:

http://www.mozilla.org/projects/mathml/

Greets,

Asger