Community
Participate
Working Groups
The old way of accessing the struct directly is made dynamic as they are no longer exposed in GTK 3. Commit/patch: http://fedorapeople.org/gitweb?p=akurtakov/public_git/eclipse.platform.swt.git;a=commit;h=034cc5eace7750f76bc08a765682bf9889967674
The natives GTK_SCROLLED_WINDOW_HSCROLLBAR and GTK_SCROLLED_WINDOW_VSCROLLBAR cannot be made dynamic since they are just #define in os_custom.h. They are not symbols exported by the gtk library.
(In reply to comment #1) > The natives GTK_SCROLLED_WINDOW_HSCROLLBAR and GTK_SCROLLED_WINDOW_VSCROLLBAR > cannot be made dynamic since they are just #define in os_custom.h. They are not > symbols exported by the gtk library. I know that but marking them dynamic makes the generated code in os.c use LOAD_FUNCTION which allows to compile when you have sealing enabled. I'll test it further but just wanted to explain the reasoning behind that.
Ok, my patch is working for gtk 2.8+ via the new call but it failing miserably when the old way (access the struct) was used. How should we proceed in this case? I don't see a clean way to compile the struct access in for newer gtk versions that don't expose the internals.
For compatibility reasons, I believe we have to compile against the oldest GTK version we want to support. So the field accessors in os_custom.h would not cause a compiler error. They would not cause a runtime error either because the native call in Java should be protected with a version check (i.e, code would not run for gtk3). If we want to allow people to compile against a newer version of GTK, we could add a version check in os_custom.h. Something like: #if GTK_CHECK_VERSION(2,8,0) #define GTK_SCROLLED_WINDOW_HSCROLLBAR(arg0) 0 #else #define GTK_SCROLLED_WINDOW_HSCROLLBAR(arg0) (arg0)->hscrollbar #endif but note that SWT libraries compiled this way would not work when running in older versions. This is probably ok if the app (i.e. eclipse, etc) gets compiled for a given distribution. This is not the case for the eclipse.org downloads. Would that work?
(In reply to comment #4) > For compatibility reasons, I believe we have to compile against the oldest GTK > version we want to support. So the field accessors in os_custom.h would not > cause a compiler error. They would not cause a runtime error either because the > native call in Java should be protected with a version check (i.e, code would > not run for gtk3). > > If we want to allow people to compile against a newer version of GTK, we could > add a version check in os_custom.h. Something like: > > > #if GTK_CHECK_VERSION(2,8,0) > #define GTK_SCROLLED_WINDOW_HSCROLLBAR(arg0) 0 > #else > #define GTK_SCROLLED_WINDOW_HSCROLLBAR(arg0) (arg0)->hscrollbar > #endif > > but note that SWT libraries compiled this way would not work when running in > older versions. This is probably ok if the app (i.e. eclipse, etc) gets > compiled for a given distribution. This is not the case for the eclipse.org > downloads. > > Would that work? Yes, this would definetely work for our case where we have to compile against newer libs. I'll prepare a new patch . Sorry for taking so long, this bug just got lost in my query.
Redone patch available at: http://fedorapeople.org/gitweb?p=akurtakov/public_git/eclipse.platform.swt.git;a=commit;h=2588a240633998eca4b2ffa8d53f15c8a428929f
Pushed to eclipse.org. Thanks! http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=2f67efb12116378f6c4fe455aa16cedec07ec5d6
