xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.

Opened 10 years ago

Closed 10 years ago

Last modified 17 months ago

#98 closed defect (fixed)

Libreoffice splash screen is created with decorations

Reported by: ahuillet Owned by: Antoine Martin
Priority: trivial Milestone:
Component: client Version: 0.2.0
Keywords: Cc:



the splash screen of libreoffice is created by Xpra with decorations (title bar and so on).
When I run libreoffice locally on the same machine the splash screen isn't decorated.

Attachments (2)

xpra-undecorate.patch (2.3 KB) - added by Antoine Martin 10 years ago.
ensures that most window types are undecorated (except NORMAL)
xpra-define-all-x11atoms.patch (5.1 KB) - added by Antoine Martin 10 years ago.
fixes openoffice by defining all the x11 atoms in advance

Download all attachments as: .zip

Change History (9)

comment:1 Changed 10 years ago by Antoine Martin

Status: newaccepted

Assuming this has ever worked properly (test with old version - we never call set_decorated!), here are obvious places to look for this bug:

  • the change to the gtk.Window initialization code, now done via init_window since r640:
            if override_redirect:
                init_window(self, WINDOW_POPUP)
                init_window(self, WINDOW_TOPLEVEL)
  • "transient-for" flag?
  • NAME_TO_HINT mapping?

comment:2 Changed 10 years ago by Antoine Martin

OK, this has never worked properly..

According to ICCCM section 4.1.10 on popup windows, clients can tell the window manager not to decorate a window by:

  • setting WM_TRANSIENT_FOR
  • using override-redirect

Neither is set in this present case! So I don't understand why the window manager would not decorate this splash screen!

In the process, I looked into the "window-type" code, and it looks like the refactoring that moved override-redirect to the common superclass inadvertently sets override redirect windows to the wrong window type if one is not set: this is fixed in r702.

As for explicitly setting set_decorated(False)} in the client, I have code to do this (see forthcoming patch) but this would not help in this case since the window-type hint is not set...

Changed 10 years ago by Antoine Martin

Attachment: xpra-undecorate.patch added

ensures that most window types are undecorated (except NORMAL)

comment:3 Changed 10 years ago by ahuillet

The WM I'm using is Fluxbox. Perhaps this window is decorated with other WMs but I doubt it.. it's a splash screen after all.

comment:4 Changed 10 years ago by Antoine Martin

Downloaded the source and found that it does this to disable decorations:

// The old method of hiding the window decorations
static void suppress_decorations_motif(struct splash* splash)
        unsigned long flags, functions, decorations;
        long input_mode;
    } mwmhints;

    Atom a = XInternAtom( splash->display, "_MOTIF_WM_HINTS", False );

    mwmhints.flags = 15; // functions, decorations, input_mode, status
    mwmhints.functions = 2; // ?
    mwmhints.decorations = 0;
    mwmhints.input_mode = 0;

    XChangeProperty( splash->display, splash->win, a, a, 32,
                     PropModeReplace, (unsigned char*)&mwmhints, 5 );

// This is a splash, set it as such.
// If it fails, just hide the decorations...
static void suppress_decorations(struct splash* splash)
    Atom atom_type = XInternAtom( splash->display, "_NET_WM_WINDOW_TYPE", True );
    Atom atom_splash = XInternAtom( splash->display, "_NET_WM_WINDOW_TYPE_SPLASH", True );

    if ( atom_type != None && atom_splash != None )
        XChangeProperty( splash->display, splash->win, atom_type, XA_ATOM, 32,
                         PropModeReplace, (unsigned char*)&atom_splash, 1 );
        suppress_decorations_motif(splash); // FIXME: Unconditional until Metacity/compiz's SPLASH handling is fixed

Changing the _NET_WM_WINDOW_TYPE property to _NET_WM_WINDOW_TYPE_SPLASH ought to be enough, not sure we want to do anything with _MOTIF_WM_HINTS (this is old legacy stuff)

Changed 10 years ago by Antoine Martin

fixes openoffice by defining all the x11 atoms in advance

comment:5 Changed 10 years ago by Antoine Martin

Resolution: fixed
Status: acceptedclosed

This looks like a bug in openoffice: the x11 atoms do not have to exist in advance to be used.
Workaround applied in r704: we pre-define the values that openoffice wants to use. If we want to go further, the patch above pre-defines all the x11 atoms we use (not sure this is needed - but maybe would avoid some bugs?)

comment:6 Changed 10 years ago by Antoine Martin

Milestone: current

Milestone current deleted

comment:7 Changed 17 months ago by migration script

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/98

Note: See TracTickets for help on using tickets.