Difference between revisions of "Education ClassRoom/Previous Logs/gsl"

From Apache OpenOffice Wiki
Jump to: navigation, search
Line 1: Line 1:
−
[10:59]  <PhilippL> Hi everybody
+
{|
 +
|- id="t10:59"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | Hi everybody
 +
|| [[#t10:59|10:59]]
 +
|- id="t10:59"
 +
| colspan="2" | * lgodard (n=lgodard@gateway.nuxeo.com) has joined #education.openoffice.org
 +
|| [[#t10:59|10:59]]
 +
|- id="t11:00"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | I have uploaded some slides to http://gsl.openoffice.org/files/documents/16/4245/gsl_overview.odp
 +
|| [[#t11:00|11:00]]
 +
|- id="t11:00"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | Which may be illustrating to what I'm going to say.
 +
|| [[#t11:00|11:00]]
 +
|- id="t11:00"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | So, I'm here to talk a little about the gsl project.
 +
|| [[#t11:00|11:00]]
 +
|- id="t11:00"
 +
! style="background-color: #42427e" | ericb2
 +
| style="color: #42427e" | hello PhilippL , thank you very much for presenting us the GSL project
 +
|| [[#t11:00|11:00]]
 +
|- id="t11:01"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | First, what does it mean ? GSL stands for Graphics System Layer.
 +
|| [[#t11:01|11:01]]
 +
|- id="t11:02"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | 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
 +
|| [[#t11:02|11:02]]
 +
|-
 +
| colspan="3" | subsystems of the system OOo runs on.
 +
|- id="t11:02"
 +
| colspan="2" | * PhilippL switches to slide # 2
 +
|| [[#t11:02|11:02]]
 +
|- id="t11:02"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | The core functionality of GSL is providing OOo's toolkit functionality.
 +
|| [[#t11:02|11:02]]
 +
|- id="t11:03"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | Toolkit meaning what gtk is for Gnome, Qt for KDE or Swing / AWT for Java.
 +
|| [[#t11:03|11:03]]
 +
|- id="t11:03"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | 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.
 +
|| [[#t11:03|11:03]]
 +
|- id="t11:04"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | VCL (Visual Control Layer) is the traditional toolkit of OOo.
 +
|| [[#t11:04|11:04]]
 +
|- id="t11:04"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | In use basically since 1997 (meaning in StarOffice before OOo went OpenSource in 2001).
 +
|| [[#t11:04|11:04]]
 +
|- id="t11:05"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | VCL is a C++ toolkit, based heavily on C++ inheritance mechanisms.
 +
|| [[#t11:05|11:05]]
 +
|- id="t11:05"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | Since these are not so easily help binary compatibly.
 +
|| [[#t11:05|11:05]]
 +
|- id="t11:06"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | toolkit was invented, which as a stable UNO API.
 +
|| [[#t11:06|11:06]]
 +
|- id="t11:06"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | UNO meaning (Unified Network Objects)
 +
|| [[#t11:06|11:06]]
 +
|- id="t11:06"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | which is OOo's kind of distributed objects (think Corba or .NET)
 +
|| [[#t11:06|11:06]]
 +
|- id="t11:07"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | toolkit is supposed to be a thin wrapper around vcl that binds the (changing) vcl interface to UNO based services which stay binary
 +
|| [[#t11:07|11:07]]
 +
|-
 +
| colspan="3" | compatible.
 +
|- id="t11:08"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | Then there is the rsc (resource compiler), currently still OOo's most heavily used method of doing localization.
 +
|| [[#t11:08|11:08]]
 +
|- id="t11:08"
 +
| colspan="2" | * PhilippL switches to slide 3
 +
|| [[#t11:08|11:08]]
 +
|- id="t11:08"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | So let's talk a little more about vcl.
 +
|| [[#t11:08|11:08]]
 +
|- id="t11:09"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | vcl is the core of gsl, providing the main event loop, everything that produces output (Windows, virtua devices, printers,...), most
 +
|| [[#t11:09|11:09]]
 +
|-
 +
| colspan="3" | controls (Edit fields, buttons, ...)
 +
|- id="t11:10"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | it also does a lot for reading system specific settings like theme colors, does native looking widget rendering (NWF).
 +
|| [[#t11:10|11:10]]
 +
|- id="t11:10"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | Basically without vcl you wouldn't see a single pixel.
 +
|| [[#t11:10|11:10]]
 +
|- id="t11:10"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | And at some point it is presumed to go away :-)
 +
|| [[#t11:10|11:10]]
 +
|- id="t11:10"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | But more to that later.
 +
|| [[#t11:10|11:10]]
 +
|- id="t11:11"
 +
| colspan="2" | * PhilippL switches to slide 4
 +
|| [[#t11:11|11:11]]
 +
|- id="t11:11"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | 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.
 +
|| [[#t11:11|11:11]]
 +
|- id="t11:12"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | A conditio sine qua non if you're writing extensions.
 +
|| [[#t11:12|11:12]]
 +
|- id="t11:12"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | There are other ways, like using java, of course, but the UNO services provided by toolkit are going to stay for a while.
 +
|| [[#t11:12|11:12]]
 +
|- id="t11:12"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | Making sure that your extension won't only run in OOo 3.0, but 3.1, 3.2 and whatever is going to follow.
 +
|| [[#t11:12|11:12]]
 +
|- id="t11:13"
 +
| colspan="2" | * PhilippL switches to slide 5
 +
|| [[#t11:13|11:13]]
 +
|- id="t11:13"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | Then there is clipboard and drag&amp;drop functionality.
 +
|| [[#t11:13|11:13]]
 +
|- id="t11:14"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | Logically and implementationwise this is tied quite closely to the main event queue, so it should belong into vcl itself.
 +
|| [[#t11:14|11:14]]
 +
|- id="t11:14"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | That actually is where it originally was, but at the time a new implementation came around, UNO had become to get "en vogue".
 +
|| [[#t11:14|11:14]]
 +
|- id="t11:15"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | So this functionality was put out into an own UNO service library and has staid there since.
 +
|| [[#t11:15|11:15]]
 +
|- id="t11:16"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | 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
 +
|| [[#t11:16|11:16]]
 +
|-
 +
| colspan="3" | could exchange the clipboard functionality by your own version, just replacing the service.
 +
|- id="t11:16"
 +
| colspan="2" | * PhilippL switches to slide 6
 +
|| [[#t11:16|11:16]]
 +
|- id="t11:16"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | The resource compiler
 +
|| [[#t11:16|11:16]]
 +
|- id="t11:17"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | I mention it mainly because it will come up in an example I will come to later.
 +
|| [[#t11:17|11:17]]
 +
|- id="t11:17"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | RSC is a compiler taking in a "resource source" file containg UI descriptions.
 +
|| [[#t11:17|11:17]]
 +
|- id="t11:18"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | It also contains localizations of everything that needs to be localized (Strings, bitmaps, potentially whole elements).
 +
|| [[#t11:18|11:18]]
 +
|- id="t11:18"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | it compiles this source into a multitude of binary output files, one for each locale requested.
 +
|| [[#t11:18|11:18]]
 +
|- id="t11:19"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | So you end up with one resource file for english, french, german, whatever each.
 +
|| [[#t11:19|11:19]]
 +
|- id="t11:19"
 +
| colspan="2" | * PhilippL switches to slide 7
 +
|| [[#t11:19|11:19]]
 +
|- id="t11:19"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | There is so many stuff in gsl, let's pick one concrete example.
 +
|| [[#t11:19|11:19]]
 +
|- id="t11:20"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | What you're first going to see when starting OOo is always a Window.
 +
|| [[#t11:20|11:20]]
 +
|- id="t11:20"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | So how does it work ?
 +
|| [[#t11:20|11:20]]
 +
|- id="t11:20"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | From the system point of view, exactly one window is involved here.
 +
|| [[#t11:20|11:20]]
 +
|- id="t11:21"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | This is abstracted using per system implementation in vcl's system dependent layer called SAL: System Abstraction Layer.
 +
|| [[#t11:21|11:21]]
 +
|- id="t11:21"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | Incidentally there is another sal in the porting project.
 +
|| [[#t11:21|11:21]]
 +
|- id="t11:21"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | That one is OOo's equivalent to the C runtime library.
 +
|| [[#t11:21|11:21]]
 +
|- id="t11:22"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | It also means (you guessed it) System Abstraction Layer.
 +
|| [[#t11:22|11:22]]
 +
|- id="t11:22"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | The same name is a historical accident, however vcl's sal layer existed first :-)
 +
|| [[#t11:22|11:22]]
 +
|- id="t11:22"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | So this one system window will usually contain multiple vcl Windows.
 +
|| [[#t11:22|11:22]]
 +
|- id="t11:23"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | That is because vcl uses "soft windows" or "gadgets" as they are e.g. called in the X11 toolkit.
 +
|| [[#t11:23|11:23]]
 +
|- id="t11:23"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | Basically a gadget is only a clip region that confines drawing of a logical window into its own borders.
 +
|| [[#t11:23|11:23]]
 +
|- id="t11:24"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | The management of these gadgets is done by vcl's independent layer.
 +
|| [[#t11:24|11:24]]
 +
|- id="t11:25"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | 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.
 +
|| [[#t11:25|11:25]]
 +
|- id="t11:25"
 +
| colspan="2" | * PhilippL switches to slide 8
 +
|| [[#t11:25|11:25]]
 +
|- id="t11:26"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | 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.
 +
|| [[#t11:26|11:26]]
 +
|- id="t11:27"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | for those seeing the presentation: the "soft" windows are marked in red on the slide.
 +
|| [[#t11:27|11:27]]
 +
|- id="t11:27"
 +
| colspan="2" | * PhilippL switches to slide 9
 +
|| [[#t11:27|11:27]]
 +
|- id="t11:28"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | 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.
 +
|| [[#t11:28|11:28]]
 +
|- id="t11:29"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | It abstracts these events into a common form understood by the independent layer and then defers these abstracted events to it.
 +
|| [[#t11:29|11:29]]
 +
|- id="t11:29"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | The independent layer then cares for transforming the events appropriately for the soft windows that are actually involved.
 +
|| [[#t11:29|11:29]]
 +
|- id="t11:30"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | 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.
 +
|| [[#t11:30|11:30]]
 +
|- id="t11:30"
 +
| colspan="2" | * PhilippL switches to slide 10
 +
|| [[#t11:30|11:30]]
 +
|- id="t11:31"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | So a more practical question: how do I create a dialog using vcl ?
 +
|| [[#t11:31|11:31]]
 +
|- id="t11:31"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | Typically you create a new class representing your dialog.
 +
|| [[#t11:31|11:31]]
 +
|- id="t11:31"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | This new class inherits form vcl's ModalDialog class.
 +
|| [[#t11:31|11:31]]
 +
|- id="t11:32"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | As data members you include the controls you want to show in your dialog.
 +
|| [[#t11:32|11:32]]
 +
|- id="t11:32"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | The dialog needs a constructor which can take the dialog's parent window as argument.
 +
|| [[#t11:32|11:32]]
 +
|- id="t11:32"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | (the parent window being the one the dialog is supposed to me modal for).
 +
|| [[#t11:32|11:32]]
 +
|- id="t11:33"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | The dialog itself is then the parent of the controls it contains.
 +
|| [[#t11:33|11:33]]
 +
|- id="t11:34"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | running it is then as simple as instantiating your new class and then calling the Execute method inherited from the dialog super class.
 +
|| [[#t11:34|11:34]]
 +
|- id="t11:34"
 +
| colspan="2" | * mynfred has quit ()
 +
|| [[#t11:34|11:34]]
 +
|- id="t11:35"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | on slide number 11 you can see an example of a very simple dialog containing two radio buttons, an OK and a Cancel button.
 +
|| [[#t11:35|11:35]]
 +
|- id="t11:35"
 +
| colspan="2" | * PhilippL switches to slide 12
 +
|| [[#t11:35|11:35]]
 +
|- id="t11:36"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | The good sides: you write abstracted code, all that is necessari
 +
|| [[#t11:36|11:36]]
 +
|- id="t11:36"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | oops
 +
|| [[#t11:36|11:36]]
 +
|- id="t11:36"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | necessary to do on a specific platform will be done automatically for you.
 +
|| [[#t11:36|11:36]]
 +
|- id="t11:36"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | Write once, run anywhere
 +
|| [[#t11:36|11:36]]
 +
|- id="t11:37"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | 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.
 +
|| [[#t11:37|11:37]]
 +
|- id="t11:37"
 +
| colspan="2" | * PhilippL switches to slide 13
 +
|| [[#t11:37|11:37]]
 +
|- id="t11:38"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | So what is "bad" about vcl ?
 +
|| [[#t11:38|11:38]]
 +
|- id="t11:38"
 +
! style="background-color: #42427e" | ericb2
 +
| style="color: #42427e" | :-)
 +
|| [[#t11:38|11:38]]
 +
|- id="t11:38"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | For even the most simple dialog you need to create new c++ code.
 +
|| [[#t11:38|11:38]]
 +
|- id="t11:38"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | There is no UI editor currently, all controls are hand positioned.
 +
|| [[#t11:38|11:38]]
 +
|- id="t11:39"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | There is no layouting capability, which OOo is quite suffering from.
 +
|| [[#t11:39|11:39]]
 +
|- id="t11:39"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | However there is an effort underway to correct this via a new toolkit service.
 +
|| [[#t11:39|11:39]]
 +
|- id="t11:40"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | vcl uses its own controls, not native widgets -&gt; you'll have perhaps the system look (if NWF works right) but won't have the system "feel"
 +
|| [[#t11:40|11:40]]
 +
|- id="t11:40"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | So is this going to change.
 +
|| [[#t11:40|11:40]]
 +
|- id="t11:40"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | In short we plan to ...
 +
|| [[#t11:40|11:40]]
 +
|- id="t11:41"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | ... for the last five years ...
 +
|| [[#t11:41|11:41]]
 +
|- id="t11:41"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | The amount involved would be staggering since virtually the whole office would have to be recoded.
 +
|| [[#t11:41|11:41]]
 +
|- id="t11:42"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | At some point we still hope to do this transformation, though.
 +
|| [[#t11:42|11:42]]
 +
|- id="t11:42"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | Which is why vcl is sometimes considered "dead".
 +
|| [[#t11:42|11:42]]
 +
|- id="t11:43"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | In short, if you create new UI, the most reliable way currently (if you don't want to do code maintanance very often) is to use the UNO based toolkit.
 +
|| [[#t11:43|11:43]]
 +
|- id="t11:43"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | This is going to stay for a while.
 +
|| [[#t11:43|11:43]]
 +
|- id="t11:44"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | Seeing that I'll have to go in about 15 minutes, are there any questions ?
 +
|| [[#t11:44|11:44]]
 +
|- id="t11:45"
 +
! style="background-color: #42427e" | ericb2
 +
| style="color: #42427e" | I have some, but I'll ask you later (very specific)
 +
|| [[#t11:45|11:45]]
 +
|- id="t11:45"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | BTW: if you have questions, you can usually find me on #dev.openoffice.org
 +
|| [[#t11:45|11:45]]
 +
|- id="t11:45"
 +
! style="background-color: #42427e" | ericb2
 +
| style="color: #42427e" | was awesome :)
 +
|| [[#t11:45|11:45]]
 +
|- id="t11:45"
 +
| colspan="2" | * ericb2 learned a lot
 +
|| [[#t11:45|11:45]]
 +
|- id="t11:45"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | or you can mail me directly (address is in the presentation).
 +
|| [[#t11:45|11:45]]
 +
|- id="t11:46"
 +
! style="background-color: #42427e" | ericb2
 +
| style="color: #42427e" | PhilippL: I just regret not much attendees joined the channel. I know for sure a lot of people read the log, but this is damage, to see a so
 +
|| [[#t11:46|11:46]]
 +
|-
 +
| colspan="3" | valuable developer like you with so few people asking for questions :/
 +
|- id="t11:46"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | I mean "send a mail to me", not "mail me" of course :-)
 +
|| [[#t11:46|11:46]]
 +
|- id="t11:47"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | not a problem, as I said I have to go for a while anyway :-)
 +
|| [[#t11:47|11:47]]
 +
|- id="t11:48"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | So it seems that's it for today.
 +
|| [[#t11:48|11:48]]
 +
|- id="t11:48"
 +
! style="background-color: #42427e" | ericb2
 +
| style="color: #42427e" | PhilippL: ok, then if there are no questions, I'll ask on the list.  Thank you very much for your presentation:  I'd really have been glad to find it several years ago, when I started to contribute for Mac OS X port
 +
|| [[#t11:48|11:48]]
 +
|- id="t11:48"
 +
! style="background-color: #407a40" | PhilippL
 +
| style="color: #407a40" | Have a nice day everyone and don't hesitate to ask on #dev.openoffice.org or dev@gsl.openoffice.orf mailing list.
 +
|| [[#t11:48|11:48]]
 +
|}
  
−
[10:59]  * lgodard (n=lgodard@gateway.nuxeo.com) has joined #education.openoffice.org
+
Generated by irclog2html.py 2.6 by [mailto:marius@pov.lt Marius Gedminas] - find it at [http://mg.pov.lt/irclog2html mg.pov.lt]!
−
 
+
−
[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.
+
−
 
+
−
[11:42]  <PhilippL> At some point we still hope to do this transformation, though.
+
−
 
+
−
[11:42]  <PhilippL> Which is why vcl is sometimes considered "dead".
+
−
 
+
−
[11:43]  <PhilippL> In short, if you create new UI, the most reliable way currently (if you don't want to do code maintanance very often) is to use the UNO based toolkit.
+
−
 
+
−
[11:43]  <PhilippL> This is going to stay for a while.
+
−
 
+
−
[11:44]  <PhilippL> Seeing that I'll have to go in about 15 minutes, are there any questions ?
+
−
 
+
−
[11:45]  <ericb2> I have some, but I'll ask you later (very specific)
+
−
 
+
−
[11:45]  <PhilippL> BTW: if you have questions, you can usually find me on #dev.openoffice.org
+
−
 
+
−
[11:45]  <ericb2> was awesome :)
+
−
 
+
−
[11:45]  * ericb2 learned a lot
+
−
 
+
−
[11:45]  <PhilippL> or you can mail me directly (address is in the presentation).
+
−
 
+
−
[11:46]  <ericb2> PhilippL: I just regret not much attendees joined the channel. I know for sure a lot of people read the log, but this is damage, to see a so
+
−
valuable developer like you with so few people asking for questions :/
+
−
 
+
−
[11:46]  <PhilippL> I mean "send a mail to me", not "mail me" of course :-)
+
−
 
+
−
[11:47]  <PhilippL> not a problem, as I said I have to go for a while anyway :-)
+
−
 
+
−
[11:48]  <PhilippL> So it seems that's it for today.
+
−
 
+
−
[11:48]  <ericb2> PhilippL: ok, then if there are no questions, I'll ask on the list. Thank you very much for your presentation:  I'd really have been glad to find it several years ago, when I started to contribute for Mac OS X port
+
−
 
+
−
[11:48] <PhilippL> Have a nice day everyone and don't hesitate to ask on #dev.openoffice.org or dev@gsl.openoffice.orf mailing list.
+

Revision as of 18:20, 28 July 2008

PhilippL Hi everybody 10:59
* lgodard (n=lgodard@gateway.nuxeo.com) has joined #education.openoffice.org 10:59
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:00
PhilippL First, what does it mean ? GSL stands for Graphics System Layer. 11:01
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 11:02
subsystems of the system OOo runs on.
* PhilippL switches to slide # 2 11:02
PhilippL The core functionality of GSL is providing OOo's toolkit functionality. 11:02
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:03
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:04
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:05
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:06
PhilippL toolkit is supposed to be a thin wrapper around vcl that binds the (changing) vcl interface to UNO based services which stay binary 11:07
compatible.
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:08
PhilippL vcl is the core of gsl, providing the main event loop, everything that produces output (Windows, virtua devices, printers,...), most 11:09
controls (Edit fields, buttons, ...)
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:10
* 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:11
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:12
* PhilippL switches to slide 5 11:13
PhilippL Then there is clipboard and drag&drop functionality. 11:13
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:14
PhilippL So this functionality was put out into an own UNO service library and has staid there since. 11:15
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 11:16
could exchange the clipboard functionality by your own version, just replacing the service.
* PhilippL switches to slide 6 11:16
PhilippL The resource compiler 11:16
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:17
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:18
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:19
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:20
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:21
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:22
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:23
PhilippL The management of these gadgets is done by vcl's independent layer. 11:24
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:25
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:26
PhilippL for those seeing the presentation: the "soft" windows are marked in red on the slide. 11:27
* PhilippL switches to slide 9 11:27
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:28
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:29
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:30
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:31
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:32
PhilippL The dialog itself is then the parent of the controls it contains. 11:33
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:34
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:35
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:36
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:37
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:38
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:39
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:40
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. 11:41
PhilippL At some point we still hope to do this transformation, though. 11:42
PhilippL Which is why vcl is sometimes considered "dead". 11:42
PhilippL In short, if you create new UI, the most reliable way currently (if you don't want to do code maintanance very often) is to use the UNO based toolkit. 11:43
PhilippL This is going to stay for a while. 11:43
PhilippL Seeing that I'll have to go in about 15 minutes, are there any questions ? 11:44
ericb2 I have some, but I'll ask you later (very specific) 11:45
PhilippL BTW: if you have questions, you can usually find me on #dev.openoffice.org 11:45
ericb2 was awesome :) 11:45
* ericb2 learned a lot 11:45
PhilippL or you can mail me directly (address is in the presentation). 11:45
ericb2 PhilippL: I just regret not much attendees joined the channel. I know for sure a lot of people read the log, but this is damage, to see a so 11:46
valuable developer like you with so few people asking for questions :/
PhilippL I mean "send a mail to me", not "mail me" of course :-) 11:46
PhilippL not a problem, as I said I have to go for a while anyway :-) 11:47
PhilippL So it seems that's it for today. 11:48
ericb2 PhilippL: ok, then if there are no questions, I'll ask on the list. Thank you very much for your presentation: I'd really have been glad to find it several years ago, when I started to contribute for Mac OS X port 11:48
PhilippL Have a nice day everyone and don't hesitate to ask on #dev.openoffice.org or dev@gsl.openoffice.orf mailing list. 11:48

Generated by irclog2html.py 2.6 by Marius Gedminas - find it at mg.pov.lt!

Retrieved from "https://wiki.openoffice.org/w/index.php?title=Education_ClassRoom/Previous_Logs/gsl&oldid=88225"
Personal tools