On Thu, 3 Sep 2009 12:24:44 +0100 Andrew Williams said:
that's not a problem :) know how it is!
> That was always the idea, I just ran out of time :(
>
> If the lists and structs can be added/improved whilst not removing the
> ability for the config to be gracefully upgraded then totally!
>
That was always the idea, I just ran out of time :(
If the lists and structs can be added/improved whilst not removing the
ability for the config to be gracefully upgraded then totally!
I do hope to get back to it honestly but I have no time right now...
Andy
On 28 Aug 2009, at 02:05, Carsten
On Thu, 27 Aug 2009 04:56:30 -0400 Atton Jonathan
said:
> Using ecore_config as an extension of eet and adding some properties (profil
> ...) can be a good idea. We can do all this with eet but it can save time.
> Currently we should disable ecore_config by default, then if someone is
> interesed
On Thu, 27 Aug 2009 09:20:44 +0200 (CEST) Vincent Torri
said:
>
>
> On Wed, 26 Aug 2009, Carsten Haitzler (The Rasterman) wrote:
>
> > On Thu, 20 Aug 2009 21:44:25 +0200 (CEST) Vincent Torri
> > said:
> >
> > hmm. now i think of it - maybe we can re-use this ecore lib but instead
> > improve
On Thu, Aug 27, 2009 at 2:37 PM, Mikhail Gusarov wrote:
>
> Twas brillig at 14:15:17 27.08.2009 UTC-03 when [email protected] did
> gyre and gimble:
>
> GSB> having a daemon (dbus?) to do these things on behalf of
> GSB> applications and notify properties changes would be awesome.
>
> Is i
Twas brillig at 14:15:17 27.08.2009 UTC-03 when [email protected] did
gyre and gimble:
GSB> having a daemon (dbus?) to do these things on behalf of
GSB> applications and notify properties changes would be awesome.
Is it really necessary? Watching the configuration file should be more
th
I agree and suggest something that I like about gconf: inter-process
notification. Of course this is dual layer, I'd make ecore_config as a
easy wrapper around eet (safe save, with tmp file + rename), but
having a daemon (dbus?) to do these things on behalf of applications
and notify properties cha
Using ecore_config as an extension of eet and adding some properties (profil
...) can be a good idea. We can do all this with eet but it can save time.
Currently we should disable ecore_config by default, then if someone is
interesed he can write a new ecore_config. But currently I think people hav
On Wed, 26 Aug 2009, Carsten Haitzler (The Rasterman) wrote:
> On Thu, 20 Aug 2009 21:44:25 +0200 (CEST) Vincent Torri
> said:
>
> hmm. now i think of it - maybe we can re-use this ecore lib but instead
> improve
> its facilities. eg support multiple profile - whole struct encode/decode via
>
On Thu, 20 Aug 2009 21:44:25 +0200 (CEST) Vincent Torri
said:
hmm. now i think of it - maybe we can re-use this ecore lib but instead improve
its facilities. eg support multiple profile - whole struct encode/decode via
eet etc. etc. and list handling (as opposed th keys with numbers and counts in
Hey,
It seems that ecore_config is going to be removed. As a first step, i
would like to disable by default during configuration. Is it ok ? Where
should I announce that ecore-config will be removed soon ?
Vincent
--
11 matches
Mail list logo
