Carl Hetherington a6fdd6c915 Maybe fix typename / no-typename problems better. ... git-svn-id: svn://localhost/ardour2/branches/3.0@12282 d708f5d6-7413-0410-9779-e7cbd77b26cf		2012-05-15 00:06:33 +00:00
..
boost-debug
macosx
pbd	Maybe fix typename / no-typename problems better.	2012-05-15 00:06:33 +00:00
test	drop boost::signals2 and replace with carl's solution which continues to rely on boost::function and boost::bind but alters two important semantics of signals2: (1) when a Connection object is disconnected, the slot ("functor") associated with the connection is destroyed immediately, unlike signals2 where this is deferred to a subsequent connect/emit call on the signal (2) if one functor called by the signal disconnects another Connection, the functor represented by the Connection will NOT be called during the current signal emission (signals2 copies the slot list at the start of emission and calls everything in the slot list). this change fixes some very nasty crashes apparently caused by boost::signals2 assuming that the memory referenced by a functor remains valid after a disconnect (google will show other developers who had issues with this).	2012-05-14 17:18:48 +00:00
.cvsignore
base_ui.cc	drop boost::signals2 and replace with carl's solution which continues to rely on boost::function and boost::bind but alters two important semantics of signals2: (1) when a Connection object is disconnected, the slot ("functor") associated with the connection is destroyed immediately, unlike signals2 where this is deferred to a subsequent connect/emit call on the signal (2) if one functor called by the signal disconnects another Connection, the functor represented by the Connection will NOT be called during the current signal emission (signals2 copies the slot list at the start of emission and calls everything in the slot list). this change fixes some very nasty crashes apparently caused by boost::signals2 assuming that the memory referenced by a functor remains valid after a disconnect (google will show other developers who had issues with this).	2012-05-14 17:18:48 +00:00
basename.cc
boost_debug.cc
cartesian.cc
ChangeLog
clear_dir.cc
cocoa_open_uri.mm
command.cc
controllable_descriptor.cc
controllable.cc
convert.cc	more fixes/tweaks from the land of the lion	2012-05-02 20:45:17 +00:00
COPYING
cpus.cc
crossthread.cc	another quick OS X Lion gcc suggestion	2012-05-02 20:33:39 +00:00
debug_rt_alloc.c
debug.cc	eventloop and abstractui debugging, lots more commenting on abstractui/eventloop implementation; minor tweaks elsewhere	2012-04-24 16:45:38 +00:00
dmalloc.cc
enums.cc
enumwriter.cc	Add basic test of playlist layering.	2011-12-15 14:33:20 +00:00
epa.cc
error.cc
event_loop.cc	eventloop and abstractui debugging, lots more commenting on abstractui/eventloop implementation; minor tweaks elsewhere	2012-04-24 16:45:38 +00:00
file_manager.cc
file_utils.cc
filesystem_paths.cc
filesystem.cc	Save templates as directories with plugin state, if	2011-12-11 20:38:42 +00:00
fpu.cc	explain MXCSR shenanigans in libs/pbd/fpu.cc	2011-12-26 22:32:21 +00:00
gettext.h
i18n.h
id.cc
libpbd.pc.in
libpbd.spec.in
locale_guard.cc
malign.cc
mountpoint.cc	complete the do-not-free-data-from-getmntinfo() fix	2012-01-11 18:14:18 +00:00
openuri.cc
pathscanner.cc
pool.cc
property_list.cc
pthread_utils.cc
receiver.cc
run-tests.sh	Fix libpbd tests and add test for url_decode().	2012-04-01 14:29:26 +00:00
search_path.cc
semutils.cc
shortpath.cc
signals.cc	Make ScopedConnectionList's mutex non-static so that one	2012-05-15 00:06:06 +00:00
sndfile_manager.cc
stacktrace.cc
stateful_diff_command.cc
stateful.cc	Clear up confusion with overloads of _frozen and frozen()	2011-12-17 16:37:18 +00:00
strreplace.cc
strsplit.cc
textreceiver.cc
transmitter.cc
undo.cc
uuid_boost.cc
uuid.cc
whitespace.cc
wscript	Merge old a new signals code into one set of classes.	2012-05-15 00:05:57 +00:00
xml++.cc	some deep changes to xml++ in which we retain a C-level xmlDocPtr as a member of an XMLTree objects. this allows us to do repeated XPATH searches (as in the midnam parser of libmidi++) without constantly rewriting an entire tree into memory to recreate a new xmlDocPtr with which we can search. Since XMLTree objects don't typically stay around for very long, just when serializing to/from disk, this is not anticipated to have much (if any) impact on memory consumption	2012-03-20 18:01:07 +00:00