----- Original Message ----- > From: "Mat Booth" <mat.bo...@redhat.com> > To: "Cross project issues" <cross-project-issues-dev@eclipse.org> > 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" <i...@ifedorenko.com> > > To: cross-project-issues-dev@eclipse.org > > 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.lape...@ericsson.com> > > >> To: "Cross project issues" <cross-project-issues-dev@eclipse.org> > > >> 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-boun...@eclipse.org > > >> [cross-project-issues-dev-boun...@eclipse.org] on behalf of Aleksandar > > >> Kurtakov [akurt...@redhat.com] > > >> 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@eclipse.org > > >> 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@eclipse.org > > >> 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@eclipse.org > > > 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@eclipse.org > > 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@eclipse.org > 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@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
