I want to know how I can make a JFileChooser in the Swedish language.
Unfortunately it turns out that if I could use a JDK version 10 or earlier i could actually do this by creating a Locale object and make it the default.
But we are discouraged to use this old version for any new programs.
But from JDK version 11 and forward choosing Swedish Locale no longer works.
So I have seen that people have been able to change individual strings for the FileChooser like in this example:
https://coderanch.com/t/475470/java/customizing-JFIleChooser
But this feels unsatisfactory to me.
At least for as long as I do not know how I can learn about how I can find those Strings and where they are located.
Maybe I will run into the same problem again with some other GUI component and then I still don't know what to do.
This works with JDK v. 10 or earlier:
//This is in my Main:
Locale sverje = new Locale("sv", "SE"); //Creates a instance of Locale for Swedish, Sweden.
Locale.setDefault(sverje); //Sets this to default.
//Then I call a class that opens a Frame and handles the FileChooser.
This is an example of modifying an individual string:
UIManager.put("FileChooser.cancelButtonText", "Cancelar"); //Changing cancel button text to Portugese
If I need to use this method it would be nice to know how to find the strings like I said before.
It would also be nice to know what is going on when you "put" in the new String value like in the example.
I believe that the JFileChooser somehow inherits the Strings in several steps, and that is what allows us to write "FileChooser.cancelButtonText" even if there actually is no "cancelButtonText" in the FileChooser class, rather (I'm guessing!) it inherits it from a so called ResourceBundle and then from there to the Localeclass and from there to some other class or classes before the FileChooser uses it.
So is this a correct assumption and how can you trace the Key / name / location of those strings from the FileChooser class to where the actually are?
Is it the ResourceBundle or the FileChooser or some other part that was changed since it stopped working from version 11?
Can / should I try to make changes to the ResourceBundle to fix this in the most professional way?
You can find the full list (including FileChooser keys) in the first answer of this post: List of Java Swing UI properties?
I think it will be enough setting only the properties ending in "Text".
AFAIK UIManager.put is just updating UIDefaults (the map that contains all the default names) so, as long as there is just one language available in the application, there is no need to use a ResourceBundle.
So correct me if I am wrong.
But I think the answer is something like this:
If you want to use one of the languages that is supported for the Swing Component just set the correct Locale and you are done.
If not it seems like using UIManager.put is the best way to go.
I was hoping to find a resource bundle containing all of the text strings but now I do no longer think that such a thing exists.
So my understanding at the moment is this:
The JComponents such as the FileChooser are generalized Components that are meant to work on many different platforms and operative systems.
And they use classes called "Look & Feel" to get their final form depending on the intended Platform.
This is where the UIManager comes in.
It allows you to decide what "Look & Feel" you want to use.
So in my case it will use a look and feel called:
"com.sun.java.swing.plaf.windows.WindowsLookAndFeel".
You can get this information using:
System.out.println(UIManager.getSystemLookAndFeelClassName());
And I believe that the UIManager will create classes called UIDefaults using some algorithm.
The UIDefaults will contain the values that gives the JComponents their "Look & Feel" i.e. their appearance & behaviour.
But the UIDefaults classes are not pre-existing.
They are created based on setup.
However I believe that they will get some of their data from a resource file that is not truly a ResourceBundle but at least extends the ResourceBundle class.
But this still does not contain all the necessary Strings to fully customize the FileChooser.
This link shows an example of these resource files that are specific to the Windows version (L&F) of the FileChooser:
https://code.yawk.at/java/6/com/sun/java/swing/plaf/windows/resources/
So the data is apparently split up and it does not come from a single source.
It is collected from different sources and put into the UIDefaults class that works like a Database for the values.
To sum it all up.
The best way to go might be to create a class that has a method to put all the String values into the UIDefaults using the UIManager.
And I suppose you could prepare for internationalization by letting this method get it's strings from a resource bundle that you have created yourself.
The best list of Keys seems to be this one:
https://thebadprogrammer.com/swing-uimanager-keys/
But unfortunately although seemingly exhausting there is still information missing.
To fully customize all the Strings in the FileChooser in addition to the Keys you will find in this list you will also need to change the value of this Key:
"saveInLabelText".
So these are all the String I changed and I believe they will customize most of the Strings for the Windows version of the FileChooser:
//Strings for Open file-dialogue: ***************************************************************************
//The numbers in the comments refers to the order of appearance of the Stirng values in the Frame
UIManager.put("FileChooser.openDialogTitleText","Open"); //1.
UIManager.put("FileChooser.lookInLabelText","Look in:"); //2.
UIManager.put("FileChooser.fileNameLabelText","File name:"); //3.
UIManager.put("FileChooser.filesOfTypeLabelText","Files of type:"); //4.
UIManager.put("FileChooser.openButtonText","Open"); //5.
UIManager.put("FileChooser.cancelButtonText", "Cancel"); //6.
UIManager.put("FileChooser.acceptAllFileFilterText","All Files"); //7.
//End of Open file-dialogue ***************************************************************************
//Strings for Save file-dialogue ***************************************************************************
UIManager.put("FileChooser.saveDialogTitleText","Save as"); //1.
UIManager.put("FileChooser.saveInLabelText","Save in:"); //2. This was not in the list but works!
// The strings with number 3 & 4 are the same as the ones for the Open file-dialogue so you do not need to set them here.
UIManager.put("FileChooser.saveButtonText","Save"); //5.
Related
I want to realise a GUI in java that contains columns and lines and the button "check", the goal is to check if the value of a column match with criterion.
the columns represents the names of a data file columns, and the lines represents criteria ( I want to list them in a properties file ). can you give me an example how I can do that.
Here is the main GUI widget toolkits existing in the Java world:
AWT/Swing, the old way, a pur java solution which works everywhere,
JavaFX, tends to be a replacement for Swing, part of the JRE since Java7,
SWT, use of natives functions, so the rendering is really quicker, but it may be more complicated than the two above.
About AWT/Swing, you should start by take a look at some tutorials. Then, here is the main classes you would use:
You need a check button: JCheckBox
Colums and lines ? JTable, mainly because you can extend an AbstractTableModel and easily fit the properties file. Moreover, you can save the model thanks to an ObjectOutputStream: your users will be happy to be able to save their works.
Once you start coding, feel free to ask a new question about your troubles :)
I've returned to IntelliJ after a long hiatus for Android development so I'm getting used to it again. The problem I have is that for example when you want to see where is a class being used, you'd position the caret in the class declaration and issue cmdaltF7 (on Mac OS X) to Find Usages, which is returning stuff from mapping.txt and seeds.txt as well as the .java results, and even tho I can set up the defaults by doing shiftcmdaltF7 and un-tick the: search for text occurrences and even change the scope from Project Files to a custom scope (for example), these options are not saved when I invoke Find Usages again.
Does anybody know of a way to personalize the Find Usages so it's more close to what Eclipse would do? (I.e., find the real usages instead of a text search for occurrences).
Reporting back from the future: the behaviour described in the question has now been implemented (Intellij issue mentioned in the comments).
To configure cmdaltF7 to run in a default scope, start by running it against some Symbol
Clicking on the wrench icon, one can select one of the pre-defined scopes, or create a new one (using the ... button).
The + creates a new scope. Find the folder in which to look, and click Include recursively. And voila!
Any consequent searches will use that scope until it is changed.
Instead of cmdaltF7, use the shortcut altF7. This will open a pop-up for you to make a selection about Scope, Test occurrences, and types of usage. You will have to make this selection one time. The next time you press altF7 then your choices are remembered.
The result is that altF7 followed by enter gives you what you need.
I was working on creating a weather application in Java using Weather Underground and I found that it does have data for some cities.
Initially, I was planning on using GeopIP to get the user's location automatically but since the support for cities is limited I decided to let the user choose the city every time the program starts.
I want the user to be able to choose a city from one that is supported by Weather Underground. The user will enter the name and as he/she enters the name, the possible locations will be displayed in a way similar to the one shown in the picture.
My question is:
How do I implement this search feature ?
My initial guess was to create a Vector containing all the names of the cities and then use brute force to find the match and display in a JPopup or a JWindow containing a JList but I guess there has to be a better method
Rephrase:
What I do not understand is WHAT INFO do I keep in the data structure I must use ? Should I manually create a list of cities that Weather Underground supports or is there another way to do it ?
Take a look at the Trie data structure (also known as digital tree or prefix tree). Autocompletion is one of the most common examples of it's usefulness.
The following article has a nice an very approachable explanation:
Roll your own autocomplete solution using Tries.
if you google autosuggestcombobox you will get some interesting results:
This one is written in JavaFX - I have used and extended it myself already. It is quite useful. What you get "for free" with JavaFX: a context menu with right-mouse click which is auto-generated containing some of the usual "stuff", like cut, copy & paste and even undo! So, I can recommend that solution. To get into JavaFX isn't so hard - and I think it is much easier to learn than Swing - and looks so much cooler! However this implementation has some drawbacks - especially when the layout is not left-aligned, because it is simply a text field on top of a combobox.
OK - but if you want to stick to Swing - you could probably use this one. I haven't used that myself, but the code looks quite straightforward and pretty clean - cleaner than the implementation for JavaFX I must admit (but that had some nice features). So - maybe you try - and extend it? It is built simply on JComboBox.
I've seen people use UIManager to change strings of some pre-created swing components (e.g. JFileChooser).
Where can I find some kind of reference that will tell me which strings in which components are changeable, and how can I access them?
To clarify:
I know that UIManager.put(key, newString); will change text of string that key references to, to "newString".
Where can I find the list of keys?
Keys for UIManager are Look and Feels sensitive, means (for example) value Keys for Metal Look and Feel could be diferrent when you comparing value from System Look and Feel, notice or Key missed too
use UIManager Defaults by #camickr
You're probably best of by dumping the list yourself using code like the following since keys might differ:
public static void printUIManagerKeys()
{
UIDefaults defaults = UIManager.getDefaults();
Enumeration<Object> keysEnumeration = defaults.keys();
ArrayList<Object> keysList = Collections.list(keysEnumeration);
for (Object key : keysList)
{
System.out.println(key);
}
}
For me the list contains 1365 elements on Windows 10.
These keys are provided by Swing PLAF resource bundles, and you can find them in the JDK sources. See e.g.:
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/com/sun/swing/internal/plaf/basic/resources/basic.java
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/com/sun/java/swing/plaf/windows/resources/windows.java
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/com/sun/java/swing/plaf/gtk/resources/gtk.java
...
String values for languages other than English are provided by adjacent bundle files.
And you can add one more bundle to any of these families just by creating one more file for desired human language and placing it anywhere on your classpath. Bundles in .java and .properties format work equally well, though .java format may be slightly more Unicode-friendly...
It may be good to keep in mind though that direct adding of content to com.sun package may violate the Java license. So to be on the safe side, it may be wise to move your extra resources to a package of your own and register it with UIManager like this:
UIManager.getDefaults().addResourceBundle("mypackage.swing.plaf.basic.resources.basic");
Seems like one has to run some code to see all the keys. I know the question is for java, but really the quickest way to obtain the keys is to launch groovy (or gradle) script:
javax.swing.UIManager.getDefaults().keys().toList().toSorted().each {println it}
Paste it to a file and call groovy keys.groovy or gradle -b keys.groovy, whatever tool is easier for you to get.
Without creating a file it's also doable with groovy. Simply execute:
groovy -e "javax.swing.UIManager.getDefaults().keys().toList().toSorted().each {println it}"
We have 5-10 developers working on Eclipse with Java here in our shop, and we often are debugging classes that don't have debug-friendly toString().
Along comes Detail Formatters to save the day. Hurray! But only my day. If I want to share the joy with my fellow devs, I THINK I have to do some copying and pasting, as do they.
That sucks. We've got N different version control systems that work in Eclipse... it seems like this would be something that folks would Like To Pass Around.
Nothing in the file->export... dialog. Nothing via searching the online help. Nothing.
I managed to track at least some of the settings to /workspace/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.dbug.ui.prefs, but Have Reason To Believe there's more to it than that. Plus, the thought of putting something burried deep in a hidden folder into source control puts my teeth on edge.
Is there a better way to share detail formatters? Ideally this would be something we could just check into our code repo and disseminate that way.
EDIT: I'm using Helios, Service Release 1, build id 20100917-0705.
In addition to the javaLogicalStructures extension point (for adding logical structure to given classes), there's also one called detailPaneFactories. But this is for creating the pane the text (or whatever, thanks to this extension point) the detail formatter renders to. Neither allows extenders to list existing detail formatters (or logical structures for that matter).
The bottom of the detailPaneFactories extension does have Something Interesting To Say:
Supplied Implementation:
The debug platform contributes a detail pane factory providing a default
text source viewer detail pane. The default detail pane displays textual
details of a selected element based on the corresponding debug model
presentation's implementation of computeDetail(IValue value,
IValueDetailListener listener).
computeDetail sounds promising. I'll keep ya posted (unless someone else beats me to it... hurray bounties).
Hmm... org.eclipse.jdt.debug.ui.JavaDebugUtils.getPreferenceStore() sounds promising, but I'd still rather not write a plugin for this myself.
Ah... well. Here's the code org.eclipse.jdt.internal.debug.ui.JavaDetailFormattersManager uses to load them:
/**
* Populate the detail formatters map with data from preferences.
*/
private void populateDetailFormattersMap() {
String[] detailFormattersList= JavaDebugOptionsManager.parseList(JDIDebugUIPlugin.getDefault().getPreferenceStore().getString(IJDIPreferencesConstants.PREF_DETAIL_FORMATTERS_LIST));
fDetailFormattersMap= new HashMap(detailFormattersList.length / 3);
for (int i= 0, length= detailFormattersList.length; i < length;) {
String typeName= detailFormattersList[i++];
String snippet= detailFormattersList[i++].replace('\u0000', ',');
boolean enabled= ! JavaDetailFormattersPreferencePage.DETAIL_FORMATTER_IS_DISABLED.equals(detailFormattersList[i++]);
fDetailFormattersMap.put(typeName, new DetailFormatter(typeName, snippet, enabled));
}
}
So the string in the preference store is just a bunch of CSVs with type-name,snippet,enabled,type-name... replace \u0000 with , in the snippets, and you're good to go.
That handles the export (hell, you could just dump the preference string whole hog).
Import wouldn't be much harder, though it'd be nice to not overwrite existing types, or given the user the option to do so, perhaps even with a diff of the two snippets in question.
OTOH, I'd really rather not rely on the inner workings of a class in *.internal.*.
From the Eclipse 3.8 and 4.2 M5 - New and Noteworthy:
Detail formatters can now be exported as separate preferences.
Previously the only way to share detail formatters was to export all of your workspace settings.
This closes the bug 224815 mentioned by Brian De Alwis in his answer:
"Make Detail formatters exportable" (with that patch)
Although there is nothing explicit in the preferences export wizard, exporting everything will also write the detail formatters. Just search in the output file for /instance/org.eclipse.jdt.debug.ui/org.eclipse.jdt.debug.ui.detail_formatters and share only those lines.
Update: There seems to be a bug in the importer, you have to remove the /instance/ prefix from each line before importing the file.
Alternatively, as they are stored in a properties file in the workspace metadata, you can share that (although you'll probably overwrite other debug settings if you just copy the file):
${workspace}\.metadata\.plugins\org.eclipse.core.runtime\.settings\org.eclipse.jdt.debug.ui.prefs
Using a "macro" might do the trick here.
You will have to
Install a plugin that lets you
record Macros
Start recording Macro and configure Detail formatters using Eclipse Menus
Save and keep that
macro on some shared directory
Install that plugin and run macro on
PCs used by other developers
One such plugin is : http://sourceforge.net/projects/practicalmacro/reviews/
This issue was filed in the Eclipse Bugzilla as bug 224815. The problem is that the detail formatters were overlooked when configuring the import/export preference transfers. The fix, providing it's accepted, should be in the 3.8/4.2 M6 due out at the end of January.