Esteban Lorenzano wrote:
Hi, A couple of weeks ago we started to plan Pharo4. This work became stagnated for many reasons, but mainly because I needed to travel to Argentina. Now I'm slowly resuming the work and I wanted to share with you what we have been talking/dreaming. In esence, we have two important drivers for this release: 1) Improving tools Turns out that we have introduced a lot of kernel improvements (opal compiler, layouts, slots, etc.) and tools are still not aware of them. Even worst: we have traits since a lot of time and our tools are still now aware enough to provide good interoperability. But not just that: we have introduced things that are not well used yet: keybindings (who do not want a better keybindings structure... coherent and editable?), spec should allow us to continue enhancing existing tools and to replace old ones. 2) Modularisation One of the fundamental ideas behind Pharo is to provide a modular environment. But well... since Pharo start to the moment, we prepared things to allow it, but still few direct effort has been made. In our dreams, Pharo should be built starting for a small kernel image and adding different modules to get a complete version. In this idea Pharo=Kernel+GUI(Morphic)+Tools.
This has huge advantages (I do not think is necesary to explain them, isn't ;)?)

We brainstomed around this and we get this list of issues (not all of them directly related to the objectives, but well... good stuff also :) ) Web site: - add catalog

Having the catalog accessible in-image from the Configuration Browser would be very useful. Also if when generating the catalog the system could would out what the versions are available from the Configuration, the being able to get a menu on an item in the Configuration Browser that should which versions were available would be super-cool.

- add videos
- enhance it in general

Infrastructure:
- support more vm platforms

VM:             
- spur
- 64bits
- make vm embedable and UI independent (with SDL2 and OSWindow)
Those three for VM are super-cool.

Image:
- Modularisation - Removing old compiler - Repackage Morphic (to allow better modularisation) - Athens (replace old bitblt)



Tools
- Replace changes with Ombu/Epicea
- Replace sources with a better abstraction

Something that could grab additional version history from a repository would be good. Now that we are delivering images from CI which from Configurations, there is no version history, and I think we lose something there.

- Git support inside image (with libgit2 + tools)

Maybe this could facilitate a cool Roassal/Moose based "git analyser" application ? And maybe draw in some new end-users, who obviously once they want to customize it, will drawn into discovering Pharo.

- Pass on Spec
- Include Glamour?
- Make Ring unloadable
- Fonts with FreeType

And lots of bugfixes :)

We would like to exchange ideas with you. So, what do you think?


For KeyBindings, a useful tool would be one that:
* could determine and display what the current bindings are - global, per tool and even per window if appropriate. * provided a history to help find what is overriding key bindings - including legacy methods of setting shortcuts. * allow end-users (even non-programmers) to define their own shortcuts similar to how other applications like MS Word do it - and all in the one place integrated with the previous two points.

Now not one of the biggest issues in the world, but one annoyance when starting with Pharo was the yellowButton/redButton legacy. I guess that when the GUI was being invented they didn't have today's terminolgy, so using colour was beneficial as they explored the problem space - but are there better terms that could be used today - like "select" / "context" / "meta"?. Or is that too constraining even today. Maybe just "primary" "secondary" "tertiary" would be more understandable and familiar.

Remote tools, that could help work with the minimal images, and on headless web servers.

cheers -ben

Reply via email to