Hi,
Attached updates the progress of the GTK port on guii.php3.
John
Index: guii.php3
===
RCS file: /cvs/lyx/www-devel/guii.php3,v
retrieving revision 1.71
diff -u -p -r1.71 guii.php3
--- guii.php3 2004/09/26 08:25:49 1.71
+++
John == John Spray [EMAIL PROTECTED] writes:
John Hi, Attached updates the progress of the GTK port on guii.php3.
I applied it.
JMarc
Hi,
Attached updates the progress of the GTK port on guii.php3.
John
Index: guii.php3
===
RCS file: /cvs/lyx/www-devel/guii.php3,v
retrieving revision 1.71
diff -u -p -r1.71 guii.php3
--- guii.php3 2004/09/26 08:25:49 1.71
+++
> "John" == John Spray <[EMAIL PROTECTED]> writes:
John> Hi, Attached updates the progress of the GTK port on guii.php3.
I applied it.
JMarc
Kalle Dalheimer and I have been having a discussion about possible ways
forward with the GUI-I stuff. Thought you might be interested (and of course,
I'll be able to find this on the archive in future!)
Feel free to comment...
A
Angus Incidentally, how do you find the new scheme?
Angus Any
It seems to me that having 5 implementations in one file separated by
#ifndef's is not a good idea. I'd rather see 5 different implementation
files. Not only will the code be cleaner, but I also like the idea of having
the xform code in the xform dir, the qt code in the qt dir, etc.
Although
Kalle What could be done would be something like this:
#ifdef XFORMS
typedef FL_OBJECT* WidgetPtr;
#elif defined QT
typedef QWidget* WidgetPtr;
#endif
This should get encapsulated in a real class, say "Widget", with different
implementaions for Qt, xforms, etc.
Kalle and
On Thursday 29 March 2001 14:28, Edwin Leuven wrote:
It seems to me that having 5 implementations in one file separated by
#ifndef's is not a good idea. I'd rather see 5 different implementation
files. Not only will the code be cleaner, but I also like the idea of
having the xform code in the
Wow a trip down memory lane...
On Thu, 29 Mar 2001, Andre Poenitz wrote:
Kalle What could be done would be something like this:
#ifdef XFORMS
typedef FL_OBJECT* WidgetPtr;
#elif defined QT
typedef QWidget* WidgetPtr;
#endif
This should get encapsulated in a real
Suggested/rejected GUII implementation number two. Both of the above
cases just end up being yet another restrictive cross-platform toolkit.
We don't need that. If you want one of those then just create a port to
the cross-platform toolkit of your choice and use that.
Oh, I did not suggest
On Thu, 29 Mar 2001, Andre Poenitz wrote:
Suggested/rejected GUII implementation number two. Both of the above
cases just end up being yet another restrictive cross-platform toolkit.
We don't need that. If you want one of those then just create a port to
the cross-platform toolkit of
On Thu, 29 Mar 2001, Allan Rae wrote:
Still tripping down memory lane...
Suggested/rejected GUII implementation number two. Both of the above
cases just end up being yet another restrictive cross-platform toolkit.
We don't need that. If you want one of those then just create a port to
Kalle Dalheimer and I have been having a discussion about possible ways
forward with the GUI-I stuff. Thought you might be interested (and of course,
I'll be able to find this on the archive in future!)
Feel free to comment...
A
Angus> Incidentally, how do you find the new scheme?
Angus>
It seems to me that having 5 implementations in one file separated by
#ifndef's is not a good idea. I'd rather see 5 different implementation
files. Not only will the code be cleaner, but I also like the idea of having
the xform code in the xform dir, the qt code in the qt dir, etc.
Although
> Kalle> What could be done would be something like this:
>
> #ifdef XFORMS
> typedef FL_OBJECT* WidgetPtr;
> #elif defined QT
> typedef QWidget* WidgetPtr;
> #endif
This should get encapsulated in a real class, say "Widget", with different
implementaions for Qt, xforms, etc.
>
On Thursday 29 March 2001 14:28, Edwin Leuven wrote:
> It seems to me that having 5 implementations in one file separated by
> #ifndef's is not a good idea. I'd rather see 5 different implementation
> files. Not only will the code be cleaner, but I also like the idea of
> having the xform code in
Wow a trip down memory lane...
On Thu, 29 Mar 2001, Andre Poenitz wrote:
> > Kalle> What could be done would be something like this:
> >
> > #ifdef XFORMS
> > typedef FL_OBJECT* WidgetPtr;
> > #elif defined QT
> > typedef QWidget* WidgetPtr;
> > #endif
>
> This should get
> Suggested/rejected GUII implementation number two. Both of the above
> cases just end up being yet another restrictive cross-platform toolkit.
> We don't need that. If you want one of those then just create a port to
> the cross-platform toolkit of your choice and use that.
Oh, I did not
On Thu, 29 Mar 2001, Andre Poenitz wrote:
> > Suggested/rejected GUII implementation number two. Both of the above
> > cases just end up being yet another restrictive cross-platform toolkit.
> > We don't need that. If you want one of those then just create a port to
> > the cross-platform
On Thu, 29 Mar 2001, Allan Rae wrote:
> Still tripping down memory lane...
>
> Suggested/rejected GUII implementation number two. Both of the above
> cases just end up being yet another restrictive cross-platform toolkit.
> We don't need that. If you want one of those then just create a port
Dear Developers,
I hope I won't be the n+199th to tell you this:
I wonder whether the "fast and light toolkit" (fltk) could help Lyx towards
GUI independence: it is fast, it is light, it works for both X-Windows and
MS-Windows and a user on the jed-list stated that it facil
"Guenter" == Guenter Milde [EMAIL PROTECTED] writes:
Guenter I wonder whether the "fast and light toolkit" (fltk) could
Guenter help Lyx towards GUI independence: it is fast, it is light,
Guenter it works for both X-Windows and MS-Windows and a user on the
Gue
On 06-Mar-2001 Guenter Milde wrote:
Dear Developers,
I hope I won't be the n+199th to tell you this:
No you are only the n+198th #:O)
I wonder whether the "fast and light toolkit" (fltk) could help Lyx towards
GUI independence: it is fast, it is light, it works for both X-Windo
Dear Developers,
I hope I won't be the n+199th to tell you this:
I wonder whether the "fast and light toolkit" (fltk) could help Lyx towards
GUI independence: it is fast, it is light, it works for both X-Windows and
MS-Windows and a user on the jed-list stated that it facil
>>>>> "Guenter" == Guenter Milde <[EMAIL PROTECTED]> writes:
Guenter> I wonder whether the "fast and light toolkit" (fltk) could
Guenter> help Lyx towards GUI independence: it is fast, it is light,
Guenter> it works for both X-Windows and MS-
On 06-Mar-2001 Guenter Milde wrote:
> Dear Developers,
>
> I hope I won't be the n+199th to tell you this:
No you are only the n+198th #:O)
> I wonder whether the "fast and light toolkit" (fltk) could help Lyx towards
> GUI independence: it is fast, it is light, it
On Thu, 27 Jul 2000, Angus Leeming wrote:
JMarc Several problems in cvs: Makefile.am has not been updated with the new
JMarc files, form_url.[Ch] have not been added. I am not sure whether I can
JMarc safely run make updatesrc to have the files. Angus?
Ahhh! Awake and on the ball as usual,
On Thu, 27 Jul 2000, Angus Leeming wrote:
> JMarc> Several problems in cvs: Makefile.am has not been updated with the new
> JMarc> files, form_url.[Ch] have not been added. I am not sure whether I can
> JMarc> safely run make updatesrc to have the files. Angus?
>
> Ahhh! Awake and on the ball
Angus Leeming [EMAIL PROTECTED] writes:
| Attached is a patch porting InsetUrl to GUI-independence. It also uses the
| InsetCommandParams class that I have mentioned before.
|
| As well as a diff file, the attachment contains some new files:
| src/frontends/xforms/FormUrl.h
| src
Lars | As well as a diff file, the attachment contains some new files:
Lars | src/frontends/xforms/FormUrl.h
Lars | src/frontends/xforms/FormUrl.C
Lars | src/frontends/xforms/forms/form_url.fd
Lars you can run diff with -N you know... to get the new files.
We've had this
Angus Leeming [EMAIL PROTECTED] writes:
| Lars | As well as a diff file, the attachment contains some new files:
| Lars | src/frontends/xforms/FormUrl.h
| Lars | src/frontends/xforms/FormUrl.C
| Lars | src/frontends/xforms/forms/form_url.fd
|
| Lars you can run diff with -N
Lars,
I see that you've added my patch. Thanks.
It looks however, as if you haven't updated Makefile.am in
src/frontends/xforms. The patch below does that.
In addition, you should
cd src/frontends/xforms/forms
make updatesrc
mv form_url.C form_url.h ../.
make clean
to put the automatically
"Angus" == Angus Leeming [EMAIL PROTECTED] writes:
Angus Attached is a patch porting InsetUrl to GUI-independence. It
Angus also uses the InsetCommandParams class that I have mentioned
Angus before.
Several problems in cvs: Makefile.am has not been updated with the new
files, fo
Angus Leeming [EMAIL PROTECTED] writes:
| Lars,
|
| I see that you've added my patch. Thanks.
| It looks however, as if you haven't updated Makefile.am in
| src/frontends/xforms. The patch below does that.
|
| In addition, you should
|
| cd src/frontends/xforms/forms
| make updatesrc
| mv
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| Also fdfix.sh does not have correct execute permissions. Does cvs
| preserve them?
Only if set from the begginging.
Lgb
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: |
Lars Also fdfix.sh does not have correct execute permissions. Does
Lars cvs | preserve them?
Lars Only if set from the begginging.
So, should makefile invoke is as "${SHELL}
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
|
| Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: |
| Lars Also fdfix.sh does not have correct execute permissions. Does
| Lars cvs | preserve them?
|
| Lars Only if set from the
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars Angus Leeming [EMAIL PROTECTED] writes: | Lars, | | I see
Lars that you've added my patch. Thanks. | It looks however, as if
Lars you haven't updated Makefile.am in | src/frontends/xforms. The
Lars patch below does that. | | In
JMarc Several problems in cvs: Makefile.am has not been updated with the new
JMarc files, form_url.[Ch] have not been added. I am not sure whether I can
JMarc safely run make updatesrc to have the files. Angus?
Ahhh! Awake and on the ball as usual, Jean-Marc!
A general point about "make
Angus Leeming <[EMAIL PROTECTED]> writes:
| Attached is a patch porting InsetUrl to GUI-independence. It also uses the
| InsetCommandParams class that I have mentioned before.
|
| As well as a diff file, the attachment contains some new files:
| src/frontends/xforms/FormUrl.h
|
Lars> | As well as a diff file, the attachment contains some new files:
Lars> | src/frontends/xforms/FormUrl.h
Lars> | src/frontends/xforms/FormUrl.C
Lars> | src/frontends/xforms/forms/form_url.fd
Lars> you can run diff with -N you know... to get the new files.
We've had
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars> | As well as a diff file, the attachment contains some new files:
| Lars> | src/frontends/xforms/FormUrl.h
| Lars> | src/frontends/xforms/FormUrl.C
| Lars> | src/frontends/xforms/forms/form_url.fd
|
| Lars> you can run diff
Lars,
I see that you've added my patch. Thanks.
It looks however, as if you haven't updated Makefile.am in
src/frontends/xforms. The patch below does that.
In addition, you should
cd src/frontends/xforms/forms
make updatesrc
mv form_url.C form_url.h ../.
make clean
to put the automatically
>>>>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Attached is a patch porting InsetUrl to GUI-independence. It
Angus> also uses the InsetCommandParams class that I have mentioned
Angus> before.
Several problems in cvs: Makefile.am
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars,
|
| I see that you've added my patch. Thanks.
| It looks however, as if you haven't updated Makefile.am in
| src/frontends/xforms. The patch below does that.
|
| In addition, you should
|
| cd src/frontends/xforms/forms
| make updatesrc
| mv
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| Also fdfix.sh does not have correct execute permissions. Does cvs
| preserve them?
Only if set from the begginging.
Lgb
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: |
Lars> Also fdfix.sh does not have correct execute permissions. Does
Lars> cvs | preserve them?
Lars> Only if set from the begginging.
So, should makefile invoke is as
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: |
| Lars> Also fdfix.sh does not have correct execute permissions. Does
| Lars> cvs | preserve them?
|
| Lars> Only if
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Angus Leeming <[EMAIL PROTECTED]> writes: | Lars, | | I see
Lars> that you've added my patch. Thanks. | It looks however, as if
Lars> you haven't updated Makefile.am in | src/frontends/xforms. The
Lars> patch below does that.
JMarc> Several problems in cvs: Makefile.am has not been updated with the new
JMarc> files, form_url.[Ch] have not been added. I am not sure whether I can
JMarc> safely run make updatesrc to have the files. Angus?
Ahhh! Awake and on the ball as usual, Jean-Marc!
A general point about "make
Attached is a patch porting InsetUrl to GUI-independence. It also uses the
InsetCommandParams class that I have mentioned before.
As well as a diff file, the attachment contains some new files:
src/frontends/xforms/FormUrl.h
src/frontends/xforms/FormUrl.C
src/frontends
Attached is a patch porting InsetUrl to GUI-independence. It also uses the
InsetCommandParams class that I have mentioned before.
As well as a diff file, the attachment contains some new files:
src/frontends/xforms/FormUrl.h
src/frontends/xforms/FormUrl.C
src/frontends
On Thu, Mar 02, 2000 at 12:09:18PM +0100, Asger K. Alstrup Nielsen wrote:
Dekel However, the real problem lies on parsing .lyx files at
Dekel Buffer::readLyXformat2 which is done using if-else statements
Dekel (... else if (token == "\\emph") ... ) This is very
Dekel inefficient!
[Rewrite the loading parsing logic]
If you want, I can do the changes (and also do the changes I suggested
for layout.C)
When you volunteer, obviously it's a good idea to make the change.
You won't find me arguing against that ;-)
I'm sure the patch would be welcomed.
Maybe it's time for
Dekel Tsur [EMAIL PROTECTED] writes:
| On Thu, Mar 02, 2000 at 12:09:18PM +0100, Asger K. Alstrup Nielsen wrote:
| Dekel However, the real problem lies on parsing .lyx files at
| Dekel Buffer::readLyXformat2 which is done using if-else statements
| Dekel (... else if (token == "\\emph")
"Asger K. Alstrup Nielsen" [EMAIL PROTECTED] writes:
| [Rewrite the loading parsing logic]
| If you want, I can do the changes (and also do the changes I suggested
| for layout.C)
|
| When you volunteer, obviously it's a good idea to make the change.
| You won't find me arguing against that
On Sat, Mar 04, 2000 at 10:02:50PM +0100, Lars Gullik Bjnnes wrote:
Dekel Tsur [EMAIL PROTECTED] writes:
|
| If you want, I can do the changes (and also do the changes I suggested
| for layout.C)
Nooo! :-)
I absolutely disagree with you ad. the parsing of layout files.
Plaese
On Thu, Mar 02, 2000 at 12:09:18PM +0100, Asger K. Alstrup Nielsen wrote:
> > Dekel> However, the real problem lies on parsing .lyx files at
> > Dekel> Buffer::readLyXformat2 which is done using if-else statements
> > Dekel> (... else if (token == "\\emph") ... ) This is very
> > Dekel>
[Rewrite the loading parsing logic]
> If you want, I can do the changes (and also do the changes I suggested
> for layout.C)
When you volunteer, obviously it's a good idea to make the change.
You won't find me arguing against that ;-)
I'm sure the patch would be welcomed.
Maybe it's time for
Dekel Tsur <[EMAIL PROTECTED]> writes:
| On Thu, Mar 02, 2000 at 12:09:18PM +0100, Asger K. Alstrup Nielsen wrote:
| > > Dekel> However, the real problem lies on parsing .lyx files at
| > > Dekel> Buffer::readLyXformat2 which is done using if-else statements
| > > Dekel> (... else if (token ==
"Asger K. Alstrup Nielsen" <[EMAIL PROTECTED]> writes:
| [Rewrite the loading parsing logic]
| > If you want, I can do the changes (and also do the changes I suggested
| > for layout.C)
|
| When you volunteer, obviously it's a good idea to make the change.
| You won't find me arguing against
On Sat, Mar 04, 2000 at 10:02:50PM +0100, Lars Gullik Bjnnes wrote:
> Dekel Tsur <[EMAIL PROTECTED]> writes:
> |
> | If you want, I can do the changes (and also do the changes I suggested
> | for layout.C)
>
> Nooo! :-)
>
> I absolutely disagree with you ad. the parsing of layout files.
>
Dekel However, the real problem lies on parsing .lyx files at
Dekel Buffer::readLyXformat2 which is done using if-else statements
Dekel (... else if (token == "\\emph") ... ) This is very
Dekel inefficient!
Yes, this code should use LyxLex correctly.
Actually, this is not a real problem
> Dekel> However, the real problem lies on parsing .lyx files at
> Dekel> Buffer::readLyXformat2 which is done using if-else statements
> Dekel> (... else if (token == "\\emph") ... ) This is very
> Dekel> inefficient!
>
> Yes, this code should use LyxLex correctly.
Actually, this is not a real
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| Lars Perhaps because the standard C++ library dioes not have hashed
| Lars containers? (that is an sgi extension (among others))
|
| Lars As for faster search times, these tables are som small that I
| Lars don't think it would have made a
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| Lars> Perhaps because the standard C++ library dioes not have hashed
| Lars> containers? (that is an sgi extension (among others))
|
| Lars> As for faster search times, these tables are som small that I
| Lars> don't think it would have made a
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars Dekel Tsur [EMAIL PROTECTED] writes: | On Mon, Feb 28, 2000
Lars at 02:21:12PM +0100, Jean-Marc Lasgouttes wrote: |
Lars "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: | |
Lars Lars Or we can just sort it... this will
On Tue, Feb 29, 2000 at 12:58:20AM +0100, Lars Gullik Bjnnes wrote:
| Lars Or we can just sort it... this will slow things down a tiny bit,
| Lars but you will never be able you measure that. (manually)
|
| With an assertion, we are always sure that manual sorting will be
| done. This
"Dekel" == Dekel Tsur [EMAIL PROTECTED] writes:
Dekel However, the real problem lies on parsing .lyx files at
Dekel Buffer::readLyXformat2 which is done using if-else statements
Dekel (... else if (token == "\\emph") ... ) This is very
Dekel inefficient!
Yes, this code should use LyxLex
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Dekel Tsur <[EMAIL PROTECTED]> writes: | On Mon, Feb 28, 2000
Lars> at 02:21:12PM +0100, Jean-Marc Lasgouttes wrote: | > >
Lars> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | > | >
Lars> Lars> Or we can just
On Tue, Feb 29, 2000 at 12:58:20AM +0100, Lars Gullik Bjnnes wrote:
> | > Lars> Or we can just sort it... this will slow things down a tiny bit,
> | > Lars> but you will never be able you measure that. (manually)
> | >
> | > With an assertion, we are always sure that manual sorting will be
> | >
> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes:
Dekel> However, the real problem lies on parsing .lyx files at
Dekel> Buffer::readLyXformat2 which is done using if-else statements
Dekel> (... else if (token == "\\emph") ... ) This is very
Dekel> inefficient!
Yes, this code should use
Andre Poenitz [EMAIL PROTECTED] writes:
| is at easy if it can possibly get. But maybe you are right and XTL is
|
| Read:
|
| ..is as easy as it ...
|
| I think I'll have another beer to get sober...
Not, in Norway yet are you?
Lgb
"Asger" == Asger K Alstrup Nielsen [EMAIL PROTECTED] writes:
Asger The LyXLex creature requires a list of keywords to function.
Asger This is a simple list of tokens, but it only works if it is
Asger sorted. Real life has shown that this is hard. Last time, it
Asger was Juergen who couldn't
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| "Asger" == Asger K Alstrup Nielsen [EMAIL PROTECTED] writes:
|
| Asger The LyXLex creature requires a list of keywords to function.
| Asger This is a simple list of tokens, but it only works if it is
| Asger sorted. Real life has shown that this
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars Or we can just sort it... this will slow things down a tiny bit,
Lars but you will never be able you measure that. (manually)
With an assertion, we are always sure that manual sorting will be
done. This is linear time, and only for
On Mon, Feb 28, 2000 at 02:21:12PM +0100, Jean-Marc Lasgouttes wrote:
"Lars" == Lars Gullik Bjnnes [EMAIL PROTECTED] writes:
Lars Or we can just sort it... this will slow things down a tiny bit,
Lars but you will never be able you measure that. (manually)
With an assertion, we are always
Dekel Tsur [EMAIL PROTECTED] writes:
| On Mon, Feb 28, 2000 at 02:21:12PM +0100, Jean-Marc Lasgouttes wrote:
| "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
|
| Lars Or we can just sort it... this will slow things down a tiny bit,
| Lars but you will never be able you measure
Andre Poenitz <[EMAIL PROTECTED]> writes:
| > is at easy if it can possibly get. But maybe you are right and XTL is
|
| Read:
|
| ..is as easy as it ...
|
| I think I'll have another beer to get sober...
Not, in Norway yet are you?
Lgb
> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> The LyXLex creature requires a list of keywords to function.
Asger> This is a simple list of tokens, but it only works if it is
Asger> sorted. Real life has shown that this is hard. Last time, it
Asger> was Juergen who
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
|
| Asger> The LyXLex creature requires a list of keywords to function.
| Asger> This is a simple list of tokens, but it only works if it is
| Asger> sorted. Real life has
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Or we can just sort it... this will slow things down a tiny bit,
Lars> but you will never be able you measure that. (manually)
With an assertion, we are always sure that manual sorting will be
done. This is linear time, and
On Mon, Feb 28, 2000 at 02:21:12PM +0100, Jean-Marc Lasgouttes wrote:
> > "Lars" == Lars Gullik Bjnnes <[EMAIL PROTECTED]> writes:
>
> Lars> Or we can just sort it... this will slow things down a tiny bit,
> Lars> but you will never be able you measure that. (manually)
>
> With an
Dekel Tsur <[EMAIL PROTECTED]> writes:
| On Mon, Feb 28, 2000 at 02:21:12PM +0100, Jean-Marc Lasgouttes wrote:
| > > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| >
| > Lars> Or we can just sort it... this will slow things down a tiny bit,
| > Lars> but you will never be able
On Fri, 25 Feb 2000, Andre Poenitz wrote:
We have considered extending the string interface
with various ways of encoding the information, but that would require
slow and error-prone parsing of strings.
I don't agree. Sorry... (Erm... well, it's friday, isn't it)
String parsing is
On Fri, 25 Feb 2000, Andre Poenitz wrote:
> > We have considered extending the string interface
> > with various ways of encoding the information, but that would require
> > slow and error-prone parsing of strings.
>
> I don't agree. Sorry... (Erm... well, it's friday, isn't it)
>
> String
You argue that debugging is important. Three words: Debugging is boring.
I know. But sometimes necessary. Not that I try to code poorly just to
have the fun of debugging ;-|
If we use XTL, there will be less debugging than if we have to write
our own parser. Just take a look at any parser
is at easy if it can possibly get. But maybe you are right and XTL is
Read:
..is as easy as it ...
I think I'll have another beer to get sober...
Andre'
--
André Pönitz . [EMAIL PROTECTED]
True. But a lot of trouble can be saved by using things like yacc...
Yacc is complex and error-prone.
It adds comparably much complexity to things. Also, Yacc by itself
does not cut it. You have to bring in the smaller cousin Lex, or Bison
if you are so inclined.
However, that complicates
> You argue that debugging is important. Three words: Debugging is boring.
I know. But sometimes necessary. Not that I try to code poorly just to
have the fun of debugging ;-|
> If we use XTL, there will be less debugging than if we have to write
> our own parser. Just take a look at any
> is at easy if it can possibly get. But maybe you are right and XTL is
Read:
..is as easy as it ...
I think I'll have another beer to get sober...
Andre'
--
André Pönitz . [EMAIL PROTECTED]
> True. But a lot of trouble can be saved by using things like yacc...
Yacc is complex and error-prone.
It adds comparably much complexity to things. Also, Yacc by itself
does not cut it. You have to bring in the smaller cousin Lex, or Bison
if you are so inclined.
However, that complicates
On Wed, 23 Feb 2000, Asger K. Alstrup Nielsen wrote:
The best format is the raw format, since it's minimalistic and the
fastest. We don't need interoperability with external sources, so
the raw format is the best solution.
That was what I thought the plain text was. The version I
[XTL]
I did that too and I admit I dont get what this is suposed to do for LyX? Do
you intend to have a new file format?
Btw XDR is a platform independent format for binary representation. I use
XDR a lot for numerical stuff. This XLT thing looks like XDR for structures with
some automatized
The string interface is too simple for the kind of information that should
be passed around.
What kind of information can not be passed around as strings?
We have considered extending the string interface
with various ways of encoding the information, but that would require
slow and
> On Wed, 23 Feb 2000, Asger K. Alstrup Nielsen wrote:
> > The best format is the raw format, since it's minimalistic and the
> > fastest. We don't need interoperability with external sources, so
> > the raw format is the best solution.
>
> That was what I thought the plain text was. The
[XTL]
> I did that too and I admit I dont get what this is suposed to do for LyX? Do
> you intend to have a new file format?
> Btw XDR is a platform independent format for binary representation. I use
> XDR a lot for numerical stuff. This XLT thing looks like XDR for structures with
> some
> The string interface is too simple for the kind of information that should
> be passed around.
What kind of information can not be passed around as strings?
> We have considered extending the string interface
> with various ways of encoding the information, but that would require
> slow and
to start again. The gui-indep dialogs
didn't cause any of the crashes though :)
I haven't gotten around to updating the gui-indep doc. However most of
the discussion in it is still relevent.
What work is currently being done on GUI independence ? I understand
major changes to the core code have
I am intending to make XTL a part of the rae branch sometime this week as
I want to try it out communication with LyXFunc. I'll have to get the
latest release to see what's new. The version I have exports to plain
text but doesn't import from it. It seems very fast for CORBA and XDF(?)
1 - 100 of 122 matches
Mail list logo
