I am creating my own custom IDE for my programming language, and I came upon a problem. In any IDE, you always want to be able to import images, other projects, and other files. Therefore, I would definitely love to have that in my IDE. I am using JavaFX for my GUI. I have already created a FileChooser, and a user can successfully choose a File they want to import into my IDE.
Here's My Question
When a user selects a File, should I use the File.copy() method to copy the File over to the IDE, or should I copy all the bytes from the File onto a resources file in my IDE? Copying the File directly would lead me to have a Resources folder attached to the Project, but I do not know if that would be the most optimal way of importing Files into my IDE. Is there a preferred way of importing and saving Files in Java? What would be the best way for me to do it in this case?
Thanks in advance!
Ideally user should have have both options and IDEs tend to support both ways.
Practically, don't get stack on this. Implement either one, and move one with other tasks to have a working prototype earlier.
It is more important to check if your language has design flaws before you devote too much time decorating gui.
Related
So I have made a simple game using Java. I have my Jar file and inside it I am keeping my pictures. It's like a lot of pictures going on there. Like 140+ pictures at around 9 MB (mostly icons) (Not worried about efficiency, game already runs pretty smoothly). Now I wrapped my jar file into an .exe and then used Inno Setup to make a setup file. The thing is I am creating a folder in Program Files that only has a the application.exe file and the uninstallation file. This looks a bit vague to me and unprofessional. Though I've seen great games having all of their icons outside of the executable of course, just wondering would it be a good practice to keep the images inside or out ?
Suggestions are welcomed :D
I prefer to keep images and other resources inside the JAR file. You don't want the user to change any of them, same as for the program classes. So I don't see why you should have a different storage for images compared to classes.
The most robust and simple (and that should be the meaning of "professional") setup is to have the whole program with all its prerequisites in just one file - either it's there and works, or it's missing, and you'll see that immediately. No need to check for existence and accessibility of dozens of subdirectories and files.
And as you're asking the question, you surely managed to read the images from the classpath, thus allowing to store them together with the class files, e.g. in a JAR.
Regarding wrapping in an EXE, that shouldn't make a difference: if the ClassLoader finds the classes, it'll surely find the images the same way. And even Ahead-Of-Time-Compilers support getResourceAsStream() (we've done that with Excelsior Jet).
I've been working on a game engine for a while, I finally finished it and now I want to implement the ability to export a jar file after designing a game in it, but the only possible way I found was using JarOutputStream which can copy the class files from your jar directory to another jar, but that isn't what I want, I want to export the INSTANCE of my engine, not the generic code that was already in my class files. Is that possible?
What I'm thinking of doing is when I'm ready to export, I would export all the original class files and program an interpreter that would hard-code the project info into a loader-class.. So; the following questions arise:
Is this a good way of doing things?
Is there a better way to do it, If so; what is it? (I'm pretty sure there is!)
How do commercial game engines export their project as an executable?
Thanks!
EDIT: To make it clear on how my engine stores data, it currently saves data in an external file containing all project data, such as assets, game objects, etc..
But I cannot use that as the main method of loading games, because that would make a game very easily moddable (Anyone can change the data file; changing the game, therefore using the engine without my approval)..
As for what I mean by the current instance; I just meant that the engine uses an object-oriented approach to create the game, there are no "hard-coded" values, so if I just copy the classes from my engine's jar, that would not run, it would just crash because it does not have a scene to run...
When we want to load a static file e.g. a picture, a sound file, a file containing information about a game map,... we can store them as resources in jar file and use getClass.getResource("images/splash.png") (also getResourceAsStream) to load and use them. But when we want to read and write into a file like settings file, I don't think using resources is a good way, because i think resources are designed to store read/only files that are not supposed to change, like splash screen image or a game's background music; These are my reasons to think this way:
That is why return value of getResourceAsStream is an instance of InputStream and we don't have a similar function which gives us an OutputStream, because we're not supposed to alter resource files.
Writing into resources changes program .jar file and i guess it's not a good thing at all; Because if we do so: we can't use check-sums to verify file, if we are a limited user and system administrator doesn't give us write permission we can't make changes into main .jar file, user-specific preferences are hard or impossible to implement,...
So, my questions are:
Which parts of my thoughts and assumptions are right or wrong?
If they're right what is the best(I mean short and portable between OSs and Computers) way to store files like that? (Application setting/preferences, A game save file, ...)
(#Some user who may wants to mark this as duplicate: I don't think my question is a duplicate, i searched in the site, I admit it has some common parts with some questions but it's not duplicate!)
Your three observations in #2 above are valid reasons not to store settings in a resource file, regardless of the APIs provided.
There are a variety of ways to save settings in Java, including:
The Java system property "user.home" provides the user's home directory, to which the user should have write access. You can create an application-specific subdirectory underneath it.
Java provides a Preferences API. This may store settings in a directory or (on Windows) in the registry.
OSGI provides a preferences API.
If you're using the Eclipse RCP, you can write to the configuration directory using a ConfigurationScope. See the Eclipse FAQ "What is a preference scope").
How would you go about opening an .xml file that is within a .jar and edit it?
I know that you can do...
InputStream myStream = this.getClass().getResourceAsStream("xmlData.xml");
But how would you open the xmlData.xml, edit the file, and save it in the .jar? I would find this useful to know and don't want to edit a file outside of the .jar... and the application needs to stay running the entire time!
Thank you!
Jar files are just .zip files with different file suffix, and naming convention for contents. So use classes from under java.util.zip to read and/or write contents.
Modifying contents is not guaranteed (or even likely) to effect running system, as class loader may cache contents as it sees fit.
So it might be good to know more about what you are actually trying to achieve with this. Modifying contents of a jar on-the-fly sounds like complicated and error-prone approach...
If you app. has a GUI and you have access to a web site/server, JWS might be the answer. The JNLP API that is available to JWS apps. provides services such as the PersistenceService. Here is a small demo. of the PersistenceService.
The idea would be to check for the XML in the JWS persistence store. If it is not there, write it there, otherwise use the cached version. If it changes, write a new version to the store.
The demo. writes to the store at shut-down, and reads at start-up. But there is no reason it could not be called by a menu item, timer etc.
I have created a fairly substantial Java GUI application with many form windows where the settings are locked up in .form files. I am wondering is there any way to convert or refactor these .form files into real Java source code that I can modify?
The GUI was created using Netbeans 6.5.
My understanding is that the ".form" files are only used by the Netbeans GUI builder to keep track of where the GUI components are. When you add components in the design view, Netbeans automatically updates the actual source (.java) files. You can actually modify these .java files directly to, say, change the label on a button, but if you do it within Netbeans, it will use the .form files to automatically regenerate the source files, destroying your manual changes.
In my experience, once you make the decision to modify the .java files manually, the .form files become out of sync and you will no longer be able to use the Netbeans GUI builder properly.
kazanaki is right, the java files that are generated can be modified but the resulting .java files are notoriously messy, large and hard to interpret. Also, you cannot change some things (as noted in the comments in the generated .java file) without rendering matisse useless because it expects the file to have things in a certain way. That being said, if you are careful not to step on Matisse's toes you can code away and it will not touch your code which is nice.
Outlaw is right too, if you change anything that is already in Matisse's perview it will be overwritten. Any changes that you make outside of matisse must be outside of any element that is covered by the xml that matisse uses to generate the code.
I have tried this kind of thing before with limited success and eventually just rewrote the interface to avoid these maddening headaches.
I can edit the source, I discovered the solution. THe problem was that I was using the "AbsoluteLayout" in the GUI builder. Netbeans was creating some hidden AbsoluteLayout class that was inside the .form files. IF I deleted the .form files the project would no longer build. The solution was to change the form to be of "FreeForm" layout and then I could delete the .form files and remove the GUI builder comments.
Thank you for the help guys, I give you both +1.