bjgf issueshttps://gitlab.bluej.org/bluej/bjgf/-/issues2020-04-21T11:25:54Zhttps://gitlab.bluej.org/bluej/bjgf/-/issues/2167[GREENFOOT-840] Stride: getWorld()-autocomplet sets cursor inside the braces2020-04-21T11:25:54ZNeil Brown[GREENFOOT-840] Stride: getWorld()-autocomplet sets cursor inside the bracesWhen I write
{code:java}
this.getWo{code}
and press CTRL-space to autocomplete, the phrase is correctly autocompleted to
{noformat}
this.getWorld(){noformat}
but the cursor is sitting inside the braces. As getWorld gets no paramet...When I write
{code:java}
this.getWo{code}
and press CTRL-space to autocomplete, the phrase is correctly autocompleted to
{noformat}
this.getWorld(){noformat}
but the cursor is sitting inside the braces. As getWorld gets no parameters this is bad. The cursor should sit behind the last brace.
---
**Issue metadata**
- Issue type: Bug
- Priority: Mediumhttps://gitlab.bluej.org/bluej/bjgf/-/issues/2166[GREENFOOT-839] Inspector layout truncates display badly2019-12-03T14:07:19ZNeil Brown[GREENFOOT-839] Inspector layout truncates display badlyThe inspectors (for objects and classes, especially) truncates the display in odd ways, either completely truncating the value or truncating the label, even when there is enough horizontal space available to do better.
---
**Issue meta...The inspectors (for objects and classes, especially) truncates the display in odd ways, either completely truncating the value or truncating the label, even when there is enough horizontal space available to do better.
---
**Issue metadata**
- Issue type: Bug
- Priority: Medium
- Fix versions: 3.6.1Neil BrownNeil Brownhttps://gitlab.bluej.org/bluej/bjgf/-/issues/2165[GREENFOOT-838] On Mac: world is not created on initial start, until window i...2019-11-29T15:38:30ZNeil Brown[GREENFOOT-838] On Mac: world is not created on initial start, until window is clicked onThis bug was caused by the debug VM stealing focus from the main Greenfoot window. On BlueJ we have code to steal the focus back again once the debug VM is loaded, and this code should be made to work in Greenfoot as well.
---
**Issue...This bug was caused by the debug VM stealing focus from the main Greenfoot window. On BlueJ we have code to steal the focus back again once the debug VM is loaded, and this code should be made to work in Greenfoot as well.
---
**Issue metadata**
- Issue type: Bug
- Priority: Medium
- Fix versions: 3.6.1Neil BrownNeil Brownhttps://gitlab.bluej.org/bluej/bjgf/-/issues/2164[GREENFOOT-837] Add image sharing to GifImage helper class2021-04-29T10:41:52ZNeil Brown[GREENFOOT-837] Add image sharing to GifImage helper classThe GifImage class in Greenfoot does two things: (1) it loads a GIF and splits it into an array of images and (2) it allows the GIF to be run and tells you which image is the valid one at any point in time. The first part is expensive, ...The GifImage class in Greenfoot does two things: (1) it loads a GIF and splits it into an array of images and (2) it allows the GIF to be run and tells you which image is the valid one at any point in time. The first part is expensive, especially on the gallery where Javascript image creation can be slow. It would be good for GIF files that are used by multiple actors to be able to share that part, but then animate separately. I think the two obvious solutions are either (A) a hidden internal static cache of loaded GIF images or (B) a copy constructor for GifImage that lets it share the loaded images but run at its own rate. A is easier for beginners, but also can cause correctness problems (e.g. if the file is modified between loads) so I think B may be best.
---
**Issue metadata**
- Issue type: Bug
- Priority: Medium
- Fix versions: 3.7.0Neil BrownNeil Brownhttps://gitlab.bluej.org/bluej/bjgf/-/issues/2163[GREENFOOT-836] Greenfoot world display can flicker with large worlds and fas...2019-11-21T09:23:04ZNeil Brown[GREENFOOT-836] Greenfoot world display can flicker with large worlds and fast speedThere is a race hazard bug in Greenfoot where we can send a world which is still being rendered on another thread. This is more likely to happen with larger worlds (or worlds with many actors) where the drawing is slower, and when the s...There is a race hazard bug in Greenfoot where we can send a world which is still being rendered on another thread. This is more likely to happen with larger worlds (or worlds with many actors) where the drawing is slower, and when the speed is set to high so that drawing happens more often.
---
**Issue metadata**
- Issue type: Bug
- Priority: Medium
- Fix versions: 3.6.1Neil BrownNeil Brownhttps://gitlab.bluej.org/bluej/bjgf/-/issues/2160[GREENFOOT-833] Add "new X()" above image preview when holding shift and prev...2021-04-29T10:41:29ZNeil Brown[GREENFOOT-833] Add "new X()" above image preview when holding shift and previewing shift-clickAs discussed in our meeting, when the user goes to shift-click to add actors into the world, the conceptual link to calling the object's constructor is not clear, especially compared to the case where they right-click the class and selec...As discussed in our meeting, when the user goes to shift-click to add actors into the world, the conceptual link to calling the object's constructor is not clear, especially compared to the case where they right-click the class and select to call the constructor from the context menu. We can help with this by adding text like "new Crab()" above the crab when the user holds shift and moves the mouse over the world, to emphasise that clicking is calling the default constructor of the actor in question.
---
**Issue metadata**
- Issue type: Bug
- Priority: Medium
- Fix versions: 3.7.0Neil BrownNeil Brownhttps://gitlab.bluej.org/bluej/bjgf/-/issues/2162[GREENFOOT-835] Greenfoot.delay() forcing repaint2019-11-21T09:25:25ZNeil Brown[GREENFOOT-835] Greenfoot.delay() forcing repaintIn Greenfoot 3.6.0, calling Greenfoot.delay() forces a repaint, even if the absolute delay time would be very small (e.g. a few microseconds) because the speed is set to high. We shouldn't need to repaint if there was a recent repaint a...In Greenfoot 3.6.0, calling Greenfoot.delay() forces a repaint, even if the absolute delay time would be very small (e.g. a few microseconds) because the speed is set to high. We shouldn't need to repaint if there was a recent repaint and the absolute time of the delay is small enough that we'll be back soon to do a further paint.
This is a regression from earlier Greenfoot versions which didn't force a repaint on every delay() call.
---
**Issue metadata**
- Issue type: Bug
- Priority: Medium
- Fix versions: 3.6.1Neil BrownNeil Brownhttps://gitlab.bluej.org/bluej/bjgf/-/issues/2161[GREENFOOT-834] Painting happens more often than needed when scenario running...2019-11-21T09:24:55ZNeil Brown[GREENFOOT-834] Painting happens more often than needed when scenario running full speedOur code was intended to prevent painting overly often in cases where the act cycle is running very fast -- if you are running the simulation at 20,000 FPS, there's no need to paint every frame, we only need to paint at 60-120 FPS at mos...Our code was intended to prevent painting overly often in cases where the act cycle is running very fast -- if you are running the simulation at 20,000 FPS, there's no need to paint every frame, we only need to paint at 60-120 FPS at most. The logic for this paint-skipping appears to have been damaged during refactoring, and Greenfoot 3.6.0 currently paints most frames even when running much faster than the screen can display.
---
**Issue metadata**
- Issue type: Bug
- Priority: Medium
- Fix versions: 3.6.1Neil BrownNeil Brownhttps://gitlab.bluej.org/bluej/bjgf/-/issues/2159[GREENFOOT-832] Incompatibility when working with more than one display2021-05-12T09:12:04ZNeil Brown[GREENFOOT-832] Incompatibility when working with more than one displayAt home I am working with 2 displays on macOS; in school it's Windows 10 with one display for each working station.
If I close a GF-project while the editor-window or the scenario-window is not on the primary display, then I get probl...At home I am working with 2 displays on macOS; in school it's Windows 10 with one display for each working station.
If I close a GF-project while the editor-window or the scenario-window is not on the primary display, then I get problems in the classroom: Either the scenario-window is "outside" the screen or the scenario-window is visible, but opening a class moves the editor-window "outside" the screen.
I encountered this problem already years ago, and probably it's not GF-specific. But it would be nice to have a solution.
---
**Issue metadata**
- Issue type: Bug
- Priority: Low
- Fix versions: 3.7.0Neil BrownNeil Brownhttps://gitlab.bluej.org/bluej/bjgf/-/issues/2158[GREENFOOT-831] Scenario does not compile/not react without reason2019-11-17T18:16:31ZNeil Brown[GREENFOOT-831] Scenario does not compile/not react without reasonIn classroom I often encounter the problem that the scenario greys out and no interaction with the editor is possible (windows still can be switched, but also no reaction on clicking the reset or act-button). You have to quit Greenfoot c...In classroom I often encounter the problem that the scenario greys out and no interaction with the editor is possible (windows still can be switched, but also no reaction on clicking the reset or act-button). You have to quit Greenfoot completely/restart, then the scenario is working again. As far as I can see there is no particular reason for this behavior (like errors in the code).
The problem is concerning Windows 10 with 3.5.3, Stride.
Some weeks ago I gave a lesson for other teachers, also Windows 10 with (I hope I remember well) 3.5.4, Stride. Same problems.
At home I am working with Mac (no problems), so excuse me being not very specific in my description of the errors (in lessons I am running around helping students, so I am distracting from analyzing the bugs).
As I have encountered this problems in two different locations I am sure that this is nothing specific to your school-network or anything.
I am marking this bug as "high", because such bugs are very, very frustrating. The teachers I have been interacting came to the conclusion "Greenfoot is a buggy amateur-tool", my pupils get angry when they don't know if the world is not compiling because of their own fault or because the software doesn't work correctly.
---
**Issue metadata**
- Issue type: Bug
- Priority: Mediumhttps://gitlab.bluej.org/bluej/bjgf/-/issues/2157[GREENFOOT-830] Convert to new Color API dialog does wrong action2019-06-07T16:17:12ZNeil Brown[GREENFOOT-830] Convert to new Color API dialog does wrong actionWhen you open an old scenario, you are offered the option to convert it to the new greenfoot.Color API rather than the old java.awt.Color API. However, in Greenfoot 3.5.x, when the user clicks yes, nothing is done, and when they click n...When you open an old scenario, you are offered the option to convert it to the new greenfoot.Color API rather than the old java.awt.Color API. However, in Greenfoot 3.5.x, when the user clicks yes, nothing is done, and when they click no, the conversion is done.
---
**Issue metadata**
- Issue type: Bug
- Priority: Medium
- Fix versions: 3.6.0Neil BrownNeil Brownhttps://gitlab.bluej.org/bluej/bjgf/-/issues/2156[GREENFOOT-829] Cut/Copy/Paste on editor context menu do nothing2019-05-28T15:33:01ZNeil Brown[GREENFOOT-829] Cut/Copy/Paste on editor context menu do nothingThe fix for http://bugs.bluej.org/browse/GREENFOOT-623 checked if the editor pane was focused before executing these actions, but it seems that triggering the context menu also counts as a defocusing event, so this has broken the context...The fix for http://bugs.bluej.org/browse/GREENFOOT-623 checked if the editor pane was focused before executing these actions, but it seems that triggering the context menu also counts as a defocusing event, so this has broken the context menu events.
Probably the best fix will be to force their execution (skipping focus check) when triggered via context menu.
---
**Issue metadata**
- Issue type: Bug
- Priority: Medium
- Fix versions: 3.6.0Neil BrownNeil Brownhttps://gitlab.bluej.org/bluej/bjgf/-/issues/2155[GREENFOOT-828] Allow inclusion of custom library in exported JAR2019-05-03T15:42:01ZNeil Brown[GREENFOOT-828] Allow inclusion of custom library in exported JARGreenfoot allows use of custom JARs, but unlike BlueJ, there's no option to include extra JARs into the exported standalone JAR (made via the Share menu). We should probably add checkboxes like in BlueJ. This may depend somewhat on how...Greenfoot allows use of custom JARs, but unlike BlueJ, there's no option to include extra JARs into the exported standalone JAR (made via the Share menu). We should probably add checkboxes like in BlueJ. This may depend somewhat on how we solve GREENFOOT-827 which has a similar issue with how to depend on/include OpenJFX for export under Java 11.
---
**Issue metadata**
- Issue type: Bug
- Priority: Mediumhttps://gitlab.bluej.org/bluej/bjgf/-/issues/2154[GREENFOOT-827] Fix issue about JavaFX requirement for export to JAR2019-06-18T13:50:36ZNeil Brown[GREENFOOT-827] Fix issue about JavaFX requirement for export to JARGreenfoot requires JavaFX, including for the case when it has been exported to a standalone JAR. In Oracle Java 8 this was fine because JavaFX was included in the JDK so running the JAR would work fine on Oracle's Java 8. However with ...Greenfoot requires JavaFX, including for the case when it has been exported to a standalone JAR. In Oracle Java 8 this was fine because JavaFX was included in the JDK so running the JAR would work fine on Oracle's Java 8. However with OpenJDK 11, JavaFX is supplied separately and installed separately, so the Greenfoot JAR won't be runnable without also supplying the path for OpenJFX 11. We need to either bundle OpenJFX into the JAR itself (with issues about OS-specific libraries or not) or have an accompanying script/batch file which somehow locates the JAR and adds it to the class path. A more advanced alternative is to export using the Java Packager so that it is an everything-included installer for the scenario.
---
**Issue metadata**
- Issue type: Bug
- Priority: Medium
- Fix versions: 3.6.0Neil BrownNeil Brownhttps://gitlab.bluej.org/bluej/bjgf/-/issues/2153[GREENFOOT-826] Greenfoot can freeze while loading on Windows2019-05-03T12:30:41ZNeil Brown[GREENFOOT-826] Greenfoot can freeze while loading on WindowsGreenfoot can freeze when attempting to bring a window to the front (which happens on load) due to a deadlock between the event thread and the external bring-to-front script.
---
**Issue metadata**
- Issue type: Bug
- Priority: Medium...Greenfoot can freeze when attempting to bring a window to the front (which happens on load) due to a deadlock between the event thread and the external bring-to-front script.
---
**Issue metadata**
- Issue type: Bug
- Priority: Medium
- Fix versions: 3.5.4Neil BrownNeil Brownhttps://gitlab.bluej.org/bluej/bjgf/-/issues/2152[GREENFOOT-825] Window invisible on startup of coordinates out of screen2019-05-03T12:25:55ZMichael Kölling[GREENFOOT-825] Window invisible on startup of coordinates out of screenIt seems that the main scenario window can be out of screen. It should automatically be moved into the visible screen area on scenario open.
This also affects windows that were minimised in MS Windows, since they are assigned a nomina...It seems that the main scenario window can be out of screen. It should automatically be moved into the visible screen area on scenario open.
This also affects windows that were minimised in MS Windows, since they are assigned a nominal window position of -32000 / -32000.
Reported in Greenroom (26 Mar 2019: [Greenfoot Scenario starts invisible|https://greenroom.greenfoot.org/forums/1/topics/630]).
---
**Issue metadata**
- Issue type: Task
- Priority: Medium
- Fix versions: 3.5.4Neil BrownNeil Brownhttps://gitlab.bluej.org/bluej/bjgf/-/issues/2151[GREENFOOT-824] Placing a new actor in the world counts as a click2019-01-17T12:50:06ZNeil Brown[GREENFOOT-824] Placing a new actor in the world counts as a clickSet the scenario running, then use the class diagram context menu to create a new actor, which will appear under the mouse cursor, ready to be placed. If you then click in the world to place the actor, it also registers as a click on th...Set the scenario running, then use the class diagram context menu to create a new actor, which will appear under the mouse cursor, ready to be placed. If you then click in the world to place the actor, it also registers as a click on the actor/world underneath, which it should not do.
---
**Issue metadata**
- Issue type: Bug
- Priority: Medium
- Fix versions: 3.5.3Neil BrownNeil Brownhttps://gitlab.bluej.org/bluej/bjgf/-/issues/2150[GREENFOOT-823] Scenario does not (always) open with double-click on project....2019-05-03T16:03:45ZMichael Kölling[GREENFOOT-823] Scenario does not (always) open with double-click on project.greenfootDouble-click on the project.greenfoot file should open a scenario.
This works if Greenfoot is not running, but if Greenfoot is already open, then the new scenario does not open correctly (process starts, but no window appears). (Obser...Double-click on the project.greenfoot file should open a scenario.
This works if Greenfoot is not running, but if Greenfoot is already open, then the new scenario does not open correctly (process starts, but no window appears). (Observed on MacOS.)
---
**Issue metadata**
- Issue type: Bug
- Priority: Medium
- Fix versions: 3.5.4https://gitlab.bluej.org/bluej/bjgf/-/issues/2149[GREENFOOT-822] We should not save or restore window positions with negative ...2019-02-14T15:26:18ZHamza Hamza[GREENFOOT-822] We should not save or restore window positions with negative coordinates When the project file contains negative window coordinates, opening the scenario will minimize the Greenfoot window and it will not be restored. This is reported by the user Irzan Fajari, the scenario file is attached with a screenshot o...When the project file contains negative window coordinates, opening the scenario will minimize the Greenfoot window and it will not be restored. This is reported by the user Irzan Fajari, the scenario file is attached with a screenshot of the minimized window. The work-around to this issue in this scenario is to open the project in a text editor and remove the offending lines:
xPosition=-32000
yPosition=-32000
A proper solution for this is to detect the negative window positions and tries to correct them.
---
**Issue metadata**
- Issue type: Bug
- Priority: Medium
- Fix versions: 3.6.0Hamza HamzaHamza Hamzahttps://gitlab.bluej.org/bluej/bjgf/-/issues/2148[GREENFOOT-821] Edit/Duplicate/Delete not initially available on image in set...2018-11-22T14:55:46ZNeil Brown[GREENFOOT-821] Edit/Duplicate/Delete not initially available on image in set image dialogGo to Set Image... on an actor. If there is a default selected image in the scenario, then the cog context menu at the bottom has Edit/Duplicate/Delete disabled. They are only enabled once you select a different image then select the o...Go to Set Image... on an actor. If there is a default selected image in the scenario, then the cog context menu at the bottom has Edit/Duplicate/Delete disabled. They are only enabled once you select a different image then select the original one again.
---
**Issue metadata**
- Issue type: Bug
- Priority: Medium
- Fix versions: 3.5.3Neil BrownNeil Brown