frame size&position woes

frame size&position woes

[Juanma Barranquero]

Currently, our API to obtain the dimensions and position of a frame is
kind of broken.

The part related to tool-bars has already been (briefly) discussed in
bug#14795. Fortunately I found a workaround for desktop-restore-frames
(set tool-bar-lines to 0, create/modify frame, set tool-bar-lines back
to its intended value).

Now I'm dealing with something related to bug#25 (yeah, the report is
that old, and even older), which Glenn merged with #14795 though they
are really different.

The problem I'm seeing is this:

  emacs -Q
  M-: (frame-height) <RET>    => 38   ;; (1)
  ;; Now, make the frame narrower until the menu wraps just after "Tools"
  M-: (frame-height) <RET>    => 36   ;; (2)
  ;; For extra fun, make the frame just wide enough to wrap after "Help"
  M-: (frame-height) <RET>    => 38   ;; (3)

(1) is the "real" height, or at least, what we do say that's the real height.
(2) happens even when (frame-parameter nil 'menu-bar-lines) is still 1
(3) happens (depending on your default font, I suppose), because when you do
    M-: whatever you're using the minibuffer menu, which has less items.

If all that behavior is considered sane, I'm spechless.

To fix that problem for desktop-restore-frames (and it is a problem,
because a frame with a wrapped menu gets shorter and shorter with each
save/restore cycle). other than adding new APIs to get real
dimensions, the only answer I can think of is

  (let ((mblines (frame-parameter *f* 'menu-bar-lines)))
    (set-frame-parameter *f* 'menu-bar-lines 0)
    (prog1
        (frame-height *f*)
      (set-frame-parameter *f* 'menu-bar-lines mblines)))

which works, but it is visible to the user (removing the menu, even
briefly, obviously triggers redisplay of the frame).

Which brings me to that other problem:

Just yesterday I added a fix for saving & restoring iconified frames.
Iconified frames have nonsensical positions (left + -32000) (top +
-32000), so I have to remove them to allow Emacs to set them at a
default position when restored. The ideal answer would be to get the
real position of the de-iconified frame, but again... to get these
values I must de-iconize, record the values, re-iconize again... which
is visible to the user.

And the same happens with maximized / fullscreen / fullwidth /
fullheight frames. I'm not storing their original size & position to
avoid the user the "flash" of restoring/maximizing back.

At this point, I'm really thinking of just adding an option
desktop-restore-frames-extra-accurate (name irrelevant) that, when
set, will give me permission to freely manipulate (temporarily)
frames' menu bars, tool bars, maximized states and whatever I need in
order to get the correct info. The user will trade a bit of discomfort
when saving the desktop for a better restoring experience.

But, to get back on track, I strongly believe we need better ways of
asking about basic frame metrics. Does anyone else agree, or I'm being
grumpy and unreasonable?

     J

Re: frame size&position woes

[Juanma Barranquero]

On Sun, Jul 21, 2013 at 2:56 PM, Juanma Barranquero <lekktu@gmail.com> wrote:

>   ;; For extra fun, make the frame just wide enough to wrap after "Help"

s/after/before/

Re: frame size&position woes

[martin rudalics]

 > Now I'm dealing with something related to bug#25 (yeah, the report is
 > that old, and even older), which Glenn merged with #14795 though they
 > are really different.
 >
 > The problem I'm seeing is this:
 >
 >   emacs -Q
 >   M-: (frame-height) <RET>    => 38   ;; (1)
 >   ;; Now, make the frame narrower until the menu wraps just after "Tools"
 >   M-: (frame-height) <RET>    => 36   ;; (2)
 >   ;; For extra fun, make the frame just wide enough to wrap after "Help"

Gets me still 36 (wrapping _before_ "Help").

 >   M-: (frame-height) <RET>    => 38   ;; (3)
 >
 > (1) is the "real" height, or at least, what we do say that's the real height.

It's not possible to tell what the real height of a frame is.

 > (2) happens even when (frame-parameter nil 'menu-bar-lines) is still 1

FWIW this parameter is ignored on Windows since the later itself resizes
the menubar (basically, we'd have to deduce the number of lines from the
frame heights).  One can, however, truncate menubars on Windows which is
the default on GNU/Linux

 > (3) happens (depending on your default font, I suppose), because when you do
 >     M-: whatever you're using the minibuffer menu, which has less items.

I'm not sure what you mean here.  Note that on Windows the toolbar is
included in the frame's height.

 > If all that behavior is considered sane, I'm spechless.

IIRC Windows won't tell you whether it wrapped the menubar.  So you can
tell only by comparing the sizes of the outer rectangle and the client
rectangle taking into account the font of the menubar.

 > To fix that problem for desktop-restore-frames (and it is a problem,
 > because a frame with a wrapped menu gets shorter and shorter with each
 > save/restore cycle). other than adding new APIs to get real
 > dimensions, the only answer I can think of is
 >
 >   (let ((mblines (frame-parameter *f* 'menu-bar-lines)))
 >     (set-frame-parameter *f* 'menu-bar-lines 0)
 >     (prog1
 >         (frame-height *f*)
 >       (set-frame-parameter *f* 'menu-bar-lines mblines)))
 >
 > which works, but it is visible to the user (removing the menu, even
 > briefly, obviously triggers redisplay of the frame).

I never tried too experiment with invisible frames and getting
information from them.  Maybe they could be used here.

 > Which brings me to that other problem:
 >
 > Just yesterday I added a fix for saving & restoring iconified frames.
 > Iconified frames have nonsensical positions (left + -32000) (top +
 > -32000), so I have to remove them to allow Emacs to set them at a
 > default position when restored. The ideal answer would be to get the
 > real position of the de-iconified frame, but again... to get these
 > values I must de-iconize, record the values, re-iconize again... which
 > is visible to the user.

On Windows you should be able to get the normal position and size of an
iconified frame.  I'm not sure about other systems.  In the worst case
we'd have to save them before processing an iconify request.

 > And the same happens with maximized / fullscreen / fullwidth /
 > fullheight frames. I'm not storing their original size & position to
 > avoid the user the "flash" of restoring/maximizing back.

We could "store" the values softly, that is, not via
`modify-frame-parameters'.

 > At this point, I'm really thinking of just adding an option
 > desktop-restore-frames-extra-accurate (name irrelevant) that, when
 > set, will give me permission to freely manipulate (temporarily)
 > frames' menu bars, tool bars, maximized states and whatever I need in
 > order to get the correct info. The user will trade a bit of discomfort
 > when saving the desktop for a better restoring experience.
 >
 > But, to get back on track, I strongly believe we need better ways of
 > asking about basic frame metrics. Does anyone else agree, or I'm being
 > grumpy and unreasonable?

We have not even agreed upon what frame metrics are.  Asking here will
get you at least five different opinions.

martin

Re: frame size&position woes

[Juanma Barranquero]

On Sun, Jul 21, 2013 at 4:03 PM, martin rudalics <rudalics@gmx.at> wrote:

> Gets me still 36 (wrapping _before_ "Help").

Yep, that depends on the font, etc. But the menu for the minibuffer
has fewer items that the menu for lisp-interaction, so if you play a
little with the frame width, you'll get to a point where the menu for
the main window is wrapped, but still M-: (frame-height) <RET> gets
you the same size that if it weren't, because during M-:
(frame-height), it is not.

>> (1) is the "real" height, or at least, what we do say that's the real
>> height.
>
> It's not possible to tell what the real height of a frame is.

Didn't I say as much?

>> (2) happens even when (frame-parameter nil 'menu-bar-lines) is still 1
>
> FWIW this parameter is ignored on Windows since the later itself resizes
> the menubar (basically, we'd have to deduce the number of lines from the
> frame heights).

Yes, so perhaps the trouble that I'm reporting only happens on
Windows. It's still quite real and annoying, though.

> One can, however, truncate menubars on Windows which is
> the default on GNU/Linux

Assuming that IUYC, I'm surprised that's the default on GNU/Linux. Is
there any key combo or another UI element to get to the truncated menu
entries?

>> (3) happens (depending on your default font, I suppose), because when you
>> do
>>     M-: whatever you're using the minibuffer menu, which has less items.
>
> I'm not sure what you mean here.  Note that on Windows the toolbar is
> included in the frame's height.

I'm not talking about the toolbar, but what I explained above, about
the wrapped menu bar.

> IIRC Windows won't tell you whether it wrapped the menubar.  So you can
> tell only by comparing the sizes of the outer rectangle and the client
> rectangle taking into account the font of the menubar.

Wonderful. All this boils down to something we discussed earlier: it
would be useful to have an API to get the height of a complete frame,
in some units (pixels, etc.), like frame-pixel-height, but coherent
across toolkits. And, a way to create or resize a frame using these
same units; I don't think that's possible right now, is it?

> I never tried too experiment with invisible frames and getting
> information from them.  Maybe they could be used here.

I've tried making frames invisible and trying to extract information
from them. Doesn't really work (depends on the info, I think) and
making a frame invisible and visible again is also user noticeable.

> On Windows you should be able to get the normal position and size of an
> iconified frame.  I'm not sure about other systems.  In the worst case
> we'd have to save them before processing an iconify request.

But it is not really useful if it's not done for all window systems /
GUI toolkits.

> We could "store" the values softly, that is, not via
> `modify-frame-parameters'.

When and how? Storing them via m-f-p is not a problem, as long as they
are not called left/top/width/height, BTW.

> We have not even agreed upon what frame metrics are.  Asking here will
> get you at least five different opinions.

Yep. But meanwhile, what we have is a mishmash of metrics, options,
units and whatnot.

   J

Re: frame size&position woes

[Juanma Barranquero]

> Yep. But meanwhile, what we have is a mishmash of metrics, options,
> units and whatnot.

And absolutely crazy behavior like this:

emacs -Q
M-x ielm <RET>

ELISP> (setq *f* (make-frame '((width . 20) (height . 40))))
#<frame emacs@ODIEONE 04e57a28>
ELISP> (defun testf (lines)
         (set-frame-parameter *f* 'menu-bar-lines lines)
         (cons (frame-height *f*)
               (frame-pixel-height *f*)))
testf
ELISP> (testf 0)
(40 . 650)

ELISP> (testf 1)
(40 . 640)

ELISP> (testf 0)
(37 . 602)

ELISP> (testf 1)
(37 . 592)

ELISP> (testf 0)
(34 . 554)

ELISP> (testf 1)
(34 . 544)

ELISP> (testf 0)
(31 . 506)

ELISP> (testf 1)
(31 . 496)

Re: frame size&position woes

[martin rudalics]

 > Yep, that depends on the font, etc. But the menu for the minibuffer
 > has fewer items that the menu for lisp-interaction, so if you play a
 > little with the frame width, you'll get to a point where the menu for
 > the main window is wrapped, but still M-: (frame-height) <RET> gets
 > you the same size that if it weren't, because during M-:
 > (frame-height), it is not.

Admittedly, it's not easy to specify what the height should be in this
case.

 > Assuming that IUYC, I'm surprised that's the default on GNU/Linux. Is
 > there any key combo or another UI element to get to the truncated menu
 > entries?

There are various ways to deal with this.  Here on Windows most
GUN/Linux-derived applications either truncate menu bar entries if they
don't fit or don't allow to make a window smaller than the actual width
of its menu bar.  Application display a combo box usually only for
objects they draw themselves.

 > Wonderful. All this boils down to something we discussed earlier: it
 > would be useful to have an API to get the height of a complete frame,
 > in some units (pixels, etc.), like frame-pixel-height, but coherent
 > across toolkits. And, a way to create or resize a frame using these
 > same units; I don't think that's possible right now, is it?

IIUC on Windows we would need a function like `w32-frame-rect' I posted
earlier and, in addition, need access to a NONCLIENTMETRICS structure to
determine whether the menubar wrapped or its font is just too high.
This means that we would have to say whether the height of the window
rectangle minus those of client rectangle, caption and two borders
equals the height of a menubar (or some multiple).

 >> I never tried too experiment with invisible frames and getting
 >> information from them.  Maybe they could be used here.
 >
 > I've tried making frames invisible and trying to extract information
 > from them. Doesn't really work (depends on the info, I think) and
 > making a frame invisible and visible again is also user noticeable.

The idea would be to start with an invisible frame and making it visible
once we're done.  But I'm 100% sure that many platforms won't get us the
metrics of an invisible frame.

 >> We could "store" the values softly, that is, not via
 >> `modify-frame-parameters'.
 >
 > When and how? Storing them via m-f-p is not a problem, as long as they
 > are not called left/top/width/height, BTW.

I hardly ever know whether and when `modify-frame-parameters' has a
visible effect.  This function is a time bomb.

martin

Re: frame size&position woes

[Juanma Barranquero]

On Mon, Jul 22, 2013 at 10:22 AM, martin rudalics <rudalics@gmx.at> wrote:

> Admittedly, it's not easy to specify what the height should be in this
> case.

Which highlights that the usefulness of `frame-height' is relatively limited.

> There are various ways to deal with this.  Here on Windows most
> GUN/Linux-derived applications

(I suppose GUN/Linux is a NRA-approved GNU/Linux distribution? ;-)

> either truncate menu bar entries if they
> don't fit or don't allow to make a window smaller than the actual width
> of its menu bar.

Honestly, at this point I'd rather have Emacs do one of these things,
that the current "incredible shrinking frame" phenomenon with wrapping
menus that I reported in another message.

> IIUC on Windows we would need a function like `w32-frame-rect' I posted
> earlier and, in addition, need access to a NONCLIENTMETRICS structure to
> determine whether the menubar wrapped or its font is just too high.
> This means that we would have to say whether the height of the window
> rectangle minus those of client rectangle, caption and two borders
> equals the height of a menubar (or some multiple).

I love how two simple requests: "Can I have the dimensions of that
frame, please?" and "Can I create another frame with that very same
metrics?" get so complex and GUI dependent answers.

> The idea would be to start with an invisible frame and making it visible
> once we're done.  But I'm 100% sure that many platforms won't get us the
> metrics of an invisible frame.

Yeah, I suspect as much.

> I hardly ever know whether and when `modify-frame-parameters' has a
> visible effect.  This function is a time bomb.

I'd agree that modify-frame-parameters (and/or the frame parameters
per se) are a bit underspecified, yes.

   J

Re: frame size&position woes

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Mon, 22 Jul 2013 11:40:49 +0200
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> On Mon, Jul 22, 2013 at 10:22 AM, martin rudalics <rudalics@gmx.at> wrote:
> 
> > Admittedly, it's not easy to specify what the height should be in this
> > case.
> 
> Which highlights that the usefulness of `frame-height' is relatively limited.

Is your problem, in practice, only with those weirdo frames that have
their tool bars and/or menu bars wrapped?  Or do you have problems
with the more "dull" use cases as well?

If the latter, can you describe the unsolved problem(s) you have in
that case?

> Honestly, at this point I'd rather have Emacs do one of these things,
> that the current "incredible shrinking frame" phenomenon with wrapping
> menus that I reported in another message.

People who wrap menus deserve that.

> I love how two simple requests: "Can I have the dimensions of that
> frame, please?" and "Can I create another frame with that very same
> metrics?" get so complex and GUI dependent answers.

It's not complex.  AFAIK, "(make-frame '((height . N)))" creates a
frame whose "(frame-height)" returns N plus the value returned by
tool-bar-lines-needed.  I expect the same to be true on X, with the
exception of a GTK build, where we might need to do something special.

Does this solve the problem with visible frames?  If not, what is
left?

Re: frame size&position woes

[Juanma Barranquero]

On Mon, Jul 22, 2013 at 5:52 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> Is your problem, in practice, only with those weirdo frames that have
> their tool bars and/or menu bars wrapped?  Or do you have problems
> with the more "dull" use cases as well?

Tool bars are much better behaved than menu bars, even when wrapped,
though there's bug#14795, that some consider a feature. "Dull" use
cases, as you say, don't pose any problem (or none related to frame
size anyway; there's still things to fix but unrelated to the physical
appearance of frames).

> If the latter, can you describe the unsolved problem(s) you have in
> that case?

The biggest problem right now is not related to frame-height, but
frame-pixel-height, that is, we'd need a function that returned (for
every available window system and toolkit) the real width & height of
an Emacs frame in pixels, not of the client area, but the whole frame.
It's the only sane way to check whether a frame is currently visible
in a monitor.

> People who wrap menus deserve that.

On one hand, I agree with you. It's ugly and I would never do it. On
the other hand, I'm not trying to make desktop-restore-frames work for
me, but for as many users as possible. And we have an elisp API to
create a frame without menu-bar or remove it from one (via frame
parameters), but I don't think we have a UI command to do that, so if
the user wants to use menus, but s/he also wants to have a narrow
frame for some reason (let's say, to follow the output of some command
which only prints short lines), s/he's forced to make the frame wider,
or accept a wrapped menu. If s/he then saves & restores...

> It's not complex.  AFAIK, "(make-frame '((height . N)))" creates a
> frame whose "(frame-height)" returns N plus the value returned by
> tool-bar-lines-needed.

I didn't even know that tool-bar-lines-needed existed. Anyway, I still
think it's horrible that height means something different for
make-frame and set-frame-parameter/modify-frame-parameters, but as
there are workarounds, I won't argue the point again.

> I expect the same to be true on X, with the
> exception of a GTK build, where we might need to do something special.

Well, let's hope someone tries desktop-restore-frames on GTK and
reports the result.

> Does this solve the problem with visible frames?  If not, what is
> left?

As said above, knowing their real, physical size in pixels, instead of
some Emacs interpretation of it in arbitrary "character" units, would
be helpful.

   Juanma

Re: frame size&position woes

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Mon, 22 Jul 2013 22:36:33 +0200
> Cc: martin rudalics <rudalics@gmx.at>, Emacs developers <emacs-devel@gnu.org>
> 
> > If the latter, can you describe the unsolved problem(s) you have in
> > that case?
> 
> The biggest problem right now is not related to frame-height, but
> frame-pixel-height, that is, we'd need a function that returned (for
> every available window system and toolkit) the real width & height of
> an Emacs frame in pixels, not of the client area, but the whole frame.
> It's the only sane way to check whether a frame is currently visible
> in a monitor.

Why do you need all that?  Isn't frame-height, frame-width, and the
top and left frame parameters enough to restore the frame's dimensions
and position?

> > People who wrap menus deserve that.
> 
> On one hand, I agree with you. It's ugly and I would never do it. On
> the other hand, I'm not trying to make desktop-restore-frames work for
> me, but for as many users as possible. And we have an elisp API to
> create a frame without menu-bar or remove it from one (via frame
> parameters), but I don't think we have a UI command to do that, so if
> the user wants to use menus, but s/he also wants to have a narrow
> frame for some reason (let's say, to follow the output of some command
> which only prints short lines), s/he's forced to make the frame wider,
> or accept a wrapped menu. If s/he then saves & restores...

...then the frame will not be restored to the exact size it was, but
maybe one or two lines more or less.  I don't see a big problem here,
it's a marginal use case, one I doubt even exists.

Re: frame size&position woes

[Juanma Barranquero]

On Tue, Jul 23, 2013 at 4:45 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> Why do you need all that?  Isn't frame-height, frame-width, and the
> top and left frame parameters enough to restore the frame's dimensions
> and position?

This is not about restoring the frame size & position, is about
knowing whether it intersects with some monitor.

Some people want for desktop-restore-frames to move on-screen frames
that are wholly off-screen. The only way to know the screen dimensions
is via `frame-monitor-attributes', which answers in pixels. Without
the real, window manager style physical size of a frame in pixels, all
we can do is crude heuristics.

> ...then the frame will not be restored to the exact size it was, but
> maybe one or two lines more or less.  I don't see a big problem here,
> it's a marginal use case, one I doubt even exists.

Which is a way to say, we won't jump through complex hoops to fix it.
Fine. I'm trying all the simple ones first, because big or not, it's
still a problem. Restoring "one or two lines more or less" is not a
big failure, but it is also not a good result for code whose only
purpose is to restore frames' sizes and positions.

Re: frame size&position woes

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Wed, 24 Jul 2013 01:47:51 +0200
> Cc: martin rudalics <rudalics@gmx.at>, Emacs developers <emacs-devel@gnu.org>
> 
> Some people want for desktop-restore-frames to move on-screen frames
> that are wholly off-screen. The only way to know the screen dimensions
> is via `frame-monitor-attributes', which answers in pixels. Without
> the real, window manager style physical size of a frame in pixels, all
> we can do is crude heuristics.

You should be able to approximate that by multiplying the
character-unit dimensions by the pixel size of the default face's
font.  The result might be a few pixels off, but I don't see that as a
grave problem, at least not until we have better facilities.

> Restoring "one or two lines more or less" is not a big failure, but
> it is also not a good result for code whose only purpose is to
> restore frames' sizes and positions.

It's good enough for me, because currently I have to restore my frames
manually every time I quit and restart Emacs for some reason.

Re: frame size&position woes

[Juanma Barranquero]

On Wed, Jul 24, 2013 at 5:55 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> You should be able to approximate that by multiplying the
> character-unit dimensions by the pixel size of the default face's
> font.

Yes. That's what I called "crude heuristics".

> The result might be a few pixels off, but I don't see that as a
> grave problem, at least not until we have better facilities.

Let's assume there's a new option
`desktop-restore-frames-move-onscreen'. If the user sets it to t, and
I move back a frame that was really visible, but just by a few pixels,
that's a tiny failure. But if I don't move back a frame that is a few
pixels off, and so, harder to access for the user without UI tricks or
M-: (modify-frame-parameters ...), that's a worse problem (not earth
shattering, but definitely not very user-friendly). Which means that,
to be safe, the heuristics must include a small constant factor to err
on the safe side. Crude. So yes, I'll do it, but certainly not having
a get-frame-window-system-metrics pains me.

> It's good enough for me, because currently I have to restore my frames
> manually every time I quit and restart Emacs for some reason.

Uh? Have you filed a bug report about it?

    J

Re: frame size&position woes

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Wed, 24 Jul 2013 12:42:49 +0200
> Cc: martin rudalics <rudalics@gmx.at>, Emacs developers <emacs-devel@gnu.org>
> 
> On Wed, Jul 24, 2013 at 5:55 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > You should be able to approximate that by multiplying the
> > character-unit dimensions by the pixel size of the default face's
> > font.
> 
> Yes. That's what I called "crude heuristics".

Then "crude" must be non-derogatory description.

> Let's assume there's a new option
> `desktop-restore-frames-move-onscreen'. If the user sets it to t, and
> I move back a frame that was really visible, but just by a few pixels,
> that's a tiny failure. But if I don't move back a frame that is a few
> pixels off, and so, harder to access for the user without UI tricks or
> M-: (modify-frame-parameters ...), that's a worse problem (not earth
> shattering, but definitely not very user-friendly). Which means that,
> to be safe, the heuristics must include a small constant factor to err
> on the safe side. Crude. So yes, I'll do it, but certainly not having
> a get-frame-window-system-metrics pains me.

Is that something rounding up to the next integral multiple of the
default font size couldn't take care of?  IOW, err on the safe side.

> > It's good enough for me, because currently I have to restore my frames
> > manually every time I quit and restart Emacs for some reason.
> 
> Uh? Have you filed a bug report about it?

No.

Re: frame size&position woes

[Juanma Barranquero]

On Wed, Jul 24, 2013 at 4:37 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> Then "crude" must be non-derogatory description.

It's contrastive, against "non-crude" or "refined" ;-)

> Is that something rounding up to the next integral multiple of the
> default font size couldn't take care of?

IIRC, there are ways to change the default values of the non-client
parts of a Windows window (borders, height of the title bar, etc.) If
not directly to the user, then through add-ons (WindowBlinds, etc.).
Any way to compute the dimensions that does not come directly from the
window manager is going to be approximate.

> IOW, err on the safe side.

In fact, the safest default is to assume that the frame is
narrower/shorter than it really is, which will err towards having to
force it onscreen. So (* (frame-height) (frame-char-height)) and (*
(frame-width) (frame-char-width)) are good defaults.

> No.

May I ask why? If you're having trouble with desktop-restore-frames, I
certainly would be interested in knowing about it.

    Juanma

Re: frame size&position woes

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Wed, 24 Jul 2013 16:51:01 +0200
> Cc: martin rudalics <rudalics@gmx.at>, Emacs developers <emacs-devel@gnu.org>
> 
> > No.
> 
> May I ask why?

Because I was talking about Emacs 24.3.

Re: frame size&position woes

[Juanma Barranquero]

On Wed, Jul 24, 2013 at 6:55 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> Because I was talking about Emacs 24.3.

If you add `desktop-saved-frame-states' to `desktop-globals-to-save'
in your .emacs, 24.3 will not destroy the frame configuration (and
trunk detects this situation and avoids saving the frame state twice).
Any trouble with this setup should be reported as a bug.

   J

Re: frame size&position woes

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Wed, 24 Jul 2013 19:01:59 +0200
> Cc: martin rudalics <rudalics@gmx.at>, Emacs developers <emacs-devel@gnu.org>
> 
> On Wed, Jul 24, 2013 at 6:55 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Because I was talking about Emacs 24.3.
> 
> If you add `desktop-saved-frame-states' to `desktop-globals-to-save'
> in your .emacs, 24.3 will not destroy the frame configuration

My problem is not with frame configuration as data, my problem is with
the frames themselves.  Restoring those is something you work on now
on the trunk, AFAIU, and it's unavailable in 24.3.

Re: frame size&position woes

[Juanma Barranquero]

On Wed, Jul 24, 2013 at 7:41 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> My problem is not with frame configuration as data, my problem is with
> the frames themselves.  Restoring those is something you work on now
> on the trunk, AFAIU, and it's unavailable in 24.3.

OK.

Though, as a test, you could try trunk's desktop.el on 24.3. I don't
see why should it fail, and you'll have frame-saving.