mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2025-04-26 06:54:49 +00:00
fix some typos
Original commit message from CVS: fix some typos
This commit is contained in:
parent
12a0211728
commit
afe15de1f9
1 changed files with 12 additions and 11 deletions
|
@ -3,26 +3,26 @@
|
||||||
<para>
|
<para>
|
||||||
Previously, in the chapter <xref linkend="chapter-building-args"/>, we have
|
Previously, in the chapter <xref linkend="chapter-building-args"/>, we have
|
||||||
introduced the concept of GObject properties of controlling an element's
|
introduced the concept of GObject properties of controlling an element's
|
||||||
behaviour. This is a very powerful, but has two big disadvantage: firstly,
|
behaviour. This is very powerful, but it has two big disadvantages:
|
||||||
it is too generic, and secondly, it isn't dynamic.
|
first of all, it is too generic, and second, it isn't dynamic.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
The first disadvantage has to do with customizability of the end-user
|
The first disadvantage is related to the customizability of the end-user
|
||||||
interface that will be built to control the element. Some properties are
|
interface that will be built to control the element. Some properties are
|
||||||
more important than others. Some integer properties are better shown in a
|
more important than others. Some integer properties are better shown in a
|
||||||
spin-button widget, whereas others would be better represented by a slider
|
spin-button widget, whereas others would be better represented by a slider
|
||||||
widget. Such things are not possible because the UI has no actual meaning
|
widget. Such things are not possible because the UI has no actual meaning
|
||||||
in the application. A UI widget that stands for a bitrate property is the
|
in the application. A UI widget that represents a bitrate property is the
|
||||||
same as an UI widget that stands for the size of a video, as long as both
|
same as a UI widget that represents the size of a video, as long as both
|
||||||
are of the same <classname>GParamSpec</classname> type. Another problem,
|
are of the same <classname>GParamSpec</classname> type. Another problem,
|
||||||
related to the one about parameter important, is that things like parameter
|
is that things like parameter grouping, function grouping, or parameter
|
||||||
grouping, function grouping or anything to make parameters coherent, is not
|
coupling are not
|
||||||
really possible.
|
really possible.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
The second argument against parameters are that they are not dynamic. In
|
The second problem with parameters are that they are not dynamic. In
|
||||||
many cases, the allowed values for a property are not fixed, but depend
|
many cases, the allowed values for a property are not fixed, but depend
|
||||||
on things that can only be detected at run-time. The names of inputs for
|
on things that can only be detected at runtime. The names of inputs for
|
||||||
a TV card in a video4linux source element, for example, can only be
|
a TV card in a video4linux source element, for example, can only be
|
||||||
retrieved from the kernel driver when we've opened the device; this only
|
retrieved from the kernel driver when we've opened the device; this only
|
||||||
happens when the element goes into the READY state. This means that we
|
happens when the element goes into the READY state. This means that we
|
||||||
|
@ -44,8 +44,9 @@
|
||||||
<para>
|
<para>
|
||||||
One important note: interfaces do <emphasis>not</emphasis> replace
|
One important note: interfaces do <emphasis>not</emphasis> replace
|
||||||
properties. Rather, interfaces should be built <emphasis>next to</emphasis>
|
properties. Rather, interfaces should be built <emphasis>next to</emphasis>
|
||||||
properties. There are two important reasons for this. Firstly, properties
|
properties. There are two important reasons for this. First of all,
|
||||||
can be saved in XML files. Secondly, properties can be specified on the
|
properties
|
||||||
|
can be saved in XML files. Second, properties can be specified on the
|
||||||
commandline (<filename>gst-launch</filename>).
|
commandline (<filename>gst-launch</filename>).
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue