Better search for string in image.

Hi.

  I was wondering whether Dolphin 6 will have a better way to search
for a string through the whole image. I was hoping for it to allow us to
do a case sensitive search and perhaps use regular expressions.

  Best regards,
    Jurko

Jurko,

>   I was wondering whether Dolphin 6 will have a better way to search
> for a string through the whole image. I was hoping for it to allow us
> to do a case sensitive search and perhaps use regular expressions.

I agree it would be nice for the searches to be more flexible in both
the search string and the ability to restrict the scope of the search.
Anyone remember the edit add-on package for Smalltalk/V that was very
good in this regard.

As a temporary measure DSDN will do case sensitive and whole word only
searches across selected text sources.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Hi Ian.

> As a temporary measure DSDN will do case sensitive and whole word only
> searches across selected text sources.

  Thanks. Completely forgot about DSDN. :-)) Only used it before to search
the news archives and wiki, but never the image itself :-)))

  Best regards,
    Jurko

"Jurko Gospodnetiæ" <[hidden email]> wrote in message
news:c0fvlk$9ev$[hidden email]...
>   Hi.
>
>   I was wondering whether Dolphin 6 will have a better way to search
> for a string through the whole image. I was hoping for it to allow us to
> do a case sensitive search and perhaps use regular expressions.

I've added your enhancement request (#1496), and it might get done, but I
think it is unlikely to be in this release as there is still so much else to
complete.

Thanks for the suggestion

Regards

Blair

Jurko Gospodnetiæ wrote:
> I was wondering whether Dolphin 6 will have a better way to search
> for a string through the whole image. I was hoping for it to allow us to
> do a case sensitive search and perhaps use regular expressions.

In D4 a *curious* thing happpens - perhaps in D5 as well.

When the active window is a Workspace and I press F12,
a dialog pops up saying "Enter Selector, may be wildcarded!"

I can then enter a wildcarded selector, and get a list-browser
for all methods that match. This is TRULY useful.  I need it
much more often than a general "Search for methods CONTAINING
text..."

Curiously, this functionality is *not* available in any of
the menus of the system, as far as I can see. Also annoyingly,
F12 does not work on all views.

I would hope D6 will remedy the situation since it should be
a minor addition to the menus, right?

Thanks

-Panu Viljamaa

Panu,

> Curiously, this functionality is *not* available in any of
> the menus of the system, as far as I can see.

It does appear in most of the browsers - just not as obvious as it might
be.

In the SystemFolder it's under the main Browse menu - Definitions Of or
References To.

In most other browsers (ones that have a workspace anyway) these two
options are in the _context_ menu for workspaces under Browse.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Hi Ian.

> As a temporary measure DSDN will do case sensitive and whole word only
> searches across selected text sources.

  Hmmm... just tried using DSDN for doing a case-insensitive search through
the
image, but DSDN seems to search only through method comments, not through
the whole method bodies. :-(

  Best regards,
    Jurko

Jurko,

>   Hmmm... just tried using DSDN for doing a case-insensitive search
> through the
> image, but DSDN seems to search only through method comments, not
> through the whole method bodies. :-(

DSDN/Tools/Options/Inspect and set 'includeMethodSource' to true.

Should have mentioned that before - sorry.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Jurko,

>   Hmmm... just tried using DSDN for doing a case-insensitive search
> through the
> image, but DSDN seems to search only through method comments, not
> through the whole method bodies. :-(

DSDN/Tools/Options/Inspect and set 'includeMethodSource' to true.

Should have mentioned that before - sorry.

--
Ian

Hi Ian.

> DSDN/Tools/Options/Inspect and set 'includeMethodSource' to true.
>
> Should have mentioned that before - sorry.

  Thanks! Works now :-)))

  I've got some old sources to go through to find many hardcoded
filenames - and all of them seem to be capitalized differently :-))

  Jurko

Ian Bartholomew wrote:

> In most other browsers (ones that have a workspace anyway) these two
> options are in the _context_ menu for workspaces under Browse.

Thanks Ian,
I got it now.

I would still think it more helpful for it to open
from  the "straight" top-of-the-window menu-bar,
perhaps as "Method->Browse-definitions"

Actually I wish it was available from /everywhere/,
because typically I know at least part of the class-
or method-name I want to browse already /before/ I
open a browser.

So why not  make entering this information part of the
process of opening the browser, in the easiest way possible!

Finding the right place to work on should be absolutely
easy and fast. Any improvement in reduction of steps
here pays off well in increased productivity and less
frustration.

Here's one possible way:

1. In *every* File-menu, and *every* context menu, add 3 options:

2. "Browse Class"  - Open a dialog where you can enter a class-name
                      with wildcards, with starting and ending wildcards
                      implicitly assumed, unless there is an exact match.

3. "Browse Method"  - Open a dialog where you enter a selector name with
                       wildcards, but again implicit wildcards unless
                       there is an exact match.
4. "Browse Package"  - similar as above, but for packages

5. Make sure there is an accelerator key for all these 3 menus
    that is the same everywhere when Dolphin is running
     (say F10, F11, F12).

6. If there is a selection in the active window, use it as
    a default for the dialog - as is currently with F12. But
    assume the wildcard is there implicitly, unless there is
    an exact match.


What's a bit frustrating is that even though Smalltalk is
supposed to be an 'open' system, 1) it doesn't seem at all
clear what is the *general* procedure to /figure out how/
to accomplish the above, and then 2) how to make these
changes into a change-set that could be easily loaded into
any virgin image.

Thanks
-Panu Viljamaa

panu,

>                             2) how to make these
> changes into a change-set that could be easily loaded into
> any virgin image.

You can just modify the existing browsers and save the new versions into
an installable package but that's probably not the best way to go if you
want to port the changes to the next Dolphin version.  Because of this
OA added a new dynamic browser modification facility in Dolphin5 - see
the OAIDEExtension class for an example of how it can be used.  You can
intercept any browser between it's creation and being opened and fiddle
about with the menu structure to add/remove what you want.  For example
(and the following is _just_ a quick example that would need more work
to provide what you want) file in the following and then evaluate
"MyIDEExtensions initialize".  You will then fins a Browse Class item
has been added to the File menu of new ClassBrowserShell and
SystemBrowserShell tools

-~-~-~-

"Filed out from Dolphin Smalltalk XP"!

Object subclass: #MyIDEExtensions

instanceVariableNames: ''

classVariableNames: ''

poolDictionaries: ''

classInstanceVariableNames: ''!

MyIDEExtensions guid: (GUID fromString:
'{1F3D452D-0CCD-420E-B490-77BB3ED8832D}')!

MyIDEExtensions comment: ''!

!MyIDEExtensions categoriesForClass!Kernel-Objects! !

!MyIDEExtensions class methodsFor!

browseClass

| class |

class := SmalltalkSystem current chooseClass.

class notNil ifTrue: [class browse]!

initialize

"self initialize"

ClassBrowserShell

when: #viewOpened:

send: #onBrowserOpened:

to: self.

SystemBrowserShell

when: #viewOpened:

send: #onBrowserOpened:

to: self!

onBrowserOpened: aBrowser

aBrowser view menuBar

ifNotNil:

[:menuBar |

(menuBar find: 'File' ifAbsent: [])

ifNotNil:

[:menu |

menu

insertItem:

(CommandMenuItem

commandDescription:

(ClosedCommandDescription

command: (Message selector: #browseClass)

description: 'Browse Class'

receiver: self))

at: 8.

menu insertItem: DividerMenuItem separator at: 9]]! !

!MyIDEExtensions class categoriesFor: #browseClass!public! !

!MyIDEExtensions class categoriesFor: #initialize!public! !

!MyIDEExtensions class categoriesFor: #onBrowserOpened:!public! !



--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Ian Bartholomew wrote:

> You can just modify the existing browsers and save the new versions into
> an installable package but that's probably not the best way to go if you
> want to port the changes to the next Dolphin version.

Just to add to this, there's another set of "hooks" that can be used to extend
the base system.  Just about all the main tools are launched via a level of
indirection that allows you to plug in your own implementation of the ToolShell
class, or your own replacement View for an existing ToolShell class.  Try the
system folder's tools=>options=>inspect command.  For instance, I use this
feature to replace the default CHB by my own slightly extended version.

Also, as Blair pointed out recently (and I, for one, had not realised this),
the SmalltalkSystem class itself is intended to be subclassed, and the
singleton instance replaced.  Thus allowing you to substitute your own
implementations of any of the "system" operations.

    -- chris

Chris Uppal wrote:

...
> Also, as Blair pointed out recently (and I, for one, had not realised this),
> the SmalltalkSystem class itself is intended to be subclassed, and the
> singleton instance replaced.  Thus allowing you to substitute your own
> implementations of any of the "system" operations.

That sounds great.  The only problem, as you acknowledge,
is that it may be hard to realize it is there.

I think customizability is one of the fortes of Smalltalk.
Having some documentation or marketing materials about this
would be great.

Thanks
-Panu Viljamaa

panu wrote:

> That sounds great.  The only problem, as you acknowledge,
> is that it may be hard to realize it is there.

Well, naturally I'm not going to respond: "any halfway competent developer
would see these things immediately" ;-)

So, yes, I've got to agree.

    -- chris