Pidgin

On Mon, Apr 26, 2004 at 01:52:09PM -0400, Sean Egan wrote:
> I'm finally looking to get rid of our useless prefs, and as this is a
> touchy subject, I'll sollicit some opinions first.
> 
> Please don't respond complaining that my opinion of sensible defaults
> and fewer preferences and stupid, you'll just be ignored.  Or worse.
> Only respond with specific insight on specific ideas listed herein:
> 
> HEREIN:
> Fonts:
> Replace 7 checkboxes, three dialog-spawning buttons, one spin button and
> two colored boxes with, like, a GtkFontSelector and a GtkIMHtml.  Or
> something.  Putting a GtkIMHtml there is definitely useful, but a
> fontselector can't pick colors or underlining, and I'd like there to be
> some way to specify the size without a face and stuff.  Ideas?

a gtkimhtml might be hard as not all protocols support the same things,
but overall i like this idea best.  as a side note, gtk's font selector
dialog also lets you pick a size, but doesn't handle color.

> 
> Message Text:
> Kill "Show graphical smileys" and put a "No Smileys" option in the
> Smiley Themes selector.

currently all our preferences are possitive. i'd like to keep it that
way. this does however mean that some things should be selected by
default for new users with no ~/.gaim/prefs.xml

> 
> Kill "Show URLs as links" default to "Yes, of course.  Why wouldn't I?"
> 

agreed.

> Replace "Ignore colors" "Ignore font faces" and "Ignore font sizes" with
> just "ignore incoming formatting".  Maybe?
> 

sounds good to me, but this one will cause complaint. 


> Buddy List:
> Kill "Show buttons as" make default "none."  I never use them and
> wouldn't miss them much.  The away message button is kinda useful
> though.  Thoughts?

i keep the buttons as text and use them fairly significantly. i don't
particularly want to see this preference going away. 

> 
> Kill "Show numbers in groups."  Default to "yes".  Are there people who
> will get violent if we force them to know how many buddies are online in
> their groups?  The preference isn't even worded well.  "Show numbers in
> groups"  What does that even mean?
> 

the people who complain about every pixel of space will be very vocal
about this, the warning levels, and the idle times. i will complain
about the warning levels because of the current gtk stupidity with
columns.  these options may however only make sense to users of the
small buddy list. 

> Kill "Show warning levels" and "Show idle times"  Default both to "yes".
> How many people would these annoy?
> 
> Conversations:
> Kill "Send URLs as links" default to "Yeah, I rarely send people links I
> don't want them to click on"
>

sounds good.
 
> Kill "Show aliases in tabs/titles"  I used to be a staunch supporter of
> no aliases in tabs, but I'll give in here and default this to "Yes,
> please."

also sounds good. 

> 
> I've been saying for a while (as have the people who ask why they can't
> get their conversations out of tabbed windows) that the tab preferences
> are braindead.  "Show IMs and chats in tabbed windows" doesn't do what
> it says at all.  I want to kill it and force people to look at the tabs
> against their will, but some people on this list care about people who
> aren't me, for some reason ;).  I think Nathan had an idea I was ok
> with... something about graying the option out when no tabs is chosen.
> 
> Can we just force everyone to use tabs anyway?  Probably not.  People
> suck.
> 

"People suck." pretty much covers this one. lets just gray it out when
not applicable. 

> Kill "Show status icons on tabs" and default to "OK."  It's useful and
> pretty, and everyone should use it.
>

i'm cool with this.
 
> IMs/Chats, these are mostly the same page, so I'll address them
> together:
> Kill "Show buttons as" default to "none."  I have to admit I really like
> the new "none" look.  I'd consider leaving a send button in, though, for
> people like my mom who actually click the Send button with the mouse
> after every message, but then again, my mom just isn't very smart.
> Opinons?
> 

if we kill the buttons entirely we have an issue with the buddy icon,
where does it go? 

> "New window width" "New window height" and "Entry field height" need to
> die.  Detect changes in size like we do with the blist and use that size
> to create new windows.
> 

about time ;-)

> Kill "Hide window on send" default to "No, that's so stupid".  ICQ does
> not have an interface we wish to emulate.
> 

good. i get a TON of invalid bug reports because of this option. 

> Kill "Show logins in window," default to "yes"

bad idea for conversations, good idea for chats. questionable how this
balences out.

> 
> Kill "Notify buddies that you are typing to them" default to "yes"?  I
> could go either way on that one.
> 

people will complain we are "spyware"  as a side note, this option is
disliked by some people enough that they go through the trouble of
finding the option in winaim's preferences (and even ars technica agrees
they are 100x worse than we are _now_)

> Kill "Old-style completion" and bury it, while defaulting to "no".
> Actually, kill "Tab-complete nicks" too and default to "yes".
> 

sounds good. 

> Kill "Show people joining in window" "Show people leaving in window" and
> "colorize screen names" defaulting all to "yes".  I can't really picture
> anyone saying "Man, Gaim's really cool, but I don't use it because it
> tells me when someone joins a chatroom"
> 

sounds good. see my comment above about show logins in window.

> Sounds:
> Kill "sounds when you log in" default to "no".  Nobody wants that.
> 

agreed.

> Away/Idle:
> Kill "sending messages removes away status" and default to "no"  AIM
> users are used to "yes," but love that they can "no."  If I want to come
> back from away, I'll just come back from away, I say.
> 

i predict this one will be controversial. i don't care. 

> Kill "Queue new messages when away" and default to "yes"?  I don't know.
> Everyone hates the "I'm away" window anyway.
> 

this one alot of people use. i see frequent bug reports about its
brokenness, what we need to do is fix it, robot101 keeps promising a
patch.

> Kill "Seconds before resending" and replace with a reasonable figure.  I
> doubt I've changed it, so 120 is probably the default.
> 

mine is set to 10 minutes, which certainly isn't the default. a useful
option for those of us who hide behind away messages.

> Kill "Send auto-response in active conversations" and default to "no"
> That's just obnoxious.

true.

> 
> So, the goal here is to get rid of a bunch of preferences, and then
> re-organize them such that the dialog is a little less weildly.  By
> killing a lot of these, we can move things around and trim the tree down
> a bit, I hope.  Let me know what you think.
> 
> Love,
> Sean.
> 

so overall i agree with you on something over half of these preferences,
not bad at all, much higher than our usual average ;-)
luke

On Mon, 2004-04-26 at 13:52 -0400, Sean Egan wrote:
> Replace 7 checkboxes, three dialog-spawning buttons, one spin button and
> two colored boxes with, like, a GtkFontSelector and a GtkIMHtml.  Or
> something.  Putting a GtkIMHtml there is definitely useful, but a
> fontselector can't pick colors or underlining, and I'd like there to be
> some way to specify the size without a face and stuff.  Ideas?

I know it's uncouth to respond to your own e-mails, but while I was in
the shower I realized that a GtkIMHtml in MSN-editable mode with a
toolbar could handle this task nicely.

-s.

Sean Egan spake unto us the following wisdom:
> I'm finally looking to get rid of our useless prefs, and as this is a
> touchy subject, I'll sollicit some opinions first.

I liked every single thing you suggested.  Go Sean.

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

I'm supposed to be working on my project, but I'll answer these, before
sean gets trigger-happy.

On Mon, 2004-04-26 at 13:52, Sean Egan wrote:
> I'm finally looking to get rid of our useless prefs, and as this is a
> touchy subject, I'll sollicit some opinions first.
>=20
> Please don't respond complaining that my opinion of sensible defaults
> and fewer preferences and stupid, you'll just be ignored.  Or worse.
> Only respond with specific insight on specific ideas listed herein:
>=20
> HEREIN:
> Fonts:
> Replace 7 checkboxes, three dialog-spawning buttons, one spin button and
> two colored boxes with, like, a GtkFontSelector and a GtkIMHtml.  Or
> something.  Putting a GtkIMHtml there is definitely useful, but a
> fontselector can't pick colors or underlining, and I'd like there to be
> some way to specify the size without a face and stuff.  Ideas?

Good.  I definitely like the idea of having a gtkimhtml window that will
demo what they've selected. =20

> Message Text:
> Kill "Show graphical smileys" and put a "No Smileys" option in the
> Smiley Themes selector.
>=20
> Kill "Show URLs as links" default to "Yes, of course.  Why wouldn't I?"
>=20
> Replace "Ignore colors" "Ignore font faces" and "Ignore font sizes" with
> just "ignore incoming formatting".  Maybe?

All of the above look good.

> Buddy List:
> Kill "Show buttons as" make default "none."  I never use them and
> wouldn't miss them much.  The away message button is kinda useful
> though.  Thoughts?

I wouldn't cry if that bar went away, but I'm sure we have people who
would.

> Kill "Show numbers in groups."  Default to "yes".  Are there people who
> will get violent if we force them to know how many buddies are online in
> their groups?  The preference isn't even worded well.  "Show numbers in
> groups"  What does that even mean?

Thats fine, although we really need to look into the corner cases that
cause those numbers to go awry.  -1/3 online is just a tad weird.

> Kill "Show warning levels" and "Show idle times"  Default both to "yes".
> How many people would these annoy?
I turn warning levels off.  I really don't care, but that's just me.

> Conversations:
> Kill "Send URLs as links" default to "Yeah, I rarely send people links I
> don't want them to click on"
Agreed.

> Kill "Show aliases in tabs/titles"  I used to be a staunch supporter of
> no aliases in tabs, but I'll give in here and default this to "Yes,
> please."
I'd keep this option.  It can be useful to keep the screennames in the
tabs/titles, especially when someone has several screennames, and you
want to know from which they're IMing you.

> I've been saying for a while (as have the people who ask why they can't
> get their conversations out of tabbed windows) that the tab preferences
> are braindead.  "Show IMs and chats in tabbed windows" doesn't do what
> it says at all.  I want to kill it and force people to look at the tabs
> against their will, but some people on this list care about people who
> aren't me, for some reason ;).  I think Nathan had an idea I was ok
> with... something about graying the option out when no tabs is chosen.
>=20
> Can we just force everyone to use tabs anyway?  Probably not.  People
> suck.

Yeah, I'd say either grey out the placement option when the other thing
is checked, or grey out the other thing when placement option is
anything but "New Window".  And rename the other thing to just "Show
Tabs"

> Kill "Show status icons on tabs" and default to "OK."  It's useful and
> pretty, and everyone should use it.
Agreed.  People have been getting pissy lately about accidentally
clicking the close button, so we can't get rid of that option

> IMs/Chats, these are mostly the same page, so I'll address them
> together:
> Kill "Show buttons as" default to "none."  I have to admit I really like
> the new "none" look.  I'd consider leaving a send button in, though, for
> people like my mom who actually click the Send button with the mouse
> after every message, but then again, my mom just isn't very smart.
> Opinons?

I'd keep the option, but I do like the new buttonless mode.  I think the
people who want the send button want the whole shebang, and the people
who are cool enough for the buttonless mode know how to work w/o a send
button.

> "New window width" "New window height" and "Entry field height" need to
> die.  Detect changes in size like we do with the blist and use that size
> to create new windows.
Amen.

> Kill "Hide window on send" default to "No, that's so stupid".  ICQ does
> not have an interface we wish to emulate.
Hallelujah.

> Kill "Show logins in window," default to "yes"
Yup.

> Kill "Notify buddies that you are typing to them" default to "yes"?  I
> could go either way on that one.
No.  This is a privacy feature.  Most people don't care that the other
side knows they're typing, some people are weirdly secretive about it.

> Kill "Old-style completion" and bury it, while defaulting to "no".
> Actually, kill "Tab-complete nicks" too and default to "yes".
Agreed.  Old-style is still slightly broken anyways.

> Kill "Show people joining in window" "Show people leaving in window" and
> "colorize screen names" defaulting all to "yes".  I can't really picture
> anyone saying "Man, Gaim's really cool, but I don't use it because it
> tells me when someone joins a chatroom"
Yes to the first two, but if you force colorized screennames on me, I
may drive to binghamton and beat you up.  Especially with those girly
pastel colors.

> Sounds:
> Kill "sounds when you log in" default to "no".  Nobody wants that.
Agreed.

> Away/Idle:
> Kill "sending messages removes away status" and default to "no"  AIM
> users are used to "yes," but love that they can "no."  If I want to come
> back from away, I'll just come back from away, I say.
Yup.

> Kill "Queue new messages when away" and default to "yes"?  I don't know.
> Everyone hates the "I'm away" window anyway.
No.  At least not until queueing doesn't suck.  Even then, no.  I don't
like queueing.

> Kill "Seconds before resending" and replace with a reasonable figure.  I
> doubt I've changed it, so 120 is probably the default.
Yeah, this is preference bloat.  Make it 5 minutes or something.

> Kill "Send auto-response in active conversations" and default to "no"
> That's just obnoxious.
Yup.

> So, the goal here is to get rid of a bunch of preferences, and then
> re-organize them such that the dialog is a little less weildly.  By
> killing a lot of these, we can move things around and trim the tree down
> a bit, I hope.  Let me know what you think.

Admiral goals.  I also think that some prefs may be candidates for a
"Advanced Preferences" plugin such as SimGuy (i think?) has started on.=20
That way sane users don't feel overwhelmed, and insane users can be
insane.

-Nathan

On Mon, 2004-04-26 at 14:12 -0400, Luke Schierer wrote: 
> > Message Text:
> > Kill "Show graphical smileys" and put a "No Smileys" option in the
> > Smiley Themes selector.
> 
> currently all our preferences are possitive. i'd like to keep it that
> way. this does however mean that some things should be selected by
> default for new users with no ~/.gaim/prefs.xml

It wouldn't be a negative pref.  A negative pref is "Don't do this."
This would be a "No Smileys" option in the smiley theme listview.  Just
like the "None" options we already have in dropdowns.

> Kill "Show warning levels" and "Show idle times" Default both to
"yes". 
> > How many people would these annoy?
> the people who complain about every pixel of space will be very vocal
> about this, the warning levels, and the idle times. i will complain
> about the warning levels because of the current gtk stupidity with
> columns.  these options may however only make sense to users of the
> small buddy list. 

And we know how much I look to please people who use Small List and
people who complain about every pixel of space ;).  I'm unfamiliar with
the column weirdness you speak of, but couldn't the "Screen real estate
agents" just resize horizontally to clip them out and let the "I hate
scrollbars" people do the complaining?

> > IMs/Chats, these are mostly the same page, so I'll address them
> > together:
> > Kill "Show buttons as" default to "none."  I have to admit I really like
> > the new "none" look.
> if we kill the buttons entirely we have an issue with the buddy icon,
> where does it go? 

Update your CVS.  It's to the left of the entry IMHtml just like in Steven Garrity's mockup.

> > Kill "Show logins in window," default to "yes"
> 
> bad idea for conversations, good idea for chats. questionable how this
> balences out.
> > Kill "Show people joining in window" "Show people leaving in window" and
> > "colorize screen names" defaulting all to "yes".  I can't really picture
> > anyone saying "Man, Gaim's really cool, but I don't use it because it
> > tells me when someone joins a chatroom"
> > 
> 
> sounds good. see my comment above about show logins in window.

Are you saying we should keep the "Show logins in window" configurable but get rid of "Show people joining chat?"
I don't see why.

<snip>
> 
> > Kill "Queue new messages when away" and default to "yes"?  I don't know.
> > Everyone hates the "I'm away" window anyway.
> No.  At least not until queueing doesn't suck.  Even then, no.  I don't
> like queueing.

oh, i missed what you said the default would be. definitally no
queueing by default. that's horrible, plus if we DO do it for chats it'd
be even more horrendous (imagine 500 queued messages), and if we don't,
it'll hinder msn development that doesn't have the chat/conversation
distinction.

> 
> > Kill "Seconds before resending" and replace with a reasonable figure.  I
> > doubt I've changed it, so 120 is probably the default.
> Yeah, this is preference bloat.  Make it 5 minutes or something.
> 

5 minutes is reasonable, i could live with that. ask kingant though, he
hides behind away messages ALL THE TIME.

> > Kill "Send auto-response in active conversations" and default to "no"
> > That's just obnoxious.
> Yup.
> 
> > So, the goal here is to get rid of a bunch of preferences, and then
> > re-organize them such that the dialog is a little less weildly.  By
> > killing a lot of these, we can move things around and trim the tree down
> > a bit, I hope.  Let me know what you think.
> 
> Admiral goals.  I also think that some prefs may be candidates for a
> "Advanced Preferences" plugin such as SimGuy (i think?) has started on. 
> That way sane users don't feel overwhelmed, and insane users can be
> insane.
> 
> -Nathan


Nathan raises a good point here, SimGuy's advanced preferences plugin
might be worth looking at for inclusion.

luke

On Mon, Apr 26, 2004 at 02:39:40PM -0400, Sean Egan wrote:
> On Mon, 2004-04-26 at 14:12 -0400, Luke Schierer wrote: 
> > > Message Text:
> > > Kill "Show graphical smileys" and put a "No Smileys" option in the
> > > Smiley Themes selector.
> > 
> > currently all our preferences are possitive. i'd like to keep it that
> > way. this does however mean that some things should be selected by
> > default for new users with no ~/.gaim/prefs.xml
> 
> It wouldn't be a negative pref.  A negative pref is "Don't do this."
> This would be a "No Smileys" option in the smiley theme listview.  Just
> like the "None" options we already have in dropdowns.
> 
> > Kill "Show warning levels" and "Show idle times" Default both to
> "yes". 
> > > How many people would these annoy?
> > the people who complain about every pixel of space will be very vocal
> > about this, the warning levels, and the idle times. i will complain
> > about the warning levels because of the current gtk stupidity with
> > columns.  these options may however only make sense to users of the
> > small buddy list. 
> 
> And we know how much I look to please people who use Small List and
> people who complain about every pixel of space ;).  I'm unfamiliar with
> the column weirdness you speak of, but couldn't the "Screen real estate
> agents" just resize horizontally to clip them out and let the "I hate
> scrollbars" people do the complaining?

we can get rid of this option if we swap the ordering of the idle times
and warning levels in the small display. the column wierdness i'm
refering to is how the column widths are (for good reasons) as wide as
the widest entry which means that the group names+numbers push the
warning levels over push the idle times over, and the idle times are far
more useful than the warning levels and its a pain to horizontally
scroll to see them. what we did before gtk2 was just append text to the
screenname with spaces and tabs so that the warning levels and idle
times weren't in a consist visible offset but varied with the size of
the screenname. this was deemed a hack when moving to gtk2 and replaced
with each having its own column.

> 
> > > IMs/Chats, these are mostly the same page, so I'll address them
> > > together:
> > > Kill "Show buttons as" default to "none."  I have to admit I really like
> > > the new "none" look.
> > if we kill the buttons entirely we have an issue with the buddy icon,
> > where does it go? 
> 
> Update your CVS.  It's to the left of the entry IMHtml just like in Steven Garrity's mockup.
> 

okay, i must have missed this update.

> > > Kill "Show logins in window," default to "yes"
> > 
> > bad idea for conversations, good idea for chats. questionable how this
> > balences out.
> > > Kill "Show people joining in window" "Show people leaving in window" and
> > > "colorize screen names" defaulting all to "yes".  I can't really picture
> > > anyone saying "Man, Gaim's really cool, but I don't use it because it
> > > tells me when someone joins a chatroom"
> > > 
> > 
> > sounds good. see my comment above about show logins in window.
> 
> Are you saying we should keep the "Show logins in window" configurable but get rid of "Show people joining chat?"
> I don't see why.
> 

i'm saying "show logins in window" and "show join/parts" are the same
option, that they should be merged, and they should be configurable.  it
does not however need to be visible, lets let it only be editable by
simguy's plugin ;-)

luke

On Mon, 26 Apr 2004, Sean Egan wrote:

> I'm finally looking to get rid of our useless prefs, and as this is a
> touchy subject, I'll sollicit some opinions first.

awesome.  i'm very much in favor of this initiative.  i've stripped out 
the ones that i agree with and have no comment about.

> Replace "Ignore colors" "Ignore font faces" and "Ignore font sizes" with
> just "ignore incoming formatting".  Maybe?

yes, this sounds sensible.  "Ignore formatting on incoming messages"?  
that sounds a bit verbose, but it's clearer.

> Buddy List:
> Kill "Show buttons as" make default "none."  I never use them and
> wouldn't miss them much.  The away message button is kinda useful
> though.  Thoughts?

i feel the same way personally, but i could see why a significant number 
of people could want the buttons - esp the away message button.

> Kill "Show numbers in groups."  Default to "yes".  Are there people who
> will get violent if we force them to know how many buddies are online in
> their groups?  The preference isn't even worded well.  "Show numbers in
> groups"  What does that even mean?

yeah, i'd say ditch it.  the first time i read it, i thought it meant 
that if someone sent you a number like "123456789", gaim would display 
it as "123,456,789".

> Kill "Show warning levels" and "Show idle times"  Default both to "yes".
> How many people would these annoy?

that would annoy me, at least.  i leave them off.  if i want to know 
this info, i mouse over the buddy and use the popup.  i like having the 
buddy list itself take up as little space as possible, and shrinking the 
list width and having scrollbars (to 'hide' the levels and times) looks 
ugly.

> I've been saying for a while (as have the people who ask why they can't
> get their conversations out of tabbed windows) that the tab preferences
> are braindead.  "Show IMs and chats in tabbed windows" doesn't do what
> it says at all.  I want to kill it and force people to look at the tabs
> against their will, but some people on this list care about people who
> aren't me, for some reason ;).  I think Nathan had an idea I was ok
> with... something about graying the option out when no tabs is chosen.
> 
> Can we just force everyone to use tabs anyway?  Probably not.  People
> suck.

agreed - the tab prefs are really nonintuitive.  perhaps something like 
this:

Conversations
  Tab Placement: [Top/Bottom/Left/Right]
  [x] Show IMs in tabbed windows
  [x] Show chats in tabbed windows
      [x] Show IMs and chats in the same tabbed window (note 1)
  [x] Show formatting toolbar
  [x] Show close button on tabs
(other options presumably nixed)

note 1: make this option sensitive only if the two preceeding options 
are both selected.  whether or not it should be indented farther is 
debatable.

this presupposes that the "Placement" option menu up top is removed 
entirely.  "Last created window" and "New window" are covered by the two 
checkboxes in "Tab Options".  would it really be a big deal to ditch "By 
account" and "By group"?  kinda iffy on that, as i can see why some 
people might like that (though i don't use it myself).

i think the "Conversations" and "Tab Options" headings are unnecessary.  
all of the options are relevant to conversations (or rather, the 
conversation window itself).

> IMs/Chats, these are mostly the same page, so I'll address them
> together:
> Kill "Show buttons as" default to "none."  I have to admit I really like
> the new "none" look.  I'd consider leaving a send button in, though, for
> people like my mom who actually click the Send button with the mouse
> after every message, but then again, my mom just isn't very smart.
> Opinons?

i like the new "none" look as well.  out of the buttons there:
- warn: presumably not used often
- block: presumably used even less often than warn
- add: used only once, in general.  would be useful to have when a new 
user IMs you
- remove: presumably used only once again, and something you can do 
elsewhere.  i would imagine that you'd usually remove people directly 
from the buddy list, and that it's pretty rare to just have a 
conversation with someone and decide to remove them.
- info:  this is probably the only useful button, but, again, probably 
not used all that often.
- send: redundant.  on the other hand, sometimes when i copy and paste a 
URL to send to someone (using the mouse), it's more convenient to click 
send (since my hand is already on the mouse) than to hit enter.  on the 
other hand, usually after clicking send, my hands go back to the 
keyboard to continue typing messages.  so i still think it's redundant.

my verdict: minimalistic view is good.

> Kill "Notify buddies that you are typing to them" default to "yes"?  I
> could go either way on that one.

hmm.  i think it's pretty stupid, but some people i know like it to be 
turned off.  kinda a privacy thing i guess.  i really don't know.  i 
think if you're actually talking to someone, it's pretty lame to feel 
like you have to hide from them when you're typing.

> Away/Idle:
> Kill "sending messages removes away status" and default to "no"  AIM
> users are used to "yes," but love that they can "no."  If I want to come
> back from away, I'll just come back from away, I say.

heartily agree - i can't think of one person who i've converted to gaim 
from winaim who hasn't thought this is a really nifty feature.  perhaps 
it's confusing at first, but since it's set to 'no' by default (right?), 
they'll get the initial confusing whether it's a pref or not.

> Kill "Queue new messages when away" and default to "yes"?  I don't know.
> Everyone hates the "I'm away" window anyway.

as long as you can retrieve all the queued messages and still remain 
away, that's fine.  how does this impact message send/receive if i'm 
away but sitting at the machine?  sometimes i like to carry on 
conversations with certain people while i'm still away.  if those 
incoming messages get queued, i wouldn't be happy at all.

> Kill "Send auto-response in active conversations" and default to "no"
> That's just obnoxious.

how do you define an "active conversation"?  if i'm away and yet at the 
machine, i want the autoresponse to be sent to pretty much everyone, 
whether or not they have a window/tab open.  i of course wouldn't want 
to send my autoresponse to someone i'm actively typing to, but i may be 
talking to a >1 subset of the people with whom i have tabs open.  if i 
have 5 tabs open, i'm away, and i'm talking to 2 of those tabs, how are 
those 2 tabs considered "active" and the other 3 "inactive"?

overall, the plan sounds great.  hopefully my suggestions are useful...

	-brian

I'm particularly unsettled by such behavior.  
		
  %j. 

I apologize for these email. 

On Mon, 26 Apr 2004 14:13:10 -0400
Sean Egan <sean.egan@...> wrote:

> I know it's uncouth to respond to your own e-mails, but while I was in
> the shower I realized that a GtkIMHtml in MSN-editable mode with a
> toolbar could handle this task nicely.
> 
> -s.

On Mon, 2004-04-26 at 15:14 -0400, Brian J. Tarricone wrote:

> how do you define an "active conversation"?

It's based on the last time you sent a message to that person.  I think
if you're only sending auto-responses in non-active conversations, it
will only send if you haven't written a message to that person in the
past two minutes.

-s.

On Mon, 2004-04-26 at 13:52, Sean Egan wrote:
> Can we just force everyone to use tabs anyway?  Probably not.  People
> suck.

No complaint here if we could still drag tabs out to be in single
windows. I've used this a few times to organize two windows with
different tabbed conversations.

> Away/Idle:
> Kill "sending messages removes away status" and default to "no"  AIM
> users are used to "yes," but love that they can "no."  If I want to come
> back from away, I'll just come back from away, I say.
> 
> Kill "Queue new messages when away" and default to "yes"?  I don't know.
> Everyone hates the "I'm away" window anyway.

These two defaults seem in conflict with each other. If don't remove the
away message on send, then clearly one wants to converse while away
(using away messages more as a presence like in Jabber rather than an
away like in AIM). If one is conversing with people, then why not
receive new messages?

> So, the goal here is to get rid of a bunch of preferences, and then
> re-organize them such that the dialog is a little less weildly.  By
> killing a lot of these, we can move things around and trim the tree down
> a bit, I hope.  Let me know what you think.

My experience with messaging clients has shown me that at some point
somebody decided their preferences should have a learning curve about on
par with a college Constructing Proofs class. It would be great to see
somebody break from this.
-- 
Andrew Sayman <gtg842q@...>

On Mon, Apr 26, 2004 at 01:52:09PM -0400, Sean Egan wrote:
> I'm finally looking to get rid of our useless prefs, and as this is a
> touchy subject, I'll sollicit some opinions first.
>=20
> Please don't respond complaining that my opinion of sensible defaults
> and fewer preferences and stupid, you'll just be ignored.  Or worse.
> Only respond with specific insight on specific ideas listed herein:

Ah, so glad we're doing this :) I agree with most of these, and I'll
make some specific comments below.

> HEREIN:
> Fonts:
> Replace 7 checkboxes, three dialog-spawning buttons, one spin button and
> two colored boxes with, like, a GtkFontSelector and a GtkIMHtml.  Or
> something.  Putting a GtkIMHtml there is definitely useful, but a
> fontselector can't pick colors or underlining, and I'd like there to be
> some way to specify the size without a face and stuff.  Ideas?

Great :) The MSN-type mode that you mentioned earlier sounds good.

> Message Text:
> Kill "Show graphical smileys" and put a "No Smileys" option in the
> Smiley Themes selector.

Agreed.

> Kill "Show URLs as links" default to "Yes, of course.  Why wouldn't I?"

Agreed.

> Replace "Ignore colors" "Ignore font faces" and "Ignore font sizes" with
> just "ignore incoming formatting".  Maybe?

I personaly use Ignore font sizes and leave the other two on.
Sometimes I'll turn on Ignore font faces as well. The reason is, I
have several friends who have their font set to something weird and
their text really large. I still do want to see the colors, however.

I feel that with all the other pref removals that'll be going on,
keeping these three shouldn't bloat things up much. I'm not religious
about this, though.

> Buddy List:
> Kill "Show buttons as" make default "none."  I never use them and
> wouldn't miss them much.  The away message button is kinda useful
> though.  Thoughts?

The away message button is useful, though with the status rewrite,
there may be other statusy things that aren't away messages. I want to
come up with a better UI for all of that, but I still haven't decided
on anything I like.

I don't use the rest of the buttons. I'm not opposed to this, though I
think others will be.

> Kill "Show numbers in groups."  Default to "yes".  Are there people who
> will get violent if we force them to know how many buddies are online in
> their groups?  The preference isn't even worded well.  "Show numbers in
> groups"  What does that even mean?

Very good.

> Kill "Show warning levels" and "Show idle times"  Default both to "yes".
> How many people would these annoy?

Some may want to keep this pref, and some posted their reasons. I
personally don't care either way.

> Conversations:
> Kill "Send URLs as links" default to "Yeah, I rarely send people links I
> don't want them to click on"

Yes, full agreement.

> Kill "Show aliases in tabs/titles"  I used to be a staunch supporter of
> no aliases in tabs, but I'll give in here and default this to "Yes,
> please."

I think this one will get some complaints.

> I've been saying for a while (as have the people who ask why they can't
> get their conversations out of tabbed windows) that the tab preferences
> are braindead.  "Show IMs and chats in tabbed windows" doesn't do what
> it says at all.  I want to kill it and force people to look at the tabs
> against their will, but some people on this list care about people who
> aren't me, for some reason ;).  I think Nathan had an idea I was ok
> with... something about graying the option out when no tabs is chosen.
>=20
> Can we just force everyone to use tabs anyway?  Probably not.  People
> suck.

Let's just grey it.

I should mention here that the conv rewrite has already begun, and
though it has not progressed all that far yet, once of the more
immediate plans was to remove a lot of these prefs. So, we can either
do that in gaim now (which will bring me into conflict hell, which I'd
rather avoid, but I can handle it) or we can wait for all the pref
work in conversations to be done in the conv rewrite. I'd personally
vote for the latter, as it's one set of changes at once, instead of
twice over a couple of releases.

> Kill "Show status icons on tabs" and default to "OK."  It's useful and
> pretty, and everyone should use it.

Yep, though we should keep the option for the close button.

> IMs/Chats, these are mostly the same page, so I'll address them
> together:
> Kill "Show buttons as" default to "none."  I have to admit I really like
> the new "none" look.  I'd consider leaving a send button in, though, for
> people like my mom who actually click the Send button with the mouse
> after every message, but then again, my mom just isn't very smart.
> Opinons?

The distinction between IMs and Chats in the new conv rewrite will
largely go away. Any and all options should for the most part be
merged.

I am redesigning the conversation window, and one of the things I
wanted to add was a bar at the top, above the conversation imhtml,
that had the buddy icon, username, the away state or whatever text
that you would otherwise see in the buddy list, and then the buttons
that are currently on the bottom of the window moved to the right of
the name and status text. The Send button would be moved to the right
of the input box.

With these changes, the conversation window wouldn't end up any larger
than the current one. Things would just be shuffled.

I feel this provides useful information that you would otherwise have
to go to the buddy list for. I have considered removing most of the
buttons, though. The Warn button is a very uncommon function, and can
be accessed through the menu. Block and Add/Remove are probably also
good candidates for the menu. I would like to keep Get Info, but it'd
end up being alone by itself, so I may just remove all of them, or
keep the preference for them. That's something we'll have to decide
on.

> "New window width" "New window height" and "Entry field height" need to
> die.  Detect changes in size like we do with the blist and use that size
> to create new windows.

Good :)

> Kill "Hide window on send" default to "No, that's so stupid".  ICQ does
> not have an interface we wish to emulate.

Agreed.

> Kill "Show logins in window," default to "yes"

I can see some people not wanting that for IMs. I don't know why they
wouldn't, though.

> Kill "Notify buddies that you are typing to them" default to "yes"?  I
> could go either way on that one.

I'd really like to keep this. There are times when I find this very
useful.

> Kill "Old-style completion" and bury it, while defaulting to "no".
> Actually, kill "Tab-complete nicks" too and default to "yes".

Good.

> Kill "Show people joining in window" "Show people leaving in window" and
> "colorize screen names" defaulting all to "yes".  I can't really picture
> anyone saying "Man, Gaim's really cool, but I don't use it because it
> tells me when someone joins a chatroom"

Let's keep the "colorize screen names" pref. I hope nobody uses the
other two.

> Sounds:
> Kill "sounds when you log in" default to "no".  Nobody wants that.

Good.

> Away/Idle:
> Kill "sending messages removes away status" and default to "no"  AIM
> users are used to "yes," but love that they can "no."  If I want to come
> back from away, I'll just come back from away, I say.

I mostly agree, though I'd still prefer to keep this option.

> Kill "Queue new messages when away" and default to "yes"?  I don't know.
> Everyone hates the "I'm away" window anyway.

In my status rewrite, the "I'm away" window is going away. I just need
to come up with a better UI for it that I actually like, as I
mentioned above.

I personally don't queue messages, so I wouldn't want to see this go
away and default to yes.

> Kill "Seconds before resending" and replace with a reasonable figure.  I
> doubt I've changed it, so 120 is probably the default.

This is a pref that only hard-core people would care about. They can
just use an advanced pref editor like SimGuy's or edit prefs.xml.

> Kill "Send auto-response in active conversations" and default to "no"
> That's just obnoxious.

Agreed.

> So, the goal here is to get rid of a bunch of preferences, and then
> re-organize them such that the dialog is a little less weildly.  By
> killing a lot of these, we can move things around and trim the tree down
> a bit, I hope.  Let me know what you think.

For the most part, I'm very happy with this decision, except for the
points I noted above.

I will tackle some of these issues in the status and conv rewrites,
which, if all goes well, won't take more than a couple more releases
to finish. Let me know if we're going to end up doing those now, or if
I should handle them.

Christian

--=20
Christian Hammond         <>  The GNUpdate Project
chipx86@...      <>  http://www.gnupdate.org/
   Don't anthropomorphize computers. They hate that.

On Mon, 26 Apr 2004, Sean Egan wrote:

> Fonts:
> Replace 7 checkboxes, three dialog-spawning buttons, one spin button and
> two colored boxes with, like, a GtkFontSelector and a GtkIMHtml.  Or
> something.  Putting a GtkIMHtml there is definitely useful, but a
> fontselector can't pick colors or underlining, and I'd like there to be
> some way to specify the size without a face and stuff.  Ideas?

I made a patch which got rid of the Font Size pref but was then informed
that the problem with that is that we use html font sizes (1-7) instead
of the pixel sizes that the GTK+ font selector uses. I very much like
the idea, just wanted to make sure everyone was aware of this

> Kill "Show URLs as links" default to "Yes, of course.  Why wouldn't I?"
>
> Replace "Ignore colors" "Ignore font faces" and "Ignore font sizes" with
> just "ignore incoming formatting".  Maybe?

I like ignoring font sizes but don't mind seeing faces or colors, so I
don't think this one works so well.

> Kill "Show warning levels" and "Show idle times"  Default both to "yes".
> How many people would these annoy?

I'm one of the small list, pixel saving people so I don't like this at
all. I also just don't care about warning levels at all.

> "New window width" "New window height" and "Entry field height" need to
> die.  Detect changes in size like we do with the blist and use that size
> to create new windows.

I think this would be fine as long as there is a method to lock the size
against stupid or accidental changes. That is I would fully agree that
using the size of the window as it's been resized to is a Good Thing(tm)
but I also know that on occasion I change the size of an IM window for
one reason or another and don't want it to stay changed to that. So if
this is going to happen make a (probably best hidden) pref to lock the
sizes.

> Kill "Show logins in window," default to "yes"

Like Luke said this doesn't make much sense for conversations. I have
more than once left a conversation window open to someone to keep
ready reference to a link or some other piece of information, but I
really don't need to see how many times since then they logged in or
out. If I need to know their status I'll look at the status icon in the
tab.

> Kill "Show people joining in window" "Show people leaving in window" and
> "colorize screen names" defaulting all to "yes".  I can't really picture
> anyone saying "Man, Gaim's really cool, but I don't use it because it
> tells me when someone joins a chatroom"

I agree with Nathan on this one, don't make me use the colors. (I don't
like colorized names, this isn't just an issue with the current colors.)

> Kill "Queue new messages when away" and default to "yes"?  I don't know.
> Everyone hates the "I'm away" window anyway.

I like the I'm Away window, but that's largely a result of the way I
have my desktop set up and my window manager choice. But I haven't used
queueing messages for a long time and would rather not have to.

> Kill "Seconds before resending" and replace with a reasonable figure.  I
> doubt I've changed it, so 120 is probably the default.

I think a pref for this makes sense, people have widely differing
opinions as to how long that should be.

Anything I didn't respond to, I either agreed with or didn't have
anything to add to.

	-Etan

On Mon, 26 Apr 2004, Sean Egan wrote:

> HEREIN:
> Fonts:
> Replace 7 checkboxes, three dialog-spawning buttons, one spin button and
> two colored boxes with, like, a GtkFontSelector and a GtkIMHtml.  Or
> something.  Putting a GtkIMHtml there is definitely useful, but a
> fontselector can't pick colors or underlining, and I'd like there to be
> some way to specify the size without a face and stuff.  Ideas?

Yes. And then move it into 'Message Text' and kill 'Fonts' because that's
what you're affecting anyway. It (I think) only affects the messages sent
and does not affect the buddy list or other dialogs.

> Message Text:
> Kill "Show graphical smileys" and put a "No Smileys" option in the
> Smiley Themes selector.

Can we make it more simple than that and simply just add a 'Text Smileys'
theme? I don't foresee picking a smiley theme and then checking 'no
smileys' or 'show graphical smileys'. I suppose we could also then add a
'Stoic' theme that simply strips off smileys too.....

> Replace "Ignore colors" "Ignore font faces" and "Ignore font sizes" with
> just "ignore incoming formatting".  Maybe?

I wouldn't be seriously put out by this, however I have a couple friends
that have very obnoxious colors and I enjoy being able to simply just
strip the colors off. A suggestion that might work better for me (I don't
know how often folks would use this) would be to implement your suggestion
of 'Ignore incoming formatting' or simply 'Ignore formatting' and possibly
also be able to toggle formatting on a buddy-by-buddy basis. I know you're
trying to keep down the complexity and pain-in-the-assness that is
otherwise known as preferences; that's something I'd like to see. I'd be
happy to sit down and write a patch to do so if that is something you'd be
willing to accept.

> Buddy List:
> Kill "Show buttons as" make default "none."  I never use them and
> wouldn't miss them much.  The away message button is kinda useful
> though.  Thoughts?

Why not move the 'away' menu from 'Tools' to a top-level menu item
inbetween 'Tools' and 'Help'? At that point there would be one place to
mark yourself away rather than two in the same interface.

On a similar note, I was just looking at the tools menu. Would it make more
sense to move 'Buddy Pounces' to 'Buddies' since it is a buddy features?

> Conversations:
> I've been saying for a while (as have the people who ask why they can't
> get their conversations out of tabbed windows) that the tab preferences
> are braindead.  "Show IMs and chats in tabbed windows" doesn't do what
> it says at all.  I want to kill it and force people to look at the tabs
> against their will, but some people on this list care about people who
> aren't me, for some reason ;).  I think Nathan had an idea I was ok
> with... something about graying the option out when no tabs is chosen.
>
> Can we just force everyone to use tabs anyway?  Probably not.  People
> suck.

I guess I just don't understand this paragraph. I love the tabs and
haven't used this preference in a long time. Does the preference not work?
I think one potential simplification to this is in the Tab Placement
dropdown to add 'No Tabs' (and possibly re-label the widget as 'Show Tabs:
' and values such as 'At Top', 'At bottom', etc.)  Then the 'show
conversations in tabs' checkbox goes away and we get that real estate
back.

One "feature" with tabs that I just tried but was unsuccessful at that I
would possibly like to see is either to have a menu option to tear off a tab
as a new window, re-order tabs (a la mozilla), etc. That could be one way to
also get rid of 'Show IMs and chats in same tabbed window'.....if you can
tear off tabs or drag them into another window that preference isn't needed.
Again, if this is something that would be appreciated, I'll put forth work to
try to make a patch for it.

> IMs/Chats, these are mostly the same page, so I'll address them
> together:
> Kill "Show buttons as" default to "none."  I have to admit I really like
> the new "none" look.  I'd consider leaving a send button in, though, for
> people like my mom who actually click the Send button with the mouse
> after every message, but then again, my mom just isn't very smart.
> Opinons?

I agree (not about your mom though ;)). I'm a keyboard guy and I don't
ever use the buttons and it's nice to throw them away. I'd also be ok with
the idea of simply just leaving a single 'send' button at the bottom. I'm of
the opinion, however, that people can (and imo should) just get used to
the idea of type type type type <whack enter to send>. I think defaulting
the interface to have a 'send' button may make people WANT to use it
rather than just realizing they can whack enter (which is most likely what
is happening with your mom)


> "New window width" "New window height" and "Entry field height" need to
> die.  Detect changes in size like we do with the blist and use that size
> to create new windows.
Ugh. Yes please.

> Kill "Notify buddies that you are typing to them" default to "yes"?  I
> could go either way on that one.
I know of people that use it both ways. I think this feature should be
kept.


I have some ideas for cleaning up/reorganizing some of the menus. I think
it may be better for me to play with it and create a patch/viewables for
people to see (and play with the changes).

Thanks for your hard work in this guys,
--dw

On Mon, 26 Apr 2004, Andrew Sayman wrote:

> On Mon, 2004-04-26 at 13:52, Sean Egan wrote:
> > Can we just force everyone to use tabs anyway?  Probably not.  People
> > suck.
>
> No complaint here if we could still drag tabs out to be in single
> windows. I've used this a few times to organize two windows with
> different tabbed conversations.
>
> > Away/Idle:
> > Kill "sending messages removes away status" and default to "no"  AIM
> > users are used to "yes," but love that they can "no."  If I want to come
> > back from away, I'll just come back from away, I say.
> >
> > Kill "Queue new messages when away" and default to "yes"?  I don't know.
> > Everyone hates the "I'm away" window anyway.
>
> These two defaults seem in conflict with each other. If don't remove the
> away message on send, then clearly one wants to converse while away
> (using away messages more as a presence like in Jabber rather than an
> away like in AIM). If one is conversing with people, then why not
> receive new messages?

Actually, I think it's just the labelling that's in conflict. IIRC, this
should only queue new conversations, not new messages. But since I always
am lazy and have 'Sending messages removes away status' turned on, so I
never run into queuing and therefore may not have a clue as to what I'm
talking about. :)

On Mon, 2004-04-26 at 18:18, Etan Reisner wrote:
> Kill "Show logins in window," default to "yes"
> 
> Like Luke said this doesn't make much sense for conversations. I have
> more than once left a conversation window open to someone to keep
> ready reference to a link or some other piece of information, but I
> really don't need to see how many times since then they logged in or
> out. If I need to know their status I'll look at the status icon in  
> the tab.
> 
Showing logins in the window makes a lot of sense for conversations
where the online/offline state doesn't determine whether you can message
somebody or not. When talking to a person that suddenly logs off, if
you're not alerted to it then you could send a bunch of messages
thinking they're afk when they actually logged off. 

-- 
Andrew Sayman <gtg842q@...>

On Mon, 2004-04-26 at 16:07 -0700, Dave West wrote:
> Can we make it more simple than that and simply just add a 'Text Smileys'
> theme? I don't foresee picking a smiley theme and then checking 'no
> smileys' or 'show graphical smileys'. I suppose we could also then add a
> 'Stoic' theme that simply strips off smileys too.....

That's the idea.  The "No smileys" option would be in the list of
available themes.  I'll probably just do it as another included smiley
theme without any smileys in it.

> The away message button is kinda useful
> > though.  Thoughts?
> Why not move the 'away' menu from 'Tools' to a top-level menu item
> inbetween 'Tools' and 'Help'? At that point there would be one place to
> mark yourself away rather than two in the same interface.

I really like this idea.

> One "feature" with tabs that I just tried but was unsuccessful at that I
> would possibly like to see is either to have a menu option to tear off a tab
> as a new window, re-order tabs (a la mozilla), etc. That could be one way to
> also get rid of 'Show IMs and chats in same tabbed window'.....if you can
> tear off tabs or drag them into another window that preference isn't needed.
> Again, if this is something that would be appreciated, I'll put forth work to
> try to make a patch for it.

I guess you've never tried dragging a tab out of a window, or into
another window?

> I have some ideas for cleaning up/reorganizing some of the menus. I think
> it may be better for me to play with it and create a patch/viewables for
> people to see (and play with the changes).

Go for it.

> --dw

-s.

On Mon, 26 Apr 2004, Sean Egan wrote:
> > One "feature" with tabs that I just tried but was unsuccessful at that I
> > would possibly like to see is either to have a menu option to tear off a tab
> > as a new window, re-order tabs (a la mozilla), etc. That could be one way to
> > also get rid of 'Show IMs and chats in same tabbed window'.....if you can
> > tear off tabs or drag them into another window that preference isn't needed.
> > Again, if this is something that would be appreciated, I'll put forth work to
> > try to make a patch for it.
>
> I guess you've never tried dragging a tab out of a window, or into
> another window?

Actually I did....I guess my attempt was brief and I didn't realize that
it was actually doing something when I dragged a tab out. You guys work
quick ;)

Thanks for the pointer. :)

Sean Egan spake unto us the following wisdom:
> I'm finally looking to get rid of our useless prefs, and as this is a
> touchy subject, I'll sollicit some opinions first.
>=20
> Please don't respond complaining that my opinion of sensible defaults
> and fewer preferences and stupid, you'll just be ignored.  Or worse.
> Only respond with specific insight on specific ideas listed herein:

Since  a  lot  of  people seem to be making comments to the effect of "I
don't use this, but some people won't like it if it's removed", I  think
I  should make a statement about that claim.  It's worthless.  Some peo-
ple use Kopete instead of Gaim, but when a new feature comes up we don't
say  "I  think  that  feature  is OK, but some people use Kopete so they
wouldn't use it, and maybe it's not necessary."

In fact, I think there are several features in Sean's list for which the
_only_ arguments in favor of keeping them are "some people like it".

This  does  mean  that  we might remove some features that people ask to
have back ... but I'm sure you can all remember that  there  were  users
for  quite  some  time who refused to use 0.60+ because they didn't like
Gtk2.  I think it will become apparent pretty rapidly if we've removed a
feature which really should stay -- and then we can put it back in.

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

On Mon, 26 Apr 2004, Andrew Sayman wrote:

> On Mon, 2004-04-26 at 18:18, Etan Reisner wrote:
> > Kill "Show logins in window," default to "yes"
> >
> > Like Luke said this doesn't make much sense for conversations. I have
> > more than once left a conversation window open to someone to keep
> > ready reference to a link or some other piece of information, but I
> > really don't need to see how many times since then they logged in or
> > out. If I need to know their status I'll look at the status icon in
> > the tab.
> >
> Showing logins in the window makes a lot of sense for conversations
> where the online/offline state doesn't determine whether you can message
> somebody or not. When talking to a person that suddenly logs off, if
> you're not alerted to it then you could send a bunch of messages
> thinking they're afk when they actually logged off.

If you want to know whether the person is afk or logged off you can also
check the status icon in the tab. I realize that some people like
knowing when their buddies log in and log out, which is why lots of
people asked for the system log back when it wasn't there (something
I've *never* used by the way). My point was exactly that some people
like knowing and some people don't which is why the option should stay.

	-Etan

Good stuff all around. I'm so encouraged by this thread that I've 
written an article about it for my weblog (still being edited - not up yet).


Sean Egan wrote:
> On Mon, 2004-04-26 at 16:07 -0700, Dave West wrote:
> 
>>Why not move the 'away' menu from 'Tools' to a top-level menu item
>>inbetween 'Tools' and 'Help'? At that point there would be one place to
>>mark yourself away rather than two in the same interface.
> 
> I really like this idea.

That would be an improvement. I would also like to see an easier path to 
setting all accounts to Away, as I suspect this is the most common 
action (that might have been discussed elsewhere on the list).

Even better, I think, would be to follow the Gossip method of setting 
status with a always-visible menu at the bottom of the contact list: 
http://actsofvolition.com/images/screenshots/gossip_status.png

I would also be interested in seeing "Offline" considered a "status", 
meaning one flydown could let you choose between "Available", "Busy", 
"Away", and "Offline". Choosing anything other than "Offline" could 
connect you. Of course, I'm over simplifying, as Gossip is only a 
one-protocol client.

The Gossip-style status flydown also serves do show you your current status.

Thanks for the great work,
Steven Garrity

In the recent thread on 'Freakin" annoying tooltips' Ethan Blanton
mentioned (on 2004-03-14) guidelines that the developers try to follow.
I had a quick look for where these are published but had no obvious
hits.  Are these guidelines available to the masses?

I see the proposed changes as attempts to address different underlying
problems that I will now attempt to enumerate:

    1.  Reduce number of code paths for ease of
        development/testing/maintenance.

        I don't develop Gaim so I don't know what kind of a problem this
        is.  I hope all of your nagging users (with their precious
        preferences) are not causing too much grief.

    2.  Make it easier to find the preference you require.

        My opinion on this is that really most people should not have to
        look in the preferences pane for anything.  The vast majority of
        preferences apply to some other aspect of the program and they
        might like to be able to directly manipulate it.  I love context
        menus and "remember this" check boxes because it lets you change
        the thing you want at the time you realise it is wrong.
        
        If taken to the extreme (never a good idea, I suppose) then the
        preferences pane is only for a few of the users and the
        developers.  This means it can have as many options as you want
        and needn't be organised from the point of view of the user.
        Something like the gconf-editor, built from XML schema?
        
    3.  Clarifying the preferences pane.

        Some of the options are misleading and/or in the wrong place and
        should be fixed.
        
    4.  Targeting the intended user base (euphemism for having some 
        balls).

        Some people like to use write(1) for instant messaging and will
        use telnet(1) to chat on IRC.  Such people might not want colour
        used to help them follow chats and might not appreciate being
        able to click on URIs to get the resource displayed in their
        favourite browser.  Such people should not hinder the rest of
        us.
        
    5.  Clear away options people don't use.

        As long as the correct default is chosen these should be moved
        to a more obscure location like gaim-extprefs.sf.net.  I would
        think twice before simultaneously changing the default and
        removing the user interface for the option as that is likely to
        annoy people.  I will defer to those who are more involved to
        decide which preferences are actually ever changed from their
        defaults in the real world.

On Mon, 2004-04-26 at 13:52 -0400, Sean Egan wrote:
> I'm finally looking to get rid of our useless prefs, and as this is a
> touchy subject, I'll sollicit some opinions first.

Nothing you have said would annoy me but I am not everybody.  Others
would probably appreciate it if real options moved out of gaim.sf.net
get into gaim-extprefs.sf.net before the the changes are released.

> Please don't respond complaining that my opinion of sensible defaults
> and fewer preferences and stupid, you'll just be ignored.  Or worse.
> Only respond with specific insight on specific ideas listed herein:
> 
> HEREIN:
> Fonts:
> Replace 7 checkboxes, three dialog-spawning buttons, one spin button and
> two colored boxes with, like, a GtkFontSelelector and a GtkIMHtml.  Or
> something.  Putting a GtkIMHtml there is definitely useful, but a
> fontselector can't pick colors or underlining, and I'd like there to be
> some way to specify the size without a face and stuff.  Ideas?

Idea (not opinion): the user could interact with the preview control in
the same way as the message composition control in an IM window.  Maybe
if the text style buttons are removed from the IM windows then this
would no longer be appropriate.  I have a gimp-created screenshot to
illustrate what I mean:
http://www.declarative.co.uk/~jwal/gaim-font-preferences.png

> Message Text:
> Kill "Show graphical smileys" and put a "No Smileys" option in the
> Smiley Themes selector.

Perhaps renaming the panel from "Smiley Themes" to just "Smilies" and
moving the existing check box to this pane.  It could grey out the theme
selector when unchecked.

> Kill "Show URLs as links" default to "Yes, of course.  Why wouldn't I?"

See [4].

> Replace "Ignore colors" "Ignore font faces" and "Ignore font sizes" with
> just "ignore incoming formatting".  Maybe?

I have played with this before because sometimes the font sizes were
messed up (I have experienced too large and too small).  The same effect
would be achieved when your "buddy" is in an annoying mood.  I am happy
with turning these three into one.  A better option would be to allow
you to disable formatting on a per-conversation window (run-time
variable only) or per-buddy (has to be persisted, so probably not within
the scope of these changes) basis.  Such an option would be best applied
to the display of messages currently in a window (even after receiving
them) and might make it redundant in the preferences panel.

> Buddy List:
> Kill "Show buttons as" make default "none."  I never use them and
> wouldn't miss them much.  The away message button is kinda useful
> though.  Thoughts?

I can only assume this falls under [1] because I cannot see another good
reason for it.  Perhaps just change the default for now and see what
happens as in [5].

> Kill "Show numbers in groups."  Default to "yes".  Are there people who
> will get violent if we force them to know how many buddies are online in
> their groups?  The preference isn't even worded well.  "Show numbers in
> groups"  What does that even mean?

A clearer example of [5].

> Kill "Show warning levels" and "Show idle times"  Default both to "yes".
> How many people would these annoy?

[5] Again

> Conversations:
> Kill "Send URLs as links" default to "Yeah, I rarely send people links I
> don't want them to click on"

This would be another [4]

> Kill "Show aliases in tabs/titles"  I used to be a staunch supporter of
> no aliases in tabs, but I'll give in here and default this to "Yes,
> please."

I would like to see the way buddies are represented homogenised across
the entire UI.  If this is what that means then I am all for it.

> I've been saying for a while (as have the people who ask why they can't
> get their conversations out of tabbed windows) that the tab preferences
> are braindead.  "Show IMs and chats in tabbed windows" doesn't do what
> it says at all.  I want to kill it and force people to look at the tabs
> against their will, but some people on this list care about people who
> aren't me, for some reason ;).  I think Nathan had an idea I was ok
> with... something about graying the option out when no tabs is chosen.
>
> Can we just force everyone to use tabs anyway?  Probably not.  People
> suck.

I have some friends that like their window manager to put things into
tabs for them and I like this idea.  I have others who use Windows and
OS X who are moving away from multiple "document" interfaces and I think
this is a good idea too.  Here and now I like tabs, though.

> Kill "Show status icons on tabs" and default to "OK."  It's useful and
> pretty, and everyone should use it.

A [5]

> IMs/Chats, these are mostly the same page, so I'll address them
> together:

What about putting them on the same page?  As in
http://www.declarative.co.uk/~jwal/gaim-conversation-preferences.png
I have removed a couple of options as discussed below.  I have unified
the button display options (if they are going to stay).  Some options
that were previously only for either IMs OR Chats have been allowed for
both (probably with different defaults).  The fact that, as an example,
the chat protocols normally don't allow notifications of whom is typing
does not mean this is impossible.  Perhaps greying such options until
needed would be clearer.  The "Show logins ..." should probably read
"Show events ...".  The MSN-specific page can then be scrapped since
conversations closing and timing out are events.

> Kill "Show buttons as" default to "none."  I have to admit I really like
> the new "none" look.  I'd consider leaving a send button in, though, for
> people like my mom who actually click the Send button with the mouse
> after every message, but then again, my mom just isn't very smart.
> Opinons?
> 
> "New window width" "New window height" and "Entry field height" need to
> die.  Detect changes in size like we do with the blist and use that size
> to create new windows.

Good.  Dare I mention the new spatial Nautilus?  No, best not.

> Kill "Hide window on send" default to "No, that's so stupid".  ICQ does
> not have an interface we wish to emulate.

A case of [5]

> Kill "Show logins in window," default to "yes"

Another [5], see comments above for saying "events" instead of "logins".

> Kill "Notify buddies that you are typing to them" default to "yes"?  I
> could go either way on that one.

Does not apply here.  Could be under a privacy heading along with
telling your buddies when you open and close conversation windows (if
you can avoid telling them this)?  You could swallow the Jabber-specific
option on disclosing the operating system into a generic privacy pane
too, perhaps.

> Kill "Old-style completion" and bury it, while defaulting to "no".
> Actually, kill "Tab-complete nicks" too and default to "yes".

[5] with maybe a touch of [4]

> Kill "Show people joining in window" "Show people leaving in window" and
> "colorize screen names" defaulting all to "yes".  I can't really picture
> anyone saying "Man, Gaim's really cool, but I don't use it because it
> tells me when someone joins a chatroom"

A [5].

> Sounds:
> Kill "sounds when you log in" default to "no".  Nobody wants that.

[5]

> Away/Idle:

Am I evil for never setting myself away?

[...]

This is my first post to this list.  I hope I have not annoyed too many
people.  If you have read it then thanks and I'm sorry for wasting your
time.  It was either do this or exam revision.

James Ascroft-Leigh

On Mon, Apr 26, 2004 at 09:34:41PM -0300, Steven Garrity wrote:
> Even better, I think, would be to follow the Gossip method of setting=20
> status with a always-visible menu at the bottom of the contact list:=20
> http://actsofvolition.com/images/screenshots/gossip_status.png
>=20
> I would also be interested in seeing "Offline" considered a "status",=20
> meaning one flydown could let you choose between "Available", "Busy",=20
> "Away", and "Offline". Choosing anything other than "Offline" could=20
> connect you. Of course, I'm over simplifying, as Gossip is only a=20
> one-protocol client.
>=20
> The Gossip-style status flydown also serves do show you your current stat=
us.

That works because you have one account on one service. I can't see
that working in the Gaim model all that well.

Christian

--=20
Christian Hammond         <>  The GNUpdate Project
chipx86@...      <>  http://www.gnupdate.org/
   "Technological progress is like an axe in the hands of a pathological
   criminal." -- Albert Einstein

Hi,
 
anybody would tell me the footprint of gaim?
i know the binary size of gaim, but don't know exactly which library it links to.
thanks.
 
avanish
 
 



---------------------------------
Do You Yahoo!?
Get your free @yahoo.com.hk address at Yahoo! Mail.

New to the list, but a _long_ time gaim user, I'll pitch in my two
cents.

On Mon, 2004-04-26 at 11:52, Sean Egan wrote:
>=20
> Kill "Show warning levels" and "Show idle times"  Default both to "yes".
> How many people would these annoy?
>=20

Personally, I don't have either of these options on, because the tool
tip provides that info and more, and the smaller the roster, er, buddy
list the better.  Annoyance level high.


> Kill "Show aliases in tabs/titles"  I used to be a staunch supporter of
> no aliases in tabs, but I'll give in here and default this to "Yes,
> please."

As long as the default is yes, this is a good option to nix.
I never spot the tab scroll arrow thingy when my tabs outgrow the
conversation window, so the smaller the tab the better.  I tend to keep
one conversation window (including chats) open all day (x-chat like) so
a lot of tabs are usually present.  You can always get the screen name
from the Info button (which I /could/ live without; it is the only
button I even seldom use).


>=20
> Kill "Show status icons on tabs" and default to "OK."  It's useful and
> pretty, and everyone should use it.

Agreed, and although off topic, wouldn't it be dope if hovering over
said status icon would show status (i.e., the status msg, idle time,
etc.) :)


-travis

On Mon, 2004-04-26 at 21:47, Travis Shirk wrote:
> As long as the default is yes, this is a good option to nix.
> I never spot the tab scroll arrow thingy when my tabs outgrow the
> conversation window, so the smaller the tab the better.  I tend to keep
> one conversation window (including chats) open all day (x-chat like) so
> a lot of tabs are usually present.  You can always get the screen name
> from the Info button (which I /could/ live without; it is the only
> button I even seldom use).

This is something that has long bugged me.  If GTK would allow us to
have multiple rows of tabs in a GtkNotebook (or if we wrote our own
GtkNotebook widget to do it) it would be a huge improvement IMHO.

-Nathan

Here's my first stab at the menu reorg. I tried to take the following into
account (no pun intended :))

* How the item in the menu applies to the menu title. For example, I
attempted to make sure that if something was in the buddy menu that it was
either directly related to the buddy list (e.g. show offline buddies) or a
buddy itself (Buddy Pounce).

* What things are users going to use most often? For instance, as
discussed before, grabbing an away message quickly is quite handy and if
one was to disable their buttons at the bottom of the buddy list it would
still be nice to have an away message in easier reach. I also flipped over
the away menu....now the top item is 'set all away' followed by the
accounts/connections, followed by new/remove at the bottom.

Unfortunately now that I look at the buddies menu it looks somewhat bland
because it only has 3 items that have icons (the same icon) while the
'Gaim' menu seems somewhat vibrant with all the icons.

As I was going through do_away_menu() I was trying to figgure out what did
what so I got about halfway through commenting it before I have to run out
the door for the evening. I'll finish commenting it either later tonight
or tomorrow. I wanted to get a patch into the developer's hands though
with the idea at least so that I can see if I'm on a track people are
going to like or if it's not working out.

Comments and constructive criticism appreciated :)

--dw

On Mon, 26 Apr 2004, Sean Egan wrote:
> > I have some ideas for cleaning up/reorganizing some of the menus. I think
> > it may be better for me to play with it and create a patch/viewables for
> > people to see (and play with the changes).
>
> Go for it.

Alright, I've done my best to collate everyone's responses.  They are listed
very roughly from "let's definitely get rid of it" to "let's keep this one." 
It probably looks better with a really wide email reader.

I get the impression people like the idea of having an "Advanced Preferences"
plugin ala what SimGuy has.  And I definitely like the idea.  I think it would
be good to have that shipped with Gaim.  See the following:
http://gaim-extprefs.sourceforge.net/
http://gaim-extprefs.sourceforge.net/extprefs.png

-Mark



REMOVE THESE FOR SURE:
Replace Interface->Fonts with a GtkIMHtml in MSN editable mode and a
GtkIMHtmlToolbar.
Remove Interface->Message Text->Show graphical smileys.  Add Interface->Smiley
Themes->No Smileys.
Remove Interface->Show URLs as links.  Default to yes
Remove Sounds->Sounds when you log in.  Default to no.
Remove Conversations->Send URLs as links.  Default to yes.
Remove Conversations->Show status icons on tabs.  Default to yes.
Remove Conversations->IMs->Hide window on send.  Default to no
Remove Conversations->IMs->Show buttons as.  Default to none.
Remove Conversations->IMs->New window width.  Detect and record changes in
size automatically.
Remove Conversations->IMs->New window height.  Detect and record changes in
size automatically.
Remove Conversations->IMs->Entry field height.  Detect and record changes in
size automatically.
Remove Conversations->Chats->Show buttons as.  Default to none.
Remove Conversations->Chats->New window width.  Detect and record changes in
size automatically.
Remove Conversations->Chats->New window height.  Detect and record changes in
size automatically.
Remove Conversations->Chats->Entry field height.  Detect and record changes in
size automatically.
Remove Conversations->Chats->Tab-complete nicks.  Default to yes.
Remove Conversations->Chats->Old-style completion.  Remove support.

Remove Away/Idle->Seconds before resending.  Default to 300 seconds.  Editable
with SimGuy's plugin?
Remove Away/Idle->Send auto-response in active conversations.  Default to no.
 A conversation should be considered active if you have messaged that person
within the last 300 seconds.
Remove Away/Idle->Sending messages removes away status.  Default to no.



OPEN FOR DISCUSSION:
Remove Buddy List->Show numbers in groups.  Default to yes.  Etan is against this.
Remove Buddy List->Show idle times.  Default to yes.  Brian Tarricone and Etan
are against this.
Remove Buddy List->Show warning levels.  Default to yes.  Brian Tarricone and
Etan are against this.  Move warning level to the area below the screen name?
 Make it NOT a part of the core and just have oscar take care of it?

Remove Conversations->Show aliases in tabs/titles.  Default to yes.  Nathan is
mostly against this.  Christian thinks people will complain.

Remove Conversations->IMs->Show logins in window.  Default to yes.
Remove Conversations->Chats->Show people joining in window.  Default to yes.
Remove Conversations->Chats->Show people leaving in window.  Default to yes.
For the above three, I think this should be handled by the Buddy State
Notification plugin and not handled by the core at all.  Is is possible to
make that plugin load by default?

Remove Message Text->Ignore colors.
Remove Message Text->Ignore font faces.
Remove Message Text->Ignore font sizes.
Add Message Text->Ignore Formatting on Incoming Messages.
Christian and Etan are against this.

Sean and Dave West want to create an Away menu between Tools and Help.  Skinny
buddy list people will freak out.  Do nothing for now and revisit the issue
after the status rewrite?

Brian Tarricone suggested this for Conversations Preferences:
 Tab Placement: [Top/Bottom/Left/Right]
 [x] Show IMs in tabbed windows
 [x] Show chats in tabbed windows
     [x] Show IMs and chats in the same tabbed window (note 1)
 [x] Show formatting toolbar
 [x] Show close button on tabs
(other options presumably nixed) 



DON'T REMOVE THESE:
Remove Buddy List->Show buttons as.  Default to none.  Mark, Luke and Brian
Tarricone are against this.
Remove Conversations->IMs->Notify buddies that you are typing to them. 
Default to yes.  Mark and some other people are against this.
Remove Conversations->Chats->Colorize screen names.  Default to yes.  Nathan,
Christian and Etan are against this.
Remove Away/Idle->Queue new messages when away.  Default to yes.  Mark, Nathan
Christian are against this.

see 
http://www106.pair.com/rhp/free-software-ui.html 
and
http://ometer.com/features.html

and some of the pages they link to.

luke

On Tue, Apr 27, 2004 at 01:37:15AM +0100, James Ascroft-Leigh wrote:
> In the recent thread on 'Freakin" annoying tooltips' Ethan Blanton
> mentioned (on 2004-03-14) guidelines that the developers try to follow.
> I had a quick look for where these are published but had no obvious
> hits.  Are these guidelines available to the masses?
> 
> I see the proposed changes as attempts to address different underlying
> problems that I will now attempt to enumerate:
> 
>     1.  Reduce number of code paths for ease of
>         development/testing/maintenance.
> 
>         I don't develop Gaim so I don't know what kind of a problem this
>         is.  I hope all of your nagging users (with their precious
>         preferences) are not causing too much grief.
> 

this is somewhat of a problem, and thus somewhat of something that needs
to be addressed, however, the preferences changes proposed will not
significantly help. 

>     2.  Make it easier to find the preference you require.
> 
>         My opinion on this is that really most people should not have to
>         look in the preferences pane for anything.  The vast majority of
>         preferences apply to some other aspect of the program and they
>         might like to be able to directly manipulate it.  I love context
>         menus and "remember this" check boxes because it lets you change
>         the thing you want at the time you realise it is wrong.
>         
>         If taken to the extreme (never a good idea, I suppose) then the
>         preferences pane is only for a few of the users and the
>         developers.  This means it can have as many options as you want
>         and needn't be organised from the point of view of the user.
>         Something like the gconf-editor, built from XML schema?
>

this is a concern, there are alot of times people ask for xyz and i tell
them to look in preferences.  i do not think that having or requiring
users to look at a preferences dialog is the problem, rather the lack of
organization in the current dialog is to blame. 

>     3.  Clarifying the preferences pane.
> 
>         Some of the options are misleading and/or in the wrong place and
>         should be fixed.

correct.


>         
>     4.  Targeting the intended user base (euphemism for having some 
>         balls).
> 
>         Some people like to use write(1) for instant messaging and will
>         use telnet(1) to chat on IRC.  Such people might not want colour
>         used to help them follow chats and might not appreciate being
>         able to click on URIs to get the resource displayed in their
>         favourite browser.  Such people should not hinder the rest of
>         us.
>

somewhat true. gaim has an incredibly diverse user base, and completely
pleasing everyone is impossible. given i spend a significant part of
most days dealing with bug reports, patches, feature requests, and
users, i like to think i have a good idea of what the "average" case is.
however this impression of mine, and the fact that i'm thus willing to
act on my sense of what is overall good, is something that is found
highly objectional every time i deny a request. 

         
>     5.  Clear away options people don't use.
> 
>         As long as the correct default is chosen these should be moved
>         to a more obscure location like gaim-extprefs.sf.net.  I would
>         think twice before simultaneously changing the default and
>         removing the user interface for the option as that is likely to
>         annoy people.  I will defer to those who are more involved to
>         decide which preferences are actually ever changed from their
>         defaults in the real world.

this is tempting. the arguement against it is equally so: making a habit
of preferences without ui is just asking for incredibly complex crufty
code. i'm not sure where the balence is.



overall Ethan's post is unrelated to this one. (the poster i'm currently
replying to may or may not realize this).  EVERY preference currently in
gaim and a good number that aren't would be useful to SOMEONE, that's
why they were put there. the question is if they are useful to
sufficient number of people to justify having them. see the urls pasted
above to help you in considering this.

luke


> 
> On Mon, 2004-04-26 at 13:52 -0400, Sean Egan wrote:
> > I'm finally looking to get rid of our useless prefs, and as this is a
> > touchy subject, I'll sollicit some opinions first.
> 
> Nothing you have said would annoy me but I am not everybody.  Others
> would probably appreciate it if real options moved out of gaim.sf.net
> get into gaim-extprefs.sf.net before the the changes are released.
> 
> > Please don't respond complaining that my opinion of sensible defaults
> > and fewer preferences and stupid, you'll just be ignored.  Or worse.
> > Only respond with specific insight on specific ideas listed herein:
> > 
> > HEREIN:
> > Fonts:
> > Replace 7 checkboxes, three dialog-spawning buttons, one spin button and
> > two colored boxes with, like, a GtkFontSelelector and a GtkIMHtml.  Or
> > something.  Putting a GtkIMHtml there is definitely useful, but a
> > fontselector can't pick colors or underlining, and I'd like there to be
> > some way to specify the size without a face and stuff.  Ideas?
> 
> Idea (not opinion): the user could interact with the preview control in
> the same way as the message composition control in an IM window.  Maybe
> if the text style buttons are removed from the IM windows then this
> would no longer be appropriate.  I have a gimp-created screenshot to
> illustrate what I mean:
> http://www.declarative.co.uk/~jwal/gaim-font-preferences.png
> 
> > Message Text:
> > Kill "Show graphical smileys" and put a "No Smileys" option in the
> > Smiley Themes selector.
> 
> Perhaps renaming the panel from "Smiley Themes" to just "Smilies" and
> moving the existing check box to this pane.  It could grey out the theme
> selector when unchecked.
> 
> > Kill "Show URLs as links" default to "Yes, of course.  Why wouldn't I?"
> 
> See [4].
> 
> > Replace "Ignore colors" "Ignore font faces" and "Ignore font sizes" with
> > just "ignore incoming formatting".  Maybe?
> 
> I have played with this before because sometimes the font sizes were
> messed up (I have experienced too large and too small).  The same effect
> would be achieved when your "buddy" is in an annoying mood.  I am happy
> with turning these three into one.  A better option would be to allow
> you to disable formatting on a per-conversation window (run-time
> variable only) or per-buddy (has to be persisted, so probably not within
> the scope of these changes) basis.  Such an option would be best applied
> to the display of messages currently in a window (even after receiving
> them) and might make it redundant in the preferences panel.
> 
> > Buddy List:
> > Kill "Show buttons as" make default "none."  I never use them and
> > wouldn't miss them much.  The away message button is kinda useful
> > though.  Thoughts?
> 
> I can only assume this falls under [1] because I cannot see another good
> reason for it.  Perhaps just change the default for now and see what
> happens as in [5].
> 
> > Kill "Show numbers in groups."  Default to "yes".  Are there people who
> > will get violent if we force them to know how many buddies are online in
> > their groups?  The preference isn't even worded well.  "Show numbers in
> > groups"  What does that even mean?
> 
> A clearer example of [5].
> 
> > Kill "Show warning levels" and "Show idle times"  Default both to "yes".
> > How many people would these annoy?
> 
> [5] Again
> 
> > Conversations:
> > Kill "Send URLs as links" default to "Yeah, I rarely send people links I
> > don't want them to click on"
> 
> This would be another [4]
> 
> > Kill "Show aliases in tabs/titles"  I used to be a staunch supporter of
> > no aliases in tabs, but I'll give in here and default this to "Yes,
> > please."
> 
> I would like to see the way buddies are represented homogenised across
> the entire UI.  If this is what that means then I am all for it.
> 
> > I've been saying for a while (as have the people who ask why they can't
> > get their conversations out of tabbed windows) that the tab preferences
> > are braindead.  "Show IMs and chats in tabbed windows" doesn't do what
> > it says at all.  I want to kill it and force people to look at the tabs
> > against their will, but some people on this list care about people who
> > aren't me, for some reason ;).  I think Nathan had an idea I was ok
> > with... something about graying the option out when no tabs is chosen.
> >
> > Can we just force everyone to use tabs anyway?  Probably not.  People
> > suck.
> 
> I have some friends that like their window manager to put things into
> tabs for them and I like this idea.  I have others who use Windows and
> OS X who are moving away from multiple "document" interfaces and I think
> this is a good idea too.  Here and now I like tabs, though.
> 
> > Kill "Show status icons on tabs" and default to "OK."  It's useful and
> > pretty, and everyone should use it.
> 
> A [5]
> 
> > IMs/Chats, these are mostly the same page, so I'll address them
> > together:
> 
> What about putting them on the same page?  As in
> http://www.declarative.co.uk/~jwal/gaim-conversation-preferences.png
> I have removed a couple of options as discussed below.  I have unified
> the button display options (if they are going to stay).  Some options
> that were previously only for either IMs OR Chats have been allowed for
> both (probably with different defaults).  The fact that, as an example,
> the chat protocols normally don't allow notifications of whom is typing
> does not mean this is impossible.  Perhaps greying such options until
> needed would be clearer.  The "Show logins ..." should probably read
> "Show events ...".  The MSN-specific page can then be scrapped since
> conversations closing and timing out are events.
> 
> > Kill "Show buttons as" default to "none."  I have to admit I really like
> > the new "none" look.  I'd consider leaving a send button in, though, for
> > people like my mom who actually click the Send button with the mouse
> > after every message, but then again, my mom just isn't very smart.
> > Opinons?
> > 
> > "New window width" "New window height" and "Entry field height" need to
> > die.  Detect changes in size like we do with the blist and use that size
> > to create new windows.
> 
> Good.  Dare I mention the new spatial Nautilus?  No, best not.
> 
> > Kill "Hide window on send" default to "No, that's so stupid".  ICQ does
> > not have an interface we wish to emulate.
> 
> A case of [5]
> 
> > Kill "Show logins in window," default to "yes"
> 
> Another [5], see comments above for saying "events" instead of "logins".
> 
> > Kill "Notify buddies that you are typing to them" default to "yes"?  I
> > could go either way on that one.
> 
> Does not apply here.  Could be under a privacy heading along with
> telling your buddies when you open and close conversation windows (if
> you can avoid telling them this)?  You could swallow the Jabber-specific
> option on disclosing the operating system into a generic privacy pane
> too, perhaps.
> 
> > Kill "Old-style completion" and bury it, while defaulting to "no".
> > Actually, kill "Tab-complete nicks" too and default to "yes".
> 
> [5] with maybe a touch of [4]
> 
> > Kill "Show people joining in window" "Show people leaving in window" and
> > "colorize screen names" defaulting all to "yes".  I can't really picture
> > anyone saying "Man, Gaim's really cool, but I don't use it because it
> > tells me when someone joins a chatroom"
> 
> A [5].
> 
> > Sounds:
> > Kill "sounds when you log in" default to "no".  Nobody wants that.
> 
> [5]
> 
> > Away/Idle:
> 
> Am I evil for never setting myself away?
> 
> [...]
> 
> This is my first post to this list.  I hope I have not annoyed too many
> people.  If you have read it then thanks and I'm sorry for wasting your
> time.  It was either do this or exam revision.
> 
> James Ascroft-Leigh
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=12297
> _______________________________________________
> Gaim-devel mailing list
> Gaim-devel@...
> https://lists.sourceforge.net/lists/listinfo/gaim-devel

On Mon, Apr 26, 2004 at 10:02:11PM -0400, Nathan Walp wrote:
> On Mon, 2004-04-26 at 21:47, Travis Shirk wrote:
> > As long as the default is yes, this is a good option to nix.
> > I never spot the tab scroll arrow thingy when my tabs outgrow the
> > conversation window, so the smaller the tab the better.  I tend to keep
> > one conversation window (including chats) open all day (x-chat like) so
> > a lot of tabs are usually present.  You can always get the screen name
> > from the Info button (which I /could/ live without; it is the only
> > button I even seldom use).
> 
> This is something that has long bugged me.  If GTK would allow us to
> have multiple rows of tabs in a GtkNotebook (or if we wrote our own
> GtkNotebook widget to do it) it would be a huge improvement IMHO.
> 
> -Nathan

Nathan is absolutely right here, this is my biggest gripe with gtk.

luke

a 4th menu is GOING to get added. skinny buddy list people will have to
deal. i've wanted a 4th menu that displays current account state and
allows for its manipulation for a long time.

luke

On Mon, Apr 26, 2004 at 09:51:33PM -0500, Mark Doliner wrote:
> Alright, I've done my best to collate everyone's responses.  They are listed
> very roughly from "let's definitely get rid of it" to "let's keep this one." 
> It probably looks better with a really wide email reader.
> 
> I get the impression people like the idea of having an "Advanced Preferences"
> plugin ala what SimGuy has.  And I definitely like the idea.  I think it would
> be good to have that shipped with Gaim.  See the following:
> http://gaim-extprefs.sourceforge.net/
> http://gaim-extprefs.sourceforge.net/extprefs.png
> 
> -Mark
> 
> 
> 
> REMOVE THESE FOR SURE:
> Replace Interface->Fonts with a GtkIMHtml in MSN editable mode and a
> GtkIMHtmlToolbar.
> Remove Interface->Message Text->Show graphical smileys.  Add Interface->Smiley
> Themes->No Smileys.
> Remove Interface->Show URLs as links.  Default to yes
> Remove Sounds->Sounds when you log in.  Default to no.
> Remove Conversations->Send URLs as links.  Default to yes.
> Remove Conversations->Show status icons on tabs.  Default to yes.
> Remove Conversations->IMs->Hide window on send.  Default to no
> Remove Conversations->IMs->Show buttons as.  Default to none.
> Remove Conversations->IMs->New window width.  Detect and record changes in
> size automatically.
> Remove Conversations->IMs->New window height.  Detect and record changes in
> size automatically.
> Remove Conversations->IMs->Entry field height.  Detect and record changes in
> size automatically.
> Remove Conversations->Chats->Show buttons as.  Default to none.
> Remove Conversations->Chats->New window width.  Detect and record changes in
> size automatically.
> Remove Conversations->Chats->New window height.  Detect and record changes in
> size automatically.
> Remove Conversations->Chats->Entry field height.  Detect and record changes in
> size automatically.
> Remove Conversations->Chats->Tab-complete nicks.  Default to yes.
> Remove Conversations->Chats->Old-style completion.  Remove support.
> 
> Remove Away/Idle->Seconds before resending.  Default to 300 seconds.  Editable
> with SimGuy's plugin?
> Remove Away/Idle->Send auto-response in active conversations.  Default to no.
>  A conversation should be considered active if you have messaged that person
> within the last 300 seconds.
> Remove Away/Idle->Sending messages removes away status.  Default to no.
> 
> 
> 
> OPEN FOR DISCUSSION:
> Remove Buddy List->Show numbers in groups.  Default to yes.  Etan is against this.
> Remove Buddy List->Show idle times.  Default to yes.  Brian Tarricone and Etan
> are against this.
> Remove Buddy List->Show warning levels.  Default to yes.  Brian Tarricone and
> Etan are against this.  Move warning level to the area below the screen name?
>  Make it NOT a part of the core and just have oscar take care of it?
> 
> Remove Conversations->Show aliases in tabs/titles.  Default to yes.  Nathan is
> mostly against this.  Christian thinks people will complain.
> 
> Remove Conversations->IMs->Show logins in window.  Default to yes.
> Remove Conversations->Chats->Show people joining in window.  Default to yes.
> Remove Conversations->Chats->Show people leaving in window.  Default to yes.
> For the above three, I think this should be handled by the Buddy State
> Notification plugin and not handled by the core at all.  Is is possible to
> make that plugin load by default?
> 
> Remove Message Text->Ignore colors.
> Remove Message Text->Ignore font faces.
> Remove Message Text->Ignore font sizes.
> Add Message Text->Ignore Formatting on Incoming Messages.
> Christian and Etan are against this.
> 
> Sean and Dave West want to create an Away menu between Tools and Help.  Skinny
> buddy list people will freak out.  Do nothing for now and revisit the issue
> after the status rewrite?
> 
> Brian Tarricone suggested this for Conversations Preferences:
>  Tab Placement: [Top/Bottom/Left/Right]
>  [x] Show IMs in tabbed windows
>  [x] Show chats in tabbed windows
>      [x] Show IMs and chats in the same tabbed window (note 1)
>  [x] Show formatting toolbar
>  [x] Show close button on tabs
> (other options presumably nixed) 
> 
> 
> 
> DON'T REMOVE THESE:
> Remove Buddy List->Show buttons as.  Default to none.  Mark, Luke and Brian
> Tarricone are against this.
> Remove Conversations->IMs->Notify buddies that you are typing to them. 
> Default to yes.  Mark and some other people are against this.
> Remove Conversations->Chats->Colorize screen names.  Default to yes.  Nathan,
> Christian and Etan are against this.
> Remove Away/Idle->Queue new messages when away.  Default to yes.  Mark, Nathan
> Christian are against this.
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=12297
> _______________________________________________
> Gaim-devel mailing list
> Gaim-devel@...
> https://lists.sourceforge.net/lists/listinfo/gaim-devel

On Mon, Apr 26, 2004 at 09:51:33PM -0500, Mark Doliner wrote:
> Remove Conversations->Show aliases in tabs/titles.  Default to yes.  Nathan is
> mostly against this.  Christian thinks people will complain.

Why remove this? With the number of other prefs being removed, clutter
is gone. This preference is simple and doesn't change a lot of code. A
lot of people prefer screennames in tabs instead of aliases; I do. My
aliases tend to be longer than the screennames, so I can fit more tabs
in a window with screennames. (No, multiple tab rows are not the
answer. See the UI Hall of Shame.) And seeing people's screennames in
tabs helps me learn them so I can make sense of my buddy list when I'm
signed on with a different client.

> Remove Conversations->IMs->Show logins in window.  Default to yes.
> Remove Conversations->Chats->Show people joining in window.  Default to yes.
> Remove Conversations->Chats->Show people leaving in window.  Default to yes.
> For the above three, I think this should be handled by the Buddy State
> Notification plugin and not handled by the core at all.  Is is possible to
> make that plugin load by default?

Good idea, but I think this preference would logically belong in the
main preferences dialog rather than an out-of-the-way plugin dialog. 
Moving it there just seems to defeat the goal of making the pref
dialog more intuitive.

If we're changing the pref dialog around anyway, why not change plugin
preferences? Instead of stashing them all under the Plugins root item,
why not allow plugins to insert their preference panel anywhere in the
plugin tree, perhaps displayed with a bold font? Isn't it a main tenet
of user interface design that the UI should be designed so that it
makes sense from a user's point of view rather than the implementor's?

Could also argue that if a plugin is included and maintained with gaim
anyway and is autoloaded, it might as well be part of the core.

> Remove Message Text->Ignore colors.
> Remove Message Text->Ignore font faces.
> Remove Message Text->Ignore font sizes.
> Add Message Text->Ignore Formatting on Incoming Messages.
> Christian and Etan are against this.

I think they should stay, since they are useful separately. I find
colors and sizes are generally more obnoxious than faces, so I ignore
two out of the three. What about renaming them and redesigning the UI?
It seems fundamentally similar to a Mozilla pref, and we could just
use the UI for that.

+--------------------+
| Always use my:     |
|    [ ] Colors      |
|    [ ] Font        |
|    [ ] Text Size   |
+--------------------+

> Sean and Dave West want to create an Away menu between Tools and Help.  Skinny
> buddy list people will freak out.  Do nothing for now and revisit the issue
> after the status rewrite?

I distinctly remember this being tried before. I'm a fat buddy list
person and I was bothered by it. A couple ideas:

* Wire up a key to pop up tools->away, or pop up a set-away-message
dialog. [ Think the xmms jump song dialog ]
* Float an away button in the upper-right-hand corner of the main
buddy list area. Maybe lower-right?


> Brian Tarricone suggested this for Conversations Preferences:
>  Tab Placement: [Top/Bottom/Left/Right]

How many people use something other than top? Especially left or right...

>  [x] Show IMs in tabbed windows
>  [x] Show chats in tabbed windows
>      [x] Show IMs and chats in the same tabbed window (note 1)

>  [x] Show formatting toolbar

Good idea.

>  [x] Show close button on tabs
> (other options presumably nixed) 
> 
> 
> 
> DON'T REMOVE THESE:
> Remove Buddy List->Show buttons as.  Default to none.  Mark, Luke and Brian
> Tarricone are against this.
> Remove Conversations->IMs->Notify buddies that you are typing to them. 
> Default to yes.  Mark and some other people are against this.

It's important to be able to disable this option for privacy reasons.

> Remove Conversations->Chats->Colorize screen names.  Default to yes.  Nathan,
> Christian and Etan are against this.

Why on earth wouldn't you want to colorize screennames? If it's broken
somehow, fix it.

> Remove Away/Idle->Queue new messages when away.  Default to yes.  Mark, Nathan
> Christian are against this.

I don't like to queue my away messages.

-- 
"Use what talents you possess: the woods would be very silent if no
birds sang there except those that sang best." -- Henry Van Dyke
"Si in Googlibus non est, non est." http://truffula.net:9999/

On Mon, Apr 26, 2004 at 11:07:12PM -0400, Luke Schierer wrote:
> a 4th menu is GOING to get added. skinny buddy list people will have to
> deal. i've wanted a 4th menu that displays current account state and
> allows for its manipulation for a long time.

Toplevel menus should not indicate state.

If you want this so badly, why not use the system tray icon? That does
what you need it to do. Or add an icon-menu item that functions like
the systray thingy?

Adding a fourth menu is tantamount to removing a feature many people
use (making the buddy list rather thin). You're doing this because
you've wanted a pet feature for a "long time?"

What would a fourth menu add? Is it so much trouble to click 'Tools',
*then* Away, the first option? Getting rid of the remove away message
facility and eliminating the 'custom' submenu would save a lot more
time. (Add a separator and then append the custom away messages.)

-- 
"Use what talents you possess: the woods would be very silent if no
birds sang there except those that sang best." -- Henry Van Dyke
"Si in Googlibus non est, non est." http://truffula.net:9999/

>>Brian Tarricone suggested this for Conversations Preferences:
>> Tab Placement: [Top/Bottom/Left/Right]
>>    
>>
>
>How many people use something other than top? Especially left or right...
>  
>

Sorry for my quick interjection here...but has anyone ever brought up 
replacing the tabbed windows with a "container" layout, like Trillian 
has?  It's kind of like an MDI.  When the inner windows are maximized, 
they behave almost exactly like tabbed windows, but when un-maximized 
you can arrange them in the parent window as you see fit (e.g. tile or 
cascade).

It can be a bit easier to deal with than tabbed windows, especially when 
working with a large number of conversations.

Anyway, just wondering.

Jeremy

because gaim should have a way to indicate status of the accounts
without opening a new dialog and without using the system tray icon and
a top level menu is the only way to 
1)make this readily accessible 
2)not cutter up the display if you have more than 5 or 6 accounts.

and anyway what says that top level menus shouldn't indicate state?




a row of status icons across the top or bottom of the buddy list along
hte lines of trillian's current ui works well for 1 to n icons where n
is (given the current default width of the buddy list) between 5 and 10,
but beyond that you'd have to increase the number of rows (which gtk
doesn't do well if at all, see the current state of tabs), or use scroll
arrows which are really bad. (or you could have the overlap which is
worse). 

so given that the system tray shouldn't have to be loaded to see your
own state and further given that opening the accounts dialog shouldn't
be required, and lastly given that a row of icons on the buddy list
won't work, where ELSE would you put current state?

luke

On Mon, Apr 26, 2004 at 11:56:08PM -0400, Dan Colascione wrote:
> On Mon, Apr 26, 2004 at 11:07:12PM -0400, Luke Schierer wrote:
> > a 4th menu is GOING to get added. skinny buddy list people will have to
> > deal. i've wanted a 4th menu that displays current account state and
> > allows for its manipulation for a long time.
> 
> Toplevel menus should not indicate state.
> 
> If you want this so badly, why not use the system tray icon? That does
> what you need it to do. Or add an icon-menu item that functions like
> the systray thingy?
> 
> Adding a fourth menu is tantamount to removing a feature many people
> use (making the buddy list rather thin). You're doing this because
> you've wanted a pet feature for a "long time?"
> 
> What would a fourth menu add? Is it so much trouble to click 'Tools',
> *then* Away, the first option? Getting rid of the remove away message
> facility and eliminating the 'custom' submenu would save a lot more
> time. (Add a separator and then append the custom away messages.)
> 
> -- 
> "Use what talents you possess: the woods would be very silent if no
> birds sang there except those that sang best." -- Henry Van Dyke
> "Si in Googlibus non est, non est." http://truffula.net:9999/
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=12297
> _______________________________________________
> Gaim-devel mailing list
> Gaim-devel@...
> https://lists.sourceforge.net/lists/listinfo/gaim-devel

On Tue, Apr 27, 2004 at 12:03:15AM -0400, Jeremy Brown wrote:
> 
> >>Brian Tarricone suggested this for Conversations Preferences:
> >>Tab Placement: [Top/Bottom/Left/Right]
> >>   
> >>
> >
> >How many people use something other than top? Especially left or right...
> > 
> >
> 
> Sorry for my quick interjection here...but has anyone ever brought up 
> replacing the tabbed windows with a "container" layout, like Trillian 
> has?  It's kind of like an MDI.  When the inner windows are maximized, 
> they behave almost exactly like tabbed windows, but when un-maximized 
> you can arrange them in the parent window as you see fit (e.g. tile or 
> cascade).
> 
> It can be a bit easier to deal with than tabbed windows, especially when 
> working with a large number of conversations.
> 
> Anyway, just wondering.

That's the feature I found most frustrating when I tried Trillian. As
I see it, you can either use tabbed windows, toplevels, or multiple
toplevel tabbed widgets.

Besides, I don't think GTK has any native MDI facility, making an
implementation of that idea really hard.

-- 
"Use what talents you possess: the woods would be very silent if no
birds sang there except those that sang best." -- Henry Van Dyke
"Si in Googlibus non est, non est." http://truffula.net:9999/

On Tue, Apr 27, 2004 at 12:03:15AM -0400, Jeremy Brown wrote:
> Sorry for my quick interjection here...but has anyone ever brought up=20
> replacing the tabbed windows with a "container" layout, like Trillian=20
> has?  It's kind of like an MDI.  When the inner windows are maximized,=20
> they behave almost exactly like tabbed windows, but when un-maximized=20
> you can arrange them in the parent window as you see fit (e.g. tile or=20
> cascade).
>=20
> It can be a bit easier to deal with than tabbed windows, especially when=
=20
> working with a large number of conversations.

That's the job of the window manager, not Gaim. I am *very* against
this ever happening. It's just bad UI.

Christian

--=20
Christian Hammond         <>  The GNUpdate Project
chipx86@...      <>  http://www.gnupdate.org/
   Who is General Failure and why is he reading my hard disk?

On Mon, Apr 26, 2004 at 11:43:00PM -0400, Dan Colascione wrote:
> On Mon, Apr 26, 2004 at 09:51:33PM -0500, Mark Doliner wrote:
> > Remove Conversations->Show aliases in tabs/titles.  Default to yes.  Nathan is
> > mostly against this.  Christian thinks people will complain.
> 
> Why remove this? With the number of other prefs being removed, clutter
> is gone. This preference is simple and doesn't change a lot of code. A
> lot of people prefer screennames in tabs instead of aliases; I do. My
> aliases tend to be longer than the screennames, so I can fit more tabs
> in a window with screennames. (No, multiple tab rows are not the
> answer. See the UI Hall of Shame.) And seeing people's screennames in
> tabs helps me learn them so I can make sense of my buddy list when I'm
> signed on with a different client.

making the use of different clients easy is a poor reason for a
preference. multiple rows of tabs are better than the scrolling arrows
we currently have. these two statements negate over half of the above
paragraph.

> 
> > Remove Conversations->IMs->Show logins in window.  Default to yes.
> > Remove Conversations->Chats->Show people joining in window.  Default to yes.
> > Remove Conversations->Chats->Show people leaving in window.  Default to yes.
> > For the above three, I think this should be handled by the Buddy State
> > Notification plugin and not handled by the core at all.  Is is possible to
> > make that plugin load by default?
> 
> Good idea, but I think this preference would logically belong in the
> main preferences dialog rather than an out-of-the-way plugin dialog. 
> Moving it there just seems to defeat the goal of making the pref
> dialog more intuitive.
> 

the plugin preferences are no more out of the way than any other
preference. invalid arguement.

> If we're changing the pref dialog around anyway, why not change plugin
> preferences? Instead of stashing them all under the Plugins root item,
> why not allow plugins to insert their preference panel anywhere in the
> plugin tree, perhaps displayed with a bold font? Isn't it a main tenet
> of user interface design that the UI should be designed so that it
> makes sense from a user's point of view rather than the implementor's?
> 

this is an interesting idea. 

> Could also argue that if a plugin is included and maintained with gaim
> anyway and is autoloaded, it might as well be part of the core.
> 

this is not true at all. and anyway, the only plugins autoloaded are the
protocols, the ssl, and the plugins that provide the perl and tcl api.
auto loaded plugins allow for extending functionality without extending
the memory footprint for those that do not use that functionality. there
are places where this is benificial and places where its needless
complication.  the current choices reflect this: we use it for protocols
because few people use every available protocol. we use it for ssl
because only two protocols can even use ssl. we use it for the plugin
api because VERY few people use the perl or tcl support AND because
providing perl and tcl as c plugins helps keep the api consistent across
the 3 interfaces. 

> > Remove Message Text->Ignore colors.
> > Remove Message Text->Ignore font faces.
> > Remove Message Text->Ignore font sizes.
> > Add Message Text->Ignore Formatting on Incoming Messages.
> > Christian and Etan are against this.
> 
> I think they should stay, since they are useful separately. I find
> colors and sizes are generally more obnoxious than faces, so I ignore
> two out of the three. What about renaming them and redesigning the UI?
> It seems fundamentally similar to a Mozilla pref, and we could just
> use the UI for that.
> 
> +--------------------+
> | Always use my:     |
> |    [ ] Colors      |
> |    [ ] Font        |
> |    [ ] Text Size   |
> +--------------------+
> 
> > Sean and Dave West want to create an Away menu between Tools and Help.  Skinny
> > buddy list people will freak out.  Do nothing for now and revisit the issue
> > after the status rewrite?
> 
> I distinctly remember this being tried before. I'm a fat buddy list
> person and I was bothered by it. A couple ideas:
> 
> * Wire up a key to pop up tools->away, or pop up a set-away-message
> dialog. [ Think the xmms jump song dialog ]
> * Float an away button in the upper-right-hand corner of the main
> buddy list area. Maybe lower-right?

people have been begging for a way to see their own status for ages. the
move to have the accounts dialog show it has not lessened these
requests, precisely because people do not want to have to open a new
dialog to see their own state, they want to be able to see it at a
glance. see my arguement above for more on this. 

> 
> 
> > Brian Tarricone suggested this for Conversations Preferences:
> >  Tab Placement: [Top/Bottom/Left/Right]
> 
> How many people use something other than top? Especially left or right...

left and right are of debatable use, that being said i know they are
used. i personally use bottom and know alot of people who do as well,
the reasoning being that it puts the tabs right next to where you type,
making your mouse movements nice and short.  having this preference is
also consistent with other gtk applications (galeon being an exception).

> 
> >  [x] Show IMs in tabbed windows
> >  [x] Show chats in tabbed windows
> >      [x] Show IMs and chats in the same tabbed window (note 1)
> 
> >  [x] Show formatting toolbar
> 
> Good idea.
> 
> >  [x] Show close button on tabs
> > (other options presumably nixed) 
> > 
> > 
> > 
> > DON'T REMOVE THESE:
> > Remove Buddy List->Show buttons as.  Default to none.  Mark, Luke and Brian
> > Tarricone are against this.
> > Remove Conversations->IMs->Notify buddies that you are typing to them. 
> > Default to yes.  Mark and some other people are against this.
> 
> It's important to be able to disable this option for privacy reasons.
> 
> > Remove Conversations->Chats->Colorize screen names.  Default to yes.  Nathan,
> > Christian and Etan are against this.
> 
> Why on earth wouldn't you want to colorize screennames? If it's broken
> somehow, fix it.

the colorized screennames are very hard to read with a large number of
gtk themes. its very hard to make the list of colors themable. the
compromise position between these two hard things is to make them
optional. 

luke

On Mon, Apr 26, 2004 at 11:43:00PM -0400, Dan Colascione wrote:
> On Mon, Apr 26, 2004 at 09:51:33PM -0500, Mark Doliner wrote:
> > Remove Conversations->Show aliases in tabs/titles.  Default to yes.  Na=
than is
> > mostly against this.  Christian thinks people will complain.
>=20
> Why remove this? With the number of other prefs being removed, clutter
> is gone. This preference is simple and doesn't change a lot of code. A
> lot of people prefer screennames in tabs instead of aliases; I do. My
> aliases tend to be longer than the screennames, so I can fit more tabs
> in a window with screennames. (No, multiple tab rows are not the
> answer. See the UI Hall of Shame.) And seeing people's screennames in
> tabs helps me learn them so I can make sense of my buddy list when I'm
> signed on with a different client.

Agreed.

> > Remove Conversations->IMs->Show logins in window.  Default to yes.
> > Remove Conversations->Chats->Show people joining in window.  Default to=
 yes.
> > Remove Conversations->Chats->Show people leaving in window.  Default to=
 yes.
> > For the above three, I think this should be handled by the Buddy State
> > Notification plugin and not handled by the core at all.  Is is possible=
 to
> > make that plugin load by default?
>=20
> Good idea, but I think this preference would logically belong in the
> main preferences dialog rather than an out-of-the-way plugin dialog.=20
> Moving it there just seems to defeat the goal of making the pref
> dialog more intuitive.
>=20
> If we're changing the pref dialog around anyway, why not change plugin
> preferences? Instead of stashing them all under the Plugins root item,
> why not allow plugins to insert their preference panel anywhere in the
> plugin tree, perhaps displayed with a bold font? Isn't it a main tenet
> of user interface design that the UI should be designed so that it
> makes sense from a user's point of view rather than the implementor's?

That's going to be a bit more tricky, I think, and I'm not sure how
good an idea it would be.

> I think they should stay, since they are useful separately. I find
> colors and sizes are generally more obnoxious than faces, so I ignore
> two out of the three. What about renaming them and redesigning the UI?
> It seems fundamentally similar to a Mozilla pref, and we could just
> use the UI for that.
>=20
> +--------------------+
> | Always use my:     |
> |    [ ] Colors      |
> |    [ ] Font        |
> |    [ ] Text Size   |
> +--------------------+

I like this.

> > Sean and Dave West want to create an Away menu between Tools and Help. =
 Skinny
> > buddy list people will freak out.  Do nothing for now and revisit the i=
ssue
> > after the status rewrite?
>=20
> I distinctly remember this being tried before. I'm a fat buddy list
> person and I was bothered by it. A couple ideas:
>=20
> * Wire up a key to pop up tools->away, or pop up a set-away-message
> dialog. [ Think the xmms jump song dialog ]
> * Float an away button in the upper-right-hand corner of the main
> buddy list area. Maybe lower-right?

I'm against using a dialog here. A menu of some kind is best, and
that'd have to either be at the bottom, or in a menu. Setting away
should be a quick operation, and I don't want to bury it in
Tools->Away. Its own menu may be better there, but I'm not sure of it
yet.

> > Brian Tarricone suggested this for Conversations Preferences:
> >  Tab Placement: [Top/Bottom/Left/Right]
>=20
> How many people use something other than top? Especially left or right...

My tabs are set to bottom, and I'm against any changes that will
prevent me from keeping that.

> >  [x] Show IMs in tabbed windows
> >  [x] Show chats in tabbed windows
> >      [x] Show IMs and chats in the same tabbed window (note 1)
>=20
> >  [x] Show formatting toolbar
>=20
> Good idea.

The distinction between IMs and chats are mostly going away, from both
a core and a UI perspective. It sounds worse than it is, I promise
you, but it's going to end up combining prefs like that. Those would
turn into "Show conversations in tabbed windows."

> > Remove Conversations->Chats->Colorize screen names.  Default to yes.  N=
athan,
> > Christian and Etan are against this.
>=20
> Why on earth wouldn't you want to colorize screennames? If it's broken
> somehow, fix it.

Not everybody wants every screen name in a chat to have its own color.

Christian
=20
--=20
Christian Hammond         <>  The GNUpdate Project
chipx86@...      <>  http://www.gnupdate.org/
   "Technological progress is like an axe in the hands of a pathological
   criminal." -- Albert Einstein

I would have to see a screenshot, and cannot find one (on an admittedly
cursory search) on trillian's site. 

luke

On Tue, Apr 27, 2004 at 12:03:15AM -0400, Jeremy Brown wrote:
> 
> >>Brian Tarricone suggested this for Conversations Preferences:
> >>Tab Placement: [Top/Bottom/Left/Right]
> >>   
> >>
> >
> >How many people use something other than top? Especially left or right...
> > 
> >
> 
> Sorry for my quick interjection here...but has anyone ever brought up 
> replacing the tabbed windows with a "container" layout, like Trillian 
> has?  It's kind of like an MDI.  When the inner windows are maximized, 
> they behave almost exactly like tabbed windows, but when un-maximized 
> you can arrange them in the parent window as you see fit (e.g. tile or 
> cascade).
> 
> It can be a bit easier to deal with than tabbed windows, especially when 
> working with a large number of conversations.
> 
> Anyway, just wondering.
> 
> Jeremy
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=12297
> _______________________________________________
> Gaim-devel mailing list
> Gaim-devel@...
> https://lists.sourceforge.net/lists/listinfo/gaim-devel

On Mon, Apr 26, 2004 at 07:27:57PM -0400, Andrew Sayman wrote:
> Showing logins in the window makes a lot of sense for conversations
> where the online/offline state doesn't determine whether you can message
> somebody or not. When talking to a person that suddenly logs off, if
> you're not alerted to it then you could send a bunch of messages
> thinking they're afk when they actually logged off. 

iChat has this really cool thing: it hides the input widget if the user is
offline. Of course, gaim would need to check if the protocol supports offline
messenging first.

-khc

On Mon, Apr 26, 2004 at 09:39:46PM -0700, Ka-Hing Cheung wrote:
> On Mon, Apr 26, 2004 at 07:27:57PM -0400, Andrew Sayman wrote:
> > Showing logins in the window makes a lot of sense for conversations
> > where the online/offline state doesn't determine whether you can message
> > somebody or not. When talking to a person that suddenly logs off, if
> > you're not alerted to it then you could send a bunch of messages
> > thinking they're afk when they actually logged off. 
> 
> iChat has this really cool thing: it hides the input widget if the user is
> offline. Of course, gaim would need to check if the protocol supports offline
> messenging first.
> 
> -khc

which would by-and-large bring back his point, that its when offline
messaging is supported that the show-logins is needed. for me though it
comes down to the fact that this option is identical to the show
parts/joins in chats, and that option is very clearly needed.  now as to
whether or not it should continue to be optional or if it should simply
default to yes i could care less.

luke

On Tue, Apr 27, 2004 at 12:07:02AM -0400, Luke Schierer wrote:
> because gaim should have a way to indicate status of the accounts
> without opening a new dialog and without using the system tray icon and
> a top level menu is the only way to 
> 1)make this readily accessible 
> 2)not cutter up the display if you have more than 5 or 6 accounts.

How many accounts is reasonable? All methods will start breaking down
at some point.
 
> and anyway what says that top level menus shouldn't indicate state?

Depends. The menu widget itself shouldn't change. I initially thought
that's what you meant.
 
> a row of status icons across the top or bottom of the buddy list along
> hte lines of trillian's current ui works well for 1 to n icons where n
> is (given the current default width of the buddy list) between 5 and 10,
> but beyond that you'd have to increase the number of rows (which gtk
> doesn't do well if at all, see the current state of tabs), or use scroll
> arrows which are really bad. (or you could have the overlap which is
> worse). 
> 
> so given that the system tray shouldn't have to be loaded to see your
> own state and further given that opening the accounts dialog shouldn't
> be required, and lastly given that a row of icons on the buddy list
> won't work, where ELSE would you put current state?

As you said in IRC, trounced.

If the "I'm Away" window goes away, then you do need an alternate
status indicator.

What would this away menu of yours look like?

Away
 +-+All
 | |-Message1
 | |-Message2
 ------------------
 +-+Account1
 | |-Message1
 | |-Message2
 |
 +-+Account2 (away)
 | |-Back
 |
 +-+Account3
   |-Message1
   |-Message2

When the user wants to check his status, he hits alt-a and examines
the menu, right? I (naively) thought you meant something like muning
the text of the "Away" menu to "Now away" or somesuch. My apologies.

This approach is workable, but I don't think it's optimal. The user
still has to press a key to check his away status. This is worse than
the old I'm Away window approach. Also, the away messages themselves
aren't readily available. The title of the away message could be
inserted in the menu, but that doesn't work for one-off untitled
messages.

With half-sized status icons, one could fit quite a few status icons
at the bottom or top of the buddy list. Writing code that arranges n
same-sized icons in however many rows is required wouldn't be that
hard. I'm thinking of something like the gimp toolbox. Full-sized
icons could be used up to a point and reduced to half-sized icons when
more than a certain number (say, six) appear. Tooltips on these icons
could describe the away message set for it. Setting all away could be
done through the menu (Tools-Away) or through a special status icon
separated from the rest.

I think one overall status icon in the buddy list with more
information on each window available in the accounts window could also
work, but that depends on whether a lot of people often set one
account away while continuing to use the others.

I don't think the current system is that bad either.

-- 
"Use what talents you possess: the woods would be very silent if no
birds sang there except those that sang best." -- Henry Van Dyke
"Si in Googlibus non est, non est." http://truffula.net:9999/

On Tue, Apr 27, 2004 at 12:16:33AM -0400, Luke Schierer wrote:
> On Mon, Apr 26, 2004 at 11:43:00PM -0400, Dan Colascione wrote:
> > On Mon, Apr 26, 2004 at 09:51:33PM -0500, Mark Doliner wrote:
> > > Remove Conversations->Show aliases in tabs/titles.  Default to yes.  Nathan is
> > > mostly against this.  Christian thinks people will complain.
> > 
> > Why remove this? With the number of other prefs being removed, clutter
> > is gone. This preference is simple and doesn't change a lot of code. A
> > lot of people prefer screennames in tabs instead of aliases; I do. My
> > aliases tend to be longer than the screennames, so I can fit more tabs
> > in a window with screennames. (No, multiple tab rows are not the
> > answer. See the UI Hall of Shame.) And seeing people's screennames in
> > tabs helps me learn them so I can make sense of my buddy list when I'm
> > signed on with a different client.
> 
> making the use of different clients easy is a poor reason for a
> preference. multiple rows of tabs are better than the scrolling arrows
> we currently have. these two statements negate over half of the above
> paragraph.

It's not so much to make using other clients easier as to help learn
people's screennames. Also, I'd rather not have to use either arrows
OR multiple rows. Regardless of which approach is taken, more tabs can
fit in the same space if each tab is shorter. Screennames are shorter
than my aliases, so I would rather use them. In the conversation
window, space isn't such a constraint.

> 
> > 
> > > Remove Conversations->IMs->Show logins in window.  Default to yes.
> > > Remove Conversations->Chats->Show people joining in window.  Default to yes.
> > > Remove Conversations->Chats->Show people leaving in window.  Default to yes.
> > > For the above three, I think this should be handled by the Buddy State
> > > Notification plugin and not handled by the core at all.  Is is possible to
> > > make that plugin load by default?
> > 
> > Good idea, but I think this preference would logically belong in the
> > main preferences dialog rather than an out-of-the-way plugin dialog. 
> > Moving it there just seems to defeat the goal of making the pref
> > dialog more intuitive.
> > 
> 
> the plugin preferences are no more out of the way than any other
> preference. invalid arguement.

No, it is a valid argument from an intuitive point of view. True,
plugin prefs are one level down in the pref tree, just like,say,
Sounds->Sound Events. The problem is that they're no longer logically
grouped with their categorization. One wouldn't expect to look for
additional preferences having to do with conversations under the
plugin item simply because they're implemented as plugins, especially
if the plugin is loaded by default (so the user doesn't notice the new
item appearing under Plugins when he checks the box for that plugin). 
Exposing implementation by doing that that doesn't help the user
locate the preferences he wants quickly, especially if there are many
plugins loaded, grouping unrelated preferences under Plugins.

> > If we're changing the pref dialog around anyway, why not change plugin
> > preferences? Instead of stashing them all under the Plugins root item,
> > why not allow plugins to insert their preference panel anywhere in the
> > plugin tree, perhaps displayed with a bold font? Isn't it a main tenet
> > of user interface design that the UI should be designed so that it
> > makes sense from a user's point of view rather than the implementor's?
> > 
> 
> this is an interesting idea.

IMHO, get rid of the Plugins tree. Leave it as singleton. Have plugins
add their preferences panels unde whichever categoy is most
appropriate. For Buddy Notification, it would be under Conversations.
System Tray Icon would go under Interface (which is a bit of a
misnomer, since Conversations is also part of the interface per se).

Doing this would make relevant plugin preferences easier to find.

> > Could also argue that if a plugin is included and maintained with gaim
> > anyway and is autoloaded, it might as well be part of the core.
> > 
> 
> this is not true at all. and anyway, the only plugins autoloaded are the
> protocols, the ssl, and the plugins that provide the perl and tcl api.

Right, but you were talking about 

> auto loaded plugins allow for extending functionality without extending
> the memory footprint for those that do not use that functionality. there

Right. That makes sense for functions that have a significant amount
of overhead or that require special libraries, like the perl and ssl
plugins mentioned below. But the code to insert signon/signoffs in the
conversation window is tiny, and putting that functionality in its own
plugin is unwarranted.

> are places where this is benificial and places where its needless
> complication.  the current choices reflect this: we use it for protocols
> because few people use every available protocol. we use it for ssl
> because only two protocols can even use ssl. we use it for the plugin
> api because VERY few people use the perl or tcl support AND because
> providing perl and tcl as c plugins helps keep the api consistent across
> the 3 interfaces.

All of these are elegant design choices. What I meant by autoloaded
plugins above are plugins that provide functionality that is enabled
by default anyway.

> > > Remove Message Text->Ignore colors.
> > > Remove Message Text->Ignore font faces.
> > > Remove Message Text->Ignore font sizes.
> > > Add Message Text->Ignore Formatting on Incoming Messages.
> > > Christian and Etan are against this.
> > 
> > I think they should stay, since they are useful separately. I find
> > colors and sizes are generally more obnoxious than faces, so I ignore
> > two out of the three. What about renaming them and redesigning the UI?
> > It seems fundamentally similar to a Mozilla pref, and we could just
> > use the UI for that.
> > 
> > +--------------------+
> > | Always use my:     |
> > |    [ ] Colors      |
> > |    [ ] Font        |
> > |    [ ] Text Size   |
> > +--------------------+
> > 
> > > Sean and Dave West want to create an Away menu between Tools and Help.  Skinny
> > > buddy list people will freak out.  Do nothing for now and revisit the issue
> > > after the status rewrite?
> > 
> > I distinctly remember this being tried before. I'm a fat buddy list
> > person and I was bothered by it. A couple ideas:
> > 
> > * Wire up a key to pop up tools->away, or pop up a set-away-message
> > dialog. [ Think the xmms jump song dialog ]
> > * Float an away button in the upper-right-hand corner of the main
> > buddy list area. Maybe lower-right?
> 
> people have been begging for a way to see their own status for ages. the
> move to have the accounts dialog show it has not lessened these
> requests, precisely because people do not want to have to open a new
> dialog to see their own state, they want to be able to see it at a
> glance. see my arguement above for more on this.

Different email.
 
> > > Brian Tarricone suggested this for Conversations Preferences:
> > >  Tab Placement: [Top/Bottom/Left/Right]
> > 
> > How many people use something other than top? Especially left or right...
> 
> left and right are of debatable use, that being said i know they are
> used. i personally use bottom and know alot of people who do as well,
> the reasoning being that it puts the tabs right next to where you type,
> making your mouse movements nice and short.  having this preference is
> also consistent with other gtk applications (galeon being an exception).

Good point. Agreed.
 
> > 
> > >  [x] Show IMs in tabbed windows
> > >  [x] Show chats in tabbed windows
> > >      [x] Show IMs and chats in the same tabbed window (note 1)
> > 
> > >  [x] Show formatting toolbar
> > 
> > Good idea.
> > 
> > >  [x] Show close button on tabs
> > > (other options presumably nixed) 
> > > 
> > > 
> > > 
> > > DON'T REMOVE THESE:
> > > Remove Buddy List->Show buttons as.  Default to none.  Mark, Luke and Brian
> > > Tarricone are against this.
> > > Remove Conversations->IMs->Notify buddies that you are typing to them. 
> > > Default to yes.  Mark and some other people are against this.
> > 
> > It's important to be able to disable this option for privacy reasons.
> > 
> > > Remove Conversations->Chats->Colorize screen names.  Default to yes.  Nathan,
> > > Christian and Etan are against this.
> > 
> > Why on earth wouldn't you want to colorize screennames? If it's broken
> > somehow, fix it.
> 
> the colorized screennames are very hard to read with a large number of
> gtk themes. its very hard to make the list of colors themable. the
> compromise position between these two hard things is to make them
> optional.

I see. Is there an algorithm to select four or five colors that are
guaranteed to contrast with a given background color? Even so, yes,
keep the preference. It could be annoying.

-- 
"Use what talents you possess: the woods would be very silent if no
birds sang there except those that sang best." -- Henry Van Dyke
"Si in Googlibus non est, non est." http://truffula.net:9999/

i have 30 some odd accounts, but that's clearly more than typical. good
planing would be to assume that a users has one account on every major
protocol (aim, msn, yahoo, and jabber), at least one minor protocol (all
the others) and a second account on at least one protocol.  this is 6
accounts which would work with a trillian type interface. but i'd want
any ui to be expandable to at least 2 accounts per (approx 12-15
accounts).


your example away menu is close. it would add in pictures (rather then
munging text around) to display status of each account, and you need a
mechanism for handing 
1)invisible
2)changing away message without returning from away.


you are correct, its not ideal, but its less bad than requiring the use
of the account editor for this.

the away dialog doesn't work well at all for the case of 2 or more
accounts only some of which are away.  it breaks down even worse once
you start adding in invisible, esp considering you can be both away and
invisible. 

i'm thinking more of a "status" menu than an "away" menu. on the whole
i'd like to see the account editor be just that, for adding and
modifying accounts, and a have the status menu be the primary way of
signing on and off as well as changing state to and from away. this is
why its important that your ui flex to more than 10 accounts, you need
to be able to handle the offline accounts sanely as well. it also brings
a new light to the flaw of the trillian design, in that putting offline
accounts there is wierd-looking, and not at all optimal for people who
have the odd account they don't use often. 

status is already far more complex than gaim handles well.  you should
be able to sign on to away, sign on to invisible, and ideally even
define states wherein some accounts go away and others sign off (or vice
versa). obviously a dialog of some sort would have to be used to set up
such a status, once such a status control is in place, i'd assume one
would replace the "all" option you have below with that, and everything
further down would be to display and override the state that status
describes. 

i'm not at all sure this is the best ui, its just the best i've heard
described or come up with myself in a year and a half of thinking about
it and talking in #gaim about it, the lack of other viable alternative
is why i am fairly sure it will happen. 



setting one or more accounts to away/invisible/offline while continuing
to use others is a key aspect of where we _need_ to go but are not yet.
a simple, though fictional example, is someone who uses the same aim and
msn screenname at home and at work, with the addition of a jabber
screenname at work.  when [s]he goes home for the day, the jabber
screenname should be set to away, the other 2 signed off. the reverse
should happen when arriving. my own typical use case is considerably
more complex.  the goal here is to make the average use case (wanting to
control 2 or more accounts simultaneously) (side note: i do not consider
users of a single account the target audience for gaim, but such use
should still 1)be possible 2)where possible, the ui should still make
sense for such a user) easy and the more complex use cases still
possible.

luke

On Tue, Apr 27, 2004 at 12:49:03AM -0400, Dan Colascione wrote:
> On Tue, Apr 27, 2004 at 12:07:02AM -0400, Luke Schierer wrote:
> > because gaim should have a way to indicate status of the accounts
> > without opening a new dialog and without using the system tray icon and
> > a top level menu is the only way to 
> > 1)make this readily accessible 
> > 2)not cutter up the display if you have more than 5 or 6 accounts.
> 
> How many accounts is reasonable? All methods will start breaking down
> at some point.
>  
> > and anyway what says that top level menus shouldn't indicate state?
> 
> Depends. The menu widget itself shouldn't change. I initially thought
> that's what you meant.
>  
> > a row of status icons across the top or bottom of the buddy list along
> > hte lines of trillian's current ui works well for 1 to n icons where n
> > is (given the current default width of the buddy list) between 5 and 10,
> > but beyond that you'd have to increase the number of rows (which gtk
> > doesn't do well if at all, see the current state of tabs), or use scroll
> > arrows which are really bad. (or you could have the overlap which is
> > worse). 
> > 
> > so given that the system tray shouldn't have to be loaded to see your
> > own state and further given that opening the accounts dialog shouldn't
> > be required, and lastly given that a row of icons on the buddy list
> > won't work, where ELSE would you put current state?
> 
> As you said in IRC, trounced.
> 
> If the "I'm Away" window goes away, then you do need an alternate
> status indicator.
> 
> What would this away menu of yours look like?
> 
> Away
>  +-+All
>  | |-Message1
>  | |-Message2
>  ------------------
>  +-+Account1
>  | |-Message1
>  | |-Message2
>  |
>  +-+Account2 (away)
>  | |-Back
>  |
>  +-+Account3
>    |-Message1
>    |-Message2
> 
> When the user wants to check his status, he hits alt-a and examines
> the menu, right? I (naively) thought you meant something like muning
> the text of the "Away" menu to "Now away" or somesuch. My apologies.
> 
> This approach is workable, but I don't think it's optimal. The user
> still has to press a key to check his away status. This is worse than
> the old I'm Away window approach. Also, the away messages themselves
> aren't readily available. The title of the away message could be
> inserted in the menu, but that doesn't work for one-off untitled
> messages.
> 
> With half-sized status icons, one could fit quite a few status icons
> at the bottom or top of the buddy list. Writing code that arranges n
> same-sized icons in however many rows is required wouldn't be that
> hard. I'm thinking of something like the gimp toolbox. Full-sized
> icons could be used up to a point and reduced to half-sized icons when
> more than a certain number (say, six) appear. Tooltips on these icons
> could describe the away message set for it. Setting all away could be
> done through the menu (Tools-Away) or through a special status icon
> separated from the rest.
> 
> I think one overall status icon in the buddy list with more
> information on each window available in the accounts window could also
> work, but that depends on whether a lot of people often set one
> account away while continuing to use the others.
> 
> I don't think the current system is that bad either.
> 
> -- 
> "Use what talents you possess: the woods would be very silent if no
> birds sang there except those that sang best." -- Henry Van Dyke
> "Si in Googlibus non est, non est." http://truffula.net:9999/
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=12297
> _______________________________________________
> Gaim-devel mailing list
> Gaim-devel@...
> https://lists.sourceforge.net/lists/listinfo/gaim-devel

On Tue, Apr 27, 2004 at 01:07:16AM -0400, Dan Colascione wrote:
> On Tue, Apr 27, 2004 at 12:16:33AM -0400, Luke Schierer wrote:
> > On Mon, Apr 26, 2004 at 11:43:00PM -0400, Dan Colascione wrote:
> > > On Mon, Apr 26, 2004 at 09:51:33PM -0500, Mark Doliner wrote:
> > > > Remove Conversations->Show aliases in tabs/titles.  Default to yes.  Nathan is
> > > > mostly against this.  Christian thinks people will complain.
> > > 
> > > Why remove this? With the number of other prefs being removed, clutter
> > > is gone. This preference is simple and doesn't change a lot of code. A
> > > lot of people prefer screennames in tabs instead of aliases; I do. My
> > > aliases tend to be longer than the screennames, so I can fit more tabs
> > > in a window with screennames. (No, multiple tab rows are not the
> > > answer. See the UI Hall of Shame.) And seeing people's screennames in
> > > tabs helps me learn them so I can make sense of my buddy list when I'm
> > > signed on with a different client.
> > 
> > making the use of different clients easy is a poor reason for a
> > preference. multiple rows of tabs are better than the scrolling arrows
> > we currently have. these two statements negate over half of the above
> > paragraph.
> 
> It's not so much to make using other clients easier as to help learn
> people's screennames. Also, I'd rather not have to use either arrows
> OR multiple rows. Regardless of which approach is taken, more tabs can
> fit in the same space if each tab is shorter. Screennames are shorter
> than my aliases, so I would rather use them. In the conversation
> window, space isn't such a constraint.

it is very much a constraint, esp with the default window size. at the
default window size, you have about 4-5 tabs before scrolling, and at
947 pixels (my default width) you have ~10 (plus or minus depending on
average nick size) tabs before scrolling. if you tab by group this might
be sufficient (its not for many users, a group size of 20+ is not that
uncommon), or if you are agressive about closing tabs,  but if you use a
single window its EASILY exceeded. 

> 
> > 
> > > 
> > > > Remove Conversations->IMs->Show logins in window.  Default to yes.
> > > > Remove Conversations->Chats->Show people joining in window.  Default to yes.
> > > > Remove Conversations->Chats->Show people leaving in window.  Default to yes.
> > > > For the above three, I think this should be handled by the Buddy State
> > > > Notification plugin and not handled by the core at all.  Is is possible to
> > > > make that plugin load by default?
> > > 
> > > Good idea, but I think this preference would logically belong in the
> > > main preferences dialog rather than an out-of-the-way plugin dialog. 
> > > Moving it there just seems to defeat the goal of making the pref
> > > dialog more intuitive.
> > > 
> > 
> > the plugin preferences are no more out of the way than any other
> > preference. invalid arguement.
> 
> No, it is a valid argument from an intuitive point of view. True,
> plugin prefs are one level down in the pref tree, just like,say,
> Sounds->Sound Events. The problem is that they're no longer logically
> grouped with their categorization. One wouldn't expect to look for
> additional preferences having to do with conversations under the
> plugin item simply because they're implemented as plugins, especially
> if the plugin is loaded by default (so the user doesn't notice the new
> item appearing under Plugins when he checks the box for that plugin). 
> Exposing implementation by doing that that doesn't help the user
> locate the preferences he wants quickly, especially if there are many
> plugins loaded, grouping unrelated preferences under Plugins.
> 

as i said, your idea of moving the preferences they provide into the
other panes is interesting.  the biggest thing against it i see is that
it isn't readily apparent that options that did not previously exist
just became available. its an interesting idea that can be looked at
separately from the rest of this reorganization.

> > > If we're changing the pref dialog around anyway, why not change plugin
> > > preferences? Instead of stashing them all under the Plugins root item,
> > > why not allow plugins to insert their preference panel anywhere in the
> > > plugin tree, perhaps displayed with a bold font? Isn't it a main tenet
> > > of user interface design that the UI should be designed so that it
> > > makes sense from a user's point of view rather than the implementor's?
> > > 
> > 
> > this is an interesting idea.
> 
> IMHO, get rid of the Plugins tree. Leave it as singleton. Have plugins
> add their preferences panels unde whichever categoy is most
> appropriate. For Buddy Notification, it would be under Conversations.
> System Tray Icon would go under Interface (which is a bit of a
> misnomer, since Conversations is also part of the interface per se).
> 
> Doing this would make relevant plugin preferences easier to find.
> 

it would make them harder: you would have to search every pane of
preferences to see if the plugin added preferences at all.

> > > Could also argue that if a plugin is included and maintained with gaim
> > > anyway and is autoloaded, it might as well be part of the core.
> > > 
> > 
> > this is not true at all. and anyway, the only plugins autoloaded are the
> > protocols, the ssl, and the plugins that provide the perl and tcl api.
> 
> Right, but you were talking about 

your thought here seems to have been cut off. iirc you are the one who
brought up autoloaded plugins and whether or not they should exist.

> 
> > auto loaded plugins allow for extending functionality without extending
> > the memory footprint for those that do not use that functionality. there
> 
> Right. That makes sense for functions that have a significant amount
> of overhead or that require special libraries, like the perl and ssl
> plugins mentioned below. But the code to insert signon/signoffs in the
> conversation window is tiny, and putting that functionality in its own
> plugin is unwarranted.
> 

as far as your specfic example goes, i agree.

> > are places where this is benificial and places where its needless
> > complication.  the current choices reflect this: we use it for protocols
> > because few people use every available protocol. we use it for ssl
> > because only two protocols can even use ssl. we use it for the plugin
> > api because VERY few people use the perl or tcl support AND because
> > providing perl and tcl as c plugins helps keep the api consistent across
> > the 3 interfaces.
> 
> All of these are elegant design choices. What I meant by autoloaded
> plugins above are plugins that provide functionality that is enabled
> by default anyway.
> 

ah. which is not the sense of "autoloaded plugins" that gaim normally
uses, hence my confusion and tangent above ;-)

> > > > Remove Message Text->Ignore colors.
> > > > Remove Message Text->Ignore font faces.
> > > > Remove Message Text->Ignore font sizes.
> > > > Add Message Text->Ignore Formatting on Incoming Messages.
> > > > Christian and Etan are against this.
> > > 
> > > I think they should stay, since they are useful separately. I find
> > > colors and sizes are generally more obnoxious than faces, so I ignore
> > > two out of the three. What about renaming them and redesigning the UI?
> > > It seems fundamentally similar to a Mozilla pref, and we could just
> > > use the UI for that.
> > > 
> > > +--------------------+
> > > | Always use my:     |
> > > |    [ ] Colors      |
> > > |    [ ] Font        |
> > > |    [ ] Text Size   |
> > > +--------------------+
> > > 
> > > > Sean and Dave West want to create an Away menu between Tools and Help.  Skinny
> > > > buddy list people will freak out.  Do nothing for now and revisit the issue
> > > > after the status rewrite?
> > > 
> > > I distinctly remember this being tried before. I'm a fat buddy list
> > > person and I was bothered by it. A couple ideas:
> > > 
> > > * Wire up a key to pop up tools->away, or pop up a set-away-message
> > > dialog. [ Think the xmms jump song dialog ]
> > > * Float an away button in the upper-right-hand corner of the main
> > > buddy list area. Maybe lower-right?
> > 
> > people have been begging for a way to see their own status for ages. the
> > move to have the accounts dialog show it has not lessened these
> > requests, precisely because people do not want to have to open a new
> > dialog to see their own state, they want to be able to see it at a
> > glance. see my arguement above for more on this.
> 
> Different email.
>  
> > > > Brian Tarricone suggested this for Conversations Preferences:
> > > >  Tab Placement: [Top/Bottom/Left/Right]
> > > 
> > > How many people use something other than top? Especially left or right...
> > 
> > left and right are of debatable use, that being said i know they are
> > used. i personally use bottom and know alot of people who do as well,
> > the reasoning being that it puts the tabs right next to where you type,
> > making your mouse movements nice and short.  having this preference is
> > also consistent with other gtk applications (galeon being an exception).
> 
> Good point. Agreed.
>  

<snip>

> > 
> > the colorized screennames are very hard to read with a large number of
> > gtk themes. its very hard to make the list of colors themable. the
> > compromise position between these two hard things is to make them
> > optional.
> 
> I see. Is there an algorithm to select four or five colors that are
> guaranteed to contrast with a given background color? Even so, yes,
> keep the preference. It could be annoying.

there may be an algorithm that will generate 30 or so colors that
contrast with a given background color and more or less with each other,
but if there is, i certainly don't know it.  that is an awesome idea, if
someone can manage to implement it though is another story ;-)

luke

On Tue, 2004-04-27 at 00:16, Luke Schierer wrote:
> On Mon, Apr 26, 2004 at 11:43:00PM -0400, Dan Colascione wrote:
> > On Mon, Apr 26, 2004 at 09:51:33PM -0500, Mark Doliner wrote:
> > > Brian Tarricone suggested this for Conversations Preferences:
> > >  Tab Placement: [Top/Bottom/Left/Right]
> > 
> > How many people use something other than top? Especially left or right...
> 
> left and right are of debatable use, that being said i know they are
> used. i personally use bottom and know alot of people who do as well,
> the reasoning being that it puts the tabs right next to where you type,
> making your mouse movements nice and short.  having this preference is
> also consistent with other gtk applications (galeon being an exception

Left and right are useful for stacking lots of conversations and being
able to see all of their activity at once without needing a massive
conversation window. Once you get over four or five active
conversations, top and bottom become useless because you can't tell who
just messaged you.

-- 
Andrew Sayman <gtg842q@...>

Luke Schierer wrote:
> On Tue, Apr 27, 2004 at 01:07:16AM -0400, Dan Colascione wrote:
>>On Tue, Apr 27, 2004 at 12:16:33AM -0400, Luke Schierer wrote:
>>IMHO, get rid of the Plugins tree. Leave it as singleton. Have plugins
>>add their preferences panels unde whichever categoy is most
>>appropriate. For Buddy Notification, it would be under Conversations.
>>System Tray Icon would go under Interface (which is a bit of a
>>misnomer, since Conversations is also part of the interface per se).
>>
>>Doing this would make relevant plugin preferences easier to find.
> 
> it would make them harder: you would have to search every pane of
> preferences to see if the plugin added preferences at all.

I think Dan was talking about plugins adding new panes in the preferences tree 
only, not just new checkboxes into existing panes. A plugin could add its own 
category into the 'Sound' below 'Sound Events', not inside (or maybe even at 
the root for unrelated plugins).

As I see it, there could be a small plug icon (or anything) in front of the 
panes coming from plugins, so users can distinguish between plugins and core 
preferences. The plugin which added the pane could be named in the pane 
itself. (added to the pane title?)

BTW, I think the status menu/button is a good idea, especially if there can be 
a kind of 'status tooltip' for online accounts. For some time now, I added my 
accounts as buddies inside contacts (for secondary accounts) in a 'Status' 
group, but I really look forward for some new stuff there.

Eric
-- 
- Life is like a sandwich. Sometimes you eat the sandwich,
   sometimes the sandwich eats you.
- What kind of sandwich are you talking about exactly?
- Pitbull salad sandwich.                            (Sluggy Freelance)

On Mon, Apr 26, 2004 at 09:19:23PM -0700, Christian Hammond wrote:

> That's going to be a bit more tricky, I think, and I'm not sure how
> good an idea it would be.

There's a certain appeal to plugin prefs being placed where they are
logically otherwise situated.  However, support-wise I think that gets
Gaimyou into a complex mess where someone says, "How do I..." and you
direct them to the right place in the prefs UI, and they now say, "I
don't have that there."  Now you have to send them to the Plugins
pane, tell them to enable the plugin, make them go back to where they
were before and look for the pref again...

On the other hand, maybe it wouldn't end up being so bad if plugins
could add their own boxes into panes, so it was grouped and you could
see if the plugin was enabled, at a glance.  For example, Interface ->
Message Text would have:

	 ----------------------
	|  Display             |
	|   ...                |
	|                      |
	|  Ignore              |
	|   ...                |
	|                      |
	|----------------------|
	|  Notification        |   <-- from notification plugin
	|   ...                |
	 ----------------------

and so on.  It's good in the sense that now prefs are grouped by
functionality rather than implementation.  But I would have thought the
primary way people use plugins is that they enable it and then they
configure it.  It's not necessarily better if, after enabling the
plugin, I have to hunt through each prefs pane looking for relevant
prefs to that plugin so I can configure its behaviour.[1]

[1] Of course, some people here would say that the defaults should be
fine and configuring not really necessary...

> > +--------------------+
> > | Always use my:     |
> > |    [ ] Colors      |
> > |    [ ] Font        |
> > |    [ ] Text Size   |
> > +--------------------+
> 
> I like this.

It really would be good to be able to set these on a per-buddy basis
(but the above is nice for a global default).

I would also like to reiterate that a small buddy list is good.  IM'ing
is, for me, a background activity.  I prefer to keep it small and
unobtrusive, a small window for a small use.  It's not a web browser, it
shouldn't need to be almost maximised :)


   Vince

-- 
    Vincent Ho
loki /at/ internode.on.net

Every complex problem is a simple hierarchy of simple problems.

On Mon, 2004-04-26 at 19:52, Sean Egan wrote:
> Can we just force everyone to use tabs anyway?  Probably not.  People
> suck.

... the gnome people mostly think that tabs-are-evil....


gabor

On Tue, Apr 27, 2004 at 09:23:52AM +0200, gabor wrote:
> On Mon, 2004-04-26 at 19:52, Sean Egan wrote:
> > Can we just force everyone to use tabs anyway?  Probably not.  People
> > suck.
>=20
> ... the gnome people mostly think that tabs-are-evil....

Since when? Lots of gnome apps use tabs.

Christian

--=20
Christian Hammond         <>  The GNUpdate Project
chipx86@...      <>  http://www.gnupdate.org/
   Who is General Failure and why is he reading my hard disk?

On Tue, 2004-04-27 at 09:54, Christian Hammond wrote:
> On Tue, Apr 27, 2004 at 09:23:52AM +0200, gabor wrote:
> > On Mon, 2004-04-26 at 19:52, Sean Egan wrote:
> > > Can we just force everyone to use tabs anyway?  Probably not.  People
> > > suck.
> > 
> > ... the gnome people mostly think that tabs-are-evil....
> 
> Since when? Lots of gnome apps use tabs.

they say that using tabs basically duplicates the functionality of the
window manager, and tabs are a necessary-evil, until the window manager
reach a level where they can 'understand' that several windows should be
grouped together...

like the 'tab' feature of black/flux/whatever-box window managers + some
heuristics maybe to find out which windows to group....

if you search for 'tabs' on the gnome-usability list, there are some
usable mails...

http://lists.gnome.org/archives/usability/

bye,
gabor

p.s: i am not saying tabs should be removed (i don't use them
personally, but i can understand that some people like them...my
personal problem with them was that i didn't know when i got a new
message...i use the raise-on-events feature, but sometimes the window
got raised, and 2 people wrote me something, and i found one of them,
and forgot about the other...well, i could check the tabs for red text,
but for me it is easier to simply have separate windows for separate
chats)

On Mon, Apr 26, 2004 at 10:56:37PM -0700, Eric Boumaour wrote:
> Luke Schierer wrote:
> >On Tue, Apr 27, 2004 at 01:07:16AM -0400, Dan Colascione wrote:
> >>On Tue, Apr 27, 2004 at 12:16:33AM -0400, Luke Schierer wrote:
> >>IMHO, get rid of the Plugins tree. Leave it as singleton. Have plugins
> >>add their preferences panels unde whichever categoy is most
> >>appropriate. For Buddy Notification, it would be under Conversations.
> >>System Tray Icon would go under Interface (which is a bit of a
> >>misnomer, since Conversations is also part of the interface per se).
> >>
> >>Doing this would make relevant plugin preferences easier to find.
> >
> >it would make them harder: you would have to search every pane of
> >preferences to see if the plugin added preferences at all.
> 
> I think Dan was talking about plugins adding new panes in the preferences 
> tree only, not just new checkboxes into existing panes. A plugin could add 
> its own category into the 'Sound' below 'Sound Events', not inside (or 
> maybe even at the root for unrelated plugins).

Right. The idea of adding boxes to existing preferences panes is
interesting, but that would be very difficult to make work correctly.
The user would also become confused looking for new preferences.
 
> As I see it, there could be a small plug icon (or anything) in front of the 
> panes coming from plugins, so users can distinguish between plugins and 
> core preferences. The plugin which added the pane could be named in the 
> pane itself. (added to the pane title?)

I'm also thinking that when a plugin is first loaded and the
preference pane first added, gaim would automatically expand that
segment of the tree, and perhaps blink the new pane once or twice to
call attention to it.

-- 
"Use what talents you possess: the woods would be very silent if no
birds sang there except those that sang best." -- Henry Van Dyke
"Si in Googlibus non est, non est." http://truffula.net:9999/

On Tue, Apr 27, 2004 at 01:14:36AM -0400, Luke Schierer wrote:
> i have 30 some odd accounts, but that's clearly more than typical. good
> planing would be to assume that a users has one account on every major
> protocol (aim, msn, yahoo, and jabber), at least one minor protocol (all
> the others) and a second account on at least one protocol.  this is 6
> accounts which would work with a trillian type interface. but i'd want
> any ui to be expandable to at least 2 accounts per (approx 12-15
> accounts).

A few rows of small status icons could work with 15 accounts. The
problem with that is that it's not readily apparent which icon
corresponds to which account.

> status is already far more complex than gaim handles well.  you should
> be able to sign on to away, sign on to invisible, and ideally even
> define states wherein some accounts go away and others sign off (or vice
> versa). obviously a dialog of some sort would have to be used to set up
> such a status, once such a status control is in place, i'd assume one
> would replace the "all" option you have below with that, and everything
> further down would be to display and override the state that status
> describes.

The most important problem with your menu is the inability to see the
current away message. Also, a menu requires at least one click or
keypress to get the status. There must be a better way, or buddies
will stay on the buddy list. This can be worked around by adding
accounts to the buddy list, but isn't that what we're trying to move
away from anyway? If we resign ourselves to that, we might as well add
the ability to control the away message and such from the context menu
of each of these buddy list entries.

There seem to be two conflicting requirements here: one, a way to
ascertain the status of all the accounts at a glance and to quickly
set an away message. Two, a way to control all of gaim's status
functionality. I don't see why these two functions have to be
presented by the same widget. Some kind of icon system would be ideal
for the first, while a dialog is the logical choice for the latter.

A dialog would require LESS time to perform certain tasks, especially
with the layout of the menu you're talking about. To come back from
away with your menu, the user would go to Away->Account->Back, and for
each of those ->s, would have to hunt through the menu for the
particular option he wants. With a dialog, he would bring up the
away/accounts dialog (control-A) and uncheck the 'away' button (while
possibly leaving, say, invisible.) When convenient, hitting escape
should close the dialog.

What about a predefined group containing all the user's accounts? Gaim
could also detect if a buddy is in fact a gaim account and provide
more options in the context menu, such as set away and set invisible. 
I was thinking about suggesting a split buddy list, with this special
group in a resizable, separately-scrollable pane at the bottom, but
that would be horribly ugly.

-- 
"Use what talents you possess: the woods would be very silent if no
birds sang there except those that sang best." -- Henry Van Dyke
"Si in Googlibus non est, non est." http://truffula.net:9999/

On Tue, Apr 27, 2004 at 09:05:38AM -0400, Dan Colascione wrote:
> On Tue, Apr 27, 2004 at 01:14:36AM -0400, Luke Schierer wrote:
> > i have 30 some odd accounts, but that's clearly more than typical. good
> > planing would be to assume that a users has one account on every major
> > protocol (aim, msn, yahoo, and jabber), at least one minor protocol (all
> > the others) and a second account on at least one protocol.  this is 6
> > accounts which would work with a trillian type interface. but i'd want
> > any ui to be expandable to at least 2 accounts per (approx 12-15
> > accounts).
> 
> A few rows of small status icons could work with 15 accounts. The
> problem with that is that it's not readily apparent which icon
> corresponds to which account.
> 
> > status is already far more complex than gaim handles well.  you should
> > be able to sign on to away, sign on to invisible, and ideally even
> > define states wherein some accounts go away and others sign off (or vice
> > versa). obviously a dialog of some sort would have to be used to set up
> > such a status, once such a status control is in place, i'd assume one
> > would replace the "all" option you have below with that, and everything
> > further down would be to display and override the state that status
> > describes.
> 
> The most important problem with your menu is the inability to see the
> current away message. Also, a menu requires at least one click or
> keypress to get the status. There must be a better way, or buddies
> will stay on the buddy list. This can be worked around by adding
> accounts to the buddy list, but isn't that what we're trying to move
> away from anyway? If we resign ourselves to that, we might as well add
> the ability to control the away message and such from the context menu
> of each of these buddy list entries.

this isn't currently possible, gaim has no way of realizing that a given
buddy is equivalent to the account seeing it. it might not be too hard
to add this though.

the away message question is a good one, esp. since some protocols, such
as yahoo, have stricter limits on how long a message can be than others
do, so the current ui fails to adequately provide this as well. 

> 
> There seem to be two conflicting requirements here: one, a way to
> ascertain the status of all the accounts at a glance and to quickly
> set an away message. Two, a way to control all of gaim's status
> functionality. I don't see why these two functions have to be
> presented by the same widget. Some kind of icon system would be ideal
> for the first, while a dialog is the logical choice for the latter.
> 

it seems to me logical that you'd see your own status, realize it nots
what you want, and change it from the same place.

> A dialog would require LESS time to perform certain tasks, especially
> with the layout of the menu you're talking about. To come back from
> away with your menu, the user would go to Away->Account->Back, and for
> each of those ->s, would have to hunt through the menu for the
> particular option he wants. With a dialog, he would bring up the
> away/accounts dialog (control-A) and uncheck the 'away' button (while
> possibly leaving, say, invisible.) When convenient, hitting escape
> should close the dialog.
> 

this is compeling, i've just always considered the case of a single
account change secondary to changing a group of accounts at once. and
i've never liked the restrictions on this that the account dialog
presents, it has no way to group accounts logically.

> What about a predefined group containing all the user's accounts? Gaim
> could also detect if a buddy is in fact a gaim account and provide
> more options in the context menu, such as set away and set invisible. 
> I was thinking about suggesting a split buddy list, with this special
> group in a resizable, separately-scrollable pane at the bottom, but
> that would be horribly ugly.
> 

this is an interesting ui and deserves consideration separate from the
rest of this thread, which is talking about preferences.

> -- 
> "Use what talents you possess: the woods would be very silent if no
> birds sang there except those that sang best." -- Henry Van Dyke
> "Si in Googlibus non est, non est." http://truffula.net:9999/
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=12297
> _______________________________________________
> Gaim-devel mailing list
> Gaim-devel@...
> https://lists.sourceforge.net/lists/listinfo/gaim-devel

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Luke Schierer wrote:
>
> so given that the system tray shouldn't have to be loaded to see your
> own state and further given that opening the accounts dialog shouldn't
> be required, and lastly given that a row of icons on the buddy list
> won't work, where ELSE would you put current state?
>

The way I deal with current state is to have myself added to my buddy
list for each of my accounts, then arranged at the top using the expand
function to make them into a single icon.

I have msn at the top so the single shown icon also gives my msn
friendly name (alias) which is useful to see.

To check my state for other accounts, I just need to move the mouse over
it and wait for it to expand.

- --
Stuart Clark
mailto:stuart.clark@...
http://www.Jahingo.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAjnWi8fzjqiF3TCIRArUCAJ4gtbypTMzjF2FXrSmAl4Zr8aRcwQCdEj6X
JpezVVzHMFoAjgYdl9fMv3w=
=JoUE
-----END PGP SIGNATURE-----

On Tue, Apr 27, 2004 at 09:23:52AM +0200, gabor wrote:
> On Mon, 2004-04-26 at 19:52, Sean Egan wrote:
> > Can we just force everyone to use tabs anyway?  Probably not.  People
> > suck.
> 
> ... the gnome people mostly think that tabs-are-evil....

which perhaps explains why they haven't spent much time fixing the few
flaws they do have. seriously, tabs rock.

luke

> 
> 
> gabor
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=12297
> _______________________________________________
> Gaim-devel mailing list
> Gaim-devel@...
> https://lists.sourceforge.net/lists/listinfo/gaim-devel

On Mon, 2004-04-26 at 21:43, Dan Colascione wrote:

> 
> How many people use something other than top? Especially left or right...
> 

Well since you asked.  I use bottom tabs for gaim.  Mainly because 
of where I keep my conversation window (the bottom of the screen).
Where I put my tabs depends on how I usually lay that window out, but it
is always top or bottom and never left or right.

-travis

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've only commented on stuff I actually use or would affect me...

Sean Egan wrote:
>
> Buddy List:
> Kill "Show buttons as" make default "none."  I never use them and
> wouldn't miss them much.  The away message button is kinda useful
> though.  Thoughts?

I've just changed to "none" from having picture versions. It suits me
without them, mainly as I could do with the extra vertical space (quite
a few buddies in my list), but I liked it too when it was there as well.

>
> Kill "Show aliases in tabs/titles"  I used to be a staunch supporter of
> no aliases in tabs, but I'll give in here and default this to "Yes,
> please."
>

I would really prefer this to be optional soon. Some of my buddies
(mainly msn) have either very long friendly names or ones which are
difficult to work out who they actually are. As a result I turned it off
and now find it less confusing (previously I was getting confused about
who I was actually talking to - especially if they initiated the chat)

> I've been saying for a while (as have the people who ask why they can't
> get their conversations out of tabbed windows) that the tab preferences
> are braindead.  "Show IMs and chats in tabbed windows" doesn't do what
> it says at all.  I want to kill it and force people to look at the tabs
> against their will, but some people on this list care about people who
> aren't me, for some reason ;).  I think Nathan had an idea I was ok
> with... something about graying the option out when no tabs is chosen.
>
> Can we just force everyone to use tabs anyway?  Probably not.  People
> suck.
>

I like having seperate windows per conversation. The few times things
have ended up tabbed (before I switched it off) I have ended up missing
new chats or missing when people say stuff. I know you can drag to make
new windows, but I would definatly prefer them being seperate from the
start.

>
> IMs/Chats, these are mostly the same page, so I'll address them
> together:
> Kill "Show buttons as" default to "none."  I have to admit I really like
> the new "none" look.  I'd consider leaving a send button in, though, for
> people like my mom who actually click the Send button with the mouse
> after every message, but then again, my mom just isn't very smart.
> Opinons?
>

I have kept them on as I do sometimes use them. The best one is add
(especially for irc rooms found using the list rooms window). However,
for IRC at least, clicking on add doesn't seem to fill in the add dialog
with the room name, which it does for 'normal' buddies.

>
> Kill "Hide window on send" default to "No, that's so stupid".  ICQ does
> not have an interface we wish to emulate.
>

I do know some people who end up with so many chats open that they close
as soon as they have sent manually. Then they reply when a new window
opens and close it again.

>
> Kill "Notify buddies that you are typing to them" default to "yes"?  I
> could go either way on that one.
>

I think this has been fairly well covered by others.

>
> Kill "Queue new messages when away" and default to "yes"?  I don't know.
> Everyone hates the "I'm away" window anyway.
>

If you are looking at killing windows, I would much prefer the logon
window (the one with the gaim logo at the top) to go, instead having a
blank buddy window if you are not logged onto any accounts.

- --
Stuart Clark
mailto:stuart.clark@...
http://www.Jahingo.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAjnmg8fzjqiF3TCIRAjaBAJ46vr/KFmWrgcXqKzJcYb/J8HG4pQCfbQ79
UWSy9jqdYurUKeYx9HHuoI0=
=rVR8
-----END PGP SIGNATURE-----

Christian Hammond wrote:
> On Mon, Apr 26, 2004 at 09:34:41PM -0300, Steven Garrity wrote:
> 
>>Even better, I think, would be to follow the Gossip method of setting 
>>status with a always-visible menu at the bottom of the contact list: 
>>http://actsofvolition.com/images/screenshots/gossip_status.png
>>
>>I would also be interested in seeing "Offline" considered a "status", 
>>meaning one flydown could let you choose between "Available", "Busy", 
>>"Away", and "Offline". Choosing anything other than "Offline" could 
>>connect you. Of course, I'm over simplifying, as Gossip is only a 
>>one-protocol client.
>>
>>The Gossip-style status flydown also serves do show you your current status.
> 
> That works because you have one account on one service. I can't see
> that working in the Gaim model all that well.

Good point - it always seems to simple :-)


Steven Garrity wrote:
 > Good stuff all around. I'm so encouraged by this thread that I've
 > written an article about it for my weblog (still being edited - not up
 > yet).

Here's the link to the article. Pardon the self-link, but I thought it 
might be pertinent, as it is flattering to the Gaim developers :-)

http://actsofvolition.com/archives/2004/april/theriseof


Steven Garrity

Since I don't have time to read the whole thread right now, I'll just 
reply now, and you can pretend I was the first person to reply or 
something, and so don't know about the rest of the thread.

Sean Egan wrote:

>Fonts:
>Replace 7 checkboxes, three dialog-spawning buttons, one spin button and
>two colored boxes with, like, a GtkFontSelector and a GtkIMHtml.  Or
>something.  Putting a GtkIMHtml there is definitely useful, but a
>fontselector can't pick colors or underlining, and I'd like there to be
>some way to specify the size without a face and stuff.  Ideas?
>  
>
I was going to suggest an imhtml in msn mode. But you already thought of it.

>Message Text:
>Kill "Show graphical smileys" and put a "No Smileys" option in the
>Smiley Themes selector.
>  
>
At first I thought this was a negative pref, but then I reread it and 
realized it was the name of a smiley theme. Good idea.

>Kill "Show aliases in tabs/titles"  I used to be a staunch supporter of
>no aliases in tabs, but I'll give in here and default this to "Yes,
>please."
>
We should make it easier then to figure out what someone's screen name 
is from the conversation window.
Sometimes I want to paste someone's screen name to someone and can't 
find anything I can select, neither in the conversation window nor in 
the buddy list.

>Can we just force everyone to use tabs anyway?  Probably not.  People
>suck.
>  
>
Sure. As long as we force everyone's tabs at the bottom where they belong.

>Kill "Show status icons on tabs" and default to "OK."  It's useful and
>pretty, and everyone should use it.
>  
>
I like it, but hate how much space it wastes. I'm tempted to give rid of 
the spacing between it and the name. And I want to implement truncating 
the name eventually too. I'm not a screen real estate person, but tabs 
lose their usefulness after they scroll off.

>IMs/Chats, these are mostly the same page, so I'll address them
>together:
>Kill "Show buttons as" default to "none."  I have to admit I really like
>the new "none" look.  I'd consider leaving a send button in, though, for
>people like my mom who actually click the Send button with the mouse
>after every message, but then again, my mom just isn't very smart.
>Opinons?
>  
>
That option is kind of new, maybe we should give people a chance to get 
used to it first?

>"New window width" "New window height" and "Entry field height" need to
>die.  Detect changes in size like we do with the blist and use that size
>to create new windows.
>  
>
Can we actually resize the entry's height with the mouse/keyboard?

>Kill "Show people joining in window" "Show people leaving in window" and
>"colorize screen names" defaulting all to "yes".  I can't really picture
>anyone saying "Man, Gaim's really cool, but I don't use it because it
>tells me when someone joins a chatroom"
>  
>
I think this should be per chat option. In some chats, like 
#gaim-commits, or that htime that Drummer from Metallic did an interview 
on irc.webchat.org, you don't want to see Join/Parts. In most you do.

>Sounds:
>Kill "sounds when you log in" default to "no".  Nobody wants that.
>  
>
The code that implements this is still kind of a hack and is buggy IIRC.


--Tim Ringenbach

On Tue, 2004-04-27 at 12:00 -0500, Tim Ringenbach wrote:
> >Kill "Show buttons as" default to "none."  I have to admit I really like
> >the new "none" look.  I'd consider leaving a send button in, though, for
> >people like my mom who actually click the Send button with the mouse
> >after every message, but then again, my mom just isn't very smart.
> >Opinons?
> That option is kind of new, maybe we should give people a chance to get 
> used to it first?

Let people get used to the option before taking it away?  What's the
point?

> >"New window width" "New window height" and "Entry field height" need to
> >die.  Detect changes in size like we do with the blist and use that size
> >to create new windows.
> Can we actually resize the entry's height with the mouse/keyboard?

Yeah.  The conversation window is paned.  You can drag it up and down in
between the two.

> >Sounds:
> >Kill "sounds when you log in" default to "no".  Nobody wants that.
> >  
> >
> The code that implements this is still kind of a hack and is buggy IIRC.

Howso?  Even if it is, wouldn't it working slightly buggy (I can only
take that to mean it plays sounds *sometimes*) be better than always
playing the sounds?

-s.

Time to give my 2 cents. I think overall I agree with Sean, and the specifics 
that I don't agree were pointed out by other people already. I just want to say
that if gaim takes out a preference and people complain about it, someone can
always put it back. That's the best way to see what preference people use.

-khc