Skip to content
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

Open
2 of 3 tasks
ptziegler opened this issue Aug 25, 2024 · 0 comments
Open
2 of 3 tasks

Reduce complexity of native method bindings #871

ptziegler opened this issue Aug 25, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@ptziegler
Copy link
Contributor

ptziegler commented Aug 25, 2024

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:

  • Automatic creation of shared objects/dlls.

When compiling e.g. the GTK bindings, one currently has to go to the C folder, invoke cmake . and make 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.

  • Improved handling of different architectures

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. an int.

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.

  • Moving complexity from C to Java layer

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.

static jboolean isPlusMinusTreeClick(GtkTreeView *tree, gint x, gint y) {
gint cell_x;
gint cell_y;
GtkTreePath *path;
GtkTreeViewColumn *column;
//
if (gtk_tree_view_get_path_at_pos(tree, x, y, &path, &column, &cell_x, &cell_y)) {
GtkTreeViewColumn *expanderColumn = gtk_tree_view_get_expander_column(tree);
if (expanderColumn == column) {
GdkRectangle rect;
gtk_tree_view_get_cell_area(tree, path, column, &rect);
if (x < rect.x) {
return JNI_TRUE;
}
}
}
return JNI_FALSE;
}

@ptziegler ptziegler added the enhancement New feature or request label Aug 25, 2024
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
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants
@ptziegler and others