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