[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] "Buddy List" ViewPart discussion...
|
Remy and all,
While working on a simple contact manager I felt that the use of a
standard SWT Tree was too limiting and thus started to create a custom
widget to help. This widget is presently named CTableTree (though I'm
thinking of a rename to FormTree to better reflect its intended use),
and is part of the Eclipse Nebula project:
http://www.eclipse.org/nebula/widgets/ctabletree/ctabletree.php
I think this widget could help create a better UI for ECF, as is being
discussed here. I have only been partially keeping an ear to the ECF
newsgroups/mailing lists because widgets have been keeping me busy, but
I could see the picture Remy refers to at,
http://www.eclipse.org/ecf/images/screens/buddy_list_expand.png, being
changed so that each buddy (contact) could be implemented something like
the contacts shown here: http://www.aspencloud.com/screenshots.php (the
upper left view). An interesting (IMHO) point regarding this contacts
list is that each contact channel (phone, email, etc) is contained by a
custom cell which can be created specifically for its type of channel,
and others can be created for new channels at later points in time (in
other plugins as well).
I don't have much time to describe it further right now so I hope this
isn't too cryptic, but in general, if this looks like it might work well
for the ECF UI, I would be interested working with you all.
cheers
jeremy
Remy Suen wrote:
Hi everyone,
I'd like to solicit some feedback on the "Buddy List" of the new UI
that's going to be developed. I'm going to paste a part of Eugene's
comment from the 'Application Refactoring' wiki article/bug 106562's
comment #13 [1] here.
"Buddy list should always show list of buddies (no matter if connected
or offline), and should allow add/remove buddies either manually or
programmatically (i.e. sync up with remote buddy list like it is now
with gtalk)."
I don't think the first point should be too difficult, it'll probably
be a matter of caching the current user's contacts somewhere. Things
gets a little iffy if providers gets removed from the plugins folder,
so I guess we'll need to figure out a good way to identify which
account should be displayed. Adding/Removing buddies will be a
question of whether the protocol implementation supports this, but I
guess it's highly unlikely that we'll make IM providers based on a
library that doesn't support something so simple. The synchronization
bit also depends on the underlying implementation.
In MSN (certainly for versions 6.0 to 7.0, I don't know about the
recent ones, but I doubt its protocol has changed in this area, it's
almost been a year since I worked on my MSN implementation), when you
connect to the server, you send a timestamp, if yours is older, you
will be sent an updated list. This would happen if you logged onto
your account at a friend's computer after just having added a new
contact back at your own place a few days ago. Protocol
implementations would probably either have some kind of a
setLastLoginTime(Date) method or it might just "not support this" and
always send an old timestamp, say, a year ago, which would likely
ensure that you'll always be sent an up-to-date one. The
implementation would do the parsing, so I don't think this really
requires any work on ECF's part other than storing a date (if
necessary).
"Roster may also allow to group/tag users (i.e. per IM server, or per
linked project)"
This may get a little iffy since there's the non-virtual/virtual
problem of whether it gets propagated to your account's information or
not. If it's virtual, then okay, if you have a friend on Jabber and a
friend on MSN and you make a group and name it 'project X' is fine and
all. But if both your friends are on Jabber and you link them to
project X, then you logon to Gaim or something and you don't see a
project X group in your Jabber account, you're going to be scratching
your chin over this. I'm not really sure how to approach this right
now, personally.
"and somehow allow other plugins to show additional info (e.g. mylar
could show what task user is working on and stuff like that). And of
course all the buddy attributes should be available to the plugins, so
they could use registered buddies for their own needs (i.e. complete
users in Mylar editors and or show if user from CC list is online)."
I'm not sure if "additional info" and "attributes" means the same
thing here, but if we're talking about the information that's
presented in [2], I think this could get _very ugly_. So I'm curious
as to whether anyone else has any bright ideas on how to show
additional information. Tooltips kind of works but again, it can only
go so far, especially if everyone and their grandmothers starts using
this extension point. I don't really like the idea of using a
'Properties' dialog via Shift+Enter since nobody likes modal dialogs.
And who wants to popup something that big if they just wanted to see
what their friend's "away message" was? Maybe we could compromise and
put presence stuff in a tooltip and extensions goes in properties?
That still doesn't sound very good to me personally though. For
providing the attributes to other plug-ins for querying purposes, I
guess maybe we can return a List or a Map?
For instant messaging, do people think that we should use a new Shell
+ embedded tabs (like Gaim), or have it as a ViewPart (with tabs also
of course)?
[1] - https://bugs.eclipse.org/bugs/show_bug.cgi?id=111218#c13
[2] - http://www.eclipse.org/ecf/images/screens/buddy_list_expand.png
Regards,
Rem
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
