To create session support, modern environments go out of their way to do all kinds of crazy things - for example, try to remember the geometry & etc. of your windows automagically, or worse yet, make you click on "remember position" in every damn window.
Why? Because they are crazy, they haven't stepped back from the code, and they haven't considered what is it that they actually REALLY want. [well... sometimes they did... except instead of figuring out what they want, they went and looked how product Q does it, and tried to emulate it + their own little hacks.] Here's a typical scenario for what I do when I work. I start an xterm. In it I set 2 or 3 environment variables (to point to various versions of various software) then I source a few config files which take those variables into account (of course this is all done with shell alises, but just to be explicit here), I then start icfb (software package A), open a design in it, click some buttons to start (software package B), tweak some settings, and proceed to run a circuit synthesis in software package B. The syntehsis is done. I am looking at the results in the window. In another window (thanks to ion, my screen is vertically split into two) I perform the same procedure, except the environment variables in step 2 above point to different version numbers for software packages A and B. Possible (although some hypothetical) scenarios: - I log out or crash. I log back in. The default version of icfb is launched in two windows where I had previously hand crafter the environments. I close them. BAD! - I log out or crash. I log back in. The default versions of icfb are run, and the default versions of software package B are launched. I stare at them, spend 5 minutes figuring out that these are not the versions I was using, and close them. BAD! - I log out or crash. I log back in. My xterms support a brilliant notion of sessions. Using a machine learning algorithm they replay my environment and pop up the right icfb sessions in each window. icfb has amazing session support helpers built in which open the appropriate design and each relaunch an appropriate copy of software B, which also has brilliantly coded session support and proceeds to re-tweak all of the hand coded settings and runs the same ciruit synthesis that I had going before login or crash. SESSION SUPPORT MONKEY'S HEAVEN. BAD! BAD! BAD! I do not WANT those applications running. I do not want to wait 20 minutes for these things to come up, there is no guarantee that I still want to run the synthesis in question. Maybe someone else (me?) has edited the design on NFS while I was mid crash, and now I'm running random crap! But that's already assuming that I did want to run those jobs again. So, pardon this mail (which has turned out to be 8x longer than I had planned when I began it) but I really wanted to make a point. Session support is not practical, it might apppear 'cool' from afar, but it's really useless. I'm not going to claim to have a solution - I do not have 'the' answer. But I can say with certainty that what people have come to expect of 'session support' these days is useless in your average computing environment. What is it that people really want? Well... I can't speak for 'people' much, so I'll say what I want. I want an easy way to configure my .xinitrc to launch a predefined set of programs when I log in, and I want them to start in the windows that I assigned to them. The support for this in Ion is practically complete - yes, it may be a minor pain to distinguish one xterm from another, but it's possible for the majority of software. In fact, there's only two things really missing from this scheme a) ability to launch one frame 'left of' another in a single window, and b) a nice configuration utility to connect the stuff in the startup script with Ion's windows. Is this session support? No! It's the ability to configure a predefined set of applications to start when I log in. I dictate exactly what is run in them, I dictate where they run. Should Ion add this functionality? No! People have been using .xinitrc files for years, why reinvent the wheel for something that already works? Again, I apologize for the rant. If I had a spare week, I'd write (b) above; it saddens me that I do not, but such is life. Mike P.S. Of course in the 'super ideal case' I would carry a key card with me that I plug into any terminal anywhere I go that connects to my actual working environment that never crashes and that I never have to log out of, and I proceed to work in it as I did before I unplugged my key card last time. But this isn't session support either, because if ever the backend 'went away', I wouldn't want it to restore a 'session' upon restart, I'd want it to start my apps from scratch, from none other than my .xinitrc file.
