* Mini-window glitch with GTK
@ 2013-01-21 6:34 Dmitry Antipov
2013-01-21 7:15 ` Dani Moncayo
` (3 more replies)
0 siblings, 4 replies; 9+ messages in thread
From: Dmitry Antipov @ 2013-01-21 6:34 UTC (permalink / raw)
To: Emacs development discussions
[-- Attachment #1: Type: text/plain, Size: 311 bytes --]
On Fedora 18 with GTK 3.6.4, height of the minibuffer window looks too large
immediately after startup (screenshot 1), but shrinks to normal after first
input comes (screenshot 2). The problem is easily visible with ./src/emacs -Q,
but doesn't appear with ./src/emacs -Q --execute '(tool-bar-mode 0)'.
Dmitry
[-- Attachment #2: miniwindow1.png --]
[-- Type: image/png, Size: 10427 bytes --]
[-- Attachment #3: miniwindow2.png --]
[-- Type: image/png, Size: 11278 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: Mini-window glitch with GTK
2013-01-21 6:34 Mini-window glitch with GTK Dmitry Antipov
@ 2013-01-21 7:15 ` Dani Moncayo
2013-01-21 17:19 ` Eli Zaretskii
2013-01-21 12:30 ` Xue Fuqiao
` (2 subsequent siblings)
3 siblings, 1 reply; 9+ messages in thread
From: Dani Moncayo @ 2013-01-21 7:15 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: Emacs development discussions
> On Fedora 18 with GTK 3.6.4, height of the minibuffer window looks too large
> immediately after startup (screenshot 1), but shrinks to normal after first
> input comes (screenshot 2). The problem is easily visible with ./src/emacs
> -Q,
> but doesn't appear with ./src/emacs -Q --execute '(tool-bar-mode 0)'.
This same problem occurs on MS-Windows. When the frame is maximized,
the remnant vertical space is put at the very bottom, instead of using
it to show more content on the main window(s).
--
Dani Moncayo
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: Mini-window glitch with GTK
2013-01-21 7:15 ` Dani Moncayo
@ 2013-01-21 17:19 ` Eli Zaretskii
2013-01-21 17:29 ` Dani Moncayo
0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2013-01-21 17:19 UTC (permalink / raw)
To: Dani Moncayo; +Cc: dmantipov, emacs-devel
> Date: Mon, 21 Jan 2013 08:15:04 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Emacs development discussions <emacs-devel@gnu.org>
>
> > On Fedora 18 with GTK 3.6.4, height of the minibuffer window looks too large
> > immediately after startup (screenshot 1), but shrinks to normal after first
> > input comes (screenshot 2). The problem is easily visible with ./src/emacs
> > -Q,
> > but doesn't appear with ./src/emacs -Q --execute '(tool-bar-mode 0)'.
>
> This same problem occurs on MS-Windows. When the frame is maximized,
> the remnant vertical space is put at the very bottom, instead of using
> it to show more content on the main window(s).
I don't think it's the same problem, because this one doesn't go away
when you type something into the minibuffer, as in Dmitry's recipe.
What you see here is normal division of the screen real estate between
windows in Emacs. This is how it was coded.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Mini-window glitch with GTK
2013-01-21 17:19 ` Eli Zaretskii
@ 2013-01-21 17:29 ` Dani Moncayo
0 siblings, 0 replies; 9+ messages in thread
From: Dani Moncayo @ 2013-01-21 17:29 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: dmantipov, emacs-devel
>> > On Fedora 18 with GTK 3.6.4, height of the minibuffer window looks too large
>> > immediately after startup (screenshot 1), but shrinks to normal after first
>> > input comes (screenshot 2). The problem is easily visible with ./src/emacs
>> > -Q,
>> > but doesn't appear with ./src/emacs -Q --execute '(tool-bar-mode 0)'.
>>
>> This same problem occurs on MS-Windows. When the frame is maximized,
>> the remnant vertical space is put at the very bottom, instead of using
>> it to show more content on the main window(s).
>
> I don't think it's the same problem, because this one doesn't go away
> when you type something into the minibuffer, as in Dmitry's recipe.
>
> What you see here is normal division of the screen real estate between
> windows in Emacs. This is how it was coded.
OK. Anyway, there are better ways to use that extra space. IMO it
should be given to the main window(s).
BTW, I filed a bug report about this:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7004
--
Dani Moncayo
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Mini-window glitch with GTK
2013-01-21 6:34 Mini-window glitch with GTK Dmitry Antipov
2013-01-21 7:15 ` Dani Moncayo
@ 2013-01-21 12:30 ` Xue Fuqiao
2013-01-21 13:08 ` Dmitry Antipov
2013-01-21 17:24 ` Eli Zaretskii
3 siblings, 0 replies; 9+ messages in thread
From: Xue Fuqiao @ 2013-01-21 12:30 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: Emacs development discussions
Hi,
On Mon, 21 Jan 2013 10:34:41 +0400
Dmitry Antipov <dmantipov@yandex.ru> wrote:
> On Fedora 18 with GTK 3.6.4, height of the minibuffer window looks too large
> immediately after startup (screenshot 1), but shrinks to normal after first
> input comes (screenshot 2). The problem is easily visible with ./src/emacs -Q,
> but doesn't appear with ./src/emacs -Q --execute '(tool-bar-mode 0)'.
I met the same problem on my system, I have reported it as a bug:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13512
--
Best regards, Xue Fuqiao.
http://www.emacswiki.org/emacs/XueFuqiao
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Mini-window glitch with GTK
2013-01-21 6:34 Mini-window glitch with GTK Dmitry Antipov
2013-01-21 7:15 ` Dani Moncayo
2013-01-21 12:30 ` Xue Fuqiao
@ 2013-01-21 13:08 ` Dmitry Antipov
2013-01-21 17:24 ` Eli Zaretskii
3 siblings, 0 replies; 9+ messages in thread
From: Dmitry Antipov @ 2013-01-21 13:08 UTC (permalink / raw)
To: emacs-devel
On 01/21/2013 10:34 AM, Dmitry Antipov wrote:
> On Fedora 18 with GTK 3.6.4, height of the minibuffer window looks too large
> immediately after startup (screenshot 1), but shrinks to normal after first
> input comes (screenshot 2). The problem is easily visible with ./src/emacs -Q,
> but doesn't appear with ./src/emacs -Q --execute '(tool-bar-mode 0)'.
...and there is no similar problem when --with-x-toolkit=no, --with-x-toolkit=lucid,
--with-x-toolkit=motif or --with-x-toolkit=gtk2 (version 2.24.13) is used.
Dmitry
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Mini-window glitch with GTK
2013-01-21 6:34 Mini-window glitch with GTK Dmitry Antipov
` (2 preceding siblings ...)
2013-01-21 13:08 ` Dmitry Antipov
@ 2013-01-21 17:24 ` Eli Zaretskii
2013-01-22 4:55 ` Dmitry Antipov
3 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2013-01-21 17:24 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: emacs-devel
> Date: Mon, 21 Jan 2013 10:34:41 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
>
> On Fedora 18 with GTK 3.6.4, height of the minibuffer window looks too large
> immediately after startup (screenshot 1), but shrinks to normal after first
> input comes (screenshot 2). The problem is easily visible with ./src/emacs -Q,
> but doesn't appear with ./src/emacs -Q --execute '(tool-bar-mode 0)'.
When it does happen, do you see the frame resize when you type C-x C-f
(or something else that causes minibuffer input)?
If the frame does not resize, does that mean the mode line moves down?
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: Mini-window glitch with GTK
2013-01-21 17:24 ` Eli Zaretskii
@ 2013-01-22 4:55 ` Dmitry Antipov
2013-01-22 7:57 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Dmitry Antipov @ 2013-01-22 4:55 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
On 01/21/2013 09:24 PM, Eli Zaretskii wrote:
> When it does happen, do you see the frame resize when you type C-x C-f
> (or something else that causes minibuffer input)?
The frame is resized by removing extra height from minibuffer window;
size of main window is not changed and mode line is not moved.
Dmitry
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Mini-window glitch with GTK
2013-01-22 4:55 ` Dmitry Antipov
@ 2013-01-22 7:57 ` Eli Zaretskii
0 siblings, 0 replies; 9+ messages in thread
From: Eli Zaretskii @ 2013-01-22 7:57 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: emacs-devel
> Date: Tue, 22 Jan 2013 08:55:31 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> CC: emacs-devel@gnu.org
>
> On 01/21/2013 09:24 PM, Eli Zaretskii wrote:
>
> > When it does happen, do you see the frame resize when you type C-x C-f
> > (or something else that causes minibuffer input)?
>
> The frame is resized by removing extra height from minibuffer window;
> size of main window is not changed and mode line is not moved.
I will respond to the bug report, to have this recorded.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2013-01-22 7:57 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-01-21 6:34 Mini-window glitch with GTK Dmitry Antipov
2013-01-21 7:15 ` Dani Moncayo
2013-01-21 17:19 ` Eli Zaretskii
2013-01-21 17:29 ` Dani Moncayo
2013-01-21 12:30 ` Xue Fuqiao
2013-01-21 13:08 ` Dmitry Antipov
2013-01-21 17:24 ` Eli Zaretskii
2013-01-22 4:55 ` Dmitry Antipov
2013-01-22 7:57 ` Eli Zaretskii
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).