After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 128105 - calendar signal "day-selected" sometimes emitted multiple times
calendar signal "day-selected" sometimes emitted multiple times
Status: RESOLVED DUPLICATE of bug 106161
Product: gtk+
Classification: Platform
Component: Widget: Other
2.3.x
Other Linux
: Normal enhancement
: ---
Assigned To: gtk-bugs
Python bindings maintainers
Depends on:
Blocks:
 
 
Reported: 2003-11-28 11:34 UTC by crouch
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement



Description crouch 2003-11-28 11:34:07 UTC
I'm using the Caledar widget. When it displays, the current date is
selected, which is when I want. I've connected the "day-selected"
signal, so when I click on a date I can arrange for something to happen.
So far, so good. 

The problem is when I click on the prev and next month (or year)
buttons, this signal is also activated and I can't work out how to tell
that a day hasn't been clicked.

Worse, when I click on a greyed out date, the signal is activated twice
- once for the date that was originally selected and once for the greyed
out date, which has been now been selected and the calendar view
adjusted appropriately.

There is currently no way I can distinguish between these different events.
NB I think this is behaving as documented, hence this is a request for
enhancement.

Would it be possible to either:

generate a different (or additional) signal when a number is single-clicked. Or

give an additional parameter to the callback indicating what had caused it
(i.e. if it was from a user click or not)
Comment 1 Christian Reis (not reading bugmail) 2003-11-28 20:30:09 UTC
Question: can you in the callback check if the day is selected in the
calendar, i.e., by using get_date() or something similar? That would
be a way of obtaining this information out-of-band (perhaps using
connect_after). 

At any rate I think this is a GTK+ bug, since it relates to a GTK+
widget signal -- we don't invent signals in PyGTK, we just wrap 'em!

(Note also that there is a PyGTK product now -- this bug was misfiled
in gnome-python, but it seems I don't have editbugs so I can't fix it!)
Comment 2 James Henstridge 2003-12-01 02:05:34 UTC
PyGTK doesn't do anything special for the GtkCalendar widget.  If this
is the behaviour you see in Python, then you would also see it in C
programs.

If this is a problem, then it should be fixed at the GTK level.
Comment 3 James Henstridge 2003-12-01 02:47:26 UTC
Out of interest, why do you want to distinguish between the user
clicking on a day, and changing month/year?

When I switch month or year, a new day is selected (eg. if I go to the
next month, the selected day changes from 1st December to 1st
January), so it seems sensible that day_selected would get emitted.
Comment 4 crouch 2003-12-01 10:23:40 UTC
Unfortunately get_date tells what was selected not what was clicked.
If I click on the next month arrow, then the same day of the next
month is returned. If I click on a grey date, then the current date
and then the grey date are returned. I get the same behaviour with
connect and connect_after.

I want to pop up a dialog when the user actively selects a date (i.e.
clicks on a number). I agree that the selection changes, so the signal
should be emitted, but I'd like more information so I can distinguish
between the calendar displaying a new month and a date being selected. 
Comment 5 James Henstridge 2003-12-22 16:23:17 UTC
This sounds like a GTK feature request, rather than a PyGTK feature
request.  Reassigning to GTK+
Comment 6 Matthias Clasen 2003-12-23 01:42:47 UTC

*** This bug has been marked as a duplicate of 106161 ***