Firstly, I am aware that my question may take some flak because JavaFX has its own FileChooser (that is largely superior/preferable to Swing's JFileChooser) and that mixing FX and Swing should be dissuaded. However - I will explain the functionality I'm trying to build and I am very open to suggestions on how else get there - if indeed I'm going in the wrong direction.
So firstly - the main application is built in JavaFX and is designed to calculate and archive parameters for biological samples. The primary observable is a tabPane wherein a new instance of a tab is generated for each new sample. As well as calculating and archive parameters for each sample, the user is also be able to store any type of data file in relation to each sample within the project. This is just for archiving - I do not plan to have in depth interaction with these files. Now, I come from a UNIX background and would very much like a sensible data structure to my "Project Folder" which can be sharable, externally editable and human-readable. In this regard, my overall idea was to make my saved output as follows:
A root folder (i.e. not a bespoke file format - just a classic folder)
Within the root folder:
1. A main XML file detailing specifics of the project
2. A second tier of folders - one for each tab of the project
Within the sample-specific folders:
1. An XML file detailing specifics of the sample
2. All the imported files/data in relation to this sample
Now - that all being said, I have the open/save functionality I'm aiming for functioning with Swing's JFileChooser. With a customised FileView class underpinning the JFileChooser, I can define a specific type of folder (both in relation to a pseudo-extension and its internal files and their content) as untraversable, give it a specific icon and then open it with the filechooser, in effect, as if it were a true file.
However, with the JavaFX Choosers, this becomes complicated. Because the ShowSaveDialog method does not exist for DirectoryChooser, from having to use FileChooser.ShowSaveDialog(), you can easily incorrectly save a folder within an already existing project (instead of rewriting it) - as, at least in OSX, this is poorly highlighted in the system file explorer. A further pain is that in selecting a folder - it does not populate the savename input box, the explorer simply descends into that directory.
Likewise - in opening a folder, the FileChooser.ShowOpenDialog() is clearly inappropriate. Using DirectoryChooser.ShowDialog() here is much more palatable, however the distinction between normal folders and project related folders (i.e. setting them untraversable and defining an icon) is something still better handled in Swing's JFileChooser.
Therefore, is anyone able to recommend how I can open a JFileChooser from within my FX app? I've tried running JFileChooser from a SwingNode, but I don't think I've implemented it correctly.
Dialog SaveDialog = new Dialog();
SaveDialog.setTitle("Save Project");
SaveDialog.setResizable(true);
SwingNode swingnode = new SwingNode();
JFileChooser SaveChooser = new JFileChooser();
SaveChooser.setAcceptAllFileFilterUsed(false);
FileNameExtensionFilter filter = new FileNameExtensionFilter(".prot projects", "*.prot");
SaveChooser.setFileFilter(filter);
SaveChooser.setFileSelectionMode(JFileChooser.FILES_AND_DIRECTORIES);
FileView view = new main.COBFileView();
SaveChooser.setFileView(view);
swingnode.setContent(SaveChooser);
SaveDialog.getDialogPane().setContent(swingnode);
Window window = SaveDialog.getDialogPane().getScene().getWindow();
window.setOnCloseRequest(event -> window.hide());
SaveDialog.showAndWait();
Or, on the other hand how I can replicate this functionality using FX?
Any help would be greatly appreciated!
Related
I am implementing a Java application using the Swing GUI framework on macOS. When using the system look and feel and a screen menu bar, Swing automatically inserts a search field called Spotlight for Help into the first menu labelled "Help" of the menu bar of a frame:
System.setProperty("apple.laf.useScreenMenuBar", "true");
try {
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
} catch (Exception e) {
e.printStackTrace();
}
JFrame frame = new JFrame();
JMenuBar menuBar = new JMenuBar();
JMenu helpMenu = new JMenu("Help");
menuBar.add(helpMenu);
frame.setJMenuBar(menuBar);
As my application is localized, the English string "Help" is different in other locales (e.g. "Aide" in French). But in those cases Swing does not insert Spotlight for Help since the string is different:
Solution
Bundle the .class files and resources (image, sound, video, localization files, etc.) of your application in a .jar file with Oracle's Java Archive.
Bundle your .jar file in an .app directory with Oracle's AppBundler (for Java 7+, which replaces the old Apple's JarBundler for Java 6).
Add to the .app directory the Contents/Resources/<locale>.lproj directories for each locale that should be supported by your application (you can let the locale directories empty since the localization files can be already in the .jar file).
Launch your application (double-click on the application icon in Finder or type open <application>.app in Terminal).
The search field Spotlight for Help will appear.
Explanation
I'm going to make a guess and it's that you're executing the .class files directly (from an IDE, for instance) or the .jar file, because from what I know this should be working.
Although what most sources say, Swing is deeply rooted on system calls and thus relies on the OS for many features, like in this case. Ideally, this should be covered by the method setHelpMenu(JMenu) but as you'll notice this has never been implemented.
If you check first, you'll notice that there's no extra component added in your JMenuBar and you have no control over that. If you try using AWT's MenuBar instead you'll see the behavior is exactly the same although, insterestingly enough, the method setHelpMenu(Menu) it is really implemented but doesn't add the search field if the menu is named something different from "Help".
At this point I found a workaround and it's setting the menu label to "Help" and once displayed (don't use ComponentListener.componentShown(ComponentEvent), this won't work, use AncestorListener.ancestorAdded(AncestorEvent)) changing the menu label to the localized one. This will add the search field to the help menu. However the search field will in English, with the label "Search".
Checking the API, it's more than clear that in Swing this feature is not implemented and fully relies on AWT. AWT on the other hand has partly implemented the native calls to the OS, but it's not wired to be invokable. Reaching this point and knowing that the search field does appear in our application and that in other ones running in Java it's properly localized lets us hint that this is a trait of the OS itself (I might be wrong at this point and it's really AWT doing the dirty job, but wasn't able to find any piece of code that does it directly, although in Objective C you can define any).
Reading the documentation about how to localize a Java application in MacOS, we note that:
it's a requirement that the application be bundled in an .app directory and contain the Contents/Resources/<os-locale>.lproj directory, so that the OS recognizes the OS locale as supported by the application, and consequently expects a menu labeled with the OS-localized "Help" string in order to add the OS-localized search field to that menu;
otherwise, the OS treats the application as en_US localized, and consequently expects a menu labeled with the en_US-localized "Help" string in order to add the en_US-localized search field to that menu.
Now you can type open <application>.app in Terminal and your application will be launched with the OS-localized search field added to the help menu.
Note that Apple has its own mechanism for forcing the application to use another locale than the OS locale, and it's using the -AppleLanguages option (open <application>.app --args -AppleLanguages "(<locale>)"). The Language Switcher utility does the same under the hood. Again, the appropriate Contents/Resources/<locale>.lproj directory should exist, otherwise the OS will treat the application as en_US localized.
How you make an .app directory from the .class files and resources (image, sound, video, localization files, etc.) of your application is beyond the scope of this question because it varies depending on the platform you're using, but Oracle provides the Java Archive (to make the intermediary .jar file) and AppBundler (to make the .app directory) utilities.
Screenshot
The OS is localized in Spanish in this screenshot but the application is localized in French, because it's been launched with the -AppleLanguages "(fr)" option.
I have just found out another way. No need to add empty Contents/Resources/<locale>.lproj directories in the .app directory, just adding these two lines (key-value pair) in the Contents/Info.plist file of the .app directory works:
<key>CFBundleAllowMixedLocalizations</key>
<true />
And the new way to make an .app bundle is to use Oracle's JavaPackager command-line utility, which is part of the J.D.K. It generates an .app directory with a Contents/Info.plist that has the above two lines by default (no need to pass the key-value pair as an option of javapackager in the command-line). And forcing another locale with the open <application>.app --args -AppleLanguages "(<locale>)" command really works with the <application>.app directory generated by Oracle's JavaPackager, contrary to the one generated by Oracle's AppBundler.
I am displaying a list of files; i.e. xls, doc, pdf, odt etc., in my Java application (Eclipse RCP). When the user clicks on the file, I want to launch the appropriate (according to what the OS thinks) native application, just like it happens in Windows Explorer or the Finder.
And while I am here: It would be nice to also display the same icons that Finder or Explorer use for the different file types.
Is there a library or Eclipse plugin for this?
What you want is java.awt.Desktop:
Desktop.getDesktop().open( file );
I have found an API in Eclipse's SWT now that seems to do the trick:
org.eclipse.swt.program.Program "provides access to facilities for discovering operating system specific aspects of external program launching."
It has methods to find the program for a given file extension, get the program's icon, and even launch the program.
Sounds like you're after the Java Activation Framework ("JAF"). This API lets you determine what files are and what actions you can do on them. Or alternatively the Java Desktop Integration Component ("JDIC"). JDIC allows you to create and no doubt query file associations.
Both projects seem to be in a semi-abandoned state howeer (sigh). But that's par for the course for Sun these days. Only other thing I know of is some Windows specific third party library that's based on JNI called Winpack. It does a bunch of other things too.
You can get the associated icon using the FileSystemView class (Java 1.4+).
I am trying to create a program were the user drags a file into an area (currently a JTextArea, but can be another container) and it adds the absolute path of the file to an ArrayList. I am having trouble figuring out how to implement drag and drop of files.
so far I have tried reading some similar questions but they aren't really helping me.
(also this is targeting windows but linux/mac support is an option as well)
Have a look at oracles page about DnD. Basically you can drag everything into your program, should it be a file directly from a native browser or the JFileChooser. What you are dragging is only the path to the file. So you only have to set your JTextAreato accept drops and define how it has to "interpret" the object that was being dropped.
Here is a full blown example.
What is the difference between Java working set and Resource working set in Eclipse?
The Resource working set is more general and it can include not only the Java applications / projects, but let me put it this way:
Let's assume a daily life of a Java developer. Do you suggest him/her to use Resource working set over Java working set? Is there any specific situation in which you prefer one over the other?
It sounds like this should have answered the question:
http://www.avajava.com/tutorials/lessons/what-is-a-working-set-and-how-do-i-use-it.html
A Working Set is a subset of your Eclipse projects. You can create
different Working Sets and then select which Working Set to display in
the Navigator view.
Specifically:
"Working set" (in this particular context), is an "Eclipse thing"
The purpose of Eclipse working sets is to help organize your projects
A project consists of "stuff": source code, bitmap graphics files, WSDL's, CSS style sheets - just about anything imagineable.
Consequently, Eclipse projects are organized (glancing at my J2EE perspective, for example) into subsections like "src", "WebContent", "Services" and so on. A project itself can be one of many different types: a "Java project", a "Java Swing Design project", and "Dynamic Web Project" and so on.
Similarly, an Eclipse Working set can be one of several different types: a "Java working set", a "Breakpoint working set ... and a "Resource working set".
As with Eclipse "Views" and Perspectives", you can usually access any project resource you need any time you need it. Selecting one or another perspective simply makes the object (e.g. "Problems pane" or "Build list") easier to get to.
Which kind of "Working Set" you choose - or whether or not you use working sets at all - is largely just a matter of personal preference and convenience.
Please let us know if you still have any further questions.
PS:
Additional links:
https://www.ibm.com/developerworks/library/os-eclipse-visualstudio/
As mentioned, many developers load all their projects into a single
Eclipse workspace. It's convenient, but it can sometimes create too
much clutter. In addition to closing unnecessary projects, you can
define working sets: groups of elements (projects, folders, classes,
etc.). Eclipse can use working sets in different views (such as
Package Explorer) and operations (like searching).
...and:
help.eclipse.org: Working Sets
A working set in the context of eclipse is a logical grouping of related projects to ease search and organize views within the IDE.
A resource working set can capture all types of resources - maybe java source, html, xml, javascript, images - anything that exists within the scope of the projects included into the working set.
The Java working set is a different working set (it is NOT a subset of a resource working set!) which captures only those java files which belong to a source folder and are being compiled into the classpath, or those java files which belong to a module (library) in the build path. Hence, it lets you lookup java "classes" which are in the classpath. Note that all java file in your project may not necessarily be built into the classpath (for example when you exclude a java source file, it does not get built any more). But a java source file which is not included in your classpath can still be detected by a resource working set (you will notice that the icon for an included java source file is a solid J, while for an excluded java source, it is a hollow J).
Example:
Say you have two projects p1 and p2 of which p1 belongs to the working set but p2 does not. So:
MyClass.java (belongs to p1 and included in build path) - Shows up in java type search (Ctrl + T) and also in resource search (Ctrl + R).
MyOtherClass.java (belongs to p2 and included in build path) - Does not show up in java type search nor in resource search.
MyExcludedClass.java (belongs to p1 and excluded from build path) - Does not show up in java type search but shows up in resource search.
MyExcludedClass.class (belongs to a dependency jar in the build path of p1) - Shows up in java type search but does not show up in resource search.
MyWebPage.html (belongs to p1) - Does not show up in java working set but in resource working set.
MyOtherWebPage.html (belongs to p2) - Does not show up in java type search nor in resource search.
MyConfig.xml (belongs to p1) - Does not show up in java type search but shows up in resource search.
So, in the context of a Java developer's use: I use Java working sets to look up types / classes defined in Java, whereas the resources working set to lookup all different types.
One difference between the working sets is that they provide different editing wizards (as stated here: http://help.eclipse.org/helios/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Fconcepts%2Fcworkset.htm). If you edit a resource working set and a java working set respectively you will see they use different screens for selecting which resources/projects are included.
Apart from this I haven't found any other difference. It also does not seem to differ which resources you can choose in any way. So to answer your question which one would be recommended I would answer "it doesn't matter" since they behave the same way.
A working set is a subset of your workspace and is a way to organise all your projects. With the different types of working sets you have also different types of editing wizards as described here.
Editing wizards
For java projects the Java working set is a more comfortable way to work. Let's assume you have a bunch of java projects in a java working set and you have just opend the editing wizard of the Java Working set:
First of all you can see everything what is in the working set at the moment in the right table. If you now want to include another project you can simply select the project(s) and press CTRL+a. To remove a project you can press CTRL+r
In the Properties of a Resources Working set you don't know what is in the working set until you have scrolled to the bottom of the tree view. This is impossible for people who have 300+ projects in their workspace.
Structure
A benefit from having two types of working sets is structure. There are situations in a daily workflow where it is useful to have different types of working sets, because they have different icons. If you have resources like config files you can create a Resource working set namend 'config files' and put all the files in there.
Afterwards you can open your File Search and search in your config files. This is possible because you can define a working set as a scope for a search.
There are several parts in Eclipse where you can select your working set with the Select working set dialog.
I'll try answering from the perspective as a plugin developer. From the API:
A working set is intended to group elements for presentation to the user or for operations on a set of elements.
This can be any kind of element and does not have to be a project. Working sets are provided by plugins, which can decide what kind of elements can be added and which provide wizards for adding elements as well as operations that can be performed.
It doesn't really matter for a project in which working set(s) it is in. A Java project is still a Java project if it in a resource working set. It only affects some views, dialogs and operations that filter for certain types of working sets.
Besides Java and Resource working sets, there are also Breakpoint, Task, Plugin and C/C++ working sets (depending on your Eclipse setup of course). Some views only show certain types of working sets while other views don't seem to filter them. For example the "Open Type" and "Open Resource" dialogs seem to display all types of working sets. The "Open task" dialog only shows task working sets.
So what is the actual difference between Java and Resource working sets? I haven't seen any functional differences yet. All standard views and dialogs either seem to handle both or none of these two working set types. Most plugins don't seem to care about the distinction at all - but that doesn't mean some plugin could handle both types differently.
On the other hand resource working sets seem to be a catch-all for any type of project, so it makes sense that most plugins don't make a distinction here.
For example if I were to create a plugin that provides an option to analyze Java projects, I would add that operation to the context menu of Java working sets but certainly not to C/C++ working sets. But some people might use resource working sets because they have both Java and C projects in the same working set. So I have to add the Java-specific operation to the context menu of resource working sets too.
I know this might seem a bit odd, but i have this requirement and I want to know if this is possible.
I have a java swing application that I select a file (program) and this program is added to a list. When the list is completed, i execute the list of programs (this is like a start-up manager).
What I want to do is somehow, grab the file that I select and display it as image to my UI. For common files like pdf, doc, txt this is easy, I just have a generic image for each type. But lets say I want to execute regedit.exe or msconfig.exe, I want to be able to grab its icon (picture below) .
Does anyone know how this can be done?
Thanks
Take a look at FileSystemView.getSystemIcon(File).
It's a little limited (in that you will only get one size), but it's build in and doesn't require any additional libraries or JNA or JNI even...
File f = new File(...);
Icon icon = FileSystemView.getFileSystemView().getSystemIcon(f);
If you want the native icons you need JNI. Java has no default API for fetching the native icons in different sizes. Here are some startingpoints for windows & linux:
File icon overlay in java for windows
How do you get the icon, MIME type, and application associated with a file in the Linux Desktop?
If you do not need the exact native icons you can get the mimetype of the file and set a icon on your own:
Getting A File's Mime Type In Java