First, let me say that docking frames is a great framework. Really easy to use and fast. But I’m facing some problems (with version 1.0.7 and 1.0.8p3a). I’m using DF common and Java 1.6.0_17.
These problems are the following:
1.)
My application has a view/dockable with an AWT component which uses OpenGL to display a 3D model, but occures with any AWT component, too.
Version 1.0.7 of DF doesnt show the AWT component at its correct location or doesnt paint it at all. If I change the layout the screen flashes and I can see the component for some milliseconds.
In version 1.0.8p3a the component is displaying correct. But version 1.0.8p3a, the location / state manager has the bug (2).
See pictures V108_1 (how it should look like) and v107 (how it looks)
2.)
I’m using a customized eclipse theme but the bug appears in other themes too. When I maximize a stacked docklable (Test2) and minize it back to normal size. The layout is corrupted. The other docklets have a new location or the maximized dockable is not stacked anymore. (see pictures v108_1 (before maximizing) and v108_2 (after normalizing))
Same problem when externalzing and internalizing a dockable. I’m using CGrid to layout the dockables.
In version 1.0.7 all works well, but the 1st bug is a big problem here.
3.)
In my test application I have a JPanel with only one button as content pane for a dockable. If I do a right click in an empty area the popup menu of the title is appearing. (see picture PopUpMenu).
Is there a way to solve these problems or is there some sort of a workaround until these bugs are fixed?
Thanks in advance.
Thomas
Btw. Beni, if you like the customized eclipse theme with the glass look. I could contribute the tab painter to docking frames. The glass painter uses a library of a friend of mine.
That was a bug in 1.0.7, some problems with glass-panes… it was fixed in the first version of 1.0.8
The easiest way would be to insert some Component between your button and the content-pane of the Dockable that takes all space and consumes all events (i.e. attaching a MouseListener to your JPanel should already be enough, even if that listener does not do anything. You just have to ensure that no MouseEvent falls through to the content-pane).
In the Core framework one could simply override “getPopupLocation” of Dockable, I realise this is not going to work for Common.
There is also a mechanism to suppress popups, the interface “ActionPopupSuppressor”. But currently it only has a look at the actions that would show up, not at their position. I’ll change that for the next release.
Yes, placement is not yet optimal. There was already some discussion in other threads like this one. I’m currently working on a more stable solution which will be available in one or two weeks. I would suggest you continue using 1.0.8p3a until then and then try the new solution.
Your customised theme looks really nice. I sure would like to have a copy and maybe incorporate it into the framework; or add it as separate download. (depends on how big this library is you use and what licence it has…).
thanks for your fast response. I added your solution for point 3 to my docking manager and it works like charm
The library of my friend is not so big (about 50kb or so) and licensing would be no problem. I will talk with him next week.
Unfortunately I have to update/rewrite my custom eclipse tab painter, because there are some changes in v1.0.8 of DF. I hope to get it working this weekend, so i could give you a sample application next week
Finally I’ve got my custom eclipse theme working with v1.0.8
I’ve attached a sample application with some other custom components of mine. Hope you like them…
@Beni:
While working on the custom theme, I’ve found another small „bug“.
The decoration painter of the eclipse tab strip paints in foreground, so that all buttons and tabs are overpainted. If this is intended, I think it would be better to have an foreground and background decoration painter.
In my development version of DF, I’ve changed the call sequence within the paint-method of the class EclipseTabPaneContent so that it paint in background.
Wow, looks very fancy. Good suggestion with the background/foreground (and yes, it is intentional that it paints in the foreground), I’ll split up the methods in a paintBackground and a paintForeground version.
Unfortunatelly one weekend was not enough to solve the location-issue, but the hardest parts are written.
