bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations

[Robert Marshall]

martin rudalics writes:
 > 
 > Thanks.  According to that dump you should see the minibuffer.

Definitely no minibuffer, I had to do the M-: commands very carefully
as I couldn't see what I was typing!

> What
 > does evaluating
 > 
 > M-: (frame-parameter nil 'minibuffer)

Unfortunately after Juanma's suggested change (and then reverting it
and an emacs restart) I get the frame *with* a minibuffer but without
the window decorations.

When that command gives me:

#<window 4 on  *Minibuf-0*>

but that is probably not relevant in the new situation
> 
 > give?  The fact that no title bar is visible is even more strange.  Do
 > you see menu bar and scroll bar normally?  Post your screenshot, it's
 > simpler than telling details.

(sorry I wasn't sure if you needed to do something special to
associate an image with a bug report, I'm just attaching it to the
email) I'm attaching the screenshot together with a normal emacs frame
for comparison

I'm running with a fairly standard kde plasma desktop - so the bit
above the menu bar is all missing (and the left hand frame is the
faulty one)


 > And what happens when you maximize the
 > frame and restore its normal size immediately afterwards?
 > 

Ah now that's interesting! When I maximize - selecting the relevant
frame in the toolbar and using that popup WM menu option (I've also
tried using M-<f10> and get the same result) the frame moves to the
top left of the screen but *doesn't* maximise it remains (AFAICT)
the same size and the minibuffer now disappears! With no minibuffer I
then get

#<window 4 on  *Minibuf-1*>

for the frame parameter. When I take off maximisation the minibuffer
is restored - but still no window decorations.  Is this a kde/plasma
bug - or maybe a gtk/plasma bug?

Robert
-- 
Robert Marshall