On Jun 24, 2006, at 1:29 PM, Bryce Harrington wrote: Could we have a breakdown of which distros we'd be leaving behind? That could help decide timing of things.

Also keep in mind that 0.44.x, which has glib-2.4 support for x>0, will be around for quite some time as "the" stable version. ralf

One thing that people should know is that the Gtk.org guys are readying gtk+-2.10 to be released within a few weeks. gtk+-2.8.x is no longer the bleeding edge, in fact, 2.8 will now be two minor versions (which means one stable minor version) back from the edge. People should begin to feel confident about using 2.8, and that it should be available on various platforms. bob

Jon A. Cruz wrote: Jon, I think it might be worthwhile to determine a breakdown: 1) what OS are users on (Win vs Linux vs OSX). Can maybe tell from downloads. I suspect Windows support gets better with each new Gtk version so that group might benefit from 2.8. For Linux, maybe someone at RedHat and Novell can give you an idea what vers most of their corp desktop users are on (ie how many have switched from FC4 to FC5 - again I suspect a big difference between desktop and server usage. Obviously you know what Ubuntu Breezy is on. OSX sounds like more of a problem but since so many developers are now using Mac there must be some way around - maybe Cairo folks have some ideas there since they are running on latest versions. 2) Maybe some contacts at the media outlets that run Inkscape articles (ie Linux Format, LWN) might have a good idea of what the pattern of use is. 3) Post a survey on the user list though the number of people on the list seem to be much less than the downloads

On Sunday 25 June 2006 11:01, Nicu Buculei wrote: Indeed, and I'm sorry about that. I was hoping to have the issue resolved during the pre-releases period, but couldn't find enough time. -- Jean-François Lemaire

On Sun, Jun 25, 2006 at 07:10:41PM +0200, Ralf Stephan wrote: I've noticed our rpm support has diminished since the project start. Way back when, rpm was one of our primary packaging formats, so this is a bit surprising. Not sure what can be done about it... Bryce

Bryce Harrington wrote: RHEL 5 will be based on Fedora Core 6, so it will be released after September (I believe October or November) and certainly will have a GTK version greater than 2.8 -- nicu Open Clip Art Library: http://www.openclipart.org my cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/

On 25/06/06, Jon A. Cruz <jon@...18...> wrote: Jon, I'm sorry that I missed this when you originally posted in this thread, you are of course 100% correct, unfortunately so is every other comment: I don't see a single path forward that will work for everyone, and we are probably left with Bryce's original proposal that the time has come to move on regardless of 'pain'. Long term planning is not often a vital part of FLOSS development, but minimising the effort required today, for today's work is. Even so, I would agree that GTK 2.10 and native would be a good goal for 0.46; Apart from supporting you, I would suggest progressively up-rating the requirements as per Ralf's post - people who are using the latest versions of Inkscape cannot but be aware of the need for Inkscape to have near contemporary (stable) UI libraries. For Mac OS X, perhaps we ought to concentrate on * Delivering Universal Binaries * Creating an XCode or Project Builder project * Native GTK+ To my mind this is roughtly in order of importance to users, and so it must be noted that the first on this list likely depends on the second which ought therefore to have priority. Native GTK+ support may seem like icing on the cake, particularly as it would move the Mac OS version into the next ball park (or whatever is the cognate of a quantum change), the next league perhaps, but I am sure that it is not as difficult as it sounds. Ben

On 06/07/06, David Himelright <himelright.2@...1307...> wrote: Since you can do it and I can't, I shall defer to you; but I would like to suggest that any other interested party should also refer to the Apple documentation on Universal Binaries and also on the GNU tools: http://developer.apple.com/documentation/DeveloperTools/Conceptual/cross_... http://developer.apple.com/unix/crossplatform.html . My rationale for using the XCode project is that one can specify an SDK, and get a one step build of the Universal Binary. A second advantage is that it is far more friendly to occasional developers, I see it as part of our mission to support Mac users who wish to build their own applications. I appreciate that this is not cut and dried. My picture is that it involves setting up the source files and targets which duplicates information in Makefile.am, but there is not much else to it. I do have such projects, which I also find handy on those occasions when it is necessary to use gdb. Are you really saying that it could be seen as an unfriendly act to suggest creating a directory MacOSX/ in the svn repository to contain an XCode project and supporting files? I don't follow the reference to OpenDarwin, and I was under impression that OpenDarwin could well become less important in the future. I am not talking about libraries at the moment, but I suspect that we will have to create our own. move == copy and delete ? No, I meant in addition. Also, isnt that a bit of a negative way of putting it. I am talking about the vendor-supported, native way of building applications, but I repeat, if you feel that my suggestions are 'unfriendly' I will assuredly drop them on the grounds that we don't wish to use, or support others who use, closed source tools. I have had a XCode project for about a year. For some reason I cannot build at all on Tiger at the moment. I did have a Native GTK+ build of Inkscape around last November, but threw it away when we switched to svn. Since then I have had hardware problems and I am still in the process of re-creating it. I think that the GTK code has improved in reliability over the last 8 months. I am intending to continue with this, and will report any succes that I do have, but an energetic person could easily pip me to the post. Ben.

On Jul 6, 2006, at 9:48 AM, Ben Fowler wrote: Oh, no not at all! I'm just reminding everyone that there's another platform that is being supported with the current configuration for Mac - the Darwin platform - and that is worth thinking about and retaining support for as the OSX target becomes more Mac-like. It's easy to forget that when you're a Mac guy (and I am) and just think in terms of things getting qualitatively better with native graphics support. I honestly have not met a lot of people who run the Darwin OS as more than a file server on a home network but if they're out there I'm sure they'd appreciate the consideration. It's not a matter of ideology for me at all. A hammer is a hammer, there's precedent in the windows port, and I already do my editing in XCode. But there are certainly people for whom it does matter and it's best to keep them in mind and not restrict their options. That's all. Ben, if you've got xcode projects to start with - even nonworking ones - I'd love to have a copy. I'm in the middle of setting my machine back up to build inkscape from source after removing fink to build libraries (cleanroom mentality). Did/do your project configurations rely entirely on xcode configuration settings? I think it would save me some time to bypass the GNU toolchain at this point, it's sort of a pain getting Makefiles configured correctly. Thanks for speaking up! --David

On 07/07/06, Jon A. Cruz <jon@...18...> wrote: Oh. I agree with that assessment, but to try be balanced, surely this was the fallback position when we started with fink in the first place? It is not much different from what the fink folk do, though they have a wider audience. Maybe this is overstating the case, but it seems to me that we cannot be like Peter Pan and stay at 2.4 for ever. Whilst there is a very good case for FLOSS projects in general minimising their requirements (for the benefit of developers and to widen the constituency of users), surely Inkscape does need to be nearly current. Why else would tool-makers want to upgrade their products? I agree with that as well, but I would suggest that in practice there is a powerful argument to reject it, namely that planning too far forward and requiring big jumps from developers is not good in the FLOSS world (where low-level irritation even if prolonged, is far less damaging) though it is O.K. in the commercial sector, where investment in training, tools or process now can be offset against later benefits. We ought to minimise the investment of time and energy that a dev needs to put in, now, in order to do what he or she has ideas for. (Also, those later benefits do not always materialise). Yes, it would be an excellent plan to hold off moving up from 2.4 for just one more release, yes it would be an excellent plan to hold off moving up from 2,4 until we could go in one jump to 2.10: I just don't see this as a good way to direct a FLOSS project, and I could not honestly argue for those tactics particularly for the convenience of one set of devs. That's a good idea, we would end up with more detail that just "it's time to move on", but I am sure that there a good list of what people would like, and would use if available. Also, there might be circumstances where some distros do not have libs or versions that we expect. There seem to be many distros springing up at the moment, and there seem to be one or two that are specifically aimed at graphic artists - we can't expect every specialist distro builder to know everything about all our dynamic libraries. I still think that only viable policy for everyone, and the one that would encourage devs to come aboard is the positive one of moving forward according to our needs and the negative one of not holding back for the sake of a few of the slower ships in this convoy. Since the sources are published there is no legal or effective barrier to anyone wanting to create a private branch that would match down-rated libraries. Are you on Tiger or Panther, and if Tiger, are you using PPC or Intel? We could put libraries into svn so that devs did not have build them, if this could be made a simple process. Obviously this would not do for release versions, but that is probably not an issue anyway. Ben

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. 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

On Jul 7, 2006, at 6:48 PM, MenTaLguY wrote: Sounds good to me too. Oh, though I do want to point out that the move to 2.6 will give some pain on Linux for enterprise distros. So perhaps we'll end up with a few month's window where we keep maintaining 0.44.x a bit longer to cover base support, then get to move on come December. That way they get *something* supported, just not the latest new features. But then again, that's what you get with a corporate distro in general. :-)

On Sat, 8 Jul 2006, Bryce Harrington wrote: No concerns here. Sounds good to me too. Michael

Bryce Harrington wrote: As RHEL does *not* include Inkscape, I don't think this should be a concern for Inkscape. Inkscape is included in Fedora Extras, where even feature fixes are allowed - for example Inkscape was updated to 0.44 in both FC4 and FC5. Also it may be worth mentioning the next RHEL, to be released in about the same time frame as Inkscape 0.45 will use GTK 2.10 (which is already in the development version) -- nicu Open Clip Art Library: http://www.openclipart.org my cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/

You wrote I'm quite sure that 0.44.1 will compile on RHEL. ralf

Bryce Harrington schrieb: ... ... Bryce, I do not think that we need to wait for cairo support until we switch to gtk2.8. It is in the most distros already. There is a patch for pdf export via cairo-pdf that is very usefull and does all the transparency and bitmap stuff that is broken in the current version. What I am trying to find out is: is there any blocker that prevents us from using that patch? Adib. ---

On Sat, 24 Jun 2006 13:29:57 -0700, Bryce Harrington wrote: What capabilities are those? Is it really worth leaving some users behind? The alternative may be to have a baseline of 2.4 but use the newer 2.8 features where available. This assumes that the features are all "nice to have but not essential". thanks -mike