Actually I think the auto-completion could be improved by the Greenfoot team, because it only shows methods, but doesn't show instance and class variables or constants (I don't know if the option is hidden somewhere).

I agree, although Greenfoot is also a learner's environment, and perhaps all that stuff would confuse someone who's new to it all. Then again, certain things could also be turned off by default, so that those who do know how to use it can if they so wish. Greenfoot can be used to create quite powerful things, after all (all the 3D stuff that's on here, for instance).

I agree that maybe some things should be allowed to be turned on and off. However, as far as fields are concerned, I feel that since they are an integral part of a class, they should be included in auto-completion. The 'wormsEaten' field is introduced within greenfoot in its tutorials. You cannot teach programming without introducing fields. I think that object reference fields should also be introduced somewhere. This is done in greenfoot in an indirect manner when discussing how to pass values between classes. There is another thing that has been something I feel should be changed. This has to do with the templates of the Actor and World classes. It would probably be better (for beginners) to show all the empty methods greenfoot uses that can be overridden in the classes (started and stopped in the World class template and addedToWorld in the Actor class template; as well as act in both class templates). By doing so, you are showing that there are more possible places to edit code into; thus, avoiding the so often seen case of a beginner coding continuous actions in the World subclass constructor (like checking for keys or checking mouse functions or using a random chance to do something like for occasionally spawning something). While on this, I think that it would be good to have an 'activated' and 'deactivated' method in the World class that can be overridden, called by greenfoot at the appropriate times. A 'removedFromWorld' Actor class method might be useful also.

Very good points you bring up. I've had to add an 'addedToWorld' method in the past for some programs, and a 'removedFromWorld' that would definitely help as well. I totally agree with you :) What would the methods 'activated' and 'deactivated' do, though?

They would be methods that execute when a world is set active when using the 'Greenfoot.setWorld' method. The 'deactivated' method executes on the world being left and the 'activated' method executes on the world going to.

Oh, I see. I was confused with the 'started' method and such. That could be quite useful too! The downside right now is that there's not really a way to add those in without changing something in Greenfoot, at least not that I know. addedToWorld is much easier to add because you can simply subclass World. Although, now that I think about it, one could subclass Greenfoot and overwrite the setWorld method. Unless it's put as a final one, though (it's been a while since I looked at Greenfoot's source).

I wrote a 'TextImage' class that subclasses the 'GreenfootImage' class (see my TextImage Support Class demo). Creating a subclass of 'Greenfoot' would be a similar idea.

Actually, there is no Greenfoot object - all the Greenfoot class' methods are static. Because it's not declared "final", you can indeed subclass the Greenfoot class. But, as you've deduced correctly, there's no point in doing so.

You could implement methods such as 'activated' and 'deactivated' (as danpost mentioned) though, if needed. This won't apply to most users however, but it could come be of use.

You don't understand, I think. The Greenfoot IDE/framework doesn't call any methods on a Greenfoot instance. Because the methods in the Greenfoot class are static, there's no need to create a Greenfoot instance. If you subclass the Greenfoot class, the IDE/framework doesn't know or care. If "activated" and "deactivate" were static methods, like all the other Greenfoot-class methods, then you could't override them in a subclass anyway. If instead they were instance methods, the IDE/framework would have to instantiate the Greenfoot class to call them, but that wouldn't result in your subclass' overriding methods getting called. The World subclasses are different, because you explicitly instantiate a world and the IDE/framework then has a reference to that world instance, so it can call methods on that instance. There is no Greenfoot class instance. If methods in the Greenfoot class are static, there is no way to override them. If they are not static, they could be overridden in a subclass, but there would be no simple way for them to be called. Anyway: I assume that "activated" and "deactivated" are for notification that a world became the active world or is no longer the active world, so it would make sense for them to be methods in the World class rather than any other class.

Sorry, I forgot that sub classing wouldn't make the framework call the methods of the subclass. I understand they're static, it's just the implication I overlooked. I guess overlooking stuff is one of the reasons bugs appear in my code.