Comment 1 by jteh on 2009-05-16 06:27
Having access to the default appModule isn't actually that useful anymore. It is not a separate level like it used to be. Instead, all appModules subclass it, so you would need to bind your scripts to each appModule as it is used. It seems we need an actual global level for scripts.

Comment 2 by aleksey_s (in reply to comment 1) on 2009-05-16 07:08
Replying to jteh:

Having access to the default appModule isn't actually that useful anymore.

Don't sure. explanation follows.

It is not a separate level like it used to be. Instead, all appModules subclass it, so you would need to bind your scripts to each appModule as it is used.

What a painfull solution :)

It seems we need an actual global level for scripts.

Making yet another level willl not simplify things. Why we can't modify the default appModule class? then modifications/bindings will affect each appModule, as it is subclass of default. So accessing default appModule is actually needed.

Comment 3 by jteh (in reply to comment 2) on 2009-05-17 00:05
Replying to aleksey_s:

Making yet another level willl not simplify things.

Why not? Also, note that the default appModule used to be another level, so we're basically just reintroducing something we removed, bt using it for a different purpose.

Why we can't modify the default appModule class ? then modifications/bindings will affect each appModule, as it is subclass of default.

This actually isn't true. When you bind a key on a subclass, the keyMap dict is copied, so you only get the bindings from the default appModule class at the time the copy occurred. We might be able to work around this by modifying the code to search all bases for scripts. I still believe reintroducing another level is probably the more correct solution; this one is pretty hacky.

So accessing default appModule is actually needed.

Previously, appModuleHandler.default accessed the instance of the default appModule. You're talking about the class, which is a rather different thing; there is no longer an instance of the default appModule. Btw, you can access the class via appModuleHandler._default.AppModule, but this is pretty evil. :)

Comment 4 by aleksey_s (in reply to comment 3) on 2009-05-17 07:11
Replying to jteh:

Why not? Also, note that the default appModule used to be another level, so we're basically just reintroducing something we removed, bt using it for a different purpose.

Ok then, why we removed it earlier? :-)

Why we can't modify the default appModule class ? then modifications/bindings will affect each appModule, as it is subclass of default.

This actually isn't true. When you bind a key on a subclass, the keyMap dict is copied, so you only get the bindings from the default appModule class at the time the copy occurred. We might be able to work around this by modifying the code to search all bases for scripts. I still believe reintroducing another level is probably the more correct solution; this one is pretty hacky.

Agree. I've just suggested approach, which will not affect all existing appModules. If we'll reintroduce global level, appModules will be not subclasses of default.

So accessing default appModule is actually needed.

there is no longer an instance of the default appModule.

I've just nodiced this when revieved appModuleHandler.

Btw, you can access the class via appModuleHandler._default.AppModule, but this is pretty evil. :)

Sure.

So target of this ticket is feature to dynamically bind/unbind scripts on global level as well as another levels.

Comment 5 by mdcurran on 2011-04-06 01:54
Default appModule no longer exists.
However, globalCommands.GlobalCommands is probably what you want.
Changes:
State: closed

Comment 6 by jteh on 2011-04-07 04:10
You should use global plugins to bind global scripts.
Changes:
Milestone changed from None to 2011.1