[Java-gnome-developer] java-gnome on MS Windows

[Ben B. <lin...@bu...>]

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