Gtk+ 3 build bit-rot alert!
Hello All,
I thought I'd quickly check how we're doing with the Gtk+ 3 build in Ubuntu Utopic, and was unpleasantly surprised to see that:
(a) A tonne more symbols that have been deprecated in Gtk+ 3.10 (principally, GtkAction)
(b) We have a few regressions, and have resumed use of some deprecated symbols that we had previously replaced. (e.g., GtkHBox)
I have updated bug #1016020 with the latest build log (20k lines caused by deprecation warnings!!) and summarised the failures in the description.
Obviously, (a) isn't our fault, but we should try to regain the progress we had made! (b) is more of a concern, since we're actually moving backwards!
Ultimately, we should really try to enforce "-Werror=deprecated-declarations" in our dev builds, but clearly we're far away from that goal. Would it be reasonable to target a deprecation-free build for Inkscape 1.0?
In the meantime, can I please request that from now on, everyone runs a strict build with both Gtk+ 2 and Gtk+ 3 before merging in any new features, so that we can ensure that we're not introducing any new warnings?
Thanks,
AV
On Fri, 2014-08-22 at 14:57 +0100, Alex Valavanis wrote:
Ultimately, we should really try to enforce "-Werror=deprecated-declarations" in our dev builds, but clearly we're far away from that goal. Would it be reasonable to target a deprecation-free build for Inkscape 1.0?
Not at all. If we target Gtk3 for 1.0, that should give us the needed impetus not to fall back on Gtk2 or other cruft.
Should we vote?
Martin,
You mean a complete switch to Gtk+ 3? It would clean things up a lot, but we'll have to do a huge amount of UX testing!
AV
On 22 August 2014 18:01, Martin Owens <doctormo@...400...> wrote:
On Fri, 2014-08-22 at 14:57 +0100, Alex Valavanis wrote:
Ultimately, we should really try to enforce "-Werror=deprecated-declarations" in our dev builds, but clearly we're far away from that goal. Would it be reasonable to target a deprecation-free build for Inkscape 1.0?
Not at all. If we target Gtk3 for 1.0, that should give us the needed impetus not to fall back on Gtk2 or other cruft.
Should we vote?
Martin,
On Fri, 2014-08-22 at 18:06 +0100, Alex Valavanis wrote:
You mean a complete switch to Gtk+ 3?
Yes! Gtk 3.0.0 is now almost four years old, can't dilly dally on gtk2 forever.
we'll have to do a huge amount of UX testing!
Huge amounts of anythings need check lists. Given enough pre-thought we could do a shared spreadsheet with a list and work away at it with an event of some kind.
Martin,
On Fri, Aug 22, 2014, at 10:01 AM, Martin Owens wrote:
On Fri, 2014-08-22 at 14:57 +0100, Alex Valavanis wrote:
Ultimately, we should really try to enforce "-Werror=deprecated-declarations" in our dev builds, but clearly we're far away from that goal. Would it be reasonable to target a deprecation-free build for Inkscape 1.0?
Not at all. If we target Gtk3 for 1.0, that should give us the needed impetus not to fall back on Gtk2 or other cruft.
Should we vote?
Can you use our wiki page for versions and update which distro's this would cut off? Being able to make an informed decision is usually a good thing.
@Jon, it wouldn't cut anyone off since all current Linux distros, devlibs & OSX are able to build the experimental Gtk+ 3 flavour.
@Martin, the obvious UX checklist would be to run through the tutorials and note any weirdness!
If we wanted to focus on Gtk+ 3 for Inkscape 1.0, the first switch could be just to build against Gtk+ 3 by default and offer an --enable-gtk2-compat build for the old libs (essentially the opposite of what we do now).
After UX testing, we can then do an enormous cleanup and get rid of the old code.
AV On 22 Aug 2014 18:17, "Jon A. Cruz" <jon@...18...> wrote:
On Fri, Aug 22, 2014, at 10:01 AM, Martin Owens wrote:
On Fri, 2014-08-22 at 14:57 +0100, Alex Valavanis wrote:
Ultimately, we should really try to enforce "-Werror=deprecated-declarations" in our dev builds, but clearly we're far away from that goal. Would it be reasonable to target a deprecation-free build for Inkscape 1.0?
Not at all. If we target Gtk3 for 1.0, that should give us the needed impetus not to fall back on Gtk2 or other cruft.
Should we vote?
Can you use our wiki page for versions and update which distro's this would cut off? Being able to make an informed decision is usually a good thing.
-- Jon A. Cruz jon@...18...
Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sat, Aug 23, 2014, at 01:30 AM, Alex Valavanis wrote:
@Jon, it wouldn't cut anyone off since all current Linux distros, devlibs & OSX are able to build the experimental Gtk+ 3 flavour.
Unfortunately it usually is nowhere near that simple in the real world. Although it is *possible*, we lose end-users when it is no longer simple and easy. If a distro has GTK3 libs in its repository then we're good. Otherwise...
The top Google search result is a page with instructions for using GTK3 on CentOS 6 which added this at the top of their page (in red):
"You don't want to do that unless you know Linux very well. Seriously. Just forget about GTK3 software."
Keep in mind that is coming from those who know and inform people on how to do the builds. We can get into the 'why's of it on another thread if people are interested, but this includes the fact that introducing non-package-owned software on a package managed distro is a source of all sorts of complications and errors.
So requiring GTK3 is clear on the Ubuntu front since 12.04LTS does include it in their repo. RHEL 5 and RHEL 6 do not, while the newly introduced RHEL 7 does. RHEL 5 can probably be safely regarded as "too old", but RHEL 6 is still in the middle of of its initial production phase which does not end until Q2 of 2016. Given that RHEL 7 is still at "dot 0", those using RHEL probably are not into a transition yet from 6 to 7.
This also is the state for many other distros that draw from RHEL including:
* CentOS
* Scientific Linux
* Oracle Linux
And definitely keep in mind that at least a large portion of our targeted end users are not highly technical linux coders, but those with the need to create graphics, such as artists and designers.
-- Jon A. Cruz jon@...18...
On Sat, Aug 23, 2014 at 1:12 PM, Jon A. Cruz <jon@...18...> wrote:
And definitely keep in mind that at least a large portion of our targeted end users are not highly technical linux coders, but those with the need to create graphics, such as artists and designers.
Also, let's not forget that a large number of people use laptops and the most common resolution is 1366x768... you can make the whole gui fit in the gtk2 ui, but a lot of stuff goes into overflow menus on the gtk3 one. We'll really need to figure out a better solution before forcing that on people.
Cheers, Josh
On 24-8-2014 5:25, Josh Andler wrote:
On Sat, Aug 23, 2014 at 1:12 PM, Jon A. Cruz <jon@...18...> wrote:
And definitely keep in mind that at least a large portion of our targeted end users are not highly technical linux coders, but those with the need to create graphics, such as artists and designers.
Also, let's not forget that a large number of people use laptops and the most common resolution is 1366x768... you can make the whole gui fit in the gtk2 ui, but a lot of stuff goes into overflow menus on the gtk3 one. We'll really need to figure out a better solution before forcing that on people.
This should then be the main focus point of the Gtk3 effort. Are there other usability issues with Gtk3?
To me it is obvious that maintaining both Gtk2 and Gtk3 is a huge burden on us, and after releasing 0.91, we should move ASAP to Gtk3. Those UI-dev cycles are so much better spent on improving the UI, instead of headaches about coding everything twice with different APIs.
regards, Johan
To me it is obvious that maintaining both Gtk2 and Gtk3 is a huge burden on us, and after releasing 0.91, we should move ASAP to Gtk3. Those UI-dev cycles are so much better spent on improving the UI, instead of headaches about coding everything twice with different APIs.
One thing that is a big burden on UI development is the lack of separation between UI and code. It's probably impossible but just in case, is there any technology out there that would be easy to incorporate to get some sort of templating in place for widget trees?
On Sat, 2014-08-23 at 13:12 -0700, Jon A. Cruz wrote:
On Sat, Aug 23, 2014, at 01:30 AM, Alex Valavanis wrote:
@Jon, it wouldn't cut anyone off since all current Linux distros, devlibs & OSX are able to build the experimental Gtk+ 3 flavour.
Unfortunately it usually is nowhere near that simple in the real world. Although it is *possible*, we lose end-users when it is no longer simple and easy. If a distro has GTK3 libs in its repository then we're good. Otherwise...
The top Google search result is a page with instructions for using GTK3 on CentOS 6 which added this at the top of their page (in red):
"You don't want to do that unless you know Linux very well.Seriously. Just forget about GTK3 software."
Keep in mind that is coming from those who know and inform people on how to do the builds. We can get into the 'why's of it on another thread if people are interested, but this includes the fact that introducing non-package-owned software on a package managed distro is a source of all sorts of complications and errors.
So requiring GTK3 is clear on the Ubuntu front since 12.04LTS does include it in their repo. RHEL 5 and RHEL 6 do not, while the newly introduced RHEL 7 does. RHEL 5 can probably be safely regarded as "too old", but RHEL 6 is still in the middle of of its initial production phase which does not end until Q2 of 2016. Given that RHEL 7 is still at "dot 0", those using RHEL probably are not into a transition yet from 6 to 7.
This also is the state for many other distros that draw from RHEL including:
CentOS
Scientific Linux
Oracle Linux
And definitely keep in mind that at least a large portion of our targeted end users are not highly technical linux coders, but those with the need to create graphics, such as artists and designers.
True, but the long-term releases are generally not targeted to this group. LTR's are more used on servers where long-term stability is important. In my previous life as a physicist, we would have the latest release on our desktops/laptops while our analysis farms would be running a LTR.
Also, don't forget that 0.92 isn't going to happen tomorrow...
Tav
On 24-8-2014 9:02, Tavmjong Bah wrote:
On Sat, 2014-08-23 at 13:12 -0700, Jon A. Cruz wrote:
On Sat, Aug 23, 2014, at 01:30 AM, Alex Valavanis wrote:
@Jon, it wouldn't cut anyone off since all current Linux distros, devlibs & OSX are able to build the experimental Gtk+ 3 flavour.
Unfortunately it usually is nowhere near that simple in the real world. Although it is *possible*, we lose end-users when it is no longer simple and easy. If a distro has GTK3 libs in its repository then we're good. Otherwise...
The top Google search result is a page with instructions for using GTK3 on CentOS 6 which added this at the top of their page (in red):
"You don't want to do that unless you know Linux very well.Seriously. Just forget about GTK3 software."
Keep in mind that is coming from those who know and inform people on how to do the builds. We can get into the 'why's of it on another thread if people are interested, but this includes the fact that introducing non-package-owned software on a package managed distro is a source of all sorts of complications and errors.
So requiring GTK3 is clear on the Ubuntu front since 12.04LTS does include it in their repo. RHEL 5 and RHEL 6 do not, while the newly introduced RHEL 7 does. RHEL 5 can probably be safely regarded as "too old", but RHEL 6 is still in the middle of of its initial production phase which does not end until Q2 of 2016. Given that RHEL 7 is still at "dot 0", those using RHEL probably are not into a transition yet from 6 to 7.
This also is the state for many other distros that draw from RHEL including:
CentOS
Scientific Linux
Oracle Linux
And definitely keep in mind that at least a large portion of our targeted end users are not highly technical linux coders, but those with the need to create graphics, such as artists and designers.
True, but the long-term releases are generally not targeted to this group. LTR's are more used on servers where long-term stability is important. In my previous life as a physicist, we would have the latest release on our desktops/laptops while our analysis farms would be running a LTR.
Also, don't forget that 0.92 isn't going to happen tomorrow...
I agree. What I gather from mails to our list, I think availability of GTK3 is not a problem for 0.92 onwards. This is similar to moving to C++11. The explanation is simply that working on an LTR/LTS system is not marriable (in general) to using supernew/trunk Inkscape; it would conflict (imho) with the "LTS" part of that system.
-Johan
On Sun, Aug 24, 2014, at 07:19 AM, Johan Engelen wrote:
I agree. What I gather from mails to our list, I think availability of GTK3 is not a problem for 0.92 onwards. This is similar to moving to C++11. The explanation is simply that working on an LTR/LTS system is not marriable (in general) to using supernew/trunk Inkscape; it would conflict (imho) with the "LTS" part of that system.
Well, just keep in mind that for CentOS, RHEL, etc., version 5 is equivalent to the LTS, 6 is 'stable', and 7 is currently akin to beta.
On Sun, Aug 24, 2014 at 04:19:23PM +0200, Johan Engelen wrote:
On 24-8-2014 9:02, Tavmjong Bah wrote:
On Sat, 2014-08-23 at 13:12 -0700, Jon A. Cruz wrote:
On Sat, Aug 23, 2014, at 01:30 AM, Alex Valavanis wrote:
@Jon, it wouldn't cut anyone off since all current Linux distros, devlibs & OSX are able to build the experimental Gtk+ 3 flavour.
So requiring GTK3 is clear on the Ubuntu front since 12.04LTS does include it in their repo. RHEL 5 and RHEL 6 do not, while the newly introduced RHEL 7 does. RHEL 5 can probably be safely regarded as "too old", but RHEL 6 is still in the middle of of its initial production phase which does not end until Q2 of 2016. Given that RHEL 7 is still at "dot 0", those using RHEL probably are not into a transition yet from 6 to 7.
And definitely keep in mind that at least a large portion of our targeted end users are not highly technical linux coders, but those with the need to create graphics, such as artists and designers.
True, but the long-term releases are generally not targeted to this group. LTR's are more used on servers where long-term stability is important. In my previous life as a physicist, we would have the latest release on our desktops/laptops while our analysis farms would be running a LTR.
Also, don't forget that 0.92 isn't going to happen tomorrow...
I agree. What I gather from mails to our list, I think availability of GTK3 is not a problem for 0.92 onwards. This is similar to moving to C++11. The explanation is simply that working on an LTR/LTS system is not marriable (in general) to using supernew/trunk Inkscape; it would conflict (imho) with the "LTS" part of that system.
I get where you're coming from, but I don't think that's a good generalization to make; there are desktop users who stick with the LTS yet still want to see updates for graphical applications. Hell, we were backporting the X stack to LTS releases for *gamers*.
But the key point seems to be that 0.91 has holding off on a variety of potentially de-stabilizing changes in order to ensure a stable release. So starting with 0.92 we *have* to start allowing some of these big changes through.
Where we could get into trouble is if when 0.92 opens up we try to change too many big things at once. Instead, lets plan out a roadmap for 0.92, 0.93, etc. and space out these changes a bit. If each release focuses on just one or two major changes, then I think it should be more feasible to accelerate the release schedule as well; if we could get it to one release per quarter that might be closer to ideal.
Bryce
participants (7)
-
Alex Valavanis -
Bryce Harrington -
Johan Engelen -
Jon A. Cruz -
Josh Andler -
Martin Owens -
Tavmjong Bah