Some feature requests for D6

"kuo" <[hidden email]> wrote in message
news:[hidden email]...
> of any serious AI-oriented task force. At present, Steve's Scheme package
is
> a good stuff to start with, and maybe worthy of integrated inside, as an
> environment-oriented shell-like goodies ( Prolog in Smalltalk/V etc).
> It would add more enhanced and limitless logic and inference power to
> Dolphin.. I think. :-)

Do you know how much are such engines used (just wondering how interesting
is this for wider public)?

There is some prolog in smalltalk implementation (probably this is
Smalltalk/V you are refering to), maybe it could be adopted for Dolphin? But
I do not know how efficient is thois implementation, i.e. is it usable or
more or less a toy?

Also maybe Amzi Prolog can be wrapped from Dolphin (Amzi is written as
component so it can be called from other languages).

rush
--
http://www.templatetamer.com/

I agree with your opinion of using DLL wrapping technique to make use of
those already mature and power products such as Amzi, or Trinc Prolog or
Strawberry Prolog, to mention those I've known. But I think Dolphin would be
more intelligent if by nature, she can understand some AI words.
    In the future days, I think AI is an evitable direction to approach, the
sooner the better, no matter we are computer layman or sophisticated
programmer.
    So, why not let Dolphin has a little built-in inference machine, step by
step, right now, so as to make her grow more quickly and has the ability to
think brightly ( I look forward: Could knowledgeBase also possibly be
created
or incoorporated with object-Database in Object-World ? ).    :-)

> "rush" <[hidden email]> wrote in message
 > Do you know how much are such engines used (just wondering how
interesting
> is this for wider public)?
>
> There is some prolog in smalltalk implementation (probably this is
> Smalltalk/V you are refering to), maybe it could be adopted for Dolphin?
But

"kuo" <[hidden email]> wrote in message
news:[hidden email]...
>     So, why not let Dolphin has a little built-in inference machine, step
by
> step, right now, so as to make her grow more quickly and has the ability
to
> think brightly ( I look forward: Could knowledgeBase also possibly be
> created
> or incoorporated with object-Database in Object-World ? ).    :-)

As a member of prolog-implementors-anonymous support group, I do get tempted
from time to time to make smart smalltalk based prolog implementation, but
nowdays I am getting over the temptation rather quickly :) . Sounds nice but
there is a quite a lot of work to do, and I am not sure how many people
would be using it, since it's targeted audience is a cross of two rather
small populations of programmers.

rush
--
http://www.rush.avalon.hr/

Blair McGlashan wrote:

> ...We could certainly add an enhancement request for that, but whether
> it gets
>
>done will depend on the amount of effort involved.
>
Although I'm not a regular Dolphin user, let me enter my
wish: Concentrate on usability, not bells, whistles
and pastel colored icons.

Usability in terms of software development: How do I start
a project, keep versions of it around, don't ever lose
anything.  How do I take the whole project from start to
finish in a managed way, without getting confused by the
myriad ways of doing the same thing.

In other words I'm asking for a tasks-support environment.
One that would make the things most important and most frequent
in production coding as easy and intuitive as possible.

Best Regards
-Panu Viljamaa

Panu,

"panu" <panu@fcc.net_zerospam> wrote in message
news:[hidden email]...
I'm not sure how to take this.  At first glance it seems like a criticism of
the fact that we have tried to make the Dolphin user interface "look good".
As you may be aware, for a long time the Smalltalk community was criticised
for putting no effort into marketing, whilst other languages such as Java
grew in popularity almost solely on that basis.  Whilst we don't have the
money to do much "true" marketing we have thought it important to make the
Dolphin user interface look modern and behave in a responsive way.  By doing
so, it shows by example that a developer can really create modern looking,
responsive applications using the tool.

> Usability in terms of software development: How do I start
> a project, keep versions of it around, don't ever lose
> anything.  How do I take the whole project from start to
> finish in a managed way, without getting confused by the
> myriad ways of doing the same thing.
>
> In other words I'm asking for a tasks-support environment.
> One that would make the things most important and most frequent
> in production coding as easy and intuitive as possible.

However, maybe I'm being oversensitive since I was directly responsible for
much of the work on the recent Windows XP style icons in Dolphin 5. Have you
actually tried to use a recent version of Dolphin to develop anything for
real?  Do you think it is harder to use than any of the other competing
Smalltalks?  I would find it hard to believe that you think it worse in
these respects than, for example, Squeak, VisualWorks or VAST.

Maybe you're not been critical of the current system at all but just
offering some suggestions as to how it could be improved in future. In which
case, I agree that there is a great scope for making it easier for new users
to get to grips with a Smalltalk-style workflow.  As you know, Smalltalk was
one of the first computer systems to advocate a non-modal approach to
workflow by introducing multiple overlapping windows.  This made things very
flexible for experienced users and stopped inexperienced users becoming
"trapped in a mode" that they didn't know how to get out of.  However, it
also introduced the "problem" of multiple ways to do the same thing.

Microsoft have obviously discovered the same issue with the Windows
operating system which has, gradually over the years, actually become more
tricky for noncomputer users to get the hang of; mainly because it has grown
in complexity.  One of the possible solutions to this same problem in the
Dolphin arena (and it is something we have briefly discussed) would be to
follow Microsoft's lead and introduce the Windows XP-style task prompts that
appear in each of its system windows. Interestingly, this amounts to adding
even more "bells and whistles" to the product which some users might
consider unwarranted.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

Andy Bower wrote:

>... Maybe you're not been critical of the current system at all but just
>offering some suggestions as to how it could be improved in future.
>
Right Andy. Dolphin may be the best ST environment, but
there is always room for improvement, especially in the
area of "usability".

Let me give you a few examples:
 
I.
When I worked on Dolphin (4) I spent a lot of time
trying to get the 'clutter' out of the environment.
I found the repeating ST-tool-icons distracting,
when the same functionality is already available
from the Tools-menu. Similarly I found the color-
coded source detrimental to readability. (Imagine
reading a book with all text being color coded).
I found the italized green comments disorienting
and hard to modify.

Fortunately - since this is Smalltalk - I was able
to disable these features by digging into the system
a bit. I also got rid of the icons in front of every
class in the browser. (Unfortunately I wasn't able to
disable the icons from the methods list though).

This maybe a purely personal preference, but I think
the multitude of icons, many with hard to decipher
meanings, simply results in information overload.


II.
Here's an example of a feature which on first thought
might seem to increase usability but really doesn't:

When I look at a method in the CHB, I typically want to
see how it is used, by looking at its senders. In many
Smalltalks I would choose 'senders' from the right-click
menu. But in Dolphin you get a feature that does more:
Choosing 'References to' pops up a *submenu* which allows
you to see the senders of either a) the method in question
or b) senders of any method used within it.

Now this may seem like a great enhancement, because the
system is "doing more". Unfortunately it means that "you
also must do more": You must click on TWO different menus,
and move the mouse between each click, to see the senders.

Yet, I *almost always* simply want to see the senders
of the current method - the one I'm interested in!
Since this task occurs so frequently it would save
a lot of effort if it was doable with a single menu
pick, instead of two.

So, usability is about making it easy for the user to
do the frequently occurring tasks *more easily*, than
the less frequent ones.  

Again, it is probably possible to change the menus,
somehow. But it doesn't work in practice if every
Dolphin user needs to go through the same effort
every time they start with a clean image, or upgrade
to the next version of Dolphin. It seems relatively
difficult to share such improvements amongst the user-
community, and between Dolphin versions.


III.
I fully understand that achieving great usability
is difficult. The other unfortunate issue is that
usability is *hard to quantify* - and thus use in
marketing.

It is probably better for the marketing of Dolphin
that "Everything has an icon!", than having a system
with only a few icons, but better usability in practice.
 
It is easier to sell a feature that "Finds senders of
*both* the current method and *also* of every other
method being called", than one that more easily, but
plainly, shows the senders only. Even though the latter
would make the end-user more productive, in day-to-day
programming.

One way around this marketer's dilemma would be to have
and advertize a feature that "Allows Dolphin users to
easily trade usability enhancements between themselves,  
resulting in continually increasing productivity, based
on the usage patterns of actual users".

I'm not aware of how easy this would be in practice.
But maybe there is a way. Maybe we could have different
'skins' for Dolphin, if that is technologically feasible.

Anyway, I think Dolphin is a great system. Therefore
it deserves to have its usability - user productivity -
maximized.

Best regards and success
-Panu Viljamaa

Panu,

> When I worked on Dolphin (4) I spent a lot of time
> trying to get the 'clutter' out of the environment.
> I found the repeating ST-tool-icons distracting,
> when the same functionality is already available
> from the Tools-menu.

I always use the icons rather than the Tools menu.  I suppose it just
depends on your preferred way of working (mouse v shortcut keys maybe?) but
a Dolphin without toobar icons would seem crippled to me!.

>                                   Similarly I found the color-
> coded source detrimental to readability. (Imagine
> reading a book with all text being color coded).

Are you normally working in an environment where the source is not colour
coded?.  It might be that you are just not used to it but I would hate the
thought of going back to black on white.

> I found the italized green comments disorienting
> and hard to modify.

I agree with this.  I find the mono green text and italic font combination
difficult to read.  One of my fixed changes to Dolphin is to change the font
for comments

> Fortunately - since this is Smalltalk - I was able
> to disable these features by digging into the system
> a bit. I also got rid of the icons in front of every
> class in the browser. (Unfortunately I wasn't able to
> disable the icons from the methods list though).

The class side icons could arguably be dispensed with (although I would miss
them) but the method ones are very useful, giving an immediate feedback on
the public/private/deprecated status of the method.

> This maybe a purely personal preference, but I think
> the multitude of icons, many with hard to decipher
> meanings, simply results in information overload.

I disagree. I find they provide an immediate feedback of aspects/attributes
that would otherwise require further investigation via a menu selection.

> Now this may seem like a great enhancement, because the
> system is "doing more". Unfortunately it means that "you
> also must do more": You must click on TWO different menus,
> and move the mouse between each click, to see the senders.

Just double click on the item in the first menu - if automatically invokes
the default (bold) option on the second menu.

--
Ian

panu wrote:

> Right Andy. Dolphin may be the best ST environment, but
> there is always room for improvement, especially in the
> area of "usability".

You take an interesting viewpoint, but I find that I don't agree with it at
all.

And I'm speaking as a Confirmed Ludite here ;-)


> When I worked on Dolphin (4) I spent a lot of time
> trying to get the 'clutter' out of the environment.
> I found the repeating ST-tool-icons distracting,
> when the same functionality is already available
> from the Tools-menu.

I'd rather have the toolbar.  In fact I keep meaning to add an enhancement to
allow me to start the tools I use most often (workspace, CHB) from the Windows
system tray.


> Similarly I found the color-
> coded source detrimental to readability. (Imagine
> reading a book with all text being color coded).

Oddly, I disagree with this.  It's odd because in *every single* other IDE or
IDE-like environment I've ever used (for any language), I've found the syntax
coloring to be an irritating and distracting waste of time.  I make an
exception for marking comments somehow (which can be useful), but I don't leave
any other syntax highlighting enabled in other IDEs.  I don't know why
Dolphin's works for me, but others don't.  Possibly its a mixture of the fact
that (IMO) Smalltalk needs a bit of help to show its structure, coupled with
the way Dolphin *doesn't* do dynamic updates.  I've messed a little with ST-X,
which does do dynamic updates, and found it infuriating.


> I found the italized green comments disorienting
> and hard to modify.

I agree that that's a bad choice.  Italics have no place in low resolution (say
<300 dots per inch) displays.  It does seem to be traditional, though (I can't
imagine why).  It's not hard to modify:
     Compiler syntaxColorAt: #Comment put:  '\cf4 '.
will turn off italics.  Perhaps there should be configuration options for this,
but it doesn't bother me much.

While I'm on the subject, one thing I would like to see, someday, is a separate
syntax colour for unary sends.  (Teal seems to work well).  I find that many of
my avoidable mistakes are down to my missing the $: off the end of a keyword.


> Fortunately - since this is Smalltalk - I was able
> to disable these features by digging into the system
> a bit. I also got rid of the icons in front of every
> class in the browser. (Unfortunately I wasn't able to
> disable the icons from the methods list though).

You do realise that the Views used for all the system tools are configurable ?
See the "Simple Class Browser" (in extra tools) for an example.

I think you'd be making a mistake to loose the method icons, though.  The
information they provide is important.

(I like the tree icons too, although they convey less information. I find that
they help me keep my place in the
tree.)


> So, usability is about making it easy for the user to
> do the frequently occurring tasks *more easily*, than
> the less frequent ones.

Yes but which user ?  I, for instance, probably use the other items in the
"senders of"/"references to" menus at least as often as I use the "main" items.


> It seems relatively
> difficult to share such improvements amongst the user-
> community, and between Dolphin versions.

That is fairly true.  In fact OA have added quite few "hooks" to allow us to
extend/modify the systems tools, but the most significant ones only came in in
D5, and are not yet widely used.  Ian Bartholomew's stuff uses them, but I
can't offhand think of any other distributed code that takes advantage of them.
Of course, there's always room for further improvement.


> Maybe we could have different
> 'skins' for Dolphin, if that is technologically feasible.

That's almost exactly what the configurable View stuff gives you.

    -- chris

> Are you normally working in an environment where the source is not colour
> coded?.  It might be that you are just not used to it but I would hate the
> thought of going back to black on white.

It was one of the reasons I decided to buy Dolphin.


>Just double click on the item in the first menu - if automatically invokes
>the default (bold) option on the second menu.

Ian, couldn't you have mentioned this a bit earlier ;-)

Ciao

...Jochen

Ian Bartholomew wrote:

> Panu wrote:
>
> > Now this may seem like a great enhancement, because the
> > system is "doing more". Unfortunately it means that "you
> > also must do more": You must click on TWO different menus,
> > and move the mouse between each click, to see the senders.
>
> Just double click on the item in the first menu - if automatically invokes
> the default (bold) option on the second menu.

Ian, that's a great general tip. I'll see if I can't train myself to start using
it. :-)

Panu, I feel your pain on getting senders/implementers from the menu. Having
used other Smalltalks for a number of years, I definitely had implements/senders
burnt into my brain. Every time I opened the menu, there was a long pause as I
mentally translated what I was looking for (implementors or senders) into
"definitions" or "references". Add to that the question of Local or not, and
then the submenus, and yes, I found usability issues.

For myself, I've found that simply using the F12/Shift-F12 hot keys for the
common case, and going to the menu only for the local case and/or sub-menu
selections works well. Give that a try for a while.

Speaking of Local Definitions/References ...
Anyone else notice that the definition of "local" is less than ideal when it
comes to inherited methods? It seems that it would be MUCH more useful if it
gave definitions/references that were "local" relative to the selected class (in
class and system browsers), rather than relative to the class that implements
the method (which appears to be what it's using -- haven't dug into it yet). The
worst case is if the method happens to be inherited from Object, in which case
the "local" (even when you're browsing one of your own application classes) ends
up giving nearly the same definitions/references as the global case (except for
proxies). Seems clear cut enough, that I'd be inclined to call the way it
currently works a bug. ;-) Okay, whether current behavior is a bug of a
"feature", consider this a request for a feature enhancement.

regards,
-Bill

-------------------------------------------
Bill Dargel            [hidden email]
Shoshana Technologies
100 West Joy Road, Ann Arbor, MI 48105  USA

"Jochen Riekhof" <[hidden email]> wrote in message
news:[hidden email]...
> > Are you normally working in an environment where the source is not
colour
> > coded?.  It might be that you are just not used to it but I would hate
the
> > thought of going back to black on white.
>
> It was one of the reasons I decided to buy Dolphin.
>
>
> >Just double click on the item in the first menu - if automatically
invokes
> >the default (bold) option on the second menu.
>
> Ian, couldn't you have mentioned this a bit earlier ;-)

It is a standard Windows UI convention that emboldened items are 'Defaults'.
Whenever you see an emboldened item on a sub-menu, this is a queue that it
will be actioned by double-clicking the parent menu.

Alternatively, in this case, the accelerator Shift-F12 would do the job.

OK, so having dismissed this usability complaint as baseless, perhaps Panu
would like to list some others so that we can either disabuse him of his
ignorance, or use the feedback to improve the system.

Blair

"Blair McGlashan" <[hidden email]> wrote in message
news:b3cnq4$1ksdk2$[hidden email]...
>...
> Whenever you see an emboldened item on a sub-menu, this is a queue that it
> will be actioned by double-clicking the parent menu.

Of course that should have been "cue", just in case anybody was thinking
they had to form a line :-).

Regards

Blair

Blair,

> OK, so having dismissed this usability complaint as baseless, perhaps
> Panu would like to list some others so that we can either disabuse
> him of his ignorance, or use the feedback to improve the system.

This is one usability issue that has been bugging me for some time  - just
not bugged me enough to do anything about it :-).

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.

It might actually be useful in a wider sense as well - maybe as an
interchangable Prompter subclass.

--
Ian

"Ian Bartholomew" <[hidden email]> wrote in message
news:b5m6a.6957$Lq.552042@stones...
> ...
> This is one usability issue that has been bugging me for some time  - just
> not bugged me enough to do anything about it :-).
>
> 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.

Thanks Ian, now that would be an improvement. Do you think the
Definitions/References recent searches lists should be separate, or
combined? I think combined would be best, with a separate list for Find
Class.

>
> It might actually be useful in a wider sense as well - maybe as an
> interchangable Prompter subclass.

Indeed, any suggestions for a name?

Regards

Blair

Blair,

>  I think combined would be best, with a separate list for
> Find Class.

Sounds good to me.

As a supplementary :-).  Edit, the add-on editor for Smalltalk/V, used to
have a way of limiting the scope for searches which could, at times, be
useful.  Might it be possible to add something like that to the search
dialog for definitions/references.  Nothing complicated, maybe just a couple
of buttons that match the options on the method context menu ("Search
Global" and "Search Local")

> Indeed, any suggestions for a name?

Not really, it's difficult to find something that fits with a root of
"Prompter" isn't it.  The best I could think of was to reverse it and use
"HistoryPrompter" or "HistoricPrompter" but I can't say they really appeal.

--
Ian

Blair McGlashan wrote:

>> It might actually be useful in a wider sense as well - maybe as an
>> interchangable Prompter subclass.
>
> Indeed, any suggestions for a name?

How about just adding an optional "suggestions" or "hints" list to the standard
Prompter ?

But if you really want a name, then "SuggestivePrompter" ?

(OK, that's a joke, but "HintedPrompter" sounds reasonable to me.)

    -- chris

Ian Bartholomew wrote:

> ...Just double click on the item in the first menu - if automatically
> invokes the default (bold) option on the second menu.

Great trick, thanks.
I assume there are others like it too, unknown to me.
Maybe it would be help to have a "Top-10 most useful
Dolphin shortcuts" published somewhere.

This really helps. Thanks again
-Panu Viljamaa

Blair McGlashan wrote:

> ... OK, so having dismissed this usability complaint as baseless,
> perhaps Panu
>
>would like to list some others so that we can either disabuse him of his
>ignorance, or use the feedback to improve the system.
>
The complaint would have been baseless if I had known about
the double-click  trick, or if there had been an obvious way
to find out about it. It's not "usable" if it's difficult to
know  how to use it. And I might add, double click is still
double the trouble.

I'm not trying prove Dolphin as "unusable". Just saying that
usability should in general be the top of the list of
goals when developing an IDE. Also, I only have Dolphin 4,
so my user-experience may be out of date already. But here's
one more example of the type of thing I'm talking about:

* In many Dolphin (4) windows if I click on Ctrl-B, I get the
  Class Hierarchy Browser.
* But in "Protocol Browser" Cntrl-B does nothing. Similarly
  in the blue-background start-window and Transcript.
* Now that I already learned the Cntrl-B trick, it's
  frustrating that it "only sometimes works".

Not a big thing, but devil is in the (many) details.

-Panu Viljamaa

Panu,

"panu" <panu@fcc.net_zerospam> wrote in message
news:[hidden email]...
But it's not a Dolphin "trick"; it's standard Windows feature.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

Andy,

> > The complaint would have been baseless if I had known about
> > the double-click  trick, or if there had been an obvious way
> > to find out about it. It's not "usable" if it's difficult to
> > know  how to use it. And I might add, double click is still
> > double the trouble.
>
> But it's not a Dolphin "trick"; it's standard Windows feature.

Ok, it's a standard Windows "trick" :)  Actually, it might explain some
weird/unwanted things that I've seen in other apps.

However, the point of my post is to mention one thing about the
definitions/references menus: in building the alphabetical list of "all"
selectors, Dolphin excludes the symbol corresponding to the browser's
selected method.  I like having it separated at the top (very helpful when
one is thinking about the selected method).  But, it might help to alsoleave
it in the alphabetical list.  My "struggle" has seldom been which menu to
follow (I generally like the way it works), but I do sometimes find myself
searching the list of selectors and then finally noticing that the one I
want is on the top.

Have a good one,

Bill

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