view TODO @ 12827:0f40c44348f4

[gaim-migrate @ 15175] SF Patch #1402533 from Sadrul " This patch pops up the dropdown when mouse-wheel is scrolled over the statusbox. This will perhaps be `better' (as in `less confusing' or something) for many users." The original patch didn't stop the scroll wheel action from applying after the dropdown popped up (at least on my system with GtkComboBox::appears-as-list = 1), so I fixed that. committer: Tailor Script <[e-mail]>

* conversation api {{{
	* need to handle: {{{
		* unnamed chats
		* chats with the same name as a buddy
			* this should be working now, but it needs to be kept in mind when (re-)designing
		* jabber Messages (one off messages vrs a conversation with a backlog)
		* multiple conversations with a single buddy (jabber, with thread tag)
		* bugs
	}}}
	* notes: {{{
		* (12:58:39) Robot101: user list always|auto|never
		* topic only where supported by the protocol
		* how do we log this? {{{
			* rlaager's (NEW) proposal: {{{
				* each conversation has 1 or more logs associated with it.
				* when someone joins, a new log is opened
					* file based loggers should try to use hard-links in a smart way
					  to avoid duplicating data on disk as much as possible...
					* this needs to be designed in such a way that a database logger
					  can handle it w/o duplication...
					* TO SOLVE THESE CONCERNS, a link and/or copy function callback
					  will likely need to be added
			}}}
		}}}
	}}}
}}}
* 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
		  most closely mimic the current functionality
		* a second way would be to actually try to aggregate them in some way. I really don't know how
		  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.
	* Easier access to saved states is needed.
}}}
* Privacy {{{
	* this is not a blocker for 2.0.0
	* Privacy sucks. it doesn't handle many of the protocols in a way that users understand. notably
	  msn, but also yahoo, jabber, and icq.
	* We want to sync to the server as much as possible, entirely local-only privacy is not an option
	  except on protocols like irc that have no server-side.
	* We want to be as consistent across protocols as possible.  this will require renaming things on
	  some protocols.
	* Bleeter suggests that we create a privacy.xml, remove privacy from blist.xml.  He suggests
	  that each protocol define certain capabilities & defaults, with accounts.xml holding exceptions
	  to the defaults.
}}}
* Perl {{{
	* Block for 2.0.0 or remove perl:
		* Extended testing and resolving the inevitable bugs remains.
		* Test each call to make sure it actually works
		* Make it work with G_MODULE_BIND_LOCAL
}}}
* Prefs {{{
	* on upgrade from 1.x, the timestamp preference often gets lost.
}}}