This is a side thread but I think some important issues are in question
On Thursday 15 February 2007 2:48 pm, Brian J. Tarricone wrote:
> Gerald I. Evenden wrote:
> > 2. A side thread suggested that in order to understand the usage of a
> > system like libglade one should study the source.
>
> I think that's pretty standard practice where any open source
> library/development system is concerned. Having full reference
> documentation, tutorials, etc. is great, but you can't expect them
> (unless you're willing to pay for them to be written, or write them
> yourself). Source code inspection is always an option.
This is not an option with me, especially with such a complex package as this.
It would take months to go over the source code and develop a rudimentary
understanding of all the entries and how they interrelate. If the only way
to use a package requires this option then I will deem it not ready for
prime-time and totally unusable.
> Note that I don't think there was much of a suggestion to inspect the
> libglade source; just that there are example programs (with source, of
> course) included in the libglade source tarball. Not really the same
> thing at all. Tristan (I think) even asked how these could be made more
> obvious/available, but didn't receive a decent reply AFAIK.
>
> > Hmmm. To use the C (or any
> > compiler) I should study the source code for the compiler???
>
> Bad analogy. A compiler is a user-space application. libglade is a
> library intended to be used by developers.
I do not understand your statement. How is using a compiler not a developer's
function?
> > To use the math library I should study the library's source??
>
> That's one of your options, yes. If you don't know the name of a
> particular function in the math library, seems to me that the fastest
> place to look would be /usr/include/math.h. Then you can look at a man
> page or other reference documentation, or, if needed, look at the .c
> file where the implementation is (I think this would be pretty rare).
I do not consider examining libm source a viable option for much of the same
reasons previously stated. I generally rely upon Harbison & Steele for all
my libm documentation mainly to ensure staying reasonably within acceptable
standards. Occasionally, a look at a man or info entry.
...
> > 3. Getting back to libglade. I have searched through many pages of
> > google to find either a decent reference and/or tutorial for libglade. A
> > couple of tutorials make halfway attempts but ultimately fail because
> > they have no reference manual to rely on---among other failings. Finding
> > a libglade reference manual is a total failure.
>
> Then that's your failure, not libglade's:
>
> http://developer.gnome.org/doc/API/2.0/libglade/index.html
>
> There's a very simple tutorial here:
> http://developer.gnome.org/doc/API/2.0/libglade/index.html
> ... which also includes instructions on how to link applications that
> use libglade.
>
> > There are a couple of sites which claim
> > to be a reference manual but I find them totally inadequate.
>
> Please explain why the site referenced above is inadequate.
I believe that much of the above and following issues are reasonably well
resolved but there are serious problems with the adequacy of some sections
(glib) but I will address these to a specific issue on a subsequent email
...
--
The whole religious complexion of the modern world is due
to the absence from Jerusalem of a lunatic asylum.
-- Havelock Ellis (1859-1939) British psychologist
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
