First of all I would like to apologize for my lack of attention with GSoC this week it was basically because my university (UFG) sent us to a coding week in other one (UFPB). To make that time lost up I’ll work double until the program end. I’ll everyday post here about what I’m refactoring and how I’m doing this stuff, and how I’m applying the corrections that Mario Torre is giving me. So to not lose some time I’ll post today some basic AWT Relationship (which explains Escher) and the class refactoring that I’m working right know (gnu.x11.Display).
Java has by default at least one AWT (Abstract Window Toolkit) implementation, which enables various ways to manipulate GUI in general (graphics/events). Everything starts with Toolkit which is a abstract class that defines the basic functionality of a rendering kit, that is a AWT. To add extra functionality GNU Classpath subclass the Toolkit into ClasspathToolkit which basically add extra methods for extra information, such as, getting all truetype fonts available on the system. The same process, sub-classing and adding extra methods, happens on OpenJDK but is called SunToolkit.
Now we need peers to make the communication with the toolkit (Gtk, Qt, X11) and Java. We basically have a bunch of implementation making calls to their respective peer, usually using JNI to call the C/C++ code. The X11 toolkit is special in a sense that it doesn’t need a full desktop environment to run, it needs only a X11 Server. Escher is the implementation of the X11 peer written totally in Java. It send and receive requests from the X11 Server and repass to Java. Since Escher is written totally in Java and the X11 peer don’t need a full desktop environment it makes perfect sense to use it on a embedded device that needs a low memory footprint. To sum up Escher like any X client can handle extension, in fact it already implemented the famous GLX extension which allow a client (application) to use OpenGL inside a X11 window.
Tomorrow I’ll bring some of the refactoring that I’m doing…