| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Use the generic ::event signal.
|
|
|
|
|
| |
You don't start a dnd operation with a device, you start it with an
event.
|
|
|
|
| |
It was unused.
|
|
|
|
| |
Replace the motion_notify handler by a drag gesture.
|
|
|
|
| |
At least wait until we've received the previous one.
|
|
|
|
|
|
|
| |
The argument is ignored by anything but X11.
It's treated like suggested_action == MOVE.
So do that in gtk_drag_finish(), too.
|
|
|
|
|
|
| |
This is in preparation of using input streams to show that these
coordinates aren't needed most of the time and can otherwise be saved
during GtkWidget::drag-drop.
|
| |
|
|
|
|
| |
It's now called GdkContentsFormat
|
|
|
|
| |
This avoids more strdups at startup.
|
|
|
|
| |
This avoids a bunch of strdups at startup.
|
|
|
|
|
|
|
|
|
| |
Instead of allowing people to pass a uint user-data, insist on them
comparing mime types.
The user data was a uint instead of a pointer anyway, so uniqueness
could not be guaranteed and it caused more issues than it was worth.
And that's ignoring the fact that it basically wasn't used.
|
| |
|
|
|
|
|
| |
This gets rid of GtkTargetEntry in the API and consistently uses
GtkTargetList.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch makes that work using 1 of 2 options:
1. Add all missing enums to the switch statement
or
2. Cast the switch argument to a uint to avoid having to do that (mostly
for GdkEventType).
I even found a bug while doing that: clearing a GtkImage with a surface
did not notify thae surface property.
The reason for enabling this flag even though it is tedious at times is
that it is very useful when adding values to an enum, because it makes
GTK immediately warn about all the switch statements where this enum is
relevant.
And I expect changes to enums to be frequent during the GTK4 development
cycle.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
CID 1432024 (#1 of 1): Uninitialized scalar variable (UNINIT)
2. uninit_use_in_call: Using uninitialized value rect.x when calling
calendar_arrow_rectangle.
Add a default case to the switch which will bail out with
g_assert_not_reached(), which should reassure Coverity that the method
is always called with a valid value that is handled in the switch.
|
|
|
|
|
|
|
|
|
|
|
| |
Since setting a clip is mandatory for almost all widgets, we can as well
change the size-allocate signature to include a out_clip parameter, just
like GtkCssGadget did. And since we now always propagate baselines, we
might as well pass that one on to size-allocate.
This way we can also make sure to transform the clip returned from
size-allocate to parent-coordinates, i.e. the same coordinate space
priv->allocation is in.
|
|
|
|
| |
and simultaneously fix input! \o/
|
|
|
|
|
| |
Hardcode the default values until someone comes and fixes the actual
widget.
|
| |
|
|
|
|
| |
gtk_widget_size_allocate_with_baselines does it automatically now.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We now rely on toplevels receiving and forwarding all the events
the windowing should be able to handle. Event masks are no longer a
way to determine whether an event is deliverable ot a widget.
Events will always be delivered in the three captured/target/bubbled
phases, widgets can now just attach GtkEventControllers and let those
handle the events.
|
| |
|
|
|
|
| |
It's now called gtk_snapshot_offset().
|
|
|
|
|
|
| |
Instead of having gtk_snapshot_append_foo_node(), just have
gtk_snapshot_append_foo(). Nobody needs to know that this internally
uses nodes.
|
| |
|
|
|
|
| |
The answer is: Yes.
|
|
|
|
|
|
|
|
| |
Add a new ::measure vfunc similar to GtkCssGadget's that widget
implementations have to override instead of the old get_preferred_width,
get_preferred_height, get_preferred_width_for_height,
get_preferred_height_for_width and
get_preferred_height_and_baseline_for_width.
|
| |
|
|
|
|
| |
The argument must always be the current state.
|
|
|
|
|
| |
glib will use the correct marshaller automatically. And as a side
effect, we also get all glib optimizations, like a va marshaller.
|
|
|
|
|
|
| |
This follows what was done for GtkDragSource in
415030d25f2552d3937ee3c394c50d22c5382982 and shaves another
500 lines off gtkdnd.c.
|
|
|
|
| |
http://www.viva64.com/en/b/0383/
|
|
|
|
| |
Don't propagate :drop(active) to components.
|
|
|
|
| |
g_logv adds one for us already.
|
| |
|
|
|
|
| |
This will allow us to drop hardcoded type names in the theme.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These days exposure happens only on the native windows (generally the
toplevel window) and is propagated down recursively. The expose event
is only useful for backwards compat, and in fact, for double buffered
widgets we totally ignore the event (and non-double buffering breaks
on wayland).
So, by not setting the mask we avoid emitting these events and then
later ignoring them.
We still keep it on eventbox, fixed and layout as these are used
in weird ways that want backwards compat.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GtkCalendar can have an invalid date — mostly at initialization. This
means that GDateTime construction may fail. We need to handle that case
gracefully, like the old code did.
This fixes the `notify` test suite, which started failing with:
/Notification/GtkCalendar:
GLib-CRITICAL **: g_date_time_get_day_of_week: assertion 'datetime != NULL' failed
inside the Continuous builder.
|
|
|
|
|
|
|
|
|
| |
If the first of the month was falling on a Sunday, we would not
render any days of the previous month, and instead show two weeks
of the next month at the bottom. Improve this by showing one week
of each.
https://bugzilla.gnome.org/show_bug.cgi?id=301835
|
|
|
|
|
| |
Instead of old copy-paste code, use GDateTime to determine week
numbers and days of week.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When allocated more than the requested height, GtkCalendar
was 'falling apart'. Not only was the main part rendered
at the far end of the allocation, clicking on days was
broken in this scenario.
Fix this by always placing the main part directly under
the header and day names.
https://bugzilla.gnome.org/show_bug.cgi?id=737670
|
| |
|