I can subscribe to most what others have said. Your list is pretty good and I like even the order of things. Only a few additions.
„Improving tools“: One aspect is making the tools aware of new achievements in the core. Another aspect is to finish things that did change in the past like e.g. keybindings. Nautilus uses new keyboard shortcut while other tools use old ones. That is killing the development experience. „Modularization“: I think this should be _the_ goal for pharo4: Changing the whole build process to a bootstrap+module approach. This is a huge step IMHO. To make it more modular also means things can get smaller and smaller. This also raises the necessity of having remote debugging tools because UI is suspect to not being there. This step will also improve the way we can manage deployed images which is especially important for a company like mine. And I hope having decent remote enabled model will also open new possibilities for image interoperation. 64bit vm: Like sven said it is necessary for us to have at least a 64bit vm with a 32bit address space. Without that we are somewhat way behind what is normal for others. 64bit address space should be a goal for pharo5. Slots: I would like it to see Slots being usable. It enables people to play with new things without having to tweak the vm. And I like all magritte like stuff being handled by slots which will improve the situation a lot. And that’s one thing that sets us way ahead of what is normal for others. Remove old compiler for obvious reasons. So that would be one to two tasks for areas of improve existing (maintenance), change for the better, distribution and cleanup. That would be all for pharo4 for me. Norbert Am 04.06.2014 um 17:36 schrieb Esteban Lorenzano <[email protected]>: > 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 > - add videos > - enhance it in general > > Infrastructure: > - support more vm platforms > > VM: > - spur > - 64bits > - make vm embedable and UI independent (with SDL2 and OSWindow) > > 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 > - Git support inside image (with libgit2 + tools) > - 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? > > Esteban > >
