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. -- MDK 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.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
