2001-09-30 15:24:24 -07:00
|
|
|
#include "cursors.h"
|
2001-07-30 09:59:37 -07:00
|
|
|
#include "border.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"
|
2001-07-30 09:59:37 -07:00
|
|
|
#include "actions.h"
|
2001-09-24 14:21:25 -07:00
|
|
|
#include "delayed.h"
|
2001-07-30 09:59:37 -07:00
|
|
|
#include "desktops.h"
|
|
|
|
#include "resist.h"
|
|
|
|
#include "icccm.h"
|
2001-11-03 01:07:40 -08:00
|
|
|
#include "file.h"
|
2001-07-30 09:59:37 -07:00
|
|
|
#include "util.h"
|
2001-09-24 14:21:25 -07:00
|
|
|
#include "place.h"
|
2001-10-08 00:32:54 -07:00
|
|
|
#include "match.h"
|
2001-11-03 23:38:42 -08:00
|
|
|
#include "focus.h"
|
2001-11-24 23:18:49 -08:00
|
|
|
#include "menu.h"
|
2001-12-06 00:06:52 -08:00
|
|
|
#include "exec.h"
|
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
|
|
|
/* Window border rendering, querying, setting & modification code */
|
|
|
|
|
|
|
|
/* globals local to window borders */
|
|
|
|
static Evas_List evases = NULL;
|
|
|
|
static Evas_List borders = NULL;
|
|
|
|
|
|
|
|
static int mouse_x, mouse_y, mouse_win_x, mouse_win_y;
|
|
|
|
static int mouse_buttons = 0;
|
|
|
|
|
|
|
|
static int border_mouse_x = 0;
|
|
|
|
static int border_mouse_y = 0;
|
|
|
|
static int border_mouse_buttons = 0;
|
|
|
|
|
2001-10-17 15:34:27 -07:00
|
|
|
static Ecore_Event *current_ev = 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
|
|
|
|
2001-09-24 14:21:25 -07:00
|
|
|
/* Global delayed window raise action */
|
|
|
|
E_Delayed_Action *delayed_window_raise = NULL;
|
|
|
|
|
2001-11-01 15:54:48 -08:00
|
|
|
static void e_idle(void *data);
|
2001-10-17 15:34:27 -07:00
|
|
|
static void e_map_request(Ecore_Event * ev);
|
|
|
|
static void e_configure_request(Ecore_Event * ev);
|
|
|
|
static void e_property(Ecore_Event * ev);
|
|
|
|
static void e_unmap(Ecore_Event * ev);
|
|
|
|
static void e_destroy(Ecore_Event * ev);
|
|
|
|
static void e_circulate_request(Ecore_Event * ev);
|
|
|
|
static void e_reparent(Ecore_Event * ev);
|
|
|
|
static void e_shape(Ecore_Event * ev);
|
2001-11-01 15:54:48 -08:00
|
|
|
static void e_focus_in(Ecore_Event * ev);
|
|
|
|
static void e_focus_out(Ecore_Event * ev);
|
2001-10-17 15:34:27 -07:00
|
|
|
static void e_colormap(Ecore_Event * ev);
|
|
|
|
static void e_mouse_down(Ecore_Event * ev);
|
|
|
|
static void e_mouse_up(Ecore_Event * ev);
|
|
|
|
static void e_mouse_in(Ecore_Event * ev);
|
|
|
|
static void e_mouse_out(Ecore_Event * ev);
|
2001-11-01 15:54:48 -08:00
|
|
|
static void e_window_expose(Ecore_Event * ev);
|
2000-12-09 16:29:46 -08:00
|
|
|
|
2001-10-12 13:13:01 -07:00
|
|
|
static void e_cb_mouse_in(void *data, Ebits_Object o, char *class, int bt,
|
|
|
|
int x, int y, int ox, int oy, int ow, int oh);
|
|
|
|
static void e_cb_mouse_out(void *data, Ebits_Object o, char *class, int bt,
|
|
|
|
int x, int y, int ox, int oy, int ow, int oh);
|
|
|
|
static void e_cb_mouse_down(void *data, Ebits_Object o, char *class, int bt,
|
|
|
|
int x, int y, int ox, int oy, int ow, int oh);
|
|
|
|
static void e_cb_mouse_up(void *data, Ebits_Object o, char *class, int bt,
|
|
|
|
int x, int y, int ox, int oy, int ow, int oh);
|
|
|
|
static void e_cb_mouse_move(void *data, Ebits_Object o, char *class, int bt,
|
|
|
|
int x, int y, int ox, int oy, int ow, int oh);
|
2000-12-09 16:29:46 -08:00
|
|
|
|
2001-10-17 15:34:27 -07:00
|
|
|
static void e_cb_border_mouse_in(E_Border *b, Ecore_Event *e);
|
|
|
|
static void e_cb_border_mouse_out(E_Border *b, Ecore_Event *e);
|
|
|
|
static void e_cb_border_mouse_down(E_Border *b, Ecore_Event *e);
|
|
|
|
static void e_cb_border_mouse_up(E_Border *b, Ecore_Event *e);
|
|
|
|
static void e_cb_border_mouse_move(E_Border *b, Ecore_Event *e);
|
2000-12-09 16:29:46 -08:00
|
|
|
static void e_cb_border_move_resize(E_Border *b);
|
|
|
|
static void e_cb_border_visibility(E_Border *b);
|
|
|
|
|
|
|
|
static void e_border_poll(int val, void *data);
|
2001-11-08 17:11:44 -08:00
|
|
|
static void e_border_cleanup(E_Border *b);
|
2000-12-09 16:29:46 -08:00
|
|
|
|
2001-10-30 03:07:12 -08:00
|
|
|
static int e_border_replay_query(Ecore_Event_Mouse_Down *ev)
|
|
|
|
{
|
|
|
|
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;
|
|
|
|
|
2001-10-30 03:07:12 -08:00
|
|
|
b = e_border_find_by_window(ev->win);
|
|
|
|
if (b)
|
|
|
|
{
|
|
|
|
int focus_mode;
|
|
|
|
E_CFG_INT(cfg_focus_mode, "settings", "/focus/mode", 0);
|
|
|
|
|
|
|
|
E_CONFIG_INT_GET(cfg_focus_mode, focus_mode);
|
|
|
|
if ((focus_mode == 2) && (ev->mods == ECORE_EVENT_KEY_MODIFIER_NONE))
|
|
|
|
/* FIXME: also if pass click always set */
|
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_(1);
|
2001-10-30 03:07:12 -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_(0);
|
2001-10-30 03:07:12 -08:00
|
|
|
}
|
|
|
|
|
2000-12-08 14:54:42 -08:00
|
|
|
/* what to dowhen we're idle */
|
2001-10-04 20:19:11 -07:00
|
|
|
|
|
|
|
void
|
|
|
|
e_border_update_borders(void)
|
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 = borders; 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_Border *b;
|
|
|
|
|
|
|
|
b = l->data;
|
|
|
|
e_border_update(b);
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
2001-01-02 15:10:12 -08:00
|
|
|
for (l = borders; l; l = l->next)
|
2000-12-08 14:54:42 -08:00
|
|
|
{
|
2001-01-02 15:10:12 -08:00
|
|
|
E_Border *b;
|
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
|
|
|
|
2001-01-02 15:10:12 -08:00
|
|
|
b = l->data;
|
|
|
|
if (b->first_expose)
|
|
|
|
{
|
|
|
|
evas_render(b->evas.l);
|
|
|
|
evas_render(b->evas.r);
|
|
|
|
evas_render(b->evas.t);
|
|
|
|
evas_render(b->evas.b);
|
|
|
|
}
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
2001-12-06 00:06:52 -08:00
|
|
|
e_db_runtime_flush();
|
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;
|
2001-10-04 20:19:11 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2001-11-01 15:54:48 -08:00
|
|
|
e_idle(void *data)
|
2001-10-04 20:19:11 -07: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;
|
|
|
|
|
2001-10-04 20:19:11 -07:00
|
|
|
e_border_update_borders();
|
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(data);
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* */
|
|
|
|
static void
|
2001-10-17 15:34:27 -07:00
|
|
|
e_map_request(Ecore_Event * ev)
|
2000-12-08 14:54:42 -08:00
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
Ecore_Event_Window_Map_Request *e;
|
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
|
|
|
current_ev = ev;
|
|
|
|
e = ev->event;
|
|
|
|
{
|
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_Border *b;
|
|
|
|
|
|
|
|
b = e_border_find_by_window(e->win);
|
|
|
|
if (!b)
|
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
if (ecore_window_exists(e->win))
|
2001-09-24 14:21:25 -07:00
|
|
|
b = e_border_adopt(e->win, 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
|
|
|
}
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
current_ev = 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
|
|
|
|
|
|
|
D_RETURN;
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* */
|
|
|
|
static void
|
2001-10-17 15:34:27 -07:00
|
|
|
e_configure_request(Ecore_Event * ev)
|
2000-12-08 14:54:42 -08:00
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
Ecore_Event_Window_Configure_Request *e;
|
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
|
|
|
current_ev = ev;
|
|
|
|
e = ev->event;
|
|
|
|
{
|
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_Border *b;
|
|
|
|
|
|
|
|
b = e_border_find_by_window(e->win);
|
|
|
|
if (b)
|
|
|
|
{
|
|
|
|
int pl, pr, pt, pb;
|
2000-12-09 16:29:46 -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
|
|
|
pl = pr = pt = pb = 0;
|
|
|
|
if (b->bits.t) ebits_get_insets(b->bits.t, &pl, &pr, &pt, &pb);
|
2001-10-17 15:34:27 -07:00
|
|
|
if (e->mask & ECORE_EVENT_VALUE_X)
|
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.x = e->x;
|
2001-10-17 15:34:27 -07:00
|
|
|
if (e->mask & ECORE_EVENT_VALUE_Y)
|
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.y = e->y;
|
2001-10-17 15:34:27 -07:00
|
|
|
if ((e->mask & ECORE_EVENT_VALUE_W) || (e->mask & ECORE_EVENT_VALUE_H))
|
2000-12-18 13:28:44 -08:00
|
|
|
{
|
|
|
|
if (b->current.shaded == b->client.h)
|
|
|
|
{
|
|
|
|
b->current.shaded = e->h;
|
|
|
|
}
|
|
|
|
else if (b->current.shaded != 0)
|
|
|
|
{
|
|
|
|
b->current.shaded += b->client.h - e->h;
|
|
|
|
if (b->current.shaded > b->client.h)
|
|
|
|
b->current.shaded = b->client.h;
|
|
|
|
if (b->current.shaded < 1)
|
|
|
|
b->current.shaded = 1;
|
|
|
|
}
|
2001-03-22 10:10:08 -08:00
|
|
|
b->current.requested.w = e->w + pl + pr;
|
2000-12-18 13:28:44 -08:00
|
|
|
b->current.requested.h = e->h + pt + pb;
|
2001-03-22 10:10:08 -08:00
|
|
|
}
|
2001-10-17 15:34:27 -07:00
|
|
|
if ((e->mask & ECORE_EVENT_VALUE_SIBLING) && (e->mask & ECORE_EVENT_VALUE_STACKING))
|
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_Border *b_rel;
|
|
|
|
|
|
|
|
b_rel = e_border_find_by_window(e->stack_win);
|
|
|
|
if (b_rel)
|
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
if (e->detail == ECORE_EVENT_STACK_ABOVE) e_border_raise_above(b, b_rel);
|
|
|
|
else if (e->detail == ECORE_EVENT_STACK_BELOW) e_border_lower_below(b, b_rel);
|
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
|
|
|
/* FIXME: need to handle & fix
|
2001-10-17 15:34:27 -07:00
|
|
|
* ECORE_EVENT_STACK_TOP_IF
|
|
|
|
* ECORE_EVENT_STACK_BOTTOM_IF
|
|
|
|
* ECORE_EVENT_STACK_OPPOSITE
|
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
|
|
|
*/
|
2001-10-17 15:34:27 -07:00
|
|
|
else if (e->detail == ECORE_EVENT_STACK_TOP_IF) e_border_raise(b);
|
|
|
|
else if (e->detail == ECORE_EVENT_STACK_BOTTOM_IF) e_border_lower(b);
|
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
|
|
|
}
|
|
|
|
}
|
2001-10-17 15:34:27 -07:00
|
|
|
else if (e->mask & ECORE_EVENT_VALUE_STACKING)
|
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
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
if (e->detail == ECORE_EVENT_STACK_ABOVE) e_border_raise(b);
|
|
|
|
else if (e->detail == ECORE_EVENT_STACK_BELOW) e_border_lower(b);
|
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
|
|
|
/* FIXME: need to handle & fix
|
2001-10-17 15:34:27 -07:00
|
|
|
* ECORE_EVENT_STACK_TOP_IF
|
|
|
|
* ECORE_EVENT_STACK_BOTTOM_IF
|
|
|
|
* ECORE_EVENT_STACK_OPPOSITE
|
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
|
|
|
*/
|
2001-10-17 15:34:27 -07:00
|
|
|
else if (e->detail == ECORE_EVENT_STACK_TOP_IF) e_border_raise(b);
|
|
|
|
else if (e->detail == ECORE_EVENT_STACK_BOTTOM_IF) e_border_lower(b);
|
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);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
if ((e->mask & ECORE_EVENT_VALUE_X) && (e->mask & ECORE_EVENT_VALUE_W))
|
|
|
|
ecore_window_move_resize(e->win, e->x, e->y, e->w, e->h);
|
|
|
|
else if ((e->mask & ECORE_EVENT_VALUE_W) || (e->mask & ECORE_EVENT_VALUE_H))
|
|
|
|
ecore_window_resize(e->win, e->w, e->h);
|
|
|
|
else if ((e->mask & ECORE_EVENT_VALUE_X))
|
|
|
|
ecore_window_move(e->win, e->x, e->y);
|
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
|
|
|
}
|
|
|
|
current_ev = 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
|
|
|
|
|
|
|
D_RETURN;
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* */
|
|
|
|
static void
|
2001-10-17 15:34:27 -07:00
|
|
|
e_property(Ecore_Event * ev)
|
2000-12-08 14:54:42 -08:00
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
Ecore_Event_Window_Property *e;
|
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
|
|
|
current_ev = ev;
|
|
|
|
e = ev->event;
|
|
|
|
{
|
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_Border *b;
|
|
|
|
|
|
|
|
b = e_border_find_by_window(e->win);
|
|
|
|
if (b)
|
|
|
|
{
|
|
|
|
e_icccm_handle_property_change(e->atom, b);
|
2001-11-19 23:01:53 -08:00
|
|
|
e_border_apply_border(b);
|
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
|
|
|
}
|
|
|
|
current_ev = 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
|
|
|
|
|
|
|
D_RETURN;
|
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
|
2001-10-17 15:34:27 -07:00
|
|
|
e_client_message(Ecore_Event * ev)
|
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
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
Ecore_Event_Message *e;
|
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
|
|
|
current_ev = ev;
|
|
|
|
e = ev->event;
|
|
|
|
|
|
|
|
e_icccm_handle_client_message(e);
|
|
|
|
|
|
|
|
current_ev = 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
|
|
|
|
|
|
|
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
|
2001-10-17 15:34:27 -07:00
|
|
|
e_unmap(Ecore_Event * ev)
|
2000-12-08 14:54:42 -08:00
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
Ecore_Event_Window_Unmap *e;
|
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
|
|
|
current_ev = ev;
|
|
|
|
e = ev->event;
|
|
|
|
{
|
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_Border *b;
|
|
|
|
|
|
|
|
b = e_border_find_by_window(e->win);
|
|
|
|
if (b)
|
|
|
|
{
|
|
|
|
if (b->win.client == e->win)
|
|
|
|
{
|
|
|
|
if (b->ignore_unmap > 0) b->ignore_unmap--;
|
|
|
|
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_stop_by_object(E_OBJECT(b), 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
|
|
|
mouse_win_x, mouse_win_y,
|
|
|
|
border_mouse_x, border_mouse_y);
|
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 (e_object_get_usecount(E_OBJECT(b)) == 1)
|
2001-11-15 21:39:34 -08:00
|
|
|
e_border_release(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
|
|
|
e_object_unref(E_OBJECT(b));
|
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
|
|
|
}
|
|
|
|
current_ev = 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
|
|
|
|
|
|
|
D_RETURN;
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* */
|
|
|
|
static void
|
2001-10-17 15:34:27 -07:00
|
|
|
e_destroy(Ecore_Event * ev)
|
2000-12-08 14:54:42 -08:00
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
Ecore_Event_Window_Destroy *e;
|
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
|
|
|
current_ev = ev;
|
|
|
|
e = ev->event;
|
|
|
|
{
|
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_Border *b;
|
|
|
|
|
|
|
|
b = e_border_find_by_window(e->win);
|
|
|
|
if (b)
|
|
|
|
{
|
|
|
|
if (b->win.client == e->win)
|
|
|
|
{
|
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(b), 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
|
|
|
mouse_win_x, mouse_win_y,
|
|
|
|
border_mouse_x, border_mouse_y);
|
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 (e_object_get_usecount(E_OBJECT(b)) == 1)
|
2001-11-15 21:39:34 -08:00
|
|
|
e_border_release(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
|
|
|
e_object_unref(E_OBJECT(b));
|
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
|
|
|
}
|
|
|
|
current_ev = 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
|
|
|
|
|
|
|
D_RETURN;
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* */
|
|
|
|
static void
|
2001-10-17 15:34:27 -07:00
|
|
|
e_circulate_request(Ecore_Event * ev)
|
2000-12-08 14:54:42 -08:00
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
Ecore_Event_Window_Circulate_Request *e;
|
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
|
|
|
current_ev = ev;
|
|
|
|
e = ev->event;
|
|
|
|
{
|
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_Border *b;
|
|
|
|
|
|
|
|
b = e_border_find_by_window(e->win);
|
|
|
|
if (b)
|
|
|
|
{
|
|
|
|
if (e->lower) e_border_lower(b);
|
|
|
|
else e_border_raise(b);
|
|
|
|
}
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
current_ev = 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
|
|
|
|
|
|
|
D_RETURN;
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* */
|
|
|
|
static void
|
2001-10-17 15:34:27 -07:00
|
|
|
e_reparent(Ecore_Event * ev)
|
2000-12-08 14:54:42 -08:00
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
Ecore_Event_Window_Reparent *e;
|
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
|
|
|
current_ev = ev;
|
|
|
|
e = ev->event;
|
|
|
|
current_ev = 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
|
|
|
|
|
|
|
D_RETURN;
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* */
|
|
|
|
static void
|
2001-10-17 15:34:27 -07:00
|
|
|
e_shape(Ecore_Event * ev)
|
2000-12-08 14:54:42 -08:00
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
Ecore_Event_Window_Shape *e;
|
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
|
|
|
current_ev = ev;
|
|
|
|
e = ev->event;
|
|
|
|
{
|
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_Border *b;
|
|
|
|
|
|
|
|
b = e_border_find_by_window(e->win);
|
2000-12-18 13:28:44 -08:00
|
|
|
if ((b) && (e->win == b->win.client))
|
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-18 13:28:44 -08:00
|
|
|
b->current.shaped_client = e_icccm_is_shaped(e->win);
|
|
|
|
b->changed = 1;
|
|
|
|
b->shape_changed = 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
|
|
|
}
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
current_ev = 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
|
|
|
|
|
|
|
D_RETURN;
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* */
|
|
|
|
static void
|
2001-11-01 15:54:48 -08:00
|
|
|
e_focus_in(Ecore_Event * ev)
|
2000-12-08 14:54:42 -08:00
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
Ecore_Event_Window_Focus_In *e;
|
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
|
|
|
current_ev = ev;
|
|
|
|
e = ev->event;
|
|
|
|
{
|
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_Border *b;
|
|
|
|
|
|
|
|
b = e_border_find_by_window(e->win);
|
2001-10-17 02:53:44 -07:00
|
|
|
if ((b) && (b->win.client == e->win))
|
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
|
|
|
{
|
2001-11-03 23:38:42 -08:00
|
|
|
E_Grab *g;
|
|
|
|
|
2001-03-20 19:07:17 -08:00
|
|
|
e_border_focus_grab_ended();
|
2001-10-21 15:30:56 -07:00
|
|
|
b->current.selected = 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
|
|
|
b->changed = 1;
|
2002-01-16 20:32:08 -08:00
|
|
|
e_observee_notify_observers(E_OBSERVEE(b), E_EVENT_WINDOW_FOCUS_IN);
|
2001-11-03 23:38:42 -08:00
|
|
|
g = b->click_grab;
|
|
|
|
if (g)
|
2001-10-30 03:07:12 -08:00
|
|
|
{
|
2001-11-15 21:39:34 -08:00
|
|
|
ecore_button_ungrab(b->win.container, g->button, g->mods, g->any_mod);
|
2001-11-03 23:38:42 -08:00
|
|
|
free(g);
|
|
|
|
b->click_grab = NULL;
|
2001-10-30 03:07:12 -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
|
|
|
}
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
current_ev = 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
|
|
|
|
|
|
|
D_RETURN;
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* */
|
|
|
|
static void
|
2001-11-01 15:54:48 -08:00
|
|
|
e_focus_out(Ecore_Event * ev)
|
2000-12-08 14:54:42 -08:00
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
Ecore_Event_Window_Focus_Out *e;
|
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
|
|
|
current_ev = ev;
|
|
|
|
e = ev->event;
|
|
|
|
{
|
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_Border *b;
|
|
|
|
|
|
|
|
b = e_border_find_by_window(e->win);
|
2001-10-17 02:53:44 -07:00
|
|
|
if ((b) && (b->win.client == e->win))
|
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 focus_mode;
|
2001-02-14 16:45:08 -08:00
|
|
|
E_CFG_INT(cfg_focus_mode, "settings", "/focus/mode", 0);
|
|
|
|
|
|
|
|
E_CONFIG_INT_GET(cfg_focus_mode, focus_mode);
|
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.selected = 0;
|
2001-10-17 02:53:44 -07:00
|
|
|
if (e->key_grab) b->current.select_lost_from_grab = 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
|
|
|
/* settings - click to focus would affect grabs */
|
2001-11-03 23:38:42 -08:00
|
|
|
if ((!b->client.internal) &&
|
2001-11-15 21:39:34 -08:00
|
|
|
(focus_mode == 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
|
|
|
{
|
2001-10-21 15:30:56 -07:00
|
|
|
E_Grab *g;
|
|
|
|
|
|
|
|
g = NEW(E_Grab, 1);
|
|
|
|
ZERO(g, E_Grab, 1);
|
2001-11-15 21:39:34 -08:00
|
|
|
g->button = 1;
|
2001-10-21 15:30:56 -07:00
|
|
|
g->mods = ECORE_EVENT_KEY_MODIFIER_NONE;
|
2001-10-30 03:07:12 -08:00
|
|
|
g->any_mod = 0;
|
2001-11-15 21:39:34 -08:00
|
|
|
g->remove_after = 0;
|
2001-11-15 23:23:08 -08:00
|
|
|
ecore_button_grab(b->win.container, g->button, XEV_BUTTON_PRESS, g->mods, g->any_mod);
|
2001-11-15 21:39:34 -08:00
|
|
|
ecore_window_button_grab_auto_replay_set(b->win.container, e_border_replay_query);
|
2001-10-30 03:07:12 -08:00
|
|
|
b->click_grab = g;
|
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;
|
|
|
|
}
|
2001-09-24 14:21:25 -07:00
|
|
|
e_delayed_action_cancel(delayed_window_raise);
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
current_ev = 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
|
|
|
|
|
|
|
D_RETURN;
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* */
|
|
|
|
static void
|
2001-10-17 15:34:27 -07:00
|
|
|
e_colormap(Ecore_Event * ev)
|
2000-12-08 14:54:42 -08:00
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
Ecore_Event_Colormap *e;
|
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
|
|
|
current_ev = ev;
|
|
|
|
e = ev->event;
|
|
|
|
{
|
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_Border *b;
|
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 = e_border_find_by_window(e->win);
|
|
|
|
if (b)
|
|
|
|
{
|
|
|
|
}
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
current_ev = 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
|
|
|
|
|
|
|
D_RETURN;
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* handling mouse down events */
|
|
|
|
static void
|
2001-10-17 15:34:27 -07:00
|
|
|
e_mouse_down(Ecore_Event * ev)
|
2000-12-08 14:54:42 -08:00
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
Ecore_Event_Mouse_Down *e;
|
2001-10-30 03:07:12 -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
|
|
|
current_ev = ev;
|
|
|
|
e = ev->event;
|
|
|
|
{
|
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_Border *b;
|
|
|
|
|
|
|
|
mouse_win_x = e->x;
|
|
|
|
mouse_win_y = e->y;
|
|
|
|
mouse_x = e->rx;
|
|
|
|
mouse_y = e->ry;
|
|
|
|
mouse_buttons |= (1 << e->button);
|
|
|
|
b = e_border_find_by_window(e->win);
|
|
|
|
if (b)
|
|
|
|
{
|
2001-10-30 03:07:12 -08:00
|
|
|
int focus_mode;
|
|
|
|
E_CFG_INT(cfg_focus_mode, "settings", "/focus/mode", 0);
|
|
|
|
|
|
|
|
E_CONFIG_INT_GET(cfg_focus_mode, focus_mode);
|
|
|
|
if (focus_mode == 2)
|
2001-11-03 23:38:42 -08:00
|
|
|
{
|
|
|
|
e_focus_set_focus(b);
|
|
|
|
/* FIXME: if (raise on click to focus) ... */
|
|
|
|
e_border_raise(b);
|
|
|
|
}
|
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 (e->win == b->win.main) e_cb_border_mouse_down(b, ev);
|
|
|
|
else
|
|
|
|
{
|
|
|
|
Evas evas;
|
|
|
|
int x, y;
|
2001-11-19 23:01:53 -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
|
|
|
evas = b->evas.l;
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_get_root_relative_location(evas_get_window(evas),
|
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
|
|
|
&x, &y);
|
|
|
|
x = e->rx - x;
|
|
|
|
y = e->ry - y;
|
|
|
|
evas_event_button_down(evas, x, y, e->button);
|
|
|
|
evas = b->evas.r;
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_get_root_relative_location(evas_get_window(evas),
|
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
|
|
|
&x, &y);
|
|
|
|
x = e->rx - x;
|
|
|
|
y = e->ry - y;
|
|
|
|
evas_event_button_down(evas, x, y, e->button);
|
|
|
|
evas = b->evas.t;
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_get_root_relative_location(evas_get_window(evas),
|
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
|
|
|
&x, &y);
|
|
|
|
x = e->rx - x;
|
|
|
|
y = e->ry - y;
|
|
|
|
evas_event_button_down(evas, x, y, e->button);
|
|
|
|
evas = b->evas.b;
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_get_root_relative_location(evas_get_window(evas),
|
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
|
|
|
&x, &y);
|
|
|
|
x = e->rx - x;
|
|
|
|
y = e->ry - y;
|
|
|
|
evas_event_button_down(evas, x, y, e->button);
|
|
|
|
}
|
|
|
|
}
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
current_ev = 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
|
|
|
|
|
|
|
D_RETURN;
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* handling mouse up events */
|
|
|
|
static void
|
2001-10-17 15:34:27 -07:00
|
|
|
e_mouse_up(Ecore_Event * ev)
|
2000-12-08 14:54:42 -08:00
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
Ecore_Event_Mouse_Up *e;
|
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
|
|
|
current_ev = ev;
|
|
|
|
e = ev->event;
|
|
|
|
{
|
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_Border *b;
|
|
|
|
|
|
|
|
mouse_win_x = e->x;
|
|
|
|
mouse_win_y = e->y;
|
|
|
|
mouse_x = e->rx;
|
|
|
|
mouse_y = e->ry;
|
|
|
|
mouse_buttons &= ~(1 << e->button);
|
|
|
|
b = e_border_find_by_window(e->win);
|
|
|
|
if (b)
|
|
|
|
{
|
|
|
|
if (e->win == b->win.main) e_cb_border_mouse_up(b, ev);
|
|
|
|
else
|
|
|
|
{
|
|
|
|
Evas evas;
|
|
|
|
int x, y;
|
|
|
|
|
|
|
|
evas = b->evas.l;
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_get_root_relative_location(evas_get_window(evas),
|
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
|
|
|
&x, &y);
|
|
|
|
x = e->rx - x;
|
|
|
|
y = e->ry - y;
|
|
|
|
evas_event_button_up(evas, x, y, e->button);
|
|
|
|
evas = b->evas.r;
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_get_root_relative_location(evas_get_window(evas),
|
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
|
|
|
&x, &y);
|
|
|
|
x = e->rx - x;
|
|
|
|
y = e->ry - y;
|
|
|
|
evas_event_button_up(evas, x, y, e->button);
|
|
|
|
evas = b->evas.t;
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_get_root_relative_location(evas_get_window(evas),
|
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
|
|
|
&x, &y);
|
|
|
|
x = e->rx - x;
|
|
|
|
y = e->ry - y;
|
|
|
|
evas_event_button_up(evas, x, y, e->button);
|
|
|
|
evas = b->evas.b;
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_get_root_relative_location(evas_get_window(evas),
|
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
|
|
|
&x, &y);
|
|
|
|
x = e->rx - x;
|
|
|
|
y = e->ry - y;
|
|
|
|
evas_event_button_up(evas, x, y, e->button);
|
|
|
|
}
|
|
|
|
}
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
current_ev = 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
|
|
|
|
|
|
|
D_RETURN;
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* handling mouse move events */
|
|
|
|
static void
|
2001-10-17 15:34:27 -07:00
|
|
|
e_mouse_move(Ecore_Event * ev)
|
2000-12-08 14:54:42 -08:00
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
Ecore_Event_Mouse_Move *e;
|
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
|
|
|
current_ev = ev;
|
|
|
|
e = ev->event;
|
|
|
|
{
|
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_Border *b;
|
|
|
|
|
|
|
|
mouse_win_x = e->x;
|
|
|
|
mouse_win_y = e->y;
|
|
|
|
mouse_x = e->rx;
|
|
|
|
mouse_y = e->ry;
|
|
|
|
b = e_border_find_by_window(e->win);
|
2001-11-19 23:01:53 -08:00
|
|
|
/* D("motion... %3.8f\n", ecore_get_time());*/
|
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)
|
|
|
|
{
|
|
|
|
if (e->win == b->win.main) e_cb_border_mouse_move(b, ev);
|
|
|
|
else
|
|
|
|
{
|
|
|
|
Evas evas;
|
|
|
|
int x, y;
|
|
|
|
|
|
|
|
evas = b->evas.l;
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_get_root_relative_location(evas_get_window(evas),
|
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
|
|
|
&x, &y);
|
|
|
|
x = e->rx - x;
|
|
|
|
y = e->ry - y;
|
|
|
|
evas_event_move(evas, x, y);
|
|
|
|
evas = b->evas.r;
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_get_root_relative_location(evas_get_window(evas),
|
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
|
|
|
&x, &y);
|
|
|
|
x = e->rx - x;
|
|
|
|
y = e->ry - y;
|
|
|
|
evas_event_move(evas, x, y);
|
|
|
|
evas = b->evas.t;
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_get_root_relative_location(evas_get_window(evas),
|
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
|
|
|
&x, &y);
|
|
|
|
x = e->rx - x;
|
|
|
|
y = e->ry - y;
|
|
|
|
evas_event_move(evas, x, y);
|
|
|
|
evas = b->evas.b;
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_get_root_relative_location(evas_get_window(evas),
|
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
|
|
|
&x, &y);
|
|
|
|
x = e->rx - x;
|
|
|
|
y = e->ry - y;
|
|
|
|
evas_event_move(evas, x, y);
|
|
|
|
}
|
|
|
|
}
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
current_ev = 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
|
|
|
|
|
|
|
D_RETURN;
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* handling mouse enter events */
|
|
|
|
static void
|
2001-10-17 15:34:27 -07:00
|
|
|
e_mouse_in(Ecore_Event * ev)
|
2000-12-08 14:54:42 -08:00
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
Ecore_Event_Window_Enter *e;
|
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
|
|
|
current_ev = ev;
|
|
|
|
e = ev->event;
|
|
|
|
{
|
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_Border *b;
|
|
|
|
|
|
|
|
b = e_border_find_by_window(e->win);
|
|
|
|
if (b)
|
|
|
|
{
|
|
|
|
if (e->win == b->win.main) e_cb_border_mouse_in(b, ev);
|
|
|
|
if (e->win == b->win.input)
|
|
|
|
{
|
|
|
|
int x, y;
|
|
|
|
Evas evas;
|
|
|
|
|
|
|
|
evas = b->evas.l;
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_get_root_relative_location(evas_get_window(evas), &x, &y);
|
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
|
|
|
x = e->rx - x;
|
|
|
|
y = e->ry - y;
|
|
|
|
evas_event_move(evas, x, y);
|
|
|
|
evas_event_enter(evas);
|
|
|
|
|
|
|
|
evas = b->evas.r;
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_get_root_relative_location(evas_get_window(evas), &x, &y);
|
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
|
|
|
x = e->rx - x;
|
|
|
|
y = e->ry - y;
|
|
|
|
evas_event_move(evas, x, y);
|
|
|
|
evas_event_enter(evas);
|
|
|
|
|
|
|
|
evas = b->evas.t;
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_get_root_relative_location(evas_get_window(evas), &x, &y);
|
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
|
|
|
x = e->rx - x;
|
|
|
|
y = e->ry - y;
|
|
|
|
evas_event_move(evas, x, y);
|
|
|
|
evas_event_enter(evas);
|
|
|
|
|
|
|
|
evas = b->evas.b;
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_get_root_relative_location(evas_get_window(evas), &x, &y);
|
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
|
|
|
x = e->rx - x;
|
|
|
|
y = e->ry - y;
|
|
|
|
evas_event_move(evas, x, y);
|
|
|
|
evas_event_enter(evas);
|
|
|
|
}
|
|
|
|
}
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
current_ev = 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
|
|
|
|
|
|
|
D_RETURN;
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* handling mouse leave events */
|
|
|
|
static void
|
2001-10-17 15:34:27 -07:00
|
|
|
e_mouse_out(Ecore_Event * ev)
|
2000-12-08 14:54:42 -08:00
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
Ecore_Event_Window_Leave *e;
|
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
|
|
|
current_ev = ev;
|
|
|
|
e = ev->event;
|
|
|
|
{
|
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_Border *b;
|
|
|
|
|
|
|
|
b = e_border_find_by_window(e->win);
|
|
|
|
if (b)
|
|
|
|
{
|
|
|
|
if (e->win == b->win.main) e_cb_border_mouse_out(b, ev);
|
|
|
|
if (e->win == b->win.input)
|
|
|
|
{
|
|
|
|
evas_event_leave(b->evas.l);
|
|
|
|
evas_event_leave(b->evas.r);
|
|
|
|
evas_event_leave(b->evas.t);
|
|
|
|
evas_event_leave(b->evas.b);
|
|
|
|
}
|
|
|
|
}
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
current_ev = NULL;
|
|
|
|
current_ev = 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
|
|
|
|
|
|
|
D_RETURN;
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* handling expose events */
|
|
|
|
static void
|
2001-11-01 15:54:48 -08:00
|
|
|
e_window_expose(Ecore_Event * ev)
|
2000-12-08 14:54:42 -08:00
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
Ecore_Event_Window_Expose *e;
|
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
|
|
|
current_ev = ev;
|
|
|
|
e = ev->event;
|
|
|
|
{
|
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
|
|
|
Evas_List l;
|
2001-01-02 15:10:12 -08:00
|
|
|
E_Border *b;
|
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
|
|
|
|
|
|
|
for (l = evases; l; l = l->next)
|
|
|
|
{
|
|
|
|
Evas evas;
|
|
|
|
|
|
|
|
evas = l->data;
|
|
|
|
if (evas_get_window(evas) == e->win)
|
|
|
|
evas_update_rect(evas, e->x, e->y, e->w, e->h);
|
|
|
|
}
|
2001-01-02 15:10:12 -08:00
|
|
|
b = e_border_find_by_window(e->win);
|
|
|
|
if (b) b->first_expose = 1;
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
current_ev = 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
|
|
|
|
|
|
|
D_RETURN;
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* what to do with border events */
|
|
|
|
|
|
|
|
static void
|
2001-10-12 13:13:01 -07:00
|
|
|
e_cb_mouse_in(void *data, Ebits_Object o, char *class,
|
|
|
|
int bt, int x, int y, int ox, int oy, int ow, int oh)
|
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
|
|
|
b = 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 (border_mouse_buttons) D_RETURN;
|
2000-12-08 14:54:42 -08:00
|
|
|
border_mouse_x = mouse_x;
|
|
|
|
border_mouse_y = mouse_y;
|
2001-09-24 14:21:25 -07:00
|
|
|
if (class) e_cursors_display_in_window(b->win.main, class);
|
|
|
|
else e_cursors_display_in_window(b->win.main, "Default");
|
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 (!current_ev) D_RETURN;
|
2001-10-12 13:13:01 -07:00
|
|
|
|
2001-10-17 15:34:27 -07:00
|
|
|
e_action_stop(class, ACT_MOUSE_IN, 0, NULL, ECORE_EVENT_KEY_MODIFIER_NONE,
|
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(b), NULL, x, y, border_mouse_x, border_mouse_y);
|
2001-10-17 15:34:27 -07:00
|
|
|
e_action_start(class, ACT_MOUSE_IN, 0, NULL, ECORE_EVENT_KEY_MODIFIER_NONE,
|
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(b), NULL, x, y, border_mouse_x, border_mouse_y);
|
|
|
|
|
|
|
|
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(o);
|
|
|
|
UN(bt);
|
|
|
|
UN(ox);
|
|
|
|
UN(oy);
|
|
|
|
UN(ow);
|
|
|
|
UN(oh);
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2001-10-12 13:13:01 -07:00
|
|
|
e_cb_mouse_out(void *data, Ebits_Object o, char *class,
|
|
|
|
int bt, int x, int y, int ox, int oy, int ow, int oh)
|
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
|
|
|
b = 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 (border_mouse_buttons) D_RETURN;
|
2000-12-08 14:54:42 -08:00
|
|
|
border_mouse_x = mouse_x;
|
|
|
|
border_mouse_y = mouse_y;
|
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 (!current_ev) D_RETURN;
|
2001-09-24 14:21:25 -07:00
|
|
|
e_cursors_display_in_window(b->win.main, "Default");
|
2001-10-17 15:34:27 -07:00
|
|
|
e_action_stop(class, ACT_MOUSE_OUT, 0, NULL, ECORE_EVENT_KEY_MODIFIER_NONE,
|
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(b), NULL, x, y, border_mouse_x, border_mouse_y);
|
2001-10-17 15:34:27 -07:00
|
|
|
e_action_start(class, ACT_MOUSE_OUT, 0, NULL, ECORE_EVENT_KEY_MODIFIER_NONE,
|
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(b), NULL, x, y, border_mouse_x, border_mouse_y);
|
|
|
|
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(o);
|
|
|
|
UN(bt);
|
|
|
|
UN(ox);
|
|
|
|
UN(oy);
|
|
|
|
UN(ow);
|
|
|
|
UN(oh);
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2001-10-12 13:13:01 -07:00
|
|
|
e_cb_mouse_down(void *data, Ebits_Object o, char *class,
|
|
|
|
int bt, int x, int y, int ox, int oy, int ow, int oh)
|
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
|
|
|
b = data;
|
|
|
|
border_mouse_x = mouse_x;
|
|
|
|
border_mouse_y = mouse_y;
|
|
|
|
border_mouse_buttons = mouse_buttons;
|
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 (!current_ev) D_RETURN;
|
2000-12-08 14:54:42 -08:00
|
|
|
{
|
2001-09-30 15:24:24 -07:00
|
|
|
E_Action_Type act;
|
2001-10-17 15:34:27 -07:00
|
|
|
Ecore_Event_Key_Modifiers mods;
|
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
|
|
|
|
2001-10-17 15:34:27 -07:00
|
|
|
mods = ((Ecore_Event_Mouse_Down *)(current_ev->event))->mods;
|
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
|
|
|
act = ACT_MOUSE_CLICK;
|
2001-10-12 13:13:01 -07:00
|
|
|
|
2001-10-17 15:34:27 -07:00
|
|
|
if (((Ecore_Event_Mouse_Down *)(current_ev->event))->double_click)
|
2001-10-12 13:13:01 -07:00
|
|
|
act = ACT_MOUSE_DOUBLE;
|
2001-10-17 15:34:27 -07:00
|
|
|
else if (((Ecore_Event_Mouse_Down *)(current_ev->event))->triple_click)
|
2001-10-12 13:13:01 -07:00
|
|
|
act = ACT_MOUSE_TRIPLE;
|
|
|
|
|
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(class, act, bt, NULL, mods, E_OBJECT(b),
|
2001-10-12 13:13:01 -07:00
|
|
|
NULL, x, y, border_mouse_x, border_mouse_y);
|
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(class, act, bt, NULL, mods, E_OBJECT(b),
|
2001-10-12 13:13:01 -07:00
|
|
|
NULL, x, y, border_mouse_x, border_mouse_y);
|
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(o);
|
|
|
|
UN(ox);
|
|
|
|
UN(oy);
|
|
|
|
UN(ow);
|
|
|
|
UN(oh);
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2001-10-12 13:13:01 -07:00
|
|
|
e_cb_mouse_up(void *data, Ebits_Object o, char *class,
|
|
|
|
int bt, int x, int y, int ox, int oy, int ow, int oh)
|
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
|
|
|
b = data;
|
|
|
|
border_mouse_x = mouse_x;
|
|
|
|
border_mouse_y = mouse_y;
|
|
|
|
border_mouse_buttons = mouse_buttons;
|
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 (!current_ev) D_RETURN;
|
2000-12-08 14:54:42 -08:00
|
|
|
{
|
2001-09-30 15:24:24 -07:00
|
|
|
E_Action_Type act;
|
2001-10-17 15:34:27 -07:00
|
|
|
Ecore_Event_Key_Modifiers mods;
|
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
|
|
|
|
2001-10-17 15:34:27 -07:00
|
|
|
mods = ((Ecore_Event_Mouse_Up *)(current_ev->event))->mods;
|
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
|
|
|
act = ACT_MOUSE_UP;
|
2001-10-12 13:13:01 -07: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
|
|
|
if ((x >= ox) && (x < (ox + ow)) && (y >= oy) && (y < (oy + oh)))
|
|
|
|
act = ACT_MOUSE_CLICKED;
|
2001-10-12 13:13:01 -07: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_action_stop(class, act, bt, NULL, mods, E_OBJECT(b),
|
2001-10-12 13:13:01 -07:00
|
|
|
NULL, x, y, border_mouse_x, border_mouse_y);
|
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(class, act, bt, NULL, mods, E_OBJECT(b),
|
2001-10-12 13:13:01 -07:00
|
|
|
NULL, x, y, border_mouse_x, border_mouse_y);
|
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(o);
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2001-10-12 13:13:01 -07:00
|
|
|
e_cb_mouse_move(void *data, Ebits_Object o, char *class,
|
|
|
|
int bt, int x, int y, int ox, int oy, int ow, int oh)
|
2000-12-08 14:54:42 -08:00
|
|
|
{
|
|
|
|
E_Border *b;
|
|
|
|
int dx, 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
|
|
|
D_ENTER;
|
|
|
|
|
2000-12-08 14:54:42 -08:00
|
|
|
b = data;
|
|
|
|
dx = mouse_x - border_mouse_x;
|
|
|
|
dy = mouse_y - border_mouse_y;
|
|
|
|
border_mouse_x = mouse_x;
|
|
|
|
border_mouse_y = mouse_y;
|
2001-10-12 13:13:01 -07:00
|
|
|
|
|
|
|
if (!current_ev)
|
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;
|
2001-10-12 13:13:01 -07:00
|
|
|
|
2001-10-17 15:34:27 -07:00
|
|
|
e_action_cont(class, ACT_MOUSE_MOVE, 0, NULL, ECORE_EVENT_KEY_MODIFIER_NONE,
|
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(b), NULL, x, y, border_mouse_x, border_mouse_y, dx, dy);
|
2001-10-12 13:13:01 -07: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(o);
|
|
|
|
UN(bt);
|
|
|
|
UN(ox);
|
|
|
|
UN(oy);
|
|
|
|
UN(ow);
|
|
|
|
UN(oh);
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* callbacks for certain things */
|
|
|
|
static void
|
2001-10-17 15:34:27 -07:00
|
|
|
e_cb_border_mouse_in(E_Border *b, Ecore_Event *e)
|
2000-12-08 14:54:42 -08:00
|
|
|
{
|
|
|
|
int x, y;
|
|
|
|
char *class = "Window_Grab";
|
2001-10-17 02:53:44 -07:00
|
|
|
int focus_mode;
|
|
|
|
E_CFG_INT(cfg_focus_mode, "settings", "/focus/mode", 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;
|
2001-10-17 02:53:44 -07:00
|
|
|
E_CONFIG_INT_GET(cfg_focus_mode, focus_mode);
|
2000-12-08 14:54:42 -08:00
|
|
|
/* pointer focus stuff */
|
2001-10-17 02:53:44 -07:00
|
|
|
if (focus_mode == 0)
|
2001-11-03 23:38:42 -08:00
|
|
|
e_focus_set_focus(b);
|
2000-12-08 14:54:42 -08:00
|
|
|
|
|
|
|
border_mouse_x = mouse_x;
|
|
|
|
border_mouse_y = mouse_y;
|
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 (!current_ev) D_RETURN;
|
2001-10-12 13:13:01 -07:00
|
|
|
|
2001-10-17 15:34:27 -07:00
|
|
|
x = ((Ecore_Event_Window_Enter *)(e->event))->x;
|
|
|
|
y = ((Ecore_Event_Window_Enter *)(e->event))->y;
|
2001-10-12 13:13:01 -07:00
|
|
|
|
2001-10-17 15:34:27 -07:00
|
|
|
e_action_stop(class, ACT_MOUSE_IN, 0, NULL, ECORE_EVENT_KEY_MODIFIER_NONE,
|
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(b), NULL, x, y, border_mouse_x, border_mouse_y);
|
2001-10-17 15:34:27 -07:00
|
|
|
e_action_start(class, ACT_MOUSE_IN, 0, NULL, ECORE_EVENT_KEY_MODIFIER_NONE,
|
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(b), NULL, x, y, border_mouse_x, border_mouse_y);
|
|
|
|
|
|
|
|
D_RETURN;
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2001-10-17 15:34:27 -07:00
|
|
|
e_cb_border_mouse_out(E_Border *b, Ecore_Event *e)
|
2000-12-08 14:54:42 -08:00
|
|
|
{
|
|
|
|
int x, y;
|
|
|
|
char *class = "Window_Grab";
|
2001-11-03 23:38: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;
|
2001-11-03 23:38: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
|
|
|
x = mouse_x;
|
|
|
|
y = mouse_y;
|
2000-12-08 14:54:42 -08:00
|
|
|
border_mouse_x = mouse_x;
|
2001-11-03 23:38:42 -08:00
|
|
|
border_mouse_y = mouse_y;
|
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 (!current_ev) D_RETURN;
|
2001-10-12 13:13:01 -07:00
|
|
|
|
2001-10-17 15:34:27 -07:00
|
|
|
e_action_stop(class, ACT_MOUSE_OUT, 0, NULL, ECORE_EVENT_KEY_MODIFIER_NONE,
|
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(b), NULL, x, y, border_mouse_x, border_mouse_y);
|
2001-10-17 15:34:27 -07:00
|
|
|
e_action_start(class, ACT_MOUSE_OUT, 0, NULL, ECORE_EVENT_KEY_MODIFIER_NONE,
|
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(b), NULL, x, y, border_mouse_x, border_mouse_y);
|
|
|
|
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(e);
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2001-10-17 15:34:27 -07:00
|
|
|
e_cb_border_mouse_down(E_Border *b, Ecore_Event *e)
|
2000-12-08 14:54:42 -08:00
|
|
|
{
|
|
|
|
int x, y, bt;
|
|
|
|
char *class = "Window_Grab";
|
2001-10-17 02:53:44 -07:00
|
|
|
int focus_mode;
|
|
|
|
E_CFG_INT(cfg_focus_mode, "settings", "/focus/mode", 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;
|
|
|
|
|
2001-10-17 02:53:44 -07:00
|
|
|
E_CONFIG_INT_GET(cfg_focus_mode, focus_mode);
|
2001-11-15 23:23:08 -08:00
|
|
|
ecore_pointer_grab(((Ecore_Event_Mouse_Down *)(e->event))->win, CurrentTime);
|
2000-12-08 14:54:42 -08:00
|
|
|
border_mouse_x = mouse_x;
|
|
|
|
border_mouse_y = mouse_y;
|
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 (!current_ev) D_RETURN;
|
2001-11-03 23:38:42 -08:00
|
|
|
|
2001-10-17 15:34:27 -07:00
|
|
|
x = ((Ecore_Event_Mouse_Down *)(e->event))->x;
|
|
|
|
y = ((Ecore_Event_Mouse_Down *)(e->event))->y;
|
|
|
|
bt = ((Ecore_Event_Mouse_Down *)(e->event))->button;
|
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
|
|
|
Evas_List l;
|
|
|
|
|
|
|
|
again:
|
|
|
|
for (l = b->grabs; l; l = l->next)
|
|
|
|
{
|
|
|
|
E_Grab *g;
|
|
|
|
|
|
|
|
g = l->data;
|
|
|
|
/* find a grab that triggered this */
|
2001-10-17 15:34:27 -07:00
|
|
|
if (((((Ecore_Event_Mouse_Down *)(e->event))->button == g->button) ||
|
2001-10-17 02:53:44 -07:00
|
|
|
(g->button == 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
|
|
|
((g->any_mod) ||
|
2001-10-17 15:34:27 -07:00
|
|
|
(((Ecore_Event_Mouse_Down *)(e->event))->mods == g->mods)))
|
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 (g->remove_after)
|
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_button_ungrab(b->win.main, g->button, g->mods, g->any_mod);
|
2001-10-30 03:07:12 -08:00
|
|
|
ecore_window_button_grab_auto_replay_set(b->win.main, 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
|
|
|
free(g);
|
|
|
|
b->grabs = evas_list_remove(b->grabs, g);
|
|
|
|
goto again;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
{
|
2001-09-30 15:24:24 -07:00
|
|
|
E_Action_Type act;
|
2001-10-17 15:34:27 -07:00
|
|
|
Ecore_Event_Key_Modifiers mods;
|
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
|
|
|
|
2001-10-17 15:34:27 -07:00
|
|
|
mods = ((Ecore_Event_Mouse_Down *)(current_ev->event))->mods;
|
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
|
|
|
act = ACT_MOUSE_CLICK;
|
2001-10-12 13:13:01 -07:00
|
|
|
|
2001-10-17 15:34:27 -07:00
|
|
|
if (((Ecore_Event_Mouse_Down *)(current_ev->event))->double_click)
|
2001-10-12 13:13:01 -07:00
|
|
|
act = ACT_MOUSE_DOUBLE;
|
2001-10-17 15:34:27 -07:00
|
|
|
else if (((Ecore_Event_Mouse_Down *)(current_ev->event))->triple_click)
|
2001-10-12 13:13:01 -07:00
|
|
|
act = ACT_MOUSE_TRIPLE;
|
|
|
|
|
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(class, act, bt, NULL, mods, E_OBJECT(b), NULL,
|
2001-10-12 13:13:01 -07:00
|
|
|
x, y, border_mouse_x, border_mouse_y);
|
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 (!e_action_start(class, act, bt, NULL, mods, E_OBJECT(b), NULL,
|
2001-10-30 03:07:12 -08:00
|
|
|
x, y, border_mouse_x, border_mouse_y))
|
2001-11-19 23:01:53 -08:00
|
|
|
{
|
|
|
|
ecore_pointer_ungrab(((Ecore_Event_Mouse_Down *)(e->event))->time);
|
|
|
|
}
|
2001-10-30 03:07:12 -08:00
|
|
|
else
|
2001-11-19 23:01:53 -08:00
|
|
|
{
|
|
|
|
ecore_pointer_grab(((Ecore_Event_Mouse_Down *)(e->event))->win,
|
|
|
|
((Ecore_Event_Mouse_Down *)(e->event))->time);
|
|
|
|
}
|
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
|
2001-10-17 15:34:27 -07:00
|
|
|
e_cb_border_mouse_up(E_Border *b, Ecore_Event *e)
|
2000-12-08 14:54:42 -08:00
|
|
|
{
|
|
|
|
int x, y, bt;
|
|
|
|
char *class = "Window_Grab";
|
|
|
|
|
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
|
|
|
border_mouse_x = mouse_x;
|
|
|
|
border_mouse_y = mouse_y;
|
2001-11-03 23:38: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
|
|
|
if (!current_ev) D_RETURN;
|
2001-11-03 23:38:42 -08:00
|
|
|
ecore_pointer_ungrab(((Ecore_Event_Mouse_Up *)(e->event))->time);
|
|
|
|
|
2001-10-17 15:34:27 -07:00
|
|
|
x = ((Ecore_Event_Mouse_Up *)(e->event))->x;
|
|
|
|
y = ((Ecore_Event_Mouse_Up *)(e->event))->y;
|
|
|
|
bt = ((Ecore_Event_Mouse_Up *)(e->event))->button;
|
2000-12-08 14:54:42 -08:00
|
|
|
{
|
2001-09-30 15:24:24 -07:00
|
|
|
E_Action_Type act;
|
2001-10-17 15:34:27 -07:00
|
|
|
Ecore_Event_Key_Modifiers mods;
|
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
|
|
|
|
2001-10-17 15:34:27 -07:00
|
|
|
mods = ((Ecore_Event_Mouse_Up *)(current_ev->event))->mods;
|
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
|
|
|
act = ACT_MOUSE_UP;
|
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(class, act, bt, NULL, mods, E_OBJECT(b),
|
2001-10-12 13:13:01 -07:00
|
|
|
NULL, x, y, border_mouse_x, border_mouse_y);
|
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(class, act, bt, NULL, mods, E_OBJECT(b),
|
2001-10-12 13:13:01 -07:00
|
|
|
NULL, x, y, border_mouse_x, border_mouse_y);
|
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
|
2001-10-17 15:34:27 -07:00
|
|
|
e_cb_border_mouse_move(E_Border *b, Ecore_Event *e)
|
2000-12-08 14:54:42 -08:00
|
|
|
{
|
|
|
|
int dx, dy;
|
|
|
|
int x, y;
|
|
|
|
char *class = "Window_Grab";
|
|
|
|
|
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
|
|
|
dx = mouse_x - border_mouse_x;
|
|
|
|
dy = mouse_y - border_mouse_y;
|
|
|
|
border_mouse_x = mouse_x;
|
|
|
|
border_mouse_y = mouse_y;
|
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 (!current_ev) D_RETURN;
|
2001-10-17 15:34:27 -07:00
|
|
|
x = ((Ecore_Event_Mouse_Move *)(e->event))->x;
|
|
|
|
y = ((Ecore_Event_Mouse_Move *)(e->event))->y;
|
|
|
|
e_action_cont(class, ACT_MOUSE_MOVE, 0, NULL, ECORE_EVENT_KEY_MODIFIER_NONE,
|
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(b), NULL, x, y, border_mouse_x, border_mouse_y, dx, dy);
|
|
|
|
|
|
|
|
D_RETURN;
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
e_cb_border_move_resize(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;
|
|
|
|
|
|
|
|
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(b);
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
e_cb_border_visibility(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;
|
|
|
|
|
|
|
|
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(b);
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
2001-11-01 15:54:48 -08:00
|
|
|
static void
|
|
|
|
e_border_poll(int val, void *data)
|
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;
|
|
|
|
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_add_event_timer("e_border_poll()", 1.00, e_border_poll, val + 1, 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
|
|
|
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(data);
|
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
|
2001-11-08 17:11:44 -08:00
|
|
|
e_border_cleanup(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
|
|
|
{
|
|
|
|
Evas_List l;
|
|
|
|
|
|
|
|
D_ENTER;
|
|
|
|
|
2001-11-24 23:18:49 -08:00
|
|
|
e_match_save_props(b);
|
|
|
|
|
|
|
|
while (b->menus)
|
|
|
|
{
|
|
|
|
E_Menu *m;
|
|
|
|
|
|
|
|
m = b->menus->data;
|
|
|
|
e_menu_hide(m);
|
|
|
|
e_object_unref(E_OBJECT(m));
|
|
|
|
b->menus = evas_list_remove(b->menus, m);
|
|
|
|
}
|
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_desktops_del_border(b->desk, b);
|
|
|
|
if (b->bits.l) ebits_free(b->bits.l);
|
|
|
|
if (b->bits.r) ebits_free(b->bits.r);
|
|
|
|
if (b->bits.t) ebits_free(b->bits.t);
|
|
|
|
if (b->bits.b) ebits_free(b->bits.b);
|
2001-11-13 13:26:20 -08:00
|
|
|
|
|
|
|
if (b->obj.title.l) e_text_free(b->obj.title.l);
|
|
|
|
if (b->obj.title.r) e_text_free(b->obj.title.r);
|
|
|
|
if (b->obj.title.t) e_text_free(b->obj.title.t);
|
|
|
|
if (b->obj.title.b) e_text_free(b->obj.title.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
|
|
|
evases = evas_list_remove(evases, b->evas.l);
|
|
|
|
evases = evas_list_remove(evases, b->evas.r);
|
|
|
|
evases = evas_list_remove(evases, b->evas.t);
|
|
|
|
evases = evas_list_remove(evases, b->evas.b);
|
|
|
|
evas_free(b->evas.l);
|
|
|
|
evas_free(b->evas.r);
|
|
|
|
evas_free(b->evas.t);
|
|
|
|
evas_free(b->evas.b);
|
|
|
|
ecore_window_destroy(b->win.container);
|
|
|
|
ecore_window_destroy(b->win.input);
|
|
|
|
ecore_window_destroy(b->win.main);
|
|
|
|
borders = evas_list_remove(borders, b);
|
|
|
|
|
|
|
|
IF_FREE(b->client.title);
|
|
|
|
IF_FREE(b->client.name);
|
|
|
|
IF_FREE(b->client.class);
|
|
|
|
IF_FREE(b->client.command);
|
|
|
|
IF_FREE(b->client.machine);
|
|
|
|
IF_FREE(b->client.icon_name);
|
|
|
|
IF_FREE(b->border_style);
|
|
|
|
IF_FREE(b->border_file);
|
|
|
|
|
|
|
|
if (b->grabs)
|
|
|
|
{
|
|
|
|
for (l = b->grabs; l; l = l->next)
|
|
|
|
{
|
|
|
|
FREE(l->data);
|
|
|
|
}
|
|
|
|
evas_list_free(b->grabs);
|
|
|
|
}
|
|
|
|
|
2001-11-08 17:11:44 -08:00
|
|
|
/* 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(b));
|
|
|
|
|
|
|
|
D_RETURN;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2000-12-08 14:54:42 -08:00
|
|
|
/* border creation, deletion, modification and general queries */
|
|
|
|
|
|
|
|
void
|
|
|
|
e_border_apply_border(E_Border *b)
|
|
|
|
{
|
|
|
|
int pl, pr, pt, pb;
|
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
|
|
|
char *borders, buf[PATH_MAX], border[PATH_MAX], *style = NULL;
|
2000-12-15 13:27:23 -08:00
|
|
|
int prop_selected = 0, prop_sticky = 0, prop_shaded = 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;
|
|
|
|
|
2000-12-15 13:27:23 -08:00
|
|
|
style = "default";
|
|
|
|
if ((!b->client.titlebar) && (!b->client.border)) style = "borderless";
|
2001-10-08 00:32:54 -07:00
|
|
|
if (b->border_style) style = b->border_style;
|
2000-12-15 13:27:23 -08:00
|
|
|
|
2001-11-19 23:01:53 -08:00
|
|
|
if (b->current.selected) prop_selected = 1;
|
|
|
|
if ((b->current.shaded > 0) &&
|
|
|
|
(b->current.shaded == b->client.h)) prop_shaded = 1;
|
|
|
|
if (b->client.sticky) prop_sticky = 1;
|
2000-12-15 13:27:23 -08:00
|
|
|
|
2002-01-23 22:15:40 -08:00
|
|
|
snprintf(border, PATH_MAX, "selected-%i.sticky-%i.shaded-%i.bits.db",
|
2000-12-15 13:27:23 -08:00
|
|
|
prop_selected, prop_sticky, prop_shaded);
|
2000-12-08 14:54:42 -08:00
|
|
|
|
2000-12-13 16:12:16 -08:00
|
|
|
borders = e_config_get("borders");
|
2002-01-23 22:15:40 -08:00
|
|
|
snprintf(buf, PATH_MAX, "%s%s/%s", borders, style, border);
|
2001-11-19 23:01:53 -08:00
|
|
|
|
2000-12-15 13:27:23 -08:00
|
|
|
/* if it's not changed - abort and dont do anything */
|
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->border_file) && (!strcmp(buf, b->border_file))) D_RETURN;
|
2001-11-19 23:01:53 -08:00
|
|
|
|
2000-12-15 13:27:23 -08:00
|
|
|
IF_FREE(b->border_file);
|
2001-08-16 01:45:37 -07:00
|
|
|
e_strdup(b->border_file, buf);
|
2000-12-15 13:27:23 -08:00
|
|
|
|
2000-12-13 16:12:16 -08:00
|
|
|
e_border_set_bits(b, buf);
|
|
|
|
|
2000-12-08 14:54:42 -08:00
|
|
|
pl = pr = pt = pb = 0;
|
|
|
|
if (b->bits.t) ebits_get_insets(b->bits.t, &pl, &pr, &pt, &pb);
|
|
|
|
e_icccm_set_frame_size(b->win.client, pl, pr, pt, pb);
|
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
|
|
|
}
|
|
|
|
|
2000-12-18 13:28:44 -08:00
|
|
|
void
|
|
|
|
e_border_reshape(E_Border *b)
|
|
|
|
{
|
|
|
|
static Window shape_win = 0;
|
|
|
|
int pl, pr, pt, pb;
|
|
|
|
|
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-18 13:28:44 -08:00
|
|
|
if ((b->current.shaped_client == b->previous.shaped_client) &&
|
|
|
|
(b->current.shape_changes == b->previous.shape_changes) &&
|
|
|
|
(b->current.has_shape == b->previous.has_shape) &&
|
|
|
|
(!b->shape_changed))
|
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;
|
2001-10-12 13:13:01 -07:00
|
|
|
|
2001-10-17 15:34:27 -07:00
|
|
|
if (!shape_win) shape_win = ecore_window_override_new(0, 0, 0, 1, 1);
|
2000-12-18 13:28:44 -08:00
|
|
|
pl = pr = pt = pb = 0;
|
|
|
|
if (b->bits.t) ebits_get_insets(b->bits.t, &pl, &pr, &pt, &pb);
|
|
|
|
b->shape_changed = 0;
|
2001-10-12 13:13:01 -07:00
|
|
|
|
2000-12-18 13:28:44 -08:00
|
|
|
if ((!b->current.shaped_client) && (!b->current.has_shape))
|
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_set_shape_mask(b->win.main, 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;
|
2000-12-18 13:28:44 -08:00
|
|
|
}
|
2001-10-12 13:13:01 -07:00
|
|
|
|
2000-12-18 13:28:44 -08:00
|
|
|
if ((b->current.shaped_client) && (!b->current.has_shape))
|
|
|
|
{
|
|
|
|
XRectangle rects[4];
|
|
|
|
|
|
|
|
rects[0].x = 0; rects[0].y = 0;
|
|
|
|
rects[0].width = b->current.w; rects[0].height = pt;
|
|
|
|
rects[1].x = 0; rects[1].y = pt;
|
|
|
|
rects[1].width = pl; rects[1].height = b->current.h - pt - pb;
|
|
|
|
rects[2].x = b->current.w - pr; rects[2].y = pt;
|
|
|
|
rects[2].width = pr; rects[2].height = b->current.h - pt - pb;
|
|
|
|
rects[3].x = 0; rects[3].y = b->current.h - pb;
|
|
|
|
rects[3].width = b->current.w; rects[3].height = pb;
|
|
|
|
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_resize(shape_win, b->current.w, b->current.h);
|
|
|
|
ecore_window_set_shape_window(shape_win, b->win.client, pl, pt - b->current.shaded);
|
|
|
|
ecore_window_clip_shape_by_rectangle(shape_win, pl, pt,
|
2001-10-12 13:13:01 -07:00
|
|
|
b->current.w - pl - pr, b->current.h - pt - pb);
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_add_shape_rectangles(shape_win, rects, 4);
|
|
|
|
ecore_window_set_shape_window(b->win.main, shape_win, 0, 0);
|
2001-10-12 13:13:01 -07: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-18 13:28:44 -08:00
|
|
|
}
|
2001-10-12 13:13:01 -07:00
|
|
|
|
2000-12-18 13:28:44 -08:00
|
|
|
if ((!b->current.shaped_client) && (b->current.has_shape))
|
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_resize(shape_win, b->current.w, b->current.h);
|
|
|
|
ecore_window_set_shape_rectangle(shape_win, pl, pt - b->current.shaded,
|
2001-10-12 13:13:01 -07:00
|
|
|
b->current.w - pl - pr, b->current.h - pt - pb);
|
|
|
|
|
2000-12-18 13:28:44 -08:00
|
|
|
/* FIXME: later when i actually generate shape masks for borders */
|
|
|
|
{
|
|
|
|
XRectangle rects[4];
|
|
|
|
|
|
|
|
rects[0].x = 0; rects[0].y = 0;
|
|
|
|
rects[0].width = b->current.w; rects[0].height = pt;
|
|
|
|
rects[1].x = 0; rects[1].y = pt;
|
|
|
|
rects[1].width = pl; rects[1].height = b->current.h - pt - pb;
|
|
|
|
rects[2].x = b->current.w - pr; rects[2].y = pt;
|
|
|
|
rects[2].width = pr; rects[2].height = b->current.h - pt - pb;
|
|
|
|
rects[3].x = 0; rects[3].y = b->current.h - pb;
|
|
|
|
rects[3].width = b->current.w; rects[3].height = pb;
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_add_shape_rectangles(shape_win, rects, 4);
|
2000-12-18 13:28:44 -08:00
|
|
|
}
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_set_shape_window(b->win.main, shape_win, 0, 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;
|
2000-12-18 13:28:44 -08:00
|
|
|
}
|
|
|
|
if ((b->current.shaped_client) && (b->current.has_shape))
|
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_resize(shape_win, b->current.w, b->current.h);
|
|
|
|
ecore_window_set_shape_window(shape_win, b->win.client, pl, pt - b->current.shaded);
|
|
|
|
ecore_window_clip_shape_by_rectangle(shape_win, pl, pt,
|
2001-10-12 13:13:01 -07:00
|
|
|
b->current.w - pl - pr, b->current.h - pt - pb);
|
|
|
|
|
2000-12-18 13:28:44 -08:00
|
|
|
/* FIXME: later when i actually generate shape masks for borders */
|
|
|
|
{
|
|
|
|
XRectangle rects[4];
|
|
|
|
|
|
|
|
rects[0].x = 0; rects[0].y = 0;
|
|
|
|
rects[0].width = b->current.w; rects[0].height = pt;
|
|
|
|
rects[1].x = 0; rects[1].y = pt;
|
|
|
|
rects[1].width = pl; rects[1].height = b->current.h - pt - pb;
|
|
|
|
rects[2].x = b->current.w - pr; rects[2].y = pt;
|
|
|
|
rects[2].width = pr; rects[2].height = b->current.h - pt - pb;
|
|
|
|
rects[3].x = 0; rects[3].y = b->current.h - pb;
|
|
|
|
rects[3].width = b->current.w; rects[3].height = pb;
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_add_shape_rectangles(shape_win, rects, 4);
|
2000-12-18 13:28:44 -08:00
|
|
|
}
|
2001-10-12 13:13:01 -07:00
|
|
|
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_set_shape_window(b->win.main, shape_win, 0, 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;
|
2000-12-18 13:28:44 -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-18 13:28:44 -08:00
|
|
|
}
|
|
|
|
|
2001-11-15 21:39:34 -08:00
|
|
|
void
|
|
|
|
e_border_release(E_Border *b)
|
|
|
|
{
|
|
|
|
int pl, pr, pt, pb;
|
|
|
|
|
2001-11-16 03:34:30 -08:00
|
|
|
D_ENTER;
|
|
|
|
|
2001-11-15 21:39:34 -08:00
|
|
|
pl = pr = pt = pb = 0;
|
|
|
|
if (b->bits.t) ebits_get_insets(b->bits.t, &pl, &pr, &pt, &pb);
|
|
|
|
ecore_window_reparent(b->win.client, 0, b->current.x + pl, b->current.y + pt);
|
|
|
|
e_icccm_release(b->win.client);
|
2001-11-16 03:34:30 -08:00
|
|
|
|
|
|
|
D_RETURN;
|
2001-11-15 21:39:34 -08:00
|
|
|
}
|
|
|
|
|
2001-11-16 03:34:30 -08:00
|
|
|
|
2000-12-08 14:54:42 -08:00
|
|
|
E_Border *
|
|
|
|
e_border_adopt(Window win, int use_client_pos)
|
|
|
|
{
|
|
|
|
E_Border *b;
|
2001-04-02 12:03:55 -07:00
|
|
|
int bw;
|
2001-09-24 14:21:25 -07:00
|
|
|
int show = 1;
|
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
|
|
|
/* create the struct */
|
|
|
|
b = e_border_new();
|
|
|
|
/* set the right event on the client */
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_set_events(win,
|
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
|
|
|
XEV_VISIBILITY |
|
|
|
|
ResizeRedirectMask |
|
|
|
|
XEV_CONFIGURE |
|
|
|
|
XEV_FOCUS |
|
|
|
|
XEV_PROPERTY |
|
|
|
|
XEV_COLORMAP);
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_select_shape_events(win);
|
2000-12-08 14:54:42 -08:00
|
|
|
/* parent of the client window listens for these */
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_set_events(b->win.container, XEV_CHILD_CHANGE | XEV_CHILD_REDIRECT);
|
2000-12-08 14:54:42 -08:00
|
|
|
/* add to save set & border of 0 */
|
|
|
|
e_icccm_adopt(win);
|
2001-10-17 15:34:27 -07:00
|
|
|
bw = ecore_window_get_border_width(win);
|
|
|
|
ecore_window_set_border_width(win, 0);
|
2000-12-08 14:54:42 -08:00
|
|
|
b->win.client = win;
|
|
|
|
b->current.requested.visible = 1;
|
2000-12-18 13:28:44 -08:00
|
|
|
/* get hints */
|
2000-12-08 14:54:42 -08:00
|
|
|
e_icccm_get_size_info(win, b);
|
2001-04-02 12:03:55 -07:00
|
|
|
e_icccm_get_pos_info(win, b);
|
2001-03-22 10:10:08 -08:00
|
|
|
{
|
|
|
|
int x, y, w, h;
|
|
|
|
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_get_geometry(win, &x, &y, &w, &h);
|
2001-04-02 12:03:55 -07:00
|
|
|
b->current.requested.x = x;
|
|
|
|
b->current.requested.y = y;
|
|
|
|
b->current.requested.w = w;
|
|
|
|
b->current.requested.h = h;
|
2001-03-22 10:10:08 -08:00
|
|
|
}
|
|
|
|
|
2000-12-08 14:54:42 -08:00
|
|
|
e_icccm_get_mwm_hints(win, b);
|
|
|
|
e_icccm_get_layer(win, b);
|
2001-01-02 15:10:12 -08:00
|
|
|
e_icccm_get_title(win, b);
|
2001-10-07 23:53:26 -07:00
|
|
|
e_icccm_get_class(win, b);
|
|
|
|
e_icccm_get_hints(win, b);
|
|
|
|
e_icccm_get_machine(win, b);
|
|
|
|
e_icccm_get_command(win, b);
|
|
|
|
e_icccm_get_icon_name(win, b);
|
2001-12-06 00:06:52 -08:00
|
|
|
e_icccm_get_e_hack_launch_id(win, b);
|
2000-12-18 13:28:44 -08:00
|
|
|
b->current.shaped_client = e_icccm_is_shaped(win);
|
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
|
|
|
/* we have now placed the bugger */
|
|
|
|
b->placed = 1;
|
2000-12-08 14:54:42 -08:00
|
|
|
/* desk area */
|
|
|
|
if (use_client_pos)
|
|
|
|
{
|
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 x, y;
|
|
|
|
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_get_geometry(win, &x, &y, NULL, 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
|
|
|
b->current.requested.x = x;
|
|
|
|
b->current.requested.y = y;
|
2001-09-24 14:21:25 -07:00
|
|
|
b->changed = 1;
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
/* reparent the window finally */
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_reparent(win, b->win.container, 0, 0);
|
2001-10-08 00:32:54 -07:00
|
|
|
e_match_set_props(b);
|
2001-10-09 08:01:58 -07:00
|
|
|
e_icccm_set_desk_area(win, b->client.area.x, b->client.area.y);
|
|
|
|
e_icccm_set_desk(win, b->client.desk);
|
2000-12-08 14:54:42 -08:00
|
|
|
/* figure what border to use */
|
|
|
|
e_border_apply_border(b);
|
|
|
|
{
|
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 pl, pr, pt, pb;
|
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
|
|
|
pl = pr = pt = pb = 0;
|
|
|
|
if (b->bits.l) ebits_get_insets(b->bits.l, &pl, &pr, &pt, &pb);
|
|
|
|
b->current.requested.x += pl;
|
|
|
|
b->current.requested.y += pt;
|
|
|
|
b->changed = 1;
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
2001-09-24 14:21:25 -07:00
|
|
|
if (!use_client_pos)
|
2001-04-02 12:03:55 -07:00
|
|
|
{
|
2001-07-30 09:59:37 -07:00
|
|
|
int x, y;
|
2001-04-02 12:03:55 -07:00
|
|
|
int pl, pr, pt, pb;
|
|
|
|
|
|
|
|
pl = pr = pt = pb = 0;
|
2001-09-25 09:37:00 -07:00
|
|
|
x = y = 0;
|
2001-04-02 12:03:55 -07:00
|
|
|
if (b->bits.t) ebits_get_insets(b->bits.t, &pl, &pr, &pt, &pb);
|
|
|
|
bw *= 2;
|
|
|
|
if (b->client.pos.requested)
|
|
|
|
{
|
|
|
|
switch (b->client.pos.gravity)
|
|
|
|
{
|
|
|
|
case NorthWestGravity:
|
|
|
|
x = b->client.pos.x + pl;
|
|
|
|
y = b->client.pos.y + pt;
|
|
|
|
break;
|
|
|
|
case NorthGravity:
|
|
|
|
x = b->client.pos.x + (bw / 2);
|
|
|
|
y = b->client.pos.y + pt;
|
|
|
|
break;
|
|
|
|
case NorthEastGravity:
|
|
|
|
x = b->client.pos.x - pr + bw;
|
|
|
|
y = b->client.pos.y + pt;
|
|
|
|
break;
|
|
|
|
case EastGravity:
|
|
|
|
x = b->client.pos.x - pr + bw;
|
|
|
|
y = b->client.pos.y + (bw / 2);
|
|
|
|
break;
|
|
|
|
case SouthEastGravity:
|
|
|
|
x = b->client.pos.x - pr + bw;
|
|
|
|
y = b->client.pos.y - pb + bw;
|
|
|
|
break;
|
|
|
|
case SouthGravity:
|
|
|
|
x = b->client.pos.x + (bw / 2);
|
|
|
|
y = b->client.pos.y - pb;
|
|
|
|
break;
|
|
|
|
case SouthWestGravity:
|
|
|
|
x = b->client.pos.x + pl;
|
2001-09-24 14:21:25 -07:00
|
|
|
y = b->client.pos.y - pb + bw;
|
2001-04-02 12:03:55 -07:00
|
|
|
break;
|
|
|
|
case WestGravity:
|
|
|
|
x = b->client.pos.x + pl;
|
|
|
|
y = b->client.pos.y + (bw / 2);
|
|
|
|
break;
|
|
|
|
case CenterGravity:
|
|
|
|
x = b->client.pos.x;
|
|
|
|
y = b->client.pos.y;
|
|
|
|
break;
|
|
|
|
case StaticGravity:
|
|
|
|
x = b->client.pos.x;
|
|
|
|
y = b->client.pos.y;
|
|
|
|
break;
|
|
|
|
case ForgetGravity:
|
|
|
|
x = b->client.pos.x;
|
|
|
|
y = b->client.pos.y;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
x = b->client.pos.x + pl;
|
|
|
|
y = b->client.pos.y + pt;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2001-09-24 14:21:25 -07:00
|
|
|
show = e_place_border(b, b->desk, &x, &y, E_PLACE_SMART);
|
|
|
|
x += pl;
|
|
|
|
y += pt;
|
2001-04-02 12:03:55 -07:00
|
|
|
}
|
|
|
|
b->current.requested.x = x - pl;
|
|
|
|
b->current.requested.y = y - pt;
|
|
|
|
b->changed = 1;
|
|
|
|
}
|
2000-12-08 14:54:42 -08:00
|
|
|
/* show the client */
|
|
|
|
e_icccm_state_mapped(win);
|
|
|
|
/* fix size so it matches the hints a client asks for */
|
|
|
|
b->changed = 1;
|
|
|
|
e_border_adjust_limits(b);
|
2001-02-12 10:58:51 -08:00
|
|
|
b->current.requested.h = b->current.h;
|
|
|
|
b->current.requested.w = b->current.w;
|
2000-12-08 14:54:42 -08:00
|
|
|
e_border_raise(b);
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_show(win);
|
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
|
|
|
|
2001-12-06 00:06:52 -08:00
|
|
|
if (b->client.e.launch_id)
|
|
|
|
e_exec_broadcast_e_hack_found(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_(b);
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
E_Border *
|
|
|
|
e_border_new(void)
|
|
|
|
{
|
2001-06-18 20:40:51 -07:00
|
|
|
/* FIXME: need to set an upper limit on the frame size */
|
2000-12-08 14:54:42 -08:00
|
|
|
E_Border *b;
|
|
|
|
int max_colors = 216;
|
|
|
|
int font_cache = 1024 * 1024;
|
|
|
|
int image_cache = 8192 * 1024;
|
2000-12-13 16:12:16 -08:00
|
|
|
char *font_dir;
|
2000-12-08 14:54:42 -08:00
|
|
|
E_Desktop *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_ENTER;
|
|
|
|
|
2000-12-13 16:12:16 -08:00
|
|
|
font_dir = e_config_get("fonts");
|
2000-12-08 14:54:42 -08:00
|
|
|
b = NEW(E_Border, 1);
|
|
|
|
ZERO(b, E_Border, 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
|
|
|
|
2001-11-08 17:11:44 -08:00
|
|
|
e_object_init(E_OBJECT(b), (E_Cleanup_Func) e_border_cleanup);
|
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_observer_register_observee(E_OBSERVER(delayed_window_raise),
|
|
|
|
E_OBSERVEE(b));
|
2000-12-08 14:54:42 -08:00
|
|
|
|
2001-11-08 17:11:44 -08:00
|
|
|
D("BORDER CREATED AT %p\n", b);
|
|
|
|
|
2000-12-08 14:54:42 -08:00
|
|
|
b->current.requested.w = 1;
|
|
|
|
b->current.requested.h = 1;
|
|
|
|
b->client.min.w = 1;
|
|
|
|
b->client.min.h = 1;
|
|
|
|
b->client.max.w = 1000000;
|
|
|
|
b->client.max.h = 1000000;
|
|
|
|
b->client.min.aspect = -1000000;
|
|
|
|
b->client.max.aspect = 1000000;
|
|
|
|
b->client.step.w = 1;
|
|
|
|
b->client.step.h = 1;
|
|
|
|
b->client.layer = 4;
|
|
|
|
b->client.border = 1;
|
|
|
|
b->client.handles = 1;
|
|
|
|
b->client.titlebar = 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
|
|
|
b->client.takes_focus = 1;
|
2000-12-08 14:54:42 -08:00
|
|
|
|
2001-10-01 20:29:57 -07:00
|
|
|
desk = e_desktops_get(0);
|
2000-12-08 14:54:42 -08:00
|
|
|
e_desktops_add_border(desk, b);
|
2001-10-17 15:34:27 -07:00
|
|
|
b->win.main = ecore_window_override_new(desk->win.container, 0, 0, 1, 1);
|
|
|
|
b->win.input = ecore_window_input_new(b->win.main, 0, 0, 1, 1);
|
|
|
|
b->win.container = ecore_window_override_new(b->win.main, 0, 0, 1, 1);
|
2001-09-24 14:21:25 -07:00
|
|
|
e_cursors_display_in_window(b->win.container, "Application");
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_set_events_propagate(b->win.input, 1);
|
|
|
|
ecore_window_set_events(b->win.input, XEV_MOUSE_MOVE | XEV_BUTTON);
|
|
|
|
ecore_window_set_events(b->win.main, XEV_IN_OUT);
|
|
|
|
ecore_window_set_events(b->win.container, XEV_IN_OUT);
|
|
|
|
ecore_window_show(b->win.input);
|
|
|
|
ecore_window_show(b->win.container);
|
|
|
|
|
|
|
|
b->evas.l = evas_new_all(ecore_display_get(),
|
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->win.main,
|
|
|
|
0, 0, 1, 1,
|
|
|
|
RENDER_METHOD_ALPHA_SOFTWARE,
|
|
|
|
max_colors,
|
|
|
|
font_cache,
|
|
|
|
image_cache,
|
|
|
|
font_dir);
|
2000-12-08 14:54:42 -08:00
|
|
|
b->win.l = evas_get_window(b->evas.l);
|
2001-10-17 15:34:27 -07:00
|
|
|
b->evas.r = evas_new_all(ecore_display_get(),
|
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->win.main,
|
|
|
|
0, 0, 1, 1,
|
|
|
|
RENDER_METHOD_ALPHA_SOFTWARE,
|
|
|
|
max_colors,
|
|
|
|
font_cache,
|
|
|
|
image_cache,
|
|
|
|
font_dir);
|
2000-12-08 14:54:42 -08:00
|
|
|
b->win.r = evas_get_window(b->evas.r);
|
2001-10-17 15:34:27 -07:00
|
|
|
b->evas.t = evas_new_all(ecore_display_get(),
|
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->win.main,
|
|
|
|
0, 0, 1, 1,
|
|
|
|
RENDER_METHOD_ALPHA_SOFTWARE,
|
|
|
|
max_colors,
|
|
|
|
font_cache,
|
|
|
|
image_cache,
|
|
|
|
font_dir);
|
2000-12-08 14:54:42 -08:00
|
|
|
b->win.t = evas_get_window(b->evas.t);
|
2001-10-17 15:34:27 -07:00
|
|
|
b->evas.b = evas_new_all(ecore_display_get(),
|
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->win.main,
|
|
|
|
0, 0, 1, 1,
|
|
|
|
RENDER_METHOD_ALPHA_SOFTWARE,
|
|
|
|
max_colors,
|
|
|
|
font_cache,
|
|
|
|
image_cache,
|
|
|
|
font_dir);
|
2000-12-08 14:54:42 -08:00
|
|
|
b->win.b = evas_get_window(b->evas.b);
|
2001-09-24 14:21:25 -07:00
|
|
|
e_cursors_display_in_window(b->win.l, "Default");
|
|
|
|
e_cursors_display_in_window(b->win.r, "Default");
|
|
|
|
e_cursors_display_in_window(b->win.t, "Default");
|
|
|
|
e_cursors_display_in_window(b->win.b, "Default");
|
2001-08-16 01:45:37 -07:00
|
|
|
|
2001-11-13 13:26:20 -08:00
|
|
|
b->obj.title.l = e_text_new(b->evas.l, "", "title");
|
|
|
|
b->obj.title.r = e_text_new(b->evas.r, "", "title");
|
|
|
|
b->obj.title.t = e_text_new(b->evas.t, "", "title");
|
|
|
|
b->obj.title.b = e_text_new(b->evas.b, "", "title");
|
2001-01-02 15:10:12 -08:00
|
|
|
|
|
|
|
b->obj.title_clip.l = evas_add_rectangle(b->evas.l);
|
|
|
|
b->obj.title_clip.r = evas_add_rectangle(b->evas.r);
|
|
|
|
b->obj.title_clip.t = evas_add_rectangle(b->evas.t);
|
|
|
|
b->obj.title_clip.b = evas_add_rectangle(b->evas.b);
|
|
|
|
|
|
|
|
evas_set_color(b->evas.l, b->obj.title_clip.l, 255, 255, 255, 255);
|
|
|
|
evas_set_color(b->evas.r, b->obj.title_clip.r, 255, 255, 255, 255);
|
|
|
|
evas_set_color(b->evas.t, b->obj.title_clip.t, 255, 255, 255, 255);
|
|
|
|
evas_set_color(b->evas.b, b->obj.title_clip.b, 255, 255, 255, 255);
|
|
|
|
|
2001-11-13 13:26:20 -08:00
|
|
|
e_text_show(b->obj.title.l);
|
|
|
|
e_text_show(b->obj.title.r);
|
|
|
|
e_text_show(b->obj.title.t);
|
|
|
|
e_text_show(b->obj.title.b);
|
2001-01-02 15:10:12 -08:00
|
|
|
|
|
|
|
evas_show(b->evas.l, b->obj.title_clip.l);
|
|
|
|
evas_show(b->evas.r, b->obj.title_clip.r);
|
|
|
|
evas_show(b->evas.t, b->obj.title_clip.t);
|
|
|
|
evas_show(b->evas.b, b->obj.title_clip.b);
|
|
|
|
|
2001-11-13 13:26:20 -08:00
|
|
|
e_text_set_clip(b->obj.title.l, b->obj.title_clip.l);
|
|
|
|
e_text_set_clip(b->obj.title.r, b->obj.title_clip.r);
|
|
|
|
e_text_set_clip(b->obj.title.t, b->obj.title_clip.t);
|
|
|
|
e_text_set_clip(b->obj.title.b, b->obj.title_clip.b);
|
2001-01-02 15:10:12 -08:00
|
|
|
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_raise(b->win.input);
|
|
|
|
ecore_window_raise(b->win.container);
|
2001-08-16 01:45:37 -07:00
|
|
|
|
2000-12-08 14:54:42 -08:00
|
|
|
evases = evas_list_append(evases, b->evas.l);
|
|
|
|
evases = evas_list_append(evases, b->evas.r);
|
|
|
|
evases = evas_list_append(evases, b->evas.t);
|
|
|
|
evases = evas_list_append(evases, b->evas.b);
|
|
|
|
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_set_events(b->win.l, XEV_EXPOSE);
|
|
|
|
ecore_window_set_events(b->win.r, XEV_EXPOSE);
|
|
|
|
ecore_window_set_events(b->win.t, XEV_EXPOSE);
|
|
|
|
ecore_window_set_events(b->win.b, XEV_EXPOSE);
|
2000-12-08 14:54:42 -08:00
|
|
|
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_show(b->win.l);
|
|
|
|
ecore_window_show(b->win.r);
|
|
|
|
ecore_window_show(b->win.t);
|
|
|
|
ecore_window_show(b->win.b);
|
2000-12-08 14:54:42 -08:00
|
|
|
|
|
|
|
e_border_attach_mouse_grabs(b);
|
2001-08-16 01:45:37 -07:00
|
|
|
|
2000-12-08 14:54:42 -08:00
|
|
|
borders = evas_list_prepend(borders, 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_(b);
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
2002-01-23 17:08:52 -08:00
|
|
|
void
|
|
|
|
e_border_iconify(E_Border *b)
|
|
|
|
{
|
|
|
|
D_ENTER;
|
|
|
|
D("iconfy window!\n");
|
|
|
|
b->client.iconified = 1;
|
|
|
|
b->current.requested.visible = 0;
|
|
|
|
e_icccm_state_iconified(b->win.client);
|
|
|
|
b->changed = 1;
|
|
|
|
e_border_update(b);
|
|
|
|
D("notify observers of iconification\n");
|
|
|
|
e_observee_notify_observers(E_OBSERVEE(b), E_EVENT_WINDOW_ICONIFY);
|
|
|
|
|
|
|
|
D_RETURN;
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
e_border_uniconify(E_Border *b)
|
|
|
|
{
|
|
|
|
b->client.iconified = 0;
|
|
|
|
b->current.requested.visible = 1;
|
|
|
|
e_icccm_state_mapped(b->win.client);
|
|
|
|
b->changed = 1;
|
|
|
|
e_border_update(b);
|
|
|
|
/* should be UNICONIFY */
|
|
|
|
e_observee_notify_observers(E_OBSERVEE(b), E_EVENT_WINDOW_ICONIFY);
|
|
|
|
}
|
|
|
|
|
2000-12-08 14:54:42 -08:00
|
|
|
void
|
|
|
|
e_border_remove_mouse_grabs(E_Border *b)
|
|
|
|
{
|
|
|
|
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
|
|
|
if (b->grabs)
|
|
|
|
{
|
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
|
|
|
for (l = b->grabs; l; l = l->next)
|
|
|
|
{
|
|
|
|
E_Grab *g;
|
|
|
|
|
|
|
|
g = l->data;
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_button_ungrab(b->win.main, g->button, g->mods, g->any_mod);
|
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
|
|
|
FREE(g);
|
|
|
|
}
|
|
|
|
evas_list_free(b->grabs);
|
|
|
|
b->grabs = NULL;
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
2001-11-03 23:38:42 -08:00
|
|
|
b->click_grab = 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
|
|
|
|
|
|
|
D_RETURN;
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
2001-10-30 03:07:12 -08:00
|
|
|
void
|
|
|
|
e_border_remove_click_grab(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;
|
|
|
|
|
2001-10-30 03:07:12 -08:00
|
|
|
if (b->click_grab)
|
|
|
|
{
|
|
|
|
E_Grab *g;
|
|
|
|
|
|
|
|
g = b->click_grab;
|
2001-11-15 21:39:34 -08:00
|
|
|
ecore_button_ungrab(b->win.container, g->button, g->mods, g->any_mod);
|
|
|
|
ecore_window_button_grab_auto_replay_set(b->win.container, NULL);
|
2001-10-30 03:07:12 -08:00
|
|
|
b->click_grab = NULL;
|
|
|
|
FREE(g);
|
|
|
|
}
|
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;
|
2001-10-30 03:07:12 -08:00
|
|
|
}
|
|
|
|
|
2000-12-08 14:54:42 -08:00
|
|
|
void
|
|
|
|
e_border_attach_mouse_grabs(E_Border *b)
|
|
|
|
{
|
2000-12-13 16:12:16 -08:00
|
|
|
char *grabs_db;
|
2000-12-08 14:54:42 -08:00
|
|
|
E_DB_File *db;
|
|
|
|
int focus_mode;
|
2001-10-12 13:13:01 -07:00
|
|
|
char buf[PATH_MAX];
|
2001-02-14 16:45:08 -08:00
|
|
|
E_CFG_INT(cfg_focus_mode, "settings", "/focus/mode", 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;
|
|
|
|
|
2001-02-14 16:45:08 -08:00
|
|
|
E_CONFIG_INT_GET(cfg_focus_mode, focus_mode);
|
2000-12-08 14:54:42 -08:00
|
|
|
|
2000-12-13 16:12:16 -08:00
|
|
|
grabs_db = e_config_get("grabs");
|
2000-12-08 14:54:42 -08:00
|
|
|
/* settings - click to focus would affect grabs */
|
2001-11-03 23:38:42 -08:00
|
|
|
if ((!b->current.selected) &&
|
|
|
|
(focus_mode == 2))
|
2000-12-08 14:54:42 -08:00
|
|
|
{
|
2001-11-03 23:38:42 -08:00
|
|
|
E_Grab *g;
|
|
|
|
|
|
|
|
g = NEW(E_Grab, 1);
|
|
|
|
ZERO(g, E_Grab, 1);
|
2001-11-15 21:39:34 -08:00
|
|
|
g->button = 1;
|
2001-11-03 23:38:42 -08:00
|
|
|
g->mods = ECORE_EVENT_KEY_MODIFIER_NONE;
|
|
|
|
g->any_mod = 0;
|
2001-11-15 21:39:34 -08:00
|
|
|
g->remove_after = 0;
|
2001-11-15 23:23:08 -08:00
|
|
|
ecore_button_grab(b->win.container, g->button, XEV_BUTTON_PRESS, g->mods, g->any_mod);
|
2001-11-15 21:39:34 -08:00
|
|
|
ecore_window_button_grab_auto_replay_set(b->win.container, e_border_replay_query);
|
2001-11-03 23:38:42 -08:00
|
|
|
b->click_grab = g;
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* other grabs - liek alt+left to move */
|
|
|
|
db = e_db_open_read(grabs_db);
|
|
|
|
if (db)
|
|
|
|
{
|
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 i, num;
|
|
|
|
|
2002-01-23 22:15:40 -08:00
|
|
|
snprintf(buf, PATH_MAX, "/grabs/count");
|
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 (!e_db_int_get(db, buf, &num))
|
|
|
|
{
|
|
|
|
e_db_close(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
|
|
|
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
|
|
|
}
|
|
|
|
for (i = 0; i < num; i++)
|
|
|
|
{
|
|
|
|
int button, any_mod, mod;
|
2001-10-17 15:34:27 -07:00
|
|
|
Ecore_Event_Key_Modifiers mods;
|
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
|
|
|
|
|
|
|
button = -1;
|
2001-10-17 15:34:27 -07:00
|
|
|
mods = ECORE_EVENT_KEY_MODIFIER_NONE;
|
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
|
|
|
any_mod = 0;
|
2002-01-23 22:15:40 -08:00
|
|
|
snprintf(buf, PATH_MAX, "/grabs/%i/button", i);
|
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 (!e_db_int_get(db, buf, &button)) continue;
|
2002-01-23 22:15:40 -08:00
|
|
|
snprintf(buf, PATH_MAX, "/grabs/%i/modifiers", i);
|
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 (!e_db_int_get(db, buf, &mod)) continue;
|
|
|
|
if (mod == -1) any_mod = 1;
|
2001-10-17 15:34:27 -07:00
|
|
|
mods = (Ecore_Event_Key_Modifiers)mod;
|
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 (button >= 0)
|
|
|
|
{
|
|
|
|
E_Grab *g;
|
|
|
|
|
|
|
|
g = NEW(E_Grab, 1);
|
|
|
|
ZERO(g, E_Grab, 1);
|
|
|
|
g->button = button;
|
|
|
|
g->mods = mods;
|
|
|
|
g->any_mod = any_mod;
|
|
|
|
g->remove_after = 0;
|
|
|
|
b->grabs = evas_list_append(b->grabs, g);
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_button_grab(b->win.main, button, XEV_BUTTON_PRESS, mods, 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
|
|
|
}
|
|
|
|
}
|
|
|
|
e_db_close(db);
|
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_border_remove_all_mouse_grabs(void)
|
|
|
|
{
|
|
|
|
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 = borders; l; l = l->next)
|
|
|
|
e_border_remove_mouse_grabs((E_Border *)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
|
|
|
|
|
|
|
D_RETURN;
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
e_border_attach_all_mouse_grabs(void)
|
|
|
|
{
|
|
|
|
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 = borders; l; l = l->next)
|
|
|
|
e_border_attach_mouse_grabs((E_Border *)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
|
|
|
|
|
|
|
D_RETURN;
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
e_border_redo_grabs(void)
|
|
|
|
{
|
2000-12-13 16:12:16 -08:00
|
|
|
char *grabs_db;
|
|
|
|
char *settings_db;
|
2000-12-08 14:54:42 -08:00
|
|
|
static time_t mod_date_grabs = 0;
|
|
|
|
static time_t mod_date_settings = 0;
|
|
|
|
time_t mod;
|
|
|
|
int changed = 0;
|
|
|
|
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-13 16:12:16 -08:00
|
|
|
grabs_db = e_config_get("grabs");
|
|
|
|
settings_db = e_config_get("settings");
|
2001-11-03 01:07:40 -08:00
|
|
|
mod = e_file_mod_time(grabs_db);
|
2000-12-08 14:54:42 -08:00
|
|
|
if (mod != mod_date_grabs) changed = 1;
|
|
|
|
mod_date_grabs = mod;
|
|
|
|
if (!changed)
|
|
|
|
{
|
2001-11-03 01:07:40 -08:00
|
|
|
mod = e_file_mod_time(settings_db);
|
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 (mod != mod_date_settings) changed = 1;
|
|
|
|
mod_date_settings = mod;
|
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
|
|
|
if (!changed) D_RETURN;
|
2000-12-08 14:54:42 -08:00
|
|
|
for (l = borders; 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_Border *b;
|
|
|
|
|
|
|
|
b = l->data;
|
|
|
|
e_border_remove_mouse_grabs(b);
|
|
|
|
e_border_attach_mouse_grabs(b);
|
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
|
|
|
}
|
|
|
|
|
|
|
|
E_Border *
|
|
|
|
e_border_find_by_window(Window win)
|
|
|
|
{
|
|
|
|
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 = borders; 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_Border *b;
|
|
|
|
|
|
|
|
b = l->data;
|
|
|
|
|
|
|
|
if ((win == b->win.main) ||
|
|
|
|
(win == b->win.client) ||
|
|
|
|
(win == b->win.container) ||
|
|
|
|
(win == b->win.input) ||
|
|
|
|
(win == b->win.l) ||
|
|
|
|
(win == b->win.r) ||
|
|
|
|
(win == b->win.t) ||
|
|
|
|
(win == b->win.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_(b);
|
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_(NULL);
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
e_border_set_bits(E_Border *b, char *file)
|
|
|
|
{
|
|
|
|
int pl, pr, pt, pb, ppl, ppr, ppt, ppb;
|
|
|
|
|
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
|
|
|
pl = pr = pt = pb = 0;
|
|
|
|
ppl = ppr = ppt = ppb = 0;
|
|
|
|
|
|
|
|
if (b->bits.t) ebits_get_insets(b->bits.t, &pl, &pr, &pt, &pb);
|
|
|
|
|
|
|
|
if (b->bits.l) ebits_free(b->bits.l);
|
|
|
|
if (b->bits.r) ebits_free(b->bits.r);
|
|
|
|
if (b->bits.t) ebits_free(b->bits.t);
|
|
|
|
if (b->bits.b) ebits_free(b->bits.b);
|
|
|
|
|
|
|
|
b->bits.l = ebits_load(file);
|
|
|
|
b->bits.r = ebits_load(file);
|
|
|
|
b->bits.t = ebits_load(file);
|
|
|
|
b->bits.b = ebits_load(file);
|
|
|
|
b->bits.new = 1;
|
|
|
|
b->changed = 1;
|
|
|
|
|
2001-01-02 15:10:12 -08:00
|
|
|
if (b->bits.t) ebits_get_insets(b->bits.t, &ppl, &ppr, &ppt, &ppb);
|
2000-12-08 14:54:42 -08:00
|
|
|
b->current.requested.w -= (pl + pr) - (ppl + ppr);
|
|
|
|
b->current.requested.h -= (pt + pb) - (ppt + ppb);
|
|
|
|
b->current.requested.x += (pl - ppl);
|
|
|
|
b->current.requested.y += (pt - ppt);
|
|
|
|
|
|
|
|
if (b->bits.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
|
|
|
ebits_add_to_evas(b->bits.l, b->evas.l);
|
|
|
|
ebits_move(b->bits.l, 0, 0);
|
|
|
|
ebits_show(b->bits.l);
|
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
|
|
|
ebits_add_to_evas(b->bits.r, b->evas.r);
|
|
|
|
ebits_move(b->bits.r, 0, 0);
|
|
|
|
ebits_show(b->bits.r);
|
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
|
|
|
ebits_add_to_evas(b->bits.t, b->evas.t);
|
|
|
|
ebits_move(b->bits.t, 0, 0);
|
|
|
|
ebits_show(b->bits.t);
|
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
|
|
|
ebits_add_to_evas(b->bits.b, b->evas.b);
|
|
|
|
ebits_move(b->bits.b, 0, 0);
|
|
|
|
ebits_show(b->bits.b);
|
|
|
|
|
|
|
|
e_border_set_color_class(b, "Title BG", 100, 200, 255, 255);
|
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
|
|
|
#define HOOK_CB(_class) \
|
2001-09-06 06:20:35 -07:00
|
|
|
ebits_set_classed_bit_callback(b->bits.t, _class, CALLBACK_MOUSE_IN, e_cb_mouse_in, b); \
|
|
|
|
ebits_set_classed_bit_callback(b->bits.t, _class, CALLBACK_MOUSE_OUT, e_cb_mouse_out, b); \
|
|
|
|
ebits_set_classed_bit_callback(b->bits.t, _class, CALLBACK_MOUSE_DOWN, e_cb_mouse_down, b); \
|
|
|
|
ebits_set_classed_bit_callback(b->bits.t, _class, CALLBACK_MOUSE_UP, e_cb_mouse_up, b); \
|
|
|
|
ebits_set_classed_bit_callback(b->bits.t, _class, CALLBACK_MOUSE_MOVE, e_cb_mouse_move, b);
|
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
|
|
|
HOOK_CB("Title_Bar");
|
|
|
|
HOOK_CB("Resize");
|
|
|
|
HOOK_CB("Resize_Horizontal");
|
|
|
|
HOOK_CB("Resize_Vertical");
|
|
|
|
HOOK_CB("Close");
|
|
|
|
HOOK_CB("Iconify");
|
|
|
|
HOOK_CB("Max_Size");
|
|
|
|
HOOK_CB("Menu");
|
|
|
|
|
|
|
|
e_border_adjust_limits(b);
|
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_border_set_color_class(E_Border *b, char *class, int rr, int gg, int bb, int aa)
|
|
|
|
{
|
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
|
|
|
ebits_set_color_class(b->bits.l, class, rr, gg, bb, aa);
|
|
|
|
ebits_set_color_class(b->bits.r, class, rr, gg, bb, aa);
|
|
|
|
ebits_set_color_class(b->bits.t, class, rr, gg, bb, aa);
|
|
|
|
ebits_set_color_class(b->bits.b, class, rr, gg, bb, aa);
|
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_border_adjust_limits(E_Border *b)
|
|
|
|
{
|
|
|
|
int w, h, pl, pr, pt, pb, mx, my;
|
|
|
|
|
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;
|
|
|
|
|
2001-02-12 10:58:51 -08:00
|
|
|
if (b->mode.move)
|
|
|
|
{
|
|
|
|
e_resist_border(b);
|
|
|
|
}
|
2000-12-08 14:54:42 -08:00
|
|
|
else
|
|
|
|
{
|
|
|
|
b->current.x = b->current.requested.x;
|
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.y = b->current.requested.y;
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
b->current.w = b->current.requested.w;
|
2000-12-12 19:14:18 -08:00
|
|
|
b->current.h = b->current.requested.h - b->current.shaded;
|
2000-12-08 14:54:42 -08:00
|
|
|
|
2001-02-12 10:58:51 -08:00
|
|
|
if ((!b->current.shaded) && (!b->mode.move))
|
|
|
|
{
|
2000-12-12 19:14:18 -08:00
|
|
|
if (b->current.w < 1) b->current.w = 1;
|
|
|
|
if (b->current.h < 1) b->current.h = 1;
|
|
|
|
|
|
|
|
pl = pr = pt = pb = 0;
|
|
|
|
if (b->bits.t) ebits_get_insets(b->bits.t, &pl, &pr, &pt, &pb);
|
|
|
|
|
|
|
|
if (b->current.w < (pl + pr + 1)) b->current.w = pl + pr + 1;
|
|
|
|
if (b->current.h < (pt + pb + 1)) b->current.h = pt + pb + 1;
|
|
|
|
|
|
|
|
w = b->current.w - pl - pr;
|
|
|
|
h = b->current.h - pt - pb + b->current.shaded;
|
|
|
|
|
|
|
|
mx = my = 1;
|
|
|
|
if (b->bits.t) ebits_get_min_size(b->bits.t, &mx, &my);
|
|
|
|
if (b->current.w < mx) b->current.w = mx;
|
|
|
|
if (b->current.h < my) b->current.h = my;
|
|
|
|
mx = my = 999999;
|
|
|
|
if (b->bits.t) ebits_get_max_size(b->bits.t, &mx, &my);
|
|
|
|
if (b->current.w > mx) b->current.w = mx;
|
|
|
|
if (b->current.h > my) b->current.h = my;
|
|
|
|
|
|
|
|
if (w < b->client.min.w) w = b->client.min.w;
|
|
|
|
if (h < b->client.min.h) h = b->client.min.h;
|
|
|
|
if (w > b->client.max.w) w = b->client.max.w;
|
|
|
|
if (h > b->client.max.h) h = b->client.max.h;
|
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 ((w > 0) && (h > 0))
|
|
|
|
{
|
2000-12-12 19:14:18 -08:00
|
|
|
w -= b->client.base.w;
|
|
|
|
h -= b->client.base.h;
|
|
|
|
if ((w > 0) && (h > 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
|
|
|
{
|
2000-12-12 19:14:18 -08:00
|
|
|
int i, j;
|
|
|
|
double aspect;
|
|
|
|
|
|
|
|
aspect = ((double)w) / ((double)h);
|
|
|
|
if ((b->mode.resize == 4) || (b->mode.resize == 5))
|
|
|
|
{
|
|
|
|
if (aspect < b->client.min.aspect)
|
|
|
|
h = (int)((double)w / b->client.min.aspect);
|
|
|
|
if (aspect > b->client.max.aspect)
|
|
|
|
h = (int)((double)w / b->client.max.aspect);
|
|
|
|
}
|
|
|
|
else if ((b->mode.resize == 6) || (b->mode.resize == 7))
|
|
|
|
{
|
|
|
|
if (aspect < b->client.min.aspect)
|
|
|
|
w = (int)((double)h * b->client.min.aspect);
|
|
|
|
if (aspect > b->client.max.aspect)
|
|
|
|
w = (int)((double)h * b->client.max.aspect);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
if (aspect < b->client.min.aspect)
|
|
|
|
w = (int)((double)h * b->client.min.aspect);
|
|
|
|
if (aspect > b->client.max.aspect)
|
|
|
|
h = (int)((double)w / b->client.max.aspect);
|
|
|
|
}
|
|
|
|
i = w / b->client.step.w;
|
|
|
|
j = h / b->client.step.h;
|
|
|
|
w = i * b->client.step.w;
|
|
|
|
h = j * b->client.step.h;
|
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-12 19:14:18 -08:00
|
|
|
w += b->client.base.w;
|
|
|
|
h += b->client.base.h;
|
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-12 19:14:18 -08:00
|
|
|
b->client.w = w;
|
|
|
|
b->client.h = h;
|
|
|
|
b->current.w = w + pl + pr;
|
|
|
|
b->current.h = h + pt + pb;
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
2000-12-12 19:14:18 -08:00
|
|
|
|
|
|
|
if (b->current.shaded == 0)
|
2000-12-08 14:54:42 -08:00
|
|
|
{
|
2001-03-22 10:10:08 -08:00
|
|
|
if ((b->mode.resize == 4) || (b->mode.resize == 6) || (b->mode.resize == 8))
|
2000-12-12 19:14:18 -08:00
|
|
|
{
|
|
|
|
}
|
2001-03-22 10:10:08 -08:00
|
|
|
else if ((b->mode.resize == 1) || (b->mode.resize == 5))
|
2000-12-12 19:14:18 -08:00
|
|
|
{
|
|
|
|
b->current.x += (b->current.requested.w - b->current.w);
|
|
|
|
b->current.y += (b->current.requested.h - b->current.h);
|
|
|
|
}
|
2001-03-22 10:10:08 -08:00
|
|
|
else if ((b->mode.resize == 2) || (b->mode.resize == 7))
|
2000-12-12 19:14:18 -08:00
|
|
|
{
|
|
|
|
b->current.y += (b->current.requested.h - b->current.h);
|
|
|
|
}
|
2001-03-22 10:10:08 -08:00
|
|
|
else if ((b->mode.resize == 3))
|
2000-12-12 19:14:18 -08:00
|
|
|
{
|
|
|
|
b->current.x += (b->current.requested.w - b->current.w);
|
|
|
|
}
|
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_border_update(E_Border *b)
|
|
|
|
{
|
|
|
|
int location_changed = 0;
|
|
|
|
int size_changed = 0;
|
|
|
|
int shape_changed = 0;
|
|
|
|
int border_changed = 0;
|
|
|
|
int visibility_changed = 0;
|
|
|
|
int state_changed = 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 (b->hold_changes) D_RETURN;
|
|
|
|
if (!b->changed) D_RETURN;
|
2000-12-08 14:54:42 -08:00
|
|
|
|
|
|
|
b->current.visible = b->current.requested.visible;
|
|
|
|
|
|
|
|
if ((b->current.x != b->previous.x) || (b->current.y != b->previous.y))
|
|
|
|
location_changed = 1;
|
|
|
|
if ((b->current.w != b->previous.w) || (b->current.h != b->previous.h))
|
|
|
|
size_changed = 1;
|
2000-12-18 13:28:44 -08:00
|
|
|
if ((size_changed) && (b->current.has_shape))
|
2000-12-08 14:54:42 -08:00
|
|
|
shape_changed = 1;
|
|
|
|
if (b->current.selected != b->previous.selected)
|
|
|
|
state_changed = 1;
|
|
|
|
if (state_changed)
|
|
|
|
{
|
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_border_apply_border(b);
|
|
|
|
if (!border_changed)
|
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_gravity_set(b->win.container, StaticGravity);
|
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
|
|
|
border_changed = 1;
|
|
|
|
size_changed = 1;
|
|
|
|
}
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
2001-11-19 23:01:53 -08:00
|
|
|
if (b->bits.new)
|
|
|
|
{
|
|
|
|
ecore_window_gravity_set(b->win.container, StaticGravity);
|
|
|
|
border_changed = 1;
|
|
|
|
}
|
|
|
|
if ((border_changed) && (b->current.has_shape))
|
|
|
|
shape_changed = 1;
|
|
|
|
if (b->current.visible != b->previous.visible)
|
|
|
|
visibility_changed = 1;
|
|
|
|
|
2000-12-08 14:54:42 -08:00
|
|
|
if ((location_changed) && (!size_changed))
|
|
|
|
{
|
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 pl, pr, pt, pb;
|
|
|
|
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_move(b->win.main, b->current.x, b->current.y);
|
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
|
|
|
pl = pr = pt = pb = 0;
|
|
|
|
if (b->bits.t) ebits_get_insets(b->bits.t, &pl, &pr, &pt, &pb);
|
|
|
|
e_icccm_move_resize(b->win.client,
|
2000-12-12 19:14:18 -08:00
|
|
|
b->current.x + pl,
|
|
|
|
b->current.y + pt,
|
|
|
|
b->client.w,
|
|
|
|
b->client.h);
|
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_cb_border_move_resize(b);
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
else if (size_changed)
|
|
|
|
{
|
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 pl, pr, pt, pb, x, y, w, h;
|
|
|
|
int smaller;
|
|
|
|
|
2000-12-18 13:28:44 -08:00
|
|
|
if ((b->current.shaped_client) || (b->previous.shaped_client) ||
|
|
|
|
(b->current.shape_changes) || (b->previous.shape_changes) ||
|
|
|
|
(b->current.has_shape) || (b->previous.has_shape))
|
|
|
|
b->shape_changed = 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
|
|
|
smaller = 0;
|
|
|
|
if ((b->current.w < b->previous.w) || (b->current.h < b->previous.h))
|
|
|
|
smaller = 1;
|
|
|
|
pl = pr = pt = pb = 0;
|
|
|
|
if (b->bits.t) ebits_get_insets(b->bits.t, &pl, &pr, &pt, &pb);
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_move_resize(b->win.input,
|
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
|
|
|
0, 0, b->current.w, b->current.h);
|
2001-03-27 11:02:37 -08:00
|
|
|
if (smaller)
|
2000-12-12 19:14:18 -08:00
|
|
|
{
|
2001-03-27 11:02:37 -08:00
|
|
|
if (b->current.shaded == b->client.h)
|
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_move_resize(b->win.client,
|
2001-03-27 11:02:37 -08:00
|
|
|
0, - b->current.shaded,
|
|
|
|
b->client.w,
|
|
|
|
b->client.h);
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_move_resize(b->win.container,
|
2001-03-27 11:02:37 -08:00
|
|
|
b->current.w + 1,
|
|
|
|
b->current.h + 1,
|
|
|
|
320,
|
|
|
|
320);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_move_resize(b->win.client,
|
2001-03-27 11:02:37 -08:00
|
|
|
0, - b->current.shaded,
|
|
|
|
b->client.w,
|
|
|
|
b->client.h);
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_move_resize(b->win.container,
|
2001-03-27 11:02:37 -08:00
|
|
|
pl,
|
|
|
|
pt,
|
|
|
|
b->current.w - pl - pr,
|
|
|
|
b->current.h - pt - pb);
|
|
|
|
}
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_move_resize(b->win.main,
|
2001-03-27 11:02:37 -08:00
|
|
|
b->current.x, b->current.y,
|
|
|
|
b->current.w, b->current.h);
|
|
|
|
x = 0, y = pt, w = pl, h = (b->current.h - pt - pb);
|
2001-10-17 15:34:27 -07:00
|
|
|
if ((w <1) || (h < 1)) ecore_window_hide(b->win.l);
|
2001-03-27 11:02:37 -08:00
|
|
|
else
|
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_show(b->win.l);
|
|
|
|
ecore_window_move_resize(b->win.l, x, y, w, h);
|
2001-03-27 11:02:37 -08:00
|
|
|
evas_set_output_size(b->evas.l, w, h);
|
|
|
|
evas_set_output_viewport(b->evas.l, x, y, w, h);
|
|
|
|
}
|
|
|
|
|
|
|
|
x = 0, y = 0, w = b->current.w, h = pt;
|
2001-10-17 15:34:27 -07:00
|
|
|
if ((w <1) || (h < 1)) ecore_window_hide(b->win.t);
|
2001-03-27 11:02:37 -08:00
|
|
|
else
|
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_show(b->win.t);
|
|
|
|
ecore_window_move_resize(b->win.t, x, y, w, h);
|
2001-03-27 11:02:37 -08:00
|
|
|
evas_set_output_size(b->evas.t, w, h);
|
|
|
|
evas_set_output_viewport(b->evas.t, x, y, w, h);
|
|
|
|
}
|
|
|
|
|
|
|
|
x = b->current.w - pr, y = pt, w = pr, h = (b->current.h - pt - pb);
|
2001-10-17 15:34:27 -07:00
|
|
|
if ((w <1) || (h < 1)) ecore_window_hide(b->win.r);
|
2001-03-27 11:02:37 -08:00
|
|
|
else
|
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_show(b->win.r);
|
|
|
|
ecore_window_move_resize(b->win.r, x, y, w, h);
|
2001-03-27 11:02:37 -08:00
|
|
|
evas_set_output_size(b->evas.r, w, h);
|
|
|
|
evas_set_output_viewport(b->evas.r, x, y, w, h);
|
|
|
|
}
|
|
|
|
|
|
|
|
x = 0, y = b->current.h - pb, w = b->current.w, h = pb;
|
2001-10-17 15:34:27 -07:00
|
|
|
if ((w <1) || (h < 1)) ecore_window_hide(b->win.b);
|
2001-03-27 11:02:37 -08:00
|
|
|
else
|
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_show(b->win.b);
|
|
|
|
ecore_window_move_resize(b->win.b, x, y, w, h);
|
2001-03-27 11:02:37 -08:00
|
|
|
evas_set_output_size(b->evas.b, w, h);
|
|
|
|
evas_set_output_viewport(b->evas.b, x, y, w, h);
|
|
|
|
}
|
2000-12-12 19:14:18 -08:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_move_resize(b->win.main,
|
2001-03-27 11:02:37 -08:00
|
|
|
b->current.x, b->current.y,
|
|
|
|
b->current.w, b->current.h);
|
|
|
|
x = 0, y = pt, w = pl, h = (b->current.h - pt - pb);
|
2001-10-17 15:34:27 -07:00
|
|
|
if ((w <1) || (h < 1)) ecore_window_hide(b->win.l);
|
2001-03-27 11:02:37 -08:00
|
|
|
else
|
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_show(b->win.l);
|
|
|
|
ecore_window_move_resize(b->win.l, x, y, w, h);
|
2001-03-27 11:02:37 -08:00
|
|
|
evas_set_output_size(b->evas.l, w, h);
|
|
|
|
evas_set_output_viewport(b->evas.l, x, y, w, h);
|
|
|
|
}
|
|
|
|
|
|
|
|
x = 0, y = 0, w = b->current.w, h = pt;
|
2001-10-17 15:34:27 -07:00
|
|
|
if ((w <1) || (h < 1)) ecore_window_hide(b->win.t);
|
2001-03-27 11:02:37 -08:00
|
|
|
else
|
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_show(b->win.t);
|
|
|
|
ecore_window_move_resize(b->win.t, x, y, w, h);
|
2001-03-27 11:02:37 -08:00
|
|
|
evas_set_output_size(b->evas.t, w, h);
|
|
|
|
evas_set_output_viewport(b->evas.t, x, y, w, h);
|
|
|
|
}
|
|
|
|
|
|
|
|
x = b->current.w - pr, y = pt, w = pr, h = (b->current.h - pt - pb);
|
2001-10-17 15:34:27 -07:00
|
|
|
if ((w <1) || (h < 1)) ecore_window_hide(b->win.r);
|
2001-03-27 11:02:37 -08:00
|
|
|
else
|
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_show(b->win.r);
|
|
|
|
ecore_window_move_resize(b->win.r, x, y, w, h);
|
2001-03-27 11:02:37 -08:00
|
|
|
evas_set_output_size(b->evas.r, w, h);
|
|
|
|
evas_set_output_viewport(b->evas.r, x, y, w, h);
|
|
|
|
}
|
|
|
|
|
|
|
|
x = 0, y = b->current.h - pb, w = b->current.w, h = pb;
|
2001-10-17 15:34:27 -07:00
|
|
|
if ((w <1) || (h < 1)) ecore_window_hide(b->win.b);
|
2001-03-27 11:02:37 -08:00
|
|
|
else
|
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_show(b->win.b);
|
|
|
|
ecore_window_move_resize(b->win.b, x, y, w, h);
|
2001-03-27 11:02:37 -08:00
|
|
|
evas_set_output_size(b->evas.b, w, h);
|
|
|
|
evas_set_output_viewport(b->evas.b, x, y, w, h);
|
|
|
|
}
|
|
|
|
if (b->current.shaded == b->client.h)
|
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_move_resize(b->win.container,
|
2001-03-27 11:02:37 -08:00
|
|
|
b->current.w + 1,
|
|
|
|
b->current.h + 1,
|
|
|
|
320,
|
|
|
|
320);
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_move_resize(b->win.client,
|
2001-03-27 11:02:37 -08:00
|
|
|
0, - b->current.shaded,
|
|
|
|
b->client.w,
|
|
|
|
b->client.h);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_move_resize(b->win.container,
|
2001-03-27 11:02:37 -08:00
|
|
|
pl,
|
|
|
|
pt,
|
|
|
|
b->current.w - pl - pr,
|
|
|
|
b->current.h - pt - pb);
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_move_resize(b->win.client,
|
2001-03-27 11:02:37 -08:00
|
|
|
0, - b->current.shaded,
|
|
|
|
b->client.w,
|
|
|
|
b->client.h);
|
|
|
|
}
|
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->bits.l) ebits_resize(b->bits.l, b->current.w, b->current.h);
|
|
|
|
if (b->bits.r) ebits_resize(b->bits.r, b->current.w, b->current.h);
|
|
|
|
if (b->bits.t) ebits_resize(b->bits.t, b->current.w, b->current.h);
|
|
|
|
if (b->bits.b) ebits_resize(b->bits.b, b->current.w, b->current.h);
|
2001-01-02 15:10:12 -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
|
|
|
e_icccm_move_resize(b->win.client,
|
2000-12-12 19:14:18 -08:00
|
|
|
b->current.x + pl, b->current.y + pt - b->current.shaded,
|
|
|
|
b->client.w, b->client.h);
|
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_cb_border_move_resize(b);
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
2001-01-02 15:10:12 -08:00
|
|
|
if ((b->client.title) && (b->bits.t))
|
|
|
|
{
|
|
|
|
double tx, ty, tw, th;
|
|
|
|
|
2001-09-06 06:20:35 -07:00
|
|
|
ebits_get_named_bit_geometry(b->bits.l, "Title_Area", &tx, &ty, &tw, &th);
|
2001-11-13 13:26:20 -08:00
|
|
|
if (b->obj.title.l)
|
|
|
|
{
|
|
|
|
e_text_set_text(b->obj.title.l, b->client.title);
|
|
|
|
e_text_move(b->obj.title.l, tx, ty);
|
|
|
|
if (b->current.selected)
|
|
|
|
e_text_set_state(b->obj.title.l, "selected");
|
|
|
|
else
|
|
|
|
e_text_set_state(b->obj.title.l, "normal");
|
|
|
|
}
|
2001-01-02 15:10:12 -08:00
|
|
|
evas_move(b->evas.l, b->obj.title_clip.l, tx, ty);
|
|
|
|
evas_resize(b->evas.l, b->obj.title_clip.l, tw, th);
|
|
|
|
|
2001-09-06 06:20:35 -07:00
|
|
|
ebits_get_named_bit_geometry(b->bits.r, "Title_Area", &tx, &ty, &tw, &th);
|
2001-11-13 13:26:20 -08:00
|
|
|
if (b->obj.title.r)
|
|
|
|
{
|
|
|
|
e_text_set_text(b->obj.title.r, b->client.title);
|
|
|
|
e_text_move(b->obj.title.r, tx, ty);
|
|
|
|
if (b->current.selected)
|
|
|
|
e_text_set_state(b->obj.title.r, "selected");
|
|
|
|
else
|
|
|
|
e_text_set_state(b->obj.title.r, "normal");
|
|
|
|
}
|
2001-01-02 15:10:12 -08:00
|
|
|
evas_move(b->evas.r, b->obj.title_clip.r, tx, ty);
|
|
|
|
evas_resize(b->evas.r, b->obj.title_clip.r, tw, th);
|
|
|
|
|
2001-09-06 06:20:35 -07:00
|
|
|
ebits_get_named_bit_geometry(b->bits.t, "Title_Area", &tx, &ty, &tw, &th);
|
2001-11-13 13:26:20 -08:00
|
|
|
if (b->obj.title.t)
|
|
|
|
{
|
|
|
|
e_text_set_text(b->obj.title.t, b->client.title);
|
|
|
|
e_text_move(b->obj.title.t, tx, ty);
|
|
|
|
if (b->current.selected)
|
|
|
|
e_text_set_state(b->obj.title.t, "selected");
|
|
|
|
else
|
|
|
|
e_text_set_state(b->obj.title.t, "normal");
|
|
|
|
}
|
2001-01-02 15:10:12 -08:00
|
|
|
evas_move(b->evas.t, b->obj.title_clip.t, tx, ty);
|
|
|
|
evas_resize(b->evas.t, b->obj.title_clip.t, tw, th);
|
|
|
|
|
2001-09-06 06:20:35 -07:00
|
|
|
ebits_get_named_bit_geometry(b->bits.b, "Title_Area", &tx, &ty, &tw, &th);
|
2001-11-13 13:26:20 -08:00
|
|
|
if (b->obj.title.b)
|
|
|
|
{
|
|
|
|
e_text_set_text(b->obj.title.b, b->client.title);
|
|
|
|
e_text_move(b->obj.title.b, tx, ty);
|
|
|
|
if (b->current.selected)
|
|
|
|
e_text_set_state(b->obj.title.b, "selected");
|
|
|
|
else
|
|
|
|
e_text_set_state(b->obj.title.b, "normal");
|
|
|
|
}
|
2001-01-02 15:10:12 -08:00
|
|
|
evas_move(b->evas.b, b->obj.title_clip.b, tx, ty);
|
|
|
|
evas_resize(b->evas.b, b->obj.title_clip.b, tw, th);
|
|
|
|
|
2001-11-13 13:26:20 -08:00
|
|
|
if (b->obj.title.l)
|
|
|
|
e_text_set_layer(b->obj.title.l, 1);
|
|
|
|
if (b->obj.title.r)
|
|
|
|
e_text_set_layer(b->obj.title.r, 1);
|
|
|
|
if (b->obj.title.t)
|
|
|
|
e_text_set_layer(b->obj.title.t, 1);
|
|
|
|
if (b->obj.title.b)
|
|
|
|
e_text_set_layer(b->obj.title.b, 1);
|
2001-01-02 15:10:12 -08:00
|
|
|
}
|
2000-12-18 13:28:44 -08:00
|
|
|
e_border_reshape(b);
|
2000-12-08 14:54:42 -08:00
|
|
|
if (visibility_changed)
|
|
|
|
{
|
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->current.visible)
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_show(b->win.main);
|
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
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_hide(b->win.main);
|
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_cb_border_visibility(b);
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (border_changed)
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_gravity_set(b->win.container, NorthWestGravity);
|
2000-12-08 14:54:42 -08:00
|
|
|
b->bits.new = 0;
|
|
|
|
b->previous = b->current;
|
|
|
|
b->changed = 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;
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
e_border_set_layer(E_Border *b, int layer)
|
|
|
|
{
|
|
|
|
int dl;
|
|
|
|
|
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 (b->client.layer == layer) D_RETURN;
|
2000-12-08 14:54:42 -08:00
|
|
|
dl = layer - b->client.layer;
|
|
|
|
b->client.layer = layer;
|
|
|
|
if (dl > 0) e_border_lower(b);
|
|
|
|
else 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;
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
2001-09-24 14:21:25 -07:00
|
|
|
static void
|
|
|
|
e_border_raise_delayed(int val, void *b)
|
|
|
|
{
|
|
|
|
int auto_raise = 0;
|
|
|
|
E_CFG_INT(cfg_auto_raise, "settings", "/window/raise/auto", 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;
|
|
|
|
|
2001-09-24 14:21:25 -07:00
|
|
|
E_CONFIG_INT_GET(cfg_auto_raise, auto_raise);
|
|
|
|
if (auto_raise)
|
|
|
|
e_border_raise((E_Border *)b);
|
2001-09-30 15:24:24 -07: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;
|
2001-09-30 15:24:24 -07:00
|
|
|
UN(val);
|
2001-09-24 14:21:25 -07:00
|
|
|
}
|
|
|
|
|
2000-12-08 14:54:42 -08:00
|
|
|
void
|
|
|
|
e_border_raise(E_Border *b)
|
|
|
|
{
|
|
|
|
Evas_List l;
|
|
|
|
E_Border *rel;
|
|
|
|
|
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
|
|
|
if (!b->desk->windows)
|
|
|
|
{
|
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->desk->windows = evas_list_append(b->desk->windows, b);
|
|
|
|
b->desk->changed = 1;
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_raise(b->win.main);
|
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
|
|
|
}
|
|
|
|
for (l = b->desk->windows; 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
|
|
|
rel = l->data;
|
|
|
|
if (rel->client.layer > b->client.layer)
|
|
|
|
{
|
|
|
|
b->desk->windows = evas_list_remove(b->desk->windows, b);
|
|
|
|
b->desk->windows = evas_list_prepend_relative(b->desk->windows, b, rel);
|
|
|
|
b->desk->changed = 1;
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_stack_below(b->win.main, rel->win.main);
|
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
|
|
|
}
|
|
|
|
if ((!l->next) && (l->data != b))
|
|
|
|
{
|
|
|
|
b->desk->windows = evas_list_remove(b->desk->windows, b);
|
|
|
|
b->desk->windows = evas_list_append(b->desk->windows, b);
|
|
|
|
b->desk->changed = 1;
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_raise(b->win.main);
|
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
|
|
|
}
|
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_border_lower(E_Border *b)
|
|
|
|
{
|
|
|
|
Evas_List l;
|
|
|
|
E_Border *rel;
|
|
|
|
|
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
|
|
|
if (!b->desk->windows)
|
|
|
|
{
|
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->desk->windows = evas_list_append(b->desk->windows, b);
|
|
|
|
b->desk->changed = 1;
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_raise(b->win.main);
|
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
|
|
|
}
|
|
|
|
for (l = b->desk->windows; 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
|
|
|
rel = l->data;
|
|
|
|
if (rel->client.layer == b->client.layer)
|
|
|
|
{
|
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 == rel) 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
|
|
|
b->desk->windows = evas_list_remove(b->desk->windows, b);
|
|
|
|
b->desk->windows = evas_list_prepend_relative(b->desk->windows, b, rel);
|
|
|
|
b->desk->changed = 1;
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_stack_below(b->win.main, rel->win.main);
|
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
|
|
|
}
|
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_border_raise_above(E_Border *b, E_Border *above)
|
|
|
|
{
|
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
|
|
|
if (!b->desk->windows)
|
|
|
|
{
|
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->desk->windows = evas_list_append(b->desk->windows, b);
|
|
|
|
b->desk->changed = 1;
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_raise(b->win.main);
|
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
|
|
|
if (!evas_list_find(b->desk->windows, above)) D_RETURN;
|
2000-12-08 14:54:42 -08:00
|
|
|
if (b->client.layer < above->client.layer) b->client.layer = above->client.layer;
|
|
|
|
b->desk->windows = evas_list_remove(b->desk->windows, b);
|
|
|
|
b->desk->windows = evas_list_append_relative(b->desk->windows, b, above);
|
|
|
|
b->desk->changed = 1;
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_stack_above(b->win.main, above->win.main);
|
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_border_lower_below(E_Border *b, E_Border *below)
|
|
|
|
{
|
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
|
|
|
if (!b->desk->windows)
|
|
|
|
{
|
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->desk->windows = evas_list_append(b->desk->windows, b);
|
|
|
|
b->desk->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;
|
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
|
|
|
if (!evas_list_find(b->desk->windows, below)) D_RETURN;
|
2000-12-08 14:54:42 -08:00
|
|
|
if (b->client.layer > below->client.layer) b->client.layer = below->client.layer;
|
|
|
|
b->desk->windows = evas_list_remove(b->desk->windows, b);
|
|
|
|
b->desk->windows = evas_list_prepend_relative(b->desk->windows, b, below);
|
|
|
|
b->desk->changed = 1;
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_window_stack_below(b->win.main, below->win.main);
|
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_border_init(void)
|
|
|
|
{
|
2001-09-24 14:21:25 -07:00
|
|
|
double raise_delay = 0.5;
|
|
|
|
E_CFG_FLOAT(cfg_raise_delay, "settings", "/window/raise/delay", 0.5);
|
|
|
|
|
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;
|
|
|
|
|
2001-09-24 14:21:25 -07:00
|
|
|
E_CONFIG_FLOAT_GET(cfg_raise_delay, raise_delay);
|
|
|
|
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_event_filter_handler_add(ECORE_EVENT_MOUSE_DOWN, e_mouse_down);
|
|
|
|
ecore_event_filter_handler_add(ECORE_EVENT_MOUSE_UP, e_mouse_up);
|
|
|
|
ecore_event_filter_handler_add(ECORE_EVENT_MOUSE_MOVE, e_mouse_move);
|
|
|
|
ecore_event_filter_handler_add(ECORE_EVENT_MOUSE_IN, e_mouse_in);
|
|
|
|
ecore_event_filter_handler_add(ECORE_EVENT_MOUSE_OUT, e_mouse_out);
|
2001-11-01 15:54:48 -08:00
|
|
|
ecore_event_filter_handler_add(ECORE_EVENT_WINDOW_EXPOSE, e_window_expose);
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_event_filter_handler_add(ECORE_EVENT_WINDOW_MAP_REQUEST, e_map_request);
|
|
|
|
ecore_event_filter_handler_add(ECORE_EVENT_WINDOW_CONFIGURE_REQUEST, e_configure_request);
|
|
|
|
ecore_event_filter_handler_add(ECORE_EVENT_WINDOW_PROPERTY, e_property);
|
|
|
|
ecore_event_filter_handler_add(ECORE_EVENT_WINDOW_UNMAP, e_unmap);
|
|
|
|
ecore_event_filter_handler_add(ECORE_EVENT_WINDOW_DESTROY, e_destroy);
|
|
|
|
ecore_event_filter_handler_add(ECORE_EVENT_WINDOW_CIRCULATE_REQUEST, e_circulate_request);
|
|
|
|
ecore_event_filter_handler_add(ECORE_EVENT_WINDOW_REPARENT, e_reparent);
|
|
|
|
ecore_event_filter_handler_add(ECORE_EVENT_WINDOW_SHAPE, e_shape);
|
2001-11-01 15:54:48 -08:00
|
|
|
ecore_event_filter_handler_add(ECORE_EVENT_WINDOW_FOCUS_IN, e_focus_in);
|
|
|
|
ecore_event_filter_handler_add(ECORE_EVENT_WINDOW_FOCUS_OUT, e_focus_out);
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_event_filter_handler_add(ECORE_EVENT_MESSAGE, e_client_message);
|
|
|
|
ecore_event_filter_handler_add(ECORE_EVENT_COLORMAP, e_colormap);
|
2001-11-01 15:54:48 -08:00
|
|
|
ecore_event_filter_idle_handler_add(e_idle, NULL);
|
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
|
|
|
delayed_window_raise =
|
2002-01-16 20:32:08 -08:00
|
|
|
e_delayed_action_new(E_EVENT_WINDOW_FOCUS_IN,
|
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
|
|
|
raise_delay, e_border_raise_delayed);
|
2001-09-24 14:21:25 -07:00
|
|
|
|
2001-10-17 15:34:27 -07:00
|
|
|
ecore_add_event_timer("e_border_poll()", 1.00, e_border_poll, 0, 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
|
|
|
|
|
|
|
D_RETURN;
|
2000-12-08 14:54:42 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
e_border_adopt_children(Window win)
|
|
|
|
{
|
|
|
|
Window *wins;
|
|
|
|
int i, num;
|
|
|
|
|
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;
|
|
|
|
|
2001-10-17 15:34:27 -07:00
|
|
|
wins = ecore_window_get_children(win, &num);
|
2000-12-08 14:54:42 -08:00
|
|
|
if (wins)
|
|
|
|
{
|
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
|
|
|
for (i = 0; i < num; i++)
|
|
|
|
{
|
2001-10-17 15:34:27 -07:00
|
|
|
if (ecore_window_is_manageable(wins[i]))
|
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_Border *b;
|
|
|
|
|
|
|
|
b = e_border_adopt(wins[i], 1);
|
|
|
|
{
|
|
|
|
int pl, pr, pt, pb;
|
|
|
|
|
|
|
|
pl = pr = pt = pb = 0;
|
|
|
|
if (b->bits.l) ebits_get_insets(b->bits.l, &pl, &pr, &pt, &pb);
|
|
|
|
b->current.requested.x -= pl;
|
|
|
|
b->current.requested.y -= pt;
|
|
|
|
b->changed = 1;
|
|
|
|
e_border_adjust_limits(b);
|
|
|
|
}
|
|
|
|
b->ignore_unmap = 2;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
free(wins);
|
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
|
|
|
}
|
2001-03-17 17:16:47 -08:00
|
|
|
|
|
|
|
E_Border *
|
|
|
|
e_border_current_focused(void)
|
|
|
|
{
|
|
|
|
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;
|
2001-03-17 17:16:47 -08:00
|
|
|
for (l = borders; l; l = l->next)
|
|
|
|
{
|
|
|
|
E_Border *b;
|
|
|
|
|
|
|
|
b = 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 (b->current.selected) D_RETURN_(b);
|
2001-03-17 17:16:47 -08:00
|
|
|
}
|
|
|
|
for (l = borders; l; l = l->next)
|
|
|
|
{
|
|
|
|
E_Border *b;
|
|
|
|
|
|
|
|
b = 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 (b->current.select_lost_from_grab) D_RETURN_(b);
|
2001-03-17 17:16:47 -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_(NULL);
|
2001-03-17 17:16:47 -08:00
|
|
|
}
|
2001-03-20 19:07:17 -08:00
|
|
|
|
|
|
|
void
|
|
|
|
e_border_focus_grab_ended(void)
|
|
|
|
{
|
|
|
|
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;
|
|
|
|
|
2001-03-20 19:07:17 -08:00
|
|
|
for (l = borders; l; l = l->next)
|
|
|
|
{
|
|
|
|
E_Border *b;
|
|
|
|
|
|
|
|
b = l->data;
|
|
|
|
b->current.select_lost_from_grab = 0;
|
2001-10-21 15:30:56 -07:00
|
|
|
b->current.selected = 0;
|
|
|
|
b->changed = 1;
|
2001-03-20 19:07:17 -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;
|
2001-03-20 19:07:17 -08:00
|
|
|
}
|
2001-09-24 14:21:25 -07:00
|
|
|
|
|
|
|
int
|
|
|
|
e_border_viewable(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;
|
|
|
|
|
2001-10-01 20:29:57 -07:00
|
|
|
if (b->desk != e_desktops_get(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_(0);
|
2001-09-24 14:21:25 -07:00
|
|
|
|
2001-09-25 15:10:33 -07:00
|
|
|
if (b->current.x + b->current.w <= 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_(0);
|
2001-09-24 14:21:25 -07:00
|
|
|
|
2001-09-25 15:10:33 -07:00
|
|
|
if (b->current.x >= b->desk->real.w)
|
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_(0);
|
2001-09-24 14:21:25 -07:00
|
|
|
|
2001-09-25 15:10:33 -07:00
|
|
|
if (b->current.y + b->current.h <= 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_(0);
|
2001-09-24 14:21:25 -07:00
|
|
|
|
2001-09-25 15:10:33 -07:00
|
|
|
if (b->current.y >= b->desk->real.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_(0);
|
2001-10-04 20:19:11 -07:00
|
|
|
|
|
|
|
if (!b->current.visible)
|
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_(0);
|
2001-09-24 14:21:25 -07: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_(1);
|
2001-09-24 14:21:25 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
e_border_send_pointer(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;
|
|
|
|
|
2001-10-17 15:34:27 -07:00
|
|
|
XWarpPointer(ecore_display_get(), None, b->win.main, 0, 0, 0, 0, b->current.w / 2, b->current.h / 2);
|
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;
|
2001-09-24 14:21:25 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
e_border_raise_next(void)
|
|
|
|
{
|
|
|
|
Evas_List next;
|
|
|
|
E_Border *current;
|
|
|
|
|
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;
|
|
|
|
|
2001-09-24 14:21:25 -07:00
|
|
|
if (!borders)
|
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;
|
2001-09-24 14:21:25 -07:00
|
|
|
|
|
|
|
current = e_border_current_focused();
|
|
|
|
|
|
|
|
/* Find the current border on the list of borders */
|
|
|
|
for (next = borders; next && next->data != current; next = next->next);
|
|
|
|
|
|
|
|
/* Step to the next border, wrap around the queue if the end is reached */
|
|
|
|
if (next && next->next)
|
|
|
|
next = next->next;
|
|
|
|
else
|
|
|
|
next = borders;
|
|
|
|
|
2001-09-25 15:10:33 -07:00
|
|
|
/* Now find the next viewable border on the same desktop */
|
2001-09-24 14:21:25 -07:00
|
|
|
current = (E_Border *)next->data;
|
|
|
|
while (next && !e_border_viewable(current))
|
|
|
|
{
|
|
|
|
next = next->next;
|
|
|
|
if (!next)
|
|
|
|
next = borders;
|
|
|
|
|
|
|
|
current = (E_Border *)next->data;
|
|
|
|
}
|
|
|
|
|
|
|
|
e_border_raise(current);
|
|
|
|
e_border_send_pointer(current);
|
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;
|
2001-09-24 14:21:25 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
e_border_print_pos(char *buf, 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;
|
|
|
|
|
2002-01-23 22:15:40 -08:00
|
|
|
snprintf(buf, PATH_MAX, "%i, %i",
|
2001-09-24 14:21:25 -07:00
|
|
|
b->current.x, b->current.y);
|
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;
|
2001-09-24 14:21:25 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
e_border_print_size(char *buf, 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;
|
|
|
|
|
2001-09-24 14:21:25 -07:00
|
|
|
if ((b->client.step.w > 1) || (b->client.step.h > 1))
|
|
|
|
{
|
2002-01-23 22:15:40 -08:00
|
|
|
snprintf(buf, PATH_MAX, "%i x %i",
|
2001-09-24 14:21:25 -07:00
|
|
|
(b->client.w - b->client.base.w) / b->client.step.w,
|
|
|
|
(b->client.h - b->client.base.h) / b->client.step.h);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2002-01-23 22:15:40 -08:00
|
|
|
snprintf(buf, PATH_MAX, "%i x %i",
|
2001-09-24 14:21:25 -07:00
|
|
|
b->client.w,
|
|
|
|
b->client.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;
|
2001-09-24 14:21:25 -07:00
|
|
|
}
|
2001-09-30 15:24:24 -07:00
|
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
e_border_set_gravity(E_Border *b, int gravity)
|
|
|
|
{
|
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 (!b)
|
|
|
|
D_RETURN;
|
|
|
|
|
|
|
|
ecore_window_gravity_set(b->win.container, gravity);
|
|
|
|
ecore_window_gravity_set(b->win.input, gravity);
|
|
|
|
ecore_window_gravity_set(b->win.l, gravity);
|
|
|
|
ecore_window_gravity_set(b->win.r, gravity);
|
|
|
|
ecore_window_gravity_set(b->win.t, gravity);
|
|
|
|
ecore_window_gravity_set(b->win.b, gravity);
|
2001-09-30 15:24:24 -07: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;
|
2001-09-30 15:24:24 -07:00
|
|
|
}
|
|
|
|
|
2002-01-23 17:08:52 -08:00
|
|
|
Evas_List
|
|
|
|
e_border_get_borders_list()
|
|
|
|
{
|
|
|
|
D_ENTER;
|
|
|
|
D_RETURN_(borders);
|
|
|
|
}
|