Thread: [Gtk1-win-developers] GTK1 for Windows and CinePaint
Brought to you by:
robinrowe
Menu
▾
▴
gtk1-win-developers
|
From: Robin R. <ro...@Mo...> - 2004-04-06 05:14:09
|
Owen and Tor, Hi. I just want to let you know that you seem to have been right from the start about GTK1 for Windows, that it is simply too much work for me to correct the problems there. I did learn a lot from working on it though. I am discontinuing my GTK1 for Windows effort so I can devote more time to CinePaint. GTK+OSX is expected to keep going because it seems to be nearing completion. I hope you won't be disappointed that I'm not moving toward GTK2. Upon the results of further research into our project's particular needs the new plan for CinePaint is to transition to FLTK. Appreciate your past help and courtesy. Thanks for everything! Robin ------------------------------------------------------------------- Rob...@Mo... Hollywood, California www.CinePaint.org Open source digital motion picture film software |
|
From: Owen T. <ot...@re...> - 2004-04-06 14:01:12
|
On Tue, 2004-04-06 at 01:13, Robin Rowe wrote: > Owen and Tor, >=20 > Hi. I just want to let you know that you seem to have been right from the > start about GTK1 for Windows, that it is simply too much work for me to > correct the problems there. I did learn a lot from working on it though. = I > am discontinuing my GTK1 for Windows effort so I can devote more time to > CinePaint. GTK+OSX is expected to keep going because it seems to be neari= ng > completion. >=20 > I hope you won't be disappointed that I'm not moving toward GTK2. Upon th= e > results of further research into our project's particular needs the new p= lan > for CinePaint is to transition to FLTK. Hi Robin, Well, I can't say I'm not disappointed about the switch to FLTK, though it's your project... Care to give some reasoning why you decided to move to a completely different toolkit, rather than one (GTK2) that is a lot closer to the current codebase? Regards, Owen |
|
From: Robin R. <ro...@Mo...> - 2004-04-07 04:23:18
|
Owen, > Well, I can't say I'm not disappointed about the switch to FLTK, though > it's your project... Care to give some reasoning why you decided to move > to a completely different toolkit, rather than one (GTK2) that is a lot > closer to the current codebase? Ok, so long as everyone understands my reasons are not intended as criticism, nor as a call for changes to GTK2. http://cinepaint.bigasterisk.com/WhyMigrateFromGTKToFLTK Robin ------------------------------------------------------------------- Rob...@Mo... Hollywood, California www.CinePaint.org Open source digital motion picture film software |
|
From: Federico M. Q. <fed...@xi...> - 2004-04-07 19:51:16
|
On Tue, 2004-04-06 at 23:22, Robin Rowe wrote: > Ok, so long as everyone understands my reasons are not intended as > criticism, nor as a call for changes to GTK2. > > http://cinepaint.bigasterisk.com/WhyMigrateFromGTKToFLTK I'm posting these comments here for the benefit of the other list members. You should really investigate moving CinePaint to GTK+ 2.4. 1.2 is really old, unsupported, and numerous bugfixes have gone in since then. There's a guide to porting apps from GTK+ 1.2 to 2.x: http://developer.gnome.org/dotplan/porting/ (Ignore the bits about GNOME; look at the GTK+ chapter.) Many changes can be done with a perl script to replace e.g. gtk_signal_connect with g_signal_connect. You can also replace obsolete APIs in stages by using the deprecation flags when building. At Ximian we had to port a lot of code that used GTK+ 1.2, during the time of the migration from GNOME 1.4 to GNOME 2.0, and it was reasonably easy to do. It's mostly grunt work. Feel free to ask if you get stuck. GTK+ has a large development community, even full-time paid hackers working on it, so you can be confident that it will always have people interested in keeping it up-to-date. It looks like your main showstopper is the threading issue on Win32. Maybe you would like to invest some time in fixing it? Changing to a completely unrelated toolkit is a very large job, especially for an app as big as CinePaint. Other toolkits will have the same problem on Win32, or they may already have a solution from which you can get inspiration. Federico |
|
From: Tor L. <tm...@ik...> - 2004-04-08 04:55:55
|
Federico Mena Quintero writes: > It looks like your main showstopper is the threading issue on Win32. > Maybe you would like to invest some time in fixing it? And are you sure, Robin, that FLTK is any better in this regard? I honestly don't know; if it is, I would be the first to admit that this would indeed be a very good reason to use it instead of GTK2, if CinePaint works in such a way that it needs to manipulate the same windows freely from different threads. (I will grab the FLTK 2.0 source from CVS and check how they handle this; maybe I can get some inspiration to finally fix it in GTK...) --tml |
|
From: Robin R. <ro...@Mo...> - 2004-04-08 19:09:55
|
Tor Lillqvist writes: > Federico Mena Quintero writes: > > It looks like your main showstopper is the threading issue on Win32. > > Maybe you would like to invest some time in fixing it? > > And are you sure, Robin, that FLTK is any better in this regard? First, Federico is entirely mistaken that our main issue with GTK2 has to do with threading. Many projects rely upon gtk.org for support and you kindly help them when you can. You have another class of user that independently fixes bugs, is not waiting for anyone's support. We're in that group. The biggest issue for us with GTK is size. GTK2 has more lines of code (10mb+) than CinePaint (about 7mb of source code). Why should we need to allocate more QA resources to maintaining GTK than we do to our own project? Unintentionally that's what we've done, and it doesn't work. Our project came almost to a standstill as we struggled with GTK. It takes too much time to get our heads around GTK because there is too much of it. Our biggest motivation to migrate to FLTK is not features but that it is 30x smaller, a size we can handle. Regarding message deadlock in a Windows thread, the general solution to is to run a message pump in the thread to clear the queue. My code in CinePaint inadvertently put to sleep a thread that needs to be awake for a Windows call. That is my bug, not GTK. Upon reflection, I don't know that there is a threading problem in GTK. Robin ------------------------------------------------------------------- Rob...@Mo... Hollywood, California www.CinePaint.org Open source digital motion picture film software |
Thanks for helping keep SourceForge clean.
X