Mercurial > pidgin
annotate TODO @ 11440:5938f6b386fa
[gaim-migrate @ 13677]
declarations after code
committer: Tailor Script <tailor@pidgin.im>
author | Daniel Atallah <daniel.atallah@gmail.com> |
---|---|
date | Sun, 04 Sep 2005 18:22:45 +0000 |
parents | 66fe476474ec |
children | 99548d90257e |
rev | line source |
---|---|
10881 | 1 * conversation api {{{ |
2 * need to handle: {{{ | |
3 * unnamed chats | |
4 * chats with the same name as a buddy | |
5 * jabber Messages (one off messages vrs a conversation with a backlog) | |
6 * multiple conversations with a single buddy (jabber, with thread tag) | |
7 * bugs | |
8 }}} | |
9 * notes: {{{ | |
10 * (12:58:39) Robot101: user list always|auto|never | |
11 * topic only where supported by the protocol | |
12 * how do we log this? {{{ | |
13 * rlaager's proposal: {{{ | |
14 * the goal of logging is to be able to find something again. | |
10891
8175206faa3d
[gaim-migrate @ 12599]
Luke Schierer <lschiere@pidgin.im>
parents:
10890
diff
changeset
|
15 * you expect to see the logs for a person IFF they are in that conversation |
10881 | 16 * you don't really need to see the log of a chat before or after said person joined it |
17 *if you did, you'd be looking at some other person(s)'s log | |
18 * so: | |
19 * each conversation has 1 or more logs associated with it. | |
20 * when someone joins, a new log is opened to log everything that happens in the | |
21 conversation, but to that person's logs. | |
22 * when someone parts, that one persons' log is closed | |
23 * this causes some duplication, the way to avoid this would be to close everyone's | |
24 log on a join/part and use a new file. we could then use links of some sort (hard | |
25 or soft) to "put" that one file in each user's directory. but this would | |
26 needlessly split the logs of someone who had been there all along. I think this | |
27 duplication is acceptable. | |
28 * this would not solve the problem of chats with the same name as a buddy. | |
29 }}} | |
30 }}} | |
31 }}} | |
32 }}} | |
33 * buddy list {{{ | |
34 * we have not committed any gobjectification, so this is not a blocker for 2.0.0 until we do. | |
35 * if we do, it is only a blocker to the extent that gaim needs to run. That is, we do not | |
36 *necessarily* have to gobjectifiy everything as long as we preserve functionality. | |
37 * That being said, my understanding of the signals mess says that it is probly more work to | |
38 try to do this in stages than to start it or not start it. | |
39 * This would require some sort of signal aggregation, as gobject signals are unique to the instance. | |
40 * one way to do this would be to emit the signals from a non-descript buddy object. this would | |
41 most closely mimic the current functionality | |
42 * a second way would be to actually try to aggregate them in some way. I really don't know how | |
43 possible this is, but it would allow us to do things like set a pounce on everyone in a group | |
44 or define sounds on a per-group basis. | |
45 * we could look at replacing the UI ops with signals/call backs | |
46 * bugs | |
11415
66fe476474ec
[gaim-migrate @ 13652]
Luke Schierer <lschiere@pidgin.im>
parents:
10891
diff
changeset
|
47 * buddy shows as group on add until gaim restart |
66fe476474ec
[gaim-migrate @ 13652]
Luke Schierer <lschiere@pidgin.im>
parents:
10891
diff
changeset
|
48 * buddy shows as online when offline |
66fe476474ec
[gaim-migrate @ 13652]
Luke Schierer <lschiere@pidgin.im>
parents:
10891
diff
changeset
|
49 * buddy shows as offline when online |
66fe476474ec
[gaim-migrate @ 13652]
Luke Schierer <lschiere@pidgin.im>
parents:
10891
diff
changeset
|
50 * wrong buddy given priority |
66fe476474ec
[gaim-migrate @ 13652]
Luke Schierer <lschiere@pidgin.im>
parents:
10891
diff
changeset
|
51 * so on and so forth |
10881 | 52 }}} |
53 * build targets {{{ | |
54 * this is not a blocker | |
55 * we need build targets for libgaim, we need to test them, and make sure they work. | |
56 * we ought to use our own build targets to build the executable itself. | |
57 * due to the limitations of cvs, this cannot accompany moving files to other directories at this time. | |
58 }}} | |
59 * status {{{ | |
60 * Sean's segment of the UI needs to be finished. We need to have support for the (new) default case | |
61 of one global status at all times. we currently do not, unless that happens to be "online/present" | |
62 * Tim's modifications to Sean's ui should be included to allow exceptions. refer to gaim-devel | |
63 archives for this. | |
64 }}} | |
65 * account editor {{{ | |
66 * this is not a blocker for 2.0.0 | |
67 * account editor is not intuitive, users do not find it. | |
68 * Luke: my temptation is to get rid of this entirely, in favor of deryni's account menu. {{{ | |
69 * at this point, tools->accounts is only used for add/delete account, modify account, and | |
70 enable account. | |
71 * most users do not have the 15+ accounts that some gaim developers do. a menu scales well for | |
72 anything from 2 to n, n "small" accounts. | |
73 * this would allow ready access to the buddy icon stuff, and account actions could go here | |
74 * status is handled as per the new api, status stuff need not go here beyond enabled. | |
75 * the account modify dialog is already too big. this would let us split it, for instance | |
76 buddy icon need not be in it this way. Similarly, alias need not be in it. | |
11415
66fe476474ec
[gaim-migrate @ 13652]
Luke Schierer <lschiere@pidgin.im>
parents:
10891
diff
changeset
|
77 * splitting the account modify dialog to tabs seems to work nicely. Still, I think |
66fe476474ec
[gaim-migrate @ 13652]
Luke Schierer <lschiere@pidgin.im>
parents:
10891
diff
changeset
|
78 that the menu would be nicer. |
10881 | 79 }}} |
80 }}} | |
81 * Privacy {{{ | |
82 * this is not a blocker for 2.0.0 | |
83 * Privacy sucks. it doesn't handle many of the protocols in a way that users understand. notably | |
84 msn, but also yahoo, jabber, and icq. | |
85 * We want to sync to the server as much as possible, entirely local-only privacy is not an option | |
86 except on protocols like irc that have no server-side. | |
87 * We want to be as consistent across protocols as possible. this will require renaming things on | |
88 some protocols. | |
89 * Bleeter suggests that we create a privacy.xml, remove privacy from blist.xml. He suggests | |
90 that each protocol define certain capabilities & defaults, with accounts.xml holding exceptions | |
91 to the defaults. | |
92 }}} | |
10885
12083e75627f
[gaim-migrate @ 12583]
Luke Schierer <lschiere@pidgin.im>
parents:
10881
diff
changeset
|
93 * Perl {{{ |
10886
0ece4cf68ea6
[gaim-migrate @ 12584]
Luke Schierer <lschiere@pidgin.im>
parents:
10885
diff
changeset
|
94 * Block for 2.0.0 or remove perl: |
11415
66fe476474ec
[gaim-migrate @ 13652]
Luke Schierer <lschiere@pidgin.im>
parents:
10891
diff
changeset
|
95 * Summer of Code seems to have largely solved this. |
66fe476474ec
[gaim-migrate @ 13652]
Luke Schierer <lschiere@pidgin.im>
parents:
10891
diff
changeset
|
96 * Extended testing and resolving the inevitable bugs remains. |
10886
0ece4cf68ea6
[gaim-migrate @ 12584]
Luke Schierer <lschiere@pidgin.im>
parents:
10885
diff
changeset
|
97 * Test each call to make sure it actually works |
0ece4cf68ea6
[gaim-migrate @ 12584]
Luke Schierer <lschiere@pidgin.im>
parents:
10885
diff
changeset
|
98 * Make it work with G_MODULE_BIND_LOCAL |
10885
12083e75627f
[gaim-migrate @ 12583]
Luke Schierer <lschiere@pidgin.im>
parents:
10881
diff
changeset
|
99 }}} |
10891
8175206faa3d
[gaim-migrate @ 12599]
Luke Schierer <lschiere@pidgin.im>
parents:
10890
diff
changeset
|
100 * Prefs {{{ |
8175206faa3d
[gaim-migrate @ 12599]
Luke Schierer <lschiere@pidgin.im>
parents:
10890
diff
changeset
|
101 * this blocks for 2.0.0 |
8175206faa3d
[gaim-migrate @ 12599]
Luke Schierer <lschiere@pidgin.im>
parents:
10890
diff
changeset
|
102 * Prefs cannot stay as-is. the dialog is far too wide and not at all usable. |
8175206faa3d
[gaim-migrate @ 12599]
Luke Schierer <lschiere@pidgin.im>
parents:
10890
diff
changeset
|
103 * The biggest problem is that each new plugin creates horizontal space. {{{ |
8175206faa3d
[gaim-migrate @ 12599]
Luke Schierer <lschiere@pidgin.im>
parents:
10890
diff
changeset
|
104 * I do not see it as a solution to remove the posability of plugin preferences. |
8175206faa3d
[gaim-migrate @ 12599]
Luke Schierer <lschiere@pidgin.im>
parents:
10890
diff
changeset
|
105 * In the past, we had a separate plugin management dialog. People never found it, |
8175206faa3d
[gaim-migrate @ 12599]
Luke Schierer <lschiere@pidgin.im>
parents:
10890
diff
changeset
|
106 and were often surprised to learn that gaim had plugins at all. I am unsure that |
8175206faa3d
[gaim-migrate @ 12599]
Luke Schierer <lschiere@pidgin.im>
parents:
10890
diff
changeset
|
107 people find the current plugin page of preferences any more frequently, but I |
8175206faa3d
[gaim-migrate @ 12599]
Luke Schierer <lschiere@pidgin.im>
parents:
10890
diff
changeset
|
108 *suspect* that it is the case. This leads to a conundrum, how do plugins |
8175206faa3d
[gaim-migrate @ 12599]
Luke Schierer <lschiere@pidgin.im>
parents:
10890
diff
changeset
|
109 display preferences? |
8175206faa3d
[gaim-migrate @ 12599]
Luke Schierer <lschiere@pidgin.im>
parents:
10890
diff
changeset
|
110 }}} |
8175206faa3d
[gaim-migrate @ 12599]
Luke Schierer <lschiere@pidgin.im>
parents:
10890
diff
changeset
|
111 * Currently the window is, at my font size, 1129x505 (or should that be 505x1129?). It *should* fit |
8175206faa3d
[gaim-migrate @ 12599]
Luke Schierer <lschiere@pidgin.im>
parents:
10890
diff
changeset
|
112 in 800x600 at worst, I'm unsure that 480x640 is a reasonable goal. still, this leaves us with |
8175206faa3d
[gaim-migrate @ 12599]
Luke Schierer <lschiere@pidgin.im>
parents:
10890
diff
changeset
|
113 something either considerably wider or considerably taller than we are currently using (on any |
8175206faa3d
[gaim-migrate @ 12599]
Luke Schierer <lschiere@pidgin.im>
parents:
10890
diff
changeset
|
114 given pane, the tabs force the width, not the contents). Further, taking "Message Text" as an |
8175206faa3d
[gaim-migrate @ 12599]
Luke Schierer <lschiere@pidgin.im>
parents:
10890
diff
changeset
|
115 example, it has 3 preferences and a text area, each in its own category (the text area sharing a |
8175206faa3d
[gaim-migrate @ 12599]
Luke Schierer <lschiere@pidgin.im>
parents:
10890
diff
changeset
|
116 category with 1 preference). obvious waste of space here. All 3 could clearly be uncategorised |
8175206faa3d
[gaim-migrate @ 12599]
Luke Schierer <lschiere@pidgin.im>
parents:
10890
diff
changeset
|
117 without loss of meaning, categories only make sense for groups of preferences. It may even be |
8175206faa3d
[gaim-migrate @ 12599]
Luke Schierer <lschiere@pidgin.im>
parents:
10890
diff
changeset
|
118 possible to combine this with "Conversations" entirely. |
8175206faa3d
[gaim-migrate @ 12599]
Luke Schierer <lschiere@pidgin.im>
parents:
10890
diff
changeset
|
119 }}} |
8175206faa3d
[gaim-migrate @ 12599]
Luke Schierer <lschiere@pidgin.im>
parents:
10890
diff
changeset
|
120 |