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.
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 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.
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.
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.
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
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
It may be unusual, but handlers of day-selected may want to transfer
focus somewhere else, without getting it reset back right after by/to
the calendar. This makes popovers demo work on the calendar again, for
one...
When trying to drag, we currently the position of the first motion
event to determine where the drag came from. This might be alright
in the case of the old animation, but the data will be inaccurate
if the user has moved the pointer quite a bit since pressing the
cursor to start dragging. While we could monkey patch the GdkEvent
at the widget layer, this is unintuitive and strange.
Add a new API that takes a set of pointer coordinates describing
the origin of the drag. Additionally, adapt most widgets to use
it and use it with correct coordinates.
https://bugzilla.gnome.org/show_bug.cgi?id=705605
This replaces the previously hardcoded calls to gdk_window_set_user_data,
and also lets us track which windows are a part of a widget. Old code
should continue working as is, but new features that require the
windows may not work perfectly.
We need this for the transparent widget support to work, as we need
to specially mark the windows of child widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=687842
This allows drawing calendar arrows in all possible states the main widget may
be in.
The arrow_state array is converted into a bit field since it only really needs
to store boolean information about prelight for each arrow.
This commit introduces a new setting, gtk-visible-focus, backed
by the Gtk/VisibleFocus X setting. Its three values control how
focus rectangles are displayed.
'always' is equivalent to the traditional GTK+ behaviour of always
rendering focus rectangles.
'never' does what it says, and is intended for keyboardless
situations, e.g. tablets.
'automatic' hides focus rectangles initially, until the user
interacts with the keyboard, at which point focus rectangles
become visible.
https://bugzilla.gnome.org/show_bug.cgi?id=649567
After the window removal a while ago, the calendar main window
was not properly moved in size_allocate. Also, we ought to hide/show
the windows in map/unmap, not keep them visible at all times.
Bug 634657
The keysyms create a lot of potential namespace conflicts for
C, and are especially problematic for introspection, where we take
constants into the namespace, so GDK_Display conflicts with GdkDisplay.
For C application compatiblity, add gdkkeysyms-compat.h which uses
the old names.
Just one user in GTK+ continues to use gdkkeysyms-compat.h, which is
the gtkimcontextsimple.c, since porting that requires porting more
custom Perl code.
This commit was created using a script that searched for all docstrings
containing a parameter and the string 'or %NULL'.
Gdk backends and demos excluded as they are not part of a public API
https://bugzilla.gnome.org/show_bug.cgi?id=610474
* gtk/gtkcalendar.c (gtk_calendar_class_init()): Limit the "year"
property to G_MAXINT >> 9, instead of G_MAXINT >> 8: year_to_days()
multiplies the year property with 365 and returns the result as
glong. Therefore ceil(log(365, 2)) = 9 bits must be available,
not just 8 bits.
svn path=/trunk/; revision=21150
2008-08-12 Michael Natterer <mitch@imendio.com>
* gtk/*.c: consistently chain up using
GTK_FOO_CLASS(parent_class)->bar(instance) instead of
(*GTK_FOO_CLASS(parent_class))->bar(instance).
svn path=/trunk/; revision=21085
2008-07-06 Matthias Clasen <mclasen@redhat.com>
Bug 539248 – gtk_calender_query_tooltip calls ->detail_func with
invalid dates
* gtk/gtkcalendar.c (gtk_calendar_query_tooltip):
Check that the cursor is over a valid date before retrieving
its details. Patch by Chris Wilson
svn path=/trunk/; revision=20789
2008-06-30 Cody Russell <bratsche@gnome.org>
* Practically everything changed.
Change all references of GIMP Toolkit (and variations of it)
to GTK+ Toolkit, showing no mercy at all to our beloved
ancestry. (#540529)
svn path=/trunk/; revision=20709
2008-06-18 Michael Natterer <mitch@imendio.com>
* gtk/gtkcalendar.c: set the maximum of the "year" property to
G_MAXINT >> 8 instead of G_MAXINT to fix overflows in internal
calculations which in turn caused writing beyond the boundaries of
the calendar->day_month[] and day[] arrays which in turn caused a
SEGV. This limits the lifetime of GTK+ to the year 8,388,608 ;)
svn path=/trunk/; revision=20452
2008-02-15 Matthias Clasen <mclasen@redhat.com>
* configure.in: Go back to 2.13.0 as version for now,
as there was no consensus to do the jump.
* many other places: Update Since: tags.
svn path=/trunk/; revision=19586
* configure.in: Require 1.19.3 for pango_layout_set_height().
* gtk/gtkcalendar.c: Use pango_layout_set_height() for details.
svn path=/trunk/; revision=19392
* gtk/gtkcalendar.c: Release the memory returned by the detail_func.
* gtk/gtkcalendar.h: Remove G_CONST_RETURN from GtkCalendarDetailFunc.
* tests/testcalendar.c: Duplicate calendar details before returning.
svn path=/trunk/; revision=19382
* gtk/gtkcalendar.c, gtk/gtkcalendar.h: Add "show-details" property
aka. GTK_CALENDAR_SHOW_DETAILS, and use it.
* tests/testcalendar.c: Test GTK_CALENDAR_SHOW_DETAILS. Reduce padding
in flags vbox.
svn path=/trunk/; revision=19267
* gtk/gtkcalendar.c: Add gtk_calendar_query_tooltip and chain it up.
Remember detail overflows in calendar_paint_day to show the tooltip
only when neccessary.
svn path=/trunk/; revision=19263
properties not only the widget has to be redrawn on certain
conditions, but also its size must be recalculated. (#339540)
* gtk/gtkcalendar.c: Add calendar_queue_refresh and call
that function instead of gtk_widget_queue_draw.
svn path=/trunk/; revision=19262
* gtk/gtkcalendar.c: Add gtk_calendar_get_detail and
is_color_attribute functions. Change gtk_calendar_size_request
and calendar_paint_day to consider and show calender details.
svn path=/trunk/; revision=19261
* gtk/gtkcalendar.c: Change week and year variable in
calendar_paint_week_numbers from gint to guint. Remove obsolete "#if
0" block from calendar_paint_day: The feature in question is handled
few lines above. Cast data returned by gtk_selection_data_get_text()
to (gchar*) in gtk_calendar_drag_data_received.
svn path=/trunk/; revision=19201
2007-11-26 Matthias Clasen <mclasen@redhat.com>
* gtk/gtkcalendar.c: Fix a theming problem with colors
in GtkCalendar. (#499703, Michael Hofmann)
svn path=/trunk/; revision=19055
2007-01-18 Matthias Clasen <mclasen@redhat.com>
* gtk/gtkcalendar.c: Fix problems with the initial
focus in GtkCalendar. (#397783, Vincent Untz)
svn path=/trunk/; revision=17190
2006-12-14 Carlos Garnacho <carlosg@gnome.org>
* gtk/gtkcalendar.c: draw arrows pointing to the right correctly
placed inside their GdkWindow. Bug #385672.
2006-10-11 Tor Lillqvist <tml@novell.com>
Merge from 2.10 branch:
* gtk/gtkmain.c (do_pre_parse_initialization): On Win32, if
environment variable LC_ALL or LANG is set, set the Win32 thread
locale to the corresponding locale. Then call the C library
setlocale() to set the C library locale accordingly. The
inconsistency mentioned below is gone. (#339756) Do some special
casing for Serbia and Montenegro. Handle the Latin and Cyrillic
scripts for Azeri, Uzbek and Serbian.
(enum_locale_proc): Helper function for the above functionality.
* gtk/gtkcalendar.c (gtk_calendar_init): No longer need to check
if the environment variables are set here, as they have already
been taken into account and the Win32 thread locale has been
set.
2006-10-07 Tor Lillqvist <tml@novell.com>
* gtk/gtkcalendar.c (gtk_calendar_init): Use the Win32 thread
locale's first day of week setting on Win32. (#339752, Bogdan
Nicula) Don't do this if one of the environment variables that
affect gettext is set, though. In that case use the week start day
from the corresponding message catalog.
Unfortunately the same logic isn't possible in the weekday and
month name lookup; there even if you have set one of the
aforementioned environment variables, you still get the weekday
and month names from the Win32 thread locale. Yes, this is
inconsistent.
Use only wide-character API in the Win32 code in this file, too.
2006-09-10 Matthias Clasen <mclasen@redhat.com>
* Commit a patch by Behdad to fix typos, omissions and other
errors in the symbol aliasing, and add checks for local PLT
entries. (#354687, Behdad Esfahbod)
2006-08-06 Matthias Clasen <mclasen@redhat.com>
* gtk/gtkcalendar.c (calendar_start_spinning, calendar_timer):
Use G_PRIORITY_DEFAULT_IDLE for the month/year-change timer,
so that the caller will have a chance to redraw/resize itself
between every change. (#348824, Federico Mena Quintero, patch
by Michael Meeks)
2006-07-17 Michael Natterer <mitch@imendio.com>
* gtk/gtkcalendar.c (calendar_timer): use 5 * gtk-timeout-repeat,
just as many other widgets. Makes the calendar arrow buttons
usable for quick month/year skipping (#142582).
