Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fixing a 20-year-old bug in Enlightenment E16

iczelia.net

Post reply on HN
Print view View original

21–30 of 193 posts

Re: Fixing a 20-year-old bug in Enlightenment E16

#22

Post by robinsonb5 »

zeruch wrote: post #7

The amount of abuse I hurled at Carsten Haitzler (Raster) during our time at VA Linux (where he worked on E as well as other stuff) was a complete sitcom unto itself; at one point he debated making a "zeruch insult generator" just to streamline the verbal abuse process. I loved using the environment but would regularly harangue him for being glib on resource usage. It really was otherwise very ahead of the curve.

It's a delicious irony that E is now a super-lightweight system compared with the mainstream environments that plauge our RAM chips today.

Re: Fixing a 20-year-old bug in Enlightenment E16

#24

Post by ChrisGreenHeur »

prmoustache wrote: post #23

Funnily, E16 was considered a rather eye candy but heavy WM/environment back in the i486 / early pentium days, now it is considered lightweight!

one of the more interesting things to think about is the big push to rendering all window manager stuff through a gpu, because we were sure we needed drop shadows and geometry transforms for windows....

Now, what we actually do in a window manager could easily be done in software in realtime, just farmed out to some cpu core.

Re: Fixing a 20-year-old bug in Enlightenment E16

#25

Post by mhd »

pjmlp wrote: post #9

Oh, people are still using Enlightenment. My last time I used it was still in the 1990's, before I settled into Afterstep and soon afterwards Windowmaker. In what concerns my use of GNU/Linux, it was CDE on others. Apparently nothing big came out of Enlightenment and Tizen.

Enlightenment always had a pretty weird value proposition. In the very beginning, there was "fvwm-xpm" and early "E" prototypes. They were graphically crazy with a heavy focus on shaped Windows. There's still nothing quite like that weird steampunk/Brazil-ish theme they had. Probably for a reason.

Then they went both visually rather tame and scope-creepy (own graphical libraries etc.). At the beginning I was hoping that we'd get some kind of Amiga-influenced design sensibilities on X (basically a more "artsy" MUI), but that never manifested.

Re: Fixing a 20-year-old bug in Enlightenment E16

#26

Post by jhbadger »

prmoustache wrote: post #23

Funnily, E16 was considered a rather eye candy but heavy WM/environment back in the i486 / early pentium days, now it is considered lightweight!

And detractors of Emacs used to claim that it stood for "Eight Megabytes And Constant Swapping" meaning that even on a then-huge machine with eight megabytes of RAM Emacs would use up all the memory. Now it is a tiny program compared to things like Visual Studio Code.

Re: Fixing a 20-year-old bug in Enlightenment E16

#27

Post by dspillett »

angled wrote: post #12
zeruch wrote: post #7

The amount of abuse I hurled at Carsten Haitzler (Raster) during our time at VA Linux (where he worked on E as well as other stuff) was a complete sitcom unto itself; at one point he debated making a "zeruch insult generator" just to streamline the verbal abuse process. I loved using the environment but would regularly harangue him for being glib on resource usage. It really was otherwise very ahead of the curve.

I still remember how cool I thought raster was with his vaio and everything. This was the future! Transparent eterms and tasteful backgrounds everywhere.

> tasteful backgrounds everywhere.

Certainly not everywhere. I definitely remember plenty of tasteless ones, some deliberately so and others just cases of other people's taste differing from mine!

Re: Fixing a 20-year-old bug in Enlightenment E16

#29

Post by pjc50 »

ChrisGreenHeur wrote: post #24
prmoustache wrote: post #23

Funnily, E16 was considered a rather eye candy but heavy WM/environment back in the i486 / early pentium days, now it is considered lightweight!

one of the more interesting things to think about is the big push to rendering all window manager stuff through a gpu, because we were sure we needed drop shadows and geometry transforms for windows.... Now, what we actually do in a window manager could easily be done in software in realtime, just farmed out to some cpu core.

> because we were sure we needed drop shadows and geometry transforms for windows

As screens get larger, the amount of pixels you need to push to composite windows gets larger-squared. It makes sense to move the pixel pushing away from the CPU and more importantly away from CPU-RAM and on to a separate RAM bus.

The "single buffer with invalidation" model of Win16 (I cannot remember how it works in X) saves memory at the cost of more redraws. The composition model allows you to do things like drag window A over window B without forcing a repaint of window B every frame.

It also allows for better process isolation. I think in both Win16 and X11 you could just get a handle to the "root window" and draw wherever you wanted?

Post reply on HN