Re: [Exploding Pixels] New Comment On: Why can't Safari get tabs right?

[Harald Kuhr]

On 11. juni. 2009, at 14.01, WordPress.com wrote:

> It would be possible to visually reproduce the look of Safari 4
> beta. There is one show stopper, however, for Java apps on the Mac:
> when you implement your own resizing mechanism (i.e. you call
> myFrame.setSize(...) in response to some event) there is a terrible
> flicker. This is why my HUD component in Mac Widgets for Java is
> currently not resizable. Hopefully this will get fixed soon.
>
> -Ken

Hi again Ken,

I feel I'm polluting your message board with off-topic posts, so I'll
switch to email mode.

I've seen the problem with the flicker, but haven't looked much into
it yet. To be honest, I haven't even been able to smoothly *move* a
window (needed for a proper unified toolbar). Do you have a way? ;-)

The idea is that the pixel in the window, under the cursor should
stick exactly (like it does when you drag the title bar). I'm able to
move the window using mouse motion listeners, or even tracking the
mouse directly. But in any case, it seems like the Swing (or AWT)
setLocation (and others) end up with an invocation of reshape(x, y, w,
h)... And because of window listeners, native calls, etc (probably
more magic I don't know), the window will allways lag behind a few
pixels.

The only way I have found is to make the entire window draggable
(apple.awt.draggableWindowBackground), but that's also not usable with
Swing, as only heavy-weight components will prevent drag...

Best regards,

--
Harald K

[Ken Orr]

Hi Harald,

I've looked into the flicker problem *extensively*, and gone so far as to write JNI code to try and work-around this nasty issue. While I did find an extremely hackish workaround, I wouldn't suggest it because it only worked for Java 1.5 (if I recall correctly).

As for creating a fully draggable Unified Toolbar, I've solved that problem in Mac Widgets for Java. Run the following demo:

http://code.google.com/p/macwidgets/source/browse/trunk/demo/com/explodingpixels/macwidgets/DUnifiedToolbar.java

Any part of the Unified Toolbar that doesn't have a component on top of it is draggable. You'll also note that I use the same technique in:

http://code.google.com/p/macwidgets/source/browse/trunk/demo/com/explodingpixels/macwidgets/DBottomBar.java

to allow a Bottom Bar to be draggable. You can run:

http://code.google.com/p/macwidgets/source/browse/trunk/demo/com/explodingpixels/macwidgets/DEverything.java

To see both the Unified Toolbar and Bottom Bar in action.

-Ken

[Harald Kuhr]

Hi again Ken,

The problem isn't so much to make the window draggable, that is fairly
simple. I started out with your approcah, but rewrote to something
that tracks the mouse directly because it seems to be smoother. Might
change that again.

Anyway, I think you'll find that moving the window using the "real"
titlebar is smooth, uses almost no CPU, and keeps the mouse position
relative to the window constant. Doing it with Swing will make the
window lag behind the mouse pointer, and the CPU usage go up
significantly. It even seems that the more complex components you
have, the more CPU it uses (and the more it lags behind) making me
believe that painting is going on for each setLocation...

--
Harald K

[Harald Kuhr]

...did some debugging and found that my treetable does a repaint every
time. Now I only need to find out why that happens, as there is no
(good) reason for that.

Best regards,

--
Harald K