On Mon, 23 Jan 2006 07:32:46 -0500 Michael Jennings <[EMAIL PROTECTED]> babbled:
> On Monday, 23 January 2006, at 21:15:24 (+0900), > Carsten Haitzler wrote: > > > dude - that message says EXACTLY what the problem is - to the > > letter. read it. the code passed NULL as a handle pointer to > > ecore_evasget() - so what it passed in was NULL - that's bad. > > Well, in that case, the naughty programmer is YOU. The error message > came from edje_cc when it was unable to load the PNG image loader > module while compiling default.edc for entrance. > > The bottom line is, the message does NOT say what the problem was. > The problem, which I discovered mainly by trial and error, was that > the buffer engine and PNG image loader modules were not available. yes - it doesnt. funny that there are a few hundred thousand lines of code that need work on - a lot of packages like edje when they build dont check for certain support. the bug u saw was a matter of the code basically not checking all its return values. this kind fo stuff happesn when u have a small team and a lot of code. it gets fixed over time. i don't think netuering support is the answer. adding the modules to edje's.spec is a much safer and better solution that removing the ability to have modules for evas at all. it's throwing the baby out with the bathwater. as i said - this is not the right solution. it doesnt make sense when the DEPENDENCIEs of edje can have these moduels added and thus explicitly state what features it requires as a base minimum. i believe i mentioned this to you on irc when i was making a modular .spec - if software needs certain features it can require the particular modules. > > that's just styupid - as my other mail says. the packages that > > REQUIRE these should add them as dependencies - EG tne enlightenment > > package for 0.17 should add these as dependencies - thus indicating > > what engines and loaders and features it requires at a minimum. what > > you have done is for rpm users, is effectively neuter a very useful > > feature - the ability to fine-grain dependencies even if they > > arene't using e17 or e apps (just using evas for some specific > > fucntionality like a dvd/pvr system - eg freevo, where it only > > displays in the framebuffer... just for starters.) > > Sure, you can look at it that way if you want. > > You can also look at it this way: I've saved them an immense amount > of time hunting down problems they don't understand by including the > features that ALMOST ALL PACKAGES which use evas require. but not ALL. i mean - feel free to make packages as such. my recommendation will be to not use them. > > errr - the point of modules is so that the engines, loaders, savers > > CAN be distributed separately without adding dependencies and > > features not wanted/needed in evas. you DO know for exampel that > > just LINKING to libGL on a system with nvidia drivers eats up 8mb of > > RSS - like it or not.? this kind of thing is what this is trying to > > avoid. if u are going to sauport some module packages - you should > > support all of them. what you have done is non-sensical. if you > > removed all i'd understand as its a "pain" but just removing some is > > just =some walfway house that gives no benefits and doesnt really > > remove work. > > It's not non-sensical at all. What I've done is roughly equivalent to > including libXaw.so.* in xorg-x11-libs instead of creating > xorg-x11-athena (which would just be silly). You'll notice that the > GL extension module IS IN A SEPARATE PACKAGE STILL! The only ones I > condensed were the most basic ones. Things like GL and Cairo are > still in separate packages. and we will see a history as with imlib2 - imlib2 needs x11 because itys not modular, but CAN be built withotu x support - suddenyl everyone thinks imlib2 NEEDS x and a lot of peoepl who want to use it for web sites think they need x instaleld for it then decide not to. evas can be used without x - or without png support. the packages now basically neuter that ability. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
