Mercurial > pidgin.yaz
changeset 12680:134e570b3688
[gaim-migrate @ 15023]
heise2k mentioned that the TODO was not up to date. now it is.
committer: Tailor Script <tailor@pidgin.im>
| author | Luke Schierer <lschiere@pidgin.im> |
|---|---|
| date | Fri, 30 Dec 2005 15:31:33 +0000 |
| parents | b18738b03b35 |
| children | 4ad0d587aac4 |
| files | TODO sounds/alert.wav sounds/login.wav sounds/logout.wav sounds/receive.wav sounds/send.wav |
| diffstat | 6 files changed, 5 insertions(+), 43 deletions(-) [+] |
line wrap: on
line diff
--- a/TODO Fri Dec 30 04:37:26 2005 +0000 +++ b/TODO Fri Dec 30 15:31:33 2005 +0000 @@ -38,11 +38,7 @@ or define sounds on a per-group basis. * we could look at replacing the UI ops with signals/call backs * bugs - * buddy shows as group on add until gaim restart - * buddy shows as online when offline - * buddy shows as offline when online * wrong buddy given priority - * so on and so forth }}} * build targets {{{ * this is not a blocker @@ -51,26 +47,10 @@ * due to the limitations of cvs, this cannot accompany moving files to other directories at this time. }}} * status {{{ - * Sean's segment of the UI needs to be finished. We need to have support for the (new) default case - of one global status at all times. we currently do not, unless that happens to be "online/present" - * Tim's modifications to Sean's ui should be included to allow exceptions. refer to gaim-devel - archives for this. -}}} -* account editor {{{ - * this is not a blocker for 2.0.0 - * account editor is not intuitive, users do not find it. - * Luke: my temptation is to get rid of this entirely, in favor of deryni's account menu. {{{ - * at this point, tools->accounts is only used for add/delete account, modify account, and - enable account. - * most users do not have the 15+ accounts that some gaim developers do. a menu scales well for - anything from 2 to n, n "small" accounts. - * this would allow ready access to the buddy icon stuff, and account actions could go here - * status is handled as per the new api, status stuff need not go here beyond enabled. - * the account modify dialog is already too big. this would let us split it, for instance - buddy icon need not be in it this way. Similarly, alias need not be in it. - * splitting the account modify dialog to tabs seems to work nicely. Still, I think - that the menu would be nicer. - }}} + * 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 @@ -86,29 +66,11 @@ }}} * Perl {{{ * Block for 2.0.0 or remove perl: - * Summer of Code seems to have largely solved this. * 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 {{{ - * this blocks for 2.0.0 - * Prefs cannot stay as-is. the dialog is far too wide and not at all usable. - * The biggest problem is that each new plugin creates horizontal space. {{{ - * I do not see it as a solution to remove the posability of plugin preferences. - * In the past, we had a separate plugin management dialog. People never found it, - and were often surprised to learn that gaim had plugins at all. I am unsure that - people find the current plugin page of preferences any more frequently, but I - *suspect* that it is the case. This leads to a conundrum, how do plugins - display preferences? - }}} - * Currently the window is, at my font size, 1129x505 (or should that be 505x1129?). It *should* fit - in 800x600 at worst, I'm unsure that 480x640 is a reasonable goal. still, this leaves us with - something either considerably wider or considerably taller than we are currently using (on any - given pane, the tabs force the width, not the contents). Further, taking "Message Text" as an - example, it has 3 preferences and a text area, each in its own category (the text area sharing a - category with 1 preference). obvious waste of space here. All 3 could clearly be uncategorised - without loss of meaning, categories only make sense for groups of preferences. It may even be - possible to combine this with "Conversations" entirely. + * on upgrade from 1.x, the timestamp preference often gets lost. }}}