On Fri, May 9, 2014 at 5:01 AM, Javier Jardón wrote:
> I already pushed a branch in the git repository with the GTK+3 port [1]
> ...
> [1] https://git.gnome.org/browse/gtkglarea/log/?h=jjardon/gtk3
This branch is working well for me.
I've created a ticket and patch [1] adding introspection suppo
Hi All,
In an effort to cleanup the Python bindings, I have been auditing the
plethora of overrides to see what can be removed [1]. There are a handful
of cases where the binding machinery could handle things given more
information from GI as opposed to binding overrides. Specifically,
overridden
On Fri, Feb 8, 2013 at 3:05 AM, Torsten Schoenfeld wrote:
> Won't gobject-introspection silently turn the (transfer full) annotation
> into (transfer none) due to the special handling for GInitiallyUnonwed
> descendants?
>
It seems to pick it up correctly. The problem was actually the rename
anno
code base.
Thanks,
-Simon
On Thu, Feb 7, 2013 at 7:08 PM, Simon Feltman wrote:
> I've created a ticket and proposed patch for GTK+:
> https://bugzilla.gnome.org/show_bug.cgi?id=693393
>
> I am looking for feedback to see if this type of thing is even acceptable
> and if
ote:
> On 07.02.2013 01:12, Simon Feltman wrote:
>
>> Unfortunately there are a few more of these:
>> Gtk.Action.create_menu
>> Gtk.Action.create_menu_item
>> Gtk.Action.create_tool_item
>> Gtk.PrintOperation.create_**custom_widget
>&g
On Wed, Feb 6, 2013 at 12:57 PM, Owen Taylor wrote:
>
> > class ToolMenuAction(Gtk.Action):
> > def do_create_tool_item(self):
> >
> > return Gtk.MenuToolButton()
>
> This is basically broken API at the GTK+ level :-( ... a virtual
> function can't return (transfer none) unless it's a
Owen,
Thank you, this will definitely make things easier. Comments below:
* Floating references are C-convenience only
>
It might be a convenience for writing code, not necessarily reading or
understanding it. Something more reasonable would be explicitly
named convenience functions which steal
ndererText()
renderer.connect('editing-started', on_view_label_cell_editing_started)
-Simon
On Tue, Feb 5, 2013 at 5:09 AM, Simon Feltman wrote:
> This is basically how PyGObject works now. There are no problems with this
> during casual usage when Python is always in the posit
This is basically how PyGObject works now. There are no problems with this
during casual usage when Python is always in the position of the "caller".
The problem is this scheme does not work with the marshaling of floating
widgets passed into Python vfuncs/closures as arguments or intended as
retur
Feb 4, 2013 at 11:05 PM, Tristan Van Berkom wrote:
> On Tue, Feb 5, 2013 at 12:08 PM, Simon Feltman
> wrote:
> > I could easily be misunderstanding the internals, but at some point
> isn't a
> > call to something like gtk_widget_set_parent on the children needed for
>
bject ref counts during marshaling and floating sunk objects
based on if it was initially floating and the GObject ref count is only 1,
which might be unsafe.
-Simon
On Mon, Feb 4, 2013 at 4:56 AM, Torsten Schoenfeld wrote:
> On 04.02.2013 03:39, Simon Feltman wrote:
>
>> I am start
eded.
The alternatives to can become grossly convoluted:
https://bugzilla.gnome.org/show_bug.cgi?id=687522#c15
Thoughts?
-Simon
On Tue, Jan 29, 2013 at 3:44 AM, Simon Feltman wrote:
> I tend to agree we should be avoiding reliance on main loops (or GC
> timing) to get the ref counts r
I tend to agree we should be avoiding reliance on main loops (or GC timing)
to get the ref counts right if possible.
PyGObject also uses toggle refs similarly to gjs for keeping the wrappers
alive. However, in PyGObject this only happens if a Python instance
attribute is set. Whereas with gjs it s
Hi Everyone,
I'm trying to figure out a complete solution for proper reference
management of gobjects passed into python vfuncs and signal closures as
"in" arguments. Currently pygobject will add a ref to gobject arguments
marked as transfer-none during marshaling and additionally sink/ref
the gob
Toggle buttons and the switch widget both suffer usability problems for me.
The visual look of a button represents an action to be performed in my
mind, perhaps why it was referred to it as a soft-action? So when a button
is stateful it can create ambiguity depending on the text of the button.
The
It does not really matter how developer discussions take place as long as
they are documented and searchable. Transparency of reasoning
behind decisions is just as important as the decision for anyone trying to
understand the code base. For medium and large development, I advocate for
something lik
16 matches
Mail list logo
