On Fri, 13 Jan 2006 12:04:19 +1000 David Seikel <[EMAIL PROTECTED]> babbled:

> On Sat, 7 Jan 2006 02:50:03 +1000 David Seikel <[EMAIL PROTECTED]>
> wrote:
> 
> > On Sat, 7 Jan 2006 00:35:42 +0900 Carsten Haitzler (The Rasterman)
> > <[EMAIL PROTECTED]> wrote:
> > 
> > > i would argue that ECORE_EVENT_EXE is fine as its a CORE ecore event
> > > (not a sub ecore system like ecore_con)... ?
> > 
> > I'm thinking consistency in naming things IPC related.  I think that
> > merging fork'n'pipe with ecore_ipc might be good, it's just another
> > IPC method, why should it be different?  Most of the ways of dealing
> > with it from the ecore users perspective are mostly similar.  Most of
> > the differences are simply due to current inconsistent naming and
> > lack of an exe add event.  The user doesn't see any core ecore / sub
> > ecore issues, it's all ecore_*_whatever to them.
> > 
> > As I said before, the naming of the exit event is historical, and I'm
> > prepared to wear that.  The data event is new though, and should be
> > consistent with other IPC data events.  It's semantics are the same,
> > hell most of the code was just cut'n'paste from ecore_con.
> 
> I've thought about it some more, and the fact that the ecore_exe
> functions are all called ecore_exe_* like the "sub" ecore functions
> means that I consider it to be more consistent.  The style guide says to
> use name spaced, object oriented style names, so ecore_exe_* and
> ECORE_EXE_* has to be the way to go.
> 
> I'll make these changes, but keep ECORE_EVENT_EXE_EXIT around for
> historical reasons (so no one can blame me for beaking evidence).

ok - though it depends how u look at the object ECORE_EVENT_* indicates it
belongs to ecore, is of a type events.. then sub type something else... it just
is a matter of which object is priority...



-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    [EMAIL PROTECTED]
裸好多
Tokyo, Japan (東京 日本)


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to