Probably I can load the GMenuModel of the popover directly but I don't
know exactly how, and I've asked already and you can set bindings using
builder's ui file, just like before I don't know how at this time.
Previously the scaling was made to the size of the text layout which
caused a blurriness of the icon. Making its size a multiple of 16 made
the icon preserve its sharpness.
The previous approach was causing an error on the animation code of
GtkStack because the search-view's GdkWindow was banishing before
the end of the animation.
The call to GtkWidget::unrealize was destroying GtkStack window because
of the reference increasing on GcalWeekView when setting the
parent_window as its own.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=739554
There are some other changes:
1. Renamed widget class to "event-widget" to avoid collisions
2. Added contrasting event title coloring
3. Use gtk_render functions
GcalEditDialog::clear_data was clearing the summary on the internal
ECalComponent instance. Blocking signal handler call allow to clear the
widget without clearing the component.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=739307
This works in conjunction with code implemented in GcalSubscriber where
the ownership of the event widget passes into the container, so the
container is free to delete it in case it does not fit into the range
represented by the view.
GcalView::draw_event overlapped a bit with GcalView::will_add_event, so
the same reasons for removing one stand for the other.
GcalView::clear was a hack for the composited GcalDayView which has
gone, and was a bad experiment.
As Lapo rightfully explain, providing a button there for creating a new
event is way to prominently and might divert users of the intended click
on a cell behavior to create an event.
New event will be also accessible from the hamburger icon on the left of
the header-bar and Ctrl-N key shortcut.
Also as Lapo suggestion Today button fall better on the header bar than
between the navigation buttons.
ECalDataModelSubscriber interface notify each view only about the events
beloging to the subscribed range so there's no need of checking if the
event widget will be added.
The safety check of not adding the same widget twice its stil being made
on each GtkContainer::add implementation.
By making GcalMonthView a descendat of GcalSubscriber it gets
implementation for each of the methods on ECalDataModel subscriber and
utomatically gains the functionality of adding and removing events widgets
GcalSubscriber abstract class is meant for handling the implementation
of ECalDataModelSubscriber interface. The code in each vfunc implemented
is the same for each view, then it makes sense to have a class holding
these implementations and make every views descend from it. This class
sits in the middle between GtkContainer and each of the views.
It seems gtk_style_context_add_provider_for_screen increase the ref
count of the GtkCssProvider (maybe copy it to GdkScreen and this isn't
releasing it correctly). We're forcing an _unref to keep the destruction
process working as expected. Previously gtk_css_provider_finalize was
not called at any time on the closing process.
Fixes destruction process. Calling g_application_quit skip the reference
decreasing process of GApplication and that resulted in a bunch of
_finalize methods not being called. By removing the windows GApplication
finalize properly.
Initial work implementing ECalDataModelSubscriber interface. As
explained before, on each set of GcalView:active-date property the range
the view its subscribing gets updated. Allowing this to obtain
notification through ECalDataModelSubscriber::components_added and
ECalDataModelSubscriber::components_removed vfuncs.
Since a pointer to the GcalManager instance it's needed at construction
time and GtkWindow::application property is not set as construction
property. We need to add this property to have a reference to pass to
the instantiated views.
Just like the views, this isn't ref/copied or anything, it's just a
dummy pointer. The application objects is the respnsible of handling
GcalManager instance initialization and destruction.
Events related signals from GcalManager had been removed previously,
those handlers aren't needed anymore.
Second, there's no need to inform GcalManager of the new range since
every view will do so internally. Also, there's no need of removing
children widgets from the active view, since each view will do so on its
own by implementing ECalDataMoelSubscriber::components_removed vfunc.
As explained before, this is only intended to keep a reference to the
GcalManager instance of the application.
Misc: fixed some documentation and whitespace issues
Since the events widget are handled entirely inside GcalView
implementations (aka the views), we need a way to hook event-widget
activation with GcalWindow which is handling the dialogs (as expected).
This signal serve as a bridge between those two objects.
This cleaning is made in order to merge this branch into master as soon
as possible.
The implementation of GcalDayView is planned to go on the same lines as
GcalWeekView but for two days alone, so much of the code of the latter
could be reused. The approach of using shallow container and kinda
layout manager objects inside GcalDayView didn't worked that well for my
expertise at this time.
Initial work. Code is marked all over the place with comments
GcalManager:set_subscriber will set a view and a new range in the
internal ECalDataModel instance.
More cleaning is needed, along the way unneeded methods will be removed
Implements an ECalDataModel object from evolution courtesy of Milan Crha
ECalDataModel hides the details of events retrieving from
calendars. Provides a time range and a subscriber system allowing
objects implements the necessary callbacks to be notified of events
happening on the selected time range.
Since GcalManager does not have any properties or use in way GObject's
initialization system there's no need of having initialization code
split between vfunc _init and vfunc _contructed.
The code added make the dialog show up. Probably anything else works,
but it's start to keep the project building while GcalManager migration
is finished and new GcalEditDialog is built.
Reorganized some code as mentioned on HACKING code style file
Removed unused methods
Started migration on new EditDialog flow to match latest GcalManager API
Updated GcalManager:events-modified handler to match lastet GcalManager
API
