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.
