Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (533)
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]
  ignore  |  Print  
  What would you modify in Swing if you had to rewrite it?  (Read 3950 times)
0 Members and 1 Guest are viewing this topic.
Offline davedes
« Reply #30 - Posted 2013-07-28 03:26:45 »

Writing an HTML/CSS renderer is exceptionally difficult. Matthias' efforts in TWL are pretty amazing!

For advanced effects it would be better to hook into Chromium or WebKit to do the rendering.

Offline nsigma
« Reply #31 - Posted 2013-07-28 19:02:29 »

GridBagLayout, which has the usability of a turd.

It does have one particular use (especially around here).  Makes you wonder why they bothered adding GridBagConstraints though!  Grin

GroupLayout is a nightmare, it isn't how people naturally think about layouts.

Well, it's not really intended for people to use, but for layout builders / WYSIWYG.  It came out of Matisse in NetBeans, which is useful now and again, though I tend to prefer hand coding. 

MigLayout is a complicated beast that IMO tries to do too much and also has an unintuitive DSL. A DSL also leads to string concatenation when you have dynamic values, which is nasty.

Now admittedly I've used MigLayout for years, and wouldn't claim it's perfect, but having looked at TableLayout I don't understand what it offers that MigLayout doesn't, apart from the added features / bulk which is useful in a small minority of cases.  The important thing for me is the separation of layout from component hierarchy, which I find to be one of the most annoying things about the built in layout managers.

You don't have to use the DSL with Mig btw - there's also the API which is somewhat similar to your API in use - no issues with string concatenation of dynamic values.

I sometimes spend a lot of time in writing custom editors and custom in-place editors. I use a lot the property sheet.

Sometimes my least favourite part of the platform.  Wink  It's definitely one of those areas that shows the problem of evolving a complex API in a large project.

Don't know if you've seen this blog post on how I created the custom sliders within the property sheet?  No idea if it's any use to you - I'm just happy I got it to work!  Grin

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #32 - Posted 2013-07-28 19:57:04 »

GridBagLayout is a bit cumbersome to use, but other than that I don't see any game-breaking issues with it. It could have been more convenient to use, but it works for me.

As for UI designer tools, I just hate them with passion and I generally don't trust developers that rely on them.
In my opinion a good UI designer doesn't exist. They either generate horrible code, are too limited to do anything good with it, are a pain to use, or just completely screw up things halfway. Usually it does all of that.

Usually GUIs designed with them end up as horrid non-resizable windows with no layout management at all (the sort of thing that's still all too common within the Windows OS) and don't quite behave as they should.
I've tried to use them a long time ago when I started out with Java and when Swing seemed to be a bit intimidating as a newbie. Using a GUI designer such as in JBuilder, NetBeans or some Eclipse plug-in seemed a good idea. Boy was I wrong. Especially JBuilder and NetBeans seemed to try to emulate RAD tools like Delphi but using java/swing, but it just never worked.
You actually save a lot of time *not* using them and to just actually learn what you're doing, and use Swing the way it was intended: Just code it.
I also never use Android's GUI designer, because it still suffers from the exact same issues.

I think JavaFX and Android UI are sort of nice. They steer you towards a clear separation between views and business logic, and they're very flexible.
I prefer JavaFX there, because it's just easier.
Android has a too many gotchas for my taste and I tend not to do everything with XML, but generally it's still quite good. I wish that we didn't have to put up with issues related to 'ConvertView' and such, and there's quite a learning curve in other things as well.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline gouessej
« Reply #33 - Posted 2013-07-28 21:43:00 »

Sometimes my least favourite part of the platform.  Wink  It's definitely one of those areas that shows the problem of evolving a complex API in a large project.

Don't know if you've seen this blog post on how I created the custom sliders within the property sheet?  No idea if it's any use to you - I'm just happy I got it to work!  Grin

This is the part of the API I use the most. I was forced to use the reflection to get the first Node.Property object when selecting multiple nodes in the connect() method, using PropertyModel.getValue() just throws a DifferentValuesException in this case. Yes I saw this post Smiley

As for UI designer tools, I just hate them with passion and I generally don't trust developers that rely on them.
In my opinion a good UI designer doesn't exist. They either generate horrible code, are too limited to do anything good with it, are a pain to use, or just completely screw up things halfway. Usually it does all of that.
In my humble opinion, you can't use Matisse a bit, you can get some quite good code if and only if you use this tool as much as possible. If you mix generated code with hand written code, you get the cons of both approaches. I know some people who don't want to learn how to use layouts and who complain when I create GUIs without Matisse :s

Offline Nate

JGO Kernel


Medals: 145
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #34 - Posted 2013-07-29 05:33:43 »

Haha, a use for GridBagLayout? Up is down, black is white...

Now admittedly I've used MigLayout for years, and wouldn't claim it's perfect, but having looked at TableLayout I don't understand what it offers that MigLayout doesn't, apart from the added features / bulk which is useful in a small minority of cases.
TableLayout offers simplicity while still offering most of the functionality. Smiley I see you're right about not having to use the DSL, that is good. I shouldn't have been so hard on MigLayout, it is on the right track for what I want from a general purpose UI layout (tables), it's just that it also comes with a boatload of extraneous stuff. IMO when building software there's a narrow path to walk, you need to know which features to put in but also which not to put in.

Offline gene9

Senior Member


Medals: 9



« Reply #35 - Posted 2013-07-29 21:12:38 »

Swing, SWT, and JavaFX are all tools for writing component-centric rich/fat-client desktop apps with component GUIS: tables, buttons, menus, text fields, etc.

For games, you usually just want a 2D or 3D surface to render to such as OpenGL.

IMO, JavaFX is much better than Swing or even WPF/Silverlight on the .NET side. However, none of the above are good fit for games. For productivity apps like CAD, Photoshop, programming IDEs, JavaFX would make sense.

I'd be interested in hearing legitimate gripes about JavaFX. Its seems to be a complete improvement over Swing.

gouessej raises some points. To paraphrase:

1) Interop with legacy AWT/SWT/Swing code is weak. I've never tried to mix Swing/JavaFX in the same project, but I'll take your word it's sub-optimal. But this doesn't really impact new projects.
2) JavaFX problems with different back ends. I am skeptical. I've run JavaFX apps on many platforms and this wasn't a problem.
3) JavaFX interop with existing OpenGL bindings. Are you talking about having an OpenGL rendering frame inside of a JavaFX app? I imagine CAD and 3D modeling would want to do that. Those serious apps don't want to use the JavaFX 3D scene graph; they do want JavaFX basic widget GUI functionality, but they want to use their own 3D engines.
4) JavaFX doesn't work with Android/iOS/mobile. Same with Swing, the Oracle JDK, and pretty much everything Oracle. Oracle is supposedly working on this.
Offline princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #36 - Posted 2013-07-29 22:36:12 »

@princec, nah, SpringLayout sucks too. You can't look at the code and get a meaningful idea of what the layout is going to look like. IMHO, people don't think about layout by what edge of something is attached to something else's edge. They think about tables. Table tables tables, all the way down.
Well... actually all of our nifty resizable UIs in our games are designed exactly like this, giving us resolution independent layout, too. Once you've worked with it for a while it's hard to do layouts any other way.

Cas Smiley

Offline gouessej
« Reply #37 - Posted 2013-07-30 14:10:21 »

For productivity apps like CAD, Photoshop, programming IDEs, JavaFX would make sense.
It would make sense except if you can't disable Direct3D whereas your code relies on OpenGL  Sad

gouessej raises some points. To paraphrase:

1) Interop with legacy AWT/SWT/Swing code is weak. I've never tried to mix Swing/JavaFX in the same project, but I'll take your word it's sub-optimal. But this doesn't really impact new projects.
It works but in the case I talked about, it has the same limitation than when mixing any other GUI APIs using different threads for event dispatching.

2) JavaFX problems with different back ends. I am skeptical. I've run JavaFX apps on many platforms and this wasn't a problem.
It seems to work in desktop environments. JavaME generally supports a subset of AWT (see the Foundation Profile) but Android doesn't support AWT; if JavaFX relies on AWT, it will be a problem. Have you ever used JavaFX on a smartphone? The other problem was the (not really smooth) transition from the separate install of JavaFX to the inclusion of JavaFX in the JRE. Anyway, I won't use JavaFX until it is fully supported in OpenJDK.

3) JavaFX interop with existing OpenGL bindings. Are you talking about having an OpenGL rendering frame inside of a JavaFX app? I imagine CAD and 3D modeling would want to do that. Those serious apps don't want to use the JavaFX 3D scene graph; they do want JavaFX basic widget GUI functionality, but they want to use their own 3D engines.
I'm talking both about using OpenGL rendering inside a JavaFX application and using JavaFX widgets inside an existing OpenGL application. We can't use scenegraphs based on OpenGL if JavaFX forces the use of Direct3D under Windows. I just hope the flag of Prism will work but I fear that it will be tricky to use. It is only an hint, it indicates the order in which backends are picked up if several ones are available. If there is no OpenGL backend under Windows, you are forced to use the backend relying on Java2D, look at "prism.order". If the Java2D backend is less used and less maintained than the Direct3D backend, then OpenGL programmers will have some more troubles Sad

4) JavaFX doesn't work with Android/iOS/mobile. Same with Swing, the Oracle JDK, and pretty much everything Oracle. Oracle is supposedly working on this.
Oracle recently published a survey to check whether supporting mobile is important for the developers...

Edit.: ES2 backend is not shipped with JavaFX under Windows, you have to build it from source (OpenJFX).

Offline doos

Senior Member


Medals: 2
Projects: 2


Here be random


« Reply #38 - Posted 2013-08-14 23:33:58 »

Deep breath...  Grin


  • The amount of sizes you have to set to make stuff work. Setting size doesn't work, setting defaultSize doesn't work, setting preferred size doesn't work, then you have to create a random dimension object to set another size. Seems like I'm always setting everything to get it to work.
  • Repaint is awkward. I end up with every class having a local reference to the repaint thread and it is annoying. My custom list has altered? Well I need to repaint everything then, oh, I cant.
  • Some of the behaviour is twisted. It says in the javadoc that it works when you do X, but in reality it only works when you have a bunch of random prerequisites which it didn't tell you about. Did you remember to call method doRandomStuff(XYZManager x) AFTER you have created the object? Well it doesn't work. Should have been in the constructor then, shouldn't it?
  • The amount of inherited fields and methods gets in the way sometimes. I know it inherited them from Component, but I don't care about them and I cant find the method I am actually interested in. I would prefer swingObject hasa Component.
  • Some children are possible only from a JFrame, but not in nested objects. So you want a filedialog window to appear when you click a button in your panel? Well, you can't.
  • Is swing JFrame the one where you cant convert easily to an Applet?
Offline BoBear2681

JGO Coder


Medals: 18



« Reply #39 - Posted 2013-08-15 00:24:42 »

I'm yet another idiot who loves Swing.  Once you get past the steep learning curve, it's both very powerful and configurable.  I think it just got a bad rap for looking like crap for so long (and not being "native" when bindings for native toolkits, like SWT, were the cool thing).

I never touch GridBagLayout.  You can do everything you need with the other built-in layouts, and a fair amount of nesting.  It is often easier to use a 3rd-party LayoutManager though.

Besides what's already mentioned here, maybe that application framework JSR that never got off the ground, based on NetBeans RCP I believe.  It would help remove a lot of boilerplate from Swing applications of any appreciable size.

  • The amount of sizes you have to set to make stuff work. Setting size doesn't work, setting defaultSize doesn't work, setting preferred size doesn't work, then you have to create a random dimension object to set another size. Seems like I'm always setting everything to get it to work.

Typically, if you find yourself calling set*Size() on any components, "you're doing it wrong."  Properly-used LayoutManagers size everything properly for you 99.9% of the time.

Quote
  • Some children are possible only from a JFrame, but not in nested objects. So you want a filedialog window to appear when you click a button in your panel? Well, you can't.

I'm not sure I follow?  You can create and show FileDialog (or JFileChooser?) from any JButton anywhere in your UI...

Quote
  • Is swing JFrame the one where you cant convert easily to an Applet?

Either one would just be a container for your UI.  If you want to write an application that can run in both a window and an applet, typically you'd add all your components to a JRootPane.  JRootPane is basically all the content in your GUI application.  Then you can shove your JRootPane containing your application content into either a JFrame or a JApplet.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline CaptainJester

JGO Knight


Medals: 12
Projects: 2
Exp: 14 years


Make it work; make it better.


« Reply #40 - Posted 2013-08-15 02:22:31 »

The amount of sizes you have to set to make stuff work. Setting size doesn't work, setting defaultSize doesn't work, setting preferred size doesn't work, then you have to create a random dimension object to set another size. Seems like I'm always setting everything to get it to work.
Unless you are sub-classing a swing component you should not be trying to set the size. If you are sub-classing then you should over-ride getPreferedSize() to get the correct size you need.
Quote
Repaint is awkward. I end up with every class having a local reference to the repaint thread and it is annoying. My custom list has altered? Well I need to repaint everything then, oh, I cant.
You don't need to repaint everywhere. Repaint cascades down the hierarchy. Just repaint from the top most point you need to. If you have multiple custom components that need repainting then you might want to think about only having one.
Quote
Some of the behaviour is twisted. It says in the javadoc that it works when you do X, but in reality it only works when you have a bunch of random prerequisites which it didn't tell you about. Did you remember to call method doRandomStuff(XYZManager x) AFTER you have created the object? Well it doesn't work. Should have been in the constructor then, shouldn't it?
Would need a specific example to comment.
Quote
The amount of inherited fields and methods gets in the way sometimes. I know it inherited them from Component, but I don't care about them and I cant find the method I am actually interested in. I would prefer swingObject hasa Component.
Agreed.
Quote
Some children are possible only from a JFrame, but not in nested objects. So you want a filedialog window to appear when you click a button in your panel? Well, you can't.
If you are opening a dialog that needs a JFrame you can either pass null or create a dialog builder class that contains static methods but you set it up in the JFrame and pass a reference to the JFrame object.
Quote
Is swing JFrame the one where you cant convert easily to an Applet?
You should never put anything directly on a JFrame other than menus. If you want to make your application applet friendly you should build your app from a JPanel down and then you can use that JPanel in either a JFrame or JApplet.

Offline CaptainJester

JGO Knight


Medals: 12
Projects: 2
Exp: 14 years


Make it work; make it better.


« Reply #41 - Posted 2013-08-15 02:25:32 »

What would you modify in Swing if you had to rewrite it?
If you are thinking of starting a project like this I would be interested.

If you want cross compatability with Android, libgdx might be an option.

Offline sproingie

JGO Kernel


Medals: 201



« Reply #42 - Posted 2013-08-15 22:41:37 »

I'd make it support Java 8 idioms and nothing earlier.  Starting with closures: I'd still use listeners, but I'd allow most of them to be replaced by closures, including splitting up bulky interfaces into single-method listeners as appropriate.  Next jdk8 trick I'd pull would be to replace most uses of inheritance with interfaces, putting appropriate default behaviors on the interface.

I'd make the MVC design completely optional throughout.  All components would be shamelessly stateful, and you should be able to easily derive models from components and new components from models without having to declare clunky model classes that only work with Swing.  Long as we're going with interfaces, you should be able to have abstract component types anyway, same reason you can talk about an ArrayList or a LinkedList as an abstract List without needing to carry around an extra object to do it.

I'd give GridBagLayout a pair of concrete shoes and a swim.
Offline Grunnt

JGO Wizard


Medals: 64
Projects: 8
Exp: 5 years


Complex != complicated


« Reply #43 - Posted 2013-08-16 00:52:15 »

For me, JavaFX sounds really nice on paper, but I somehow never managed to make anything useful with it. Unlike Swing, which I find quite easy to use.

The pre-Java 7 requirement to installing a framework to be able to use JavaFX was a big barrier to adoption IMHO, especially considering the crapware-pushing installers associated with Java. Embedding JavaFX runtimes was complicated, compiling a tiny tool with Excelsior JET turns into a complicated mess using JavaFX.

Swing, being part of the standard Java distribution for ages now, does not give me this trouble. The only real problem I had with Swing was layout. MigLayout soved this partially. I must say SpringLayout sounds cool as well, I'll look into it next time I have to make a Java tool.

So for me, if you want to make a better Swing, please make it a simple library without needing any binaries, frameworks or dependencies Grin And make layout easy. Other than that Swing is just fine as far as I'm concerned.

Offline gimbal

JGO Knight


Medals: 25



« Reply #44 - Posted 2013-08-16 09:52:09 »

I'd make it support Java 8 idioms and nothing earlier.  Starting with closures: I'd still use listeners, but I'd allow most of them to be replaced by closures, including splitting up bulky interfaces into single-method listeners as appropriate.  Next jdk8 trick I'd pull would be to replace most uses of inheritance with interfaces, putting appropriate default behaviors on the interface.

I'd make the MVC design completely optional throughout.  All components would be shamelessly stateful, and you should be able to easily derive models from components and new components from models without having to declare clunky model classes that only work with Swing.  Long as we're going with interfaces, you should be able to have abstract component types anyway, same reason you can talk about an ArrayList or a LinkedList as an abstract List without needing to carry around an extra object to do it.

I'd give GridBagLayout a pair of concrete shoes and a swim.


... 100% agree. I think I've used a shared model between two components exactly once in a Swing application, and that was because I wanted to toy around with shared models, not because it was particularly beneficial.
Offline Nate

JGO Kernel


Medals: 145
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #45 - Posted 2013-08-16 22:06:14 »

@princec, nah, SpringLayout sucks too. You can't look at the code and get a meaningful idea of what the layout is going to look like. IMHO, people don't think about layout by what edge of something is attached to something else's edge. They think about tables. Table tables tables, all the way down.
Well... actually all of our nifty resizable UIs in our games are designed exactly like this, giving us resolution independent layout, too. Once you've worked with it for a while it's hard to do layouts any other way.
Tables also give you resolution independent layout, but in a way that is easy to visualize. Except for the simplest layouts, you can't look at a bunch of SpringLayout constraints and know what the layout will be, you'll need to run it and see what happens. When you run it and it doesn't look like you want, you'll have to go back and stare at the code. With tables you can turn on table, cell, and/or widget debug borders and easily see what is going on.

In TableLayout resolution independence is done by saying which columns and/or rows fill the remaining space. This can be weighted, but it is rare to need that. Widgets provide a pref size and the table lays them out at that size. If there isn't room, then they get sized smaller, down to their min size. Most layouts don't hardcode widget sizes, the table adjusts based on the size the widget wants to be. If running on a different sized screen or with different sized widgets, the layout still works.

Offline Zhon

Junior Member


Medals: 4



« Reply #46 - Posted 2013-08-16 22:27:52 »

<<---- BorderLayout master race
Offline gouessej
« Reply #47 - Posted 2013-08-17 00:48:27 »

(and not being "native" when bindings for native toolkits, like SWT, were the cool thing).
It depends on your customers, some people don't expect a native "look and feel". SWT applications are difficult to maintain, there are different layout problems even on different versions of Windows (XP, Vista, 7), for example when you put exactly 2 icons into a vertical toolbar, sometimes the icons are set horizontally under some versions of Windows :s

I have already seen a real commercial JavaFX Web application deployed once, the switch from a separate version to install with Java 1.7 to the integrated version caused a lot of troubles (it still doesn't work on some machines and we don't know why). The memory footprint is very high compared to Swing and even the API seems not very mature, there are already several methods who do exactly the same thing (close() and hide())... Pisces software rendering engine (AWT-free) is known to use a lot of memory (because of the (ab)use of Arrays.copyOf()). For me, JavaFX is not ready for prime time, especially with no OpenGL backend for Windows (in Oracle Java, not in OpenJFX).

Netbeans Platform is really cool but there is a real lack of documentation. Of course, I can look at the source code. The problem is that I understand the design of this API mostly by reading its source code and I have already seen numerous examples that simply don't take advantage of the life cycle of objects to do the things correctly.

Offline BoBear2681

JGO Coder


Medals: 18



« Reply #48 - Posted 2013-08-17 05:26:31 »

(and not being "native" when bindings for native toolkits, like SWT, were the cool thing).
It depends on your customers, some people don't expect a native "look and feel".

Aye, to a degree, that's what I was alluding to.  A few years ago, native looking (desktop) apps was what everybody wanted to build.  Nowadays, we've done a 180 and everybody wants unique looking apps.  Or maybe it just seems that way because so much stuff is being built as webapps these days, and it's so much easier for designers to get creative with CSS than it is with a programmatic styling API like Swing LookAndFeels.
Offline ClickerMonkey

JGO Coder


Medals: 20


Game Engineer


« Reply #49 - Posted 2013-08-26 13:50:52 »

@Nate

TableLayout looks pretty nifty, do you mind if I integrate it into my game engine? (my game engine isn't public just yet)

TableLayout does look several magnitudes better than anything in Swing...

Offline Nate

JGO Kernel


Medals: 145
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #50 - Posted 2013-08-26 22:50:05 »

@ClickerMonkey, yes by all means, use it! Smiley See one of the TableLayout backends for how to extend it for a UI toolkit. Eg, here is the scene2d Toolkit impl:
https://github.com/libgdx/libgdx/blob/master/gdx/src/com/badlogic/gdx/scenes/scene2d/ui/TableToolkit.java
And the TableLayout impl:
https://github.com/libgdx/libgdx/blob/master/gdx/src/com/badlogic/gdx/scenes/scene2d/ui/TableLayout.java
That is all you need to extend it. You can integrate it into your engine however you like, it can be a layout manager not in the scene, or a scene object that lays out children.  In scene2d Table is the latter:
https://github.com/libgdx/libgdx/blob/master/gdx/src/com/badlogic/gdx/scenes/scene2d/ui/Table.java
It delegates a ton of methods for convenience. Also it might help to see how layout invalidation works in scene2d:
https://code.google.com/p/libgdx/wiki/scene2dui#Layout
This way layout doesn't happen every frame, it only happens when something changes size that might affect the layout.

Pages: 1 [2]
  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.

pw (26 views)
2014-07-24 01:59:36

Riven (25 views)
2014-07-23 21:16:32

Riven (20 views)
2014-07-23 21:07:15

Riven (22 views)
2014-07-23 20:56:16

ctomni231 (51 views)
2014-07-18 06:55:21

Zero Volt (46 views)
2014-07-17 23:47:54

danieldean (37 views)
2014-07-17 23:41:23

MustardPeter (40 views)
2014-07-16 23:30:00

Cero (56 views)
2014-07-16 00:42:17

Riven (55 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!