[news.eclipse.tools] Re: KDE and GNOME interfaces

["McQ" <mike_wilson@xxxxxxx>]

I think we aren't really going to come to any agreement here, but I'll make
one more attempt and then we'll just have to agree that we don't agree.

"David Goodenough" <david.goodenough@xxxxxxxxxxxxx> wrote in message
news:9q21ju$kf8$1@xxxxxxxxxxxxxxxx
> Having multiple APIs that do
> the same job is a quick route to problems.
>
There is *one* API to do the work, and that's ours. Unless you are telling
me that the KDE interface also integrates with the win32 registry, which was
not my reading of what they were doing in that effort at all. The point is,
we implemented the features we needed to support the workbench in a
cross-platform scenario. If you find those features (and the associated
portability) useful, great! If not, then there's nothing more to say except
"don't use them".

> You cut out the bit that
> pointed out that we do NOT want to have to stop at a particular KDE
> because it is not binary compatible (or source when it is released under
> a suitable licence) and have to wait for you to recompile your stuff or
> for someone to update the source.
>
It sounds to me like you are saying "the people doing the KDE Java binding
are more likely to be current than eclipse". That's certainly a possibility,
and if that proves to be problematic over time, then that would be *strong*
argument _for_ implementing our API in terms of the KDE java classes. It
doesn't however get rid of the need for the existance of our classes as I
described above.

> You also ommitted the bit where I
> pointed out that your APIs are proving less platform independant that
> is needed.  There is another thread where there are problems because
> under Windows a value is a handle and under Linux it is a pointer -
> so much for one common API.
>
I guess there's not much I can say about this. We _really_do_ use the
platform widgets in SWT. On win32, widgets _are_ referenced by handles. On
motif they _are_ referenced by pointers (although they are supposed to be
considered to be opaque (i.e. you aren't supposed to look at them)).

btw, I'm actually very interested in places where this is an issue, since I
don't believe there should be any. Can you tell me the subject of the thread
you are refering to? I looked for it, but couldn't find it.

> There is one other merit in using an existing API, even if it is under
> the covers.  That way you have to write less code, which means that
> Eclipse is smaller and that you can get on with writing other things
> rather than reinventing a perfectly good wheel.
>
The case for it being smaller was actually one of the arguments we used for
*not* using the Java binding. It appeared that our footprint would be much
larger using it than it would be by writing a small number of C natives.
Perhaps I was wrong?

> Code reuse is seen as a Good Thing (TM) in both the OO world (i.e. Java)
> and the Linux (and Unix) world.
>
Now that's something we both can agree on. ;-)

McQ.