[maemo-developers] [maemo-developers] Java on 770

From: Michael Dominic Kostrzewa michael.kostrzewa at nokia.com
Date: Sat Dec 2 18:24:22 EET 2006
On Fri, 2006-11-24 at 15:08 +0200, ext Santtu Lakkala wrote:
> Michael Dominic Kostrzewa wrote:
> >> I find it more reasonable to port a Java widget toolkit to hildon, than
> >> to create a wholly new toolkit. SWT can already use Gtk, so I guess it'd
> >> mostly be porting the backend to use hildon widgets where applicable.
> > Hmm, I'm not sure what you mean. There is, indeed, no sense in creating
> > a new toolkit (for what?). What we prolly need is hildon-* bindings for
> > Java and gtk bindings (I assume they exists somewhere). 
> Afaik there are no Gtk "bindings" per se. But there is IBM's swt
> toolkit, that can use Gtk as a backend. If we just make Gtk bindings, we
> lose quite a lot of the reasons to use Java in the first place. If we
> have our own, product specific, library for widgets, then there is a
> need for porting software. Instead there should be a backend for swt (or
> awt/swing) that uses hildon widgets where appropriate. This way the
> program will run and look native in multitude of environments. All this
> without need for modifying source or even recompiling.

IMHO, part of the success[1] of mono is the fact that it uses (can use)
Gtk almost natively. People who know Gtk can jump on the bandwagon
instantly, benefiting from the C# object-oriented features without
"losing" any C knowledge. 

Again, maybe I'm just not looking into the right places... but has
anyone actually managed to achieve this (kind of) UI-abstraction with
Java? I mean -- is is possible to run those games for mobile phones on
linux/windows desktop? Can I run the gmail java-client for symbian on a
linux/windows desktop? I don't think so, since google even seems to be
bundling a separate version of the gmail-app for every 
version of symbian. 

> > Also, it's not only about GUI toolkit but also about other API's. Ie.
> > you most likely want to use gnome-vfs, dbus, gstreamer, etc. 
> > Using plain SWT (even with Gtk drawing) will result in a lot of 
> > inconsistencies. Ie. the input methods will not work as expected.  
> Why will the input methods not work? I may be wrong on this, but I
> really think they would work. But anyway, having gnome-vfs available
> would be nice, but once again, if it is only used on maemo there is no
> real gain from using java. For gnome-vfs, I'd say the best way is to
> replace FileInputStreams with gnome-vfs implementations. Sure, then
> you'd be forced to use gnome-vfs, but at least you would not need code
> changes.

The core of input methods should work, but devil is in the details.
Example: using our custom defines you can currently set a GtkEntry into
a "numbers only" mode, which will be nicely picked-up by the input
methods. This will not automagically work with SWT. 

Another example -- I don't recall SWT having an equiv. of infobanners,
which play an import role in hildon UI look & feel. Sure, you can use
some kind of dialogs... but then you're compromising.

> GStreamer is a harder one, this would probably be a nice-to-have one.
> And without DBus I guess there's no way to get total integration with
> rest of the system.
> > With mono, the bindings exist for most of the components we use,
> > although they might need some tweaking. For some custom components
> > (ie. hildon-libs) we want to generate the bindings with the
> > gapi-parser. This way the mono apps on 770 will have a 100% "native" look,
> > feel and behaviour. 
> Call me idealist, but in my opinion for Java (and mono) to be really
> useful, the same code -- even the same binaries, should run everywhere
> and look native -- without a mess of checks on what the system we're on
> supports.

Well, that's very much true for mono. Your gtk-sharp based application
will run and look very much same on Linux/Gnome and ie. Windows. On
Windows Gtk will use an "Xp" theme to look like the rest of the system.

But to be frank, I don't believe much in the "compile once, run
everywhere" idea. It's technically possible, but ignores the fact that
different systems/devices/UI's have different methodologies. Something
that makes sense on a touchscreen-based device (ie. drag&drop based
interface) will not make sense on the keypad-driven mobile phone. Or, to
be less radical: instant-apply settings make sense on Gnome, but might
be very confusing to the windows user. 

The only way to solve this problem is to enter higher-levels of UI
abstraction -- what often produces bloated, heavy monsters that in the
end look like aliens in every environment.

I think the only solution to this problem is to write applications that
have nicely detached UI and "engine".  And code UI separately for every
platfrom from scratch. This is, unfortunately, very hard and requires a
lot of skills.  But java (and mono) is not a "silver bullet" that will
make your applications automagically fully cross-platform. 


1: "Success" is pretty contrversial here, especially in the light of the
recent MS & Novell randez-vous. But I understand "success" here from the
Gnome point of view -- having more user-ready applications written in
Mono than written in Java. 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.maemo.org/pipermail/maemo-developers/attachments/20061202/76a109ec/attachment.pgp 
More information about the maemo-developers mailing list