EFocusTracker tracks the input focus within a window and helps keep
the sensitivity of "selectable" actions in the main menu up-to-date.
Selectable actions include Cut, Copy, Paste, Select All and Delete.
EFocusTracker has built-in support for widgets that implement the
GtkEditable interface such as GtkEntry and GtkTextView. It also
supports custom widgets that implement the ESelectable interface,
which is a subset of GtkEditable and can apply to anything that
displays selectable content (esp. tree views and ETables).
This commit integrates EFocusTracker with EShellWindow, CompEditor,
EMsgComposer, and ESignatureManager.
It also bumps the GtkHTML requirement to 2.29.5 to utilize the new
GtkhtmlEditor:html constructor property.
/apps/evolution/mail/display/show_preview
/apps/evolution/mail/display/thread_list
These keys are no longer needed since we're storing the settings by
folder now in ~/.evolution/mail/config/state. To simplify things we use
hard-coded defaults: TRUE for PreviewVisible, FALSE for GroupByThreads.
Move the search interface to a new widget: EShellSearchbar
The current search rule is now stored in EShellView, and the search
context in EShellViewClass similar to GalViewCollection (since it's
class-specific, not instance-specific).
Also add a couple new signals to EShellView: "clear-search" and
"custom-search" ("custom" refers to an advanced search or a saved
search -- something more complex than a quick search).
Still working out a few kinks. The search entry is clearly trying to
be too many things. We need a different way of indicating that you're
looking at search results. Perhaps a search results banner similar to
Nautilus.
This allows modules to specify their own data dir in a flexible way without
having them hard-coded to the backend class name. For example, the data dir for
the mail backend should be specified by the mail session (eventually as an eds
daemon) and the vfunc will allow the shell to query that in a generic way.
EMailSidebar is a subclass of EMFolderTree that implements the state
saving and restoration feature from EMailShellSidebar. Placing this
in the shared mail library allows Anjal to reuse it.
The changes are mainly including the e-alert-header.h header instead of just
e-alert.h. This allows us to include e-alert.h in non-UI situations when
necessary.
This tells EShell where to look for EModules. Best practice is to
define the directory in your CPPFLAGS and then pass it to EShell at
instantiation time, like so:
Makefile.am:
evolution_CPPFLAGS = \
-DMODULEDIR=\""$(moduledir)"\"
...
main.c:
shell = g_object_new (
E_TYPE_SHELL, "module-directory", MODULEDIR, ...);
So Anjal can override what it needs to for its own purpose.
Also makes the EShellWindow design a little cleaner.
Methods added:
GtkWidget * (*construct_menubar) (EShellWindow *shell_window);
GtkWidget * (*construct_toolbar) (EShellWindow *shell_window);
GtkWidget * (*construct_sidebar) (EShellWindow *shell_window);
GtkWidget * (*construct_content) (EShellWindow *shell_window);
GtkWidget * (*construct_taskbar) (EShellWindow *shell_window);
EShellView * (*create_shell_view) (EShellWindow *shell_window,
const gchar *view_name);
Also added some new GObject properties to help decouple actions from
internal EShellWindow widgets created by these methods:
EShellWindow:sidebar-visible
EShellWindow:switcher-visible
EShellWindow:taskbar-visible
EShellWindow:toolbar-visible
The EError mechanism is used both for error dialogs as well as basic alerts or
user prompts, so we should give it a more general name which matches this use.
This patch also cleans up a few includes of e-alert.h (formerly e-error.h) that
were not actually being used.
https://bugzilla.gnome.org/show_bug.cgi?id=602963
Add method pointers to EShellClass for all the EShell signals.
Also rework my previous --quit corner case workaround: we'll want to do
the full shutdown procedure after all, since the backends have already
spun up.
This -asks- an existing Evolution process to quit. It is equivalent to
selecting File->Quit in the main window. It does not kill the process.
My plan is to use this as part of a new --force-shutdown implementation.
Hide actions that are disabled by lockdown settings instead of showing
them as disabled. Showing them as disabled gives the impression the
user can do something to enable them, which is not the case here.
Matthew Barnes