This file is indexed.

/usr/lib/x86_64-linux-gnu/perl5/5.20/Glib/Type.pod is in libglib-perl 3:1.305-2.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

  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
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
=head1 NAME

Glib::Type -  Utilities for dealing with the GLib Type system

=cut

=for position DESCRIPTION

=head1 DESCRIPTION

This package defines several utilities for dealing with the GLib type system
from Perl.  Because of some fundamental differences in how the GLib and Perl
type systems work, a fair amount of the binding magic leaks out, and you can
find most of that in the C<Glib::Type::register*> functions, which register
new types with the GLib type system.

Most of the rest of the functions provide introspection functionality, such as
listing properties and values and other cool stuff that is used mainly by
Glib's reference documentation generator (see L<Glib::GenPod>).

=cut



=for object Glib::Type Utilities for dealing with the GLib Type system

=for flags Glib::SignalFlags
=cut




=head1 METHODS

=head2 list = Glib::Type-E<gt>B<list_ancestors> ($package)

=over

=item * $package (string) 

=back


List the ancestry of I<package>, as seen by the GLib type system.  The
important difference is that GLib's type system implements only single
inheritance, whereas Perl's @ISA allows multiple inheritance.

This returns the package names of the ancestral types in reverse order, with
the root of the tree at the end of the list.

See also L<list_interfaces ()|/"list = Glib::Type-E<gt>B<list_interfaces> ($package)">.


=head2 list = Glib::Type-E<gt>B<list_interfaces> ($package)

=over

=item * $package (string) 

=back


List the GInterfaces implemented by the type associated with I<package>.
The interfaces are returned as package names.


=head2 list = Glib::Type-E<gt>B<list_signals> ($package)

=over

=item * $package (string) 

=back


List the signals associated with I<package>.  This lists only the signals
for I<package>, not any of its parents.  The signals are returned as a list
of anonymous hashes which mirror the GSignalQuery structure defined in the
C API reference.

=over

=item - signal_id

Numeric id of a signal.  It's rare that you'll need this in Gtk2-Perl.

=item - signal_name

Name of the signal, such as what you'd pass to C<signal_connect>.

=item - itype

The I<i>nstance I<type> for which this signal is defined.

=item - signal_flags

GSignalFlags describing this signal.

=item - return_type

The return type expected from handlers for this signal.  If undef or not
present, then no return is expected.  The type name is mapped to the 
corresponding Perl package name if it is known, otherwise you get the
raw C name straight from GLib.

=item - param_types

The types of the parameters passed to any callbacks connected to the emission
of this signal.  The list does not include the instance, which is always
first, and the user data from C<signal_connect>, which is always last (unless
the signal was connected with "swap", which swaps the instance and the data,
but you get the point).

=back


=head2 list = Glib::Type-E<gt>B<list_values> ($package)

=over

=item * $package (string) 

=back


List the legal values for the GEnum or GFlags type I<$package>.  If I<$package>
is not a package name registered with the bindings, this name is passed on to
g_type_from_name() to see if it's a registered flags or enum type that just
hasn't been registered with the bindings by C<gperl_register_fundamental()>
(see Glib::xsapi).  If I<$package> is not the name of an enum or flags type,
this function will croak.

Returns the values as a list of hashes, one hash for each value, containing
the value, name and nickname, eg. for Glib::SignalFlags

    { value => 8,
      name  => 'G_SIGNAL_NO_RECURSE',
      nick  => 'no-recurse'
    }


=head2 string = Glib::Type-E<gt>B<package_from_cname> ($cname)

=over

=item * $cname (string) 

=back


Convert a C type name to the corresponding Perl package name.  If no package
is registered to that type, returns I<$cname>. 


=head2 Glib::Type-E<gt>B<register> ($parent_class, $new_class, ...)

=over

=item * $parent_class (package) type from which to derive

=item * $new_class (package) name of new type

=item * ... (list) arguments for creation

=back

Register a new type with the GLib type system.

This is a traffic-cop function.  If I<$parent_type> derives from Glib::Object,
this passes the arguments through to C<register_object>.  If I<$parent_type>
is Glib::Flags or Glib::Enum, this strips I<$parent_type> and passes the
remaining args on to C<register_enum> or C<register_flags>.  See those
functions' documentation for more information.

=head2 Glib::Type->B<register_enum> ($name, ...)

=over

=item * $name (string) package name for new enum type

=item * ... (list) new enum's values; see description.

=back

Register and initialize a new Glib::Enum type with the provided "values".
This creates a type properly registered GLib so that it can be used for
property and signal parameter or return types created with
C<< Glib::Type->register >> or C<Glib::Object::Subclass>.

The list of values is used to create the "nicknames" that are used in general
Perl code; the actual numeric values used at the C level are automatically
assigned, starting with 1.  If you need to specify a particular numeric value
for a nick, use an array reference containing the nickname and the numeric
value, instead.  You may mix and match the two styles.

  Glib::Type->register_enum ('MyFoo::Bar',
          'value-one',            # assigned 1
          'value-two',            # assigned 2
          ['value-three' => 15 ], # explicit 15
          ['value-four' => 35 ],  # explicit 35
          'value-five',           # assigned 5
  );

If you use the array-ref form, beware: the code performs no validation
for unique values.

=head2 Glib::Type->B<register_flags> ($name, ...)

=over

=item * $name (string) package name of new flags type

=item * ... (list) flag values, see discussion.

=back

Register and initialize a new Glib::Flags type with the provided "values".
This creates a type properly registered GLib so that it can be used for
property and signal parameter or return types created with
C<< Glib::Type->register >> or C<Glib::Object::Subclass>.

The list of values is used to create the "nicknames" that are used in general
Perl code; the actual numeric values used at the C level are automatically
assigned, of the form 1<<i, starting with i = 0.  If you need to specify a
particular numeric value for a nick, use an array reference containing the
nickname and the numeric value, instead.  You may mix and match the two styles.

  Glib::Type->register_flags ('MyFoo::Baz',
           'value-one',               # assigned 1<<0
           'value-two',               # assigned 1<<1
           ['value-three' => 1<<10 ], # explicit 1<<10
           ['value-four' => 0x0f ],   # explicit 0x0f
           'value-five',              # assigned 1<<4
  );

If you use the array-ref form, beware: the code performs no validation
for unique values.

=head2 Glib::Type-E<gt>B<register_object> ($parent_package, $new_package, ...)

=over

=item * $parent_package (string) name of the parent package, which must be a derivative of Glib::Object.

=item * $new_package (string) usually __PACKAGE__.

=item * ... (list) key/value pairs controlling how the class is created.

=back





Register I<new_package> as an officially GLib-sanctioned derivative of
the (GObject derivative) I<parent_package>.  This automatically sets up
an @ISA entry for you, and creates a new GObjectClass under the hood.

The I<...> parameters are key/value pairs, currently supporting:

=over

=item signals => HASHREF

The C<signals> key contains a hash, keyed by signal names, which describes
how to set up the signals for I<new_package>.

If the value is a code reference, the named signal must exist somewhere in
I<parent_package> or its ancestry; the code reference will be used to 
override the class closure for that signal.  This is the officially sanctioned
way to override virtual methods on Glib::Objects.  The value may be a string
rather than a code reference, in which case the sub with that name in 
I<new_package> will be used.  (The function should not be inherited.)

If the value is a hash reference, the key will be the name of a new signal
created with the properties defined in the hash.  All of the properties
are optional, with defaults provided:

=over

=item class_closure => subroutine or undef

Use this code reference (or sub name) as the class closure (that is, the 
default handler for the signal).  If not specified, "do_I<signal_name>",
in the current package, is used.

=item return_type => package name or undef

Return type for the signal.  If not specified, then the signal has void return.

=item param_types => ARRAYREF

Reference to a list of parameter types (package names), I<omitting the instance
and user data>.  Callbacks connected to this signal will receive the instance
object as the first argument, followed by arguments with the types listed here,
and finally by any user data that was supplied when the callback was connected.
Not specifying this key is equivalent to supplying an empty list, which
actually means instance and maybe data.

=item flags => Glib::SignalFlags

Flags describing this signal's properties. See the GObject C API reference'
description of GSignalFlags for a complete description.

=item accumulator => subroutine or undef

The signal accumulator is a special callback that can be used to collect return
values of the various callbacks that are called during a signal emission.
Generally, you can omit this parameter; custom accumulators are used to do
things like stopping signal propagation by return value or creating a list of
returns, etc.  See L<Glib::Object::Subclass/SIGNALS> for details.

=back

=item properties => ARRAYREF

Array of Glib::ParamSpec objects, each describing an object property to add
to the new type.  These properties are available for use by all code that
can access the object, regardless of implementation language.  See
L<Glib::ParamSpec>.  This list may be empty; if it is not, the functions
C<GET_PROPERTY> and C<SET_PROPERTY> in I<$new_package> will be called to
get and set the values.  Note that an object property is just a mechanism
for getting and setting a value -- it implies no storage.  As a convenience,
however, Glib::Object provides fallbacks for GET_PROPERTY and SET_PROPERTY
which use the property nicknames as hash keys in the object variable for
storage.

Additionally, you may specify ParamSpecs as a describing hash instead of
as an object; this form allows you to supply explicit getter and setter
methods which override GET_PROPERY and SET_PROPERTY.  The getter and setter
are both optional in the hash form.  For example:

   Glib::Type->register_object ('Glib::Object', 'Foo',
      properties => [
         # specified normally
         Glib::ParamSpec->string (...),
         # specified explicitly
         {
            pspec => Glib::ParamSpec->int (...),
            set => sub {
               my ($object, $newval) = @_;
               ...
            },
            get => sub {
               my ($object) = @_;
               ...
               return $val;
            },
         },
      ]
   );

You can mix the two declaration styles as you like.  If you have
individual C<get_foo> / C<set_foo> methods with the operative code for
a property then the C<get>/C<set> form is a handy way to go straight
to that.

=item interfaces => ARRAYREF

Array of interface package names that the new object implements.  Interfaces
are the GObject way of doing multiple inheritance, thus, in Perl, the package
names will be prepended to @ISA and certain inheritable and overrideable
ALLCAPS methods will automatically be called whenever needed.  Which methods
exactly depends on the interface -- Gtk2::CellEditable for example uses
START_EDITING, EDITING_DONE, and REMOVE_WIDGET.

=back




=cut


=head1 SEE ALSO

L<Glib>


=cut


=head1 COPYRIGHT

Copyright (C) 2003-2011 by the gtk2-perl team.

This software is licensed under the LGPL.  See L<Glib> for a full notice.



=cut