GNOME Bugzilla – Bug 639043
Alarm notify snooze time not properly adjustable
Last modified: 2011-02-21 06:59:15 UTC
Created attachment 177862 [details] [review] Arbitrary alarm snooze time patch The maximum notify snooze time is restricted to (absolutely arbitrary) 12 hours and 59 min. However, for good reasons the alarm time can be set to an arbitrary time before the appointment. If you want a notification say 7 days before the event (something needs to be done well in advance) and again want to be notified on the day of the event, you - again and again - will have to snooze for c. 12 hours (14! times in this example). This is why I call it a bug and not a feature. 1. There is even no good reason for any restriction on the minutes. If I want the alarm to snooze for 70 minutes?? Why restrict to 59??? I would have to do the unnecessary hassle to fill in two fields namely 1 hour AND 10 minutes. Is this a check on the user that there are 60 minutes to an hour? 2. No reason for whatever restriction on the hours. 3. One should be able to also state a number of days. Attached you find the patches to incorporate days and no restrictions on the hours and minutes.
Hi & thanks for the patch. Patch seems to be against 2.28.3 which is more than a year old, and Evolution has been migrated from libglade to gtkbuilder in the meantime as libglade is deprecated...
Hi, You're right, the patch is again 2.28.3. I can provide a patch against a more recent version of evolution. Will 2.30.3 be sufficiently recent?
Patches need to be submitted against the latest revision in git, which is currently at version 2.91.6.
Created attachment 178050 [details] [review] Arbitrary snooze time for evolution alarm for branch 2.28.3.1
Created attachment 178051 [details] [review] Arbitrary snooze time for evolution alarm for branch 2.30.3
Created attachment 178052 [details] [review] Arbitrary snooze time for evolution alarm for 2.91.5
Sorry for the delay, but it took me some time to have a system on which to compile 2.91.5 ... You find 3 patch files: One against 2.91.5 One against 2.28.3.1 (e.g. of interest for ubuntu 10.04) One against 2.30.3 (e.g of interest for ubuntu 10.10)
Shall I provide a patch against 2.32.1 as well?
Unfortunately I reacted to the quick reply to provide a patch against the current version. Obviously the patch is only good for copying it to /dev/null. Also, it seems it was necessary to provide a patch against the recent version before it can properly be sent to /dev/null. Thus, it seems the patch will always only be applied to my own system. This, I will have to repeat with every new version released for my OS. Most likely this was the last time I provided a patches for gnome.
I don't see a problem. Patch for 2.91.x will probably get reviewed soon, while 2.30 and 2.28 are ancient unsupported versions here in upstream that nobody cares about anymore (it's up to your distribution to provide updates for them, or not). That's how development works with limited manpower and there have not been any changes to that policy in the last years.
Thanks for a patch It looks fine. I removed only the allocation of the ngettext'ed string (in all three functions). It was unnecessary to allocate memory there. I'm not 100% convinced with restriction removals on those values, some users may consider it a bug, but if you think it's OK, then I'm keeping it as you did it. Created commit 21147b2 in evo master (2.91.90+)
What do you mean by "restrictions"? You mean that you can't enter e.g. 90 min (even though you definitely know you want to be reminded in 90 min)? What schould the 59 min. restriction be good for? Force someone into modulo 60 calculations? And make him/her enter 2 fields instead of one? Same with with hours and modulo 24. It is only good for unnecessary work by the user. Apart from that: 90 min. is an absolute perfect time statement. Nothing wrong with it. In case the patch is being incorporated: could you also make sure it'll also go into EVOLUTION_2_32_3? That would be helpful for many current distributions being released soon.
(In reply to comment #12) > What do you mean by "restrictions"? ... Your examples expect setting only one value, minutes or hours or days. Setting more than one makes things unclear/complicated (like setting an hour and 95 minutes). Either way, as I said, I kept no-limits there. > In case the patch is being incorporated: could you also make sure it'll also > go into EVOLUTION_2_32_3? No for two reasons: a) 2.32.x is under UI freeze, no changes to UI are allowed b) there will be no 2.32.3 release, unless some really bad thing will be discovered in 2.32.2, but even in that case the a) applies > That would be helpful for many current distributions being released soon. The history indicates just the opposite, ask the release team. But you can always ask your distribution to incorporate the patch on their own.