Bugzilla – Full Text Bug Listing
| Summary: | [ui] Chatroom view is bound to a single perspective | ||
|---|---|---|---|
| Product: | [RT] ECF | Reporter: | Remy Suen <remy.suen> |
| Component: | ecf.ui | Assignee: | ecf.core-inbox <ecf.core-inbox> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | bokowski, caniszczyk, d_a_carver, pombredanne, pwebster, slewis |
| Version: | 1.0.0 Release | ||
| Target Milestone: | 2.1.0 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | 154121 | ||
| Bug Blocks: | |||
|
Description
Remy Suen
I'd like to note that you can solve this by customizing your perspective to add the menus to the toolbar....but that's just lame. (In reply to comment #1) > I'd like to note that you can solve this by customizing your perspective to add > the menus to the toolbar....but that's just lame. > Well, that's Eclipse for 'ya :). I don't think we are supposed to add UI/widgets to other existing perspectives *without* having the user customize the perspective. But may be wrong about that. Note that if you 1) add the connect widgets via the Window->Customize Perspective...->Commands (tab)->Communications (check box) 2) Choose Window->Show View->Other...->Communications->Chats (view) Then subsequent IRC views connected in that perspective will show in that perspective. (In reply to comment #2) > Then subsequent IRC views connected in that perspective will show in that > perspective. Well, that's precisely the problem. The view only appears in that perspective. If I switch perspectives, the view remains in the previous perspective. So if I switch to 'Debug', I can no longer see the IRC window. I've changed the summary to better reflect the issue at hand. (In reply to comment #3) > (In reply to comment #2) > > Then subsequent IRC views connected in that perspective will show in that > > perspective. > > Well, that's precisely the problem. The view only appears in that perspective. > If I switch perspectives, the view remains in the previous perspective. So if I > switch to 'Debug', I can no longer see the IRC window. > > I've changed the summary to better reflect the issue at hand. > AFAIK, there is no way to move an existing non-singleton view to another perspective. If there is a way to do this, then we can deal with the bug. If not, I'm not sure what we can do about it. I guess the way out of this is to rehash the UI and/or change it a la bug #181507. (In reply to comment #5) > I guess the way out of this is to rehash the UI and/or change it a la bug > #181507. > I don't see how doing work on bug #181507 will particularly address this bug, as the Chat view instances are associated with accounts. Even with work on bug #181507 that will still have to be addressed. I think we either need to a) make the chat room view a singleton view (and somehow have it manage multiple accounts). This is not at all preferable, in my view, because it means more mechanism and UI to manage multiple accounts within the single view. b) figure out how to have a non-singleton view move from one perspective to another. If this is possible via API then we could easily add UI for it...as Eclipse out-of-box doesn't seem to allow it (?), but I'm not immediately sure of whether its programatically possible either. (In reply to comment #6) > I don't see how doing work on bug #181507 will particularly address this bug, > as the Chat view instances are associated with accounts. Even with work on bug > #181507 that will still have to be addressed. I was thinking maybe if you just double-clicked on a chatroom on that list, it'll show that view up. The view's clearly there because if you switch back to the other perspective, the view is alive and well and not closed. So surely there must be a way to have it show up in the other perspective as well. Paul, can you comment on this one at all? I need help from the workbench gods and I have nothing to offer for a sacrifice :( I think that page.showView("id", "secondary", flags) should open an existing multi-instance view in your current perspective ... is this not the case? The question just becomse how to allow the user to request the existing view in his current perspective.
How were you opening the original multi-instance views?
The show view command currently only takes a primary viewId (auto-generated in the Keys pref page) ... we are considering adding the secondary ID to it, although I'm not sure how to bind those correctly.
PW
Could this be solved similar to the Console view? If you just open the Console view without passing a secondary ID, you see the console contents if there is just one console, or you can switch between available consoles using a dropdown in the view toolbar. In addition to this, there is a way to pin the currently selected console, so that a new view will be opened when you try to switch to another console. At this time, a view with a secondary ID will be opened. Currently, you would have to implement this yourself (toolbar item, multi-instance view management logic, pin action). Because clients seem to have to implement this over and over again, the Platform UI team is looking at adding support for multi-instance/multi-page views like this. I cannot promise anything for 3.4 though as I don't know if we will have the resources/time to do this. My apologies for not being able to respond sooner to this and comment #9, I've been occupied with other things. (In reply to comment #10) > Could this be solved similar to the Console view? If you just open the Console > view without passing a secondary ID, you see the console contents if there is > just one console, or you can switch between available consoles using a dropdown > in the view toolbar. In addition to this, there is a way to pin the currently > selected console, so that a new view will be opened when you try to switch to > another console. At this time, a view with a secondary ID will be opened. Yes, it probably could be done this way. Although I like the general idea, I'm a little concerned about scaling and usability, as I find the way that the console works when lots of processes (channels for us) are all writing to std out (channel output widget) somewhat confusing since they switch back and forth (not pinned). I think this could be worse when, say 5+ channels, are presenting chat output simultaneously. But there are other, better ways to visually represent such changes for chat viewer...like having the default to be 'pinned', and present notification of reception of messages in non-visible channels through some other mechanism (e.g. popups like ECF MessagesView, etc). > > Currently, you would have to implement this yourself (toolbar item, > multi-instance view management logic, pin action). Because clients seem to have > to implement this over and over again, the Platform UI team is looking at > adding support for multi-instance/multi-page views like this. I cannot promise > anything for 3.4 though as I don't know if we will have the resources/time to > do this. This would clearly help with our use case: multi instance (e.g. accounts...IRC, XMPP, others), multi-page (IRC channels, XMPP chat rooms, IM 1-1 chats). I think this could also help us provide a more general solution for bug 183027 and bug 198110. So FWIW: +1 in such directions. Scott Boris / Platform UI ninjas, is there a bug open on this request? I'm so stupid, I totally forgot about the console view. See Bug 154121. Setting target milestone to 1.2 Assigning to zx and setting dependency on bug #154121. Setting target milestone to 2.1 I was thinking about the following. As soon as a chatroomview is open, we put a contribution on the status trim. The contribution is a drop-down icon menu similar to the "Run Launch" and "Connect to IM provider" menus. As soon as all chatroomviews are closed, this contribution disappears. Obviously, the appearance of the menu can be controlled by the preferences, much like the "show heap status" preference setting. This would also enable us to decorate the icon when actions appear in the view (e.g. new message) to notify the user of state change. Resolving as invalid as I think with all the platform changes (and ECF changes) this is no longer valid. |