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: "Mat Booth" <mat.booth@xxxxxxxxxx>
> To: "Cross project issues" <cross-project-issues-dev@xxxxxxxxxxx>
> Sent: Wednesday, October 8, 2014 4:27:25 PM
> Subject: 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

Slight correction - RHEL 6.6 (in public beta) contains update to GTK 2.24. 

Alexander Kurtakov
Red Hat Eclipse team

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