After years of reluctance, I have finally decided to completely migrate from Enlightenment E16/DR16 to version E17. The main issue keeping me from making the change was the loss of desk viewports. Enlightenment has the concept of 'desktops' (as do other window managers), but E16 also has the fiction of 'areas.' An E16 area is a viewport mapping the monitor to some portion of the desktop. If your monitor has a resolution of 1024×768 and you have defined 2×1 areas, your desktop is actually 2048×768. One area is mapped to desktop coordinates [0,0]-[1023,767], and the other to [1024,0]-[2047,767].
![[Desktop rep]](http://Ken.Coar.Org/images/Enlightenment-Desktops.png)
Enlightenment desktops and areas
Given those conditions, it's extremely easy to set up windows in the various areas programatically. In the figure, there are 6×2 areas, with windows in viewports [0,0] and [2,1]. Each is in the upper-left corner of its viewport. If the monitor resolution is 1024×768, that means those windows could have been placed using geometry strings specifying 0x0 and 2048x768 respectively.
For years I've used a layout like this -- six viewports wide by two high. I have a login script that started up two terminal windows in each except the last two, which I reserved for Firefox and Xchat. This allowed me to organise my activities somewhat:
- Viewport [0,0] was reserved for sessions logged in as root
- [1,0] was for TweetDeck and ad hoc general stuff
- [3,0] was for ssh sessions logged into various mail servers
- [5,0[ was for ssh sessions on my main Web server host
- [3,1] was sessions dealing with downloads and local kit building
- [4,1] was Firefox
- [5,1] was Xchat
The remaining viewports had no firm usage.
E17, on the other hand, has apparently discarded the viewport/area concept. Desktops are all there is. And since that's strictly a window manager fiction, X doesn't know anything about it and hence you can't use X geometry strings to place things programatically. Enlightenment supposedly lets you work around this (although that's not how it's phrased) by allowing you to have it 'remember' things like placement and autostart.
The 'remember' functionality helps me not at all, unfortunately, since I use the same scripts on multiple systems with varying resolutions and numbers of monitors. Plus, shelves and menu bars and window dressing dimensions are not the same across all my environments, but my scripts understood that and make appropriate adjustments. Withe 'remembers,' though, what works in one environment is misplaced on the next.
So I'm giving up the ability to dynamically place windows at login time. E17 also doesn't have an included 'system tray' capability, but stalonetray is sufficing there (although it isn't currently dockable on an E17 shelf). And the GNOME disk mounter applet isn't to be found on E17, of which I was just getting quite fond.
On the positive side, E17 does understand multiple monitors, and smart maximise (mostly), which gives me a lot more flexibility at work where I use it most.
So I think I'll stick with E17, and see what I can do to help correct the bits I consider deficiencient.