Community
Participate
Working Groups
I have a property sheet,in which there are categories,under which there are entries which has sub-entries. Now the categories are expanded by default,but my sub-entries are not. I need a way to specify that sub-entries need to be expanded at property sheet visible time. I see that PropertySheetViewer is the one that creates the entries,and sub- entries are lazily created in handleTreeExpanded().I can solve my problem by creating a CustomPropertySheetViewer that will create all entries at startup.I will switch off this lazy creation.But again there is no way to tell PropertySheetPage to use my CustomPropertySheetViewer..The PropertySheetPage hardcodes the creation of PropertySheetViewer.
I have a property sheet,in which there are categories,under which there are entries which has sub-entries. Now the categories are expanded by default,but my sub-entries are not. I need a way to specify that sub-entries need to be expanded at property sheet visible time. I see that PropertySheetViewer is the one that creates the entries,and sub- entries are lazily created in handleTreeExpanded().I can solve my problem by creating a CustomPropertySheetViewer that will create all entries at startup.I will switch off this lazy creation.But again there is no way to tell PropertySheetPage to use my CustomPropertySheetViewer..The PropertySheetPage hardcodes the creation of PropertySheetViewer. If we can tell the propertysehhetpage to use a custom property sheet viewer,then that will be perfect. Now i have to create a CustomPropertySheetPage,and also replicate all other classes that PropertySheetPage uses becoz all those classes are package protected like CategoriesAction,CopyPropertyAction,PropertySheetEntry. It is very hard to reuse,extend the eclipse property sheet implementation.
Indeed, the property sheet does not expand sub-sub-elements automatically, and the view generally needs work. However, due to other priorities, the UI team has no plans to address any enhancements to the property sheet for 3.0. This is a good opportunity for you to contribute to Eclipse to address these problems. If you would like to do so, please let us know on the platform-ui- dev mailing list.
Hi Nick, I am not sure whether my time constraints will allow me to make significant contributions but had sure like to try.So I would like to contribute to the eclipse platform for solving this problem.This is my first time. Not aware of the processes in place. Please give guidelines as to how i can go about it.. Rgds, Zenil
The main thing is to get the API for the change right first. If you haven't read it already, check out http://eclipse.org/articles/Article- API%20use/eclipse-api-usage-rules.html. Then propose some API for the enhancement in this PR. If the overall shape of it makes sense, then you can go ahead and implement it (you might want to do a prototype-quality implementation before proposing the API) and supply a patch. One option would be to introduce IPropertySource2 which extends IPropertySource and has a method boolean isInitiallyExpanded(). This would override the default behavior (expanded for top-level elements only). Note that we can't add methods to the existing IPropertySource as that would break any existing implementors.
Hi Nick, I would like to work on this bug and a couple of issues related to. Basically my intention is to solve the following problems.. 1)Ability to specify whether elemnts in the property sheet should be expanded or not.[Right now only top level categories are expanded by default,sub-levels not expanded,and hence really irritating if u have mutliple levels] 2)Property sheet context menu default actions like Copy/Paste..Copy copies the whole row in the table.In most cases this is not useful.In my project,when i copy a property sheet row, i want to copy only the r-value in the row and not the l-value. So some way for me to plugin my custom copy/paste actions functionality to a property sheet view.Right now CopyAction/Paste action are all internal,package protected classes with no scope for extension or modification. 3)Double click on a property sheet row to expand/collapse it,if it has children. [related to point 1] My plan is to write it as a separate plugin.I did a small analysis.The whole property sheet implementation in eclipse is mostly package protected.No way to extend or reuse it.There is no way i can get the above functionalities by extending/reusing them simply because i have no access to them.I got to duplicate it. So my plan is to duplicate these internal classes in to my plugin,retrofit them with these functionalites,come up with new interfaces.I will not modify existing interfaces(like u said in ur previous posts) .But i go to rewrite the eclipse internal classes..I will come to more specifics later,which classes,the design etc.. I want ur feedback on my plans.Are we in agreement on the problems to solve??
Zenil, The properties view needs a complete overhaul. It has been somewhat neglected in 3.0, with no proper owner. While it's too late to get anything other than critical fixes into 3.0, it needs attention post-3.0. As designed, it provides a default property page implementation which, if it doesn't meet the needs of a particular view or editor, they can write their own. This is not ideal. For example, PDE provides their own page mainly to augment the entries with icons and other actions. You then have the side effect of the columns jumping around when switching between a PDE editor and some other property provider, since there are multiple TableTree widgets in play, usually with different column widths. The default implementation should be more flexible, and the limitations you outline above are good places to start, but they are small steps. I think it's worth stepping back and evaluating what property sheet support exists in other products, and doing a competitive analysis of Eclipse's. If you would like to go ahead and do as you suggest, I think it would be worthwhile, and I would encourage you to explore. This will help us understand how to open up the default sheet post-3.0, although we may not be able to accept your changes verbatim. As always, backwards compatibility is important to us, so please keep this in mind when making changes to either APIs or behaviour.
Hi Nick, I agree with u that properties view requires a complete overhaul.But its been a long time without an owner.Not much bug fixes or feature enhancements here. I got a wish list too apart from the above bugs a)Stop unwanted sorting of properties,there's a bug already logged against this. Right now there are workarounds(u can have ur own propertysheetentry rather than the default one and comment the sorting code out..)So this is not really an issue. b)Muli-select of properties ,support for this in eclipse is primitive.I can think of several cases.One case: in oracle forms ,if i select multiple elements with the same properties,if the values are different,ther show ****..Eclipse has no way of doing that.. So "evaluating what property sheet support exists in other products, and doing a competitive analysis of Eclipse's." is required..But i can't really wait for that..:)-.The bugs i mentioned above are small bugs,fixable bugs.As u said small steps.I can work on it.I got to work on it anyway becoz i got to solve these bugs for my project.So want to share the outcome with ur team. So I will start to work on bug no1,which is a way to expand/collapse the propertysheet.Will send u more on that later. If we find an acceptable solution to the above issues,i had like ur help to move it forward post 3.0 .My recommendation would be not to wait for the process of a whole design change of property view to take place.Small small bug fixes like these can be put in.Parallely when u gain a resource for this,u can start thinking of overhauling the property sheet design. Just so that u dont think that i am an unknown quantity not to be trusted..:)- I have been working on eclipse for the past 3yrs,since R1.O days. I was part of the development team that developed the COBOL IDE(Fujitsu).Right now working on an MDA tool in the Datawarehousing/BI domain.We are using GEF and property sheets extensively.I think we are one of the few guys who are developing a commercial quality tool on top of eclipse in this domain.Here's our site..http://www.certive.com/products/composer.html.
OK Zenil, your approach makes sense to me. Good luck!
Consequent to our discussion,I am attaching my fixes here. I am attaching the the main plugin and a test case plugin.Here's a summary of the fixes: 1)Properties are NOT sorted by default.It is shown in the order entered by the user.[I have just commented out the sorting code and used LinkedHashmap instead of Hashmap to maintain the order] 2)For properties that need to be expanded while being shown,an API has been provided to the user.For this i have created 2 new interfaces,IPropertySheetEntry2(extending IPropertySheetEntry) and IPropertySource2(extending IPropertySource). [Every Property item u see in a property sheet has a IPropertySheetEntry2. So after creating an item,the propertysheetviewer queries IPropertySheetEntry2 whether it has to be expanded.The IPropertySheetEntry2_Obj inturn queries the IPropertySource2_OBj.expandProperty() to see if the property has to be expanded] 3)The property sheet expands/collapses based on double-clicks.. For every eclipse class i have modified i have suffixed it with 2.So i have a PropertySheetViewer2,PropertyPage2..For those that are not modified,i have used the same names as their eclipse counterparts. The one thing remaining is how to customise actions on the property sheet like Copy,Paste..I think eclipse should remove its default implementation of Copy,Paste actions from the property sheet code.They should a)provide it as default actions(but not add it to the code),and if user decides,he can add it via a viewercontribution. b)if user doesnt like the default Copy/Paste[LIKE ME,copy should copy only r- value,not l-value] actions provided by eclipse,he can write his own custom actions and contribute it to propertysheet via viewercontribution. [Or User can provide his own ActionFactory to a propertysheet page,which will create actions based on it.If user doesnt send any action factory,then property sheet will create a set of default actions..Search view has done something similar to this..] My Test plugin has 2 views :SampleView1 uses the eclipse property sheet implementation. SampleView2 uses the custom property sheet implementation. For its 2cents worth,hope this exploration helps u guys in some way!!!
Created attachment 12012 [details] Preliminary Fix for this Bug Preliminary Fix for this Bug
Created attachment 12013 [details] Test Case plugin for the bug fix Test Case plugin for the bug fix
Hi Zenil, Unfortunately I will not be able to look at this for a week or two since we're very busy getting 3.0 finalized. I've marked it as 3.1 to ensure it does not get lost.
Zenil, is this still of interest to you? Sorry, I left it on the back burner for too long, and now our API freeze is this Friday. If the expansion behaviour is still important, perhaps you could supply a patch just for that, against the current code from HEAD.
(In reply to comment #13) > Zenil, is this still of interest to you? Sorry, I left it on the back burner > for too long, and now our API freeze is this Friday. > If the expansion behaviour is still important, perhaps you could supply a patch > just for that, against the current code from HEAD. > Hi Nick, For me personally this is not an issue anymore.This alongwith the sorter bug was hampering the use of default eclipse property sheet implementation.So I created my own eclipse property sheet implementation to fix these bugs(similar to the patch i provided). I have moved on to other projects..:)- Its obvious to me that for anyone using prop.sheet extensively,ability to expand/collapse properties is important.But it seems no one else is interested in this bug...:)-.And I have fixed my issues.So u decide on the priority of this bug[in the overall scheme of things..I also remember in our discussion that u had mentioned the property sheet implementation overall needs a relook about the features.Is that relook going to happen in the next releases??If so,since this bug is not a top priority,probably it should be part of that relook...]. In any case,I am willing to contribute the patch for the latest codebase[please send me the link to the latest HEAD]. Zenil
Thanks for responding Zenil. I'm going to defer this work then, as I do think it should be done in the context of a broader overhaul of the property sheet. If you still want to look at providing an updated patch for 3.1, see the following for CVS connection details, however note that this week is our API freeze so we won't be able to make further API changes past this Friday. http://www.eclipse.org/eclipse/faq/eclipse-faq.html#users_7
Reassigning bugs in component areas that are changing ownership.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it and remove the stalebug whiteboard tag. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. --
