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

From: Carlos Pita <[email-masked]>
Date: Thu, 31 Jul 2014 06:12:20 -0300

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" <[email-masked]> 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
>