On Mon, 10 Apr 2017 23:46:43 -0300 Gustavo Sverzut Barbieri
<barbi...@gmail.com> said:
> I'm commenting mostly on tickets, but two points I'd like to reply here:
>
>
> On Mon, Apr 10, 2017 at 7:12 PM, Cedric BAIL <cedric.b...@free.fr> wrote:
> [...]
> > Finally something that we are not addressing yet, but would I think
> > make sense, is some way to describe simple layout (Like Android XML
> > file or Microsoft XAML). With Eo property it becomes quite easy to
> > automatically generate code for this.
>
> We're incurring in the same error as we did for EDC, thinking much of
> our side instead of users... EDC started as something for designers
> but then we never provided WYSIWYG and it sucked... the primitives are
> all there, but unusable for the naive or designers.
>
> the only way to describe this is to create a WYSIWYG first, then come
> with some format to store it... But do that as the *USER* point of
> view, not from EFL development PoV. Ignore our terms, ignore our
> limitations, try to make design use cases and then we see how to
> implement that with our tech, adding features and removing limitations
> as needed.
yeah. this was my fault. before edje was ebits. it started with a gui editor.
but it was far too limited. i replaced with edje but writing the gui editor was
a loooot more work and i wanted to get on with making e... so i took a tmp
shortcut with edc - it was a data struct you filled in - the idea being that a
gui editor would come and fill it in for you later... it was a temporary
solution
i learned my lesson. don't make temporary solutions. :)
> Clear example with edc is to do chained animations, a series of
> "after" must be chained, but if you need to cancel that you can't call
> it a 'chain', you need to cancel all the program{} blocks... Also the
> rel1/rel2 are very close to our internals, don't get into must
> people's head that expect what the new "anchor" patchset is adding.
>
>
> [...]
> > We have been iterating over a MVC design for more than a year now. I
> > think we are nearing a design that start to look good. The funny part
> > is when I was trying to find some presentation to explain people about
> > MVC and the difference with what we were doing, I stumble on Microsoft
> > MVVM design pattern which is pretty close to the design we have
> > selected. So we will rename the work we have done from ProxyModel to
> > ViewModel to use the same naming convention as everyone else.
> >
> > The main difference between MVC and MVVM is that it allow the
> > definition of a clean interface between View and Model. There isn't
> > really a ProxyModel or ViewModel interface, as they really are just a
> > Model that get data from another Model and interpret them into what
> > the View will actually display. This means you can easily reuse Model
> > and that you can test your Proxy/ViewModel without connecting it to an
> > actual View.
> >
> > And last very nice benefit, I think, is that you are defining a
> > "connection" for each parameter of your widget. So to connect a View
> > with a Model, you are only setting the model and indicating which
> > property to fetch on the model. No need to deal with callback in many
> > case ! For an example (which is broken at the moment) of the idea you
> > can look at layout_model_connect.c in efl elementary example.
> >
> > The most complex work will now be in writing this Proxy or View Model.
> > This is something we have to work on to make it easier.
>
> I've talked to you and felipe at IRC, I still think that the current
> Model is trying to address too much of "performance and async" at the
> level that it will suck for developers.
>
> to address the correct goal of "never block", what the current
> implementation does is make all property-get async, resulting in a
> promise... callback, etc. Whenever you need a simple:
>
> if (model.a + model.b < model.c) do_bla(model);
>
> then you're screwed... you need to store these elsewhere, wait on 3
> callbacks, then execute what you want. Okay, helpers to accumulate and
> wait on all futures... then dispatch an array of values will be there,
> but still.
>
> caching is also left to outside. But to cache properly you need to
> know your information, access pattern, load coast, evict cost... Okay,
> applications may know better which information they are going to use,
> but they can hint that to model if needed (we could add a way to
> declare "hot properties").
i personally prefer the idea of caching. have the item object and list which
properties you want fetched, and some thread fetches in the background. when
it's done your promise or callback is triggered. once it is you can be certain
the properties are already fetched and live in memory. it's not a promise per
property to fetch. it's "get me all of this in a blob" and should be simpler to
deal with. this is where i dislike promises for this. i prefer some "updated"
callback... as below, it'd work better with live updates. if an object changed
at the source - the model can be listening and it already knows what properties
you want... and it can auto re-fetch them and then call the "updated" callback.
you only have to register that cb on that object once to handle all cases.
child objects in a tree that you haven't instantiated yet of source you don't
get these cb's on... but parent objects could tell you if a child changed etc.
> My suggestion is that we benefit from "models are live entities and
> always change", thus the users *MUST* monitor the changed events...
> and make all property getters/setters synchronous. However you may
> call a property get and receive a dummy value, which will trigger the
> fetch of real values, then emit "changed", which will likely trigger
> the code path again and that one will receive the actual values.
>
> example: FS model. walking a directory and generating children models
> will give you the filename and MAYBE the d_type (it may be
> DT_UNKNOWN). You know the rest of the model is sizeof(struct stat),
> which makes your Eo private data very small. Once a property get that
> needs 'stat()', then you return dummy values but trigger an
> async/thread/eio stat... that will give you ALL the fields (mode, uid,
> gid, size...). Unless object changes (ie: inotify), then no extra
> async call, promise/future are needed.
>
> compare this to the implementation where N calls to get("size"),
> get("mode"), get("uid"), get("gid") will result in N*4 promises/future
> pairs, N*4 callbacks...
>
> DB can be done like that as well. My experience with Canola running
> Python on a Maemo 770 (64mb ram, armv5) required us to do exactly
> that. DB access resulted in shallow objects, that were populated as
> needed. In our case, when a 10,000 song DB was queried, we would only
> call 'SELECT COUNT(*) FROM TABLE' and say we had 10,000 song without
> creating any actual children. Then when an index/slice/range was
> asked, we'd optimize block/group load ('LIMIT = X', X being multiple
> of 10, 100 or whatever). and only the important/cheap information,
> like Music title. Whenever the user asked for cover, length, artist...
> these would "pagefault" and load the values with individual 'SELECT',
> populating the model as needed.
>
> This is also great approach when you have in-memory info, as you never
> generate async calls... say you're exposing Eet-decoded object in
> Efl_Model... what's the benefit of generating many promise/future?
> It's all in there, all memory is easily accessible. That's also the
> case for things like JSON, where you can tokenize and keep pointers to
> in-memory buffers, then it's a memcpy and some eventual decode (like
> parse the int/float... unescape strings...)
>
>
> --
> Gustavo Sverzut Barbieri
> --------------------------------------
> Mobile: +55 (16) 99354-9890
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
