Control: tags -1 + moreinfo
On Sun, 01 Feb 2026 at 01:40:02 +0100, Mazen Neifer wrote:
Building GTK bindings for Free Pascal using `git2pas` tool.
Do you mean gir2pascal, or something different? A tool of that name
doesn't seem to be packaged as a binary in Debian, although
lazarus-src-4.4 and similar packages seem to contain source code for it.
Cheked the definition of the fields in GIR file and compared it with relevant C
header files.
...
There is clearly a mismatch between C and GIR files.
What do you believe to be a clear mismatch between the C and the GIR
files? When reporting a bug it's usually best to describe what the
problem is, rather than expecting a reader to guess it from a proposed
solution.
Provided a patch to fix the issue.
The GIR XML is machine-generated from the C source, C header files and
shared library by tools in the gobject-introspection package, which are
the reference implementation of GObject-Introspection - so patching the
GIR XML by hand is not going to be the right solution to any problem.
line="703">a bit-mask representing the state of
the modifier keys (e.g. Control, Shift and Alt) and the pointer
buttons. See #GdkModifierType.</doc>
- <type name="ModifierType"/>
+ <type name="ModifierType" c:type="GdkModifierType*"/>
</field>
<field name="button" writable="1">
<doc xml:space="preserve"
If the gobject-introspection tools generate GIR XML that gir2pascal
can't cope with, then there are three possibilities:
1. C source, etc. mis-parsed by gobject-introspection;
2. wrong annotations (doc-comments) in GTK source that would have made
gobject-introspection generate the right thing if corrected;
3. gir2pascal is misinterpreting the GIR XML
Other introspected languages seem to work well, so it seems most likely
that you're encountering some sort of gir2pascal problem.
For the part of your patch quoted above, I believe it's referring to the
GIR XML describing the GtkEventButton struct:
<record name="EventButton" c:type="GdkEventButton">
... more fields ...
<field name="state" writable="1">
<type name="ModifierType"/>
</field>
... more fields ...
</record>
This seems like something that gir2pascal might reasonably be expected
to be able to cope with: although the c:type of this field is not
explicitly given in the GIR XML, gir2pascal should be able to infer that
it's the same bit-representation as the <bitfield name="ModifierType">
that appears elsewhere in the file.
Adding `c:type="GdkModifierType*"` is certainly wrong: the field is a
GdkModifierType (an integer, in practice 32 bits, containing flags), but
you seem to be saying that you believe it should be a pointer to a
GdkModifierType (in practice usually 64 bits). That isn't even the same
memory layout...
In fact the field is declared as `guint` rather than `GdkModifierType`
in the C source, but the doc-comment overrides it to be treated as
GdkModifierType by introspection (something that was done intentionally
by the GTK maintainers), and the whole GLib, GObject,
GObject-Introspection ecosystem has an architectural assumption that
enums are the same size as `int` and `unsigned int`.
smcv
