Bugzilla – Full Text Bug Listing
| Summary: | [Compatibility] View's content description is non-existent | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] e4 | Reporter: | Remy Suen <remy.suen> | ||||
| Component: | UI | Assignee: | Project Inbox <e4.ui-inbox> | ||||
| Status: | RESOLVED WORKSFORME | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | darin.eclipse, emoffatt, gheorghe, Lars.Vogel, susan | ||||
| Version: | 1.0 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | 322889 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
|
Description
Remy Suen
What do we want to do here exactly? This concept doesn't really exist in the model. One could argue that it's an MPart's tooltip though that feels kind of weird. Where should the label control go? Should it be merged with the toolbar as it did in 3.x or should it just be on a new line? (In reply to comment #1) > What do we want to do here exactly? This concept doesn't really exist in the > model. One could argue that it's an MPart's tooltip though that feels kind of > weird. I agree that's weird. I thinkthe existing word "description" is accurate. Some views use it as a summary, (search, problems), others use it as a heading or label (history). The fact that it changes dynamically makes it seem very untooltip to me. > > Where should the label control go? Should it be merged with the toolbar as it > did in 3.x or should it just be on a new line? I would vote for new line. And I would vote for renderer implementing it vs. stuffing it into CTabFolder. I realize we already made the leap of having CTabFolder get into the toolbar business, but do we need to keep pushing new function into it? To me, it conceptually belongs in the renderer, and if we just allow it to have its own line, it will be trivial to implement. We could at least start out with this approach to get the model attribute defined and something up and running. We can see in practice how often we get the scenario where we could have saved the space. If it becomes a big deal, we can revisit. (Note that in 3.x, the search view implements its own description area to force it to its own line anyway) (As a side note, we'll want to style attributes of this area. In the design mockups, Linda removed the border separator between the description and the content area.) Bogdan, what do you think? Do you feel strongly that it *should* be part of CTabFolder? It depends on what look we want. Currently in 3.6 when menus overflow, they merge with the status line. Since we're going to most likely keep the menu wrapping code (albeit with a better API) in CTabFolder, we would need to add some concept of a header control to allow for merging on the same line. I personally think that having CTabFolder handle the status line is too much - it's a lot of code for something that would not be used by all users of CTabFolder. If we can live with the status line residing on a lower line than the menu, I would vote to have the renderer provide the status line. (In reply to comment #3) > I personally think that having CTabFolder handle the status line is too much - > it's a lot of code for something that would not be used by all users of > CTabFolder. If we can live with the status line residing on a lower line than > the menu, I would vote to have the renderer provide the status line. I think we should try this approach and see what the reaction is. It's easier to implement and we can get feedback. Regardless of what happens, it seems like we will need something in the model to support this. I have opened bug 322889 for this matter. *** Bug 325646 has been marked as a duplicate of this bug. *** There's a reason that we put the Toolbar (including wrapping) directly into the CTF, the 3.x mechanism was a complexly hand-crafted dance between the CTF and the ViewForm widget. While I agree that we don't want the CTF's capabilities to explode I can't see that the addition of the description being anywhere near as difficult as determining the tab sizes... What's the alternative? How do you see the renderer being capable of doing this without CTF support? If we use a ViewForm we only have two choices; one per CTF or one per (rendered) tab. The latter doubles the number of widgets needed to support a part while the former causes the tab selection to become quite complex (we'd have to set the newly activating tab's control to be the 'shared' ViewForm and then reparent the part under the VF). Also, now that we've made the CTF include its own mechanism to replace its look would we now have to also replace the ViewForm with 'renderable' version? Created attachment 179882 [details]
Patch that shows part content descriptions
This patch manipulates the Composite we create in ContributedPartRenderer to allow it to have a display area for the description if it's ever set...
Committed in >20100929. Applied the patch. The 'Console' view has become unusable. java.lang.ClassCastException: org.eclipse.swt.widgets.ToolBar incompatible with org.eclipse.swt.widgets.Label at org.eclipse.e4.ui.workbench.renderers.swt.ContributedPartRenderer.setDescription(ContributedPartRenderer.java:71) at org.eclipse.ui.part.WorkbenchPart.internalSetContentDescription(WorkbenchPart.java:453) at org.eclipse.ui.part.WorkbenchPart.setContentDescription(WorkbenchPart.java:437) at org.eclipse.ui.part.ViewPart.setContentDescription(ViewPart.java:154) at org.eclipse.ui.internal.console.ConsoleView.updateTitle(ConsoleView.java:238) at org.eclipse.ui.internal.console.ConsoleView.showPageRec(ConsoleView.java:184) at org.eclipse.ui.part.PageBookView.createPartControl(PageBookView.java:490) at org.eclipse.ui.internal.console.ConsoleView.createPartControl(ConsoleView.java:570) at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.createPartControl(CompatibilityPart.java:97) at org.eclipse.ui.internal.e4.compatibility.CompatibilityView.createPartControl(CompatibilityView.java:73) at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.create(CompatibilityPart.java:191) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:618) at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:52) at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:796) at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:776) at org.eclipse.e4.core.internal.di.InjectorImpl.inject(InjectorImpl.java:104) at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:292) at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:219) at org.eclipse.e4.core.contexts.ContextInjectionFactory.make(ContextInjectionFactory.java:152) at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.createFromBundle(ReflectionContributionFactory.java:90) at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.doCreate(ReflectionContributionFactory.java:64) at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.create(ReflectionContributionFactory.java:53) at org.eclipse.e4.ui.workbench.renderers.swt.ContributedPartRenderer.createWidget(ContributedPartRenderer.java:56) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createWidget(PartRenderingEngine.java:581) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:423) at org.eclipse.e4.ui.workbench.renderers.swt.ElementReferenceRenderer.createWidget(ElementReferenceRenderer.java:69) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createWidget(PartRenderingEngine.java:581) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:423) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:499) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$1.handleEvent(PartRenderingEngine.java:119) at org.eclipse.e4.ui.services.internal.events.UIEventHandler.handleEvent(UIEventHandler.java:41) at org.eclipse.equinox.internal.event.EventHandlerWrapper.handleEvent(EventHandlerWrapper.java:188) at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:198) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148) at org.eclipse.equinox.internal.event.EventAdminImpl.dispatchEvent(EventAdminImpl.java:139) at org.eclipse.equinox.internal.event.EventAdminImpl.sendEvent(EventAdminImpl.java:78) at org.eclipse.equinox.internal.event.EventComponent.sendEvent(EventComponent.java:39) at org.eclipse.e4.ui.services.internal.events.EventBroker.send(EventBroker.java:73) at org.eclipse.e4.ui.internal.workbench.UIEventPublisher.notifyChanged(UIEventPublisher.java:58) at org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify(BasicNotifierImpl.java:380) at org.eclipse.e4.ui.model.application.ui.impl.UIElementImpl.setToBeRendered(UIElementImpl.java:288) at org.eclipse.e4.ui.internal.workbench.ModelServiceImpl.bringToTop(ModelServiceImpl.java:222) at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.activate(PartServiceImpl.java:412) at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.activate(PartServiceImpl.java:388) at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.showPart(PartServiceImpl.java:726) at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.showPart(PartServiceImpl.java:793) at org.eclipse.ui.internal.WorkbenchPage.busyShowView(WorkbenchPage.java:708) at org.eclipse.ui.internal.WorkbenchPage$7.run(WorkbenchPage.java:2627) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) at org.eclipse.ui.internal.WorkbenchPage.showView(WorkbenchPage.java:2624) at org.eclipse.ui.internal.WorkbenchPage.showView(WorkbenchPage.java:2600) I've introduced another composite in CompatibilityPart to prevent the CCE from occurring. A ToolBar is created because of the code added for bug 279599. We should probably re-evaluate why this is necessary. Please mark the bug as fixed or move it to M5. PW *** Bug 327040 has been marked as a duplicate of this bug. *** Removing outdated target milestone. Since We haven't received any new reports of this as a defect I'll close it out. |