crusadingknight
Group: Members
Posts: 65
Joined: Nov. 2005 |
 |
Posted: April 23 2006,16:44 |
 |
| Quote (mikshaw @ April 23 2006,11:34) | Ok, so "stupid" was a bad choice for an adjective. It should have been "lazy".
This is just one opinion, and I realize it's off-topic, but it does relate to myDSL in that Imlib has been one of the biggest annoyances for me personally while building mydsl packages. Take libpng, for example. If I compile a program that uses libpng.so.3, I can simply include that lib with the package. However, if I compile a program using libpng.so.3 and Imlib1, it won't work in DSL because DSL's Imlib was compiled to use an earlier version of libpng. So I either need to include a redundant Imlib with the package, or install headers for DSL's older version of libpng and compile with the older header. I chose the latter, and it works, but it seems silly that a user who has png, jpeg, xpm, blah, blah, blah support on their system can't run certain programs because the developers didn't want to bother coding support for a few individual image formats.
Please consider the fact that I don't think it would be much of an issue if Imlib was not also very picky about lib versions. I have the same issue in reverse when i try to use an application that was compiled with Imlib and DSL's libpng on a system with a newer version of libpng...it doesn't work. There's a big difference between supporting libs of a certain version or later, and supporting only the precise version with which it was compiled. |
Yeah, we may need to split this into another forum. :P
Anyway, IMlib is actually a part of Enlightenment, as I already mentioned. If Enlightenment were not to use imlib, it would not only be more work for them (because they'd end up duplicating IMlib's functionality in every image loader, because imlib doesn't ever use anything you don't configure it to build with), but would also make everything which suddenly wasn't using imlib take on the overhead of it's own image loading code, making them more 'bloated'. Thus, coding support for xpm, bmp, and png into an application will increase the size more, than if dymanically linked to imlib. (OK, now I'm done trying to explain why reusable interfaces don't make programmers lazy. However, I do admit that it's often a symptom of bad design if library interfaces have to change, forcing you to upgrade versions.)
Anyway, most of the imlib problems are due to the way DSL libraries are chosen; often, size is favored over popular interface , which works well in DSL, but only if you don't try to extend with it. However, I don't think there's much left to add to any of the libraries, so they should all become de facto standards soon (I hope). I certainly favour something imlib-based (such as E16/E17) over something GLIB-based (Openbox-3), because there's far fewer unused features in imlib vs. glib.
--------------
System:
eTower 566.12, 32MB RAM, 7GB HD, 200MB swap, 1x USB v.1, Intel 810GFX, Intel 810 Audio.
Recompiled so far: Pretty much everything. I think I'll have to do a remaster to cut the growing bloat off my system.
|
.
DSL Market ,
Great VPS hosting provided by Tektonic
