Mercurial > pidgin
annotate TODO @ 11398:90290f579926
[gaim-migrate @ 13630]
a simple fix for a bug found by Daniel Atallah
committer: Tailor Script <tailor@pidgin.im>
author | Thomas Butter <tbutter> |
---|---|
date | Wed, 31 Aug 2005 22:27:16 +0000 |
parents | 8175206faa3d |
children | 66fe476474ec |
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 | |
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 }}} | |
10885
12083e75627f
[gaim-migrate @ 12583]
Luke Schierer <lschiere@pidgin.im>
parents:
10881
diff
changeset
|
86 * Perl {{{ |
12083e75627f
[gaim-migrate @ 12583]
Luke Schierer <lschiere@pidgin.im>
parents:
10881
diff
changeset
|
87 * Update to match as much as possible of the C api |
10886
0ece4cf68ea6
[gaim-migrate @ 12584]
Luke Schierer <lschiere@pidgin.im>
parents:
10885
diff
changeset
|
88 * Block for 2.0.0 or remove perl: |
0ece4cf68ea6
[gaim-migrate @ 12584]
Luke Schierer <lschiere@pidgin.im>
parents:
10885
diff
changeset
|
89 * Test each call to make sure it actually works |
0ece4cf68ea6
[gaim-migrate @ 12584]
Luke Schierer <lschiere@pidgin.im>
parents:
10885
diff
changeset
|
90 * Make it work with G_MODULE_BIND_LOCAL |
10885
12083e75627f
[gaim-migrate @ 12583]
Luke Schierer <lschiere@pidgin.im>
parents:
10881
diff
changeset
|
91 }}} |
10891
8175206faa3d
[gaim-migrate @ 12599]
Luke Schierer <lschiere@pidgin.im>
parents:
10890
diff
changeset
|
92 * Prefs {{{ |
8175206faa3d
[gaim-migrate @ 12599]
Luke Schierer <lschiere@pidgin.im>
parents:
10890
diff
changeset
|
93 * this blocks for 2.0.0 |
8175206faa3d
[gaim-migrate @ 12599]
Luke Schierer <lschiere@pidgin.im>
parents:
10890
diff
changeset
|
94 * 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
|
95 * The biggest problem is that each new plugin creates horizontal space. {{{ |
8175206faa3d
[gaim-migrate @ 12599]
Luke Schierer <lschiere@pidgin.im>
parents:
10890
diff
changeset
|
96 * 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
|
97 * 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
|
98 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
|
99 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
|
100 *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
|
101 display preferences? |
8175206faa3d
[gaim-migrate @ 12599]
Luke Schierer <lschiere@pidgin.im>
parents:
10890
diff
changeset
|
102 }}} |
8175206faa3d
[gaim-migrate @ 12599]
Luke Schierer <lschiere@pidgin.im>
parents:
10890
diff
changeset
|
103 * 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
|
104 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
|
105 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
|
106 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
|
107 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
|
108 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
|
109 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
|
110 possible to combine this with "Conversations" entirely. |
8175206faa3d
[gaim-migrate @ 12599]
Luke Schierer <lschiere@pidgin.im>
parents:
10890
diff
changeset
|
111 }}} |
8175206faa3d
[gaim-migrate @ 12599]
Luke Schierer <lschiere@pidgin.im>
parents:
10890
diff
changeset
|
112 |