Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Limiting GTK versions supported by SWT or SWT call for help

----- Original Message -----
> From: "Igor Fedorenko" <igor@xxxxxxxxxxxxxx>
> To: cross-project-issues-dev@xxxxxxxxxxx
> Sent: Wednesday, 8 October, 2014 12:38:10 PM
> Subject: Re: [cross-project-issues-dev] Limiting GTK versions supported by SWT	or SWT call for help
> 
> What major distribution still stuck with GTK2? Aren't they all on GTK3
> already?
> 
> --
> Regards,
> Igor
> 

RHEL 6/CentOS 6 only has GTK 2.20, IIRC

Mat Booth
Software Engineer, Red Hat Eclipse Team


> On 2014-10-08, 2:40, Aleksandar Kurtakov wrote:
> > ----- Original Message -----
> >> From: "Marc-André Laperle" <marc-andre.laperle@xxxxxxxxxxxx>
> >> To: "Cross project issues" <cross-project-issues-dev@xxxxxxxxxxx>
> >> Sent: Wednesday, October 8, 2014 6:25:14 AM
> >> Subject: Re: [cross-project-issues-dev] Limiting GTK versions supported by
> >> SWT	or SWT call for help
> >>
> >> Hi Alexander,
> >>
> >> "If this is not done, properties using GdkColor seem to no longer have
> >> effect/have problems, so it's only a matter of time how long such changes
> >> can be delayed"
> >>
> >> I am not familiar with this but it sounds like this shouldn't break if it
> >> was
> >> merely deprecated.
> >
> > But it's still a problem when we try to work on newer GTK version. E.g.
> > newer GTK functions work with GdkRGBA only but all through SWT codebase
> > GdkColor is used. There is no sane way we can do
> > GdkColor to GdkRGBA, call the function, GdkRGBA to GdkColor to store it.
> > And more the point even if technically possible if ignoring performance
> > problems it's not possible to achieve with current manpower.
> > And this is just one such example that is most visible and easy to explain
> > it is by no means the biggest such.
> >
> >
> >>  From the bugs I've experienced among the different GTK3
> >> versions, I've been thinking that maybe the main problem is that GTK is
> >> changing too quickly for its own good - or at least, too quickly for the
> >> community to keep up, compared to GTK2 which is in maintenance mode.
> >
> > Well, honestly it's mainly our problem trying to keep GTK3 and GTK2 ports
> > from the same codebase/branch. This is something GTK developers actively
> > discourage but we(SWT) are forced to do due to not enough manpower to
> > maintain two ports.
> > In many places if we don't have to keep up with GTK2 way adapting GTK3
> > would be way easier.
> >
> >> Is
> >> there a plan somewhere that indicates when GTK3 will enter maintenance
> >> mode
> >> and when development of GTK4 will start? I haven't found anything like
> >> that.
> >> I don't mean to sound negative though, I appreciate the enthusiasm and
> >> advances that are being made in GTK.
> >
> > If there is one thing that have to be made clear about GTK it is that it
> > suffers from the very same problem that SWT suffers from - many and
> > demanding users and almost no contributions. It's actually impressive how
> > compatible GTK 2 and 3 are (allowing us to target two major versions from
> > same codebase) with the resources they have.
> >
> >>
> >> About supporting only specific versions, I'm not sure which ones would get
> >> picked. I think one approach could be to support only versions that are
> >> included in popular distributions with longterm/extended support. For
> >> Ubuntu
> >> and Debian that would mean supporting 3.4 and 3.10. Looking at RHEL7 that
> >> would mean 3.8. That's already 3 different versions. I'm not sure what to
> >> do
> >> about Fedora since it moves more rapidly and doesn't have a
> >> longterm/extended support.
> >
> > Technically if we support 3.4 and 3.10 we have done all the work to support
> > all versions in between so having a "white list" of supported Gtk versions
> > has never been something I thought of. As I previously said many of the
> > problems are due to differences between Gtk 2 and 3 and SWT trying to play
> > with both aka not adhering to any recommendations. What I've been thinking
> > of is actively bumping the lowest level of supported Gtk 2.x version, this
> > would allow adopting SWT to GTK 3 way of doing things incrementally. E.g.
> > for Mars dropping non Cairo drawing (aka bump min Gtk version to 2.24)
> > would be nice start back to sanity.
> > There is GTK 3.14 released and GTK 3.16 will be released before Mars is out
> > so in order to not make things worse I (personal opinion) think we should
> > bump min Gtk version from current 2.10 to at least 2.14 to not make the
> > range bigger than it currently is. This should not affect any user but if
> > it affects someone please speak up and say what your plans are.
> >
> >> The thought of bundling a well tested GTK with
> >> Eclipse also crossed my mind but since it's LGPL that's not possible,
> >> unless
> >> I'm mistaken.
> >
> > I don't think this is an option at all.
> >
> >>
> >> About getting more people involved, I can only hope that people hear the
> >> call
> >> for help. From my experience, the SWT committers/contributors have been
> >> very
> >> supportive and appreciative of bug reports, testing and patches. On my
> >> end,
> >> I will be looking at improving compatibility with 3.10 (on Ubuntu) in my
> >> spare time so I can start using GTK3 on a day to day basis.
> >
> > Thank you Marc-Andre, your help with getting Luna out is highly appreciated
> > and I can just hope that more people act like you do.
> >
> > Alexander Kurtakov
> > Red Hat Eclipse team
> >
> >>
> >> Regards,
> >> Marc-Andre
> >> ________________________________________
> >> From: cross-project-issues-dev-bounces@xxxxxxxxxxx
> >> [cross-project-issues-dev-bounces@xxxxxxxxxxx] on behalf of Aleksandar
> >> Kurtakov [akurtako@xxxxxxxxxx]
> >> Sent: Tuesday, 07 October 2014 11:15 AM
> >> To: Cross project issues
> >> Subject: [cross-project-issues-dev] Limiting GTK versions supported by SWT
> >> or SWT call for help
> >>
> >> On behalf of SWT team (committers working on GTK port):
> >>
> >> The addition of the GTK+ 3.x based implementation of SWT which is now
> >> officially supported along with the GTK+ 2.x implementation means that the
> >> range of supported GTK+ versions has now grown pretty large and is in
> >> fact,
> >> continuing to grow with every release (for each x.y+1 SWT release, there
> >> are x.y+2 releases of GTK+). However, it is not practically possible for
> >> the current set of committers alone to actually test all these versions
> >> before we make a release. Therefore, we end up  "declaring" support for a
> >> huge range of GTK+ versions while the reality is that they are not tested
> >> and verified the way they must be to call them supported.
> >>
> >> Another consequence of this is that constantly having to convert between
> >> old-to-new or vice versa ways of doing things takes all our time, not
> >> allowing for any meaningful new developments or even to keep pace with the
> >> advancements in the platforms. There are two possible ways to improve this
> >> situation from our point of view:
> >>
> >> *) Others start to actively contribute to SWT - help improve the test
> >> suite, get a representative range of test machine variations running the
> >> tests so problems are caught earlier, get rid of dead bits from the
> >> code-base to ease migrations, etc. etc. Many of the tasks don't require
> >> any
> >> special OS specific knowledge as many seem to think before trying to help
> >> with SWT. Also, the current committers are more than willing to help new
> >> contributors with guidance and patch reviews as and when needed.
> >>
> >> *) Actively limiting the number of supported GTK+ versions - continually
> >> adapting to newer versions is really stretching the current resources. So,
> >> we end up with neither the old nor the new versions being in a really good
> >> shape. To overcome this limitation, it's needed that both groups of people
> >> (committers and end-users) participate actively as some of the soon to
> >> come
> >> changes in GTK+ require major overhaul of certain areas. For example,
> >> GdkColor is being deprecated and GdkRGBA is the new way of doing stuff but
> >> there are changes in too many places and there are huge chances to break
> >> some older versions. If this is not done, properties using GdkColor seem
> >> to
> >> no longer have effect/have problems, so it's only a matter of time how
> >> long
> >> such changes can be delayed. And this is just one of the examples, there
> >> are
> >> quite a few similar. As a bare minimum, we think that the range of
> >> supported GTK+ versions should not grow until people step up to help
> >> support a broader range.
> >>
> >> An ideal solution would be a combination of both the above approaches -
> >> having more people contributing to SWT + actively dropping support for
> >> older versions of GTK+.
> >>
> >> Please reply to this thread and let us know what your thoughts are. It
> >> would be very useful for us to also know which versions of GTK+ are being
> >> used widely and what is the minimum required version that you need support
> >> for from future releases of SWT (4.5+).
> >>
> >> Alexander Kurtakov
> >> Red Hat Eclipse team
> >>
> >> _______________________________________________
> >> cross-project-issues-dev mailing list
> >> cross-project-issues-dev@xxxxxxxxxxx
> >> To change your delivery options, retrieve your password, or unsubscribe
> >> from
> >> this list, visit
> >> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> >> _______________________________________________
> >> cross-project-issues-dev mailing list
> >> cross-project-issues-dev@xxxxxxxxxxx
> >> To change your delivery options, retrieve your password, or unsubscribe
> >> from
> >> this list, visit
> >> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> >>
> > _______________________________________________
> > cross-project-issues-dev mailing list
> > cross-project-issues-dev@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or unsubscribe
> > from this list, visit
> > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> >
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


Back to the top