enlightenment/src/actions.c

1818 lines
42 KiB
C
Raw Normal View History

#include "actions.h"
#include "config.h"
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
#include "debug.h"
#include "border.h"
#include "desktops.h"
#include "exec.h"
#include "icccm.h"
#include "keys.h"
#include "view.h"
#include "util.h"
#include "guides.h"
static Evas_List action_impls = NULL;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
static Evas_List current_actions = NULL;
static Evas_List current_timers = NULL;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
static void e_action_find(char *action, E_Action_Type act, int button, char *key,
Ecore_Event_Key_Modifiers mods, E_Object *object);
static void e_action_cleanup(E_Action *a);
2000-12-08 14:54:42 -08:00
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
static void e_act_move_start (E_Object *object, E_Action *a, void *data,
int x, int y, int rx, int ry);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
static void e_act_move_stop (E_Object *object, E_Action *a, void *data,
int x, int y, int rx, int ry);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
static void e_act_move_cont (E_Object *object, E_Action *a, void *data,
int x, int y, int rx, int ry, int dx, int dy);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
static void e_act_resize_start (E_Object *object, E_Action *a, void *data,
int x, int y, int rx, int ry);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
static void e_act_resize_stop (E_Object *object, E_Action *a, void *data,
int x, int y, int rx, int ry);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
static void e_act_resize_cont (E_Object *object, E_Action *a, void *data,
int x, int y, int rx, int ry, int dx, int dy);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
static void e_act_resize_h_start (E_Object *object, E_Action *a, void *data,
int x, int y, int rx, int ry);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
static void e_act_resize_h_stop (E_Object *object, E_Action *a, void *data,
int x, int y, int rx, int ry);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
static void e_act_resize_h_cont (E_Object *object, E_Action *a, void *data,
int x, int y, int rx, int ry, int dx, int dy);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
static void e_act_resize_v_start (E_Object *object, E_Action *a, void *data,
int x, int y, int rx, int ry);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
static void e_act_resize_v_stop (E_Object *object, E_Action *a, void *data,
int x, int y, int rx, int ry);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
static void e_act_resize_v_cont (E_Object *object, E_Action *a, void *data,
int x, int y, int rx, int ry, int dx, int dy);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
static void e_act_close_start (E_Object *object, E_Action *a, void *data,
int x, int y, int rx, int ry);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
static void e_act_kill_start (E_Object *object, E_Action *a, void *data,
int x, int y, int rx, int ry);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
static void e_act_shade_start (E_Object *object, E_Action *a, void *data,
int x, int y, int rx, int ry);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
static void e_act_raise_start (E_Object *object, E_Action *a, void *data,
int x, int y, int rx, int ry);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
static void e_act_lower_start (E_Object *object, E_Action *a, void *data,
int x, int y, int rx, int ry);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
static void e_act_raise_lower_start (E_Object *object, E_Action *a,
void *data, int x, int y, int rx, int ry);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
static void e_act_exec_start (E_Object *object, E_Action *a, void *data,
int x, int y, int rx, int ry);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
static void e_act_menu_start (E_Object *object, E_Action *a, void *data,
int x, int y, int rx, int ry);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
static void e_act_exit_start (E_Object *object, E_Action *a, void *data,
int x, int y, int rx, int ry);
static void e_act_restart_start (E_Object *object, E_Action *a, void *data,
int x, int y, int rx, int ry);
static void e_act_stick_start (E_Object *object, E_Action *a, void *data,
int x, int y, int rx, int ry);
static void e_act_sound_start (E_Object *object, E_Action *a, void *data,
int x, int y, int rx, int ry);
static void e_act_iconify_start (E_Object *object, E_Action *a, void *data,
int x, int y, int rx, int ry);
static void e_act_max_start (E_Object *object, E_Action *a, void *data,
int x, int y, int rx, int ry);
static void e_act_snap_start (E_Object *object, E_Action *a, void *data,
int x, int y, int rx, int ry);
static void e_act_zoom_start (E_Object *object, E_Action *a, void *data,
int x, int y, int rx, int ry);
static void e_act_desk_start (E_Object *object, E_Action *a, void *data,
int x, int y, int rx, int ry);
static void e_act_raise_next_start (E_Object *object, E_Action *a, void *data,
int x, int y, int rx, int ry);
static void e_act_desk_rel_start (E_Object *object, E_Action *a, void *data,
int x, int y, int rx, int ry);
2000-12-08 14:54:42 -08:00
static void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_action_find(char *action, E_Action_Type act, int button,
char *key, Ecore_Event_Key_Modifiers mods, E_Object *object)
2000-12-08 14:54:42 -08:00
{
char *actions_db;
2000-12-08 14:54:42 -08:00
E_DB_File *db;
int i, num;
char *a_name = NULL;
char *a_action = NULL;
char *a_params = NULL;
int a_event = 0;
int a_button = 0;
char *a_key = NULL;
int a_modifiers = 0;
Evas_List l;
2000-12-08 14:54:42 -08:00
E_Action *a;
static Evas_List actions = NULL;
E_CFG_FILE(cfg_actions, "actions");
2000-12-08 14:54:42 -08:00
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
E_CONFIG_CHECK_VALIDITY(cfg_actions, "actions");
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
/* if we had a previous list - nuke it */
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
/* FIXME: this has potential to segfault if reference
counting is actually used and those actions are
referenced in more than one place --cK.
*/
if (actions)
{
for (l = actions; l; l = l->next)
{
a = l->data;
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
if (a) e_action_cleanup(a);
}
actions = evas_list_free(actions);
}
/* now build the list again */
actions_db = e_config_get("actions");
2000-12-08 14:54:42 -08:00
db = e_db_open_read(actions_db);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
if (!db) D_RETURN;
2000-12-08 14:54:42 -08:00
if (!e_db_int_get(db, "/actions/count", &num)) goto error;
for (i = 0; i < num; i++)
{
char buf[PATH_MAX];
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
sprintf(buf, "/actions/%i/name", i);
a_name = e_db_str_get(db, buf);
sprintf(buf, "/actions/%i/action", i);
a_action = e_db_str_get(db, buf);
sprintf(buf, "/actions/%i/params", i);
a_params = e_db_str_get(db, buf);
sprintf(buf, "/actions/%i/event", i);
e_db_int_get(db, buf, &a_event);
sprintf(buf, "/actions/%i/button", i);
e_db_int_get(db, buf, &a_button);
sprintf(buf, "/actions/%i/key", i);
a_key = e_db_str_get(db, buf);
sprintf(buf, "/actions/%i/modifiers", i);
e_db_int_get(db, buf, &a_modifiers);
a = NEW(E_Action, 1);
ZERO(a, E_Action, 1);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_object_init(E_OBJECT(a), (E_Cleanup_Func) e_action_cleanup);
a->name = a_name;
a->action = a_action;
a->params = a_params;
a->event = a_event;
a->button = a_button;
a->key = a_key;
a->modifiers = a_modifiers;
a->action_impl = NULL;
a->object = NULL;
a->started = 0;
actions = evas_list_append(actions, a);
/* it's a key? lets grab it! */
if ((a->key) && (strlen(a->key) > 0))
{
if (a->modifiers == -1)
e_keys_grab(a->key, ECORE_EVENT_KEY_MODIFIER_NONE, 1);
else
e_keys_grab(a->key, (Ecore_Event_Key_Modifiers)a->modifiers, 0);
a->grabbed = 1;
}
}
error:
e_db_close(db);
E_CONFIG_CHECK_VALIDITY_END;
/* run thru our actions list and match event, state and stuff with an */
/* and action for it */
for (l = actions; l; l = l->next)
{
Evas_List ll;
a = l->data;
if (act != a->event) goto next;
if (!((a->name) &&
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
(action) &&
(!strcmp(a->name, action)))) goto next;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
if ((act >= ACT_MOUSE_CLICK) &&
(act <= ACT_MOUSE_CLICKED) &&
(!((a->button == -1) ||
(a->button == button)))) goto next;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
if ((act >= ACT_KEY_DOWN) &&
(act <= ACT_KEY_UP) &&
(!((a->key) && (key) &&
(!strcmp(a->key, key))))) goto next;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
if ((act >= ACT_MOUSE_CLICK) &&
(act <= ACT_KEY_UP) &&
(!((a->modifiers == -1) ||
(a->modifiers == (int)mods)))) goto next;
for (ll = action_impls; ll; ll = ll->next)
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
{
E_Action_Impl *ap;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
ap = ll->data;
if (!strcmp(ap->action, a->action))
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
{
E_Action *aa;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
aa = NEW(E_Action, 1);
ZERO(aa, E_Action, 1);
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_object_init(E_OBJECT(aa), (E_Cleanup_Func) e_action_cleanup);
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
e_strdup(aa->name, a->name);
e_strdup(aa->action, a->action);
e_strdup(aa->params, a->params);
aa->event = a->event;
aa->button = a->button;
e_strdup(aa->key, a->key);
aa->modifiers = a->modifiers;
aa->action_impl = ap;
e_object_ref(E_OBJECT(ap));
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
aa->object = object;
e_object_ref(object);
aa->started = 0;
current_actions = evas_list_append(current_actions, aa);
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
}
}
next:
2000-12-08 14:54:42 -08:00
}
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN;
2000-12-08 14:54:42 -08:00
}
static void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_action_cleanup(E_Action *a)
2000-12-08 14:54:42 -08:00
{
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
/* it's a key? lets ungrab it! */
if ((a->key) && (strlen(a->key) > 0) && (a->grabbed))
{
if (a->modifiers == -1)
e_keys_ungrab(a->key, ECORE_EVENT_KEY_MODIFIER_NONE, 1);
else
e_keys_ungrab(a->key, (Ecore_Event_Key_Modifiers)a->modifiers, 0);
}
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
/* Clean up the strings by simply freeing them ... */
2000-12-08 14:54:42 -08:00
IF_FREE(a->name);
IF_FREE(a->action);
IF_FREE(a->params);
IF_FREE(a->key);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
/* Cleanup action implementations and objects. These
we don't free directly, but just decrement their use counts.
*/
if (a->action_impl)
{
e_object_unref(E_OBJECT(a->action_impl));
a->action_impl = NULL;
}
if (a->object)
{
e_object_unref(a->object);
a->object = NULL;
}
/* Cleanup superclass. */
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_object_cleanup(E_OBJECT(a));
D_RETURN;
2000-12-08 14:54:42 -08:00
}
int
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_action_start(char *action, E_Action_Type act, int button,
char *key, Ecore_Event_Key_Modifiers mods,
E_Object *object, void *data, int x, int y, int rx, int ry)
2000-12-08 14:54:42 -08:00
{
Evas_List l;
int started_long_action = 0;
2000-12-08 14:54:42 -08:00
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
e_action_find(action, act, button, key, mods, object);
2000-12-08 14:54:42 -08:00
again:
for (l = current_actions; l; l = l->next)
{
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
E_Action *a;
a = l->data;
if (!a->started)
{
if (a->action_impl->func_stop)
{
a->started = 1;
started_long_action = 1;
}
if (a->action_impl->func_start)
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
{
a->action_impl->func_start(a->object, a, data, x, y, rx, ry);
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
}
}
if (!a->started)
{
current_actions = evas_list_remove(current_actions, a);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_object_unref(E_OBJECT(a));
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
goto again;
}
2000-12-08 14:54:42 -08:00
}
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN_(started_long_action);
2000-12-08 14:54:42 -08:00
}
void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_action_stop(char *action, E_Action_Type act, int button,
char *key, Ecore_Event_Key_Modifiers mods, E_Object *object,
void *data, int x, int y, int rx, int ry)
2000-12-08 14:54:42 -08:00
{
Evas_List l;
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
2000-12-08 14:54:42 -08:00
again:
for (l = current_actions; l; l = l->next)
{
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
E_Action *a;
a = l->data;
if ((a->started) && (a->action_impl->func_stop))
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
{
int ok = 0;
if ((a->event == ACT_MOUSE_IN) &&
(act == ACT_MOUSE_OUT))
ok = 1;
if ((a->event == ACT_MOUSE_OUT) &&
(act == ACT_MOUSE_IN))
ok = 1;
if ((a->event >= ACT_MOUSE_CLICK) &&
(a->event <= ACT_MOUSE_TRIPLE) &&
(act >= ACT_MOUSE_UP) &&
(act <= ACT_MOUSE_CLICKED) &&
(a->button == button))
ok = 1;
if ((a->event == ACT_MOUSE_MOVE) &&
((act == ACT_MOUSE_OUT) ||
(act == ACT_MOUSE_IN) ||
((act >= ACT_MOUSE_CLICK) &&
(act <= ACT_MOUSE_TRIPLE)) ||
(act >= ACT_MOUSE_UP)))
ok = 1;
if ((a->event == ACT_KEY_DOWN) &&
(act == ACT_KEY_UP) &&
(key) && (a->key) && (!strcmp(key, a->key)))
ok = 1;
if ((a->event == ACT_KEY_UP) &&
(act == ACT_KEY_DOWN))
ok = 1;
if (ok)
{
a->action_impl->func_stop(a->object, a, data, x, y, rx, ry);
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
a->started = 0;
}
}
if (!a->started)
{
current_actions = evas_list_remove(current_actions, a);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_object_unref(E_OBJECT(a));
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
goto again;
}
2000-12-08 14:54:42 -08:00
}
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
UN(action);
UN(mods);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
UN(object);
2000-12-08 14:54:42 -08:00
}
void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_action_cont(char *action, E_Action_Type act, int button, char *key,
Ecore_Event_Key_Modifiers mods, E_Object *object, void *data,
int x, int y, int rx, int ry, int dx, int dy)
2000-12-08 14:54:42 -08:00
{
Evas_List l;
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
2000-12-08 14:54:42 -08:00
for (l = current_actions; l; l = l->next)
{
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
E_Action *a;
a = l->data;
if ((a->started) && (a->action_impl->func_cont))
a->action_impl->func_cont(a->object, a, data, x, y, rx, ry, dx, dy);
2000-12-08 14:54:42 -08:00
}
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
UN(action);
UN(act);
UN(button);
UN(key);
UN(mods);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
UN(object);
2000-12-08 14:54:42 -08:00
}
void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_action_stop_by_object(E_Object *object, void *data, int x, int y, int rx, int ry)
2000-12-08 14:54:42 -08:00
{
Evas_List l;
D_ENTER;
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_action_del_timer_object(object);
2000-12-08 14:54:42 -08:00
again:
for (l = current_actions; l; l = l->next)
{
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
E_Action *a;
a = l->data;
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
if ((a->started) && (object == a->object))
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
{
if (a->action_impl->func_stop)
a->action_impl->func_stop(a->object, a, data, x, y, rx, ry);
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
a->started = 0;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
current_actions = evas_list_remove(current_actions, a);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_object_unref(E_OBJECT(a));
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
goto again;
}
2000-12-08 14:54:42 -08:00
}
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN;
2000-12-08 14:54:42 -08:00
}
void
e_action_stop_by_type(char *action)
{
Evas_List l;
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
for (l = current_actions; l; l = l->next)
{
E_Action *a;
a = l->data;
if ((a->started) && (a->action_impl->func_stop) &&
(action) && (!strcmp(action, a->name)))
{
a->action_impl->func_stop(a->object, a, NULL, 0, 0, 0, 0);
a->started = 0;
}
}
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN;
}
static void
e_action_impl_cleanup(E_Action_Impl *eai)
{
D_ENTER;
e_object_cleanup(E_OBJECT(eai));
D_RETURN;
}
2000-12-08 14:54:42 -08:00
void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_action_add_impl(char *action, E_Action_Start_Func func_start,
E_Action_Cont_Func func_cont, E_Action_Stop_Func func_stop)
2000-12-08 14:54:42 -08:00
{
E_Action_Impl *ap;
2000-12-08 14:54:42 -08:00
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
ap = NEW(E_Action_Impl, 1);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
ZERO(ap, E_Action_Impl, 1);
e_object_init(E_OBJECT(ap), (E_Cleanup_Func) e_action_impl_cleanup);
2000-12-08 14:54:42 -08:00
e_strdup(ap->action, action);
2000-12-08 14:54:42 -08:00
ap->func_start = func_start;
ap->func_cont = func_cont;
2000-12-08 14:54:42 -08:00
ap->func_stop = func_stop;
action_impls = evas_list_append(action_impls, ap);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN;
2000-12-08 14:54:42 -08:00
}
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_action_del_timer(E_Object *object, char *name)
{
Evas_List l;
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
again:
for (l = current_timers; l; l = l->next)
{
E_Active_Action_Timer *at;
at = l->data;
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
if ((at->object == object) &&
(name) &&
(at->name) &&
(!strcmp(at->name, name)))
{
e_object_unref(at->object);
ecore_del_event_timer(at->name);
current_timers = evas_list_remove(current_timers, at);
IF_FREE(at->name);
FREE(at);
goto again;
}
}
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN;
}
void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_action_add_timer(E_Object *object, char *name)
{
E_Active_Action_Timer *at;
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
at = NEW(E_Active_Action_Timer, 1);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
at->object = object;
e_object_ref(object);
e_strdup(at->name, name);
current_timers = evas_list_append(current_timers, at);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN;
}
void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_action_del_timer_object(E_Object *object)
{
Evas_List l;
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
again:
for (l = current_timers; l; l = l->next)
{
E_Active_Action_Timer *at;
at = l->data;
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
if (at->object == object)
{
e_object_unref(at->object);
ecore_del_event_timer(at->name);
current_timers = evas_list_remove(current_timers, at);
IF_FREE(at->name);
FREE(at);
goto again;
}
}
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN;
}
2000-12-08 14:54:42 -08:00
void
e_action_init(void)
2000-12-08 14:54:42 -08:00
{
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
e_action_add_impl("Window_Move", e_act_move_start, e_act_move_cont, e_act_move_stop);
e_action_add_impl("Window_Resize", e_act_resize_start, e_act_resize_cont, e_act_resize_stop);
e_action_add_impl("Window_Resize_Horizontal", e_act_resize_h_start, e_act_resize_h_cont, e_act_resize_h_stop);
e_action_add_impl("Window_Resize_Vertical", e_act_resize_v_start, e_act_resize_v_cont, e_act_resize_v_stop);
e_action_add_impl("Window_Close", e_act_close_start, NULL, NULL);
e_action_add_impl("Window_Kill", e_act_kill_start, NULL, NULL);
e_action_add_impl("Window_Shade", e_act_shade_start, NULL, NULL);
e_action_add_impl("Window_Raise", e_act_raise_start, NULL, NULL);
e_action_add_impl("Window_Lower", e_act_lower_start, NULL, NULL);
e_action_add_impl("Window_Raise_Lower", e_act_raise_lower_start, NULL, NULL);
e_action_add_impl("Execute", e_act_exec_start, NULL, NULL);
e_action_add_impl("Menu", e_act_menu_start, NULL, NULL);
e_action_add_impl("Exit", e_act_exit_start, NULL, NULL);
e_action_add_impl("Restart", e_act_restart_start, NULL, NULL);
e_action_add_impl("Window_Stick", e_act_stick_start, NULL, NULL);
e_action_add_impl("Sound", e_act_sound_start, NULL, NULL);
e_action_add_impl("Window_Iconify", e_act_iconify_start, NULL, NULL);
e_action_add_impl("Window_Max_Size", e_act_max_start, NULL, NULL);
e_action_add_impl("Winodw_Snap", e_act_snap_start, NULL, NULL);
e_action_add_impl("Window_Zoom", e_act_zoom_start, NULL, NULL);
e_action_add_impl("Desktop", e_act_desk_start, NULL, NULL);
e_action_add_impl("Desktop_Relative", e_act_desk_rel_start, NULL, NULL);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_action_add_impl("Window_Next", e_act_raise_next_start, NULL, NULL);
D_RETURN;
2000-12-08 14:54:42 -08:00
}
/* FIXME: these REALLY need to go into other file(s) but it's not worht it */
/* yet at this point. it can be done later */
2000-12-08 14:54:42 -08:00
/* Erm is that really true? They're all static, all called through the */
/* above functions -- so it's good to have them encapsulated here? --cK */
/* well i was thinking changing this to be a bunch of: */
/* #include "action_windows.c" */
/* #include "action_files.c" */
/* #include "action_general.c" */
/* etc. - group actions in files for their logical uses */
/* kind of evil to inlucde c files.. but it means breaking it up better */
/* probably moving these includes above the init and having hooks into the */
/* init func */
2000-12-08 14:54:42 -08:00
static void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_act_move_start (E_Object *object, E_Action *a, void *data, int x, int y, int rx, int ry)
2000-12-08 14:54:42 -08:00
{
E_Border *b;
E_Guides_Mode move_mode = E_GUIDES_BOX;
double align_x = 0.5;
double align_y = 0.5;
E_Guides_Location display_loc = E_GUIDES_DISPLAY_LOCATION_WINDOW_MIDDLE;
E_CFG_INT(cfg_window_move_mode, "settings", "/window/move/mode", E_GUIDES_BOX);
E_CFG_FLOAT(cfg_guides_display_x, "settings", "/guides/display/x", 0.5);
E_CFG_FLOAT(cfg_guides_display_y, "settings", "/guides/display/y", 0.5);
E_CFG_INT(cfg_guides_display_location, "settings", "/guides/display/location", E_GUIDES_DISPLAY_LOCATION_WINDOW_MIDDLE);
2000-12-08 14:54:42 -08:00
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
E_CONFIG_INT_GET(cfg_window_move_mode, move_mode);
E_CONFIG_FLOAT_GET(cfg_guides_display_x, align_x);
E_CONFIG_FLOAT_GET(cfg_guides_display_y, align_y);
E_CONFIG_INT_GET(cfg_guides_display_location, display_loc);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
b = (E_Border*) object;
if (!b)
b = e_border_current_focused();
if (!b)
D_RETURN;
if (b->client.fixed)
D_RETURN;
if (move_mode >= E_GUIDES_BOX)
b->hold_changes = 1; /* if non opaque */
2000-12-08 14:54:42 -08:00
b->mode.move = 1;
b->current.requested.dx = 0;
b->current.requested.dy = 0;
b->previous.requested.dx = 0;
b->previous.requested.dy = 0;
{
char buf[PATH_MAX];
e_border_print_pos(buf, b);
e_guides_set_display_alignment(align_x, align_y);
e_guides_set_mode(move_mode);
e_guides_set_display_location(display_loc);
e_guides_display_text(buf);
sprintf(buf, "%s/%s", e_config_get("images"), "win_shadow_icon.png");
e_guides_display_icon(buf);
e_guides_move(b->current.x, b->current.y);
e_guides_resize(b->current.w, b->current.h);
e_guides_show();
}
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
UN(a);
UN(data);
UN(x);
UN(y);
UN(rx);
UN(ry);
2000-12-08 14:54:42 -08:00
}
static void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_act_move_stop (E_Object *object, E_Action *a, void *data, int x, int y, int rx, int ry)
2000-12-08 14:54:42 -08:00
{
E_Border *b;
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
b = (E_Border*) object;
if (!b)
b = e_border_current_focused();
if (!b)
D_RETURN;
if (b->client.fixed)
D_RETURN;
b->hold_changes = 0; /* if non opaque */
2000-12-08 14:54:42 -08:00
b->current.requested.x = b->current.x;
b->current.requested.y = b->current.y;
b->changed = 1;
b->mode.move = 0;
b->current.requested.dx = 0;
b->current.requested.dy = 0;
b->previous.requested.dx = 0;
b->previous.requested.dy = 0;
b->changed = 1;
b->current.requested.visible = 1;
b->current.visible = 1;
2000-12-08 14:54:42 -08:00
e_border_adjust_limits(b);
e_guides_hide();
2001-10-07 23:53:26 -07:00
e_desktops_add_border(b->desk, b);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
UN(a);
UN(data);
UN(x);
UN(y);
UN(rx);
UN(ry);
2000-12-08 14:54:42 -08:00
}
static void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_act_move_cont (E_Object *object, E_Action *a, void *data, int x, int y, int rx, int ry, int dx, int dy)
2000-12-08 14:54:42 -08:00
{
E_Border *b;
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
2000-12-08 14:54:42 -08:00
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
b = (E_Border*) object;
if (!b)
b = e_border_current_focused();
if (!b)
D_RETURN;
if (b->client.fixed)
D_RETURN;
2000-12-08 14:54:42 -08:00
b->current.requested.x += dx;
b->current.requested.y += dy;
if (dx != 0) b->current.requested.dx = dx;
if (dy != 0) b->current.requested.dy = dy;
b->changed = 1;
e_border_adjust_limits(b);
{
char buf[1024];
e_border_print_pos(buf, b);
e_guides_move(b->current.x, b->current.y);
e_guides_resize(b->current.w, b->current.h);
e_guides_display_text(buf);
}
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
UN(a);
UN(data);
UN(x);
UN(y);
UN(rx);
UN(ry);
2000-12-08 14:54:42 -08:00
}
static void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_act_resize_start (E_Object *object, E_Action *a, void *data, int x, int y, int rx, int ry)
2000-12-08 14:54:42 -08:00
{
E_Border *b;
E_Guides_Mode resize_mode = E_GUIDES_BOX;
double align_x = 0.5;
double align_y = 0.5;
E_Guides_Location display_loc = E_GUIDES_DISPLAY_LOCATION_WINDOW_MIDDLE;
E_CFG_INT(cfg_window_resize_mode, "settings", "/window/resize/mode", E_GUIDES_BOX);
E_CFG_FLOAT(cfg_guides_display_x, "settings", "/guides/display/x", 0.5);
E_CFG_FLOAT(cfg_guides_display_y, "settings", "/guides/display/y", 0.5);
E_CFG_INT(cfg_guides_display_location, "settings", "/guides/display/location", E_GUIDES_DISPLAY_LOCATION_WINDOW_MIDDLE);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
2000-12-08 14:54:42 -08:00
E_CONFIG_INT_GET(cfg_window_resize_mode, resize_mode);
E_CONFIG_FLOAT_GET(cfg_guides_display_x, align_x);
E_CONFIG_FLOAT_GET(cfg_guides_display_y, align_y);
E_CONFIG_INT_GET(cfg_guides_display_location, display_loc);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
b = (E_Border*) object;
if (!b) b = e_border_current_focused();
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
if (!b) D_RETURN;
if (b->client.min.w == b->client.max.w) D_RETURN;
if (b->client.min.h == b->client.max.h) D_RETURN;
if (b->current.shaded != 0) D_RETURN;
if (resize_mode >= E_GUIDES_BOX)
b->hold_changes = 1; /* if non opaque */
ecore_window_gravity_set(b->win.client, StaticGravity);
ecore_window_gravity_set(b->win.l, NorthWestGravity);
ecore_window_gravity_set(b->win.r, SouthEastGravity);
ecore_window_gravity_set(b->win.t, NorthWestGravity);
ecore_window_gravity_set(b->win.b, SouthEastGravity);
ecore_window_gravity_set(b->win.input, NorthWestGravity);
ecore_window_gravity_set(b->win.container, NorthWestGravity);
/* 1 | 2 */
2000-12-08 14:54:42 -08:00
/* --+-- */
/* 3 | 4 */
2000-12-08 14:54:42 -08:00
if (x > (b->current.w / 2))
{
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
if (y > (b->current.h / 2))
{
b->mode.resize = 4;
/* e_border_set_gravity(b, NorthWestGravity); */
/* ecore_window_gravity_set(b->win.container, SouthEastGravity);*/
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
}
else
{
b->mode.resize = 2;
/* e_border_set_gravity(b, SouthWestGravity);*/
/* ecore_window_gravity_set(b->win.container, NorthEastGravity);*/
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
}
2000-12-08 14:54:42 -08:00
}
else
{
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
if (y > (b->current.h / 2))
{
b->mode.resize = 3;
/* e_border_set_gravity(b, NorthEastGravity);*/
/* ecore_window_gravity_set(b->win.container, SouthWestGravity);*/
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
}
else
{
b->mode.resize = 1;
/* e_border_set_gravity(b, SouthEastGravity);*/
/* ecore_window_gravity_set(b->win.container, NorthWestGravity); */
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
}
2000-12-08 14:54:42 -08:00
}
{
char buf[PATH_MAX];
e_border_print_size(buf, b);
e_guides_set_display_alignment(align_x, align_y);
e_guides_set_mode(resize_mode);
e_guides_set_display_location(display_loc);
e_guides_display_text(buf);
sprintf(buf, "%s/%s", e_config_get("images"), "win_shadow_icon.png");
e_guides_display_icon(buf);
e_guides_move(b->current.x, b->current.y);
e_guides_resize(b->current.w, b->current.h);
e_guides_show();
}
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
UN(a);
UN(data);
UN(rx);
UN(ry);
2000-12-08 14:54:42 -08:00
}
static void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_act_resize_stop (E_Object *object, E_Action *a, void *data, int x, int y, int rx, int ry)
2000-12-08 14:54:42 -08:00
{
E_Border *b;
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
b = (E_Border*) object;
if (!b) b = e_border_current_focused();
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
if (!b) D_RETURN;
if (b->client.min.w == b->client.max.w) D_RETURN;
if (b->client.min.h == b->client.max.h) D_RETURN;
if (b->current.shaded != 0) D_RETURN;
b->hold_changes = 0; /* if non opaque */
2000-12-08 14:54:42 -08:00
b->current.requested.x = b->current.x;
b->current.requested.y = b->current.y;
b->current.requested.w = b->current.w;
b->current.requested.h = b->current.h;
b->mode.resize = 0;
b->changed = 1;
e_border_adjust_limits(b);
ecore_window_gravity_set(b->win.client, NorthWestGravity);
e_border_set_gravity(b, NorthWestGravity);
e_guides_hide();
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
UN(a);
UN(data);
UN(x);
UN(y);
UN(rx);
UN(ry);
2000-12-08 14:54:42 -08:00
}
static void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_act_resize_cont (E_Object *object, E_Action *a, void *data, int x, int y, int rx, int ry, int dx, int dy)
2000-12-08 14:54:42 -08:00
{
E_Border *b;
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
2000-12-08 14:54:42 -08:00
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
b = (E_Border*) object;
if (!b) b = e_border_current_focused();
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
if (!b) D_RETURN;
if (b->client.min.w == b->client.max.w) D_RETURN;
if (b->client.min.h == b->client.max.h) D_RETURN;
if (b->current.shaded != 0) D_RETURN;
if (b->mode.resize == 1)
2000-12-08 14:54:42 -08:00
{
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
b->current.requested.w -= dx;
b->current.requested.h -= dy;
b->current.requested.x += dx;
b->current.requested.y += dy;
2000-12-08 14:54:42 -08:00
}
else if (b->mode.resize == 2)
2000-12-08 14:54:42 -08:00
{
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
b->current.requested.w += dx;
b->current.requested.h -= dy;
b->current.requested.y += dy;
2000-12-08 14:54:42 -08:00
}
else if (b->mode.resize == 3)
2000-12-08 14:54:42 -08:00
{
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
b->current.requested.w -= dx;
b->current.requested.h += dy;
b->current.requested.x += dx;
2000-12-08 14:54:42 -08:00
}
else if (b->mode.resize == 4)
2000-12-08 14:54:42 -08:00
{
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
b->current.requested.w += dx;
b->current.requested.h += dy;
2000-12-08 14:54:42 -08:00
}
b->changed = 1;
e_border_adjust_limits(b);
{
char buf[1024];
e_border_print_size(buf, b);
e_guides_move(b->current.x, b->current.y);
e_guides_resize(b->current.w, b->current.h);
e_guides_display_text(buf);
}
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
UN(a);
UN(data);
UN(x);
UN(y);
UN(rx);
UN(ry);
2000-12-08 14:54:42 -08:00
}
static void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_act_resize_h_start (E_Object *object, E_Action *a, void *data, int x, int y, int rx, int ry)
2000-12-08 14:54:42 -08:00
{
E_Border *b;
E_Guides_Mode resize_mode = E_GUIDES_BOX;
double align_x = 0.5;
double align_y = 0.5;
E_Guides_Location display_loc = E_GUIDES_DISPLAY_LOCATION_WINDOW_MIDDLE;
E_CFG_INT(cfg_window_resize_mode, "settings", "/window/resize/mode", E_GUIDES_BOX);
E_CFG_FLOAT(cfg_guides_display_x, "settings", "/guides/display/x", 0.5);
E_CFG_FLOAT(cfg_guides_display_y, "settings", "/guides/display/y", 0.5);
E_CFG_INT(cfg_guides_display_location, "settings", "/guides/display/location", E_GUIDES_DISPLAY_LOCATION_WINDOW_MIDDLE);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
2000-12-08 14:54:42 -08:00
E_CONFIG_INT_GET(cfg_window_resize_mode, resize_mode);
E_CONFIG_FLOAT_GET(cfg_guides_display_x, align_x);
E_CONFIG_FLOAT_GET(cfg_guides_display_y, align_y);
E_CONFIG_INT_GET(cfg_guides_display_location, display_loc);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
b = (E_Border*) object;
if (!b) b = e_border_current_focused();
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
if (!b) D_RETURN;
if (b->client.min.w == b->client.max.w) D_RETURN;
if (b->current.shaded != 0) D_RETURN;
if (resize_mode >= E_GUIDES_BOX)
b->hold_changes = 1; /* if non opaque */
ecore_window_gravity_set(b->win.client, StaticGravity);
ecore_window_gravity_set(b->win.l, NorthWestGravity);
ecore_window_gravity_set(b->win.r, SouthEastGravity);
ecore_window_gravity_set(b->win.t, NorthWestGravity);
ecore_window_gravity_set(b->win.b, SouthEastGravity);
ecore_window_gravity_set(b->win.input, NorthWestGravity);
ecore_window_gravity_set(b->win.container, NorthWestGravity);
/* 5 | 6 */
2000-12-08 14:54:42 -08:00
if (x > (b->current.w / 2))
{
b->mode.resize = 6;
/* e_border_set_gravity(b, NorthWestGravity);*/
2000-12-08 14:54:42 -08:00
}
else
{
b->mode.resize = 5;
/* e_border_set_gravity(b, NorthEastGravity);*/
2000-12-08 14:54:42 -08:00
}
{
char buf[PATH_MAX];
e_border_print_size(buf, b);
e_guides_set_display_alignment(align_x, align_y);
e_guides_set_mode(resize_mode);
e_guides_set_display_location(display_loc);
e_guides_display_text(buf);
sprintf(buf, "%s/%s", e_config_get("images"), "win_shadow_icon.png");
e_guides_display_icon(buf);
e_guides_move(b->current.x, b->current.y);
e_guides_resize(b->current.w, b->current.h);
e_guides_show();
}
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
UN(a);
UN(data);
UN(y);
UN(rx);
UN(ry);
2000-12-08 14:54:42 -08:00
}
static void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_act_resize_h_stop (E_Object *object, E_Action *a, void *data, int x, int y, int rx, int ry)
2000-12-08 14:54:42 -08:00
{
E_Border *b;
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
b = (E_Border*) object;
if (!b) b = e_border_current_focused();
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
if (!b) D_RETURN;
if (b->client.min.w == b->client.max.w) D_RETURN;
if (b->current.shaded != 0) D_RETURN;
b->hold_changes = 0; /* if non opaque */
2000-12-08 14:54:42 -08:00
b->current.requested.x = b->current.x;
b->current.requested.y = b->current.y;
b->current.requested.w = b->current.w;
b->current.requested.h = b->current.h;
b->mode.resize = 0;
b->changed = 1;
e_border_adjust_limits(b);
ecore_window_gravity_set(b->win.client, NorthWestGravity);
e_border_set_gravity(b, NorthWestGravity);
e_guides_hide();
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
UN(a);
UN(data);
UN(x);
UN(y);
UN(rx);
UN(ry);
2000-12-08 14:54:42 -08:00
}
static void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_act_resize_h_cont (E_Object *object, E_Action *a, void *data, int x, int y, int rx, int ry, int dx, int dy)
2000-12-08 14:54:42 -08:00
{
E_Border *b;
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
b = (E_Border*) object;
if (!b) b = e_border_current_focused();
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
if (!b) D_RETURN;
if (b->client.min.w == b->client.max.w) D_RETURN;
if (b->current.shaded != 0) D_RETURN;
if (b->mode.resize == 5)
2000-12-08 14:54:42 -08:00
{
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
b->current.requested.w -= dx;
b->current.requested.x += dx;
2000-12-08 14:54:42 -08:00
}
else if (b->mode.resize == 6)
2000-12-08 14:54:42 -08:00
{
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
b->current.requested.w += dx;
2000-12-08 14:54:42 -08:00
}
b->changed = 1;
e_border_adjust_limits(b);
{
char buf[1024];
e_border_print_size(buf, b);
e_guides_move(b->current.x, b->current.y);
e_guides_resize(b->current.w, b->current.h);
e_guides_display_text(buf);
}
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
UN(a);
UN(data);
UN(x);
UN(y);
UN(rx);
UN(ry);
UN(dy);
2000-12-08 14:54:42 -08:00
}
static void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_act_resize_v_start (E_Object *object, E_Action *a, void *data, int x, int y, int rx, int ry)
2000-12-08 14:54:42 -08:00
{
E_Border *b;
E_Guides_Mode resize_mode = E_GUIDES_BOX;
double align_x = 0.5;
double align_y = 0.5;
E_Guides_Location display_loc = E_GUIDES_DISPLAY_LOCATION_WINDOW_MIDDLE;
E_CFG_INT(cfg_window_resize_mode, "settings", "/window/resize/mode", E_GUIDES_BOX);
E_CFG_FLOAT(cfg_guides_display_x, "settings", "/guides/display/x", 0.5);
E_CFG_FLOAT(cfg_guides_display_y, "settings", "/guides/display/y", 0.5);
E_CFG_INT(cfg_guides_display_location, "settings", "/guides/display/location", E_GUIDES_DISPLAY_LOCATION_WINDOW_MIDDLE);
2000-12-08 14:54:42 -08:00
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
E_CONFIG_INT_GET(cfg_window_resize_mode, resize_mode);
E_CONFIG_FLOAT_GET(cfg_guides_display_x, align_x);
E_CONFIG_FLOAT_GET(cfg_guides_display_y, align_y);
E_CONFIG_INT_GET(cfg_guides_display_location, display_loc);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
b = (E_Border*) object;
if (!b) b = e_border_current_focused();
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
if (!b) D_RETURN;
if (b->client.min.h == b->client.max.h) D_RETURN;
if (b->current.shaded != 0) D_RETURN;
if (resize_mode >= E_GUIDES_BOX)
b->hold_changes = 1; /* if non opaque */
ecore_window_gravity_set(b->win.client, StaticGravity);
ecore_window_gravity_set(b->win.l, NorthWestGravity);
ecore_window_gravity_set(b->win.r, SouthEastGravity);
ecore_window_gravity_set(b->win.t, NorthWestGravity);
ecore_window_gravity_set(b->win.b, SouthEastGravity);
ecore_window_gravity_set(b->win.input, NorthWestGravity);
ecore_window_gravity_set(b->win.container, NorthWestGravity);
2000-12-08 14:54:42 -08:00
/* 7 */
/* - */
/* 8 */
2000-12-08 14:54:42 -08:00
if (y > (b->current.h / 2))
{
b->mode.resize = 8;
/* e_border_set_gravity(b, NorthWestGravity);*/
2000-12-08 14:54:42 -08:00
}
else
{
b->mode.resize = 7;
/* e_border_set_gravity(b, SouthWestGravity);*/
2000-12-08 14:54:42 -08:00
}
{
char buf[PATH_MAX];
e_border_print_size(buf, b);
e_guides_set_display_alignment(align_x, align_y);
e_guides_set_mode(resize_mode);
e_guides_set_display_location(display_loc);
e_guides_display_text(buf);
sprintf(buf, "%s/%s", e_config_get("images"), "win_shadow_icon.png");
e_guides_display_icon(buf);
e_guides_move(b->current.x, b->current.y);
e_guides_resize(b->current.w, b->current.h);
e_guides_show();
}
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
UN(a);
UN(data);
UN(x);
UN(rx);
UN(ry);
2000-12-08 14:54:42 -08:00
}
static void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_act_resize_v_stop (E_Object *object, E_Action *a, void *data, int x, int y, int rx, int ry)
2000-12-08 14:54:42 -08:00
{
E_Border *b;
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
b = (E_Border*) object;
if (!b) b = e_border_current_focused();
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
if (!b) D_RETURN;
if (b->client.min.h == b->client.max.h) D_RETURN;
if (b->current.shaded != 0) D_RETURN;
b->hold_changes = 0; /* if non opaque */
2000-12-08 14:54:42 -08:00
b->current.requested.x = b->current.x;
b->current.requested.y = b->current.y;
b->current.requested.w = b->current.w;
b->current.requested.h = b->current.h;
b->mode.resize = 0;
e_border_adjust_limits(b);
ecore_window_gravity_set(b->win.client, NorthWestGravity);
e_border_set_gravity(b, NorthWestGravity);
2000-12-08 14:54:42 -08:00
b->changed = 1;
e_guides_hide();
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
UN(a);
UN(data);
UN(x);
UN(y);
UN(rx);
UN(ry);
2000-12-08 14:54:42 -08:00
}
static void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_act_resize_v_cont (E_Object *object, E_Action *a, void *data, int x, int y, int rx, int ry, int dx, int dy)
2000-12-08 14:54:42 -08:00
{
E_Border *b;
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
b = (E_Border*) object;
if (!b) b = e_border_current_focused();
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
if (!b) D_RETURN;
if (b->client.min.h == b->client.max.h) D_RETURN;
if (b->current.shaded != 0) D_RETURN;
if (b->mode.resize == 7)
2000-12-08 14:54:42 -08:00
{
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
b->current.requested.h -= dy;
b->current.requested.y += dy;
2000-12-08 14:54:42 -08:00
}
else if (b->mode.resize == 8)
2000-12-08 14:54:42 -08:00
{
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
b->current.requested.h += dy;
2000-12-08 14:54:42 -08:00
}
e_border_adjust_limits(b);
b->changed = 1;
{
char buf[1024];
e_border_print_size(buf, b);
e_guides_move(b->current.x, b->current.y);
e_guides_resize(b->current.w, b->current.h);
e_guides_display_text(buf);
}
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
UN(a);
UN(data);
UN(x);
UN(y);
UN(rx);
UN(ry);
UN(dx);
2000-12-08 14:54:42 -08:00
}
static void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_act_close_start (E_Object *object, E_Action *a, void *data, int x, int y, int rx, int ry)
2000-12-08 14:54:42 -08:00
{
E_Border *b;
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
b = (E_Border*) object;
if (!b) b = e_border_current_focused();
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
if (!b) D_RETURN;
if (b->client.is_desktop) D_RETURN;
2000-12-08 14:54:42 -08:00
if (b->win.client) e_icccm_delete(b->win.client);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
UN(a);
UN(data);
UN(x);
UN(y);
UN(rx);
UN(ry);
2000-12-08 14:54:42 -08:00
}
static void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_act_kill_start (E_Object *object, E_Action *a, void *data, int x, int y, int rx, int ry)
2000-12-08 14:54:42 -08:00
{
E_Border *b;
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
b = (E_Border*) object;
if (!b) b = e_border_current_focused();
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
if (!b) D_RETURN;
if (b->client.is_desktop) D_RETURN;
if (b->win.client) ecore_window_kill_client(b->win.client);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
UN(a);
UN(data);
UN(x);
UN(y);
UN(rx);
UN(ry);
2000-12-08 14:54:42 -08:00
}
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
static void e_act_cb_shade(int val, void *data);
static void
e_act_cb_shade(int val, void *data)
{
E_Border *b;
static double t = 0.0;
double dif;
int si;
int pix_per_sec = 3200;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
b = data;
if (!b) b = e_border_current_focused();
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
if (!b) D_RETURN;
if (b->client.is_desktop)
D_RETURN;
if (val == 0)
{
t = ecore_get_time();
ecore_window_gravity_set(b->win.client, SouthWestGravity);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_action_del_timer(E_OBJECT(b), "shader");
e_action_add_timer(E_OBJECT(b), "shader");
}
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
dif = ecore_get_time() - t;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
si = (int)(dif * (double)pix_per_sec);
if (si > b->client.h) si = b->client.h;
b->current.shaded = si;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
b->changed = 1;
e_border_adjust_limits(b);
e_border_apply_border(b);
if (si < b->client.h)
ecore_add_event_timer("shader", 0.01, e_act_cb_shade, 1, data);
else
{
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_action_del_timer(E_OBJECT(b), "shader");
ecore_window_gravity_reset(b->win.client);
}
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
}
static void e_act_cb_unshade(int val, void *data);
static void
e_act_cb_unshade(int val, void *data)
{
E_Border *b;
static double t = 0.0;
double dif;
int si;
int pix_per_sec = 3200;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
b = data;
if (!b) b = e_border_current_focused();
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
if (!b) D_RETURN;
if (b->client.is_desktop) D_RETURN;
if (val == 0)
{
t = ecore_get_time();
ecore_window_gravity_set(b->win.client, SouthWestGravity);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_action_del_timer(E_OBJECT(b), "shader");
e_action_add_timer(E_OBJECT(b), "shader");
}
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
dif = ecore_get_time() - t;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
si = b->client.h - (int)(dif * (double)pix_per_sec);
if (si < 0) si = 0;
b->current.shaded = si;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
b->changed = 1;
e_border_adjust_limits(b);
e_border_apply_border(b);
if (si > 0)
ecore_add_event_timer("shader", 0.01, e_act_cb_unshade, 1, data);
else
{
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_action_del_timer(E_OBJECT(b), "shader");
ecore_window_gravity_reset(b->win.client);
}
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
}
2000-12-08 14:54:42 -08:00
static void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_act_shade_start (E_Object *object, E_Action *a, void *data, int x, int y, int rx, int ry)
2000-12-08 14:54:42 -08:00
{
E_Border *b;
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
b = (E_Border*) object;
if (!b) b = e_border_current_focused();
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
if (!b) D_RETURN;
if (b->client.is_desktop)
D_RETURN;
if (b->current.shaded == 0)
e_act_cb_shade(0, b);
else
e_act_cb_unshade(0, b);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
UN(a);
UN(data);
UN(x);
UN(y);
UN(rx);
UN(ry);
2000-12-08 14:54:42 -08:00
}
static void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_act_raise_start (E_Object *object, E_Action *a, void *data, int x, int y, int rx, int ry)
2000-12-08 14:54:42 -08:00
{
E_Border *b;
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
b = (E_Border*) object;
if (!b) b = e_border_current_focused();
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
if (!b) D_RETURN;
if (b->client.is_desktop) D_RETURN;
2000-12-08 14:54:42 -08:00
e_border_raise(b);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
UN(a);
UN(data);
UN(x);
UN(y);
UN(rx);
UN(ry);
2000-12-08 14:54:42 -08:00
}
static void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_act_lower_start (E_Object *object, E_Action *a, void *data, int x, int y, int rx, int ry)
2000-12-08 14:54:42 -08:00
{
E_Border *b;
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
b = (E_Border*) object;
if (!b) b = e_border_current_focused();
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
if (!b) D_RETURN;
if (b->client.is_desktop) D_RETURN;
2000-12-08 14:54:42 -08:00
e_border_lower(b);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
UN(a);
UN(data);
UN(x);
UN(y);
UN(rx);
UN(ry);
2000-12-08 14:54:42 -08:00
}
static void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_act_raise_lower_start (E_Object *object, E_Action *a, void *data, int x, int y, int rx, int ry)
2000-12-08 14:54:42 -08:00
{
E_Border *b;
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
b = (E_Border*) object;
if (!b) b = e_border_current_focused();
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
if (!b) D_RETURN;
if (b->client.is_desktop) D_RETURN;
D_RETURN;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
UN(a);
UN(data);
UN(x);
UN(y);
UN(rx);
UN(ry);
2000-12-08 14:54:42 -08:00
}
static void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_act_exec_start (E_Object *object, E_Action *a, void *data, int x, int y, int rx, int ry)
2000-12-08 14:54:42 -08:00
{
char *exe;
2000-12-08 14:54:42 -08:00
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
exe = (char *) a->params;
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
if(!exe) D_RETURN;
e_exec_run(exe);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
UN(a);
UN(data);
UN(x);
UN(y);
UN(rx);
UN(ry);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
UN(object);
2000-12-08 14:54:42 -08:00
}
static void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_act_menu_start (E_Object *object, E_Action *a, void *data, int x, int y, int rx, int ry)
2000-12-08 14:54:42 -08:00
{
E_Border *b;
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
b = (E_Border*) object;
if (!b) b = e_border_current_focused();
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
if (!b) D_RETURN;
if (b->client.is_desktop) D_RETURN;
D_RETURN;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
UN(a);
UN(data);
UN(x);
UN(y);
UN(rx);
UN(ry);
2000-12-08 14:54:42 -08:00
}
static void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_act_exit_start (E_Object *object, E_Action *a, void *data, int x, int y, int rx, int ry)
2000-12-08 14:54:42 -08:00
{
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
2000-12-08 14:54:42 -08:00
exit(0);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN;
UN(object);
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
UN(a);
UN(data);
UN(x);
UN(y);
UN(rx);
UN(ry);
2000-12-08 14:54:42 -08:00
}
static void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_act_restart_start (E_Object *object, E_Action *a, void *data, int x, int y, int rx, int ry)
2000-12-08 14:54:42 -08:00
{
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
e_exec_restart();
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN;
UN(object);
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
UN(a);
UN(data);
UN(x);
UN(y);
UN(rx);
UN(ry);
2000-12-08 14:54:42 -08:00
}
static void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_act_stick_start (E_Object *object, E_Action *a, void *data, int x, int y, int rx, int ry)
2000-12-08 14:54:42 -08:00
{
E_Border *b;
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
b = (E_Border*) object;
if (!b) b = e_border_current_focused();
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
if (!b) D_RETURN;
if (b->client.is_desktop) D_RETURN;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
if (b->client.sticky) b->client.sticky = 0;
else b->client.sticky = 1;
b->changed = 1;
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
UN(a);
UN(data);
UN(x);
UN(y);
UN(rx);
UN(ry);
2000-12-08 14:54:42 -08:00
}
static void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_act_sound_start (E_Object *object, E_Action *a, void *data, int x, int y, int rx, int ry)
2000-12-08 14:54:42 -08:00
{
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
D_RETURN;
UN(object);
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
UN(a);
UN(data);
UN(x);
UN(y);
UN(rx);
UN(ry);
2000-12-08 14:54:42 -08:00
}
static void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_act_iconify_start (E_Object *object, E_Action *a, void *data, int x, int y, int rx, int ry)
2000-12-08 14:54:42 -08:00
{
E_Border *b;
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
b = (E_Border*) object;
if (!b) b = e_border_current_focused();
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
if (!b) D_RETURN;
if (b->client.is_desktop) D_RETURN;
D_RETURN;
UN(object);
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
UN(a);
UN(data);
UN(x);
UN(y);
UN(rx);
UN(ry);
2000-12-08 14:54:42 -08:00
}
static void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_act_max_start (E_Object *object, E_Action *a, void *data, int x, int y, int rx, int ry)
2000-12-08 14:54:42 -08:00
{
E_Border *b;
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
b = (E_Border*) object;
if (!b) b = e_border_current_focused();
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
if (!b) D_RETURN;
if (b->client.is_desktop) D_RETURN;
if (b->current.shaded > 0) D_RETURN;
if ((b->mode.move) || (b->mode.resize)) D_RETURN;
b->mode.move = 0;
b->mode.resize = 0;
if (b->max.is)
{
b->current.requested.x = b->max.x;
b->current.requested.y = b->max.y;
b->current.requested.w = b->max.w;
b->current.requested.h = b->max.h;
b->changed = 1;
b->max.is = 0;
e_border_adjust_limits(b);
b->current.requested.x = b->current.x;
b->current.requested.y = b->current.y;
b->current.requested.w = b->current.w;
b->current.requested.h = b->current.h;
}
else
{
b->max.x = b->current.x;
b->max.y = b->current.y;
b->max.w = b->current.w;
b->max.h = b->current.h;
b->current.requested.x = 0;
b->current.requested.y = 0;
b->current.requested.w = b->desk->real.w;
b->current.requested.h = b->desk->real.h;
b->changed = 1;
b->max.is = 1;
e_border_adjust_limits(b);
b->current.requested.x = b->current.x;
b->current.requested.y = b->current.y;
b->current.requested.w = b->current.w;
b->current.requested.h = b->current.h;
}
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
UN(a);
UN(data);
UN(x);
UN(y);
UN(rx);
UN(ry);
2000-12-08 14:54:42 -08:00
}
static void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_act_snap_start (E_Object *object, E_Action *a, void *data, int x, int y, int rx, int ry)
2000-12-08 14:54:42 -08:00
{
E_Border *b;
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
b = (E_Border*) object;
if (!b)
b = e_border_current_focused();
if (!b)
D_RETURN;
D_RETURN;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
UN(a);
UN(data);
UN(x);
UN(y);
UN(rx);
UN(ry);
2000-12-08 14:54:42 -08:00
}
static void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_act_zoom_start (E_Object *object, E_Action *a, void *data, int x, int y, int rx, int ry)
2000-12-08 14:54:42 -08:00
{
E_Border *b;
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
b = (E_Border*) object;
if (!b)
b = e_border_current_focused();
if (!b)
D_RETURN;
D_RETURN;
Sorry guys.. I had to revert a bunch of changes.. that's life.. but READ the following (it's in the README now) ------------------------------------------------------------------------------- Enlightenment 0.17.0 CVS Code.... ------------------------------------------------------------------------------- The Rasterman - raster@valinux.com, raster@rasterman.com ******************************************************************************* **************** READ THIS! It is of the UTMOST IMPORTANCE! ******************* ******************************************************************************* This is the source code for Enlightenment 0.17 - If you got this you got it from Enlightenment's CVS repository - or from someone who took it out of the CVS repository. The CVS repository is full of code *IN DEVELOPMENT* - that often means it's in the middle of being worked on and may install strange things in strange places, make a mess, and may not even be compatible with a final release. If you at all use this code, you are HEAVILY URGED, when it is finally released, to remove all traces of anything this CVS code base has installed on your system (it is COMPLETELY up to you to keep track of that - do NOT expect any help), and then install the full release on a cleaned system. Don't come asking "can I just keep using CVS" oonce things are released - thqat is the reason I pu this paragraph here - so you don't ask. The asnwer is the same as above - if there is a proper final release use that. CVS is really only for those havily hacking on the code. Now we have that warning over and done with. How to build and install from CVS? $ ./autogen.sh && make $ su Password: <- as root -> # make install You should be able to use the binary of enlightenment as a window manager. you might be advised for cleanliness to do $ ./autogen.sh --prefix=/usr/local/e-17 so it installs relative to the /usr/local/e-17 directory and keeps all the e-17 development code and data in that tree so it is easily removed when the time codes. NOTES: Read these carefully! Enlightenment does not check for previously running Window Managers right now - so you need to make sure no other WM is running - E will not do that for you. Enlightenment has no menus or keybindings or any way of launching applications right now - you'll have to figure out an alternative way of doing it. Enlightenment only handles a small subset of ICCCM and thus will have bugs - some applications will not behave correctly and may apear in odd spots or not resize or place themselves properly etc. Expect this - it's code being worked on. Just be happy it does as much as it already does. Enlightenment RELIES on lots of libraires that have been written. Ecore, Ebits, Evas, Edb, Imlib2 just to mention a few. Especially Ebits, Ecore and Evas change in CVS often - you will need the absolute latest of these if you wish Enlightenment 0.17 code to run properly or compile. If you update Enlightenment from CVS update these too to get any changes they have in their trees. If you plan on working on the code... STOP! don't rush in and work on it - even if you have CVS commit access - EXPECT me (Raster) to revert any changes you make if you do this - regardless of the changes and how much work you put into them. First read the code well and LEARN it. If you have questions about some of the more obscure hidden program flow - ASK - but don't go tampering with it - Enlightenment 0.17's code is much more complex and intricate than E 0.16 - but at the same time it's much cleaner and more object oriented. Learn it well first. Some parts of E 0.17 are "hacked" with hard-coded stuff, just so, for now, it works. They will be virtualized and imporved over time. If you have plans - tell me about them first - discuss them before you go impliment them. I know I already have a lot of the components of E 0.17's code planned in my head - but I won't get to them for a while - and if people go impliment or hack bad stuff in, it means I have to spend lots of time fixing something that is bad in the first place, or we end up doing duplicate work. There *IS* a plan - believe it or not - but to be honest - it's more complex and large than I can just write down in a README, so talk about your ideas first. I'm going to be ruthless in keeping the code neat, clean and free of nasty hacks (except ones I put in as temporary stop-gap measures to make the thing work - since I know where those are and what I need to do to do it right). If you can't find me or I don't reply to your e-mail - don't get impatient - just wait. I currently have no network access at home, so I'm doing a chunk of code offline. I'll get to your mail and queries as time allows. If you have problems with the code or bugs to report, kindly forward them to /dev/null (the code is in now way or form ready for bug reports - I don't want crap filling my mailbox). I hope that clears things up for now. SVN revision: 3976
2000-12-11 12:08:38 -08:00
UN(a);
UN(data);
UN(x);
UN(y);
UN(rx);
UN(ry);
2000-12-08 14:54:42 -08:00
}
static void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_act_desk_start (E_Object *object, E_Action *a, void *data, int x, int y, int rx, int ry)
{
int desk = 0;
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
if (a->params)
desk = atoi(a->params);
e_desktops_goto_desk(desk);
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN;
UN(object);
UN(a);
UN(data);
UN(x);
UN(y);
UN(rx);
UN(ry);
}
static void
e_act_desk_rel_start (E_Object *object, E_Action *a, void *data, int x, int y, int rx, int ry)
{
int desk = 0;
int desk_max = e_desktops_get_num () - 1;
D_ENTER;
if (a->params)
desk = atoi(a->params) + e_desktops_get_current();
if (desk < 0)
desk = desk_max;
else if (desk > desk_max)
desk = 0;
e_desktops_goto_desk(desk);
D_RETURN;
UN(object);
UN(a);
UN(data);
UN(x);
UN(y);
UN(rx);
UN(ry);
}
static void
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
e_act_raise_next_start (E_Object *object, E_Action *a, void *data, int x, int y, int rx, int ry)
{
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_ENTER;
e_border_raise_next();
Alright, I spent some time now reading e17's code. Here's what I've changed, this is big, so read this carefully :) * I've added debugging macros for messages and function call tracing. Usage: D("Creating item %i %i %i\n", x, y, z); Define DEBUG to use the D macro. D_ENTER; D_RETURN; D_RETURN_(x); These are for call tracing. Use D_RETURN_(x) when returning something from a function. Define DEBUG_NEST to use this. * added iconbar header file to Makefile.am * added proper new()/cleanup() calls for E_Delayed_Action; * I've completely rewritten the object and observer handling. Bye bye macros, this was nasty. It'll be hard enough to avoid leaks with usecounting in C. We now basically have the same system as gtk. There's a clear separation of observer and object code now. An E_Object by itself has nothing to do with observing or being observed, therefore, there are now E_Observers and E_Observees that are derived from E_Object. IMPORTANT: The cleanup system now reflects the reference count system, therefore, all ..._free() calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling now is as follows: - The cleanup functions clean up everything that is contained in a struct, but NOT the struct itself. Instead of the final free() call, they call the destructor of the base class. The calls will walk up the hierarchy and clean up what's contained in every struct, and the final e_object_cleanup() will free the structure itself. E_Delayed_Action is a good example. - The only calls that influence the reference count are e_object_ref() and e_object_unref(). If you need to do things before an object gets destroyed, you can query the use count using e_object_get_usecount() and check if it's equal to 1. So this: OBJ_UNREF(b); OBJ_IF_FREE(b) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); OBJ_FREE(b); } now is this: if (e_object_get_usecount(E_OBJECT(b)) == 1) { ecore_window_reparent(e->win, 0, 0, 0); e_icccm_release(e->win); } e_object_unref(E_OBJECT(b)); object.h and observer.h are completely commented, it shouldn't be too hard to understand. This'll need to be documented in the manual anyway. * E_Objects are now used in lots of places where void* were used as pointers to objects before, especially in the actions code. This is obviously better, as it will generate compiler warnings when people want to pass things to functions that expect E_Objects. This could probably be more restrictive. * Added typedefs for the function prototypes in E_Action_Impl. Those fat signatures were just painful to read in the function declarations/implementations. * I've also tried to give parameters more useful names. Calling an object "o" is a lot of fun when you want to grep for it. * Included is also Graham's latest menu.c patch. Sorry for the delay, Graham. * I've added checks to the menu code that make sure that menus don't pop up when they're empty (which resulted in a little useless rectangle). I guess that's it for now. Sorry if I broke anything, but this was necessary imho. SVN revision: 5605
2001-11-02 09:07:52 -08:00
D_RETURN;
UN(object);
UN(a);
UN(data);
UN(x);
UN(y);
UN(rx);
UN(ry);
}