[d-mason]

The small size of methods is a feature, not a bug :-).

And this partly explains why the lack of [your favourite editor] bindings isn't so important. You don't typically spend as much time as you're used to typing in code - and make progress faster as a result - counter-intuitive as that may sound. The integration and the debugger are most of the reason why.

[zestyping]

It sounds a lot like you are trying to tell a programmer to stop programming using the keyboard and program using the mouse instead. I think I understand why you are doing that, but I don't see how you can expect to be successful this way.

For 99% of programmers out there, programming IS typing on a keyboard. Clicking around with a mouse is only something that non-expert users (or children, e.g. Scratch users) do, because it is approximately 10x slower to get anything done by laboriously pointing and clicking than by typing. For example, finding the largest file in my home directory through the GUI takes 5 careful targeting operations and 5 clicks, a click-and-drag, and then some scrolling, and then I have to do more dragging to move the window around so I can see what's under it. Using a keyboard I type "ll -S" and I'm done in half a second (and immediately able to issue the next command). You simply can't compete with that.

Even though it isn't the same way you are used to operating, I think it will be necessary to take into account the needs of that audience if you want to bring them on board.

As a thought experiment, what would it take to make the environment comfortably usable with only a keyboard, including discoverability of all the necessary keyboard controls? You could treat it as an accessibility issue; what if the user is unable to use a mouse?

[philippeback]

As a keyboard freak and vim user, I can relate.

As a Pharo contributor, well, there is indeed some clicking involved but not as much as you may think.

Keybindings are okayish at this point but can use some more love indeed. But this is not related to the core of Pharo but to the tooling that can be improved on some aspects (and this is moving forward actually).

If a user is not able to use a mouse, well, maybe the user can have a CI that integrates all of the code written in Tonel format and pushed to a git repo. Can work, Tonel format is pretty readable and usable from a command line.

There are ways to use Pharo as a "normal" language. But then, what's the point.

[klibertp]

> Keybindings are okayish at this point

I see the new framework for keyboard shortcuts was completed. There are many shortcuts to customize in preferences now. Congrats! :)

Still, the shortcuts by default are totally different than the usual. Is it possible to make for example readline (bash) emulation with the new keyboard shortcuts code? Where would you start if you wanted to do this?

> As a Pharo contributor

I played with 7.0 yesterday, I have a few questions, maybe you'll be able to help me:

- I work on a Linux with high DPI display. I increased the font size of everything to extra large and set scaling factor, which helped, but the cursor is still tiny and almost invisible. I tried reading the code in HandMorph and Cursor, however, the beCursor method which handles displaying of hardwareCursor (I assume) is a primitive. I downloaded the opensmalltalk-vm and after a short fight with it succeeded in running its image. I found primitiveBeCursor method, but it calls C-level function called something like `ioSetCursorSomething` - and I couldn't locate that function. Do you know where it is?

- when you set scaling factor and font size, it's not universally recognized. The menu at the top of screen didn't change its font size, the lists with columns (in preferences, in debugger, etc.) have fixed column-size which truncates most entries (and splitter for changing the width of a column is barely visible), some elements start overlapping (tabs in the browser obscure the row with instance/class side, flat/hier and so on), the windows seem to have hard-coded initial extents which ignore font-size and scaling. To be honest it's barely usable right now for me, to the point that, to play with it, I had to create a dummy Xvnc display and run Pharo there, then run x11vnc on the Pharo window id and finally connect to it via VNC client, scaled the whole thing up. It's a bit nightmarish an experience :) Is there any work towards making it better in progress?

- related to the above, is it possible to set the initial extent of the Pharo window (the top-most, OS-level one, I mean) on the command-line? There's a switch for starting in iconified state or fullscreen, but I didn't find one like `size` or `geometry`.

- What are class "extensions"? Are they simply traits, or is it something new? Is it documented somewhere?

---

I see lots of great progress on all fronts, but Pharo remains rough around the edges. The discoverability of the details is great, but the bigger picture - an overview of all the toolkits, for example, or a succinct description of architecture - is very hard to piece together. The new package manager interface finally displays a bit of description for each (this wasn't the case for a long time), but many packages have no description. Coupled with package names being rather hermetic this makes for a frustrating experience. I'm a rather persistent kind of guy and so I stuck with Pharo despite all that, but I imagine many other devs wouldn't care to do this, unfortunately.

[klibertp]

Note to self (mostly): there's a SQUEAK_FAKEBIGCURSOR env var which you can set to 1 to have the VM display twice as big cursor. I've no idea why there's the 'FAKE' part, from the source it looks like it just creates a normal X11 cursor that's twice as big. This should work will Cuis, Squeak, and Pharo, as it's part of VM.

[xkriva11]

"MenubarMorph reset" will fix the menu bar scaling factor.

Extensions are methods installed into classes by other packages.

[klibertp]

The problem with the keyboard-only input style in Pharo is that it encourages opening lots and lots of windows. Arranging them by hand is tedious with a mouse, and with the keyboard, it would be unbearable I think.

There is the infrastructure for custom key-bindings in place, although last time I checked it was being rewritten; I think that was finished around 6.0.

What it would need, in my opinion, as someone who almost never touches a mouse myself:

- either a tiling window manager or a set of fixed layouts for where windows should appear. I'm not sure how is the placement of new windows currently done, but it's rather dumb.

- something like this: http://oremacs.com/download/ace-window.gif for switching focus between windows. Failing that, the ability to switch focus to the window on the left/right/top/bottom. switching between hordes of ungrouped windows in Ctrl+Tab is a nightmare.

- easily overridable global key bindings. This was rather complicated last time I checked. Also, the key-binding model should be powerful enough to allow for chords (sequences of keys: Ctrl+X, then Ctrl+Y, etc.).

- a mode which would go through all the widgets in the current window and display all available labels (over buttons and menus). Most of the labels contain a name of a function and a keyboard shortcut already.

- there's a Shift+Enter shortcut which opens Spotter: you can type some characters and it will search the image for anything matching, including code, comments, external packages, and global menu items. It would be great if it was also context-sensitive so that you can invoke functions of the currently focused window through it too.

- Emacs/Readline and Vim bindings provided in the base image would be very appreciated.

That would be a good start, I think :) It's a lot of work, though, and there doesn't seem to be a will to pursue this in the community, unfortunately :(