Bugzilla – Full Text Bug Listing
| Summary: | Need new "description" model attribute | ||
|---|---|---|---|
| Product: | [Eclipse Project] e4 | Reporter: | Remy Suen <remy.suen> |
| Component: | UI | Assignee: | Thomas Schindl <tom.schindl> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | emoffatt, susan, tom.schindl |
| Version: | 1.0 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 320252, 324957 | ||
|
Description
Remy Suen
Is this a PartDescriptor or Part-Attribute - I'm not sure yet what 320252 talks about 100%. Where in the UI can i see the attribute in action? (In reply to comment #1) > Is this a PartDescriptor or Part-Attribute I don't think it'd make sense as an attribute in MPartDescriptor personally. > Where in the UI can i see the attribute in action? You can't because it's not implemented yet. It's basically the "description" label you see in the top part of the 'Problems' view or the 'Search' view in 3.x. The value of this label is supplied *by* the part through some API (not sure which but we can find out). This leans away from making it an attribute in the model because its value cannot be meaningfully persisted. We should see how it's currently done and see if there's an e4 appropriate equivalent... (In reply to comment #3) > The value of this label is supplied *by* the part through some API (not sure > which but we can find out). Subclasses of WorkbenchPart do this by invoking the protected setContentDescription(String) method. See bug 325646 for a screencap... Perhaps this is best handled with a transient property on MPart? We do need some place to cache the last known value because the call to 'setContentDescriptor' will be called once but needs to show up whenever that part is activated. Note that we'll also need to have the CTF be capable of handling this field (this is the 2nd part of the ui that is covered by ViewForm in the 3.x implementation... Oops, that's a dup of bug 320252, which has more info on the rendering side of this. The comments about the model impact still seem valid though... I'm not very happy with the attribute name "description". The reason is that we might want to add a MPartDescriptor#description (e.g. to show more info about the Part to be opened in "Show View ..."). Haveing: * MPart#description * MPartDescriptor#description who have a different meaning is not good. Is the value in MPart not better named summary? I've filed bug 325852 for a description attribute on MPart/MPartDescriptor with at least me the correct meaning of the a description attribute. To implement the required feature here are my suggestions for the MPart-Attribute name: * contentDescriptor * summary Anyone has some feedback on this, I'm currently thinking about naming summary but native speakers might have better names Technically speaking, this is no longer a "hard" requirement for the compatibility layer as Eric has implemented something purely on the renderer side. I'm closing this as won't fix as it looks like it is not needed anymore |