From: Rob F. <ga...@ro...> - 2004-10-15 15:54:36
|
>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. > > I think the window looks a little more odd without the buttons. I'd rather have them than not... >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 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. > > I need to think about this one as well.... >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. > > I'm inclined to agree with this one, too. >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. > > No way ;) >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). > > Fine by me.... >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. > > This makes sense to me. >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. > Haha! I stopped using those :P. Funny that you remember. > 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? > > >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've been thinking about this some and haven't really come up with wha tI think the best solution would be. |
From: UV <ugl...@ug...> - 2004-10-15 17:02:38
|
> >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). > > =20 > > > Fine by me.... personally, I often have dozens of tabs open and having them on the left side is much better, only 4 or 5 fit along the top, but 10 or so down the side (w/ the window size I use), at the very least I'd request that you make this an option that one can set via a plugin. --uv |
From: Ryan B. <gai...@ry...> - 2004-10-16 21:13:52
|
On Sat, 16 Oct 2004, Ethan Blanton wrote: > The only caveat with Enter-to-send is that there must be some way to get > the Enter keystroke to an input method. shift-enter already does this. (right?) combined with enter-to-send, this sounds like a good solution to me. -Ryan -- "I do not like all these things that I used to..." -Brad Wolfe |
From: Ethan B. <ebl...@cs...> - 2004-10-16 21:19:25
|
Ryan Barrett spake unto us the following wisdom: > On Sat, 16 Oct 2004, Ethan Blanton wrote: > > The only caveat with Enter-to-send is that there must be some way to get > > the Enter keystroke to an input method. >=20 > shift-enter already does this. (right?) Yes and no ... it should be as easy or easier to commit to the input method than to send the message -- you're likely to commit to the input method many times for a single message. I currently use Enter to commit to the input method, and ctrl+enter to send for this very reason. 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: Sean E. <sea...@gm...> - 2004-10-16 21:32:26
|
On Sat, 16 Oct 2004 14:14:17 -0700 (PDT), Ryan Barrett <gai...@ry...> wrote: > shift-enter already does this. (right?) Shift-enter just inserts a newline in the widget. We need a way of sending that will first tell the input methods that the character currently being inputted is finished. We're hoping that adding "Enter" as a keybinding will do that.t -s. |
From: Luke S. <lsc...@us...> - 2004-10-19 17:57:16
|
On Tue, Oct 19, 2004 at 11:26:51AM -0500, Felipe Contreras wrote: > On Sat, 16 Oct 2004 14:07:30 -0400, Luke Schierer <lsc...@us...> wrote: > > On Sat, Oct 16, 2004 at 12:08:59PM -0400, Sean Egan wrote: > > > > > > > On Sat, 16 Oct 2004 07:39:40 -0500, Felipe Contreras > > > > I think that's a very good solution, anyway I don't know why Gaim > > > > should parse all that info. > > > > > > Consistency. I like it much better this way. > > > > sean is absolutely right, consistency is why I originally asked that the > > webpage be pulled and parsed. > > Seeing that info on the Get Info dialog is nice, but it's very slow; and if > I just want to see the crucial information, like just the screen name > (in the case that buddy has an bogus alias or a weird nick), that will > not work very well for me. then the tooltip should work fine. > > The progressive Get Info dialog that Luke purposed is very neat, but i didn't propose it, but it is a good idea. i think Stu did. > it's not implemented. Even if we have that dialog, there may be some > missing information, or the webpage may change. So even if that > solution is coded, I think the link should be available too. if the webpage changes while we grab & parse it, we have issues even if we have a link, it might change afterall while the browser renders it. > > IMHO responsivenes is more important than consistency, so I think a > temporary solution to add a link that makes it much more responsible > is good, and I don't see how badly it breaks the consistency, as this > is a different thing. i really wonder if you have the right conception of the most common case. i wouldn't think you do. > > BTW, isn't a blody hell slow dialog compared to others more > inconsistent? Maybe you should try it under a 56k connection. not much we can do there anyway. you'll end up visiting that page, and suffering that slowness (if my concept of the most common use is accurate). luke > > -- > Felipe Contreras > |
From: Felipe C. <fel...@gm...> - 2004-10-19 22:26:40
|
On Tue, 19 Oct 2004 13:29:21 -0400, Luke Schierer <lsc...@us...> wrote: > On Tue, Oct 19, 2004 at 11:26:51AM -0500, Felipe Contreras wrote: > > On Sat, 16 Oct 2004 14:07:30 -0400, Luke Schierer <lsc...@us...> wrote: > > > On Sat, Oct 16, 2004 at 12:08:59PM -0400, Sean Egan wrote: > > > > > > > > > > On Sat, 16 Oct 2004 07:39:40 -0500, Felipe Contreras > > > > > I think that's a very good solution, anyway I don't know why Gaim > > > > > should parse all that info. > > > > > > > > Consistency. I like it much better this way. > > > > > > sean is absolutely right, consistency is why I originally asked that the > > > webpage be pulled and parsed. > > > > Seeing that info on the Get Info dialog is nice, but it's very slow; and if > > I just want to see the crucial information, like just the screen name > > (in the case that buddy has an bogus alias or a weird nick), that will > > not work very well for me. > > then the tooltip should work fine. Sorry, I forgot to mention I was talking about the conversation window. > > it's not implemented. Even if we have that dialog, there may be some > > missing information, or the webpage may change. So even if that > > solution is coded, I think the link should be available too. > > if the webpage changes while we grab & parse it, we have issues even if > we have a link, it might change afterall while the browser renders it. I'm not sure if I'm not getting this or I explained it wrong. I was talking about the layout of the page, which may change some day and we might have to change the parser. I'm sure they have in mind that web browsers are going to parse that page. > > IMHO responsivenes is more important than consistency, so I think a > > temporary solution to add a link that makes it much more responsible > > is good, and I don't see how badly it breaks the consistency, as this > > is a different thing. > > i really wonder if you have the right conception of the most common > case. i wouldn't think you do. I thought the common case was to get all that information through the server (the server that provides the IM service) something the MSN protocol doesn't. The MSN protocol provides things as phone numbers, screenname, nickname and buddy icon; the rest is available through the web page (http://members.msn.com/bu...@ho...) only if that person has filled their MSN profile. > > BTW, isn't a blody hell slow dialog compared to others more > > inconsistent? Maybe you should try it under a 56k connection. > > not much we can do there anyway. you'll end up visiting that page, and > suffering that slowness (if my concept of the most common use is > accurate). Yeah, *if* you want to see that extra information, which you might not want, and even might not exist, which is the most common case (profile empty). -- Felipe Contreras |