Hi mkatkar, mkatkar wrote:
> Hi Mathias , > Thanks a lot for your reply . Few comments from my side . > > [Mathias] I don't understand how the port relates to the viewing > functionality. I >> would expect that changes in the vcl pluging layer won't affect any code >> in framework, sw, sc etc. > [Monali] : To start with the porting to directfb , i intend to used the > sw,sc only to viewing Microsoft docs and xls . Basically want to open the > documents in read only mode with these packages and get this working with > the GTK-DirectfB plugin that i intend to add in OOo > > When porting these OOo applications ( like writer, calc, impress ) to > directfb plugin, I want to understand how the writer , calc and impress > module interact with VCL. Do all the three have the same way of interaction > with VCL layer.What layers do i need to understand to get the path from > application modules to the VCL layer ? What is the role played at modules in > frramework layer. Is there any documentation ? Any pointers from you will > really help. > > Is there any way, to get a list of modules that the swriter/calc/impress > depend on . Is there any way that i kind of find only the relevant modules > in the large OOo code that i would need to build/test. > > Also is it possible for me to disable other modules not required for viewing > functionality as dtrans ( clipboard functionality) and which make X calls . VCL is not a part of our framework. Basically the OOo framework is implemented on top of our AWT toolkit API, only a few parts in the code directly access VCL as the toolkit misses the corresponding functionality (this can be seen as an "incomplete implementation" - a bug). The framework creates an environment where the applications run with and this environment is described in our Developer's Guide in close detail. No VCL involved so far. The code in our applications has an origin that is much older than our framework and so uses much more VCL based code than would be necessary today. They communicate with the framework through a thin UNO API layer. A part of the application is the "viewing" functionality. This code heavily uses direct VCL calls to render output to a device. There is ongoing effort to replace this by encapsulating output in graphical primitives that render themselves to a Canvas with a UNO API layer but this surely will take some time. So for the time being you can assume that most of the rendering code in our application uses VCL. An important exception is the presentation engine. Wrt. DirectFB I don't think that you need to know a lot about the way how applications use VCL. I would be very astonished if any code inside the applications needed to be changed. VCL shields them against the platform layer pretty well, they don't know wether they run on Windows, Mac OS, KDE or Gnome. Everything that is needed for the graphical platform support is done inside VCL. So why should that be different for DirectFB? So for further details you place should be dev[at]gsl.openoffice.org Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
