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

Does anyone use those on Desktop? These are server distros with some
crazy support times. I have couple of VMs that use centos 6.5 to run
headless eclipse tests, but I think it'd be only fair if I had to
upgrade to centos 7 to use new eclipse versions, for example.

--
Regards,
Igor

On 2014-10-08, 9:27, Mat Booth wrote:
----- 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
_______________________________________________
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