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.

Regards, Zulq.

Blake wrote:

On Wed, 30 Jan 2008 00:12:57 -0800, Igor Stasenko siguctua@gmail.com wrote:

...

I just got an idea, what if make option for browser to show all methods in one big listing, so developer can see, edit and do search e.t.c using single code window without switching to different methods. The idea, in general is to make browser look more convenient for newcomers because most of mainstream languages keeping per-class sources in single big source file.

Note, i'm not saying that current source browsing/editing have to be changed or it's less convenient than mode which i proposing. It just an option, mainly focused to help newcomers to get on board.

I've had the same thought. I think it would be helpful to see more of your code at one time, particularly for pedagogic purposes.

"Blake" blake@kingdomrpg.com wrote

"Show me everything I need and only what I need...."

Nice.

On Jan 30, 2008 3:09 PM, itsme213 itsme213@hotmail.com wrote:

It is very painful or impossible to get these kinds of view currently. Some STers seem very attached to current browsers.

Well I'm a relatively new Smalltalker and I'm quite attached to the way current browsers work. In fact, my day job currently has me working on C# and I really wish I had a view there that was like the Smalltalk one. All those methods on one screen is just clutter for me since I only concentrate on one method at a time in any event.

But if someone else wants to work that way then it sounds fine. I just hope people who work only from such a view take the time to learn how people write Smalltalk (i.e. small well factored methods) instead of carrying *other* practices into Smalltalk (e.g. 1000 line Java methods).

On Jan 30, 2008 10:03 PM, itsme213 itsme213@hotmail.com wrote:

Fair enough, though I did not see the link to 1000-line Java methods.

Just an observation of human nature. Someone comes into something new and assumes it's just like something else they know and can be used the same way. They hit little bumps here and there but not enough to make them stop and think. It's not until the crash into a brick wall that they stop and either (a) assume this new thing sucks, leave it and never look back or (b) realize maybe things are different here and go out and learn the new thing.

By giving "all the comforts of home" (e.g. an editor that seems to be used just like their previous language editor was) we remove one more of those "stop and think" places that would make the "b" people look around and try to see if there is a better way to do things in this new place.

However, just because Smalltalk's pure-objects-image view starts out far superior to a file-based view, does not mean there are cannot be better variations on an established pure-objects view.

I really hope there are superior ways of doing things then what we have right now. But I wouldn't begin my search from old, overly simplistic ways (e.g. code is just something vomited into a file).

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. You can do a full-text search on listing. With some shortcuts it's easy to make actions like moving caret to different method, simply by typing first letters of it's selector. What else can be done: more reacher editor functionality: - bookmarks, letting you remember and then jump to previously bookmarked method. - 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, it can be better than using multiple browser windows with own set of controls (and which is 99% will overlap each other). - edit window splitting , when you need to code something, while referring to other methods/sources. My vision is to make upper pane of browser more compact and make more space for text editing. As option, we can add a tiny button, which when clicked will collapse all lists, making more space for editing text, while list should be still available via using small combo-boxes on window top. All i seek, is more convenience: less clicking and fuzzy typing, more coding and analyzing :)

On 30-Jan-08, at 3:30 PM, itsme213 wrote:

"Igor Stasenko" siguctua@gmail.com wrote in message

...

• edit window splitting , when you need to code something, while

referring to other methods/sources.

This is one good scenario of use where todays browser is not efficient.

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?

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim All wiyht. Rho sritched mg kegtops awound?

Everything you say is true and objective, except perhaps "complication" and "poor attempt". Why doesn't everyone just mouse + keyboard + search around using separate general-purpose browser windows for all tasks? Why do people like hierarchy browsers for some purposes? Or senders and receivers? Or chasing variations of these? Or the refactoring browser?

If I consider an open browser, or collection of browsers, as a working context for the task I am focused on this moment (a reasonable approach to usability); then, if I consider

• what I want to accomplish in that task,
• what things I want to see and do,
• what other things I have to see and do (including

selection clicks, menu actions, moving between windows, number of repeated panels with similar or identical lists of categories, classes, protocols, methods, action buttons...), I see several scenarios where the general purpose tool of multiple browsers can be improved.

All from a newbies perspective ... but sometimes both newbies and ThoseInTheKnow bring useful old as well as fresh views of things.

Thanks - Sophie

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. It sound nice at first, at least to me was attractive but I quickly gravitate again on having my N system browsers and never used the idea space again.

I think that for experienced users there is information on the way they accommodate the windows in the screen area. Sometimes you make a little portion of the transcript to be seen very low under N other windows just to monitor if something has moved without loosing much really useful area. N details like that can be observed in users.

It's a little like trying to find a way to organize the way we use the objects on the desk (the phisical one). I'm more and more minimalistic on that subject.

Cheers,

Sebastian

On Jan 31, 2008 1:13 AM, tim Rowledge tim@rowledge.org 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 30-Jan-08, at 2:39 PM, Igor Stasenko wrote:

You can scroll to other method using keys, instead click-click , open new browser window and click, totally losing your focus.

Could trivially be implemented, if indeed some analogue of alt-tab type window cycling hasn't already been done. How is moving the code around in a single view any different focus-wise to looking at a different window?

You can do a full-text search on listing.

You can do that in Squeak already.

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

Within the method list that already happens, pretty much. So add a key to jump up to the method list or add access to that functionality to the texteditor morph(s)

What else can be done: more reacher editor functionality:

• bookmarks, letting you remember and then jump to previously

bookmarked method.

An open browser is a pretty good bookmark, with the added advantage that you can type remarks into the text there. For example, if I have to leave a bit of editing unfinished overniht I will often type XXXXXXX working on frobulating the libnoz XXXXXXX into the code.

• edit window splitting , when you need to code something, while

referring to other methods/sources.

Many browsers open at once solves that problem much more effectively.

Before anyone tries to tell me I should try an editor with splittable windows and bookmarks etc. I should perhaps point out that I spent nearly 20 years using one for my C coding. Within that style it is of some use but Smalltalk allows a much nicer style. I'm no more likely to accept your arguments on the matter than I would accept claims that "you people need to change the syntax to match visual basic".

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- His page was intentionally left blank.

"Francisco Garau" francisco.garau@gmail.com wrote

I hope the screenshot clarifies what I am trying to say.

Absolutely, thank you. Even better would be to have all the torn-off bits available in one "working context" (such as a window) that you can minimize, maximize, close, etc. as one unit. Traditional file-based split editor windows are not the only alternative to N open browsers.

Perhaps the new OB framework makes these more doable?

- Sophie

"Colin Putney" cputney@wiresong.ca wrote

...

Absolutely, thank you. Even better would be to have all the torn-off bits available in one "working context" (such as a window) that you can minimize, maximize, close, etc. as one unit. Traditional file-based split editor windows are not the only alternative to N open browsers.

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

Not quite, just an actual grouped "working context" I can manipulate (e.g. a window) that treats as a group all the snippets/slices I want present for my current task.

Perhaps drag and drop across browsers might be one way to do this, if the "group" is realized by multiple top-level browser windows (non-ideal imho). Better if smaller browser windows (such as the "tear-offs" or split panels/columns/rows) are contained within a "working context" window.

- Sophie

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

"Francisco Garau" francisco.garau@gmail.com wrote

...

I hope the screenshot clarifies what I am trying to say.

Absolutely, thank you. Even better would be to have all the torn- off bits available in one "working context" (such as a window) that you can minimize, maximize, close, etc. as one unit. Traditional file-based split editor windows are not the only alternative to N open browsers.

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

- Bert -

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

Sophie,

It would be nice to have a new browser (or bookmarker actually) where you can drop methods from several classes. I envision the UI as a combination of Paul Fernhout's PlantStudio and Strongtalk (or self).

The text only UI would look like like this: + Date class >> today + Point >>min: aMin max: aMax + Collection >> add: newObject

And when expanded the second item: + Date class >> today - Point >>min: aMin max: aMax ^ (self min: aMin) max: aMax

+ Collection >> add: newObject See the screenshoots to have an idea how the GUI might look like.

Cheers, Francisco

----- Original Message ----- From: "itsme213" itsme213@hotmail.com To: squeak-dev@lists.squeakfoundation.org Sent: Thursday, January 31, 2008 2:26 AM Subject: Re: Editing class method sources in single place

"Francisco Garau" francisco.garau@gmail.com wrote

...

I hope the screenshot clarifies what I am trying to say.

Absolutely, thank you. Even better would be to have all the torn-off bits available in one "working context" (such as a window) that you can minimize, maximize, close, etc. as one unit. Traditional file-based split editor windows are not the only alternative to N open browsers.

Perhaps the new OB framework makes these more doable?

• Sophie

Francisco-

I like the idea of keeping only the methods of interest around somewhere, like you outline or as someone else mentioned with MorphicWrapers as even as separate windows. I was surprised at first to see a PlantStudio reference in this context, but after seeing the screenshot it made sense. Here are some comments on the origins of those ideas, as well as a simple suggestion in the last paragraph, involving just keeping the recently viewed method history in a side panel of a regular browser, like Firefox can.

=== History

The PlantStudio browser, and also the Garden Simulator browser which preceded it, screenshot here: http://www.gardenwithinsight.com/sc_brows.htm were inspired from Smalltalk, but also from VisualBasic and Delphi property tools for editing form widgets.

Lazarus is a free Delphi-like system, a couple "Object Inspector" window screenshots from it: http://www.lazarus.freepascal.org/modules.php?op=modload&name=Screenshot... http://www.lazarus.freepascal.org/modules.php?op=modload&name=Screenshot... These show that idea of having the value on the same line as the name (and you can change the value on that line), but also being able to expand the item if it has internal complexity (see the FONT line on the first link) so you can change the parts separately. In PlantStudio, S-curves were something that needed to be changed that way as the curves were defined by more than one numerical value.

PataPata is another variant (post-PlantStudio), except with the expansion in a lower pane, more like a Smalltalk browser. This is a little bit like what Igor suggested (but not separate windows, which might be nicer). Here is a screenshot (see the most front window): http://sourceforge.net/project/screenshots.php?group_id=165910 In the end, I didn't like it much, for a few reasons. (*)

In the Garden Simulator (released around 1997) we organized what we called "aspects" (variables or derived or simulated current values) related to simulation objects into Smalltalk-like protocols we called "groups". One difference was that you could have an aspect in more than one group. We removed that flexibility to make your own groups in PlantStudio (thinking less is more? :-) I would put that flexibility back in a more generic way if I did it again (I would like users to be able to create their own models and declare their own groups).

There was another idea in the Garden Simulator browser: http://www.gardenwithinsight.com/sc_brows.htm "The browser is a tool for examining the simulation in detail. The browser has two sides. The numbers side shows you the numbers in the simulation very simply as numbers with units on a sliding gauge. The pictures side shows the same information, but arranged in ways that are more visual and easier to understand. For the weather, you can see running graphs of temperature, humidity, precipitation, radiation, day length, and wind speed. For the soil, you can see a soil profile with soil color, temperature, pH, nitrogen, phosphorus, soil materials, or plant roots. For a plant, you can see a close-up look at the plant, a breakdown of plant biomass in various plant parts (such as leaves and fruits), or the stresses on the plant's growth. Groups help to manage the complexity of the over 800 aspects in the simulation. You can create your own groups. You can also use the browser to harvest fruits from a plant, create your own plant cultivars (varieties), soil types, and climates, and change many of simulation values. "

What is most important there is that the browser could actually mix presentations of the same data. So, in a Smalltalk context, imagine a browser with a left hand side which is the bookmarked methods you indicate, and perhaps a right hand side which might be, say, a graphical network visualization of the way the methods call each other. That browser was inspired by the left brain (logical) / right brain (visual) duality idea some have proposed.

== Generalizing

So to generalize that with the bookmark idea, what you kind of want is some way to collect all the views on a specific task you are working on into a coherent whole, especially one you can dismiss or hide with one click. I have so often opened two dozen windows trying to debug something, or trying to make some change to the code, and then had to find each window, remember why I opened it, and close it, while still leaving some windows open. I'm not sure how to do that in a generic way, especially because tasks seem to shade into each other -- you solve one issue but a related one comes up.

Perhaps an OLPC/Sugar-like history list of *when* you opened windows in time-order might be most useful? Or it could track when you last looked at the window or changed something relevant to it? It's almost a workflow-like problem. Definitely a possible area of exploration.

Maybe it would be useful to have one method per window but just have a better way to organize and reorganize windows (or window icons) in Squeak. Perhaps that generic system might know something about when the window was opened or what else was going on in the system or how the windows were related (which browser window spawned from another).

But perhaps simplicity is a good philosophy here -- and one window with a bunch of related bookmarked methods of interest might be good. But you still end up needing to spend time managing what you put in and take out of your bookmarks, and if they keep growing you end up with clutter again.

Other simple things might be holding or coloring or graying methods in a browser based on how recently you looked at them. That way you could find them again more easily at a glance. I think someone did this? Maybe part of Spoon for methods which were actually used as code coverage?

Generalizing, this is all about restricting views of the system to what is interesting or useful to you at the moment. That can be done by your own choice (bookmarks), or it can even be done by others in an educational or corporate setting, restricting programmers to what they are allowed (by someone else's bookmarking choices) to view or change (assuming a security model, which Smalltalk does not have, and maybe shouldn't). Completely generalizing this would entail making "bookmarks" somehow a first class object in the system's design, perhaps called "shadow modules"? :-)

== Simplest suggestions

In practice, what I often want is to view only a *few* classes of interest, and then perhaps simplify the methods of interest for those classes; so, sort of like a regular browser, but with just some classes and then for these classes, just some methods. It might be nice to drag and drop to this browser from regular browser. One might also have prepared class/method sets for newbies to use (hiding much of the system complexity); LearningWorks had some ideas along this line of hiding complexity in the debugger (not showing new programmers some intermediate methods).

Or even easier, what I think I would like is another panel on a regular browser which keeps a method viewed history in chronological order, so as I look at methods they show up in the list (Class and name) and I can just click in that list to make the browser go back and forth to that method (including being able to open a new browser on the method with a double click?). But I wonder if I have seen that somewhere too? Or maybe I have just wanted it for so long? :-) The FireFox web browser can have a side bar which can do that. Maybe that is what I am thinking of?

--Paul Fernhout (*) While I thought it was a good idea at the time to try, PataPata's hierarchical browser (which was *not* fully Self-like, Self-s was much better) became very confusing lumping everything into a big hierarchical inspector (although you could have more than one). Using it entailed lots of scrolling where you could easily lose your place in lots of clutter. That clutter came in part from mixing variables and methods, but also from mixing classes and instances (since it was a Prototype-based system and there was no clear difference). I also learned I did not like Self's choice (which I had followed) of merging separate method and variable namespaces (of Smalltalk) into one common one where any variable could be method. If you separate classes and instances there would not be so much clutter. I tried a wonderful browser for an prototype-ish extension to TCL that did a good job of supporting mixing prototypes/singeltons and classes using a browser desing which looked more Smalltalk-ish: "XotclIDE" http://wiki.tcl.tk/2131 "Integrated interactive development environment for the XOTcl extension (but supports also regular Tcl programs). Provides a Smalltalk like graphical programming environment (ENVY, Squeak, Visual Works) with graphical introspection and editing of a running system. It supports also normal Tcl procs and packages. State can be saved in the form of Tcl packages. Can optionally use a sql-based version control system ..." "XOTclIDE. Integrated Development Environment for XOTcl and Tcl" http://www.xdobry.de/xotclIDE/

Francisco Garau wrote:

It would be nice to have a new browser (or bookmarker actually) where you can drop methods from several classes. I envision the UI as a combination of Paul Fernhout's PlantStudio and Strongtalk (or self).

The text only UI would look like like this: + Date class >> today + Point

...

...

min: aMin max: aMax + Collection >> add: newObject

And when expanded the second item: + Date class >> today - Point >>min: aMin max: aMax ^ (self min: aMin) max: aMax

• Collection >> add: newObject See the screenshoots to have an idea how

the GUI might look like.

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.

On Wed, 30 Jan 2008 16:22:30 -0800, tim Rowledge tim@rowledge.org wrote:

Many browsers open at once solves that problem much more effectively.

I find that I: a) run out of screen space quickly; b) need to revert to the mouse to switch browsers; c) if I try solve (a) by collapsing, I end up with even more mouse clicks at (b). Maybe there's a hot-key for switching conveniently that I'm missing, but in my experience ST is pretty keyboard hostile.

Something like what John Hyland describes--stack based, so that the window shows the latest methods you've been working on--seems like it would be very useful, and having a single screen of code (that could actually be debugged, so you could look at how the code moves without the visually distracting flipping that occurs) would be very useful for teaching.

Conceptually, this wouldn't even need to be that different from the regular browser, really, just a browser that showed code from more than one method at once.

Jason Johnson wrote:

"Just an observation of human nature. Someone comes into something new and assumes it's just like something else they know and can be used the same way. They hit little bumps here and there but not enough to make them stop and think. It's not until the crash into a brick wall that they stop and either (a) assume this new thing sucks, leave it and never look back or (b) realize maybe things are different here and go out and learn the new thing."

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

===Blake===

On Wed, 30 Jan 2008 22:59:54 -0800, Jason Johnson jason.johnson.081@gmail.com wrote:

On Jan 31, 2008 3:58 AM, Blake blake@kingdomrpg.com 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 Thu, 31 Jan 2008 12:59:55 +0100, Bert Freudenberg bert@freudenbergs.de 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 Jon@huv.com http://www.huv.com/jon

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

On Jan 31, 2008 6:59 AM, Bert Freudenberg bert@freudenbergs.de wrote:

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

...

On Wed, 30 Jan 2008 22:59:54 -0800, Jason Johnson <jason.johnson. 081@gmail.com> wrote:

...

On Jan 31, 2008 3:58 AM, Blake blake@kingdomrpg.com 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>)

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 :)

SmalltalkAgents made an interesting and promising stab at a more flexible toolset nearly two decades ago which worked well in many respects. However, I think it helps to broaden the discussion and consider the impact of screen real estate and human cognition in the context of Croquet.http://croquet.funkencode.com/2008/01/31/story-oriented-coding/

On Thu, 31 Jan 2008 13:41:49 -0800, Brian Brown rbb@techgame.net wrote:

A lot of this conversation smacks of Ned Konz's Starbrowser - it's on squeakmap, but I don't think it will run on newer stuff than 3.7 without some love.

The layout's pretty nice. Do those arrows mean you can traverse code like a stack?

"Brian Brown" rbb@techgame.net wrote

A lot of this conversation smacks of Ned Konz's Starbrowser - it's on squeakmap, but I don't think it will run on newer stuff than 3.7 without some love.

Yes!!

Some more screenshots of its VW predecessor at http://homepages.ulb.ac.be/~rowuyts/StarBrowser/screenshots.html and its design at http://homepages.ulb.ac.be/~rowuyts/StarBrowser/index.html

It seems to establish working contexts nicely, with a lot of extensibility on what services to use on a selected element (including groups or classifications) in that context.

It does not include any example of viewing a group of methods simultaneously, but the UML diagram certainly simultaneously shows all classes in the Soul* classification, so it would probably fit into the framework.

- Sophie

On Thu, 31 Jan 2008 09:43:24 -0800, Jason Johnson jason.johnson.081@gmail.com wrote:

I was just pointing out the kind of requests that happen from people coming from other languages and not "integrating". I remember recently seeing someone request that Smalltalk drop the "image idea" and switch to source files so it would be more "friendly to newbies".

Well, yes, that's called "Ruby". ;-)

...

I recall a study (by IBM, I think) where the amount of code one could see at once was postiively related to productivity.

I don't understand this. Are you saying that having more source code on the screen increased productivity?

Yes. The tracks faster than the fingers, basically. I've been known to use miniscule fonts at 1600x1200 for precisely that reason. (There are limits, unfortunately.)

That may be but if so a simple "show me all the methods in the class" isn't going to work.

That was never my suggestion. In fact, the set of code items in question is going to be split among classes, and isn't necessarily going to embrace entire classes. I suspect variants in here--some folks are going to favor a LIFO type stack, while others might prefer an alphabetic arrangement.

So that view is good for figuring out where functionality is in a new class. But when I want to work on the functionality of one specific button the view is all wrong. I want to see the above mentioned items that are related to this specific button and nothing else. What I do right now is click the minus on the unrelated methods to shorten them down to one line, but it's still clutter I have to wade through.

That's where Smalltalk, being a non-source-file-based system can shine. Since order is not significant (and it IS in C# and other projects), you can arbitrarily designate what is shown and in what order, without the clunkiness of hiding chunks of code (which is how the modern IDEs handle clutter).

...

(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 wonder about doing a tooltip style pop up on mouse over of the B method call. :)

Would require going to the mouse and waiting for the tooltip to pop-up. We're talking fractions of a second here. Another study I recall reading was the effect of lag on programmer producivity. A half-second was all it took to break concentration. At 2 seconds, the programmer has left the building.<s>

...

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.

Interesting ideas.

Now...off to implementation.... Heh.

===Blake===

On Jan 31, 2008 10:51 PM, Blake blake@kingdomrpg.com wrote:

That was never my suggestion. In fact, the set of code items in question is going to be split among classes, and isn't necessarily going to embrace entire classes. I suspect variants in here--some folks are going to favor a LIFO type stack, while others might prefer an alphabetic arrangement.

In that case, it sounds like we're on the same page. I'm all for improvement. I just hate oversimplified solutions that may actually make things worse (which doesn't sound like what you're suggesting).

That's where Smalltalk, being a non-source-file-based system can shine.

Agreed.

Would require going to the mouse and waiting for the tooltip to pop-up. We're talking fractions of a second here. Another study I recall reading was the effect of lag on programmer producivity. A half-second was all it took to break concentration. At 2 seconds, the programmer has left the building.<s>

Fair point. What about having a sort of "context view" off to the side that shows all the methods referenced in by the current method? You could even have a setting to say how far out to fan (i.e. 2 levels shows all methods used in the current method, and all their methods). Of course we would first need a way to filter what would show up in such a context window, so we don't get flooded by non-project code.

Now...off to implementation.... Heh.

Are you really implementing? I suppose you could use some of that nice free labor (students) to get something developed. :)

Hello Blake,

B> That was never my suggestion. In fact, the set of code items in question B> is going to be split among classes, and isn't necessarily going to embrace B> entire classes. I suspect variants in here--some folks are going to favor B> a LIFO type stack, while others might prefer an alphabetic arrangement.

a variant of this is done in the TracingMessagesBrowser by Chris Muller which is a Senders Implementors Browser giving a hierarchical view of an algorithm across several classes.

Helps me a lot to understand or change code I didn't touch for some time.

Cheers,

Herbert mailto:herbertkoenig@gmx.net

Hello Blake,

B> Sounds interesting. I can't even get it to load, tho'. right now I dropped (in this sequence) Ma exception handling-cmm.12.mcz Ma base additions-cmm.34.mcz Tracing Messages Browser-cmm.19.mcz into a fres 3.9 image and it worked.

There may be newer versions. Drop me a mail, if you need the files.

Cheers

Herbert mailto:herbertkoenig@gmx.net

"Jon Hylands" jon@huv.com 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

"Jason Johnson" jason.johnson.081@gmail.com 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

tim Rowledge tim@rowledge.org writes:

This turns out to be incorrect. Have another browser open. Leave the one with partially written code and go to this other browser.

That's exactly not what I want. I do not want to have a tons of browser open just to realize that I do not know which one to choose next.

Investigate other methods or even start writing your 'function b'. Open yet another browser and do it all again. If categories bother you just leave everything in a single category. You'll soon learn how helpful they can be once you have a couple of dozen methods in your class.

Well if it's clear in which category to put the stuff then I agree, but that's not that clear ot me always and then I'm searching for a method from which I "expect" it to be foo but unfotunatly it's in bar....

I don't want to change your way of doing things. But I'm not willing to just adopt to this way. I conceil I'm corrupted by (X)Emacs (it's among other a decent editor) Smalltalks Editors could gain much by just beeing a bit more Emacsish ....

Regards Friedrich

On Thu, 31 Jan 2008 14:25:47 -0800, tim Rowledge tim@rowledge.org wrote:

On 31-Jan-08, at 10:00 AM, Friedrich Dominicus wrote:

...

Smalltalks Editors could gain much by just beeing a bit more Emacsish ....

NNnnnnooooooooooooooooooooooooooooooooo <runs away, very fast>

Oh, a vi fan, eh?

On Thu, 31 Jan 2008 16:19:51 -0800, tim Rowledge tim@rowledge.org wrote:

...

...

NNnnnnooooooooooooooooooooooooooooooooo <runs away, very fast>

Oh, a vi fan, eh?

Aaaaaarrrrrgggghhhh!

No. No way. No how.

Hee hee. We used to use SPF....

tim Rowledge wrote:

On 31-Jan-08, at 4:14 PM, Blake wrote:

...

On Thu, 31 Jan 2008 14:25:47 -0800, tim Rowledge tim@rowledge.org wrote:

...

On 31-Jan-08, at 10:00 AM, Friedrich Dominicus wrote:

...

Smalltalks Editors could gain much by just beeing a bit more Emacsish ....

NNnnnnooooooooooooooooooooooooooooooooo <runs away, very fast>

Oh, a vi fan, eh?

Aaaaaarrrrrgggghhhh!

No. No way. No how. I like my ParagraphEditor thank you very much. If I *have* to use a not-Smalltalk text editor then I prefer StrongEd (google it) and I can tolerate TextWrangler - just barely.

StrongEd? What's wrong with Zap eh?

2008/2/2, Igor Stasenko siguctua@gmail.com:

One more idea: How about adding a single input field for 'address', where i can type Class>>selector and make browser open it. and make it with hinting while i typing (when i type first letter of selector, it shows a popup list with number of choices). Also, it can react on typing just selector (it's easy to determine, because all classes are starting from capital letter)

I think the search browser is a start for that. It certainly need to be improved but there is an adress field in the OBBrowser's where you can browse/find different stuff. It's based on the Mercury finder Avi quickly made. I use it a lot to find classes... WA*Conf*ation stuff like that. It gets more complicated and less useful for selectors (#aSelector) as there is no wildcard possible for now...

On Thu, 31 Jan 2008 17:18:10 -0800, Sebastian Sastre ssastre@seaswork.com wrote:

...

On 31-Jan-08, at 10:00 AM, Friedrich Dominicus wrote:

...

Smalltalks Editors could gain much by just beeing a bit more Emacsish ....

NNnnnnooooooooooooooooooooooooooooooooo <runs away, very fast>

tim

+1 here.

Why anyone would wish to go backwards todays when user experience is starting to gett the place it allways deserved?

Fredrich may not have been joking but I most certainly was.

"tim Rowledge" tim@rowledge.org wrote

...

Smalltalks Editors could gain much by just beeing a bit more Emacsish ....

NNnnnnooooooooooooooooooooooooooooooooo <runs away, very fast>

Most "emacs|vi|...ish" requests are really about:

"I would like to - move around my code structures - package, class, method, sub-expressions, hierarchy, senders.. - finding or selecting elements, grouping elements, etc. - operating on my found, grouped, or selected elements - with keyboard fluidity and minimal distraction - (preferably) using familiar keyboard shortcuts".

Few want literally single text-file editing of a class (or package, or image :-)

My customary 2 c :) Sophie

On Feb 2, 2008 5:21 AM, itsme213 itsme213@hotmail.com wrote:

"tim Rowledge" tim@rowledge.org wrote

...

...

Smalltalks Editors could gain much by just beeing a bit more Emacsish ....

NNnnnnooooooooooooooooooooooooooooooooo <runs away, very fast>

Most "emacs|vi|...ish" requests are really about:

"I would like to

• move around my code structures
• package, class, method, sub-expressions, hierarchy, senders..
• finding or selecting elements, grouping elements, etc.
• operating on my found, grouped, or selected elements
• with keyboard fluidity and minimal distraction
• (preferably) using familiar keyboard shortcuts".

- without needing to reach for your mouse all the time!

Gulik.

On 1-Feb-08, at 12:33 AM, Ben Goetter wrote:

But I dearly miss Emacs when working inside Squeak.

I'd have to say that I think you're completely missing out on a lot of the Smalltalk Way in that case. I used emacs for *years*. I hated modal editing (and as for vi... blech. overwrite mode? insert mode? append mode? destroy-your-file-by-mistake mode?) and the totally overbearing do-everything with only fifteen convenient keypresses approach. I mean who *really* needs access to ctl-alt-opt-shift-meta2- RMS to get an ascii portrait of Stallman in his speedos?

When your text is in small chunks - and if you're writing large chunks of code you're Doing It Wrong - you just don't need regular expression handling that can find all files in a complex set of directories based on your .emacsdirpathopt file(s) and then convert all complexly specified search targets into complexly specified contingent results and then rewrite each file; with another option to specify what to do if the file is not writeable, of course.

Having said that, if you really insist on living within some demented editor-as-OS world then you are quite at liberty to code up FFI calls to provide access to method code to whatever editor you like and to make use of OS facilities to have the editor save-file actions result in the chunk of code being returned to the compiler for accepting. I suspect that in the milieu of COM/OpenDoc type systems it could be done quite well. I imagine it would be possible to hook up to XCode, for example. But I'm afraid I won't be helping to implement it.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim A bug in the code is worth two in the documentation.

On Thu, 31 Jan 2008 09:49:25 -0800, Jason Johnson jason.johnson.081@gmail.com wrote:

What I mean was, "compared to IDE's of other languages". That is, I can open 10 browsers on one project I'm working on and it's no problem. 10 Eclipse, IntelliJ, Visual Studio or what ever is unthinkable.

The comparison is not entirely apt. Each Eclipse, IntelliJ, Visual Studio is a complete environment. It would be like opening an entirely new Image+VM, which you don't do in Smalltalk either. It's actually more do-able (and I've done it occasionally) in these other tools because of the source-file-based set-up.

The equivalent of the browser in these environments is the editing window (with associated browsing tools). And, of course, one has many of those open at once--though not as many as browsers in Smalltalk since one window is good for an entire class, at least. ;-)

===Blake===

Francisco Garau wrote:

...

I just got an idea, what if make option for browser to show all methods in one big listing, so developer can see, edit and do search e.t.c using single code window without switching to different methods. The idea, in general is to make browser look more convenient for newcomers because most of mainstream languages keeping per-class sources in single big source file.

If you want to do that, I think GNU Smalltalk syntax is more "newcomer friendly". Here is a simple example in case you haven't seen it.

Magnitude subclass: Date [ | days day month year |

Date class >> today [ <category: 'instance creation (Blue Book)'> ^self fromSeconds: Time secondClock ]

subtractDays: dayCount [ <category: 'basic'> ^Date fromDays: self days - dayCount ] ]

Thanks Paolo! you've got rid of the exclamation marks in a beatiful way.

Heh. This looks just like my SqueakScript hacks from 2001 ;-)

Cheers, - Andreas