File: ui-across-boundaries.txt

package info (click to toggle)
libbonoboui 2.24.5-4
  • links: PTS, VCS
  • area: main
  • in suites: stretch
  • size: 6,808 kB
  • ctags: 3,596
  • sloc: ansic: 30,221; sh: 10,256; xml: 599; makefile: 475
file content (153 lines) | stat: -rw-r--r-- 5,383 bytes parent folder | download | duplicates (6)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
                    ----------------------
                    U.I. Across Boundaries
                    ----------------------
                       Mark McLoughlin
                        mark@skynet.ie
                       Mon Oct 1st, 2001

	Perhaps the most compelling aspect of the Bonobo U.I. APIs is
the ability to use cross-process U.I. embedding - that is, to have a
U.I. component, managed by one process, visible in the window of
another process.

	Because Bonobo makes such a big deal of being built upon
CORBA, you would be forgiven for assuming that this bit of magic is
carried out solely using CORBA. That assumption is, in fact, untrue.
The magic - displaying the out of process widgets and proxying the
U.I. signals and events to the other process - is actually provided by
the GtkPlug/GtkSocket APIs and, ultimately the X11 windowing system
itself.

====================
GtPlug and GtkSocket
====================

	A GtkPlug wdget is a top-level window running in one
application which may be embedded in a GtkSocket widget running in
another application.

	These APIs are actually quite simple. One application creates
a GtkSocket and passes the XID of the wigets window to another
process which, in turn, creates a GtkPlug window using that XID.

	e.g. in the 'container' application:

---                                                             ---
	GtkWidget *socket = gtk_socket_new ();

	gtk_container_add (GTK_CONTAINER (parent), socket);

	app_transmit_xid (GDK_WINDOW_XWINDOW (socket->window));
---                                                             ---

	and in the 'component' application

---                                                             ---
	GtkWidget *window;
	guint32    xid = app_receive_xid ();

	window = gtk_plug_new (xid);

	gtk_container_add (GTK_CONTAINER (window), widgets);

	gtk_widget_show_all (window);
---                                                             ---

	The key here is how to communicate the XID between processes?
Any IPC mechanism will do. In the 'testsocket' program with gtk+ the
processes communicate via a UNIX domain socket. However, we could just
as easily use CORBA ...

	With Bonobo, we don't need to concern ourselves with
GtkPlug/Sockets - as you'd expect with Bonobo there is a beautiful,
clean and simple API we can use which abstracts away the complexities.
These are the BonoboControl and BonoboControlFrame APIs.

============
BonoboControl
============

	The BonoboControl API essentially provides a way to create a
GtkPlug which exports a widget of your choice. The really important
part, though, is that a BonoboControl also represents a CORBA object
which may be exported and made available to other applications on the
system.

---                                                             ---
	BonoboControl *control;
	GtkWidget     *widget;
	Bonobo_Unkown *corba_object;

	widget = app_create_widget ();
	gtk_widget_show (widget);

	control = bonobo_control_new (widget);

	corba_object = BONOBO_OBJREF (control);
---                                                             ---

	Usually, the BonoboControl CORBA object - or the
Bonobo_Control[1] object - would be exported using a Bonobo factory
which may be discovered by querying  the bonobo-activation server.
However, this need not always be the case.

==================
BonoboControlFrame
==================

	Just like BonoboControl is, conceptually, a wrapper for
GtkPlug, so then is BonoboControlFrame a wrapper for GtkSocket. Once
again though, a BonoboControlFrame is more than a mere wrapper for a
GtkSocket. It is also a CORBA object.

	Simliar to the way you add, or bind, a widget to a container,
you bind a BonoboControl to a BonoboControlFrame. It is at this point
that the control creates a GtkPlug using the GtkSocket's XID. The
control and control frame communicate using CORBA to make this happen.

---                                                             ---
	BonoboControlFrame *frame;
	GtkWidget          *frame_widget;

	frame = bonobo_control_frame_new (NULL);

	bonobo_control_frame_bind_to_control (frame, control);

	frame_widget = bonobo_control_frame_get_widget (frame);

	gtk_container_add (GTK_CONTAINER (container), frame_widget);

	gtk_widget_show (frame_widget);
---                                                             ---

	As simple as the API is to use, it could be simpler. And it
is. Enter BonoboWidget ...

============
BonoboWidget
============

	"Bonobo component embedding for hydrocephalic imbeciles"
			- Nat Friedman.

	To embed a control in our application, all we really need is a
GtkWidget representing the control to add to a GtkContainer. With the
BonoboWidget API, the one piece of information needed to obtain this
GtkWidget is a moniker that identifies the component.

---                                                             ---
	GtkWidget *widget;

	widget = bonobo_widget_new_control ("OAFIID:GNOME_myControl");

	gtk_container_add (GTK_CONTAINER (container), frame_widget);

	gtk_widget_show (frame_widget);
---                                                             ---

	I mean, really, could this be simpler?


[1] - Bonobo uses the convention that identifiers like BonoboControl
      represent the C wrapper object of a CORBA object and identifiers 
      like Bonobo_Control represent the actual CORBA object.