comparison TODO @ 16071:5e436cd088e4

merge of '6c54a71cc08e47f3b1498c61ee62d17107165817' and 'eae479abc840db2b4808b2de16397086deefab3b'

16070:14a9d9f50b5d

		}}}
	}}}
}}}
* buddy list {{{
	* we have not committed any gobjectification, so this is not a blocker for 2.0.0 until we do.
		* if we do, it is only a blocker to the extent that gaim needs to run.  That is, we do not
		  *necessarily* have to gobjectifiy everything as long as we preserve functionality.
		* That being said, my understanding of the signals mess says that it is probly more work to
		  try to do this in stages than to start it or not start it.
	* This would require some sort of signal aggregation, as gobject signals are unique to the instance.
		* one way to do this would be to emit the signals from a non-descript buddy object.  this would

		  possible this is, but it would allow us to do things like set a pounce on everyone in a group
		  or define sounds on a per-group basis.
		* we could look at replacing the UI ops with signals/call backs
	* bugs
		* wrong buddy given priority
}}}
* build targets {{{
  * this is not a blocker
  * we need build targets for libgaim, we need to test them, and make sure they work.
  * we ought to use our own build targets to build the executable itself.
  * due to the limitations of cvs, this cannot accompany moving files to other directories at this time.
}}}
* status {{{
	* Error messages aren't particularly usable currently.  we need to be able to see the full text of
	  the error, and what account is in that error condition.
	* No way to see accounts not in the global state.

}}}
* Prefs {{{
	* on upgrade from 1.x, the timestamp preference often gets lost.
}}}
* system log {{{
	* The system log minimally should tell me what _I_ do in gaim.  It should (minimally) tell me about
	  my accounts and actions.  It should thus list
	  * gaim start and quit
	  * Account connection
	  * account disconnection, and reason if caused by error.
	  * account state changes, IFF we are logging that for buddies.
		* This might include the state message(s).
	  * This might be done using one or more files.

16071:5e436cd088e4

		}}}
	}}}
}}}
* buddy list {{{
	* we have not committed any gobjectification, so this is not a blocker for 2.0.0 until we do.
		* if we do, it is only a blocker to the extent that pidgin & finch need to run.  That is, we do not
		  *necessarily* have to gobjectifiy everything as long as we preserve functionality.
		* That being said, my understanding of the signals mess says that it is probly more work to
		  try to do this in stages than to start it or not start it.
	* This would require some sort of signal aggregation, as gobject signals are unique to the instance.
		* one way to do this would be to emit the signals from a non-descript buddy object.  this would

		  possible this is, but it would allow us to do things like set a pounce on everyone in a group
		  or define sounds on a per-group basis.
		* we could look at replacing the UI ops with signals/call backs
	* bugs
		* wrong buddy given priority
}}}
* status {{{
	* Error messages aren't particularly usable currently.  we need to be able to see the full text of
	  the error, and what account is in that error condition.
	* No way to see accounts not in the global state.

}}}
* Prefs {{{
	* on upgrade from 1.x, the timestamp preference often gets lost.
}}}
* system log {{{
	* The system log minimally should tell me what _I_ do in Pidgin.  It should (minimally) tell me about
	  my accounts and actions.  It should thus list
	  * Pidgin start and quit
	  * Account connection
	  * account disconnection, and reason if caused by error.
	  * account state changes, IFF we are logging that for buddies.
		* This might include the state message(s).
	  * This might be done using one or more files.