Editing class method sources in single place

On 30-Jan-08, at 6:26 PM, itsme213 wrote:

It sounds to me like you're talking about being able to drag and drop  
from one browser to another. Is that right?

> Perhaps the new OB framework makes these more doable?

Possibly.

Colin

On Wed, 30 Jan 2008 09:18:17 -0800, Zulq Alam <[hidden email]> wrote:

> Perhaps the Whisker browser would be a good place to start.
>
> http://www.mindspring.com/~dway/smalltalk/whisker.html
>
> Not sure about the status of the project.

That's actually a fairly horrifying screenshot.

I installed it and it actually looks pretty clean. Fussy though. DNUs in  
my current image.

OS/2 used to have this grand concept of a workspace. I have missed it in  
every environment I've used since then. "Show me everything I need and  
only what I need...."

        ===Blake===

On Jan 31, 2008 1:13 AM, tim Rowledge <[hidden email]> wrote:
>
> That's exactly where having many browsers open at once is a big win. I
> typically have 5 - 10 browsers open. A couple where I might be in the
> midst of editing, a couple open on related methods, some available for
> looking up stuff. I've been doing it that way since a 640*400 screen
> was a luxury. Why add the complication of window splitting when it is
> merely a poor attempt at what we already have?

This is how I work too.  And the new enhancements with the task
switching makes working this way even more pleasant/efficient.

On Jan 30, 2008 11:39 PM, Igor Stasenko <[hidden email]> wrote:
> What benefits i see, comparing to single-method view.
>
> You can scroll to other method using keys, instead click-click , open
> new browser window and click, totally losing your focus.

That has nothing to do with how many methods are in the text area and
everything to do with the browser implementation.

> You can do a full-text search on listing.

I don't understand this one.  Do you mean constrain searches to less
then "the whole image"?

> With some shortcuts it's easy to make actions like moving caret to
> different method, simply by typing first letters of it's selector.

And why would this be any harder to do in a single method view?  Think
about emacs for example.  As many features as one cares to add and all
accessible without removing your hands from the keyboard.  I can
envision doing a Ctrl+M (m for method) popping up a little text box
where I type in the method I want to zoom to.  And if we could make
the browser project aware it would only search for methods in the
current project.

> - more area for text editing/view. Yes, most of the methods are too
> short, that you can say it's not worth it, but consider when you can
> see multiple methods in single big window,

But why do you want to see multiple methods in a single window?  Do
you want to switch quickly?  There are potentially more efficient ways
then the overly simplified "just stick it all in the same window like
notepad".  Do you want to compare one method with another?  That
sounds like a special feature that should have a special button and
keyboard sequence.  The feature could pop up a special window with the
highlighting optimized for diffing.

>it can be better than using
> multiple browser windows with own set of controls (and which is 99%
> will overlap each other).

I don't understand this complaint.  In current Squeak a code browser
is relatively quick.  When I work I'm constantly popping up new
browsers to check something, leaving them open sometimes to
"bookmark", etc.  In the Java or MS language world you couldn't do
this because those IDE's are too expensive resource-wise (but even in
those environments I find myself opening a second browser on the same
project to temporarily get functionality I have in Squeak out-of-box).

> - edit window splitting , when you need to code something, while
> referring to other methods/sources.

Another feature.  The "window tearing" shown below seemed like a cool
idea.  Especially if we could put these torn off methods onto a
"refrigerator door" morph so we can stick 'em on the door and they are
all grouped as one and can be manipulated as one unit, etc.

> All i seek, is more convenience: less clicking and fuzzy typing, more
> coding and analyzing :)

As is mine.

On Jan 31, 2008 12:30 AM, itsme213 <[hidden email]> wrote:
Btw, there is a package (or maybe one of the browsers) that lets you
switch to other methods while the current one is not "accepted", so
you can just accept them when you want to.

On Jan 31, 2008 3:58 AM, Blake <[hidden email]> wrote:
>
>         You say this almost like it's a bad thing. It's only bad when people do
> (a), and if they do (a) anyway, moving the brick wall up so that they hit
> it right at the beginning makes it more likely that they're going to think
> that it sucks, because there's not enough time for anything new to
> insinuate itself in to their thought processes.

I think doing (a) is a bad thing.  Anyone can do (a) to a new
technology (I know I have, even to Smalltalk once upon a time), and to
me that means they are not ready to look at it.  Moving the wall only
changes what they complain about.  If one is too accommodating one
ends up changing Smalltalk to be source file based instead of image
based so newbies understand what's going on better.

>         I love Smalltalk: It's informed my programming for 15 years now. But it
> does not suit the way I work at all. I write tiny little routines and
> objects in all the languages I work in (even in procedural languages) but
> I can write a lot more a lot quicker if I don't have to take my hands off
> the keyboard.

That sounds to me like an indication that the Smalltalk browser needs
some of the keyboard shortcuts your other environments have.  I
suppose you achieve some of this by simply dumping a bunch of methods
in one text area, but wouldn't it be better to attack the root of the
problem?

On Jan 31, 2008, at 3:26 , itsme213 wrote:

That is pretty much exactly what the Whisker browser does. It has  
been mentioned previously in this thread. Try it.

- Bert -

On Wed, 30 Jan 2008 22:59:54 -0800, Jason Johnson  
<[hidden email]> wrote:

> On Jan 31, 2008 3:58 AM, Blake <[hidden email]> wrote:
>>
>>         You say this almost like it's a bad thing. It's only bad when  
>> people do (a), and if they do (a) anyway,

> I think doing (a) is a bad thing.  Anyone can do (a) to a new
> technology (I know I have, even to Smalltalk once upon a time), and to

Indeed, we agree.

> me that means they are not ready to look at it.  Moving the wall only
> changes what they complain about.

Also agreed.

> If one is too accommodating one
> ends up changing Smalltalk to be source file based instead of image
> based so newbies understand what's going on better.

Squeak isn't source file based, and I doubt any form of presentation could  
make it so. (Though, I guess maybe if you had the Smalltalk OS, it would  
probably host something like a source-file based scripting system. Or  
something.<s>)

I'm talking presentation and navigation. And it's come up as I've wended  
my way through the Laser Game tutorial. It actually inspired me to try to  
come up with a modification that would make building tutorials a lot  
clearer and easier.

> That sounds to me like an indication that the Smalltalk browser needs
> some of the keyboard shortcuts your other environments have.  I
> suppose you achieve some of this by simply dumping a bunch of methods
> in one text area, but wouldn't it be better to attack the root of the
> problem?

Well, look, I'm not one to turn down hot keys. I think Bert and I must  
operate in very different ways, and it wouldn't surprise me to find that  
there are many different styles of coding. (Or maybe there are just two:  
Bert's and mine.<s>)

But the "root of the problem" is visual as well as tactile. It's all very  
well to have all the source code available all the time, but much of the  
time, I don't want to have to care. And the remainder of the time, I don't  
want to see all of it, all the time. I want to see what =I= am working on.  
More importantly, when I'm teaching, I want students to see =THEIR= code  
most of the time: I'd like to be able set it up so that the debugger  
wouldn't go in to the base classes unless asked, because that stuff can be  
very confusing to a beginner.

One of the most important lessons in programming is that, when you're  
programming and there's a bug, it's in your own code. Not in the library,  
not in the compiler, not in the operating system. (If that's not the case,  
you need a new library/compiler/OS.) I love the encouragement to explore  
in Smalltalk--I just want to be able to turn it off sometimes.

One nice thing about the debugging stack is that it allows you to flip  
through the code very quickly. There's a clarity that's not available in  
the usual object soup.

I recall a study (by IBM, I think) where the amount of code one could see  
at once was postiively related to productivity. (And yet, I'm the only  
coder I know with a propensity for conserving vertical space.) I do know  
that if I'm in method A and it calls method B, and method B is right  
there? I'm golden. As a corrolary to "the problem is in your code",  
there's also, "the problem is mostly in the code you just changed". I  
could see a browser where the methods highlighted their latest changes,  
like a mini-diff--something also good for pedagogical purposes.

None of this is actually opposed to the Smalltalk philosophy, which  
encourages the writing of small methods precisely because they're easy to  
understand. Great. Now let me see more of those little methods, without  
the real estate needed to make every browser window as effective at  
browsing the entire universe as it is browsing my code.

By the way, it was my experience with the laser game tutorial that brought  
a lot of this home (both doing it and watching others). For example, it  
doesn't leap out at you from a screenshot of a method, whether that method  
is class- or instance- side. It was always something extra to  
check--whether that "class" button was a slightly darker shade of green.

        ===Blake===

On Jan 31, 2008, at 12:27 , Blake wrote:

I'm not entirely sure how my name got dragged into this conversation  
- but I do agree with the rest of your post. Setting up a context  
that lets you focus on what you're currently working on is helpful.  
There should be a browser that just shows your "working set", like a  
couple of packages that make up your application. I used such a  
browser framework 10 years ago (Application Management Browser IIRC)  
and it worked nicely, basically each tool had a little checkbox  
switching the filter to your current app on and off. Very handy.

What I find is that experienced Smalltalkers blend out those  
distractions mentally, they only "see" the interesting parts. For  
them it's easy to spot the one interesting sender in a list of a  
hundred methods, or the stack frame in a debugger 10 places from the  
top where the error actually happened. But I also see Newbies being  
overwhelmed by the lack of separation between the system and their  
code. So improved tools are welcome :)

- Bert -

On 31/01/2008, Francisco Garau <[hidden email]> wrote:
Yes, tearing-off it's very useful for saving desktop space. It would
be good to have a 'bag' window, where i can drag and drop different
methods, so they will be kept in single window with a single
scrollbar.

I'm against 'many windows' work style. Because you spending too much
time of managing them on screen.
For example, in screenshot you taken, when i want to tear-off 3rd
method, and place it on desktop to see all 3 methods, i'll need to
spend time dragging/resizing windows.

And if you open more than 10 browser windows, they simply can't fit on
the screen,  making a mess of your desktop. In most cases, i found
that opening new browser window with interesting method/class is
faster than searching all open windows to get back to that
class/method.
It's because browser window designed as standalone unit of
information, and without any means of having navigation between them.


About browser window contents:
let's analyze for a moment, how much time we spending interacting with
different lists while working:
- package list mainly it's used when i setting up my work space. I
going to find package i'm currently working on and then clicking way
through it to find interesting piece of code/class. My POV, showing a
list of packages in each browser window is a waste of screen space. In
regular work it's used very rarely, that it's not worth of space it's
occupying.

- classes list. Again, when i focused on something, i need to refer
only to couple of classes (in most cases these classes located in
different packages/categories). So, again, it would be better in
having own, custom class list, which i can populate and browse them
when i need to, instead of having list of all classes , where i need
only couple of them from each category.

- method categories and method lists. These list are used most
frequently, and i think only these lists worth occupied space.

And finally, all these 4 lists can be merged in single tree view and
showed as separate window, so you interact with it only when you need
it, leaving the rest of screen space free to other tasks.

--
Best regards,
Igor Stasenko AKA sig.

As follow-up, how would you like an idea in having a 'working-set'
window, where i can add and manage packages/classes/methods.

So i'm setting up my work once, by placing all i need into single
list/treeview.
Then to get to what i need is just a single click away. Also, for my
task, i would need only single of such window on desktop, so i can
arrange it to be kept at left/right side of screen to be always
visible and accessible. Clicking at class/method will open new browser
window (or navigate to already opened window).
Also, with such window, i don't need to use classes/packages lists
anymore - because i'm already having all what i need before my eyes.



--
Best regards,
Igor Stasenko AKA sig.

"Blake" <[hidden email]> wrote
> "Show me everything I need and  only what I need...."

Nice.

On Thu, 31 Jan 2008 12:59:55 +0100, Bert Freudenberg <[hidden email]>
wrote:

> I'm not entirely sure how my name got dragged into this conversation  
> - but I do agree with the rest of your post. Setting up a context  
> that lets you focus on what you're currently working on is helpful.  
> There should be a browser that just shows your "working set", like a  
> couple of packages that make up your application. I used such a  
> browser framework 10 years ago (Application Management Browser IIRC)  
> and it worked nicely, basically each tool had a little checkbox  
> switching the filter to your current app on and off. Very handy.

We added something like this to our browser. At the time, we used change
sets for development, and we added a drop-down combo box above the class
categories, which allowed you to choose the "current" change set for that
browser. Any entry in the four lists that was associated with the change
set ended up being a different color, so it was easy to see what we were
working on, while at the same time showing everything else as well.

Later,
Jon

--------------------------------------------------------------
   Jon Hylands      [hidden email]      http://www.huv.com/jon

  Project: Micro Raptor (Small Biped Velociraptor Robot)
           http://www.huv.com/blog

Hi,

as mentioned before, the Whisker Browser seems to be nearly what you propose. Or a good starting point.
Have you had a look at it?

Dietmar

"Igor Stasenko" <[hidden email]> Gesendet von: [hidden email] 31.01.2008 14:05 Bitte antworten an The general-purpose Squeak developers list        <[hidden email]>

An "The general-purpose Squeak developers list" <[hidden email]> Kopie Thema Re: Editing class method sources in single place

As follow-up, how would you like an idea in having a 'working-set'
window, where i can add and manage packages/classes/methods.

So i'm setting up my work once, by placing all i need into single
list/treeview.
Then to get to what i need is just a single click away. Also, for my
task, i would need only single of such window on desktop, so i can
arrange it to be kept at left/right side of screen to be always
visible and accessible. Clicking at class/method will open new browser
window (or navigate to already opened window).
Also, with such window, i don't need to use classes/packages lists
anymore - because i'm already having all what i need before my eyes.



--
Best regards,
Igor Stasenko AKA sig.

"Sebastian Sastre" <[hidden email]> wrote
> Hi sophie, did you see Dolphin Smalltalk? It has what they call the *idea
> space* which group all the ST tools in one system window.

I have not see that, but "all the tools" is not what I mean. Rather, all the
relevant snippets/slices of the image that pertain to my task. These slices
would typically (not always) be a group of related methods, where "related"
might mean different things.

Sometimes the identification of the "related" set can be tool assisted e.g.
senders, receivers; hierarchy. Other times it might just need to be user
selected (e.g. the "tear-offs" someone else described). Would this kind of
thing be called a "Pluggable selection criteria" perhaps?

- Sophie

"Bert Freudenberg" <[hidden email]> wrote
> That is pretty much exactly what the Whisker browser does. It has  been
> mentioned previously in this thread. Try it.

I did a while ago and had trouble with it, which was one reason I said
  "... There are browser packages around for doing some of these but they
   generally seem to have fallen out of favour."
Just re-tried, still get some DNUs and somewhat strange selection-list
displays, but it might be a good starting point -- perhaps some pre-defined
"pluggable" ways to select a set of focus methods, a bit less rigid about
columns, ...

But could there be meaningful value to considering this across more than one
browser, not localized to something like Whisker? As Nathaniel Scharli &
Andrew Black wrote in "A Browser for Incremental Programming",
http://web.cecs.pdx.edu/~black/presentations/ESUGBrowserTalk.pdf and
elaborated on in their Model Extensions paper:

  "It is because even good programmers will make
   mistakes unless they have good tools"

Thanks,

Sophie

"Jon Hylands" <[hidden email]> wrote in message
> However, it turns out there's a better metaphor that people intuitively
> understand - a stack.

A Back-Button on steroids? Would be _very_ useful.

It might be good, though, to treat this as _one_ way to
  "see a set of User-Selectable methods very Conveniently"
to allow combining different orthogonal aspects:

A. different ways to see them Conveniently (and navigate between them)
  - cascading columns/rows
  - split screen/row/column
  - tear-offs
  - tabs
  - back buttons

B. different and easier User-Selectables
  - ways to limit scope: global image, my package, class hierarchy..
  - senders, implementors of a message
    - concrete methods wherever possible e.g. self, super sends
    - lists multi-options otherwise, perhaps showing method bodies
  - all messages sent to an instVar (from a class, or from a method)
  - all calls to self or super (from a class, or from a method)
  - method protocol (manual or dynamic)
  - all not-implemented-like methods
  - user hand-picked set of methods
  - all methods of class (ok, with suitable neolithic icon :-)
  (I am certain we can come up with several useful others)

C. the option to change the view in-place or spawn another window
  - in-place updates that window stack / Back button
  - spawn 1 other window for the new (multiple method) view
  - spawning <N> other windows, one for each method
      - would be the N-Browser approach

- Sophie

Hi, I'm following this thread with interest because I’m trying to  
learn about interaction design.

I want to add some comments to the discussion:
There is an assumption that the current browser is difficult or  
strange for the newbie. But that assumption is not backed by any survey.

I think that interfaces for “beginners” are good for “casual”  
applications like multimedia kiosks. But for applications that we use  
regularly,  we start as beginners and them we want to become  
“intermediate” as soon as possible. So a good interface design should  
allow the transition from beginner to intermediate quickly.

 From that point of view, the justification of editing all methods  
like in a text file, just to make the system friendly to new comers,  
is not good enough. The system is better for beginners if you can  
learn the system model quickly, a flat view of methods maybe looks  
nice but is not going to help with the fact that browsers are an  
special kind of inspectors for method dictionaries and classes.

To me the source of usability problems in browsers is that there is  
two modes of work: editing and browsing.
One problem is that when you are in “edit mode”, you can’t browse  
code: you have to save the code first, or open a new browser window.
And when you are in “browsing mode” and start to follow senders,  
implementors, references you end with a lot of browsers opened but  
just a few a relevant.

And for beginners, I think that big annoyance in Squeak are not  
multiple browsers, but hotkeys,  input focus, and undo.
For example the FillInTheBlankMorph lost the focus when you point the  
mouse pointer to another place, this is an unexpected behavior.

Diego.-

"Jason Johnson" <[hidden email]> writes:

> I don't understand this complaint.  In current Squeak a code browser
> is relatively quick.
Well searching through it to find some stuff is not that fast, I have
not idea on how to limit it to just the class I'm working in e.g.

>   When I work I'm constantly popping up new
> browsers to check something, leaving them open sometimes to
> "bookmark", etc.  In the Java or MS language world you couldn't do
> this because those IDE's are too expensive resource-wise (but even in
> those environments I find myself opening a second browser on the same
> project to temporarily get functionality I have in Squeak
 > out-of-box).
And how do you do that, you use the mouse and go forth and back and
how to you find your browsers? In any other langauge I can write


function a

...


function b

....

But I can not in Squeak I have to accept generate a new template an
possible put the stuff in categories from which I never know which
methods belong to which category (a bit too pointed) etc.

I know that people feel that Morphic is the tool chain but I'd prefer
a decent GUI builder, in which I can drag and drop my stuff. I would
appreciate something like putting my cursor on some method and type F1
and got help about that thing. Smalltalks are really nice but they are
lacking a decent editor ;-)

Regards
Friedrich





--
Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus