Education ClassRoom/Previous Logs/gsl

[10:59] <PhilippL> Hi everybody

[10:59] * lgodard (n=lgodard@gateway.nuxeo.com) has joined #education.openoffice.org

[11:00] <PhilippL> I have uploaded some slides to http://gsl.openoffice.org/files/documents/16/4245/gsl_overview.odp

[11:00] <PhilippL> Which may be illustrating to what I'm going to say.

[11:00] <PhilippL> So, I'm here to talk a little about the gsl project.

[11:00] <ericb2> hello PhilippL , thank you very much for presenting us the GSL project

[11:01] <PhilippL> First, what does it mean ? GSL stands for Graphics System Layer.

[11:02] <PhilippL> Actually there are some modules in it that have not so much to do with graphics, but essentially GSL is about binding to the graphical subsystems of the system OOo runs on.

[11:02] * PhilippL switches to slide # 2

[11:02] <PhilippL> The core functionality of GSL is providing OOo's toolkit functionality.

[11:03] <PhilippL> Toolkit meaning what gtk is for Gnome, Qt for KDE or Swing / AWT for Java.

[11:03] <PhilippL> The parts of gsl I'm going to talk about a little are mainly located in the vcl, toolkit, dtrans and rsc modules of gsl.

[11:04] <PhilippL> VCL (Visual Control Layer) is the traditional toolkit of OOo.

[11:04] <PhilippL> In use basically since 1997 (meaning in StarOffice before OOo went OpenSource in 2001).

[11:05] <PhilippL> VCL is a C++ toolkit, based heavily on C++ inheritance mechanisms.

[11:05] <PhilippL> Since these are not so easily help binary compatibly.

[11:06] <PhilippL> toolkit was invented, which as a stable UNO API.

[11:06] <PhilippL> UNO meaning (Unified Network Objects)

[11:06] <PhilippL> which is OOo's kind of distributed objects (think Corba or .NET)

[11:07] <PhilippL> toolkit is supposed to be a thin wrapper around vcl that binds the (changing) vcl interface to UNO based services which stay binary compatible.

[11:08] <PhilippL> Then there is the rsc (resource compiler), currently still OOo's most heavily used method of doing localization.

[11:08] * PhilippL switches to slide 3

[11:08] <PhilippL> So let's talk a little more about vcl.

[11:09] <PhilippL> vcl is the core of gsl, providing the main event loop, everything that produces output (Windows, virtua devices, printers,...), most controls (Edit fields, buttons, ...)

[11:10] <PhilippL> it also does a lot for reading system specific settings like theme colors, does native looking widget rendering (NWF).

[11:10] <PhilippL> Basically without vcl you wouldn't see a single pixel.

[11:10] <PhilippL> And at some point it is presumed to go away :-)

[11:10] <PhilippL> But more to that later.

[11:11] * PhilippL switches to slide 4

[11:11] <PhilippL> A little more on toolkit: toolkit is your way to go if you want to write UI code that is going to be binary compatible.

[11:12] <PhilippL> A conditio sine qua non if you're writing extensions.

[11:12] <PhilippL> There are other ways, like using java, of course, but the UNO services provided by toolkit are going to stay for a while.

[11:12] <PhilippL> Making sure that your extension won't only run in OOo 3.0, but 3.1, 3.2 and whatever is going to follow.

[11:13] * PhilippL switches to slide 5

[11:13] <PhilippL> Then there is clipboard and drag&drop functionality.

[11:14] <PhilippL> Logically and implementationwise this is tied quite closely to the main event queue, so it should belong into vcl itself.

[11:14] <PhilippL> That actually is where it originally was, but at the time a new implementation came around, UNO had become to get "en vogue".

[11:15] <PhilippL> So this functionality was put out into an own UNO service library and has staid there since.

[11:16] <PhilippL> If that is a good thing is open to debate, but at least it shows how much flexibility we have with the concepts of UNO. In principle you could exchange the clipboard functionality by your own version, just replacing the service.

[11:16] * PhilippL switches to slide 6

[11:16] <PhilippL> The resource compiler

[11:17] <PhilippL> I mention it mainly because it will come up in an example I will come to later.

[11:17] <PhilippL> RSC is a compiler taking in a "resource source" file containg UI descriptions.

[11:18] <PhilippL> It also contains localizations of everything that needs to be localized (Strings, bitmaps, potentially whole elements).

[11:18] <PhilippL> it compiles this source into a multitude of binary output files, one for each locale requested.

[11:19] <PhilippL> So you end up with one resource file for english, french, german, whatever each.

[11:19] * PhilippL switches to slide 7

[11:19] <PhilippL> There is so many stuff in gsl, let's pick one concrete example.

[11:20] <PhilippL> What you're first going to see when starting OOo is always a Window.

[11:20] <PhilippL> So how does it work ?

[11:20] <PhilippL> From the system point of view, exactly one window is involved here.

[11:21] <PhilippL> This is abstracted using per system implementation in vcl's system dependent layer called SAL: System Abstraction Layer.

[11:21] <PhilippL> Incidentally there is another sal in the porting project.

[11:21] <PhilippL> That one is OOo's equivalent to the C runtime library.

[11:22] <PhilippL> It also means (you guessed it) System Abstraction Layer.

[11:22] <PhilippL> The same name is a historical accident, however vcl's sal layer existed first :-)

[11:22] <PhilippL> So this one system window will usually contain multiple vcl Windows.

[11:23] <PhilippL> That is because vcl uses "soft windows" or "gadgets" as they are e.g. called in the X11 toolkit.

[11:23] <PhilippL> Basically a gadget is only a clip region that confines drawing of a logical window into its own borders.

[11:24] <PhilippL> The management of these gadgets is done by vcl's independent layer.

[11:25] <PhilippL> SAL usually does not need to know about any specific soft child windows that may or may not be children of its one real system window.

[11:25] * PhilippL switches to slide 8

[11:26] <PhilippL> so if you have your typical dialog, the system (X11, Windows, Aqua, whatever) actually knows just one window there, although there are usually many more UI elements which are drawn by vcl's independent layer.

[11:27] <PhilippL> for those seeing the presentation: the "soft" windows are marked in red on the slide.

[11:27] * PhilippL switches to slide 9

[11:28] <PhilippL> So SAL cares about system specific things on our window (positioning, sizing, giving a title) as well as the events that are sent by the system to our window.

[11:29] <PhilippL> It abstracts these events into a common form understood by the independent layer and then defers these abstracted events to it.

[11:29] <PhilippL> The independent layer then cares for transforming the events appropriately for the soft windows that are actually involved.

[11:30] <PhilippL> e.g. it will paint those soft windows that are in the area the system notified us for the system window that needs to be drawn.

[11:30] * PhilippL switches to slide 10

[11:31] <PhilippL> So a more practical question: how do I create a dialog using vcl ?

[11:31] <PhilippL> Typically you create a new class representing your dialog.

[11:31] <PhilippL> This new class inherits form vcl's ModalDialog class.

[11:32] <PhilippL> As data members you include the controls you want to show in your dialog.

[11:32] <PhilippL> The dialog needs a constructor which can take the dialog's parent window as argument.

[11:32] <PhilippL> (the parent window being the one the dialog is supposed to me modal for).

[11:33] <PhilippL> The dialog itself is then the parent of the controls it contains.

[11:34] <PhilippL> running it is then as simple as instantiating your new class and then calling the Execute method inherited from the dialog super class.

[11:34] * mynfred has quit ()

[11:35] <PhilippL> on slide number 11 you can see an example of a very simple dialog containing two radio buttons, an OK and a Cancel button.

[11:35] * PhilippL switches to slide 12

[11:36] <PhilippL> The good sides: you write abstracted code, all that is necessari

[11:36] <PhilippL> oops

[11:36] <PhilippL> necessary to do on a specific platform will be done automatically for you.

[11:36] <PhilippL> Write once, run anywhere

[11:37] <PhilippL> There is a provend localization mechanism that works the same on all platforms, no need to be involved in one localization mechanism for every platform.

[11:37] * PhilippL switches to slide 13

[11:38] <PhilippL> So what is "bad" about vcl ?

[11:38] <ericb2> :-)

[11:38] <PhilippL> For even the most simple dialog you need to create new c++ code.

[11:38] <PhilippL> There is no UI editor currently, all controls are hand positioned.

[11:39] <PhilippL> There is no layouting capability, which OOo is quite suffering from.

[11:39] <PhilippL> However there is an effort underway to correct this via a new toolkit service.

[11:40] <PhilippL> vcl uses its own controls, not native widgets -> you'll have perhaps the system look (if NWF works right) but won't have the system "feel"

[11:40] <PhilippL> So is this going to change.

[11:40] <PhilippL> In short we plan to ...

[11:41] <PhilippL> ... for the last five years ...

[11:41] <PhilippL> The amount involved would be staggering since virtually the whole office would have to be recoded.