unity-design team mailing list archive

[Gregory Merchan <gregory.merchan@xxxxxxxxx>]

On Sun, Oct 21, 2012 at 5:10 AM, Gabriel Pettier
<gabriel.pettier@xxxxxxxxx> wrote:
> I'd love too, to have such an option, that works reliably, that's why i use
> suspend whenever i can, and i hate when i get a unity crash or something,
> all my windows on all workspaces are lost/messed up, it's a pain, i want
> something that doesn't make me think too.
>
> i'm not sure it can even work with the internal state of applications (a
> terminal with vim inside? A thunderbird with an half-written email? ditto
> for libreoffice?).
>
> But i would really love that kind of thing, i just don't think it's possible
> to get correct.

"Correct" is a luxury of the gods and mathematicians. I'll accept
decreasing error.

Yes, the free software community has never reached a conclusion on how
window positions should be saved. Part of this is an inherited messed
up notion of what the window manager should do. (Hint: less.)

Terminals are tricky, and I confess I don't understand how they
interact with X11 well enough to say much about them. One snafu that
we have is that we talk about terminals themselves instead of what you
can do in a terminal. Most of the time when I'm running a terminal,
the program I want is the shell that runs in it; the terminal program
itself is an implementation detail. I imagine it would be confusing to
people now if we highlighting the terminal in the GUI and instead
highlighted the shells, but I don't think the confusion would last
long; if I remember correctly, that's what CDE did 15 years ago. Maybe
thinking about it that way helps someone find a solution. One thing
that is possible approaching correctness is to restart terminals with
the shell and what was the working directory restored.

Thunderbird, or any mail client, should be able to save drafts. Yes,
somebody may have to change the code to make it behave. Same for
LibreOffice.

I mentioned it before and again at the start of this thread: OS/2 work
area folders are a session restore mechanism. They are more fine
grained than anything being used today, and at least seem to take
advantage of recursion: If the desktop is a work area, then anything
on it (or "in it", when you recognize it as a special folder) that was
open the moment before shutdown should be reopened. If a work area
folder on the desktop was open, it's reopened, and it in turn reopens
the things in it that were open. By driving the system through
folders, providing work area folders, and focusing on the data that
people work on instead of the applications they use to do that work,
you solve most session restoration woes. There are still people who
want to start apps and load files into them, instead of just opening
files. In some of those cases there is a file that provides a hook
into session management, like a project file listing the files in the
project. (It's a "hook" that you might use to reel in a solution.)
Other cases are harder. Some programs, like the calculator, don't
usually have any sort of file representation that can be useful. There
are for these the binaries themselves, .desktop files, loading
scripts, treating the dash somehow as a work area folder, and somehow
the same old session mechanism that there was some years ago.

Part of what horrified my about the session handling page was the low
aim. I'm sure to some people that's called "being realistic". Call me
Don Quixote.

I realized while writing this that I wrote something that might be
taken the wrong way: "Writing a desktop environment is a cheap hobby
that will last a long time." I meant that it's MY cheap hobby, one
that I've worked on here and there for a long time, mostly in design
ideas and very little code. One guy who types slowly (~40wpm) trying
to write a desktop environment (toolkit, wm, everything) on the
weekends will be at it for a long time. I already have the computer
and the Internet connection; I don't need power tools, scopes, or much
of a physical workspace for it.