-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reduce complexity of native method bindings #871
Labels
enhancement
New feature or request
Comments
ptziegler
added a commit
to ptziegler/windowbuilder
that referenced
this issue
Aug 25, 2024
The Linux binaries are now created via an Ant script executed via Maven. This script calls "cmake ." and "make", and then overwrites the old binaries with the ones that have just been created. See eclipse-windowbuilder#871
ptziegler
added a commit
to ptziegler/windowbuilder
that referenced
this issue
Aug 25, 2024
The Linux binaries are now created via an Ant script executed via Maven. This script calls "cmake ." and "make", and then overwrites the old binaries with the ones that have just been created. See eclipse-windowbuilder#871
ptziegler
added a commit
to ptziegler/windowbuilder
that referenced
this issue
Aug 25, 2024
The Linux binaries are now created via an Ant script executed via Maven. This script calls "cmake ." and "make", and then overwrites the old binaries with the ones that have just been created. See eclipse-windowbuilder#871
ptziegler
added a commit
to ptziegler/windowbuilder
that referenced
this issue
Sep 13, 2024
The Linux binaries are now created via an Ant script executed via Maven. This script calls "cmake ." and "make", and then overwrites the old binaries with the ones that have just been created. See eclipse-windowbuilder#871
ptziegler
added a commit
to ptziegler/windowbuilder
that referenced
this issue
Sep 16, 2024
The Linux binaries are now created via an Ant script executed via Maven. This script calls "cmake ." and "make", and then overwrites the old binaries with the ones that have just been created. See eclipse-windowbuilder#871
ptziegler
added a commit
that referenced
this issue
Sep 17, 2024
The Linux binaries are now created via an Ant script executed via Maven. This script calls "cmake ." and "make", and then overwrites the old binaries with the ones that have just been created. See #871
ptziegler
added a commit
to ptziegler/windowbuilder
that referenced
this issue
Sep 21, 2024
By exposing gtk_widget_is_composited(), gtk_widget_get_opacity() and gtk_widget_set_opacity(), the get/setAlpha() methods which are currently implemented in C can now be implemented in Java. See eclipse-windowbuilder#871
ptziegler
added a commit
that referenced
this issue
Sep 21, 2024
By exposing gtk_widget_is_composited(), gtk_widget_get_opacity() and gtk_widget_set_opacity(), the get/setAlpha() methods which are currently implemented in C can now be implemented in Java. See #871
ptziegler
added a commit
to ptziegler/windowbuilder
that referenced
this issue
Sep 21, 2024
The method begin_shot() is now called gtk_widget_show_now() and end_shot() is now called gtk_widget_hide(). Given that the return type of both methods is always "true", it has been removed to match the signature of the GTK methods. See eclipse-windowbuilder#871
ptziegler
added a commit
to ptziegler/windowbuilder
that referenced
this issue
Sep 21, 2024
The method begin_shot() is now called gtk_widget_show_now() and end_shot() is now called gtk_widget_hide(). Given that the return type of both methods is always "true", it has been removed to match the signature of the GTK methods. See eclipse-windowbuilder#871
ptziegler
added a commit
that referenced
this issue
Sep 21, 2024
The method begin_shot() is now called gtk_widget_show_now() and end_shot() is now called gtk_widget_hide(). Given that the return type of both methods is always "true", it has been removed to match the signature of the GTK methods. See #871
ptziegler
added a commit
to ptziegler/windowbuilder
that referenced
this issue
Sep 21, 2024
This renames the getWidgetBounds() to _gtk_widget_get_allocation() and adapts the signature to expects a GtkAllocation object. On the C layer, this Java object is converted to a C object using the JGtkAllocation struct. This struct keeps track of all fields of the Java class and used to exchange the values with the Java layer. See eclipse-windowbuilder#871
ptziegler
added a commit
that referenced
this issue
Sep 21, 2024
This renames the getWidgetBounds() to _gtk_widget_get_allocation() and adapts the signature to expects a GtkAllocation object. On the C layer, this Java object is converted to a C object using the JGtkAllocation struct. This struct keeps track of all fields of the Java class and used to exchange the values with the Java layer. See #871
ptziegler
added a commit
to ptziegler/windowbuilder
that referenced
this issue
Sep 21, 2024
This exposes the following method to Java land, allowing us to implement this method directly: - gtk_tree_view_get_expander_column - gtk_tree_view_get_cell_area - gtk_tree_view_get_path_at_pos - gtk_tree_path_free This new implementation also avoids a potential resource leak where because previously, the tree path was not freed properly. See eclipse-windowbuilder#871
ptziegler
added a commit
to ptziegler/windowbuilder
that referenced
this issue
Sep 21, 2024
This exposes the following method to Java land, allowing us to implement this method directly: - gtk_tree_view_get_expander_column - gtk_tree_view_get_cell_area - gtk_tree_view_get_path_at_pos - gtk_tree_path_free This new implementation also avoids a potential resource leak because previously, the tree path was not freed properly. See eclipse-windowbuilder#871
ptziegler
added a commit
to ptziegler/windowbuilder
that referenced
this issue
Sep 21, 2024
This exposes the following methods to Java land, allowing us to implement this method directly: - gtk_tree_view_get_expander_column - gtk_tree_view_get_cell_area - gtk_tree_view_get_path_at_pos - gtk_tree_path_free This new implementation also avoids a potential resource leak because previously, the tree path was not freed properly. See eclipse-windowbuilder#871
ptziegler
added a commit
that referenced
this issue
Sep 22, 2024
This exposes the following methods to Java land, allowing us to implement this method directly: - gtk_tree_view_get_expander_column - gtk_tree_view_get_cell_area - gtk_tree_view_get_path_at_pos - gtk_tree_path_free This new implementation also avoids a potential resource leak because previously, the tree path was not freed properly. See #871
ptziegler
added a commit
to ptziegler/windowbuilder
that referenced
this issue
Sep 23, 2024
This exposes the GDK/Cairo methods to allow us to implement taking a screenshot of an SWT widget directly in Java. To improve readability, the C methods have been split into separate GDK, GTK and Cairo files. See eclipse-windowbuilder#871
ptziegler
added a commit
that referenced
this issue
Sep 30, 2024
This exposes the GDK/Cairo methods to allow us to implement taking a screenshot of an SWT widget directly in Java. To improve readability, the C methods have been split into separate GDK, GTK and Cairo files. See #871
ptziegler
added a commit
to ptziegler/windowbuilder
that referenced
this issue
Sep 30, 2024
Renames toggle_above and to gtk_window_set_keep_above, which is the method that is called internally. See eclipse-windowbuilder#871
ptziegler
added a commit
that referenced
this issue
Oct 1, 2024
Renames toggle_above and to gtk_window_set_keep_above, which is the method that is called internally. See #871
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
While working with the Linux fragment for the SWT screenshots again, I noticed a couple of issues that -if resolved- could greatly reduce the frustration when dealing with our native bindings:
When compiling e.g. the GTK bindings, one currently has to go to the C folder, invoke
cmake .
andmake
and then replace the shared objects in the destination folder with the newly created files. It's even more complicated on Windows, where one has to open the project in Visual Studio and start the compilation from there. We need a simple launch configuration in the projects that does all of this with a single click.The native bindings where created with both 32 and 64 bit in mind. As a result, the native methods are invoked using Integer and Long objects, rather than primitive types, causing a lot of boxing and unboxing within the C layer. Given that 32 bit is effectively unsupported, one could think about completely removing this ambiguity. My suggestion: Exclusively use
long
, so that the architecture with the longest memory addresses is the default. Any architectures with shorter memory addresses have to cast their values to e.g. anint
.On the Java side, this wouldn't be noticeable, as we exclusively work with
long
and on the C side, one would have to add a type cast (utilizing the pre-processor for the correct architecture) when calling the proper GTK methods. This would introduce an overhead for non-64-bit architectures but I think is this outweighed by no longer having to work on the Java objects.A lot of the logic is implemented directly in the C layer. This makes debugging next to impossible. Here I would propose a similar approach to what the SWT team has done; Have a very thin C layer that only forwards the method call.
For example, the following method could also be implemented in Java, as long as the three gtk methods are accessible.
windowbuilder/org.eclipse.wb.os.linux/native/gtk/gtk3/rcp.c
Lines 140 to 158 in 63f84fd
The text was updated successfully, but these errors were encountered: