Also allow different fonts for borders vs. menus. This adds links in /usr/local/share/enlightenment/fonts (default install) for a menu.ttf and a text.ttf file. text.tff is the font used for border text/window titles. menu.ttf will be used for menus. No change by default, but you'll need to re-run autogen.sh & make install for the links to be created automatically.
Update AUTHORS
Kevin Brosius <cobra@compuserve.com>
SVN revision: 6751
Instead of /path/.e_iconbar.bits.db, now uses /path/.e_layout/iconbar.bits.db.
Custom scrollbars can be placed in the .e_layout directory as well.
I should probably move the background db into here also, any objections?
So, to get your iconbar again, move the .e_iconbar[.bits].db to .e_layout/iconbar[.bits].db
SVN revision: 6034
their geometry on close. I'll start getting the documentation back in sync and commenting some more. Could anyone
willing to clean up/fix either the iconbar dnd stuff and/or the regular dnd stuff please announce it, so we dont start
duplicating work. Thanks.
SVN revision: 5977
Quite a bit has been implemented. Check the data/epplets dir for examples.
Currently the only loading method is a file called .e_epplets.bits.db which contains bits whose names are equal to the epplet name, and whose geometry is the default epplet geometry (unless overridden in the script).
The idea being that one could set up an entire desktop epplet layout within one file, making it easily transferable.
So, to use epplets make sure you copy the default epplets.bits.db to ~/.e/desktop/default/.e_epplets.bits.db
Also, make sure you update ebits
SVN revision: 5826
cp most of it and lay it out in /.e eventually anyway (and if u dont like
the idea of cping the files - we can symlink too - but e_setup will take
care of this... eventually.. might start work on it now i have fixed things
- though personally i think i should make it cp to start so your user config
is independant of the system and wont suddenyl chaneg cause the system one
did... but again... can be made an option)
SVN revision: 5729
* 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
sleuth
rbdpngn
rephorm
Till Adam
Carsten Haitzler
cpk