[platform-swt-dev] Bumping minimum version of GTK3 to 3.14 in 4.11

Discussion:

Eric Williams

2018-11-29 17:03:20 UTC

Hello,

For the 4.11 release, I believe SWT will strongly benefit from moving to
a minimum version of GTK3.14. Here are some specific details:

-CSS for backgrounds and foregrounds is 3.14+, no more GtkStyleContext
background/foreground machinery

-no need to support pre-3.10 drawing model changes

-gtk-gradient CSS is gone in GTK4, we only use it for Combo on GTK3.12
and below

-removal of non-Cairo setRegion() drawing as this is 3.8 and below

-removal of pre-GTK3.10 DnD logic

-removal of miscellaneous functions such as: GtkWidget opacity,
GtkScrolledWindow add_with_viewport, etc.

-removal of several pre-GTK3.14 Table/Tree drawing hacks

-greatly allows for simplification of Cairo drawing in GC, as many of
these operations are guarded with GTK3.14+ calls

-allows SWT to rely solely on GTK CSS theme parsing, no more
GtkStyleContext lookups to get system colours

In summary, these changes would really simplify the codebase as almost
all the items mentioned above are gone in GTK4. With the introduction of
GTK4 guards it would be really beneficial if we could start to eliminate
the GTK3 specific version guards. Furthermore, it is very hard to find a
modern (supported) Linux distribution that ships with anything less than
GTK3.14 anymore, and the disconnect between the 3.14- and 3.24
methodologies is quite large.

If anyone has any concerns, please raise them.

Thanks,

--
Eric Williams
Software Engineer - Eclipse/SWT Team
Red Hat

Lars Vogel

2018-11-29 17:22:28 UTC

Permalink

+1 as PMC member

Post by Eric Williams
Hello,
For the 4.11 release, I believe SWT will strongly benefit from moving to
-CSS for backgrounds and foregrounds is 3.14+, no more GtkStyleContext
background/foreground machinery
-no need to support pre-3.10 drawing model changes
-gtk-gradient CSS is gone in GTK4, we only use it for Combo on GTK3.12
and below
-removal of non-Cairo setRegion() drawing as this is 3.8 and below
-removal of pre-GTK3.10 DnD logic
-removal of miscellaneous functions such as: GtkWidget opacity,
GtkScrolledWindow add_with_viewport, etc.
-removal of several pre-GTK3.14 Table/Tree drawing hacks
-greatly allows for simplification of Cairo drawing in GC, as many of
these operations are guarded with GTK3.14+ calls
-allows SWT to rely solely on GTK CSS theme parsing, no more
GtkStyleContext lookups to get system colours
In summary, these changes would really simplify the codebase as almost
all the items mentioned above are gone in GTK4. With the introduction of
GTK4 guards it would be really beneficial if we could start to eliminate
the GTK3 specific version guards. Furthermore, it is very hard to find a
modern (supported) Linux distribution that ships with anything less than
GTK3.14 anymore, and the disconnect between the 3.14- and 3.24
methodologies is quite large.
If anyone has any concerns, please raise them.
Thanks,
--
Eric Williams
Software Engineer - Eclipse/SWT Team
Red Hat
_______________________________________________
platform-swt-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-swt-dev

Andrey Loskutov

2018-11-29 17:39:02 UTC

Permalink

+1 from me.
No doubts, with more resources this would be may be different, but for now we have no other alternative. Maintaining this spaghetti code is a Nightmare.

Post by Eric Williams
Hello,
For the 4.11 release, I believe SWT will strongly benefit from moving to
-CSS for backgrounds and foregrounds is 3.14+, no more GtkStyleContext
background/foreground machinery
-no need to support pre-3.10 drawing model changes
-gtk-gradient CSS is gone in GTK4, we only use it for Combo on GTK3.12
and below
-removal of non-Cairo setRegion() drawing as this is 3.8 and below
-removal of pre-GTK3.10 DnD logic
-removal of miscellaneous functions such as: GtkWidget opacity,
GtkScrolledWindow add_with_viewport, etc.
-removal of several pre-GTK3.14 Table/Tree drawing hacks
-greatly allows for simplification of Cairo drawing in GC, as many of
these operations are guarded with GTK3.14+ calls
-allows SWT to rely solely on GTK CSS theme parsing, no more
GtkStyleContext lookups to get system colours
In summary, these changes would really simplify the codebase as almost
all the items mentioned above are gone in GTK4. With the introduction of
GTK4 guards it would be really beneficial if we could start to
eliminate
the GTK3 specific version guards. Furthermore, it is very hard to find a
modern (supported) Linux distribution that ships with anything less than
GTK3.14 anymore, and the disconnect between the 3.14- and 3.24
methodologies is quite large.
If anyone has any concerns, please raise them.
Thanks,

--
Kind regards,
Andrey Loskutov

http://google.com/+AndreyLoskutov

Leo Ufimtsev

2018-11-29 18:36:27 UTC

Permalink

+1. Multiple dnd logic is confusing.

Post by Andrey Loskutov
+1 from me.
No doubts, with more resources this would be may be different, but for now
we have no other alternative. Maintaining this spaghetti code is a
Nightmare.
Am 29. November 2018 18:03:20 MEZ schrieb Eric Williams <

--
Leo Ufimtsev
Senior Consultant, Red Hat Certified Engineer #150-127-462
Red Hat Consulting
***@redhat.com

Aleksandar Kurtakov

2018-11-29 18:48:34 UTC

Permalink

Post by Leo Ufimtsev
+1. Multiple dnd logic is confusing.

+1.
Sounds like we have an agreement from the people that touched the code in
the last few years :) .

Post by Leo Ufimtsev

Post by Andrey Loskutov
+1 from me.
No doubts, with more resources this would be may be different, but for
now we have no other alternative. Maintaining this spaghetti code is a
Nightmare.
Am 29. November 2018 18:03:20 MEZ schrieb Eric Williams <

--
Leo Ufimtsev
Senior Consultant, Red Hat Certified Engineer #150-127-462
Red Hat Consulting
_______________________________________________
platform-swt-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-swt-dev

--
Alexander Kurtakov
Red Hat Eclipse Team

Sravan K Lakkimsetti

2018-11-30 06:50:18 UTC

Permalink

We use SLES 12 on our JIPPs. And GTK version available here is 3.10.9.

Now moving to 3.14 will make the gerrit jobs to fail for all components(specifically UI tests). We will need to upgrade our infrastructure to upgrade OS on all JIPPs. I donât think that is a good option considering we are trying to move to Cloudbees Jenkins Enterprise(CJE). With CJE we will run on an OS configuration of our choosing

I suggest a delay to 4.12 as I am expecting CJE migration to be complete by that time.

Thanks and Regards,

Sravan

Sravan Kumar Lakkimsetti

IBM India Pvt Ltd,

Embassy Golf Links Business Park, D Block,

Off Indiranagar-Kormangla Inner Ring Road,

Bangalore - 560071, India

Phone: 91-80-41776858

From: Aleksandar Kurtakov <***@redhat.com>
Sent: Friday, November 30, 2018 12:19 AM
To: developers, Eclipse <platform-swt-***@eclipse.org>
Subject: Re: [platform-swt-dev] Bumping minimum version of GTK3 to 3.14 in 4.11

On Thu, Nov 29, 2018 at 8:36 PM Leo Ufimtsev <***@redhat.com <mailto:***@redhat.com> > wrote:

+1. Multiple dnd logic is confusing.

+1.

Sounds like we have an agreement from the people that touched the code in the last few years :) .

On Thu, Nov 29, 2018 at 12:39 PM Andrey Loskutov <***@gmx.de <mailto:***@gmx.de> > wrote:

+1 from me.
No doubts, with more resources this would be may be different, but for now we have no other alternative. Maintaining this spaghetti code is a Nightmare.

Post by Eric Williams
Hello,
For the 4.11 release, I believe SWT will strongly benefit from moving
to
-CSS for backgrounds and foregrounds is 3.14+, no more GtkStyleContext
background/foreground machinery
-no need to support pre-3.10 drawing model changes
-gtk-gradient CSS is gone in GTK4, we only use it for Combo on GTK3.12
and below
-removal of non-Cairo setRegion() drawing as this is 3.8 and below
-removal of pre-GTK3.10 DnD logic
-removal of miscellaneous functions such as: GtkWidget opacity,
GtkScrolledWindow add_with_viewport, etc.
-removal of several pre-GTK3.14 Table/Tree drawing hacks
-greatly allows for simplification of Cairo drawing in GC, as many of
these operations are guarded with GTK3.14+ calls
-allows SWT to rely solely on GTK CSS theme parsing, no more
GtkStyleContext lookups to get system colours
In summary, these changes would really simplify the codebase as almost
all the items mentioned above are gone in GTK4. With the introduction
of
GTK4 guards it would be really beneficial if we could start to
eliminate
the GTK3 specific version guards. Furthermore, it is very hard to find
a
modern (supported) Linux distribution that ships with anything less
than
GTK3.14 anymore, and the disconnect between the 3.14- and 3.24
methodologies is quite large.
If anyone has any concerns, please raise them.
Thanks,

--
Kind regards,
Andrey Loskutov

http://google.com/+AndreyLoskutov <http://google.com/+AndreyLoskutov>
_______________________________________________
platform-swt-dev mailing list
platform-swt-***@eclipse.org <mailto:platform-swt-***@eclipse.org>
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-swt-dev <https://www.eclipse.org/mailman/listinfo/platform-swt-dev>
--
Leo Ufimtsev

Senior Consultant, Red Hat Certified Engineer #150-127-462
Red Hat Consulting
***@redhat.com <mailto:***@redhat.com>

_______________________________________________
platform-swt-dev mailing list
platform-swt-***@eclipse.org <mailto:platform-swt-***@eclipse.org>
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-swt-dev <https://www.eclipse.org/mailman/listinfo/platform-swt-dev>

--
Alexander Kurtakov

Red Hat Eclipse Team

Aleksandar Kurtakov

2018-11-30 07:51:47 UTC

Permalink

On Fri, Nov 30, 2018 at 8:50 AM Sravan K Lakkimsetti <

Post by Sravan K Lakkimsetti
We use SLES 12 on our JIPPs. And GTK version available here is 3.10.9.

Now moving to 3.14 will make the gerrit jobs to fail for all

Post by Sravan K Lakkimsetti
components(specifically UI tests). We will need to upgrade our
infrastructure to upgrade OS on all JIPPs. I donât think that is a good
option considering we are trying to move to Cloudbees Jenkins
Enterprise(CJE). With CJE we will run on an OS configuration of our choosing
I suggest a delay to 4.12 as I am expecting CJE migration to be complete by that time.

I think we should take the middle ground here - and bump the min Gtk
version to Gtk 3.10. It would still be an improvement for maintenance and
will make the next round smaller. Furthermore, CJE migration might need
additional cycle (my previous experience with the SLES 11 -> 12 migration)
so we would better get what we can now.

Post by Sravan K Lakkimsetti
Thanks and Regards,
Sravan
Sravan Kumar Lakkimsetti
IBM India Pvt Ltd,
Embassy Golf Links Business Park, D Block,
Off Indiranagar-Kormangla Inner Ring Road,
Bangalore - 560071, India
Phone: 91-80-41776858
*Sent:* Friday, November 30, 2018 12:19 AM
*Subject:* Re: [platform-swt-dev] Bumping minimum version of GTK3 to 3.14
in 4.11
+1. Multiple dnd logic is confusing.
+1.
Sounds like we have an agreement from the people that touched the code in
the last few years :) .
+1 from me.
No doubts, with more resources this would be may be different, but for now
we have no other alternative. Maintaining this spaghetti code is a
Nightmare.
Am 29. November 2018 18:03:20 MEZ schrieb Eric Williams <

--
Kind regards,
Andrey Loskutov
http://google.com/+AndreyLoskutov
_______________________________________________
platform-swt-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-swt-dev
--
Leo Ufimtsev
Senior Consultant, Red Hat Certified Engineer #150-127-462
Red Hat Consulting
_______________________________________________
platform-swt-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-swt-dev
--
Alexander Kurtakov
Red Hat Eclipse Team
_______________________________________________
platform-swt-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-swt-dev

--
Alexander Kurtakov
Red Hat Eclipse Team

Sravan K Lakkimsetti

2018-11-30 07:56:49 UTC

Permalink

+1 for taking middle ground

Thanks and Regards,

Sravan

Sravan Kumar Lakkimsetti

IBM India Pvt Ltd,

Embassy Golf Links Business Park, D Block,

Off Indiranagar-Kormangla Inner Ring Road,

Bangalore - 560071, India

Phone: 91-80-41776858

From: Aleksandar Kurtakov <***@redhat.com>
Sent: Friday, November 30, 2018 1:23 PM
To: developers, Eclipse <platform-swt-***@eclipse.org>
Subject: Re: [platform-swt-dev] Bumping minimum version of GTK3 to 3.14 in4.11

On Fri, Nov 30, 2018 at 8:50 AM Sravan K Lakkimsetti <***@in.ibm.com <mailto:***@in.ibm.com> > wrote:

We use SLES 12 on our JIPPs. And GTK version available here is 3.10.9.

Now moving to 3.14 will make the gerrit jobs to fail for all components(specifically UI tests). We will need to upgrade our infrastructure to upgrade OS on all JIPPs. I donât think that is a good option considering we are trying to move to Cloudbees Jenkins Enterprise(CJE). With CJE we will run on an OS configuration of our choosing

I suggest a delay to 4.12 as I am expecting CJE migration to be complete by that time.

I think we should take the middle ground here - and bump the min Gtk version to Gtk 3.10. It would still be an improvement for maintenance and will make the next round smaller. Furthermore, CJE migration might need additional cycle (my previous experience with the SLES 11 -> 12 migration) so we would better get what we can now.

Thanks and Regards,

Sravan

Sravan Kumar Lakkimsetti

IBM India Pvt Ltd,

Embassy Golf Links Business Park, D Block,

Off Indiranagar-Kormangla Inner Ring Road,

Bangalore - 560071, India

Phone: 91-80-41776858

From: Aleksandar Kurtakov <***@redhat.com <mailto:***@redhat.com> >
Sent: Friday, November 30, 2018 12:19 AM
To: developers, Eclipse <platform-swt-***@eclipse.org <mailto:platform-swt-***@eclipse.org> >
Subject: Re: [platform-swt-dev] Bumping minimum version of GTK3 to 3.14 in 4.11

On Thu, Nov 29, 2018 at 8:36 PM Leo Ufimtsev <***@redhat.com <mailto:***@redhat.com> > wrote:

+1. Multiple dnd logic is confusing.

+1.

Sounds like we have an agreement from the people that touched the code in the last few years :) .

On Thu, Nov 29, 2018 at 12:39 PM Andrey Loskutov <***@gmx.de <mailto:***@gmx.de> > wrote:

+1 from me.
No doubts, with more resources this would be may be different, but for now we have no other alternative. Maintaining this spaghetti code is a Nightmare.

Post by Eric Williams
Hello,
For the 4.11 release, I believe SWT will strongly benefit from moving
to
-CSS for backgrounds and foregrounds is 3.14+, no more GtkStyleContext
background/foreground machinery
-no need to support pre-3.10 drawing model changes
-gtk-gradient CSS is gone in GTK4, we only use it for Combo on GTK3.12
and below
-removal of non-Cairo setRegion() drawing as this is 3.8 and below
-removal of pre-GTK3.10 DnD logic
-removal of miscellaneous functions such as: GtkWidget opacity,
GtkScrolledWindow add_with_viewport, etc.
-removal of several pre-GTK3.14 Table/Tree drawing hacks
-greatly allows for simplification of Cairo drawing in GC, as many of
these operations are guarded with GTK3.14+ calls
-allows SWT to rely solely on GTK CSS theme parsing, no more
GtkStyleContext lookups to get system colours
In summary, these changes would really simplify the codebase as almost
all the items mentioned above are gone in GTK4. With the introduction
of
GTK4 guards it would be really beneficial if we could start to
eliminate
the GTK3 specific version guards. Furthermore, it is very hard to find
a
modern (supported) Linux distribution that ships with anything less
than
GTK3.14 anymore, and the disconnect between the 3.14- and 3.24
methodologies is quite large.
If anyone has any concerns, please raise them.
Thanks,

--
Alexander Kurtakov

Red Hat Eclipse Team

Eric Williams

2018-12-03 18:39:26 UTC

Permalink

I have opened a ticket for this:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=541862

Eric

Post by Sravan K Lakkimsetti
+1 for taking middle ground
Thanks and Regards,
Sravan
Sravan Kumar Lakkimsetti
IBM India Pvt Ltd,
Embassy Golf Links Business Park, D Block,
Off Indiranagar-Kormangla Inner Ring Road,
Bangalore - 560071, India
Phone: 91-80-41776858
*Sent:* Friday, November 30, 2018 1:23 PM
*Subject:* Re: [platform-swt-dev] Bumping minimum version of GTK3 to
3.14 in4.11
On Fri, Nov 30, 2018 at 8:50 AM Sravan K Lakkimsetti
We use SLES 12 on our JIPPs. And GTK version available here is 3.10.9.
Now moving to 3.14 will make the gerrit jobs to fail for all
components(specifically UI tests). We will need to upgrade our
infrastructure to upgrade OS on all JIPPs. I don’t think that is a
good option considering we are trying to move to Cloudbees Jenkins
Enterprise(CJE). With CJE we will run on an OS configuration of our
choosing
I suggest a delay to 4.12 as I am expecting CJE migration to be
complete by that time.
I think we should take the middle ground here - and bump the min Gtk
version to Gtk 3.10. It would still be an improvement for maintenance
and will make the next round smaller. Furthermore, CJE migration might
need additional cycle (my previous experience with the SLES 11 -> 12
migration) so we would better get what we can now.
Thanks and Regards,
Sravan
Sravan Kumar Lakkimsetti
IBM India Pvt Ltd,
Embassy Golf Links Business Park, D Block,
Off Indiranagar-Kormangla Inner Ring Road,
Bangalore - 560071, India
Phone: 91-80-41776858
*Sent:* Friday, November 30, 2018 12:19 AM
*Subject:* Re: [platform-swt-dev] Bumping minimum version of GTK3 to
3.14 in 4.11
+1. Multiple dnd logic is confusing.
+1.
Sounds like we have an agreement from the people that touched the
code in the last few years :) .
On Thu, Nov 29, 2018 at 12:39 PM Andrey Loskutov
+1 from me.
No doubts, with more resources this would be may be
different, but for now we have no other alternative.
Maintaining this spaghetti code is a Nightmare.
Am 29. November 2018 18:03:20 MEZ schrieb Eric Williams

Post by Eric Williams
Hello,
For the 4.11 release, I believe SWT will strongly benefit

from moving

Post by Eric Williams
to
-CSS for backgrounds and foregrounds is 3.14+, no more

GtkStyleContext

Post by Eric Williams
background/foreground machinery
-no need to support pre-3.10 drawing model changes
-gtk-gradient CSS is gone in GTK4, we only use it for

Combo on GTK3.12

Post by Eric Williams
and below
-removal of non-Cairo setRegion() drawing as this is 3.8

and below

Post by Eric Williams
-removal of pre-GTK3.10 DnD logic
-removal of miscellaneous functions such as: GtkWidget

opacity,

Post by Eric Williams
GtkScrolledWindow add_with_viewport, etc.
-removal of several pre-GTK3.14 Table/Tree drawing hacks
-greatly allows for simplification of Cairo drawing in GC,

as many of

Post by Eric Williams
these operations are guarded with GTK3.14+ calls
-allows SWT to rely solely on GTK CSS theme parsing, no more
GtkStyleContext lookups to get system colours
In summary, these changes would really simplify the

codebase as almost

Post by Eric Williams
all the items mentioned above are gone in GTK4. With the

introduction

Post by Eric Williams
of
GTK4 guards it would be really beneficial if we could start to
eliminate
the GTK3 specific version guards. Furthermore, it is very

hard to find

Post by Eric Williams
a
modern (supported) Linux distribution that ships with

anything less

Post by Eric Williams
than
GTK3.14 anymore, and the disconnect between the 3.14- and

3.24

Post by Eric Williams
methodologies is quite large.
If anyone has any concerns, please raise them.
Thanks,

--
Kind regards,
Andrey Loskutov
http://google.com/+AndreyLoskutov
_______________________________________________
platform-swt-dev mailing list
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-swt-dev
--
Leo Ufimtsev
Senior Consultant, Red Hat Certified Engineer #150-127-462
Red Hat Consulting
_______________________________________________
platform-swt-dev mailing list
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-swt-dev
--
Alexander Kurtakov
Red Hat Eclipse Team
_______________________________________________
platform-swt-dev mailing list
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-swt-dev
--
Alexander Kurtakov
Red Hat Eclipse Team
_______________________________________________
platform-swt-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-swt-dev

Jonah Graham

2018-12-04 10:01:43 UTC

Permalink

Hi folks,

It seems that this discussion may be partly moot anyway as 2018-12 and
2018-09 already require at least GTK 3.7.6, perhaps later?

In July it was announced[1] that 3.0 was going to be the minimum version of
GTK. But changes[2] in the code base before 2018-09 was released means that
SWT does not work in (for example) GTK 3.6. The reason is that the change
uses a method in GTK that had its internal name changed between GTK 3.7.4
and 3.7.6. The GTK_TYPE_TEXT_VIEW_ACCESSIBLE macro changed[3] the symbol
used. So if you try and run Eclipse on an older GTK you get the following
and a JVM failed to start error popup.

/home/tools/local/java/Linux64/jdk8u172-b11/bin/java: symbol lookup error:
/home/hall/eclipse.2018.12/eclipse/configuration/org.eclipse.osgi/456/0/.cp/libswt-pi3-gtk-4922r31.so:
undefined symbol: gtk_text_view_accessible_get_type

as older GTK versions the symbol was _gtk_text_view_accessible_get_type.
(The GTK version for the above error is 3.6.2, I coincidentally came across
it yesterday when doing a customer site visit and came across an old Fedora
18 machine.)

Just to be clear, I am not asking for support for such old GTKs, but rather
for the documentation/N&N[4] to specify what the minimum GTK really is.

As a related issue, the above type of failure means that the checks in
Display.java (createDisplay) are also not working as intended because
instead of a warning to System.out ("***WARNING: SWT requires GTK[...]")
eclipse fails to load in OS.java's static initialization where it does
the loadLibrary.

Would you like me to turn any of the above into bug reports?

[1] https://www.eclipse.org/lists/cross-project-issues-dev/msg15783.html
[2] https://git.eclipse.org/r/#/c/127362/
[3]
https://gitlab.gnome.org/GNOME/gtk/commit/e4b5e94eb9500a83769771e6132f9abb08badb32#74676b17e9286f84d0c9256cce1338df7a8f538b_25_25
[4] https://www.eclipse.org/eclipse/news/4.10/platform.php#gtk2-removal

Thanks,
Jonah

~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com

Post by Eric Williams
https://bugs.eclipse.org/bugs/show_bug.cgi?id=541862
Eric

3.10.9.

Post by Sravan K Lakkimsetti
Now moving to 3.14 will make the gerrit jobs to fail for all
components(specifically UI tests). We will need to upgrade our
infrastructure to upgrade OS on all JIPPs. I donât think that is a
good option considering we are trying to move to Cloudbees Jenkins
Enterprise(CJE). With CJE we will run on an OS configuration of our
choosing
I suggest a delay to 4.12 as I am expecting CJE migration to be
complete by that time.
I think we should take the middle ground here - and bump the min Gtk
version to Gtk 3.10. It would still be an improvement for maintenance
and will make the next round smaller. Furthermore, CJE migration might
need additional cycle (my previous experience with the SLES 11 -> 12
migration) so we would better get what we can now.
Thanks and Regards,
Sravan
Sravan Kumar Lakkimsetti
IBM India Pvt Ltd,
Embassy Golf Links Business Park, D Block,
Off Indiranagar-Kormangla Inner Ring Road,
Bangalore - 560071, India
Phone: 91-80-41776858
*Sent:* Friday, November 30, 2018 12:19 AM
*Subject:* Re: [platform-swt-dev] Bumping minimum version of GTK3 to
3.14 in 4.11
+1. Multiple dnd logic is confusing.
+1.
Sounds like we have an agreement from the people that touched the
code in the last few years :) .
On Thu, Nov 29, 2018 at 12:39 PM Andrey Loskutov
+1 from me.
No doubts, with more resources this would be may be
different, but for now we have no other alternative.
Maintaining this spaghetti code is a Nightmare.
Am 29. November 2018 18:03:20 MEZ schrieb Eric Williams

Post by Eric Williams
Hello,
For the 4.11 release, I believe SWT will strongly benefit

from moving

Post by Eric Williams
to
a minimum version of GTK3.14. Here are some specific
-CSS for backgrounds and foregrounds is 3.14+, no more

GtkStyleContext

Post by Eric Williams
background/foreground machinery
-no need to support pre-3.10 drawing model changes
-gtk-gradient CSS is gone in GTK4, we only use it for

Combo on GTK3.12

Post by Eric Williams
and below
-removal of non-Cairo setRegion() drawing as this is 3.8

and below

Post by Eric Williams
-removal of pre-GTK3.10 DnD logic
-removal of miscellaneous functions such as: GtkWidget

opacity,

Post by Eric Williams
GtkScrolledWindow add_with_viewport, etc.
-removal of several pre-GTK3.14 Table/Tree drawing hacks
-greatly allows for simplification of Cairo drawing in GC,

as many of

Post by Eric Williams
these operations are guarded with GTK3.14+ calls
-allows SWT to rely solely on GTK CSS theme parsing, no

Post by Sravan K Lakkimsetti

Post by Eric Williams
GtkStyleContext lookups to get system colours
In summary, these changes would really simplify the

codebase as almost

Post by Eric Williams
all the items mentioned above are gone in GTK4. With the

introduction

Post by Eric Williams
of
GTK4 guards it would be really beneficial if we could

start to

Post by Sravan K Lakkimsetti

Post by Eric Williams
eliminate
the GTK3 specific version guards. Furthermore, it is very

hard to find

Post by Eric Williams
a
modern (supported) Linux distribution that ships with

anything less

Post by Eric Williams
than
GTK3.14 anymore, and the disconnect between the 3.14- and

3.24

Post by Eric Williams
methodologies is quite large.
If anyone has any concerns, please raise them.
Thanks,

--
Kind regards,
Andrey Loskutov
http://google.com/+AndreyLoskutov
_______________________________________________
platform-swt-dev mailing list
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-swt-dev
--
Leo Ufimtsev
Senior Consultant, Red Hat Certified Engineer #150-127-462
Red Hat Consulting
_______________________________________________
platform-swt-dev mailing list
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-swt-dev
--
Alexander Kurtakov
Red Hat Eclipse Team
_______________________________________________
platform-swt-dev mailing list
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-swt-dev
--
Alexander Kurtakov
Red Hat Eclipse Team
_______________________________________________
platform-swt-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe

from this list, visit

Post by Sravan K Lakkimsetti
https://www.eclipse.org/mailman/listinfo/platform-swt-dev

_______________________________________________
platform-swt-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-swt-dev

Eric Williams

2018-12-04 15:18:05 UTC

Permalink

Hi Jonah,

Post by Jonah Graham
Hi folks,
It seems that this discussion may be partly moot anyway as 2018-12 and
2018-09 already require at least GTK 3.7.6, perhaps later?
In July it was announced[1] that 3.0 was going to be the minimum version
of GTK. But changes[2] in the code base before 2018-09 was released
means that SWT does not work in (for example) GTK 3.6. The reason is
that the change uses a method in GTK that had its internal name changed
between GTK 3.7.4 and 3.7.6. The GTK_TYPE_TEXT_VIEW_ACCESSIBLE macro
changed[3] the symbol used. So if you try and run Eclipse on an older
GTK you get the following and a JVM failed to start error popup.
undefined symbol: gtk_text_view_accessible_get_type
as older GTK versions the symbol was _gtk_text_view_accessible_get_type.
(The GTK version for the above error is 3.6.2, I coincidentally came
across it yesterday when doing a customer site visit and came across an
old Fedora 18 machine.)
Just to be clear, I am not asking for support for such old GTKs, but
rather for the documentation/N&N[4] to specify what the minimum GTK
really is.

I don't think the N&N is the right place to do this, as this only
announces noteworthy changes/features. The GTK3 version support can be
found in the 4.10 plan, under target environments [1]. While there is no
hard version listed there (it only says "GTK+ 3"), none of the supported
target environments have any GTK3 older than 3.20. IMO there is also no
reasonable expectation that a distribution as old as Fedora 18 would run
4.8/9/10 Eclipse.

I do think having a short paragraph discussing GTK3 versions in the
target environments section would be a good idea, as there is often a
lot confusion around this subject.

Post by Jonah Graham
As a related issue, the above type of failure means that the checks in
Display.java (createDisplay) are also not working as intended because
instead of a warning to System.out ("***WARNING: SWT requires GTK[...]")
eclipse fails to load in OS.java's static initialization where it does
the loadLibrary.

--
Eric Williams
Software Engineer - Eclipse/SWT Team
Red Hat

Daniel Megert

2018-12-04 15:58:32 UTC

Permalink

Post by Eric Williams
I do think having a short paragraph discussing GTK3 versions in the
target environments section would be a good idea, as there is often a
lot confusion around this subject.

Please file a bug report (please cc me) and attach a Gerrit change for the
target environments section in the plan. The repository is
'git.eclipse.org:29418/www.eclipse.org/eclipse.git' and the path is
development/plans/eclipse_project_plan_4_10.xml

Dani

From: Eric Williams <***@redhat.com>
To: platform-swt-***@eclipse.org
Date: 04.12.2018 16:20
Subject: Re: [platform-swt-dev] Bumping minimum version of GTK3 to
3.14in4.11
Sent by: platform-swt-dev-***@eclipse.org

Hi Jonah,

Post by Eric Williams
Hi folks,
It seems that this discussion may be partly moot anyway as 2018-12 and
2018-09 already require at least GTK 3.7.6, perhaps later?
In July it was announced[1] that 3.0 was going to be the minimum version
of GTK. But changes[2] in the code base before 2018-09 was released
means that SWT does not work in (for example) GTK 3.6. The reason is
that the change uses a method in GTK that had its internal name changed
between GTK 3.7.4 and 3.7.6. The GTK_TYPE_TEXT_VIEW_ACCESSIBLE macro
changed[3] the symbol used. So if you try and run Eclipse on an older
GTK you get the following and a JVM failed to start error popup.
undefined symbol: gtk_text_view_accessible_get_type
as older GTK versions the symbol was _gtk_text_view_accessible_get_type.
(The GTK version for the above error is 3.6.2, I coincidentally came
across it yesterday when doing a customer site visit and came across an
old Fedora 18 machine.)
Just to be clear, I am not asking for support for such old GTKs, but
rather for the documentation/N&N[4] to specify what the minimum GTK
really is.

Post by Eric Williams
As a related issue, the above type of failure means that the checks in
Display.java (createDisplay) are also not working as intended because
instead of a warning to System.out ("***WARNING: SWT requires GTK[...]")
eclipse fails to load in OS.java's static initialization where it does
the loadLibrary.

This is a fair point, we should really do some sort of System.err
message in the static initialization block too, please open a bug for
this and add me as CC.

1:
https://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_10.xml#target_environments
--
Eric Williams
Software Engineer - Eclipse/SWT Team
Red Hat
_______________________________________________
platform-swt-dev mailing list
platform-swt-***@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-swt-dev

Jonah Graham

2018-12-05 10:33:20 UTC

Permalink

Thanks Eric. The GTK version issue does come up a lot and it is really
great to have the versions added explicitly to the project plan.

I submitted the bug report you requested at 542426
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=542426>
And for those who were interested, Eric submitted 542098
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=542098> and the project plan
has already been updated in the target_environments
<https://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_10.xml#target_environments>
section.

Thank you very much for resolving this issue and the quick turnaround on
getting this info into the project plan. I also saw Eric updated the FAQ
<https://www.eclipse.org/swt/faq.php#gtkstartup>, so thanks for catching
all these different areas.

Jonah

~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com

Post by Daniel Megert

Post by Eric Williams
I do think having a short paragraph discussing GTK3 versions in the
target environments section would be a good idea, as there is often a
lot confusion around this subject.

Please file a bug report (please cc me) and attach a Gerrit change for the
target environments section in the plan. The repository is '
git.eclipse.org:29418/www.eclipse.org/eclipse.git' and the path is
development/plans/eclipse_project_plan_4_10.xml
Dani
Date: 04.12.2018 16:20
Subject: Re: [platform-swt-dev] Bumping minimum version of GTK3 to
3.14in4.11
------------------------------
Hi Jonah,

I don't think the N&N is the right place to do this, as this only
announces noteworthy changes/features. The GTK3 version support can be
found in the 4.10 plan, under target environments [1]. While there is no
hard version listed there (it only says "GTK+ 3"), none of the supported
target environments have any GTK3 older than 3.20. IMO there is also no
reasonable expectation that a distribution as old as Fedora 18 would run
4.8/9/10 Eclipse.
I do think having a short paragraph discussing GTK3 versions in the
target environments section would be a good idea, as there is often a
lot confusion around this subject.

This is a fair point, we should really do some sort of System.err
message in the static initialization block too, please open a bug for
this and add me as CC.
https://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_10.xml#target_environments
--
Eric Williams
Software Engineer - Eclipse/SWT Team
Red Hat
_______________________________________________
platform-swt-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-swt-dev
_______________________________________________
platform-swt-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-swt-dev