2014-07-18 1:31 GMT+01:00 Jean-Philippe André j...@videolan.org:
Hi
On Thu, Jul 17, 2014 at 6:31 AM, Daniel Kolesa quake...@gmail.com 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
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
Hi
On Thu, Jul 17, 2014 at 6:31 AM, Daniel Kolesa quake...@gmail.com 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
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 ras...@rasterman.com
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 docs is not complete yet, but any
new feedback is appreciated
Hi Raster!
On Tue, Jul 1, 2014 at 6:36 AM, Carsten Haitzler ras...@rasterman.com
wrote:
On Tue, 24 Jun 2014 12:25:53 -0300 Carlos Carvalho
ccarva...@expertisesolutions.com.br said:
child_select() and child_select_eval() are basically not documented. i can
guess that they may create a
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
On Mon, 7 Jul 2014 11:27:27 -0300 Carlos Carvalho
ccarva...@expertisesolutions.com.br said:
Hi Raster!
On Tue, Jul 1, 2014 at 6:36 AM, Carsten Haitzler ras...@rasterman.com
wrote:
On Tue, 24 Jun 2014 12:25:53 -0300 Carlos Carvalho
ccarva...@expertisesolutions.com.br said:
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 gives
On Tue, Jul 1, 2014 at 7:08 PM, Carlos Carvalho
ccarva...@expertisesolutions.com.br 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
On Tue, 24 Jun 2014 12:25:53 -0300 Carlos Carvalho
ccarva...@expertisesolutions.com.br 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
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
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 of
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 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
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
On Wed, Jun 25, 2014 at 10:52 AM, Gustavo Sverzut Barbieri
barbi...@gmail.com 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
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
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 Mon, 16 Jun 2014 12:00:20 -0300 Felipe Magno de Almeida
felipe.m.alme...@gmail.com 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
Hi raster :)
please see below.
On Thu, Jun 19, 2014 at 4:09 AM, Carsten Haitzler ras...@rasterman.com
wrote:
On Mon, 16 Jun 2014 12:00:20 -0300 Felipe Magno de Almeida
felipe.m.alme...@gmail.com said:
Hey guys. just reading now. looking at emodel.eo a lot of these methods
have no
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 ras...@rasterman.com
wrote:
On Mon, 16 Jun 2014 12:00:20 -0300 Felipe Magno de
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
Hello Raster,
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 ras...@rasterman.com
wrote:
can i recommend we have a path property you can
set AND get? so you
On Thu, 19 Jun 2014 12:20:21 -0300 Carlos Carvalho
ccarva...@expertisesolutions.com.br said:
Hi raster :)
please see below.
On Thu, Jun 19, 2014 at 4:09 AM, Carsten Haitzler ras...@rasterman.com
wrote:
On Mon, 16 Jun 2014 12:00:20 -0300 Felipe Magno de Almeida
On Thu, 19 Jun 2014 18:02:02 -0300 Felipe Magno de Almeida
felipe.m.alme...@gmail.com said:
Hello Raster,
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
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 we do
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 tom.haco...@samsung.com
wrote:
On 17/06/14 20:25, Cedric BAIL wrote:
Hello,
So I did just a very quick high level
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
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
Hi Cedric,
Please read in-line.
On Tue, Jun 17, 2014 at 4:25 PM, Cedric BAIL cedric.b...@free.fr 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
On Tue, Jun 17, 2014 at 4:39 PM, Carlos Carvalho
ccarva...@expertisesolutions.com.br 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,
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
33 matches
Mail list logo
