On Sun, Nov 20, 2005 at 10:29:22PM -0500, 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 don't want to delay 2.0.0 on -vv stuff. I want to get a release
out the door with the other changes. It would make many things
considerably easier from a support perspective.
This is in many respects going to be a nightmare release with or
without -vv stuff. People are, at this point, going to be upset if
its totally absent, upset if it isn't 100% functional, and upset if
it is hard to get working.
Additionally, at least some users are going to be upset at the UI
changes. Many, even if not upset, will have questions related to it.
In many respects, I'd rather deal with this second group than add in
-vv to the mix. I suspect that it will be easier to handle the "why
is there no -vv" questions than to answer the "why is it not working"
questions or the "why does it not do xyz" questions.
But that's just me. feel free to veto.
>
> 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?
That sounds good to me.
>
> 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.
They certainly aren't ideal right now. Of course, they aren't quite
what we discussed either. The idea was to have one for each account
not matching the global status. Not to have one for each account
period.
If we get rid of them, we need some replacement UI to display _which_
account had that read error, and to display what, exactly, the full
error message says. We, from a support perspective, MUST have some
way to ask the users this. I suspect that it would be easier to make
the individual account UI do this than to make some alternative work.
Secondly, we did in the state creation dialog finally enable an
ability to create a complex state in which different accounts have
different presences. We do need some way to display this, or we have
kind of missed part of the goal of this effort, to avoid the need to
have yourself in your buddy list.
Thirdly, while not strictly necessary, it is nice to be able to
_force_ an account to be an exception. The current UI allows this,
but at a very high price, the confusion you mention above.
My suggestion is to get some code in place to detect when an account
is _not_ an exception and to reduce such accounts to a very small
display at the bottom of the list. I'd suggest we _not_ have the
list be statically ordered, but specifically resort it as necessary
to achieve this. We'd thus minimize the confusion factor.
My second, alternative, suggestion is to drop the support for #3
above, but retain the individual selection for the purposes #s 1 and
2 above. Don't display them at all for accounts that are not in some
exception or error state. Reduce the menu for such accounts to a
"return to global" state selection. Leave the message box, but make
it uneditable. This makes the space almost purely a display space,
and not really a control space, and should thus remove much of the
confusion.
>
> 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)
mmm. my first suggestion is more or less 'a', but my other is none of
these. its more of a 'd'
>
> 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?
if we can make the status the stuff mentioned here work well. I also
want http://faceprint.com/gaimwiki/index.cgi?ShowStopperBugs
to be fixed before release, but I think the current list is not too
bad for a beta release.
>
> 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.
That sounds good. I don't want the string freeze any shoter than
that though.
luke
>
> -Mark
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
> Register for a JBoss Training Course. Free Certification Exam
> for All Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
> _______________________________________________
> Gaim-devel mailing list
> Gaim-devel@...
> https://lists.sourceforge.net/lists/listinfo/gaim-devel
>
|
