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 769470 - drag and drop places the event on wrong date
drag and drop places the event on wrong date
Status: RESOLVED FIXED
Product: gnome-calendar
Classification: Applications
Component: User Interface
3.21.x
Other Linux
: Normal major
: 3.26
Assigned To: GNOME Calendar maintainers
GNOME Calendar maintainers
Depends on:
Blocks:
 
 
Reported: 2016-08-03 14:20 UTC by Mohammed Sadiq
Modified: 2017-04-17 18:20 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
month-view: fix dnd (2.94 KB, patch)
2016-08-03 19:28 UTC, Ernestas Kulik
none Details | Review
Plugged a leak. (3.21 KB, patch)
2016-08-03 19:34 UTC, Ernestas Kulik
none Details | Review
month-view: fix dnd (3.24 KB, patch)
2016-08-03 19:58 UTC, Ernestas Kulik
none Details | Review
month-view: fix dnd (3.23 KB, patch)
2016-08-06 11:33 UTC, Ernestas Kulik
committed Details | Review
year-view: fix dnd (3.38 KB, patch)
2016-08-06 14:10 UTC, Ernestas Kulik
committed Details | Review
month-view: update events after dnd (1.27 KB, patch)
2016-08-11 08:28 UTC, Ernestas Kulik
committed Details | Review

Description Mohammed Sadiq 2016-08-03 14:20:34 UTC
When the event is spanning more than one month, drag and drop sometimes places the event on the wrong date.

How to reproduce:

1. Create a new event: Let it be a 2 day event on 31st August and 1st September.
2. In Month view, Go to the month September, drag the event (which is shown as the continuation on 1st September) to some other date of the same month.
3. The event is placed on the same day of the previous month, which is not intended.
4. Also, in year view, the drag and drop works pretty much weird. The end date is set as one day past the beginning date (This happens on single full day events too).
Comment 1 Ernestas Kulik 2016-08-03 19:28:42 UTC
Created attachment 332675 [details] [review]
month-view: fix dnd

Currently, the event is moved by a number of cells, calculated from the
start date and the cell index. The problem with that is that it does not
work with events, whose start and end dates of which are on different
months or years. This commit changes the logic so that the start date is
calculated by taking the year and month difference into consideration
and the end date is set by adding the event length to the adjusted start
date.
Comment 2 Ernestas Kulik 2016-08-03 19:30:58 UTC
I am not proud of this mess, but it does fix the month view (at least judging by the minimal testing I had done).
Comment 3 Ernestas Kulik 2016-08-03 19:34:02 UTC
Created attachment 332676 [details] [review]
Plugged a leak.
Comment 4 Ernestas Kulik 2016-08-03 19:58:02 UTC
Created attachment 332677 [details] [review]
month-view: fix dnd

Sorry for the noise.
This avoids crashes with null end dates.
Comment 5 Georges Basile Stavracas Neto 2016-08-05 20:27:46 UTC
Review of attachment 332677 [details] [review]:

Only a minor nitpik.

::: src/gcal-month-view.c
@@ +888,3 @@
+    {
+      timespan = g_date_time_difference (end_dt, start_dt);
+    }

Remove the {}s
Comment 6 Ernestas Kulik 2016-08-06 11:33:22 UTC
Created attachment 332820 [details] [review]
month-view: fix dnd

Currently, the event is moved by a number of cells, calculated from the
start date and the cell index. The problem with that is that it does not
work with events, whose start and end dates of which are on different
months or years. This commit changes the logic so that the start date is
calculated by taking the year and month difference into consideration
and the end date is set by adding the event length to the adjusted start
date.
Comment 7 Ernestas Kulik 2016-08-06 14:10:58 UTC
Created attachment 332824 [details] [review]
year-view: fix dnd

Currently, the end date is set by calling gcal_event_set_date_end() with
new_start instead of new_end, which is incorrect.

With the former issue fixed, the difference evaluates to one less than
required when dragging to a later date. This can be fixed by calculating
the drop date by adding to the start date and adding the difference.

This commit fixes both issues.
Comment 8 Ernestas Kulik 2016-08-06 14:13:18 UTC
Re the year view fix, I do not actually know what causes the latter issue. Could it have something to do with timezones? The difference between drop date and start date would always be a couple of hours short off a full day.
Comment 9 Georges Basile Stavracas Neto 2016-08-11 07:40:05 UTC
Review of attachment 332820 [details] [review]:

Sure.
Comment 10 Georges Basile Stavracas Neto 2016-08-11 07:41:27 UTC
Review of attachment 332824 [details] [review]:

Sure
Comment 11 Georges Basile Stavracas Neto 2016-08-11 07:42:17 UTC
I notice that Month view doesn't update events modified on Year view with DnD. Fixing that in a third patch would be a nice addition to this patchset.
Comment 12 Ernestas Kulik 2016-08-11 08:28:28 UTC
Created attachment 333095 [details] [review]
month-view: update events after dnd

The month view is not updated after a DnD operation. This commit marks
the children as changed after a drop.
Comment 13 Ernestas Kulik 2016-08-11 08:28:51 UTC
Is this what you meant?
Comment 14 Georges Basile Stavracas Neto 2016-08-11 16:01:46 UTC
Review of attachment 333095 [details] [review]:

Sure!
Comment 15 Ernestas Kulik 2016-08-11 16:05:24 UTC
Attachment 332820 [details] pushed as b5fb1d4 - month-view: fix dnd
Attachment 332824 [details] pushed as 04617fc - year-view: fix dnd
Attachment 333095 [details] pushed as 7243f70 - month-view: update events after dnd