eric.bachard wrote:
Hi,Philipp Lohmann - Sun Germany a écrit :If you find any design patterns in vcl, please let me know :-)Ok, sorry for my bad english. I was mainly thinking "design", "organisation", "logical", or, maybe the more close word is the one you proposed below : "abstractions"
I understood, i merely tried to make a joke. The sad fact is that there is no one left of the original designers and that most of vcl is more like grown than designed.
More seriously, if you have any question please ask.I'll try. In fact, what I ask means a lot of possibilities, and is probably not very precise, but anything like diagrams or any information describing :- the logical of other integrators (like DTIntegrator ), if any other similar abstractions are used/existing - the logical about e.g. interactions between main, instance, windows and frames (what needs what, what happens when quit ..etc)- the logical describing vcl, and it's interaction with other modules Will help.This is very generic, I know, but even some sentences describing this will save a lot of time, e.g. to describe how the code is organized, and how it works.
Basically vcl is divided in the system dependent and the system independent part. The interface between these two is mostly the Sal interface (every interface name Sal*: SalInstance, SalFrame, SalGraphics, SalPrinter, etc.).
SalInstance is a factory that can create all the other abstracted interfaces of the system dependent part. It also provides the main loop SalInstance::Yield()
SalFrame abstracts any kind of system window. SalVirtualDevice abstracts an offscreen window (e.g. a Pixmap on X11)SalPrinter and SalInfoPrinter abstract the system print queues where SalInfoPrinter is for querying and SalPrinter for actual printing.
SalGraphics is an interface produced by either SalFrame, SalVirtualDevice or SalPrinter which is used for actual drawing operations (text, bitmaps, vector graphics)
SalSound is for sound playing.SalBitmap provides memory for bitmap graphics as well as methods converting this memory to a system handle (e.g. a Pixmap on X11).
SalOpenGL provides OpenGL functionality if available.SalTimer is an interface for periodically triggering the event queue (to timer implementation).
SalI18NImeStatus handles how the status window of an Input Method Editor (IME) should display (this is mainly X11 specific).
SalSystem has some system specific methods that did not belong anywhere else :-)
Of all these there interfaces is at least one implementation per system (Windows, X11 or Mac). The Unix implementation also has a plugin concept to allow for integration of different native toolkits (currently gtk and Qt) which became necessary for the implementation of Native Widget Framework (NWF) to display controls like their normal desktop counterparts.
Basically the independent part (what is beneath vcl/source directory) has generic methods for drawing, window handling and stuff which it brings into a suitable form and then delegates to the system specific implementaion (located beneath vcl/win for Windows and vcl/unx for the X11 platforms).
I hope this is a start, please feel free to ask any questions.
Kind regards, pl
--
If you give someone a program, you will frustrate them for a day;
if you teach them how to program, you will frustrate them for a lifetime.
-- Author unknown
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
