Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Externalize does not repaint frame #41

Open
Sciss opened this issue Apr 11, 2016 · 6 comments
Open

Externalize does not repaint frame #41

Sciss opened this issue Apr 11, 2016 · 6 comments

Comments

@Sciss
Copy link

Sciss commented Apr 11, 2016

I am seeing this problem both with 1.1.1 and latest snapshot and across different JVM (OpenJDK 6, OpenJDK 7, Oracle JDK 8) and look-and-feels (Motif, Metal, Native, ...), so assume it's a bug in docking-frames. I have a very simple layout with one single and one multi dock. If I try to externalise either frame, I just get a blank rectangle, the frame is not painted (neither border decoration nor content). I have to explicitly deactivate and reactive the window and then move it to have it fully painted.

1_before_externalize
2_after_externalize
3_after_reactivating_and_resizing

@Benoker
Copy link
Owner

Benoker commented Apr 12, 2016

Swing is broken in Linux since about version 1.6. Not just Docking-Frames has repaint issues, any application that uses more than one frame has issues (we have a nice Swing application at my workplace that does not work properly on many different Linux computers).

@Sciss
Copy link
Author

Sciss commented Apr 13, 2016

This is simply not true. I am using a great number of Swing based multi-window applications. It may be that there are bugs, but they are usually not consistent across OpenJDK 6, OpenJDK 7 and Oracle JDK 8. I am sure there are possible work-arounds. For example, is it possible to turn off the animation that creates the externalised frame?

@Sciss
Copy link
Author

Sciss commented Apr 13, 2016

Making the dialog displayable by calling pack in ScreenDockDialog.java mostly fixes this problem:

        if( undecorated ){
            dialog.setUndecorated( true );
            dialog.getRootPane().setWindowDecorationStyle( JRootPane.NONE );
            dialog.pack();  // N.B. required for Linux
        }

@Sciss
Copy link
Author

Sciss commented Apr 13, 2016

The second change necessary is calling updateBorder in the Listener in AbstractScreenDockWindow, e.g. by adding a constructor:

        private Listener() {
            updateBorder();
        }

@Benoker
Copy link
Owner

Benoker commented Apr 13, 2016

pack may be a bit dangerous, that could have unwanted side effects (like the size of the dialog not being the expected size). I'll try out your fixes, I'm really curious to see if these changes help on my system too (due to having a new computer I first need to reinstall my Ubuntu... could take a while).

@Sciss
Copy link
Author

Sciss commented Apr 13, 2016

I double checked that the size is not initialised at that moment. If there is doubt, one may just paste the contents of pack minus setting the size:

  Container parent = this.parent;
  if (parent != null && parent.getPeer() == null) {
    parent.addNotify();
  }
  if (peer == null) {
    addNotify();
  }

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants