Google Summer of Code 2013 - GNOME - Archive Integration workspace https://www.lant.com.tw/~lantw44/cgit/cgit.cgi/gsoc2013-evolution/atom?h=archive-integration 2012-12-12T19:33:43+00:00 2012-12-12T19:33:43+00:00 Matthew Barnes mbarnes@redhat.com 2012-12-10T13:09:59+00:00 urn:sha1:d09d8de870b6697c8a8b262e7e077b871a69b315 Evolution consists of entirely too many small utility libraries, which increases linking and loading time, places a burden on higher layers of the application (e.g. modules) which has to remember to link to all the small in-tree utility libraries, and makes it difficult to generate API documentation for these utility libraries in one Gtk-Doc module. Merge the following utility libraries under the umbrella of libeutil, and enforce a single-include policy on libeutil so we can reorganize the files as desired without disrupting its pseudo-public API. libemail-utils/libemail-utils.la libevolution-utils/libevolution-utils.la filter/libfilter.la widgets/e-timezone-dialog/libetimezonedialog.la widgets/menus/libmenus.la widgets/misc/libemiscwidgets.la widgets/table/libetable.la widgets/text/libetext.la This also merges libedataserverui from the Evolution-Data-Server module, since Evolution is its only consumer nowadays, and I'd like to make some improvements to those APIs without concern for backward-compatibility. And finally, start a Gtk-Doc module for libeutil. It's going to be a project just getting all the symbols _listed_ much less _documented_. But the skeletal structure is in place and I'm off to a good start. 2012-11-30T20:18:14+00:00 Matthew Barnes mbarnes@redhat.com 2012-11-30T20:18:14+00:00 urn:sha1:0c751ff6dbc9a50d4d956f765334e1a6d0d6bf80 Call gtk_widget_style_get(). No need to get GtkStyle involved. 2012-11-30T19:28:35+00:00 Matthew Barnes mbarnes@redhat.com 2012-11-30T18:36:38+00:00 urn:sha1:7c2e05401bfed572a7253d3da24a30306497d570 Use GtkStyleContext-based "render" functions instead. gtk_paint_arrow() --> gtk_render_arrow() gtk_paint_box() --> gtk_render_background() gtk_paint_expander() --> gtk_render_expander() gtk_paint_flat_box() --> gtk_render_background() gtk_paint_shadow() --> gtk_render_frame() gtk_paint_vline() --> gtk_render_line() 2012-11-30T16:40:04+00:00 Matthew Barnes mbarnes@redhat.com 2012-11-30T16:40:04+00:00 urn:sha1:b15e0d6df6e3e626a7c8b33fd1d0504fca7ca5b5 Use gtk_widget_get_preferred_size() instead. 2012-11-30T16:30:10+00:00 Matthew Barnes mbarnes@redhat.com 2012-11-30T15:39:03+00:00 urn:sha1:2ce2f8c27698e6122c6a2687f710a18bb4ca602b Use gdk_device_grab() and gdk_device_ungrab() instead. In some cases this requires stashing the grabbed device so it can be ungrabbed outside of an GdkEvent handler. 2012-11-30T14:30:45+00:00 Milan Crha mcrha@redhat.com 2012-11-30T14:29:34+00:00 urn:sha1:ab3f65a15e1b6fe5bdf488e6e879899e283ccc43 2012-11-29T23:15:35+00:00 Matthew Barnes mbarnes@redhat.com 2012-11-29T21:33:41+00:00 urn:sha1:d52ad1054d509bbe02809b7f5a9471e95727ef08 GnomeCanvas will stash the GdkDevice and reuse it in the subsequent gnome_canvas_item_ungrab() call. 2012-11-29T18:24:24+00:00 Matthew Barnes mbarnes@redhat.com 2012-11-29T18:12:41+00:00 urn:sha1:d2fb5ee1a86539e49f02c1fe9ea10cf55b0b351a Prefer dealing with GdkEvent pointers and using accessor functions like gdk_event_get_button(). This is complicated by the fact that some GtkWidget method declarations still use GdkEventButton pointers, and synthesizing button events pretty much requires direct GdkEventButton access. But GDK seems to be nudging itself toward sealing the GdkEvent union. Likely to happen in GDK4. Mainly clean up signal handlers and leave method overrides alone for now. 2012-11-29T14:16:11+00:00 Matthew Barnes mbarnes@redhat.com 2012-11-29T00:01:30+00:00 urn:sha1:4bc40f6663d6a809dda4dcbeae27902b5883cad1 Will be needed for grabs in response to button events. 2012-11-10T20:54:43+00:00 Matthew Barnes mbarnes@redhat.com 2012-11-10T03:40:00+00:00 urn:sha1:2c4ae5e7685c462f8d464448e4617b8dea029e72