[E-devel] Re: E CVS: apps/entrance xcomputerman

2004-03-25 Thread Corey Donohoe 
All of these diff's looked pretty good, but ... :)

You don't ever seem to close the connection when you successfully
authenticate, so the removed entrance_ipc_shutdown() in
entrance_session.c should probably go back in.  

What's the purpose of the static _session variable that was added in
entrance_ipc.c ?  Would it be better handled as the data variables to
the different IPC_EVENT types ?  I'm assuming this is just something
that isn't being used yet, but probably is there for checking things
when the callbacks roll in.

ecore_event_handler_add(ECORE_IPC_EVENT .., _entrance_ipc..., session);

* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
 Enlightenment CVS committal
 
 Author  : xcomputerman
 Project : e17
 Module  : apps/entrance
 
 Dir : e17/apps/entrance/src/client
 
 
 Modified Files:
   entrance_auth.h entrance_ipc.c entrance_ipc.h 
   entrance_session.c entrance_session.h main.c 
 
 
 Log Message:
 Fill in client-side IPC functions/refactor code
 
 
 ===
 RCS file: /cvsroot/enlightenment/e17/apps/entrance/src/client/entrance_session.c,v
 retrieving revision 1.45
 retrieving revision 1.46
 diff -u -3 -r1.45 -r1.46
 --- entrance_session.c25 Mar 2004 05:29:21 -  1.45
 +++ entrance_session.c25 Mar 2004 06:44:52 -  1.46
 @@ -343,6 +364,7 @@
 syslog(LOG_CRIT, Unable to set group id.);
  if (setuid(e-auth-pw-pw_uid))
 syslog(LOG_CRIT, Unable to set user id.);
 +entrance_auth_clear_pass(e-auth);
  entrance_auth_free(e-auth);
  e-auth = NULL;
  execl(/bin/sh, /bin/sh, -c, buf, NULL);
 @@ -357,7 +379,6 @@
 _entrance_session_user_list_fix(e);
 /* clear users's password out of memory */
 entrance_auth_clear_pass(e-auth);
 -   entrance_ipc_shutdown();
 /* this bypasses a race condition where entrance loses its x connection */
 /* before the wm gets it and x goes and resets itself */
 sleep(10);
 ===
 RCS file: /cvsroot/enlightenment/e17/apps/entrance/src/client/main.c,v
 retrieving revision 1.46
 retrieving revision 1.47
 diff -u -3 -r1.46 -r1.47
 --- main.c25 Mar 2004 05:23:00 -  1.46
 +++ main.c25 Mar 2004 06:44:52 -  1.47
 @@ -303,7 +303,7 @@
 * receive the cookie back from server
 */
 }
 -   ecore_main_loop_quit();
 +   entrance_session_setup_user_session(session);
  }
  
  /**
 @@ -852,6 +852,7 @@
  #endif
  
entrance_session_ecore_evas_set(session, e);
 +  entrance_ipc_session_set(session);
entrance_session_run(session);
  
if (session-authed)
 @@ -862,9 +863,9 @@
else
{
   entrance_session_free(session);
 - entrance_ipc_shutdown();
   ecore_evas_shutdown();
}
 +  entrance_ipc_shutdown();
edje_shutdown();
ecore_x_shutdown();
ecore_shutdown();
 
__
Corey Donohoe
atmos.org


---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click
___
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] Re: Re: E CVS: apps/entrance xcomputerman

2004-03-25 Thread Corey Donohoe 
* Ibukun Olumuyiwa ([EMAIL PROTECTED]) wrote:
 On Thu 25 Mar 2004, Corey Donohoe wrote:
  All of these diff's looked pretty good, but ... :)
  
  You don't ever seem to close the connection when you successfully
  authenticate, so the removed entrance_ipc_shutdown() in
  entrance_session.c should probably go back in.  
 
 Ah, right...that shutdown doesn't happen. Will fix.
Would it be better to return the pointer to the server, and keep it
encapsulated in the Entrance_Session?  That way we can shutdown the ipc
when we cleanup the session.  hmm...
 
  What's the purpose of the static _session variable that was added in
  entrance_ipc.c ?  Would it be better handled as the data variables to
  the different IPC_EVENT types ?  I'm assuming this is just something
  that isn't being used yet, but probably is there for checking things
  when the callbacks roll in.
  
  ecore_event_handler_add(ECORE_IPC_EVENT .., _entrance_ipc..., session);
  
 
 At the time of entrance_ipc_init(), the session has not yet been
 initialized ... can't pass an empty pointer. So I have to manually set it
 afterwards using ipc_session_set(). This approach is still OK since we're
 using a static variable. That approach was what I wanted to use at first.
How about keeping the session_set function, and assigning the callbacks
at that point.  Or have the entrance_ipc_init() function also take an
Entrance_Session parameter?  See the attached diff.

__
Corey Donohoe
atmos.org
Index: entrance_ipc.c
===
RCS file: /cvsroot/enlightenment/e17/apps/entrance/src/client/entrance_ipc.c,v
retrieving revision 1.3
diff -u -r1.3 entrance_ipc.c
--- entrance_ipc.c  25 Mar 2004 06:44:52 -  1.3
+++ entrance_ipc.c  25 Mar 2004 15:04:16 -
@@ -3,11 +3,12 @@
  **/
 #include entrance_ipc.h
 
+#define TRUE 1
+#define FALSE 0
+
 #define IPC_TITLE entrance_ipc
 static Ecore_Ipc_Server *server = NULL;
 
-static Entrance_Session *_session = NULL;
-
 /**
  * _entrance_ipc_server_add - when we connect to the ipc daemon
  * @data -
@@ -51,7 +52,7 @@
 {
Ecore_Ipc_Event_Server_Data *e;
 
-   if ((e = (Ecore_Ipc_Event_Server_Data *) event)  _session)
+   if ((e = (Ecore_Ipc_Event_Server_Data *) event)  data)
{
   printf(_entrance_ipc_server_data: Received [%i] [%i] (%i) \%s\\n,
  e-major, e-minor, e-size, (char *) e-data);
@@ -138,7 +139,7 @@
  * itself as the server and the app should then start up.
  */
 int
-entrance_ipc_init(int argc, const char **argv)
+entrance_ipc_init(int argc, const char **argv, Entrance_Session *e)
 {
/* we definitely fail if we can't connect to ecore_ipc */
if (ecore_ipc_init()  1)
@@ -148,22 +149,22 @@
 ecore_ipc_server_connect(ECORE_IPC_LOCAL_USER, IPC_TITLE, 0, NULL)))
{
   ecore_event_handler_add(ECORE_IPC_EVENT_CLIENT_ADD, 
-  _entrance_ipc_client_add, NULL);
+  _entrance_ipc_client_add, e);
   
   ecore_event_handler_add(ECORE_IPC_EVENT_CLIENT_DEL,
-  _entrance_ipc_client_del, NULL);
+  _entrance_ipc_client_del, e);
   
   ecore_event_handler_add(ECORE_IPC_EVENT_CLIENT_DATA,
-  _entrance_ipc_client_data, NULL);
+  _entrance_ipc_client_data, e);
   
   ecore_event_handler_add(ECORE_IPC_EVENT_SERVER_DATA,
-  _entrance_ipc_server_data, NULL);
+  _entrance_ipc_server_data, e);
   
   ecore_event_handler_add(ECORE_IPC_EVENT_SERVER_ADD,
-  _entrance_ipc_server_add, NULL);
+  _entrance_ipc_server_add, e);
   
   ecore_event_handler_add(ECORE_IPC_EVENT_SERVER_DEL,
-  _entrance_ipc_server_del, NULL);
+  _entrance_ipc_server_del, e);
   
   
   fprintf(stderr, entrance_ipc_init: Success\n);
@@ -191,12 +192,6 @@
 }
 
 void
-entrance_ipc_session_set(Entrance_Session *session)
-{
-   _session = session;
-}
-
-void
 entrance_ipc_request_xauth(char *homedir, uid_t uid, gid_t gid)
 {
ecore_ipc_server_send(server, E_XAUTH_REQ, E_UID, 0, 0, (int) uid, , 0);
Index: entrance_ipc.h
===
RCS file: /cvsroot/enlightenment/e17/apps/entrance/src/client/entrance_ipc.h,v
retrieving revision 1.3
diff -u -r1.3 entrance_ipc.h
--- entrance_ipc.h  25 Mar 2004 06:46:02 -  1.3
+++ entrance_ipc.h  25 Mar 2004 15:04:16 -
@@ -13,9 +13,8 @@
 #include entrance_session.h
 
 void entrance_ipc_shutdown(void);
-int  entrance_ipc_init(int argc, const char **argv);
+int  entrance_ipc_init(int argc, const char **argv, Entrance_Session *session);
 int  entrance_ipc_connected_get(void);
-void

[E-devel] Re: Re: Re: E CVS: apps/entrance xcomputerman

2004-03-25 Thread Corey Donohoe 
* Ibukun Olumuyiwa ([EMAIL PROTECTED]) wrote:
 On Thu 25 Mar 2004, Corey Donohoe wrote:
  * Ibukun Olumuyiwa ([EMAIL PROTECTED]) wrote:
   On Thu 25 Mar 2004, Corey Donohoe wrote:
All of these diff's looked pretty good, but ... :)

You don't ever seem to close the connection when you successfully
authenticate, so the removed entrance_ipc_shutdown() in
entrance_session.c should probably go back in.  
   
   Ah, right...that shutdown doesn't happen. Will fix.
  Would it be better to return the pointer to the server, and keep it
  encapsulated in the Entrance_Session?  That way we can shutdown the ipc
  when we cleanup the session.  hmm...
 
 I'm not sure putting ipc data inside of the session is a good idea. That
 could lead to complications later down the road, possibly with Xdmcp and
 any other communication issues that may need to be resolved outside the
 context of the session.

If entrance always atleast has an Entrance_Session in memory, we COULD
nest the initialization and shutdown of the ipc system into the new/free
calls to entrance_session.  I admittedly have nfc about Xdmcp, and
what's necessary there tho.  Entrance w/o an Entrance_Session struct
doesn't go very far, unless a lot of the data flow gets gutted.  Even in
that case, the callbacks that require the _session pointer
(_entrance_ipc_server_data) won't work anyways.

 
   
What's the purpose of the static _session variable that was added in
entrance_ipc.c ?  Would it be better handled as the data variables to
the different IPC_EVENT types ?  I'm assuming this is just something
that isn't being used yet, but probably is there for checking things
when the callbacks roll in.

ecore_event_handler_add(ECORE_IPC_EVENT .., _entrance_ipc..., session);

   
   At the time of entrance_ipc_init(), the session has not yet been
   initialized ... can't pass an empty pointer. So I have to manually set it
   afterwards using ipc_session_set(). This approach is still OK since we're
   using a static variable. That approach was what I wanted to use at first.
  How about keeping the session_set function, and assigning the callbacks
  at that point.  Or have the entrance_ipc_init() function also take an
  Entrance_Session parameter?  See the attached diff.
  
 
 Nice idea, but I'm not convinced it's the best way to go for the reason
 outlined above ... in other words, I'm not sure the ipc code should be
 confined to the session. Think of IPC as a separate module or object that
 other modules in entrance (session, auth) can use to communicate with
 entranced. When you look at it from a pseudo-object-oriented standpoint,
 session-related data should be modified using a publicly available method
 (i.e. ipc_session_set()). The use of a static var emphasises the fact that
 it is data local to the ipc module/object.

Well I wouldn't really call it data that's local to the ipc module,
since it's created/destroyed elsewhere. Its (planned) use at certain
times(callbacks) makes sense to just feed it as data to those callbacks.

The Entrance_Session struct that we allocate is always present, and
there is only one per entrance process(singleton sorta).  I don't
see any reason to duplicate that pointer in another place and keep it
static.  I understand the subsystem information hiding-esque concept, I
just don't think it makes sense here. 

Entrance_Session is a handle to all of the memory we've allocated in
entrance, you can basically get to anything with it.  This is true
except in the case of the ipc subsystem.  From a fresh co
(This isn't the perfect way to grep this, but it'll hopefully make sense)

[EMAIL PROTECTED]:~/Source/e17/apps/entrance/src/client$ grep static *.[ch] | grep = 
entrance_ipc.c:static Ecore_Ipc_Server *server = NULL;
entrance_ipc.c:static Entrance_Session *_session = NULL;
main.c:static Entrance_Session *session = NULL;
... + two lines from entrance_edit.c ...

callbacks with extra data parameters are tastey, we should use them. 
I can patch in the above mentioned ideas.
I must seem like a raving idiot here, well... :)

__
Corey Donohoe
atmos.org


---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click
___
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] edje_cc error when compiling ewl

2004-03-25 Thread The Rasterman 
On Sun, 21 Mar 2004 18:33:27 +0100 (MET) Vincent Torri [EMAIL PROTECTED]
(Bbabbled:
(B
(B 
(B Hello,
(B 
(B i am trying to (locally) compile the EFLs and there's an error during the
(B last one's compilation (arggg !). edje_cc complains : 
(B 
(B edje_cc: Error. unable to write image part "border-square.png" as
(B "images/0" part entry to default.eet
(B
(Bis border-square.png there as a file? i.e. can it open it? :) sorry i dont have
(Bthe best error message here - it probably should say that it cant load it. this
(Bis probably because the image doesnt exist in any image directory given to
(Bedje_cc.
(B
(B I am not familiar at all with edge, and i don't understand this error.
(B 
(B Could someone help me ?
(B 
(B thanks !
(B 
(B Vincent TORRI
(B 
(B 
(B 
(B ---
(B This SF.Net email is sponsored by: IBM Linux Tutorials
(B Free Linux tutorial presented by Daniel Robbins, President and CEO of
(B GenToo technologies. Learn everything from fundamentals to system
(B administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click
(B ___
(B enlightenment-devel mailing list
(B [EMAIL PROTECTED]
(B https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
(B
(B
(B-- 
(B- Codito, ergo sum - "I code, therefore I am" --
(BThe Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
$B7'<*(B - $Bhttp://ads.osdn.com/?ad_id=1470alloc_id=3638op=click
(B___
(Benlightenment-devel mailing list
(B[EMAIL PROTECTED]
(Bhttps://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E17

2004-03-25 Thread The Rasterman 
On Sun, 21 Mar 2004 16:36:49 -0300 (ART) Alan Rodrigues de Oliveira
(B[EMAIL PROTECTED] babbled:
(B
(B Helo big team!
(B 
(B He is possible to implement in e17 a project to read
(B icone of the program as iconbox of e16 makes not to
(B have to create icone for the menus of enlightenment?
(B
(Bthe plan is to use the NETWM properties provided by the application to get an
(BRGBA 32bit icon and use that data..
(B
(B
(B-- 
(B- Codito, ergo sum - "I code, therefore I am" --
(BThe Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
$B7'<*(B - $Bhttp://ads.osdn.com/?ad_id=1470alloc_id=3638op=click
(B___
(Benlightenment-devel mailing list
(B[EMAIL PROTECTED]
(Bhttps://lists.sourceforge.net/lists/listinfo/enlightenment-devel