Fltk S60 Introduction

450 views

Published on

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
450
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Fltk S60 Introduction

  1. 1. FLTK/S60 Port Introduction Version Author Comments v0.0.1 (Draft) Sadysta Initial version. Symbian Introduction Symbian Essentials Symbian is an operating system designed for mobile devices, written in pure C++ with only some minor very low-level fragments written in assembly language. Symbian is 100% object- oriented and features the following highlights: preemptive multitasking • memory protection • platform security (per-application capabilities system) • real-time kernel (permitting execution of both signaling stack and user applications on a • single core) resources conservation encouragement (e.g. one can't push arbitrary amount of data through • a socket (forcing allocation of kernel-side buffers), rather portions of data must be sent in response to previous Send() completion events) Multitasking in Symbian is based on asynchronous events generated by plethora of servers responsible for providing diverse sets of functionalities. The core concepts concerning handling those events are active objects and active schedulers. In a typical Symbian application every thread has an active scheduler assigned to it and the scheduler is responsible for time-slicing thread activity between different asynchronous events handlers. In other words there are usually two schedulers involved in running an user application – kernel-side preemptive scheduler responsible for alloting CPU time to specific thread and an user- side scheduler responsible for dividing the alloted time between different asynchronous events handlers. Thanks to Symbian design kernel-side scheduler is aware of every user-side scheduler and in case the latter has no tasks to service (i.e. no asynchronous events took place) the former doesn't allot time to the thread owning the user-side scheduler. Example class Timeout: public CActive { public: Timeout() { iTimer.CreateLocal(); }
  2. 2. ~Timeout() { iTimer.Close(); } void Start() { iTimer.After(iStatus, 1000000); // CActiveObject::iStatus SetActive(); /* Mark this active object as active to let active scheduler know that it is waiting for a request to complete */ } void RunL() { // iStatus containts result of last timer request if (iStatus != KErrNone) { // Handle error } // Handle event } void DoCancel() { iTimer.Cancel(); } private: RTimer iTimer; }; TInt E32Main() { CActiveScheduler::Install(new CActiveScheduler()); /* Install an active scheduler for this thread */ Timeout timeout; CActiveScheduler::Add(&timeout); /* Insert an active object into the active scheduler */ timeout.Start(); // Execute an asynchronous request CActiveScheduler::Start(); /* Run the active scheduler. It will trigger timeout.RunL() once after 1s elapses (i.e. timer request is completed) and then keep idling (the thread won't be scheduled for execution as well). */ return 0; // We never get here... } Most OS functionality is provided using this mechanism, including keyboard, pointer and windowing system events.
  3. 3. S60 Essentials S60 (Series 60) is a software platform running on Symbian OS. It is owned by Nokia and licensed to various other smartphone vendors. FLTK/S60 port is using only core Symbian servers at this point of time (namely WSERV and FBSERV) and doesn't require S60 (i.e. it could probably be recompiled for UIQ without any source code modifications). However S60 integration will be necessary in the future because of various issues arising with current low-level approach (see Known Bugs section below). Known Bugs Task-switching to FLTK/S60 applications takes a long time in certain cases (A timeout of • sorts seems to be present, but I have no idea what the S60 task switcher is waiting for, some S60-specific signal I guess). On-screen keyboard support is missing. This requires implementation of FEP (Front-End • Processors) aware text controls or (more likely) extending existing FLTK text controls with FEP-awareness. I'm not sure if fonts implementation is entirely correct because I seem to be able to use only • one font face. FLTK/S60 Core Architecture Global Variables FLTK/S60 port makes use of certain number of global variables, many of which are static members of Fl_X class listed below: static int WsSessionReady; static RWsSession WsSession; static CWsScreenDevice *WsScreenDevice; static RWindowGroup *WindowGroup; static CBitmapContext *WindowGc; static RTimer Timer; static CTrapCleanup *TrapCleanup; static RWsPointerCursor *WsPointerCursor; static CFont *Font; static RFs Fs; static RFbsSession FbsSession; static CBitmapContext *SavedGc; static CFbsBitGc *BitmapGc; static CRedrawEventActive *RedrawEventActive; static CWsEventActive *WsEventActive; static CWaitTimeoutActive *WaitTimeoutActive; Of particular importance are instances of RWsSession, CWsScreenDevice, RWindowGroup, CBitmapContext, RTimer, CTrapCleanup, RWsPointerCursor, CFont, RFs, RFbsSession, CFbsBitGc, CRedrawEventActive, CWsEventActive and CWaitTimeoutActive. Wow.... that means
  4. 4. all of them ;) I'd like to discuss them in more detail below. Main Loop One of the most important functions in FLTK/S60 port is int fl_wait(double timeout) which is responsible for waiting till an event happens or a specified timeout is reached. Currently three active objects are involved in this behavior, namely CRedrawEventActive, CWsEventActive and CWaitTimeoutActive. Additionaly as S60 doesn't support select() on multiple sockets, a select() replacement called fl_select_s60() is used to poll sockets for events. This replacement requires additional thread to be running, which (as select() on multiple sockets is unavailable) runs select() on every socket in turn with 1ms intervals. This obviously introduces certain latency and thus it is a far from perfect way of implementing multi-socket select(). Probably some smart-ass RSocket- based implementation of Berkeley sockets API should be created.

×