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.lape...@ericsson.com> >> To: "Cross project issues" <cross-project-issues-dev@eclipse.org> >> 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-boun...@eclipse.org >> [cross-project-issues-dev-boun...@eclipse.org] on behalf of Aleksandar >> Kurtakov [akurt...@redhat.com] >> 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.schi...@bestsolution.at> >>> To: cross-project-issues-dev@eclipse.org >>> 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" <losku...@gmx.de> >>>>> To: "Cross project issues" <cross-project-issues-dev@eclipse.org>, >>>>> "Aleksandar Kurtakov" <akurt...@redhat.com> >>>>> 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 >>>>> <akurt...@redhat.com>: >>>>>> ----- Original Message ----- >>>>>>> From: "Mat Booth" <mat.bo...@redhat.com> >>>>>>> To: "Cross project issues" <cross-project-issues-dev@eclipse.org> >>>>>>> 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" <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 >>>>> >>>>> -- >>>>> Kind regards, >>>>> Andrey Loskutov >>>>> >>>>> http://google.com/+AndreyLoskutov >>>>> >>>> _______________________________________________ >>>> 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 _______________________________________________ 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
