bug#18155: 24.3.92; Honor toolBar resource *before* showing frame

bug#18155: 24.3.92; Honor toolBar resource *before* showing frame

[carlosjosepita]

The elisp reference states that:

> Emacs creates the initial frame before it reads your init file. After
> reading that file, Emacs checks initial-frame-alist, and applies the
> parameter settings in the altered value to the already created initial
> frame.

> If these settings affect the frame geometry and appearance, you'll see
> the frame appear with the wrong ones and then change to the specified
> ones. If that bothers you, you can specify the same geometry and
> appearance with X resources; those do take effect before the frame is
> created. See X Resources.

This is true except when the toolbar is visible. In this case, no matter
the value of the toolBar resource, the frame is initially shown without
a toolbar and then the geometry is modified to fit the toolbar. This
produces unpleasant visual artifacts during emacs startup.

I'm afraid that fixing this will require to add a resource to set the
toolbar position, too. I don't know how viable this is. In case it's not
desirable to implement this feature I think some remark has to be added
to the aforementioned documentation excerpt. Otherwise this is indeed a
bug, as the behavior contradicts what's documented.

Cheers
--
Carlos

bug#18155: 24.3.92; Honor toolBar resource *before* showing frame

[Eli Zaretskii]

> From: carlosjosepita@gmail.com
> Date: Wed, 30 Jul 2014 19:27:14 -0300
> 
> This is true except when the toolbar is visible. In this case, no matter
> the value of the toolBar resource, the frame is initially shown without
> a toolbar and then the geometry is modified to fit the toolbar. This
> produces unpleasant visual artifacts during emacs startup.

Thanks.

Please make a point of using "M-x report-emacs-bug RET" to report
bugs.  In this case, that command would have collected and included in
the report the most relevant information: what toolkit was your Emacs
built with.  With some toolkits, the toolbar is created and shown by
the toolkit code, out of Emacs's control; with others, Emacs itself
draws the toolbar and has full control.  It is not clear which case is
yours.

Please provide that missing information, to make the report more
complete and clear.

bug#18155: 24.3.92; Honor toolBar resource *before* showing frame

[Carlos Pita]

Below is the complete info.
Regards, Carlos.


In GNU Emacs 24.3.92.1 (i686-pc-linux-gnu, GTK+ Version 3.12.2)
 of 2014-07-25 on localhost
Configured using:
 `configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --with-x-toolkit=gtk3 --with-xft
 'CFLAGS=-march=i686 -mtune=generic -O2 -pipe -fstack-protector-strong
 --param=ssp-buffer-size=4' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro'

Important settings:
  value of $LC_COLLATE: en_US.UTF-8
  value of $LC_CTYPE: en_US.UTF-8
  value of $LC_MESSAGES: en_US.UTF-8
  value of $LC_MONETARY: en_US.UTF-8
  value of $LC_NUMERIC: en_US.UTF-8
  value of $LC_TIME: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  gpm-mouse-mode: t
  show-paren-mode: t
  winner-mode: t
  shell-dirtrack-mode: t
  ido-everywhere: t
  global-auto-complete-mode: t
  auto-complete-mode: t
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
C-x 2 ESC x r e s p DEL DEL p o TAB r t - e m TAB 
RET

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...

Load-path shadows:
/home/loscar/.emacs.d/elpa/popup-20140207.1702/popup hides /usr/share/emacs/site-lisp/auto-complete/popup
/home/loscar/.emacs.d/elpa/auto-complete-20140726.303/auto-complete hides /usr/share/emacs/site-lisp/auto-complete/auto-complete
/home/loscar/.emacs.d/elpa/auto-complete-20140726.303/auto-complete-config hides /usr/share/emacs/site-lisp/auto-complete/auto-complete-config
~/.emacs.d/lisp/python hides /usr/share/emacs/24.3.92/lisp/progmodes/python

Features:
(shadow sort mail-extr emacsbug message idna rfc822 mml mml-sec
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mail-utils help-mode
t-mouse flymake paren winner windmove wombat-theme ac-nrepl
cider-interaction apropos arc-mode archive-mode cider-doc org-table org
org-macro org-footnote org-pcomplete org-list org-faces org-entities
noutline outline easy-mmode org-version ob-emacs-lisp ob ob-tangle
org-src ob-ref ob-lob ob-table ob-keys ob-exp ob-comint ob-core ob-eval
org-compat org-macs org-loaddefs find-func cal-menu calendar
cal-loaddefs cider-test cider-stacktrace cider-client nrepl-client
cider-util ewoc etags dash clojure-mode imenu inf-lisp tramp
tramp-compat auth-source eieio byte-opt bytecomp byte-compile cconv
eieio-core gnus-util mm-util mail-prsvr password-cache tramp-loaddefs
cl-macs trampver cl gv ess-toolbar ess-mouse mouseme thingatpt
browse-url ess-menu ess-swv ess-noweb ess-noweb-font-lock-mode
ess-bugs-l essd-els ess-sas-d ess-sas-l ess-sas-a shell pcomplete
ess-sta-d ess-sta-l cc-vars cc-defs make-regexp ess-sp6-d ess-sp3-d
ess-julia ess-r-d compile ess-tracebug format-spec ess-roxy advice
hideshow ess-help ess-developer ess-r-args eldoc help-fns ess-s-l ess
ess-inf comint ansi-color ring ess-mode ess-noweb-mode ess-utils
time-date ess-custom executable ess-compat ess-site ido
auto-complete-config auto-complete edmacro kmacro popup cl-loaddefs
cl-lib info easymenu package tooltip electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core frame cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew
greek romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
gfilenotify dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty emacs)

Memory information:
((conses 8 221331 11150)
 (symbols 24 35290 0)
 (miscs 20 103 187)
 (strings 16 64577 10960)
 (string-bytes 1 1889964)
 (vectors 8 31660)
 (vector-slots 4 1312017 12174)
 (floats 8 198 270)
 (intervals 28 265 0)
 (buffers 512 13)
 (heap 1024 18310 787))

bug#18155: 24.3.92; Honor toolBar resource *before* showing frame

[Eli Zaretskii]

> From: Carlos Pita <carlosjosepita@gmail.com>
> Cc: 18155@debbugs.gnu.org
> Date: Thu, 31 Jul 2014 02:17:52 -0300
> 
> 
> Below is the complete info.

Thanks.

> In GNU Emacs 24.3.92.1 (i686-pc-linux-gnu, GTK+ Version 3.12.2)
>  of 2014-07-25 on localhost
> Configured using:
>  `configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
>  --localstatedir=/var --with-x-toolkit=gtk3 --with-xft
>  'CFLAGS=-march=i686 -mtune=generic -O2 -pipe -fstack-protector-strong
>  --param=ssp-buffer-size=4' CPPFLAGS=-D_FORTIFY_SOURCE=2
>  LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro'

AFAIK, GTK is one of the toolkits which draw their own toolbar.

Perhaps Jan (CC'ed) could tell if your wish can be granted.

bug#18155: 24.3.92; Honor toolBar resource *before* showing frame

[Jan D.]

Eli Zaretskii skrev 2014-07-31 07:53:
>> From: Carlos Pita <carlosjosepita@gmail.com>
>> Cc: 18155@debbugs.gnu.org
>> Date: Thu, 31 Jul 2014 02:17:52 -0300
>>
>>
>> Below is the complete info.
>
> Thanks.
>
>> In GNU Emacs 24.3.92.1 (i686-pc-linux-gnu, GTK+ Version 3.12.2)
>>   of 2014-07-25 on localhost
>> Configured using:
>>   `configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
>>   --localstatedir=/var --with-x-toolkit=gtk3 --with-xft
>>   'CFLAGS=-march=i686 -mtune=generic -O2 -pipe -fstack-protector-strong
>>   --param=ssp-buffer-size=4' CPPFLAGS=-D_FORTIFY_SOURCE=2
>>   LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro'
>
> AFAIK, GTK is one of the toolkits which draw their own toolbar.
>
> Perhaps Jan (CC'ed) could tell if your wish can be granted.
>

As far as I know, for the first frame when .emacs has not been read yet, 
Emacs internally says that no tool bar shall be added.
After .emacs has been read, and tool bar mode is still active (i.e. not 
disabled by .emacs) it adds the tool bar.  So this is generic code that 
is at work.

It does not start with a tool bar and then remove it if .emacs disables 
it.  It is the other way around, starts with no tool bar and then adds it.

	Jan D.

bug#18155: 24.3.92; Honor toolBar resource *before* showing frame

[Eli Zaretskii]

> Date: Thu, 31 Jul 2014 08:57:05 +0200
> From: "Jan D." <jan.h.d@swipnet.se>
> CC: 18155@debbugs.gnu.org
> 
> As far as I know, for the first frame when .emacs has not been read yet, 
> Emacs internally says that no tool bar shall be added.
> After .emacs has been read, and tool bar mode is still active (i.e. not 
> disabled by .emacs) it adds the tool bar.  So this is generic code that 
> is at work.

Thanks.  So I was mistaken: this does not depend on the toolkit.  In
that case, I guess we could change that to work more like the menu
bar, which (AFAIR) is shown on the initial frame.

bug#18155: 24.3.92; Honor toolBar resource *before* showing frame

[Carlos Pita]

[-- Attachment #1: Type: text/plain, Size: 975 bytes --]

Take into account that the geometry will also depend on the toobar position
and there is no documented resource for that, afaics. And then there's the
question of the toolbar style (icons only, icons plus text, etc) but I
guess that is already configurable in the gtk3 css file. Cheers, Carlos.
On Jul 31, 2014 4:11 AM, "Eli Zaretskii" <eliz@gnu.org> wrote:

> > Date: Thu, 31 Jul 2014 08:57:05 +0200
> > From: "Jan D." <jan.h.d@swipnet.se>
> > CC: 18155@debbugs.gnu.org
> >
> > As far as I know, for the first frame when .emacs has not been read yet,
> > Emacs internally says that no tool bar shall be added.
> > After .emacs has been read, and tool bar mode is still active (i.e. not
> > disabled by .emacs) it adds the tool bar.  So this is generic code that
> > is at work.
>
> Thanks.  So I was mistaken: this does not depend on the toolkit.  In
> that case, I guess we could change that to work more like the menu
> bar, which (AFAIR) is shown on the initial frame.
>

[-- Attachment #2: Type: text/html, Size: 1377 bytes --]

bug#18155: 24.3.92; Honor toolBar resource *before* showing frame

[martin rudalics]

 > It does not start with a tool bar and then remove it if .emacs disables it.  It is the other way around, starts with no tool bar and then adds it.

IIUC this is what Carlos mentioned.  On systems with internal toolbars,
however, we initially assume that the toolbar exists and later on remove
it if the user doesn't want it.  And the real initial height of an
internal toolbar is only known after the redisplay algorithm has passed
over it for the first time.

martin

bug#18155: 24.3.92; Honor toolBar resource *before* showing frame

[Carlos Pita]

[-- Attachment #1: Type: text/plain, Size: 1423 bytes --]

I see 3 different approches to deal with this issue:

1. It doesn't matter, it's just a cosmetic issue and it's not worth the
effort. Besides it won't completely eliminate the startup ugliness because
default and initial frame parameters could be different and so one of them
won't match the resources anyway. In this case I would just remove the
misleading assertion from the manual, in order to avoid false expectations.

2. Keep the frame window unmapped until it's completely initialized and
then make it visible. If startup is taking too long, show a splash while
launching. This is a pretty straightforward solution, at least conceptually.

3. Fix it so that the frame won't be resized during startup.

I'm completely unable to measure the complexity of doing 2 or 3. If these
tasks are anything above easy I could certainly live in a world where 1 is
true.
On Jul 31, 2014 5:49 AM, "martin rudalics" <rudalics@gmx.at> wrote:

> > It does not start with a tool bar and then remove it if .emacs disables
> it.  It is the other way around, starts with no tool bar and then adds it.
>
> IIUC this is what Carlos mentioned.  On systems with internal toolbars,
> however, we initially assume that the toolbar exists and later on remove
> it if the user doesn't want it.  And the real initial height of an
> internal toolbar is only known after the redisplay algorithm has passed
> over it for the first time.
>
> martin
>

[-- Attachment #2: Type: text/html, Size: 1758 bytes --]

bug#18155: 24.3.92; Honor toolBar resource *before* showing frame

[Jan Djärv]

Hi. 

31 jul 2014 kl. 09:11 skrev Eli Zaretskii <eliz@gnu.org>:

>> Date: Thu, 31 Jul 2014 08:57:05 +0200
>> From: "Jan D." <jan.h.d@swipnet.se>
>> CC: 18155@debbugs.gnu.org
>> 
>> As far as I know, for the first frame when .emacs has not been read yet, 
>> Emacs internally says that no tool bar shall be added.
>> After .emacs has been read, and tool bar mode is still active (i.e. not 
>> disabled by .emacs) it adds the tool bar.  So this is generic code that 
>> is at work.
> 
> Thanks.  So I was mistaken: this does not depend on the toolkit.  In
> that case, I guess we could change that to work more like the menu
> bar, which (AFAIR) is shown on the initial frame.

When I looked at this, the tool bar items where not initialised at frame creation.  So there where no items to put there even if we did show the toolbar. For Gtk it will show a bar a few pixels high.  It is hard to figure out how high an item will be later on as this depends on the size of the image, padding and so on. 

     Jan D. 

bug#18155: 24.3.92; Honor toolBar resource *before* showing frame

[Jan Djärv]

[-- Attachment #1: Type: text/plain, Size: 1649 bytes --]

Hi. 

2 is the way to go IMHO. 
3 is way harder. 
But so far we have done 1...

    Jan D. 

> 31 jul 2014 kl. 11:12 skrev Carlos Pita <carlosjosepita@gmail.com>:
> 
> I see 3 different approches to deal with this issue:
> 
> 1. It doesn't matter, it's just a cosmetic issue and it's not worth the effort. Besides it won't completely eliminate the startup ugliness because default and initial frame parameters could be different and so one of them won't match the resources anyway. In this case I would just remove the misleading assertion from the manual, in order to avoid false expectations.
> 
> 2. Keep the frame window unmapped until it's completely initialized and then make it visible. If startup is taking too long, show a splash while launching. This is a pretty straightforward solution, at least conceptually.
> 
> 3. Fix it so that the frame won't be resized during startup.
> 
> I'm completely unable to measure the complexity of doing 2 or 3. If these tasks are anything above easy I could certainly live in a world where 1 is true.
> 
>> On Jul 31, 2014 5:49 AM, "martin rudalics" <rudalics@gmx.at> wrote:
>> > It does not start with a tool bar and then remove it if .emacs disables it.  It is the other way around, starts with no tool bar and then adds it.
>> 
>> IIUC this is what Carlos mentioned.  On systems with internal toolbars,
>> however, we initially assume that the toolbar exists and later on remove
>> it if the user doesn't want it.  And the real initial height of an
>> internal toolbar is only known after the redisplay algorithm has passed
>> over it for the first time.
>> 
>> martin

[-- Attachment #2: Type: text/html, Size: 2213 bytes --]

bug#18155: 24.3.92; Honor toolBar resource *before* showing frame

[Eli Zaretskii]

> Cc: "carlosjosepita@gmail.com" <carlosjosepita@gmail.com>,
>  "18155@debbugs.gnu.org" <18155@debbugs.gnu.org>
> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Thu, 31 Jul 2014 13:29:23 +0200
> 
> > Thanks.  So I was mistaken: this does not depend on the toolkit.  In
> > that case, I guess we could change that to work more like the menu
> > bar, which (AFAIR) is shown on the initial frame.
> 
> When I looked at this, the tool bar items where not initialised at frame creation.  So there where no items to put there even if we did show the toolbar. For Gtk it will show a bar a few pixels high.  It is hard to figure out how high an item will be later on as this depends on the size of the image, padding and so on. 

Yes, of course.  However, tool-bar buttons are (by default) created
from certain menu-bar items.  And since (AFAIR) we do show the menu
bar when the frame is created, we could at the same time compute and
display the tool bar.

bug#18155: 24.3.92; Honor toolBar resource *before* showing frame

[Stefan Monnier]

> 2 is the way to go IMHO. 

An alternative to 2 is to create the GUI terminal later in
startup.el.  This way, all the .emacs code is read while the selected
terminal is the "dumb" initial terminal, e.g. messages are sent to
stderr and the GUI frame is created after the .emacs is read so it can
take user settings. into account.

I've been using a local patch that does it for several years, very
happily, but of course, it will break any ~/.emacs that tries to check
things like screen size.


        Stefan