[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jan Djärv
Subject: bug#18155: 24.3.92; Honor toolBar resource *before* showing frame
Date: Thu, 31 Jul 2014 13:32:19 +0200


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 <address@hidden>:

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" <address@hidden> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]