* Is it possible let child-frame not hide the mode-line and minibuffer out
@ 2018-02-02 15:57 Feng Shu
2018-02-03 9:05 ` martin rudalics
0 siblings, 1 reply; 6+ messages in thread
From: Feng Shu @ 2018-02-02 15:57 UTC (permalink / raw)
To: Emacs-Devel
When a child-frame move to position (-1 . 0), it will hide its
parent-frame's mode-line and minibuffer, is it possible let child-frame
auto move above a little, and let it not hide its parent-frame's
mode-line and minibuffer?
--
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Is it possible let child-frame not hide the mode-line and minibuffer out
2018-02-02 15:57 Is it possible let child-frame not hide the mode-line and minibuffer out Feng Shu
@ 2018-02-03 9:05 ` martin rudalics
2018-02-04 2:45 ` Feng Shu
0 siblings, 1 reply; 6+ messages in thread
From: martin rudalics @ 2018-02-03 9:05 UTC (permalink / raw)
To: Feng Shu, Emacs-Devel
> When a child-frame move to position (-1 . 0), it will hide its
> parent-frame's mode-line and minibuffer, is it possible let child-frame
> auto move above a little, and let it not hide its parent-frame's
> mode-line and minibuffer?
I'm not sure why a position like (-1 . 0) should do that - did you
mean (0 . -1)?
But what is "auto" move? Positioning and sizing of child frames is
completely left to the caller with one exception: When the parent
frame is resized, the child frame may have to be resized and
repositioned too. IIRC we try to do that proportionally so it's
possible that the parent frame's mode line gets obscured. Is it that
you had in mind?
martin
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Is it possible let child-frame not hide the mode-line and minibuffer out
2018-02-03 9:05 ` martin rudalics
@ 2018-02-04 2:45 ` Feng Shu
2018-02-04 10:02 ` martin rudalics
0 siblings, 1 reply; 6+ messages in thread
From: Feng Shu @ 2018-02-04 2:45 UTC (permalink / raw)
To: martin rudalics; +Cc: Emacs-Devel
[-- Attachment #1: Type: text/plain, Size: 825 bytes --]
martin rudalics <rudalics@gmx.at> writes:
>> When a child-frame move to position (-1 . 0), it will hide its
>> parent-frame's mode-line and minibuffer, is it possible let child-frame
>> auto move above a little, and let it not hide its parent-frame's
>> mode-line and minibuffer?
>
> I'm not sure why a position like (-1 . 0) should do that - did you
> mean (0 . -1)?
>
> But what is "auto" move? Positioning and sizing of child frames is
> completely left to the caller with one exception: When the parent
> frame is resized, the child frame may have to be resized and
> repositioned too. IIRC we try to do that proportionally so it's
> possible that the parent frame's mode line gets obscured. Is it that
> you had in mind?
>
sorry, it is (0 . -1) :-)
If I move a child-frame to (0 . -1), it like this at the moment:
[-- Attachment #2: 1.png --]
[-- Type: image/png, Size: 80460 bytes --]
[-- Attachment #3: Type: text/plain, Size: 86 bytes --]
but I think the below result is more useful when I move a child-frame to
(0 . -1)
[-- Attachment #4: 2.png --]
[-- Type: image/png, Size: 62595 bytes --]
[-- Attachment #5: Type: text/plain, Size: 19 bytes --]
> martin
>
--
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Is it possible let child-frame not hide the mode-line and minibuffer out
2018-02-04 2:45 ` Feng Shu
@ 2018-02-04 10:02 ` martin rudalics
2018-02-04 11:43 ` tumashu
2018-02-05 7:53 ` tumashu
0 siblings, 2 replies; 6+ messages in thread
From: martin rudalics @ 2018-02-04 10:02 UTC (permalink / raw)
To: Feng Shu; +Cc: Emacs-Devel
> but I think the below result is more useful when I move a child-frame to
> (0 . -1)
We should not inhibit placement there just as we allow a frame to hide
the taskbar of the window manager on the desktop. But we could
provide a parameter for child frames that would, if set, accomplish
that.
Could you try coding such a thing? The value to be added in the
y-direction should account for the internal border width of the frame,
the height of the minibuffer, a vertical window divider and the height
of the mode line if these are set. In the x-direction we then should
probably avoid hiding the internal border as well. And we probably
should disable the effect of this if it would cause the child frame to
no more fit into its parent at the top or the right.
martin
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re:Re: Is it possible let child-frame not hide the mode-line and minibuffer out
2018-02-04 10:02 ` martin rudalics
@ 2018-02-04 11:43 ` tumashu
2018-02-05 7:53 ` tumashu
1 sibling, 0 replies; 6+ messages in thread
From: tumashu @ 2018-02-04 11:43 UTC (permalink / raw)
To: martin rudalics; +Cc: Emacs-Devel
--
发自我的网易邮箱手机智能版
在 2018-02-04 18:02:03，"martin rudalics" <rudalics@gmx.at> 写道：
> > but I think the below result is more useful when I move a child-frame to
> > (0 . -1)
>
>We should not inhibit placement there just as we allow a frame to hide
>the taskbar of the window manager on the desktop. But we could
>provide a parameter for child frames that would, if set, accomplish
>that.
>
this is a good idea
>Could you try coding such a thing? The value to be added in the
No, i do not fimilar the relate C and lisp code, the 2.png snapshot just a PS photo :-)
>y-direction should account for the internal border width of the frame,
>the height of the minibuffer, a vertical window divider and the height
>of the mode line if these are set. In the x-direction we then should
>probably avoid hiding the internal border as well. And we probably
>should disable the effect of this if it would cause the child frame to
>no more fit into its parent at the top or the right.
>
>martin
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re:Re: Is it possible let child-frame not hide the mode-line and minibuffer out
2018-02-04 10:02 ` martin rudalics
2018-02-04 11:43 ` tumashu
@ 2018-02-05 7:53 ` tumashu
1 sibling, 0 replies; 6+ messages in thread
From: tumashu @ 2018-02-05 7:53 UTC (permalink / raw)
To: martin rudalics; +Cc: emacs-devel@gnu.org
[-- Attachment #1: Type: text/plain, Size: 1211 bytes --]
I have re-read the elisp documents and found it is not a problem :-), sorry for disturb...
A positive integer always relates the left edge of the frame
to the left edge of its display or parent frame. A negative
integer relates the right frame edge to the right edge of the
display or parent frame.
At 2018-02-04 18:02:03, "martin rudalics" <rudalics@gmx.at> wrote:
> > but I think the below result is more useful when I move a child-frame to
> > (0 . -1)
>
>We should not inhibit placement there just as we allow a frame to hide
>the taskbar of the window manager on the desktop. But we could
>provide a parameter for child frames that would, if set, accomplish
>that.
>
>Could you try coding such a thing? The value to be added in the
>y-direction should account for the internal border width of the frame,
>the height of the minibuffer, a vertical window divider and the height
>of the mode line if these are set. In the x-direction we then should
>probably avoid hiding the internal border as well. And we probably
>should disable the effect of this if it would cause the child frame to
>no more fit into its parent at the top or the right.
>
>martin
[-- Attachment #2: Type: text/html, Size: 1680 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-02-05 7:53 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-02-02 15:57 Is it possible let child-frame not hide the mode-line and minibuffer out Feng Shu
2018-02-03 9:05 ` martin rudalics
2018-02-04 2:45 ` Feng Shu
2018-02-04 10:02 ` martin rudalics
2018-02-04 11:43 ` tumashu
2018-02-05 7:53 ` tumashu
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).
![[-- Attachment #2: 1.png --] [-- Type: image/png, Size: 80460 bytes --]](../../874lmx321z.fsf@163.com/2-1.png){kind=link}
![[-- Attachment #4: 2.png --] [-- Type: image/png, Size: 62595 bytes --]](../../874lmx321z.fsf@163.com/4-2.png){kind=link}