| Re: [cross-project-issues-dev] Limiting GTK versions supported by SWT or SWT call for help |
Hi,
we are using 2.18.9 in production. We therefore test it continuously and
are also willing to provide fixes for it.
Best regards
Jonas
Am 10.10.2014 09:42, schrieb Aleksandar Kurtakov:
> ----- Original Message -----
>> From: "Marc-André Laperle" <marc-andre.laperle@xxxxxxxxxxxx>
>> To: "Cross project issues" <cross-project-issues-dev@xxxxxxxxxxx>
>> Sent: Thursday, October 9, 2014 8:09:53 PM
>> Subject: Re: [cross-project-issues-dev] Limiting GTK versions supported by SWT or SWT call for help
>>
>> I see in the target environments that Eclipse 4.5 supports SUSE Linux
>> Enterprise Server 11 which only has 2.14 according to the package list .
> Good catch, GTK was updated to 2.18 in SP2 we should clearly mark the requirement for service pack 2 being installed in the target environment. I have used foundation servers to do rpm -qi gtk2 and expect the rpm version, whether it's Suse's one and etc. and there is 2.18.9 there.
>
> https://www.suse.com/LinuxPackages/packageRouter.jsp?product=server&version=11&service_pack=sp2&architecture=x86_64&package_name=index_all
>
>> Aside from that, I think only supporting 2.18 and up sounds pretty safe.
>> Will it be sufficient to help the GTK3 situation though? It sounds like it
>> won't help the two examples you gave (using GdkRGBA and using cairo only to
>> draw).
> You're right. It would not help as much as I would like but it will give a clear sign that we reached the limit.
>
>> I also wonder how much time is really saved in testing, bug reporting
>> and fixing for 2.10/2.14 if they are so old that it's unlikely that people
>> use them.
> I personally don't do any checks fixes for GTK 2.20. Heck, even 2 weeks ago we have fixed a bug that was making Eclipse not start on certain combination of Cairo and GTK 2.24. (bug 441705)
>
>> I can see that in the code it will remove quite a bit of branches
>> so that's good for readability but will it make a difference for the GTK3
>> support stability and make it easier to adopt new recommendations? I was
>> under the impression that as long as 2.24 is supported, it will be hard to
>> adopt most of the new ways of GTK3. But you probably know a lot more that I
>> do about the subject :)
> Removing this code is big win. Think of the next one that join and try to fix something. I don't envy Anatoly (who did most of the GTK3 port) for starting and having to deal with stuff that was there for 2.0-2.10 compatibility and was not used at all. A lot of his time was spent dealing with such things instead of really working on GTK 3 problems. This is clearly something that is hurting the development and makes it way harder than it should be to work on SWT.
> Regarding the changes needed there are many things that have changed in 2.10-2.18 like - new tooltips code(bug 386772) (anyone experiencing the ever staying popups?), new clipboard/selection code (DnD problems anyone?), restacking windows (a lot of the direct X calls in for that and the GSoC student adding support for Wayland had to expect them one by one, could have worked on equinox.launcher instead), visibility notify (catch the signal and ignore?, no way to hurt performance :)), etc. One can say that removing this would not fix the bugs and will probably be right but if it makes the next person assigned a bug not scared and not losing time reading useless stuff we have achieved a lot.
> This was only about useless stuff. But there are new features that are not added as if we have to version guard them it will take twice the time to do them one I can think of is Link widget (GTK 2.18 supports link in GtkLabel) which can be improved that way meaning that we can stop caring about accessibility and let GTK care for that for us.
>
>
>> By the way, is it completely ruled out to have two ports? The GTK2 port could
>> remain almost untouched (critical bugs only) and the GTK3 port would be free
>> to use all the new GTK3 stuff. I remember that for a while, there was both
>> the Carbon and Cocoa port for Mac so people would be free to use the more
>> stable one and "modern" development could happen on the Cocoa port without
>> compromise. Eventually, Carbon was marked as unsupported and was removed
>> recently without fuss.
> All of the above equally benefits GTK 2 and 3 so things are not that different, the difference between 2.10 and 2.24 is probably bigger than between 2.24 and 3.8 from SWT POV. If others step in I would not mind having GTK 2 port (set in stone) and GTK 3(actively developed) but in the current situation I really think that having only one is better.
>
> 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: Thursday, 09 October 2014 12:00 AM
>> To: Cross project issues
>> Subject: Re: [cross-project-issues-dev] Limiting GTK versions supported by
>> SWT or SWT call for help
>>
>> ----- Original Message -----
>>> From: "Tom Schindl" <tom.schindl@xxxxxxxxxxxxxxx>
>>> To: cross-project-issues-dev@xxxxxxxxxxx
>>> Sent: Thursday, October 9, 2014 1:16:29 AM
>>> Subject: Re: [cross-project-issues-dev] Limiting GTK versions supported by
>>> SWT or SWT call for help
>>>
>>> hi,
>>>
>>> dropping Gtk2 means:
>>> * swing embed is broken when the Gtk-Theme is used because it links
>>> against Gtk2
>>> * javafx embed is broken because it links against Gtk2
>>>
>>> So clearly openjdk/oraclejdk (even the latest builds) links against
>>> Gtk2, or am I wrong in this regard?
>> Hi Tom,
>> My mail seems to be misunderstood. This is not a proposal to drop GTK 2.x
>> support (2.10 - 2.24) in general but to limit this support to only newer 2.x
>> versions (aka 2.18+). With 2.18 being released 5 years ago[1] and being in
>> strict maintenance mode for smth like last 4 years this is safe requirement.
>> It also DOES not require any change in Mars target environments [2] and will
>> satisfy even Luna [3].
>> So to make it clear GTK 2.18 up to 2.24 will still be supported.
>> By bumping this minimum requirement we open the door for streamlining swt
>> codebase as there are many changes that have happened (macros-> functions,
>> struct access -> functions, etc.) which are the same for newer GTK 2.x
>> (2.18-2.24) and GTK 3.x versions but we have different codepaths for older
>> GTK 2.x versions (2.10-2.17).
>> So this proposal will not affect the Swing problems in anyway.
>>
>> [1]
>> https://mail.gnome.org/archives/gtk-devel-list/2009-September/msg00054.html
>> [2]
>> https://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_5.xml#target_environments
>> [3]
>> https://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_4.xml#target_environments
>>
>> Alexander Kurtakov
>> Red Hat Eclipse team
>>
>>> I can also prove what Andrey said: We have turned of Gtk3 on *all* our
>>> linux desktops because there are too many problems with it.
>>>
>>> Tom
>>>
>>> On 08.10.14 16:18, Aleksandar Kurtakov wrote:
>>>> ----- Original Message -----
>>>>> From: "Andrey Loskutov" <loskutov@xxxxxx>
>>>>> To: "Cross project issues" <cross-project-issues-dev@xxxxxxxxxxx>,
>>>>> "Aleksandar Kurtakov" <akurtako@xxxxxxxxxx>
>>>>> Sent: Wednesday, October 8, 2014 5:11:53 PM
>>>>> Subject: Re: [cross-project-issues-dev] Limiting GTK versions supported
>>>>> by
>>>>> SWT or SWT call for help
>>>>>
>>>>> BTW we at Advantest are still using RHEL 5.8, even because RHEL has
>>>>> crazy
>>>>> long support times :o)
>>>>>
>>>>> Limiting to GTK3 only and drop GTK2 ports for *new* Eclipse releases
>>>>> would
>>>>> be
>>>>> good idea but AFAK GTK3 SWT port is still problematic (I'm on *latest*
>>>>> Ubuntu and must turn it off).
>>>>>
>>>>> In general I would also prefer to have always *one* (smallest possible
>>>>> from
>>>>> latest GTK on major distros) SWT port for latest Eclipse release but
>>>>> that
>>>>> port must be 99% usable.
>>>>>
>>>>> I won't hijack the thread, but the best long term solution for SWT Linux
>>>>> ports and Eclipse UI toolkit in general would be to move away from SWT
>>>>> to
>>>>> Java FX or better Qt (I know Qt LGPL license is a showstopper, but this
>>>>> *is*
>>>>> technically viable alternative). Without the man power of IBM (which
>>>>> originally allowed SWT to be developped for so many different
>>>>> plattforms)
>>>>> SWT as we have it today has no feature.
>>>> Options are endless. But let's try to limit the discussion towards Mars
>>>> and
>>>> Mars+1 for now. In this timeframe I don't think a new option will pop up
>>>> and I'm trying to solve our daily issues first so we can try to look a
>>>> bit
>>>> further.
>>>>
>>>>
>>>> Alexander Kurtakov
>>>> Red Hat Eclipse team
>>>>
>>>>>
>>>>> Am 8. Oktober 2014 16:44:30 OESZ, schrieb Aleksandar Kurtakov
>>>>> <akurtako@xxxxxxxxxx>:
>>>>>> ----- Original Message -----
>>>>>>> From: "Mat Booth" <mat.booth@xxxxxxxxxx>
>>>>>>> To: "Cross project issues" <cross-project-issues-dev@xxxxxxxxxxx>
>>>>>>> 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" <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
>>>>>
>>>>> --
>>>>> Kind regards,
>>>>> Andrey Loskutov
>>>>>
>>>>> http://google.com/+AndreyLoskutov
>>>>>
>>>> _______________________________________________
>>>> 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
_______________________________________________
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