Some feature requests for D6

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
59 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: About usability Re: Some feature requests for D6

panu-2
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


Reply | Threaded
Open this post in threaded view
|

Re: About usability Re: Some feature requests for D6

Ian Bartholomew-18
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


Reply | Threaded
Open this post in threaded view
|

Re: About usability Re: Some feature requests for D6

panu-2
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.
>
>  
>


Reply | Threaded
Open this post in threaded view
|

Re: About usability Re: Some feature requests for D6

Blair McGlashan
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


Reply | Threaded
Open this post in threaded view
|

Re: About usability Re: Some feature requests for D6

Ian Bartholomew-18
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


Reply | Threaded
Open this post in threaded view
|

Re: About usability Re: Some feature requests for D6

Chris Uppal-3
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


Reply | Threaded
Open this post in threaded view
|

Re: About usability Re: Some feature requests for D6

Blair McGlashan
"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


Reply | Threaded
Open this post in threaded view
|

Re: About usability Re: Some feature requests for D6

panu-2
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


Reply | Threaded
Open this post in threaded view
|

Re: Some feature requests for D6

Mark Wilden
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!


Reply | Threaded
Open this post in threaded view
|

Re: Some feature requests for D6

Mark Wilden
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. :)


Reply | Threaded
Open this post in threaded view
|

Re: About usability Re: Some feature requests for D6

Mark Wilden
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.


Reply | Threaded
Open this post in threaded view
|

Re: About usability Re: Some feature requests for D6

Mark Wilden
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. :)


Reply | Threaded
Open this post in threaded view
|

Re: About usability Re: Some feature requests for D6

Blair McGlashan
"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


Reply | Threaded
Open this post in threaded view
|

Re: About usability Re: Some feature requests for D6

Mark Wilden
"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. :)


Reply | Threaded
Open this post in threaded view
|

Re: Some feature requests for D6

Sergei Gnezdov
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.


Reply | Threaded
Open this post in threaded view
|

Re: Some feature requests for D6

Blair McGlashan
"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


Reply | Threaded
Open this post in threaded view
|

Re: Some feature requests for D6

Dmitry Zamotkin-4
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


Reply | Threaded
Open this post in threaded view
|

Re: Some feature requests for D6

Daniel Rozzeta
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.


Reply | Threaded
Open this post in threaded view
|

Re: Some feature requests for D6

Blair McGlashan-2
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


123