Re: GUI Independence page
> "John" == John Spray <[EMAIL PROTECTED]> writes: John> Hi, Attached updates the progress of the GTK port on guii.php3. I applied it. JMarc
Re: GUI-Independence continued; some ideas...
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 > the cross-platform toolkit of your choice and use that. Exactly. This isn't Mozilla (thankfully). Let's share code as far as possible - and no further. We might be able to do this, as Angus says and Baruch has done, for the Button Controller; here the requirements are fairly simple, and the enforced uniformity a good thing (since the OK-Apply-Restore-Cancel system should be uniform throughout the dialogs anyway). But any further I would be dead against IMHO ... john -- "You might have lived a good life as an exemplary Christian, only to be met at the gates of Heaven by Mohammed. That's called fate." - Neil Peart, drummer and lyricist from Rush
Re: GUI-Independence continued; some ideas...
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 your choice and use that. > > Oh, I did not suggest to use it. It was just something like "If something > to that effect has to be used it'd better be encapsulated nicely and not > relying on macros..." Sure but what you provided code for was the second GUII implementation from 1998 (?). The "Suggested/rejected" is an historical fact not a comment reflecting upon you since this is an old suggestion (that I made). Allan. (ARRae)
Re: GUI-Independence continued; some ideas...
> 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 to use it. It was just something like "If something to that effect has to be used it'd better be encapsulated nicely and not relying on macros..." Andre' -- André Pönitz . [EMAIL PROTECTED] C++-Programmierer gesucht ... Naeheres unter http://mathematik.htwm.de/job
Re: GUI-Independence continued; some ideas...
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 class, say "Widget", with different
> implementaions for Qt, xforms, etc.
>
> > Kalle> and then:
> >
> > int getChoiceItem( WidgetPtr choice )
> > {
> > #ifdef XFORMS
> > return fl_get_object( choice );
> > #elif QT
> > ASSERT( choice->isA( "QComboBox" ) );
> > return static_cast( choice )->currentItem();
> > #endif
> > }
This looks very similar to the first suggested implementation for GUII
that was rejected before any more code than the above was written. It
lasted a couple of hours before its ashen hulk sunk below the waves.
See the GUII History part 1 article at
http://www.lyx.org/news/20010117.php3
> widget_xform ---
> class Widget {
> [...]
> int getChoiceItem() const {
> return fl_get_object( me_ );
> }
> private:
> FL_OBJECT * me_;
> };
> widget_xform ---
>
> widget_qt ---
> class Widget {
> [...]
> int getChoiceItem() const {
> ASSERT( choice->isA( "QComboBox" ) );
> return static_cast( me_ )->currentItem();
> }
> private:
> QWidget* me_;
> };
> widget_qt ---
>
> You could even hide the different implementations using the pimpl idiom,
> so the choice which gui you want can be made at link time by simply linking
> the desired pimpl.o
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
the cross-platform toolkit of your choice and use that.
See the above mentioned article for links to the archive. You'll have to
read though some of the threads yourself but it will save a bit of
bandwidth here if you do.
That doesn't mean we can't do some sensible merging of code in specific
cases such as the button controller. But please remember those wise
words of Morticia Addams:
"Too much of a good thing can be bad for you."
Allan. (ARRae)
Re: GUI-Independence continued; some ideas...
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 xform dir, the qt code in the qt dir, etc. > > Although not that I know anything about these things... ;-) Sure, this was just to illustrate. In real life, you would of course have the implementations in different files. Kalle -- Matthias Kalle Dalheimer President & CEO/VD Klarälvdalens Datakonsult AB Fax +46-563-540028 Email [EMAIL PROTECTED]
Re: GUI-Independence continued; some ideas...
> 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 then:
>
> int getChoiceItem( WidgetPtr choice )
> {
> #ifdef XFORMS
> return fl_get_object( choice );
> #elif QT
> ASSERT( choice->isA( "QComboBox" ) );
> return static_cast( choice )->currentItem();
> #endif
> }
widget_xform ---
class Widget {
[...]
int getChoiceItem() const {
return fl_get_object( me_ );
}
private:
FL_OBJECT * me_;
};
widget_xform ---
widget_qt ---
class Widget {
[...]
int getChoiceItem() const {
ASSERT( choice->isA( "QComboBox" ) );
return static_cast( me_ )->currentItem();
}
private:
QWidget* me_;
};
widget_qt ---
You could even hide the different implementations using the pimpl idiom,
so the choice which gui you want can be made at link time by simply linking
the desired pimpl.o
Andre'
--
André Pönitz . [EMAIL PROTECTED]
C++-Programmierer gesucht ... Naeheres unter http://mathematik.htwm.de/job
Re: GUI-Independence continued; some ideas...
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 not that I know anything about these things... ;-) gr.ed. ps. Relatedly, the frontends will always end up sharing code, but it is not sure that it is always a good idea to put the common code in a shared class. Think of the pathological case of 1 common line of code. The reason for this is that there are overhead and other costs. So in the end we should keen in mind that MC=MB. Even coding is economics :-)
Re: GUI-independence patch
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, Jean-Marc!
>
> A general point about "make updatesrc":
>
> we (ie Allan!) made the policy decision that we should accept only form_xxx.fd
> and make the .[Ch] files from this. All files in src/frontends/xforms/forms
> conform to this policy and should continue to do so.
While I put my foot down about the mess that people had made of the
${topsrc_dir}/forms it was Jürgen that convinced me (and did most of the
work) to improve fdfix.sh and the makefile so that the files generated by
fdesign could be used directly.
Now all I have to do is convert it to a Makefile.am and then we can always
generate form_.[Ch] files and remove them from CVS.
> JMarc> Also fdfix.sh does not have correct execute permissions. Does cvs
> JMarc> preserve them?
>
> Someone explained to me that this was a good thing. Prevents the
> unwary messing things up. The argument is less relevant than it was as
> the generated files should now be "good enough" not to need changing.
Ha ha ha ha...
See above.
Actually, Lars' suggestion that it keeps whatever permissions were on the
file when first committed don't seem to fit my experience: I committed
this particular fdfix.sh in both the rae and dialogbase branches with
perms of 750 and it ignored that.
Maybe there is a magic command line parameter for cvs that I haven't
bothered looking for?
Allan. (ARRae)
Re: GUI-independence patch
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 updatesrc": we (ie Allan!) made the policy decision that we should accept only form_xxx.fd and make the .[Ch] files from this. All files in src/frontends/xforms/forms conform to this policy and should continue to do so. JMarc> Also fdfix.sh does not have correct execute permissions. Does cvs JMarc> preserve them? Someone explained to me that this was a good thing. Prevents the unwary messing things up. The argument is less relevant than it was as the generated files should now be "good enough" not to need changing. Angus
Re: GUI-independence patch not applied correctly
> "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 addition, you should | | cd Lars> src/frontends/xforms/forms | make updatesrc | mv form_url.C Lars> form_url.h ../. | make clean Lars> I can't do that since I am using wrong version of fdesign. Lars> Jean-Marc? I'll do that. JMarc
Re: GUI-independence patch
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 begginging.
|
| So, should makefile invoke is as "${SHELL} fdfix.sh"?
yes
Lgb
Re: GUI-independence patch
> "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} fdfix.sh"?
JMarc
Re: GUI-independence patch
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
Re: GUI-independence patch not applied correctly
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 form_url.C form_url.h ../. | make clean I can't do that since I am using wrong version of fdesign. Jean-Marc? Lgb
Re: GUI-independence patch
> "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, form_url.[Ch] have not been added. I am not sure whether I can safely run make updatesrc to have the files. Angus? Also fdfix.sh does not have correct execute permissions. Does cvs preserve them? JMarc
Re: GUI-independence patch
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 you know... to get the new files. | | We've had this discussion before. | cvs diff -N -u > patch | does NOT get the new files. :-) that is because you have not run cvs add on them... | Incidentally, src/insets/form_url.[Ch] are also redundant and should | be removed. I'll remove them. Lgb
Re: GUI-independence patch
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 discussion before. cvs diff -N -u > patch does NOT get the new files. Incidentally, src/insets/form_url.[Ch] are also redundant and should be removed. Angus
Re: GUI-independence patch
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/frontends/xforms/FormUrl.C | src/frontends/xforms/forms/form_url.fd you can run diff with -N you know... to get the new files. | | The following files are now redundant. Please remove: | forms/cite.fd | forms/form_url.fd ok, done. Lgb
Re: GUI independence and XTL
On Sat, Mar 04, 2000 at 10:02:50PM +0100, Lars Gullik Bj&resh;nnes 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 explain why you don't agree with me (give your comment to my mail " The code in layout.C ")
Re: GUI independence and XTL
"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 ;-) | | I'm sure the patch would be welcomed. | | Maybe it's time for Dekel to get cvs write access? We should not ahve too many people with cvs access, anyway this has to wait a bit since we might have some lyx.org changes soon. Lgb
Re: GUI independence and XTL
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") ... ) This is very | > > Dekel> inefficient! | > > | > > Yes, this code should use LyxLex correctly. | > | > Actually, this is not a real problem at all. | > The bottleneck at load time is the rendering of the figures and | > of the document, not the parsing of the LyX document. | > | > You can assert this for yourself by loading the user guide. | > As soon as the program says "Formatting" or "Loading font", | > the raw loading part is over. You have to be fast to see it, | > though. | | It depends of the document. If you have a very large file, with lots of | insets, and a weak CPU, you will notice the time for parsing the document. | | > | > So: There is no reason to change this. So much else to do. | > | | 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. Lgb
Re: GUI independence and XTL
[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 to get cvs write access? Greets, Asger
Re: GUI independence and XTL
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! > > > > Yes, this code should use LyxLex correctly. > > Actually, this is not a real problem at all. > The bottleneck at load time is the rendering of the figures and > of the document, not the parsing of the LyX document. > > You can assert this for yourself by loading the user guide. > As soon as the program says "Formatting" or "Loading font", > the raw loading part is over. You have to be fast to see it, > though. It depends of the document. If you have a very large file, with lots of insets, and a weak CPU, you will notice the time for parsing the document. > > So: There is no reason to change this. So much else to do. > If you want, I can do the changes (and also do the changes I suggested for layout.C)
Re: GUI independence and XTL
> 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 at all. The bottleneck at load time is the rendering of the figures and of the document, not the parsing of the LyX document. You can assert this for yourself by loading the user guide. As soon as the program says "Formatting" or "Loading font", the raw loading part is over. You have to be fast to see it, though. So: There is no reason to change this. So much else to do. Greets, Asger
Re: GUI independence and XTL
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 difference anyway. | | And the table would have to be constructed at initialisation, whereas | it is static now. I have changed some of that in layout.C now. Since we usually parse layout files pretty seldom I have changed the lyxlex tables to be dynamic. I have also changed to of the code that annoyed Dekel the most. and thus now some of the code has run-time checking instead of compile time... Lgb
Re: GUI independence and XTL
> "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 correctly. JMarc
Re: GUI independence and XTL
On Tue, Feb 29, 2000 at 12:58:20AM +0100, Lars Gullik Bj&resh;nnes 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 is linear time, and only for debug builds. > | Why not use hashing? You also get faster search time. > | In any case, why isn't the STL being used? (map/hash_map containers) > > Perhaps because the standard C++ library dioes not have hashed > containers? > (that is an sgi extension (among others)) You can still use map containers which automatically sort the tokens (with a small(?) penalty for initialization) But maybe it not worth it to mess up a code that works... > > As for faster search times, these tables are som small that I don't > think it would have made a difference anyway. > The table of lyxrc tokens contains ~100 entries which is not that small, but you are correct: the difference should be small (at least for parsing the lyxrc/layout files). However, the real problem lies on parsing .lyx files at Buffer::readLyXformat2 which is done using if-else statements (... else if (token == "\\emph") ... ) This is very inefficient!
Re: GUI independence and XTL
> "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 slow things down a Lars> tiny bit, | > Lars> but you will never be able you measure that. Lars> (manually) | > | > With an assertion, we are always sure that Lars> manual sorting will be | > done. This is linear time, and only Lars> for debug builds. | > | > JMarc | | Why not use hashing? You Lars> also get faster search time. | In any case, why isn't the STL Lars> being used? (map/hash_map containers) 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 difference anyway. And the table would have to be constructed at initialisation, whereas it is static now. JMarc
Re: GUI independence and XTL
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 that. (manually) | > | > With an assertion, we are always sure that manual sorting will be | > done. This is linear time, and only for debug builds. | > | > JMarc | | Why not use hashing? You also get faster search time. | In any case, why isn't the STL being used? (map/hash_map containers) Perhaps because the standard C++ library dioes not have hashed containers? (that is an sgi extension (among others)) As for faster search times, these tables are som small that I don't think it would have made a difference anyway. Lgb
Re: GUI independence and XTL
On Mon, Feb 28, 2000 at 02:21:12PM +0100, Jean-Marc Lasgouttes wrote: > > "Lars" == Lars Gullik Bj&resh;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 debug builds. > > JMarc Why not use hashing? You also get faster search time. In any case, why isn't the STL being used? (map/hash_map containers)
Re: GUI independence and XTL
> "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 debug builds. JMarc
Re: GUI independence and XTL
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 is hard. Last time, it | Asger> was Juergen who couldn't remember the alphabet. Earlier, I have | Asger> made the same mistake, and I would wonder if not Lgb and | Asger> everybody else that has touched it has too sometime. | | It would be easy for LyXLex to test the proper sorting of lists when | ENABLE_ASSERTIONS is set. I'll do it if I find time. Or we can just sort it... this will slow things down a tiny bit, but you will never be able you measure that. (manually) Lgb
Re: GUI independence and XTL
> "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 remember the alphabet. Earlier, I have Asger> made the same mistake, and I would wonder if not Lgb and Asger> everybody else that has touched it has too sometime. It would be easy for LyXLex to test the proper sorting of lists when ENABLE_ASSERTIONS is set. I'll do it if I find time. JMarc
Re: GUI independence and XTL
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
Re: GUI independence and XTL
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 not error prone once you got it nicely encapsulated. > And that's really not too difficult. > > String parsing is slow. But that does not matter in our context. We want > a "real time _user_ interface", i.e. on one end of the interface sits a > human. And this human is the weak link performance-wise. Recall that Asger has already memntioned the text export and that XTL supports several other formats for externalization (CORBA stuff and XDR). If you really, really wanted to you could write support for another format that could be XML-like. This would be a string input and output that could then be used to support all the external scripting languages or other client programs you could imagine. > > The XTL library solves this problem for us in a clean, efficient, elegant, > > and extensible way. > > This introduces another bit of software that deals with binary data. And text data and any other format you care to define. > > It even promises the perspective of easier interoperability with external > > stuff, as Allan mentions. I.e. over time XTL can provide a LyXServer on > > steroids. > > So can a string interface. UNIX external stuff tends to be plain ASCII. > It's easy to debug, it's easy to control with standard tools. And with an XTL-based string format we don't have to write or maintain new parser databases for each new object/structure we want to communicate. In fact XTL makes it very easy for us to use the exact same code to communicate in different formats (be it a string, raw binary, or CORBA GIOP IIXYZ whatever the acronym is). [... strings + streams sample code...] > I don't think, this will be possible. You're right ;-) Allan. (ARRae)
Re: GUI independence and XTL
> 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 everything. Just think of the Makefile hell you are suddenly into. Who would voluntarily bring in the weird Lex and Yacc pair to solve a problem which is solved much better with simpler tools? Always, if you are as maschochistic as to insist that your computer science teaching should be used in real life, and that Lex and Yacc are indeed useful in real life, I would recommend you to have a look at PCCTS, or the newer incarnation called ANTLR. This is a lexer and parser hybrid, with the added benefit of a tree construction feature on top. It uses a kind of predicates to get a fresh approach to parsing. See http://www.antlr.org. However, for the task at hand, we should avoid the whole parsing business. > > If for nothing else, > > them simply because it actual is hard to keep a list sorted! > > I don't understand you here. Which list do you mean? The LyXLex creature requires a list of keywords to function. This is a simple list of tokens, but it only works if it is sorted. Real life has shown that this is hard. Last time, it was Juergen who couldn't remember the alphabet. Earlier, I have made the same mistake, and I would wonder if not Lgb and everybody else that has touched it has too sometime. [Simple winged example of XTL power] > No. If it is realy *that* easy it looks like a viable solution. Thank you. Now, go back and drink some more beer. > > If you think so, you must be drunk. Come to Norway and I'll buy you a beer. > > You mean drinking Norwegian beer makes me less drunk? No. My line of reasoning was this: 1) André was against XTL. 2) André either did not know what XTL was, or he must be drunk to think this. 3) Asger explains what XTL can do, and now the only excuse for André to resist reason would involve alcohol. 4) Asger buys beer for André, and then Asger is right no matter what. Maybe I should get a beer as well. Cheers, Asger P.S. *Are* you coming to Norway?
Re: GUI independence and XTL
> 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]
Re: GUI independence and XTL
> 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 we have in LyX. Every
> one of them is problematic, and has causes bugs.
True. But a lot of trouble can be saved by using things like yacc...
> If for nothing else,
> them simply because it actual is hard to keep a list sorted!
I don't understand you here. Which list do you mean?
> Now, maybe you can find a better encapsulation than what we currently
> have. Good for you, but I already found the best encapsulation. It's
> called XTL.
Ok, I promise have a closer look at XTL. You seem rather convinced and
I've seen a few good ideas from you already ;-)
> > Tons of interfaces?
>
> All dialogs require an interface to the kernel to get the information
> that should go in the dialog.
Some dialogs just construct some sort of command that is send down to
the kernel. Those should of course use the interface... But since XTL
seems to be able to handle that, too, the problem is reduced to the question
which solution is easier. Until now I thought a string (or stream) interface
is at easy if it can possibly get. But maybe you are right and XTL is
truly easier.
> It is more difficult than using XTL.
> It is less secure than XTL.
> It is less sexy than XTL.
:-)
> Have a look at XTL. Let me wing you an example. I can make it more
> complex if you want to, but maybe you would not understand what we
> are talking about:
>
> struct Foo {
> vector data1;
> list > data2;
> string data3;
> template
> void simple(X x) {
> X.simple(data1).simple(data2).simple(data3);
> }
> };
>
> There you have all your externalization code, both for input and output.
> You can't beat that, now can you?
No. If it is realy *that* easy it looks like a viable solution.
> If you think so, you must be drunk. Come to Norway and I'll buy you a beer.
You mean drinking Norwegian beer makes me less drunk? I knew that this
stuff was expensive, but I did not know that they don't even have
alcohol in it. Poor Lars ;-)
Regards,
Andre'
--
André Pönitz . [EMAIL PROTECTED]
Re: GUI independence and XTL
André argues that we should not use XTL because we can do things with
a string. He thinks that the added complexity of another library is
not worth the hassle -- after all a text format is well-known, and
if it is well encapsulated, it's no problem.
Surprise!
This is exactly what XTL is: A well encapsulated and easy to use library.
You argue that debugging is important. Three words: Debugging is boring.
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 we have in LyX. Every
one of them is problematic, and has causes bugs. If for nothing else,
them simply because it actual is hard to keep a list sorted!
Now, maybe you can find a better encapsulation than what we currently
have. Good for you, but I already found the best encapsulation. It's
called XTL.
By the way, did you know that XTL provides an easily debugable text
format? Not that you would ever need to use it, except when you have
to convince somebody to drop old fashioned methods.
> Tons of interfaces?
All dialogs require an interface to the kernel to get the information
that should go in the dialog.
> Conversion of strings and stream is niot difficult, too...
It is more difficult than using XTL.
It is less secure than XTL.
It is less sexy than XTL.
> > The neat part about XTL is obviously that you only have to implement
> > one method for each structure to get both read and write functionality.
>
> Do you think this will be much easier than:
>
>function(istream & inputstream, ostream & outputstream, ostream & err.. )
>{
> int par1, par2;
> inputstream >> par1 >> par2;
>
> if (!inputstream) {
>errorstream << "funny parameters";
>return;
> }
>
> outputstream << "some rtesult";
>}
>
> I don't think, this will be possible.
Think again.
Have a look at XTL. Let me wing you an example. I can make it more
complex if you want to, but maybe you would not understand what we
are talking about:
struct Foo {
vector data1;
list > data2;
string data3;
template
void simple(X x) {
X.simple(data1).simple(data2).simple(data3);
}
};
There you have all your externalization code, both for input and output.
You can't beat that, now can you?
If you think so, you must be drunk. Come to Norway and I'll buy you a beer.
Greets,
Asger
Re: GUI independence and XTL
> 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 error-prone parsing of strings.
I don't agree. Sorry... (Erm... well, it's friday, isn't it)
String parsing is not error prone once you got it nicely encapsulated.
And that's really not too difficult.
String parsing is slow. But that does not matter in our context. We want
a "real time _user_ interface", i.e. on one end of the interface sits a
human. And this human is the weak link performance-wise.
As long as you do not pass lots and lots of internal calls through this
interface that's just fine. And LyX does not do that currently. Even if
LyX becomes more modular and some internal calls could be made through
this interface, this won't become overwhelming. After all, it's modular
then...
> The XTL library solves this problem for us in a clean, efficient, elegant,
> and extensible way.
This introduces another bit of software that deals with binary data.
> It even promises the perspective of easier interoperability with external
> stuff, as Allan mentions. I.e. over time XTL can provide a LyXServer on
> steroids.
So can a string interface. UNIX external stuff tends to be plain ASCII.
It's easy to debug, it's easy to control with standard tools.
> can live without XTL, but it makes life easier, because we don't have
> to provide tons of interfaces into the kernel.
Tons of interfaces?
> Instead, we just have to provide XTL memory pools for certain features
> that contain potentially lots of parameters.
If we really need that we should have a stream interface.
Send a command/parameter stream in and wait until something comes out
the result stream or on the error stream.
Conversion of strings and stream is niot difficult, too...
> The neat part about XTL is obviously that you only have to implement
> one method for each structure to get both read and write functionality.
Do you think this will be much easier than:
function(istream & inputstream, ostream & outputstream, ostream & err.. )
{
int par1, par2;
inputstream >> par1 >> par2;
if (!inputstream) {
errorstream << "funny parameters";
return;
}
outputstream << "some rtesult";
}
I don't think, this will be possible.
Regards,
Andre'
--
André Pönitz . [EMAIL PROTECTED]
Re: GUI independence and XTL
[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 traversal, but what would that be needed for? > > Am I clueless or missing imagination here? The problem XTL can solve is primarily the communication between the LyX kernel in the form of the current LyXFunc and the front-ends. This interface either has the form of a simple string interface now, much like the minibuffer, or is non-existant. The string interface is too simple for the kind of information that should be passed around. 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. The XTL library solves this problem for us in a clean, efficient, elegant, and extensible way. It even promises the perspective of easier interoperability with external stuff, as Allan mentions. I.e. over time XTL can provide a LyXServer on steroids. In other words: XTL can provide the medium of communication between the LyX kernel and the rest of the world. Technically, we could use XTL to get a new file format, but that's not relevant at this point in time. For starters, we would probably only export the needed stuff for the dialogs via XTL, and over time, more and more of the kernel can be exported this way. Anyway, that's how I thought the XTL could help LyX. Obviously, we can live without XTL, but it makes life easier, because we don't have to provide tons of interfaces into the kernel. Instead, we just have to provide XTL memory pools for certain features that contain potentially lots of parameters. The neat part about XTL is obviously that you only have to implement one method for each structure to get both read and write functionality. Greets, Asger
Re: GUI independence and XTL
> 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 currently have > only exports to raw but doesn't import. Oh, no. The class is called "raw_format" and it's a binary only format. It does both import and export. This is different from the text_format, which only does export at this point. The raw_format is defined in objio.h. Greets, Asger
Re: GUI independence
John I've answered your original post at the end. On Tue, 22 Feb 2000, Roland Krause wrote: > After that, someone will probably have to make a real concept for > LyXFunc, i.e. events from the document view, menu, toolbar, and GUI > initialization as well as other things that I dont understand yet. Menu and toolbar abstractions exist in the archived lyx repository. There is still more work to do though. > Try to check out the rae-2 branch and look in frontends. There are > DialogBase.[Ch] and Dialogs.[Ch] pair of files. Alan put the header > files in frontends/include. Personally I think that is not necessary > since this is C++ and the header are part of the implementation and > should be with the implementation. The two header files are shared across multiple implementations. This revised scheme allows each frontend to use whatever names they like for their classes and files -- hopefully ones more in keeping with the platform/toolkit they are using. > Anyway. I started moving the Paragraph stuff so pick something else. John, if you want to get up to speed you might like to get the archived lyx repository where a lot of the gui-indep work was previously done. Compare the details in the gui-indep doc with what was happening in that source code. Concentrate on src/frontends/xforms once you recognize the pattern take a look at the rae branch and see how the new scheme works. They are very similar but the new scheme is a lot cleaner. cvs co lyx cvs co -r rae -d rae_lyx_devel lyx-devel > On Tue, 22 Feb 2000, John Levon wrote: > > It seems the devel web page is sort of out of date... It's just that we archived all the previous work and are doing it all again in a more stable environment -- the last development series crashed so often we decided it'd be quicker 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 made this easier, but the frontends > > directory is empty and the lyx-devel module on CVS doesn't seem to have > > any abstraction from xforms (sorry, I hate xforms) ... cvs co -r rae -d rae_lyx_devel lyx-devel > > Has this got beyond the high-level stuff in Asger's (out of date ?) paper > > on devel web page ? Yes. About 75% of the dialogs had been cleared out in the archived lyx repository. As I said above we are now looking at improving on that design and then (possibly|hopefully) back-porting the older work or redoing it all from scratch. The discussion about why we are doing it is still relevent and some of details are still true. However the method of communicating from the frontends (GUI, TUI, LyXServer or even CLI) will be different this time around. We're also using libsigc++ instead of now defunct gtk-- signal/slot system. > > I would definitely be interested in helping out with this as it's the only > > thing I don't like about LyX :) Your assistance would be greatly appreciated. If you've any questions or comments I'd be glad to hear them. (I might be a bit slow in answering though). > > Oh and another thing : you are using ghostscript for the figure insets, > > yes ? Well how difficult would it be to embed gs output for the whole > > document inside a LyXView ? That would be v. nice as you could just > > add "Preview mode" which can be updated in much the same way as it is > > currently, except there's no clutter with separate windows ... It could be done but I don't know that anyone is excited enough to take on the job (except perhaps you). Besides gv offers several extra capabilities we don't (like one-click zoom). I'm not in favour but that doesn't mean you shouldn't try. > > sorry if all this is FAQ but the devel web page is a little sketchy :) Hopefully it'll be updated before the work is completed ;-) Allan. (ARRae)
Re: GUI independence and XTL
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 currently have only exports to raw but doesn't import. Allan. (ARRae)
Re: GUI independence and XTL
On Wed, 23 Feb 2000, Roland Krause wrote: > 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? No. A better way to shift data between the various components of LyX (internal or external). > 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 traversal, so far so good. > but what would that be needed for? > Am I clueless or missing imagination here? You almost answered your own question in the previous paragraph. Externalization. Whether its external to LyX or external to the core. As you will have noticed in the XTL documentation the optimized code for any of the fancier formats is no worse than about half the speed of a memcpy but it can be used to communicate to external clients -- a Python script or a CORBA-enabled bibliography database for example -- at almost no extra cost. Allan. (ARRae)
Re: GUI independence and XTL
Hi, On Tue, 22 Feb 2000, Allan Rae wrote: > On Tue, 22 Feb 2000, Asger K. Alstrup Nielsen wrote: > > I've looked at the code and read the manual for it a couple of times on > the bus. So I agree it's exactly what we need. 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 traversal, but what would that be needed for? Am I clueless or missing imagination here? Roland -- Roland Krause Visiting Research Associate - Center for Computational Mechanics Washington University, Saint Louis
Re: GUI independence and XTL
> 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(?) > formats. 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. Fortunately, this decision is so easy to change later, given the XTL setup. > From what I saw in the code it doesn't need anything more advanced than > libsigc++ but then libsigc++ requires an up-to-date compiler. Actually, it does rely more heavily on some modern C++ constructs, so it is more demanding than sigc++. Greets, Asger
Re: GUI independence and XTL
On Tue, 22 Feb 2000, Asger K. Alstrup Nielsen wrote: > Hi! Hello Asger! > I've used it for a few things and can only say that it rocks your > socks off. I think this is exactly what we need for the communication > layer in the GUI indep-work. It's clean, fast, and very elegant > if you ask me. I've looked at the code and read the manual for it a couple of times on the bus. So I agree it's exactly what we need. > Regarding how to realize this goal: I'm wondering if we should try a > small experiment after 1.1.5 is out: Include the latest XTL in the > building step, and then apply the usual routine to work out what > needs to be done to make the thing build on the various platforms. 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(?) formats. > The thing is that XTL requires a fairly advanced C++ compiler to work > completely. (However, we can use a less ambitious subset of the system > with older compilers, and that is still a nice solution. I know, because > I had to do that in order to make it work with Visual C++.) >From what I saw in the code it doesn't need anything more advanced than libsigc++ but then libsigc++ requires an up-to-date compiler. Allan. (ARRae)
Re: GUI independence
Hi John, GUI independece is coming, there is light at the end of the tunnel. Platform independence is a long way to go. Alan Rae does the coordination of some of the GUI independence work in a seperate branch (rae-2). He was able to implement signal/slot for the Dialogs and move one Dialog into its new subfolder already. Now the rest hast to follow and the stuff should then be merged asap. since it does not involve any changes in the code, just moving of things. After that, someone will probably have to make a real concept for LyXFunc, i.e. events from the document view, menu, toolbar, and GUI initialization as well as other things that I dont understand yet. Try to check out the rae-2 branch and look in frontends. There are DialogBase.[Ch] and Dialogs.[Ch] pair of files. Alan put the header files in frontends/include. Personally I think that is not necessary since this is C++ and the header are part of the implementation and should be with the implementation. Anyway. I started moving the Paragraph stuff so pick something else. Roland On Tue, 22 Feb 2000, you wrote: > It seems the devel web page is sort of out of date... > > What work is currently being done on GUI independence ? I understand > major changes to the core code have made this easier, but the frontends > directory is empty and the lyx-devel module on CVS doesn't seem to have > any abstraction from xforms (sorry, I hate xforms) ... > > Has this got beyond the high-level stuff in Asger's (out of date ?) paper > on devel web page ? > > I would definitely be interested in helping out with this as it's the only > thing I don't like about LyX :) > > Oh and another thing : you are using ghostscript for the figure insets, > yes ? Well how difficult would it be to embed gs output for the whole > document inside a LyXView ? That would be v. nice as you could just > add "Preview mode" which can be updated in much the same way as it is > currently, except there's no clutter with separate windows ... > > > sorry if all this is FAQ but the devel web page is a little sketchy :) > > thanks, > john > > -- > "History is the slaughter-bench at which the happiness of peoples, the > wisdom of states and the virtue of individuals have been sacrificed." > - Hegel -- Roland Krause Visiting Research Associate - Center for Computational Mechanics Washington University, Saint Louis
Re: gui independence
"Dr. Ing. Roland Krause" <[EMAIL PROTECTED]> writes: | Grep is your friend but so is any other cross-referencer. | | Isnt there an etags goal in the makefiles? make TAGS Lgb
Re: gui independence
Hi Allan, I wanted to answer earlier, just didnt get to it. I 've seen that you checked in some stuff for the big GUI independence hack, good. Let's see that I can scrap some time to help with this now. First, you were correct, that I hadn't read all about the LyXfunc discussion in the mailing list archive. Now with your explanations though I think I've got a rough idea how things are supposed to be. > I agree 100%, this is a step by step process. I'll try to summarize what the > necessary steps are her emostly for my own understanding. > 1. Take a popup, e.g. paragraphs, find the code in the exisiting code > base that creates, updates and deletes this dialog and create a > form_paragraphs.[Ch] pair of files, then move the existing code. > Compile and see whether is all still works. Or something that might be easier: cp lyx/src/frontends/xforms/form_paragraph.[Ch] As you are removing the old implementation merge in any changes and tidy it all up. There are quite some changes so we'll see how much this actually works, but yes you are in principle right of course. s/Dialog/LyXDialogBase/ ors/Dialog/DialogBase/ There are no create or destroy signals. If a dialog hasn't been shown before it will be created just-in-time. Similarly, the hide could be used to delete[] the dialog. In any case, the destructor should clean up anything that may have been created. See other thread on this. I think we may need a ModalDialogBase for the modal dialogs but that can be decided as we go. Grep is your friend but so is any other cross-referencer. Isnt there an etags goal in the makefiles? [...] All it needs is the addition of the appropriate entries. This is mainly the common bits of code that can accept or return data and perform some action with it. Getting the current paragraphs parameters is one possibility. LyXFunc is the API. Anyone writing a script can access anything that LyXFunc has to offer. So its essential that we ensure that both the scripts and the GUI/TUI frontend and the LyX internals can all use it and that it has a sensible, clean collection of functions. Ok, I'll have to look closer into this. I dont understand how this will be usable for scripting yet but I cant imagine how passing strings is the most convenient method for interaction to the GUI frontend, all these conversion from and too integers floats etc... Well as I said I may understand this better when I actually see it. > So with this three steps one dialog is encapsulated. The slots can be > called from the menu or by means of the cursor moving to a new > paragraph. or by keyboard shortcut, or minibuffer command or even a LyXServer request from some exterenal program/script and for some popups there is also the likelihood of calls from inside the LyX core or other lyxfuncs. They all call a LyXFunc. The LyXFunc consists of: case LFUN_LAYOUT_PARAGRAPH: owner->getPopups.showParagraph(); break; (taken straight from the lyx/src/lyxfunc.C:1081-1083) well, yes, except that you'll have to call a slot of the appropriate DialogBase class, yet you havent passed any parameters to the dialog, I guess I havent understood yet. The dialogs will have to explicitely access data from the kernel on their own. Reread the paragraph and example above. We have at least six different ways of getting stuff to happen in LyX. At least three are likely to want answers or to push data into the system (kernel, ui and lyxserver). On the GUI side it's not a push (and shouldnt be) it is the GUI polling info from the kernel, yes, when writing back it could be a push... more OT in private email. Thanks Roland
Re: gui independence
On 28 Jan 2000, Jean-Marc Lasgouttes wrote: > > "Duncan" == Duncan Simpson <[EMAIL PROTECTED]> writes: > > Duncan> Do not hold your breath, since I need to get a PhD, but it > Duncan> occurs to me that GUI independence would be accelerated by > Duncan> having some common cases as re-usable widgets or something > Duncan> spiritually similar. How many boxes have a message and yes, no > Duncan> and cancel buttons? Would it not make sense to have a gettext > Duncan> aware version of such a box---it seems this could convert a > Duncan> lot of boxen quite quickly. > > Duncan> I guess the first step would be writing a XForms version of > Duncan> the idea above and using it instead of custom boxes > Duncan> everywhere. I will look at this some time modulo dealing with > Duncan> OLE archives on C++ implementations without overidable > Duncan> sys_read, sys_write and sys_seek functions (the documentation > Duncan> incidates these are specific to my iostream implementation). > Duncan> Does the standard have anything equivilent? (I can not RTFS > Duncan> myself). > > Isn't this idea similar to what we have in lyx_gui_misc.[Ch]? Of > course functions like WriteAlert() will be ported to other toolkits. Exactly, XForms already provides the facilities for these common yes/no type dialogs. And we use them already. Similarly, KLyX has an implementation of the very dialog in the same manner. So you don't have to worry, these facilities already exist ;-) Allan. (ARRae)
Re: gui independence
> "Duncan" == Duncan Simpson <[EMAIL PROTECTED]> writes: Duncan> Do not hold your breath, since I need to get a PhD, but it Duncan> occurs to me that GUI independence would be accelerated by Duncan> having some common cases as re-usable widgets or something Duncan> spiritually similar. How many boxes have a message and yes, no Duncan> and cancel buttons? Would it not make sense to have a gettext Duncan> aware version of such a box---it seems this could convert a Duncan> lot of boxen quite quickly. Duncan> I guess the first step would be writing a XForms version of Duncan> the idea above and using it instead of custom boxes Duncan> everywhere. I will look at this some time modulo dealing with Duncan> OLE archives on C++ implementations without overidable Duncan> sys_read, sys_write and sys_seek functions (the documentation Duncan> incidates these are specific to my iostream implementation). Duncan> Does the standard have anything equivilent? (I can not RTFS Duncan> myself). Isn't this idea similar to what we have in lyx_gui_misc.[Ch]? Of course functions like WriteAlert() will be ported to other toolkits. JMarc
