On Fri, 12 Nov 1999 12:59:03 MET, Andre' Poenitz wrote:
>The commandline interface does exactly the same, of course the painter
>is much simpler in this case, it just produces some text describing the
>current state. But this is a way to achieve GUI
>independence: Everything up to and including the generic UI does not
>need to know anything about GUIs, and everything above the generic UI
>does not know anything about the objects that are handled below:
>The GUI only knows how to construct commandlines, when to call
>'draw', and how to execute the resulting sequence of drawing commands.
>
>If you don't like Tcl/Tk as GUI - no problem. All you have to do is to
>to build the actual GUI as a collection of menus etc., implement the
>single 'kernel call' and implement a painter. It's more ore less a
>client-server-architecture...
>So what I am suggesting?
Perhaps you remember, some time ago when discussing X-clipboard I
suggested to isolate the whole X11-specific stuff in a library (whether
shared or static depends on the target system) and to use a kind of
abstraction layer to communicate in a generic way with it.
>
>The 'buffer-execute' facility of LyX is really close to the
>command-string thingy in our project. If this facility would be declared
>as the Right Way(tm) to access 'kernel' functionality (like inserting
>characters, running LaTeX etc) some degree of modularization could be
>obtained at almost no cost (parsing 20 character strings in an
>interactive environment is really 'no cost')
>
>I would even volunteer to work on it, but of course I will not start
>if all of you think that this is completely useless ;-)
>
>Any opinions?
For me this sounds just great, it is a major step to the right
direction:
1) to completely isolate all the hackish GUI stuff as well as
other OS-dependencies in seperate stand-alone modules (*.o/*.obj) or
static archives (*.a/*.lib),
2) to wrap them in support libraries so as to make the actual
implementation completely opaque - (and to me it seems to be of
secondary importance whether doing this by using the traditional
working 'static' local namespace, using bleeding edge namespaces which
still have to overcome child's diseases on certain compilers, or using
the feature of DLL's on certain OS's to export only symbols that are
explicitly marked for 'export'- AIX?, Win*?, OS/2, not: SYSVr4), and
3) to communicate only with one generic exported interface per
library in a unified way.
Greets,
Arnd
