GNU bug report logs -
#18155
24.3.92; Honor toolBar resource *before* showing frame
Previous Next
Full log
Message #29 received at 18155 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> 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
>
[Message part 2 (text/html, inline)]
This bug report was last modified 10 years and 322 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.