On Tue, 5 Oct 2010, Enlightenment SVN wrote:
> Log:
> * eio: follow efl coding style.
>
> Author: cedric
> Date: 2010-10-05 08:58:19 -0700 (Tue, 05 Oct 2010)
> New Revision: 53066
>
> Modified:
> trunk/eio/src/lib/eio_file.c
>
> Modified: trunk/eio/src/lib/eio_file.c
> =
On Tue, 2010-10-05 at 21:56 +0800, Tom Haste wrote:
> I figured Id throw my $0.2 AUD into this...
>
> Being a noob to the programming game, Just the ecore_init() seems fine
> by me as long as ecore_init() documentation also states that
> eina_init() happens with it. Seeing eina_init() and ecor
I figured Id throw my $0.2 AUD into this...
Being a noob to the programming game, Just the ecore_init() seems fine
by me as long as ecore_init() documentation also states that
eina_init() happens with it. Seeing eina_init() and ecore_init() tells
my noobie brain that one must happen before the
On Tue, 2010-10-05 at 09:41 -0300, Iván Briano (Sachiel) wrote:
> Still not good. There's a difference of relying on some component initializing
> a library because it uses internally, and initializing it because it's
> also giving
> you back stuff from it. In the first case, yes, relying on that a
On Tue, Oct 5, 2010 at 9:13 AM, Tom Hacohen
wrote:
> On Tue, 2010-10-05 at 09:05 -0300, Iván Briano (Sachiel) wrote:
>> I think it's a very bad example, considering glib is an outside dependency.
>> On the other hand, given the amount of functions in the EFL that return an
>> Eina type, having you
On Tue, 2010-10-05 at 09:05 -0300, Iván Briano (Sachiel) wrote:
> I think it's a very bad example, considering glib is an outside dependency.
> On the other hand, given the amount of functions in the EFL that return an
> Eina type, having your app break because you were not explicily initializing
On Tue, Oct 5, 2010 at 9:01 AM, Tom Hacohen
wrote:
> On Tue, 2010-10-05 at 08:58 -0300, Iván Briano (Sachiel) wrote:
>> glib?
>
> I was just making a point, that we may have depended on glib in the past
> (no idea really, but for example ewebkit still in some cases depends on
> it) in ecore and al
On Tue, 2010-10-05 at 08:58 -0300, Iván Briano (Sachiel) wrote:
> glib?
I was just making a point, that we may have depended on glib in the past
(no idea really, but for example ewebkit still in some cases depends on
it) in ecore and all the applications that assumed ecore_init inits glib
broke.
On Tue, Oct 5, 2010 at 6:34 AM, Tom Hacohen
wrote:
> On Tue, 2010-10-05 at 11:29 +0200, Vincent Torri wrote:
>> because it's useless ? That kind of stuff must be documented. If not, the
>> doc must be fixed. Hence, internal or not, a user knows what the
>> initialisation does.
>
> Useless: yes, co
On Tue, 2010-10-05 at 11:29 +0200, Vincent Torri wrote:
> because it's useless ? That kind of stuff must be documented. If not, the
> doc must be fixed. Hence, internal or not, a user knows what the
> initialisation does.
Useless: yes, costly: no, future-proof: more than without.
What do you nee
On Tue, 5 Oct 2010, Tom Hacohen wrote:
> On Tue, 2010-10-05 at 09:58 +0200, Vincent Torri wrote:
>> ecore_init calls eina_init, so it's useless
>
> As you said, it doesn't really matter, but I honestly find explicitly
> init-ing a good idea. You should never depend on internal design, even
> if
On Tue, 2010-10-05 at 09:58 +0200, Vincent Torri wrote:
> ecore_init calls eina_init, so it's useless
As you said, it doesn't really matter, but I honestly find explicitly
init-ing a good idea. You should never depend on internal design, even
if you are the one who writes both parts.
As I said, i
On Mon, 4 Oct 2010, Enlightenment SVN wrote:
> Log:
> reorder inits
> Author: discomfitor
> Date: 2010-10-04 23:33:12 -0700 (Mon, 04 Oct 2010)
> New Revision: 53048
>
> Modified:
> trunk/e/src/bin/e_fm_main.c
>
> Modified: trunk/e/src/bin/e_fm_main.c
> ===
13 matches
Mail list logo
