From: Sean E. <sea...@gm...> - 2004-10-14 17:10:59
|
I was going to originally wait until after I did status mockups to do this, but the "why did you change to tabs" thread this morning shifted my focus a bit. Also, someone on planet.gnome.org criticized the unreleased, incomplete dialog, but that didn't shift my focus because I don't take anyone who has a blog seriously :). This time, my suggestions are a lot less conservative. As such, I expect a lot more opposition, and do not expect all (or even *most*) of my suggestions to get passed. Here are some more preferences we should remove: Interface ====== Remove the whole thing. Figure out *something* to do with the sole option on it. I'm not sure it's a good idea to remove the option, although when we start using ellipsized widgets in Gaim, it would probably be safer to do so. Buddy List ======= Remove "Show warning levels", "show idle times", "dim idle buddies" default them all to "Yes." Rename "Show buddy icons" to something that more accurately represents what it does. Perhaps we should remove "Raise window on events" and default to no. Does anyone really use that feature? There are a few glitches with "Automatically expand contacts," but it would probably be better to fix the glitches and ditch the option, then to keep the option to work around the glitches. Also, this is currently the only place the Contact feature is named in the Gaim UI, I believe. Doing all this would result in a single option in this tab, which would warrent killing the tab and moving the preferences elsewhere. Conversations ========= Remove "Show buttons as," default to "none." I'm a fan of the more minimalistic interface we've been going for, and I think people would adjust to the removed buttons. We would need to ask an accessibility person if removing the Send button would be problematic, though. Even if it is, we could keep the send button, and ditch the other buttons and kill the preference. Remove "Send unknown slash commands as messages." I'm not sure what I think of the whole "slash" commands deal. They're really only incredibly useful in IRC and other protocols where people are used to them as well as giving plugins a convienient way to interact without UI, but they're inheritly not easily discoverable and can probably be confusing to someone not familiar with IRC. That said, we should kill the option and default to "yes." Remove "Show formatting toolbar." There's a per-conversation option for this that we could have affect the global preference instead. I'm not positive about this one. Remove "Show buddy icons" and "Enable buddy icon animation" and default to "yes." Again, these have per-conversation preferences that could be used for individuals with particularly offensive icons. We could even save the preference for future sessions. People who find the sheer *concept* of buddy icons offensive will just have to suffer. We could probably remove "Show aliases in tabs/titles" and default to "yes" when we can depend on elipsizing support in gtknotebook Remove "use multi-colored screen names in chats" default to "yes." I'm pretty sure I included this in the original prefslash, but I need someone to remind me why it was vetoed. I still support removing "Show IMs and chats in tabbed windows" and defaulting to "yes," but I know I'll never get that through committee. Can we kill "Tab placement" and choose an appropriate place to default to (top or bottom, most likely. I use bottom, but I'd say "top" might be better). This all would leave 5 preferences left on this, the longest, prefs page. Message Text ========= Remove "Show timestamp on messages," default to "yes" or use the per-conversation preference globally (and get it working the way it used to). Remove "Highlight misspelled word," default to "./configure --disable-gtkspell" if you don't want this ;). Remove the "Ignore" preferences, default to "no," make them per-conversation preferences that get saved for future sessions. I think the case is much more likely that there are a handful of people with uber-obnoxious formatting that would cause people to turn these on than someone wanting the preference global. This results in only "Default Formatting" on this tab. Shortcuts ====== Kill the whole tab, default all to "yes," except "Ctrl-number inserts smileys" because it only inserts default AIM smileys and I'm sure there's no good way (apart from, I suppose, setting shortcuts in a theme) to change that. Regardless, I think RobFlynn is the only person who actually uses those shortcuts. Most of these preferences were from the days where these shortcuts conflicted with window manager or other global shortcuts. I think shortcuts have pretty much been standardized and we shouldn't have a problem as long as we don't touch Alt at all. Can anyone provide more insight on this? Network ====== As you know, we killed the browser preference if someone is using GNOME by delagating it to a GNOME command. Apparently, it makes some incomplete assumptions, the details of which I'm not familiar with, but provide we can have a failproof way of detecting if GNOME is running, this is a Good Thing. GNOME also has system-wide proxy preferences; we should use the same method to remove these if GNOME is running and retrieve the correct values with gconf-tool2 if available. If GNOME duplicates the other options on this tab, we should naturally do the same. Also, we should find out if there's a good way to do the same things for KDE preferences. Logging ===== Remove the system log options, leaving just "Enable System log" which we should probably change to "Log all system events," to be consistant with the other log types. Away / Idle ======= "Queue new messages when away" can probably be removed and defaulted to "no," and replaced with a more robust, queueing system for all messages. These preferences, in general, will obviously depend on the direction we take the status UI in. Away Messages =========== Gone. No matter what. These aren't even actually preferences. Protocols ====== I've generally refrained from commenting on how things should be restructured once all the preferences are gone, but I think it's obvious that there should be a single Protocols tab, with gaim_gtk_pref_frames or whatever we call them within that tab. That said: Jabber - Privacy - Hide Operating System" is just generally poorly worded, I think, and just needs to be renamed, although I wouldn't mind seeing it default to "yes" AIM/ICQ - "Use recent buddies group" could possibly be made a global option, and we could simulate the behavior in other protocols. I don't know. Show how long you have been idle - This seems to duplicate the same option in "Away / Idle." There should be a better way to respect the server-side option while keeping the server-side option. Regardless, this preference needs to go. MSN - I find "Display conversation closed notices" useful, and "Display timeout notices" annoying, so I'd propose killing both and making those the defaults, but I'm sure just as many people feel strongly about either. The only use the timeout notices serve, though, is telling you you won't receive typing notifications anymore. Generally, I find that unimportant. Plugins ==== There's the problem of how to give plugins their own pages, that is, whether giving them each their own tab is necessarily a good idea. I really don't know. I think that's all the preferences we can safely remove without too much of a problem. Obviously, I don't expect them all to get killed, but I'd like to see which ones get defended the most. Discuss and opine. -s. |
From: Jon O. <jo...@ob...> - 2004-10-14 18:01:23
|
Greetings, On Thu, 2004-10-14 at 13:10 -0400, Sean Egan wrote: > I was going to originally wait until after I did status mockups to do > this, but the "why did you change to tabs" thread this morning shifted > my focus a bit. >=20 > Also, someone on planet.gnome.org criticized the unreleased, > incomplete dialog, but that didn't shift my focus because I don't take > anyone who has a blog seriously :). >=20 > This time, my suggestions are a lot less conservative. As such, I > expect a lot more opposition, and do not expect all (or even *most*) > of my suggestions to get passed. >=20 > Here are some more preferences we should remove: >=20 > Interface > =3D=3D=3D=3D=3D=3D > Remove the whole thing. Figure out *something* to do with the sole > option on it. I'm not sure it's a good idea to remove the option, > although when we start using ellipsized widgets in Gaim, it would > probably be safer to do so. >=20 > Buddy List > =3D=3D=3D=3D=3D=3D=3D > Remove "Show warning levels", "show idle times", "dim idle buddies" > default them all to "Yes." Bad, I like my buddy list with small icons and=20 > Rename "Show buddy icons" to something that more accurately represents > what it does. > Perhaps we should remove "Raise window on events" and default to no.=20 > Does anyone really use that feature? Of course, couldn't live without it. In fact, I don't know of any of my gaim-using-friends who don't use it. > There are a few glitches with "Automatically expand contacts," but it > would probably be better to fix the glitches and ditch the option, > then to keep the option to work around the glitches. Also, this is > currently the only place the Contact feature is named in the Gaim UI, > I believe. > Doing all this would result in a single option in this tab, which > would warrent killing the tab and moving the preferences elsewhere. >=20 > Conversations > =3D=3D=3D=3D=3D=3D=3D=3D=3D > Remove "Show buttons as," default to "none." I'm a fan of the more > minimalistic interface we've been going for, and I think people would > adjust to the removed buttons. We would need to ask an accessibility > person if removing the Send button would be problematic, though. Even > if it is, we could keep the send button, and ditch the other buttons > and kill the preference. I agree. > Remove "Send unknown slash commands as messages." I'm not sure what I > think of the whole "slash" commands deal. They're really only > incredibly useful in IRC and other protocols where people are used to > them as well as giving plugins a convienient way to interact without > UI, but they're inheritly not easily discoverable and can probably be > confusing to someone not familiar with IRC. That said, we should kill > the option and default to "yes." Also agree. > Remove "Show formatting toolbar." There's a per-conversation option > for this that we could have affect the global preference instead. I'm > not positive about this one. > Remove "Show buddy icons" and "Enable buddy icon animation" and > default to "yes." Again, these have per-conversation preferences that > could be used for individuals with particularly offensive icons. We > could even save the preference for future sessions. People who find > the sheer *concept* of buddy icons offensive will just have to suffer. > We could probably remove "Show aliases in tabs/titles" and default to > "yes" when we can depend on elipsizing support in gtknotebook > Remove "use multi-colored screen names in chats" default to "yes."=20 > I'm pretty sure I included this in the original prefslash, but I need > someone to remind me why it was vetoed. > I still support removing "Show IMs and chats in tabbed windows" and > defaulting to "yes," but I know I'll never get that through committee. > Can we kill "Tab placement" and choose an appropriate place to default > to (top or bottom, most likely. I use bottom, but I'd say "top" might > be better). > This all would leave 5 preferences left on this, the longest, prefs page. >=20 > Message Text > =3D=3D=3D=3D=3D=3D=3D=3D=3D > Remove "Show timestamp on messages," default to "yes" or use the > per-conversation preference globally (and get it working the way it > used to). > Remove "Highlight misspelled word," default to "./configure > --disable-gtkspell" if you don't want this ;). Except for the many users on binary distributions who may have it built with gtkspell support but find the highlighting annoying. > Remove the "Ignore" preferences, default to "no," make them > per-conversation preferences that get saved for future sessions. I > think the case is much more likely that there are a handful of people > with uber-obnoxious formatting that would cause people to turn these > on than someone wanting the preference global. > This results in only "Default Formatting" on this tab. So in other words, we'll be moving a lot of the global preferences to per-buddy preferences. May be beneficial for some people, but a horrible inconvenience for those who want to block all buddy icons or kill all formatting. > Shortcuts > =3D=3D=3D=3D=3D=3D > Kill the whole tab, default all to "yes," except "Ctrl-number inserts > smileys" because it only inserts default AIM smileys and I'm sure > there's no good way (apart from, I suppose, setting shortcuts in a > theme) to change that. Regardless, I think RobFlynn is the only > person who actually uses those shortcuts. Most of these preferences > were from the days where these shortcuts conflicted with window > manager or other global shortcuts. I think shortcuts have pretty much > been standardized and we shouldn't have a problem as long as we don't > touch Alt at all. Can anyone provide more insight on this? I think everything in here could probably go but I'm cautious about removing the "enter/control+enter to send" option. > Network > =3D=3D=3D=3D=3D=3D > As you know, we killed the browser preference if someone is using > GNOME by delagating it to a GNOME command. Apparently, it makes some > incomplete assumptions, the details of which I'm not familiar with, > but provide we can have a failproof way of detecting if GNOME is > running, this is a Good Thing. GNOME also has system-wide proxy > preferences; we should use the same method to remove these if GNOME is > running and retrieve the correct values with gconf-tool2 if available. > If GNOME duplicates the other options on this tab, we should > naturally do the same. Also, we should find out if there's a good way > to do the same things for KDE preferences. >=20 > Logging > =3D=3D=3D=3D=3D > Remove the system log options, leaving just "Enable System log" which > we should probably change to "Log all system events," to be consistant > with the other log types. >=20 > Away / Idle > =3D=3D=3D=3D=3D=3D=3D > "Queue new messages when away" can probably be removed and defaulted > to "no," and replaced with a more robust, queueing system for all > messages. These preferences, in general, will obviously depend on the > direction we take the status UI in. >=20 > Away Messages > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Gone. No matter what. These aren't even actually preferences. >=20 > Protocols > =3D=3D=3D=3D=3D=3D > I've generally refrained from commenting on how things should be > restructured once all the preferences are gone, but I think it's > obvious that there should be a single Protocols tab, with > gaim_gtk_pref_frames or whatever we call them within that tab. That > said: > Jabber - Privacy - Hide Operating System" is just generally poorly > worded, I think, and just needs to be renamed, although I wouldn't > mind seeing it default to "yes" > AIM/ICQ - "Use recent buddies group" could possibly be made a global > option, and we could simulate the behavior in other protocols. I > don't know. > Show how long you have been idle - This seems to duplicate the same > option in "Away / Idle." There should be a better way to respect the > server-side option while keeping the server-side option. Regardless, > this preference needs to go. > MSN - I find "Display conversation closed notices" useful, and > "Display timeout notices" annoying, so I'd propose killing both and > making those the defaults, but I'm sure just as many people feel > strongly about either. The only use the timeout notices serve, > though, is telling you you won't receive typing notifications anymore. > Generally, I find that unimportant. >=20 > Plugins > =3D=3D=3D=3D > There's the problem of how to give plugins their own pages, that is, > whether giving them each their own tab is necessarily a good idea. I > really don't know. >=20 > I think that's all the preferences we can safely remove without too > much of a problem. Obviously, I don't expect them all to get killed, > but I'd like to see which ones get defended the most. >=20 > Discuss and opine. >=20 > -s. Sorry, don't have much time now to comment on everything in depth. Regards, Jon Oberheide --=20 Jon Oberheide <jo...@ob...> GnuPG Key: 1024D/F47C17FE Fingerprint: B716 DA66 8173 6EDD 28F6 F184 5842 1C89 F47C 17FE |
From: Steven G. <ste...@si...> - 2004-10-14 18:04:42
|
Sean Egan wrote: > Buddy List > ======= > Remove "Show warning levels", "show idle times", "dim idle buddies" > default them all to "Yes." > Rename "Show buddy icons" to something that more accurately represents > what it does. > Perhaps we should remove "Raise window on events" and default to no. > Does anyone really use that feature? > There are a few glitches with "Automatically expand contacts," but it > would probably be better to fix the glitches and ditch the option, > then to keep the option to work around the glitches. Also, this is > currently the only place the Contact feature is named in the Gaim UI, > I believe. > Doing all this would result in a single option in this tab, which > would warrent killing the tab and moving the preferences elsewhere. Agreed on most parts. I've always turned off "Auto expand contacts" - never saw the value in it. Once I have meta contacts setup, I treat them as one content in my head - the various protocols used become transparent. > Conversations > ========= > Remove "Show buttons as," default to "none." I'm a fan of the more > minimalistic interface we've been going for, and I think people would > adjust to the removed buttons. We would need to ask an accessibility > person if removing the Send button would be problematic, though. Even > if it is, we could keep the send button, and ditch the other buttons > and kill the preference. Agreed. > Remove "Send unknown slash commands as messages." I'm not sure what I > think of the whole "slash" commands deal. They're really only > incredibly useful in IRC and other protocols where people are used to > them as well as giving plugins a convienient way to interact without > UI, but they're inheritly not easily discoverable and can probably be > confusing to someone not familiar with IRC. That said, we should kill > the option and default to "yes." Agreed. > Remove "Show formatting toolbar." There's a per-conversation option > for this that we could have affect the global preference instead. I'm > not positive about this one. Yeah, we could rely on the per-conversation option and make it global. A little weird, but not bad. > Message Text > ========= > Remove "Show timestamp on messages," default to "yes" or use the > per-conversation preference globally (and get it working the way it > used to). Agreed. > Remove "Highlight misspelled word," default to "./configure > --disable-gtkspell" if you don't want this ;). > Remove the "Ignore" preferences, default to "no," make them > per-conversation preferences that get saved for future sessions. I > think the case is much more likely that there are a handful of people > with uber-obnoxious formatting that would cause people to turn these > on than someone wanting the preference global. > This results in only "Default Formatting" on this tab. Agreed. > Logging > ===== > Remove the system log options, leaving just "Enable System log" which > we should probably change to "Log all system events," to be consistant > with the other log types. Agreed. > Away Messages > =========== > Gone. No matter what. These aren't even actually preferences. Agreed. > Protocols > ====== > I've generally refrained from commenting on how things should be > restructured once all the preferences are gone, but I think it's > obvious that there should be a single Protocols tab, with > gaim_gtk_pref_frames or whatever we call them within that tab. Agreed. > Plugins > ==== > There's the problem of how to give plugins their own pages, that is, > whether giving them each their own tab is necessarily a good idea. I > really don't know. What about putting the plugin-specific prefs on another inside tab (even though hardcore tabs-on-tabs action is wacky) along with Description and Details? Up with PREFSLASH 2! Steven Garrity |
From: Andrew S. <gt...@ma...> - 2004-10-14 18:12:31
|
On Thu, 2004-10-14 at 13:10 -0400, Sean Egan wrote: > I still support removing "Show IMs and chats in tabbed windows" and > defaulting to "yes," but I know I'll never get that through committee. > Can we kill "Tab placement" and choose an appropriate place to default > to (top or bottom, most likely. I use bottom, but I'd say "top" might > be better). No no no no no no... Top and bottom are the worst for screen real-estate vs. information shown. The whole conversation window is set up so that information will flow from top to bottom. This means that you'll always have more vertical pixels than horizontal pixels. Especially if you want to put chats and conversations in the same tabbed area, there are a lot of tabs to display. I've always used right/left for conversations, and top/bottom for chats. The names in conversations are easily controllable so they don't stretch the window out really far. In chats, they aren't, so I put them along the top so the window doesn't stretch to fit the entire screen. > > Away / Idle > ======= > "Queue new messages when away" can probably be removed and defaulted > to "no," and replaced with a more robust, queueing system for all > messages. These preferences, in general, will obviously depend on the > direction we take the status UI in. How does this fit with the new status system? Which types of status's are "Away." I'm not entirely familiar with the new design. I lurk with away messages all of time and still talk to people. I don't want queueing at all. Is there going to be a way to just turn it off? -- Just because my vocabulary isn't as high, doesn't mean that I can't post a challenging response to your message. |
From: Sean E. <sea...@gm...> - 2004-10-14 18:41:37
|
On Thu, 14 Oct 2004 14:14:19 -0400, Andrew Sayman <gt...@ma...> wrote: > No no no no no no... > Top and bottom are the worst for screen real-estate vs. information > shown. The whole conversation window is set up so that information will > flow from top to bottom. This means that you'll always have more > vertical pixels than horizontal pixels. Especially if you want to put > chats and conversations in the same tabbed area, there are a lot of tabs > to display. I think I understand your concern, but you reasoning is flawed. Putting tabs on the bottom doesn't take more room because there's more room on the side, but because text is a lot wider than it is tall. A lot of people have concern about the way gtknotebook scrolls tabs, but once we can ellipsize them, we can theoretically put as many tabs in as little space as possible. -s. |
From: Andrew S. <gt...@ma...> - 2004-10-14 18:51:47
|
On Thu, 2004-10-14 at 14:41 -0400, Sean Egan wrote: > On Thu, 14 Oct 2004 14:14:19 -0400, Andrew Sayman > <gt...@ma...> wrote: > > No no no no no no... > > Top and bottom are the worst for screen real-estate vs. information > > shown. The whole conversation window is set up so that information will > > flow from top to bottom. This means that you'll always have more > > vertical pixels than horizontal pixels. Especially if you want to put > > chats and conversations in the same tabbed area, there are a lot of tabs > > to display. > > I think I understand your concern, but you reasoning is flawed. > Putting tabs on the bottom doesn't take more room because there's more > room on the side, but because text is a lot wider than it is tall. I missed a few words in there... what I meant was that putting tabs along the left and right is better because conversation names tend to take up less vertical space. This means you can comfortably fit a lot more of them in right/left tabs because this is the area with the most vertical space. > > A lot of people have concern about the way gtknotebook scrolls tabs, > but once we can ellipsize them, we can theoretically put as many tabs > in as little space as possible. > I don't know for sure what ellipses are, but if this is anything like how Firefox handles tabs, it won't solve the problem I'm describing at all. If I have 20 conversations open, I'm just going to see 20 sets of "..." Along the right and left you can ellipse at say 20 characters. This will limit the amount of horizontal expansion, and give you plenty of space for lots of conversations to be listed along the vertical. -- Marketing: The art of making you think you got something better than you actually did. |
From: Luke S. <lsc...@us...> - 2004-10-14 19:20:17
|
On %+, Andrew Sayman wrote: > I don't know for sure what ellipses are, but if this is anything like > how Firefox handles tabs, it won't solve the problem I'm describing at > all. If I have 20 conversations open, I'm just going to see 20 sets of > "..." Along the right and left you can ellipse at say 20 characters. > This will limit the amount of horizontal expansion, and give you plenty > of space for lots of conversations to be listed along the vertical. actually, I tend to agree here, ellipses does not solve the problem of too many tabs, it just makes the possible tab count higher. luke |
From: Stu T. <st...@no...> - 2004-10-14 18:40:43
|
On Thu, 2004-10-14 at 13:10, Sean Egan wrote: > This time, my suggestions are a lot less conservative. As such, I > expect a lot more opposition, and do not expect all (or even *most*) > of my suggestions to get passed. I agree with most of these, actually. Some comments below. > Buddy List > Perhaps we should remove "Raise window on events" and default to no. > Does anyone really use that feature? I suspect people (used to?) use it as a poor-man's Guifications. I think it should go. > Doing all this would result in a single option in this tab, which > would warrent killing the tab and moving the preferences elsewhere. By my count it would leave 2 - "Sorting" and (the renamed) "Show buddy icons", but still, yes, kill the tab and move them elsewhere. > Conversations > Remove "Show buttons as," default to "none." I'm a fan of the more Some plugins like to add buttons to the conversation windows, maybe gtkimhtmltoolbar could be extended to allow plugins to continue to do so, but on the formatting toolbar instead? Maybe the "formatting toolbar" should just be referred to as the "toolbar" too, it already does more than just formatting. > Remove "Send unknown slash commands as messages." <snip> > That said, we should kill the option and default to "yes." On protocols where slash commands are common (IRC & SILC), I think this is a bad option. Maybe have the prpl specify what to do instead? > Remove "Show formatting toolbar." There's a per-conversation option > for this that we could have affect the global preference instead. I'm > not positive about this one. I like the idea, but we need to either make it obvious that the other conversation window options are not global, or make them global (I'm not a fan of making them all global, I often toggle Logging and/or Sounds for individual conversations). > We could probably remove "Show aliases in tabs/titles" and default to > "yes" when we can depend on elipsizing support in gtknotebook That would be bad for MSN users who have buddies with a tendency to set their friendly name to something completely ridiculous. > Remove "use multi-colored screen names in chats" default to "yes." > I'm pretty sure I included this in the original prefslash, but I need > someone to remind me why it was vetoed. I agree with removing this this, but there may be a11y issues with it. Could we also have less pastelly (is that a word?) colors please? > I still support removing "Show IMs and chats in tabbed windows" and > defaulting to "yes," but I know I'll never get that through committee. I must be on a different committee, I'd vote for this. You didn't mention "Show close buttons on tabs", I think that should go, default to "Yes" > Can we kill "Tab placement" and choose an appropriate place to default > to (top or bottom, most likely. I use bottom, but I'd say "top" might > be better). top++ > Message Text > Remove the "Ignore" preferences, default to "no," make them > per-conversation preferences that get saved for future sessions. I > think the case is much more likely that there are a handful of people > with uber-obnoxious formatting that would cause people to turn these > on than someone wanting the preference global. I want this as a global preference, I have all three permanently set, and still want an additional "Ignore font formatting" (bold etc.). Maybe merge them into a single "Ignore all font formatting". (ISTR this is what was suggested in the last prefslash, but it didn't happen for some reason), possibly move the UI to set it to the Options menu in conversation windows. > Shortcuts > Kill the whole tab, default all to "yes," except "Ctrl-number inserts > smileys" I don't want escape to close windows (does it really close windows? shouldn't that be "Escape closes conversation"). Also, don't the Ctrl-B/I/U shortcuts conflict with emacs key bindings or something? > Network I suggest also removing "Autodetect IP address" - use the specified public IP if one is specified, if one isn't specified explicitly, then autodetect it. > Protocols > The only use the timeout notices serve, > though, is telling you you won't receive typing notifications anymore. I never realized it had any relevance at all. > Plugins > There's the problem of how to give plugins their own pages, that is, > whether giving them each their own tab is necessarily a good idea. I > really don't know. How about putting a plugins preference page in an additional "Preferences" tab alongside the Description & Details tabs ? Regards, Stu. |
From: Sean E. <sea...@gm...> - 2004-10-14 19:04:41
|
On Thu, 14 Oct 2004 14:41:18 -0400, Stu Tomlinson <st...@no...> wrote: > I suspect people (used to?) use it as a poor-man's Guifications. I think > it should go. I used to (I wrote the feature, actually), but then my buddy list grew huge and it became too much of an annoyance. But, yeah, something like guifications is a much better implementation than this feature. > Some plugins like to add buttons to the conversation windows, maybe > gtkimhtmltoolbar could be extended to allow plugins to continue to do > so, but on the formatting toolbar instead? Already done. In HEAD, gtkimhtmltoolbar descends from GtkHbox, so gtk_box_pack_start is all that's needed to add a button. > Maybe the "formatting > toolbar" should just be referred to as the "toolbar" too, it already > does more than just formatting. I suppose so, but I'd still consider inserting images, smileys, and links more formatting-related than, say, gaim-encryption's status icons. I think that if plugins really want to add per-conversation buttons, they should put them in a menu somehow. > On protocols where slash commands are common (IRC & SILC), I think this > is a bad option. Maybe have the prpl specify what to do instead? The only downside is that a user expecting a command to work will send it. I think this is preferable to a user expecting his message to send and getting an error message. The protocol specifying what to do (registering a "default" command handler for all commands seems logical), would be a happy medium. > That would be bad for MSN users who have buddies with a tendency to set > their friendly name to something completely ridiculous. I wonder how many times I can mention ellipsizing gtknotebooks in this thread. > I agree with removing this this, but there may be a11y issues with it. > Could we also have less pastelly (is that a word?) colors please? Luke convinced me to write an algorithm that will determine suitable colors based on your GTK theme for both this and for Dim idle buddies. > You didn't mention "Show close buttons on tabs", I think that should go, > default to "Yes" You're probably right, but I expect this pref to have a lot of support. Apparently it's too easy to hit the x by mistake. Perhaps we can do something cool, and detect if the mouse is on the border of the close button, and if it is, hold it that there for a short delay. That would seem to prevent people from accidentally clicking it, because it effectively makes the tab itself much larger from a Fitz viewpoint. > Maybe merge them into a single "Ignore all font formatting". (ISTR this > is what was suggested in the last prefslash, but it didn't happen for > some reason), possibly move the UI to set it to the Options menu in > conversation windows. It was suggested last time. If we keep the global options, I'd support doing this again. > I don't want escape to close windows (does it really close windows? > shouldn't that be "Escape closes conversation"). Also, don't the > Ctrl-B/I/U shortcuts conflict with emacs key bindings or something? I don't really care what we default "escape closes windows" to, as long as we get rid of it. Ctrl-b/i/u does conflict with the emacs bindings, but, tough cookies, I say. I suppose we could check to see what keybinding is being used, and let its bindings overrule our own. For some reason I doubt anyone using emacs bindings uses a whole lot of formatting in his messages. > I suggest also removing "Autodetect IP address" - use the specified > public IP if one is specified, if one isn't specified explicitly, then > autodetect it. Good idea. > How about putting a plugins preference page in an additional > "Preferences" tab alongside the Description & Details tabs ? That's what Steven suggested. I'm not sure there's enough room there, but I suppose few plugins have that many preferences (guifications being a notable exception which would then have tabs within tabs within tabs in the new dialog). |
From: Luke S. <lsc...@us...> - 2004-10-14 19:49:43
|
On %+, Sean Egan wrote: > On Thu, 14 Oct 2004 14:41:18 -0400, Stu Tomlinson <st...@no...> wrote: <snip> > > On protocols where slash commands are common (IRC & SILC), I think this > > is a bad option. Maybe have the prpl specify what to do instead? > > The only downside is that a user expecting a command to work will send > it. I think this is preferable to a user expecting his message to > send and getting an error message. The protocol specifying what to do > (registering a "default" command handler for all commands seems > logical), would be a happy medium. agreed. > > > That would be bad for MSN users who have buddies with a tendency to set > > their friendly name to something completely ridiculous. > > I wonder how many times I can mention ellipsizing gtknotebooks in this thread. at least 10 more times :-P <snip> > > You didn't mention "Show close buttons on tabs", I think that should go, > > default to "Yes" > > You're probably right, but I expect this pref to have a lot of > support. Apparently it's too easy to hit the x by mistake. i've never understood this particular assertion. > > Perhaps we can do something cool, and detect if the mouse is on the > border of the close button, and if it is, hold it that there for a > short delay. That would seem to prevent people from accidentally > clicking it, because it effectively makes the tab itself much larger > from a Fitz viewpoint. this sounds like asking for trouble & confusion. > > > Maybe merge them into a single "Ignore all font formatting". (ISTR this > > is what was suggested in the last prefslash, but it didn't happen for > > some reason), possibly move the UI to set it to the Options menu in > > conversation windows. > > It was suggested last time. If we keep the global options, I'd > support doing this again. there will be a run on simguy's plugin for win32 users currently using this to deal with the sizing issues on win32 + wimp ;-) > > > I don't want escape to close windows (does it really close windows? > > shouldn't that be "Escape closes conversation"). Also, don't the > > Ctrl-B/I/U shortcuts conflict with emacs key bindings or something? > > I don't really care what we default "escape closes windows" to, as i like defaulting to "yes" ;-) > long as we get rid of it. Ctrl-b/i/u does conflict with the emacs > bindings, but, tough cookies, I say. I suppose we could check to see > what keybinding is being used, and let its bindings overrule our own. > For some reason I doubt anyone using emacs bindings uses a whole lot > of formatting in his messages. probly true. <snip> |
From: Stu T. <st...@no...> - 2004-10-14 20:02:10
|
On Thu, 2004-10-14 at 15:04, Sean Egan wrote: > > That would be bad for MSN users who have buddies with a tendency to set > > their friendly name to something completely ridiculous. > > I wonder how many times I can mention ellipsizing gtknotebooks in this thread. Sorry, I wasn't clear about what my concern is - and it's nothing to do with the length, or anything that ellipsizing could solve. An unfortunately large number of MSN users use their Friendly name as an Away/Available message to make up for the lack of support for these in the protocol. Quite a few use it for other more stupid things. Neither use makes it in any way obvious *who* you are talking to. Regards, Stu. |
From: Tim R. <om...@ho...> - 2004-10-15 00:29:46
|
> > >>I suggest also removing "Autodetect IP address" - use the specified >>public IP if one is specified, if one isn't specified explicitly, then >>autodetect it. >> >> Sean Egan wrote: >Good idea. > > > I don't really consider that two preferences. If we only have the box, then won't users think they HAVE to enter one and there is no autodetection? --Tim |
From: Tim R. <om...@ho...> - 2004-10-15 01:03:51
|
Nathan Walp wrote: > > If it's blank, fill it with "(auto)" > Good idea. If someone wanted to take it one step further, they could use one of those editable dropdown thingies, and remember recent IP's, as well as having an auto option. But that might be overboard. --Tim |
From: Christopher (s. O'B. <si...@pr...> - 2004-10-14 18:41:59
|
On Thu, 2004-10-14 at 13:10 -0400, Sean Egan wrote: > Buddy List > ======= > Remove "Show warning levels", "show idle times", "dim idle buddies" > default them all to "Yes." Warning levels. Do these exist anywhere outside of AIM? Does anyone ever do anything at all with that information? I've had it turned off since the first time I used Gaim, and it's stayed that way. > Remove "Show buddy icons" and "Enable buddy icon animation" and > default to "yes." Again, these have per-conversation preferences that > could be used for individuals with particularly offensive icons. We > could even save the preference for future sessions. People who find > the sheer *concept* of buddy icons offensive will just have to suffer. That's pretty harsh, and I'd really really hope that the options for both the icon and their animation stick around. > Can we kill "Tab placement" and choose an appropriate place to default > to (top or bottom, most likely. I use bottom, but I'd say "top" might > be better). >From someone who puts his tabs on the right side, I'd vote strongly 'no' > Message Text > ========= > Remove "Show timestamp on messages," default to "yes" or use the > per-conversation preference globally (and get it working the way it > used to). Something I always leave off, in favour of the iChat timestamp plugin, which I think rocks. > Remove the "Ignore" preferences, default to "no," make them > per-conversation preferences that get saved for future sessions. I > think the case is much more likely that there are a handful of people > with uber-obnoxious formatting that would cause people to turn these > on than someone wanting the preference global. > This results in only "Default Formatting" on this tab. Ignoring all incoming fonts and colors saves my dubious sanity pretty often, but so long as it's easy enough to set it for the obnoxious people, then it's fine. I'd really rather not have to worry about it though, and just see everyone as relatively plain text. > MSN - I find "Display conversation closed notices" useful, and > "Display timeout notices" annoying, so I'd propose killing both and > making those the defaults, but I'm sure just as many people feel > strongly about either. The only use the timeout notices serve, > though, is telling you you won't receive typing notifications anymore. > Generally, I find that unimportant. Could this sort of notice be moved into the typing notification graphic instead? That little icon space could really display this better than lines in the conversation. > Discuss and opine. Ok. - siege -- Christopher (siege) O'Brien <si...@pr...> http://preoccupied.net/~siege/ |
From: Luke S. <lsc...@us...> - 2004-10-14 19:52:48
|
On %+, Christopher (siege) O'Brien wrote: > > On Thu, 2004-10-14 at 13:10 -0400, Sean Egan wrote: > > Buddy List > > ======= > > Remove "Show warning levels", "show idle times", "dim idle buddies" > > default them all to "Yes." > > Warning levels. Do these exist anywhere outside of AIM? Does anyone ever > do anything at all with that information? I've had it turned off since > the first time I used Gaim, and it's stayed that way. nope. which is a good reason to have that option remain, or default to "no". its a throw-back to our days as an aim-only client. actually, if you default that one to "no", i don't mind removing the options. > > > Remove "Show buddy icons" and "Enable buddy icon animation" and > > default to "yes." Again, these have per-conversation preferences that > > could be used for individuals with particularly offensive icons. We > > could even save the preference for future sessions. People who find > > the sheer *concept* of buddy icons offensive will just have to suffer. > > That's pretty harsh, and I'd really really hope that the options for > both the icon and their animation stick around. I'd prefer they stick around, but remembering my decisions should do the job for most cases. > > Message Text > > ========= > > Remove "Show timestamp on messages," default to "yes" or use the > > per-conversation preference globally (and get it working the way it > > used to). > > Something I always leave off, in favour of the iChat timestamp plugin, > which I think rocks. perhaps the ichat plugin could be re-done to supress them as the autorecon plugin can suppress some of the other ui features. > > MSN - I find "Display conversation closed notices" useful, and > > "Display timeout notices" annoying, so I'd propose killing both and > > making those the defaults, but I'm sure just as many people feel > > strongly about either. The only use the timeout notices serve, > > though, is telling you you won't receive typing notifications anymore. > > Generally, I find that unimportant. > > Could this sort of notice be moved into the typing notification graphic > instead? That little icon space could really display this better than > lines in the conversation. i like this idea. luke > - siege |
From: Nathan F. <na...@si...> - 2004-10-14 18:44:40
|
Agreed on most. On Thu, 2004-10-14 at 13:10, Sean Egan wrote: > Conversations > ========= > Remove "Show buttons as," default to "none." I'm a fan of the more > minimalistic interface we've been going for, and I think people would > adjust to the removed buttons. We would need to ask an accessibility > person if removing the Send button would be problematic, though. Even > if it is, we could keep the send button, and ditch the other buttons > and kill the preference. Yeah, everything else is fine being in the menu only, except for the send button. Perhaps a better location for the send button that doesn't require a full horizontal toolbar. > Remove "Show formatting toolbar." There's a per-conversation option > for this that we could have affect the global preference instead. I'm > not positive about this one. Not sure either. If I turned it on to send formatted text to one buddy, I wouldn't really want that to become my new default. > Can we kill "Tab placement" and choose an appropriate place to default > to (top or bottom, most likely. I use bottom, but I'd say "top" might > be better). I support this if the default was bottom ;) > Message Text > ========= > Remove "Highlight misspelled word," default to "./configure > --disable-gtkspell" if you don't want this ;). That only really works for people who build their own gaim. If I use the gaim from my distro I'd be forced to use spell checking. > Shortcuts > ====== > Kill the whole tab, default all to "yes," except "Ctrl-number inserts > smileys" Defaulting "Enter sends messages" to yes will make it impossible to write multi-line messages without knowing some other shortcut. Nathan |
From: Luke S. <lsc...@us...> - 2004-10-14 18:47:45
|
anything snipped or not commented on, I agree with, or at least do not disagree enough to defend it. On %+, Sean Egan wrote: <snip> > Buddy List > ======= > Remove "Show warning levels", "show idle times", "dim idle buddies" > default them all to "Yes." disagree. this only works for the big blist view, in the small view, these are much needed preferences even if you aren't a extremely-narrow-blist person. <snip> > Perhaps we should remove "Raise window on events" and default to no. > Does anyone really use that feature? given i get questions about why doesn't it work right on win32 & kde, i would say yes. > There are a few glitches with "Automatically expand contacts," but it > would probably be better to fix the glitches and ditch the option, > then to keep the option to work around the glitches. Also, this is > currently the only place the Contact feature is named in the Gaim UI, > I believe. Like someone else said, i prefer not to deal with the buddies inside a contact whenever possible. I prefer having this option off, and in fact i'd like to see the idea of contacts get stronger, with a contact-aware log viewwer & system log viewwer. > Doing all this would result in a single option in this tab, which > would warrent killing the tab and moving the preferences elsewhere. > > Conversations > ========= <snip> > Remove "Show formatting toolbar." There's a per-conversation option > for this that we could have affect the global preference instead. I'm > not positive about this one. i'm not a fan of making the per-conversation options global. what I would like to see though, is have these per-conversation options remembered for buddies on your buddy list. if this were done, I would not object to removing the globals. > Remove "Show buddy icons" and "Enable buddy icon animation" and > default to "yes." Again, these have per-conversation preferences that > could be used for individuals with particularly offensive icons. We > could even save the preference for future sessions. People who find > the sheer *concept* of buddy icons offensive will just have to suffer. see above, with the additional note of the fact that turning off a single buddy's annoying animation every time is a strong arguement for why the above is necessary if this is defaulted to "yes". > We could probably remove "Show aliases in tabs/titles" and default to > "yes" when we can depend on elipsizing support in gtknotebook > Remove "use multi-colored screen names in chats" default to "yes." > I'm pretty sure I included this in the original prefslash, but I need > someone to remind me why it was vetoed. this option is necessary untill you figure out how to compute the colors to use based on the gtk theme. > I still support removing "Show IMs and chats in tabbed windows" and > defaulting to "yes," but I know I'll never get that through committee. > Can we kill "Tab placement" and choose an appropriate place to default > to (top or bottom, most likely. I use bottom, but I'd say "top" might > be better). i would say bottom, you want your tab changing to be near where your input is. that being said, one of the big requests for elipsis support comes from people who use the tabs on the left option. so i would say not to remove this at all. > This all would leave 5 preferences left on this, the longest, prefs page. > <snip> > > Shortcuts > ====== <snip long discussion about the single idea to default most if it to yes> the enter options are used by the i18n & accessibility stuff. > Network ====== we do need these options if not using gnome, kde, or win32. > <snip> > > Away / Idle > ======= > "Queue new messages when away" can probably be removed and defaulted > to "no," and replaced with a more robust, queueing system for all > messages. These preferences, in general, will obviously depend on the > direction we take the status UI in. sidenote, we've been expecting a patch from *ahem* robot101 *ahem* someone for this for ages. > <snip> > > Protocols > ====== <snip> > AIM/ICQ - "Use recent buddies group" could possibly be made a global > option, and we could simulate the behavior in other protocols. I > don't know. making this global sounds good. <snip> > Discuss and opine. see above :-) luke > > -s. > |
From: Daniel A. <dan...@gm...> - 2004-10-14 19:17:58
|
> Remove "Show buddy icons" and "Enable buddy icon animation" and > default to "yes." Again, these have per-conversation preferences that > could be used for individuals with particularly offensive icons. We > could even save the preference for future sessions. People who find > the sheer *concept* of buddy icons offensive will just have to suffer. Removing the "Enable buddy icon animation" preference and defaulting to yes will be a somewhat serious problem for win32 since the animation uses unhealthy amounts of CPU time. (Yes, i know it is a GTK bug, but this would remove the workaround that has been in place for quite some time) **Sorry Sean, i forgot to send this to the list the first time. |
From: Ethan B. <ebl...@cs...> - 2004-10-14 20:15:49
|
Sean Egan spake unto us the following wisdom: > I was going to originally wait until after I did status mockups to do > this, but the "why did you change to tabs" thread this morning shifted > my focus a bit. People are afraid of what they do not understand. And people aren't afraid of CVS, which they should be. Together it's just a bad combina- tion. I largely agree with your assessments. Here are my comments. > Perhaps we should remove "Raise window on events" and default to no.=20 > Does anyone really use that feature? Kill it. > There are a few glitches with "Automatically expand contacts," but it > would probably be better to fix the glitches and ditch the option, > then to keep the option to work around the glitches. Also, this is > currently the only place the Contact feature is named in the Gaim UI, > I believe. I agree, fix them and turn it on by default. I'm not even sure what needs fixing, as they work fine for me. > Remove "Show buttons as," default to "none." I'm a fan of the more > minimalistic interface we've been going for, and I think people would > adjust to the removed buttons. We would need to ask an accessibility > person if removing the Send button would be problematic, though. Even > if it is, we could keep the send button, and ditch the other buttons > and kill the preference. I agree, and I would kill the send button as well. Apple did this in iChat, and if Mac users can understand it then anybody can. > Remove "Send unknown slash commands as messages." I'm not sure what I > think of the whole "slash" commands deal. They're really only > incredibly useful in IRC and other protocols where people are used to > them as well as giving plugins a convienient way to interact without > UI, but they're inheritly not easily discoverable and can probably be > confusing to someone not familiar with IRC. That said, we should kill > the option and default to "yes." I disagree strongly. Slash commands should NOT be sent as messages if they are not recognized; the fundamental problem is that we've put slash commands in places that they do not belong. They should be in IRC and SILC and probably nowhere else. AIM has no slash commands. > I still support removing "Show IMs and chats in tabbed windows" and > defaulting to "yes," but I know I'll never get that through committee. > Can we kill "Tab placement" and choose an appropriate place to default > to (top or bottom, most likely. I use bottom, but I'd say "top" might > be better). I would not show IMs and chats in the same tabbed window, simply because our chat window is so horrible and huge. I hate it. IMs are small and beautiful. > Remove the "Ignore" preferences, default to "no," make them > per-conversation preferences that get saved for future sessions. I > think the case is much more likely that there are a handful of people > with uber-obnoxious formatting that would cause people to turn these > on than someone wanting the preference global. > This results in only "Default Formatting" on this tab. I think there should be exactly one preference for this, "Ignore all incoming formatting". There are legitimate reasons to want this glob- ally (accessibility not being the least of these), but I see no reason for it to be so complicated. > Kill the whole tab, default all to "yes," except "Ctrl-number inserts > smileys" because it only inserts default AIM smileys and I'm sure > there's no good way (apart from, I suppose, setting shortcuts in a > theme) to change that. Regardless, I think RobFlynn is the only > person who actually uses those shortcuts. Most of these preferences > were from the days where these shortcuts conflicted with window > manager or other global shortcuts. I think shortcuts have pretty much > been standardized and we shouldn't have a problem as long as we don't > touch Alt at all. Can anyone provide more insight on this? No. Regardless of what all the losers out there using arrow keys think, ^b is back one character. ^u is kill input. Some of us can and do touch type. > Remove the system log options, leaving just "Enable System log" which > we should probably change to "Log all system events," to be consistant > with the other log types. I think we should remove this preference as well, and simply log system events if we log. They're really not a big deal. > MSN - I find "Display conversation closed notices" useful, and > "Display timeout notices" annoying, so I'd propose killing both and > making those the defaults, but I'm sure just as many people feel > strongly about either. The only use the timeout notices serve, > though, is telling you you won't receive typing notifications anymore. > Generally, I find that unimportant. I'd kill them both in every respect. I don't give a crap what the other person is doing with their windows, because I'm not a stalker. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
From: Peter L. <spa...@si...> - 2004-10-14 20:50:31
|
Ethan Blanton wrote: >Sean Egan spake unto us the following wisdom: > > >>I was going to originally wait until after I did status mockups to do >>this, but the "why did you change to tabs" thread this morning shifted >>my focus a bit. >> >> > >People are afraid of what they do not understand. And people aren't >afraid of CVS, which they should be. Together it's just a bad combina- >tion. > >I largely agree with your assessments. Here are my comments. > > > >>Perhaps we should remove "Raise window on events" and default to no. >>Does anyone really use that feature? >> >> > >Kill it. > > > >>There are a few glitches with "Automatically expand contacts," but it >>would probably be better to fix the glitches and ditch the option, >>then to keep the option to work around the glitches. Also, this is >>currently the only place the Contact feature is named in the Gaim UI, >>I believe. >> >> > >I agree, fix them and turn it on by default. I'm not even sure what >needs fixing, as they work fine for me. > > > >>Remove "Show buttons as," default to "none." I'm a fan of the more >>minimalistic interface we've been going for, and I think people would >>adjust to the removed buttons. We would need to ask an accessibility >>person if removing the Send button would be problematic, though. Even >>if it is, we could keep the send button, and ditch the other buttons >>and kill the preference. >> >> > >I agree, and I would kill the send button as well. Apple did this in >iChat, and if Mac users can understand it then anybody can. > > > >>Remove "Send unknown slash commands as messages." I'm not sure what I >>think of the whole "slash" commands deal. They're really only >>incredibly useful in IRC and other protocols where people are used to >>them as well as giving plugins a convienient way to interact without >>UI, but they're inheritly not easily discoverable and can probably be >>confusing to someone not familiar with IRC. That said, we should kill >>the option and default to "yes." >> >> > >I disagree strongly. Slash commands should NOT be sent as messages if >they are not recognized; the fundamental problem is that we've put slash >commands in places that they do not belong. They should be in IRC and >SILC and probably nowhere else. AIM has no slash commands. > > > Yahoo has slash commands, which the prpl does not (yet) implement (/join chatroomname[:roomnumber] is one, /me for the 'action' is another [which doesn't 'match' the default client behaviour, but that's irrelevant for this discussion]). There may be more, but they're not coming to the top of my head this morning. IIRC, the preference used to behave as you would prefer, but it was discovered this interfered with sending of smileys that started with a slash [eg, one of Yahoo's "what the hell are you on????" smileys - /:) ]. I'd suggest the non-sending of smileys is a more important potential issue than some prpl functionality, no matter how 'useful' both may be. Regards, Bleets. |
From: Tim R. <om...@ho...> - 2004-10-15 00:46:50
|
Peter Lawler wrote: > Ethan Blanton wrote: > >> Sean Egan spake unto us the following wisdom: >> >> >>> Remove "Send unknown slash commands as messages." I'm not sure what I >>> think of the whole "slash" commands deal. They're really only >>> incredibly useful in IRC and other protocols where people are used to >>> them as well as giving plugins a convienient way to interact without >>> UI, but they're inheritly not easily discoverable and can probably be >>> confusing to someone not familiar with IRC. That said, we should kill >>> the option and default to "yes." >>> >> >> >> I disagree strongly. Slash commands should NOT be sent as messages if >> they are not recognized; the fundamental problem is that we've put slash >> commands in places that they do not belong. They should be in IRC and > Remember that faceprint orignally committed the patch, because he wanted it for jabber chats. >> >> SILC and probably nowhere else. AIM has no slash commands. > Believe it or not, AIM chat's have // commands. They're server side though. >> >> >> >> > Yahoo has slash commands, which the prpl does not (yet) implement > (/join chatroomname[:roomnumber] is one, /me for the 'action' is > another [which doesn't 'match' the default client behaviour, but > that's irrelevant for this discussion]). There may be more, but > they're not coming to the top of my head this morning. > > IIRC, the preference used to behave as you would prefer, but it was > discovered this interfered with sending of smileys that started with a > slash [eg, one of Yahoo's "what the hell are you on????" smileys - /:) ]. If a smiley appears in the input widget as a graphic, it will send regardless now (that used to be a bug). The pref was more for people typing file paths. It seems to have made them happy. > > > I'd suggest the non-sending of smileys is a more important potential > issue than some prpl functionality, no matter how 'useful' both may be. > /me currently does work on yahoo chat's as it should. (Or did last time I checked :) Yahoo Chat's, on the java client at least, have a number of commands, such as /me, /think, /follow, /goto, /join, of which only /me Gaim currently implements. I was also considering implementing a /buzz command for IM's, although Yahoo uses a menu item or button or something. --Tim |
From: Peter L. <spa...@si...> - 2004-10-15 01:11:38
|
Tim Ringenbach wrote: > > /me currently does work on yahoo chat's as it should. (Or did last > time I checked :) > Yahoo Chat's, on the java client at least, have a number of commands, > such as /me, /think, /follow, /goto, /join, of which only /me Gaim > currently implements. I was also considering implementing a /buzz > command for IM's, although Yahoo uses a menu item or button or something. > > --Tim Hi Tim, I've been fiddling with grim's gxr a bit to provide a bell button for YIM IM's, amongst other things. Unfortunately, there's one plugin unloading bug with it (it's possible to end up with hundreds of extra buttons). Grim's intendeing to fix this up in the next few days. I was intending to release once that's done. It has a /bell, but that could be easily changed to /buzz. If not a plugin, I had been curious as to whether this should be yahoo prpl, or core (in view that another protocol may sometime in the future, or even currently support it or a similar 'oi, are you there' function). I had been thinking about extending it to add a popup menu for Yahoo chats to provide the 'actions' as the official client does (using a dynamic popup depending on if you've selected a room member or not), but have'nt yet looked at how to find out which room member is selected. If you give me some direction on that, I'll supply a patch for the basic bell operation by the end of the w/e for both HEAD and oldstatus if you like. Regards, Pete. |
From: Ka-Hing C. <ja...@ja...> - 2004-10-15 02:10:31
|
On Thu, 2004-10-14 at 15:15 -0500, Ethan Blanton wrote: > > There are a few glitches with "Automatically expand contacts," but it > > would probably be better to fix the glitches and ditch the option, > > then to keep the option to work around the glitches. Also, this is > > currently the only place the Contact feature is named in the Gaim UI, > > I believe. > > I agree, fix them and turn it on by default. I'm not even sure what > needs fixing, as they work fine for me. I found the main problem is that it shifts the position of the buddies. So if you want to see the tooltip for ELB, then move down to SE, ELB would be collapsed and your mouse won't be on SE anymore. -khc |
From: Tim R. <om...@ho...> - 2004-10-15 01:16:54
|
Sean Egan wrote: >Interface > Yes, kill the category, its name is too generic to be meaningful anyway. >Perhaps we should remove "Raise window on events" and default to no.=20 >Does anyone really use that feature? > I have a bad feeling some AIM people do and will whine without it. ><snip>"Automatically expand contacts," <snip> > I keep this one off myself, but I don't feel strongly about it. >Remove "Show buddy icons" and "Enable buddy icon animation" and >default to "yes." > I worry about performance issues with this one. >We could probably remove "Show aliases in tabs/titles" and default to >"yes" when we can depend on elipsizing support in gtknotebook > =A1Vive elipsizing! However, if we're removing the button bar too, then Get Info is burried=20 in the menu, and so there's no easy way to tell who the hell just=20 messaged you on MSN. >Remove "use multi-colored screen names in chats" default to "yes."=20 > I'm not a big fan of this, but I could live with it. >I'm pretty sure I included this in the original prefslash, but I need >someone to remind me why it was vetoed. > I think several people said over my dead body. >Can we kill "Tab placement" and choose an appropriate place to default >to (top or bottom, most likely. I use bottom, but I'd say "top" might >be better). > Or maybe it was this one that got the over my dead body responce. I see=20 no reason to remove this. The code for it is part of GtkNotebook anyway. > If GNOME duplicates the other options on this tab, we should >naturally do the same. Also, we should find out if there's a good way >to do the same things for KDE preferences. > Or maybe someone should xdg the crap out of those. >"Queue new messages when away" can probably be removed and defaulted >to "no," and replaced with a more robust, queueing system for all >messages. =20 > I had some ideas for this. But no code. >Protocols > As each protocol only has a couple prefs, it seems to me like the scarce = resource that pref slots are, are plentiful in prpl land, and thus even=20 a couple of stupid ones can use the slots. --Tim |
From: Felipe C. <fel...@gm...> - 2004-10-15 01:29:50
|
On Thu, 14 Oct 2004 20:19:46 -0500, Tim Ringenbach <om...@ho...> wro= te: > Sean Egan wrote: > >We could probably remove "Show aliases in tabs/titles" and default to > >"yes" when we can depend on elipsizing support in gtknotebook > > > =A1Vive elipsizing! > However, if we're removing the button bar too, then Get Info is burried > in the menu, and so there's no easy way to tell who the hell just > messaged you on MSN. I think a tab in the conversation window should be trated almost as a buddy, a mouseover event should print the buddy tooltip, and that problem is gone. Anyway Get Info is too damn slow in MSN. --=20 Felipe Contreras |