Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (602)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 2 [3]
  ignore  |  Print  
  PureSwing  (Read 23829 times)
0 Members and 1 Guest are viewing this topic.
Offline jezek2
« Reply #60 - Posted 2010-02-17 00:18:10 »

What really hurts is the usability. I mean it's probably bad idea to allow a general even passthorugh, because when i tried, it messed with the repaint buffer, since one of my mouselisteners called repaint on the list underneath the tooltip, but at least for some of them, like the ultra useful mousewheelevent on a JScrollpane underneath the tooltip, it should pass.

In my app i made it pass even if the tooltip is outside the bounds (my tooltips are at a specified place, for a JList alone inside the JScrollpane and it was easier YMMV).

The real solution is to make the tooltips invisible to everything, including events and damaging repaint requests.

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?
Offline i30817

Junior Devvie





« Reply #61 - Posted 2010-02-17 08:19:08 »

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.
Offline jezek2
« Reply #62 - Posted 2010-03-17 03:49:47 »

So I made some nice progress again on PureSwing in last few days Smiley 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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Online kappa
« League of Dukes »

JGO Kernel


Medals: 81
Projects: 15


★★★★★


« Reply #63 - Posted 2010-03-17 09:38:19 »

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.
Offline kaffiene
« Reply #64 - Posted 2010-03-17 20:29:34 »

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

Offline jezek2
« Reply #65 - Posted 2010-03-17 22:34:03 »

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

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.
Offline kaffiene
« Reply #66 - Posted 2010-03-18 23:07:22 »

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.

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

Junior Devvie





« Reply #67 - Posted 2010-03-26 05:11:35 »

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.
Offline i30817

Junior Devvie





« Reply #68 - Posted 2010-03-26 05:49:36 »

That shitty class has serialization support or attribute sets.

 Roll Eyes

Edit: In fact that class should be renamed "MemoryLeak". Singleton + 4 maps. The most important is weakhashmap with weak values true, but still...
Offline jezek2
« Reply #69 - Posted 2010-03-26 08:29:57 »

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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline jezek2
« Reply #70 - Posted 2010-04-12 12:53:35 »

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.
Offline Nate

« JGO Bitwise Duke »


Medals: 158
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #71 - Posted 2010-04-12 20:31:13 »

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 Smiley), 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.

Offline jezek2
« Reply #72 - Posted 2010-04-12 23:31:27 »

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.

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.

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.

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.

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 Smiley), 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.

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 Smiley

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.

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

« JGO Bitwise Duke »


Medals: 158
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #73 - Posted 2010-04-13 20:22:36 »

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

Offline jezek2
« Reply #74 - Posted 2010-04-13 20:56:48 »

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

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)
Offline me520

Innocent Bystander





« Reply #75 - Posted 2010-04-15 11:14:38 »

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!!!
Offline jezek2
« Reply #76 - Posted 2010-04-15 12:22:40 »

hi jezek2
I am a new starter,
[...]
but i don't know what's wrong,please help me!!!

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.
Pages: 1 2 [3]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

rwatson462 (30 views)
2014-12-15 09:26:44

Mr.CodeIt (20 views)
2014-12-14 19:50:38

BurntPizza (42 views)
2014-12-09 22:41:13

BurntPizza (76 views)
2014-12-08 04:46:31

JscottyBieshaar (37 views)
2014-12-05 12:39:02

SHC (51 views)
2014-12-03 16:27:13

CopyableCougar4 (49 views)
2014-11-29 21:32:03

toopeicgaming1999 (115 views)
2014-11-26 15:22:04

toopeicgaming1999 (103 views)
2014-11-26 15:20:36

toopeicgaming1999 (31 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!