[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Java Bindings for KDE
From:       Richard Moore <rich () ipso-facto ! freeserve ! co ! uk>
Date:       1999-02-25 16:44:09
[Download RAW message or body]



Pietro Iglio wrote:
> 
> At 11.15 23/02/99 -0800, Patrick D. Dowler wrote:
> >
> >My last message seems to have been ignored, so I will re-iterate:
> >
> >Any java support that requires developers to use KDE java classes, or
> >worse yet KDE wrappers to qt/c++ classes, would be a total waste, IMO.
> > ...
> > ...
> >
> >** Summary **
> >
> >1. I have classes that could become KConfig and KApplication with a
> >bit of tweaking. I don't know that the behaviour is the same as the
> >kdecore versions right now, I just did what I needed...
> >
> >2. We should focus on a KDE PLaF and not mess around with anything
> >else KDE-specific at this time. To start, someone could create a
> >KDE plaf that extends Metal and doesn't actually implement anything.
> >As you implement a class, you just change it to extend Basic and
> >make your own implementation. That way, we have a functional plaf
> >right away.
> >
> >3. We obviosly need a package heirarchy, with "org.kde" being the
> >standard choice. I can make org.kde.KConfig and org.kde.KApplication
> >available next week sometime.

These should be in org.kde.kdecore to follow the existing KDE
conventions. Or possible org.kde.core.

> >
> >4. 100% java!
> 
> A 100% pure java solution would probably be the best, but I don't think it
> is possible. The problem is that a minimum requirement to say that an app is
> a KDE app is the integration with the desktop and the other apps, plus
> the access to common resources such as icons, help files and the national
> language translation database. These aspects are probably more important than
> the look itself. I wouldn't care too much if the app has a metal look. Even
> under Windows applications have a different look.

A 100% Java solution also has trouble supporting AWT widgets. These are
important for adding Java applet support to KFM. I do agree though that
a Swing L&F is very important, but I think there need to be some small
pieces of native code to handle things like display properties or we
will not be able to change the L&F dynamically to match the KDE
settings.

Does anyone know how to get the peers used by the JVM? We should be able
to use the invokation API (part of JNI) to run the JVM in KFM, but we
need our own peers to be used or we will not be able to integrate it
with any exisiting KDE UI.

> 
> KConfig and KApplication (and any other class) as pure java are welcome. The
> problem is that the compatibility with KDE DND and clipboard probably cannot
> be achieved without loosing portability.

You can do the DND without loosing portability by writing your own peer
classes. These are an abstraction layer in the Java APIs designed for
just this. They use the AbstractFactory pattern. Look at the Toolkit
class
and other low level classes such as those in java.awt.peer.

Rich.
-- 
     Richard Moore		rich@ipso-facto.freeserve.co.uk
http://www.robocast.com/	richard@robocast.com
http://developer.kde.org/	rich@kde.org

[prev in list] [next in list] [prev in thread] [next in thread]