Overwriting path options before MUI does anything.

[eerne]

Webkit browsers currently try to require window-webkit-shadow.js in mui/core.js, when the script is included. http://github.com/cdotyone/mochaui/blob/develop/src/mui/core.js#L748

With no standard directory layout, this results in an error: Failed to load resource: the server responded with a status of 404 (Not Found) /custom/dir/mui-util/window-webkit-shadow.js

It would be nice to move the require of window-webkit-shadow.js from core.js somewhere else that is executed later on initialize. It should be possible to

• include mochaui.js
• set MUI.path.* to custom directories
• set MUI.Desktop.options to custom options
• start the initialize chain (then window-webkit-shadow.js can be required with the correct MUI.path.utils settings)

I feel it should go into windows.js, but there is currently no place that get's initialized only once, since the class initialize fires everytime a new window is called.

[mui-org]

Yep the plugin stuff is a little weak. I have known we would have to move it. I just have not got around to it yet. That is why I created the /src/mui-util folder. Eventually the code in mochaui.js may get pulled into mochaui-util.js or mochaui-lazy.js . I haven't really pinned that down in my head yet.

[eerne]

I think there is nothing else in mui/core.js that loads when the file is included, not sure about the other scripts. Some other scripts have initialize method (for example MUI.Desktop.initialize or MUI.Dock.initialize) so one can execute the initalize part.

If MUI would be written as classical MooTools class, default options could be overwritten when instantiating new MUI(). But I think that would break things, i.e. the ability to alter options anytime later (if i remember correctly).

[mui-org]

I generally agree. I am not a big fan of how MUI was done. This requires more thought. I want to make sure lazy loaded plugins are completely pluggable without the need to modify in MochaUI code base. I will digest this a little more.

[mui-org]

I think we may be able to pull window-webkit-shadow.js. I will have to check this on my Mac. I am not sure it gives us enough advantage now that we have CSS3 support. the only thing I can think it helps us with, is the drawGauge for the clock. I don't know if I care enough about the drawGauge function enough to leave this in there.

[mui-org]

Of course this still does not answer how to handle path changes externally from the mochaui.js. This I will still work on.

[mui-org]

rebuilt how MUI uses paths. should be able to initialize MUI options using a call to MUI.initialize( options );

[eerne]

I updated to latest develop and the error obviously disappeared (because of window-webkit-shadow.js). So far I only use columns and panels in my app and it just worked (even without MUI.initialize()) and "wrong" paths.

btw. I like MUI.initialize(). it looks consistent with MUI.Desktop.initialize() and MUI.Dock.initialize()

About window-webkit-shadow.js I think it only is an advantage if you force to use canvas or use Safari < 4. I suppose most are using Safari 4 and 5 though.

Thanks