Re: [cross-project-issues-dev] Limiting GTK versions supported by SWT or

[Aleksandar Kurtakov <akurtako@xxxxxxxxxx>]

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