Re: [Evolution-hackers] alarm-notify patch: Proposed changes to notify dialog
On Thu, 2013-08-15 at 07:47 +0200, Thomas Mittelstaedt wrote: I made a couple of changes to my ancient (2.28.4) version of evolution. First, I encountered a nuisance in the alarm notify dialog, that when the dialog pops up and a new alarm is coming in, the selection changes to this new item, while the user potentially ist just clicking the dismiss or snooze button. I made the attached change to simply not preselect anything, having checked that the same is still running in the current git version at https://git.gnome.org/browse/evolution. Hi, I made a little change to your proposal, and committed it as: https://git.gnome.org/browse/evolution/commit/?id=daaf089be7ea1ac97a39ce6e38696be6851d3259 I also had a crash in the alarm-notify app and I inserted the attached safety check. I guess you face: https://bugzilla.gnome.org/show_bug.cgi?id=641711 but I cannot tell for sure without a backtrace. I cannot speak for the ask before dismiss all right now, I do not have any strong opinion on it. The other clients do not ask too, which doesn't mean it's a bad idea to add the confirmation dialog. By the way, it's better to file bugs, as it's kind of a tracker and things do not get lost there, like on mailing lists. See: https://bugzilla.gnome.org/enter_bug.cgi?product=Evolution Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] alarm-notify patch: Proposed changes to notify dialog
Am Donnerstag, den 15.08.2013, 07:47 +0200 schrieb Thomas Mittelstaedt:
I made a couple of changes to my ancient (2.28.4) version of evolution.
First, I encountered a nuisance in the alarm notify dialog, that when
the dialog pops up and a new alarm is coming in, the selection changes
to this new item, while the user potentially ist just clicking the
dismiss or snooze button. I made the attached change to simply not
preselect anything, having checked that the same is still running in the
current git version at https://git.gnome.org/browse/evolution.
I also had a crash in the alarm-notify app and I inserted the attached
safety check.
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
Also make another change to show a confirmation dialog when the user
presses the dismiss all button.
--
thomas
commit 8db79a84f68f32f07be4c139cdb4f9721d43ef0c
Author: Thomas Mittelstaedt tmsta...@t-mittelstaedt.de
Date: Fri Aug 16 05:07:11 2013 +0200
Show a confirmation dialog, when the user presses the dismiss all
button.
diff --git a/calendar/gui/alarm-notify/alarm-queue.c b/calendar/gui/alarm-notify/alarm-queue.c
index 59a0884..b29b8ac 100644
--- a/calendar/gui/alarm-notify/alarm-queue.c
+++ b/calendar/gui/alarm-notify/alarm-queue.c
@@ -1177,6 +1177,9 @@ tray_list_remove_data (TrayIconData *data)
message_push ((Message *) msg);
}
+static gboolean
+procedure_notification_dialog (const gchar *cmd, const gchar *url);
+
static void
notify_dialog_cb (AlarmNotifyResult result, gint snooze_mins, gpointer data)
{
@@ -1232,7 +1235,7 @@ notify_dialog_cb (AlarmNotifyResult result, gint snooze_mins, gpointer data)
case ALARM_NOTIFY_CLOSE:
d(printf(%s:%d (notify_dialog_cb) - Dialog close\n,__FILE__, __LINE__));
- if (alarm_notifications_dialog) {
+ if (alarm_notifications_dialog procedure_notification_dialog (Sure close?, )) {
GtkTreeIter iter;
GtkTreeModel *model =
gtk_tree_view_get_model (
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] alarm-notify patch: Proposed changes to notify dialog
Am Freitag, den 16.08.2013, 05:09 +0200 schrieb Thomas Mittelstaedt: Am Donnerstag, den 15.08.2013, 07:47 +0200 schrieb Thomas Mittelstaedt: I made a couple of changes to my ancient (2.28.4) version of evolution. First, I encountered a nuisance in the alarm notify dialog, that when the dialog pops up and a new alarm is coming in, the selection changes to this new item, while the user potentially ist just clicking the dismiss or snooze button. I made the attached change to simply not preselect anything, having checked that the same is still running in the current git version at https://git.gnome.org/browse/evolution. I also had a crash in the alarm-notify app and I inserted the attached safety check. Also make another change to show a confirmation dialog when the user presses the dismiss all button. ___ Forget the last attached diff. Doesn't work properly. Just as a general idea: Ask for confirmation before dismissing all alarms or even a single one. -- thomas ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] alarm-notify patch: Proposed changes to notify dialog
I made a couple of changes to my ancient (2.28.4) version of evolution.
First, I encountered a nuisance in the alarm notify dialog, that when
the dialog pops up and a new alarm is coming in, the selection changes
to this new item, while the user potentially ist just clicking the
dismiss or snooze button. I made the attached change to simply not
preselect anything, having checked that the same is still running in the
current git version at https://git.gnome.org/browse/evolution.
I also had a crash in the alarm-notify app and I inserted the attached
safety check.
--
thomas
commit 20c497b8a7fa130eae9c639c191aa0821c1f8d47
Author: Thomas Mittelstaedt tmsta...@t-mittelstaedt.de
Date: Thu Aug 15 06:55:43 2013 +0200
Don't set selection to new items coming in while dialog is open
diff --git a/calendar/gui/alarm-notify/alarm-queue.c b/calendar/gui/alarm-notify/alarm-queue.c
index 5d9177d..9a3f80b 100644
--- a/calendar/gui/alarm-notify/alarm-queue.c
+++ b/calendar/gui/alarm-notify/alarm-queue.c
@@ -1306,7 +1306,7 @@ open_alarm_dialog (TrayIconData *tray_data)
tray_data-location,
notify_dialog_cb, tray_data);
- gtk_tree_selection_select_iter (selection, tray_data-iter);
+ /* gtk_tree_selection_select_iter (selection, tray_data-iter); */
}
commit 2d7f700f3ef7de943549f4780252c9c6bcf1fc68
Author: Thomas Mittelstaedt tmsta...@t-mittelstaedt.de
Date: Thu Aug 15 07:27:34 2013 +0200
Check for empty list in tray_list_remove_async
diff --git a/calendar/gui/alarm-notify/alarm-queue.c b/calendar/gui/alarm-notify/alarm-queue.c
index 9a3f80b..59a0884 100644
--- a/calendar/gui/alarm-notify/alarm-queue.c
+++ b/calendar/gui/alarm-notify/alarm-queue.c
@@ -1103,6 +1103,7 @@ static void
tray_list_remove_async (Message *msg)
{
GList *list = tray_icons_list;
+ g_return_if_fail (g_list_first(list) != NULL);
d(printf(%s:%d (tray_list_remove_async) - Removing %d alarms\n,__FILE__, __LINE__, g_list_length(list)));
while (list != NULL) {
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] alarm-notify ...
Hi guys,
I was reading calendar/gui/alarm-dialog/alarm-notify.c - trying (of
course) to work out why alarm delivery is apparently not working at all.
I just committed some code enabling dbus threading - without which you
can quite happily use dbus from multiple threads, only it will crash and
burn very horribly. That seemed to fix a nasty race I was getting
whereby no alarms showed up at all.
It might also help to undo:
static void
message_push (Message *msg)
{
/* This used be pushed through the thread pool. This fix is made to
work-around
the crashers in dbus due to threading. The threading is not completely
removed as
its better to have alarm daemon running in a thread rather than
blocking main thread.
This is the reason the creation of thread pool is commented out */
msg-func (msg);
}
This sort of thing.
I could also not see where the Repeat functionality (customize an
alarm, and select Repeat the alarm is setup - surely not on the e-d-s
side ? - do we still have it ?
It was also a surprise to me to see the default setting for create an
alarm 15 mins before each appointment to be off - is that a
feature ? :-) it was unexpected.
Finally - it seems some migration code went awry somewhere here, and
busted the use systray setting for the alarm daemon:
https://bugzilla.gnome.org/show_bug.cgi?id=616658
HTH,
Michael.
--
michael.me...@novell.com , Pseudo Engineer, itinerant idiot
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
