Community
Participate
Working Groups
This patch uses gtk_scrollbar_new() instead of deprecated gtk_hscrollbar_new() and gtk_vscrollbar_new() for GTK+3 and higher: http://fedorapeople.org/cgit/aspektor/public_git/eclipse.platform.swt.git/commit/?h=gtk3_scrollbar_new
Hi Anatoly, The patch looks good and I have tested it with GTK 2.x. However, this patch introduces a GTK 3.x code path and I'm wondering if you've been able to actually test this particular path since as far as I understand, we cannot build the complete SWT library with GTK 3.x dependency as yet. If we cannot actually test the code with GTK 3.x right now, we have to either hold off from committing the patches or commit them and mark for testing later. I'm just thinking aloud, let me know if you have any other suggestions. Thanks!
(In reply to comment #1) > Hi Anatoly, > > The patch looks good and I have tested it with GTK 2.x. > However, this patch introduces a GTK 3.x code path and I'm wondering if > you've been able to actually test this particular path since as far as I > understand, we cannot build the complete SWT library with GTK 3.x dependency > as yet. > > If we cannot actually test the code with GTK 3.x right now, we have to > either hold off from committing the patches or commit them and mark for > testing later. I'm just thinking aloud, let me know if you have any other > suggestions. > > Thanks! Hey Arun, As you might have guessed, there is no way to test GTK 3 patches before we commit them and compile against GTK 3, on the other hand, without committing them, we are not able to compile at all, as these patches are required to build againt GTK+3. So I think that holding off from committing won't be a good idea. As I know, there was a suggestion brought up couple of times, regarding such cases, which I think would be best for now. Suggestion is to create separate gtk3 branch upstream, so we could use it as a master, and after all compilation errors are solved and we can compile against GTK+ 3, patches are tested, and branches are merged. What do you think about this idea ? Regards, Anatoly
(In reply to comment #2) > build againt GTK+3. So I think that holding off from committing won't be a > good idea. I understand and agree completely that not committing these patches isn't the right thing to do. > > separate gtk3 branch upstream, so we could use it as a master, and after all > compilation errors are solved and we can compile against GTK+ 3, patches are > tested, and branches are merged. Having a separate branch is an alternative and thats exactly what we did when we were making the Cairo drawing related changes. Silenio, do you think we need to have a separate branch too? My only concern was to avoid having changes that are not fully tested in master branch but on second thoughts it might not break anything since the GTK 3.x code path will not be exercised anyway. If you feel it is okay, we can commit to master branch and mark for testing later. I'm fine with either approach.
(In reply to comment #3) > Silenio, do you think we need to have a separate branch too? My only concern > was to avoid having changes that are not fully tested in master branch but > on second thoughts it might not break anything since the GTK 3.x code path > will not be exercised anyway. If you feel it is okay, we can commit to > master branch and mark for testing later. I'm fine with either approach. My vote is to put this patch in master directly since the code cannot cause problems to the GTK 2.x code path. The problem with a separate branch is that there will be no regular builds for it, so it will not be tested by the community until it gets merged into master.
(In reply to comment #4) > (In reply to comment #3) > > Silenio, do you think we need to have a separate branch too? My only concern > > was to avoid having changes that are not fully tested in master branch but > > on second thoughts it might not break anything since the GTK 3.x code path > > will not be exercised anyway. If you feel it is okay, we can commit to > > master branch and mark for testing later. I'm fine with either approach. > > My vote is to put this patch in master directly since the code cannot cause > problems to the GTK 2.x code path. The problem with a separate branch is > that there will be no regular builds for it, so it will not be tested by the > community until it gets merged into master. This solution works perfectly for me.
Pushed the patch to eclipse.org http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=6e60699d5dc28f66b62a845bf0b1a57aa83c551a with a minor change http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=cf0bd3fd1ec7876aa51811a1df8c52b9efccf824 Thanks! Silenio, should we mark these bugs that need to be tested separately with GTK 3.x using a keyword or something else?
Yes, how about gtk3test keyword?
(In reply to comment #7) > Yes, how about gtk3test keyword? +1
