Tuning the Newspeak browser; fast classical browser

[Shaping]

Hi Folks.

I do not see any GUI-related options under the Settings icon, for adjusting font size and style.  Is there a way to do this?  I searched the newspeak-101.pdf, too, and did not find any reference to fonts there, either.

Also, is there a method styler and formatter?

How can I change all mouse-click actions to be leading-edge, as in VW?  The trailing-edge responses mess with my mind.  

I don't, at least for now, want the Newspeak browser GUI jumping about, as I click through classes.  Is there a way to use a native (fast) classical Smalltalk browser, instead of the current Newspeak-style browser in which Windows open and close and, in so doing, push a lot of other screen real-estate around, causing distractions for the eye?  I want less of the screen changing as I browse, as with the classical browser.  Does anyone feel this way?  I find the NS GUI dynamics to be too kinetic and too distracting--they actually disrupt my thinking, and this is keeping me form delving deeper.  And I want to delve deeper.

Eliot, the Cog and Spur developments look exciting.  I'm looking forward to the speed-up.

Is there a plan to get off the Squeak image completely?

[Gilad Bracha]

Hi,

On Wed, Apr 1, 2015 at 5:54 AM Shaping <sha...@uurda.org> wrote:

Hi Folks.

I do not see any GUI-related options under the Settings icon, for adjusting font size and style.  Is there a way to do this?

Not without programming. There is a small/regular fonts option under File/Preferences but it appears to be broken. Not sure it ever worked for Newspeak browsers anyway. 

 I searched the newspeak-101.pdf, too, and did not find any reference to fonts there, either.

Also, is there a method styler and formatter?

No. I've wanted to have one for a long time. 

 

How can I change all mouse-click actions to be leading-edge, as in VW?  The trailing-edge responses mess with my mind.  

I don't, at least for now, want the Newspeak browser GUI jumping about, as I click through classes.  

 I don't understand what you mean here. Unless you press shift, no new windows open. The content of the window changes, but 90% of a Squeak browser window content changes when you switch classes too.

Is there a way to use a native

What do you mean by native?  Or fats for that matter.

(fast) classical Smalltalk browser, instead of the current Newspeak-style browser in which Windows open and close and, in so doing, push a lot of other screen real-estate around, causing distractions for the eye?

 It used to be possible, but worked very poorly as you lose the connection to nested and enclosing classes. In fact, we started that way and developed the Newspeak browsers to address that.  Nowadays, Newspeak classes don't live in the Squeak namespace and you can't do it at all. 

 

 I want less of the screen changing as I browse, as with the classical browser.  Does anyone feel this way?  I find the NS GUI dynamics to be too kinetic and too distracting--they actually disrupt my thinking, and this is keeping me form delving deeper.  And I want to delve deeper.

Eliot, the Cog and Spur developments look exciting.  I'm looking forward to the speed-up.

Is there a plan to get off the Squeak image completely?

There has always been such a plan. To an extent, the web version is one, partial, implementation of that. You can run a subset of the IDE in the browser. It would take a few months of effort to make that reasonably complete. 

To run properly on nsvm without Squeak requires a bunch of work too. For example, the native GUI only works on Windows. We'd need a mac UI so we could abandon Morphic. There are quite a few other Squeak dependencies.  

Bottom line - there are many areas where the system can be improved. To improve them, we need more volunteers. 

[Shaping]

I don't, at least for now, want the Newspeak browser GUI jumping about, as I click through classes.  

 I don't understand what you mean here. Unless you press shift, no new windows open. The content of the window changes, but 90% of a Squeak browser window content changes when you switch classes too.

By default new subwindows for new methods open when you click on method names.  Peripheral field action is very bad when programming.  I don't ever want to see any such motion. 

Is there a way to use a native

What do you mean by native?  Or fats for that matter.

Native, overlapped, fast Windows window, like the one you use for Newspeak.  You seem to be drawing in the client area of a native window.

(fast) classical Smalltalk browser, instead of the current Newspeak-style browser in which Windows open and close and, in so doing, push a lot of other screen real-estate around, causing distractions for the eye?

 It used to be possible, but worked very poorly as you lose the connection to nested and enclosing classes. In fact, we started that way and developed the Newspeak browsers to address that.  Nowadays, Newspeak classes don't live in the Squeak namespace and you can't do it at all. 

I need it. 

Is there a plan to get off the Squeak image completely?

There has always been such a plan. To an extent, the web version is one, partial, implementation of that. You can run a subset of the IDE in the browser. It would take a few months of effort to make that reasonably complete. 

To run properly on nsvm without Squeak requires a bunch of work too. For example, the native GUI only works on Windows. We'd need a mac UI so we could abandon Morphic. There are quite a few other Squeak dependencies.  

Bottom line - there are many areas where the system can be improved. To improve them, we need more volunteers. 

I would volunteer if I could read the methods without the peripheral field flux. 

[Shaping]

Is there a way to use a native

What do you mean by native?  Or fats for that matter.

fast == the response times I see in the current Newspeak browser but with leading-edge mouse clicks.   

Not fast == the Squeak GUIs launched from the VM window.  Not enough snap for me.

(fast) classical Smalltalk browser, instead of the current Newspeak-style browser in which Windows open and close and, in so doing, push a lot of other screen real-estate around, causing distractions for the eye?

 It used to be possible, but worked very poorly as you lose the connection to nested and enclosing classes. In fact, we started that way and developed the Newspeak browsers to address that.  Nowadays, Newspeak classes don't live in the Squeak namespace and you can't do it at all. 

Is Newspeak's ability to nest classes the only feature of the language that makes the classical browser unworkable?  If so, there has got to be better way.  These in-lined dynamic windows containing the text of selected methods are super-annoying to me.  They seemed very cool at first, but don't let me stay focused on my programming thoughts.  I would do almost anything necessary to get a classical browser working.  I don't see why a path to nested classes can't be shown near the top of the GUI; otherwise just plug the current namespace, class, and method into the one and only classical-browser GUI, as usual.  I only want to look at GUI parts that matter, and always want them to be located where they were last.  This reading strategy is practiced by most who use a classical browser. Everyone is familiar with the pattern, and it creates a lot of reading efficiency, much of which is lost with the new scheme.

[Gilad Bracha]

Ok, so I gather:

1)  You are using Newspeak on Windows.

2) By window, you mean a pane or view. That is what confused me.

3) What bothers you is that when a pane expands in place, it necessarily forces re-layout of its surroundings.

4) You suggest using traditional style class browser for Newspeak, but running in native Win32 UI, to solve (3).

You are the first person to complain about (3), but you are probably not the only one that is acutely sensitive to this. What can we do to help? 

Some not great, but at least constructive ideas:

(1) Open all the nested methods the first time you look at a class. You can do this by clicking the open circle in the Methods section (or class section for that matter). This makes things a lot more like reading a file where you have to scroll through the contents. This would seem to mitigate the issue.

(2) Save code to a file and read it in a text editor. Unlike Smalltalk, you can do this with Newspeak.

That might help a bit. Maybe it would be enough that you could make fixes, or write an alternate browser if you so chose.

[Gilad Bracha]

The nesting is one major reason why the Squeak browser was unworkable, and maybe you can mitigate that while keeping the basic design.  There are other reasons why we don't care for the classic browser:

(1) It is modal which is a big problem in UI. 

(2) It has no notion of history. 

(3) It doesn't allow me to view multiple methods at once.

All of these contributed to our decision to make a new browser.

You can retrofit back and forwards buttons and maybe make it non-modal by retaining the state of things in the history. In short, you might be able to create a class view that fit into the Hopscotch framework  and retain some of the advantages. The last point (3 above) is an inherent weakness in the design of the classic browser. But for you it sounds like the tradeoff is worthwhile. So if you can work with the system as I suggested in my prior mail, and can invest the effort, you can probably create a browser that is to your liking yet better than the classic one.

For us, (3) was longstanding problem. In fact, back in Strongtalk we built such browsers (inspired by Self) without dealing with (1) and (2), and without having to worry about a language with nesting. So, we like it better. 

[Shaping]

1)  You are using Newspeak on Windows.

Yes.

 

2) By window, you mean a pane or view. That is what confused me.

Window here is a top-level window--called an "overlapped" window in the Windows GDI window-style parlance.  The speed there is good, being about opening, resizing, and closing.  I don't know how you render in the client area of the top-level window, but it seem to be fast enough.

3) What bothers you is that when a pane expands in place, it necessarily forces re-layout of its surroundings.

Yes, and all this happens below the point in the browser where you are clicking, pushing whatever is currently down there to a new position.  It's just a lot of linguistically irrelevant flutter activating basic fight-or-flight peripheral-vision triggers, which is not what I want in my dev environ.  I think we all want less GUI action and more information with which to reason, per unit time, per unit area scanned.  The classical browser still seems superior in this way, but I don't have a solution for the nesting of classes, except to create a path of names of namespaces and classes (which I assume work like namespaces as containers for other classes) separated by spaces, maybe in the title bar, or maybe in a narrow tree off to the left.

4) You suggest using traditional style class browser for Newspeak, but running in native Win32 UI, to solve (3).

Yes, with some kind of abbreviated navigation for all the nesting, which I have not used/experienced yet, but I'm sure it has some value if you guys are still holding onto it.  I generally like scoping to be as local as I can make it; so the nesting seems like a good idea on the surface.  I don't foresee not wanting it.  So I need to figure out a better way to navigate it.

You are the first person to complain about (3), but you are probably not the only one that is acutely sensitive to this. What can we do to help? 

See my suggestion in (3), another way to provide hierarchic awareness whilst editing nested classes in the same set of panes, old-style. 

Some not great, but at least constructive ideas:

(1) Open all the nested methods

Are methods also nestable?  I'm wondering how that works.  I might not be understanding the big scheme.  I thought only classes and namespaces were nestable.  That's a big enough reason to try the classical browser again, but can you explain nested methods?  Perhaps you are talking about only the order in which the methods are encounter and displayed?

 

the first time you look at a class. You can do this by clicking the open circle in the Methods section (or class section for that matter). This makes things a lot more like reading a file where you have to scroll

I don't want to scroll.  Who does?  That's why I love the Smalltalk browser.  You mostly stay put and occasionally search for a new class that is not in view or not in some MRU cache (which is nice feature in NS). 

through the contents. This would seem to mitigate the issue.

(2) Save code to a file and read it in a text editor. Unlike Smalltalk, you can do this with Newspeak.

Yes, I like that.  I've always thought that, even if you have your favorite browser thing for efficiently viewing code, you ought to be able to just go read a long equivalent file that you know will compile to produce the needed behavior.  But I don't want to give up the ease of getting quickly around to a lot of classes and methods.  I prefer to make a classical browser.

That might help a bit. Maybe it would be enough that you could make fixes, or write an alternate browser if you so chose.

Can someone help me with some snippets for changing font size and style?  At least one of you must know how to do this in 15 minutes or less.  Maybe publish a workspace of the snippets that do this, so that we have a working starting point for developing a proper Setting menu with the same?

How are you rendering in the client area of the Windows window?  I should back up to my application level to help you understand what matters to me.  I'm trying to get a mature OpenGL 4.x framework working in VW, but am considering something that is possibly better:  a hybrid approach of using WebGL in web view wrapped in a native window, which is the trend nowadays for developing mobile apps.  We might as well point things in that direction and be able to convert from a local client app to a mobile one easily.  How are you rendering text and subwindows in the client area?  Is this JS and HTML?

[Shaping]

The nesting is one major reason why the Squeak browser was unworkable, and maybe you can mitigate that while keeping the basic design.  There are other reasons why we don't care for the classic browser:

(1) It is modal which is a big problem in UI. 

Can you break that down some for me?

 

(2) It has no notion of history. 

Right, and we need to fix that.  I really like the NS MRU cache.  

 

(3) It doesn't allow me to view multiple methods at once.

I understand the perceived need to do this, but I'm not sure the separate subpanes have as much value as two windows on top of each other, each with a different method, each accessible by Alt-tab, which is quicker and less disruptive for my mind that moving my eyes across a page.  Really.  I know it sounds odd at first, but keeping the stuff that matters (the two methods you are comparing) in the fovea is very powerful.   So work the speed-reading programs that show you one word at a time in the same place in rapid succession.  Lower distraction.  Lower eye fatigue.  Two separate panes for two methods works okay if the panes are juxtaposed and the methods are small.  This limits eye-span.  Still I'd rather Alt-tab.

That kind of gives me an idea.  Use an Alt-tab kind of mechanism but with a less OS-specific key combo or maybe by clicking a button to rotate through a stack methods shown in one pane in one place.  If the list gets long, use random access instead of rotation.  I can almost always recognized a method by its size, color and left-edge indent-pattern, because I indent strictly to the nearest space.  So why not use tiny thumbnail images of methods in a side bar for showing the methods you want to see in the same place/pane.  This avoids the whole-window-per-method problem (say implementers or senders).  These methods could span different classes and namespaces.  They needn't be in just the currently selected class.  You could get even fancier.  At any time during development, you have your mind on a few classes and one to a few methods in each class.  You could stack same-class method-thumnails contiguously, to ease recognizing them as part of a certain class.  Hovering over any contiguous block of method thumbnails could show the class name in the hover help.  You could still rotate through the same stack of thumbnails with a button click, if you were lazy about studying the thumnails or weren't quite sure what you were looking for, but knew it was in your method thumbnail stack.  I do this all the time with implementers/senders windows.  I know it's there.  I just have to Alt-tab two to eight times to find it.  I find such occularly non-disruptive rotational access for in-one-place reading of methods to be much more focused and mentally resonant, because I'm not loading my visual system anymore than I need to.  Resort to the random-access method thumbnails when rotation becomes too long or fails to find the method.  Failing recognition of a method thumbnail, search for the method or class in a nearby search field.  The method thumbnail stack should be just that:  It should be vertical.  Note that you will only have so much vertical room for each method thumbnail (they are all the same size) and that this will force you to keep your methods short if you want the thumbnails to cover most or all of the form of the method, increasing your ability to recognize it.

You can retrofit back and forwards buttons and maybe make it non-modal by retaining the state of things in the history.

That might work.

 

[Gilad Bracha]

Interesting ideas. Feel free to implement whatever browser scheme works for you and let us know how it goes. On our side, we have no free cycles to pursue this particular issue; in any event we like the current design much better than the circa 1976 class browser.

If you do follow up, make sure your tool fits in the overall Hopscotch framework.  Best would be to create a separate mixin designed to extend, say, NewspeakBrowsing.  That way, it can be integrated into the iDE by those who want it, without burdening those who don't.

[Gilad Bracha]

I just noticed I missed your earlier messages and responded only to the last one. I'll get back to you.

[Bob Westergaard]

On Thu, Apr 2, 2015 at 1:15 AM, Shaping <sha...@uurda.org> wrote:
> Can someone help me with some snippets for changing font size and style?

If on Mophic, I think all you need to do is find the right text style,
update MorphicFontMapper>>#initialize with your preference and then
flush Brazil's font mapper.

For example, I picked a name (BitstreamVeraSansMono ) out of the
dictionary returned by "TextStyle actualTextStyles". Verified the
font's point size with:

(TextStyle named: #BitstreamVeraSansMono) fontArray collect: [:each
| each pointSize]

updated the fontMap in MorhpicFontMapper>>#initialize like so:

fontMap:= {
"tiny" StrikeFont familyName: #BitstreamVeraSansMono pointSize: 9.
"small" StrikeFont familyName: #BitstreamVeraSansMono pointSize: 12.
"normal" StrikeFont familyName: #BitstreamVeraSansMono pointSize: 15.
"large" StrikeFont familyName: #BitstreamVeraSansMono pointSize: 24.
"huge" StrikeFont familyName: #BitstreamVeraSansMono pointSize: 38
}.

Then ran the following do-it:

BlackMarket platform brazil flushDefaultFontMapper

I'm not running Newspeak on windows, but looking at the Brazil mapping
code it looks like you can do something similar by changing the
constructor for FontMapper in WindowsSession to have the font's sizes
you want. The default font we use there appears to be what is set to
the defaultFont slot, which is arialFont. So you could change that
assignment to one of those other fonts if they look acceptable (or
come up with a do-it to set defaultFont after you look at how
FontPreferences are created).

To have that change become visible, your best bet might be to save the
image and restart. Tthere is likely a do-it that can do it. Anyway,
as I mentioned I haven't verified this on Windows, so I might be
missing a detail there.

-- Bob

[Gilad Bracha]

On Thu, Apr 2, 2015 at 1:15 AM Shaping <sha...@uurda.org> wrote:

Are methods also nestable?

No. What I meant was the methods shown nested within the class presenter. They appear in a section with a header labeled 'Methods'. On the right side of that header are small icons: a circle, a dot and a # mark. The circle opens up all the nested presenters in the section. The dot closes them all. # toggles the order between category based and alphabetical.

 

 I'm wondering how that works.  I might not be understanding the big scheme.  I thought only classes and namespaces were nestable.

Only classes are nestable. The language has no notion of namespace declaration other than a class. The IDE supports namespaces, but that is not mature yet.

 

the first time you look at a class. You can do this by clicking the open circle in the Methods section (or class section for that matter). This makes things a lot more like reading a file where you have to scroll

I don't want to scroll.  Who does?  

Nobody. But it is an option so you can avoid what distresses you most, the collapsible method presenters. It lets you stay in the IDE, and the scrolling is what the rest of the world puts up with using their stupid files. 

Can someone help me with some snippets for changing font size and style?

Bob responded.  

How are you rendering in the client area of the Windows window?

The UI is layered. Hopscotch is the high level framework. Brazil is a underneath, supporting widgets. Search for classes with Hopscotch or Brazil in  their names.

 

  How are you rendering text and subwindows in the client area?  Is this JS and HTML?

No - except for when we deploy to JS, where we use Hopscotch directly on top of HTML.

 

[Gilad Bracha]

On Thu, Apr 2, 2015 at 1:50 AM Shaping <sha...@uurda.org> wrote:

The nesting is one major reason why the Squeak browser was unworkable, and maybe you can mitigate that while keeping the basic design.  There are other reasons why we don't care for the classic browser:

(1) It is modal which is a big problem in UI. 

Can you break that down some for me?

In a classical browser, when you make a change to a method, you must accept it or cancel it before switching the view to something else. You can' type some code in and say: ' I want to look at something else before deciding how to proceed' unless you go open another window. This leads to having lots of windows open, which leads to the problem of having to manage them, which leads inventing things like docks or tabs.

More generally, modes have been known to be a bad thing in UI for decades. Hopscotch pretty much makes making modal stuff impossible. Instead, it supports a navigation model much like a web browser.

[Bob Westergaard]

On Thu, Apr 2, 2015 at 10:36 AM, Bob Westergaard <bweste...@gmail.com> wrote:
> I'm not running Newspeak on windows...

I tried it on windows and there is a little more convience there, e.g:

BlackMarket theNativeSession useGeorgiaFont

will switch the font to the georgia font. Take a look at the
NativeSession class for how this works.

-- Bob

[Shaping]

On Thursday, April 2, 2015 at 9:16:20 AM UTC-5, Gilad Bracha wrote:

Interesting ideas. Feel free to implement whatever browser scheme works for you and let us know how it goes. On our side, we have no free cycles to pursue this particular issue; in any event we like the current design much better than the circa 1976 class browser.

If you do follow up, make sure your tool fits in the overall Hopscotch framework.  Best would be to create a separate mixin designed to extend, say, NewspeakBrowsing.  That way, it can be integrated into the iDE by those who want it, without burdening those who don't.

For the client area, are you rendering directly to the device context with GDI, or using HTML and JS in a web view? 

[Gilad Bracha]

No web view or JS involved. Native windows APIs (I guess that's GDI and GDI+, but I no longer recall). Have a look at class Win32API, as well as the BrazilMappingForWin32.

[Vassili Bykov]

It's GDI+.

[sha...@uurda.org]

On Thu, Apr 2, 2015 at 1:50 AM Shaping <sha...@uurda.org> wrote:

The nesting is one major reason why the Squeak browser was unworkable, and maybe you can mitigate that while keeping the basic design.  There are other reasons why we don't care for the classic browser:

 

(1) It is modal which is a big problem in UI. 

 

Can you break that down some for me?

 

In a classical browser, when you make a change to a method, you must accept it or cancel it before switching the view to something else.

 

Gotcha.

 

You can' type some code in and say: ' I want to look at something else before deciding how to proceed' unless you go open another window. This leads to having lots of windows open, which leads to the problem of having to manage them, which leads inventing things like docks or tabs.

 

Yes I agree about the effect, but I don’t mind the extra windows and supporting docks and tabs, as long as I am disciplined enough to control the number of these I allow to appear.  I more or less know my limit.  I’m good to about three or four moderately complicated methods, at once-- ones I’m probably trying to minimize and factor to be more numerous, smaller, and simpler ones.  As the newer ones are created, I can see that they are adequate and simple enough. I then immediately close that window to clear my space and improve my focus.  I’m looping on that pattern of complexity reduction much of the time.

 

More generally, modes have been known to be a bad thing in UI for decades. Hopscotch pretty much makes making modal stuff impossible. Instead, it supports a navigation model much like a web browser.

 

Yes, I see what is driving this, but the modality is not a problem for me as long as I have the “minimize the window-count” discipline working.  I prefer the increasing and decreasing stack of windows to the jumpy NS GUI.   Often the stack degenerates to a ring, but I can still work with that as long as I don’t exceed about eight windows.

 

 

---

This email has been checked for viruses by Avast antivirus software. www.avast.com

[sha...@uurda.org]

Thank you, Bob. I'm working on it.

I'm also looking for work these days; so I'm a bit pressed for time and distracted.

---

This email has been checked for viruses by Avast antivirus software.

http://www.avast.com