Up through 0.44 we've stuck to the Gtk 2.4 requirement, in order to minimize dependency problems for users. When we jumped from Gtk 2.0 to 2.4, a lot of users had installation troubles that we had to spend a lot of time helping with, so we wished to avoid that as long as possible.
Yet 2.8 has been out a while, and has some new capabilities that would be nice to rely on. 2.8 would be more compelling of a change than 2.6, so if we have to put people through the trouble of upgrading gtk, it might be better to move them to 2.8.
I'd like to propose that we change the dependency requirements for Inkscape to 2.8. Doing this right now gives us a maximum amount of testing time before 0.45.
Would anyone see an issue with doing this in this next release?
Bryce
On Jun 24, 2006, at 1:29 PM, Bryce Harrington wrote:
I'd like to propose that we change the dependency requirements for Inkscape to 2.8. Doing this right now gives us a maximum amount of testing time before 0.45.
Would anyone see an issue with doing this in this next release?
Could we have a breakdown of which distros we'd be leaving behind? That could help decide timing of things.
Would anyone see an issue with doing this in this next release?
Not at all.
Could we have a breakdown of which distros we'd be leaving behind? That could help decide timing of things.
Fedora Core 4. Possibly CentOS 4.2 (see bug 1505373)?
Let me stress that the recent problems with compiling 0.44 on FC4 only happened because NO SINGLE PERSON tested the prereleases with a pure glib-2.4 system.
This shows how many people out there rely on our 2.4 support. Next to nil!
ralf
On Jun 25, 2006, at 12:31 AM, Ralf Stephan wrote:
Fedora Core 4. Possibly CentOS 4.2 (see bug 1505373)?
Let me stress that the recent problems with compiling 0.44 on FC4 only happened because NO SINGLE PERSON tested the prereleases with a pure glib-2.4 system.
True...
But then again, that's mainly that no single dev or cutting edge person tested it. I'm not too surprised if those willing to test pre- releases are a bit more advanced than some common users.
Given that Fedora Core 5 only just came out, we might want to look at things a bit.
More importantly, I think the CentOS 4.2 problem is a more telling one. I'm pretty sure that it's corresponding to RedHat Enterprise 4.x, so is still a very prevalent platform for end users (at least of the corporate type). RHEL, RHAS, NLD, SLES and friends might be the "trailing edge" we should keep an eye on supporting.
Since Fedora's job is to be cutting edge, I won't have as much problem leaving slightly older ones behind. I don't have a good feel for Ubuntu, so will need to defer to others on that.
Ok. Just did a quick check. http://www.redhat.com/rhel/
Red Hat Enterprise Linux 4 was only released in Feb of 2005 (just over a year ago). They also provide seven years of support for each version. That might be a little long for us, though. But the more important factor might be their 18 month version plan. That means RHEL 4.x is still the latest-and-greatest.
And... checking CentOS 4's OS download rpms seems to show GTK+ at 2.4.13.
Hmmmm..... so I think we don't have 5 coming up to beta 'till next month, with actual release scheduled for December. With that in mind, we might want to see if we can wait on the bump until 0.46 intead of 0.45. I'm thinking that might be one way to approach it given that we probably want to do quicker releases this time and get two done in the next six months.
Oh, another driving platform as far as I'm concerned would be OS X. That's my main OS at the moment, so I have ulterior motives for keeping it build-able there. :-) At the moment, fink is only up to GTK+ 2.6.10. http://pdb.finkproject.org/pdb/package.php/gtk+2
Now.... if some people were to help getting native GTK+ working well on OS X, then that would free at least that particular dependency. It *might* be practical for a 0.46 timeframe, but not 0.45 (though good enough for devs might be doable in that timeframe).
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
On Jun 25, 2006, at 1:29 AM, Bob Jamison wrote:
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.
Well.... I think the key is the platforms it's on. Even though 2.8 is about to be "old hat", some existing distros don't even have released versions that are beyond 2.4.x yet.
I'm thinking that we'll probably want to just collect up this kind of info on some page on the Wiki. Then we can at least point people with different distros to the version of Inkscape that's expected to work for them. (leaving behind entire blocks of professional users does give me a bit of concern, though)
Jon A. Cruz wrote:
Well.... I think the key is the platforms it's on. Even though 2.8 is about to be "old hat", some existing distros don't even have released versions that are beyond 2.4.x yet.
I'm thinking that we'll probably want to just collect up this kind of info on some page on the Wiki. Then we can at least point people with different distros to the version of Inkscape that's expected to work for them. (leaving behind entire blocks of professional users does give me a bit of concern, though)
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
Jon A. Cruz wrote:
On Jun 25, 2006, at 12:31 AM, Ralf Stephan wrote:
But then again, that's mainly that no single dev or cutting edge person tested it. I'm not too surprised if those willing to test pre-releases are a bit more advanced than some common users.
Given that Fedora Core 5 only just came out, we might want to look at things a bit.
It does not help very much that the rpm version of all pre-releases and the final 0.44 are effectively not installable on Fedora (both 4 and 5) due to bogus dependencies, so common users have no way to test (the problem is known since at least the first pre-).
On Sunday 25 June 2006 11:01, Nicu Buculei wrote:
It does not help very much that the rpm version of all pre-releases and the final 0.44 are effectively not installable on Fedora (both 4 and 5) due to bogus dependencies, so common users have no way to test (the problem is known since at least the first pre-).
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.
Given that Fedora Core 5 only just came out, we might want to look at things a bit.
It does not help very much that the rpm version of all pre-releases and the final 0.44 are effectively not installable on Fedora (both 4 and 5) due to bogus dependencies, so common users have no way to test (the problem is known since at least the first pre-).
what - and noone with this distro was able to help out since pre- ???
ralf
On Sun, Jun 25, 2006 at 07:10:41PM +0200, Ralf Stephan wrote:
Given that Fedora Core 5 only just came out, we might want to look at things a bit.
It does not help very much that the rpm version of all pre-releases and the final 0.44 are effectively not installable on Fedora (both 4 and 5) due to bogus dependencies, so common users have no way to test (the problem is known since at least the first pre-).
what - and noone with this distro was able to help out since pre- ???
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
On Sun, Jun 25, 2006 at 01:15:31AM -0700, Jon A. Cruz wrote:
On Jun 25, 2006, at 12:31 AM, Ralf Stephan wrote:
Fedora Core 4. Possibly CentOS 4.2 (see bug 1505373)?
Let me stress that the recent problems with compiling 0.44 on FC4 only happened because NO SINGLE PERSON tested the prereleases with a pure glib-2.4 system.
True...
But then again, that's mainly that no single dev or cutting edge person tested it. I'm not too surprised if those willing to test pre- releases are a bit more advanced than some common users.
Given that Fedora Core 5 only just came out, we might want to look at things a bit.
I've emailed the gtkmm list to see if Murray has this data handy.
Hmm, seems like there ought to be some site where all the versions of dependencies are listed, for all major distros. Anyone know of such a thing? If there isn't maybe I should suggest OSDL do it (ISV's probably need it even more than us).
More importantly, I think the CentOS 4.2 problem is a more telling one. I'm pretty sure that it's corresponding to RedHat Enterprise 4.x, so is still a very prevalent platform for end users (at least of the corporate type). RHEL, RHAS, NLD, SLES and friends might be the "trailing edge" we should keep an eye on supporting.
I noticed Gentoo has it, and I think has had it for a while - it was just that one system where I noticed this bug; my other systems already had the newer gtkmm on it. It's sort of strange having inkscape be about the only application I have installed that requires gtkmm...
I agree that looking at the enterprise distros is a good way to judge what is mainstream, however do keep in mind that the way enterprises work, it's unlikely they'd be allowing users to install latest inkscape until it's included in the distro, too. For this situation, I'd actually think it more appropriate to check that inkscape's autopackage installs cleanly there (if anyone happens to have a copy of it).
Also, regarding the enterprise distros, I don't know exact release plans, but I gather they'll all be finalizing the versions in their next releases prior to when we'll be ready to release 0.45. We'll probably even have time to get a few stable releases out before then too, which enterprise users will probably value much more.
Anyway, so while I agree looking at RHEL, SLES, etc. is worthwhile, I suspect timing-wise it works out well for us to upgrade gtk now.
Ok. Just did a quick check. http://www.redhat.com/rhel/
Red Hat Enterprise Linux 4 was only released in Feb of 2005 (just over a year ago). They also provide seven years of support for each version. That might be a little long for us, though. But the more important factor might be their 18 month version plan. That means RHEL 4.x is still the latest-and-greatest.
Okay, so 18 months from Feb '05 is Aug '06, and that fits with what I've heard. So we've done good by getting 0.44 out with plenty of time for them to test and include, but 0.45 will come after. However, possibly the new RHEL will have gtk 2.8 anyway?
And... checking CentOS 4's OS download rpms seems to show GTK+ at 2.4.13.
Hmmmm..... so I think we don't have 5 coming up to beta 'till next month, with actual release scheduled for December. With that in mind, we might want to see if we can wait on the bump until 0.46 intead of 0.45. I'm thinking that might be one way to approach it given that we probably want to do quicker releases this time and get two done in the next six months.
If we do decide to stick with 2.4 for 0.45, we ought to make sure we still have some devs (or at least some test machines - we can keep the nightly build machine set to 2.4 I think) that still compile and/or test against 2.4, to keep us straight... It's getting pretty easy to slip and use newer features...
Oh, another driving platform as far as I'm concerned would be OS X. That's my main OS at the moment, so I have ulterior motives for keeping it build-able there. :-) At the moment, fink is only up to GTK+ 2.6.10. http://pdb.finkproject.org/pdb/package.php/gtk+2
Now.... if some people were to help getting native GTK+ working well on OS X, then that would free at least that particular dependency. It *might* be practical for a 0.46 timeframe, but not 0.45 (though good enough for devs might be doable in that timeframe).
Hmm, this is a good point; knowing how long it took to get gtk going on osx, I'd hold this as pretty important.
Bryce
Bryce Harrington wrote:
On Sun, Jun 25, 2006 at 01:15:31AM -0700, Jon A. Cruz wrote:
Red Hat Enterprise Linux 4 was only released in Feb of 2005 (just over a year ago). They also provide seven years of support for each version. That might be a little long for us, though. But the more important factor might be their 18 month version plan. That means RHEL 4.x is still the latest-and-greatest.
Okay, so 18 months from Feb '05 is Aug '06, and that fits with what I've heard. So we've done good by getting 0.44 out with plenty of time for them to test and include, but 0.45 will come after. However, possibly the new RHEL will have gtk 2.8 anyway?
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
On Sun, 2006-06-25 at 12:09 -0700, Bryce Harrington wrote:
Hmm, seems like there ought to be some site where all the versions of dependencies are listed, for all major distros. Anyone know of such a thing? If there isn't maybe I should suggest OSDL do it (ISV's probably need it even more than us).
Source: distrowatch.com
"Top" 4 Distros plus Red Hat:
Distro. Version Date gtk+ Inkscape
Ubuntu Snapshot Current 2.8.17 0.43 6.06 2006/06/01 2,8.17 0.43 5.10 2005/10/13 2.8.6 0.42 5.04 2005/04/08 2.6.4 0.40 4.10 2004/10/20 2.4.9 0.38.1
SUSE factory Current 2.8.10 0.43 10.1 2006/05/11 2.8.10 0.43 10.0 2005/10/06 2.8.3 0.42.2 9.3 2005/04/15 2.6.4 0.41 9.2 2004/10/25 2.4.9 0.39 9.1 2004/04/23 2.2.4 - 9.0 2003/10/15 2.2.3 -
Fedora devel Current 2.9.3 - test 6.1 2006/06/21 2.9.3 - 5 2006/03/20 2.8.15 - 4 2005/06/13 2.6.7 - 3 2004/11/08 2.4.13 -
Mandriva cooker Current 2.9.4 0.43 2006.1-0.3 2005/12/26 2.8.9 - 2006 2005/10/06 2.8.3 - 2005 2005/04/14 2.6.4 - 10.1 2004/09/16 2.4.9 - 10.0 2004/03/04 2.2.4 -
Red Hat RHEL4 2005/02/15 2.4.13 - RHEL3 2003/10/22 2.2.4 - RHEL2.1 2002/03/26 1.2.10 -
Tav
On 25/06/06, Jon A. Cruz <jon@...18...> wrote:
On Jun 25, 2006, at 12:31 AM, Ralf Stephan wrote:
Fedora Core 4. Possibly CentOS 4.2 (see bug 1505373)?
Let me stress that the recent problems with compiling 0.44 on FC4 only happened because NO SINGLE PERSON tested the prereleases with a pure glib-2.4 system.
True...
[ big snip ]
Oh, another driving platform as far as I'm concerned would be OS X. That's my main OS at the moment, so I have ulterior motives for keeping it build-able there. :-) At the moment, fink is only up to GTK+ 2.6.10. http://pdb.finkproject.org/pdb/package.php/gtk+2
Now.... if some people were to help getting native GTK+ working well on OS X, then that would free at least that particular dependency. It *might* be practical for a 0.46 timeframe, but not 0.45 (though good enough for devs might be doable in that timeframe).
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 Jul 6, 2006, at 8:08 AM, Ben Fowler wrote:
On 25/06/06, Jon A. Cruz <jon@...18...> wrote:
On Jun 25, 2006, at 12:31 AM, Ralf Stephan wrote:
Oh, another driving platform as far as I'm concerned would be OS X. That's my main OS at the moment, so I have ulterior motives for keeping it build-able there. :-) At the moment, fink is only up to GTK+ 2.6.10. http://pdb.finkproject.org/pdb/package.php/gtk+2
Now.... if some people were to help getting native GTK+ working well on OS X, then that would free at least that particular dependency. It *might* be practical for a 0.46 timeframe, but not 0.45 (though good enough for devs might be doable in that timeframe).
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.
...
Hi Ben & Ralf, I have a little bit of experience now with the build process and Native GTK+, so I thought I'd interject with a couple of comments.
It's my experience that an XCode project isn't going to be *required* to generate universal binaries, but that bypassing the automake dependency will both create a little pain and avoid a little pain in building the application itself. However, I'm not aware of the number of people using OpenDarwin, which doesn't have all of the libraries present on Mac OS X. So before moving the Mac OS X build process to proprietary tools and libs, it's worth considering whether you'd want to leave a target in place for OpenDarwin users that allows them to build Inkscape for a darwin platform using GTK+/X11 and GNU tools. The nice thing about XCode is that it allows you to take half- measures in adopting the Apple toolset.
On the first two points a 0.45 timeframe is a piece of cake. On the third, I agree with Ralf. I'm unsure how ambitious a 0.46 timeframe is for the native GTK+ libraries. The last time I built and looked at them (in April), there were pretty significant performance and reliability problems. That said, I'm really interested in working on them.
--David H
On 06/07/06, David Himelright <himelright.2@...1307...> wrote:
On Jul 6, 2006, at 8:08 AM, Ben Fowler wrote:
On 25/06/06, Jon A. Cruz <jon@...18...> wrote:
On Jun 25, 2006, at 12:31 AM, Ralf Stephan wrote:
Oh, another driving platform as far as I'm concerned would be OS X. ...
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, ...
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 roughly 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.
...
Hi Ben & Ralf, I have a little bit of experience now with the build process and Native GTK+, so I thought I'd interject with a couple of comments.
It's my experience that an XCode project isn't going to be *required* to generate universal binaries, but that bypassing the automake dependency will both create a little pain and avoid a little pain in building the application itself.
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_dev... 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?
However, I'm not aware of the number of people using OpenDarwin, which doesn't have all of the libraries present on Mac OS X.
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.
So before moving the Mac OS X build process to proprietary tools and libs, it's worth considering whether you'd want to leave a target in place for OpenDarwin users that allows them to build Inkscape for a darwin platform using GTK+/X11 and GNU tools.
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.
On the first two points a 0.45 timeframe is a piece of cake. On the third, I agree with Ralf. I'm unsure how ambitious a 0.46 timeframe is for the native GTK+ libraries. The last time I built and looked at them (in April), there were pretty significant performance and reliability problems. That said, I'm really interested in working on them.
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.
Ben Fowler wrote:
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.
That sounds like a lot of work. Would it be good to get that sort of work into SVN for others to build upon? Is this an incremental change thing that could be a compile flag in trunk? Or is it more suited to being worked on as a branch?
Aaron Spike
On Jul 6, 2006, at 9:48 AM, Ben Fowler 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_development/UniversalBinaries/ chapter_4_section_1.html 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?
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.
So before moving the Mac OS X build process to proprietary tools and libs, it's worth considering whether you'd want to leave a target in place for OpenDarwin users that allows them to build Inkscape for a darwin platform using GTK+/X11 and GNU tools.
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.
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.
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, 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 Jul 6, 2006, at 5:08 AM, Ben Fowler 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'.
Unfortunately this "pain" in this instance is not just a minor scratch, but the amputation of a few major limbs.
:-)
We're at 2.4 now. By jumping to 2.8 and past 2.6 we lose the support that has allowed me to develop on the Mac.
The equivalent would be to that of being on Ubuntu or Debian and dropping all use of the stock tools like apt, dpkg, etc., and pulling down source tarballs for everything, including all the way to X11 itself. (and not in the nice Gentoo way either).
I guess one factor for the other major platforms being left behind is what timeframe we're looking at (remember, at least one of the major distros isn't scheduling a release with 2.8+ support before December). If it's over six months out before we do a 0.45 release, then that is more reasonable. If we are targeting a shorter release cycle though, the move would be a lot more questionable.
Aside from the other issues, has anyone listed out what it is that we need in 2.8+ that's not in 2.4 and 2.6?
On 07/07/06, Jon A. Cruz <jon@...18...> wrote:
On Jul 6, 2006, at 5:08 AM, Ben Fowler 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'.
Unfortunately this "pain" in this instance is not just a minor scratch, but the amputation of a few major limbs.
:-)
We're at 2.4 now. By jumping to 2.8 and past 2.6 we lose the support that has allowed me to develop on the Mac.
Oh.
The equivalent would be to that of being on Ubuntu or Debian and dropping all use of the stock tools like apt, dpkg, etc., and pulling down source tarballs for everything, including all the way to X11 itself. (and not in the nice Gentoo way either).
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 guess one factor for the other major platforms being left behind is what timeframe we're looking at (remember, at least one of the major distros isn't scheduling a release with 2.8+ support before December). If it's over six months out before we do a 0.45 release, then that is more reasonable. If we are targeting a shorter release cycle though, the move would be a lot more questionable.
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.
Aside from the other issues, has anyone listed out what it is that we need in 2.8+ that's not in 2.4 and 2.6?
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
On Jul 7, 2006, at 3:07 AM, Ben Fowler wrote:
On 07/07/06, Jon A. Cruz <jon@...18...> wrote:
The equivalent would be to that of being on Ubuntu or Debian and dropping all use of the stock tools like apt, dpkg, etc., and pulling down source tarballs for everything, including all the way to X11 itself. (and not in the nice Gentoo way either).
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.
Jon, Ben,
My $0.02: I've been working on this problem myself recently:
http://sourceforge.net/tracker/index.php? func=detail&aid=1517872&group_id=93438&atid=604308
The major discovery I've made so far is that a number of packages we rely upon in fink are already present in Mac OS X, and a number of additional packages that fink relies on are obviated by moving to native pango, cairo, and GTK+ . Mac OS X already provides freetype, X11, libxml, libjpeg, libtiff, libpng etcetera as part of the sdk, and all of the dependencies on gtk-doc and the associated packages are unnecessary when you just build GTK+ without doc. So saying that you'd have to pull down source tarballs for everything is an overstatement, we're talking about a maximum of 18-20 with all of inkscape's features enabled.
When I first looked at the problem, I thought that it was going to be a major headache getting this stuff built from source. Once I'd taken away everything that wasn't necessary, and seen hints at further simplifications that could be made, I was left with 12 source packages to build (not including lcms, inkboard, and gnome-vfs).
As for maintaining builds with fink, it's certainly possible to submit .info files into the fink/unstable tree.
--David
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
On Fri, 2006-07-07 at 11:15 -0700, Bryce Harrington wrote:
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
I'm in favor of this proposal.
-mental
On Jul 7, 2006, at 6:48 PM, MenTaLguY wrote:
On Fri, 2006-07-07 at 11:15 -0700, Bryce Harrington wrote:
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
I'm in favor of this proposal.
-mental
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, Jul 08, 2006 at 12:06:21AM -0700, Jon A. Cruz wrote:
On Jul 7, 2006, at 6:48 PM, MenTaLguY wrote:
On Fri, 2006-07-07 at 11:15 -0700, Bryce Harrington wrote:
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
I'm in favor of this proposal.
-mental
Sounds good to me too.
Cool, if we can get a couple more people I think that'll be a sufficient concensus. Does anyone have any concerns?
It sounds like it will be helpful to have this plan in place, as it'll define priorities for the port maintainers to focus on for the coming months.
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. :-)
Yes, that's true. Does anyone know someone that works in the media app maintenance area for SuSE or RedHat? It would be useful to hear their feedback on how they plan to handle maintenance of inkscape in their release, including what kinds of patches they would want (i.e. security only? Bug fixes? Translations?) Anyone know SuSE / RedHat people they could ask?
Bryce
On Sat, 8 Jul 2006, Bryce Harrington wrote:
On Sat, Jul 08, 2006 at 12:06:21AM -0700, Jon A. Cruz wrote:
On Jul 7, 2006, at 6:48 PM, MenTaLguY wrote:
On Fri, 2006-07-07 at 11:15 -0700, Bryce Harrington wrote:
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
I'm in favor of this proposal.
Sounds good to me too.
Cool, if we can get a couple more people I think that'll be a sufficient concensus. Does anyone have any concerns?
No concerns here. Sounds good to me too.
Michael
Bryce:
... Does anyone know someone that works in the media app maintenance area for SuSE or RedHat? It would be useful to hear their feedback on how they plan to handle maintenance of inkscape in their release, including what kinds of patches they would want (i.e. security only? Bug fixes? Translations?) Anyone know SuSE / RedHat people they could ask?
I have asked someone at suse to forward the following letter:
Inkscape is an SVG editor application for Linux/Mac/Windows.
As a member of the inkscape development team, I'm looking for contact to relevant people maintaining the media apps who can say something on what SuSE needs from us for being able to support their products in the future. This step was made necessary by our plans to increase requirements for building inkscape from gtk+-2.4 in the upcoming 0.44.1 release to gtk+-2.6 in 0.45 (half a year from now at the earliest) and gtk+-2.8 in 0.46 (> 1 year). As your Enterprise products require gtk+-2.4 at the moment, we will maintain the 0.44.x branch at least until this requirement is lifted. For this, we need to know from you which changes to inkscape you want to be applied to that branch. Please understand that that version will not get any new features.
The possibilities include
[ ] security fixes only; [ ] severe bug fixes; [ ] all applicable bug fixes; [ ] translation fixes; and [ ] new translations.
Please give us feedback!
Regards Ralf "rwst" Stephan
----- Forwarded message from Bryce Harrington <bryce@...961...> -----
Date: Sat, 8 Jul 2006 14:58:16 -0700 From: Bryce Harrington <bryce@...961...> To: "Jon A. Cruz" <jon@...18...> Cc: Inkscape Devel List Inkscape-devel@lists.sourceforge.net, Ben Fowler <ben.the.mole@...400...>, MenTaLguY <mental@...3...> Subject: Re: [Inkscape-devel] Proposal: Upgrading Gtk for Inkscape 0.45 (was Re: Gtk 2.8 for 0.45?) Message-ID: <20060708215816.GC17746@...961...> References: <20060624202956.GK22746@...961...> <CADBB8FC-D1B7-4B43-86CC-E2A780FD2361@...18...> <20060625073128.GA4523@...748...> <906F8ED7-10D0-424B-B2DF-CA3154208476@...18...> <3b69e42c0607060508x272a530en38abf8c14101e82b@...401...> <141DB472-1787-4A88-AAA1-7C4B5ECB6F90@...18...> <3b69e42c0607070007r44eed02fp7ca3e7d3314cc419@...401...> <20060707181540.GA25724@...961...> <1152323285.5673.2.camel@...16...> <10D552F9-774C-4FBA-BF5C-84E825386979@...18...>
On Sat, Jul 08, 2006 at 12:06:21AM -0700, Jon A. Cruz wrote:
On Jul 7, 2006, at 6:48 PM, MenTaLguY wrote:
On Fri, 2006-07-07 at 11:15 -0700, Bryce Harrington wrote:
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
I'm in favor of this proposal.
-mental
Sounds good to me too.
Cool, if we can get a couple more people I think that'll be a sufficient concensus. Does anyone have any concerns?
It sounds like it will be helpful to have this plan in place, as it'll define priorities for the port maintainers to focus on for the coming months.
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. :-)
Yes, that's true. Does anyone know someone that works in the media app maintenance area for SuSE or RedHat? It would be useful to hear their feedback on how they plan to handle maintenance of inkscape in their release, including what kinds of patches they would want (i.e. security only? Bug fixes? Translations?) Anyone know SuSE / RedHat people they could ask?
Bryce
... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
----- End forwarded message -----
Bryce Harrington wrote:
Yes, that's true. Does anyone know someone that works in the media app maintenance area for SuSE or RedHat? It would be useful to hear their feedback on how they plan to handle maintenance of inkscape in their release, including what kinds of patches they would want (i.e. security only? Bug fixes? Translations?) Anyone know SuSE / RedHat people they could ask?
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 Buculei (OCAL) wrote:
Bryce Harrington wrote:
Yes, that's true. Does anyone know someone that works in the media app maintenance area for SuSE or RedHat? It would be useful to hear their feedback on how they plan to handle maintenance of inkscape in their release, including what kinds of patches they would want (i.e. security only? Bug fixes? Translations?) Anyone know SuSE / RedHat people they could ask?
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)
I got a reply from Red Hat people, I guess this is as official as one can get, se below:
Jonathan Blandford wrote: On Tue, 2006-07-11 at 11:22 -0400, Máirín Duffy wrote:
Hi Jonathan,
Do you have any thoughts on this or know who might?
FWIW Inkscape .44 (release just a few weeks ago) won't install on
RHEL 4. .43 installs no problem.
I would say it's up to them. People do use inkscape on RHEL, but they're likely to just keep using .43 if they make this change.
You can also let them know that we are interested in shipping inkscape in the next release of RHEL.
You wrote
Jonathan Blandford wrote: On Tue, 2006-07-11 at 11:22 -0400, M?ir?n Duffy wrote:
Hi Jonathan,
Do you have any thoughts on this or know who might?
FWIW Inkscape .44 (release just a few weeks ago) won't install on
RHEL 4. .43 installs no problem.
I would say it's up to them. People do use inkscape on RHEL, but they're likely to just keep using .43 if they make this change.
I'm quite sure that 0.44.1 will compile on RHEL.
ralf
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)
I got no response from SuSE, so, I guess, they don't care.
ralf
Bryce Harrington schrieb: ...
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.
...
Bryce
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 Sun, Jul 09, 2006 at 01:45:52PM +0200, Adib Taraben wrote:
Bryce Harrington schrieb: ...
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.
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.
That's true, but what I was referring to was more about gtk's support for use of cairo for rendering using gtk widgets (e.g. icons, etc.) Obviously, if we're just after cairo itself, for things like pdf export or SVG rendering in the canvas, that's a separate matter.
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?
I don't know, but it would be nice to get that patch integrated, if it's acceptable; or if not, to ensure feedback gets back to its author. :-)
Bryce
On Sat, 24 Jun 2006 13:29:57 -0700, Bryce Harrington wrote:
Yet 2.8 has been out a while, and has some new capabilities that would be nice to rely on. 2.8 would be more compelling of a change than 2.6,
What capabilities are those? Is it really worth leaving some users behind?
I'd like to propose that we change the dependency requirements for Inkscape to 2.8. Doing this right now gives us a maximum amount of testing time before 0.45.
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
participants (16)
-
Aaron Spike -
Adib Taraben -
Ben Fowler -
Bob Jamison -
Bryce Harrington -
David Himelright -
Jean-François Lemaire -
Jon A. Cruz -
jtaber -
MenTaLguY -
Michael Wybrow -
Mike Hearn -
Nicu Buculei -
Nicu Buculei (OCAL) -
Ralf Stephan -
Tavmjong Bah