GNOME Bugzilla – Bug 427221
GtkCalendar GDate set/get and today
Last modified: 2014-05-23 10:48:56 UTC
In the last bugzilla entry I mentioned some enhancement stuff that could be nice for GtkCalendar. To summarize: - GDate get and set methods -- Get a pointer to the widgets basic types in order to compare between dates etc. - Today function -- Something to set the calendar to 'today' using the caledar GUI. (And have something around the current day.) - Mulitcolour marking -- Ability using data abstraction to set the calendars marks to specific colours. I want to post this as feature request, but I do my best to get a patch here too.
Related to bug 59048. We need to know how get/set functions will affect the GtkCalendar->month attribute. What do the functions should look like ? gboolean gtk_calendar_set_dmy(GtkCalendar *calendar, GDateDay day, GDateMonth month, GDateYear year); or gboolean gtk_calendar_set_dmy(GtkCalendar *calendar, GDate *dmy);
The last one: gboolean gtk_calendar_set_dmy(GtkCalendar *calendar, GDate *dmy); or gboolean gtk_calendar_set_date(GtkCalendar *calendar, GDate *dmy); GDate * gtk_calendar_get_date(GtkCalendar *calendar);
The (g|s)et_dmy naming scheme would be good for the current calendar. The (g|s)et_date naming scheme would be better for a GNOME 3.0 calendar widget. More about this here: http://bugzilla.gnome.org/show_bug.cgi?id=59048#c21
I disagree, this should be a start to get the calendar widget working as it should have been in the first place. So slowly phase out the dmy... and get date working. It isn't a bad thing to have multiple interfaces doing the same set operation.
Having multiple interfaces is not a bad thing, sure. But when functions of the same object to get the same data return different things, the API just becomes unefficient and error-prone. http://developer.gnome.org/doc/API/2.0/glib/glib-Date-and-Time-Functions.html#GDateMonth http://developer.gnome.org/doc/API/2.0/gtk/GtkCalendar.html#GtkCalendar--month We surely will have cases where people will get the value with one set of function, store it, and set it with another set of functions. And keeping the same name for the functions, just changing input argument's type is even more confusing. That's why I prefer a name change, and use *_dmy functions. I think we can't add this API without deprecating the old gtk_calendar_(g|s)et_date. Having different functions that do the same thing, but one that uses 0-based values and the other that uses 1-based values is just bad conception.
Ok Stefan, it seems Emmanuele is ok in bug 59048 for the GDate-based API, and the latest patch uses it, so this point is closed. As the bug title is now irrelevant, it may be better to close this bug and open a new feature request with the remaining points.
closing out old bugs