Re: GNOME & KOM/OP



I'm not picking on anybody's ideas here, but I have
an opinion and some thoughts.  Whatever happens, I'll have
to live with it, as I've got 2 more years left on a project
that is consuming all of my time, I can't devote much more
than some documentation time to free software (currently
learning SGML/DocBook and documenting for another project).

Todd Graham Lewis wrote:

> On Thu, 6 Aug 1998, Chris Knight wrote:
>
> > Look guys. This is a serious mistake. COM is NOT what you are looking
> > for. Get yourself a copy of Visual C++, and create an extensive
> > COM/OLE/Active-X program. You won't for quite a while.  Linux and Unix
> > in general attract programmers because, although at the surface are
> > more difficult to use, are much easier on what is required from the
> > programmer. COM requires you to learn an entire jungle of information,
> > which will turn developers away from Gnome. Microsoft may be able to
> > have unprogrammable systems, but we can't afford to.
>
> I'm going to have to respectfully disagree.  I think that the OLE model in
> particular is a great way to go.  No other programming model allows as
> much reuse through embedding other programs, a technique which is surely
> in accordance with The Unix Way.
>

I'm going to have to respectfully disagree.  '[E]mbedding otherprograms' is
not The Unix Way, at least not in the OLE sense.  The
unix command line gains the bulk of its power from giving you the
ability to piece together *little* atomic parts of things to
accomplish a task...which may be entirely unique.  OLE is all about
letting *fat* applications tickle the innards of each other to gain
some integration.  It is not conceptually much different than what
Borland was doing with Paradox and Quattro on DOS in the late 80's.
I could have Paradox load up Quattro and do some calculations or a
graph for me.  It was crap, but nice for DOS.

What I was hoping for (expecting, really) was more of the OpenDoc
goal.  If I don't like table editing tool A, let me use table editing
tool B, or write table editing tool C and plug it into the Corba bus.
The document editor need not change. I don't need to know the API's of
the document editor, I just need to know a standard set of API's that
let me get at my data to do my thing with it.   I can mail the document
to another user who prefers table editor D and he can still use it.
I don't need to write a whole *application* to edit tables.

I'm not saying that Gnome should implement OpenDoc, but it would
not hurt to look hard at it...especially since the IDL is available for
'educational' use.   I don't know a bloody thing about OpenParts, but
not for want of trying...can't find anything much about it on the KDE
site, and I don't use KDE.

I also subscribe to the GNUStep mailing list, which has seen a flurry
of activity lately.  One thing they are currently discussing is adding
the Apple 'extensions' to the OpenStep spec, which include among
other things a document model and Undo & Redo classes.  I think (if
I remember correctly) that someone has already worked on the Undo
and Redo mechanisms.  So how many Document Models will free software
have?  Yeesh.  I'd like to see Gnome at least work with the GNUStep
group, at minimum when it comes to storage classes for documents.

One last thing.  The W3C just released Draft 1.0 of the 'DOM', a
"standard" document model for representing HTML/XML as objects.  It
may be good to look at this...it seems generic, there's IDL available
and they are doing it with CORBA in mind.  It would be cool to have
a Gnome-native document servable across the web in such a way that
standard scripting languages on any platform could manipulate the
content.  It would be a definite advantage over KDE/KOM, I think.
Whatsmore, it is document-centered --the document is composed of
objects that have API's that software can manipulate, not raw data
and separate API's to some chunk(s) of software that can manipulate
it.  I thought Data Encapsulation was one of the points of OOP ;-).


> I can't wait to read the arch doc on this.
>
> --
> Todd Graham Lewis                                     (800) 719-4664, x2804
> ******Linux******         MindSpring Enterprises      tlewis@mindspring.net
>
> --
>          To unsubscribe: mail gnome-list-request@gnome.org with
>                        "unsubscribe" as the Subject.

--
Robert J. Slover, Administrative Systems Manager
Rose-Hulman Institute of Technology
5500 Wabash Avenue
Terre Haute, Indiana 47803-3999



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]