Java Look and Feel Design Guidelines 98
| Java Look and Feel Design Guidelines | |
| author | Sun Microsystems, Inc. |
| pages | 230 |
| publisher | Addison Wesley, 06/1999 |
| rating | 9/10 |
| reviewer | Jayakrishnan Nair (jayakrishnan@netscape.net) |
| ISBN | 0201615851 |
| summary | This book is a must for people involved in creating userinterfaces for Java applications and applets using the Java Foundation Classes. The guidelines presented in this book will allow for the design of applications with consistent appearance and behavior. |
Java Look and Feel Design Guidelines is a very practical book meant for the UI Designer as well as people involved in the design process. The large number of examples is supplemented with about 170 screen shots. Java Look and Feel guidelines for consistent appearance, cross-platform delivery guidelines, internationalization guidelines and implementation tips are mentioned in the appropriate sections and are marked by special icons. A list of books and Web sites on related topics like human interface design, accessibility, internationalization, etc., are given.
Java Look and Feel Design Guidelines is divided into three parts--Overview, Fundamental Java Application Design and The Components of the Java Foundation Classes. This book uses the word "application" to refer to both Java standalone applications and applets.
The Overview part gives a quick visual tour of the Java Look and Feel. The Java Foundation Classes are introduced and the major JFC User Interface Components are visually presented with cross-references to the pages where they are described in detail.
Internationalization allows for the development of applications that are independent of the countries or the language of the users. Such applications allow for the easy customization of the software for a particular region, thus creating a global market. The application may also have to interact with assistive technologies like screen readers, speech recognition systems and Braille terminals. The second part of the book Java Look and Feel Design Guidelines begins by giving guidelines on these two topics.
Given an empty panel, how do you start placing components on it? How much spacing do you need between a label and a textfield? The answers to these questions are given by guiding you through a step-by-step example where a simple dialog box is created using design grids. Colors, Fonts, text and layout of the elements are what create the mood of the applications. The chapter on Visual Design explains how to use these to increase the user confidence and comfort with your application.
The application that is designed for one platform may eventually run on other platforms and display systems with different capabilities. The chapter on Application Graphics gives guidelines in designing icons and buttons and using cross platform color so that the quality of graphics is not affected. Effective use of splash screens, login screens and about boxes to enhance the corporate identity is also discussed.
Part III: The Components of the Java Foundation Classes takes a look at each component of the JFC in detail. This will be the section that will be the most used in the book. Each component behavior is explained and tips regarding implementation and look and feel are given. The Appendix gives the keyboard operations available for JFC components for navigation.
An HTML version of the complete book is available at http://java.sun.com/products/jlf/dg/index.htm for those of you who like to browse the book before buying. The book does not provide code samples for any of the examples shown. Since the book is very specific one about JFC, such examples provided in the appendix or the Web site would have provided a starting point for programmers. Maybe this will come in the later editions.
Other platforms have their own books setting the guidelines. The timely publication of this well structured book has provided Java developers with an unparalleled resource for reference with its comprehensive set of guidelines. This book along with The JFC Swing Tutorial is a must on every developer's physical desktop.
Purchase this book at fatbrain.
L&F Guidelines good (Score:3)
With Java, as you lose (or will generally not use) the precise positioning, and allow layout managers to take over to place elements, you're still left with a lot of questions -- I know that when I was trying to design a Java interface recently that I noticed no key trends here. Because of the WORA aspect of Java, much of the GUI interface for programs inherited from whatever OS it was developed on (various WinXX-isms, or motif-isms for example). Having a guide such as this will help make Java apps look and feel the same across platforms, which can be very good, but for some reason, it's somewhat bothersome that the java app might not be consistant with the native apps on the computer.
A good example is how dialogs are done - WinXX tend to have the OK to the leftmost, MacOS to the rightmost. There's a few other similar examples.
What might be the next necessary step in the next java release (jdk 1.3) is to add another platform dependant part to the system so that when there are differences in the platform for placement of visual elements, the sandbox can set them up to act more like the native system.
Welsey? (Score:1)
Good overview, but you need a practical guide (Score:2)
But as a seasoned Swing developer, I would like to see in a book, not just the PR aspects (what's good, what looks nice, what you can achieve), but also some practical advice about overcoming the many bugs in JFC, the many workarounds you need to include in your code, the peculiar hacks that they've done with dialog boxes (especially in internal frames), the threading issues you may encounter (especially if you decide to multithread your front end), etc., etc.
So, read this and get inspired, try it and don't be too discouraged...
--------------------------------------
At least browse it (Score:1)
Unfortunaly occasional freeware coders haven't been very eager to read LNF guidelines so far and probably won't start now.
Ever read the CUA guidelines from IBM? (Score:2)
The problem is that nobody will read and apply anything from this book any more than they did when IBM came out with CUA guidelines manual when they created OS/2. (And that one just covered the obvious but it covered a lot of it! Even way back when before Windows 3.0)
Most software is drek because there is no QA done. This is specially true of the UI. Most skins and themes deserve to get their authors a good thrashing behind the wood shed. Finding a gem means that you had to devastate a resource somewhere.
No I didn't write the book, but I wrote the article(s) specially Rovira Diagrams (Computer Language Magazine, Jan 1990, V7N1) which gives some hints about how to think about how you integrate GUI into your apps and how you specify, code and document them...
I'll be glad when I stop looking at crap and the GUI isn't just look&feel by people who think stolen milk crates is an interior decorating "style."
Re:Ever read the CUA guidelines from IBM? (Score:1)
Don't worry about originality, worry about usability.
OT: Could anyone recommend a good beginners book? (Score:1)
I've been using O'Reilly's introductory Java book and it seems to be OK -- but it would be nice if it had a few more example programs to play around with. Some people have recommended Kris Jamsa's Java Now, any opinions here?
Waste of reading time... (Score:1)
Spend your time reading about servlets & JSP instead.
Mark
desktop space (Score:3)
Now, do you think I'm gonna be able to find space for this book in THAT?! Even the top of my monitor has stuff on it (ah, tux, looking beautiful as always)....
Re:Obviously this book is a waste of time. (Score:1)
And people wonder why there are so many crap products out there that crash when you look at them wrong. You gotta love the marketroid attitude. "Don't spend any time making a good product. Just spend money trying to convince people that they want crap."
>As usual my "open source" marketing advice is >free.
And worth every penny.
The book is also available on the web (Score:3)
Standards (Score:1)
Re:OT: Could anyone recommend a good beginners boo (Score:1)
Shudder! (Score:1)
Consistent appearance and behavior... makes your skin crawl, doesn't it?
-- Eythain
Re:Waste of reading time... (Score:1)
Crawling UIs (Score:1)
Other than that, I've seen performance approaching that of compiled C++ out of Java, if the app takes pains to avoid new. UI layers simply don't do this.
Re:Obviously this book is a waste of time. (Score:5)
Rubbish: don't talk such tripe.
The first product I worked on as a professional had 17 engineers coding like hell with no formal process. Guess what? When we introduced a formal process and started dictating our own deadlines (which seemed further in advance), our product improved, it was delivered more quickly, the user interface became usable, and most importantly, the satisfaction of our clients increased.
If you want to get up and market an awful product, that's fine by me. You're the one who will look foolish to potential clients. You're the one who will be laughed at at trade shows.
Coding standards do matter. For example, when you have people using combinations of spaces, tabs, different size indentation, different size tabs, you will not believe the number of bugs that can be introduced just because the indentation is screwed up on somebody else machine. That is the very simplest coding standard that we implemented. It saves a lot of time being able to sit down with somebody elses code and not have to figure out their conventions before fixing their bugs, or implement enhancements. A software profession shouldn't mind such things: they can keep their personal styles for their hobbies.
User Interfaces do matter. Without formal design, you can end up with an unuseable user interface that is completely inconsistent across the application. Customers generally only see the UI, and so their opinions of the whole product are based on this. It doesn't matter how good the underlying technology is, a flawed UI will lead a customer to believe the whole product is flawed. Besides, if they find a UI unuseable, they won't be able to get at your underlying technology.
Finally, with a properly implemented formal process, there should be very little UI fixing needed when the product is ready. In my experience, UI design goes in parallel with the rest of the product development. The UI design needs be started as soon as possible so that it can be reviewed (by non-engineers) and redesigned as necessary before it's implemented and the rest of the product is ready to ship.
You sound like a car salesman or a spammer.
Good Book (Score:1)
Re:Obviously this book is a waste of time. (Score:1)
Re:Obviously this book is a waste of time. (Score:1)
Obviously it was below the minimum quality or you wouldn't be complaining about it, would you?
Get off the high horse and learn to make some $$$s from all these dumb consumers out there who wouldn't recognise a quality operating system if it was given to them free, with source on a plate...
The term "bottom-feeder" comes to mind when I see a phrase like this. As a marketroid, you should also know that people use Windows as a matter of convenience. Yes it's buggy, but it comes pre-installed on their PC's and almost every program they would want to run is available for it, which is not the case with Linux.
Just as the users have their tradeoffs (quality for convenience), developers also have their tradeoffs. Coding standards really help a large project, especially if there is a lot of turnover. Design reviews and code walkthroughs are also a big help. The larger the project, the bigger the help. For smaller projects, though, these activities would take a much larger portion of the total development time, so they are usually scaled back or eliminated completely. Usually when I hear someone tell me that I should eliminate activities like these (or even worse, skip design and go straight to coding) they usually only have experience with short projects and think that techniques for the short projects scale up well.
I do care about making a good product and I'm not about to trash my principles to make a fast buck. If you think that the end goal is to get the most money, that's your opinion and that's why you're in marketing.
Re:desktop space (Score:1)
-----------
"You can't shake the Devil's hand and say you're only kidding."
Re:OT: Could anyone recommend a good beginners boo (Score:1)
You should carefully evaluate what it is that you want to do. I spent a lot of time trying to learn Java, then decided that for what I wanted to do a scripting language like Python was actually the way to go. I checked out Perl, but the maintainability seemed to be lacking (it seems that ESR and Perens have switched to Python for this reaon, from what I've read). Python is OO, so if I decide later that I really do need Java, I should be able to ease into it without as much difficulty.
hth,
>K
Re:OT: Could anyone recommend a good beginners boo (Score:2)
Re:Obviously this book is a waste of time. (Score:1)
different size tabs, you will not believe the number of bugs that can be introduced just because the indentation is screwed up on
somebody else machine. That is the very simplest coding standard that we implemented. It saves a lot of time being able to sit down
with somebody elses code and not have to figure out their conventions before fixing their bugs, or implement enhancements. A
software profession shouldn't mind such things: they can keep their personal styles for their hobbies."
Wow, where do you find programmers like that, most of the ones I've ever worked with would have absolute screaming fits if you ever dared to mention coding style standards... The majority of programmers re-write any other programmer's code to meet their style aesthestics, it's the first thing they do. The real fun comes when it's time to enforce standards, you get the 'it works, if you dont like my code, fix it yourself' attitude. Maybe I've just worked with prima-donnas, but they were productive coders, with the exception of a few who obfuscated to hide incompetance.
Re:Ever read the CUA guidelines from IBM? (Score:1)
Re:L&F Guidelines good (Score:1)
Application consistency > platform consistency.
Take games, for instance. The last time I played a game that used the platform's UI was...well, never. Game designers often invent their own special-purpose UIs, and as long as they are internally consistent and work, the users will quickly adapt.
Wylfing
"What would be the use of immortality to a person who cannot use well a half hour?"Here's one (Score:2)
one right here. Forget about swing, use FLTK instead (http://www.fltk.org/ ) Shit, write
it in COBOL, Visual Basic, assembly, anything but use Swing (er, except MFC which is even worse).
I've been using Swing for the last 2 years
(since it first came out). It's slow, buggy,
leaky, and did I mention slow. Check out the call stack at any point in a Swing program - it's
about 15 levels deep.
Doubtless I'll be called a troll for this. Fine, fuck you too, but I do know what I'm talking about. I admit I'm kindof bitter about this, but if people had been honest about Swing before I got into it I would have been saved a ton of grief.
Re:OT: Get Java in Nutshell 3rd Edition (Score:1)
-Peace
Dave
Slow? yep (Score:1)
Re:Obviously this book is a waste of time. (Score:2)
Uh-huh. If I was laughing all the way to the bank I wouldn't be bothering myself with this discussion.
"magic power of marketing spin"
You obviously haven't been using that today. Anyway, I haven't met anybody who has enough "magic power of marketing spin" to sell me a thing. You'd be a fool to try it on me.
"Rest assured I will take steps to fire anyone who suggests I am wrong. I KNOW development, I've been there and done it all before. You cannot tell me anything I don't know"
That sums it all up: you are a fool! Perhaps that is why you need to hide as an anonymous coward when posting? I haven't met anybody who knows everything (I have met a few arrogant/pompous twats who THINK they know everything - but I've taking pervse pleasuring in showing them up, which CAN ALWAYS be achieved).
Re:OT: Could anyone recommend a good beginners boo (Score:1)
*Follow* the existing standard instead! (Score:3)
The problem with this book is that there already *are* UI standards, and they decide to *not* follow them, and create their own instead.
Lets remember why a UI standard is good: It makes the behaviour of different programs consistent and predictable. The user does not have to learn a whole new way of working for each application, and when switching between program, the user does not have to remember a lot of special rules, but can focus on getting things done.
Unless these java programs are run in a java only environment, which I believe does not exist in the real world anytime soon, software written according to this "standard" will in fact be different, non-standard, and expose the poor user to the exact problems that a UI standard is supposed to solve.
Not much content in this book (Score:1)
references for design decisions throughout the book. As a result, many
of the guidelines seem arbitrary and somewhat whimsical.
I agree that it may be more prudent (at this point in time) to
create a layout manager that places objects consistent to the
current look and feel.
-B
Re: (Score:1)
Critique of book (Score:3)
In other words, its better than nothing - L&F guidelines good - incomplete guidelines bad.
The best thing about this book is the bibliography, which is very comprehensive and lists a lot of things you should read.
They're very open about the fact that they've simply copied a great deal from their references. Which is good - no point in reinventing the wheel, but there is a lack of imagination.
Here's my main objections:
You can summarise the entire book thus:
If an MS Windows standard exists, follow it blindly and without modification
If no Windows standard exists follow the Mac.
e.g. Close Window is Ctrl-W which is a Macism.
Find is Ctrl-F, Find again is Ctrl-G. Again Macisms. And why? Because there is no standard for find and find again on Windows. (OK alt-f4 is close window, but you can't really do that one handed unless you're a Vulcan so it doesn't count).
It sticks firmly to the Java Look and Feel - not touching any of the real issues or problems with this Look And Feel
e.g.
Windows - OK on left, File->Exit to quit
Mac - OK on right, File->Quit to quit
Linux - OK wherever, File->Quit, File->Exit both common
The Java L&F again follows Windows and Swing has no facility for the sort of overlays supported by Mozilla to deal with these issues.
According to Sun this is not a problem. The whole point of the Java L&F is that it works the same on all platforms, they say.
Oh dear. Sun demonstrate once again that they have no understanding of end users whatsoever.
Every application on your computer uses
File->Quit and has right hand side OK button. So you can just adapt to this one app thats totally different. Well yes, people are adaptable, but the idea of a set off look and feel guidelines that enshrines bad practise into the standard makes me slightly queasy. People want to get their jobs done, not suffer through Sun's UI designer's latest misjudgement.
The single biggest screw up in the Java L&F is the insistence that the alt key must be used for shortcuts. You cannot override this in your application.
This is a disaster area from an internationalisation standpoint - you can't enter a whole bunch of characters when using the Java look and feel as the native OS needs to use the alt key as part of it input method. Doh! Never mind about the Swedes, or those pesky Norwegian teenagers eh?
Speaking of UI - why is the comment entry text area on Slashdot so damn small?
Oh - and the screenshots show modal dialog boxes with *close boxes*. ARGGGGGHHHHHHHHH!!!!!!!
Lord Pixel - The cat who walks through walls
Re:Crawling UIs (Score:1)
The only strangeness with Swing I've seen recently has been with Font differences between WinNT and Solaris. A majority of my work lately has been doing WinNT Java clients that connect to a Java middle layer on Solaris via CORBA. The performace with Swing is greatly improved since they don't rely on heavyweight native UI peers so much like AWT did. Also the Swing API is not thread-safe so there's no waiting due to synchonization on any methods (I haven't looked at the Swing code to see if they have alot of synchronized blocks of code). UI performance on PII400 has been very acceptable and I haven't had any complaints from any users about performance.
I'm working a contract now and so I got the crappy equipment at the customer site. I have a P5 166 and so yes my UI performance is very crappy. I'm thankful that all of our builds are happening with Clearcase on a speedy Solaris server.
Re:L&F Guidelines good (Score:1)
Re:Obviously this book is a waste of time. (Score:1)
Then they would be fireed where I work...
"The majority of programmers re-write any other programmer's code to meet their style aesthestics, it's the first thing they do."
How do your configuration management people keep track of changes when a diff shows 90% of the file has changed, and it turns out that it was because some prick re-indened the file?
"The real fun comes when it's time to enforce standards, you get the 'it works, if you dont like my code, fix it yourself' attitude."
We created coding standards up-front. Code that does not meet the coding standards will NOT make it through the code review. It is then the job of the enginer that wrote the code to fix it before it will be included in the baseline. In short, code is assumed to be broken until it makes it through review. Code that fails the standards is broken by denfinition. Period.
"Maybe I've just worked with prima-donnas, but they were productive coders, with the exception of a few who obfuscated to hide incompetance."
They wouldn't have been able to hide their incompetance if they followed coding standards. Besides that, it almost sounds as though these coders never had their code reviewed by their peers. We do. Every line. That's part of the reason for coding standards. I'm a firm believer in peer review. As such, I believe in coding standards. If nothing else, they make per reviews easier, since everyone is familiar with the coding style.
Re:*Follow* the existing standard instead! (Score:1)
The ambitious way would be the "when in Rome..." approach, so that the applets somehow could switch at least some of their behaviour to fit in with the desktop environment where they run at the moment. I don't know how feasible that is.
Re:Gcj/libgcj/classpath/gtk/swing (Score:1)
Re:OT: Could anyone recommend a good beginners boo (Score:1)
Sun guidelines apply to Metal L&F (Score:2)
It suggested that if you're coding for a particular platform then use the appropriate guidelines for that platform. So the Windows guidelines apply when you use the Windows L&F. The Sun guide recommended using the Metal/Swing L&F if it was likely that your app was to be used on more than one platform.
I design and build UIs in Java every day. I always follow the Windows guidelines because even though my code could be run on a UNIX box, it won't be.
While the Sun guidelines are pretty good, I would only recommend buying the book if you design with the Metal L&F.
Re:Here's one (Score:1)
Slow's been handled... Buggy takes time (and two years ago, Swing was pretty new so one wonders if you expect perfect 1.0's) and leaky... well that's typically the coders fault for not cleaning up listeners and a profiler/memory tool will track that.
I'll use Swing thanks. It works here because I don't expect magic bullets for no work done.
Re:Good overview, but you need a practical guide (Score:1)
BTW, the threading issue is simple; you don't! :)
(You despatch a worker to service the display if you have any suspicion that there'll be multiple calls on the UI).
It's ok (Score:2)
There are open issues in the book - like in most GUI design guides. They sometimes don't follow their own rules in the book. So what? GUI design is hard, and the book authors have experienced just that with their own examples. They could have made the icons available for usage in own applications, they could have spent a few more words on how to actually implement some of the recommended behaviour. Like in most GUI design guides, they didn't - there are other books which fill the void.
They got some things plain wrong - at least in my opinion. E.g. placing dialog buttons to the lower left ensures the longest possible mouse move to reach one of the buttons (you click in an upper left entry field to start entering data, then you grab the mouse again and you have to move it to the lower right side of the window to click the button. They have "Close" instead of "Ok" buttons in notification dialogs - shiver. What does this mean? Nothing, other GUI design guides have the very same problems.
What do you get if you follow the advice in the book? A logical, predictable GUI, not to alien for the typical John Braindead who uses Windows or Mac. A GUI with the distinct Metal L&F. If you don't want that, don't use the book.
Will the book solve all your (GUI) problems? Nop. If you can't design GUIs, if you are not talented, if you don't have end user feedback, you will remain the very same clueless idiot you were before reading the book.
BTW, there is a general pattern in GUI design discussions. On one hand you have those who don't care, who don't know pain, and who develop crap. On the other hand you have the talented people who know that every GUI is just a compromise and a good GUI is a constant battle for perfection (which is never reached).
The first mentioned ones cry out loud whenver the words "GUI design guidelines" are mentioned (they deeply fear GUIs, because they know they always lose). The later ones invoke their brains and pick the useful stuff out of such guidelines (they too know they will lose, but they prefere to battle in style).
Re:Thats great, but Sun DISABLED L&F on Linux (Score:1)
In case you haven't noticed, desktop vendors can be a touch tetchy about UI design, Apple particularly. What about lawsuits about Aqua, or the design of the iMac? A sure way to kill the beleagured Java on the client would have been to (further) alienate the two major desktops.
On Linux you can use the default, Metal L&F or the Motif L&F. And if you miss Windows that much, you could write your own Win-like L&F and use that.
Re:*Follow* the existing standard instead! (Score:1)
Lord Pixel - The cat who walks through walls
UI standards not just for newbies (Score:1)
Think of the confusing array of copy keystrokes you may use in a day:
esc w (emacs)
ctrl k ctrl u(pico)
ctrl x (windows)
ctrl insert (secureCRT under windows)
the attention you have to spend tracking this stuff would be better spent elsewhere.
That is the relevance of a book like this. However, the reviewer doesn't discuss the quality of the standards given by the books, which makes the review much less useful.
Not usable == unusable (Score:1)
Still, if a product is unusable, it is real hard to market.
Re:L&F Guidelines good (Score:2)
Let's see some credentials. You certainly don't talk like an expert in the field of marketing, much less an acknowledged one. And you give us no evidence to believe you, and plenty not to.
Who is the #1 software producer Apple or Microsoft ?
On what scale, might I ask? Here, at least, you sound like a marketer. I'll give you that much.
Answer: Microsoft, because they know when to quit coding and start MARKETING
Which also explains why most of their software is so bad (I have to give a nod to Excel, which I'm forced to admit is respectable). However, here you also talk like a marketer.
Apple have seen the light recently in this regard, but as a marketing expert with an extremely technical background (NT admin, VB developer)
Again, spoken like a true marketer. NT administration hardly qualifies as "extremely" technical (technical, yes, "extremely," no). Nor does developing in VB, which even Microsoft markets as being for non-technical people.
I have to ask the question who are Sun or Apple to tell me how to write my GUI ? Do they know my target market ?
Um, yes, they do. Both of them, especially Apple, have spent millions of dollars researching human interface design. Who are they to tell you how to design your GUI? People who know more about GUI design than you do, that's who. You could do worse than to take the advice of experts.
Are they paying my development staff ? No they are not.
Directly, no, But consider: well-designed apps lead to good reviews. Good reviews lead to better sales. Better sales lead to more profit. More profit leads to better-paid developers. So, in an indirect way, they are helping to pay your development staff.
So they can go to hell.
So you'll have company after your boss and co-workers kill you for writing buggy apps with badly-designed interfaces? I can see why you wouldn't want to be lonely, but I don't think it'll happen.
Re:L&F Guidelines good (Score:2)
Things like Glade allow you to describe your GUI in XML. It's possible that you could write a high-level description of what you want in XML, and then use a 'Windows L&F style sheet' or a 'Motif L&F style sheet' together with a set of icons to automatically produce the desired effect. Or maybe this would be better done by actual code rather than getting carried away with style sheets. It would be very cool to simply say what you want the user to input, and have the layout taken care of by platform-specific rules.
Re:L&F Guidelines good (Score:2)
Inventing a special-purpose UI could be useful for a real-time god game, where everything has to be quickly accessible. But even in these cases the UI could often be made less bizarre and more intuitive without spoiling the game.
Re:Critique of book (Score:1)
This is incorrect. The Java Foundation Classes themselves do not support other shortcuts but ALT+key, but the framework is very easy to extend by using the normal methods of OOP.
Check out jEdit [gjt.org] for example. Most of its shortcuts are CTRL+key and many are behind two control keys, like CTRL+e CTRL+x.
Framework does not support it, but it doesn't mean it can't be extended to support it.
Re:Critique of book (Score:1)
Well, actually, let me clarify what I meant...
By default mnemomics are bound to the alt key.
So you download a mail program that uses alt-s for send, for example...
So if you're using a computer that needs alt (or option on a Mac) to enter certain characters, then you can't enter the character that alt-s sends into a mail message, because it will always be interpretted by Java Look and Feel as the mnemomic for send. (whoops, there goes a half written message).
If its your program, fine, you can edit the source. But if you're just a user, one who speaks a different language to the author or the software, and has a computer running a localised version of a *different* operating system to the author, your mileage in getting the change is going to vary. The author won't see the problem, so you're relying on goodwill of the individual or company. If its a popular program with many existing users, they won't like having the shortcuts changed.
BTW - this applies to the Java Look and Feel. If you use the Windows or Mac or Motif Look and Feels, they all handle keyboard shortcuts in a platform specifc way.
Lord Pixel - The cat who walks through walls
moderation... (Score:1)
Re:Critique of book (Score:1)
Hmm, well my keyboard has 2 different alt keys, ALT and ALT GRAPH. Some of the older JVM's didn't handle the OEM keys correctly and didn't differentiate between the two alt keys. The newer ones work fine.
Is this the problem you're talking about?
Re:OT: Could anyone recomme a good beginners book? (Score:1)
Re:Thats great, but Sun DISABLED L&F on Linux (Score:1)
on "peer" components. The peer components are the
native versions of the Java ones. So on a Mac
you're not going to have Windows peer components
because there are no libraries for drawing
Windows UI components on a Mac. Now apply that
to all the OS's. Duh.
Re:Shudder! (Score:1)
Re:Critique of book (Score:1)
Here's a real example:
Say you're a British Mac User. On a British Mac keyboard:
shift-3 is the British pounds Sterling sign £
shift-4 is the dollar sign $
alt-3 is the hash sign # (what Americans would call a pound sign, for historical reasons
In the Java (Metal) Look and Feel, you cannot type the # symbol, as Swing grabs this event and treats it as a keyboard mnemomic. I think this is true *even if* alt-3 is not actually in use as a mnemomic in the application in question.
Even time you try to type in a # it just sits there, and the application writer cannot easily fix this.
Again this is Mac OS based - but some of the Scandinavian languagues use the shift- to enter accented characters and the like. So to enter "normal" punctuation like % $ & ^ you need to use the alt key.
This would apply even more so to the Japanese, Chinese, Arabs etc. And potentially the input method for any OS could be thus broken by the Java Look & Feels draconian 'standard'.
BTW - if you look at any modern PC keyboard, you're unlikely to see alt and alt-gr. Mostly you'll only see alt. Java does not handle OEM keys. I can't remember the last time I saw an app that uses alt-gr as anything other that alt.
I sincerely doubt its possible to detect the difference between alt and alt-gr. I know for a fact that its impossible to detect whether 'Return' on the Keyboard on 'Enter' on the Numeric keypad has been pressed.
(On PCs both keys are usually labelled Enter, on Macs and Sun boxes one is Return one is Enter and they frequently do different things)
Java applications cannot do this. Sun have declared that in Java both keys do the same thing. They're indistinguishable at the application level, you can't tell which the user pressed. If you don't like this decision: tough! is the message...
Lord Pixel - The cat who walks through walls
Re:Critique of book (Score:1)
Scandinavian keyboards use Alt Graph to enter @£${[]}\~ keys. Its not the same key as Alt.
if you look at any modern PC keyboard, you're unlikely to see alt and alt-gr.
This is NOT true. All the keyboards I've seen have Alt Graph. The reason is mentioned above. I need it to type.
I can't remember the last time I saw an app that uses alt-gr as anything other that alt.
All mine do, I have different functionality in Alt and Alt Graph. Its OS specific. Applications don't have to worry about it.
I sincerely doubt its possible to detect the difference between alt and alt-gr.
You can detect the difference between Alt and Alt-Gr just as easily (or not easily, depends on your expereince, tool in use, etc.) as you can detect difference between enter and return. It's a low level job. It's not impossible. At all.
In KeyEvent class:
public static final int VK_ALT
public static final int VK_ALT_GRAPH
There you go. Two different keys.
If you don't like this decision: tough! is the message...
It can be done just as easily as it can be done to Alt and Alt Graph keys. If there's a real need for differentiating Enter and Return, just ask for it. It's not that big a deal.
Re:Critique of book (Score:1)
if you look at any modern PC keyboard, you're unlikely to see alt and alt-gr.
This is NOT true. All the keyboards I've seen have Alt Graph. The reason is mentioned above. I need it to type.Quick survey of the office:
Dell - no Alt Gr
Hewlett Packard - no Alt Gr
Sony - no alt Gr
Acer - has alt gr
Roc - has alt gr (ancient machine)
Compaq Arabic - no alt gr
Compaq Chinese - no alt gr
Compaq Japanese - no alt gr
AST Russian - has alt gr
Sun - Tellingly, has alt gr
So most keyboards do not have it. I suspect yours do because its necessary for the typical Scandinavian input methods. As someone who is not American but lives in the US myself I can sympathise when this sort of thing. Someone no doubt thought that because typical American users don't use the keys differently, no one at all uses the Alt-Gr key anymore.
This is not really the point of the discussion though. In fact, I have other messages in this thread explaining why this is so important for Scandinavian input methods on the Mac OS. Believe me, I'm on your side!
You can detect the difference between Alt and Alt-Gr just as easily (or not easily, depends on your expereince, tool in use, etc.) as you can detect difference between enter and return. It's a low level job. It's not impossible. At all.
In KeyEvent class:
public static final int VK_ALT
public static final int VK_ALT_GRAPH
There you go. Two different keys.
It can be done just as easily as it can be done to Alt and Alt Graph keys. If there's a real need for differentiating Enter and Return, just ask for it. It's not that big a deal.
Um, now you're just being deliberately obtuse. Looking in the same KeyEvent class, you will see that there clearly is not a VK_RETURN to go with the VK_ENTER. So what's your point?
Sun have deliberately left this out of their implementation. You cannot just do it as a low level task. Its hidden from you in Java as there is no way to access the Keyboard at a lower level and Return and Enter have deliberately been made to return the same event
As for 'just asking Sun for it'. Have you ever tried anything like that? Go look at the top 10 bugs in the bug parade on java.sun.com. If they will not fix those, what makes you think they'd change policy on something like this just because some one asked them nicely? Sun (like most big companies) are notoriously deaf about this sort of thing.
I don't understand your argument. We agree that people need different keys for different things, often depending on their OS or native spoken language. But since ALT and ALT_GR just happen to be defined by Sun (which suits your puproses) and Enter and Return just happen to be undefined by Sun (which doesn't effect you but annoys me), you seem to be saying that there's no room for improvement in Java's handling of the keyboard. I don't see how you can see and feel strongly about one problem, without realising that the similar case will cause problems for other people
I'll re-iterate - if you can show me some Java code that call differentiate Return and Enter I'll take this all back. It is impossible as things stand
Lord Pixel - The cat who walks through walls