- Rename GtkLegacyLayout to GtkCustomLayout
- Use for() to iterate over children in GtkBinLayout
- Whitespace fixes for code imported from GtkBox
- Store the GtkLayoutChild instances inside LayoutManager
- Simplify the GtkLayoutManager API by dropping unnecessary arguments
- Fix the ownership model of GtkLayoutManager
If a widget has a LayoutManager instance, then we want to parse layout
properties in UI description files; the grammar is similar to packing
properties in GtkContainer:
<child>
<object ...>
<property name="...">...</property>
<layout>
<property name="pname">value</property>
</layout>
</object>
</child>
The properties are applied after a child has been added to its parent,
to the parent's layout manager property should be set.
GtkLegacyLayout is a layout manager for the transitional period between
the introduction of layout managers and the removal of GtkWidget virtual
functions for the size negotiation.
Layout managers needs a way to store properties that control the layout
policy of a widget; typically, we used to store these in GtkContainer's
child properties, but since GtkLayoutManager is decoupled from the
actual container widget, we need a separate storage. Additionally, child
properties have their own downsides, like requiring a separate, global
GParamSpecPool storage, and additional lookup API.
GtkLayoutChild is a simple GObject class, which means you can introspect
and document it as you would any other type.
We can use a constructor property for existing container widgets with
a layout policy, and move the layout policy implementation out of the
widget itself and into a LayoutManager subclass.
We delegate the size request mode, the measuring, and the allocation of
a widget through a GtkLayoutManager instance, if one has been attached
to the widget; otherwise, we fall back to the widget's own implementation.
A base abstract class for layout manager delegate objects.
Layout managers are associated to a single widget, like event
controllers, and are responsible for measuring and allocating the
children of the widget they are bound to.
Otherwise we're getting warnings about allocating a widget we haven't
measured first, which is fair. The contents gizmo itself will later take
care about whether or not the real popover child is NULL.
We were not paying enough attention to detail when updating
hover and focus state while generating crossing events. The
invariant that we need to preserve here is that when a widget
has focus or hover, its parent does too.
We basically don't have child surfaces anymore (the last
use in popovers is on the way out). This really needs
to be done in terms of widgets, not surfaces. For now,
just stop walking parent surfaces.
ImmIsIME() doesn't work (always returns TRUE) since Vista.
Use ITfActiveLanguageProfileNotifySink to detect TSF changes,
which are equal to IME changes for us.
Also make sure that IMMultiContext re-loads the IM when keyboard layout
changes, otherwise there's a subtle bug that could happen:
* Run GTK application with non-IME layout (US, for example)
* Focus on an editable widget (GtkEntry, for example)
* IM Context is initialized to use the simple IM
* Switch to an IME layout (such as Korean)
* Start typing
* Since IME module is not loaded yet, keypresses are handled
by a default MS IME handler
* Once IME commits a character, GDK will get a WM_KEYDOWN,
which will trigger a GdkKeyEvent, which will be handled by
an event filter in IM Context, which will finally re-evaluate
its status and load IME, and only after that GTK will get
to handle IME by itself - but by that point input would
already be broken.
To avoid this we can emit a dummy event (with Void keyval),
which will cause IM Context to load the appropriate module
immediately.
When the window gets active / inactive, we
don't propagate events, but just send focus-in / -out
to the current focus_widget. Improve this by updating
its state flags as well.
We were walking the parent chain here, which now
always needs to consider whether it should stop
at roots. Like this one should.
The symptom was that a label with a popup attached to
it would end up with an unintentional focus ring that
would not go away.
