Re: get_maximized

[Emmanuele Bassi <ebassi gmail com>]

On Wed, 2006-09-06 at 13:31 -0700, Sergei Steshenko wrote:

> > On a technical note, using constant values a la the enum module was
> > impractical because we make use of glib / gobject / gtk+'s built-in lists of
> > enum to name mappings, which is where we get these string nicknames.  Without
> > that we would've had to maintain lists of enumeration values by hand, meaning
> > they'd always be wrong.  This practice was adopted by Gtk-Perl in about 1998,
> > iirc.
> >
> >
> > > I disagree with the claim that present implemetation leaves
> > > things like they are in gtk+ "C" - I believe it's the opposite.
> >
> > Note that i said it allows you to use a "C-ish" syntax, not same as in C.
> >
> > At any rate, you're just shy of three years too late (the overloads were
> > created in November of '03 by Marc Lehmann), and the current state of things
> > is part of an API-frozen stable release series and will not go away.

> 1) documentation on (gtk+ + friends) Perl bindings by itself is unsufficient
> to practically use the bindings;

To "technically use the bindings" you need the API reference plus the
Glib and Gtk2::api perldoc pages.

More tutorial-like stuff, like the gtk-perl tutorial and a ::Cookbook
perldoc page would be great, so please: write one and submit it for
review on this mailing list.

> 2) because of the above one has to look into gtk+ "C" documentation
> - at least, I had to do this many tines;

Me too.  It happens also on the other bindings *and*, when coding
directly in C, I often need to resort to the Glib/GTK+ sources.

Documentation, as you see, is a problem because there is not much people
writing it; you are welcome to try and improve the situation by writing
good documentation.

> 3) whenever Perl bindings differ from the original "C" it's a confusion
> for end user like myself, though I understand that Perl is not "C", so
> some differences are expected, like  structs will become hashes, all numeric
> types are essentially the same in Perl, etc.

Yes, and this matters in this situation because... ?

The operator overloading in this case makes things work for C coders
*and* for Perl coders; it's well documented in the Glib *and* Gtk2::api
page; there are examples of this usage.

I had to resort on my memory, and I wrote an example from memory without
even having to look at the documentation; the moment I tried, I skimmed
through it and made a mess - but the important things are: the API is
right and the documentation is right (and I'm sometimes a sloppy coder,
but this is known ;-)).

> I do not buy your argument about Perl programmers not knowing "C" because
> I myself learned "C" long before Perl :-).

I'm sorry, but you are an exception.

> Guys, when porting next things PLEASE try not to be oversmart, OK ?

I tried to remain calm for the best part of this email, and I'd like to
be able to keep it even now, when reading this makes my blood boil - and
not in a very figuratively manner of speech - so I'll say this once and
then I'll add you to the filter of my MUA.

This is the most insulting, petty, stupid and absurd phrase you ever
uttered both on this mailing list and on bugzilla entries opened by you
about your half-assed attempt to create a self-contained module
installation blindly ignoring all the Perl checks and balances and
settings, which showed me how little you know about the inner workings
of Perl and *nix.  The phrase above also shows how little respect you
pay to the people that have been working on the Gtk2 perl bindings in
the last three and a half years, on their free time, without being paid
a dime for them.

I would really like to hope that this is because, like myself, your
first language is not english; unfortunately, as I said, this comes
after your utter disregard of the work done by the gtk-perl team
developers that you have shown in the past on bugzilla and this mailing
list.

I'd expect an apology, but as of this moment I don't really care.

-- 
Emmanuele Bassi,  E: ebassi gmail com
W: http://www.emmanuelebassi.net
B: http://log.emmanuelebassi.net