RE: Gtk tabs in emacs, new branch

[Drew Adams]

> > Can users save such frame & window configs independently of 
> > desktops - and vice versa? Can they save individual
> > frame/window configs as well as all configs
> > together?
> 
> If you want to save frame and window configurations 
> independently of desktops, you can easily do this using the
> same functions that desktop.el now uses.

So is that confirmation or not that one can save desktops without frame+win
configs and one can also save frame configs or window configs or both
independently of desktops (the traditional desktop info)?

And can users do that interactively out of the box, or are you saying only that
someone is free to create some user commands to do that using existing desktop
functions?

> > A desktop saves some variables, buffers, etc. Users should 
> > be able to save just frame/window state or just the
> > vars+bufs state, as well as being able to save
> > everything together at once.
> 
> There is a new variable `desktop-save-frame-configuration' 
> that defines whether to save frame and window configurations
> to the desktop. It is nil by default.

You don't also say that there is a way to save frame and window configs without
saving them to a desktop file. Or whether there is a way to save them without
also saving the other desktop info (buffers, vars etc.). 

It sounds like frame+win are optionally part of a desktop, but not the contrary
as well. That is different from them being separate things that can optionally
be combined.

I don't care much about the names - whether, for instance, "desktop" applies to
what it means now (buffers, vars, etc.) or it is changed to apply to everything,
including frames and windows. What I am concerned about is being able to easily
save & restore the different kinds of things separately.

> > Also, desktop.el has a big limitation (which I would like 
> > to see removed): it assumes only one desktop file per directory.
> 
> It's a separate task to implement named desktops.
> 
> I imagine that named desktops should be an object above frames
> in the hierarchy of screen objects:
>  - desktop - frame - tab - window configuration - window
> So switching desktops could be like switching frames:
>   M-x select-desktop-by-name RET
> will read a desktop name, delete old frames by calling 
> `desktop-clear', and create a new desktop by calling
> `desktop-read' with the selected name.

I do not really want to see desktops and frames coupled that way. Again, the
names don't matter to me much - what I want is to be able to save & restore such
different things together or separately.

I did not mention "named desktops". I asked to be able to have more than one
desktop file per directory. Currently, the desktop functions assume you can have
only one desktop file per dir.

I would like the basic desktop functions to accept an optional FILE arg that
tells them where the desktop file is. (If no such arg is passed, then they could
do as they do now: look to `desktop-dirname' to find the file.) That would
permit other code to pass a FILE arg to directly specify a desktop file to use.

I have desktop bookmarks, for instance. Because the desktop.el code does not
allow a caller to specify the file to use, my code jumps through a few extra
hoops.

Look at `desktop-change-dir' and `desktop-read'. They just change to the desktop
represented by a particular desktop file. But they assume one file per dir, so
they accept only a dir as arg. You would expect that you could explicitly pass a
desktop file to read, but you cannot.

The desktop.el code seems to be oriented toward a particular interaction between
users and its basic features. That's the problem, as I see it. It has general
features of saving and restoring a desktop to/from a file, but the functions
that perform those basic operations are cobbled by making them assume a
particular UI. That makes them less general (less useful) than they could be.

IOW, there is not enough separation between the basic desktop functions and the
UI that uses them - the UI design bleeds down into the basic functions
themselves.

We need not change the desktop UI. (But we could do that, to let users use
multiple files per dir interactively as well.) The basic desktop functions could
still assume that the desktop file they need is in the `desktop-dirname' dir by
default. All I'm suggesting is that these functions should allow an optional
parameter that provides the desktop file location. 

Other changes to the code (e.g. locking) might also be necessary to allow use of
multiple files per dir - dunno. I'm guessing that the reason behind the original
one-desktop-file-per-dir design had to do with locking (multiple users etc.). I
don't know what all might be involved in trying to remove this limitation (maybe
allow multiple lock files per dir?). For my use of desktop files for bookmarks,
I want to let users save desktop files anywhere, and I don't use the locking.

I brought up this point because you seem to be coupling persistence of frame and
window configs with desktop files - and hence extending the limitation of one
such file per dir to the new feature as well. That means users cannot have
multiple frame-config files per dir etc.

Don't get me wrong. I'm very glad you're working on this, and I don't pretend to
be an expert on desktops or the desktop.el code. I just would like things to be
modular - separable and combinable, and I would like the basic save-&-restore
functions to handle multiple state-saving files per dir.

> > Can users hook into this to handle user-defined frame 
> > parameters also? The feature should be open and not limited to
> > a predefined set of parameters.
> 
> Yes, there is a new variable `desktop-frame-parameters-to-save'.

Very good.