On Sat, 13 Feb 2010, Daniel Atallah wrote:
On Fri, Feb 12, 2010 at 22:40, Dan Mahoney, System Admin
<d...@prime.gushi.org> wrote:
Hey there, I'm noticing an odd behavior with pidgin under ubuntu linux
(whatever version just happens to come with Karmic via apt). In this case
it's Pidgin 2.6.2
(libpurple 2.6.2)
95470d310d5d3a229c0b9fc4232da9bfeafaeb5b
You can (and should) try a newer version (but I don't believe this
issue has been resolved).
This is the newest one in apt. I realize that sometimes ubuntu is slow
to track newer versions, instead opting to remain stable. (This is
laughable to me as I decided to try Karmic, which introduced a number of
regressions to me.) In turn, this is why I bring up the issue here rather
than open a bug immediately.
Would it not make more sense, on an auth fail, to have the system DELETE the
in-memory password (if it's not saved on disk), so you'll simply be
re-prompted?
Yes, I believe that would make sense. I believe the complication is
that we can't necessarily tell that the problem is definitively that
you typed the password wrong - there are other cases under which a
"<not-authorized/>" may be received.
We'll call that option feature request number one. (Delete the stored pass
on an auth fail if it's not saved to disk).
The AIM case above is the only one I can think of (but then, I'm not a
protocol guru). I'd say the best logic might be: if I've gotten an
authfail, and I'm clicking "re-enable" and get ANOTHER auth-fail (while
trying the in-memory password), it's most likely that. (Feature request
number 2).
Would it also not make sense that if I'm editing an account that was ONLY
disabled for an auth fail, that as soon as I click save, it's re-enabled
without having to manually do so?
That would require otherwise unnecessary accounting of the reason for
disabling, so I'd be inclined to say "not worth the effort" for an
exception case. If the other issue (which I consider a bug) wasn't
present this would be a non-issue.
Even if I had had something else wrong (say, my username), there'd still
be a need for the extra trip up to the enable menu once I had saved the
thing.
How about an "enable account now" checkbox in the "edit" dialog box, then?
Or a "save and enable" next to the save? (Number 3).
Also, there's an additional bug that's I may not have made clear from the
above. If, on the "edit account" button, I put a password, but do not opt
to save it, I am still prompted when I enable the account. This means
that the password field in the edit box means NOTHING unless you click
save. Logically, to me, it would mean "save this in memory and use for
sessions until I quit" but not to disk. (Bug #4)
The final bug is that in the current incarnation, there are both a "modify
account" and a "re-enable". I need BOTH, as things are currently set up,
but the dialog disappears after I hit modify. I'm still in a "failed"
state (I'm not signed in). The only reason I'd go to modify the account
is if I wanted to continue using it. Can we keep that dialog box around,
possibly add a little "x" or "dismiss" until I'm enabled? (Feature request
#5)
Is there already a bug open on this issue? I get this on two different
machines, and it seems REALLY bad ui design.
It is more of a bug than bad design.
Feel free to file a ticket (http://d.pidgin.im/newticket), there
doesn't appear to be one already.
As above, it's actually four or five inter-related bugs. Would you (as
someone with more voice for the developers than I) prefer one issue per,
or one monolithic "this interaction all hurts my head, here's how to make
it better" bug?
-Dan
--
"Station!"
-Bill & Ted's Bogus Journey
--------Dan Mahoney--------
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144 AIM: LarpGM
Site: http://www.gushi.org
---------------------------
_______________________________________________
Support@pidgin.im mailing list
Want to unsubscribe? Use this link:
http://pidgin.im/cgi-bin/mailman/listinfo/support
