[gst-devel] some cleanups

[Jan Tore Korneliussen]

--- Andy Wingo <wingo at pobox.com> wrote:
> For reference, I already did a cleanup when I got
> inspect-gui working in
> its older incarnation. Can you post to the list with
> your proposed
> categories? I don't think the current
> classifications are bad at all, on
> the whole.
> 
> Otherwise, your list looks good to me.
> 
> regards,
> 
> wingo.
> 
Hello,
I tried out gst last year, and have been following
this list for a while. I noticed that there was a
quite lengthy discussion about how to 'classify'
elements. Although I realize this might be a
controversial topic, I could not resist commenting on
it...
My main point is: why does there need to be a
hierearchy and a C(K?)lass property in the first
place? It seems to me it is quite redundant since
most, if not all, of the information exists in the
properties of an element already. I guess that trying
to squeeze  'all' the information in the other
properties into one ordered string is a very hard
task. Either the hierarchy would be very deep/wide and
sparsely populated, or it would be ambigous. Also it
would be a matter of taste what is root in such a
hierarcy, and what are leaves.

Example of how the klass fields could be extracted
from what's already in the properties:
- Source/sink/filter could be determined by counting
the number of inputs and outputs
- Audio/video could be determined by looking at the
mime types on the input and outputs.
- Decoder/encoder elements could probably be
identified by looking at the mime subtypes.
 
Couldn't just the user interface for browsing elements
be designed with a list widget, with elements in the
rows, and element properties in the coloumns? Coupled
with flexible sorting & filtering stuff it could
indeed be quite nice..
Or perhaps the user could organize the elements in
folders himself, like bookmarks in a browser. 
Yet another possibility would be to build a tree
widget automatically on-the-fly from element
properties according to the users preferences, thus
letting the user decide what is most fundamental
property of an element, how deep the tree needs too be
e.t.c.(Not to mention deciding if an element
processing video and audio is REALLY a video element
or actually an audio element with video functionality
he would just design a custom filter for that, doing
it _his_ way), thus gst developers would not have to
fight over these issues and could get on whith more
important tasks, and everybody would be happy :-)

That was much rambling from a newbie, feel free to
ignore... Hopefully I will have time to experiment
with gst again soon, it is great to see that it is
gaining momentum!

Jan Tore Korneliussen

=====
Jan Tore Korneliussen    |
jtkornel at yahoo.no        |   +47 952 13 672 
Fayes gate 20            |
0455 Oslo                |

__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/