E17 - Enlightenment 17Forum: Window Mangers Topic: E17 - Enlightenment 17 started by: aveline Posted by aveline on April 21 2006,04:54
I was looking thru the dsl repository & saw a few other WM's in there to use if you don't like Fluxbox. I got to wondering if E17 would be able to be run on DSL or are its dependencies too complex to make a .dsl extension out of it?
Posted by pr0f3550r on April 21 2006,09:40
I don't see 17 in the debian packages. I can speak for e16:
Posted by mikshaw on April 21 2006,15:10
I'd compiled e16 to run in DSL a while ago. With the exception of one or two things, it can be made to run without most of those dependencies included (imlib2 is something that apparently cannot be disabled). I'm pretty sure the same can be done with e17. The biggest issue with enlightenment, though, is just the fact that it's so slow and bulky. It wasn't anything that I felt was suitable for running in a damn small distro, so i deleted it before doing much debugging or testing. From what I've heard, quite a few people have found e to be too fat to be worth bothering with. Of course that's just opinion. A DSL user who wants it can install with apt-get, and maybe create a myDSL from that.
Posted by aveline on April 21 2006,17:30
Thx that answers the questions I had. I was curious because I ran e17 on a new distro I found accidentally called aistrumi IIRC and it runs E17. I agree, E16 is slow even on good hardware but E17 seemed to be very fast on my older PIII 550 with 384 mb of ram.Aveline Posted by mikshaw on April 23 2006,00:05
[edit]nevermind...sorry i brought it up. enlightenment is now wanting a newer version of imlib2 than what i have, and i'm not about to upgrade it just to build an extension i'll never use.[/edit] [rant] There seem to be some really stupid decisions made about how to develop gui applications that you don't really notice when you're running a distro with 2gb of various libs and other support files. Then you try getting those applications into DSL and you start to notice how bloated most software is becoming. Imlib is just one of those weird things, and something that I don't think I'll ever understand. It's supposed to handle all sorts of image types, but it still requires the individual image libraries. 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. [/rant] Posted by crusadingknight on April 23 2006,02: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. 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). Posted by mikshaw on April 23 2006,15: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. Posted by desnotes on April 23 2006,16:14
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 Posted by crusadingknight on April 23 2006,16:44
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. Posted by mikshaw on April 23 2006,19:56
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)
Posted by kerry on May 07 2006,10:07
How about someone try this distro out and let us know how it is and how it runs in ram if any good. I would do it my self but i'm running in ram with no hd's so i'm screwed on that one, not to mention i haven't been able to burn a iso image from dsl.-> < http://web.isteve.bofh.cz/olive/ >
Posted by desnotes on May 07 2006,13:24
I d/l and ran Olive in Qemu...can't really tellyou much about how it would run in RAM but here are my quick impressions:-I like the Enlightenment WM...it is laid out well and offers different menus for left-click and right-click on the workspace -The application selection is minimal, one app per need -Runs quick in Qemu, even Firefox 'seems' to run a little quicker than DSL but I did no real timing so it might be just me -The only thing I don't like about the way the WM is setup is if you minimize an application it disappears. I thought maybe it was being closed but it is possible to bring it back up by a left-click, select Windows and then see the minimized apps. Not the best way in my opinion. -Also, it looks like there are some bugs when it comes to displaying various dialog boxes in firefox where the OK & Cancel buttons are masked...hard to explain and they work but some work needs to be done in this are. All in all not a bad little distro but over twice as lard as DSL without an ability to add apps and I haven't tested out whether any user configurations can be saved. desNotes Posted by kerry on May 07 2006,18:30
That minimize apps is a E17 thing, E17 live does the same thing. E17 is still work in progress so most distro's who use it it's always in complete. From what i read this distro is still young yet, as far as i can tell it's origins are from the deadcd distro that is now concertraiting on a mini deadcd. There app's list is surprizingly close to DSL though. I plan on keeping my eye on this olive distro, it was only by chance that i stumbled across, as i think this one is still unlisted anywhere.Did you only try the E17 desktop? How is the Fluxbox desktop? Posted by desnotes on May 07 2006,20:10
When I initially changed from Enlightnement to Fluxbox it did not work. I re-booted and brought up Fluxbox and the menu is configured similarly to Enlightnment. Overall I like the selection of apps:Firefox Sylpheed Gaim X-Chat Audacious MPlayer GQview SciTE VIM Abiword Evince Midnight Commander X-CD-Roast Control Panel Posted by kerry on May 08 2006,07:45
Can you post a copy of the E17 styles i would like to snag that for DSL. Are's is in /usr/share/fluxbox/styles, there's might be there to.
Posted by kerry on May 10 2006,04:03
Here's another E17 mini contender. Like DSL it's 50mb but runs E17 in ram.->< http://www.tuxmachines.org/node/6800 > Posted by kerry on May 10 2006,04:03
Sorry, it double posted.
Posted by mikshaw on May 10 2006,15:20
Austrumi is pretty impressive in how many gui apps it can squeeze in along with kernel 2.6 and xorg, but unfortunately in order to do this it has very few console applications. As a result it reminds me of Windows, in that you can do a few tasks from the commandline but you're tied to the desktop for practically everything.
|