Search Members Help

» Welcome Guest
[ Log In :: Register ]

Mini-ITX Boards Sale, Fanless BareBones Mini-ITX, Bootable 1G DSL USBs, 533MHz Fanless PC <-- SALE $200 each!
Get The Official Damn Small Linux Book. DSL Market , Great VPS hosting provided by Tektonic
Pages: (4) </ 1 [2] 3 4 >/

[ Track this topic :: Email this topic :: Print this topic ]

reply to topic new topic new poll
Topic: E17 - Enlightenment 17< Next Oldest | Next Newest >
crusadingknight Offline





Group: Members
Posts: 65
Joined: Nov. 2005
Posted: April 23 2006,02:20 QUOTE

Quote (mikshaw @ April 22 2006,20:05)
So what is the point of having this additional library when it still requires the same libs that you'd use if imlib didn't exist? Software developers seem to like it, though, and endusers don't seem to mind that they are installing redundant software.

It takes longer when you have no wrappers to develop through; using IMlib would be redundant if you were only supporting one image type, but it certainly saves a lot of programmer time if you can pass all of the images you need to load through the same interface. Anyway, IMlib is technically part of enlightenment.

Anyway, I got e16 to compile and run quite quickly on my Celeron 556. (It goes faster if you tweak the configuration settings, and compile from scratch - some modules can be much more efficient at -O20).


--------------
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.
Back to top
Profile PM WEB MSN 
mikshaw Offline





Group: Members
Posts: 4856
Joined: July 2004
Posted: April 23 2006,15:34 QUOTE

Quote (crusadingknight @ April 22 2006,22:20)
It takes longer when you have no wrappers to develop through; using IMlib would be redundant if you were only supporting one image type, but it certainly saves a lot of programmer time if you can pass all of the images you need to load through the same interface.

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.


--------------
http://www.tldp.org/LDP/intro-linux/html/index.html
Back to top
Profile PM WEB 
desnotes Offline





Group: Members
Posts: 120
Joined: Dec. 2005
Posted: April 23 2006,16:14 QUOTE

I have used Austrumi and it is quite fast and well packaged. I would say next to DSL, it is the fastest and nicest small distro I have used. I especially like their use of Openbox & fbpanel.

I tried downloading the e17 version but it appears to be just the same version so maybe someone made a mistake when placing them available for download.

desNotes
Back to top
Profile PM 
crusadingknight Offline





Group: Members
Posts: 65
Joined: Nov. 2005
Posted: April 23 2006,16:44 QUOTE

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.
Back to top
Profile PM WEB MSN 
mikshaw Offline





Group: Members
Posts: 4856
Joined: July 2004
Posted: April 23 2006,19:56 QUOTE

I think I see what you're saying.  I wasn't aware that other gui apps use their own image loaders as well, so i guess my rant was unfounded.  Thanks for your patience =o)

--------------
http://www.tldp.org/LDP/intro-linux/html/index.html
Back to top
Profile PM WEB 
17 replies since April 21 2006,04:54 < Next Oldest | Next Newest >

[ Track this topic :: Email this topic :: Print this topic ]

Pages: (4) </ 1 [2] 3 4 >/
reply to topic new topic new poll
Quick Reply: E17 - Enlightenment 17

Do you wish to enable your signature for this post?
Do you wish to enable emoticons for this post?
Track this topic
View All Emoticons
View iB Code