Re: Add function to make frame topmost?

[David De La Harpe Golden]

Drew Adams wrote:

> Not to divert the discussion from your patch, but wouldn't we anyway need
> something like what bug #4476 suggests in order to save & restore frame configs?
> If we are intending to be let users persistently save the state of their windows
> and frames, then won't we need to record and restore (or at least request
> restoration of) the fine-grained stacking order/z-order?


Maybe. Apart from leaving the z-order alone:

One could try to restore something as close as possible to a saved 
absolute z-order, but users might be surprised by that since  non-emacs 
windows may well have come and gone in the meantime, and it would mean 
restoring a frame configuration might bury and interleave frames behind 
non-emacs windows. It might all seem a bit random.

Restoring the relative z-order of emacs frames, but restoring them
contiguous in the stack and maybe at the top (not always-on-top, I just 
mean in front) on restoration, might be a better option. Except when the 
user is saving and restoring in rapid succession in the one session, as 
I imagine most people's typical use of 
frame-configuration-to-register/jump-to-register is. Then it might be 
the surprising/annoyingly-raisey option, and leaving
the z-order as-is might be best.

Or could punt and make it an option as to which of the three happens
and/or which of the three happens in which context (same-session
set-frame-configuration from a "live" frame configuration object
vs. from a deserialized "undead" frame configuration object)

Probably need coding up and testing for a real assessment.