Re: libglade frustration redux

["Freddie Unpenstein" <fredderic excite com>]

> > Especially since glade is pushing the use of libglade as THE
> > way to incorporate glade-produced layouts into applications,
> > libglade should be packaged so as to encourage just that. Not
> > make it hard for application developers to figure out how to use
> > it. In any case, this is more an issue for the package maintainer,
> > than the author (assuming, of course, that they're different
> > people). If the author puts out a tarball of everything, then
> > it's the package maintainers job to divide it up appropriately.

> Sure, the maintainer of a package in gnome is typically one who
> releases the tarballs containing gnome software, other third
> parties might go creating self extracting executable zip files,
> rpms, debian packages etc... maybe the world might even converge
> towards some kind of standard one day.

Yes, I was using the wonderfully cushy world of Debian as an example.  But any distro that wants to be taken 
seriously should put some effort into how it packages its software offerings.  If you're going to pre-package 
a library software, it's common place to take a moment to sit back and consider at least those three basic 
use cases.  The people who use it indirectly, the people who use it directly, and the people who help develop 
it.


> Maybe in an ideal world the user of the libglade library (the user
> that wants api docs and header files) should have everything
> presented to him by a "distro" and on a silver platter - this is
> obviously not that world.

No, but there's no bad in wishing, is there?  Improving things starts with discussing them.  And while I see 
the merits in your standpoint that the end user should get off their arse and put some effort in too, the 
world isn't quite as simple as we'd all like.

Quite often I've been faced with an irritating and frustrating problem (no, I'm not going to go into a whole 
new off-topic discussion on better programming practices), and rather than going out and doing something the 
"right" way, I've done it the "familiar" way so I can stick with focusing on the problem at hand.  Even the 
best of us find ourselves in that situation occasionally, and clear and readily available documentation and 
examples can help reduce the barrier to doing it the "right" way rather than the (apparently) easy way.


> So you can chose a few things to do when your distro doesnt make
> the world clear to you:
> - Complain to the distro that they didnt give you what you think
> should have been provided

Essentially what I was getting at, for those in that position.  But for the rest of us, having the community 
of authors a little more aware of what to look out for when putting together their own pre-packaged releases, 
can only be a good thing.


> - Complain to the community of authors that they should have posted
> more documentation on websites (this typical approach is what I am
> complaining about myself...)

Whining and complaining without end, I agree, is just annoying.  However, within reason, it is fair to 
discuss what should and should/not be considered the "good practice" for pre-packaged software.  And if there 
is documentation, and there are good example files, then having those good example files easily and readily 
available with the documentation IS good practice, and IS worth discussing.

Software authors who don't wish to have to deal with the packaging of their software, can, of course, simply 
release it as a source-only tarball, with everything all thrown in for someone else to divide up.    


> - Be resourcefull and get the package from the authors directly so
> you know what really comes with the whole package, not what
> "someone said" the package should include or whatever joe blow
> decided to distribute.

This is all good and well...  And in this instance I too believe the OP had ample opportunity to do so.  My 
reply was intended to put forth specifically, a suggestion to hopefully help out those of us who find 
ourselves in the position of having to get something done without the luxury (for any number of reasons) of 
being able to spend a few hours searching on Google, or downloading and sifting through entire release 
tarballs.


> Surely we can agree that theres no point in asking the maintainers
> of the tarball to please give better documentation and examples, if
> you've never even looked at the tarball right ?

He shouldn't, but as a user of libglade who DID go and out figure out how to use it (I do still have some 
"best libglade practices" issues to figure out, though), I don't see why I can't back him up in so far as 
what I see as a good point.


Fredderic

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!