On Sat, May 31, 2014 at 10:00 AM, Ben Coman <[email protected]> wrote: > > > Backward compatibility can be a divisive subject. The disparate views > expressed at [1] will give you a general overview of Pharo's philosophy. > Now your question is slightly different to the usual backward-compatibility > discussion that relates to the existing codebase inherited from Squeak and > before. Here on of Pharo's goal to enhance future maintainability by > elimination of "legacy code", where [1] defines "legacy code" as: > - a code written eons ago > - original authors are gone/not interested in communicating > - no documentation > - a lot of patches and extensions from various authors over ears > - often same functionality implemented using two different ways > - things are completely bizarre, unmaintainable and unable to understand > > So for the existing code, while compatibility is kept as much as possible, > cleaning takes priority. While this might cause some early pain, the mid > to long terms should end up better than otherwise. >
Very reasonable and pragmatic. > > Regarding "once something is developed in Pharo will it work unchanged on > _all_ future Pharo versions?" I would hazard to guess, considering the > keyword "all", that the answer is "no". The Pharo team are pragmatic about > what they can achieve with their resources. If something can provide more > (in terms of maintainability and broader usage) for a given effort, then > that is probably the path to be taken. > > [1] > http://lists.gforge.inria.fr/pipermail/pharo-project/2012-December/072196.html > Thanks for the link. Very illuminating. > > > cheers -ben > > > > Maybe we need a GL3ViewportMorph to live along side GLViewportMorph. > > >> As for plans for OpenGL support, normal and accelerated GUIs, I am >> working in OSWindow. >> > > I have read a little of this -- very exciting! > > >> OSWindow provides support to manage native operating system windows >> purely from image side. With Igor, we made a custom image and VM for Linux >> in which we removed almost everything graphic related from the VM. The only >> support needed in the VM is a small check for event presence in the VM >> heartbeat. >> >> For OSWindow, we made initially a XLib based back-end. To reduce >> maintenance efforts for Windows and Mac OS, I made a new backend based in >> SDL2. It is quite complete and I have tested mostly in Linux. For Windows I >> could make it work, not perfect so it needs more testing and a complete >> removal of the old Win32 drivers. I don't have a Mac for testing, but Alex >> is going to help me there. >> > > If there is something I can do to help with the Mac I would like to. > > I have to tell the CMakeVMMaker to also build SDL2 before building, >> instead of having to build/install it manually. After that I think that we >> can start integrating into Pharo 4. >> >> As for OpenGL, SDL2 gives me a multi-platform abstraction for creating >> a window with an OpenGL context. I already made it work with NBOpenGL, the >> only tricky part is dependency order when loading the stuff in the image. >> > > Yes, SDL2 is the way to go. > > In fact, I already started making a new 3D graphics engine Pharo, to >> rewrite Roassal 3D on top of this one in the near future. Soon I will be >> posting some screen-shots of this engine. >> > > Sounds interesting! > > >> With this graphics engine, I am also going to try to make an Athens >> backend, for accelerated vector graphics. Vectorial graphics with OpenGL >> are very hard to do fast, specially self intersecting bezier curves. >> Stencil based testing is simple, fast, supported and efficient for this job. >> > > Very nice. Is Athens used to render the main UI elements (windows, > buttons, bitmaps, text, etc?). > > It's not clear to me how the OSWindow work will result in a faster Pharo > UI. On OSX, at least, underneath everything is already an OS window that > supports GL and other accelerated calls but the Pharo graphics primitives > don't take advantage of this. Won't they need reworking? > > Greetings, >> Ronie >> >> >> 2014-05-30 11:10 GMT-04:00 Sean P. DeNigris <[email protected]>: >> >>> darrinm wrote >>> > Oh, and NBMacGLConstants is lacking necessary constants. Is it manually >>> > created or generated somehow? >>> > >>> > - darrinm >>> >>
