TODO


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52


================================
Details info page label wrapping
================================

The labels on the details page should wrap and ellipsize accordingly, but GTK+
doesn't have the tools for this currently.  Since the needed layout
improvements (height-for-width) are already in the works, I gave up fiddling
around with custom solutions.

======================
Better Devhelp support
======================

A caveat of the current situation is that we can't derive the exact Devhelp
book name from anything found in the introspection data.  To work around this,
we tell Devhelp to do a search for the element class name.  This isn't perfect
since it makes Devhelp scroll to the structure definition.

It seems that GStreamer bug #396774 tries to resolve the whole situation.  In
the end that might also work for non-gtkdoc/Devhelp integrated documentation
(e.g. LADSPA elements).

==========================
Command-line query support
==========================

GStreamer bug #115360 suggests that there is a need for richer commandline and
scripting friendliness of introspection.  Adding this functionality to
gst-inspector is much more easy than hacking it into gst-inspect.

================
Automatic reload
================

For startup speed and memory saving reasons, the program maintains an on-disk
cache of all introspection data.  The current downside of this is that the user
has to update the cache manually via View -> Reload data.  GStreamer doesn't
provide us with a _fast_ solution of finding out whether we need to ditch the
cache at startup.

Until this gets implemented somehow, the following might be an acceptable
method: After the load from cache on startup is complete, start a child process
that performs an update and writes out a fresh cache.  If the new data actually
differs anywhere, signal that fact to the parent process.  The GUI would then
display a non-popup message (like the gedit message area) indicating to the user
that the data needs an update.  The update in response to that could then just
read the new cache, which is really fast again.

The key point of this solution is that the update is still triggered by the
user.  Sneaking the new data silently into the GUI while it is live and kicking
must be avoided -- it looks strange and is technically very hard to get right.