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

List:       kde-devel
Subject:    Re: Java Bindings for KDE
From:       iglio () fub ! it (Pietro Iglio)
Date:       1999-02-24 9:38:35
[Download RAW message or body]

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.
>
>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.

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.

This is why I suggest the following solution: we have a set of classes,
called KDE Java platform, that encapsulate non-portable stuff (DND, clipboard,
etc.), implemented using native methods.
At the same time we provide a 100% pure java version of the KDE Java platform,
so that, for example, one can develop and run apps under Windows.
When an app build on the top of the KDE Java platform is ran under KDE, it
is fully integrated with the desktop. When the same app is ran on another
platform, you just loose the DND/clipboard/etc. stuff (this is probably a
necessary limitation of 100% pure java apps).

With my solution, you can run apps everywhere (as 100% java apps) but you
don't loose integration with other KDE apps.

*Summary*:

- write KConfig, KApplication, etc. as 100% java;
- write non-portable classes for interaction with the desktop and other apps
  (DND, clipboard, etc.);
- write a 100% java version of the non-portable class to run apps on any other
  platform;
- (less important, future task) write a pluggable KDE look;


-- Pietro Iglio

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