* cleaned up functions in utils in file utils and others, there's a
new file.[ch] for the file-related helpers.
* Added stat info to E_Icon, watch how directories become grayed when
you cannot access them :)
SVN revision: 5610
I've changed, this is big, so read this carefully :)
* I've added debugging macros for messages and function call
tracing. Usage:
D("Creating item %i %i %i\n", x, y, z);
Define DEBUG to use the D macro.
D_ENTER;
D_RETURN;
D_RETURN_(x);
These are for call tracing. Use D_RETURN_(x) when returning
something from a function. Define DEBUG_NEST to use this.
* added iconbar header file to Makefile.am
* added proper new()/cleanup() calls for E_Delayed_Action;
* I've completely rewritten the object and observer handling. Bye
bye macros, this was nasty. It'll be hard enough to avoid leaks
with usecounting in C. We now basically have the same system as gtk.
There's a clear separation of observer and object code now.
An E_Object by itself has nothing to do with observing or being
observed, therefore, there are now E_Observers and E_Observees
that are derived from E_Object. IMPORTANT: The cleanup system now
reflects the reference count system, therefore, all ..._free()
calls are now static, because the destructor should never be called explicitly, but implicitly through e_object_unref(). The object handling
now is as follows:
- The cleanup functions clean up everything that is contained in
a struct, but NOT the struct itself. Instead of the final
free() call, they call the destructor of the base class. The
calls will walk up the hierarchy and clean up what's contained in
every struct, and the final e_object_cleanup() will free the
structure itself. E_Delayed_Action is a good example.
- The only calls that influence the reference count are
e_object_ref() and e_object_unref(). If you need to do things
before an object gets destroyed, you can query the use count using
e_object_get_usecount() and check if it's equal to 1. So this:
OBJ_UNREF(b);
OBJ_IF_FREE(b)
{
ecore_window_reparent(e->win, 0, 0, 0);
e_icccm_release(e->win);
OBJ_FREE(b);
}
now is this:
if (e_object_get_usecount(E_OBJECT(b)) == 1)
{
ecore_window_reparent(e->win, 0, 0, 0);
e_icccm_release(e->win);
}
e_object_unref(E_OBJECT(b));
object.h and observer.h are completely commented, it shouldn't be
too hard to understand. This'll need to be documented in the manual
anyway.
* E_Objects are now used in lots of places where void* were used as
pointers to objects before, especially in the actions code. This is
obviously better, as it will generate compiler warnings when people
want to pass things to functions that expect E_Objects. This could
probably be more restrictive.
* Added typedefs for the function prototypes in E_Action_Impl. Those
fat signatures were just painful to read in the function
declarations/implementations.
* I've also tried to give parameters more useful names. Calling an
object "o" is a lot of fun when you want to grep for it.
* Included is also Graham's latest menu.c patch. Sorry for the
delay, Graham.
* I've added checks to the menu code that make sure that menus
don't pop up when they're empty (which resulted in a little useless
rectangle).
I guess that's it for now. Sorry if I broke anything, but this was
necessary imho.
SVN revision: 5605
scritp again (pass in a directory path to set up.. i'd suggest
mkdir ~/.e
mkdir ~/.e/desktop
mkdir ~/.e/desktop/default
build_iconbar_db.sh ~/.e/desktop/default
the scritp is a bit smaller now :)
SVN revision: 5519
it doesn't exist.
* Renamed E_Action_Proto to E_Action_Impl. I think that's more intuitive
* Renamed the xxx_go functions to xxx_cont. It took me a while to understand the difference between "start" and "go".
* Some line wrapping and cosmetics.
SVN revision: 5475
added header files for most of the logical units, which greatly
reduces the size of e.h. The dependencies are probably still a bit
too dense, I'll look at that next. Things don't get rebuilt completely
any more when efsd is updated. I've also started command line options.
Only version info and the display variable are recognized so far.
I see no warnings here on my machine. Hope I didn't break anything.
SVN revision: 5014
yes - it generates it from a..... DATABASE - there's a script that builds the
menu - it's a default set - but easily editable in the script (an example of
how to build a menu db - but... eventually we'd need a gui.) This only builds
a menu from a db file - it also monitors it for changes and updates the menu
to match any changes that happen. I need to write later a fs menu builder that
builds a menu from the filing system.
SVN revision: 4164
cpk
Carsten Haitzler