I have a Nim gintro user who has both GTK4 and GTK3 installed on his
box, and seems to have some trouble:
https://github.com/StefanSalewski/gintro/issues/30
I can not test that, because for my Gentoo Linux box only GTK3 is
official available.
My gintro package should generate latest GTK3 bindin
On Tue, 3 Apr 2018 14:33:40 +
Carsten Mattner wrote:
> Looks like a crash in WebKitGTK+ which I suspect is used by Liferea
> to render HTML. Is your version of WebKitGTK+ working in Wayland?
I think so... Although, how do I tell? Fedora 27 is Wayland-based,
but I think there's a compatibilit
On 4/3/18, Pete Zaitcev wrote:
> On Tue, 3 Apr 2018 14:33:40 +
> Carsten Mattner wrote:
>
>> Looks like a crash in WebKitGTK+ which I suspect is used by Liferea
>> to render HTML. Is your version of WebKitGTK+ working in Wayland?
>
> I think so... Although, how do I tell? Fedora 27 is Wayland
On 4/1/18, Pete Zaitcev wrote:
> Dear All:
>
> Not sure where this belongs, but long story short: I tried to build
> Liferea, which crashes when it's done intropecting. Here's a traceback:
>
> (gdb) where
> #0 0x7fa90a2a93b0 in wl_list_insert_list ()
> at /lib64/libwayland-server.so.0
> #
Dear All:
Not sure where this belongs, but long story short: I tried to build
Liferea, which crashes when it's done intropecting. Here's a traceback:
(gdb) where
#0 0x7fa90a2a93b0 in wl_list_insert_list ()
at /lib64/libwayland-server.so.0
#1 0x7fa90a2a4e6f in wl_priv_signal_emit ()
On Fri, 2017-09-29 at 04:45 +, Gergely Polonkai wrote:
> As a side note, STRING probably refers to https://developer.gnome.org
> /glib/stable/glib-Strings.html which is a more OO string
> implementation. G_TYPE_STRING being gchararray is of more close
> relation with C strings (except it consis
macros like G_TYPE_STRING which
> for my box gives currently value 64. These values seems to be not
> directly supported by gobject-introspection. Seems to be no big
> problem, we may query the values by g-type-from-name().
>
>
> https://developer.gnome.org/gobject/stable/gobject-Type-Inf
gives currently value 64. These values seems to be not
directly supported by gobject-introspection. Seems to be no big
problem, we may query the values by g-type-from-name().
https://developer.gnome.org/gobject/stable/gobject-Type-Information.html#g-type-from-name
For G_TYPE_STRING I assumed that name
an icon name or %NULL
a stock icon size (#GtkIconSize)
So ctype is GtkIconSize, but due to name="gint" I get from gobject-
introspection only plain gint=int32. Unfortunately there ex
On Fri, 2017-09-15 at 10:28 +0100, Emmanuele Bassi wrote:
> All API that takes a GtkIconSize should have a `type int` annotation.
Thanks. I learned that already from the reply of Mr. Phil Clayton.
Seems that some functions like gtk_toolbar_set_icon_size() do not yet
have a `type int` annotation.
On 14 September 2017 at 21:12, Stefan Salewski wrote:
> GtkIconSize type is reported as plain gint, but it is an enum.
It's an "extensible" enumeration, like GtkResponseType for GtkDialog:
the API accepts an integer, because app and library developers can
register their own icon sizes, but GTK+ p
On Fri, 2017-09-15 at 09:57 +0100, Phil Clayton wrote:
> Have a look at
> https://bugzilla.gnome.org/show_bug.cgi?id=601425
Great, thanks.
I had looked only into the list of gobject-introspection bugs mentioned
at the bottom of this page:
https://wiki.gnome.org/action/show/Pr
(#GtkIconSize)
So ctype is GtkIconSize, but due to name="gint" I get from gobject-
introspection only plain gint=int32. Unfortunately there exists a few
functions with that bug, and it is some work fixing it manually. I will
investigate if there is a way to get the ctype fr
On Mon, 2017-09-11 at 07:25 +, Emmanuele Bassi wrote:
> If you're writing a language binding, you should use the GBoxed API
> for all boxed types, as that defers to the correct function without
> having to make up an annotation for copy and free functions.
That is interesting, thanks. I will r
go_font_description_free() for freeing.
>
> Do you suggest just using g_boxed_free() instead?
>
If you're writing a language binding, you should use the GBoxed API for all
boxed types, as that defers to the correct function without having to make
up an annotation for copy and free functi
t in the last few hours at least: Pango data types which
needs a ...destroy() function for freeing seems to be mostly marked
with introspectable="0". So my current impression is, that for all the
data types which I "see" from gobject introspection with transfer-
ownership="
Boxed types use g_boxed_free() to release resources, and g_boxed_copy() to
copy them:
https://developer.gnome.org/gobject/stable/gobject-Boxed-Types.html
Ciao,
Emmanuele.
On Sat, 9 Sep 2017 at 21:29, Stefan Salewski wrote:
> First I noticed that for pango_font_description_from_string()
>
> Fro
First I noticed that for pango_font_description_from_string()
>From /usr/share/gir-1.0/Pango-1.0.gir we know that transfer-
ownership="full" so we have to free it in our language bindings.
But how to guess the function for freeing?
For gobject there is generally a plain g_object_unref() necessar
On Sat, 2017-07-15 at 18:21 +0200, Nicola Fontana wrote:
> They have been included in gobject-introspection 1.53.2, released
> on may:
>
> https://git.gnome.org/browse/gobject-introspection/log/
Fine.
My Gentoo box has still
dev-libs/glib-2.50.3-r1:2::gentoo
I will try to grab the
t; > Ciao.
>
> Is it already known when these patches will be available for ordinary
> users?
> ...
They have been included in gobject-introspection 1.53.2, released
on may:
https://git.gnome.org/browse/gobject-introspection/log/
Ciao.
--
Nicola
___
On Tue, 2017-05-09 at 17:05 +0200, Nicola Fontana wrote:
> Il Tue, 09 May 2017 16:39:10 +0200 Stefan Salewski > scrisse:
>
> > I am currently working again on the gobject introspection based
> > bindings for Nim language (https://github.com/StefanSalewski/nim-gi
> > )
can gtk-doc and gobject-introspection be used for a library that don't
have gobjects?
i have a library that is only a set of utility functions (that use
glib/gtk/etc): can i use gtk-doc and/or gobject-introspection?
thanks in advance
___
gtk
Il Tue, 09 May 2017 16:39:10 +0200 Stefan Salewski scrisse:
> I am currently working again on the gobject introspection based
> bindings for Nim language (https://github.com/StefanSalewski/nim-gi).
>
> And I wonder why there is only minimal support for cairo --
> /usr/share/gi
On 9 May 2017 at 15:39, Stefan Salewski wrote:
> I am currently working again on the gobject introspection based
> bindings for Nim language (https://github.com/StefanSalewski/nim-gi).
>
> And I wonder why there is only minimal support for cairo --
> /usr/share/gir-1.0/cairo-1.0
I am currently working again on the gobject introspection based
bindings for Nim language (https://github.com/StefanSalewski/nim-gi).
And I wonder why there is only minimal support for cairo --
/usr/share/gir-1.0/cairo-1.0.gir is minimal.
Of course cairo is not gobject based, but is that the
ox, I
thought I was doing something wrong.
But it is already reported in bug696935 -- one of 283 open bugs.
But in spite of that, gobject introspection seems to be a very useful
tool. Rust people seems to use it too.
___
gtk-list mailing list
gtk-list@gnome.o
On 13 February 2017 at 11:19, Stefan Salewski wrote:
> Is gobject-introspection unmaintained?
It's not heavily maintained, but it's not unmaintained either.
> I found a github reposity at
>
> https://github.com/GNOME/gobject-introspection
The GitHub GNOME organiz
Is gobject-introspection unmaintained?
I found a github reposity at
https://github.com/GNOME/gobject-introspection
but the issue tracker is disabled.
As you may know, I have done some work on a higher level GTK Nim
wrapper recently. Starting with the API docs
https://developer.gnome.org/gi
https://developer.gnome.org/gi/1.50/gi-GIFieldInfo.html#g-field-info-get-size
Is someone still familiar with GObject Introspection?
I am investigating creating high level GObject Introspection based Nim bindings.
Most seems to work well, some not: For example
g-field-info-get-size()
seems to
Could you share your Gir file?
>>
>
>
>
>
> xmlns="http://www.gtk.org/introspection/core/1.0";
> xmlns:c="http://www.gtk.org/introspection/c/1.0";
> xmlns:glib="http://www.gtk.org/introspection/glib/1.0"
For better manage, all your returns should be basic, boxed and GObjects,
it's transparent for GI to manage them because it knows how copy,
instantiate and delete them. I'm not really sure but you can say to GI what
functions to call on GIR but better library use registered GType to easy
live to GI.
i have a library (the same as thet thread before) that have a method
that returns a gnode
but when it is introspected by g-ir-scanner i got
Warning: Confi: confi_get_tree: return value: Invalid non-constant
return of bare structure or union; register as boxed type or (skip)
how must i anno
i/libconfi;a=tree;h=refs/heads/introspection;hb=refs/heads/introspection
for now, thank you very much for the help
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list
ritten, for example, in
>> phython?
>>
>
> what do you mean with "internal"?
>
> libconfi (and others libraries that i said) is a library that i used with
> my softwares; as i do with gtk or libgda or ...
>
>
> If it's internal not to be
with "internal"?
libconfi (and others libraries that i said) is a library that i used
with my softwares; as i do with gtk or libgda or ...
If it's internal not to be used in scripts, then you don't need to expose
its API to GObject Introspection (GI).
https:
API to GObject Introspection (GI).
https://wiki.gnome.org/Projects/GObjectIntrospection/Annotations
But that means to modify code in the library to add comments.
Because this libconfi is not fully introspectable (at least automatically)
library, you should use (rename-to) annotation, I think in
Il giorno gio 20 nov 2014 22:06:15 CET, Daniel Espinosa ha scritto:
I found in your GIR file, it don't detect (for example) confi_new() as a
function of Confi object and it is not introspectable. Also, all functions
are "free" no related to any GObject. Then you haven't provided enough
informatio
Il giorno mer 19 nov 2014 18:20:17 CET, Daniel Espinosa ha scritto:
1. Could you share your Gir file?
http://www.gtk.org/introspection/core/1.0";
xmlns:c="http://www.gtk.org/introspection/c/1.0";
xmlns:glib="http://www.gtk.org/in
1. Could you share your Gir file?
2. Is a good idea to add a namespace. Like your main project prefix. This
avoids introspection function and objects name collisions.
El 19/11/2014 05:13, "Andrea Zagli" escribió:
> i made a very l
);
===
now i want to add introspection; i follow
https://wiki.gnome.org/Projects/GObjectIntrospection/AutotoolsIntegration and
i can build the library and gir file
but if i try to use it from python i get errors
Hi all,
I am trying to build gobject-introspection 1.34.2 with support for glib 2.35.9.
I have glib 2.35.9 installed and am getting stuck on the part of the
Makefile for gobject-introspection involving the checking for the
required shell env variables.
The make command doesn't seem t
bject-introspection.
I have suffered for a while and still could not get this package installed. I
have fitured out the reason for this problem. During configure and make stage,
the path to glib-2.0 is using /usr/local, but during install it uses /usr
The maintainer assured me that this is not a bug, but r
hides internal definition and forces the developer to use the
API. This way GObject Introspection will always make bindings to
modify struct fields as expected by the implementator and makes very
easy to automatically generate GIR files with the required API.
2011/12/2 Tal Liron :
Thanks!
I solved
Struct MyStruct;
>
> This hides internal definition and forces the developer to use the
> API. This way GObject Introspection will always make bindings to
> modify struct fields as expected by the implementator and makes very
> easy to automatically generate GIR files with the require
internal definition and forces the developer to use the
API. This way GObject Introspection will always make bindings to
modify struct fields as expected by the implementator and makes very
easy to automatically generate GIR files with the required API.
2011/12/2 Tal Liron :
> Thanks!
>
>
No one have sent any response message.
I've added this annotations to GdaNumeric, but GIR and Vala bindings
make no difference. Both use GdaNumeric, as declared on GDA, as a
GBoxed and use g_boxed_copy and g_boxed_free functions.
May be this help was added but not implemented jet.
2011/12/2 Tal
Resently has been added the following annotations for gtk-doc headings:
Set value func:
Get value func:
in GDA we have a GdaNumeric struct with gda_value_set_numeric and
gda_value_get_numeric to set this Boxed Derived type to a GValue is it
correct to add the following annotations:
/**
* GdaNum
Dieter Verfaillie wrote:
>> Such things as needing to convert \\ to /
>
> Are you still getting those even with os.path.join() being
> monkey-patched? From my windows branch:
> https://github.com/dieterv/gobject-introspection/commit/75ff95092d952c0e4aa17ad58de5a02da54c1240
I
my windows branch:
https://github.com/dieterv/gobject-introspection/commit/75ff95092d952c0e4aa17ad58de5a02da54c1240
mvg,
Dieter
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Dieter Verfaillie wrote:
> On 15/10/2011 18:49, Earnie wrote:
>> I'm building gobject-introspection-1.30.0 with MSYS and MinGW. I'm
>> to the point of the GISCAN GLib-2.0.gir and it reports "No
>> mscvr71.dll loaded." I'm using the python.org provided
On 15/10/2011 18:49, Earnie wrote:
> I'm building gobject-introspection-1.30.0 with MSYS and MinGW. I'm to
> the point of the GISCAN GLib-2.0.gir and it reports "No mscvr71.dll
> loaded." I'm using the python.org provided Windows distribution version
> 2.7.
Earnie wrote:
> Earnie wrote:
>> Earnie wrote:
>>> I'm building gobject-introspection-1.30.0 with MSYS and MinGW.
>>> I'm to the point of the GISCAN GLib-2.0.gir and it reports "No
>>> mscvr71.dll loaded." I'm using the python.org provi
Earnie wrote:
> Earnie wrote:
>> I'm building gobject-introspection-1.30.0 with MSYS and MinGW. I'm
>> to the point of the GISCAN GLib-2.0.gir and it reports "No
>> mscvr71.dll loaded." I'm using the python.org provided Windows
>> distribution v
Earnie wrote:
> I'm building gobject-introspection-1.30.0 with MSYS and MinGW. I'm
> to the point of the GISCAN GLib-2.0.gir and it reports "No
> mscvr71.dll loaded." I'm using the python.org provided Windows
> distribution version 2.7. I had to modify the hac
I'm building gobject-introspection-1.30.0 with MSYS and MinGW. I'm to
the point of the GISCAN GLib-2.0.gir and it reports "No mscvr71.dll
loaded." I'm using the python.org provided Windows distribution version
2.7. I had to modify the hack in giscanner/utils.py at l
I've filed bug #657743, because I have an struct with a GSList to contain
another struct type element. I've added (element-type Gda.SqlSelectTarget)
annotation to gtk-doc as shown, but generated GIR doesn't set ctype: to
GdaSqlSelectFrom, instead use gpointer.
/**
* GdaSqlSelectFrom:
* @any: inh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi.
We recently did some experiments with porting PyGtk code to PyGi and
stumbled over the Drag and Drop handling. In PyGtk nothing more than the
following is required to allow a tree view to handle file drops:
> view = gtk.TreeView()
>
> view.drag_d
Hi,
I just updated to git trunk and now pango autogen.sh requires
introspection.m4 yet the application itself does not require
introspection. Is there a simple way (other than hacking at autogen.sh
and associated files) to remove this dependency
On Tue, 2008-07-08 at 13:02 +0200, Andreas Sliwka wrote:
> Greetings,
> I'd like to query a Gobject for its properties. Browsing through the
> header files I found g_object_class_list_properties(), which takes a
> GObjectClass as first parameter. Now how do I get this GObjectClass
> from GObject?
Greetings,
I'd like to query a Gobject for its properties. Browsing through the
header files I found g_object_class_list_properties(), which takes a
GObjectClass as first parameter. Now how do I get this GObjectClass
from GObject? Is this possible at all, if not, is this planned for a
future vers
Shreevatsa R <[EMAIL PROTECTED]> wrote:
>Consider this a feature request. It would be useful to have a program
>with which you can point at any running GTK application, and find out
>what widgets you're seeing and what names have been set. This way one
>can figure out what to put in the .gtkrc file
On Feb 2, 2008 11:13 PM, Shreevatsa R <[EMAIL PROTECTED]> wrote:
>
> Consider this a feature request. It would be useful to have a program
> with which you can point at any running GTK application, and find out
> what widgets you're seeing and what names have been set.
Have you tried at-poke.
http:
Consider this a feature request. It would be useful to have a program
with which you can point at any running GTK application, and find out
what widgets you're seeing and what names have been set. This way one
can figure out what to put in the .gtkrc files to edit the appearance
of those widgets (
<[EMAIL PROTECTED]> writes:
> Is there any sort of introspection facility built into gtk? For example,
> I'd like to be able to ask a widget what signals it knows about and what its
> property names are. This isn't perhaps such a useful thing when programming
> i
Is there any sort of introspection facility built into gtk? For example,
I'd like to be able to ask a widget what signals it knows about and what its
property names are. This isn't perhaps such a useful thing when programming
in C, but I've gotten kind of spoiled working with Py
65 matches
Mail list logo