Window Mangers :: E17 - Enlightenment 17



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).
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.
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
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.
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)
Next Page...
original here.