These are frequently asked questions and answers regarding Greenfoot installation and configuration.
If you have a question not answered here, please email email@example.com for assistance.
Greenfoot has three files in which in stores its configuration properties.
Properties set in greenfoot.properties override those in greenfoot.defs and bluej.defs.
You can edit all of these files using a standard text editor.
On Windows you can use the Notepad application to edit the files, but you will need to select "All files" as the file type in the "Open file" dialog. Furthermore, you may need to save the file to a different location (using "save as") and then copy it over the original file using the Windows Explorer if you are unable to save over the original file directly.
People occasionally ask if Greenfoot will run on a particular type of computer or device.
We have no immediate plans to port Greenfoot to other platforms, including smartphones / tablets and cloud platforms.
If you are a system administrator you may wish to perform a scripted or "silent" installation of Greenfoot. You can use the standard Windows MSI installation tools with the new MSI installer. For example to install Greenfoot with all the default settings but without the GUI, you can use:
msiexec /qn /L* logfile.txt /i Greenfoot-windows-241.msi
(The "/qn" turns off the GUI, the "/L* logfile.txt" logs to a file so you can check if the install succeeded afterwards - look at the end of the file - and the "/i Greenfoot-windows-241.msi" tells it which installer package to install). If you want to customise the settings, then here's the full set of properties that you might want to tweak for a 32-bit install:
msiexec /qn /L* logfile.txt /i Greenfoot-windows-241.msi ALLUSERS=0 INSTALLDIR="C:\Program Files\Greenfoot" INSTALLASSOCIATIONS=1 INSTALLMENUSHORTCUT=1 INSTALLDESKTOPSHORTCUT=1
You can leave off any that you don't want to alter from the default setting. The properties are independent of each other, and can be added or removed individually; specify "" (an empty pair of double-quotes) as the property value in order to turn a setting off.
The group policy settings on Windows can restrict which drives/folders are shown in the standard Windows "save" (or "save as") and "open" dialog windows. They do not, in any other way, restrict the ability of programs being run by users to modify files in directories for which they otherwise have appropriate permission. This means that, in general, relying on these group policy settings to restrict access to particular drives/folders/files is a bad idea, although it seems that some schools do use such group policy settings (hopefully) as an additional, rather than primary, security measure.
Greenfoot uses Java's built-in file chooser dialog, which does not respect the group policy settings. It would be difficult, from an implementation point of view, to make Greenfoot use the native Windows dialog, since Greenfoot is a Java program which is intended to be portable to multiple operating systems and in general it is not perfectly straightforward to access native APIs from a Java program. However, even if Greenfoot were to use the native Windows file chooser dialog (or otherwise somehow respect the group policy settings), this would not by itself prevent students using Greenfoot from accessing files outside their own area, since it would be straightforward for them to write and run a Java program (from within Greenfoot) that did exactly that. Indeed, they could quite simply invoke the Java file chooser from within their own program.
This problem is not unique to Greenfoot - any programming environment for a non-trivial programming language is likely to give its users the ability to access files and even execute programs programmatically in such a way that does not respect any group policy settings.
To prevent students from accessing files or folders altogether, the best option is simply to set the access permissions on those files/folders to prevent student access; this then applies to all programs that the student runs. It is possible for instance to prevent a group of users from seeing the contents of a folder by setting the permissions on that folder appropriately. Of course, the default permissions granted to a regular user on Windows are usually sufficient to prevent them from performing actions that would normally be considered a violation of system security. Note that (read-only) access to certain system files/folders may be required for a user to successfully log in and use the system.