I've been thinking about jQuery Compat Mode and plugins quite a bit.

Here's what I'm thinking: I think we should have a configuration switch (in configuration.inc.php) that's called "jQuery in compatibility mode" that's by default set to ON. All plugins that use $ would have to declare a property (in the installation file, just like they declare title/description/version) that they use jQuery in non-compatible mode.

The plugin manager will check the configuration setting of the installation and DECLINE TO INSTALL a plugin plugin that is using $, if the installation is set to be working in compatibility mode. Plugin Manager will explain how to change the configuration setting in QCubed, and what effect this will have (can't use any other JS frameworks).

What this will accomplish is:
1) People who want to use other frameworks will be WARNED before they install and integrate plugins that will screw them over.
2) People who don't care about frameworks other than jQuery will be easily able to install any plugins - just by changing a constant in configuration.inc.php

On your question (c): we should totally mod the plugins to not use document.ready() any more.

Thanks alex.
If we run jQuery in non-compatible mode, would we have to render the internal js commands as $() as well, or can we keep $j() ?
I'm not (yet) familiar enough with jQuery to know if we can have both $ and $j() ...anyone?

I'd like it if the core could stay as $j() at all times.

I'm pretty sure we can make jQuery support both $() and $j() - jQuery users must have faced this in the past. If they didn't, two jQuery plugins would not work well together (i.e. one that uses $() and another that uses $j()).

just verified that if we would do:

var $j = jQuery.noConflict();
var $ = $j;

in javascript, we have both variables available and as a result, plugins work out of the box (verified QJqDoc and QAutoComplete plugins)

out of the box = without ANY code change! I love this!!
Though we should probably remove the document.ready() from the plugins, this is not a requirement for the plugin to work.

greetings,
Kristof

I like this approach. :)
And just so I'm clear, is the .ready() change due to .ready() not being handled nicely on ajax updates? (And we get around this in core by using QApplication::Execute instead.)?

if all patches are apllied, we already integrate .ready().
If the plugin also used .ready(), we have something like

$(document).ready(function() {
... javascript code from core qcubed

$(document).ready(function() {
.... javascript code from the plugin
});
});

Althoug this works, I think it may be better for the control to just output javascript rather then the included .ready() as well.

kmeirlaen, if you look in the experimental 2.0 I redid the way javascript was outputted for doc ready. The form handled the rendering of doc ready and every control that had a doc ready action assigned to it was printed out.

I wanted to throw a flag on the form if javascript was actually included, so that way we can support things without javascript, which I didn't get to.

thanks basilieus,

Now that I know most things work, I'm startin to integrate your work into the branch, so keep your eyes open , there is so much more to come :)