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 778713 - Discarding changes on events even if changes are cancelled
Discarding changes on events even if changes are cancelled
Status: RESOLVED OBSOLETE
Product: gnome-calendar
Classification: Applications
Component: General
3.23.x
Other Linux
: Normal normal
: 3.26
Assigned To: GNOME Calendar maintainers
GNOME Calendar maintainers
Depends on:
Blocks:
 
 
Reported: 2017-02-15 21:13 UTC by Iñigo Martínez
Modified: 2017-11-24 22:11 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Iñigo Martínez 2017-02-15 21:13:06 UTC
When editing an event, even if you press the "Cancel" button, changes made to location and alarms still remain in the application (not in the source). This behaviour cames from two reasons.

1. the way in which the edit dialog is created

When you click on a widget event, after some signals, event_activated function from GcalWindow is executed, where the event of the GcalEventWidget is set as the event to be edited in the GCalEditDialog. This is done by calling to gcal_edit_dialog_set_event and then to g_set_object from GcalEditDialog to update the event reference:

static void
event_activated (GcalView        *view,
                 GcalEventWidget *event_widget,
                 gpointer         user_data)
{
   GcalWindow *window = GCAL_WINDOW (user_data);
   GcalEvent *event;
 
   event = gcal_event_widget_get_event (event_widget);
   gcal_edit_dialog_set_event_is_new (GCAL_EDIT_DIALOG (window->edit_dialog), FALSE);
   gcal_edit_dialog_set_event (GCAL_EDIT_DIALOG (window->edit_dialog), event);
 
   gtk_widget_show (window->edit_dialog);
}

void
gcal_edit_dialog_set_event (GcalEditDialog *dialog,
                            GcalEvent      *event)
{
   g_return_if_fail (GCAL_IS_EDIT_DIALOG (dialog));
 
   if (g_set_object (&dialog->event, event))
    {
    ...
    }
}

After several changes, when the event dialog is closed using the "Cancel" button, gcal_edit_dialog_action_button_clicked is executed on GcalEditDialog without any action other than emiting the response with GTK_RESPONSE_CANCEL value (and changes the internal event reference, but that is not important in this case), and then the edit_dialog_closed function from GcalWindow is executed where that response value is analized. When the action is GTK_RESPONSE_CANCEL it does nothing, but actually the changes remain as they have been made on the event that GcalEventWidget stores.

static void
edit_dialog_closed (GtkDialog *dialog,
                    gint       response,
                    gpointer   user_data)
{
   GcalWindow *window;
   GcalEditDialog *edit_dialog;
   GcalEvent *event;
   GcalView *view;
   GList *widgets;
 
   window = GCAL_WINDOW (user_data);
   edit_dialog = GCAL_EDIT_DIALOG (dialog);
   event = gcal_edit_dialog_get_event (edit_dialog);
   view = GCAL_VIEW (window->views[window->active_view]);
 
   gtk_widget_hide (GTK_WIDGET (dialog));
 
   switch (response)
     {
     ...
     case GTK_RESPONSE_CANCEL:
     default:
       break;
 
     }
}

2. Changes made on those properties inside the edit dialog.

When updating location property the update_location function from GCalEditDialog is executed which calls gcal_event_set_location modifying the event. The same happens with alarms on remove_button_clicked by calling to gcal_event_remove_alarm and also on add_alarm_button_clicked by calling to gcal_event_add_alarm.

I have been thinking about the problem and there should be different approaches to solve it.
Comment 1 Georges Basile Stavracas Neto 2017-11-24 22:11:53 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-calendar/issues/115.