starting a battery module (in need this for my laptop)
SVN revision: 12599
|
@ -180,10 +180,11 @@ src/bin/Makefile
|
|||
src/modules/Makefile
|
||||
src/modules/test/Makefile
|
||||
src/modules/ibar/Makefile
|
||||
src/modules/dropshadow/Makefile
|
||||
src/modules/clock/Makefile
|
||||
src/modules/flame/Makefile
|
||||
src/modules/snow/Makefile
|
||||
src/modules/dropshadow/Makefile
|
||||
src/modules/battery/Makefile
|
||||
data/Makefile
|
||||
data/fonts/Makefile
|
||||
data/images/Makefile
|
||||
|
|
|
@ -256,6 +256,18 @@ images {
|
|||
image: "e17_clock_minutes_57.png" COMP;
|
||||
image: "e17_clock_minutes_58.png" COMP;
|
||||
image: "e17_clock_minutes_59.png" COMP;
|
||||
|
||||
image: "e17_battery_000.png" COMP;
|
||||
image: "e17_battery_010.png" COMP;
|
||||
image: "e17_battery_020.png" COMP;
|
||||
image: "e17_battery_030.png" COMP;
|
||||
image: "e17_battery_040.png" COMP;
|
||||
image: "e17_battery_050.png" COMP;
|
||||
image: "e17_battery_060.png" COMP;
|
||||
image: "e17_battery_070.png" COMP;
|
||||
image: "e17_battery_080.png" COMP;
|
||||
image: "e17_battery_090.png" COMP;
|
||||
image: "e17_battery_100.png" COMP;
|
||||
}
|
||||
|
||||
collections {
|
||||
|
@ -5189,4 +5201,123 @@ collections {
|
|||
}
|
||||
}
|
||||
}
|
||||
group {
|
||||
name: "modules/battery/main";
|
||||
max: 128 128;
|
||||
parts {
|
||||
part {
|
||||
name: "battery";
|
||||
description {
|
||||
state: "default" 0.0;
|
||||
aspect: 0.669291339 0.669291339;
|
||||
align: 0.0 0.5;
|
||||
max: 85 127;
|
||||
rel1 {
|
||||
relative: 0.0 0.0;
|
||||
}
|
||||
rel2 {
|
||||
relative: 1.0 1.0;
|
||||
}
|
||||
image {
|
||||
normal: "e17_battery_000.png";
|
||||
}
|
||||
}
|
||||
description {
|
||||
state: "default" 0.1;
|
||||
inherit: "default" 0.0;
|
||||
image {
|
||||
normal: "e17_battery_010.png";
|
||||
}
|
||||
}
|
||||
description {
|
||||
state: "default" 0.2;
|
||||
inherit: "default" 0.0;
|
||||
image {
|
||||
normal: "e17_battery_020.png";
|
||||
}
|
||||
}
|
||||
description {
|
||||
state: "default" 0.3;
|
||||
inherit: "default" 0.0;
|
||||
image {
|
||||
normal: "e17_battery_030.png";
|
||||
}
|
||||
}
|
||||
description {
|
||||
state: "default" 0.4;
|
||||
inherit: "default" 0.0;
|
||||
image {
|
||||
normal: "e17_battery_040.png";
|
||||
}
|
||||
}
|
||||
description {
|
||||
state: "default" 0.5;
|
||||
inherit: "default" 0.0;
|
||||
image {
|
||||
normal: "e17_battery_050.png";
|
||||
}
|
||||
}
|
||||
description {
|
||||
state: "default" 0.6;
|
||||
inherit: "default" 0.0;
|
||||
image {
|
||||
normal: "e17_battery_060.png";
|
||||
}
|
||||
}
|
||||
description {
|
||||
state: "default" 0.7;
|
||||
inherit: "default" 0.0;
|
||||
image {
|
||||
normal: "e17_battery_070.png";
|
||||
}
|
||||
}
|
||||
description {
|
||||
state: "default" 0.8;
|
||||
inherit: "default" 0.0;
|
||||
image {
|
||||
normal: "e17_battery_080.png";
|
||||
}
|
||||
}
|
||||
description {
|
||||
state: "default" 0.9;
|
||||
inherit: "default" 0.0;
|
||||
image {
|
||||
normal: "e17_battery_090.png";
|
||||
}
|
||||
}
|
||||
description {
|
||||
state: "default" 1.0;
|
||||
inherit: "default" 0.0;
|
||||
image {
|
||||
normal: "e17_battery_100.png";
|
||||
}
|
||||
}
|
||||
}
|
||||
part {
|
||||
name: "reading";
|
||||
type: TEXT;
|
||||
effect: SOFT_SHADOW;
|
||||
description {
|
||||
state: "default" 0.0;
|
||||
align: 1.0 0.0;
|
||||
rel1 {
|
||||
relative: 1.0 0.0;
|
||||
to_x: "battery";
|
||||
}
|
||||
rel2 {
|
||||
relative: 1.0 1.0;
|
||||
}
|
||||
color: 255 255 255 255;
|
||||
color3: 0 0 0 32;
|
||||
text {
|
||||
text: "100%";
|
||||
font: "Edje Vera";
|
||||
size: 7;
|
||||
min: 1 1;
|
||||
align: 0.0 0.0;
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
@ -231,4 +231,15 @@ e17_clock_seconds_55.png \
|
|||
e17_clock_seconds_56.png \
|
||||
e17_clock_seconds_57.png \
|
||||
e17_clock_seconds_58.png \
|
||||
e17_clock_seconds_59.png
|
||||
e17_clock_seconds_59.png \
|
||||
e17_battery_000.png \
|
||||
e17_battery_010.png \
|
||||
e17_battery_020.png \
|
||||
e17_battery_030.png \
|
||||
e17_battery_040.png \
|
||||
e17_battery_050.png \
|
||||
e17_battery_060.png \
|
||||
e17_battery_070.png \
|
||||
e17_battery_080.png \
|
||||
e17_battery_090.png \
|
||||
e17_battery_100.png
|
||||
|
|
After Width: | Height: | Size: 9.6 KiB |
After Width: | Height: | Size: 9.4 KiB |
After Width: | Height: | Size: 9.2 KiB |
After Width: | Height: | Size: 9.1 KiB |
After Width: | Height: | Size: 9.1 KiB |
After Width: | Height: | Size: 8.9 KiB |
After Width: | Height: | Size: 8.9 KiB |
After Width: | Height: | Size: 8.9 KiB |
After Width: | Height: | Size: 8.9 KiB |
After Width: | Height: | Size: 8.8 KiB |
After Width: | Height: | Size: 8.7 KiB |
|
@ -1,10 +1,16 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
|
||||
<TITLE>Enlightenment Developer Documentation</TITLE>
|
||||
<META NAME="GENERATOR" CONTENT="OpenOffice.org 1.1.3 (Linux)">
|
||||
<META NAME="CREATED" CONTENT="20041227;10170000">
|
||||
<META NAME="CHANGED" CONTENT="20041227;10253900">
|
||||
<STYLE>
|
||||
<!--
|
||||
@page { size: 51pc 66pc }
|
||||
@page { size: 8.5in 11in }
|
||||
TD P.western { font-size: 8pt }
|
||||
TD P.cjk { font-family: "Bitstream Vera Sans"; font-size: 8pt }
|
||||
P.western { font-size: 8pt }
|
||||
P.cjk { font-family: "Bitstream Vera Sans"; font-size: 8pt }
|
||||
A.western:link { font-size: 8pt }
|
||||
|
@ -21,13 +27,13 @@
|
|||
<COL WIDTH=256*>
|
||||
<TR>
|
||||
<TD WIDTH=100% VALIGN=TOP>
|
||||
<P CLASS="western" ALIGN=CENTER STYLE="margin-bottom: 0pc"><IMG SRC="enlightenment.png" NAME="Graphic1" ALIGN=LEFT WIDTH=320 HEIGHT=320 BORDER=0><FONT FACE="Bitstream Vera Sans"><FONT SIZE=5><B>Enlightenment</B></FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-bottom: 0pc"><BR>
|
||||
<P CLASS="western" ALIGN=CENTER STYLE="margin-bottom: 0in"><IMG SRC="enlightenment.png" NAME="Graphic1" ALIGN=LEFT WIDTH=320 HEIGHT=320 BORDER=0><FONT FACE="Bitstream Vera Sans"><FONT SIZE=5><B>Enlightenment</B></FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-bottom: 0in"><BR>
|
||||
</P>
|
||||
<P CLASS="western" ALIGN=CENTER STYLE="margin-bottom: 0pc"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 6pt">Version
|
||||
<P CLASS="western" ALIGN=CENTER STYLE="margin-bottom: 0in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 6pt">Version
|
||||
0.17.0 </FONT></FONT>
|
||||
</P>
|
||||
<P CLASS="western" STYLE="margin-bottom: 0pc"><BR>
|
||||
<P CLASS="western" STYLE="margin-bottom: 0in"><BR>
|
||||
</P>
|
||||
<P CLASS="western"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt"><B>What
|
||||
is Enlightenment?</B> </FONT></FONT>
|
||||
|
@ -51,7 +57,7 @@
|
|||
<HR>
|
||||
<P CLASS="western"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt"><B>A
|
||||
Brief History of Time... err Enlightenment</B></FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">In
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">In
|
||||
the past E has undergone 1 major rewrite since release DR
|
||||
(Development Release) 0.1. This rewrite occurred for DR 0.14). DR
|
||||
0.17 heralds another major rewrite. We have to be honest here. The
|
||||
|
@ -60,20 +66,20 @@ window in favor of quick fixes and fast features. Too many people
|
|||
worked on the code with too little care and attention to detail.
|
||||
Large design mistakes were made, that to undo would be paramount to
|
||||
half a rewrite. Patches were accepted without taking care to look at
|
||||
them in detail, clean them or even reject them if not “well
|
||||
done” enough for E's code. Thus the decision was made to fix
|
||||
things once and for all and split things up, have well defined
|
||||
interfaces (the EFL library API's) and clean and consistent code and
|
||||
naming schemes. No it's not perfect - probably it will never be, but
|
||||
we are trying. It is a massive improvement over anything
|
||||
Enlightenment had before, and we are proud enough to probably say
|
||||
it's some of the better API's and code of any available in the world
|
||||
or used in any application or WM. It's not the best, but it's pretty
|
||||
good. In doing this rewrite and split, we aim to not make those
|
||||
mistakes again that happened before DR 0.17.0.</FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">With
|
||||
them in detail, clean them or even reject them if not “well done”
|
||||
enough for E's code. Thus the decision was made to fix things once
|
||||
and for all and split things up, have well defined interfaces (the
|
||||
EFL library API's) and clean and consistent code and naming schemes.
|
||||
No it's not perfect - probably it will never be, but we are trying.
|
||||
It is a massive improvement over anything Enlightenment had before,
|
||||
and we are proud enough to probably say it's some of the better API's
|
||||
and code of any available in the world or used in any application or
|
||||
WM. It's not the best, but it's pretty good. In doing this rewrite
|
||||
and split, we aim to not make those mistakes again that happened
|
||||
before DR 0.17.0.</FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">With
|
||||
Enlightenment and EFL's massive break-up into smaller sized chunks,
|
||||
many users will complain about “how hard it is to install”
|
||||
many users will complain about “how hard it is to install”
|
||||
because there are so many libraries and inter-dependencies to handle.
|
||||
We believe this is not our job, but the job of a package management
|
||||
system to handle. We have documented the dependencies for people to
|
||||
|
@ -87,12 +93,12 @@ code consistent and easy to follow - make it follow the style of the
|
|||
rest in function naming, variable naming, access functions etc. Use
|
||||
existing infrastructures - or extend them cleanly as needed. Just
|
||||
because an infrastructure or system doesn't provide an accessor or
|
||||
way of doing something does NOT mean you can't add it. Choose a clean
|
||||
“correct” implementation over a nasty hack, all the time.
|
||||
You get the idea. Now, on to the style guide.</FONT></FONT></P>
|
||||
way of doing something does NOT mean you can't or chouldn't add it.
|
||||
Choose a clean “correct” implementation over a nasty hack, all
|
||||
the time. You get the idea. Now, on to the style guide.</FONT></FONT></P>
|
||||
<P CLASS="western"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt"><B>Enlightenment
|
||||
Stylin'</B></FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">Firstly
|
||||
Stylin' straight from the top of ma dome</B></FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">Firstly
|
||||
comes naming. All functions are name spaced. The EFL libraries begin
|
||||
with library_something_something. It is object oriented naming so you
|
||||
will have system_subsystem_subsystem_object_verb() as a name. For
|
||||
|
@ -116,7 +122,7 @@ functions should be called from e_main.c during startup and shutdown
|
|||
of the WM. It is encouraged that even systems that do not have state
|
||||
have an init and shutdown call pair, just in case in future they will
|
||||
gain state internally.</FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">Any
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">Any
|
||||
system that returns objects (allocated structures) should probably
|
||||
use the E_Object system as a parent. See examples on its use in the
|
||||
code. E_Object provides a simple object wrapper with reference
|
||||
|
@ -124,7 +130,7 @@ counting, object pointer and type checking and safety that should,
|
|||
runtime, trap a lot of potential problems and let the programmer know
|
||||
about them. Use the object type checking macros for checking if an
|
||||
object passed into a function as a parameter is a valid object.</FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">Keep
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">Keep
|
||||
to the indentation and spacing style thats there - it makes it easier
|
||||
to read if all the code matches. All functions called as "callbacks"
|
||||
should be called _e_system_cb_something. The "cb" denotes
|
||||
|
@ -134,19 +140,19 @@ of the control of the program itself. Functions such as the free
|
|||
function for an object aren't the same kind of callback, since they
|
||||
are predictable and controllable, so they do not get "cb"
|
||||
in their name.</FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">So
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">So
|
||||
that's the quick rundown on basic coding style. More will likely be
|
||||
added to this list, but the best way to put it all is "look at
|
||||
what's there and follow the same style".</FONT></FONT></P>
|
||||
<P CLASS="western"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt"><B>Tree
|
||||
Layout</B></FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">The
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">The
|
||||
E17 source tree is well structured, with a location for everything.
|
||||
In the top-level directory you will find a src directory that is the
|
||||
master directory for all the C source code for the WM and components.
|
||||
You will also find a doc and data directories. The doc directory
|
||||
contains all documentation (this document for example).</FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">The
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">The
|
||||
data directory contains all cross-platform data needed for the WM to
|
||||
run as well as a basic default theme that it also needs to run.
|
||||
Currently the default theme is not complete at all and is no
|
||||
|
@ -156,7 +162,7 @@ make a theme. There is also other data used for things like low-level
|
|||
error dialogs (used for example if the theme doesn't work) as well as
|
||||
a default font and other system data such as data for the splash
|
||||
screen displayed while Enlightenment starts up.</FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">The
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">The
|
||||
src directory contains 3 main repositories of code. They are bin, lib
|
||||
and modules. The bin directory contains all the source code for the
|
||||
WM itself and any primary executables it uses during execution. The
|
||||
|
@ -172,7 +178,7 @@ files etc. that are specific to that module. See further on for more
|
|||
information on modules.</FONT></FONT></P>
|
||||
<P CLASS="western"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt"><B>Design
|
||||
Ethos</B></FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">As
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">As
|
||||
for design, Enlightenment doesn't strictly follow a conservative WM
|
||||
design. It does some things quite differently, with the aim of
|
||||
providing more features with simpler internal design to achieve more
|
||||
|
@ -194,74 +200,73 @@ different resolutions very easily since it can control the virtual
|
|||
root window, which is not normally possible to do with the real root
|
||||
window.</FONT></FONT></P>
|
||||
<P CLASS="western"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt"><B>Managers</B></FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">Managers
|
||||
are the basic unit of window management. One Manager object is created
|
||||
per root window to manage. For more people, even if they run Xinerama
|
||||
across multiple screens, there is only 1 root window, and thus E17
|
||||
will only ever have 1 Manager object. If the user runs traditional
|
||||
Multihead there will be 1 root window per screen, that may be a
|
||||
different size and color depth. E17 will create 1 Manager object per
|
||||
screen in this situation. The Manager object handles redirection WM
|
||||
specific events for the root window into the WM, thus effectively
|
||||
being able to trap several kinds of events before a client gets to
|
||||
perform them, thus enabling it to be a WM. A Manager object actually
|
||||
creates a window the size of the root window it manages and covers
|
||||
the root window up completely. Each Manager object may contain 1 or
|
||||
more Container objects which in-turn create their own child windows
|
||||
of the Manager window.</FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">Managers
|
||||
are the basic unit of window management. One Manager object is
|
||||
created per root window to manage. For more people, even if they run
|
||||
Xinerama across multiple screens, there is only 1 root window, and
|
||||
thus E17 will only ever have 1 Manager object. If the user runs
|
||||
traditional Multihead there will be 1 root window per screen, that
|
||||
may be a different size and color depth. E17 will create 1 Manager
|
||||
object per screen in this situation. The Manager object handles
|
||||
redirection WM specific events for the root window into the WM, thus
|
||||
effectively being able to trap several kinds of events before a
|
||||
client gets to perform them, thus enabling it to be a WM. A Manager
|
||||
object actually creates a window the size of the root window it
|
||||
manages and covers the root window up completely. Each Manager object
|
||||
may contain 1 or more Container objects which in-turn create their
|
||||
own child windows of the Manager window.</FONT></FONT></P>
|
||||
<P CLASS="western"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt"><B>Containers</B></FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">Container
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">Container
|
||||
objects create their own windows to CONTAIN managed window frames,
|
||||
the desktop window (the desktop background is actually just a big
|
||||
window that is always kept below all frame windows that contains a
|
||||
canvas for displaying the desktop background and all desktop objects
|
||||
such as a launcher bar, file icons, etc. etc.). The Container is
|
||||
responsible for holding this together and also managing a list of
|
||||
“obscuring” objects that fully obscure the desktop
|
||||
canvas, so it can help optimize drawing to the desktop canvas by
|
||||
avoiding to draw parts of the desktop background canvas that cannot
|
||||
be seen at all. This list is also used to draw soft drop shadows on
|
||||
the desktop canvas by the Dropshadow module. The Container object
|
||||
managed the desktop background, which is actually a complete EDJE
|
||||
object. This may seem strange as a simple JPEG or PNG or GIF may be
|
||||
enough, but by using an EDJE object for the background, the desktop
|
||||
wallpaper can be animated, react to events and input, scale
|
||||
intelligently (not just “stretch” or “tile”),
|
||||
where the desktop wallpaper designer can specify what elements of the
|
||||
wallpaper scale, align, where and how, if they tile, overlay,
|
||||
underlay each other, and how.</FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">Currently
|
||||
“obscuring” objects that fully obscure the desktop canvas, so it
|
||||
can help optimize drawing to the desktop canvas by avoiding to draw
|
||||
parts of the desktop background canvas that cannot be seen at all.
|
||||
This list is also used to draw soft drop shadows on the desktop
|
||||
canvas by the Dropshadow module. The Container object managed the
|
||||
desktop background, which is actually a complete EDJE object. This
|
||||
may seem strange as a simple JPEG or PNG or GIF may be enough, but by
|
||||
using an EDJE object for the background, the desktop wallpaper can be
|
||||
animated, react to events and input, scale intelligently (not just
|
||||
“stretch” or “tile”), where the desktop wallpaper designer
|
||||
can specify what elements of the wallpaper scale, align, where and
|
||||
how, if they tile, overlay, underlay each other, and how.</FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">Currently
|
||||
the Container only responds to configuration change events to change
|
||||
the background, which needs to be a path to an Edje .eet file that
|
||||
contains a Edje group of the key “desktop/background”. It
|
||||
will load this group, if present in the file, as the background. What
|
||||
it needs is a configuration tool that can browse the filing system
|
||||
and directories for .eet files that are like this, display thumbnails
|
||||
and previews, allow a user to select a new background and maybe
|
||||
specify if the background file should change between different
|
||||
virtual desktops (which are currently not implemented), and also be
|
||||
able to browse normal JPEG, PNG etc. files and “import”
|
||||
them into a users wallpaper database (a directory of wallpaper .eet
|
||||
files) and thus convert into a Edje .eet file, which now retains the
|
||||
scaling, tiling and other preferences the user selected within the
|
||||
file. The user can now give this file to others and it will retain
|
||||
the same information, without them needing to know if the wallpaper
|
||||
needs to tile as a pattern, stretch etc.</FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">The
|
||||
contains a Edje group of the key “desktop/background”. It will
|
||||
load this group, if present in the file, as the background. What it
|
||||
needs is a configuration tool that can browse the filing system and
|
||||
directories for .eet files that are like this, display thumbnails and
|
||||
previews, allow a user to select a new background and maybe specify
|
||||
if the background file should change between different virtual
|
||||
desktops (which are currently not implemented), and also be able to
|
||||
browse normal JPEG, PNG etc. files and “import” them into a users
|
||||
wallpaper database (a directory of wallpaper .eet files) and thus
|
||||
convert into a Edje .eet file, which now retains the scaling, tiling
|
||||
and other preferences the user selected within the file. The user can
|
||||
now give this file to others and it will retain the same information,
|
||||
without them needing to know if the wallpaper needs to tile as a
|
||||
pattern, stretch etc.</FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">The
|
||||
desktop canvas is also shared by many modules that may display things
|
||||
like battery meters, cpu load, launcher bars, drop shadows etc. on
|
||||
the desktop background. The desktop canvas lets this be a bit more
|
||||
organized than it would be with a “free for all” drawing
|
||||
to the root window under more conservative WM's.</FONT></FONT></P>
|
||||
organized than it would be with a “free for all” drawing to the
|
||||
root window under more conservative WM's.</FONT></FONT></P>
|
||||
<P CLASS="western"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt"><B>Borders</B></FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">Borders
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">Borders
|
||||
are the frame outside an application window that is controlled by the
|
||||
WM and that holds the application window within, and allows users to
|
||||
move, resize, shade, lower, close and otherwise control windows. This
|
||||
is currently buggy and not very useful and needs work in combination
|
||||
with the Manager system.</FONT></FONT></P>
|
||||
<P CLASS="western"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt"><B>Menus</B></FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">Enlightenment
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">Enlightenment
|
||||
has its own Menu widget code to allow for highly themable menus that
|
||||
match your WM's theme. These menus are intended to act as ways to
|
||||
launch programs, select actions to perform with context sensitive
|
||||
|
@ -274,20 +279,20 @@ delete and modify menu items while the item is still realized, and a
|
|||
set of other things listed in the TODO list at the top of the
|
||||
e_menu.c source file.</FONT></FONT></P>
|
||||
<P CLASS="western"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt"><B>Modules</B></FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">Modules
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">Modules
|
||||
are a new and powerful way to extend E17 by being able to load and
|
||||
execute code during runtime that may be shipped with E17 or even
|
||||
developed after installation as enhancements and additions. This
|
||||
system still needs work in the configuration department, knowing what
|
||||
modules to load and not load, if they are to be enabled once they are
|
||||
loaded etc. It is possible to have “dormant” modules that
|
||||
are loaded but not enabled. They will use memory and resources for
|
||||
the module entry and the binary executable code loaded into memory,
|
||||
but nothing else. An enabled module will also use resources for
|
||||
objects, images, etc. etc.</FONT></FONT></P>
|
||||
loaded etc. It is possible to have “dormant” modules that are
|
||||
loaded but not enabled. They will use memory and resources for the
|
||||
module entry and the binary executable code loaded into memory, but
|
||||
nothing else. An enabled module will also use resources for objects,
|
||||
images, etc. etc.</FONT></FONT></P>
|
||||
<P CLASS="western"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt"><B>Dropshadow
|
||||
Module</B></FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">This
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">This
|
||||
module demonstrates the Container shape system allowing a module to
|
||||
monitor obscuring shapes in a container. This lets the module, in
|
||||
this case, draw soft shadows under these obscuring shapes. It is a
|
||||
|
@ -299,21 +304,21 @@ entirely from the blurring algorithm, and perhaps finding a way of
|
|||
blurring using a Gaussian blur that is faster.</FONT></FONT></P>
|
||||
<P CLASS="western"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt"><B>IBar
|
||||
Module</B></FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">The
|
||||
IBar module is a template for doing a “launcher panel” in
|
||||
E17. It allows the user to manage a list of frequently used
|
||||
applications to go into the IBar's panel. It is an attempt to unify
|
||||
the configuration of “bars” in E17 so if a user changes
|
||||
launcher bar modules, they can retain at least most of the basic
|
||||
configuration, like what applications are in the bar, and so-on. The
|
||||
IBar has some unique characteristics allowing a lot of applications
|
||||
to be held in a small bar, by having it auto-scroll on mouse over to
|
||||
the desired location in the list. It uses the Application interface
|
||||
to fetch a list of applications and monitor this list for changes on
|
||||
disk. The IBar also allows itself to be resized and dragged around
|
||||
the edges of the screen, set to fill a edge, auto-size to fit its
|
||||
contents, or be a fixed size.</FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">It
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">The
|
||||
IBar module is a template for doing a “launcher panel” in E17. It
|
||||
allows the user to manage a list of frequently used applications to
|
||||
go into the IBar's panel. It is an attempt to unify the configuration
|
||||
of “bars” in E17 so if a user changes launcher bar modules, they
|
||||
can retain at least most of the basic configuration, like what
|
||||
applications are in the bar, and so-on. The IBar has some unique
|
||||
characteristics allowing a lot of applications to be held in a small
|
||||
bar, by having it auto-scroll on mouse over to the desired location
|
||||
in the list. It uses the Application interface to fetch a list of
|
||||
applications and monitor this list for changes on disk. The IBar also
|
||||
allows itself to be resized and dragged around the edges of the
|
||||
screen, set to fill a edge, auto-size to fit its contents, or be a
|
||||
fixed size.</FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">It
|
||||
needs work to be done on auto hide and auto show, so on an auto show
|
||||
it could signal other parts of E17, for example, to slide all windows
|
||||
out of the way, or other such features. It needs work to display
|
||||
|
@ -324,12 +329,12 @@ work is to support subdirectories in the bar's application list. How
|
|||
best to do this is still up in the air. For now this isn't supported.</FONT></FONT></P>
|
||||
<P CLASS="western"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt"><B>Test
|
||||
Module</B></FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">This
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">This
|
||||
is just a test module for playing with new module features. It will
|
||||
not make its way into a final E17 release, but can be used as a bare
|
||||
skeleton for building a new module.</FONT></FONT></P>
|
||||
<P CLASS="western"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt"><B>Applications</B></FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">This
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">This
|
||||
subsystem is responsible for being able to list applications held in
|
||||
E17 specific application directories. This system can inform other
|
||||
parts of E17 and modules of changes, such as an application being
|
||||
|
@ -338,7 +343,7 @@ in a directory changing, an application being executed or displaying
|
|||
its window, or finishing execution. It can share the application
|
||||
lists between multiple systems to save RAM and CPU and I/O in loading
|
||||
them multiple times.</FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">It
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">It
|
||||
may be of surprise to find E17 is not loading the XML, .desktop
|
||||
entries etc. etc. than KDE and GNOME use. In all honesty that system
|
||||
is a little overcomplicated and hard to keep up with. It also is not
|
||||
|
@ -351,7 +356,7 @@ create such files FROM existing system databases of applications and
|
|||
monitor these for changes, reflecting those changes in Enlightenments
|
||||
application directories.</FONT></FONT></P>
|
||||
<P CLASS="western"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt"><B>IPC</B></FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">IPC
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">IPC
|
||||
(inter process communication) is provided in E17 as a mechanism for
|
||||
another application to send commands and requests to Enlightenment
|
||||
and receive responses with information. This mechanism is intended to
|
||||
|
@ -362,89 +367,88 @@ but will accept clients connecting. Many commands need to be
|
|||
implemented here, such as being able to ask E17 to load or unload a
|
||||
module, change background, change focus mode, theme, restart etc.</FONT></FONT></P>
|
||||
<P CLASS="western"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt"><B>Objects</B></FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">This
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">This
|
||||
provides a basic Object Oriented handling system for E17. Any major
|
||||
“object” in E17 should use this system for handling
|
||||
reference counting, destruction and creation of objects, as it
|
||||
provides safety mechanisms to check if an object has accidentally
|
||||
been destroyed and still has a pointer to it, keep references on
|
||||
objects intact etc. This should be used as much as possible, as well
|
||||
as the macros it provides for checking on entry points into subsystem
|
||||
functions etc.</FONT></FONT></P>
|
||||
“object” in E17 should use this system for handling reference
|
||||
counting, destruction and creation of objects, as it provides safety
|
||||
mechanisms to check if an object has accidentally been destroyed and
|
||||
still has a pointer to it, keep references on objects intact etc.
|
||||
This should be used as much as possible, as well as the macros it
|
||||
provides for checking on entry points into subsystem functions etc.</FONT></FONT></P>
|
||||
<P CLASS="western"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt"><B>Pointers</B></FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">This
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">This
|
||||
subsystem handles setting of X mouse cursors in an abstract fashion.
|
||||
In theory E just looks at a cursor as RGBA pixel data. In future
|
||||
Ecore will be expanded to be able to set full color cursors in X as
|
||||
well as monochrome versions of them. Currently it is very simplistic
|
||||
loading a fixed PNG as a cursor. This needs to be improved.</FONT></FONT></P>
|
||||
<P CLASS="western"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt"><B>Box</B></FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">This
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">This
|
||||
is a basic Evas Smart Object that acts as a horizontal or vertical
|
||||
box layout container. It needs more features for layout, like better
|
||||
non homogeneous layout. This is a handy object that is sued by menus
|
||||
and the IBar module for starters.</FONT></FONT></P>
|
||||
<P CLASS="western"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt"><B>Icons</B></FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">This
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">This
|
||||
is an Evas Smart Object that creates a icon display object That
|
||||
handles scaling the icon sensibly within the object bounds, so the
|
||||
application doesn't have to handle trying to retain aspect ratio for
|
||||
the object. This is a simple smart object and indicative of possibly
|
||||
more in future to go into E17's code to save time and effort.</FONT></FONT></P>
|
||||
<P CLASS="western"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt"><B>Paths</B></FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">This
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">This
|
||||
helps E17 find files in a list of paths/directories. There isn't a
|
||||
lot to say about this except that it works and may need some minimal
|
||||
expansion in future.</FONT></FONT></P>
|
||||
<P CLASS="western"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt"><B>User
|
||||
Information</B></FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">This
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">This
|
||||
returns information about a user such as their home directory. This
|
||||
will expand in future.</FONT></FONT></P>
|
||||
<P CLASS="western"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt"><B>Virtual
|
||||
and Multiple Desktops</B></FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">This
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">This
|
||||
is not implemented yet.</FONT></FONT></P>
|
||||
<P CLASS="western"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt"><B>Error
|
||||
Dialogs</B></FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">This
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">This
|
||||
displays very basic error dialogs right now, either as text in the
|
||||
console if E17 isn't ready to run graphically yet, or as text in a graphical
|
||||
dialog box. This needs to be made more robust, so it can display errors if it
|
||||
cannot find the font and images for the basic error dialog. It should also be
|
||||
expanded to support fully themed dialogs if the theme loads properly and
|
||||
properly supports theming of dialogs, so dialogs look good.</FONT></FONT></P>
|
||||
console if E17 isn't ready to run graphically yet, or as text in a
|
||||
graphical dialog box. This needs to be made more robust, so it can
|
||||
display errors if it cannot find the font and images for the basic
|
||||
error dialog. It should also be expanded to support fully themed
|
||||
dialogs if the theme loads properly and properly supports theming of
|
||||
dialogs, so dialogs look good.</FONT></FONT></P>
|
||||
<P CLASS="western"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt"><B>Initialization
|
||||
Splash Screen</B></FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">This
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">This
|
||||
keeps the user amused while E17 starts up and launches all programs.
|
||||
For now it is artificially fixed to stay up for 4 seconds so you can
|
||||
enjoy its radiant splendor, as E17 starts so quickly you'd never see
|
||||
it, but in future it will stay up until the WM is all ready to go.</FONT></FONT></P>
|
||||
<P CLASS="western"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt"><B>Configuration</B></FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">Loading
|
||||
and saving configuration is a big task. E17 uses Ecore Config as its
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">Loading
|
||||
and saving configuration is a big task. E17 uses EET directly as its
|
||||
underlying layer for saving and loading configuration. The E17 Config
|
||||
system simply sets up all listeners for when configuration values
|
||||
change, loads all the initial configuration values, and saves them
|
||||
when and if they change internally. It needs work to make it much
|
||||
simpler as many more config values will be added and it needs to be
|
||||
more efficient ad loading them if they change runtime via a listener
|
||||
(the number of listeners needs to be reduced), so maybe loading
|
||||
config values in sections/groups and deferring a reload in a Ecore
|
||||
Job would limit the reloading effects. Also declaring config values
|
||||
and how to load and declare them is required. Maybe a big table with
|
||||
default values, min, max, step, descriptions etc.</FONT></FONT></P>
|
||||
system simply loads all the initial configuration values, and saves
|
||||
them when and if they change internally. It needs work to make it
|
||||
much simpler as many more config values will be added and it needs to
|
||||
be more efficient and loading them if they change runtime via a
|
||||
listener (the number of listeners needs to be reduced), so maybe
|
||||
loading config values in sections/groups and deferring a reload in a
|
||||
Ecore Job would limit the reloading effects. Also declaring config
|
||||
values and how to load and declare them is required. Maybe a big
|
||||
table with default values, min, max, step, descriptions etc.</FONT></FONT></P>
|
||||
<P CLASS="western"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt"><B>File
|
||||
Operations</B></FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT SIZE=1 STYLE="font-size: 8pt"><FONT FACE="Bitstream Vera Sans">Files
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">Files
|
||||
need to be accessed, listed, found, examined as part of E17 running.
|
||||
This file has simplified, easy-to-use functions for doing anything
|
||||
related to files. This file will expand over time as more file
|
||||
operations are needed.</FONT></FONT></P>
|
||||
<P CLASS="western"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt"><B>Miscellaneous
|
||||
Utilities</B></FONT></FONT></P>
|
||||
<P CLASS="western" STYLE="margin-left: 4.73pc"><FONT SIZE=1 STYLE="font-size: 8pt"><FONT FACE="Bitstream Vera Sans">Things
|
||||
<P CLASS="western" STYLE="margin-left: 0.79in"><FONT FACE="Bitstream Vera Sans"><FONT SIZE=1 STYLE="font-size: 8pt">Things
|
||||
that are useful in many places but do not have enough scope to have a
|
||||
file of their own go into this file.</FONT></FONT></P>
|
||||
</BODY>
|
||||
|
|
|
@ -2,7 +2,8 @@ MAINTAINERCLEANFILES = Makefile.in
|
|||
SUBDIRS = \
|
||||
test \
|
||||
ibar \
|
||||
dropshadow \
|
||||
clock \
|
||||
flame \
|
||||
snow \
|
||||
dropshadow
|
||||
battery
|
||||
|
|
|
@ -0,0 +1,26 @@
|
|||
MAINTAINERCLEANFILES = Makefile.in
|
||||
MODULE = battery
|
||||
|
||||
# data files for the module
|
||||
filesdir = $(libdir)/enlightenment/modules/$(MODULE)
|
||||
files_DATA = \
|
||||
module_icon.png
|
||||
|
||||
EXTRA_DIST = $(files_DATA)
|
||||
|
||||
# the module .so file
|
||||
INCLUDES = -I. \
|
||||
-I$(top_srcdir) \
|
||||
-I$(includedir) \
|
||||
-I$(top_srcdir)$(MODULE) \
|
||||
-I$(top_srcdir)/src/bin \
|
||||
-I$(top_srcdir)/src/lib \
|
||||
-I$(top_srcdir)/src/modules \
|
||||
@e_cflags@
|
||||
pkgdir = $(libdir)/enlightenment/modules/$(MODULE)
|
||||
pkg_LTLIBRARIES = module.la
|
||||
module_la_SOURCES = e_mod_main.c \
|
||||
e_mod_main.h
|
||||
module_la_LIBADD = @e_libs@ @dlopen_libs@
|
||||
module_la_LDFLAGS = -module -avoid-version
|
||||
module_la_DEPENDENCIES = $(top_builddir)/config.h
|
|
@ -0,0 +1,349 @@
|
|||
#include "e.h"
|
||||
#include "e_mod_main.h"
|
||||
|
||||
/* TODO List:
|
||||
*
|
||||
* should support proepr resize and move handles in the edje.
|
||||
*
|
||||
*/
|
||||
|
||||
/* module private routines */
|
||||
static Battery *_battery_init(E_Module *m);
|
||||
static void _battery_shutdown(Battery *e);
|
||||
static E_Menu *_battery_config_menu_new(Battery *e);
|
||||
static void _battery_config_menu_del(Battery *e, E_Menu *m);
|
||||
static void _battery_face_init(Battery_Face *ef);
|
||||
static void _battery_face_free(Battery_Face *ef);
|
||||
static void _battery_face_reconfigure(Battery_Face *ef);
|
||||
static void _battery_cb_face_down(void *data, Evas *e, Evas_Object *obj, void *event_info);
|
||||
static void _battery_cb_face_up(void *data, Evas *e, Evas_Object *obj, void *event_info);
|
||||
static void _battery_cb_face_move(void *data, Evas *e, Evas_Object *obj, void *event_info);
|
||||
static int _battery_cb_event_container_resize(void *data, int type, void *event);
|
||||
|
||||
/* public module routines. all modules must have these */
|
||||
void *
|
||||
init(E_Module *m)
|
||||
{
|
||||
Battery *e;
|
||||
|
||||
/* check module api version */
|
||||
if (m->api->version < E_MODULE_API_VERSION)
|
||||
{
|
||||
e_error_dialog_show("Module API Error",
|
||||
"Error initializing Module: IBar\n"
|
||||
"It requires a minimum module API version of: %i.\n"
|
||||
"The module API advertized by Enlightenment is: %i.\n"
|
||||
"Aborting module.",
|
||||
E_MODULE_API_VERSION,
|
||||
m->api->version);
|
||||
return NULL;
|
||||
}
|
||||
/* actually init battery */
|
||||
e = _battery_init(m);
|
||||
m->config_menu = _battery_config_menu_new(e);
|
||||
return e;
|
||||
}
|
||||
|
||||
int
|
||||
shutdown(E_Module *m)
|
||||
{
|
||||
Battery *e;
|
||||
|
||||
e = m->data;
|
||||
if (e)
|
||||
{
|
||||
if (m->config_menu)
|
||||
{
|
||||
_battery_config_menu_del(e, m->config_menu);
|
||||
m->config_menu = NULL;
|
||||
}
|
||||
_battery_shutdown(e);
|
||||
}
|
||||
return 1;
|
||||
}
|
||||
|
||||
int
|
||||
save(E_Module *m)
|
||||
{
|
||||
Battery *e;
|
||||
|
||||
e = m->data;
|
||||
e_config_domain_save("module.battery", e->conf_edd, e->conf);
|
||||
return 1;
|
||||
}
|
||||
|
||||
int
|
||||
info(E_Module *m)
|
||||
{
|
||||
char buf[4096];
|
||||
|
||||
m->label = strdup("Battery");
|
||||
snprintf(buf, sizeof(buf), "%s/module_icon.png", e_module_dir_get(m));
|
||||
m->icon_file = strdup(buf);
|
||||
return 1;
|
||||
}
|
||||
|
||||
int
|
||||
about(E_Module *m)
|
||||
{
|
||||
e_error_dialog_show("Enlightenment Battery Module",
|
||||
"A simple module to give E17 a battery meter.");
|
||||
return 1;
|
||||
}
|
||||
|
||||
/* module private routines */
|
||||
static Battery *
|
||||
_battery_init(E_Module *m)
|
||||
{
|
||||
Battery *e;
|
||||
Evas_List *managers, *l, *l2;
|
||||
|
||||
e = calloc(1, sizeof(Battery));
|
||||
if (!e) return NULL;
|
||||
|
||||
e->conf_edd = E_CONFIG_DD_NEW("Battery_Config", Config);
|
||||
#undef T
|
||||
#undef D
|
||||
#define T Config
|
||||
#define D e->conf_edd
|
||||
E_CONFIG_VAL(D, T, width, INT);
|
||||
E_CONFIG_VAL(D, T, x, DOUBLE);
|
||||
E_CONFIG_VAL(D, T, y, DOUBLE);
|
||||
|
||||
e->conf = e_config_domain_load("module.battery", e->conf_edd);
|
||||
if (!e->conf)
|
||||
{
|
||||
e->conf = E_NEW(Config, 1);
|
||||
e->conf->width = 64;
|
||||
e->conf->x = 1.0;
|
||||
e->conf->y = 1.0;
|
||||
}
|
||||
E_CONFIG_LIMIT(e->conf->width, 2, 256);
|
||||
E_CONFIG_LIMIT(e->conf->x, 0.0, 1.0);
|
||||
E_CONFIG_LIMIT(e->conf->y, 0.0, 1.0);
|
||||
|
||||
managers = e_manager_list();
|
||||
for (l = managers; l; l = l->next)
|
||||
{
|
||||
E_Manager *man;
|
||||
|
||||
man = l->data;
|
||||
for (l2 = man->containers; l2; l2 = l2->next)
|
||||
{
|
||||
E_Container *con;
|
||||
Battery_Face *ef;
|
||||
|
||||
con = l2->data;
|
||||
ef = calloc(1, sizeof(Battery_Face));
|
||||
if (ef)
|
||||
{
|
||||
ef->bat = e;
|
||||
ef->con = con;
|
||||
ef->evas = con->bg_evas;
|
||||
_battery_face_init(ef);
|
||||
e->face = ef;
|
||||
}
|
||||
}
|
||||
}
|
||||
return e;
|
||||
}
|
||||
|
||||
static void
|
||||
_battery_shutdown(Battery *e)
|
||||
{
|
||||
free(e->conf);
|
||||
E_CONFIG_DD_FREE(e->conf_edd);
|
||||
|
||||
_battery_face_free(e->face);
|
||||
free(e);
|
||||
}
|
||||
|
||||
static E_Menu *
|
||||
_battery_config_menu_new(Battery *e)
|
||||
{
|
||||
E_Menu *mn;
|
||||
E_Menu_Item *mi;
|
||||
|
||||
/* FIXME: hook callbacks to each menu item */
|
||||
mn = e_menu_new();
|
||||
|
||||
mi = e_menu_item_new(mn);
|
||||
e_menu_item_label_set(mi, "(Unused)");
|
||||
/* e_menu_item_callback_set(mi, _battery_cb_time_set, e);*/
|
||||
e->config_menu = mn;
|
||||
|
||||
return mn;
|
||||
}
|
||||
|
||||
static void
|
||||
_battery_config_menu_del(Battery *e, E_Menu *m)
|
||||
{
|
||||
e_object_del(E_OBJECT(m));
|
||||
}
|
||||
|
||||
static void
|
||||
_battery_face_init(Battery_Face *ef)
|
||||
{
|
||||
Evas_Coord ww, hh, bw, bh;
|
||||
Evas_Object *o;
|
||||
|
||||
ef->ev_handler_container_resize =
|
||||
ecore_event_handler_add(E_EVENT_CONTAINER_RESIZE,
|
||||
_battery_cb_event_container_resize,
|
||||
ef);
|
||||
evas_output_viewport_get(ef->evas, NULL, NULL, &ww, &hh);
|
||||
ef->fx = ef->bat->conf->x * (ww - ef->bat->conf->width);
|
||||
ef->fy = ef->bat->conf->y * (hh - ef->bat->conf->width);
|
||||
|
||||
evas_event_freeze(ef->evas);
|
||||
o = edje_object_add(ef->evas);
|
||||
ef->bat_object = o;
|
||||
|
||||
edje_object_file_set(o,
|
||||
/* FIXME: "default.eet" needs to come from conf */
|
||||
e_path_find(path_themes, "default.eet"),
|
||||
"modules/battery/main");
|
||||
evas_object_show(o);
|
||||
|
||||
o = evas_object_rectangle_add(ef->evas);
|
||||
ef->event_object = o;
|
||||
evas_object_layer_set(o, 2);
|
||||
evas_object_repeat_events_set(o, 1);
|
||||
evas_object_color_set(o, 0, 0, 0, 0);
|
||||
|
||||
evas_object_event_callback_add(o, EVAS_CALLBACK_MOUSE_DOWN, _battery_cb_face_down, ef);
|
||||
evas_object_event_callback_add(o, EVAS_CALLBACK_MOUSE_UP, _battery_cb_face_up, ef);
|
||||
evas_object_event_callback_add(o, EVAS_CALLBACK_MOUSE_MOVE, _battery_cb_face_move, ef);
|
||||
evas_object_show(o);
|
||||
|
||||
edje_object_size_min_calc(ef->bat_object, &bw, &bh);
|
||||
ef->minsize = bh;
|
||||
ef->minsize = bw;
|
||||
|
||||
_battery_face_reconfigure(ef);
|
||||
|
||||
evas_event_thaw(ef->evas);
|
||||
}
|
||||
|
||||
static void
|
||||
_battery_face_free(Battery_Face *ef)
|
||||
{
|
||||
ecore_event_handler_del(ef->ev_handler_container_resize);
|
||||
evas_object_del(ef->bat_object);
|
||||
evas_object_del(ef->event_object);
|
||||
free(ef);
|
||||
}
|
||||
|
||||
static void
|
||||
_battery_face_reconfigure(Battery_Face *ef)
|
||||
{
|
||||
Evas_Coord minw, minh, maxw, maxh, ww, hh;
|
||||
|
||||
edje_object_size_min_calc(ef->bat_object, &minw, &maxh);
|
||||
edje_object_size_max_get(ef->bat_object, &maxw, &minh);
|
||||
evas_output_viewport_get(ef->evas, NULL, NULL, &ww, &hh);
|
||||
ef->fx = ef->bat->conf->x * (ww - ef->bat->conf->width);
|
||||
ef->fy = ef->bat->conf->y * (hh - ef->bat->conf->width);
|
||||
ef->fw = ef->bat->conf->width;
|
||||
ef->minsize = minw;
|
||||
ef->maxsize = maxw;
|
||||
|
||||
evas_object_move(ef->bat_object, ef->fx, ef->fy);
|
||||
evas_object_resize(ef->bat_object, ef->bat->conf->width, ef->bat->conf->width);
|
||||
evas_object_move(ef->event_object, ef->fx, ef->fy);
|
||||
evas_object_resize(ef->event_object, ef->bat->conf->width, ef->bat->conf->width);
|
||||
}
|
||||
|
||||
static void
|
||||
_battery_cb_face_down(void *data, Evas *e, Evas_Object *obj, void *event_info)
|
||||
{
|
||||
Evas_Event_Mouse_Down *ev;
|
||||
Battery_Face *ef;
|
||||
|
||||
ev = event_info;
|
||||
ef = data;
|
||||
if (ev->button == 3)
|
||||
{
|
||||
e_menu_activate_mouse(ef->bat->config_menu, ef->con,
|
||||
ev->output.x, ev->output.y, 1, 1,
|
||||
E_MENU_POP_DIRECTION_DOWN);
|
||||
e_util_container_fake_mouse_up_all_later(ef->con);
|
||||
}
|
||||
else if (ev->button == 2)
|
||||
{
|
||||
ef->resize = 1;
|
||||
}
|
||||
else if (ev->button == 1)
|
||||
{
|
||||
ef->move = 1;
|
||||
}
|
||||
evas_pointer_canvas_xy_get(e, &ef->xx, &ef->yy);
|
||||
}
|
||||
|
||||
static void
|
||||
_battery_cb_face_up(void *data, Evas *e, Evas_Object *obj, void *event_info)
|
||||
{
|
||||
Evas_Event_Mouse_Up *ev;
|
||||
Battery_Face *ef;
|
||||
Evas_Coord ww, hh;
|
||||
|
||||
ev = event_info;
|
||||
ef = data;
|
||||
ef->move = 0;
|
||||
ef->resize = 0;
|
||||
evas_output_viewport_get(ef->evas, NULL, NULL, &ww, &hh);
|
||||
ef->bat->conf->width = ef->fw;
|
||||
ef->bat->conf->x = (double)ef->fx / (double)(ww - ef->bat->conf->width);
|
||||
ef->bat->conf->y = (double)ef->fy / (double)(hh - ef->bat->conf->width);
|
||||
e_config_save_queue();
|
||||
}
|
||||
|
||||
static void
|
||||
_battery_cb_face_move(void *data, Evas *e, Evas_Object *obj, void *event_info)
|
||||
{
|
||||
Evas_Event_Mouse_Move *ev;
|
||||
Battery_Face *ef;
|
||||
Evas_Coord cx, cy, sw, sh;
|
||||
|
||||
evas_pointer_canvas_xy_get(e, &cx, &cy);
|
||||
evas_output_viewport_get(e, NULL, NULL, &sw, &sh);
|
||||
|
||||
ev = event_info;
|
||||
ef = data;
|
||||
if (ef->move)
|
||||
{
|
||||
ef->fx += cx - ef->xx;
|
||||
ef->fy += cy - ef->yy;
|
||||
if (ef->fx < 0) ef->fx = 0;
|
||||
if (ef->fy < 0) ef->fy = 0;
|
||||
if (ef->fx + ef->fw > sw) ef->fx = sw - ef->fw;
|
||||
if (ef->fy + ef->fw > sh) ef->fy = sh - ef->fw;
|
||||
evas_object_move(ef->bat_object, ef->fx, ef->fy);
|
||||
evas_object_move(ef->event_object, ef->fx, ef->fy);
|
||||
}
|
||||
else if (ef->resize)
|
||||
{
|
||||
Evas_Coord d;
|
||||
|
||||
d = cx - ef->xx;
|
||||
ef->fw += d;
|
||||
if (ef->fw < ef->minsize) ef->fw = ef->minsize;
|
||||
if (ef->fw > ef->maxsize) ef->fw = ef->maxsize;
|
||||
if (ef->fx + ef->fw > sw) ef->fw = sw - ef->fx;
|
||||
if (ef->fy + ef->fw > sh) ef->fw = sh - ef->fy;
|
||||
evas_object_resize(ef->bat_object, ef->fw, ef->fw);
|
||||
evas_object_resize(ef->event_object, ef->fw, ef->fw);
|
||||
}
|
||||
ef->xx = ev->cur.canvas.x;
|
||||
ef->yy = ev->cur.canvas.y;
|
||||
}
|
||||
|
||||
static int
|
||||
_battery_cb_event_container_resize(void *data, int type, void *event)
|
||||
{
|
||||
Battery_Face *ef;
|
||||
|
||||
ef = data;
|
||||
_battery_face_reconfigure(ef);
|
||||
return 1;
|
||||
}
|
|
@ -0,0 +1,48 @@
|
|||
#ifndef E_MOD_MAIN_H
|
||||
#define E_MOD_MAIN_H
|
||||
|
||||
typedef struct _Config Config;
|
||||
typedef struct _Battery Battery;
|
||||
typedef struct _Battery_Face Battery_Face;
|
||||
|
||||
struct _Config
|
||||
{
|
||||
int width;
|
||||
double x, y;
|
||||
};
|
||||
|
||||
struct _Battery
|
||||
{
|
||||
E_Menu *config_menu;
|
||||
Battery_Face *face;
|
||||
|
||||
E_Config_DD *conf_edd;
|
||||
Config *conf;
|
||||
};
|
||||
|
||||
struct _Battery_Face
|
||||
{
|
||||
Battery *bat;
|
||||
E_Container *con;
|
||||
Evas *evas;
|
||||
|
||||
Evas_Object *bat_object;
|
||||
Evas_Object *event_object;
|
||||
|
||||
Evas_Coord minsize, maxsize;
|
||||
|
||||
unsigned char move : 1;
|
||||
unsigned char resize : 1;
|
||||
Evas_Coord xx, yy;
|
||||
Evas_Coord fx, fy, fw;
|
||||
|
||||
Ecore_Event_Handler *ev_handler_container_resize;
|
||||
};
|
||||
|
||||
EAPI void *init (E_Module *m);
|
||||
EAPI int shutdown (E_Module *m);
|
||||
EAPI int save (E_Module *m);
|
||||
EAPI int info (E_Module *m);
|
||||
EAPI int about (E_Module *m);
|
||||
|
||||
#endif
|
After Width: | Height: | Size: 974 B |
|
@ -30,7 +30,7 @@ init(E_Module *m)
|
|||
if (m->api->version < E_MODULE_API_VERSION)
|
||||
{
|
||||
e_error_dialog_show("Module API Error",
|
||||
"Error initializing Module: IBar\n"
|
||||
"Error initializing Module: Clock\n"
|
||||
"It requires a minimum module API version of: %i.\n"
|
||||
"The module API advertized by Enlightenment is: %i.\n"
|
||||
"Aborting module.",
|
||||
|
@ -168,13 +168,8 @@ _clock_config_menu_new(Clock *e)
|
|||
mn = e_menu_new();
|
||||
|
||||
mi = e_menu_item_new(mn);
|
||||
e_menu_item_label_set(mi, "Set Time");
|
||||
// e_menu_item_callback_set(mi, _clock_cb_time_set, e);
|
||||
|
||||
/*
|
||||
mi = e_menu_item_new(mn);
|
||||
e_menu_item_label_set(mi, "More Options...");
|
||||
*/
|
||||
e_menu_item_label_set(mi, "(Unused)");
|
||||
/* e_menu_item_callback_set(mi, _clock_cb_time_set, e);*/
|
||||
e->config_menu = mn;
|
||||
|
||||
return mn;
|
||||
|
|
|
@ -64,7 +64,7 @@ init(E_Module *m)
|
|||
if (m->api->version < E_MODULE_API_VERSION)
|
||||
{
|
||||
e_error_dialog_show("Module API Error",
|
||||
"Error initializing Module: dropshadow\n"
|
||||
"Error initializing Module: Dropshadow\n"
|
||||
"It requires a minimum module API version of: %i.\n"
|
||||
"The module API advertized by Enlightenment is: %i.\n"
|
||||
"Aborting module.",
|
||||
|
|
|
@ -29,7 +29,7 @@ init(E_Module *m)
|
|||
if (m->api->version < E_MODULE_API_VERSION)
|
||||
{
|
||||
e_error_dialog_show("Module API Error",
|
||||
"Error initializing Module: dropshadow\n"
|
||||
"Error initializing Module: Snow\n"
|
||||
"It requires a minimum module API version of: %i.\n"
|
||||
"The module API advertized by Enlightenment is: %i.\n"
|
||||
"Aborting module.",
|
||||
|
|