On 09/24/2010 12:55 PM, Carsten Haitzler (The Rasterman) wrote: > On Fri, 24 Sep 2010 11:51:59 -0400 Christopher Michael<cpmicha...@comcast.net> > said: > >> On 09/24/2010 08:30 AM, Carsten Haitzler (The Rasterman) wrote: >>> On Fri, 24 Sep 2010 09:04:39 -0300 Iván Briano (Sachiel)<sachi...@gmail.com> >>> said: >>> >>>> On Fri, Sep 24, 2010 at 8:57 AM, Vincent Torri<vto...@univ-evry.fr> >>>> wrote: >>>>> >>>>> Hey, >>>>> >>>>> in ecore_evas, there are plenty of calls that can use Eina_Bool instead of >>>>> int: >>>>> >>>>> ecore_evas_engine_type_supported_get >>>>> ecore_evas_app_comp_sync_set >>>>> ecore_evas_app_comp_sync_get >>>>> all the _set functions that have an 'on' parameter and their _get too. >>>>> >>>>> Should we modify them before beta ? >>>>> >>>> >>>> I would say yes. >>> >>> yes - same with the rest of ecore. want to go fix them all up before beta? >>> as i said before - i already did evas, embryo and edje and fixed these. >>> also moved >>> #defines to enums too. >>> >> >> I realize that this is probably a pretty minor thing, but wrt >> evas_object_color_set/get ... currently it is using int's for r, g, b >> ... should we use 'unsigned int' there ? afaik, The values passed there >> cannot be negative anyway ... > > i'm happy with int's - it is more common to use them for math allowing< 0 in > intermediate steps. also less in the way of warnings etc. - if u wanted to be > strict, u'd make them unisgned chars, but.. int's are fine i'd say. > Ok, fair enough :) Just wanted to check on that in case they should have been changed before beta
dh ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
