Mikael Hallendal wrote:
So IMO in these cases it would be nice if there was some 'Client UI
design best practices'-guide :D
The fact that you are sending over Jabber shouldn't enforce anything on
your UI. I think however that it's very important to have rules on how
to behave with other clients
This was one of the items ive always had an opinion on, since the very
first day I started jabber development.. Ive tried 4 different
approaches to this method now... And just from my point of view what im
doing now is fairly efficient... In the original Rival, i didnt really
cater for
fre 2003-11-07 klockan 18.23 skrev Daniel Chote:
This was one of the items ive always had an opinion on, since the very
first day I started jabber development.. Ive tried 4 different
approaches to this method now... And just from my point of view what im
doing now is fairly efficient... In
Justin Karneges wrote:
On Wednesday 05 November 2003 02:03 pm, Mikael Hallendal wrote:
This sounds like a work-around that the user has to handle himself
everytime. This is really hard to solve in a nice way, other IM systems
don't have the problem since they don't allow multiple logins.
Hmm, IMO
tor 2003-11-06 klockan 11.06 skrev Bart van Bragt:
Hi!
Hmm, IMO this is one of the implementation issues that should be at
least mentioned in the specs. It's _very_ confusing for the user if
different clients behave differently in this respect. I'm not saying
that some behaviour should
Bart van Bragt [EMAIL PROTECTED] wrote on 06/11/2003 10:06:12:
So IMO in these cases it would be nice if there was some 'Client UI
design best practices'-guide :D
well, there's the Jabber Client GUI Design page [ http://www.yabber.
org/design/ ], but personally i think that it would be a good
Hi!
Ralph bugged me about Gossip not handling resources correctly when
chatting with a person that is logged in with multiple resources.
According to the spec we don't but I'm a bit unsure on how to handle
this in a way that both conforms with the spec and is good for the user
interface.
The
Mikael Hallendal wrote:
ons 2003-11-05 klockan 19.14 skrev Joe Hildebrand:
There have been clients in the past that always sent to the [EMAIL PROTECTED] jid
(which is what you are suggesting), and user-experience-wise, they aren't
great, since some of the messages in a conversation end up
On Wednesday 05 November 2003 10:50 am, Mikael Hallendal wrote:
Any suggestions on how to handle this then? For example, I change
computers and goes to my laptop, my desktop client is set to away (by
autoaway or manually setting it to away), I log into my laptop. My
friend who I where chatting
ons 2003-11-05 klockan 21.40 skrev Justin Karneges:
The solution is to inform others where you actually are. ;-)
Just because you recently signed on with another resource does not
indicate that you are physically there. If you have a laptop and a
desktop both connected to Jabber with
, 2003 3:03 PM
To: Jabber Devel List
Subject: Re: [JDEV] Chatting with the correct resource
ons 2003-11-05 klockan 21.05 skrev Peter Millard:
This stuff has come from experience of the jabber community (client
writers mostly). Not from a marketing droid survey of some kind.
So it's
On Wednesday 05 November 2003 02:03 pm, Mikael Hallendal wrote:
This sounds like a work-around that the user has to handle himself
everytime. This is really hard to solve in a nice way, other IM systems
don't have the problem since they don't allow multiple logins.
The bottom line is that it
practices based on
real use patterns that we've seen.
--
Joe Hildebrand
-Original Message-
From: Mikael Hallendal [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 05, 2003 10:00 AM
To: Jabber Devel List
Cc: [EMAIL PROTECTED]
Subject: [JDEV] Chatting with the correct resource
To: Jabber Devel List
Cc: [EMAIL PROTECTED]
Subject: [JDEV] Chatting with the correct resource
Hi!
Ralph bugged me about Gossip not handling resources correctly
when chatting with a person that is logged in with multiple resources.
According to the spec we don't but I'm a bit
ons 2003-11-05 klockan 19.14 skrev Joe Hildebrand:
This is one of those things that is a little counter-intuitive. The
language that's in the spec is correct, particularly when combined with
the rule that if a message is sent to a non-existent resource, it gets
delivered as if it has no
15 matches
Mail list logo
