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.
https://bugzilla.gnome.org/show_bug.cgi?id=769470
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.
https://bugzilla.gnome.org/show_bug.cgi?id=769470
Currently, all-day multi-day events are displayed inconsistently with
regard to other calendar applications. That is due to strict following
of RFC 5545, which mandates non-inclusive all-day multi-day event end
dates. This commit makes the edit dialog display a faked date for such
events.
https://bugzilla.gnome.org/show_bug.cgi?id=769300
Currently, the hour component of the time is doubled when switching from
AM to PM, which is incorrect. This commit fixes the logic by adding 12
hours when switching to PM.
https://bugzilla.gnome.org/show_bug.cgi?id=765370
If GcalEditDialog.format_24h is initialized to zero, the call to
gcal_edit_dialog_set_time_format() from GcalWindow will not make
period_combo boxes visible on systems, where 12-hour clocks are used.
This commit fixes that by removing the if statement from the function.
https://bugzilla.gnome.org/show_bug.cgi?id=765370
Function calendar_get_week_start do the same things with the same code as
function get_first_weekday, so it is better to remove calendar_get_week_start
and switch all the use of calendar_get_week_start to get_first_weekday.
This also fixes build problems on non-glibc systems because get_first_weekday
provides fallback for non-glibc systems.
https://bugzilla.gnome.org/show_bug.cgi?id=769140
To keep the current date chooser in sync with
GNOME Shell, tweak the week names to show only
the first, upcased letter of the week name.
Also, this commit avoids making day number circles
ellipses when the week number is not present.
The current implementation of the new calendar widget
accepts showing the week numbers in a modern and much
more consistent way.
The behavior, however, is not aligned with the rest of
the application and the desktop, which share a setting
to show or hide the week number.
Fix that by synchronizing the new calendar's week number
property with the specific setting.
After making the date selector use the brand
new date chooser widget, it is now time to make
it an entry.
This commit, then turns GcalDateSelector into a
GtkEntry subclass, and add all the plumbing that
is necessary to make it work as such.
As a side effect, this commit adds rudimentary
natural language support for parsing dates.
After adding the new GcalDateChooser widget, change the
current date selector to use it as the internal widget
of the popover.
The next logical step is turning GcalDateSelector into
an entry.
This is mainly a copy-paste from an old branch authored
by Matthias Clasen. The code style was updated to match
Calendar's one, and the theming was improved a little bit.
After adding the button in the headerbar, it is natural to
bring back the ability to move events between sources.
This commit finally includes the usage of GcalManager:move_event_to_source
function, which was implemented ages ago.
Since we're storing the GdkWindow relative to the event widget,
it's usually safer to create a pixbuf of the widget *after* it's
drawn, and not while it's being drawed.
This commit moves the pixbuf retrieval code to the draw-begin
implementation, so we only create the pixbuf when actually
using it.
This commit introduces the ability in Edit dialog to
display the currently available alarms, as well as basic
editing of these alarms.
Currently, only removing the alarms and modifying it to
play a sound or not is available. The following up commit
will add the ability to add new alarms.
Instead of keeping a ref to the GcalEditDialog::select-calendar
action, use the builtin facilities and simplify the action
handling by using a const structure.
This is also a preparation for the next few commits where alarms
will be added.
If the user quickly performs a search, open up the calendar
and close it immediately after, the timeout for showing the
event is mistakenly called after the window is destroyed and
causes Calendar to crash.
Fix that by keeping the source id tracked, and realizing it
on finalize().
Currently, the user performs a search in Shell and activates
the result. That should show the edit dialog with the event
being edited, but it's not happening correctly.
Debugging the warnings generated, it was found that the event
was being unref()d and, obviously, that was not what we wanted.
Fix that by only unref()ing the events we don't want, and keeping
the wanted event alive.
Year view was placing popover to mouse click (x,y) position. That was a
little odd because sometimes popover was placed above the selected day.
This patch address that by placing popover always out of the day box.
When selecting the whole month or more than one day, popover will also
be placed out of the month box. reducing the chance to cover selected
days.
https://bugzilla.gnome.org/show_bug.cgi?id=743306
