Re: [E-devel] Making EFL easier to use

[Cedric BAIL]

On Tue, Apr 11, 2017 at 3:57 PM, Christophe Sadoine  wrote:
> On 12 April 2017 at 06:15, Cedric BAIL  wrote:
>> On Mon, Apr 10, 2017 at 7:46 PM, Gustavo Sverzut Barbieri
>>  wrote:
>>> On Mon, Apr 10, 2017 at 7:12 PM, Cedric BAIL  wrote:
>>> 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.
>>
>> That's where I have a different opinion. Developers are bad with
>> WYSIWYG interface. Designers are the users of that potential WYSIWYG
>> interface. Problem is that in the population we are trying to address,
>> a large portion of them are developers without a sidekick designer.
>> They are the one who want to be able to do simple UI "assemblage" from
>> a file. EDC is way to complicated and powerful for what they want. We
>> actually do not have anything to address the needs of this people.
>> This is what I am talking above.
>
> You say the population you are trying to address have a large portion
> of developers.
> You also said in your original email that there was 3 groups :
> developers, developers, developers :D
> I just want to mention, please don't forget about the designers or
> even "wannabe designers".

Oh sure ! Well, that's because the work I am talking about is first
focused on helping developers. There are other initiative to help
designer. I think eflete is a good one.

> I get the "more developers -> more apps -> more e/efl users"
> But until 0.16, I think e became what it was in part because of themes
> and customization.
> There was a bunch of themes and it was fun :)

Yes, and they were much much simpler. I hope that one side effect of
clearly defined the style in the API of widget is that we can get a
smaller theme. Simplifying the theme would greatly help.

> Everybody knows making a theme takes time. I think one reason is
> because you have to recompile your edc just to see what happens when
> you changed an offset. (I am currently trying to make a simple theme)
> If I could just change a line and see the change instantly I would be
> so happy. Enventor is nice but of course it has to recompile all edc
> files.

Eflete does I think what you have in mind. One of the combo I would
like to fix is edje_watch and edje_player. Ideally if it could just
update what changed, that would be great. Like an edje_cc --update.
Would be way faster. Sadly I don't have time for this :-(
-- 
Cedric BAIL

--
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

Re: [E-devel] Making EFL easier to use

[Simon Lees]

On 04/12/2017 08:27 AM, Christophe Sadoine wrote:
> On 12 April 2017 at 06:15, Cedric BAIL  wrote:
>> On Mon, Apr 10, 2017 at 7:46 PM, Gustavo Sverzut Barbieri
>>  wrote:
>>> On Mon, Apr 10, 2017 at 7:12 PM, Cedric BAIL  wrote:
>>>
>>> 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.
>>
>> That's where I have a different opinion. Developers are bad with
>> WYSIWYG interface. Designers are the users of that potential WYSIWYG
>> interface. Problem is that in the population we are trying to address,
>> a large portion of them are developers without a sidekick designer.
>> They are the one who want to be able to do simple UI "assemblage" from
>> a file. EDC is way to complicated and powerful for what they want. We
>> actually do not have anything to address the needs of this people.
>> This is what I am talking above.
> 
> You say the population you are trying to address have a large portion
> of developers.
> You also said in your original email that there was 3 groups :
> developers, developers, developers :D
> I just want to mention, please don't forget about the designers or
> even "wannabe designers".
> I get the "more developers -> more apps -> more e/efl users"
> But until 0.16, I think e became what it was in part because of themes
> and customization.
> There was a bunch of themes and it was fun :)
> 
> Everybody knows making a theme takes time. I think one reason is
> because you have to recompile your edc just to see what happens when
> you changed an offset. (I am currently trying to make a simple theme)
> If I could just change a line and see the change instantly I would be
> so happy. Enventor is nice but of course it has to recompile all edc
> files.

when I'm doing minor things like that I just import my .edj file into
eflete use it to figure out what values I want then copy the values back
into the .edc files. This is the most efficient way for me but i've
spent a long time reading .edc files probably alot more then most.

-- 

Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE Linux   Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B



signature.asc
Description: OpenPGP digital signature
--
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

Re: [E-devel] Making EFL easier to use

[Christophe Sadoine]

On 12 April 2017 at 06:15, Cedric BAIL  wrote:
> On Mon, Apr 10, 2017 at 7:46 PM, Gustavo Sverzut Barbieri
>  wrote:
>> On Mon, Apr 10, 2017 at 7:12 PM, Cedric BAIL  wrote:
>>
>> 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.
>
> That's where I have a different opinion. Developers are bad with
> WYSIWYG interface. Designers are the users of that potential WYSIWYG
> interface. Problem is that in the population we are trying to address,
> a large portion of them are developers without a sidekick designer.
> They are the one who want to be able to do simple UI "assemblage" from
> a file. EDC is way to complicated and powerful for what they want. We
> actually do not have anything to address the needs of this people.
> This is what I am talking above.

You say the population you are trying to address have a large portion
of developers.
You also said in your original email that there was 3 groups :
developers, developers, developers :D
I just want to mention, please don't forget about the designers or
even "wannabe designers".
I get the "more developers -> more apps -> more e/efl users"
But until 0.16, I think e became what it was in part because of themes
and customization.
There was a bunch of themes and it was fun :)

Everybody knows making a theme takes time. I think one reason is
because you have to recompile your edc just to see what happens when
you changed an offset. (I am currently trying to make a simple theme)
If I could just change a line and see the change instantly I would be
so happy. Enventor is nice but of course it has to recompile all edc
files.

--
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

[EGIT] [core/enlightenment] master 01/01: Sysinfo: Make memusage and cpumonitor work better on BSD.

[Al 'netstar' Poole]

okra pushed a commit to branch master.

http://git.enlightenment.org/core/enlightenment.git/commit/?id=c282341ed8cbf8091dcdecc507f5a114a3087677

commit c282341ed8cbf8091dcdecc507f5a114a3087677
Author: Al 'netstar' Poole 
Date:   Tue Apr 11 16:34:05 2017 -0500

Sysinfo: Make memusage and cpumonitor work better on BSD.

This commits D4749
---
 src/modules/sysinfo/cpumonitor/cpumonitor_sysctl.c | 54 ++
 src/modules/sysinfo/memusage/memusage_sysctl.c | 23 +++--
 2 files changed, 53 insertions(+), 24 deletions(-)

diff --git a/src/modules/sysinfo/cpumonitor/cpumonitor_sysctl.c 
b/src/modules/sysinfo/cpumonitor/cpumonitor_sysctl.c
index 8c3a53c..55ffd39 100644
--- a/src/modules/sysinfo/cpumonitor/cpumonitor_sysctl.c
+++ b/src/modules/sysinfo/cpumonitor/cpumonitor_sysctl.c
@@ -50,17 +50,23 @@ _cpumonitor_sysctl_getusage(Instance *inst)
 for (j = 0; j < CPU_STATES; j++) 
total += cpu[j];
 
-double used = total - (cpu[4]); //  + cpu[2] + cpu[1] + cpu[0]);
-double ratio = (float) total / 100.0;
+core = eina_list_nth(inst->cfg->cpumonitor.cores, i);
+
+int diff_total = total - core->total;
+int diff_idle = cpu[4] - core->idle;
+
+if (diff_total == 0) diff_total = 1;
+
+double ratio = diff_total / 100.0;
+long used = diff_total - diff_idle;
 
-double percent = ((double)used / (double)ratio);
+int percent = used / ratio;
 if (percent > 100) 
percent = 100;
 else if (percent < 0) 
percent = 0;
 
-core = eina_list_nth(inst->cfg->cpumonitor.cores, i);
-core->percent = (int) percent;
+core->percent = percent;
 core->total = total;
 core->idle = cpu[4];
 
@@ -86,17 +92,23 @@ _cpumonitor_sysctl_getusage(Instance *inst)
 for (j = 0; j < CPU_STATES; j++) 
   total += cpu_times[j];
 
-//user", "nice", "system", "interrupt", "idle", NULL
-long used = total - cpu_times[0] + cpu_times[1] + cpu_times[2] + 
cpu_times[3];
-double ratio = (double) total / 100.0;
-double percent =  100.0 - ((double) used / (double) ratio);
+long idle = cpu_times[4];
+
+int diff_total = total - inst->cfg->cpumonitor.total;
+int diff_idle = idle - inst->cfg->cpumonitor.idle;
+
+if (diff_total == 0) diff_total = 1;
+
+double ratio = diff_total / 100.0;
+long used = diff_total - diff_idle;
+int percent = used / ratio;
 if (percent > 100)
   percent = 100;
 else if (percent < 0)
   percent = 0;
  
 inst->cfg->cpumonitor.total = total;
-inst->cfg->cpumonitor.idle = cpu_times[3];
+inst->cfg->cpumonitor.idle = idle; // cpu_times[3];
 inst->cfg->cpumonitor.percent = (int) percent; 
  }
else if (ncpu > 1)
@@ -114,25 +126,27 @@ _cpumonitor_sysctl_getusage(Instance *inst)
  for (j = 0; j < CPU_STATES - 1; j++)
total += cpu_times[j];
 
- long used = total - (cpu_times[4]); 
- double ratio = (float) total / 100.0;
- int percent = used / ratio;
- if (percent > 100) 
-   percent = 100;
- else if (percent < 0) 
-   percent = 0;
  core = eina_list_nth(inst->cfg->cpumonitor.cores, i);
- core->percent = (int) percent;
+ int diff_total = total - core->total;
+ int diff_idle  = cpu_times[4] - core->idle;
+
  core->total = total;
  core->idle = cpu_times[4];
 
+ if (diff_total == 0) diff_total = 1;
+ double ratio = diff_total / 100;
+ long used = diff_total - diff_idle;
+ int percent = used / ratio;
+
+ core->percent = percent;
+
  percent_all += (int) percent;
  total_all += total;
  idle_all += core->idle;
   }

-inst->cfg->cpumonitor.total = total_all / ncpu;
-inst->cfg->cpumonitor.idle = idle_all / ncpu;
+inst->cfg->cpumonitor.total =  (total_all / ncpu);
+inst->cfg->cpumonitor.idle =   (idle_all / ncpu);
 inst->cfg->cpumonitor.percent = (percent_all / ncpu) + (percent_all % 
ncpu);
  }
 #endif
diff --git a/src/modules/sysinfo/memusage/memusage_sysctl.c 
b/src/modules/sysinfo/memusage/memusage_sysctl.c
index 1694861..db2c7e5 100644
--- a/src/modules/sysinfo/memusage/memusage_sysctl.c
+++ b/src/modules/sysinfo/memusage/memusage_sysctl.c
@@ -28,6 +28,13 @@ _sysctlfromname(const char *name, void *mib, int depth, 
size_t *len)
 }
 #endif
 
+#if defined(__OpenBSD__)
+void _memsize_bytes_to_kb(unsigned long *bytes)
+{
+ *bytes = (unsigned int) *bytes >> 10;
+}
+#endif
+
 void _memusage_sysctl_getusage(unsigned long *mem_total,
  unsigned long *mem_used,

Re: [E-devel] Enlightenment on OpenIndiana

[Aurélien Larcher]

Hi,
sorry for the very late reply, I have been busy with other tasks... and
thank you very much for your substantial answers.
I followed up off-list with Vincent Torri in the past weeks.

i don't know what to say... both of the traces i see smell to me like really
> nasty OS issues at a glance. show me more info to say they are not, but
> this
> would imply opensolaris is really badly broken. especially getpid()
> hanging.
>

Better late than never: I found the origin of the our problems: it is epoll.
Joyent introduced an implementation of epoll at some point but if you look
at:

https://us-east.manta.joyent.com/smartosman/public/man5/epoll.5.html

it is not considered a first class citizen and is deliberately avoided on
illumos.

In src/lib/ecore/ecore_main.c, epoll is used if the header exists, so as
soon as sys/epoll.h appeared in the tree, it broke our packages.

I have changed the ifdef, rebuilt EFL 1.18.4, tested elementary and
terminology 1.0, all is good.
Thank you very much for your kind help.

Aurelien



>
> > Kind regards
> >
> > Aurelien
> >
> > 
> 
> > helios> pstack `pgrep terminology`
> > 12876:terminology
> > -  lwp# 1 / thread# 1  
> >  feeff915 getpid   (fafc, 400fa919, 8046118, fe9c8db9) + 15
> >  fe9c8fef ecore_main_loop_begin (febf4409) + 36f
> >  febf4417 elm_run  (0, 0, 752f0031, 81414f0, 40001415, 0) + 17
> >  0806a559 elm_main (1, 804769c, 8047668, 806aa0d, 80bc000, 8047648) + e59
> >  0806aa26 main (804765c, fef786e8, 8047690, 8062cb3, 1, 804769c) + 36
> >  08062cb3 _start   (1, 80477fc, 0, 8047808, 8047824, 804782f) + 83
> > -  lwp# 2 / thread# 2  
> >  feefb5b9 lwp_park (0, 0, 0)
> >  feef55f8 cond_wait_queue (fe698408, fe6983ec, 0, 1, 83088f8, 83088f8) +
> 6a
> >  feef5c70 __cond_wait (fe698408, fe6983ec, fe657c9a, fe66b000,
> > fef6e000, fe698408) + 8f
> >  feef5cc4 cond_wait (fe698408, fe6983ec, fe50123b, fe5cf036, fe65965a,
> > fe66b000) + 2e
> >  feef5d0d pthread_cond_wait (fe698408, fe6983ec, fdb9ef98, fe5ced59) + 24
> >  fe5cedde evas_thread_worker_func (0, 2, fdb9efc8, fedd1429, feed7c7e,
> 3) + 9e
> >  fedd1432 _eina_internal_call (80bf5c0, 0, 0, 0) + 32
> >  feefb3cb _thrp_setup (fda90240) + 88
> >  feefb560 _lwp_start (fda90240, 0, 0, 0, 0, 0)
> > -  lwp# 3 / thread# 3  
> >  fedd1400 _eina_internal_call(), exit value = 0x
> > ** zombie (exited, not detached, not yet joined) **
> > -  lwp# 4 / thread# 4  
> >  fedd1400 _eina_internal_call(), exit value = 0x
> > ** zombie (exited, not detached, not yet joined) **
> > -  lwp# 5 / thread# 5  
> >  feefb5b9 lwp_park (0, 0, 0)
> >  feeef15e sema_wait (81428d8, fef726c0, fd97ef28, feef41d9, fee0c000,
> > 81428d8) + 19
> >  feee22cd sem_wait (81428d8, fee10018, fda90a40, feef3e46) + 35
> >  fedd24af eina_thread_queue_wait (8142898, fd97ef7c, fd97ef98, fe5c5c9c)
> + 3f
> >  fe5c5cbf _evas_common_scale_sample_thread (0, 5, fd97efc8, fedd1429,
> > feed7c7e, 3) + 3f
> >  fedd1432 _eina_internal_call (8199d80, 0, 0, 0) + 32
> >  feefb3cb _thrp_setup (fda90a40) + 88
> >  feefb560 _lwp_start (fda90a40, 0, 0, 0, 0, 0)
> > -  lwp# 6 / thread# 6  
> >  feeffcc5 pollsys  (fb87fc30, 1, fb87fd68, 0)
> >  fee9730f pselect  (13, fb87fde0, fb87fe60, fb87fee0, fb87fd68, 0) + 1bf
> >  fee97618 select   (13, fb87fde0, fb87fe60, fb87fee0, fb87fdd8,
> 41197acd) + 8e
> >  fe9bde8f _timer_tick_core (0, 83a7f10, fb87ff98, fe9cf948, fee0c000,
> > 813a988) + 15f
> >  fe9cf96c _ecore_direct_worker (83a7f10, 6, fb87ffc8, fedd1429,
> > feed7c7e, 3) + 3c
> >  fedd1432 _eina_internal_call (813a988, 0, 0, 0) + 32
> >  feefb3cb _thrp_setup (fda91a40) + 88
> >  feefb560 _lwp_start (fda91a40, 0, 0, 0, 0, 0)
> >
> > 
> 
> > helios> pstack 9171
> > 9171:elementary_test
> > -  lwp# 1 / thread# 1  
> >  feeff475 __so_recvmsg (a, 80473f8, 8000, 0) + 15
> >  fe0dc229 __xnet_recvmsg (a, 80473f8, 0, fd110d4c, 0, 1) + 25
> >  fd110122 _xcb_in_read (81eab10, fe37, 80474c8, fe36239b) + 82
> >  fd110e71 xcb_poll_for_event (81eab10, 0, 0, feda5550, 0, 81ac380) + 91
> >  fd1c2ed5 poll_for_response (fd1c3a49, fd2b6000, 8047538, fd1ae469,
> > 8239780, fedcb840) + 135
> >  fd1c34cf _XEventsQueued (8239780, 2, fecf68fb, fed14000) + 5f
> >  fd1b2712 XPending (8239780, 8168910, fecff0d0, feda681b) + 62
> >  fe56c14a _ecore_x_fd_handler_buf (8239780, 816aad0, 80475b8, feda53d2)
> + 1a
> >  feda6854 _ecore_main_fd_handlers_buf_call (fed1469c, 3f, edb4,
> > 4005c842, fed1469c, 8047610) + 74
> >  feda8d6e ecore_main_loop_begin (feda9039, fedcb000, 8047648,
> > feda6114, 4102, 8168960) + ee
> >  feda9047 _efl_loop_begin 

Re: [E-devel] Making EFL easier to use

[Cedric BAIL]

On Mon, Apr 10, 2017 at 7:46 PM, Gustavo Sverzut Barbieri
 wrote:
> On Mon, Apr 10, 2017 at 7:12 PM, Cedric BAIL  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.

That's where I have a different opinion. Developers are bad with
WYSIWYG interface. Designers are the users of that potential WYSIWYG
interface. Problem is that in the population we are trying to address,
a large portion of them are developers without a sidekick designer.
They are the one who want to be able to do simple UI "assemblage" from
a file. EDC is way to complicated and powerful for what they want. We
actually do not have anything to address the needs of this people.
This is what I am talking above.

[...]

>> 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").
>
> 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.

My main concern with this proposition is that it is very very easy to
write blocking code and it makes also the code of the model more
complex in the sense that you have to remember which request you are
currently answering and where your dummy values are. The reason we
push for a single API to fetch property is because we want to simplify
the logic by having just one pattern to be implemented in model.
Ideally this would mean that the monitoring is to be done solely by
the root model and the leaf.

I understand why you 

Re: [E-devel] Voting on EDD 2017 dates

[Jonathan Aquilina]

Dates are confirmed as available will get back to everyone shortly once 
everything is confirmed

Sent from my iPhone

> On 11 Apr 2017, at 21:43, Stefan Schmidt  wrote:
> 
> HEllo.
> 
>> On 04/10/2017 01:19 AM, Stefan Schmidt wrote:
>> Hello.
>> 
>>> On 04/06/2017 09:07 AM, Stefan Schmidt wrote:
>>> Hello.
>>> 
 On 03/31/2017 03:43 PM, Stefan Schmidt wrote:
 Hello.
 
 Getting a suitable venue at the locations voted highest in the EDD 2017
 location voting took a longer time than we expected. We have found one
 now in lovely Malta.
 
 To bring things further I put out another vote on the dates. Please try
 to vote soon so we can getting things sorted out with the venue.
 
 https://phab.enlightenment.org/V28
>>> 
>>> We have 10 votes so far which is not bad. If you want to attend but have
>>> not voted yet you have until Sunday to do so. On Sunday we will close
>>> the vote to finalize the date with the venue.
>> 
>> Voting is closed now. With 12 out of 15 votes the winner is the 24+25.06
>> weekend.
> 
> Please wait before making any bookings for this for now. We need to have 
> another confirmation with the venue as there seem to have been a date 
> mixup. Stay tuned before booking anything without the option to cancel.
> 
> regards
> Stefan Schmidt
> 
> --
> 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


--
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

Re: [E-devel] 1.19 release imminent?

[Stefan Schmidt]

Hello.

On 04/10/2017 11:31 PM, Mike Blumenkrantz wrote:
> Okay, I've heard back and it seems like current ecore-con behavior matches
> expected behavior so I have no more blockers there.

ok, great, so we are finally ready. I will test things tomorrow and tar 
the release up as well as writing release notes etc.

If you have something that you want mentioned in the release notes 
please add it here. I will massage things as needed when I come to it 
tomorrow.

https://phab.enlightenment.org/w/efl_and_elementary_1_19_release_announcement/

regards
Stefan Schmidt

--
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

Re: [E-devel] Voting on EDD 2017 dates

[Stefan Schmidt]

HEllo.

On 04/10/2017 01:19 AM, Stefan Schmidt wrote:
> Hello.
>
> On 04/06/2017 09:07 AM, Stefan Schmidt wrote:
>> Hello.
>>
>> On 03/31/2017 03:43 PM, Stefan Schmidt wrote:
>>> Hello.
>>>
>>> Getting a suitable venue at the locations voted highest in the EDD 2017
>>> location voting took a longer time than we expected. We have found one
>>> now in lovely Malta.
>>>
>>> To bring things further I put out another vote on the dates. Please try
>>> to vote soon so we can getting things sorted out with the venue.
>>>
>>> https://phab.enlightenment.org/V28
>>
>> We have 10 votes so far which is not bad. If you want to attend but have
>> not voted yet you have until Sunday to do so. On Sunday we will close
>> the vote to finalize the date with the venue.
>
> Voting is closed now. With 12 out of 15 votes the winner is the 24+25.06
> weekend.

Please wait before making any bookings for this for now. We need to have 
another confirmation with the venue as there seem to have been a date 
mixup. Stay tuned before booking anything without the option to cancel.

regards
Stefan Schmidt

--
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

Re: [E-devel] changing development of core apps and E itself

[Cedric BAIL]

On Tue, Apr 11, 2017 at 2:52 AM, Carsten Haitzler  wrote:
> On Tue, 11 Apr 2017 18:58:58 +0930 Simon Lees  said:
>> On 04/11/2017 04:19 PM, Carsten Haitzler (The Rasterman) wrote:
>> > On Mon, 10 Apr 2017 12:01:49 -0300 Gustavo Sverzut Barbieri
>> >  said:
>> >> On Mon, Apr 10, 2017 at 4:50 AM, Carsten Haitzler 
>> >> wrote:
>> >>> On Sun, 9 Apr 2017 23:25:39 -0700 Cedric BAIL  said:
>> >>>
>>  On Sun, Apr 9, 2017 at 7:51 PM, Gustavo Sverzut Barbieri
>>   wrote:
>> > On Sun, Apr 9, 2017 at 9:38 PM, Simon Lees  wrote:
>> >> On 04/10/2017 12:39 AM, Gustavo Sverzut Barbieri wrote:
>> >>> Which brings me to my last point: we should adopt and use for REAL a
>> >>> one possible option is to jump behind the transpiler bandwagon. what 
>> >>> about
>> >>> writing a js -> lua transpiler? this should be not that hard given the
>> >>> incredible similarity in the 2 languages. you can then write in lua or in
>> >>> js. just you need a compile step for js. perhaps we should also have a
>> >>> compile step for lua anyway? at least minify it for faster parsing
>> >>> etc?
>> >>
>> >> isn't jerryscript good enough? Seems pretty small, not sure if they're
>> >> focusing on efficiency as much as ram/disk.
>> >
>> > jerryscript is interpreted only - no jit, so it's going to have a fairly 
>> > big
>> > performance hit vs something jitted. if the point is to write more and more
>> > in such a language you want it to be as performant as possible. it can be
>> > more performant with a jit... so you'd want that.
>> >
>>
>> I'll be controversial and say that for many Desktop UI applications and
>> probably for a lot of smartphone ones as well performance really doesn't
>> matter that much, its not like were running these things on a 386, So I
>> guess sometimes less performant languages have other benefits which is
>> why people use them.
>
> then why does android precompile java apps to native code on installation now
> as opposed to just keep interpreting? :)

No clue of what this guys are doing, but I can tell you for sure, you
will be fine writing EFL application in JS. For a reminder, EFL with a
JS binding without any JIT run fine for doing 2D games on a MIPS at
200Mhz with no GPU. So speed is absolutely not necessary for the large
majority of application with EFL as a toolkit (Not talking bob here).
I think that if we are to choose a preferred binding, we should go
with what bring most developers in.

Cedric

--
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

[EGIT] [core/efl] master 01/01: Evas_Common: Fix minor grammatical errors

[Bryce Harrington]

devilhorns pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=20e7f661e6eaebb55fe78d7e83982f91d711e954

commit 20e7f661e6eaebb55fe78d7e83982f91d711e954
Author: Bryce Harrington 
Date:   Tue Apr 11 11:48:36 2017 -0400

Evas_Common: Fix minor grammatical errors

Reviewers: devilhorns

Reviewed By: devilhorns

Subscribers: cedric, jpeg

Differential Revision: https://phab.enlightenment.org/D4781
---
 src/lib/evas/Evas_Common.h | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/src/lib/evas/Evas_Common.h b/src/lib/evas/Evas_Common.h
index c41b626..59f11a0 100644
--- a/src/lib/evas/Evas_Common.h
+++ b/src/lib/evas/Evas_Common.h
@@ -1426,7 +1426,7 @@ EAPI const Evas_Device 
*evas_device_emulation_source_get(const Evas_Device *dev)
 /**
  * @defgroup Evas_Image_Group Image Functions
  *
- * Functions that deals with images at canvas level.
+ * Functions that deal with images at canvas level.
  *
  * @ingroup Evas_Canvas
  */
@@ -1434,7 +1434,7 @@ EAPI const Evas_Device 
*evas_device_emulation_source_get(const Evas_Device *dev)
 /**
  * @defgroup Evas_Font_Group Font Functions
  *
- * Functions that deals with fonts.
+ * Functions that deal with fonts.
  *
  * @ingroup Evas_Canvas
  */
@@ -1595,7 +1595,7 @@ EAPI const Evas_Device 
*evas_device_emulation_source_get(const Evas_Device *dev)
  * evas_object_show(bg);
  * @endcode
  *
- * This however will have issues if the @c evas_canvas is resized, however most
+ * This will have issues if the @c evas_canvas is resized, however most
  * windows are created using ecore evas and that has a solution to using the
  * rectangle as a background:
  * @code
@@ -1735,9 +1735,9 @@ EAPI const Evas_Device 
*evas_device_emulation_source_get(const Evas_Device *dev)
  * In image viewer applications, for example, the user will be looking
  * at a given image, at full size, and will desire that the navigation
  * to the adjacent images on his/her album be fluid and fast. Thus,
- * while displaying a given image, the program can be on the
+ * while displaying a given image, the program can be in the
  * background loading the next and previous images already, so that
- * displaying them on the sequence is just a matter of repainting the
+ * displaying them in sequence is just a matter of repainting the
  * screen (and not decoding image data).
  *
  * Evas addresses this issue with image pre-loading. The code
@@ -2294,7 +2294,7 @@ struct _Evas_Smart_Cb_Description
  * @param cb_desc Array of callback descriptions for this smart class.
  *
  * This macro saves some typing when writing a smart class derived
- * from another one. In order to work, the user @b must provide some
+ * from another one. In order for this to work, the user @b must provide some
  * functions adhering to the following guidelines:
  *  - @_smart_set_user(): the @b internal @c _smart_set
  *function (defined by this macro) will call this one, provided by
@@ -2377,7 +2377,7 @@ struct _Evas_Smart_Cb_Description
  *   class.
  *
  * This macro saves some typing when writing a smart class derived
- * from another one. In order to work, the user @b must provide some
+ * from another one. In order for this to work, the user @b must provide some
  * functions adhering to the following guidelines:
  *  - @_smart_set_user(): the @b internal @c _smart_set
  *function (defined by this macro) will call this one, provided by

-- 

Re: [E-devel] changing development of core apps and E itself

[Solerman Kaplon]

Em 11/04/2017 06:52, Carsten Haitzler (The Rasterman) escreveu:
>
> then why does android precompile java apps to native code on installation now
> as opposed to just keep interpreting? :)
>

Because java is jitted and doing JIT takes time, memory and battery to do. 
Plus, 
on usual VMs, there is no caching of JIT code. So they just do the JIT once and 
save it for later reuse (Its more complicated than JIT cache, but you get the 
point)


Solerman


--
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

Re: [E-devel] changing development of core apps and E itself

[Simon Lees]

On 04/11/2017 07:22 PM, Carsten Haitzler (The Rasterman) wrote:
> On Tue, 11 Apr 2017 18:58:58 +0930 Simon Lees  said:
> 
>>
>>
>> On 04/11/2017 04:19 PM, Carsten Haitzler (The Rasterman) wrote:
>>> On Mon, 10 Apr 2017 12:01:49 -0300 Gustavo Sverzut Barbieri
>>>  said:
>>>
 On Mon, Apr 10, 2017 at 4:50 AM, Carsten Haitzler 
 wrote:
> On Sun, 9 Apr 2017 23:25:39 -0700 Cedric BAIL  said:
>
>> On Sun, Apr 9, 2017 at 7:51 PM, Gustavo Sverzut Barbieri
>>  wrote:
>>> On Sun, Apr 9, 2017 at 9:38 PM, Simon Lees  wrote:
 On 04/10/2017 12:39 AM, Gustavo Sverzut Barbieri wrote:
> Which brings me to my last point: we should adopt and use for REAL a
> one possible option is to jump behind the transpiler bandwagon. what about
> writing a js -> lua transpiler? this should be not that hard given the
> incredible similarity in the 2 languages. you can then write in lua or in
> js. just you need a compile step for js. perhaps we should also have a
> compile step for lua anyway? at least minify it for faster parsing
> etc?

 isn't jerryscript good enough? Seems pretty small, not sure if they're
 focusing on efficiency as much as ram/disk.
>>>
>>> jerryscript is interpreted only - no jit, so it's going to have a fairly big
>>> performance hit vs something jitted. if the point is to write more and more
>>> in such a language you want it to be as performant as possible. it can be
>>> more performant with a jit... so you'd want that.
>>>
>>
>> I'll be controversial and say that for many Desktop UI applications and
>> probably for a lot of smartphone ones as well performance really doesn't
>> matter that much, its not like were running these things on a 386, So I
>> guess sometimes less performant languages have other benefits which is
>> why people use them.
> 
> then why does android precompile java apps to native code on installation now
> as opposed to just keep interpreting? :)
> 

I was referring to the half written in javascript :-P, granted most of
these are just slightly glorified web pages with notifications but still.

-- 

Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE Linux   Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B



signature.asc
Description: OpenPGP digital signature
--
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

Re: [E-devel] changing development of core apps and E itself

[The Rasterman]

On Tue, 11 Apr 2017 18:58:58 +0930 Simon Lees  said:

> 
> 
> On 04/11/2017 04:19 PM, Carsten Haitzler (The Rasterman) wrote:
> > On Mon, 10 Apr 2017 12:01:49 -0300 Gustavo Sverzut Barbieri
> >  said:
> > 
> >> On Mon, Apr 10, 2017 at 4:50 AM, Carsten Haitzler 
> >> wrote:
> >>> On Sun, 9 Apr 2017 23:25:39 -0700 Cedric BAIL  said:
> >>>
>  On Sun, Apr 9, 2017 at 7:51 PM, Gustavo Sverzut Barbieri
>   wrote:
> > On Sun, Apr 9, 2017 at 9:38 PM, Simon Lees  wrote:
> >> On 04/10/2017 12:39 AM, Gustavo Sverzut Barbieri wrote:
> >>> Which brings me to my last point: we should adopt and use for REAL a
> >>> one possible option is to jump behind the transpiler bandwagon. what about
> >>> writing a js -> lua transpiler? this should be not that hard given the
> >>> incredible similarity in the 2 languages. you can then write in lua or in
> >>> js. just you need a compile step for js. perhaps we should also have a
> >>> compile step for lua anyway? at least minify it for faster parsing
> >>> etc?
> >>
> >> isn't jerryscript good enough? Seems pretty small, not sure if they're
> >> focusing on efficiency as much as ram/disk.
> > 
> > jerryscript is interpreted only - no jit, so it's going to have a fairly big
> > performance hit vs something jitted. if the point is to write more and more
> > in such a language you want it to be as performant as possible. it can be
> > more performant with a jit... so you'd want that.
> > 
> 
> I'll be controversial and say that for many Desktop UI applications and
> probably for a lot of smartphone ones as well performance really doesn't
> matter that much, its not like were running these things on a 386, So I
> guess sometimes less performant languages have other benefits which is
> why people use them.

then why does android precompile java apps to native code on installation now
as opposed to just keep interpreting? :)

-- 
- 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

Re: [E-devel] changing development of core apps and E itself

[Simon Lees]

On 04/11/2017 04:19 PM, Carsten Haitzler (The Rasterman) wrote:
> On Mon, 10 Apr 2017 12:01:49 -0300 Gustavo Sverzut Barbieri
>  said:
> 
>> On Mon, Apr 10, 2017 at 4:50 AM, Carsten Haitzler 
>> wrote:
>>> On Sun, 9 Apr 2017 23:25:39 -0700 Cedric BAIL  said:
>>>
 On Sun, Apr 9, 2017 at 7:51 PM, Gustavo Sverzut Barbieri
  wrote:
> On Sun, Apr 9, 2017 at 9:38 PM, Simon Lees  wrote:
>> On 04/10/2017 12:39 AM, Gustavo Sverzut Barbieri wrote:
>>> Which brings me to my last point: we should adopt and use for REAL a
>>> one possible option is to jump behind the transpiler bandwagon. what about
>>> writing a js -> lua transpiler? this should be not that hard given the
>>> incredible similarity in the 2 languages. you can then write in lua or in
>>> js. just you need a compile step for js. perhaps we should also have a
>>> compile step for lua anyway? at least minify it for faster parsing etc?
>>
>> isn't jerryscript good enough? Seems pretty small, not sure if they're
>> focusing on efficiency as much as ram/disk.
> 
> jerryscript is interpreted only - no jit, so it's going to have a fairly big
> performance hit vs something jitted. if the point is to write more and more in
> such a language you want it to be as performant as possible. it can be more
> performant with a jit... so you'd want that.
> 

I'll be controversial and say that for many Desktop UI applications and
probably for a lot of smartphone ones as well performance really doesn't
matter that much, its not like were running these things on a 386, So I
guess sometimes less performant languages have other benefits which is
why people use them.

-- 

Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE Linux   Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B



signature.asc
Description: OpenPGP digital signature
--
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

[EGIT] [tools/eflete] master 01/01: property_private: fix saving empty script code

[Tetiana Naumenko]

rimmed pushed a commit to branch master.

http://git.enlightenment.org/tools/eflete.git/commit/?id=77e98e94adbb9359ff8c9d015eec886534b6a8c0

commit 77e98e94adbb9359ff8c9d015eec886534b6a8c0
Author: Tetiana Naumenko 
Date:   Mon Apr 10 12:03:22 2017 +0300

property_private: fix saving empty script code

@fix

Change-Id: I3a89b186dd3bdb9a4d4e0a4ac6f770fed822a657
---
 src/bin/ui/property/property_private.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/bin/ui/property/property_private.h 
b/src/bin/ui/property/property_private.h
index 4b74148..b95b27f 100644
--- a/src/bin/ui/property/property_private.h
+++ b/src/bin/ui/property/property_private.h
@@ -700,6 +700,9 @@ property_color_entry_set(Evas_Object *entry, const char 
*text, color_data *c_dat
  {
 markup = elm_entry_utf8_to_markup(text);
 colored = color_apply(c_data, markup, strlen(markup), NULL, NULL);
+
+if (colored == NULL) return;
+
 if ((elm_entry_entry_get(entry)) &&
 (strcmp(colored, elm_entry_entry_get(entry)) != 0))
   elm_entry_entry_set(entry, colored);

-- 

Re: [E-devel] changing development of core apps and E itself

[The Rasterman]

On Mon, 10 Apr 2017 12:01:49 -0300 Gustavo Sverzut Barbieri
 said:

> On Mon, Apr 10, 2017 at 4:50 AM, Carsten Haitzler 
> wrote:
> > On Sun, 9 Apr 2017 23:25:39 -0700 Cedric BAIL  said:
> >
> >> On Sun, Apr 9, 2017 at 7:51 PM, Gustavo Sverzut Barbieri
> >>  wrote:
> >> > On Sun, Apr 9, 2017 at 9:38 PM, Simon Lees  wrote:
> >> >> On 04/10/2017 12:39 AM, Gustavo Sverzut Barbieri wrote:
> >> >>> Which brings me to my last point: we should adopt and use for REAL a
> >> >>> binding. You all know my personal preference is Python, but in 11
> >> >>> years I couldn't convince people to like it... so whatever people
> >> >>> like, let's pick one language and use it as much as possible where
> >> >>> appropriate (you're not rewriting the core of Evas in it...). It seems
> >> >>> Lua is strong contender, and is very efficient, small and already a
> >> >>> hard dependency... our docs are being generated by a lua script,
> >> >>> etc...
> >> >>>
> >> >> openSUSE ships atleast 4-5 applications using the python bindings and
> >> >> could probably ship a few others from bodhi. (We don't at the moment as
> >> >> they don't have a proper build system and I haven't had the time to port
> >> >> them too one). I personally also prefer the python bindings and have
> >> >> used them in the past.
> >> >
> >> > I'm a python guy, wrote the initial python efl... I wrote big software
> >> > using that (Canola 2.0 if people remember of that) and tried to push
> >> > them as E modules... never sticks, particularly Rasterman never liked
> >> > it, thus a major developer who would never ever touch it -- and this
> >> > defeats the purpose.
> >> >
> >> > Lua isn't bad, and as it's required to build and during efl's use, we
> >> > can stick with that. Like making it zero-cost/effort to enable lua
> >> > scripting in every application, reducing the pain to write simple
> >> > stuff like basic configurations.
> >>
> >> I like the idea of having a zero-cost/effort to add scripting support
> >> in any EFL application. I don't know yet how easily we can do that. I
> >
> > technically... thats exactly why q66 has done libelua.so... :) it's so the
> > elua binary launcher can be used without putting al the code in there. it's
> > so eventually "bob" could easily load lua too etc. etc. - basically provide
> > a higher level luajit + efl binding setup to allow just this.
> >
> > it hasn't been exercized beyond the elua binary right now which is used to
> > generate al our eo based docs... so it does work in that sense... :)
> >
> >> guess that maybe some of the binding should provide a library as part
> >> of EFL to make it easy to do integrate them. Something doing
> >> initialization, registering object, loading a script and executing one
> >> for some amount of time.
> >
> > elua :)
> >
> >> I am also not sure about lua at all here. I know we are focusing
> >> mostly on performance, but if we really care about increasing our
> >> developers base and making it easier, isn't JS the winner in that
> >> space ? Isn't it over already for choosing the scripting language ?
> >
> > from a performance and size point of view lua is the biggest winner. from a
> > popularity point of view js is the biggest winner. it depends how much you
> > expect people to do in scripting. the more you expect them to write in it,
> > the more size, performance etc. will matter. the less they do, the less it
> > matters. if we take gustavo's point about "using high level languages more"
> > then the implication is to use them more and more and more. thus it matters.
> >
> > personally i prefer js a little more than lua from a language point of
> > view... but because of performance etc. imho lua is the winner. if someone
> > came up with a js library like luajit that was about the same size and
> > performance i wouldn't hesitate to jump behind js.
> >
> > one possible option is to jump behind the transpiler bandwagon. what about
> > writing a js -> lua transpiler? this should be not that hard given the
> > incredible similarity in the 2 languages. you can then write in lua or in
> > js. just you need a compile step for js. perhaps we should also have a
> > compile step for lua anyway? at least minify it for faster parsing etc?
> 
> isn't jerryscript good enough? Seems pretty small, not sure if they're
> focusing on efficiency as much as ram/disk.

jerryscript is interpreted only - no jit, so it's going to have a fairly big
performance hit vs something jitted. if the point is to write more and more in
such a language you want it to be as performant as possible. it can be more
performant with a jit... so you'd want that.

> also be warned about js... not sure if you used it for real, but it's

used it in html for a few things a while ago... a long while ago. not really
written lots of it - just glue code or "onclicked=function ..." stuff.

> hardly usable "as is", most 

Re: [E-devel] changing development of core apps and E itself

[The Rasterman]

On Tue, 11 Apr 2017 07:59:15 +0930 Simon Lees  said:

> 
> 
> On 04/11/2017 12:25 AM, Gustavo Sverzut Barbieri wrote:
> > On Mon, Apr 10, 2017 at 6:06 AM, Carsten Haitzler 
> > wrote:
> >> On Sun, 9 Apr 2017 12:09:08 -0300 Gustavo Sverzut Barbieri
> >>  said:
> >>
> >> Is it an old need? At least on OSX and modern Windows apps are encouraged
> >> to fit in and look "standard" and users want it there... :)
> > 
> > more and more apps move to individual looks, this happened before
> > (remember Nero CD Burner and the likes? Winamp?) but after smartphones
> > almost no app wants to use the "system look and feel". Each app wants
> > their own brand, theme and impact...
> 
> Yet us users wish that all apps still look consistent   Designers
> have been given too much power they should have less :-P

i still hear many users asking for consistent ui look and feel too. this is not
a universal truth that all apps must, should be or are desired to be "custom
designed by a designer".

-- 
- 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

Re: [E-devel] changing development of core apps and E itself

[The Rasterman]

On Mon, 10 Apr 2017 11:55:38 -0300 Gustavo Sverzut Barbieri
 said:

> On Mon, Apr 10, 2017 at 6:06 AM, Carsten Haitzler 
> wrote:
> > On Sun, 9 Apr 2017 12:09:08 -0300 Gustavo Sverzut Barbieri
> >  said:
> >
> >> Hi all,
> >>
> >> Nowadays with a newborn daughter I have more time to think than to
> >> code (likely to remain like that for few more weeks), so I did think a
> >> bit more of our development process in the light of "how to make it
> >> faster, more reliable and easier to use".
> >>
> >> As most of you that join IRC at the same time as I do know, my idea is
> >> to use more of our high level features, including our high level
> >> languages. To elaborate:
> >>
> >> # Background
> >>
> >> Historically in E/EFL new features are developed based on needs, like
> >> Evas was created to address Enlightenments fancy graphics and
> >> particularly EFM... this also resulted in need for theme engine which
> >> resulted in EDB, EET, Edje... The main loop abstraction resulted in
> >> Ecore, the widgets need resulted in Elementary.
> >>
> >> However, also historically although the features are developed to
> >> address some needs they are not used up to their potential. For
> >> example, if you know Edje's potential you'd be amazed how much of that
> >> potential is wasted in E, with many layouts and design being done
> >
> > Edje wasn't designed to do UI layout. it's incredibly limited in what it can
> > ultimately do here and it just wasn't intended to do this. I think this is
> > the job of something else to do other than Edje. Edje has expanded over
> > time to the point it can kind of lay out some UI's - but thats just it
> > being overgrown for it's intended use. :)
> 
> I know Edje since 2006 and since then it's very usable to this
> purpose... Unless you're creating automated forms in some way, where
> you get along with a loop to manually populate label=entry... edje is
> just much easier than coping with designer requirements to get proper
> padding, alignment and effects, things like click and expand...
> box/table is just a pain, in every toolkit you have to play with size
> hints, expand/fill/align/padding/preferrred size... and it never gets
> what you want.
> 
> OTOH if you open a visual designer, type your label text where you
> want, the color you want, with the padding/margin you want... then you
> put in some EXTERNAL or SWALLOW, you do get what you want.

boxes, tables, and so on are far easier for most ui layout. that combined with
elm layout widgets where you can use edje generally should cover. edje alone is
far too limited to do a decent ui.

> [...]
> >> Historically we have few apps other than our window manager, which as
> >> said above uses lots of low level APIs, and the few apps we have also
> >> use some sort of low level features, such as Terminology, Rage and
> >> even Ephoto. For instance, while we're creating Eo "MVC", no app is
> >> using that.. replicating stuff like file system walk/scan for files,
> >> then presenting them in list/grid views.
> >
> > this is all part of efl+interfaces - we're designing based on past
> > experience with efl and apps, but it's not being used yet because it's not
> > stable yet. one major bit of work will be in porting apps like terminology,
> > rage, e, ephoto, edi etc. to eo/efl interfaces... it's certainly not a
> > small amount of work.
> 
> okay, but over time all "solutions" we added were only used by 1-2
> apps that came post it... previous instances were not changed, and new
> instances would need something else and a new solution would be
> created.
> 
> see EFM's internal, it's quite nice, it's not only asynchronous, but
> done in a slave process to mitigate possible crashes... could be
> enhanced to limit resources (caps, MAC, ...) while the UI is also very
> well done, capable of many modes (list, icon...)
> 
> instead of splitting that out of E and moving to ELM, elm created its
> own stuff... which never feedback into EFM... then it came Ecore_File,
> then Eio... Eina_Model -> Eo -> Eo-Model... Meanwhile Ephoto used one
> of these solutions, Rage didn't.
> 
> That's what I mean. Is this going to vanish? Could we agree to work on
> a single basic building block that address all of that? I want
> elm_fileselector to be as reliable as efm and rage to use the same
> tech, as I do want for ephoto.

well rage is different as it collects files from subdirectories in a specific
way where it's just simpler how it does how it does.

i do agree that efm vs elm file selector is an issue. e's file selector that is
built out of efm is by far better and more featureful. reality is that it
should have been ported to elm (and then e made to depend on elm) when file
selectors were added.

this is a duplication i currently also dislike. elm's file selector isn't the
greatest and needs love. it is pretty simple compared to e's file selector when
you use them side by side.

now efm's 

[EGIT] [core/efl] master 01/01: EvasGL: Do internal make current if context changed.

[Minkyoung Kim]

jpeg pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=78d266e1897cc524522caa7bc8c9b8908f1096e8

commit 78d266e1897cc524522caa7bc8c9b8908f1096e8
Author: Minkyoung Kim 
Date:   Tue Apr 11 16:20:07 2017 +0900

EvasGL: Do internal make current if context changed.

Summary:
Before, rsc->current_ctx is always same with ctx.
So checking context change was meaningless.
From now, it has meaning.

Test Plan: App call evas_gl_make_current more than twice in pixels 
callback. Those surfaces are indirect rendering surface.

Reviewers: jpeg, dkdk, wonsik

Reviewed By: jpeg

Subscribers: cedric

Differential Revision: https://phab.enlightenment.org/D4773
---
 src/modules/evas/engines/gl_common/evas_gl_core.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/modules/evas/engines/gl_common/evas_gl_core.c 
b/src/modules/evas/engines/gl_common/evas_gl_core.c
index d558a9d..c4d3541 100644
--- a/src/modules/evas/engines/gl_common/evas_gl_core.c
+++ b/src/modules/evas/engines/gl_common/evas_gl_core.c
@@ -2460,6 +2460,7 @@ evgl_make_current(void *eng_data, EVGL_Surface *sfc, 
EVGL_Context *ctx)
Eina_Bool dbg = EINA_FALSE;
EVGL_Resource *rsc;
int curr_fbo = 0, curr_draw_fbo = 0, curr_read_fbo = 0;
+   Eina_Bool ctx_changed = EINA_FALSE;
 
// Check the input validity. If either sfc is valid but ctx is NULL, it's 
also error.
// sfc can be NULL as evas gl supports surfaceless make current
@@ -2550,6 +2551,10 @@ evgl_make_current(void *eng_data, EVGL_Surface *sfc, 
EVGL_Context *ctx)
 evas_gl_common_error_set(eng_data, EVAS_GL_BAD_CONTEXT);
 return 0;
  }
+
+   if (rsc->current_ctx != ctx)
+ ctx_changed = EINA_TRUE;
+
rsc->current_ctx = ctx;
rsc->current_eng = eng_data;
 
@@ -2807,7 +2812,7 @@ evgl_make_current(void *eng_data, EVGL_Surface *sfc, 
EVGL_Context *ctx)
_framebuffer_create(>surface_fbo, ctx->version);
 
  // Attach fbo and the buffers
- if ((rsc->current_ctx != ctx) || (ctx->current_sfc != sfc) || 
(rsc->direct.rendered))
+ if ((ctx_changed) || (ctx->current_sfc != sfc) || 
(rsc->direct.rendered))
{
   sfc->current_ctx = ctx;
   if ((sfc->direct_mem_opt) && (sfc->direct_override))

-- 

[EGIT] [core/efl] master 01/01: evas: If there isn't clipper when recalcing clip, set mask.clip = NULL.

[Minkyoung Kim]

jpeg pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=60a97c9be30ce429c9609f631c0b24d748c9b3d7

commit 60a97c9be30ce429c9609f631c0b24d748c9b3d7
Author: Minkyoung Kim 
Date:   Tue Apr 11 13:47:55 2017 +0900

evas: If there isn't clipper when recalcing clip, set mask.clip = NULL.

Summary:
There's problem in Tizen3.0.

1. Clip set mask_obj to obj for masking.
2. Unset mask_obj from obj, and del mask_obj.
3. obj has clip.mask still. So obj is trying to do mask_subrender() for 
freeed mask_obj.

So reset clip.mask to NULL, If there isn't clipper.

Now, there's no routine for reseting clip.mask when clipper object is 
freed. isn't it?
Actually I'm not sure that clip.mask=NULL should be there as this patch.

Test Plan: Tizen3.0 wearable

Reviewers: cedric, raster, wonsik, jpeg

Subscribers: scholb.kim, dkdk

Differential Revision: https://phab.enlightenment.org/D4721

Signed-off-by: Jean-Philippe Andre 
---
 src/lib/evas/canvas/evas_object_main.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/lib/evas/canvas/evas_object_main.c 
b/src/lib/evas/canvas/evas_object_main.c
index adae7d5..dcfecfc 100644
--- a/src/lib/evas/canvas/evas_object_main.c
+++ b/src/lib/evas/canvas/evas_object_main.c
@@ -311,6 +311,9 @@ evas_object_clip_recalc_do(Evas_Object_Protected_Data *obj, 
Evas_Object_Protecte
 cb = (cb * (nb + 1)) >> 8;
 ca = (ca * (na + 1)) >> 8;
  }
+   else obj->clip.mask = NULL;
+   if (!EVAS_OBJECT_DATA_VALID(obj->clip.mask))
+ obj->clip.mask = NULL;
 
if (((ca == 0) && (obj->cur->render_op == EVAS_RENDER_BLEND)) ||
(cw <= 0) || (ch <= 0))

--