Re: [xs] notebook problem

["muppet" <scott asofyet org>]

Joe Smith said:
> Of the things I like least about gtk, the top one is its verbosity.  I  mean
> it's really painful to read gtk code.  A good Perlish layer could  go a long
> way to alleviate that.

even with no sugar, the gtk-perl/gtk2-perl interface to Gtk+ is a *lot* less
verbose.  porting C apps to perl usually involves cutting out quite a lot of
the code.  no casting, no c-style list handling, no malloc/free, yadda yadda
yadda.

the gtk_widget_new (type, listofpropertiesandvalues...) interface was
implemented in both C and gtk-perl, and allowed you to create and initialize a
widget in one statement.  i personally prefer the itemized function calls
because they also work with my own objects (for which i never really bothered
creating object properties), but it should be rather easy to implement this.


> If it was a completely separate layer though, is to possible to
> transparently overlay, e.g., the 'notebook_append' function with a new
> (Perl) function of the same name?  If you can (and given enough magic  Perl
> can do *anything*), is it wise to do so?

some things are trivial; you can insert new functions into a package from
anywhere.

other things require deep changes or built-in support.  for example, if you
want to change the way arguments are handled in a function, you'll need to do
that in the code of that function, because when you declare a new one with the
same name, the old one goes away.  one solution for that is to declare the
actual workhorse and front-end separately, but that gets really ugly really
fast, and can lead to code bloat (which is already a danger).

for some of the API cleanup suggestions, i'm all for putting them directly
into the binding code if they are appropriate; however, i agree with ross that
for consistency, we should get the direct mapping complete, and *then* work on
the syntactic sugar.  if we do them as we go, we run the risk of having ten
competing ways of doing something, which, while perlish in spirit, is not good
for a project of this scope.


let's collect all these proposals someplace, and start putting them into
effect when the main interface stabilizes (in just a few weeks, at this rate).


-- 
muppet <scott asofyet org>