|
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.
|
|
|
15 * you expect to see the logs for a person IFF they are in that conversation
|
|
|
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
|
|
|
47 }}}
|
|
|
48 * build targets {{{
|
|
|
49 * this is not a blocker
|
|
|
50 * we need build targets for libgaim, we need to test them, and make sure they work.
|
|
|
51 * we ought to use our own build targets to build the executable itself.
|
|
|
52 * due to the limitations of cvs, this cannot accompany moving files to other directories at this time.
|
|
|
53 }}}
|
|
|
54 * status {{{
|
|
|
55 * Sean's segment of the UI needs to be finished. We need to have support for the (new) default case
|
|
|
56 of one global status at all times. we currently do not, unless that happens to be "online/present"
|
|
|
57 * Tim's modifications to Sean's ui should be included to allow exceptions. refer to gaim-devel
|
|
|
58 archives for this.
|
|
|
59 }}}
|
|
|
60 * account editor {{{
|
|
|
61 * this is not a blocker for 2.0.0
|
|
|
62 * account editor is not intuitive, users do not find it.
|
|
|
63 * Luke: my temptation is to get rid of this entirely, in favor of deryni's account menu. {{{
|
|
|
64 * at this point, tools->accounts is only used for add/delete account, modify account, and
|
|
|
65 enable account.
|
|
|
66 * most users do not have the 15+ accounts that some gaim developers do. a menu scales well for
|
|
|
67 anything from 2 to n, n "small" accounts.
|
|
|
68 * this would allow ready access to the buddy icon stuff, and account actions could go here
|
|
|
69 * status is handled as per the new api, status stuff need not go here beyond enabled.
|
|
|
70 * the account modify dialog is already too big. this would let us split it, for instance
|
|
|
71 buddy icon need not be in it this way. Similarly, alias need not be in it.
|
|
|
72 }}}
|
|
|
73 }}}
|
|
|
74 * Privacy {{{
|
|
|
75 * this is not a blocker for 2.0.0
|
|
|
76 * Privacy sucks. it doesn't handle many of the protocols in a way that users understand. notably
|
|
|
77 msn, but also yahoo, jabber, and icq.
|
|
|
78 * We want to sync to the server as much as possible, entirely local-only privacy is not an option
|
|
|
79 except on protocols like irc that have no server-side.
|
|
|
80 * We want to be as consistent across protocols as possible. this will require renaming things on
|
|
|
81 some protocols.
|
|
|
82 * Bleeter suggests that we create a privacy.xml, remove privacy from blist.xml. He suggests
|
|
|
83 that each protocol define certain capabilities & defaults, with accounts.xml holding exceptions
|
|
|
84 to the defaults.
|
|
|
85 }}}
|
