Gustavo wrote:

> >       Has anyone followed up on this? It seems to me that this
> > could be easily done in a way that would allow for a certain amount
> > of re-usability of such 'gadgets', and yet enough flexibility to
> > have custom designs as well. Likely there are multitudes of ways to
> > go about doing something like this, but maybe a simple approach
> > could be a good one to start with?
> 
> Raster sent this code as example, it's pretty simple, but no time to
> work on it still:
> 
>    http://www.rasterman.com/files/logo-0.0.1.tar.gz


        A very nice example :)  Note that one could do much the same
with many of the current gadcon based e17-modules - ie. display them
directly on a zone's bg evas and have move/resize handlers if desired.
And of course one could write whole new ones...

        But there are a couple of limitations with this:

        1. All these nice gadgets are strictly "e17 only". Not much
here that other apps/libs could use (except copy paste some code).

        2. Even within e17 only, there are some undesirable aspects.
eg. if you wanted to have a gadget that consists of a clock, plus a
cpu-monitor, plus a mem-monitor, and you want these to be arranged
in some interesting way relative to each other, and maybe have a nice
background that contains them which does a nebula-effect (whatever
that is) on mouse-over, then it's not clear wether you'd have to
write all of these components from scratch...

        One would like to be able to address these things in as simple
a way as possible - ie. make it easier to re-use exhisting 'gadgets',
to create new ones from sets of given ones, etc.

        Note that one thing that all these kinds of 'gadgets' have in
common is that they define evas objects on a given evas, preferably a
'themable' object - and commonly they simply define an edje object.
They could also have certain 'properties' that might be varied, and
this is usually done via some configuration gui.

        Does this seem like something one could use as a starting point
for finding a means to address the above mentioned limitations?

        For example, let's say we take only the "core" aspects of
these gadget modules so that one has only some loadable libs that
expose certain functions - say a function that 'adds' an evas object
to a given evas, and another to 'set' a theme/resource file on such
a thusly created evas object, and maybe a function to set/get named
property/values, .... and possibly other functions particular to a
given gadget.
        Of course one might want a way to 'manage' such object-modules
and thus maybe a lib to load them, init them, keep references, etc...

        Could these generic 'object-modules' (plus a 'managing' lib)
be used for building 'gadgets' as desired??

_____________________________________________________________
Beauty Product Reviews
Read unbiased beauty product reviews and join our product review team!
http://thirdpartyoffers.juno.com/TGL2121/fc/JKFkuJi7GiXG07S2bI33ExQknalirOMoYMTWHjW874ZiTMwMFZ1MiE/



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to