Community
Participate
Working Groups
Java type names are case sensitive. The Open Type dialog is not case sensitive. We have classes (don't ask) that end in with the upper case letter "X". I cannot ask the Open Type dialog to pick from a list of classes that end in "X" Please add a check box that lets me say whether I want the type name match to be case sensitive or not. Right now, when I type "*X", I get classes like "_NamingContextImplBase" and a gazillion others. Thank you, Gary
There was an explicit request to make the Open Type Dialog case insensitive. So adding a check box is the right thing to do to solve the problem.
I'm going to work on this ...
Created attachment 2450 [details] showing the feature
Created attachment 2451 [details] org.eclipse.workbench -- infrastructure for the "case sensititive" checkbox This patch belongs to org.eclipse.workbench Implementation notes: Impact on existing clients: None -- if a client doesn't call TwoPaneElementSelector#setCaseSensitiveLabel(String) no checkbox will be created The existing fields and methods had "IgnoreCase" as part of their name -- I did not change those. I named the new stuff "CaseSensitive" because the checkbox label will read "Case sensitive" therefore naming the checkbox "IgnoreCase" would lead to misunderstandings -- the selection state of the checkbox is always the inverse of the field fIgnoreCase.
Created attachment 2452 [details] org.eclipse.jdt.ui depends on attachment 2451 [details]
Does the check-box remember its setting the next time the dialog comes up? Just checking. Thanks, Gary
Created attachment 2453 [details] now checkbox state persistant checkbox state is stored in IDialogSettings default checkbox state is unchecked
Created attachment 2454 [details] cleaned up infrastructure 2453 depends on this patch
thanks for the patch, but there is a consistency issue. The Open Resource/Navigate>Go to Resource dialog is case insensitive. Case insensitive is more convenient for the user and I therefore suggest to make the Open Type dialog case insensitive as well.
carboning Nick for a comment from the platform UI side.
Just a side note ... Default is case insensitive. If the user never checks the checkbox the Open Type dialog will never be case sensitive.
you are correct, actually now I even remember that I was one of the requestors for making the dialog case insensitive <g> However, the consistency argument still applies, the Open Resource and Open Type should have the same behaviour. I'm not thrilled about the case sensitive check box and I wonder whether we can infer case sensitivity based on what the user types. One idea would be to switch to case sensitive matching as soon as the user enters a capital letter. This will still allow the case insensitive matching as of today.
Created attachment 2455 [details] fixed NPE
IMHO, I would be really careful in not making e /too/ clever and risk confusing the user. You can bet that toggling case sensitivity on and off magically is bound to be more complicated to explain and for users to understand without causing trouble. Having a case sensitive check box is both simple and clear. If UI clutter is the issue here, then we should talk about that, and not try and make the feature extra clever in order to avoid dealing with making the UI better. I would also suggest that the 2.0-level feature is inconsistent. Today, there is an invisble "*" at the end of the not-quite-pattern such that typing "A" really means "A*". This works nicely BUT when I want classes that end in "A" as opposed to starts with "A", then I have to say "*A", which is not consistent and therefore a confusing. Furthermore, the UI states that "* = any string" and when the dialog comes up all classes are matched by default but the pattern in empty, instead of "*". This again is inconsistent. It is great that the UI states "? = any char, * = ..." but then the dialog itself does not do that! It makes it look like the user and dialog are not playing by the same rules. Sorry for repeating my point but I think that consistency is too often overlooked in favor of special rules and forcing the user to deduce what the connection b/w his behavior and the s/w's behavior is, which in turns lowers productivity. Thank you for considering this POV.
@@ Consistency @@ I've looked at the related classes. Solution would be to pull up the "case sensitivity" features (fields fIgnoreCase and fCaseSensitiveCheckbox and related methods) from AbstractElementListSelectionDialog into a new class rooted under SelectionDialog. Then subclass SelectionStatusDialog and ResourceListSelectionDialog from this new class. Then modify ResourceListSelectionDialog similar to TwoPaneElementSelector (fCaseSensitiveLabel and related methods) or even pull those modifications into the new class also. Consistency ... the global Search has the "Case sensitive" checkbox. @@ Typing capital letters @@ Nice idea :) The only problem I see is ... is the user supposed to guess this feature? @ first cut at this idea @ StringMatcher: add methods setIgnoreCase(boolean) & isCaseIgnored() FilteredList -- toggles it's FilterMatcher (and the StringMatcher it contains); also method to turn this new behavior on or off (default -- so clients already using the FilteredList won't break) ResourceListSelectionDialog: textChanged() -- creates a new StringMatcher w/ ignore case on/off depending on input. Problem: We cannot just look at the last char entered -- we have to scan the entire input String for capital letters (Performance?) Example: aBcD ... if we delete D we still want to be case sensitive Or we create a wrapper containing the input String and the # of capital letters we've encountered so far -- this time we only have to look at the char the user has entered/deleted (last char of input String) and raise/lower our capital letters count accordingly.
I do not favour adding a check box since it clutters the UI, for questionable value-add. I would need to understand the original use case better. Gary, you want to get at classes ending in "X". Could you let us in on what this signifies? Is listing classes ending in "X" or "x" acceptable? This is what Open Type does currently if you enter "*x". Go To / Resource in the Navigator (and the new Open Resource action in M3) is inconsistent with this - it matches all names containing 'x' or 'X' in this case, but it could be changed to be consistent with Open Type (and should be made consistent regardless of what we decide here). So the rules would be: - if no '*' in pattern then do prefix matching (the 99% case) - else names must match pattern exactly (no extra '*' added to pattern) While perhaps not immediately intuitive, I don't think this would be too hard to explain in Help. Another option would be to support arbitrary regular expressions.
Let me reiterate my problem with the current implementation. BTW, thank you for actually making "*X" work differently then the initial impl. which was equivalent to "*X*". Our code library has classes that end in the letter "X". If you must know, we have a library of classes that provide extensions to base Java classes. Since we do not want to mod java. and javax. classes and recompile the JRE, we provide these base extensions in classes like com.seagullsw.javax.lang.ClassX. So, we have a dozen or so of classes like this in many packages. This is why making "*x" the same as "*X" is useless to me. When I type "*X" I get about 80 classes (yes, I took the time to count), needless to say, it is a giant pain looking for the class I want out of this pile and somewhat defeats the purpose of this otherwise great feature. [flame on] I am always disappointed when I hear arguments like this: "We do not want to add this feature because our UI would not be as pretty". [flame off] (Ideally, it would be nice to have full RE support such that I could choose from all of our library classes with “com\.seagullsw\.*X”)
To clarify, I did not mean to say that I don't want to add the checkbox just because it's not pretty. I'm not in favour of it because I question how useful it is (and it's also not pretty). I don't want to add complexity to the UI if it's only going to be used in very rare cases. It sounds like your use of Open Type here is somewhat nonstandard. Usually you know at least some of the prefix of the type you want, and case doesn't usually matter. It sounds to me like you're using it as a way of quickly determining the list of extension classes you have, rather than wanting to go to a particular one. Which is not to say that your desire for tool support for figuring this out is illegitimate, but perhaps improvements to Search would be more appropriate. Am I completely off base here? I'm not trying to fuel your flames, I just want to understand how you're using this better.
We have changed the Open Type matching behaviour in the 2.1 stream. When you type Foo*x you will only getting types ending in x (case insensitive). This should also address your use case and we can keep the current UI as simple as it is.
Filed bug 26863 to make Navigator consistent.
>"I'm not trying to fuel your flames [...]" Well, we are all on the same page here, do not worry about adding fuel to the fire, I have found all discussions about e in this forum to be constructive, hopefully productive for the developers, and well mannered to top it all off. >"I don't want to add complexity to the UI if it's only going to be used in very rare cases." Now, I am on the simplicity page as well, but, at the risk of being anal, I just want to point out that it is the current case-INsensitive behavior that is more clever/complex what one might expect since Java types are case-SENsitive by definition. Yes, making the dialog case-INsensitive is a nice productivity boost, /sometimes/, or most of the time /depending on/ how you work. Please consider the following: (1) When I am coding, I type class names all the time, all day. I HAVE to type them all day with the proper-casing, Java types are case-sensitive. I do this EXCEPT when I use the Open Type dialog, where the rules are different. In the case of the OT dialog, this extra "wired-in" ability and knowledge is used against me because it is ignored. Furthermore, I cannot tell e that “I know what I’m doing”. (2) >"It sounds to me like you're using it as a way of quickly determining the list of extension classes you have, rather than wanting to go to a particular one." (2a) Go To When I use the OT dialog to go to a given class, depending on "where" I am, it is sometimes faster to use the OT dialog than to navigate to the ClassPath/Package/Type. If the class is already in the code I am editing and properly imported I can just hit F3 on the type. If just type in the class name in a proper line of code and hit F3, nothing happens since the class is not imported. What I really want is to go to a class as fast as possible. Unless that class is in the UI nearby, I hit CTRL+SHIFT+T type in a couple of chars and ENTER does the trick. For example, I want to load StringTokenizerX, I’d like to type in CTRL+SHIFT+T S*X ENTER. That will not work in M3 since I get JRE classes to match the “S*X” pattern. My target class is in there but I have to take my hands off the keyboard a go click on it in the list. It works, but not as efficiently as possible. (2b) Browsing Indeed, I do use the OT dialog to do some high level browsing. For example: What classes have “*HTTP*” in them? Case-insensitive is good here. Better: Which Apache classes have “*HTTP*” in them? One cannot do this right now: “org\.apache\.*HTTP*”. I like the OT for this type of querying because it is super-fast since all of the class names are right there. I would not consider doing a real e Search since I have the OT dialog.
Re 1: you do not have to type in code in a case sensitive way, code assist is case insensitive. Precise case sensitive matches have higher relevance and show up before case insensitive ones. Actually, using precision based sorting in the open type dialog would address your case sensitivity issue as well. Re 3: org\.apache\.*HTTP*”. this should work try: org.apache.tools.ant.*Scanner*
RE 1: I do not use code assist all the time. Sometimes code assist is great but other times I spend more time /looking/ or down-arrowing or clicking in the code assist window. Bottom-line: sometimes, I just type the class name without using CRTL-SPACE because there would be too many matches and it would take me more time. >"Actually, using precision based sorting in the open type dialog would address your case sensitivity issue as well." Seems reasonable, I'd like to try it out. >"this should work try: org.apache.tools.ant.*Scanner*" Hmm, not in Version: 2.1 Build id: 200211151436 (M3). There is something wrong with "." and or "*" processing. org yields nothing org.* yields nothing org*. gives me a bunch of classes. org.omg. yields nothing org*.omg*. gives me a bunch of classes. org*omg* yields nothing org*.omg* yields "org.omg.CORBA.OMGVCID"
opened related feature request 26890 ... the descision on that request should be independent on this discussion.
grml, forgot the "bug" bug 26890
the matching of org.* looks indeed incorrect. Filed bug 26983
