Community
Participate
Working Groups
The Find dialog really needs to be optimized for the most common search task, which will be the message 98% of the time. It needs to have a field to enter the message directly and the way to enter the additional attributes which could use the current dialog. While I am listing this as an enhancement, I think this is critical for user acceptance from support organizations. There are also a few minor improvements that should be made along the way: 1. Add an "X" to upper left corner to close dialog 2. Move Find Next and Close to the bottom row of the dialog (lower than Direction).
Created attachment 52615 [details] Mockup of Find panel
This is for both RCP and IDE
Also, we need to find on all the CBE properties. Today, you can't find on CBE extended Data Elements
Created attachment 55770 [details] Mockup - this is what we would like to acheive eventually. The Find all Instances button is requirement 161637
You may need to use some other notions in the scope, as a real RCP user I don't know what is a Project, Workspace, Working set. Would be good to hide (or better avoid the use of) those Eclipse IDE concepts in our RCP applications.
I agree. I meant to add the caveat that we need to look at the wording and the details for the RCP implementation.
The mockup in comment #4 supports only one criteria in each search. However, the current search supports multiple criteria (eg sev 's' of message 'm' between time 't1' and 't2') which I think this new UI will miss. Also can you explain more on what is in 'Advance'? Is advance expand/hide the lower portion of the ui?
Currently we can export filters from Eclipse LTA, so should the filters from RCP LTA be compatible (complexity wise) with those in the Eclipse LTA?
Created attachment 56003 [details] Updated mockup Updated per our conversation today.
Created attachment 56004 [details] Advanced Find - if these additions are easy to incorporate, please do.
I can not find this in LTA-Eclipse. Can you give me the steps to do this? I would have expected to be able to import a filter in the same way as a log is imported and from the Search dialog, but cannot find it in either place.
(In reply to comment #10) > Created an attachment (id=56004) [details] > Advanced Find - if these additions are easy to incorporate, please do. > This looks very similar with the current Filter dialog - Standard and Advanced tabs, would be better to keep those names like Standard and Advanced (they have been used in the past 4 TPTP releases). If we pair Find Next button with a Find Previous one then we can get rid of the Forward/Backward radio button group which allow us to reuse those two tabs (the Basic tab looks a bit better than the Filter Standard tab) in the Filter dialog (and have a consistent approach). It is still not clear how search in files vs in current view/editor will work, if we want to build the list of matches it might be better to have only one Find button and a Find Result view with better navigation controls (for example something similar with the page navigation control that you can see in Adobe PDF Reader, similar navigation control could be provide in any other views in addition to the use of SWT Virtual support) and which will list all the hits (like in Eclipse Search Result view) and when you click on a hit it will open/select it in the Log view so you can see it in the filtered context. In this case would be interesting what event attributes will be shown in the Find Result view, the list of attributes could match the ones from the log view. I think I mentioned this before in a different bug report, the Find criteria should be applied against the filtered list of events (like we do today), basically in the Find case the two criterias needs to be merged before they are executed. Regarding comment #11, I mistakenly assumed that log filter import/export function was added in the same time with the support for profile filter import/export (the implementation is basically the same), that function should be added also.
(In reply to comment #12) > (In reply to comment #10) > > Created an attachment (id=56004) [details] [details] > > Advanced Find - if these additions are easy to incorporate, please do. > > > > This looks very similar with the current Filter dialog - Standard and Advanced > tabs, would be better to keep those names like Standard and Advanced (they have > been used in the past 4 TPTP releases). The reason I had changed the tab name was because I had an advanced button to hid and show the other stuff. Since tall the additional stuff I had related to files, we could make the button something like "Multiple Files". So I think Basic and Advanced are fine. > > If we pair Find Next button with a Find Previous one then we can get rid of the > Forward/Backward radio button group which allow us to reuse those two tabs Agree. Sounds good. (the > Basic tab looks a bit better than the Filter Standard tab) in the Filter dialog > (and have a consistent approach). > > It is still not clear how search in files vs in current view/editor will work, > if we want to build the list of matches it might be better to have only one > Find button and a Find Result view with better navigation controls (for example > something similar with the page navigation control that you can see in Adobe > PDF Reader, similar navigation control could be provide in any other views in > addition to the use of SWT Virtual support) and which will list all the hits > (like in Eclipse Search Result view) and when you click on a hit it will > open/select it in the Log view so you can see it in the filtered context. In > this case would be interesting what event attributes will be shown in the Find > Result view, the list of attributes could match the ones from the log view. > Good points. Attributes would have to include: Filename and Attribute, I'm not sure what else. > I think I mentioned this before in a different bug report, the Find criteria > should be applied against the filtered list of events (like we do today), > basically in the Find case the two criterias needs to be merged before they are > executed. Yes, I agree. The basic Find should only be executed against the view that the user sees (including any filters). Maybe searching multiple Does just dropping the "Find one item" Find (Eclipse Find) in favor of always doing a Find All (Eclipse Search) simplify things? I guess the only downsides I can think of are: 1. This is a not really the standard way to do this, although Acrobat does not have the single-item Find. We have never gotten any feedback on not having an Eclipse Find, but it does make it simpler. Note that Acrobat uses Ctrl + F to open it. 2. It does take up some screen real estate. If this is the way we want to go, let me put together a proposal and talk on the phone to finalize the design quickly. > > Regarding comment #11, I mistakenly assumed that log filter import/export > function was added in the same time with the support for profile filter > import/export (the implementation is basically the same), that function should > be added also. >
Based on some customer feedback, there are several updates to this enhancement. This portion contains the main requirement. The default view that a user should see when they invoke Find is shown in Figure 1 (see attachment). They should be able to type in a search string that by default searches the Message field (the full one, not just the field shown in the log view) and the extended properties. They should be able to specify "all fields", Message ID, and possibly a few more fields as well. The default behavior should be non-case sensitive, search for partial words, and by default search all message types. The user should be able to change any of these (see Figure 1). The highest priority output method should be to product a list of all hits (Find All) for all hits throughout the log (not constrained by paging). Find Next/Previous, which highlights the next occurance of a hit was desirable to customers, but lower priority than this function.
Created attachment 61752 [details] Mockup
*** Bug 161637 has been marked as a duplicate of this bug. ***
Created attachment 62131 [details] Mockup
raising priority per consumer's feedback.
Resolving this as WONTFIX because it is no longer required by the consumer that requested it.
Closing.
