Anonymous | Login | 02-28-2021 15:53 UTC |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ Issue History ] [ Print ] | |||||||||||
ID | Category | Severity | Reproducibility | Date Submitted | Last Update | |||||||
0001524 | [Squeak] Tools | minor | always | 07-22-05 19:06 | 07-22-05 21:08 | |||||||
Reporter | chris | View Status | public | |||||||||
Assigned To | ||||||||||||
Priority | normal | Resolution | open | |||||||||
Status | new | Product Version | ||||||||||
Summary | 0001524: [ENH] ImprovedBrowseIt | |||||||||||
Description |
Note the comment in ParagraphEditor>>browseClassFromIt indicates a hierarchy browser is to be used. But I've noticed the ambiguity that I think you're alluding to. alternativeBrowseIt seems to do two things: 1) open with a Hierarchy browser instead of a package browser. 2) Be more friendly/responsive when the user requests to browse something that doesn't exactly match a class-name in the system. I think alternativeBrowseIt should toggle just between the two parts of #1. This allows the user/developer to focus primarily on the object-model or the package-model as he desires. (To have that function toggle between the PackageBrowser or the PackagePaneBrowser seems to contradict our favorite axiom that if two things are 99% the same we should make them the same or very different). For 0000002, how about we make it more user-friendly all the time, regardless of the alternativeBrowseIt setting. Today, when a new user browses "Int" without alternativeBrowseIt turned on the system does nothing; no response. When is this sort of behavior desirable? I've attached a changeSet which I think does better. It follows these rules in order of precedence: 1) If you type an exactly matching class name, it automatically browses that class. 2) If no exact match from #1, then it presents a list of the classes whose name partially matches what you've typed, even if the match is only in the middle. 3) If there is no match from either of the first two rules, then it looks for an exact-match of the capitalized Smalltalk-words inside the selection. For example, if you are looking at Interval>> from: startInteger to: stopInteger and you double click "startInteger" and browse it, the system brings up Integer. If you browse "aGlobalPoint" you get Point and if you browse "anOrderedCollection" you get a list to select between OrderedCollection or Collection. So the system provides a next-best-guess alternative based on Smalltalk naming conventions of prefixing with "a", "an" or some adjective. The third rule is very nice for fast browsing. I've been using it for years and have learned to type-imply my argument names so it will quickly open the correct browser. No need for Chuck when browsing my own code. Note, this changeset *only* changes the what-to-browse behavior; it does not affect *which* browser is used to present it. 3.9 is a for-developers release, I think this changeSet should be considered for inclusion. |
|||||||||||
Additional Information | ||||||||||||
Attached Files |
![]() ![]() |
|||||||||||
|
Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
43 total queries executed. 32 unique queries executed. |