Community
Participate
Working Groups
A lot of IRC clients have support for commands on usernames listed. Some examples are 'op,voice,deop,etc...' We should aim to do this.
Created attachment 74316 [details] early access I've played a bit with this bug, just to find out which are classes are raesponsible for it. So far there is a popup menu with fake /kick in users list. I'd like to move the irc specific IAction away from presence.ui and fix current /kick action, as currently it throws a StringIndexOutOfBoundsException
Let me check out the patch!
Created attachment 74340 [details] patch forget that, now is fairly better. There is a very small change to ChatRoomManagerView, just to make popup menus available and extensible for others. IRC Provider makes use of this by adding an example Kick action. Still todo: i wonder how to detect if ChatRoomManager really runs IRC session, or not. Kick still fails with some StringArrayIndexOutOfBounds. More actions should be just a piece of cake when I add an abstract action.
Created attachment 74366 [details] org.eclipse.ecf.patch added proper copyrights, refactored ids
Created attachment 74367 [details] mylyn/context/zip
Jacek, I see your problem currently. ChatroomManagerView doesn't support anyway of getting the currently connected container so it's hard to know when to show the proper actions. Scott, does adding code to get the container associated with the chatroommanager view seem reasonable? I can't think of any other way to do this right now.
Actually Jacek, how about we focus on the functionality first and then we look at how to disable the commands. Thinking about this... there's a few ways we can do this in regards to visibility... ie., do we use visibleWhen and some property to test (maybe like currently connected targetId?) I'll open another bug for this as that problem is a bit more advanced.
(In reply to comment #6) > Jacek, I see your problem currently. ChatroomManagerView doesn't support anyway > of getting the currently connected container so it's hard to know when to show > the proper actions. > > Scott, does adding code to get the container associated with the > chatroommanager view seem reasonable? I can't think of any other way to do this > right now. > I haven't had a chance to look at the patch yet, but ChatRoomManagerView.initializeWithManager is passed the IChatRoomContainer (rootChatRoomContainer), which represents the root IRC chat room (irc.freenode.net). If you want/need the IContainer associated with the IChatRoomContainer, then you should be able to simply call IContainer container = (IContainer) rootChatRoomContainer.getAdapter(IContainer.class); But it seems to me that we might want to add API (extension point perhaps) to allow providers to expose arbitrary actions (that they define) off of the CRMV members list items.
Scott, easy extensibility is what I'd like to see too. I was actually expecting to see some more details in IUser, like the fact that it's IRC user, from session X. Following that anyone could simply implement object contribution, that would add actions like "kick", "op", "whois", etc. ewerywhere in UI where this IUser would be exposed. Having that, we could avoid new extension points and keep things simple. Imagine having kick option, whenever you right click on someone :) I'll try your way with IContainer, but first add more actions and make them actually working. Thanks for review Chris!
(In reply to comment #9) > Scott, easy extensibility is what I'd like to see too. We can/will add it. >I was actually expecting > to see some more details in IUser, like the fact that it's IRC user, from > session X. Well, IUser is just the very basics about a user...but it does implement IAdaptable, so we have an ready means to extend what IUser exposes...that is the UI code could be enhanced to do the following: INewInterfaceForUserActions actionsGetter = (INewInterfaceForUserActions) user.getAdapter(INewInterfaceForUserActions.class); if (actionsGetter != null) { // call actionsGetter.someMethodToGetActionsForUser(etc) } Then, providers (that implement IUser) could implement the getAdapter call and provide a way to expose appropriate actions. > Following that anyone could simply implement object contribution, that would > add actions like "kick", "op", "whois", etc. ewerywhere in UI where this IUser > would be exposed. Seems reasonable, but it would be good, I think, to try to have an action framework that allowed for other (non IRC) actions as well...e.g. "call", "send file", etc. > > Having that, we could avoid new extension points and keep things simple. In favor of simplest mechanism that exposes whats needed...and does it in a way that isn't bound to IRC (or XMPP for that matter). > > Imagine having kick option, whenever you right click on someone :) I would prefer to have a 'work on ECF' action on my own entry :).
how about this...
Created attachment 74372 [details] org.eclipse.ef.patch make ChatRoomParticipant implement IActionFilter so you can now use objectContribution visibility to test the scheme of the current IUser It would look like this now... + <extension + point="org.eclipse.ui.popupMenus"> + <objectContribution + id="org.eclipse.ecf.provider.irc.ui.objectContribution1" + objectClass="org.eclipse.ecf.core.user.IUser"> + <action + class="org.eclipse.ecf.internal.irc.ui.actions.Kick" + id="org.eclipse.ecf.provider.irc.ui.action2" + label="Kick" + menubarPath="additions"/> + <visibility> + <objectState + name="scheme" + value="irc"> + </objectState> + </visibility> + </objectContribution> + </extension>
Created attachment 74373 [details] mylyn/context/zip
Seems simpler.
(In reply to comment #12) > Created an attachment (id=74372) [details] > org.eclipse.ef.patch > > make ChatRoomParticipant implement IActionFilter so you can now use > objectContribution visibility to test the scheme of the current IUser > > It would look like this now... > > + <extension > + point="org.eclipse.ui.popupMenus"> > + <objectContribution > + id="org.eclipse.ecf.provider.irc.ui.objectContribution1" > + objectClass="org.eclipse.ecf.core.user.IUser"> > + <action > + class="org.eclipse.ecf.internal.irc.ui.actions.Kick" > + id="org.eclipse.ecf.provider.irc.ui.action2" > + label="Kick" > + menubarPath="additions"/> > + <visibility> > + <objectState > + name="scheme" > + value="irc"> > + </objectState> > + </visibility> > + </objectContribution> > + </extension> > I like the basic idea. I would like to avoid having interfaces in bundle org.eclipse.ecf (IUser/User) or bundle org.eclipse.ecf.presence depend upon interfaces in org.eclipse.ui (IActionFilter), but am fine if in org.eclipse.ecf.presence.ui or via IUser.getAdapter or some such. And isn't org.eclipse.ui.popupMenus sort of UI passe relative to menuContribution?
(In reply to comment #15) > (In reply to comment #12) > > Created an attachment (id=74372) [details] [details] > > org.eclipse.ef.patch > > > > make ChatRoomParticipant implement IActionFilter so you can now use > > objectContribution visibility to test the scheme of the current IUser > > > > It would look like this now... > > > > + <extension > > + point="org.eclipse.ui.popupMenus"> > > + <objectContribution > > + id="org.eclipse.ecf.provider.irc.ui.objectContribution1" > > + objectClass="org.eclipse.ecf.core.user.IUser"> > > + <action > > + class="org.eclipse.ecf.internal.irc.ui.actions.Kick" > > + id="org.eclipse.ecf.provider.irc.ui.action2" > > + label="Kick" > > + menubarPath="additions"/> > > + <visibility> > > + <objectState > > + name="scheme" > > + value="irc"> > > + </objectState> > > + </visibility> > > + </objectContribution> > > + </extension> > > > > I like the basic idea. I would like to avoid having interfaces in bundle > org.eclipse.ecf (IUser/User) or bundle org.eclipse.ecf.presence depend upon > interfaces in org.eclipse.ui (IActionFilter), but am fine if in > org.eclipse.ecf.presence.ui or via IUser.getAdapter or some such. After looking at code...I see...you are having IActionFilter implemented by ChatRoompParticipant (I had forgotten that IUser was implemented by inner class). Seems like this would work nicely then.
yap, I committed the new ChatRoomManagerView to CVS. Jacek, when you have time, update and supply a new patch. You should be good to go now. Sorry, this bug was a bit trickier than I thought initially ;)
cool, thanks Chris! But it looks like we have couple more tricks here :) 1. currently active channel is needed from outside of ChatRoomManagerView. 2. IRCRootContainer.parseCommandAndSend doesn't work as expected. 3. ChatRoomManagerView should update participants view on users status changes. AD1. This is because ie. /kick needs selected user (which we get through ISelection) and channel from which to kick. I see there two options: 1a) get channel from user. This sounds too much hack to me. To get active tab of a view, do: view.getUser.getChannel. User may be on multiple channels so it would be frustrating to have the same user instances for different channels. 1b) get active channel stright from ChatRoomManagerView. This is easy :) (but affects API - not sure if Scott likes this) So I picked 1b) AD2. This is actually a separate bug. Writing on channel anything like: "/kick john", "/op john", "/voice john", etc. doesn't work. So i've created a separate bugzilla + test + patch (bug 197604). AD3. That is open topic now. I'd prefer to work on it, after you accept 1. and 2. Current behaviour is that only kick makes some reaction - output view shows red message like "John was kicked by Frank". Other operations like /op, /ban are not reflected, whereas for example on op/deop user would expect to see "@" appearing/hiding next to affected user name in participants view. Looks like it would help fix also bug 197329 and bug 149912.
Created attachment 74432 [details] 1b + basic irc actions
awesome, evaluating!
thanks, committed to HEAD.
Created attachment 74474 [details] mylyn/context/zip
(In reply to comment #22) > Created an attachment (id=74474) [details] > mylyn/context/zip > Although this seems to be generally working, I'm getting the following in error log everytime I bring up the context menu: Context menu missing standard group 'org.eclipse.ui.IWorkbenchActionConstants.MB_ADDITIONS'. (menu ids = [org.eclipse.ecf.presence.ui.chatroom.participantsView]) part id = org.eclipse.ecf.presence.ui.chatroom.ChatRoomManagerView) Also...it seems as if the right click (context menu) does not actually select the associated menu item...and it probably should. And this may have to do with the error log entries above, but it seems that if I try to select and then do 'whois' on several users, it seems to always do a whois for the first one I selected. Thanks for the good work. It's pretty cool.
I'll check the message. Rightclick indeed doesn't work. It should change selection to the element over cursor. Multiple elements selection support is a good idea too..
Created attachment 74514 [details] almost ok, I almost got it: - mutliple selection will work now - message in error doesn't appear any more - this was caused by missing ADDITIONS element, that was added to context menu in earlier patches, but then has gone accidentally. - rightclick is almost working. It selects element under the cursor, however menumanager still doesn't pick this selection (it takes the last instead). I'll have to investigate it further.
cool, let me know Jacek. I appreciate the effort.
btw, I created 197746 to address UI issues in regards to when these actions should be active (depending on the status of the user in a channel). That bug can be for some other lucky soul :P
Created attachment 74669 [details] patch all is working now. I've changed participants ListViewer to TableViewer, following this suggestion: http://dev.eclipse.org/newslists/news.eclipse.platform.swt/msg10890.html This enables us for more fun, like images, etc. Let me know if you're okay with table.
looks good, committed to HEAD. Thanks Jacek!
(In reply to comment #28) > Created an attachment (id=74669) [details] > patch > > all is working now. > I've changed participants ListViewer to TableViewer, following this suggestion: > http://dev.eclipse.org/newslists/news.eclipse.platform.swt/msg10890.html > > This enables us for more fun, like images, etc. > Let me know if you're okay with table. > Looks good. Thanks Jacek. I've added you to the ECF IP log for this contribution (http://www.eclipse.org/ecf/ip_log.html). Jacek would you like to be added to the team page as contributor? http://www.eclipse.org/ecf/team.php
Sure! if you even could make it a link to http://eclipser-blog.blogspot.com/ that would be terrific.
(In reply to comment #31) > Sure! if you even could make it a link to http://eclipser-blog.blogspot.com/ > that would be terrific. > Done. And welcome aboard!
(In reply to comment #32) > (In reply to comment #31) > > Sure! if you even could make it a link to http://eclipser-blog.blogspot.com/ > > that would be terrific. > > > > Done. And welcome aboard! > Also, BTW, I just committed to HEAD some additions to that when system text (e.g. whois response, preceeded by whois menu selection) is output that the tab title (irc.freenode.net) is highlighted so that users can see that a response was received.
Closing. In ip log.
