On Fri, 10 Aug 2001 00:04:39 -0500 Lyle Kempler <term@...> babbled
> * 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. :)
> > 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
> > 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.
> Enlightenment-devel mailing list
--------------- 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