enum Foo {} is simpler but it also means that all tapedef's are equally
prefixed by "_". What if you need to have a different prefix or name?
In C I prefer 'typedef struct {} Foo;' but 'typedef _Foo Foo' close to
the top of header helps readability when you have many structs in your .h
however
2014-07-18 1:31 GMT+01:00 Jean-Philippe André :
> Hi
>
> On Thu, Jul 17, 2014 at 6:31 AM, Daniel Kolesa wrote:
>
> > 2014-07-16 22:17 GMT+01:00 Larry de Oliveira Lira Jr <
> > la...@expertisesolutions.com.br>:
> >
> > > Hello all
> > >
> > > we have a new version of emodel based in all feedback h
Hi
On Thu, Jul 17, 2014 at 6:31 AM, Daniel Kolesa wrote:
> 2014-07-16 22:17 GMT+01:00 Larry de Oliveira Lira Jr <
> la...@expertisesolutions.com.br>:
>
> > Hello all
> >
> > we have a new version of emodel based in all feedback here (thanks for
> all)
> > this version is in working progress, and
2014-07-16 22:17 GMT+01:00 Larry de Oliveira Lira Jr <
la...@expertisesolutions.com.br>:
> Hello all
>
> we have a new version of emodel based in all feedback here (thanks for all)
> this version is in working progress, and docs is not complete yet, but any
> new feedback is appreciated
>
> http:/
Hello all
we have a new version of emodel based in all feedback here (thanks for all)
this version is in working progress, and docs is not complete yet, but any
new feedback is appreciated
http://pastebin.com/uAxb3PHp
On Tue, Jul 8, 2014 at 2:46 AM, Carsten Haitzler
wrote:
> On Mon, 7 Jul 201
On Mon, 7 Jul 2014 11:27:27 -0300 Carlos Carvalho
said:
> Hi Raster!
>
>
> On Tue, Jul 1, 2014 at 6:36 AM, Carsten Haitzler
> wrote:
>
> > On Tue, 24 Jun 2014 12:25:53 -0300 Carlos Carvalho
> > said:
> >
> > child_select() and child_select_eval() are basically not documented. i can
> > guess
Hi Gustavo,
I have a doubt here. I already implemented the use
of Eina_Value_Struct_Desc in our Emodel_Eio example. In prop_list I'm
returning, via EMODEL_EVENT_PROPERTIES_CHANGE, Eina_Value which must be
handled by the caller as Eina_Value_Struct, (it is a list of properties)
but it doesn't seem
Hi Raster!
On Tue, Jul 1, 2014 at 6:36 AM, Carsten Haitzler
wrote:
> On Tue, 24 Jun 2014 12:25:53 -0300 Carlos Carvalho
> said:
>
> child_select() and child_select_eval() are basically not documented. i can
> guess that they may create a EMODEL_EVENT_CHILD_SELECTED later... but what
> is
> the
Hi Gustavo,
about the "property get/fetch" to return a value (sync mode), I like it but
in many cases it would be necessary to cache all the values, is it a
problem? I'm thinking about cases where we have many files, another thing,
model_property_load() needs a cache and property_get() always give
On Tue, Jul 1, 2014 at 7:08 PM, Carlos Carvalho
wrote:
> Hi gustavo,
>
> I'd like to talk a little bit about some points Larry told we are fixing OK.
Great, will take some time to review the new code tomorrow. Some
comments about your questions:
> #10, now we have a loaded event, shouldn't we ha
Hi gustavo,
I'd like to talk a little bit about some points Larry told we are fixing OK.
About #1 , sure, it is going to change. Dunno yet if it will be part of EIO
or something else. Anyways it was created as a kind of proof of concept so
we could test Emodel concepts. It ended up being a more c
On Tue, 24 Jun 2014 12:25:53 -0300 Carlos Carvalho
said:
child_select() and child_select_eval() are basically not documented. i can
guess that they may create a EMODEL_EVENT_CHILD_SELECTED later... but what is
the difference between these? no info there. and the docs for the events point
back to
Hi gustavo
thanks for your detailed review
about item 1, no problem, initial intention with model Eio was make a "real
assync" model, to have a best case to make/tests "views" and examples, not
make a definitive model for "file objects" and therefore this choice for
name
If nobody oppose we will
Hi!
Some review items already pushed: 4, 7, 13.1, 14 and partially 9 (const
void* and doc).
[]s
On Thu, Jun 26, 2014 at 3:14 PM, Carlos Carvalho <
ccarva...@expertisesolutions.com.br> wrote:
> Hi Gustavo,
>
> First of all thank you very much for your review!
>
> I, personally, agree with most
Hi Gustavo,
First of all thank you very much for your review!
I, personally, agree with most of your recommendations and already pushed a
couple of changes into the repository, the same you pulled from earlier.
Some items like '1', '2' and '5' are also about code design and will
inflict more fun
Okay, after a review of Emodel.h, some comments:
1 - As previously said, Emodel_Eio is not ideal, it should be
Eio_Emodel and it should exist in eio's code, that will then depend on
Emodel -- as there is no reason for Emodel to know (and pull in) Eio.
(This is based on the first example in Emodel
On Wed, Jun 25, 2014 at 10:52 AM, Gustavo Sverzut Barbieri
wrote:
> did not look at it in depth now, but selection is not a model
> property, is a controller-view. If you want selection of a model to
> appear in multiple views, then you sync that elsewhere (either in a
> central controller -- more
did not look at it in depth now, but selection is not a model
property, is a controller-view. If you want selection of a model to
appear in multiple views, then you sync that elsewhere (either in a
central controller -- more usual, or in another model that is the
selection of target model).
On Thu
< sending again, always forget the reply-all :( >
Hi raster!
I changed the code and adjusted the function names to match a more correct
convention as you suggested.
Now about the constructor, we'll implement as you suggested as well because
it makes sense too.
Can you please update from our repo
On Thu, 19 Jun 2014 18:02:02 -0300 Felipe Magno de Almeida
said:
> Hello Raster,
>
> On Thu, Jun 19, 2014 at 12:20 PM, Carlos Carvalho
> wrote:
> > Hi raster :)
> >
> > please see below.
> >
> > On Thu, Jun 19, 2014 at 4:09 AM, Carsten Haitzler
> > wrote:
>
>
> > > can i recommend we have a
On Thu, 19 Jun 2014 12:20:21 -0300 Carlos Carvalho
said:
> Hi raster :)
>
> please see below.
>
> On Thu, Jun 19, 2014 at 4:09 AM, Carsten Haitzler
> wrote:
>
> > On Mon, 16 Jun 2014 12:00:20 -0300 Felipe Magno de Almeida
> > said:
> >
> > Hey guys. just reading now. looking at emodel.eo a l
Hello Raster,
On Thu, Jun 19, 2014 at 12:20 PM, Carlos Carvalho
wrote:
> Hi raster :)
>
> please see below.
>
> On Thu, Jun 19, 2014 at 4:09 AM, Carsten Haitzler
> wrote:
> > can i recommend we have a path property you can
> > set AND get? so you can create an empty eio model and then point it
hi raster
about child_del in eio_model the name of the method is wrong, instead of
emodel_eio_child_del the right is emodel_eio_del, for a model delete
itself, and it dos not need make to override of emodel_child_del.
On Thu, Jun 19, 2014 at 12:23 PM, Carlos Carvalho <
ccarva...@expertisesoluti
s/don't though/didn't think/s :)
On Thu, Jun 19, 2014 at 12:20 PM, Carlos Carvalho <
ccarva...@expertisesolutions.com.br> wrote:
> Hi raster :)
>
> please see below.
>
> On Thu, Jun 19, 2014 at 4:09 AM, Carsten Haitzler
> wrote:
>
>> On Mon, 16 Jun 2014 12:00:20 -0300 Felipe Magno de Almeida
>>
Hi raster :)
please see below.
On Thu, Jun 19, 2014 at 4:09 AM, Carsten Haitzler
wrote:
> On Mon, 16 Jun 2014 12:00:20 -0300 Felipe Magno de Almeida
> said:
>
> Hey guys. just reading now. looking at emodel.eo a lot of these methods
> have no
> return just looking at properties for starter
On Mon, 16 Jun 2014 12:00:20 -0300 Felipe Magno de Almeida
said:
Hey guys. just reading now. looking at emodel.eo a lot of these methods have no
return just looking at properties for starters. also child_select_get().
this needs a lot more documentation as it's really mysterious as to what t
Please before anyone review the code make sure to be up-to-date because I'm
pushing some fixes, code cleanup and so on...
[]s!
On Wed, Jun 18, 2014 at 6:28 AM, Tom Hacohen
wrote:
> On 17/06/14 20:25, Cedric BAIL wrote:
> > Hello,
> >
> > So I did just a very quick high level review for now and
On 17/06/14 20:25, Cedric BAIL wrote:
> Hello,
>
> So I did just a very quick high level review for now and the following
> is just my opinion. But I do think it makes more sense to have what
> you name emodel be part of either Eo directly or a new Efl library as
> it should be a core object like w
On Tue, Jun 17, 2014 at 4:39 PM, Carlos Carvalho
wrote:
> Hi Cedric,
[snip]
>> then EModel_Eio, I think, should move and be
>> part of Eio directly (and become Eio_Model).
>
> Emodel_Eio is just one kind of model, to deal with files, what if we need,
> in the future, to add other models unrelate
Hi Cedric,
Please read in-line.
On Tue, Jun 17, 2014 at 4:25 PM, Cedric BAIL wrote:
> Hello,
>
> So I did just a very quick high level review for now and the following
> is just my opinion. But I do think it makes more sense to have what
> you name emodel be part of either Eo directly or a new
Hello,
So I did just a very quick high level review for now and the following
is just my opinion. But I do think it makes more sense to have what
you name emodel be part of either Eo directly or a new Efl library as
it should be a core object like we do plan to do with other core
object like color
There's a prepended "and" in the first link
it should be:
https://github.com/expertisesolutions/efl/tree/emodel-eolian and
https://github.com/expertisesolutions/elementary/tree/eo_mvc
instead.
Regards.
--
Savio
On 6/16/2014 at 12:02 PM, "Felipe Magno de Almeida" wrote:Hello,
We are implem
Hello,
We are implementing a model interface and a few views in elementary
and would like feedback.
The code is at https://github.com/expertisesolutions/efl/tree/emodel-eolian
and https://github.com/expertisesolutions/elementary/tree/eo_mvc
We've designed a model interface which is tree-like (DAG
33 matches
Mail list logo
