These are frequently asked questions and answers about Greenfoot.
If you have a question not answered here, please see the support page for contact information.
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 (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.