Swing

From otaking wiki

Revision as of 17:45, 16 June 2009 Putte (Talk | contribs) Let's summarize all the ways in which Swing sucks. ← Previous diff		Current revision Putte (Talk | contribs)
Line 1:		Line 1:
	''Swing'' is the official [[Java]] GUI toolkit. It's also a steaming pile of shit.		''Swing'' is the official [[Java]] GUI toolkit. It's also a steaming pile of shit.
		+
		+	To verify that the steaming pile is indeed composed purely of shit, follow this procedure:
		+	# Start a Java Swing application of your choice.
		+	# Poke around in the GUI for a minute or two.
		+	# Note the drawing bugs, the inconsistent and unattractive spacing, the odd focus glitches and the [[#Font_rendering|horrible font rendering]].
		+	# Now, consider that this GUI toolkit has been worked on by a large team of engineers continuously for over ten (10) years. It's not a beta release.
		+	# Thus we can see that it's fundamentally crap. Crap == shit. QED.
		+
		+	== Examples ==
		+
		+	The purpose of a GUI toolkit is to provide a set of standard components to solve common problems. Let's have a look at a few of these problems and see how different toolkits approach them.
		+
		+	=== Menus: Problem 1 ===
		+
		+	All desktop GUI toolkits provide a menu bar with drop-down menus. What happens when a menu (e.g. a bookmarks menu) is to too long to fit on the screen?
		+
		+	==== Mac OS & GTK ====
		+	Let the menu stretch all the way from the top edge to the bottom edge of the screen. Provide scroll arrows (as wide as the menu) at the edges, taking advantage of [[Fitts' law]].
		+
		+	==== Windows & Qt ====
		+	Wrap the menu into multiple columns.
		+
		+	==== Swing ====
		+	Swing makes no attempt at addressing this problem. The items that don't fit will not be displayed.
		+
		+	=== Menus: Problem 2 ===
		+
		+	A drop-down menu often contains submenus, which appear when you point at a certain item in the parent menu and disappear when you point at any other item. The shortest path to any of the items in the submenu leads across items in the parent menu, but passing over them makes the submenu disappear.
		+
		+	==== Mac OS & GTK ====
		+	The menu remains on screen as long as the pointer is moving towards it. If you stop moving or move in another direction it disappears instantly.
		+
		+	==== Windows & Qt ====
		+	There is a slight delay to allow the user to reach the menu before it disappears.
		+
		+	==== Swing ====
		+	Swing makes no attempt at addressing this problem. The menu disappears when you try to reach it.
		+
		+	== Font rendering ==
		+
		+	There are two schools of thought when it comes to rendering fonts on a low-resolution computer screen. Apple (in Mac OS X) takes the view that the fonts should look as similar as possible to what's printed, when it comes to glyph shapes and weight, using anti-aliasing. The downside of this is that the text appears slightly fuzzy, since it's not always aligned to the pixel grid.
		+
		+	Microsoft, on the other hand, prioritizes sharp text, using hinting to cram the letters into the pixel grid. This usually gives nice and legible text, but the proper shape of the font is distorted, and the difference in weight between normal and bold text is usually far too large.
		+
		+	Swing (or rather Java2D, which Swing uses) takes a third approach: the glyphs are the wrong shapes and wrong weight, but also blurry. Enabling subpixel anti-aliasing interestingly makes the text too thin, whereas Apple's anti-aliasing usually makes it slighty thicker than hinted text.

---

Current revision

Swing is the official Java GUI toolkit. It's also a steaming pile of shit.

To verify that the steaming pile is indeed composed purely of shit, follow this procedure:

1. Start a Java Swing application of your choice.
2. Poke around in the GUI for a minute or two.
3. Note the drawing bugs, the inconsistent and unattractive spacing, the odd focus glitches and the horrible font rendering.
4. Now, consider that this GUI toolkit has been worked on by a large team of engineers continuously for over ten (10) years. It's not a beta release.
5. Thus we can see that it's fundamentally crap. Crap == shit. QED.

Contents 1 Examples 1.1 Menus: Problem 1 1.1.1 Mac OS & GTK 1.1.2 Windows & Qt 1.1.3 Swing 1.2 Menus: Problem 2 1.2.1 Mac OS & GTK 1.2.2 Windows & Qt 1.2.3 Swing 2 Font rendering

Examples

The purpose of a GUI toolkit is to provide a set of standard components to solve common problems. Let's have a look at a few of these problems and see how different toolkits approach them.

Menus: Problem 1

All desktop GUI toolkits provide a menu bar with drop-down menus. What happens when a menu (e.g. a bookmarks menu) is to too long to fit on the screen?

Mac OS & GTK

Let the menu stretch all the way from the top edge to the bottom edge of the screen. Provide scroll arrows (as wide as the menu) at the edges, taking advantage of Fitts' law.

Windows & Qt

Wrap the menu into multiple columns.

Swing

Swing makes no attempt at addressing this problem. The items that don't fit will not be displayed.

Menus: Problem 2

A drop-down menu often contains submenus, which appear when you point at a certain item in the parent menu and disappear when you point at any other item. The shortest path to any of the items in the submenu leads across items in the parent menu, but passing over them makes the submenu disappear.

Mac OS & GTK

The menu remains on screen as long as the pointer is moving towards it. If you stop moving or move in another direction it disappears instantly.

Windows & Qt

There is a slight delay to allow the user to reach the menu before it disappears.

Swing

Swing makes no attempt at addressing this problem. The menu disappears when you try to reach it.

Font rendering

There are two schools of thought when it comes to rendering fonts on a low-resolution computer screen. Apple (in Mac OS X) takes the view that the fonts should look as similar as possible to what's printed, when it comes to glyph shapes and weight, using anti-aliasing. The downside of this is that the text appears slightly fuzzy, since it's not always aligned to the pixel grid.

Microsoft, on the other hand, prioritizes sharp text, using hinting to cram the letters into the pixel grid. This usually gives nice and legible text, but the proper shape of the font is distorted, and the difference in weight between normal and bold text is usually far too large.

Swing (or rather Java2D, which Swing uses) takes a third approach: the glyphs are the wrong shapes and wrong weight, but also blurry. Enabling subpixel anti-aliasing interestingly makes the text too thin, whereas Apple's anti-aliasing usually makes it slighty thicker than hinted text.