* There's no need to force the streamer plugin to use a
BMediaIO. This class is supplied to accomodate more smart uses,
but in certain cases it makes just things more complex. If a
plugin doesn't need to have an internal caching method, then it
will be simpler to implement a block-consuming BDataIO and let
the internal BMediaIOWrapper to deal with caching.
just noticed this crash...
when fConfigView gets deleted by selecting a translator it
deletes its child fInfoText but we were leaving the pointer
alone.
Afterwords if you changed the panel text color in Appearance
a message gets sent that checks to see if the fInfoView
pointer is NULL, and since it isn't, procedes to dereference
the pointer and *boom* the app crashes.
Fix this by setting the fInfoText pointer to NULL when fConfig
view gets deleted. That way when you change the panel text
color it doesn't attempt to dereference the stale pointer
and everything works as it should.
As you scroll through the list of translators keep the window width
constant by setting a minimum width. A little too narrow at 8pt,
and the window is too wide at 24pt, but at 12pt it is just right.
(at least for 1024x768).
The window width and height were not chosen arbitrarily, 598px
is just about 600px and almost exactly fits the width of our
widest translator (PNG translator). The height is 369px which comes
from the golden ratio of 1.62:1. The width of the translators are
set to exactly match this at 12pt font size. This way you don't get
any unexpected window resizing. At other font sizes the window does
resize, but, the contents still fit (mostly) nicely.
See screenshot for details:
http://insightfactory.tumblr.com/image/141980518317
* When a watched directory contains a mount point, we need to resolve
the actual parent directory of the mount point in the file system to
serve the monitor.
* Added a directory argument for notify_{stat/attribute}_changed().
* This allows to watch only a directory, and get the notifications for
all of its files, not just add/remove entry notifications.
As part of the refactoring that was done for app_server layer support,
the private shape_data struct was updated to derive from BReferenceable.
However, BShape's destructor was never updated to reflect this, and
consequently attempts to use a debug build of libbe would consistently
throw the user into the debugger due to BReferenceable's sanity check
against non-zero deletes that weren't on the stack.
It should be noted though that there are probably a few things that could
be factored out and/or simplified with that class in general, since e.g.
when copying its data from another shape_data instance, it uses C++ array
allocations, while when being manipulated by BShape directly, the latter
uses alloc/realloc/free.
John Scipione