
This message is to summarize the earlier discussions about upgrading Gtk for our next release, and make a proposal that will hopefully move us forward, without incurring the potential pain points that we identified.
It sounds like by and large, upgrading to Gtk 2.8 (and gtkmm, glib, et al) on Windows would not be a problem (I think we may distribute 2.8 gtk with the windows packages already), and on Linux would be an irritant only for people whose systems are significantly behind mainstream, such as enterprise distros.
However, as has been hashed out in detail in the previous thread, moving to gtk 2.8 would be a larger issue on the Mac platform. Users wouldn't be affected too badly, as they could just use compiled binaries. But developers on the Mac would be impacted in that they would need to manually upgrade their systems.
Now, in theory it would be good for the Mac gtk port to have a high profile project like Inkscape moving up its requirements; this would increase the motivation and pay-off for getting those ports viable. When we moved to 2.4 in the first place, I seem to recall we had a similar pain point with the Windows port, and going through that trouble actually seems to have ended up pretty well. It's entirely possible that doing so would bring similar benefit to us.
That said, recall our _primary_ motivation for moving to 2.8 is not due to roadblocking feature needs (which was the motivation for moving to 2.4), but a desire to make life a tad easier on the developers. So we need to weigh the benefits that some developers will gain against the pain that the Mac-based developers will incur. I think the balance in this case favors *not* upgrading to 2.8 quite yet.
From the discussion, I gather that 2.6 *is* reasonably well supported on
Mac. Thus, this suggests perhaps it would be wisest to do our 2.8 upgrade in two steps:
0.45 - Move our requirements to Gtk 2.6 Communicate our Gtk 2.8 ambitions to the Mac Gtk port maintainers. Encourage Inkscape Mac developers to experiment with 2.8 Around Sept, re-evaluate Gtk Mac 2.8 status
0.46 - Depending on evaluation, move to Gtk 2.8
When we looked at Gtk 2.6 previously, the new features were interesting, but not compelling enough to warrant changing, so we decided to wait until 2.8. 2.8 brings polish to these features, plus brings Cairo - something we are definitely interested in.
I am not super familiar with all the stuff that's changed in Gtk, but it appears that feature and API-wise, 2.6 is a much more significant change than 2.8; 2.8 appears to focus more on polish. Thus, moving first to 2.6 enables developers to start using the new features and learning the new API's, with the confidence that any clunkiness found will be ironed out soon once we've completed the upgrade to 2.8.
Here are things we can look forward to by going through this upgrade:
* New IconView widget [2.6] - displays tree model as grid of icons
* New GtkAboutDialog [2.6] - supports license info and links
* Improved GtkFileChooser [2.6]
* Improved widgets for displaying tree data [2.6]. GtkTreeView, GtkComboBox, etc.
* Better Clipboard/Selection/Drag and drop handling. [2.6]
* Icon themes [2.6]
* Cairo support [2.8]. Cairo used for rendering GTK+ widgets. Our SVG icons in the Inkscape UI will benefit.
* Text view improvements [2.8]. Dragging text displays dragged text instead of generic icon.
* Improvements to tree view, icon view, and file chooser widgets. [2.8] These make usage of these widgets more intuitive and useful.
* Lots of little things - convenience functions, API improvements, easier to use data structures...
* We can remove some Gtk stuff we copied into the Inkscape codebase to work around issues we found in the Gtk 2.4 stuff.
* Online documentation will be more useful. Currently we have to take care when reading docs that the features and examples we use aren't using features from 2.6 or later.
Some of these capabilities we've already gained by backporting the feature or other ways, so the benefit will be not that we gain the feature but that we gain the ability to implement it the standard way.
It looks like Gtk 2.10 is going to have much better printer support, too bad that didn't make it into 2.8!
Bryce