brl/gnome-shell
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
21403b19e0
gnome-shell/src/Makefile-calendar-server.am

38 lines
1.0 KiB
Plaintext
Raw Normal View History

sniffer: add a mimetype sniffer helper executable The sniffer is a simple helper process, activated as a DBus service, that tries to crawl as many files as possible in the provided target directory (i.e. the new mount's root), for a maximum amount of time - which is set here to 1.5 seconds (i.e. it will crawl either all the files in the directory tree, or as many as it can before the specified timeout expires). Crawled files are ordered by their content type, and a generic estimation of the type of files composing the directory is returned to the caller, using generic 'x-content/*' mimetypes. The process will then set an autoquit timeout on itself, which can be disabled by setting the env variable HOTPLUG_SNIFFER_PERSIST for debugging purposes. The HOTPLUG_SNIFFER_DEBUG env variable can also be set to enable debugging output. https://bugzilla.gnome.org/show_bug.cgi?id=653520
2011-07-12 10:34:41 -04:00
service_in_files += calendar-server/org.gnome.Shell.CalendarServer.service.in
Move calendar handling out-of-process Unfortunately the evolution-data-server client-side libraries seem to block the calling thread. This is a major problem as we must never ever block the main thread (doing so causes animations to flicker etc.). In the worst case, this problem causes login to hang (without falling back to fall-back mode) and in the best case it slows down login until a network connection is acquired. Additionally, in order to sanely use these evolution-data-server libraries, GConf has to be involved and GConf is not thread-safe. So it's not really feasible just moving the code to a separate thread. Therefore, move all calendar IO out of process and use a simple (and private) D-Bus interface for the shell to communicate with the out-of-process helper. For simplification, remove existing in-process code since internal interfaces have been slightly revised. This means that the shell is no longer using any native code for drawing the calendar dropdown. https://bugzilla.gnome.org/show_bug.cgi?id=641396 Signed-off-by: David Zeuthen <davidz@redhat.com>
2011-02-25 17:42:25 -05:00
libexec_PROGRAMS += gnome-shell-calendar-server
gnome_shell_calendar_server_SOURCES = \
calendar-server/calendar-debug.h \
calendar-server/calendar-sources.c calendar-server/calendar-sources.h \
calendar-server/gnome-shell-calendar-server.c \
$(NULL)
calendar-server: Add .desktop file for evolution calendar When selecting "Open Calendar" in the date menu, the configured application is launched via command line, so we don't get any startup notification. In order to fix the issue at least for our default calendar, add a hidden .desktop file for evolution's calendar component. https://bugzilla.gnome.org/show_bug.cgi?id=677907
2012-07-03 17:48:57 -04:00
desktopdir=$(datadir)/applications
desktop_DATA = $(desktop_in_files:.desktop.in=.desktop)
desktop_in_files = calendar-server/evolution-calendar.desktop.in
@INTLTOOL_DESKTOP_RULE@
Move calendar handling out-of-process Unfortunately the evolution-data-server client-side libraries seem to block the calling thread. This is a major problem as we must never ever block the main thread (doing so causes animations to flicker etc.). In the worst case, this problem causes login to hang (without falling back to fall-back mode) and in the best case it slows down login until a network connection is acquired. Additionally, in order to sanely use these evolution-data-server libraries, GConf has to be involved and GConf is not thread-safe. So it's not really feasible just moving the code to a separate thread. Therefore, move all calendar IO out of process and use a simple (and private) D-Bus interface for the shell to communicate with the out-of-process helper. For simplification, remove existing in-process code since internal interfaces have been slightly revised. This means that the shell is no longer using any native code for drawing the calendar dropdown. https://bugzilla.gnome.org/show_bug.cgi?id=641396 Signed-off-by: David Zeuthen <davidz@redhat.com>
2011-02-25 17:42:25 -05:00
gnome_shell_calendar_server_CFLAGS = \
-I$(top_srcdir)/src \
-DPREFIX=\""$(prefix)"\" \
-DLIBDIR=\""$(libdir)"\" \
-DDATADIR=\""$(datadir)"\" \
-DG_DISABLE_DEPRECATED \
-DG_LOG_DOMAIN=\"ShellCalendarServer\" \
$(CALENDAR_SERVER_CFLAGS) \
$(NULL)
gnome_shell_calendar_server_LDFLAGS = \
$(CALENDAR_SERVER_LIBS) \
$(NULL)
EXTRA_DIST += \
calendar-server/README \
calendar-server/org.gnome.Shell.CalendarServer.service.in \
$(NULL)
calendar-server: Add .desktop file for evolution calendar When selecting "Open Calendar" in the date menu, the configured application is launched via command line, so we don't get any startup notification. In order to fix the issue at least for our default calendar, add a hidden .desktop file for evolution's calendar component. https://bugzilla.gnome.org/show_bug.cgi?id=677907
2012-07-03 17:48:57 -04:00
build: Fix distcheck I knew it had to be something simple ...
2012-08-06 10:11:17 -04:00
CLEANFILES += \
calendar-server: Add .desktop file for evolution calendar When selecting "Open Calendar" in the date menu, the configured application is launched via command line, so we don't get any startup notification. In order to fix the issue at least for our default calendar, add a hidden .desktop file for evolution's calendar component. https://bugzilla.gnome.org/show_bug.cgi?id=677907
2012-07-03 17:48:57 -04:00
$(desktop_DATA)
Reference in New Issue Copy Permalink