as some of you may have noticed... i'e started redoing ecore. for those of you
following the code commits going into the SPLIT branch of ecore, you'll know
what I mean.
i did put some api ideas in there a while ago looking for ideas/comments. not
much happened, so i've just scurried along and redone the core event loop now.
why you ask? the previous one was a mess. the api wasn't that good either, and
it was becoming a bit of a nightmare. i've got (now) what i think is a pretty
slick and solid core loop abstraction there in the new ecore code. it works
(i've actually tested it now). it provides:
timers:
they can be one of or (NEW!) repeating (if they return 0, they are 1 off, if
they return 1 they will repeat themselves). They work and are really clean. They
get passed a data pointer that you can set on timer setup time. They are very
accurate in my tests and seem to keep time very well (for now the accuracy is
about 0.00002 seconds on my machine here (that's the maximum variance of a
repeating timer that i've seen), so i'm willing to say most of the accuracy
issues would be OS/hardware/box load related. you can add and delete timers and
they seem to work.
idle enterers:
this is what the idle handler used to be called in ecore. it is called once when
the ecore main loop is about to "go idle" and wait for more events to be
processed. this is normally where you have the program update its current state
for the user on screen (or so). the program has stopped processing things and
has come to an idle state. you can add and (NEW!) delete these handlers
(NEW!) ilders:
these are called CONTINUOUSLY in a loop while ecore is waiting for events. these
are good for things a program has to do that require non-blocking polling or
continuous handling. a call to these doesn't trigger going back into an idle
state so if these calls update things that an idle enterer displays the program
needs to post a dummy event on the event queue or such to break out of this
state.
fd handlers:
these are generic file descriptor handlers that become active if that file
descriptor has any data available to read from or the buffer is available to
write to. these can be used for file I/O, network I/O, (and this means, X, IPC
and many other things too). They are a generic building block that lets the main
loop function and multiplex everything. You can add and delete them
signal events:
unix signals interrupt anything. they can ruin non-re-entrant code. they can
kill programs executing x calls WITHIN the signal handler. The solution is to
just have the handler set some flags nd handle the signal later in the event
loop. ecore does that for you by turning the signals into events in the event
stream. executable "exit" (SIGCHLD) become evens with process id and termination
codes as events. if they were directly launched via the ecore launching calls
you get the handles generated by them as well. termination, quit and interrupt
signals become events too to be handled gracefully. as do (NEW!) SIGPWR and
"user defined" signals (SIGUSR1, SIGUSR2) and (NEW!) SIGHUP. the application no
longer needs to handle signals and can just loop through its event loop nicely.
(NEW!) event posting:
the application can create and post its own events to the event queue. it can
create new event types and do this cleanly
(NEW!) execution:
you can execute programs and not have to wait for them to finish (ala system()).
You get a process handle back and can attach data to the handle, as well as get
events when the child process dies. no zombies are generated as pid exit status
is collected for you.
time:
you can get the current time as a convenient floating point (double) number so
you can easily compare times without special code to handle seconds and
sub-seconds (milliseconds or nanoseconds) differently.
(NEW!) application handling:
being able to access the applications command-line arguments any time by storing
them globally,and being able to modify them and restart the application
(unfinished) using the cmd-line arguments it was started with.
now i think this covers a LOT of the most core and BASIC application handling.
can anyone suggest anything else? anything that would belong in the area of
handling executing of the app, and events/signals etc.
now i think about it i think i'm missing a "semaphore lock" handler so u can put
some event etcher in a thread and when it becomes active have ti break the
select etc... not sure how i'd handle this though. need to think
the next thing i need to deal with is: X11, IPC, Job queues, etc.
now this isn't "Core" app handling. i'm thinking of making these modules as they
all use either fd's (so fd_handlers can deal with them) or can just synthesize
events and add an event handler for them. now the question is.. do these modules
belong in ecore... ? should i make a bunch of optionally compilable modules
(X11, IPC etc.) separate libraries (libecore_x11.so) or separate projects? i'm
currently tossing this up, BUT i do believe that this doesn't belong in the
current core loop i have here as it can be built off this generic loop.
modules i'm considering:
X11
X abstraction.. a lot like ecore now.
IPC (local unix socket)
handles connecting & disconnecting, breaking protocol into data packets,
buffering etc.
IPC (remote tcp/ip)
handles connecting & disconnecting (remotely) authentication and breaking
protocol into data packets, buffering etc.
IPC (remote tcp/ip secure)
handles connecting & disconnecting (remotely) authentication and encryption,
breaking protocol into data packets, buffering etc.
Job Queue
basically function pointers dumped onto the event queue and executed in line
with the event queue so you can queue yourself things to do later outside of
the callback you are in (cleaner for api's and subsystems to handle this)
Framebuffer console/mouse
reads the console and mouse or touchscreen devices manually and produces
events (good to make custom fullscreen fb apps)
Directfb
abstracts directfb events etc. (would require semaphore etc. handling)
Evas
wraps creating/destroying evas's and creating a window (or setting up the fb)
and handles passing all the events into the evas properly from their handlers
so all you need to do is hook to evas object callbacks. this would probably
work for X11 and the framebuffer and directfb maybe too.
NB: i have divided IPC up into 3 parts and they may be able to be 1 IPC module
with multiple options too. they are listed in priority here
any more modules?
anyway... braindump over.
--
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
[EMAIL PROTECTED]
Mobile Phone: +61 (0)413 451 899 Home Phone: 02 9698 8615
-------------------------------------------------------
This SF.NET email is sponsored by: A Thawte Code Signing Certificate
is essential in establishing user confidence by providing assurance of
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
_______________________________________________
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
