I'm using Swing with default UI (without any special skins).
How to make some buttons/textfields more bright or more pale? It means the user is expected/not expected(although not completely disabled) to press the button.
Example: user had changed a field - "save" button becomes more bright (for example, green). Status is "compilation failed" - "execute" button is pale (although user can still execute previous version of something). User filled in "password" field - he expected to fill in "password confirmation" - so it becomes bright.
I have: {normal, disabled, invisible}
I want: {bright, normal, pale, disabled, invisibe}.
How to make it properly, without hacking with drawing things, with separation of content and presentation? I want it to look well even if user overridden colour settings in the system. Should I use some other toolkit?
I expect something like I set hints for the given control, and then skin read hints and applies additional look and feel options (such as brighter background) without me dealing with concrete colours. May be one skin will use other background and some other skin will use other font for this effect. Like in enabled/disabled case, but more flexible.
Just use setBackground() to change the color to match the component's status. Maybe even create a Custom Component that has a method to change the status and it knowns which color matches that status.
I'm not sure that I see the value in what you're trying to achieve from the examples that you've provided. Is it possible that users could get confused about how the application works if you give them functionality that differs from their expected user experience?
If the user hasn't yet changed a field, the save button could be completely disabled. What's the value in being able to save if there have been no changes made. Alternatively, if you still dead set on making this distinction, can you do it in another way? Perhaps a visual queue, an icon next to the field that's changed, cell highlighting, or a * appended to the end of the text on the window name to show that there are unsaved changes in a window, perhaps?
From a purely user experience perspective, I don't think you want to go messing with the way people expect applications to behave unless you have a really good reason!
Related
I'm working on my custom ColorChooserPanel class, but I don't know how to create a ColorSwatch.
I found a class named ColorSwatch or something like that but its package private and I can't access it.
How can I ensure that I have a proper color chooser?
First, you need to think about the way this should work, to formulate your goals into action points that you can always check and see whether and how they are fulfilled:
it should be displayed
it should handle click events
it should be able to return a color (the last chosen color, or a default in lack of that)
Now, a very common way of supporting color choosers is to have something like in this image:
However, this is way too complex for a first implementation. You should first have something which "works", that is, you are able to choose colors to taste success and then work out the subsequent details. Unless you say otherwise, I'm assuming that the Basic colors section is good for now. In that case, you can create a class, which contains a JPanel, containing clickable elements. Your class needs to have a Color member, which one can get calling a getter and which is set when a clickable item inside your JPanel is clicked. The clickable items can be JPanels on their own, for example.
If you prefer something ready-made, then kindly read these:
https://docs.oracle.com/javase/tutorial/uiswing/components/colorchooser.html
https://coderanch.com/t/332515/java/Color-Palette
I find it useful to have fields colored in different way than local variables so that I find it easier to visually read the code flow.
In the same way, I would like to color method calls acting on the current instance, so that they look different from method calls acting on other instances (regardless of their type). This should affect interface methods, inherited methods, abstract methods...
These methods are most of the time self-documenting code, or duplicated code that was refactored but not deemed worthy enough of having another class handle the common logic. Therefore I find it useful to visually see I'm not leaving the responsibility of this class.
How can I achieve this in IntelliJ Idea?
I am writing this question because I have found a similar question related to Android Studio while looking for an answer to this, but when I tried to google/search the question days later it was absolutely painful as it did not come up anywhere in the search results, I did not remember how I found it in the first place. I'm writing this question in the hopes it will be useful to any future reader having the same question.
There's a way, but it's a workaround, it will have side effects.
How:
Go to File > Settings > Inspections (Choose the Global Profile if necessary).
Type in the search: qualified.
Tick the checkbox next to "Instance method call not qualified with 'this'".
Click on Severity > Edit severities, add new entry by clicking the green + button.
Name it whatever you want.
You must put it at the bottom of the list using the arrows. If you don't, the F2 key will no longer work as you expect it as it will prioritize errors at the top of the list.
Set the Error stripe mark to #FFFFFF, or the same color as the scrollbar.
Set it bold if you wish.
If you want to set a color, you must set a background color to white (or black if you have a black interface). If you don't, the color will appear black in most conditions.
If you really want to, do the same for "Unnecessary 'this' qualifier"; there is an additional checkbox to make it only apply to methods and not fields.
Side effects:
This enables inspections, which is not desired.
Pointing the mouse cursor onto the method calls will cause a hover text to appear describing the inspection.
If your code has no errors, no warnings, and no additional informative inspections, pressing F2 will jump through these calls.
So this may seem strange, but I am trying to create a very basic game that works somewhat like what an older RPG game may have as the interface (think choosing attacks from a list (ex: Pokemon)).
Right now I have a class that extends JFrame, and it contains private variables of three panels: one for displaying the sprites at the top 75% of the screen, and the other two are the ones I wish to display text on (one for announcements like, "CRITICAL HIT" and the other for the selectable choices). The second of the text boxes would only be visible sometimes, but that is irrelevant.
Can anybody start me off or lend me a hand? I am finding many way but none that seem to work for my needs.
Edit: My game is laid out and the sprite panel works exactly as it should, as much as it may sound like it, I am not rushing into anything blindly. I have the game working except for displaying the dialogs in an effective way.
EDIT 2: Ok maybe I am being unclear, my basic concern is finding the best Java component to draw strings to the bottom panels. The strings will be changing regularly, so some methods that I have tried such as the Graphics drawString() are not very effective.
Thank you,
roflha
Well, your original question statement lacks any actual cohesive question, other than "Can anybody start me off or lend me a hand?" which makes it rather hard to figure out what you really need. I discerned that what you want help from us about is displaying dialogues that popup to the user when some event happens. If you don't care too much about special effects, there are three easy ways to do this:
1) Simply have sprites for your messages, and set them to visible as needed. If you have a limited number of important messages, this makes it easy to control the visibility/flashiness of the message.
2) JTextArea allows you to simply print some text to a box. It is useful if you have a wordy console or messages that can't simply be a few images. You would just have a JTextArea in your panel, and update it as needed:
JTextArea messageBox;
messagePanel.add(messageBox);
//displays a message
messageBox.setText("CRITICAL HIT!!!");
But the user may not notice when the text changes, since it changes instantly. Whether you want to flash the text, or display some animation on top of the text area is up to you.
3) If you want a more intrusive message, you can actually have a popup dialogue where the user would have to click "OK" to continue. This is relatively easy to do, and you can even put custom icons for the message:
http://download.oracle.com/javase/tutorial/uiswing/components/dialog.html
JOptionPane.showMessageDialog(myFrame,
"You got a critical hit!!!",
"Critical Hit",
JOptionPane.INFORMATION_MESSAGE,
criticalHitIcon);
Sorry for the odd choice of words for the title, however, "border" seems to be the inappropriate term. While it is true that the visible line surrounding an icon in a JToggleButton can be made invisible by using setBorderPainted(false), the same is not true for JCheckBox and JRadioButton.
I can not use the JToggleButton and therefore need to use either the JCheckBox or JRadioButton (or some derivative of JToggleButton I am not aware of), but need the square or circle, respectively, to be non-visible when there is no icon on the button. Also, using setVisible(false) eliminates the button from the layout, however, I need the space to be reserved and not have the component layout change (using GroupLayout).
Any suggestions? Am I going to have to create a custom renderer? I will be looking at that in the mean time.
The route into this would be through customising the look at feel by changing some of the UI properties in the UImanager (the sort of thing that allows you to make simple tweaks with fonts and colours and presumably the images used for the checkboxes or radiobuttons) -- but it's many years since I last did that sort of thing and can't remember the details.
A little Googling turned up this project to inspect current property values, so might at least help with indicating the right part of the APIs to be looking at.
You have to choices here:
1) Customize Look and Feel as described in previous entry.
2) Create your own custom controls by inheriting from existing ones and overriding component painting.
I found a cheap and easy (read hack) for this. I created an empty transparent icon and used it when I didn't want any item to be displayed.
Here's a very specific coding question:
I've recently been asked to maintain some old-ish Java Swing GUI code at work and ran into this problem:
I've attached my own subclass of InputVerifier called MyFilenameVerifier to a JTextField (but it may as well be any JComponent for these purposes). I've overridden the verify() method such that it calls super.verify(input) (where input is the JComponent parameter to verify()). If super.verify(input) comes back false, I do:
input.setBorder(BorderFactory.createLineBorder(Color.RED));
This is a convention used throughout the UI of this application that started long before me, so I don't have a lot of choice as far as using other ways to get the users attention (wish I did). This is just the way it works.
Problem is, once the user goes back and types something valid into the text field, I need a way to set it back to default border (instead of just saying set it to Color.GRAY or whatever, which is a different color from its original border). I need a way to say, "remove the extra decoration and go back to normal" or just set the border to its default, in other words.
Couldn't you just call input.getBorder() and cache it somewhere before setting the border to red?
Or without caching anything, you could tell the JComponent to update its UI back to the look and feel's defaults via component.updateUI. That should make the component reset its colors, borders, fonts, etc to match the original settings.
input.getBorder()
Wouldn't it be awesome if no one ever saw this and I got away free without the ass-beating I deserve for asking this question?
Not sure how your system is build, but I think you can store the original border before changing it. So you can change it back later
// assuming the Border was not null before
if (!super.verify(input)) {
original = input.getBorder();
input.setBorder(...);
} else {
if (original != null) {
input.setBorder(original);
original = null; // not needed
}
}
You need to preserve the existing border when you change it.
One way to do this is to use the methods putClientProperty() and getClientProperty(), which you'll find documented in the API.
Another possibility, if there are only a few input widgets you need this for is to subclass, e.g. JTextField, add setBorderOverride() and modify getBorder() to return "overriddingBorder" if it is not null.
Then you just use setBorderOverride(redBorder) to make it red and setBorderOverride(null) to clear it.
This of course depends on the painting to use getBorder(), which it may or may not do, and which may be implementation specific.
Incidentally, you only need a single static reference to the border-- it's the selfsame border instance used by all JTextFields.