[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] shared editing design thought

Hi Remy,

Yeah, it is related to this code.  No, it's not a mis-commit.

I could not find a way to dynamically create/add command IDs to the ICommandService (I think)...so these commands are declaratively defined, and then used dynamically in the Roster Menu (i.e. the dynamic code uses the existing commandIDs).

I found it strange that it didn't seem possible with menuContributions to create/add command ids dynamically, and asked Paul Webster about/complained about it in IRC, but it doesn't seem to be possible (creating adding command ids programmatically).  I did try the dynamic menu creation without declaring these command ids (to see if command ids would be implicitly created), but it didn't work.

In any event, if you know of or find a way to have this code (AbstractRosterMenuContributionItem.createContributionItemsForEntry) work without these declarations then please let all know.

Scott


Remy Chi Jian Suen wrote:
Is this plugin.xml change related to this code?
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ecf/plugins/org.eclipse.ecf.presence.ui/plugin.xml?root=Technology_Project&r1=1.22&r2=1.23

Looks like a mis-commit.

On 10/30/07, Mustafa K. Isik <isik@xxxxxxxxxx> wrote:
  
Good Stuff.

I'll try it out once I am home ...

On Oct 30, 2007 6:08 PM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
    
 Hi Folks,

 I've added some classes to create 'Roster Menus' as per the original
posting on this thread.  I put up a new wiki page describing this and
showing a quick test/demo here:

 http://wiki.eclipse.org/Roster_Menus

 It's pretty cool, I think, as it would allow easy addition of arbitrary
communications to existing editors, views, etc.

 Any thoughts/comments, etc are appreciated.

 Scott

 Scott Lewis wrote:

 Hi Chris,

 Chris Aniszczyk wrote:


+1

 This work will probably encompass taking some of the roster information
offline which is a good thing.
 I don't really expect so at this point...as even if the roster information
is available persistently offline, it doesn't make much sense to expose
actions/commandhandlers (like share current editor with soandso, etc)
because the actions are generally worthless when offline (e.g. you can't
start a shared editing session with a user that is offline).




If I have some spare cycles I would love to help.

 That would be great.  I think the trickiest bits will have to do with
setting/resetting the command handlers dynamically (with the IServiceLocator
I guess).  I expect you, Remy, and Boris have more knowledge of this than I
do so anything that shows doing this sort of thing (creating menus
dynamically, and assigning actions to dynamically constructed items) would
be helpful.





 I also noticed that ECF hasn't submitted anything to EclipseCon yet :)
 https://eclipsecon.greenmeetingsystems.com/submissions

 I noticed that too.  I will be submitting something...probably around
remote OSGi services and/or ECF overview, but I haven't decided what.

 I hope that we can get other submissions from committers...i.e. around
topics such as

 RT Shared Editing
 Presence and IM APIs
 Bots
 Committer Community, IRC, XMPP, and Communication
 Discovery
 VOIP
 Others of interest...

 These are just some ideas.  I imagine others have other ideas as well.

 Scott






 Cheers,

 ---
 Chris Aniszczyk | IBM Lotus | Eclipse Committer |
http://mea-bloga.blogspot.com | +1.860.839.2465

 Scott Lewis ---10/27/2007 06:07:45 PM---Hi Folks, We at BEA have/will/are
doing some work with using ECF to add real-time



 From:
 Scott Lewis <slewis@xxxxxxxxxxxxx>

 To:
 "Eclipse Communication Framework (ECF) developer mailing list."
<ecf-dev@xxxxxxxxxxx>

 Date:
 10/27/2007 06:07 PM

 Subject:
 [ecf-dev] shared editing design thought ________________________________



 Hi Folks,

 We at BEA have/will/are doing some work with using ECF to add real-time
 shared editing to commercial and OS editors...i.e. text editors,
 structured editors (e.g. java, other langs, xml, etc), graphical
 editors, and the like.

 I was thinking yesterday was that it is typically unnecessarily
 difficult to setup a sharing/editing session.  It usually has to be
 explicitly done by one or both participants prior to the actual shared
 editing...and it's often error prone.

 This is true also of the existing cola shared editor...the setup of the
 shared editing session is kind of cumbersome.

 I had one thought about how this could be easier...and I thought I would
 throw it out to the mailing list:

 Let's assume that user 'slewis' has a (e.g.) text editor open.  At a
 certain point, they decide that they would like to initiate a shared
 editing session with another party (e.g. 'codesurgeon').  At that point,
 'slewis' has to initiate a shared editing session.

 What if they simply opened the editor's context menu, and chose
 'Share'->codesurgeon...and this initiated a shared editing session with
 codesurgeon.  This begs the question, though...where does the
 'Share'->codesurgeon menu come from?  My answer:  Using Eclipse's new
 dynamic menu contribution mechanisms, it could be dynamically created
 from the ECF Contacts/buddy list.  That is, when the user chose 'Share'
 it could produce a menu hierarchy that corresponded to the entries in
 the contacts list (whatever the active ones happened to be at that
 moment)...allowing the initiator to choose the target user for the
 shared editing session.  The Eclipse menu contribution mechanisms should
 allow this (i.e. dynamic creation of hierarchical menus...plus the
 ability to retarget actions), and ECF allows programmatic access to the
 buddy list via IPresenceContainerAdapter.getRosterManager().   Further,
 it would be possible to add such a thing in a new plugin (rather than
 modifying the existing editor's code) to increase separation of concerns.

 Any thoughts/comments about this approach?

 Scott







 Let's also




 That is,  between...perhaps one way on how to setup a 'session for
 shared editing' (between 2 participants is initial focus...2+ will
 probably be for later).


 _______________________________________________
 ecf-dev mailing list
 ecf-dev@xxxxxxxxxxx
 https://dev.eclipse.org/mailman/listinfo/ecf-dev


 ________________________________

_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev


 ________________________________


_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev



_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev


      
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev

    
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev