GNOME Bugzilla – Bug 231166
do not start appointment time drop-down at midnight
Last modified: 2013-09-13 00:54:30 UTC
Currently if you book an appointment late in the day, it is a bit of pain to scroll down the long list of times - could the list be centered around the currently selected time. To reproduce:- 1. From the Calendar window, click on a time late in the day, say 4pm, to set an appointment. 2. The default start time is now 4pm, and the end time is 4:30pm. 3. Now change the end time to say 5pm by clicking on the drop down arrow to the right of the time. What actually happens:- The drop down appears and the currently selected time (4:30pm) is way down the list - probably off the bottom. What I would expect:- The currently selected time (4:30pm) to be in the middle - i.e. to have the pull-down already scrolled so that 4:30pm is in the middle. Thus making it easier to select 5pm.
still valid in evolution-2.0.2.0.200412060900-0.snap.ximian.10.1. this one really sucks. i'll target this to 2.3 since to me it's a great and not-to-hard improvement for the user...ximian guys: please contradict me. ;-)
changing target milestone from 2.3 to 2.1 according to duplicate bug 263870.
*** bug 263870 has been marked as a duplicate of this bug. ***
*** bug 266629 has been marked as a duplicate of this bug. ***
please also take a look at bug 266629, it's nearly the same with scheduling meetings.
Apologies for any spam... cc'ing usability-maint on all Evolution usability bugs. Filter on EVO-USABILITY-SPAM to ignore.
still valid in 2.3.7
still in 2.4.0, retargetting from 2.3 to 2.5.
With the "For" implementation in event-editor, this bug becomes obsolete.
The problem does not get solved by the new 'for' implementation. Please remember you might want to change the start time more often than the duration.
proposal: dropdown time menu should begin at the "day begins:" setting under "edit > preferences > calendar and tasks > general > work week".
This bug is still 'at large' in Evolution 2.10.1 I'd love it to be fixed! Andre Klapper's suggestion looks excellent ("proposal: dropdown time menu should begin at the "day begins:" setting under "edit > preferences > calendar and tasks > general > work week".")
Created attachment 95780 [details] [review] proposed evo patch for evolution; It is not used everywhere, but I think that's no problem. There are only couple things I need to mention: someone could suppose that the hours after midnight are for next day, but they aren't. (there is 9...23:30, 0:00, .... 8:30). Also, it uses only starting hour, not a minute, from preferences.
Milan, Im not very clear on your patch. What does it do really?
It does the behavior as described in comment #11 and approved in comment #12, it fills the combo with time always starting at 'start time' and rounds to the end time, even the end time can be smaller than start time, in that case, it moves through midnight. My example above is for "day begins: 9:xx" and the interval is set to "9, 9", so it creates items in combo like "9:00, 9:30, ... 23:30, 0:00, ... 8:30". In other words, it only changes starting time in the combo, nothing else.
for "day begins: 9:xx" i would actually prefer if the *focus* in the dropdown list is set to 9:00 and the item list still starts at 0:00. it seems unlogical to me that if i want to change the start time from 9:00 to 8:30, i don't have to choose one item up, but 47 items down.
You've right, it's strange, but with GtkComboBoxEntry it looks very weired, nothing nice around, so I think it's not that what we want. (I like classic combo with scrollbar to move quickly with a list, not those arrow on top and bottom with slow movement). Even it is deprecated component. I saw that it is selected in old GtkCombo, but not scrolled in a proper place. So it's the opportunity to move with the scrollbar there, but god knows how :) or maybe other developer...
Precisely, I remember I worked on this bug year or two back and found that it is a broken gtk+ bug. Unfortunately we are using a deprecated widget.
Created attachment 97833 [details] [review] proposed evo patch ][ for evolution; Migrate from gtk_combo to gtk_com_box_entry for time_combo. Also added selecting item from list on change, if possible, so you can type your time and if it is in a list, then you've got right item selected, when popup.
Awesome. I think it doesn't break anything. Commit to head/stable
Committed to trunk. Committed revision 34505. Committed to stable. Committed revision 34506.
We need to either revert this or find a different solution for stable. The patch uses gtk_cell_layout_get_cells(), which is a new function in GTK+ 2.12. The stable branch is limited to GTK+ 2.10. It's fine for trunk, but we can't go bumping our GTK+ requirement in a stable update. Increasing priority and severity, and reopening.
please revert the commit to stable then, i'd say.
I agree. Unfortunately I don't see any other way to get to a GtkComboBoxEntry's text renderer but through gtk_cell_layout_get_cells(). Bit of a shortcoming in the GTK+ API if you ask me.
The stable branch compiles fine for me with the patch reverted. I don't *think* there's any side-effects to reverting the patch but Milan would know better. I'll leave it to Srini and Andre to decide if this warrants a 2.12.2.1 release. I haven't committed anything yet.
hmm. i'd say: wait for complaints, and revert for 2.12.3 (personal opinion, not release-team view.) i don't think there's a distro shipping evo 2.12 as part of gnome 2.20 without shipping gtk 2.12 (many parts of gnome 2.20 depend on gtk 2.12).
oops, should have been an "and **if required**, revert for 2.12.3", so only if there are complaints
> oops, should have been an "and **if required**, revert for 2.12.3", so only if > there are complaints If we leave it in place then we need to bump the GTK+ requirement in configure.in, and that's mostly where my concern lies. I doubt I would have noticed the problem had I not been backporting 2.12.2 to a GNOME 2.16 platform (for RHEL).
I think, we should revert it from stable for consistency purposes. I don't think bumping the Gtk+ version is right at this late stage. Milan, just revert it for stable alone.
OK, reverted in stable. Committed revision 34593.