HTML help that is shown instead of the plain help text where appropriate
and supported by the interface. The command-line help output and the Qt
GUI plugin tooltips show the plain help text, while the Qt GUI plugin
preferences page displays the HTML help, if available, falling back to
displaying the plain help otherwise.
Allows to present the help text in a more structured and expressive way.
Also useful for out-of-tree plugins, in case they want to link to
plugin's home page, bug tracker, donation page, etc.
For the supported HTML subset, see
https://doc.qt.io/qt-6/richtext-html-subset.htmlFixes#27798
If MODULE_STRING is not defined just use a default name.
If MODULE_NAME is not set either it's a dynamic plugin and the MODULE_STRING
should be set, or it's an internal test and we don't care about the name.
We should not use names stating with underscore for our internal code.
This is almost the same name used in the makefile for more coherence.
HAVE_DYNAMIC_PLUGINS already exists in the core. We keep a different
name to separate the 2 usages. For now they mean exactly the same thing.
The previous commit made use of compound literals. MSVC was identified
as not yet having support for compound literals in C++ though, which is
considered a blocking problem to their use. This work around was
suggested by Alexandre Janniaux.
I.e. check the type of the values provided, rather than just blindly
casting, and thus allow mistakes to get caught with compilation errors.
I once lost some hours tracking down the cause of a crash that this type
strictness would have prevented.
Note, now that `change_string_list()` and `change_integer_list()` use type
strictness for the value and label arrays to help make sure they're the
right types, we can more safely make use of `ARRAY_SIZE()` to more cleanly
get the length.
`set_callback[s]()` is excluded from this for obvious reasons.
I've taken the opportunity to ditch remaining use of Hungarian notation
and to fix a param name that should be singular rather than plural
(psz_caps on `add_module[_list]()`.
Re-implemented using compound literals upon excellent suggestion by
Alexandre Janniaux.
with cats and subcats both being plain integers it's very easy to
make a mistake mixing them up, storing one in a variable for another,
or passing the wrong variable to the wrong function.
switching to enums adds type strictness to help catch such mistakes.
in switching to enums there is of course additional opportunity to
exploit sequential numbering to achieve certain optimisations that
can be gained from this, but that it not done here. here we're simply
interested in catching mistakes through type strictness.
note that we simply retain the same cat/subcat numbering as before
here.
i have a use for `CONFIG_CLASS` now in the qt prefs code, and elsewhere in
later work.
the other test macros may be useful to have publicly for preference
interface code so were moved also, and besides, having them all in one
place makes finding them and maintaining them easier. there's no harm in
exposing them to plugins.
The config "advanced" flag was unused and has been removed by
6a7a137f7b.
It has been removed from many add_*() macros, but not all. Remove it
from the remaining macros.
there are no in-tree modules using this subcat that actually have any
options; this moves the few that do reference it (filter/mixer modules)
to audio-filter (making no difference since no options) and removes the
unneeded subcat.
note that in the previous commit I restored an add_subcategory() call for
it to the core option set, missing since 2005, to fix organisation of
any options that may be associated with it, but since no in-tree modules
actually place any options under it, it means that there's an empty page
for it in the preferences which isn't ideal, so here we just ditch it.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
Within all the introduced static libraries, the module cannot be known
at compilation time. This moves the module name from a compilation
constant to a link time constant string symbol. That way, the same
compiled object within a static library can use a different and correct
module name depending on which plugin it is linked into.
The symbol is hidden so it does not leak between shared objects. For
non-plugins shared libraries (vlccore, vlc, vlc_pulse and
vlc_xcb_events) the module name must be defined manually, unless the
library does not use msg_* macros at all (vlc_vdpau).
Steve Lhomme