A small IDE suggestion

A small suggestion for anyone who likes extending their system tools, or which
OA might even like to consider for the base image.

I've found it very helpful to add a couple of entries to the CHB's method list
context menu.  Both apply only to class-side methods with no arguments.  One
just invokes the selected method, the other executes it and inspects the
result.

    -- chris

Chris Uppal wrote:

>I've found it very helpful to add a couple of entries to the CHB's method list
>context menu.  Both apply only to class-side methods with no arguments.  One
>just invokes the selected method, the other executes it and inspects the
>result.
>  
>
That would be handy for SUnit tests.  Integrate the test runner with the
class browser somehow.  So that from the one interface you run the
individual test, or all tests in the class.   Mmmm.

Mark

> I've found it very helpful to add a couple of entries to the CHB's method
> list
> context menu.  Both apply only to class-side methods with no arguments.
> One
> just invokes the selected method, the other executes it and inspects the
> result.

Is there a way to make changes to a context menu and store them in a
package? or would it be simpler to create a subclass which overrides
onAboutToDisplayMenu: or something?

Can a single modified view be stored in a separate package? I guess it
must.. When I
say view, I mean ViewResource...

> That would be handy for SUnit tests.  Integrate the test runner with the
> class browser somehow.  So that from the one interface you run the
> individual test, or all tests in the class.   Mmmm.

You can sort of do that already by right clicking on a subclass of TestCase
in the CHB and selecting "Tests | [Run|Browse]"

Sean,

> Is there a way to make changes to a context menu and store them in a
> package? or would it be simpler to create a subclass which overrides
> onAboutToDisplayMenu: or something?
>
> Can a single modified view be stored in a separate package? I guess it
> must.. When I
> say view, I mean ViewResource...

Look at IDE extensions.  They allow you to manipulate menus to your
liking, and would probably be the best option for additional ways to
launch the test browser.  The advantage is that you do not need to store
the extra view resource, and _should_ (see next paragraph) benefit
immediately from any changes to the tool you are extending.

FWIW, I recommend making most extensions inactive to start, mostly for
the benefit of your move to the next version of Dolphin.  The idea being
that you would load all packages, including extensions, make a backup,
and then start activating and, if necessary, debugging extensions.


 >>That would be handy for SUnit tests.  Integrate the test runner
 >>with the
 >>class browser somehow.  So that from the one interface you run the
 >>individual test, or all tests in the class.   Mmmm.
 >
 > You can sort of do that already by right clicking on a subclass
 > of TestCase
 > in the CHB and selecting "Tests | [Run|Browse]"

My strongest wish for the unit test browser is to have selections
preserved on reset.  I recall reading that it was supposed to be fixed,
but either I'm running an older version, or perhaps keep shooting it in
the foot some other way.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Mark,

> That would be handy for SUnit tests.  Integrate the test runner with the
> class browser somehow.  So that from the one interface you run the
> individual test, or all tests in the class.   Mmmm.

also, this:

http://www.dolphinharbor.org/dh/projects/goodies/sunitBrowserIDE.html

Regards,

Sean

On Tue, 14 Sep 2004 07:28:34 +1000, Sean Malloy <[hidden email]>  
wrote:

>> That would be handy for SUnit tests.  Integrate the test runner with the
>> class browser somehow.  So that from the one interface you run the
>> individual test, or all tests in the class.   Mmmm.
>
> You can sort of do that already by right clicking on a subclass of  
> TestCase
> in the CHB and selecting "Tests | [Run|Browse]"

And I bind a shortcut (Ctrl-0), to send #runTests and then #setFocus back  
to the same CHB shell.

--
Regards
Hwee Boon
MotionObj

Chris Uppal wrote:

> just invokes the selected method, the other executes it and inspects the
> result.

how about this:

Add an extra TAB into the browser's
bottom pane, which shows the result
of executing the currently selected
method.

This could be extended to give other
textual information about the method
selected, such as its different
definitions, its senders, and messages
sent in it.

And why not go further and below those
show also the  source-code of all those
definitions 'local' senders as well.

Then we could see all this info in one
place, without having to struggle with
the menu.

-Panu Viljamaa

"panu" <[hidden email]> wrote in message
news:[hidden email]...
That area of Dolphin's class browsers is user extensible by adding "Class
Browser Plugins". The Class Diagram is an example of such a plugin, the sole
example in Dolphin 5 in fact. We have a number of additional plug-ins for
Dolpin 6: The Code Mentor (a Smalllint-based coding assistant), The Code
Rewriter (a rewrite tool), and Disassembler (disassembles method bytecodes),
and we'll probably add more (e.g. an SUnit browser). I think your suggestion
is interesting, but that it might turn out to be too cramped and like
working through a letterbox. Why not try it out yourself, at least to the
extent of mocking it up to see how usable it would be. To add a new one,
define a new subclass of ClassBrowserPluginAbstract, draw up a view for it
(copy that of ClassDiagramPlugin), and then add it to the browser using
plugins aspect of the Class Browser in User Preferences.

Regards

Blair

Blair McGlashan wrote:
> ...  Why not try it out yourself, at least to the
> extent of mocking it up to see how usable it would be.

Thanks for the suggestion and advice. If I find
the time perhaps I will. Thinking a bit further
on what I'd /really/ like to do is to have a
'Method Description Tab' that contains *hyperlinks*.
Those would lead to other parts of the documentation,
or would open further browsers on linked-to items,
etc.

How feasible would it be to hypertext-enable
the tab-panes?

Thanks
-Panu Viljamaa

"panu" <[hidden email]> wrote in message
news:[hidden email]...
Our Code Mentor uses an embedded browser (Internet Explorer) control for
just that purpose. The IE control sends a 'BeforeNavigate2' event when a
link is clicked, this includes the URL associated with the href. You can
define your own protocol and look for that and act accordingly, allowing the
control to perform its normal navigation for other protocols. For example
you could define a 'smalltalk:' protocol that is followed by an expression
to be evaluated - of course this is not very secure, and would not be
appropriate for browsing HTML from external sources.

The 'Simple Web Browser' & 'Autoplay' samples both demonstrate the use of IE
control, and indeed hook the aforementioned navigation event. You can also
find it used in Ian and Bill's DSDN. All of these demonstrate interference
with the browser's default hyperlink navigation, particularly the last. For
URLs that you want to intercept you can tell the brower not to do anything
(by setting a boolean value holder argument), and then take your own
actions.

Another approach might be to have the hyperlinks refer to a Swazoo server
running in the same image. A whole IDE could be built like that to run in a
browser I suppose.

Regards

Blair