aboutsummaryrefslogtreecommitdiffstats
path: root/widgets/text/e-text.h
diff options
context:
space:
mode:
authorJon Trowbridge <trow@gnu.org>2001-03-06 08:13:23 +0800
committerJon Trowbridge <trow@src.gnome.org>2001-03-06 08:13:23 +0800
commit1bdc6e147f19384e42679512130cfc5f4d93364b (patch)
tree4b65f6d428b6d2a5c1b5787c78c423f900686306 /widgets/text/e-text.h
parent9b8456b4d12dd59ee485ceb9bffbc635c8776b12 (diff)
downloadgsoc2013-evolution-1bdc6e147f19384e42679512130cfc5f4d93364b.tar
gsoc2013-evolution-1bdc6e147f19384e42679512130cfc5f4d93364b.tar.gz
gsoc2013-evolution-1bdc6e147f19384e42679512130cfc5f4d93364b.tar.bz2
gsoc2013-evolution-1bdc6e147f19384e42679512130cfc5f4d93364b.tar.lz
gsoc2013-evolution-1bdc6e147f19384e42679512130cfc5f4d93364b.tar.xz
gsoc2013-evolution-1bdc6e147f19384e42679512130cfc5f4d93364b.tar.zst
gsoc2013-evolution-1bdc6e147f19384e42679512130cfc5f4d93364b.zip
Set version number to 0.5.99.5
2001-03-05 Jon Trowbridge <trow@gnu.org> * configure.in: Set version number to 0.5.99.5 * gal/e-text/e-entry.c (e_entry_class_init): Add a "popup" signal. If you have trepidations about this, see the technical argument below. (e_entry_init): Connect to the EText's popup signal. (e_entry_proxy_popup): Proxy emitter for popup signals from the EText. * gal/e-text/e-text.c (e_text_class_init): Added a "popup" signal. (e_text_event): Emit the "popup" signal on right-clicks. Now you could ask yourself: "should there be a signal named 'popup' in EText that gets emitted on right-clicks?" And this is a reasonable question, since... well, this has a funny feeling to it. But the whole point of GNOME, or at least one of the original points of GNOME, was to impose policy in a reasonable way when it made sense in order to simplify the user's experience. Convention dictates that popup menus are tied to right-clicks --- so rather than setting up some elaborate forwarding of button-press signals, why not just impose a little policy and set up a signal that is closely tied to a familiar set of semantics? Maybe it isn't the best thing to do from a aesthetics-of-the-API point of view, but I doubt anyone could condemn it as being anything more than mostly harmless. svn path=/trunk/; revision=8565
Diffstat (limited to 'widgets/text/e-text.h')
-rw-r--r--widgets/text/e-text.h9
1 files changed, 5 insertions, 4 deletions
diff --git a/widgets/text/e-text.h b/widgets/text/e-text.h
index 8ab6e33815..b42ea06663 100644
--- a/widgets/text/e-text.h
+++ b/widgets/text/e-text.h
@@ -1,8 +1,9 @@
/* -*- Mode: C; tab-width: 8; indent-tabs-mode: t; c-basic-offset: 8 -*- */
/* EText - Text item for evolution.
- * Copyright (C) 2000 Helix Code, Inc.
+ * Copyright (C) 2000, 2001 Ximian Inc.
*
- * Author: Chris Lahey <clahey@umich.edu>
+ * Author: Chris Lahey <clahey@ximian.com>
+ * Further hacking by Jon Trowbridge <trow@ximian.com>
*
* A majority of code taken from:
*
@@ -216,15 +217,15 @@ struct _EText {
struct _ETextClass {
GnomeCanvasItemClass parent_class;
- void (* changed) (EText *text);
+ void (* changed) (EText *text);
void (* activate) (EText *text);
+ void (* popup) (EText *text, GdkEventButton *ev, gint pos);
};
/* Standard Gtk function */
GtkType e_text_get_type (void);
-
END_GNOME_DECLS
#endif