doc/documentation.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
   2 <html>
   3 <head>
   4   <meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8">
   5   <title>Enlightenment Developer Documentation</title>
   6   <meta name="GENERATOR" content="OpenOffice.org 1.1.3  (Linux)">
   7   <meta name="CREATED" content="20041227;10170000">
   8   <meta name="CHANGED" content="20041227;10253900">
   9   <style>
  10         <!--
  11                 @page { size: 8.5in 11in }
  12                 TD P.western { font-size: 8pt }
  13                 TD P.cjk { font-family: "Bitstream Vera Sans"; font-size: 8pt }
  14                 P.western { font-size: 8pt }
  15                 P.cjk { font-family: "Bitstream Vera Sans"; font-size: 8pt }
  16                 A.western:link { font-size: 8pt }
  17                 A.cjk:link { font-family: "Bitstream Vera Sans"; font-size: 8pt }
  18                 A.sdfootnotesym-western { font-size: 8pt }
  19                 A.sdfootnotesym-cjk { font-family: "Bitstream Vera Sans"; font-size: 8pt }
  20                 A.sdendnotesym-western { font-size: 8pt }
  21                 A.sdendnotesym-cjk { font-family: "Bitstream Vera Sans"; font-size: 8pt }
  22         -->
  23         </style>
  24 </head>
  25 <body dir="ltr" lang="en-US">
  26 <table style="page-break-before: always;" border="0" cellpadding="0"
  27  cellspacing="0" width="100%">
  28   <col width="256*"> <tbody>
  29     <tr>
  30       <td valign="top" width="100%">
  31       <p class="western" style="margin-bottom: 0in;" align="center"><img
  32  src="enlightenment.png" name="Graphic1" align="left" border="0"
  33  height="233" width="160"><font face="Bitstream Vera Sans"><font
  34  size="5"><b>Enlightenment</b></font></font></p>
  35       <p class="western" style="margin-bottom: 0in;"><br>
  36       </p>
  37       <p class="western" style="margin-bottom: 0in;" align="center"><font
  38  style="font-size: 6pt; font-family: sans-serif;">Version
  39 0.17.0</font><big><big><big><font face="Bitstream Vera Sans"><font
  40  style="font-size: 6pt;" size="1"><big><big><big><big> </big></big></big></big></font></font>
  41       </big></big></big></p>
  42       <p class="western" style="margin-bottom: 0in;"><br>
  43       </p>
  44       <p style="font-family: sans-serif;" class="western"><font
  45  style="font-size: 8pt;"><b>What is Enlightenment?</b> </font> </p>
  46       <p style="font-family: sans-serif;" class="western"><font
  47  style="font-size: 8pt;">Enlightenment is a Window
  48 Manager for X11. This is the latest incarnation of code of the
  49 Enlightenment window manager (often referred to in short as WM). This
  50 WM is built on the EFL (Enlightenment Foundation Libraries) that have
  51 been worked on very hard over the last few years. These libraries
  52 provide a sound base on which to build the WM and related tools,
  53 utilities, and applications.</font></p>
  54       <p style="font-family: sans-serif;" class="western"><font
  55  style="font-size: 8pt;">Right now if you are just a
  56 "user" this code is NOT for you. You're on your own. If you are a
  57 developer wanting to work on the code - read on. But first we should
  58 take a break for some history... </font> </p>
  59       </td>
  60     </tr>
  61   </tbody>
  62 </table>
  63 <hr style="font-family: sans-serif;">
  64 <p style="font-family: sans-serif;" class="western"><font
  65  style="font-size: 8pt;"><b>A
  66 Brief History of Time... err Enlightenment</b></font></p>
  67 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
  68  style="font-size: 8pt;">In
  69 the past E has undergone 1 major rewrite since release DR
  70 (Development Release) 0.1. This rewrite occurred for DR 0.14). DR
  71 0.17 heralds another major rewrite. We have to be honest here. The
  72 reason for this is the fact that we got lazy. Design went out the
  73 window in favor of quick fixes and fast features. Too many people
  74 worked on the code with too little care and attention to detail.
  75 Large design mistakes were made, that to undo would be paramount to
  76 half a rewrite. Patches were accepted without taking care to look at
  77 them in detail, clean them or even reject them if not “well done”
  78 enough for E's code. Thus the decision was made to fix things once
  79 and for all and split things up, have well defined interfaces (the
  80 EFL library API's) and clean and consistent code and naming schemes.
  81 No it's not perfect - probably it will never be, but we are trying.
  82 It is a massive improvement over anything Enlightenment had before,
  83 and we are proud enough to probably say it's some of the better API's
  84 and code of any available in the world or used in any application or
  85 WM. It's not the best, but it's pretty good. In doing this rewrite
  86 and split, we aim to not make those mistakes again that happened
  87 before DR 0.17.0.</font></p>
  88 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
  89  style="font-size: 8pt;">With
  90 Enlightenment and EFL's massive break-up into smaller sized chunks,
  91 many users will complain about “how hard it is to install”
  92 because there are so many libraries and inter-dependencies to handle.
  93 We believe this is not our job, but the job of a package management
  94 system to handle. We have documented the dependencies for people to
  95 follow, but if anything, we aim to split things up more to make
  96 maintenance, in the long term, an easier task. So in an effort to
  97 avoid them, Here is a quick style and design guide for working on
  98 this code. Please follow it, and if what you want to do doesn't fit
  99 in, please discuss it first. Discuss your designs on the e-devel
 100 (enlightemment-devel@lists.sourceforge.net) mailing list. Make your
 101 code consistent and easy to follow - make it follow the style of the
 102 rest in function naming, variable naming, access functions etc. Use
 103 existing infrastructures - or extend them cleanly as needed. Just
 104 because an infrastructure or system doesn't provide an accessor or
 105 way of doing something does NOT mean you can't or couldn't add it.
 106 Choose a clean “correct” implementation over a nasty hack, all
 107 the time. You get the idea. Now, on to the style guide.</font></p>
 108 <p style="font-family: sans-serif;" class="western"><font
 109  style="font-size: 8pt;"><b>Enlightenment
 110 Stylin' straight from the top of ma dome</b></font></p>
 111 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
 112  style="font-size: 8pt;">Firstly
 113 comes naming. All functions are name spaced. The EFL libraries begin
 114 with library_something_something. It is object oriented naming so you
 115 will have system_subsystem_subsystem_object_verb() as a name. For
 116 example: e_config_load() or e_border_move() etc. All functions are
 117 all lower-case with underscores between "words". All
 118 functions that are accessed outside a file must have a prototype in
 119 the file's header. All files have their code file (e_file.c) and a
 120 header (e_file.h). The main "master" header (e.h) includes
 121 all the smaller ones. All functions within that file are the same
 122 name as the file. i.e. e_frog.c contains functions called
 123 e_frog_something(). All internal functions only used within that file
 124 should be declared as static and should begin with an underscore.
 125 i.e. _e_frog_something(). All "local" globals (global to
 126 that file only) should be declared static and beginning with _e_frog
 127 just like functions. All static local functions should be at the end
 128 of the file. All static function prototypes should be first at the
 129 top of each file. All static local variables should come next, then
 130 followed by the accessible functions. Any system that has "state"
 131 should have an init and shutdown function. The init and shutdown
 132 functions should be called from e_main.c during startup and shutdown
 133 of the WM. It is encouraged that even systems that do not have state
 134 have an init and shutdown call pair, just in case in future they will
 135 gain state internally.</font></p>
 136 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
 137  style="font-size: 8pt;">Any
 138 system that returns objects (allocated structures) should probably
 139 use the E_Object system as a parent. See examples on its use in the
 140 code. E_Object provides a simple object wrapper with reference
 141 counting, object pointer and type checking and safety that should,
 142 runtime, trap a lot of potential problems and let the programmer know
 143 about them. Use the object type checking macros for checking if an
 144 object passed into a function as a parameter is a valid object.</font></p>
 145 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
 146  style="font-size: 8pt;">Keep
 147 to the indentation and spacing style thats there - it makes it easier
 148 to read if all the code matches. All functions called as "callbacks"
 149 should be called _e_system_cb_something. The "cb" denotes
 150 that that function may get called by other code, maybe unpredictably,
 151 at any time in response to an event, timer, or something mostly out
 152 of the control of the program itself. Functions such as the free
 153 function for an object aren't the same kind of callback, since they
 154 are predictable and controllable, so they do not get "cb"
 155 in their name.</font></p>
 156 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
 157  style="font-size: 8pt;">So
 158 that's the quick rundown on basic coding style. More will likely be
 159 added to this list, but the best way to put it all is "look at
 160 what's there and follow the same style".</font></p>
 161 <p style="font-family: sans-serif;" class="western"><font
 162  style="font-size: 8pt;"><b>Tree
 163 Layout</b></font></p>
 164 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
 165  style="font-size: 8pt;">The
 166 E17 source tree is well structured, with a location for everything.
 167 In the top-level directory you will find a src directory that is the
 168 master directory for all the C source code for the WM and components.
 169 You will also find a doc and data directories. The doc directory
 170 contains all documentation (this document for example).</font></p>
 171 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
 172  style="font-size: 8pt;">The
 173 data directory contains all cross-platform data needed for the WM to
 174 run as well as a basic default theme that it also needs to run.
 175 Currently the default theme is not complete at all and is no
 176 indication of Enlightenments final look when it is released. It is
 177 only just enough to make it work and demonstrate an example of how to
 178 make a theme. There is also other data used for things like low-level
 179 error dialogs (used for example if the theme doesn't work) as well as
 180 a default font and other system data such as data for the splash
 181 screen displayed while Enlightenment starts up.</font></p>
 182 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
 183  style="font-size: 8pt;">The
 184 src directory contains 3 main repositories of code. They are bin, lib
 185 and modules. The bin directory contains all the source code for the
 186 WM itself and any primary executables it uses during execution. The
 187 modules directory contains all plug-in modules that E17 can load and
 188 unload dynamically at runtime, allowing the WM to be extended even
 189 after it has been compiled and installed by users, other developers
 190 or by the E development team itself. These modules are intended to
 191 provide clean modular boundaries for certain features of
 192 Enlightenment too, so if a feature isn't used it doesn't have to use
 193 any resources at all. Each module lives in its own subdirectory with
 194 the code and special module specific data like images, Edje .eet
 195 files etc. that are specific to that module. See further on for more
 196 information on modules.</font></p>
 197 <p style="font-family: sans-serif;" class="western"><font
 198  style="font-size: 8pt;"><b>Design
 199 Ethos</b></font></p>
 200 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
 201  style="font-size: 8pt;">As
 202 for design, Enlightenment doesn't strictly follow a conservative WM
 203 design. It does some things quite differently, with the aim of
 204 providing more features with simpler internal design to achieve more
 205 features with more solidity than a conservative design. An example of
 206 this is the fact that E17 does away completely with the root window
 207 and puts all managed windows within a virtual root. Virtual roots are
 208 valid to be used in WM's but are rarely used and many client
 209 applications are badly written to hunt for windows on the screen
 210 ASSUMING there is no virtual root. These are bugs in the respective
 211 applications (some of which are: Mozilla, xwininfo, xprop, xkill)
 212 which when searching for an application window should walk the window
 213 tree correctly. The reason for Enlightenment to adopt virtual roots
 214 is not to make users annoyed or force application developers to
 215 change their code, but to allow certain things to be done much more
 216 efficiently. A virtual root allows the WM to scroll windows
 217 seamlessly and all in sync by using window gravity and resizing of
 218 the virtual root container. It also allows the WM to simulate
 219 different resolutions very easily since it can control the virtual
 220 root window, which is not normally possible to do with the real root
 221 window.</font></p>
 222 <p style="font-family: sans-serif;" class="western"><font
 223  style="font-size: 8pt;"><b>Managers</b></font></p>
 224 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
 225  style="font-size: 8pt;">Managers
 226 are the basic unit of window management. One Manager object is
 227 created per root window to manage. For more people, even if they run
 228 Xinerama across multiple screens, there is only 1 root window, and
 229 thus E17 will only ever have 1 Manager object. If the user runs
 230 traditional Multihead there will be 1 root window per screen, that
 231 may be a different size and color depth. E17 will create 1 Manager
 232 object per screen in this situation. The Manager object handles
 233 redirection WM specific events for the root window into the WM, thus
 234 effectively being able to trap several kinds of events before a
 235 client gets to perform them, thus enabling it to be a WM. A Manager
 236 object actually creates a window the size of the root window it
 237 manages and covers the root window up completely. Each Manager object
 238 may contain 1 or more Container objects which in-turn create their
 239 own child windows of the Manager window.</font></p>
 240 <p style="font-family: sans-serif;" class="western"><font
 241  style="font-size: 8pt;"><b>Containers</b></font></p>
 242 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
 243  style="font-size: 8pt;">Container
 244 objects create their own windows to CONTAIN managed window frames,
 245 the desktop window (the desktop background is actually just a big
 246 window that is always kept below all frame windows that contains a
 247 canvas for displaying the desktop background and all desktop objects
 248 such as a launcher bar, file icons, etc. etc.). The Container is
 249 responsible for holding this together and also managing a list of
 250 “obscuring” objects that fully obscure the desktop canvas, so it
 251 can help optimize drawing to the desktop canvas by avoiding to draw
 252 parts of the desktop background canvas that cannot be seen at all.
 253 This list is also used to draw soft drop shadows on the desktop
 254 canvas by the Dropshadow module. The Container object managed the
 255 desktop background, which is actually a complete EDJE object. This
 256 may seem strange as a simple JPEG or PNG or GIF may be enough, but by
 257 using an EDJE object for the background, the desktop wallpaper can be
 258 animated, react to events and input, scale intelligently (not just
 259 “stretch” or “tile”), where the desktop wallpaper designer
 260 can specify what elements of the wallpaper scale, align, where and
 261 how, if they tile, overlay, underlay each other, and how.</font></p>
 262 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
 263  style="font-size: 8pt;">Currently
 264 the Container only responds to configuration change events to change
 265 the background, which needs to be a path to an Edje .eet file that
 266 contains a Edje group of the key “desktop/background”. It will
 267 load this group, if present in the file, as the background. What it
 268 needs is a configuration tool that can browse the filing system and
 269 directories for .eet files that are like this, display thumbnails and
 270 previews, allow a user to select a new background and maybe specify
 271 if the background file should change between different virtual
 272 desktops (which are currently not implemented), and also be able to
 273 browse normal JPEG, PNG etc. files and “import” them into a users
 274 wallpaper database (a directory of wallpaper .eet files) and thus
 275 convert into a Edje .eet file, which now retains the scaling, tiling
 276 and other preferences the user selected within the file. The user can
 277 now give this file to others and it will retain the same information,
 278 without them needing to know if the wallpaper needs to tile as a
 279 pattern, stretch etc.</font></p>
 280 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
 281  style="font-size: 8pt;">The
 282 desktop canvas is also shared by many modules that may display things
 283 like battery meters, cpu load, launcher bars, drop shadows etc. on
 284 the desktop background. The desktop canvas lets this be a bit more
 285 organized than it would be with a “free for all” drawing to the
 286 root window under more conservative WM's.</font></p>
 287 <p style="font-family: sans-serif;" class="western"><font
 288  style="font-size: 8pt;"><b>Borders</b></font></p>
 289 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
 290  style="font-size: 8pt;">Borders
 291 are the frame outside an application window that is controlled by the
 292 WM and that holds the application window within, and allows users to
 293 move, resize, shade, lower, close and otherwise control windows. This
 294 is currently buggy and not very useful and needs work in combination
 295 with the Manager system.</font></p>
 296 <p style="font-family: sans-serif;" class="western"><font
 297  style="font-size: 8pt;"><b>Menus</b></font></p>
 298 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
 299  style="font-size: 8pt;">Enlightenment
 300 has its own Menu widget code to allow for highly themable menus that
 301 match your WM's theme. These menus are intended to act as ways to
 302 launch programs, select actions to perform with context sensitive
 303 menus and to provide basic on/off and option select options for
 304 simple enabling and disabling of features of states on objects. The
 305 menu code is fairly solid, but incomplete. It is efficient, able to
 306 let the user navigate with the keyboard, mouse wheel or mouse. It
 307 currently needs work to support shaped menu windows, be able to add,
 308 delete and modify menu items while the item is still realized, and a
 309 set of other things listed in the TODO list at the top of the
 310 e_menu.c source file.</font></p>
 311 <p style="font-family: sans-serif;" class="western"><font
 312  style="font-size: 8pt;"><b>Modules</b></font></p>
 313 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
 314  style="font-size: 8pt;">Modules
 315 are a new and powerful way to extend E17 by being able to load and
 316 execute code during runtime that may be shipped with E17 or even
 317 developed after installation as enhancements and additions. This
 318 system still needs work in the configuration department, knowing what
 319 modules to load and not load, if they are to be enabled once they are
 320 loaded etc. It is possible to have “dormant” modules that are
 321 loaded but not enabled. They will use memory and resources for the
 322 module entry and the binary executable code loaded into memory, but
 323 nothing else. An enabled module will also use resources for objects,
 324 images, etc. etc.</font></p>
 325 <p style="font-family: sans-serif;" class="western"><font
 326  style="font-size: 8pt;"><b>Dropshadow
 327 Module</b></font></p>
 328 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
 329  style="font-size: 8pt;">This
 330 module demonstrates the Container shape system allowing a module to
 331 monitor obscuring shapes in a container. This lets the module, in
 332 this case, draw soft shadows under these obscuring shapes. It is a
 333 fairly simple module and also demonstrates a module that has no
 334 visible elements on the screen you can click on or control directly
 335 with the mouse or keyboard. It could do with some optimization work
 336 with the blur algorithm, like clipping out the obscuring shape
 337 entirely from the blurring algorithm, and perhaps finding a way of
 338 blurring using a Gaussian blur that is faster.</font></p>
 339 <p style="font-family: sans-serif;" class="western"><font
 340  style="font-size: 8pt;"><b>IBar
 341 Module</b></font></p>
 342 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
 343  style="font-size: 8pt;">The
 344 IBar module is a template for doing a “launcher panel” in E17. It
 345 allows the user to manage a list of frequently used applications to
 346 go into the IBar's panel. It is an attempt to unify the configuration
 347 of “bars” in E17 so if a user changes launcher bar modules, they
 348 can retain at least most of the basic configuration, like what
 349 applications are in the bar, and so-on. The IBar has some unique
 350 characteristics allowing a lot of applications to be held in a small
 351 bar, by having it auto-scroll on mouse over to the desired location
 352 in the list. It uses the Application interface to fetch a list of
 353 applications and monitor this list for changes on disk. The IBar also
 354 allows itself to be resized and dragged around the edges of the
 355 screen, set to fill a edge, auto-size to fit its contents, or be a
 356 fixed size.</font></p>
 357 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
 358  style="font-size: 8pt;">It
 359 needs work to be done on auto hide and auto show, so on an auto show
 360 it could signal other parts of E17, for example, to slide all windows
 361 out of the way, or other such features. It needs work to display
 362 application names, descriptions and other such information as well.
 363 It also needs to support the icon size changing on the fly as well as
 364 saving and loading its configuration, On of the largest pieces of
 365 work is to support subdirectories in the bar's application list. How
 366 best to do this is still up in the air. For now this isn't supported.</font></p>
 367 <p style="font-family: sans-serif;" class="western"><font
 368  style="font-size: 8pt;"><b>Test
 369 Module</b></font></p>
 370 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
 371  style="font-size: 8pt;">This
 372 is just a test module for playing with new module features. It will
 373 not make its way into a final E17 release, but can be used as a bare
 374 skeleton for building a new module.</font></p>
 375 <p style="font-family: sans-serif;" class="western"><font
 376  style="font-size: 8pt;"><b>Applications</b></font></p>
 377 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
 378  style="font-size: 8pt;">This
 379 subsystem is responsible for being able to list applications held in
 380 E17 specific application directories. This system can inform other
 381 parts of E17 and modules of changes, such as an application being
 382 deleted or added, its name or icon changed, the order of applications
 383 in a directory changing, an application being executed or displaying
 384 its window, or finishing execution. It can share the application
 385 lists between multiple systems to save RAM and CPU and I/O in loading
 386 them multiple times.</font></p>
 387 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
 388  style="font-size: 8pt;">It
 389 may be of surprise to find E17 is not loading the XML, .desktop
 390 entries etc. etc. than KDE and GNOME use. In all honesty that system
 391 is a little overcomplicated and hard to keep up with. It also is not
 392 as robust as E17's system. With E17's system the images for the icons
 393 are within the application file. They cannot be separately deleted.
 394 Also using an Edje .eet file for the application entry allows for
 395 fully scalable and animated icons as well, with excellent compression
 396 abilities. The intent is to have external tools that can import and
 397 create such files FROM existing system databases of applications and
 398 monitor these for changes, reflecting those changes in Enlightenments
 399 application directories.</font></p>
 400 <p style="font-family: sans-serif;" class="western"><font
 401  style="font-size: 8pt;"><b>IPC</b></font></p>
 402 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
 403  style="font-size: 8pt;">IPC
 404 (inter process communication) is provided in E17 as a mechanism for
 405 another application to send commands and requests to Enlightenment
 406 and receive responses with information. This mechanism is intended to
 407 allow external utilities to be written and ask Enlightenment to do
 408 things via a communications channel built into the WM. E17 uses the
 409 Ecore IPC system to do this. So far it support no commands at all,
 410 but will accept clients connecting. Many commands need to be
 411 implemented here, such as being able to ask E17 to load or unload a
 412 module, change background, change focus mode, theme, restart etc.</font></p>
 413 <p style="font-family: sans-serif;" class="western"><font
 414  style="font-size: 8pt;"><b>Objects</b></font></p>
 415 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
 416  style="font-size: 8pt;">This
 417 provides a basic Object Oriented handling system for E17. Any major
 418 “object” in E17 should use this system for handling reference
 419 counting, destruction and creation of objects, as it provides safety
 420 mechanisms to check if an object has accidentally been destroyed and
 421 still has a pointer to it, keep references on objects intact etc.
 422 This should be used as much as possible, as well as the macros it
 423 provides for checking on entry points into subsystem functions etc.</font></p>
 424 <p style="font-family: sans-serif;" class="western"><font
 425  style="font-size: 8pt;"><b>Pointers</b></font></p>
 426 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
 427  style="font-size: 8pt;">This
 428 subsystem handles setting of X mouse cursors in an abstract fashion.
 429 In theory E just looks at a cursor as RGBA pixel data. In future
 430 Ecore will be expanded to be able to set full color cursors in X as
 431 well as monochrome versions of them. Currently it is very simplistic
 432 loading a fixed PNG as a cursor. This needs to be improved.</font></p>
 433 <p style="font-family: sans-serif;" class="western"><font
 434  style="font-size: 8pt;"><b>Box</b></font></p>
 435 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
 436  style="font-size: 8pt;">This
 437 is a basic Evas Smart Object that acts as a horizontal or vertical
 438 box layout container. It needs more features for layout, like better
 439 non homogeneous layout. This is a handy object that is sued by menus
 440 and the IBar module for starters.</font></p>
 441 <p style="font-family: sans-serif;" class="western"><font
 442  style="font-size: 8pt;"><b>Icons</b></font></p>
 443 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
 444  style="font-size: 8pt;">This
 445 is an Evas Smart Object that creates a icon display object That
 446 handles scaling the icon sensibly within the object bounds, so the
 447 application doesn't have to handle trying to retain aspect ratio for
 448 the object. This is a simple smart object and indicative of possibly
 449 more in future to go into E17's code to save time and effort.</font></p>
 450 <p style="font-family: sans-serif;" class="western"><font
 451  style="font-size: 8pt;"><b>Paths</b></font></p>
 452 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
 453  style="font-size: 8pt;">This
 454 helps E17 find files in a list of paths/directories. There isn't a
 455 lot to say about this except that it works and may need some minimal
 456 expansion in future.</font></p>
 457 <p style="font-family: sans-serif;" class="western"><font
 458  style="font-size: 8pt;"><b>User
 459 Information</b></font></p>
 460 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
 461  style="font-size: 8pt;">This
 462 returns information about a user such as their home directory. This
 463 will expand in future.</font></p>
 464 <p style="font-family: sans-serif;" class="western"><font
 465  style="font-size: 8pt;"><b>Virtual
 466 and Multiple Desktops</b></font></p>
 467 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
 468  style="font-size: 8pt;">This
 469 is not implemented yet.</font></p>
 470 <p style="font-family: sans-serif;" class="western"><font
 471  style="font-size: 8pt;"><b>Error
 472 Dialogs</b></font></p>
 473 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
 474  style="font-size: 8pt;">This
 475 displays very basic error dialogs right now, either as text in the
 476 console if E17 isn't ready to run graphically yet, or as text in a
 477 graphical dialog box. This needs to be made more robust, so it can
 478 display errors if it cannot find the font and images for the basic
 479 error dialog. It should also be expanded to support fully themed
 480 dialogs if the theme loads properly and properly supports theming of
 481 dialogs, so dialogs look good.</font></p>
 482 <p style="font-family: sans-serif;" class="western"><font
 483  style="font-size: 8pt;"><b>Initialization
 484 Splash Screen</b></font></p>
 485 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
 486  style="font-size: 8pt;">This
 487 keeps the user amused while E17 starts up and launches all programs.
 488 For now it is artificially fixed to stay up for 4 seconds so you can
 489 enjoy its radiant splendor, as E17 starts so quickly you'd never see
 490 it, but in future it will stay up until the WM is all ready to go.</font></p>
 491 <p style="font-family: sans-serif;" class="western"><font
 492  style="font-size: 8pt;"><b>Configuration</b></font></p>
 493 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
 494  style="font-size: 8pt;">Loading
 495 and saving configuration is a big task. E17 uses EET directly as its
 496 underlying layer for saving and loading configuration. The E17 Config
 497 system simply loads all the initial configuration values, and saves
 498 them when and if they change internally. It needs work to make it
 499 much simpler as many more config values will be added and it needs to
 500 be more efficient and loading them if they change runtime via a
 501 listener (the number of listeners needs to be reduced), so maybe
 502 loading config values in sections/groups and deferring a reload in a
 503 Ecore Job would limit the reloading effects. Also declaring config
 504 values and how to load and declare them is required. Maybe a big
 505 table with default values, min, max, step, descriptions etc.</font></p>
 506 <p style="font-family: sans-serif;" class="western"><font
 507  style="font-size: 8pt;"><b>File
 508 Operations</b></font></p>
 509 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
 510  style="font-size: 8pt;">Files
 511 need to be accessed, listed, found, examined as part of E17 running.
 512 This file has simplified, easy-to-use functions for doing anything
 513 related to files. This file will expand over time as more file
 514 operations are needed.</font></p>
 515 <p style="font-family: sans-serif;" class="western"><font
 516  style="font-size: 8pt;"><b>Miscellaneous
 517 Utilities</b></font></p>
 518 <p class="western" style="margin-left: 0.79in; font-family: sans-serif;"><font
 519  style="font-size: 8pt;">Things
 520 that are useful in many places but do not have enough scope to have a
 521 file of their own go into this file.</font></p>
 522 </body>
 523 </html>