This reduces the amount of memory copied when creating/deleting a
variable on an object. We now use a table of pointers instead of table
of variable_t.

This also simplifies callback handling a bit as the variable_t cannot
move anymore while we wait. Earlier another thread could add or remove
another variable on the same object, thus changing the variable table.

With this change, we could also store non-serialized data (i.e.
non-movable with memcpy/memmove) directly inside variable_t.

Only default to rc.lua if module loading wasn't forced. This still isn't perfect. (And there seems to be an issue in module_need(), wasn't -I intf1,intf2 supposed to first try loading intf1 and fallback to intf2 if intf1 couldn't load? For example -I rc,qt4 should load rc and not qt4, which is the case in 0.8.6 but doesn't seem to be the case in 1.0.0 ... looks like this is due to bb0d7527 removing i_shortcut_bonus)

We use the same pattern as the variable callback lock: one mutex,
one condition variable and N boolean flags instead of N mutexes.
This is a bit slower but it shouldn't leak OS handles anymore.

First one is about starting to inherit from the parent. Shouldn't hurt much.
Second one is about looking to inherit from the right variable. hurt more.

Make the dialogs that requires no user action and that will be normally handled via regular error code path optionals.

Still, there is no context with those dialogs, and we don't know to what output they belongs, ideally we should have a proper API that makes the client a proxy for those user actions.

If the lua rc submodule gets autoselected because it has the higher priority, we need to correctly use it.

Only enable when X window support is wanted.
Feel free to adjust.

Close #2763

This may hopefully spare us some conflicts with VLCKit/libvlc users.

This is meant to fix the *printf format strings.
This is compatible with mingw 4.2.1 and 4.3.0
I haven't find a better place where to put this code...
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

We don't have the renderer for it, so far.

Close #3213

Close #2866

And close #3182 the unparented widget that could be bothering you.
The issue about the unparented widget was totalled found by freeruner (on IRC and trac)

The address field is removed, as it is quite useless. The default
unspecified value works just fine. In fact, it works better than
0.0.0.0 as it allows both IPv6 and IPv4 automatically.

A new path field is added for the local path, defaults to '/'
consistent with HTTP URI semantics ("http://www.example.com" really
means "http://www.example.com/").

The initial value of the variable must be correct when the variables
lock is released after the variable was created. Hence we could not
release the lock between Insert() and InheritValue(). If we did, there
would be a race where another thread could see the variable with the
generic default value (0, "", 0., ...) instead of the inherited value.

So instead, we inherit the value in a temporary variable on the stack,
before we take the variables lock. Then we can create the variable with
the correct value without taking the lock for the duration of
InheritValue().

This adds overhead when an existing variable is re-created (i.e.
reference count is increased but no new variable is created). But it
dramatically reduces contention on the variables lock. More importantly,
it allows calling InheritValue() without the variables lock. So when we
fix InheritValue(), which is currently not thread-safe, we won't have
any problem with nested locking.