| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Set an urgency hint on dialog's parent, or dialog itself, when it has
no parent, to get user's attention to the dialog. For example, when
there is a changed mail composer window on a different workspace than
evolution's main window and user invokes quit by File->Quit in evolution,
then the window is waiting for a response on the composer, but there
was no hint it's waiting for anything.
|
|
|
|
|
|
|
|
|
|
| |
Making EAlertDialog non-resizable is the only way at present for GTK+ to
pick a resonable default size, otherwise we get alerts looking like this:
https://bugzilla.gnome.org/attachment.cgi?id=221303
See https://bugzilla.gnome.org/681937 for details.
Also drop the default window size hack in alert_dialog_constructed().
|
|
|
|
|
| |
Clean up resulting deprecation warnings, which were all related to
GtkOrientable consolidation (e.g. gtk_hbox_new() -> gtk_box_new()).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
| |
This is a regression from commit 451179909849, which removes the default
"Dismiss" action from each EAlert, but the EAlertDialog was using that
button to allow users to close it.
|
| |
|
| |
|
|
|
|
|
|
|
| |
Add e_alert_dialog_get_content_area(), which returns the GtkVBox
containing the primary and secondary labels. Use this instead of
gtk_dialog_get_content_area() to maintain the dialog's left margin
beneath the image.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
As of GLib 2.28 all GObject virtual methods, including constructed(),
are safe to chain up to unconditionally. Remove unnecessary checks.
|
| |
|
| |
|
|
|
|
|
|
| |
This marks the end of unintrusive error dialogs, which were too
unintrusive. We now show errors directly in the main window using
the EAlert / EAlertSink framework.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
You can now amend the predefined actions in an EAlert by calling
e_alert_add_action(). Useful for adding actions from an existing
GtkUIManager.
Call e_alert_peek_actions() to obtain a combined list of predefined
and custom actions. These will typically serve as "related" actions
for GtkButtons (cf. gtk_activatable_set_related_action()).
Also, both EShellWindow and EShellView now implement EAlertSink. Use
EShellWindow for application-wide alerts, EShellView for view-specific
alerts.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'Send' and 'Save Draft' are now asynchronous and run outside of
Evolution's MailMsg infrastructure.
Add an EActivityBar to the composer window so these asynchronous
operations can be tracked and cancelled even in the absense of a main
window. Also add an EAlertBar to the composer window so error messages
can be shown directly in the window.
Instead of calling e_alert_dialog_run_for_args(), call e_alert_submit()
and pass the EMsgComposer as the widget argument. The EMsgComposer will
decide whether to show an EAlertDialog or use the EAlertBar, depending
on the GtkMessageType of the alert.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Trying out a new interface called EAlertSink. The idea is to centralize
how errors are shown to the user. A GtkWindow subclass would implement
the EAlertSink interface, which consists of a single method:
void (*submit_alert) (EAlertSink *alert_sink, EAlert *alert);
The subclass has complete control over what to do with the EAlert,
although I imagine we'll wind up implementing various alert-handling
policies as standalone widgets such as EAlertDialog. I'd like to try
an EAlertInfoBar.
Code that would otherwise display an error dialog itself would instead
pass the EAlert to an appropriate EAlertSink and be done with it.
Nothing is final yet. Still hacking on EAlert trying to find an API
that feels right for these use cases.
|
|
|
|
| |
Clean up the header, drop some unused cruft.
|
|
|
|
|
|
|
| |
If we're using GTK+ 2.21.8 (where gtk_dialog_set_has_separator() is
deprecated but the property is still present and defaults to TRUE), we
still need to set the property to FALSE. So instead use g_object_set()
up through GTK+ 2.90.6, after which the property itself is gone.
|
|
|
|
|
|
| |
Unfortunately the default value for this property is TRUE (bzzt, WRONG!)
so we can't just remove the function outright until we require GTK+ 2.22.
It was deprecated in GTK+ 2.21.8.
|
| |
|
|
|
|
|
|
|
| |
Prefer thread-safe G_DEFINE_TYPE and G_DEFINE_INTERFACE macros over
manual GType registration.
This is just a start... lots more to do.
|
|\ |
|
| | |
|
| | |
|
|/ |
|
|
|
|
|
|
| |
Add G_GNUC_NULL_TERMINATED to EAlert functions with variable-length
parameter lists and drop the unnecessary "arg0" parameter so the
function attribute works correctly.
|
|
|
|
|
|
| |
EAlertDialog wants the primary and secondary strings escaped for use in
markup text, EActivityProxy does not use markup. So make it an explicit
part of the EAlert API.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
previously we were storing the EAlert's primary and secondary text in the dialog
object (using g_object_set_data_full). Since EAlertDialog encapsulates an
EAlert and we have access to the underlying EAlert object, we can just use the
EAlert API to get the primary and secondary text rather than storing duplicates
copies of it in the dialog.
|
|
|
|
| |
Fix another minor regression from my EAlert refactoring
|
|
|
|
|
| |
Make it obvious that this does not need to be freed like the other things that
use get_* (e.g. e_alert_get_title)
|
|
This is a proper implementation of the various alert dialog helper functions.
It is a proper subclass of GtkDialog, etc.
|