Enlightenment

On Fri, 10 Aug 2001 00:45:09 +0100 Tom Gilbert <tom@...> babbled
profusely:

> Imlib2 is unable to load any file with a ":" in the filename.
> 
> ":" is a perfectly valid filename character.
> 
> This is presumably due to the db loader?

yup. i'ts technically not really a bug - its a "documented feature". it's in the
documentation for imlib2 actually. ":" is a special char in a filename as far as
imlib2 is concerened - it's a delimiter between the filename and contents of a
file. the db loader uses it - but in theory any loader can. for example you
could use it to do

filename.tiff:2

to load the 2nd page of a tiff file (tiff files can do multi-page within the
same document) - the tiff loader doesn't impliment this though.. but it's
documented. :)

> Could this be changed somehow please, as I get numerous bug reports
> about it for feh and even I have some images of the form foo:648x480.jpg
> around.

i could possibly put in an escape method. like :: :) so  seeing you pass the
filename in, you coudl escape it if you know the : is not a delimiter.

> I had another thought - a user recently refused to install edb in order

why?

> to install imlib2 in order to use feh. I thought the idea of imlib2's
> dynamic loaders was that apps requiring special loaders could install
> them themselves. The db loader is only used by E17, but instead of E17

well thats is assuming that app also contains the loader src and it isnt shipped
with the base imlib2 dist - but to some extent, yes.

> building and installing loader_db.so, it is part of imlib2, and imlib2
> depends on edb for no reason I can see.

well... i could say the same thing abotu the rgba loader - no one uses it as i
put it in there as a simple example of a loader since it uses no libs and only
dumps the rgba data right to disk with a tiny header and loads it... but it's
there anyway. the only program i've seen that uses it is entice... anyway - the
reaosn this is here is because it has a lot of usefulness to it.

for example: a program can insall ALL its data it needs in a db - images, config
info, audio data etc. - you may choose not to - that's fine, but in many ways
its convenient to be abel to lump all fo the configuration for a program into 1
file and be able to swap it in and out - this way porgrams could do this. i did
write the db loader before i started on e17 :) efm uses it too (well did since
efm is now dead) :)

ewl uses it too actually :)

if the user refused to install, fankly - that's their problem. i'm baffled as to
why a user refuses to install a simple library that is a requirement of a
library that an app depends on if they wish to use that app. 

basically it's a policy reason. i made the jpg, png and db loaders requiremetns
of imlib2 for it to build - basically because 
1. i want some functional and useful loaders to start, 
2. i don't want to hear reports of people "it doesn't work" because the db
loader decided not to build and they can't read the instructions that state it
must be there. the same went for teh jpg and png loaders as i "assumed" these
woudl be some of the most common formats people will have.
3. the db loader is a good exmample of loading data from within a file (ie the
multi-page tiff) and thus is in the imlib2 dist and 
4. if they are REALLY keen they can always hack the configure scritps and stuff
to build wihtout edb - but this requires some level of knowledge. if you have
this level of knowledge you are free to do whatever you want - as you obviously
can dig a grave you are quite capable of digging yourself out of again... or i
expect that you are... though knowing my luck this assumption is completely
wrong and wil be shown to be in due course.

NB: the db loader is used by e17 and a whole heap of tools (etcher, ebony for
starters, and an unreleased image viewer called monacle that i wrote -
completely devoid of e17)

now if a user refuses to install a requirement - well - my position - tough
luck. what i would actually like to know iw why the hell they refused?

> Tom.
> -- 
>    .^.    .-------------------------------------------------------.
>    /V\    | Tom Gilbert, London, England | http://linuxbrit.co.uk |
>  /(   )\  | Open Source/UNIX consultant  | tom@...    |
>   ^^-^^   `-------------------------------------------------------'
> 
> _______________________________________________
> Enlightenment-devel mailing list
> Enlightenment-devel@...
> http://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@...     raster@...
VA Linux Systems                    raster@...
Mobile Phone: +61 (0)408 363 984    Work Phone: +61 (02) 9386 9362

Quoth Carsten Haitzler:
> > I had another thought - a user recently refused to install edb in order
> 
> why?

I'm sure they had a reason, even if it was silly.  IMHO imlib2 doesn't
need edb but I agree with your design decisions; however I think it
would be nice to see some optional autoconf flags such as --without-edb
or --without-png or --without-jpg.  Someone wishing to package imlib2
may, for some reason, not wish to have one or more of those default
loader formats.  (they may create 'imlib2' and 'imlib2-lite', who knows)

Also once the change is made regarding the ':' parsing it would be nice
to release new binary packages (Linux/ia32 at the very least) of edb and
imlib2.  *Build Wanker hat on*

Hmmm, with installable packages it should be possible to install imlib2
without edb, shouldn't it?  It'll just break the db loader but it won't
matter unless they try to load a db.  ;)

Andrew.

-- 
Andrew Shugg <andrew@...>                   http://www.neep.com.au/

"Just remember, Mr Fawlty, there's always someone worse off than yourself."
"Is there?  Well I'd like to meet him.  I could do with a good laugh."

On Fri, 10 Aug 2001 10:22:27 +0800 Andrew Shugg <andrew@...> babbled
profusely:

> Quoth Carsten Haitzler:
> > > I had another thought - a user recently refused to install edb in order
> > 
> > why?
> 
> I'm sure they had a reason, even if it was silly.  IMHO imlib2 doesn't
> need edb but I agree with your design decisions; however I think it
> would be nice to see some optional autoconf flags such as --without-edb
> or --without-png or --without-jpg.  Someone wishing to package imlib2
> may, for some reason, not wish to have one or more of those default
> loader formats.  (they may create 'imlib2' and 'imlib2-lite', who knows)

check imlib2's spec file. it makes eahc loader a separate package. admittedly
the main imlib2 package requires the jpg, db and png loaders, so it uses package
dependancies to "enforce" the policy.. BUT they are separate.. and if ia user is
silly they can --nodeps and --force install :)

anyway - i just dont want to make it too easy to dig your own grave so to
speak...

> Also once the change is made regarding the ':' parsing it would be nice
> to release new binary packages (Linux/ia32 at the very least) of edb and
> imlib2.  *Build Wanker hat on*

yup. don't need to release edb tho - it works. just imlib2. i have a 1.0.4
release planned real soon. i made a few fixes recently - and i'll throw this in
too. i also want to do 0.6 of evas as well.

> Hmmm, with installable packages it should be possible to install imlib2
> without edb, shouldn't it?  It'll just break the db loader but it won't
> matter unless they try to load a db.  ;)

as above- --nodeps --force CAN do it.. but i prefer to hint/poke at people that
its a stilly idea.

when enlightenemnt packages are out for e17 thei will have explicit requires for
the db loader and any other loader package they need - but i want to minimize
support/bug issues here. i'll probably write a test app that tests your imlib2
install and things to see if you have edb.. to see if it can actually load
images form db's etc/. and tell you if anythign fails - what failed, and tell
you to bugger off and fix these things that you decided to ignore in the
documentation.

anyway.. thats for later. right now i still think that it isnt a bad idea these
loader be inlucded by default. i dont really see too big a diff between a db and
a jpeg loader - both require libs outside of imlib2 (libjpeg, libpng.. edb ...)

> Andrew.
> 
> -- 
> Andrew Shugg <andrew@...>                   http://www.neep.com.au/
> 
> "Just remember, Mr Fawlty, there's always someone worse off than yourself."
> "Is there?  Well I'd like to meet him.  I could do with a good laugh."
> 
> _______________________________________________
> Enlightenment-devel mailing list
> Enlightenment-devel@...
> http://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@...     raster@...
VA Linux Systems                    raster@...
Mobile Phone: +61 (0)408 363 984    Work Phone: +61 (02) 9386 9362

On Friday, 10 August 2001, at 10:22:27 (+0800),
Andrew Shugg wrote:

> IMHO imlib2 doesn't need edb but I agree with your design decisions;

Well, I suppose that makes one of us.  The reality of the situation is
that there really is no good reason to make Imlib2 depend on any
loaders at all.  The whole point of loaders is that you have them or
you don't and Imlib2 doesn't care either way.

The RGBA loader would be a good candidate for an exception since it
doesn't depend on any external libraries.  However, the JPG, PNG, and
DB loaders should certainly not be required by Imlib2 itself.  That's
just silly.

The simple fact is that Imlib2 itself should not require any loaders
at all.  In fact, anyone who has actually tried to build and install
RPM's using Imlib2's spec file in CVS knows that it is chock full of
circular dependencies because of this very mistake.

The only things that should ever require particular loaders are
applications.  This is the very reason they're packaged separately, in
fact!  loader_db can require edb, and e17 can require loader_db in
addition to Imlib2 itself.  That's how dependencies work.  That's the
whole point of making packages and encouraging people to use them.

   mej@... ~/pics >> feh original/sphere.xcf 
   feh WARNING: original/sphere.xcf - No Imlib2 loader for that file
   format

See?  It's painfully obvious what the problem in loading the XCF image
is.  (Of course feh itself generates this message because Tom had the
foresight to write his own version of "imlib_strerror()" since Imlib2
neglected to provide one.  But that's not the point here.)  If e17 and
friends are smart enough to flag errors like this appropriately, users
will be less likely to say "it's broke!" and more likely to say "where
do I get a loader for XCF files?"

Of course, either way, raster's complaint argument simply doesn't hold
weight in the first place, because raster is almost never the first
one to answer a user's request for help, if he answers it at all.  And
many users come to #E with their questions anyway since the list is
subscriber-post only.

Sorry, but raster chose poorly on this one.  Tom is right; there's no
good reason for the imlib2 base package to require edb.  He made a
design decision based on the principle of keeping users from
bitching.  When you get right down to it, that's just wrong.  If you
don't want to answer a user's question, don't.  There are plenty of
people on this list who will.  That's a really shitty reason to make
an obviously misguided design choice.

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <mej@...>
Software Engineer, VA Linux Systems       Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
 "...in order to secure the safety of the public while traveling on
  public roads...it shall be unlawful for any person to drive, propel,
  or run any vehicle in, upon, and along any of the public roads in
  this county."             -- Montgomery County, Mississippi, statute

On Thu, 9 Aug 2001 20:14:41 -0700 Michael Jennings <mej@...>
babbled profusely:

> Sorry, but raster chose poorly on this one.  Tom is right; there's no
> good reason for the imlib2 base package to require edb.  He made a
> design decision based on the principle of keeping users from
> bitching.  When you get right down to it, that's just wrong.  If you
> don't want to answer a user's question, don't.  There are plenty of
> people on this list who will.  That's a really shitty reason to make
> an obviously misguided design choice.

it';s still a "policy" decision. none of the test programs in the demo dir of
imlib2 would work without png loaders at least.

as for imlib2 not providing a imlib_strerr - i did this for a VERY GOOD REASON.
internationalization. i don't think that imlib2 shoudl be handling .po files and
internationalized error messages. theats why it has enums and leaves it up to
the app calling it to deal with it. the only string errors in imlib2 are those
intended for developers to point out they missed somehting and catch it before
the app blows up and tell them.

anyway. it was a policy decision on my part - i think we might disagree on it,
but i guarantee its probably saves a lot of e-mail requests in the meantime
already.

anyway - it's a policy decision - some poele like it - some dont care, some hate
it. i'm willing to live with that. tho i do think tom's point of the ":" is a
valid one - i just never saw it as important to solve as i have not actually
ever seen a file paht with a ":" in it in unix yet -  but as tom said - he has
users who somehow seem to have files with ":" in them - so it might be worth
fixing somehow.

> Michael
> 
> -- 
> Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <mej@...>
> Software Engineer, VA Linux Systems       Author, Eterm (www.eterm.org)
> -----------------------------------------------------------------------
>  "...in order to secure the safety of the public while traveling on
>   public roads...it shall be unlawful for any person to drive, propel,
>   or run any vehicle in, upon, and along any of the public roads in
>   this county."             -- Montgomery County, Mississippi, statute
> 
> _______________________________________________
> Enlightenment-devel mailing list
> Enlightenment-devel@...
> http://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@...     raster@...
VA Linux Systems                    raster@...
Mobile Phone: +61 (0)408 363 984    Work Phone: +61 (02) 9386 9362

On Friday, 10 August 2001, at 13:40:48 (+1000),
Carsten Haitzler wrote:

> it';s still a "policy" decision.

No, it's a "design" decision.  I noticed that you didn't address any
of my actual points.  "My way or the highway" is generally a poor
stance for a project leader to take. :-)

> none of the test programs in the demo dir of imlib2 would work
> without png loaders at least.

So what?  Who cares about demos?  Is there an imlib2-demos package
nobody told me about? :)

The demos are only in CVS, and therefore are subject to the rules of
CVS.  Besides that, most modern distributions come with libpng already
installed.  Not too many (none besides RH-VALE, AFAIK) come with edb
already installed.

> as for imlib2 not providing a imlib_strerr - i did this for a VERY
> GOOD REASON.

Well, we can argue about that some also, I suppose. :)

> internationalization. i don't think that imlib2 shoudl be handling
> .po files and internationalized error messages. theats why it has
> enums and leaves it up to the app calling it to deal with it. the
> only string errors in imlib2 are those intended for developers to
> point out they missed somehting and catch it before the app blows up
> and tell them.

Oh, I see.  So you wanted to create a loading engine so that people
could write loaders, and you made sure to create example loaders so
that people would know how the mechanism worked.  And you wrote an
error return system, but didn't feel you could write an example
error-reporting function?  Hmmm, perhaps I missed something.... :-)

> anyway. it was a policy decision on my part - i think we might
> disagree on it, but i guarantee its probably saves a lot of e-mail
> requests in the meantime already.

And as I said, that's not a good reason to do something wrong.  It
takes no time flat to bounce a message from your inbox to the E list,
and it takes even less time to ignore a message sent to the E list.
You're always bitching about how you do all the work.  So let others
worry about user questions.  You should only be dealing with developer
questions.

> anyway - it's a policy decision - some poele like it - some dont
> care, some hate it. i'm willing to live with that.

I haven't heard anyone really back you up.  All I've heard is one
person (apparently blindly) saying "I agree," and that's it. :P  If
you can really justify your reasoning, then let's hear it.  Otherwise,
as the leader of an open source project, you have a responsibility to
listen to and address other people's concerns.

On the other hand, you can always say, "It's mine, so everybody fuck
off."  But then you can't complain about not getting any patches. :)

But you can't have it both ways.  Either this is a group effort and
you take into account everyone's feelings, or you do it yourself and
however you want to.  But if you want people to use your library for
their programs, you really ought to listen to their concerns. :)

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <mej@...>
Software Engineer, VA Linux Systems       Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
 "I believe God's grace is so incredible that He saves those who so
  much as grunt in His general direction, as long as it is from their
  heart."    -- Rick Durrance, Youth Pastor, Wilmore UMC (paraphrased)

On Thu, 9 Aug 2001 21:11:58 -0700 Michael Jennings <mej@...>
babbled profusely:

> On Friday, 10 August 2001, at 13:40:48 (+1000),
> Carsten Haitzler wrote:
> 
> > it';s still a "policy" decision.
> 
> No, it's a "design" decision.  I noticed that you didn't address any
> of my actual points.  "My way or the highway" is generally a poor
> stance for a project leader to take. :-)

no its policy. its not design. its a fewlines in configure.in that enforce the
policy - same withthe spec file.

as for the stance - yes i'm takign that on this. i don't see the benefit of
doing it your suggested way - i see only increased support issues.

> > none of the test programs in the demo dir of imlib2 would work
> > without png loaders at least.
> 
> So what?  Who cares about demos?  Is there an imlib2-demos package
> nobody told me about? :)

no ythere isn't. its in the src only. :)

> The demos are only in CVS, and therefore are subject to the rules of

actually no - they ship with the src tarball too.

> CVS.  Besides that, most modern distributions come with libpng already
> installed.  Not too many (none besides RH-VALE, AFAIK) come with edb
> already installed.

thats because anything requiring it outside edb isnt fully released yet or on a
dist. i dont see this as a valid excuse for not installing it "i'm a lazy bum
and dotn want to download 1 extra package" i dont see as a reason. if you were
saying "we have an embedded system with minimal resources and requiring edb is a
train on the storage space" i'd accept that. i haven't heard anyone say that. i
have seen numebrous mails before i implimented the "policy" about jpeg and png
images failing to work in the demos and in programs and peole didnt know why and
having to be told to "Read the output of your build - notice the "warning -
didnt find libjpg" and such. these went away quite a bit after said policy went
in.

> > as for imlib2 not providing a imlib_strerr - i did this for a VERY
> > GOOD REASON.
> 
> Well, we can argue about that some also, I suppose. :)

heheheh :)

> > internationalization. i don't think that imlib2 shoudl be handling
> > .po files and internationalized error messages. theats why it has
> > enums and leaves it up to the app calling it to deal with it. the
> > only string errors in imlib2 are those intended for developers to
> > point out they missed somehting and catch it before the app blows up
> > and tell them.
> 
> Oh, I see.  So you wanted to create a loading engine so that people
> could write loaders, and you made sure to create example loaders so
> that people would know how the mechanism worked.  And you wrote an
> error return system, but didn't feel you could write an example
> error-reporting function?  Hmmm, perhaps I missed something.... :-)

if (error == IMLIB_ERROR_WHATEVER) printf(_("imlib reckons: whatever!\n"));
ooh it's HAAARD
:)

no there is a difference in what they do and hwo they work. imho i think its
better off outside imlib's space to handle representing the error to a user
sensibly.

> > anyway. it was a policy decision on my part - i think we might
> > disagree on it, but i guarantee its probably saves a lot of e-mail
> > requests in the meantime already.
> 
> And as I said, that's not a good reason to do something wrong.  It
> takes no time flat to bounce a message from your inbox to the E list,
> and it takes even less time to ignore a message sent to the E list.
> You're always bitching about how you do all the work.  So let others
> worry about user questions.  You should only be dealing with developer
> questions.

i still dont see a good poin for dropping the policy. anyway. i can... but i'd
like GOOD arguments. sofar i havent seen any.

> > anyway - it's a policy decision - some poele like it - some dont
> > care, some hate it. i'm willing to live with that.
> 
> I haven't heard anyone really back you up.  All I've heard is one
> person (apparently blindly) saying "I agree," and that's it. :P  If
> you can really justify your reasoning, then let's hear it.  Otherwise,
> as the leader of an open source project, you have a responsibility to
> listen to and address other people's concerns.

leaders often say no. i know linus does regularly. often he doesnt say anything
other than "bad idea.". leaders don always just give in when someone says "lets
do this" or "i don't like this". what i want to hear is good reasons. tom has a
good point on the ":". i don't agree on the edb thing though.

> On the other hand, you can always say, "It's mine, so everybody fuck
> off."  But then you can't complain about not getting any patches. :)
> 
> But you can't have it both ways.  Either this is a group effort and
> you take into account everyone's feelings, or you do it yourself and
> however you want to.  But if you want people to use your library for
> their programs, you really ought to listen to their concerns. :)

see above. i am compromizing on the things he brought up - one i agree wiht, one
i don't. imlib2 is not requiring a lib that shard to find, that isnto open
source or thats hard to build or is immense. its convenient, an example, is used
by more than one program (db loading that is), and in including it as policy
saves hassles.

now.. what are practical points against having it required as policy?

thats what i want to know. i have conceeded the ":" thing - so don't sya its all
a "my way or the higway" thing - rememebr you don't have it all your way either.
being the guy who works on this mostly and writes and designs most of it... i
guess my decisions get to be defaults - unless there is a vERY good reaosn
otherwise AND you can convince me. tom convinced me that ignoring ":" as a
cahacter ever used in folenames was wrong and i should change the code to
acoomodate. that was an easy convince. the edb dependancy (and jpeg and png)
wont be as easy a convince. but try.


-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@...     raster@...
VA Linux Systems                    raster@...
Mobile Phone: +61 (0)408 363 984    Work Phone: +61 (02) 9386 9362

* Carsten Haitzler (raster@...) wrote:
> On Thu, 9 Aug 2001 21:11:58 -0700 Michael Jennings <mej@...>
> babbled profusely:
> as for the stance - yes i'm takign that on this. i don't see the benefit of
> doing it your suggested way - i see only increased support issues.

You're enforcing policy on the user, and like I said when you changed
the spec file to what it is now, you shouldn't enforce more policy on
the user than you need to, given that this project is all about user
independance from policy enforcement. :) That's kind of hypocritical.
It'd certainly be a lot easier if everyone had to use one theme, or one
kind of pointer rule, or one place to put the iconbox.. but those are
left to the user. We don't force users to install epplets. It's all
along the same lines from the user's perspective. :P

> > The demos are only in CVS, and therefore are subject to the rules of
> actually no - they ship with the src tarball too.

So? The demo directory only gets built if you go into the demo directory
and build it. If you're doing that, you should get yelled at if you
don't have libpng and the loader. :)

> thats because anything requiring it outside edb isnt fully released
> yet or on a dist. i dont see this as a valid excuse for not installing
> it "i'm a lazy bum and dotn want to download 1 extra package" i dont
> see as a reason. if you were saying "we have an embedded system with
> minimal resources and requiring edb is a train on the storage space"
> i'd accept that. i haven't heard anyone say that. i have seen
> numebrous mails before i implimented the "policy" about jpeg and png
> images failing to work in the demos and in programs and peole didnt
> know why and having to be told to "Read the output of your build -
> notice the "warning - didnt find libjpg" and such. these went away
> quite a bit after said policy went in.

If I just want to install imlib2, and I never want to see one of the db
files, I don't see why I should be forced to install edb. It's not a
matter of hard drive space, it's a matter of I don't need or want a copy
of it. It's my machine, and I never plan to use the loader, so why am I
installing stuff I don't want on there? That's absurd. No, actually,
it's compulsary. It reminds me of stuff Microsoft does. I install Office
and I get Outlook. I delete it and upgrade the OS patches. I get Outlook
(even if I tell it not to install it).

> > > internationalization. i don't think that imlib2 shoudl be handling
> > > .po files and internationalized error messages. theats why it has
> > > enums and leaves it up to the app calling it to deal with it. the
> > > only string errors in imlib2 are those intended for developers to
> > > point out they missed somehting and catch it before the app blows up
> > > and tell them.
> > Oh, I see.  So you wanted to create a loading engine so that people
> > could write loaders, and you made sure to create example loaders so
> > that people would know how the mechanism worked.  And you wrote an
> > error return system, but didn't feel you could write an example
> > error-reporting function?  Hmmm, perhaps I missed something.... :-)
> if (error == IMLIB_ERROR_WHATEVER) printf(_("imlib reckons: whatever!\n"));
> ooh it's HAAARD
> :)
> 
> no there is a difference in what they do and hwo they work. imho i think its
> better off outside imlib's space to handle representing the error to a user
> sensibly.

I don't see how that makes any sense.. imlib2 is going to know what
happened better than anything using it. You're saying that every user of
imlib2 is now forced to add a layer of abstraction between imlib2 and
their application to add stuff like error-checking, if not other things.
That's ludicrious. Why force everyone to duplicate work when you have
80% of the functionality already in the library?

If it's a time issue, ask Tom for his code. He's already apparently
written a well-functioning version.

> > And as I said, that's not a good reason to do something wrong.  It
> > takes no time flat to bounce a message from your inbox to the E list,
> > and it takes even less time to ignore a message sent to the E list.
> > You're always bitching about how you do all the work.  So let others
> > worry about user questions.  You should only be dealing with developer
> > questions.
> i still dont see a good poin for dropping the policy. anyway. i can... but i'd
> like GOOD arguments. sofar i havent seen any.

I'll take that up on irc.

> > On the other hand, you can always say, "It's mine, so everybody fuck
> > off."  But then you can't complain about not getting any patches. :)
> > 
> > But you can't have it both ways.  Either this is a group effort and
> > you take into account everyone's feelings, or you do it yourself and
> > however you want to.  But if you want people to use your library for
> > their programs, you really ought to listen to their concerns. :)
> see above. i am compromizing on the things he brought up - one i agree
> wiht, one i don't. imlib2 is not requiring a lib that shard to find,
> that isnto open source or thats hard to build or is immense. its
> convenient, an example, is used by more than one program (db loading
> that is), and in including it as policy saves hassles.
> 
> now.. what are practical points against having it required as policy?
> 
> thats what i want to know. i have conceeded the ":" thing

I don't see how fixing an obvious bug is conceeding anything. ;)

term

On Friday, 10 August 2001, at 14:37:54 (+1000),
Carsten Haitzler wrote:

> thats because anything requiring it outside edb isnt fully released
> yet or on a dist.

Actually, that is incorrect.  feh has been released several times.
Eterm 0.9.1 will be released very shortly.

> i dont see this as a valid excuse for not installing it "i'm a lazy
> bum and dotn want to download 1 extra package" i dont see as a
> reason.

Nobody ever said that was his reason.  That's what you've assumed his
reason to be.

Let's say someone wants to run Eterm 0.9.1 but not e17.  Under no
circumstances would Eterm ever load an image from a DB file since
nobody puts images in DB's besides e17 and friends.

Let's say someone objects to the Joint Photographers' Expert Group
(compares them to the RIAA, perhaps) and decides they'll only install
PNG's and PNG-based software.

Let's say all a person uses Imlib2 for is feh, and all this person
uses feh for is porn.  Everybody knows that porn is always GIF's and
JPG's.  So why would this person want a PNG loader?

Now damnit, raster, you can argue with Eterm, and you can argue with
zealots.  But you CANNOT ARGUE WITH PORN!  :-)

> i have seen numebrous mails before i implimented the "policy" about
> jpeg and png images failing to work in the demos and in programs and
> peole didnt know why and having to be told to "Read the output of
> your build - notice the "warning - didnt find libjpg" and
> such. these went away quite a bit after said policy went in.

Well, did any of these demos say, "Sorry, you don't have the PNG
loader?"  No?  Well, gee, I wonder why they had to ask what went
wrong.... :P

> if (error == IMLIB_ERROR_WHATEVER) printf(_("imlib reckons: whatever!\n"));
> ooh it's HAAARD
> :)

I didn't say it was hard.  I'm saying there was nothing stopping you
from writing an example, if not in the lib itself, then in the
demos. :)

> i still dont see a good poin for dropping the policy. anyway. i
> can... but i'd like GOOD arguments. sofar i havent seen any.

First off, it's wrong from a packaging standpoint.  You created a
circular dependency situation that even RPM barfs on.  I had to fix
this in order to get imlib2 into our load.  Imlib2 does *not* require
any loaders to be installed; that is a simple fact.  Arbitrary package
dependencies should not be added, especially when they create such a
messy situation.

Second, it's wrong from a technical point of view.  Imlib2 does not
link with any loader; the loaders are what require the base Imlib2.
Applications should require the loaders they need for proper
operation, or simply Imlib2 itself if they don't care.  This method
creates a proper dependency hierarchy.  Your way creates a dependency
nightmare.  If you don't believe me, draw it out with a pen and paper.

Third, because there's no good reason *not* to.  Others are willing to
do the work to make it happen, and you don't have to deal with cries
for help if you don't want to.  So it really shouldn't matter to you
either way, and since it does matter to others, the choice seems
obvious.

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <mej@...>
Software Engineer, VA Linux Systems       Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
 "I've been doing the Fonda workout:  the Peter Fonda workout.  That's
  where I wake up, take a hit of acid, smoke a joint, and go to my
  sister's house and ask her for money."               -- Kevin Meaney

On Fri, 10 Aug 2001 00:04:39 -0500 Lyle Kempler <term@...> babbled
profusely:

> * Carsten Haitzler (raster@...) wrote:
> > On Thu, 9 Aug 2001 21:11:58 -0700 Michael Jennings <mej@...>
> > babbled profusely:
> > as for the stance - yes i'm takign that on this. i don't see the benefit of
> > doing it your suggested way - i see only increased support issues.
> 
> You're enforcing policy on the user, and like I said when you changed

that is correct :)

> the spec file to what it is now, you shouldn't enforce more policy on
> the user than you need to, given that this project is all about user
> independance from policy enforcement. :) That's kind of hypocritical.

well... there are some things u need policy on :)

> It'd certainly be a lot easier if everyone had to use one theme, or one
> kind of pointer rule, or one place to put the iconbox.. but those are
> left to the user. We don't force users to install epplets. It's all
> along the same lines from the user's perspective. :P

they still will finally need edb all the same :)

> > > The demos are only in CVS, and therefore are subject to the rules of
> > actually no - they ship with the src tarball too.
> 
> So? The demo directory only gets built if you go into the demo directory
> and build it. If you're doing that, you should get yelled at if you
> don't have libpng and the loader. :)

true :)

> > thats because anything requiring it outside edb isnt fully released
> > yet or on a dist. i dont see this as a valid excuse for not installing
> > it "i'm a lazy bum and dotn want to download 1 extra package" i dont
> > see as a reason. if you were saying "we have an embedded system with
> > minimal resources and requiring edb is a train on the storage space"
> > i'd accept that. i haven't heard anyone say that. i have seen
> > numebrous mails before i implimented the "policy" about jpeg and png
> > images failing to work in the demos and in programs and peole didnt
> > know why and having to be told to "Read the output of your build -
> > notice the "warning - didnt find libjpg" and such. these went away
> > quite a bit after said policy went in.
> 
> If I just want to install imlib2, and I never want to see one of the db
> files, I don't see why I should be forced to install edb. It's not a
> matter of hard drive space, it's a matter of I don't need or want a copy
> of it. It's my machine, and I never plan to use the loader, so why am I
> installing stuff I don't want on there? That's absurd. No, actually,
> it's compulsary. It reminds me of stuff Microsoft does. I install Office
> and I get Outlook. I delete it and upgrade the OS patches. I get Outlook
> (even if I tell it not to install it).

hmm ok - i will concede on a few conditions:
1. someone breaks the db l,oader out of imlib2 cleanely and cleans up afterwards
and makes sure it builds probpelr afterwards
2. they put it elsewhere in cvs so it can build on its own
3. someone has to take blame for the support mail that will appear

> > > > internationalization. i don't think that imlib2 shoudl be handling
> > > > .po files and internationalized error messages. theats why it has
> > > > enums and leaves it up to the app calling it to deal with it. the
> > > > only string errors in imlib2 are those intended for developers to
> > > > point out they missed somehting and catch it before the app blows up
> > > > and tell them.
> > > Oh, I see.  So you wanted to create a loading engine so that people
> > > could write loaders, and you made sure to create example loaders so
> > > that people would know how the mechanism worked.  And you wrote an
> > > error return system, but didn't feel you could write an example
> > > error-reporting function?  Hmmm, perhaps I missed something.... :-)
> > if (error == IMLIB_ERROR_WHATEVER) printf(_("imlib reckons: whatever!\n"));
> > ooh it's HAAARD
> > :)
> > 
> > no there is a difference in what they do and hwo they work. imho i think its
> > better off outside imlib's space to handle representing the error to a user
> > sensibly.
> 
> I don't see how that makes any sense.. imlib2 is going to know what
> happened better than anything using it. You're saying that every user of
> imlib2 is now forced to add a layer of abstraction between imlib2 and
> their application to add stuff like error-checking, if not other things.
> That's ludicrious. Why force everyone to duplicate work when you have
> 80% of the functionality already in the library?

every app needs to do error checking - well its good if it does.. so they have
to do it anyway... and yes - as i expect each app may want to deal with and
present the error differently :) and the lib alerady tells u what the error
is... its just in enum form. i'm not in the mood to support N languages in
imlib2 - i still think internationalization is the land of the app, not the lib
:)

> If it's a time issue, ask Tom for his code. He's already apparently
> written a well-functioning version.
>
> > > And as I said, that's not a good reason to do something wrong.  It
> > > takes no time flat to bounce a message from your inbox to the E list,
> > > and it takes even less time to ignore a message sent to the E list.
> > > You're always bitching about how you do all the work.  So let others
> > > worry about user questions.  You should only be dealing with developer
> > > questions.
> > i still dont see a good poin for dropping the policy. anyway. i can... but
> i'd
> > like GOOD arguments. sofar i havent seen any.
> 
> I'll take that up on irc.
> 
> > > On the other hand, you can always say, "It's mine, so everybody fuck
> > > off."  But then you can't complain about not getting any patches. :)
> > > 
> > > But you can't have it both ways.  Either this is a group effort and
> > > you take into account everyone's feelings, or you do it yourself and
> > > however you want to.  But if you want people to use your library for
> > > their programs, you really ought to listen to their concerns. :)
> > see above. i am compromizing on the things he brought up - one i agree
> > wiht, one i don't. imlib2 is not requiring a lib that shard to find,
> > that isnto open source or thats hard to build or is immense. its
> > convenient, an example, is used by more than one program (db loading
> > that is), and in including it as policy saves hassles.
> > 
> > now.. what are practical points against having it required as policy?
> > 
> > thats what i want to know. i have conceeded the ":" thing
> 
> I don't see how fixing an obvious bug is conceeding anything. ;)

its not an oversight - its not a mistake - it was documented as a limitation -
theres a big difference.

> term
> 
> _______________________________________________
> Enlightenment-devel mailing list
> Enlightenment-devel@...
> http://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@...     raster@...
VA Linux Systems                    raster@...
Mobile Phone: +61 (0)408 363 984    Work Phone: +61 (02) 9386 9362

On Thu, 9 Aug 2001 22:30:07 -0700 Michael Jennings <mej@...>
babbled profusely:

> On Friday, 10 August 2001, at 14:37:54 (+1000),
> Carsten Haitzler wrote:
> 
> > thats because anything requiring it outside edb isnt fully released
> > yet or on a dist.
> 
> Actually, that is incorrect.  feh has been released several times.
> Eterm 0.9.1 will be released very shortly.

sorry - i meant anything outside e that requires edb... oops - anyway.

> > i dont see this as a valid excuse for not installing it "i'm a lazy
> > bum and dotn want to download 1 extra package" i dont see as a
> > reason.
> 
> Nobody ever said that was his reason.  That's what you've assumed his
> reason to be.

well i havent heard a reason.. i've just heard a "one user refused" which sounds
odd to me.

> Let's say someone wants to run Eterm 0.9.1 but not e17.  Under no
> circumstances would Eterm ever load an image from a DB file since
> nobody puts images in DB's besides e17 and friends.
> 
> Let's say someone objects to the Joint Photographers' Expert Group
> (compares them to the RIAA, perhaps) and decides they'll only install
> PNG's and PNG-based software.
> 
> Let's say all a person uses Imlib2 for is feh, and all this person
> uses feh for is porn.  Everybody knows that porn is always GIF's and
> JPG's.  So why would this person want a PNG loader?

true.

> Now damnit, raster, you can argue with Eterm, and you can argue with
> zealots.  But you CANNOT ARGUE WITH PORN!  :-)

ok. i conceed. porn wins. but someone else gets to do the work. i knwo theres
goign to be masses of bithcing abotu now having to donalod and compile and
install each loader separately... i just know it... and i've been doing htis for
a long time now... anyway.. someone else gets to get the support mail.

> > i have seen numebrous mails before i implimented the "policy" about
> > jpeg and png images failing to work in the demos and in programs and
> > peole didnt know why and having to be told to "Read the output of
> > your build - notice the "warning - didnt find libjpg" and
> > such. these went away quite a bit after said policy went in.
> 
> Well, did any of these demos say, "Sorry, you don't have the PNG
> loader?"  No?  Well, gee, I wonder why they had to ask what went
> wrong.... :P
> 
> > if (error == IMLIB_ERROR_WHATEVER) printf(_("imlib reckons: whatever!\n"));
> > ooh it's HAAARD
> > :)
> 
> I didn't say it was hard.  I'm saying there was nothing stopping you
> from writing an example, if not in the lib itself, then in the
> demos. :)

oh pfft :-P

> > i still dont see a good poin for dropping the policy. anyway. i
> > can... but i'd like GOOD arguments. sofar i havent seen any.
> 
> First off, it's wrong from a packaging standpoint.  You created a
> circular dependency situation that even RPM barfs on.  I had to fix
> this in order to get imlib2 into our load.  Imlib2 does *not* require
> any loaders to be installed; that is a simple fact.  Arbitrary package
> dependencies should not be added, especially when they create such a
> messy situation.
> 
> Second, it's wrong from a technical point of view.  Imlib2 does not
> link with any loader; the loaders are what require the base Imlib2.
> Applications should require the loaders they need for proper
> operation, or simply Imlib2 itself if they don't care.  This method
> creates a proper dependency hierarchy.  Your way creates a dependency
> nightmare.  If you don't believe me, draw it out with a pen and paper.

how about ascii art? i forgot how to draw :)

> Third, because there's no good reason *not* to.  Others are willing to
> do the work to make it happen, and you don't have to deal with cries
> for help if you don't want to.  So it really shouldn't matter to you
> either way, and since it does matter to others, the choice seems
> obvious.

see my other mail. someone esle gets to do the work. i won't do work for what i
am certain will cause me more work despite your arguments. if this gets rid of
these emails form my mailbox that sovles htis problem for now.. but suffice to
say if i at all start getting annoyed with the collection of people using and
installign imlib2 complaing of things not working because of this change.. the
policy is coming right back.

> Michael
> 
> -- 
> Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <mej@...>
> Software Engineer, VA Linux Systems       Author, Eterm (www.eterm.org)
> -----------------------------------------------------------------------
>  "I've been doing the Fonda workout:  the Peter Fonda workout.  That's
>   where I wake up, take a hit of acid, smoke a joint, and go to my
>   sister's house and ask her for money."               -- Kevin Meaney
> 
> _______________________________________________
> Enlightenment-devel mailing list
> Enlightenment-devel@...
> http://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@...     raster@...
VA Linux Systems                    raster@...
Mobile Phone: +61 (0)408 363 984    Work Phone: +61 (02) 9386 9362

Michael Jennings wrote:

 >--snip
 >
 >Let's say all a person uses Imlib2 for is feh, and all this person
 >uses feh for is porn.  Everybody knows that porn is always GIF's and
 >JPG's.  So why would this person want a PNG loader?
 >
 >Now damnit, raster, you can argue with Eterm, and you can argue with
 >zealots.  But you CANNOT ARGUE WITH PORN!  :-)
 >

In intensive daily testing, over a long period of time, I can confirm
that that imlib2/feh pr0n delivery sytem is the most rocking thing on
the planet. It kicks that gnome pixbuf thing in the butt and then drags
it around the block. Png has yet to gain a foothold in this field, but
when it does, I'll be ready!

Dumb humor and present squables aside, I've wanted to say thanks for
both for a long time.

Jonathan Moran

Quoth Michael Jennings:
> > IMHO imlib2 doesn't need edb but I agree with your design decisions;
> 
> Well, I suppose that makes one of us.

Poor choice of words.  s/agree with/accept/  =)

> The only things that should ever require particular loaders are
> applications.  This is the very reason they're packaged separately, in
> fact!  loader_db can require edb, and e17 can require loader_db in
> addition to Imlib2 itself.  That's how dependencies work.  That's the
> whole point of making packages and encouraging people to use them.

I wasn't aware of how the loaders were packages separately (I'm not an 
RPM man) but this heirarchical dependencies sounds like the "right" way
to do it.

(wonders if I'm going to agree with anyone else's opinions today)

Andrew.

-- 
Andrew Shugg <andrew@...>                   http://www.neep.com.au/

"Just remember, Mr Fawlty, there's always someone worse off than yourself."
"Is there?  Well I'd like to meet him.  I could do with a good laugh."

On Fri, 10 Aug 2001 13:47:36 +0800, Andrew Shugg <andrew@...>  said:

> I wasn't aware of how the loaders were packages separately (I'm not an 
> RPM man) but this heirarchical dependencies sounds like the "right" way
> to do it.

You need to do it that way, or you will be in for fun if an upgrade is ever
needed.  Anybody installed the new RedHat RPMS's for OpenSSL 096b?  The
ones you can't just 'rpm -Fv' into place, you need to 'rpm -e' one thing,
then install another, THEN install the compat lib, then finally rpm -Fv the
rest into place?  They did it with a few other things in recent Rawhide's
as well.

I'll leave answering THOSE support questions to the person who created the
circular dependencies. ;)

And also, the easiest way to avoid creeping dependencies is to be careful
what you list as dependencies.  Did anybody ELSE out there start cursing
when the newer RawHide RPMs for SDL suddenly required you to install
almost ALL of 'arts' too?
-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

On Fri, 10 Aug 2001 02:45:48 -0400 Valdis.Kletnieks@... babbled profusely:

> On Fri, 10 Aug 2001 13:47:36 +0800, Andrew Shugg <andrew@...>  said:
> 
> > I wasn't aware of how the loaders were packages separately (I'm not an 
> > RPM man) but this heirarchical dependencies sounds like the "right" way
> > to do it.
> 
> You need to do it that way, or you will be in for fun if an upgrade is ever
> needed.  Anybody installed the new RedHat RPMS's for OpenSSL 096b?  The
> ones you can't just 'rpm -Fv' into place, you need to 'rpm -e' one thing,
> then install another, THEN install the compat lib, then finally rpm -Fv the
> rest into place?  They did it with a few other things in recent Rawhide's
> as well.
> 
> I'll leave answering THOSE support questions to the person who created the
> circular dependencies. ;)

easy. rpm -hUV imlib2-*rpm.
do it on 1 line with all the packages and circular/interdependancies are
auto-resolved for you. it's no problem actually :)

> And also, the easiest way to avoid creeping dependencies is to be careful
> what you list as dependencies.  Did anybody ELSE out there start cursing
> when the newer RawHide RPMs for SDL suddenly required you to install
> almost ALL of 'arts' too?
> -- 
> 				Valdis Kletnieks
> 				Operating Systems Analyst
> 				Virginia Tech
> 
> 


-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@...     raster@...
VA Linux Systems                    raster@...
Mobile Phone: +61 (0)408 363 984    Work Phone: +61 (02) 9386 9362

* Carsten Haitzler (raster@...) wrote:
> hmm ok - i will concede on a few conditions:
> 1. someone breaks the db l,oader out of imlib2 cleanely and cleans up afterwards
> and makes sure it builds probpelr afterwards
> 2. they put it elsewhere in cvs so it can build on its own
> 3. someone has to take blame for the support mail that will appear

Sure I'll do it.

Tom.
-- 
   .^.    .-------------------------------------------------------.
   /V\    | Tom Gilbert, London, England | http://linuxbrit.co.uk |
 /(   )\  | Open Source/UNIX consultant  | tom@...    |
  ^^-^^   `-------------------------------------------------------'

On Fri, 10 Aug 2001 09:13:13 +0100 Tom Gilbert <tom@...> babbled
profusely:

> * Carsten Haitzler (raster@...) wrote:
> > hmm ok - i will concede on a few conditions:
> > 1. someone breaks the db l,oader out of imlib2 cleanely and cleans up
> afterwards
> > and makes sure it builds probpelr afterwards
> > 2. they put it elsewhere in cvs so it can build on its own
> > 3. someone has to take blame for the support mail that will appear

cool. thanks :)

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@...     raster@...
VA Linux Systems                    raster@...
Mobile Phone: +61 (0)408 363 984    Work Phone: +61 (02) 9386 9362

On Friday, 10 August 2001, at 17:03:01 (+1000),
Carsten Haitzler wrote:

> easy. rpm -hUV imlib2-*rpm.  do it on 1 line with all the packages
> and circular/interdependancies are auto-resolved for you. it's no
> problem actually :)

You'd think that, but what actually happens is that rpm's dependency
checker gets into a loop and bails out.  But not without spewing forth
a large quantity of goop first.  If that hadn't happened, I would
never have had to fix the spec file for our load. :)

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <mej@...>
Software Engineer, VA Linux Systems       Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
 "Narrow is the road and too high a price to pay when loneliness is
  such a sanctuary.  Empty are the musings and wasted are the days
  when you say you were only waiting."
                                  -- Jars of Clay, "Famous Last Words"

"Carsten Haitzler (The Rasterman)" wrote:
> 
> now.. what are practical points against having it required as policy?

Alright, I guess I'm a bit late here, but ... frankly I think that
there's absolutely no reason to enforce any loader on a user. The db
loader *is* fairly exotic, our apps use it, but that doesn't make it in
any way comparable to jpg or png loaders. When an app depends on a
loader, make the loader a requirement of the app, and the loader depend
on whatever it needs to do its job, just as Michael said.

I guess it's a fact that the average Linux installation contains a
shitload of stuff the user never touches. Most people say "Right, and so
our little lib here and app there don't make a difference". No need to
add to that habit. If a user is sure that she doesn't want edb, then why
enforce it? 

"Carsten Haitzler (raster@...)" wrote:
> hmm ok - i will concede on a few conditions:
> 1. someone breaks the db l,oader out of imlib2 cleanely and cleans up afterwards
> and makes sure it builds probpelr afterwards
> 2. they put it elsewhere in cvs so it can build on its own
> 3. someone has to take blame for the support mail that will appear

Why are 1+2 necessary? Just remove the requirements from the packaging
files and the requirement checks from configure.in?

-- Christian.
________________________________________________________________________
                                                    http://www.whoop.org

> * Carsten Haitzler (raster@...) wrote:
> > hmm ok - i will concede on a few conditions:
> > 1. someone breaks the db l,oader out of imlib2 cleanely and cleans up afterwards
> > and makes sure it builds probpelr afterwards
> > 2. they put it elsewhere in cvs so it can build on its own
> > 3. someone has to take blame for the support mail that will appear
> Sure I'll do it.
> Tom.
There you go, Toms doing it :)
As for point 3 - I'm sure term said he wouldn't mind taking the blame
for support emails. On a real point though remember that there is a
small team of people for E17 who have been given the area of responsability
for Docs/FAQs. Just just an added thought. Why don't we actally publicly
kind of state it as a user support network as well. Basically along the
lines of "Read the Docs/FAQs first, and if (and only if) you don't find
it in there there try the list/sourceforge forems/or email these
sepecific people." but also make it clear that stupid question will be
ignored.

There we go - my neck is now on the chopping block, feel free to drop
the guliteen :P

 - Hendryx

* Carsten Haitzler (raster@...) wrote:
> > nightmare.  If you don't believe me, draw it out with a pen and paper.
> how about ascii art? i forgot how to draw :)
Hey - leave ascii art out of this discussion :)
Some of us less talented people like drawing pritty
pictures with ascii text. I mean how really needs color anyhow!! :PP

 - Hendryx, One sleep deprived loon!

On Thu, Aug 09, 2001 at 10:30:07PM -0700, Michael Jennings wrote:
> Let's say all a person uses Imlib2 for is feh, and all this person
> uses feh for is porn.  Everybody knows that porn is always GIF's and
> JPG's.  So why would this person want a PNG loader?
>=20
> Now damnit, raster, you can argue with Eterm, and you can argue with
> zealots.  But you CANNOT ARGUE WITH PORN!  :-)

See, but if they were supplying porn in png format, we could have nice
antialiased against transparency women.  *sigh*

--=20
Mandrake       | http://mandrake.net
Cepstral, LLC  | http://www.cepstral.com
public key     | http://mandrake.net/publickey

* Carsten Haitzler (raster@...) wrote:
> On Fri, 10 Aug 2001 00:04:39 -0500 Lyle Kempler <term@...>
> babbled profusely:
> > I don't see how that makes any sense.. imlib2 is going to know what
> > happened better than anything using it. You're saying that every
> > user of imlib2 is now forced to add a layer of abstraction between
> > imlib2 and their application to add stuff like error-checking, if
> > not other things.  That's ludicrious. Why force everyone to
> > duplicate work when you have 80% of the functionality already in the
> > library?
> every app needs to do error checking - well its good if it does.. so
> they have to do it anyway... and yes - as i expect each app may want
> to deal with and present the error differently :) and the lib alerady
> tells u what the error is... its just in enum form. i'm not in the
> mood to support N languages in imlib2 - i still think
> internationalization is the land of the app, not the lib :)

If someone wants to provide more information than the library's
strerror() equivalent function provides, then they can cut and paste the
original and hack it up. But the original should be provided. And I
think a lot of people will go with the standard strerror() call to get
the string version of what happened (e.g., an app brings up an error
information window, but still would want imlib_strerror() to find out
the error).

> > > thats what i want to know. i have conceeded the ":" thing
> > I don't see how fixing an obvious bug is conceeding anything. ;)
> its not an oversight - its not a mistake - it was documented as a limitation -
> theres a big difference.

Semantics. :P Though documenting a 'limitation' to me that interferes
with normal usage is still something wrong in the implementation or
design.. but anyway. :)

term

* Hendryx (winterlight@...) wrote:
> > * Carsten Haitzler (raster@...) wrote:
> > > 3. someone has to take blame for the support mail that will appear
> As for point 3 - I'm sure term said he wouldn't mind taking the blame
> for support emails.

I don't have a problem with that, like I said on irc, I know how to use
procmail.

> On a real point though remember that there is a
> small team of people for E17 who have been given the area of responsability
> for Docs/FAQs. Just just an added thought. Why don't we actally publicly
> kind of state it as a user support network as well. Basically along the
> lines of "Read the Docs/FAQs first, and if (and only if) you don't find
> it in there there try the list/sourceforge forems/or email these
> sepecific people." but also make it clear that stupid question will be
> ignored.

If you want to create a page that assigns people to be the first contact
person for a problem with a library or application, go right ahead
(though obviously clear it with each of the people first). Make sure
they can answer the questions though. :)

While I'm talking about this sort of thing, I also want to get E16
documentation/info on the site. E17 is under development, and so we
should have E16 documentation at the forefront -- if anyone has any from
previous days, or has some they've written, let me know -- we want to
include it or link to it.

term

* Valdis.Kletnieks@... (Valdis.Kletnieks@...) wrote:
> And also, the easiest way to avoid creeping dependencies is to be careful
> what you list as dependencies.  Did anybody ELSE out there start cursing
> when the newer RawHide RPMs for SDL suddenly required you to install
> almost ALL of 'arts' too?

Hah, the copy of xmms I'm fighting with right now on my sparcstation has
the same problem (assumes arts is installed). ;)

term

On Fri, Aug 10, 2001 at 10:40:20AM -0500, Lyle Kempler wrote:
> While I'm talking about this sort of thing, I also want to get E16
> documentation/info on the site. E17 is under development, and so we
> should have E16 documentation at the forefront -- if anyone has any from
> previous days, or has some they've written, let me know -- we want to
> include it or link to it.

There is a ton of documentation on e16.  Middle click on the desktop, select
'Help', and start reading.
Feel free to hack it up into html however you see fit.  There is also a man
page (type 'man enlightenment')

--=20
Mandrake       | http://mandrake.net
Cepstral, LLC  | http://www.cepstral.com
public key     | http://mandrake.net/publickey

On Fri, 10 Aug 2001 10:41:00 CDT, Lyle Kempler <term@...>  said:

> Hah, the copy of xmms I'm fighting with right now on my sparcstation has
> the same problem (assumes arts is installed). ;)

Did you like how the problem is a visualisation plug-in that calls SDL
to do *graphics*, and then SDL wants 'arts' assumed? ;)

/Valdis

* Carsten Haitzler (raster@...) wrote:
> well i havent heard a reason.. i've just heard a "one user refused" which sounds
> odd to me.

Well the reason shouldn't matter, it's his machine and a non-existant
dependancy should not be enforced upon him.

I'll give you the context of the discussion tho.

I was showing a friend of mine feh. He is extremely clueful and a
talented coder. He said "cool, I'll install it on my machine and play".
Cool, good stuff. But then he started following the dependancy tree.

him: "imlib2 eh?"
me:  "yeah I use it for loading/rendering"
him: "ah cool."
him: "er, edb?"
me:  "er... imlib2 wants it"
him: "why?"
me:  "because e17 uses it"
him: "um..."
me:  *embarrassed look.
him: "let me get this straight. Library A depends on Library B because
     app A which uses Library A, requires Library B".
me:  *frown "yes."
him: "nothanks".

Please let me fix this.

Tom.
-- 
   .^.    .-------------------------------------------------------.
   /V\    | Tom Gilbert, London, England | http://linuxbrit.co.uk |
 /(   )\  | Open Source/UNIX consultant  | tom@...    |
  ^^-^^   `-------------------------------------------------------'

* Mandrake (Geoff Harrison) (mandrake@...) wrote:
> On Fri, Aug 10, 2001 at 10:40:20AM -0500, Lyle Kempler wrote:
> > While I'm talking about this sort of thing, I also want to get E16
> > documentation/info on the site. E17 is under development, and so we
> > should have E16 documentation at the forefront -- if anyone has any from
> > previous days, or has some they've written, let me know -- we want to
> > include it or link to it.
> There is a ton of documentation on e16.  Middle click on the desktop, select
> 'Help', and start reading.
> Feel free to hack it up into html however you see fit.  There is also a man
> page (type 'man enlightenment')

That doesn't tell you how to make a theme, or how to work with or create
epplets, and those sorts of things. It's much more than a user's guide,
though I think we should htmlize that stuff and toss it up.

term

* Valdis.Kletnieks@... (Valdis.Kletnieks@...) wrote:
> On Fri, 10 Aug 2001 10:41:00 CDT, Lyle Kempler <term@...>  said:
> > Hah, the copy of xmms I'm fighting with right now on my sparcstation has
> > the same problem (assumes arts is installed). ;)
> Did you like how the problem is a visualisation plug-in that calls SDL
> to do *graphics*, and then SDL wants 'arts' assumed? ;)

Just another reason I'm using debian at home (I know rpm really well so
I installed it for use at work). :)

term

* Tom Gilbert (tom@...) wrote:
> * Carsten Haitzler (raster@...) wrote:
> > well i havent heard a reason.. i've just heard a "one user
> > refused" which sounds odd to me. 
> 
> Well the reason shouldn't matter, it's his machine and a non-existant
> dependancy should not be enforced upon him.
> 
> I'll give you the context of the discussion tho.
> 
> I was showing a friend of mine feh. He is extremely clueful and a
> talented coder. He said "cool, I'll install it on my machine and play".
> Cool, good stuff. But then he started following the dependancy tree.

Ok, From watching this thread I've come up with an idea or two. It
seems to me Raster's complaint is that he wants the e17,
ebony... configure scripts to fail when there's no edb loader for
Imlib2, his method for doing this was to force Imlib2 to not build or
install without the edb loader, and then just check for Imlib2. It's
the easiest way to get what he wants, and there's something to be said
for being lazy. Now this method has become a problem, for reasons
already stated. I sugest the best way to handle this is to have a
method for checking to see if a specific loader is installed. I'm
personally not very familiar with GNU Autoconf, but I do have a
general idea of what it does, and it seems to me that checking for the
existance of a library is what it was designed for. Now I figure that
it's probably not an easy task, or that would have been Rasters first
choice, but Maybe we could write an autoconf macro that can test for a
Imlib2 loader of a certan type and maybe even of a certian
version. That way you can keep all the loaders you want in the Imlib2
distrobution and just warn if none of them are being built.
-Ted

ps sorry if this seems a little scattered, but I'm at work, and kept
being interrupted by my boss.

* Ted Nitz (tnitz@...) wrote:
> Ok, From watching this thread I've come up with an idea or two. It
> seems to me Raster's complaint is that he wants the e17,
> ebony... configure scripts to fail when there's no edb loader for
> Imlib2, his method for doing this was to force Imlib2 to not build or
> install without the edb loader, and then just check for Imlib2. It's
> the easiest way to get what he wants, and there's something to be said
> for being lazy. Now this method has become a problem, for reasons
> already stated. I sugest the best way to handle this is to have a
> method for checking to see if a specific loader is installed. I'm
> personally not very familiar with GNU Autoconf, but I do have a
> general idea of what it does, and it seems to me that checking for the
> existance of a library is what it was designed for. Now I figure that
> it's probably not an easy task, or that would have been Rasters first
> choice, but Maybe we could write an autoconf macro that can test for a
> Imlib2 loader of a certan type and maybe even of a certian
> version. That way you can keep all the loaders you want in the Imlib2
> distrobution and just warn if none of them are being built.
> -Ted

I agree, and I will write such a macro when I move the db loader out
into it's own module. Just a teeny weeny C program to try and load a db
image, and die if it can't.

Cheers,

Tom.
-- 
   .^.    .-------------------------------------------------------.
   /V\    | Tom Gilbert, London, England | http://linuxbrit.co.uk |
 /(   )\  | Open Source/UNIX consultant  | tom@...    |
  ^^-^^   `-------------------------------------------------------'

On Fri, 10 Aug 2001 19:53:40 BST, Tom Gilbert <tom@...>  said:

> I agree, and I will write such a macro when I move the db loader out
> into it's own module. Just a teeny weeny C program to try and load a db
> image, and die if it can't.

Should be sufficient to just supply an AC_TRY() for the load function.  Not
much else in Autoconf checks for the function *working*, merely for the
presence of the function.

-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

* Valdis.Kletnieks@... (Valdis.Kletnieks@...) wrote:
> On Fri, 10 Aug 2001 19:53:40 BST, Tom Gilbert <tom@...>  said:
> 
> > I agree, and I will write such a macro when I move the db loader out
> > into it's own module. Just a teeny weeny C program to try and load a db
> > image, and die if it can't.
> 
> Should be sufficient to just supply an AC_TRY() for the load function.  Not
> much else in Autoconf checks for the function *working*, merely for the
> presence of the function.

I don't think that is congruous with the way imlib2 loaders work. They
all have the same function, load(), you can only see if you have a
loader for a file format by trying to read the file. Unless I missed
something.

Autoconf does let you (or so I thought) provide test programs (or code
snippets) to test for specific things.

Tom.
-- 
   .^.    .-------------------------------------------------------.
   /V\    | Tom Gilbert, London, England | http://linuxbrit.co.uk |
 /(   )\  | Open Source/UNIX consultant  | tom@...    |
  ^^-^^   `-------------------------------------------------------'

what about moving the db loader from imlib2 to edb, this way when ppl
install imlib2 they don't get the db loader. plus if they want to use the
db loader then they'll need edb as well. just have edb's config check for
imlib2, if imlib2 isn't there, then the loader isn't buit and installed.
besides, you woun't need the loader unless you have edb, and you wount
need the loader unless you have imlib2.

hopefully i didn't confuse anyone here.

-SLS- (SouLShadow)
  soul@...
    http://www.soulshadow.net

* soul (soul@...) wrote:
> what about moving the db loader from imlib2 to edb, this way when ppl
> install imlib2 they don't get the db loader. plus if they want to use the
> db loader then they'll need edb as well. just have edb's config check for
> imlib2, if imlib2 isn't there, then the loader isn't buit and installed.
> besides, you woun't need the loader unless you have edb, and you wount
> need the loader unless you have imlib2.

That's not how dependancies should work.

The application that requires the functionality should depend on the
library that provides it. Therefore e17 should depend on loader_db, and
loader_db should depend on edb.

But I guess we can live with what we have now. I would rather have the
loader split out, but so long as it isn't _required_, I can deal.

Tom.
-- 
   .^.    .-------------------------------------------------------.
   /V\    | Tom Gilbert, London, England | http://linuxbrit.co.uk |
 /(   )\  | Open Source/UNIX consultant  | tom@...    |
  ^^-^^   `-------------------------------------------------------'

On Fri, 10 Aug 2001 13:31:19 +0200 Christian Kreibich
<kreibich@...> babbled profusely:

> "Carsten Haitzler (The Rasterman)" wrote:
> > 
> > now.. what are practical points against having it required as policy?
> 
> Alright, I guess I'm a bit late here, but ... frankly I think that
> there's absolutely no reason to enforce any loader on a user. The db
> loader *is* fairly exotic, our apps use it, but that doesn't make it in
> any way comparable to jpg or png loaders. When an app depends on a
> loader, make the loader a requirement of the app, and the loader depend
> on whatever it needs to do its job, just as Michael said.
> 
> I guess it's a fact that the average Linux installation contains a
> shitload of stuff the user never touches. Most people say "Right, and so
> our little lib here and app there don't make a difference". No need to
> add to that habit. If a user is sure that she doesn't want edb, then why
> enforce it? 
> 
> "Carsten Haitzler (raster@...)" wrote:
> > hmm ok - i will concede on a few conditions:
> > 1. someone breaks the db l,oader out of imlib2 cleanely and cleans up
> afterwards
> > and makes sure it builds probpelr afterwards
> > 2. they put it elsewhere in cvs so it can build on its own
> > 3. someone has to take blame for the support mail that will appear
> 
> Why are 1+2 necessary? Just remove the requirements from the packaging
> files and the requirement checks from configure.in?

user installes imlib2 from src
user installes e - realises he needs edb..
installes edb...
instalels e
e bailed out.. complaining
go back to compile imlib2
forget they have to do funky things like rm config.cache etc.
they complain to us and end up recompiling a whole lib to get 1 loader :)


> 
> -- Christian.
> ________________________________________________________________________
>                                                     http://www.whoop.org
> 
> 
> _______________________________________________
> Enlightenment-devel mailing list
> Enlightenment-devel@...
> http://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@...     raster@...
VA Linux Systems                    raster@...
Mobile Phone: +61 (0)408 363 984    Work Phone: +61 (02) 9386 9362

Rasterman [raster@...] wrote:
> user installes imlib2 from src
> user installes e - realises he needs edb..
> installes edb...
> instalels e
> e bailed out.. complaining
> go back to compile imlib2
> forget they have to do funky things like rm config.cache etc.
> they complain to us and end up recompiling a whole lib to get 1 loader :)
> 

Now here is an example where I can understand the way you are seeing
things raster.  However, the problem is user education.  I understand
peopel being irritated by these kinds of questions (Did you delete
your config.cache? My what?) but dumbing things down to the lowest
common denominator is not what unix or this project (I think) is about.

Also, if we are going to have people who are going to specifically 
answer questions from these types of users, instead of having people
email them directly, why not create a support mailing list for them
to manage.  Amoung other things, a -user list would help to reduce that
sort of traffic on this list.  It won't eliminate it (I think the mutt-devel
list demonstrates that) but we can certainly keep it down to a manageable
level that way.

On Sat, 11 Aug 2001 01:08:44 -0500 Mark Bainter <mark-e@...> babbled
profusely:

> Rasterman [raster@...] wrote:
> > user installes imlib2 from src
> > user installes e - realises he needs edb..
> > installes edb...
> > instalels e
> > e bailed out.. complaining
> > go back to compile imlib2
> > forget they have to do funky things like rm config.cache etc.
> > they complain to us and end up recompiling a whole lib to get 1 loader :)
> > 
> 
> Now here is an example where I can understand the way you are seeing
> things raster.  However, the problem is user education.  I understand
> peopel being irritated by these kinds of questions (Did you delete
> your config.cache? My what?) but dumbing things down to the lowest
> common denominator is not what unix or this project (I think) is about.
> 
> Also, if we are going to have people who are going to specifically 
> answer questions from these types of users, instead of having people
> email them directly, why not create a support mailing list for them
> to manage.  Amoung other things, a -user list would help to reduce that
> sort of traffic on this list.  It won't eliminate it (I think the mutt-devel
> list demonstrates that) but we can certainly keep it down to a manageable
> level that way.  

yes.. but in my travels over the yearsiv'e noticed...
1. users dont get smarter... they get dumber - because more no unix people start
playing with things
2. tom already split it out.
3. either way it's an extra package regardless for binary stuff
4. we alreayd have an xcf loader as an example - things can follow from there.
5. if we break out the db loader we shoudl break out the jpeg, tiff, png, gif
etc. loaders too - any ones that require external libs at all.

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@...     raster@...
VA Linux Systems                    raster@...
Mobile Phone: +61 (0)408 363 984    Work Phone: +61 (02) 9386 9362

On Saturday, 11 August 2001, at 16:15:03 (+1000),
Carsten Haitzler wrote:

> yes.. but in my travels over the yearsiv'e noticed...
> 1. users dont get smarter... they get dumber - because more no unix people start
> playing with things

This isn't about the users at all.  This is about you.  You don't want
to have to deal with users asking the same questions over and over
again.

Well welcome to life as an open source software developer.  Get used
to it, and get over it.  If you don't want to respond to those types
of questions, don't.  Bounce them to this list; someone here will
respond.  But I'll say it again; attempting to avoid support questions
by making the wrong design choice is not a smart move.  If it were, I
never would have implemented the --cmod flags in Eterm, or auto mode,
or the buttonbar.  They have all generated lots of user questions.
But they were all good things to have, so we have them, and I live
with the questions.

> 2. tom already split it out.

Because it was one of your demands.  That doesn't make it right.

> 3. either way it's an extra package regardless for binary stuff

It's going to be a separate package either way, so the end user of
binary packages won't care either way.  Given that, you should make it
easy on the people who are left over:  packagers and source users.  It
is far better (and far less maintenance) to have 1 Imlib2 SRPM than to
have 7 or 8.

> 4. we alreayd have an xcf loader as an example - things can follow from there.

The XCF loader HAD to be split out due to licensing.  That comparison
is irrelevant and misleading.

> 5. if we break out the db loader we shoudl break out the jpeg, tiff, png, gif
> etc. loaders too - any ones that require external libs at all.

That is entirely pointless and a waste of time.  All the loaders that
require external libs are already optional builds.  There is no reason
to complicate matters further.

Am I the only one who feels this way?  Agree or disagree, I'd rather
not be the only one discussing this.  So let's hear other opinions,
folks. :-)

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <mej@...>
Software Engineer, VA Linux Systems       Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
 "I don't think 'huge machine' is the right phrase to describe a
  cluster of 486/SX's.  Maybe 'cluster-f***ed'..."    -- Jacob Wilkins

Rasterman [raster@...] wrote:
> On Sat, 11 Aug 2001 01:08:44 -0500 Mark Bainter <mark-e@...> babbled
> profusely:
> 
> > Rasterman [raster@...] wrote:
> > > user installes imlib2 from src
> > > user installes e - realises he needs edb..
> > > installes edb...
> > > instalels e
> > > e bailed out.. complaining
> > > go back to compile imlib2
> > > forget they have to do funky things like rm config.cache etc.
> > > they complain to us and end up recompiling a whole lib to get 1 loader :)
> > > 
> > 
> > Now here is an example where I can understand the way you are seeing
> > things raster.  However, the problem is user education.  I understand
> > peopel being irritated by these kinds of questions (Did you delete
> > your config.cache? My what?) but dumbing things down to the lowest
> > common denominator is not what unix or this project (I think) is about.
> > 
> > Also, if we are going to have people who are going to specifically 
> > answer questions from these types of users, instead of having people
> > email them directly, why not create a support mailing list for them
> > to manage.  Amoung other things, a -user list would help to reduce that
> > sort of traffic on this list.  It won't eliminate it (I think the mutt-devel
> > list demonstrates that) but we can certainly keep it down to a manageable
> > level that way.  
> 
> yes.. but in my travels over the yearsiv'e noticed...
> 1. users dont get smarter... they get dumber - because more no unix people start
> playing with things

I won't dispute that.  But I don't think it works as an argument 
in support of dumbing down an interface.  Allowing the users to 
get by without using their head because they choose not to only
contributes to the problem.  MS made computers much easier by wiping
out dos and giving them windows.  And look at the users that created.
AOL created a dumbed down version of the internet, and we all know 
what kind of userbase that created too.  I'd much rather be part of
the solution than part of the problem.  -shrug-  

> 2. tom already split it out.

/me kicks the dead horse a few more times. 

Thought there was still a little life left in the discussion of
the underlying philosophy.

> 3. either way it's an extra package regardless for binary stuff
> 4. we alreayd have an xcf loader as an example - things can follow from there.
> 5. if we break out the db loader we shoudl break out the jpeg, tiff, png, gif
> etc. loaders too - any ones that require external libs at all.

Yup.

On Fri, 10 Aug 2001 23:37:45 -0700 Michael Jennings <mej@...>
babbled profusely:

> On Saturday, 11 August 2001, at 16:15:03 (+1000),
> Carsten Haitzler wrote:
> 
> > yes.. but in my travels over the yearsiv'e noticed...
> > 1. users dont get smarter... they get dumber - because more no unix people
> start
> > playing with things
> 
> This isn't about the users at all.  This is about you.  You don't want
> to have to deal with users asking the same questions over and over
> again.

yup.

> Well welcome to life as an open source software developer.  Get used

i don't know about you but i've been doing this a tad longer than you have...
and i'm fankly sick of being distracted form doing code.

> to it, and get over it.  If you don't want to respond to those types
> of questions, don't.  Bounce them to this list; someone here will
> respond.  But I'll say it again; attempting to avoid support questions
> by making the wrong design choice is not a smart move.  If it were, I

why not? avoiding support issues by packaging somehting separately has been done
lots of times before. it's nothing new. if its in imlib2's code our outside of
it... not an issue reall except for people who want to make packages out of it..
this means another spec file and build procedure. are you sure your'e not saying
this from that point of view? that it cause extra work there?

> never would have implemented the --cmod flags in Eterm, or auto mode,
> or the buttonbar.  They have all generated lots of user questions.
> But they were all good things to have, so we have them, and I live
> with the questions.
> 
> > 2. tom already split it out.
> 
> Because it was one of your demands.  That doesn't make it right.
> 
> > 3. either way it's an extra package regardless for binary stuff
> 
> It's going to be a separate package either way, so the end user of
> binary packages won't care either way.  Given that, you should make it
> easy on the people who are left over:  packagers and source users.  It
> is far better (and far less maintenance) to have 1 Imlib2 SRPM than to
> have 7 or 8.

we already have an external xcf package. rpm -ta works wonders :)

> > 4. we alreayd have an xcf loader as an example - things can follow from
> there.
> 
> The XCF loader HAD to be split out due to licensing.  That comparison
> is irrelevant and misleading.
> 
> > 5. if we break out the db loader we shoudl break out the jpeg, tiff, png,
> gif
> > etc. loaders too - any ones that require external libs at all.
> 
> That is entirely pointless and a waste of time.  All the loaders that
> require external libs are already optional builds.  There is no reason
> to complicate matters further.
> 
> Am I the only one who feels this way?  Agree or disagree, I'd rather
> not be the only one discussing this.  So let's hear other opinions,
> folks. :-)
> 
> Michael
> 
> -- 
> Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <mej@...>
> Software Engineer, VA Linux Systems       Author, Eterm (www.eterm.org)
> -----------------------------------------------------------------------
>  "I don't think 'huge machine' is the right phrase to describe a
>   cluster of 486/SX's.  Maybe 'cluster-f***ed'..."    -- Jacob Wilkins
> 
> _______________________________________________
> Enlightenment-devel mailing list
> Enlightenment-devel@...
> http://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@...     raster@...
VA Linux Systems                    raster@...
Mobile Phone: +61 (0)408 363 984    Work Phone: +61 (02) 9386 9362

On Saturday, 11 August 2001, at 16:50:39 (+1000),
Carsten Haitzler wrote:

> yup.

Well, at least you admit it now. :)

> i don't know about you but i've been doing this a tad longer than
> you have...

Maybe so.  So why haven't you figured it out by now? :)

> and i'm fankly sick of being distracted form doing code.

So don't let yourself be.  *You* are the one who decides whether or
not to answer user questions.  If you don't want to answer one, don't.

You'd also save a lot of time by working with your fellow developers
to hash out designs *before* you go and write lots of code.  Instead
you just go off and code things before the issue has been fully
discussed and analyzed (like the ':' thing).  Had you been a little
more patient and given the discussion time to pan out, you wouldn't
have spent all that time doing both escaping and toggling.

> why not? avoiding support issues by packaging somehting separately
> has been done lots of times before. it's nothing new.

Can you name some examples?  And they can't be packages of yours
either. :-)

> if its in imlib2's code our outside of it... not an issue reall
> except for people who want to make packages out of it..  this means
> another spec file and build procedure. are you sure your'e not
> saying this from that point of view? that it cause extra work there?

It's not just 1 extra spec file, tarball, and SRPM you're talking
about here.  It's a whole bunch.  And that would be just fine if there
were a really good reason for it, but I don't see that there is.

I'm looking at this from several points of view.  One, as a packager,
it's going to be much more difficult to package Imlib2 if it's done
the way you suggest.  Two, I'm looking at this as a person who
downloads and builds source code from CVS.  Having several additional
modules to keep up with, build, and install for no apparently benefit
doesn't benefit that type of person either.  Three, for the person who
downloads released source tarballs, I've now got 7 or 8 to fetch
instead of 1, and that's just for Imlib2.  Again, if there was a good
reason, that's cool...but there isn't.  And finally, from the
perspective of a user of binary packages, neither way is preferable to
the other.  So out of those 4 types of users, you've pissed off 3, and
1 doesn't give a shit.  Not a good ratio, my friend. :)

> we already have an external xcf package. rpm -ta works wonders :)

Come now, raster.  As a fellow packager, and especially as someone who
is familiar with our build system, you should certainly be familiar
with the disadvantages of source tarballs when compared with
SRPM's. :)  Of course, having written the build system, I may have a
different perspective on the two alternatives, the details of which
I'm happy to share if you're interested.

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <mej@...>
Software Engineer, VA Linux Systems       Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
 "By the time they had diminished from 50 to 8, the other dwarves 
  began to suspect 'Hungry' ..."        -- Gary Larson, "The Far Side"

Rasterman [raster@...] wrote:
> On Fri, 10 Aug 2001 23:37:45 -0700 Michael Jennings <mej@...>
> babbled profusely:
> > Well welcome to life as an open source software developer.  Get used
> 
> i don't know about you but i've been doing this a tad longer than you have...
> and i'm fankly sick of being distracted form doing code.

I can sympathize with you on that.  And really there's no reason you should 
be distracted from it in a project of this size.  There's no reason the user
community can't/shouldn't support itself.  It's silly for you to have to
answer user questions.

Quoth Tom Gilbert:
> Autoconf does let you (or so I thought) provide test programs (or code
> snippets) to test for specific things.

Yeah it does; I'm pretty sure binutils or perl (or something else big)
does a fair bit of it.  That's what the lt*.sh scripts in the binutils
source look like they're doing anyway.  =)

Andrew.

-- 
Andrew Shugg <andrew@...>                   http://www.neep.com.au/

"Just remember, Mr Fawlty, there's always someone worse off than yourself."
"Is there?  Well I'd like to meet him.  I could do with a good laugh."

Quoth Carsten Haitzler:
> user installes imlib2 from src
> user installes e - realises he needs edb..
> installes edb...
> instalels e
> e bailed out.. complaining
> go back to compile imlib2
> forget they have to do funky things like rm config.cache etc.
> they complain to us and end up recompiling a whole lib to get 1 loader :)

This is getting quite tangential - but haven't you expressed in the past
that you want people to install E by packages for their system, and not
from source?  I seem to recall you saying that, or something like that.

Hence, if someone comes along and decides to build a stable (or devel)
release of E by source, then it is expected that they know what they are
doing and have read the page that explains what you need to build, and
in what order.  *admits with mild embarressment that said page doesn't
seem to exist on the site at the moment*

Yes?

Andrew.

-- 
Andrew Shugg <andrew@...>                   http://www.neep.com.au/

"Just remember, Mr Fawlty, there's always someone worse off than yourself."
"Is there?  Well I'd like to meet him.  I could do with a good laugh."

Quoth Michael Jennings:
> This isn't about the users at all.  This is about you.  You don't want
> to have to deal with users asking the same questions over and over
> again.

And raster - if you're really really honest with yourself - I think you
will agree with me that plastering your email address on every file you
touch must have something to do with the reason you find yourself the
first point of contact for all the user queries.  =)

Andrew.

-- 
Andrew Shugg <andrew@...>                   http://www.neep.com.au/

"Just remember, Mr Fawlty, there's always someone worse off than yourself."
"Is there?  Well I'd like to meet him.  I could do with a good laugh."

Michael Jennings wrote:
> 
> Am I the only one who feels this way?  Agree or disagree, I'd rather
> not be the only one discussing this.  So let's hear other opinions,
> folks. :-)


1. I still don't see why the db loader has to be a separate module. We
now have Imlib2-shipped loaders, a db loader module, and an
"All-other-things-here-please" module currently only containing the XCF
loader. 

What is so bad about people having to go back to Imlib2 and re-run
configure? Raster, if you're worried about config.cache, we could add a
AC_CHECK_LIB_UNCACHED check that doesn't do caching. This is about
people who compile their stuff themselves. It should not be beyond them
to understand that it's necessary.

Some won't get it and we might have to help them, but what the hell? At
some point I hope we'll have a decent FAQ scheme and a one-liner reply
pointing to the right entry certainly is acceptable.


2. From the README I put in the imlib2_loaders module:

"This package contains image loader plugins for Imlib 2 that are not
dis-
tributed together with the Imlib 2 package itself."

It's not like this is set in stone, but Tom, why did you create an extra
module and not use imlib2_loaders?

I think I'll need to change the README -- so what should the purpose of
the imlib2_loaders module now be? Just for loaders causing BSD license
problems? Otherwise I could just as well remove the module and add
imlib2_loader_xcf.

Raster, Tom, you both just hacked away without waiting until an issue is
properly discussed through -- be it the ":" thing or adding a new
module. I'm pretty surprised.


3. On another note, regarding this:

"Carsten Haitzler (The Rasterman)" wrote:
> 
> On Fri, 10 Aug 2001 10:48:02 -0500 Lyle Kempler <term@...> babbled
> profusely:
> 
> > > Log Message:
> > >
> > >
> > > efsd respawnign by e17 is more robust now...
> > >
> > > ===================================================================
> > > RCS file: /cvsroot/enlightenment/e17/apps/e/src/config.c,v
> > > retrieving revision 1.13
> > > retrieving revision 1.14
> > > diff -u -3 -r1.13 -r1.14
> > > --- config.c        2001/07/30 16:59:08     1.13
> > > +++ config.c        2001/08/09 23:48:40     1.14
> > > @@ -21,6 +21,7 @@
> > >  static char cfg_menus_dir[4096] = "";
> > >  static char cfg_entries_dir[4096] = "";
> > >  static char cfg_selections_dir[4096] = "";
> > > +static char cfg_scrollbars_dir[4096] = "";
> > >  static char cfg_user_dir[4096] = "";
> > >  static char cfg_images_dir[4096] = "";
> > >  static char cfg_backgrounds_dir[4096] = "";
> >
> > Wouldn't it be better to use PATH_MAX?
>
> that woudl assume i actually added a configurew check for it and it was in
> configure.in AND i were to use snprintf too.. whihc i don't
> 
> yes your'e right... but i'm leaving that for "another day" - i don't see it as
> important at this stage. i knwo every instance of 4096 in my code can be
> search/replaced with PATH_MAX  - in linux 4096 is what PATH_MAX is anyway.. so
> for now its doign quite fine.. :)

This is really not a matter of life and death, but I'll never understand
why you don't do these things right in the first place. It looks ugly,
people who read it will think "Eeeeew" (or is it just me and term?) and
chances are that it will never get cleaned up. But what the hell, you
know my opinion on this.

Anyway. I'll add some e16 content to the site now because otherwise
noone else is ever going to do it.

-- Christian.
________________________________________________________________________
                                                    http://www.whoop.org

* Christian Kreibich (kreibich@...) wrote:
> Michael Jennings wrote:
> > 
> > Am I the only one who feels this way?  Agree or disagree, I'd rather
> > not be the only one discussing this.  So let's hear other opinions,
> > folks. :-)
> 
> 
> 2. From the README I put in the imlib2_loaders module:
> 
> "This package contains image loader plugins for Imlib 2 that are not
> dis-
> tributed together with the Imlib 2 package itself."
> 
> It's not like this is set in stone, but Tom, why did you create an extra
> module and not use imlib2_loaders?

Because the way you set up imlib2_loaders, the whole thing is under a
GPL license. The db loader is not. If you want me to change it so each
loader has a specific license, etc, fine, but it was actually a lot less
work to do it this way and I didn't see what the xcf loader and the db
loader had in common.

> Raster, Tom, you both just hacked away without waiting until an issue is
> properly discussed through -- be it the ":" thing or adding a new
> module. I'm pretty surprised.

No, I asked if I could break out the module and when people said "yes",
I did it. Then I posted the commitlog to the list and asked for
responses. I still have not made the other changes because I am still
waiting for feedback. My initial suggestion to do it was 3 days before
me doing it.  How is that not waiting for discussion ck?

Tom.
-- 
   .^.    .-------------------------------------------------------.
   /V\    | Tom Gilbert, London, England | http://linuxbrit.co.uk |
 /(   )\  | Open Source/UNIX consultant  | tom@...    |
  ^^-^^   `-------------------------------------------------------'

Tom Gilbert wrote:
> 
> > It's not like this is set in stone, but Tom, why did you create an extra
> > module and not use imlib2_loaders?
> 
> Because the way you set up imlib2_loaders, the whole thing is under a
> GPL license. The db loader is not. If you want me to change it so each
> loader has a specific license, etc, fine, but it was actually a lot less
> work to do it this way and I didn't see what the xcf loader and the db
> loader had in common.

Oh, it was not my intent to have a GPLd imlib2_loaders module. That's
why I put "The XCF loader therefore is GPL'd as well" in the README. If
it comes across this way, we really should change that. After all, it's
possible to bundle up a number of loaders, each with potentially
different licenses, right?

> No, I asked if I could break out the module and when people said "yes",
> I did it. Then I posted the commitlog to the list and asked for
> responses. I still have not made the other changes because I am still
> waiting for feedback. My initial suggestion to do it was 3 days before
> me doing it.  How is that not waiting for discussion ck?

Don't get this wrong, I appreciate the fact that you implemented what
you were talking about. I just feel that breaking out the loader is a
controversial subject, and the details of how that should be done were
not yet clear. I at least think that the current situation is not
satisfying, neither for us nor for users.
 
-- Christian.
________________________________________________________________________
                                                    http://www.whoop.org

* Christian Kreibich (kreibich@...) wrote:
> Tom Gilbert wrote:
> > 
> > > It's not like this is set in stone, but Tom, why did you create an extra
> > > module and not use imlib2_loaders?
> > 
> > Because the way you set up imlib2_loaders, the whole thing is under a
> > GPL license. The db loader is not. If you want me to change it so each
> > loader has a specific license, etc, fine, but it was actually a lot less
> > work to do it this way and I didn't see what the xcf loader and the db
> > loader had in common.
> 
> Oh, it was not my intent to have a GPLd imlib2_loaders module. That's
> why I put "The XCF loader therefore is GPL'd as well" in the README. If
> it comes across this way, we really should change that. After all, it's
> possible to bundle up a number of loaders, each with potentially
> different licenses, right?

Right - no problem.

> > No, I asked if I could break out the module and when people said "yes",
> > I did it. Then I posted the commitlog to the list and asked for
> > responses. I still have not made the other changes because I am still
> > waiting for feedback. My initial suggestion to do it was 3 days before
> > me doing it.  How is that not waiting for discussion ck?
> 
> Don't get this wrong, I appreciate the fact that you implemented what
> you were talking about. I just feel that breaking out the loader is a
> controversial subject, and the details of how that should be done were
> not yet clear. I at least think that the current situation is not
> satisfying, neither for us nor for users.

Okay. I will move the loader into imlib2_loaders as soon as the debate
between raster and mej about whether it should be broken out at all is
concluded.

Tom.
-- 
   .^.    .-------------------------------------------------------.
   /V\    | Tom Gilbert, London, England | http://linuxbrit.co.uk |
 /(   )\  | Open Source/UNIX consultant  | tom@...    |
  ^^-^^   `-------------------------------------------------------'