Isn’t it only a matter of designing buttons that look like ‘native’ buttons?

Well – sort of, for buttons. But this might be harder than you imagine. These days the graphics used to represent GUI components aren’t as simple as random bitmaps that are stretched (since these don’t scale very well at all) – they’re often vector based graphics with a lot of corner cases programmed into them (so when the button reaches the edge of the screen it may look slightly different, for instance.) And of course, you’ll need different graphics when a button is clicked. For copyright reasons, developers often can’t just use these existing graphics outright, so they have to be recreated – and while they do a good job for the most part, inevitably some things get missed given the huge array of graphical components out there. This is much less severe than it used to be – these days if I set the default platform look and feel in Swing, I notice very little that looks odd.

I’m saying all the above based on Swing, which is of course a lightweight, non-native GUI toolkit. You specifically mention SWT not looking native, which is a bit odd, because SWT is native. It’s a toolkit that uses JNI underneath to call native components – so if something doesn’t look right there, it’s not going to be because of the look and feel.

There are literally half a dozen of toolkits that could be considered “native” on some system. Some of these have rather unique concepts or capabilities, and replicating them in a cross-platform toolkit is tedious. The look & feel of an application is not only determined by a “skin”, but also on the layout and how it behaves. Some considerations:

• In a dialog, on which side does the “OK” button belong – on the left or on the right? Fair enough, let’s build a separate dialog for each system.
• How do we mark the default button on a screen? Color tinting, bold font, enlarging the button? Fair enough, let’s put that in a stylesheet.
• On Windows, the “Ribbon” concept is rather native. How would this be translated to Mac, where the Ribbon isn’t common? Fair enough, let’s forget pixel-exact layout and provide a different toolbar implementation for each system.
• Is the menu bar part of the window (Windows, optionally KDE), or does it sit at the top of the screen (Mac, Unity)? Fair enough, let’s write a different implementation for each system, as we’ve already thrown away pixel-exact layout
• How are the fonts rendered? As crisp as possible, or smooth and antialiased? And what font should be used? Note that different fonts have different metrics, so the same paragraph rendered to the same width may have a different number of lines depending on the font.
• Is the background of a window a single color, an image, or a gradient? Let’s just put that into a stylesheet as well.
• How do scrollbars look? Where are the buttons – if they have any? How wide are they, or are they only revealed when the pointer moves into a certain region?
• How do we incorporate other color schemes?
• What is expected to be draggable? Where are context menus expected?

These issues can’t be solved through a simple stylesheet when they touch on the behavior or general layout of the application. The only real solution is to re-write the application for each system (thus ignoring Java’s cross-platform benefits). The only realistic solution is to forget about pixel-exact layout, and to write to a common interface which abstracts over over system-specific toolkits. The solution taken by Swing is to emulate various systems, which fails spectacularly.

And then there is cross-platform consistency, the idea that your app can look exactly the same on all systems (often chosen by games, where this increases immersion). On desktop applications, this is just annoying and breaks user expectations.

Yes, it does go deeper.

Building a button which looks like a Windows or OS X button is easy, when you are building only this button. But the button must “behave” like the original ones, which might not be easy: maybe there is more space in one version available, but not in the other, maybe the color is more fitting for your design in the Windows version, etc.

This is excarberated when you have a whole GUI: an OS X program presents its content differently than a Windows program. This is next to impossible to capture in one GUI – you would need two GUIs, but not many applications make so much fuss. Instead they are aiming for “looks ok on most systems” – this still looks somewhat alien, but is usable and much easier to develop.

It’s not hard to make a button that looks like an OSX button, or a Windows button, or that of any other toolkit. But the UI guidelines for most environments are not as simple as the basics of “this is what a button looks like.” There are many subtler differences, from the spacing between UI elements to the order in which certain well-known actions should appear in a list to the exact position of the Preferences/Options dialog in the menu system. One can automate the most common cases for very simple user interfaces, but many if not most UI tasks require a much finer touch.

SWT tried to automate this to some degree, and once again, it gets it right for simple UI tasks. But there is no one-size-fits-all solution, and so when UIs get more complex, the basic methods it uses begin to fall apart. It is generally possible to bring it back into line with painstaking manual UI work, but this is not something that most programmers are able or willing to do for all platforms.

Swing’s approach to this was simply to eschew native toolkits whenever possible. It’s not native, and it doesn’t try to be: instead, it tries to create something that will look (almost) the same no matter where it is run. Rather than trying (futilely) to please everyone, it tried to please itself, and while it succeeded as far as that goes, one can question how effective the result is to the wider community of users.

There is a trade-off between expecting your application to look as natural as possible on every system and expecting your application to work in the same way on each system. There is no “right” choice.

Moreover, even if you choose the “natural looking” side, you might want to protect the users of your graphic toolkit against “improvements” in the underlying native components and API which might break their application unexpectedly.

This is why some GUI toolkit developers prefer to provide their own components that mimic native ones, but provide their own implementation. On the other hand developing a functionally complete GUI toolkit is a significant effort and economic considerations may lead to cutting a few edges.

Note that this problem is not Java specific, but is faced by every company producing platform independent toolkits.

It’s all due to history.

Sun wished all Java software to work the same on all machines.

For software to “appear native” it has to work the same as other software on the given OS.

Sun did everything in their power to make it hard to write Java software that integrated in with an OS, as any integration with an OS would make the software work differently on each OS.

These days very few Java programmers care about anything other than web server based software.

Sun killed Java on the desktop by shafting all programmers that used the Microsoft java based systems, hence making any programmer that choose Java in the early days look bad.

Anyone writing desktop software that care about “appear native” learned a long time ago not to use Java and has their views reinforced every time they use any Oracle software.

Therefore these days there is no demand for “appear native” on desktop software from Java programmers.

What you think is native is actually native apps doing their own thing while toolkits like SWT follow the published standards for the UI of that OS. The problem is that no one builds apps following those standards so when you fire up a Java app. It appears to not be native. As an example, almost all of Microsoft’s projects (Office, Outlook, etc.) cannot be reproduced visually using Windows standard controls.

It’s going to get even worse as both Microsoft and Apple add dynamic UI features to their OS platforms. Allowing developers to skin/style their apps much the same way web designs create styles for websites.

Java on the Android platform is following this path. Making the UI elements for Android defined in XML with skinnable styles.

Java has never been very popular as a desktop platform. As a result these changes in the industry are not propagating down to the desktop runtimes. There just aren’t enough developers willing to spend time to fix the issue.

Which operating system do you want to look “native” too?

You just can’t be native to all of them 100% of the time.

SWT etc. are the best effort approach to look as native to all of them as it gets when you need to reach some compromise.

And in fact, this compromise starts to become more and more hard to reach; not so much because of operating systems, but because of input devices. For touchscreens, you actually have to design differently, because there is no right mouse button. Therefore, you need to accomodate the same functionality otherwise.

There will never be a magic button that moves functionality “intuitively” from the right mouse button to guestures, without you specifiying every detailed aspect for every single input device (at which point, you are native to every platform you have considered, but nevertheless non-native to any you have not considered).

Really good question. I always wondered about it myself for a few subsequent years in the past, I thought there was some legit reason behind this, but there really isn’t.

I think the answer is rather simple, and a lot of answers are not really digging into the issue.

If your language allows to draw piexel on screen then it is 100% possible to create a gui framework based on it which will mimic Windows form controls looks & feel precisely.

Since Java is crossplatform its also entirely possible to make sure that based on actual running system type (Mac/Windows) UI would choose to look different on both platforms, matching the runtime platform style.

As you can see in XAML for example UI can be easily presented in very structured form and language. Choosing the “native” behaviours is also possible if time is taken to do this.

So it would be possible to create GUI framework which would allow Java developers to get applications which would look native on Mac and Windows.

So we get to Swing, thats just one GUI framework out of potential infinity of GUI frameworks which could be created for Java. It behaves how it was programmed, which doesn’t follow the above process and you get weirdly looking apps on both systems. Thats the choice made by Swing developers, noone forced them to do this and to behave that way.