Re: Gtk2::Gdk::Atom questions



ah, an excellent way to kill the last half an hour before i have to hit the
highway...  you'll find this stuff in two new files in CVS, xs/GdkProperty.xs
and xs/GdkSelection.xs, which means you'll need to do a complete rebuild.

take a crack at that and let me know if it works for you.


René Seindal said:
The usual terminology is intern(), but maybe there should be a new() alias
to maintain that convention.  I'd prefer writing "new
Gtk2::Gdk::Atom($name)".

i used both, and the defaults you suggested.


to get the name.  If the Gtk2::Gdk::Atom can be made as a real blessed
object, then it could be mapped as

    $name = $atom->name;

a blessed object in perl is merely a reference which has been blessed -- the
reference can be a reference to anything.

for the Atom, it's a reference to an integer value; the reference is there so
we can do type-checking, but it's also handy when you want to look up methods
on it.  so you can do either of

   Gtk2::Gdk::Atom::name ($atom)
   $atom->name


If possible I think Gtk2::Gdk::Atom should have an id() method that returns
that number, since it is perfect for comparisons.

you can get the id anytime you like simply by dereferencing the object. 
simple enough.  so you could implement a comparison function like this:

  sub Gtk2::Gdk::Atom::eq { ${$_[0]} == ${$_[1]} }

(i tried that, and it works)

but you don't have to; because i'm such a nice and helpful guy, i used an
overload for Gtk2::Gdk::Atom::eq (as implemented in XS to get type-checking)
so that you can just do

  print "atoms equal\n" if $atom1 == $atom2;


for those of you who didn't notice, this same trick has been applied to
GObjects for quite some time.


I don't know if it is worth it reproducing that in gtk2-perl-xs, since you
can simply do

    $type_string_atom = new Gtk2::Gdk::Atom('STRING');

though the Gdk way saves a round-trip to the X server.  The numbers are
well-defined by X11.  On my system the list is in
/usr/X11R6/include/X11/Xatom.h, but not all are equally interesting.

eh...  hmm.  i recall reading not too long ago about how Gtk is faster at
startup than Qt because Qt interns all the atoms at startup, but Gtk doesn't. 
or something strange like that.  anyway, it was something that left me with
the impression that round trips are worse than you think.

however, i'm not really sure what a clean way to do this would be.  the first
thing that comes to mind is

 GDK_SELECTION_PRIMARY   => Gtk2::Gdk->SELECTION_PRIMARY
 GDK_SELECTION_SECONDARY => Gtk2::Gdk->SELECTION_SECONDARY
 GDK_SELECTION_CLIPBOARD => Gtk2::Gdk->SELECTION_CLIPBOARD
 GDK_TARGET_BITMAP       => Gtk2::Gdk->TARGET_BITMAP
 ...

so that's what i did.  feel free to gripe.


The documentation for the above is at
http://developer.gnome.org/doc/API/2.0/gdk/gdk-Properties-and-Atoms.html

hmmmmm.... lots of functions defined in here that i'm not sure how to handle,
so they are commented out in xs/GdkProperty.xs....

and
http://developer.gnome.org/doc/API/2.0/gdk/gdk-Selections.html
(including predefined atoms)

you'll hate me for this, but from what i can tell most of the selection stuff
is class methods, not object methods.  i say that fundamentally because
there's a different thing passed as the first parameter to each, and the most
obvious target object, GdkWindow, may be NULL for one of them.  it's not often
that you can have NULL for a method's object.  (this was the same decision
process i used for the GtkDnd functions and several others.  i'm open to good
arguments to the contrary.)

on the other hand, i don't feel bad because the documentation says that most
users should use the GtkClipboard stuff instead.



I hope this explains it.

many thanks --- the documentation never gives you the same "just what you need
to know" high level rundown that an experienced human can.


-- 
muppet <scott at asofyet dot org>





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]