Re: GTK and CinePaint

[Mike Hearn <mike navi cx>]

On Wed, 07 Apr 2004 10:28:00 -0700, Robin Rowe wrote:
> http://cinepaint.bigasterisk.com/WhyMigrateFromGTKToFLTK

IMHO the threading issue on Win32 is entirely bogus. Virtually every
widget toolkit on Win32 has this problem with multithreading - you should
not be accessing windows from different threads anyway as GTK+ is not
thread safe, so there is a theoretical risk of Bad Things happening even
on Linux. Even if you explicitly lock the window object externally, this
is still a bad idea as you have no idea what other pieces of code are
being invoked given any operation.

FWIW other widget toolkits and API wrappers (like the Delphi VCL) on Win32
have the same problem, and simply require you to run all GUI code in the
main thread. For instance see the Delphi Synchronize method.

http://www.mail-archive.com/csound-unix-dev ilogic com au/msg01514.html

That message appears to imply that FLTK is not thread safe either, so you
would not avoid these problems by switching to another toolkit. In fact,
the only toolkit I know of that *is* thread safe is Win32 itself accessed
directly without wrappers, which of course you don't want as it would then
not be portable.

If CinePaint is accessing the same window from multiple threads then this
is broken by design, and it should be fixed. Until GTK+ becomes thread
safe, that's it. End of story.

To be frank, the other arguments don't convince me either I'm afraid. GTK2
is too big for you to debug? So what? Your program depends on a whole ton
of huge codebases - what if your program crashes the X server? What about
if it panics the kernel? You cannot possibly audit every piece of code you
build on, it's not even worth trying. If a crash occurs inside GTK+,
report it in bugzilla and it'll be looked at by a large dedicated team.
Can you say the same for FLTK?

I'm not sure why you think GTKmm isn't elegant, but I've not used that
toolkit in any large projects so I won't pass comment. You might want to
clarify that.

thanks -mike