Greenfoot has three files in which in stores its configuration properties.

• The "greenfoot.defs" and "bluej.defs" files are installed with Greenfoot, and apply to all users who use that installation of BlueJ. On Windows and Linux they are stored in the "lib" subdirectory of wherever you installed Greenfoot. (On Mac OS X, it is found in the application bundle.) Usually, you will not want to edit greenfoot.defs/bluej.defs unless you are a system administrator configuring an installation for many users.
• The "greenfoot.properties" file is a per-user configuration file stored in a different place on different systems:
  • On Windows Vista, 7, 8: C:\Users\your-user-name\greenfoot\greenfoot.properties
  • On Windows XP: C:\Documents and Settings\your-user-name\greenfoot\greenfoot.properties
  • On Mac OS X: /User/your-user-name/Library/Preferences/org.greenfoot/greenfoot.properties
    For OS X 10.7 (Lion) and newer, please see this page for how to access your Library folder (which is otherwise hidden).
  • On Linux and similar systems: your-home-directory/.greenfoot/greenfoot.properties
    Note that ".greenfoot" is normally an invisible directory.

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.

• In general, if a recent Java platform will run on the device, then Greenfoot will also run. Note that Android-based phones and tables including Chromebooks do not run the Java platform (despite that you can use the Java language to write applications for them) and Greenfoot cannot normally be installed on these devices.
• The Windows version of Greenfoot will run on 64-bit installations of Windows 7 or later, on machines with an "x86" (Intel-compatible) architecture. If you want to use Greenfoot on a 32-bit installation, then version 3.5.4 is the last version that would run on a 32-bit system.
• The Macintosh version of Greenfoot will run on any modern Mac. The regular Mac version requires a 64-bit Intel (compatible) processor. The "legacy" package of Greenfoot 2.4.2 should run on any Intel (compatible) processor, but requires that Java 6 be installed separately (you may be prompted to install Java when you try to run Greenfoot). The security changes in macOS Catalina (and later) may make it hard to run older Greenfoot versions; version 3.6.0 should be compatible with the changes in Catalina.
• The Ubuntu/Debian version will run on Ubuntu, Debian and Raspbian, and most other Linux distributions using Debian's "dpkg" package management system. It requires that a suitable version of Java be available - for the current Greenfoot that is Java 11. It does not require any specific processor.
• The "Pure Java" version of Greenfoot can be installed on nearly any system that has a suitable version of Java already installed, including the systems listed above. However, it provides no integration with the host operating system, and is usually less convenient to install.

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 (Note, as of Greenfoot 3.5.0, this is no longer true and the Greenfoot file chooser dialogs should respect group policy settings). 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.

Using group policy alone to restrict access to drives/folders is insufficient. 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.

On recent versions of MacOS, certain keys may seem to occasionally stop working temporarily or permanently (until Greenfoot is restarted). This is due to the "press-and-hold for accented characters" functionality in MacOS interfering with regular keyboard input. (This might no longer be an issue with Greenfoot 3.5.0 onwards).

The solution is to disable this functionality, which can only be done via the Terminal application. Open it and enter the following command:

defaults write -g ApplePressAndHoldEnabled -bool false

To re-enable the press-and-hold functionality, use this command:

defaults write -g ApplePressAndHoldEnabled -bool true

Unfortunately, there is no way to disable this function just for Greenfoot — turning it on or off affects all applications.

We have found that on MacOS Mojave, Greenfoot can crash when a dialog is displayed. This may happen if the "update API" dialog is shown when an old scenario is opened but may also occur for other dialogs, particularly if you switch to another application while the dialog is shown.

This is actually a Java crash, described in bug entries here and here.

A workaround is to add Greenfoot to the accessibility list in:

System Preferences > Security & Privacy > Privacy (tab) > Accessibility (in list on left; then add Greenfoot to the list of applications on the right).

Doing this appears to prevent the crash.