Re: Touch selections

[Matthias Clasen]

Hey,

I've now taken a look at the code, here are some impressions:

GtkBubbleWindow looks interesting and somewhat similar to two things
that have been discussed:
a) a "PopupWindow" class to replace grabs (e.g. on wayland)
b) a "popover" widget that behaves like a transient overlay
(without being its own toplevel)
We should keep this private until we've worked out how it
overlaps/interacts with these usecases.

I'm not really convinced of some of the choices made in the
GtkSelectionWindow class:
   a) a toolbar may not be the right container for what the designers
had in mind - there was some talk of scrolling
   b) doesn't seem necessary to use a ui manager and actions here,
since you are not even allowing addition of actions
   c) adding a public getter for the toolbar will make it impossible
for us to change the implementation strategy later
   d) I'm not convinced the special-casing of cut/copy/paste is really
worth it - I would just have added these action in
GtkEntry/GtkTextView
I recommend dropping this widget altogether for now, and just
construct the toolbar with the default actions directly in
GtkEntry/GtkTextView.

In GtkEntry, I think the use of g_timeout_add_seconds for popping up
the selection is inappropriate - you don't want the delay to fluctuate
depending on whether you touch early or late in the second.

It would be nice if we could reuse the ::populate-popup signals to
allow custom actions to be added; unfortunately, all existing users of
this signal expect to add menuitems to a menu. One possibility might
be to add a set_context_menu_model() function that takes a GMenuModel,
which could be used to populate the traditional context menu, or to
build something toolbar-like for your popup. Of course menumodel and
toolbar is not a perfect fit, either.


Matthias
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Event controller/gestures branch

[Carlos Garnacho]

Hey,

I've just pushed a redone gestures branch, the code in there has been
first developed as a standalone mini-library on Sugar, and then carried
on and refined on personal experiments. 

The branch contains a basic GtkEventController abstract object that
mainly has a handle_event vfunc and a more specific GtkGesture object
that is made to handle 1..N pointer/touch sequences. On top of that
object there are 4 implementations for long press/swipe/zoom/rotate.

The way to currently operate with those is creating specific instances
and feeding events to those through gtk_event_controller_handle_event(),
and connect to the signals those emit. 

While it's tempting to add a gtk_widget_add_controller() call, there's
none yet. I think there should be a decision first about captured events
and whether they'll definitely stay private. There's a question about
how multiple gestures within the same widget or on the widget hierarchy
should interoperate to claim/yield entire event sequences. But for now,
just funneling GtkWidget::event to the controllers will make things work
for the basic cases, so this is already quite useful.

  Carlos

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Problems with un-owned objects passed to closures in pygobject (gtk_cell_renderer_text_start_editing)

[Giovanni Campagna]

2013/1/17 Simon Feltman :
> 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 gobject when
> the python object wrapper is created around it. The initial added ref during
> marshaling is then leaked upon the closure finishing in most cases.
>
> The fix could simply be to not add the initial ref during marshaling (or we
> need to make sure it is released when the closure finishes). The problem is
> this behavior is relied upon when a floating ref is passed and is the
> explicit fix described in the following ticket (which un-fortunately causes
> a leak in the non-floating case):
> https://bugzilla.gnome.org/show_bug.cgi?id=661359
>
> The specific problem described in bug 661359 occurs when a python closure is
> connected to a GtkCellRendererTexts "editing-started" signal. During the
> start of editing, a GtkEntry is created and passed almost immediately to
> signal emission before any ownership takes place:
> http://git.gnome.org/browse/gtk+/tree/gtk/gtkcellrenderer.c#n864
>
> This results in the following ref counting behavior of the GtkEntry as it is
> used by gtk_cell_area_activate_cell and gtk_cell_renderer_start_editing:
>
> 1 (floating) - gtk_cell_renderer_text_start_editing creates the GtkEntry
> 2 (floating) - g_signal_emit argument marshaling adds an additional ref
> during signal emission
> 3 (floating) - python closure marshaling adds an additional ref described
> above
> 3 (owned) - A PyGObject wraps the GtkEntry and sinks the floating ref
> * python callback is called and passed the wrapper
> 2 (owned) - The PyGObject wrapper is destroyed after the python callback
> finishes additionally freeing a gobject ref
> 1 (owned) - g_signal_emit argument marshaling completes and frees the ref it
> added
> 2 (owned) - gtk_cell_area_activate_cell sets the CellAreas edit widget which
> adds a ref
> 1 (owned) - cell editing finishes and removes the widget from the CellArea

I don't know the internals of pygobject, but to me it looks the leak
comes from not releasing the reference you add inside the callback
marshaller.
The way it works in gjs is:

1 (floating) - gtk_cell_renderer_text_start_editing creates the GtkEntry
2 (floating) - g_signal_emit argument marshaling adds an additional ref
during signal emission
2 (owned) - gjs closure marshaling creates a JS object wrapper,
calling ref_sink on the object
2 (owned, toggle, GC root) gjs adds a toggle reference and then
immediately unrefs the object
1 (owned, toggle, not rooted) - g_signal_emit argument marshaling
completes and frees the ref it added
2 (owned, toggle, GC root) - gtk_cell_area_activate_cell sets the
CellAreas edit widget which adds a ref
1 (owned, toggle, not rooted) - cell editing finishes and removes the
widget from the CellArea
... time passes ...
0 - GC triggers and the JS object finalizer removes the last ref

I know that Python doesn't have a GC in the traditional sense, but you
could still send finalization for GObject wrappers to a idle callback
so there is no risk of finalizing objects that C code assumes are
still alive.

Giovanni
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Problems with un-owned objects passed to closures in pygobject (gtk_cell_renderer_text_start_editing)

[Torsten Schoenfeld]

I cannot offer a solution, just a grumpy observation:

The problem occurring with this kind of ref sequence is due to
gobject-introspection's decision to always set transfer-ownership=none
for GInitiallyUnowned descendants and the resulting habit of language
bindings to always sink floating refs.  For previous discussion:
.

On 17.01.2013 01:42, Simon Feltman wrote:

The pygobject specific problems I mention could be solved by tracking
incoming floating refs and re-floating them upon closure exit if the
python ref is not stored anywhere (or by attempting to just keep it
floating).


The approach in parentheses is used by the Perl bindings:

• For constructors which return GInitiallyUnowned instances, we
internally force transfer-ownership=full.

• We generally only sink floating refs if transfer-ownership=full.

Thus, there is no need to add and remove an additional ref during 
closure marshalling and the GtkEntry in the example keeps its "floating" 
flag.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: glib 2.34 g_main_context_unref hangs

[Ken Bass]

On 01/17/2013 01:58 PM, Dan Winship wrote:

g_main_context_default() does not give you a ref on the default context,
so your code here is destroying an object internal to glib. If you call
this more than once (or, if you do *anything* involving the default
context after this point), I'd definitely expect it to fail.

Beyond that, it's hard to say what you might be doing wrong without
seeing more code.


Odd that it worked all these years, it is something I can easily change 
on my end--only un_ref'ing the context

on the 'non main' main loop.

However...

For some reason I was under the impression it gave me a reference, 
particularly because
when I look at that default context, its ref_count is 1, not 0. My clean 
up routine is the last thing executed before exit(), so
wouldn't this mean there is a memory leak? I guess it is not a big deal 
since it can only happen for the first main loop context so

there is only a single context left allocated before exit().
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: glib 2.34 g_main_context_unref hangs

[Dan Winship]

On 01/17/2013 12:17 PM, Ken Bass wrote:
> ch->main_context  = g_main_context_default ();

> g_main_context_unref(context);

g_main_context_default() does not give you a ref on the default context,
so your code here is destroying an object internal to glib. If you call
this more than once (or, if you do *anything* involving the default
context after this point), I'd definitely expect it to fail.

Beyond that, it's hard to say what you might be doing wrong without
seeing more code.

-- Dan

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

glib 2.34 g_main_context_unref hangs

[Ken Bass]

I'm trying to figure out if this is a glib bug or not. I just upgraded 
to 2.34 from 2.32 and my applications now hangs on exit. (This is 
existing code that has worked fine since 2.22)


I have a sig handler to intercept Ctrl-C which calls main_loop_quit() 
which appears to all work.



I create my main_loop as follows:

static GMainContext *default_main_context;

  if (!default_main_context)
  {
// For main thread
ch->main_context  = g_main_context_default ();
default_main_context = ch->main_context;
} else
{
// If running a thread, give it its own mainloop context.
ch->main_context  = g_main_context_new();
}

ch->main_loop = g_main_loop_new(ch->main_context, FALSE);

In my cleanup routine, called after main_loop exists, I have:

  main_loop = ch->main_loop;
  context = ch->main_context;

  if (main_loop)
  {
g_main_loop_unref(main_loop);
  }

  if (context)
  {
g_main_context_unref(context);
  }

Under 2.34.2, g_main_context_unref is hanging on the following line:

 g_source_destroy_internal (source, context, FALSE);
And in that function the hang is due to LOCK_CONTEXT(context)

Is this a 2.34 bug? I believe I have cleaned up everything and the 
g_main_context_unref(context) is pretty much the last glib thing done. 
Not sure

why it is hanging on anything.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkWidget::visible

[Tristan Van Berkom]

On Thu, Jan 17, 2013 at 11:59 AM, Tristan Van Berkom  wrote:
> On Wed, Jan 9, 2013 at 12:04 AM, Benjamin Otte  wrote:
>> Hey,
>>
>> Today, in my quest to make things clearer in the GTK core, I'm
>> tackling GtkWidget::visible.
>> The flag is documented as "Whether the widget is visible."[1] or a bit
>> better in the documentation for gtk_widget_show() as "Any widget that
>> isn't shown will not appear on the screen."[2]
>> However, this doesn't say anything about sizes, in particular sizes
>> requested from a widget. So far, GTK would not check the visibility
>> flag when calling size request functions ad would happily allocate a
>> size to a hidden widget. It also would happily expose the widgets to
>> the accessibility APIs. This has a bunch of problems:
>> - performance suffers
>> If we need to compute all these things for widgets we're not going to
>> use anyway doesn't make Stuff Go Faster.
>> - containers don't know what to do
>> Should they skip invisible widgets when allocating? Or still reserve
>> space for them?
>
> That's not exactly true. All containers know what to do with invisible
> children, all containers skip invisible children when requesting and
> allocating sizes. They even have the option of doing different things
> depending on the container type or the child properties of the given
> invisible widget.
>
> For instance, it can be useful in notebooks if the notebook reserves
> space for invisible children, this way the notebook size does not
> jump/change whenever one of the optional pages is shown/hidden
> (I can't seem to find it, but was sure there was a
> "request-space-even-if-invisible"
> child property in one of our containers).

I realize this wasn't the most constructive reply, I've been busy
and planned to reply to this when I initially received it, so wrote
a reply in a hurry.

What I think we're looking for here, is just an alternative way to iterate
over container children, i.e. a convenience API that would iterate
over only visible children.

I'm only a bit wary of removing the capacity to request the size of
an invisible widget, since that can also have it's uses.

With an alternative API, like gtk_container_foreach_visible(), or
gtk_container_list_visible_children(), we could eliminate all of those
statements which exist in GtkContainer size request/allocate
implementations which basically all already do:

if (!gtk_widget_get_visible (child))
   continue;

It might not be too much code reduction, but would probably make
things more readable (and easier to implement, it can be easy to
forget to skip the invisible widgets when implementing containers).

Cheers,
  -Tristan

>
>> - developers implementing widgets get confused
>> Can they optimize things away when their child is not visible? Like
>> can I skip the whole CSS machinery for hidden widgets in GTK?
>> - developer expect those widgets to not do anything
>> A11y people have lots of "fun" fixing bugs when Orca pokes into
>> widgets nobody expects to be pokable. Usually developers just hide()
>> widgets when they are supposed to be unresponsive and invisible and
>> then they don't update them anymore and expect no callbacks to happen
>> from them.
>>
>> So as a result, 2 things are going to be changed:
>> (1) gtk_widget_get_preferred_width/height() will return 0
>> With a recent commit[3], GTK will shortcut all
>> get_preferred_width/height() to return 0 for minimum and natural sizes
>> for all invisible widgets. Also, the allocation of the widget will be
>> immediately recent to an invalid state, so gtk_widget_get_allocation()
>> will return the initial { -1, -1, 1, 1 }.
>
> I don't think this is exactly right.
>
> There can be reasons to calculate the size of a widget regardless if it is
> mapped or visible.
>
> One example could be when creating a target surface for gtk_widget_draw().
>
> Cheers,
>-Tristan
>
>
>> (2) A11y code will ignore invisible widgets
>> We're working on a patch that will make sure no accessibles show up
>> for invisible widgets.[4]
>>
>> Why am I writing this? Because if you happen to run code that breaks
>> due to these commits or think this is a bad idea in general, you now
>> know that it's happening and still have a chance to stop us before we
>> release this as GTK 3.8.
>>
>> Benjamin
>>
>>
>> 1: http://developer.gnome.org/gtk3/stable/GtkWidget.html#GtkWidget--visible
>> 2: http://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-show
>> 3: 
>> http://git.gnome.org/browse/gtk+/commit/?id=b495ce5446a0bbf2ed63b5880537779e4b123515
>> 4: https://bugzilla.gnome.org/show_bug.cgi?id=577392
>> ___
>> gtk-devel-list mailing list
>> gtk-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list