Bill Dargel wrote:
> ...Speaking of Local Definitions/References ...Anyone else notice that > the definition of "local" is less than ideal when it comes to > inherited methods? >... rather than relative to the class that implements >the method (which appears to be what it's using -- haven't dug into it yet). > I think your comment speaks for the fact that it's not *obvious* what it's doing, and thus it's hard to know when to use it, and when not. Here's what I think it *should* be doing: Local 'senders' and local 'implementors' should give me the senders and implementors *within the same and requisite packages*. Typically when I'm trying to understand how a given application or component works, I'm only interested in seeing what happens within the context of that package. Seeing more just distracts me (naturally we do need the global senders and implementors too). Now, could anybody give a guesstimate as to how much work it would be to change the menus to work accordingly, and how easy it would then be to share such an enhancement/modification with other users? Thanks -Panu Viljamaa |
panu wrote:
> Here's what I think it *should* be doing: I don't :-) > Now, could anybody give a guesstimate as to how > much work it would be to change the menus to work > accordingly, This is a hack of the existing method in D5 (I haven't got D4 installed any more) and it only alters the definitions menu option - the references should be similar. There are couple of things that still need sorting out (and I'm too knackered to think them through at the moment). - I'm not sure if the method browser filter (used when the list may need updating) is right. - The initial package list uses the package of the current class as it's starting point - not the package of the selected method. Using the method's package causes walkbacks if the chosen selector is not implemented in the current class. - It always includes classes and methods in the Dolphin (and other) package as everything (loosely speaking) is in a subclass of Object and the Dolphin package is therefore always a prerequisite.. I also haven't bothered altering the comments/titles. SmalltalkSystem>>browseDefinitionsOf: selector inLocalHierarchyOf: classDesc "Opens a MethodBrowser on all the methods with the specified selector in the local hierarchy of the <ClassDescription>, classDesc." | defns browser class targetPackage targetPackages | targetPackage := classDesc owningPackage. targetPackages := (OrderedCollection with: targetPackage) addAll: targetPackage prerequisites; yourself. class := classDesc instanceClass. defns := self definitionsOf: selector. defns := defns select: [:each | targetPackages includes: each owningPackage]. defns isEmpty ifTrue: [MessageBox notify: selector printString , ' has no definitions in the local hierarchy of ', class name] ifFalse: [self browseMethods: defns caption: 'Definitions of ' , selector printString , ' in local hierarchy of ' , class name findString: nil filter: [:m | m selector == selector and: [ targetPackages includes: m owningPackage]]] > and how easy it would then be to share > such an enhancement/modification with other users? Stick the above method in a .st file and invite others to file it in. -- Ian |
Great,
Thanks Ian -Panu Viljamaa Ian Bartholomew wrote: >panu wrote: > > > >>Here's what I think it *should* be doing: >> >> > >I don't :-) > > > >>Now, could anybody give a guesstimate as to how >>much work it would be to change the menus to work >>accordingly, >> >> > >This is a hack of the existing method in D5 (I haven't got D4 installed any >more) and it only alters the definitions menu option - the references should >be similar. > >There are couple of things that still need sorting out (and I'm too >knackered to think them through at the moment). >- I'm not sure if the method browser filter (used when the list may need >updating) is right. >- The initial package list uses the package of the current class as it's >starting point - not the package of the selected method. Using the method's >package causes walkbacks if the chosen selector is not implemented in the >current class. >- It always includes classes and methods in the Dolphin (and other) package >as everything (loosely speaking) is in a subclass of Object and the Dolphin >package is therefore always a prerequisite.. > >I also haven't bothered altering the comments/titles. > >SmalltalkSystem>>browseDefinitionsOf: selector inLocalHierarchyOf: classDesc > "Opens a MethodBrowser on all the methods with the specified selector > in the local hierarchy of the <ClassDescription>, classDesc." > > | defns browser class targetPackage targetPackages | > targetPackage := classDesc owningPackage. > targetPackages := (OrderedCollection with: targetPackage) > addAll: targetPackage prerequisites; > yourself. > class := classDesc instanceClass. > defns := self definitionsOf: selector. > defns := defns select: [:each | > targetPackages includes: each owningPackage]. > > defns isEmpty > ifTrue: > [MessageBox notify: > selector printString , > ' has no definitions in the local hierarchy of ', > class name] > ifFalse: > [self > browseMethods: defns > caption: > 'Definitions of ' , > selector printString , > ' in local hierarchy of ' , > class name > findString: nil > filter: [:m | > m selector == selector and: [ > targetPackages includes: m owningPackage]]] > > > >> and how easy it would then be to share >>such an enhancement/modification with other users? >> >> > >Stick the above method in a .st file and invite others to file it in. > > > |
In reply to this post by panu-2
"panu" <panu@fcc.net_zerospam> wrote in message
news:[hidden email]... > Bill Dargel wrote: > > > ...Speaking of Local Definitions/References ...Anyone else notice that > > the definition of "local" is less than ideal when it comes to > > inherited methods? > > >... rather than relative to the class that implements > >the method (which appears to be what it's using -- haven't dug into it yet). > > > > I think your comment speaks for the fact that it's not > *obvious* what it's doing, and thus it's hard to know > when to use it, and when not. More likely it stems from the fact that the feature was originally added when Dolphin had only a class hierarchy browser, and could not display inherited methods. In that context the way it works mirrors that browser's concept of being at an unambiguous selection point in the hierarchy. With the introduction of inherited methods it makes sense (as Bill suggests) that the search be relative to the selected rather than the implementing class. With the introduction of the System Browser, it would be useful to have another search that could be limited to the selected packages. Blair |
Blair,
> . With the introduction of the > System Browser, it would be useful to have another search that could > be limited to the selected packages. I was having a think about this and came up with a couple of additional suggestions. - An additional MethodBrowser that uses a tree rather than a list and would be used when a restricted search is used. This would display classes that have a definition or reference in bold (as the ClassHierarchy tree in the SystemBrowser does) and could give immediate feedback on the scope that is being checked. - I often tend to avoid doing a local search for def/ref but do a global search and sort the list on packages to narrow it down to ones of interest (which on reflection is, I suppose, closer to panu's original request?). Might it be possible to rename all the packages that come with the basic image so that they have a common prefix (maybe "Dolphin" or "OA") which would make sorting easier -- Ian |
Ian Bartholomew wrote:
> Might it be possible to rename all the packages > that come with the basic image so that they have a common prefix > (maybe "Dolphin" or "OA") which would make sorting easier I second this request. Actually there's a fair amount of cohesion in the names already: Dolphin* ActiveX* OLE* but it'd be nice if the pattern were universal. -- chris |
"Chris Uppal" <[hidden email]> wrote in message
news:3e632d00$0$59849$[hidden email]... > Ian Bartholomew wrote: > > > Might it be possible to rename all the packages > > that come with the basic image so that they have a common prefix > > (maybe "Dolphin" or "OA") which would make sorting easier > > I second this request. > > Actually there's a fair amount of cohesion in the names already: > > Dolphin* > ActiveX* > OLE* > > but it'd be nice if the pattern were universal. When creating new packages we do apply a prefix convention, but this hasn't been done for older packages because they may be referenced as pre-requisites from other packages. Renaming them would thus cause difficulties on package load. This could be solved by introducing an aliasing mechanism to map from the old names to new, but it didn't seem like a very high priority. Regards Blair |
In reply to this post by Blair McGlashan
Blair McGlashan wrote:
> ... list some others so that we can either disabuse him of > hisignorance, or use the feedback to improve the system. Ok, while we're at it, here's a feature I *really* miss from Dolphin (4): When I'm editing a method in the browser, I typically want to enlarge the text-area, to concentrate just on the method under edit. You can do this by re- portioning the browser's window-panes with mouse. However, this take some effort: Moving the mouse to exactly the correct vertical position between the panes, pressing it down, and keeping it down while resizing the pane. Now if you want to reverse this action, it it's again the same amount of effort. On some other IDEs I've used, you can simply click Alt-Z to 'Zoom in' on the current pane, and 'Zoom out' with another Alt-Z. This is really fast, convenient, and productivity enhancing. Thanks -Panu Viljamaa |
In reply to this post by rush
"rush" <[hidden email]> wrote in message
news:b10ned$8sva$[hidden email]... > "Andy I am planning my garderobe, so do you think that Dolphin-xyz > T-shirt will have long or short sleeves" :) Unless I'm missing a really funny joke about medieval defecation, I think you meant wardrobe! |
In reply to this post by Jochen Riekhof-3
"Jochen Riekhof" <[hidden email]> wrote in message
news:[hidden email]... > > End of march is also fairly aggressive interpretation of "somewhere in about > this years second quarter" ;-) I think "end of March" is probably a pretty realistic estimate. :) |
In reply to this post by Blair McGlashan
> "Ian Bartholomew" <[hidden email]> wrote in message
> news:b5m6a.6957$Lq.552042@stones... > > ... > > I think that the prompters that ask for user input (Browse Definitions, > > Browse References, Find Class etc) should use a separate dialog rather > than > > just a default Prompter. This could then have a "most recently entered" > > ComboBox allowing for quick reselection and editing of the previous 10 or > so > > entries. Also, any such dialog should at least remember the last thing entered, which you can type over. |
In reply to this post by Andy Bower
"Andy Bower" <[hidden email]> wrote in message
news:[hidden email]... > > But it's not a Dolphin "trick"; it's standard Windows feature. But double-clicking on a menu is so rare in the field as to be unintuitive. FWIW, I saw the bold choice in the submenu, and I related it to the bold choice in many systray menus, but I still didn't make the leap to doubleclicking the menu item <thwack>. Which doesn't make it a bad UI choice, but you can't get away with calling it a standard Windows feature. :) |
"Mark Wilden" <[hidden email]> wrote in message
news:[hidden email]... > "Andy Bower" <[hidden email]> wrote in message > news:[hidden email]... > > > > But it's not a Dolphin "trick"; it's standard Windows feature. > > But double-clicking on a menu is so rare in the field as to be unintuitive. > > FWIW, I saw the bold choice in the submenu, and I related it to the bold > choice in many systray menus, but I still didn't make the leap to > doubleclicking the menu item <thwack>. > > Which doesn't make it a bad UI choice, but you can't get away with calling > it a standard Windows feature. :) Certainly it can take a long time for a standard feature to be recognised as such. Default menu items have been a feature of Windows for at least the last 7 or 8 years. In Windows 95, for example, the property menu for the desktop shortcuts defaults the 'Open' command, and this has remained the case in every version of Windows since, including Windows XP. Of course this doesn't mean that a lot of people necessarily know what the emboldening of a menu item means, apart from those rare individuals who read the Windows help, or those that made the association between double-clicking a desktop shortcut and the bold Open command. Also the style is not much used in sub-menus. For these reasons we make selection of the method's own selector the most prominent choice in two other ways: 1) It is listed as the first entry in the sub-menu, and separated from the other selectors with a divider. 2) Definitions/References of the selector of the selected method can be browsed directly using the context-sensitive F12 and Shift-F12 accelerator key sequences, respectively. Regards Blair |
"Blair McGlashan" <[hidden email]> wrote in message
news:b546sn$26ij03$[hidden email]... > > Certainly it can take a long time for a standard feature to be recognised as > such. Default menu items have been a feature of Windows for at least the > last 7 or 8 years. Yes, like I said, most people know about default menu items from systray menus. It wasn't the notion of a default menu item that I was saying was unintuitive--it is the notion of doubleclicking its parent menu item to activate it. In fact, Dolphin Smalltalk is the only UI I've ever seen where you doubleclick a menu item! It's actually quite cool, and I hope it catches on. :) |
In reply to this post by Jochen Riekhof
On Sun, 26 Jan 2003 11:25:07 +0100, "Jochen Riekhof"
<[hidden email]> wrote: >Hi... > >I would like to put some (small) feature requests: [snip] Here is one of my feature requests. May be I just use IDE in a wrong way. In a class browser I use Ctrl-Shift-F to open another class quickly. I have to remember and type class name. I think it would be good to provide a list of matching classes as you type. This list is displayed below a text field entry and can be clicked on to open class quickly. I know that if I type part of the class name and submit dialog box contents I will get this list. The functionality is the same, but user interaction could be improved. |
"Sergei Gnezdov" <[hidden email]> wrote in message
news:[hidden email]... > ... > I know that if I type part of the class name and submit dialog box > contents I will get this list. The functionality is the same, but > user interaction could be improved. Good point Sergei. I'll add this to the list for consideration in the next major release. Regards Blair |
In reply to this post by Sergei Gnezdov
Hello Sergei,
> In a class browser I use Ctrl-Shift-F to open another class quickly. > I have to remember and type class name. I think it would be good to > provide a list of matching classes as you type. This list is > displayed below a text field entry and can be clicked on to open class > quickly. I made spike solution for your request: http://www.infolio.ru/~zamsky/EnchancedClassChoice.pac Suggestions are welcome. -- Dmitry Zamotkin |
In reply to this post by Sergei Gnezdov
Perhaps this could be extended to other entry fields, such as those
for categories, text search, etc. Best regards, Daniel Sergei Gnezdov <[hidden email]> wrote in message news:<[hidden email]>... > On Sun, 26 Jan 2003 11:25:07 +0100, "Jochen Riekhof" > <[hidden email]> wrote: > > >Hi... > > > >I would like to put some (small) feature requests: > [snip] > > Here is one of my feature requests. May be I just use IDE in a wrong > way. > > In a class browser I use Ctrl-Shift-F to open another class quickly. > I have to remember and type class name. I think it would be good to > provide a list of matching classes as you type. This list is > displayed below a text field entry and can be clicked on to open class > quickly. > > I know that if I type part of the class name and submit dialog box > contents I will get this list. The functionality is the same, but > user interaction could be improved. |
Daniel
You wrote in message news:[hidden email]... > Perhaps this could be extended to other entry fields, such as those > for categories, text search, etc. I'm not sure it would be feasible to incrementally filter all possible search strings for the full text search :-), but clearly if we implement this functionality for the next release it will done in a generic way (as an extension to Prompter I expect), and so we are likely to re-use it where it makes sense. For the full text search we'd probably filter against previous searches. Regards Blair |
Free forum by Nabble | Edit this page |