PureSwing

Shared Code
#61

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?

#62

I have no great ideas on that topic. It’s a great mess since swing is a framework, not a library… the mechanisms for extension are supposed to be same as for normal programming. There was a guy a few years ago complaining about that (priorities) on the awt or swing mailing list but the engineer asked for use cases and wasn’t convinced by whatever the guy wrote.

That thing about no mouse listeners allows pass is very inconsistent in my eyes though.
Don’t allow and make the implementers of the component do that (no matter how easy) as a setting, not a side-effect. Inconsistent behavior because of user actions should be avoided to the max in a framework.

#63

So I made some nice progress again on PureSwing in last few days :slight_smile: 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.

#64

wow I must say this is sounding really impressive now, this could well end up being the best java gui. Will have to keep a close eye on this and hopefully give it a try soon too.

#65

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

#66

Nope. It’s GPL with Classpath exception, effectively less restrictive license than LGPL.

Also remember that the license is inherited from GNU Classpath project thus I cannot modify it for inherited code (a lot of code). As the license is actually less restrictive than LGPL it’s OK choice for me. When not restricted I would choose either LGPL or BSD.

#67

Hmmm… I guess I don’t understand the Classpath exception. :wink: Thanks for the reference and good luck with the library

#68

BTW jezek2 i don’t know if you know this, but the StyleContex class in java.swing.text sucks.

It is supposed to be extensible, with a away to configure the AttributeSet (interface) cache strategy into either using a mutable attribute set or using a immutable attribute set. The problem? The immutable attribute set that they choose is a concrete class. And extending it with a different strategy means having the fields of the super class hanging around doing nothing. Considering that the whole point is to minimize memory, the only way is to redefine almost all of the cache strategy since that entry point is useless.
Maybe it’s just possible i’m doing something wrong to have memory problems with my extension. Maybe some attribute sets are not needed.

#69

That shitty class has serialization support or attribute sets.

::slight_smile:

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

#70

I intend to remove the text package completely (or almost completely). I want to have simpler API for JTextField and JTextArea and remove both JEditorPane and JTextPane.

Instead I want to introduce a new way for richtext editing focused on simplicity (including simple extension and adaptation to various cases) and 100% reliability regarding to user input. I’ve never seen any 100% reliable richtext editor based on Swing Text support (commercial or not), it always blew up if you pressed “bad” key at “bad” time. My prototype from 2006 works very well on the other hand, but needs more work and it’s low priority for now.

#71

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.

#72

So you are basically saying that one of your LAFs will use native GUI components? You will just ignore functionality the native components cannot support? As you said, if you can design the GUI for each target platform (which is still less work than the current native approach of two very separate apps), this would be OK.

I wonder… You won’t want to mix native and non-native widgets of the same type in an app. Eg, say you are using all native buttons, except in one area you want an image on a button (or whatever) and the native button doesn’t support that. If you used a non-native button, the imperfections of the native emulation are going to be easily noticed, side by side. I worry that, for this reason, in a reasonably complex app you may end up with mostly non-native components.

Maybe it would be better to do all or nothing? Build a Java API for each OS, wrapping the native widgets and all their functionality. You would have to write your GUI once for each OS, but at least it would be native (and shameless :)), and would be written in Java even if it were OS specific (I shudder at the [thought [of [more [ObjC:hell]]]]). If you don’t want that, then go all emulated and put up with the imperfections.

It would be nice to mix the two approaches if you choose, which I guess is what you are proposing, but I’m not sure it is worth the effort and complexity for the API to hide the fact that you are going native. Give me flexible, reasonably cross platform emulation, or give me all the power of the native widgets.

#73

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 :slight_smile:

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

#74

Sounds pretty close to SWT. How do you feel about SWT?

#75

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)
#76

hi jezek2
I am a new starter,

in your latest release project “pureswing-20091121.zip”

when i try to run “cz.advel.pureswing.test.Modern3DDemo.java” and some error …

Exception in thread “main” java.lang.Error: not instrumented
at cz.advel.stack.Stack.alloc(Stack.java:110)
at cz.advel.pureswing.BorderLayout.layoutContainer(BorderLayout.java:471)
at cz.advel.pureswing.JComponent.doLayout(JComponent.java:3435)
at cz.advel.pureswing.JComponent.validateTree(JComponent.java:3480)
at cz.advel.pureswing.JComponent.validate(JComponent.java:3456)
at cz.advel.pureswing.desktop.VirtualDesktop$InternalWindow.setBounds(VirtualDesktop.java:476)
at cz.advel.pureswing.JComponent.Component_reshape(JComponent.java:5636)
at cz.advel.pureswing.JComponent.reshape(JComponent.java:2928)
at cz.advel.pureswing.JComponent.setBounds(JComponent.java:5604)
at cz.advel.pureswing.test.Modern3DDemo.main(Modern3DDemo.java:97)

to run it ,i use the command :

-Djava.library.path=lib/lwjgl2/windows -Xmx128m -cp lib/lwjgl2/lwjgl.jar;lib/lwjgl2/lwjgl_util.jar;lib/jstackalloc/stack-alloc.jar;
cz.advel/pureswing/test/Modern3DDemo

but i don’t know what’s wrong,please help me!!!

#77

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.