GNOME Bugzilla – Bug 106161
GtkCalendar: confusing signals when month changes
Last modified: 2018-05-02 13:47:26 UTC
At present, clicking on the "next month" or "prev month" arrows in GtkCalendar will cause it to emit a day_selected signal. This is a nuisance because there is no way to distinguish these signals from those generated when the user explicitly clicks on a day. Maybe a new signal ("day_selected_single_click"?) could be added that is only generated by actual clicks from the user.
* What's the use case? GtkCalender in a popup? GnomeDateEdit seems to require a double click, which is indeed perhaps a little confusing. * What do you want it to do when the user clicks on a day in a different month and it changes to that month and selects the day the user clicks on? * Also, keynav needs consideration here ... any operation possible from the mouse should be possible from the keyboard. * It's worth considering whether an API like: gtk_calender_get_month_in_month_change() is better than a separate signal.
*** Bug 128105 has been marked as a duplicate of this bug. ***
2003? ouch. :) I'm not sure on the development direction happening with GtkCalendar. I've been reading through the bug reports and it seems a rework is in the pipelines? Anyway, I have noticed the issue still currently stands in the SVN branch. This one is an annoyance to me working with wx's wrapper. A simple temporary fix for this issue would be a gboolean flag in the calendar_set_month_prev and calendar_set_month_last functions eg. calendar_set_month_prev(GtkCalendar *calendar,gboolean block_day_signal=false) { ... if (!block_day_signal) { emit... }; } and in the calendar_main_button_press function, set the calls to calender..._prev and _next to calendar_set_month_xxxx(calendar,true); Unless of course GtkCalendar on the way out next cycle. Can anyone clear up for me what's planned with it?
Whoops.. Sorry.. Can't half guess I'm a c++ programmer.. :) the lazy block_day_signal=false thing won't work. Also made a typo.. by calendar_set_month_last I meant next. But I hope you get the gist of what I meant.
Created attachment 188110 [details] [review] Patch to block excess (and wrongly dated) DAY_SELECTED signal in gtkcalendar Note: Renames calendar_set_month_xxxx (prev & next) to real_calendar_set_month_xxxx, and uses a #define to get the orignal name back in place of a default argument initializer. Changes the calls in calendar_main_button_press and gtk_calendar_key_press to block the signals where this problem occurs. changes them to real_calendar_set_month_xxxx(...,TRUE) This wasn't the neatest idea, some alternatives to this that I just came up with now: 1. changing all the calls to include the gboolean, 2. replicating the two prev/next functions, 3. removing the call to gtk_calendar_select_day from the prev/next functions, and adding it back directly after the calls to calendar_set_month_xxxx wherever the months are changed by means than clicking the surrounding areas. 4. Waiting for a gtkcalendar rewrite. Option 3 is probably the cleanest. Option 4 is obviously the best.. but if no-one is quite ready to do that yet, is there much point leaving this one hanging when it's a simple fix?
Created attachment 188205 [details] [review] Fixes redundant day_selected signals in gtkCalendar I've tested this same fix concept on ubuntu (gtk2.0), it works well, so I ported what I did there to the svn version of GtkCalendar. It also solves a couple of related assert glitches too. Note: I have not been able to build this yet for svn, as I don't have new enough glib dev libraries on this box yet.
Review of attachment 188205 [details] [review]: No comment on the sense, but this is unusable due to paying almost no attention to the coding style. Please read docs/CODING-STYLE, or at least notice the conventions used in the surrounding code.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/225.