RE: How to restore the layout?

[Drew Adams <drew.adams@oracle.com>]

> If the font parameter were saved, recreating the frame would use it.

Good.

> I'm QUITE afraid you will now say that in some cases you want the font
> saved (you already said as much),

Yes, of course.

> but in other cases you would the frames to be "transparent" to the
> font, so restoring them woul inherit the current default font of
> the running Emacs.

No, except for user-specified exceptions.

A notable exception is a standalone minibuffer frame.  I want at least
the possibility to tell Desktop not to restore (and even not to save)
such a frame; IOW, hands-off.

And I am still of the opinion that folks using a standalone minibuffer
frame will typically not want additional minibuffers (I'd guess 99.999%
of the time, but I could be wrong of course).  So I think it would make
sense for this particular exception to be the default case.

To cite Epoch again, there were two possibilities only: (1) use a
standalone minibuffer frame, in which case there were no other
minibuffers, or (2) have a minibuffer in each frame.  (#1 was the
default, and I never saw anyone choose #2.

In Epoch there was no chimera possibility such as exists in GNU Emacs.
Perhaps it is good that GNU Emacs allows for such a possibility, but
IMHO it should not be encouraged - or even allowed for when designing
something like Desktop frame support.  I just do not see a use case
for mixing a standalone minibuffer frame and other frames that have
their own minibuffers.  No one has spoken up to the contrary, and I
doubt you ever will find someone who makes use of that odd possibility.

To be clear:

Yes, Desktop should save and restore the `font' parameter in general.
Yes, users should be able to specify certain frames or types of frames
that they do not want saved or that they do not want restored.
Yes, users should be able to specify particular frame parameters that
they do not want saved or that they do not want restored in general.
Yes, users should be able to specify particular frame parameters that
they do not want saved (or...restored) for particular frames or
particular types of frames.

IOW, some of the design questions that you are raising should in fact
be user-specifiable preferences, if that is at all possible.  Desktop
should provide the knobs for users to easily adjust Desktop to get
different behaviors.  One size will not fit all.  That does not mean,
of course, that Desktop cannot or should not have a simple-to-understand
default behavior.

Whether you can provide all of that flexibility at the outset I don't
know, but it should be a goal, IMO.  And I'm guessing that it makes
sense to consider this from the outset, to avoid painting into a corner.
But I'm not familiar with your implementation/design and I can't really
say anything specific about this.  Just a general heads-up, something
to keep in mind.

> > I hope that changing the font size will continue to resize the
> > frame and associated building blocks.
> 
> Yes. The font value of a frame parameter cannot preclude you doing
> (set-default-font "DejaVus Sans Mono-15" nil t) and changing every
> frame in sight.
> 
> > I make heavy use of this feature (a frame's font driving size in
> > general).  It would break most of what I use everyday if this feature
> > were to be "fixed" away.
> 
> For features, all input is welcome. For bugs, I would prefer if you
> could wait untill you stumble upon it ;-)

100% agreed.  (I don't think I've spoken about any bugs.)