98

Most Java applications don't look the same as C/C++ applications. Swing might have been designed on purpose to have a distincitve look, but based on what I've read, SWT for example tried to 'look native', and doesn't completley succeed.

My question is:

Why is it hard for the developers of the Java language to design a GUI system that copies exactly the look of native GUIs? What's different in native GUIs? Isn't it only a matter of designing buttons that look like 'native' buttons? Or does it go deeper than that?

user3150201
  • 1,217
  • 2
  • 10
  • 9
  • 32
    because swing writes its own gui components that try to mimic the native, instead of creating a binding to the actual native components, in the idea of portability – ratchet freak Feb 03 '14 at 11:58
  • 5
    I am not an expert on this topic, but I guess it is just a matter of how much effort GUI toolkit vendors are willing to invest to get all the gory details right. See, for example, the C++ framwork "Qt" and this SO question: http://stackoverflow.com/questions/7298441/do-qt-apps-lookfeel-native-under-windows – Doc Brown Feb 03 '14 at 12:01
  • 4
    There are many many details to take care of. For example the way auto-completition works in a file open dialog is one point where a native looking java application broke down. – CodesInChaos Feb 03 '14 at 12:27
  • 3
    Maybe because by design Java is meant to be non-native? – Pieter B Feb 03 '14 at 12:39
  • 4
    Swing has a "native lookalike" look-and-feel that you can plug in instead of the default. Also, Java first tried to use available native stuff with AWT but it didn't work very well, AFAIK because of the inherent differences between platforms. That's why they created Swing, so that a Java app works exactly the same everywhere. – marczellm Feb 03 '14 at 12:58
  • 1
    @marczellm it was because of a faulted idea of thread safety, AWT was meant to be thread safe but that doesn't work when events bubble both ways – ratchet freak Feb 03 '14 at 14:56
  • 3
    "Write once, debug everywhere." Or perhaps, "Write once, create native-style UI's everywhere." You can't really write UI code once and have it mimic native-style UI's on every platform. – Christos Hayward Feb 03 '14 at 16:02
  • 1
    "SWT for example tried to 'look native', and doesn't completely succeed" SWT might have other problems, but it looks fully native to me (further, as one answer comments: it's native). The canonical example is Eclipse. – leonbloy Feb 03 '14 at 20:15
  • 1
    Without actually calling the GUI functions provided by the OS, trying to mimic a "native" look is trying to hit a moving target. Even something as simple as a button looks different in Windows 95 versus Windows 8. That's why the OS generally provides libraries for GUI controls so that your C++ app on Windows 95 gets a Windows 95 button and on Windows 8 it gets a Windows 8 button automagically. – Matt Burland Feb 03 '14 at 20:37
  • 5
    Don't overlook JavaFX. It's the SWING replacement and is in the JDK/JRE by default starting with Java 8. It is much more modern than SWING and AWT and looks a lot more native on just about all platforms (it hooks a lot into the native UI toolkit on each platform). With that said, as others have mentioned, to get an exactly native looking application out of a "one-size-fits-all" language like Java, you will have to do some work. Java's UI's was/were/still-are intended to be a "best fit for all platforms" out-of-the-box. – SnakeDoc Feb 03 '14 at 21:30
  • @MattBurland It's a slowly moving target though, isn't it? Windows 7 and 8 could be targetted now, and in a few years when Windows 9 comes out that could be covered. It's not like the work would have to be done from scratch every 6 months or anything, and the apps would look a lot better (well, more consistent). – bye Feb 03 '14 at 21:55
  • @Poldie: You *could* target Windows 7 and 8 now, but you already need to do twice as much work (because the GUI formerly known as Metro is a pretty radical departure from 7) plus you still have hold-outs (mostly corporate systems) using XP. And it's a pretty safe bet you'll be supporting 7 for a good while after 9 comes out. And you'll still not "native" on OSX or anything outside Windows. – Matt Burland Feb 03 '14 at 22:01
  • Yeah, but at any given point you're just targetting the next one. I was assuming "native" meant "like the OS the app is running under", so yes, it would have to be per-OS. But it would be worth it because it wouldn't look so bad, and I'm sure a lot of work goes into SWT etc anyway. – bye Feb 03 '14 at 22:08
  • "*based on what I've read, SWT for example tried to 'look native', and doesn't completley succeed*": just wondering whether you could add pointers to what you've read, to get an idea where SWT isn't "native". – Bruno Feb 04 '14 at 02:36
  • 1
    Making SWT look good is a breeze, but you will have to test your application on every platform you plan to support. Even Mac and Windows will differ. Though, if you plan your GUI - even barely - beforehand, you will only need a few IFs. If any. | Swing on the other hand looks terrible. BUT it can look good! (I was surprised as well. Take a look at "IntelliJ IDEA" by JetBrains. It uses Swing, and it does look fantastic. Here is a "recent" blog post about the new Darcula theme - http://blog.jetbrains.com/blog/2013/06/11/inside-darcula-look-and-feel-an-interview-with-konstantin-bulenkov/) – Apache Feb 04 '14 at 11:25
  • 1
    But what's "native"? Users can heavily customise "native", so unless you're tapping into the underlying OS and going native yourself I don't see how this could ever be _mimicked_. – MrWhite Feb 04 '14 at 20:46
  • I don't understand, Java applications look native if they activate the system L&F: UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName()); – Charlie Aug 10 '14 at 20:18
  • You'd probably get more helpful answers from UX experts than programmers: http://ux.stackexchange.com/ – Mark E. Haase Aug 19 '14 at 14:57

9 Answers9

71

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.

samthebrand
  • 368
  • 2
  • 12
  • 27
amon
  • 132,749
  • 27
  • 279
  • 375
  • 1
    +1. Only one thing I’d like to add: What about things the system allows the user to configure, starting from “simple” details such as how to open context menus? (And I’d much prefer windows programs to have ribbons and Mac apps not to, thank you. Yes, good GUIs need to be designed per OS.) – Christopher Creutzig Feb 04 '14 at 04:51
  • @ChristopherCreutzig That's where my experience comes from: On my main desktop, I use KDE on Linux (both of which are very configurable themselves), and use QtCurve to adjust the look of applications. These special styles work just fine in the flagship KDE applications. Well-written GTK apps can make use of a compatibility layer, but background gradients are missing, the menu bar stays inside the window etc.. But then it quickly starts to deteriorate, with programs taking some widgets from the system style (like scrollbars), but ignoring others (like font rendering, or shadows around menus) – amon Feb 04 '14 at 09:52
  • +1 because there are some strong points in this answer, but there are some weak points, too. Any "how does this window manager draw X" issue is handled by using the native API. For example, X11 on OS X can draw native OS X windows, buttons, scroll bars, dialogs, etc. So a lot of those issues disappear. The _real_ answer is what @TheSpooniest said below: UX is _so much more_ than just drawing widgets. Spacing, timing, animation, mouse acceleration, touch inputs... there's a world of subtle details that are very expensive to reproduce with a cross-platform toolkit. – Mark E. Haase Aug 19 '14 at 14:53
57

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.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
berry120
  • 1,747
  • 14
  • 17
  • 1
    Thanks. What does 'light-weight' mean exactly? And what does 'native' actually mean? I assume it means something that uses resources from the OS of the computer or interacts with it directly. Is this true? – user3150201 Feb 03 '14 at 12:22
  • 1
    @user3150201 Sure, so the underlying OS will have a set amount of buttons and widgets that can be placed natively, but obviously these buttons will differ between OS and between platforms - these are the heavyweight, native components. Lightweight components aren't the components dictated by the OS, they're drawn by Java (in this case) to look and behave like GUI components - so they can look however you want if you put the work in (but you have to emulate the platform look and feel if you want that, you don't get it for free.) – berry120 Feb 03 '14 at 12:27
  • 1
    Yeah, I thought SWT did a fine job at a native look. – Rig Feb 03 '14 at 15:46
  • 14
    Placement of buttons, exact sizes, and preferred GUI styles vary by platform and getting Java to mimic them takes work. Swing can give you the native button but if it's 10 pixels to tall the user will still think something is off. Apple has the [Human Interface Guidelines](https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/AppleHIGuidelines/Intro/Intro.html) and Microsoft has the [User Interface Guidelines](http://msdn.microsoft.com/en-us/library/aa297210(v=vs.60).aspx) to help you get the correct native look. You will need to change UI somewhat between platforms. – Michael Shopsin Feb 03 '14 at 15:47
  • 4
    JavaFX appears much more "native" than SWING and AWT. It has native transparent windows, etc. Much more modern looking out-of-the-box. – SnakeDoc Feb 03 '14 at 21:27
  • 2
    @SnakeDoc It appears more modern, sure, but I wouldn't say it appears "native" - it certainly doesn't use the platform's underlying GUI components, it's all skinned in CSS. – berry120 Feb 03 '14 at 21:54
  • @berry120 it is, that is correct. but if you do not skin it yourself, the default is native-ish looking. also, having CSS as a tool makes it a lot easier to do this type of skinning (adjust button sizes, colors, fonts, etc and just determine at runtime which CSS sheet to load). – SnakeDoc Feb 03 '14 at 21:59
  • 1
    SWT is in the uncanny-valley, IMHO, which makes it worse. – Nick T Feb 04 '14 at 23:31
  • You should touch on the fact that emulating a native "look and feel" is a moving target. Just when you put work into catching up, the native widgets get a makover. Pretty soon you have not one but a dozen moving versions depending on OS and version. – Caleb Feb 06 '14 at 19:41
  • I don't know about the rest of you but on my Mac, AWT's file chooser looks pretty much like the real deal and AWT buttons look a lot more native than Swing ones. – Hakanai Jan 08 '21 at 20:32
12

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.

Alex P
  • 123
  • 1
  • 5
Christian Sauer
  • 1,269
  • 1
  • 9
  • 16
8

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.

The Spooniest
  • 2,160
  • 12
  • 9
7

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.

Nicola Musatti
  • 341
  • 1
  • 2
  • 6
  • Rather than silently downvoting you'd do a greater service to the community by explaining what you feel is wrong with an answer. Unless it's just a personal issue... – Nicola Musatti Feb 04 '14 at 08:34
4

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.

Ian
  • 4,594
  • 18
  • 28
  • 5
    "Sun did everything in their power to make it hard to write java software that integrated in with an OS, " wrong. They simply put no great effort into making it easy. "Sun killed Java on the desktop by shafting all programmers that used the Microsoft java based systems" wrong, the mutual enmity between Microsoft and Sun caused Microsoft to create a version of the AWT libraries that wasn't compatible with Sun's requirements, causing the infamous Sun/MS lawsuits. – jwenting Feb 04 '14 at 09:09
  • 1
    @jwenting, Sun cared more about making problems for Microsoft then about programmers that had chosen to use Microsoft's java based system. Hence **I** gave up on Jave and kept with MFC until C# come out. – Ian Feb 04 '14 at 09:31
  • 3
    maybe some people at Sun, but that sentiment was mutual. If you're developing exclusively for a single platform, a native tool for that platform is ALWAYS the prefered option, this has nothing to do with corporate politics. If you choose your tools based on "I hate Sun" or "I hate Microsoft" that reflects very poorly on your professional attitude. I've mostly used Java, but alongside that I've also used Delphi, C#, Ruby, C++, C, Progress, whatever was the best for the job at hand. And more often than not that will end up being a hybrid solution. – jwenting Feb 04 '14 at 13:02
3

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.

Reactgular
  • 13,040
  • 4
  • 48
  • 81
  • 1
    +1, back in the Windows 95 era there was a 'standard' look for Windows controls. Now, not so much. – GrandmasterB Feb 03 '14 at 15:54
  • Yeah, its been a few years since I've programmed desktop but I was surprised that .NET didn't ship with a ribbon style control despite it becoming integral to the MS built productivity software. – Rig Feb 03 '14 at 16:27
  • @Rig Since NET 4.0 there is a good native Ribbon Control in .NET. Here is a good article: http://www.c-sharpcorner.com/UploadFile/0b73e1/ribbon-control-in-wpf-4-5/ – Christian Sauer Feb 03 '14 at 18:15
  • @ChristianSauer I must totally be missing it. I just created a fresh WPF .NET4 project in VS2010 and can't seem to find that assembly. I'll have to play with it when I get off work. Edit: That walkthrough says WPF 4.5. Is the WPF version independent of the .NET version? – Rig Feb 03 '14 at 18:47
  • 1
    @Rig You'll need .NET 4.5, not .NET 4. Visual Studio 2010 can only target up to 4; you'll need VS2012 or newer to target 4.5. I can see it when targeting 4.5 in VS2013, but not when I change the target version to 4. – Bob Feb 04 '14 at 00:15
  • 1
    @Rig It is possible to use the Ribbon in Net 4.0 - you can download it from Microsoft and then it will show up: http://10rem.net/blog/2010/10/22/wpf-ribbon-october-release (Not sure if this is the latest version). Better download it from Nuget. I had to do that for a program which had to run on Windows XP - works fine and is mostly compatible with the Net 4.5 variant, so you can rip out the 4.0 thing when XP finally retires. – Christian Sauer Feb 04 '14 at 07:27
  • @ChristianSauer That would probably explain it as 10/22/2010 would have been around when I got out of the desktop programming game. – Rig Feb 04 '14 at 13:15
  • @rig it wasn't a game. it was a war.... – Reactgular Feb 04 '14 at 14:07
-1

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

Has QUIT--Anony-Mousse
  • 137
  • 5
-2

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.

Valentin Kuzub
  • 105
  • 2