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 335400 - "until" time entry in new appointment dialog is unusable
"until" time entry in new appointment dialog is unusable
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Calendar
2.6.x (obsolete)
Other All
: Normal normal
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
: 336903 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-03-21 18:54 UTC by Christopher Lee
Modified: 2013-09-10 14:04 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
Patch (487 bytes, patch)
2006-05-30 12:18 UTC, Johnny Jacob
committed Details | Review

Description Christopher Lee 2006-03-21 18:54:56 UTC
Please describe the problem:
The "until" time entry in the new appointment dialog does not work.  It updates
the time at each keystroke.  On the first keystroke, it updates/overrides the
(starting) time entry with an incorrect time value.

Steps to reproduce:
1. Create a new appointment
2. Enter a staring time, such as 12 pm
3. Select "until" instead of "for"
4. Select the "until" time, and press 1 (to start to enter 1pm, for example)


Actual results:
The staring time is immediately updated to 12 am (because the keystroke of 1 is
immedately interpreted as a 1am end time, which invalidates the 12pm start time).

Expected results:
You should be able to enter 1pm, and then either press enter or navigate out of
the entry, at which time the "start" value would be updated, if necessary.

Does this happen every time?
Every time -- this makes using the "until" time entry completely unusable

Other information:
The temporary work around is to always use "for" for the end time entry.  This
is, however awkward for things like entering the arrival time of an airline flight.
Comment 1 André Klapper 2006-03-21 23:37:23 UTC
same here, was just too lazy to file this. confirming, currently it's just overaggressive and very hard for people not using a mouse.

adding srini to cc, this makes entering the date by keyboard nearly impossible for me.
Comment 2 Srinivasa Ragavan 2006-03-22 04:07:15 UTC
andre, I guess, the fix for validation/sensitivity of save on typing introduced this bug. But a nice one :-)
Comment 3 Karsten Bräckelmann 2006-03-25 01:22:35 UTC
Adding keyword, setting proper Severity. Being forced to use the mouse sure is not a minor issue...
Comment 4 André Klapper 2006-05-04 12:55:59 UTC
to me this is a 2.7 issue and a regression.
Comment 5 Srinivasa Ragavan 2006-05-30 04:07:43 UTC
johnny: ping?
Comment 6 Johnny Jacob 2006-05-30 12:18:13 UTC
Created attachment 66468 [details] [review]
Patch
Comment 7 André Klapper 2006-05-31 19:56:36 UTC
targetting to 2.6, before i get mad because of this...

please review someone. thanks.
Comment 8 Harish Krishnaswamy 2006-06-02 06:00:14 UTC
Approved for commit to both branches.
Comment 9 Johnny Jacob 2006-06-02 10:11:10 UTC
Can u plz commit the patch as i don't have commit rights. 
Comment 10 Michael Van Dorpe 2006-06-02 18:15:56 UTC
It's always nice to check whether a bug has been filed already and then see it's already solved :-) This bug was especially bad because I had not discovered the workaround of using a mouse.

Does this patch solve bug 336903 as well? That's a similar problem I think.
Comment 11 Srinivasa Ragavan 2006-06-02 18:26:06 UTC
I strongly feel so.
Comment 12 André Klapper 2006-06-09 00:46:30 UTC
patch committed both to stable branch and HEAD:
http://cvs.gnome.org/viewcvs/evolution/widgets/misc/e-dateedit.c?r1=1.54&r2=1.55
http://cvs.gnome.org/viewcvs/evolution/widgets/misc/e-dateedit.c?r1=1.54&r2=1.54.2.1

fix will be included in stable evolution 2.6.3 and unstable evolution 2.7.3.
Comment 13 André Klapper 2006-06-09 00:47:47 UTC
*** Bug 336903 has been marked as a duplicate of this bug. ***