Hey,
this seems to be a hot and very emotional topic. But I am currently
writing an app that was intended not only for me, but for a specific
user group which happens to run Windows. I can't help it, although you
can be sure I share your opinion about this Redmondish OS.
So, I face the two options: Make java-gnome run on Windows, or dump my
app and rewrite it from scratch.
It's still fairly early in the dev cycle, so it's an option. But I like
java-gnome. And I think running only on one OS will be a deterrent for
java-gnome, so I think the project will profit from being able to run on
Windows, even if some project members couldn't care less *cough*.
So, I was asking for the actual problem Andrew Cowie, was rather
mystical "It's something deep", but said it's about thread-safety and
the fact that GDK-Win32 simply doesn't implement the thread-safety
mechanism used by java-gnome. Or something like that - I couldn't get
much more facts out of him. He did point me to the same documents about
thread-safety that he posted today in the other thread.
I read them, and actually understood most of them, but I still don't see
how that's a blocker for java-gnome on Windows: If the app is
single-threaded (which the majority of GUI apps are, and mine is) (or
java-gnome calls are only made from one thread, which should amount to
the same thing), then the whole thread-safety issue is simply
irrelevant, no?
The only problem I could imagine is that java-gnome uses GDK APIs which
are simple not implemented for GDK-Win32 at all, and that simply breaks
stuff so nothing works. But, if we accept the restriction on
single-threaded for now, these APIs are implemented as skeletons, with
no implementation: keeping the app going, just without making the
assurances about threads that they promise. Then single-threaded apps
should work, no?
Andrew said this would be 70% of the way. The other question is: What's
the other 30%?
Greetings. Respectfully,
Ben
|
