On Tue, 2003-01-21 at 07:13, Nathan Ingersoll wrote:
> On Tue, Jan 21, 2003 at 03:19:55PM +1100, Carsten Haitzler wrote:
> >
> > yes.. if renaming is to happen.. NOW is the time. i don't want duplicate fn
> > calls for "compatability" i'd like to keep it simple. i'd prefer to make people
> > have
On Tue, Jan 21, 2003 at 03:19:55PM +1100, Carsten Haitzler wrote:
>
> yes.. if renaming is to happen.. NOW is the time. i don't want duplicate fn
> calls for "compatability" i'd like to keep it simple. i'd prefer to make people
> have to change their code than add #defines or compat symbols (at th
On Mon, 20 Jan 2003 22:16:10 -0600 [EMAIL PROTECTED] babbled:
> * Carsten Haitzler <[EMAIL PROTECTED]> [2003-01-21 10:14:15 +1100]:
>
> > On Mon, 20 Jan 2003 16:55:17 -0600 [EMAIL PROTECTED] babbled:
> >
> > > I was just curious about why the font path functions are
> > > evas_object_font_path_*
* Carsten Haitzler <[EMAIL PROTECTED]> [2003-01-21 10:14:15 +1100]:
> On Mon, 20 Jan 2003 16:55:17 -0600 [EMAIL PROTECTED] babbled:
>
> > I was just curious about why the font path functions are
> > evas_object_font_path_*() instead of evas_font_path_*(), since they take an
> > evas (not an objec
On Mon, 20 Jan 2003 16:55:17 -0600 [EMAIL PROTECTED] babbled:
> I was just curious about why the font path functions are
> evas_object_font_path_*() instead of evas_font_path_*(), since they take an
> evas (not an object) and they apply evas-wide.
> Its not the biggest problem, just a little less
I was just curious about why the font path functions are
evas_object_font_path_*() instead of evas_font_path_*(), since they take an
evas (not an object) and they apply evas-wide.
Its not the biggest problem, just a little less than intuitive.
--
brian