There shouldn't be any repaint problems in PureSwing as there is no lightweight popup optimization, it's simply not needed and it's incompatible with GUI compositors (no effects for such lightweight popups). Heavyweight popups are fast enough (and always were) either by disabling automatic background redraw of native window (not possible in AWT, I work on native backends bypassing AWT completely) or in case of compositors in modern OSs there is nice fade-in/out animation which is even better.

About transparent events, it's interesting idea, especially if the tooltip is translucent. But that would touch only custom tooltips/popups I suppose? As the default behaviour should be that tooltip is always out of way of mouse cursor. I think the transparency of events should be handled directly in JWindow or even JComponent somehow.

This also touches my not so good feeling about event handling in AWT/Swing, like the event consuming mechanism (how one can specify some order or priority?), or some ways to temporarily disable event handlers (if it's not bad in some way...) and other things like that... but I still don't have concrete idea what is exactly wrong (or isn't?), any ideas on this topic?

So I made some nice progress again on PureSwing in last few days Improving the Modern LAF, soon it will completely replace Metal LAF which will be removed as it's not much nice visually and I don't want to maintain it as I'm also doing changes to LAF API. Once done, creating own LAFs will be much easier.

Another thing I'm working on are platform dependant complete replacements of AWT for native window access. Currently I'm working on X11 backend, just basic version of it, rendering using BufferedImage and blitting it into X11 window. Works nicely and I don't even use XSHM optimization yet.

Another aspect is resolving the damned grey rect problem. While Java 6 delivered supposedly the final fix for it, it was done actually more complex and wrongly. Even with the fix there are situations where it occurs. The obvious and well known solution to this problem is to disable automatic background clearing when the window gets unobscured and not doing any fancy coalescing of repaint events.

This also completely solves the well known issue with lightweight vs heavyweight popups. In PureSwing there are only heavyweight as the deactivation of automatic background clearing also handles this very well. Lightweight popups were really just workaround for bad AWT.

Doesn't making it GPL reduce the ability of other people to use the library a great deal over the LGPL?

Hmmm... I guess I don't understand the Classpath exception.    Thanks for the reference and good luck with the library

That shitty class has serialization support or attribute sets.

 

Edit: In fact that class should be renamed "MemoryLeak". Singleton + 4 maps. The most important is weakhashmap with weak values true, but still...

After lot of thinking and researching I've decided the final route the development of native look and feel support in PureSwing will take. The truth is that emulating will be always behind, always imprecise. It's also worth to note that it's not just look and feel, but also accessibility, possible extensibility by 3rd party utilities, new features when upgrading the OS and other aspects.

So the route is to use real native components, but with a twist: any individual component could use non-native version using any LAF. Some complex components such as JTable will be LAF themed (emulating native look and feel) as table support varies a lot between platforms, not to mention various bugs (features). Components like JScrollPane would always use real component so heavyweight native components would be properly clipped.

Another interesting divergence from other native wrapping GUI libraries is that you as a developer would be using ordinary PureSwing classes and the nativeness will be just runtime state, just like standard LAFs are. You could combine non-native window (embeded eg. in OpenGL context) with native windows and even migrate between these at will.

This approach will secure basic components and stuff, but any GUI goes beyond these building blocks, there are differences in higher level stuff, like order of buttons, layout of certain dialogs and windows, use of native components, and the overall  approach of GUI towards the user.

This can't be done just as is, which often is the case of other cross platform GUI libraries. What we need is having the ability to layout certain dialog/window for each platform (slightly) differently. I want to create standalone GUI builder application (possibly embeddable into various IDEs) that can easily allow to design such dialogs with differences. This can also be extended to localization as some languages have quite different length of some texts than others.

Such standalone GUI builder will also fix the issue with current Java GUI builders that are often tied to particular IDE, making use of another one quite difficult.

I would like to hear your opinions on this and other possible ideas how to create really usable cross-platform GUI library that can be used for professional applications without any degree of shame.

Yes I will ignore it, if the native control can't do it, it would be alien to have it in your app. On the other hand there will be platform dependant interfaces with additional options for different platforms for any native widget, so all native options will be exposed.


The emulation of native look and feel would be provided only for some special cases, such as JTables. Not for any other widgets including buttons. You won't have option to just set non-native and have emulated look, instead you'll get totally different look of said button (based on which LAF you will use for that concrete component). So you can do completely custom controls, but not slightly modified native ones.

Also if the native one doesn't support eg. images there is some good reason for it, like the icons not used at all in any application. If you add forcefully such image it will be against native look and feel and this won't be supported.


These are two common approaches. They're both bad. One is great but too expensive for development, other one is heading to ugly application. If you need to choose from two bad options, use the third


You'll get both flexibility and power of native widgets including any platform specific details.

Similarity is only in usage of native widgets.

Unlike SWT, PureSwing:

• has nice Java-ish API
• is universal (can use it in OpenGL contexts and stuff)
• in future: ability to transparently switch any widget to non-native version (either completely custom look or emulated one in case of JTables, etc.), or use entirelly custom LAF without creating own custom widgets (popular for certain kinds of apps) or generally just use of any mix of native/non-native as needed
• has dedicated homepage (eg. SWT notoriously lacks standalone examples download, the homepage is just part of Eclipse site)
• in future: standard standalone GUI builder with ability to customize for various platforms and other stuff
• in future: wrapping of various platform-specific widgets and settings
• in future: better native aligning and spacing (SWT has these quite unnatural) and generally better look (SWT/Eclipse is using too much custom widgets with non-native look, compare to NetBeans that while Swing based has more native overall look)

Current version is still preview release and while some tasks can be already done with it (like OpenGL embedding using my Modern3D library) it's not intended for general usage yet. Expect many API changes in upcoming versions, etc. Therefore only experts and contributors should use it for now.

About the problem, you need to run bytecode instrumentation of JStackAlloc, it's already done for you when using official Ant build script.