On Sun, 2009-08-09 at 23:25 +0100, Steve Fryatt wrote: > I've already checked out the trunk sources from SVN and -- following John's > advice on the other list -- got it to at least work without fatal errors with > Make and GCC under RISC OS. I don't think I'll have time to return to it until > next week now, but when I do, I'll probably come looking for advice on > IRC.
Ok. > In the meantime, if I have time, I'll see what I can learn from the source, > armed with the info from this thread. It occurs to me that the flow of execution within a frontend may not be obvious. A very high-level sketch looks something like: gui_init() -- initialise frontend gui_init2() -- do any last-minute initialisation (by now, everything else is guaranteed to be initialised). In the RISC OS frontend, this decides whether to open a window on startup and, if so, works out what to put in it. gui_poll() -- the main poll loop; called from netsurf_poll(), which is the core poll function. gui_quit() -- close down the frontend. All events and stuff are dispatched from within the poll function. Most things are event driven. You'll also find gui_multitask(), which is like gui_poll() except it's called from the core when it's busy doing something (like laying out a page or waiting for embedded objects to fetch). I don't think there's any circumstances where you need to care about which of gui_multitask() or gui_poll() was called. I guess the other major interactions with the core is delivering of input events (i.e. keyboard/mouse) and redraw. Input events are pretty simple: Keypress events are delivered to the relevant core function, passing the UCS4 codepoint for the keypress. Modifiers are passed, too. See ro_gui_window_keypress() for this. Mouse events are sent, passing the current button state, and the state of any modifier keys. See ro_gui_window_mouse_at() and ro_gui_window_mouse_click() for these. Redraw is fun. The core may need to redraw (part of) the contents of a window. In this case, it'll send a redraw request to the frontend by calling one of gui_window_redraw(), gui_window_redraw_window(), or gui_window_update_box(). The frontend then does whatever is necessary to make a redraw happen, and then calls content_redraw() for the contents of the window the redraw was requested for. The core will then call the current set of plotter functions to draw the relevant content. In the case of the RISC OS frontend, this means that it'll call XWimp_ForceRedraw for the relevant window, then actually perform the redraw when Wimp_Poll returns RedrawWindow. I think that's most of the major core->UI communication. There's a load of other interface API, but most of it is pretty trivial. Browser windows are the most complex part, really. J.
