The regular scroll area can expand horizontally, but the problem with
this is that sometimes there are controls within it that expand way too
big.
For example, the properties window for window capture can have a list of
windows where the titles of the windows are really really long, and it
causes the properties to extend way too far to the right, making the
window look really unusual.
Another example are the volume controls in the main window that can
expand way to the right if the name of a source is really long, causing
the volume control to stretch way too far to the right, making the
volume controls difficult to use when that happens.
So this just makes it so it sets the maximum width of a scroll area's
internal widget to the actual width of the scroll area, preventing it
from going off the side of the scroll area.
This crash report dialog is mostly just for the windows crash handling
code. If a crash occurs, the user will be able to view the crash report
and post it on the forums or give it to a developer for debugging
purposes.
Suppress signals of the volume input when setting a value. This stops
the volume control from setting the source volume when it receives the
volume changed event from the source.
Suppress signals of the volume slider when setting a value. This stops
the volume control from setting the source volume when it receives the
volume changed event from the source.
Use a dedicated method for setting the dB label in the volume control
and make sure to call it regardless if the volume was changed through
the slider or from somewhere else.
This dialog gives options such as increasing audio past 100%, forcing
the audio of a source to mono, and setting the audio sync offset of a
source (which was an oft-requested feature)
Refactor the screen enumeration code a little to make sure xinerama is present
and active before using it. If the extension is present but not active it will
no longer fail.
Remove the update time check from the volume meter since it is no longer
nescessary. The update interval can now be set with the volmeter which has
the added benefit of not loosing data where previously updates had been
skipped.
This was an important change because we were originally using an
hard-coded 709/partial range color matrix for the output, which was
causing problems for people wanting to use different formats or color
spaces. This will now automatically generate the color matrix depending
on the format, color space, and range, or use an identity matrix if the
video format is RGB instead of YUV.
This replaces the old code for the audio meter that was using
calculations in two different places with the new audio meter api.
The source signal will now emit simple levels instead of dB values,
in order to avoid dB conversion and calculation in the source.
The GUI on the other hand now expects simple position values from
the volume meter api with no knowledge about dB calculus either.
That way all code that handles those conversions is in one place,
with the option to easily add new mappings that can be used
everywhere.
This replaces the code for volume control with a newer version that
uses the new fader implementation in order to control the fader/slider
position and source volume.
The volume label will now indicate the gain in dB instead of percent,
mainly because it looks cool and is easy to do.
Due to libobs saving the multiplier option for the source instead of
the slider/fader positon, existing volume levels will (mostly) stay
the same with only the slider beeing at a different position.
This is of course within the resolution of the slider (100 steps).
The remuxer thread was only started if there was an actual remux job,
which resulted in the remuxer thread not being able to call the worker's
destructor (because it wasn't running)
OBS Sparkle feeds have two extensions to vanilla Sparkle feeds:
- There can be two kinds of items per feed: (zipped) .app and .mpkg
via <ce:packageType>app|mpkg</ce:packageType> (default is mpkg)
- Feed items can be disabled via <ce:deployed>false</ce:deployed>; these
items will not be considered for updates unless
"[General] UpdateToUndeployed=1" is set the global config
Unlike other Sparkle implementations the FeedURL cannot be updated via user
preferences because we support multiple app packages with the same package
identifier but different FeedURL settings on the same machine
Typedef pointers are unsafe. If you do:
typedef struct bla *bla_t;
then you cannot use it as a constant, such as: const bla_t, because
that constant will be to the pointer itself rather than to the
underlying data. I admit this was a fundamental mistake that must
be corrected.
All typedefs that were pointer types will now have their pointers
removed from the type itself, and the pointers will be used when they
are actually used as variables/parameters/returns instead.
This does not break ABI though, which is pretty nice.
I feel like people keep mistaking how x264 preset functions. They often
associate it with their own CPU speed, and I feel the name does not help
with that issue. I think it may be for the best to just take it out.
At best, it will keep people away from using it unless they know what
they're doing, and at worst, people at least won't be able to associate
it with their CPU as easily anymore.
Change checkbox with text "Advanced Encoder Settings" to "Use Advanced
Encoder Settings". This way it will hint that the settings will be
disabled when unchecked.
jp9000
fryshorts
Jake Probst
Palana
dodgepong
Ben Torell