...I'm actually concerned that I went a bit overkill trying to prevent
backwards compatibility issues with this abstraction design, because
this is a large number of files that have to be modified just to add a
single graphics subsystem export. Someone's going to strangle me, and
when you know that someone might strangle you, that means that you did
something wrong. We'll have to look in to simplifying this in the
future without killing backward compatibility safety.
The module callback obs_module_set_locale will be called after loading
the module, and any time the locale is manually changed via core API.
When this function is called, the module is expected to load new text
lookup values for all the text it uses based upon the current locale.
The locale parameter was a mistake, because it puts extra needless
burden upon the module developer to have to handle this variable for
each and every single callback function. The parameter is being removed
in favor of a single centralized module callback function that
specifically updates locale information for a module only when needed.
Having the value stored here is somewhat pointless, so this is one step
in fixing the locale handling. Locale should be handled by the modules
themselves with their own loaded locale lookup information.
This API is used to set the current locale for libobs, which it will set
for all modules when a module is loaded or specifically when the locale
is manually changed.
These functions were mostly related to being able to set true fullscreen
mode -- however, this has no place for our purposes, and these functions
were just sitting empty and unused, so they should be removed.
Besides, fullscreen mode only applies to the windows operating system.
This variable is currently somewhat pointless, I was originally going to
use it to tell the graphics subsystem to completely rebuild the internal
vertex buffers, but it would be bad/inefficient to allow that
functionality.
Currently, if a user presses 'OK' or 'Apply' on the settings window, it
will save all data from all controls on a settings pane, regardless of
whether of not they were changed. The major issue with this is that
setting the data will overwrite all default values, making it impossible
for default values to be used if a user didn't actually change a value.
(Thanks to palana for pointing this fact out)
So instead, mark a control as 'changed' using QObject::property() and
QObject::sender(), and add a few helper functions to controls to ensure
that they are checked to see whether they were actually changed directly
by the user before saving the value to the config.
If the scene item has a bounding box set up for it, do not make it use
aspect ratio clamping by default.
Instead, make it so that shift will turn on aspect ratio, and make it
also apply to all types of bounding box modes.
The only time where aspect ratio clamping should apply by default is
when bounds are not in use (i.e. when a source is just created). Some
will disagree with me just because that's how photoshop does it, but
we're not photoshop, and I feel that the majority of users will have
more trouble with it disabled by default than enabled by default.
So to sum it up:
If bounds inactive, clamp aspect ratio by default, because scene items
start out with it inactive, and it directly affects the scale.
If bounds active, do not clamp aspect ratio by default, because clamping
to aspect ratio doesn't particularly have an effect for mode bounds
modes except for "stretch to bounds".
Instead of using bounds to force the source to be centered (and
unrotated), just center the source positionally on the screen. Will
also preserve rotation.
There's no reason to represent this value in terms of scale. Scale is a
useless value for users to use. What are they going to enter, 0.5?
2.0? 0.25?
Even if it can be subject to change by the source itself, and even if
it's still converted to scale internally, having it display the base
source size value is much more ideal for the user.
These are meant to reflect auto-detection configuration changes that
should not be written to the config, for example, frame rate changes
for a camera where the (user-/config-file-)configured frame rate isn't
available but a similar frame rate can be automatically chosen
Default values are now permanently stored in the obs_data_items and
can be accessed via the new get_default functions
Also default values are no longer serialized to JSON to ease transition
to new default values
Due to the recent change with matrices, the way space is represented by
matrices is a bit different. The matrix stack represents the view
matrix, rather than the model matrix, so the position is more
representative of the camera (view) itself, rather than that of the
objects (model).
jp9000
Palana
BtbN
Arkkis
Christoph Hohmann