Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 340741 - [ui] open model element dialog should respect current selection
Summary: [ui] open model element dialog should respect current selection
Status: CLOSED FIXED
Alias: None
Product: TMF
Classification: Modeling
Component: Xtext (show other bugs)
Version: 2.0.0   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: M7   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-23 07:21 EDT by Knut Wannheden CLA
Modified: 2011-03-31 10:49 EDT (History)
1 user (show)

See Also:
sebastian.zarnekow: indigo+


Attachments
patch for XtextEObjectSearchDialog (4.35 KB, patch)
2011-03-23 07:39 EDT, Knut Wannheden CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Knut Wannheden CLA 2011-03-23 07:21:06 EDT
It would be nice if the Open Model Element dialog (class XtextEObjectSearchDialog) would initialize the name pattern field with the current text selection in the Eclipse workbench.

FilteredResourceSelectionDialog can be used as a reference for how to do this.
Comment 1 Knut Wannheden CLA 2011-03-23 07:39:38 EDT
Created attachment 191741 [details]
patch for XtextEObjectSearchDialog
Comment 2 Knut Wannheden CLA 2011-03-31 04:40:40 EDT
Is it worth to include this feature in Xtext 2.0?
Comment 3 Sebastian Zarnekow CLA 2011-03-31 04:46:27 EDT
I like that, please feel free to push the changes. 

Just two minor remarks: The getter and setter should be either both protected or both public - I prefer protected. Please mark the new methods with @Since 2.0.
Comment 4 Knut Wannheden CLA 2011-03-31 05:14:00 EDT
I actually copied the idea of the getInitialPattern() and setInitialPattern() methods from the FilteredItemsSelectionDialog class, where they are declared as protected and public respectively.

I think the idea behind this is that client code instantiating and thus *using* the dialog should be able to set the initial search pattern before opening the dialog (thus public) while code which subclasses the dialog should be able to access the pattern (thus protected as the field is private).

So I would either leave it as is or mark both as public :-)
Comment 5 Knut Wannheden CLA 2011-03-31 10:49:58 EDT
fix pushed to master