Re: [Gaim-devel] Gaim 2.0.0

[Etan R. <de...@ed...>]

On Sun, 20 Nov 2005, Mark Doliner wrote:

> Me again!
>
> Gaim is looking good.  There are a few things we should talk about before we
> can release a beta.
>
> 1. Voice/video
> It seems like the general concensus is that we won't delay Gaim 2.0.0 for
> anything related to voice/video, and we probably won't release Gaim 2.0.0 with
> support gstreamer or with support for voice/video for any protocol other than
> Google Talk.  And if our Google Talk support is causing problems then we'll
> "#if 0" it or something.  The iLBC license incompatability is currently a
> major concern to me.  Does anyone disagree with any of this?

I've got nothing to say about any of this.

> 2. Ability to specify the idle-away status
> We still need a UI for selecting the idle-away state (all the backend code
> should be working fine).  I'm fine with having a dropdown in prefs to select
> one of the saved statuses.  Does anyone have a better idea?

Sounds fine to me, though it would probably make sense to have the 
regular global statuses as well as the saved ones. (Unless that's what 
you meant.)

> 3. Per-account status boxes
> I personally don't like them.  I think they hurt more than they help.  They
> clutter the bottom of the buddy list, they're distracting, they take up a lot
> of room, and they're a little confusing.  I don't think I've ever set a
> different status for an individual account.  I don't think the functionality
> will be used very often, and I think it's unnecessary to have it at the bottom
> of the buddy list.
>
> Please vote:
>  a. keep them! (and make sure everything works perfectly)
>  b. remove them! (and figure out a better way to display account disconnected
> messages)
>  c. keep them! (and add a 'Save' button)

I vote for c.

I like the per-account status boxes as an interface to per-account 
status control. I do think they are way too imposing and confusing to be 
there all the time though. I think we should hide them for any global or 
saved status, and only show them when the status is Custom. If we then 
add a 'Save Status' button it would be much more obvious what the point 
of the per-account selectors is, as well as giving people a very simple 
way to create all the custom statuses they want.

I was also thinking that we would then fall into 'Custom' when we get an 
error or some other connection disruption. Which would immediately 
indicate that something was wrong as well as allowing for the very easy 
'fix' of just selecting the correct global status.

> I'll be out of town Wednesday through Saturdayish.  You guys have done an
> awesome job of not falling too far behind in my totally unreasonable schedule.
> If we deal with everything above, do you think we can release a beta on
> Monday the 28th?
>
> We should have a 4 week string freeze before we release.  If we freeze on
> December 2nd we can release by the end of the year.
>
> -Mark

I have a bunch of outstanding changes in my tree that I need to finish, 
but which I think should really make it in to 2.0.0.

Also there is still the matter of the /command debate, which if we want 
to do something about should really happen for 2.0.0 (or 3.0.0 whenever 
we do that).

I'm heading up to Mass. Wednesday night and I'll be back Saturday. So 
assuming things at work don't get too crazy I think a beta on the 28th 
is doable. I'm not sure we want to string freeze so soon after the beta, 
I think a one week string "chill" followed by a 3 week freeze (assuming 
we want to make the new year) might be a better idea. (To give the beta 
people some time to report on bugs, or unclear language, etc.)

 	-Etan