Education ClassRoom/Previous Logs/framework part1

From Apache OpenOffice Wiki
Jump to: navigation, search
ericb2 mba_: why not present the begining today. Say a 30 min max presentation ? 11:28
mba_ I can do that. I will give a brief overview of what I could talk about. 11:29
ericb2 mba_: thank you :) 11:29
mba_ So, let's start. 11:29
FelixZ mba_: Thanks 11:29
mba_ First of all, the Framework module is very privileged - because it is largely documented in our DevGuide. 11:30
mba_ If you look on the coarse diagram in our wiki ( ) you can see what the Framework basically is 11:31
meant to do
mba_ It cares for the general managing of documents, task windows, the (high level) file handling, and more. 11:32
mba_ An important part of the Framework also is Embedding. But as I consider this to be "advanced", I will not go into details there. 11:32
mba_ If you are a macro developer or anybody else using OOo API you ususally will start with Framework API calls before you can do anything further. 11:33
mba_ Quite often this is the XDesktop::loadComponentFromURL method 11:33
mba_ This method belongs to an interface css.frame.XDesktop that not surprisingly is implemented by a service css.frame.Desktop, but also by all "frame" services (currently there is only one css.frame.Frame service but we always thought there could be more in the future). 11:35
mba_ The Desktop object does a lot more that I don't want to touch now, for a first reference I recommend to study the DevGuide ( 11:36
* mod_ ( has joined 11:38
mba_ loadComponentFromURL is expected to return a Component. The only interface that is mandatory for a compoent is the css.lang.XComponent interface that allows to control the components' life time. 11:38
mba_ BTW: I typed too fast - of course loadComponentFromURL belongs to css.frame.XComponentLoader. 11:39
mba_ What are these "components" in reality? 11:40
mba_ Or more exactly: what kinds of components can be loaded that way, usually into a frame? 11:40
mba_ Our idea was that these component could be "documents" (models) on the one extreme or simply windows on the other. 11:41
mba_ There is a third option that a simple view/controller pair without any model could be loaded into a frame and so the returned component might be a "Controller" object also. 11:42
mba_ Without going into the details too much here, the Desktop object and all the Frame objects form a hierarchy of frames that make up what we call the "Desktop Environment" that is described in the DevGuide also ( ). 11:43
mba_ All other parts of the Framework are implemented as additional services that are used inside the Desktop and Frame services. 11:45
mba_ There are several parts worth mentioning, the most important ones IMHO are the type detection and LoadEnvironment, the Dispatch Framework and the LayoutManager. 11:47
mba_ I don't want to talk about the TypeDetection and LoadEnvironment today as IMHO this is code isn't much interesting for new developers. It is quite "done" yet and it contains a lot of knowledge and "tricks" collected over the years. 11:49
mba_ The more interesting parts are the Dispatching and Layouting services as they usually offer a lot of opportunities to modify or extend them. 11:50
mba_ Understanding the Dispatch Framework ( ) is the key to understanding how the OOo UI can be extended or customized. 11:51
mba_ The idea we implemented here is that the UI of each loaded Component does not directly communicate with the outside world and that the UI of the outside world does not directly communicate with the component. 11:52
mba_ Every communication is routed through the frame. "Communication" means sending commands or exchanging status information for UI elements. 11:54
mba_ As the frame is the central part here every extension or customization can be applied at the frame - no need to plan for interactions with several, even yet-unknown components. 11:55
mba_ Examples for such things are that a simple communication file can be used to disable commands globally and - more important - the possibility to intercept command dispatching by registering DispatchInterceptors at the frame. 11:56
mba_ The Dispatch Framework is based on the idea that a command can be executed only if a Dispatch object can be found for it. So a UI element (e.g. a toolbar button) queries for such an object by asking the frame it is assigned to (how this assignment is done will be explained later). 11:58
* mod_ ( has left 11:58
mba_ The frame now can either handle the command itself (because it knows it and does not want to allow others to handle it or because this command is disabled by configuration), pass it to its component if it also imlements Dispatching) or scans the configuration whether there is another DispatchProvider object that can handle the command. 12:00
mba_ The last option is the base for the whole Extension infrastructure. 12:00
mba_ An extension usually registers DispatchProvider services for a group of Commands that start with the same prefix called "protocol" (thus these services are called ProtocolHandlers). So a Frame is able to dispatch commands to them and OTOH receive status information from them. 12:02
mba_ So it is understandable that UI elements or any code that wants to execute commands must be assigned to a frame. This assignment is done by passing the frame that carries the targetted component, either by a direct API call of as an initialization parameter. 12:03
mba_ For UI elements like toolbar buttons this happens inside the LayoutManager. 12:03
mba_ The LayoutManager (I will talk about it later) is always directly attached to a frame. Or the other way around: each frame has one. 12:04
mba_ The purpose of the LayoutManager is to organize panels, toolbars, docked windows etc. and resize the internal document window properly. It also uses some internal services to create UI elements like toolbars or the menu. 12:05
mba_ It is important to see that UI elements are very abstract on the LayoutManager level, they are just UNO servives with a small API. This e.g. enables the Framework to work with Windows and Mac menubars without changing a lot of code. 12:06
mba_ Everytime when UI elements are created, the Frame of the LayoutManager is passed to them so that UI elements know where to send command requests to or where to get status updates from. In fact usually the Frame is everything they know. 12:07
mba_ The Layout Manager itself and how it creates the OOo user interface is described at 12:08
mba_ So this is a very coarse overview of the main parts of the Framework. What do you think: should we start with going into details now, should we already ask and answer questions or should be give people a chance to read the log and the documentation I pointed to and the proceed in another session? 12:11
ericb2 mba_: is everything you explained located in framework (the module in source tree ) ? 12:12
ericb2 mba_: or are there other parts elsewhere ? 12:12
mba_ Yes - except parts of the TypeDetection 12:12
ericb2 mba_: thank you 12:12
mba_ The TypeDetection uses the FilterConfiguration that is part of the "Filter" module 12:12
ericb2 mba_: noticed :) 12:13
ericb2 mba_: from my side, what I learned is enough (a lot to read until the next part) 12:13
ericb2 mba_: what you explained is incredibly precise, and very usefull for the understanding of I must admit it was a dark side for me 12:14
* SaSaintete ( has joined 12:15
FelixZ mba_: Is dispatching currently located in framework module too? 12:15
mba_ FelixZ: yes and no. 12:15
ericb2 mba_: well, I still have to read and learn, else I won't progress :) 12:16
FelixZ mba_: I find /sfx2/source/control/dispatch.cxx, that's why I'm a little confused 12:16
mba_ Of course commands handled by the frame, the infrastructure for Interceptors and ProtocolHandlers and the DisableCommands handling are implemented in the Framework module 12:16
mba_ But as I said, the components inside the frame also may implement dispatching and they usually do 12:17
mba_ Most of our components are documents based on the sfx2 12:17
mba_ sfx2 is our old framework and in former times also contained a desktop, frames etc. but in a very highly-coupled, non-modular implementation 12:17
mba_ So we decided to reimplement our framework based solely on UNO interfaces and services 12:18
mba_ The sfx today "only" is the backbone of the dispatching implementation of the Controller objects of our documents. 12:18
mba_ You can read more about that at 12:19
mba_ But this is very advanced stuff and I don't recommend to read that before having a solid understanding of the general dispatching 12:19
FelixZ mba_: Thank you for your answer :) 12:20
mba_ FelixZ: if you are interested in Dispatching, the DevGuide chapter linked above is highly recommened. 12:24
FelixZ mba_: I'll read that carefully, thanks 12:24
mba_ I have some additional pictures in some of my OOoCon presentations and I will see if I can upload them to the Dev Guide. I really like that it is online now. :-) 12:24
mba_ FelixZ, YanWu: in case you don't have any immediate questions I think we can close for today. Eric will spread the news about our today's meeting and will invite for another session for people that read the documentation I have pointed to and have questions about it. 12:30
FelixZ mba_: No questions from me today, thank you very much :) 12:31
mba_ OK, see you next time - bye! 12:32
FelixZ mba_: See you next time, have a nice day :) 12:33
mba_ And a nice leisure-time for you now! :-) 12:33
* mba_ has quit ("ChatZilla [Firefox]") 12:35
FelixZ ericb2: Thank you for hosting this, it's time to grab some food for me and YanWu, see you :) 12:37
ericb2 FelixZ: you're welcome :) 13:05
ericb2 FYI, the partial log of the ClassRoom is there : 13:05

Generated by 2.6 by Marius Gedminas - find it at!

Personal tools