Re: [E-devel] Server down
On Wed, 26 Jul 2017 08:44:18 +0900 Carsten Haitzler (The Rasterman) said: FYI... it seems our machines have now been up for 4.5 days... seemingly with no troubles and have not been rebooted... so something i did must have had an effect... i want to leave this going for another week or 2 or 3... if you see an issue... PLEASE try and get help in confirming if it's just you or everyone ASAP. it might be routing issues specifically affecting you? or something else? we need to know how/why/where. is the website still running? is it just ssh/git? ... etc. :) but i think things are looking much better. > On Tue, 25 Jul 2017 20:47:04 + Andrew Williams > said: > > > Yeah I got no connection from ssh to the main node > > that smells like a very different problem... because e5 has always been up and > working UNLESS someone is rebooting it at the time and e5 has been up for 3 > days now straight... > > this probably need to be looked into at exactly the time when the issue > happens to compare notes. > > > On Tue, 25 Jul 2017 at 12:32 Carsten Haitzler wrote: > > > > > On Tue, 25 Jul 2017 10:10:32 + Andrew Williams > > > said: > > > > > > > No, connection refused on any attempt to any vm on ssh or http(s)... > > > > > > you tried e5 itself? this is the host ... no vm there. > > > > > > > On Tue, 25 Jul 2017 at 10:41, Carsten Haitzler > > > wrote: > > > > > > > > > On Tue, 25 Jul 2017 08:49:27 + Andrew Williams < > > > a...@andywilliams.me> > > > > > said: > > > > > > > > > > > Maybe there is a routing issue in there too then, as I was > > > struggling to > > > > > > get any connection at all for an hour or three? > > > > > > > > > > could you get to e5? > > > > > > > > > > > Andy > > > > > > On Tue, 25 Jul 2017 at 00:47, Carsten Haitzler > > > > > > > > wrote: > > > > > > > > > > > > > On Mon, 24 Jul 2017 15:25:14 + Andrew Williams < > > > > > a...@andywilliams.me> > > > > > > > said: > > > > > > > > > > > > > > > It seems to be back now without a kick... Is there stuff going > > > on at > > > > > the > > > > > > > > moment? > > > > > > > > > > > > > > i don't know. when i saw your mail i checked. all was up... i > > > > > > > moved > > > > > on. i > > > > > > > have > > > > > > > disabled the logrotate daily crons in e5v1 and www/git ... because > > > > > because > > > > > > > the > > > > > > > going down suspiciously coincided with these. i've disabled > > > auditing in > > > > > > > libvirt > > > > > > > too... i just want to get things working and then figure out which > > > > > level i > > > > > > > pulled did it. maybe one of the levers i pulled di it? e5v1, www, > > > have > > > > > > > been up > > > > > > > over 1 whole day so not one rebooted them. 35 has now been up 2 > > > days > > > > > (last > > > > > > > time > > > > > > > there was an issue i restarted libvirt and its guests only and > > > things > > > > > > > worked > > > > > > > again). > > > > > > > > > > > > > > > On Mon, 24 Jul 2017 at 15:30 Andrew Williams < > > > a...@andywilliams.me> > > > > > > > wrote: > > > > > > > > > > > > > > > > > Today it died between 1 and 2pm UTC... > > > > > > > > > On Sat, 22 Jul 2017 at 16:26, Carsten Haitzler < > > > > > ras...@rasterman.com> > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > >> On Sat, 22 Jul 2017 15:20:48 + Andrew Williams < > > > > > > > a...@andywilliams.me> > > > > > > > > >> said: > > > > > > > > >> > > > > > > > > >> > Thanks to whoever kicked the server just now :) > > > > > > > > >> > > > > > > > > >> me :) > > > > > > > > >> > > > > > > > > >> > Are we any closer to what might be triggering this as soon > > > as > > > > > the > > > > > > > > >> weekend > > > > > > > > >> > starts? ;) > > > > > > > > >> > > > > > > > > >> no. i've experimented with disabling cron.daily things on > > > e5... it > > > > > > > does > > > > > > > > >> seem > > > > > > > > >> that now shutting down vm's and bringing them back up works > > > now > > > > > kvm > > > > > > > is a > > > > > > > > >> module... ? hmmm. > > > > > > > > >> > > > > > > > > >> > Andy > > > > > > > > >> > > > > > > > > > >> > On Wed, 19 Jul 2017 at 18:47 Andrew Williams < > > > > > a...@andywilliams.me> > > > > > > > > >> wrote: > > > > > > > > >> > > > > > > > > > >> > > It looks like the new key did work after all - but in the > > > > > > > confiscation > > > > > > > > >> > > about ensuring no proxies were set up I accidentally > > > deleted > > > > > the > > > > > > > line > > > > > > > > >> of > > > > > > > > >> > > config that sets the username. > > > > > > > > >> > > Either way I can now long in, thanks. > > > > > > > > >> > > Now at least I can kick the server if/when it's not > > > accessible > > > > > > > this > > > > > > > > >> > > weekend. > > > > > > > > >> > > > > > > > > > > >> > > Andy > > > > > > > > >> > > > > > > > > > > >> > > On Tue, 18 Jul 2017 at 17:14 Andrew Williams < > > > > > > > a...@andywilliams.me> > > > > > > > > >> wrote: > > > > > > > > >> > > > > > > > > > > >> >
Re: [E-devel] Rebuilding edj files per efl release
On Thu, 27 Jul 2017 17:13:40 -0400 "William L. Thomson Jr." said: > For the many benefits of EDJE. I think a major downfall is having to > rebuild a theme per every EFL update. Something seems very wrong with > that approach. there is no need to do that. what makes you think you have to rebuild your theme every efl update? if your theme is a direct copy of the default and it has a BUG... (well the default theme has/had a bug)... then your theme also has a bug. if we fix it in the default... you should also copy that. themes don't just define a color or a background. they define interaction and behaviour too. we have tried our best, and i have rejected patches and reverted commits because they were doing in a way that REQUIRED a theme to keep up. i suspect you are missing some key understanding of what edje is and how it works and how we use it for themes. the only case where you MIGHT want to keep up is when we add new theme elements. i.e. a new group. this is often used for a new widget etc. ... and if you do NOT provide it... things still work fine... but elementary will find the group from the default theme instead (it'll fall through to looking there) and it may not look "right". but this is really hard or nigh impossible to avoid. it's like css. you make a page and use classes for divs etc. ... but some new idea/design creates some new div with a class that never existed before. if you define a custom theme and you DON'T provide a css entry for that class that div is probably going to look odd. the "default" css maybe give it a thick top border, with a specific image in the bg with tiling and some specific padding etc. ... so it looks the part. maybe some css transitions specific to its behaviour (some js might initiate the transition on an event). so in this case if you have your html do: http://original.org/default.css rel=stylesheet> this is how themes work. your theme is "mytheme.css". the original.org default one is always implicitly fallen through too... yours overrides. if a web page is using mytheme.css BUt it upgrades its content and uses new widgets from original.org - your mytheme.css wont style these well or maybe not at all... and edje works exactly this way, but it's more "all or nothing". the entire element is provided... or its not. so no. there is no need to rebuild. but if you have new features coming in and new widgets being added and so on then your overlayed mytheme.css (your theme edj file) might want to keep up as over time it'll not be styling new elements. but existing stuff will stay. > If one does not have to per se rebuild an EFL app per EFL release. Why > should one have to rebuild a theme? If an app is using say standard > stuff, that is not likely to change. Then rebuilding an app against > newer would provide little if any benefit or difference. > > Design wise I thought themes were separate from code so seems really > bad that themes must be rebuilt per every EFL release. That adds an > entirely new level of complexity to theming. Which IMHO is already > pretty complex. > > Things I can do easily in say gtk, qt, or others, like changing base > colors of things. Takes considerable time using EDJE. This is not meant > as an insult. But more request for consideration to make some things > easier to modify. we have the features. color classes. we just don't use them a lot in the default theme. we haven't standardized color class names api-wise. only group names, signals and specific part names for swallows, text etc. - it's just a massive amount of work to support because you also have to carefully design your images to wokr with colorclasses (as colors multiple pixel values so your images have to basically become all white with alpha and maybe greyscale and you have to break things up into multiple images layered if each needs to be colored differently and this also then costs overhead at runtime for rendering). look at colorclasses.edc in the default theme where you get to define the colors of "named color classes" (they do indirect to #defines there). all those color classes are changeable per edje object and globally at runtime. as i said - we just haven't formalized this at this point. the features have been there (along with text classes) for 13+ years or so. recently size classes were added too for being able to control sizing a (for padding). > Example > This gtkrc file is all I need to modify gtk theme colors to match my > eminence theme colors. Inheriting another theme > https://github.com/Obsidian-StudiosInc/eminence/blob/master/src/gtkrc-2.0 > > Doing the same with EDJE is very complex. One must rebuild the default > theme and/or make one of their own. Both I have done and am doing > presently with eminence. > > More importantly, I will vary rarely if ever have to touch that gtkrc > file again. I surely will not have to do anything with any theme for a > gtk update. Also has legacy compliance. That gtkrc-2.0 file works for > 3.0 stuff
Re: [E-devel] Rebuilding edj files per efl release
On Thu, Jul 27, 2017 at 2:28 PM, William L. Thomson Jr. wrote: > On Thu, 27 Jul 2017 14:20:09 -0700 > Cedric BAIL wrote: >> On Thu, Jul 27, 2017 at 2:13 PM, William L. Thomson Jr. >> wrote: >> > For the many benefits of EDJE. I think a major downfall is having to >> > rebuild a theme per every EFL update. Something seems very wrong >> > with that approach. >> >> I think there is a missunderstanding here. There shouldn't be any >> breakage in existing theme, but you would not benefit from the new >> feature that a widget provide if it require a change in the theme. > > Also seems per my comments, not directly effected by changes that maybe > unwanted just the same. Like since I have not rebuilt my theme with > 1.20, I think is why I get an error vs it stopping the program as its > trying to and reported in the initial bug report. > https://phab.enlightenment.org/T5720#93048 > > If it did stop after rebuilding with 1.20, that would not be wanted. > Thus it seems like the door swings both ways. :) This is a bug. There is multiple piece that can be the source of the problem. Having no way to reproduce it, I need to rule out it isn't a change in edje_cc that break it. -- 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
[EGIT] [apps/terminology] master 01/01: termpty: fix inserting blank chars. Closes T5802
billiob pushed a commit to branch master.
http://git.enlightenment.org/apps/terminology.git/commit/?id=3a28d9964970122cfe0dd7fc671ce68bb8026911
commit 3a28d9964970122cfe0dd7fc671ce68bb8026911
Author: Boris Faure
Date: Thu Jul 27 23:27:23 2017 +0200
termpty: fix inserting blank chars. Closes T5802
---
src/bin/termptyesc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/bin/termptyesc.c b/src/bin/termptyesc.c
index ee63dfa..7e2370f 100644
--- a/src/bin/termptyesc.c
+++ b/src/bin/termptyesc.c
@@ -1007,7 +1007,7 @@ _handle_esc_csi(Termpty *ty, const Eina_Unicode *c, const
Eina_Unicode *ce)
break;
case '@': // insert N blank chars
arg = _csi_arg_get(&b);
-TERMPTY_RESTRICT_FIELD(ty->cursor_state.cx, 1, ty->w * ty->h);
+TERMPTY_RESTRICT_FIELD(arg, 1, ty->w * ty->h);
DBG("insert %d blank chars", arg);
{
int pi = ty->termstate.insert;
--
Re: [E-devel] Rebuilding edj files per efl release
On Thu, 27 Jul 2017 14:20:09 -0700 Cedric BAIL wrote: > Hello, > > On Thu, Jul 27, 2017 at 2:13 PM, William L. Thomson Jr. > wrote: > > For the many benefits of EDJE. I think a major downfall is having to > > rebuild a theme per every EFL update. Something seems very wrong > > with that approach. > > I think there is a missunderstanding here. There shouldn't be any > breakage in existing theme, but you would not benefit from the new > feature that a widget provide if it require a change in the theme. Also seems per my comments, not directly effected by changes that maybe unwanted just the same. Like since I have not rebuilt my theme with 1.20, I think is why I get an error vs it stopping the program as its trying to and reported in the initial bug report. https://phab.enlightenment.org/T5720#93048 If it did stop after rebuilding with 1.20, that would not be wanted. Thus it seems like the door swings both ways. :) -- William L. Thomson Jr. pgpU_e8u2teuZ.pgp 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] Rebuilding edj files per efl release
Hello, On Thu, Jul 27, 2017 at 2:13 PM, William L. Thomson Jr. wrote: > For the many benefits of EDJE. I think a major downfall is having to > rebuild a theme per every EFL update. Something seems very wrong with > that approach. I think there is a missunderstanding here. There shouldn't be any breakage in existing theme, but you would not benefit from the new feature that a widget provide if it require a change in the theme. 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
[E-devel] Rebuilding edj files per efl release
For the many benefits of EDJE. I think a major downfall is having to rebuild a theme per every EFL update. Something seems very wrong with that approach. If one does not have to per se rebuild an EFL app per EFL release. Why should one have to rebuild a theme? If an app is using say standard stuff, that is not likely to change. Then rebuilding an app against newer would provide little if any benefit or difference. Design wise I thought themes were separate from code so seems really bad that themes must be rebuilt per every EFL release. That adds an entirely new level of complexity to theming. Which IMHO is already pretty complex. Things I can do easily in say gtk, qt, or others, like changing base colors of things. Takes considerable time using EDJE. This is not meant as an insult. But more request for consideration to make some things easier to modify. Example This gtkrc file is all I need to modify gtk theme colors to match my eminence theme colors. Inheriting another theme https://github.com/Obsidian-StudiosInc/eminence/blob/master/src/gtkrc-2.0 Doing the same with EDJE is very complex. One must rebuild the default theme and/or make one of their own. Both I have done and am doing presently with eminence. More importantly, I will vary rarely if ever have to touch that gtkrc file again. I surely will not have to do anything with any theme for a gtk update. Also has legacy compliance. That gtkrc-2.0 file works for 3.0 stuff with no additional modifications. -- William L. Thomson Jr. pgps1haKMYiIr.pgp 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] [core/enlightenment] master 01/01: Fix geometry for drm outputs
derekf pushed a commit to branch master. http://git.enlightenment.org/core/enlightenment.git/commit/?id=fbceceff5a1c0fc5490d1d5c8309a0d4e7b19aa7 commit fbceceff5a1c0fc5490d1d5c8309a0d4e7b19aa7 Author: Derek Foreman Date: Thu Jul 27 15:20:32 2017 -0500 Fix geometry for drm outputs It appears that config.geom.x and config.geom.y specify the corner of an output in global space, but ecore_drm2_output_mode_set's x and y are offsets into the framebuffer for the corner of the display. Just pass 0, 0 and everything will be ok. --- src/modules/wl_drm/e_mod_main.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/modules/wl_drm/e_mod_main.c b/src/modules/wl_drm/e_mod_main.c index 38c02097b..577d4db15 100644 --- a/src/modules/wl_drm/e_mod_main.c +++ b/src/modules/wl_drm/e_mod_main.c @@ -579,8 +579,7 @@ _drm2_randr_apply(void) if (s->config.priority > top_priority) top_priority = s->config.priority; -ecore_drm2_output_mode_set(output, mode, - s->config.geom.x, s->config.geom.y); +ecore_drm2_output_mode_set(output, mode, 0, 0); /* TODO: cannot support rotations until we support planes * and we cannot support planes until Atomic support is in */ --
[EGIT] [apps/ephoto] master 01/01: Ephoto: Remove unneccessary header.
okra pushed a commit to branch master. http://git.enlightenment.org/apps/ephoto.git/commit/?id=b76a54bd3ee93fe9d529e577251a1d5fc6b32d1a commit b76a54bd3ee93fe9d529e577251a1d5fc6b32d1a Author: Stephen 'Okra' Houston Date: Thu Jul 27 12:51:28 2017 -0500 Ephoto: Remove unneccessary header. This fixes compilation and T5761 --- src/bin/ephoto_thumb_browser.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/bin/ephoto_thumb_browser.c b/src/bin/ephoto_thumb_browser.c index bdfab34..f7fb408 100644 --- a/src/bin/ephoto_thumb_browser.c +++ b/src/bin/ephoto_thumb_browser.c @@ -1,5 +1,4 @@ #include "ephoto.h" -#include #define ZOOM_MAX512 #define ZOOM_MIN128 --
Re: [E-devel] Minor issue with new Zoomable widget
Thanks ami, your recent commit indeed fix my issue 2017-07-22 9:28 GMT+02:00 Davide Andreoli : > When the Zoomable widget (photocam in legacy) is used as an external edje > object it spwan this error: > > [ERROR] eo (eo.c: 573) --- in lib/edje/edje_object.eo.c:82: func > 'edje_obj_group_size_max_get' (1041) could not be resolved for class > 'Efl.Ui.Image.Zoomable'. > > Is this solvable? > the python-efl test suite suffer for this issue > > Thanks > -- 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: eo-cxx: Add overload for Eina_Bool inout handling interoperability
felipealmeida pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=634f7d0dbb191dfa6805e1bd1c909e37d6a12a3b
commit 634f7d0dbb191dfa6805e1bd1c909e37d6a12a3b
Author: Felipe Magno de Almeida
Date: Thu Jul 27 13:19:49 2017 -0300
eo-cxx: Add overload for Eina_Bool inout handling interoperability
Add convert_inout_impl overload to handle bool/Eina_Bool conversion in
inout direction.
---
src/bindings/cxx/eo_cxx/eo_cxx_interop.hh | 4
1 file changed, 4 insertions(+)
diff --git a/src/bindings/cxx/eo_cxx/eo_cxx_interop.hh
b/src/bindings/cxx/eo_cxx/eo_cxx_interop.hh
index f8444ddc64..edc68f1f39 100644
--- a/src/bindings/cxx/eo_cxx/eo_cxx_interop.hh
+++ b/src/bindings/cxx/eo_cxx/eo_cxx_interop.hh
@@ -245,6 +245,10 @@ T* convert_inout_impl(T& v, tag)
{
return v;
}
+inline Eina_Bool convert_inout_impl(bool v, tag)
+{
+ return v ? EINA_TRUE : EINA_FALSE;
+}
inline void* convert_inout_impl(void* v, tag)
{
return v;
--
[EGIT] [core/efl] master 02/02: Ecore_Conn: Enable CLOEXEC by default.
stefan pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=45a767632d417043936622f78597c06dc7a8cf94
commit 45a767632d417043936622f78597c06dc7a8cf94
Author: Guilherme Iscaro
Date: Wed Jul 26 18:48:45 2017 -0300
Ecore_Conn: Enable CLOEXEC by default.
This flag should be enabled by default in order to avoid socket leaks.
---
src/bin/efl/efl_debugd.c | 1 -
src/examples/ecore/efl_net_server_example.c| 3 ---
src/examples/ecore/efl_net_server_simple_example.c | 4
src/examples/ecore/efl_net_socket_ssl_server_example.c | 1 -
src/lib/ecore_con/ecore_con_legacy.c | 3 ---
src/lib/ecore_con/efl_net_server_fd.c | 1 +
src/lib/ecore_con/efl_net_server_fd.eo | 2 +-
src/lib/ecore_con/efl_net_server_ssl.eo| 2 +-
src/lib/ecore_ipc/ecore_ipc.c | 2 --
9 files changed, 3 insertions(+), 16 deletions(-)
diff --git a/src/bin/efl/efl_debugd.c b/src/bin/efl/efl_debugd.c
index cfd83e13ae..562bd822be 100644
--- a/src/bin/efl/efl_debugd.c
+++ b/src/bin/efl/efl_debugd.c
@@ -634,7 +634,6 @@ _remote_server_create(void)
{
Eo *inner_server =
efl_net_server_simple_inner_server_get(_remote_server);
- efl_net_server_fd_close_on_exec_set(inner_server, EINA_TRUE);
efl_net_server_fd_reuse_address_set(inner_server, EINA_TRUE);
}
efl_event_callback_add(_remote_server, EFL_NET_SERVER_EVENT_CLIENT_ADD,
_client_add, NULL);
diff --git a/src/examples/ecore/efl_net_server_example.c
b/src/examples/ecore/efl_net_server_example.c
index c3b19ec3fc..277d4c9e1e 100644
--- a/src/examples/ecore/efl_net_server_example.c
+++ b/src/examples/ecore/efl_net_server_example.c
@@ -652,7 +652,6 @@ main(int argc, char **argv)
if (cls == EFL_NET_SERVER_TCP_CLASS)
{
efl_net_server_tcp_ipv6_only_set(server, ipv6_only);
-efl_net_server_fd_close_on_exec_set(server, EINA_TRUE); /* recommended
*/
efl_net_server_fd_reuse_address_set(server, EINA_TRUE); /* optional,
but nice for testing */
efl_net_server_fd_reuse_port_set(server, EINA_TRUE); /* optional, but
nice for testing... not secure unless you know what you're doing */
@@ -672,7 +671,6 @@ main(int argc, char **argv)
efl_net_server_udp_multicast_join(server, str);
-efl_net_server_fd_close_on_exec_set(server, EINA_TRUE); /* recommended
*/
efl_net_server_fd_reuse_address_set(server, EINA_TRUE); /* optional,
but nice for testing */
efl_net_server_fd_reuse_port_set(server, EINA_TRUE); /* optional, but
nice for testing... not secure unless you know what you're doing */
if (socket_activated) efl_net_server_fd_socket_activate(server,
address);
@@ -704,7 +702,6 @@ main(int argc, char **argv)
efl_net_server_ssl_context_set(server, ssl_ctx);
-efl_net_server_ssl_close_on_exec_set(server, EINA_TRUE); /*
recommended */
efl_net_server_ssl_reuse_address_set(server, EINA_TRUE); /* optional,
but nice for testing */
efl_net_server_ssl_reuse_port_set(server, EINA_TRUE); /* optional, but
nice for testing... not secure unless you know what you're doing */
if (socket_activated) efl_net_server_ssl_socket_activate(server,
address);
diff --git a/src/examples/ecore/efl_net_server_simple_example.c
b/src/examples/ecore/efl_net_server_simple_example.c
index ddce4c86cd..6cafe9ddcb 100644
--- a/src/examples/ecore/efl_net_server_simple_example.c
+++ b/src/examples/ecore/efl_net_server_simple_example.c
@@ -460,7 +460,6 @@ main(int argc, char **argv)
if (cls == EFL_NET_SERVER_TCP_CLASS)
{
efl_net_server_tcp_ipv6_only_set(server, ipv6_only);
-efl_net_server_fd_close_on_exec_set(server, EINA_TRUE); /* recommended
*/
efl_net_server_fd_reuse_address_set(server, EINA_TRUE); /* optional,
but nice for testing */
efl_net_server_fd_reuse_port_set(server, EINA_TRUE); /* optional, but
nice for testing... not secure unless you know what you're doing */
@@ -479,8 +478,6 @@ main(int argc, char **argv)
EINA_LIST_FOREACH(udp_mcast_groups, lst, str)
efl_net_server_udp_multicast_join(server, str);
-
-efl_net_server_fd_close_on_exec_set(server, EINA_TRUE); /* recommended
*/
efl_net_server_fd_reuse_address_set(server, EINA_TRUE); /* optional,
but nice for testing */
efl_net_server_fd_reuse_port_set(server, EINA_TRUE); /* optional, but
nice for testing... not secure unless you know what you're doing */
if (socket_activated) efl_net_server_fd_socket_activate(server,
address);
@@ -512,7 +509,6 @@ main(int argc, char **argv)
efl_net_server_ssl_context_set(server, ssl_ctx);
-efl_net_server_ssl_close_on_exec_set(server, EINA_TRUE); /*
recommended */
efl_net_server_ssl_reuse_address_set(server, EINA_TRUE); /* optional,
but nice for testing */
ef
[EGIT] [core/efl] master 01/02: Ecore_IPC: Preserve Ecore_Con legacy behaviour.
stefan pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=97f6803be14212c8b5fb70071e312cf1e51f8fe5
commit 97f6803be14212c8b5fb70071e312cf1e51f8fe5
Author: Guilherme Iscaro
Date: Wed Jul 26 12:11:29 2017 -0300
Ecore_IPC: Preserve Ecore_Con legacy behaviour.
This patch sets some Ecore_Con flags that were missing after
the EO migration. These flags must be set in order
maintain the Ecore_IPC behaviour before Ecore_Con EO was implemented.
Fixes T5722
---
src/lib/ecore_ipc/ecore_ipc.c | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/src/lib/ecore_ipc/ecore_ipc.c b/src/lib/ecore_ipc/ecore_ipc.c
index e9973f30a7..8cb7f3f7e8 100644
--- a/src/lib/ecore_ipc/ecore_ipc.c
+++ b/src/lib/ecore_ipc/ecore_ipc.c
@@ -386,6 +386,7 @@ ecore_ipc_server_add(Ecore_Ipc_Type type, const char *name,
int port, const void
char *address = NULL;
Eina_Error err;
#ifdef EFL_NET_SERVER_UNIX_CLASS
+ Eina_Bool local_system = EINA_FALSE;
mode_t old_mask = 0, new_mask = 0;
#endif
@@ -415,6 +416,7 @@ ecore_ipc_server_add(Ecore_Ipc_Type type, const char *name,
int port, const void
/* ecore_con didn't create leading directories for LOCAL_SYSTEM */
new_mask = 0;
+local_system = EINA_TRUE;
svr->server = efl_add(EFL_NET_SERVER_UNIX_CLASS,
ecore_main_loop_get());
EINA_SAFETY_ON_NULL_GOTO(svr->server, error_server);
@@ -477,9 +479,36 @@ ecore_ipc_server_add(Ecore_Ipc_Type type, const char
*name, int port, const void
efl_event_callback_array_add(svr->server, _ecore_ipc_server_cbs(), svr);
+ if (efl_isa(svr->server, EFL_NET_SERVER_FD_CLASS))
+ {
+efl_net_server_fd_close_on_exec_set(svr->server, EINA_TRUE);
+efl_net_server_fd_reuse_address_set(svr->server, EINA_TRUE);
+efl_net_server_fd_reuse_port_set(svr->server, EINA_TRUE);
+ }
+
+ if (efl_isa(svr->server, EFL_NET_SERVER_TCP_CLASS))
+ {
+/* old ecore_con did not map ipv4 to ipv6... */
+efl_net_server_tcp_ipv6_only_set(svr->server, EINA_TRUE);
+ }
+ else if (efl_isa(svr->server, EFL_NET_SERVER_SSL_CLASS))
+ {
+/* old ecore_con did not map ipv4 to ipv6... */
+efl_net_server_ssl_ipv6_only_set(svr->server, EINA_TRUE);
+efl_net_server_ssl_close_on_exec_set(svr->server, EINA_TRUE);
+efl_net_server_ssl_reuse_address_set(svr->server, EINA_TRUE);
+efl_net_server_ssl_reuse_port_set(svr->server, EINA_TRUE);
+ }
+
#ifdef EFL_NET_SERVER_UNIX_CLASS
if (efl_isa(svr->server, EFL_NET_SERVER_UNIX_CLASS))
- old_mask = umask(new_mask);
+ {
+old_mask = umask(new_mask);
+efl_net_server_unix_unlink_before_bind_set(svr->server, EINA_TRUE);
+efl_net_server_unix_leading_directories_create_set(svr->server,
+ EINA_TRUE,
+ local_system ? 0755
: 0700);
+ }
#endif
err = efl_net_server_serve(svr->server, address);
--
Re: [E-devel] Git and branching
On 07/27/2017 09:28 AM, Simon Lees wrote: Then you were likely told the wrong thing, every bugfix should go into enlightenment-0.XX, it that doesn't happen let us know and we will make sure it does. You are right, I am wrong, I does not find what I thought to be a counter exemple. Sorry for the noise. -- 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] Work items towards 1.20
Hello. Updated list below from what I see today. Phab show stopper: -- ecore_ipc_server_add can't create CLOEXEC sockets, E leaks the sockets to all child processes https://phab.enlightenment.org/T5722 -> It has an initial patch and we should be on track. edje programs don't stop after state set (regression) https://phab.enlightenment.org/T5720 -> Not being able to reproduce yet, keep trying. Can't change selection or move I-beam cursor in textboxes https://phab.enlightenment.org/T5451 -> Not being able to reproduce yet, keep trying. Are there any other issues that need to be promoted to a showstopper? Coverity high impact: - 1374646 Resource leak /src/modules/evas/engines/gl_...vas_ector_gl_image_buffer.c 1374645 Resource leak /src/modules/evas/engines/gl_generic/evas_ector_gl_buffer.c ABI/API report: --- https://abi-laboratory.pro/tracker/timeline/efl/index.html o The remaining one from beta3 (evas_textblock_cursor_equal) got fixed directly after. o Nothing else pending from this side. 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
[EGIT] [core/enlightenment] master 01/01: build - remove policy mobile module
raster pushed a commit to branch master.
http://git.enlightenment.org/core/enlightenment.git/commit/?id=3932a069f7f17f92bdfd93a3bd2a35d4b400d14f
commit 3932a069f7f17f92bdfd93a3bd2a35d4b400d14f
Author: Carsten Haitzler (Rasterman)
Date: Thu Jul 27 20:23:59 2017 +0900
build - remove policy mobile module
this module is not loaded by any other (dependency) nor is it loadable
via the gui - no module/desktop there thus will be hidden... so it's
useless/unused... thus remove it as its not usable by users.
---
configure.ac | 1 -
meson.build | 1 -
meson_options.txt | 4 -
src/modules/Makefile.mk | 2 -
src/modules/Makefile_policy_mobile.mk | 19 -
src/modules/policy_mobile/e_mod_config.c | 375 --
src/modules/policy_mobile/e_mod_main.c| 639 --
src/modules/policy_mobile/e_mod_main.h| 107 -
src/modules/policy_mobile/e_mod_softkey.c | 171
src/modules/policy_mobile/meson.build | 22 -
10 files changed, 1341 deletions(-)
diff --git a/configure.ac b/configure.ac
index 79f88de3c..776e0795a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -886,7 +886,6 @@ AC_E_OPTIONAL_MODULE([wl_buffer], $have_wayland_dep)
AC_E_OPTIONAL_MODULE([wl_drm], $have_wayland_dep, [CHECK_MODULE_WL_DRM])
AC_E_OPTIONAL_MODULE([wl_text_input], $have_wayland_dep)
AC_E_OPTIONAL_MODULE([wl_weekeyboard], $have_wayland_dep)
-AC_E_OPTIONAL_MODULE([policy_mobile], true)
AC_E_OPTIONAL_MODULE([geolocation], true)
AC_E_OPTIONAL_MODULE([xwayland], $have_wayland_dep, [CHECK_MODULE_XWAYLAND])
AC_E_OPTIONAL_MODULE([wireless], true)
diff --git a/meson.build b/meson.build
index 8a14c6045..ca398a48a 100644
--- a/meson.build
+++ b/meson.build
@@ -462,7 +462,6 @@ subdir('src/modules/wl_buffer')
subdir('src/modules/wl_drm')
subdir('src/modules/wl_text_input')
subdir('src/modules/wl_weekeyboard')
-subdir('src/modules/policy_mobile')
subdir('src/modules/geolocation')
subdir('src/modules/xwayland')
subdir('src/modules/wireless')
diff --git a/meson_options.txt b/meson_options.txt
index 78d7dd66b..7b830873b 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -185,10 +185,6 @@ option('quickaccess',
type: 'boolean',
default: true,
description: 'enable quickaccess module: (default=true)')
-option('policy-mobile',
- type: 'boolean',
- default: true,
- description: 'enable policy-mobile module: (default=true)')
option('start',
type: 'boolean',
default: true,
diff --git a/src/modules/Makefile.mk b/src/modules/Makefile.mk
index 4bc293ace..e7f1eead5 100644
--- a/src/modules/Makefile.mk
+++ b/src/modules/Makefile.mk
@@ -128,8 +128,6 @@ include src/modules/Makefile_wl_text_input.mk
include src/modules/Makefile_wl_weekeyboard.mk
-include src/modules/Makefile_policy_mobile.mk
-
include src/modules/Makefile_geolocation.mk
include src/modules/Makefile_sysinfo.mk
diff --git a/src/modules/Makefile_policy_mobile.mk
b/src/modules/Makefile_policy_mobile.mk
deleted file mode 100644
index c0a61965f..0
--- a/src/modules/Makefile_policy_mobile.mk
+++ /dev/null
@@ -1,19 +0,0 @@
-if USE_MODULE_POLICY_MOBILE
-policy_mobiledir = $(MDIR)/policy_mobile
-
-policy_mobilepkgdir = $(MDIR)/policy_mobile/$(MODULE_ARCH)
-policy_mobilepkg_LTLIBRARIES = src/modules/policy_mobile/module.la
-
-src_modules_policy_mobile_module_la_LIBADD = $(MOD_LIBS)
-src_modules_policy_mobile_module_la_CPPFLAGS = $(MOD_CPPFLAGS)
-src_modules_policy_mobile_module_la_LDFLAGS = $(MOD_LDFLAGS)
-src_modules_policy_mobile_module_la_SOURCES = \
-src/modules/policy_mobile/e_mod_main.h \
-src/modules/policy_mobile/e_mod_config.c \
-src/modules/policy_mobile/e_mod_softkey.c \
-src/modules/policy_mobile/e_mod_main.c
-
-PHONIES += policy_mobile install-policy_mobile
-policy_mobile: $(policy_mobilepkg_LTLIBRARIES) $(policy_mobile_DATA)
-install-policy_mobile: install-policy_mobileDATA
install-policy_mobilepkgLTLIBRARIES
-endif
diff --git a/src/modules/policy_mobile/e_mod_config.c
b/src/modules/policy_mobile/e_mod_config.c
deleted file mode 100644
index e9f6aef49..0
--- a/src/modules/policy_mobile/e_mod_config.c
+++ /dev/null
@@ -1,375 +0,0 @@
-#include "e_mod_main.h"
-
-static void _pol_conf_desk_add(Config *conf, E_Desk *desk);
-static void _pol_conf_desk_del(Config *conf, Config_Desk *d);
-static Config_Desk *_pol_conf_desk_get(Config *conf, Config_Desk *d);
-
-static void*_pol_cfd_data_create(E_Config_Dialog *cfd);
-static void _pol_cfd_data_free(E_Config_Dialog *cfd EINA_UNUSED,
E_Config_Dialog_Data *cfdata);
-static int _pol_cfd_data_basic_apply(E_Config_Dialog *cfd
EINA_UNUSED, E_Config_Dialog_Data *cfdata);
-static void _pol_cfd_desk_list_update(E_Config_Dialog_Data *cfdata,
E_Zone *zone);
-static void _pol_cfd_hook_zone_change(void *data, Evas_Object *obj);
-s
[EGIT] [core/efl] master 01/01: efl.ui.image.zoomable: Add missing edje.group_size_min/max_get
ami pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=0787b739cddd1df0bc33312d0f048e308e509373
commit 0787b739cddd1df0bc33312d0f048e308e509373
Author: Amitesh Singh
Date: Thu Jul 27 19:03:51 2017 +0900
efl.ui.image.zoomable: Add missing edje.group_size_min/max_get
This supresses the warnings when photocam is used as
an external edje object.
---
src/lib/elementary/efl_ui_image_zoomable.c | 18 ++
src/lib/elementary/efl_ui_image_zoomable.eo | 2 ++
2 files changed, 20 insertions(+)
diff --git a/src/lib/elementary/efl_ui_image_zoomable.c
b/src/lib/elementary/efl_ui_image_zoomable.c
index 21a27e779e..6bc07a9a90 100644
--- a/src/lib/elementary/efl_ui_image_zoomable.c
+++ b/src/lib/elementary/efl_ui_image_zoomable.c
@@ -1570,6 +1570,24 @@ _efl_ui_image_zoomable_efl_image_image_size_get(Eo *obj
EINA_UNUSED, Efl_Ui_Imag
if (h) *h = pd->size.imh;
}
+EOLIAN static void
+_efl_ui_image_zoomable_edje_object_group_size_min_get(Eo *obj EINA_UNUSED,
Efl_Ui_Image_Zoomable_Data *sd, int *w, int *h)
+{
+ if (sd->edje)
+ edje_object_size_min_get(sd->edje, w, h);
+ else
+ efl_gfx_size_hint_combined_min_get(sd->img, w, h);
+}
+
+EOLIAN static void
+_efl_ui_image_zoomable_edje_object_group_size_max_get(Eo *obj EINA_UNUSED,
Efl_Ui_Image_Zoomable_Data *sd, int *w, int *h)
+{
+ if (sd->edje)
+ edje_object_size_max_get(sd->edje, w, h);
+ else
+ evas_object_size_hint_max_get(sd->img, w, h);
+}
+
static Eina_Bool
_img_proxy_set(Evas_Object *obj, Efl_Ui_Image_Zoomable_Data *sd,
const char *file, const Eina_File *f, const char *group,
diff --git a/src/lib/elementary/efl_ui_image_zoomable.eo
b/src/lib/elementary/efl_ui_image_zoomable.eo
index dc16c10a58..8eecca7dac 100644
--- a/src/lib/elementary/efl_ui_image_zoomable.eo
+++ b/src/lib/elementary/efl_ui_image_zoomable.eo
@@ -68,6 +68,8 @@ class Efl.Ui.Image.Zoomable (Elm.Widget, Efl.Ui.Image,
Efl.Ui.Zoom,
Efl.File.file { get; set; }
Efl.Orientation.orientation { get; set; }
Efl.Flipable.flip { get; set; }
+ Edje.Object.group_size_min { get; }
+ Edje.Object.group_size_max { get; }
}
events {
press; [[Called when photocam got pressed]]
--
[EGIT] [core/enlightenment] master 01/01: meson generic module build - dashify the option string
raster pushed a commit to branch master.
http://git.enlightenment.org/core/enlightenment.git/commit/?id=669604d1cd7e49982dfdd859c8a2926b1a286588
commit 669604d1cd7e49982dfdd859c8a2926b1a286588
Author: Carsten Haitzler (Rasterman)
Date: Thu Jul 27 18:37:56 2017 +0900
meson generic module build - dashify the option string
thanks marcel for the split.
---
src/modules/meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/modules/meson.build b/src/modules/meson.build
index 118d0d9a2..853e8cb96 100644
--- a/src/modules/meson.build
+++ b/src/modules/meson.build
@@ -7,7 +7,7 @@ foreach m: mods
subdir(m)
_module = m
- _opt= m
+ _opt= '-'.join(m.split('_'))
_conf = 'USE_MODULE_' + m.to_upper()
_src = [ ]
foreach s: src
--
[EGIT] [core/enlightenment] master 01/01: meson build generics - ooops. missed files. add now
raster pushed a commit to branch master.
http://git.enlightenment.org/core/enlightenment.git/commit/?id=ce3b72e371b67e4674cac843d4434b20cafbf206
commit ce3b72e371b67e4674cac843d4434b20cafbf206
Author: Carsten Haitzler (Rasterman)
Date: Thu Jul 27 18:32:43 2017 +0900
meson build generics - ooops. missed files. add now
---
meson.build | 2 ++
src/modules/meson.build | 37 +
2 files changed, 39 insertions(+)
diff --git a/meson.build b/meson.build
index 85b84baf9..8a14c6045 100644
--- a/meson.build
+++ b/meson.build
@@ -404,8 +404,10 @@ module_includes2 = [ '../..', '../bin', '../bin/efx' ]
module_deps = [deps_e, dep_dl]
subdir('src/modules')
+ the below now use the gneric build above
#subdir('src/modules/ibar')
#subdir('src/modules/clock')
+
subdir('src/modules/pager')
subdir('src/modules/pager_plain')
subdir('src/modules/battery')
diff --git a/src/modules/meson.build b/src/modules/meson.build
new file mode 100644
index 0..118d0d9a2
--- /dev/null
+++ b/src/modules/meson.build
@@ -0,0 +1,37 @@
+mods = [
+ 'clock',
+ 'ibar'
+]
+
+foreach m: mods
+ subdir(m)
+
+ _module = m
+ _opt= m
+ _conf = 'USE_MODULE_' + m.to_upper()
+ _src = [ ]
+ foreach s: src
+_src += [ join_paths(m, s) ]
+ endforeach
+ _icon = [
+join_paths(m, 'e-module-' + _module + '.edj'),
+join_paths(m, 'module.desktop')
+ ]
+ _dir = join_paths(dir_module_e, _module)
+ _dir_bin = join_paths(_dir, module_arch)
+
+ if get_option(_opt) == true
+config_h.set(_conf, '1')
+module_files += join_paths(_dir_bin, _module + '.so')
+install_data(_icon, install_dir: _dir)
+_inc = include_directories(module_includes2,
+ join_paths('.', m))
+shared_module(_module, _src,
+ include_directories: _inc,
+ name_prefix: '',
+ dependencies : module_deps,
+ install_dir: _dir_bin,
+ install: true
+ )
+ endif
+endforeach
--
[EGIT] [core/enlightenment] master 02/02: e module build - make ibar and clock really simple and generic
raster pushed a commit to branch master.
http://git.enlightenment.org/core/enlightenment.git/commit/?id=822a0bcacbce6e960a4456405108723ec448eb60
commit 822a0bcacbce6e960a4456405108723ec448eb60
Author: Carsten Haitzler (Rasterman)
Date: Thu Jul 27 18:30:11 2017 +0900
e module build - make ibar and clock really simple and generic
now their build fiels are super easy to maintan. we should expand this
kind of ptterning aross the e build and then expand it to handle new
patters where needed like custom binaries (setuid or not), etc etc.
---
meson.build | 6 --
src/modules/clock/meson.build | 27 ---
src/modules/ibar/meson.build | 27 ---
3 files changed, 4 insertions(+), 56 deletions(-)
diff --git a/meson.build b/meson.build
index 6c6c0fe95..85b84baf9 100644
--- a/meson.build
+++ b/meson.build
@@ -400,10 +400,12 @@ subdir('src/bin')
module_files = []
module_ldflags = '-module -avoid-version'
module_includes = ['../../..', '../../bin', '../../bin/efx']
+module_includes2 = [ '../..', '../bin', '../bin/efx' ]
module_deps = [deps_e, dep_dl]
-subdir('src/modules/ibar')
-subdir('src/modules/clock')
+subdir('src/modules')
+#subdir('src/modules/ibar')
+#subdir('src/modules/clock')
subdir('src/modules/pager')
subdir('src/modules/pager_plain')
subdir('src/modules/battery')
diff --git a/src/modules/clock/meson.build b/src/modules/clock/meson.build
index 7d475d491..9d426f36f 100644
--- a/src/modules/clock/meson.build
+++ b/src/modules/clock/meson.build
@@ -1,32 +1,5 @@
-module = 'clock'
-opt= 'clock'
-conf = 'USE_MODULE_CLOCK'
-
src = [
'e_mod_main.c',
'e_mod_config.c',
'e_mod_main.h'
]
-
-icon = [
- 'e-module-' + module + '.edj',
- 'module.desktop'
-]
-
-dir_mod = join_paths(dir_module_e, module)
-dir_mod_bin = join_paths(dir_mod, module_arch)
-
-if get_option(opt) == true
- config_h.set(conf, '1')
- module_files += join_paths(dir_mod_bin, module + '.so')
-
- install_data(icon, install_dir: dir_mod)
-
- shared_module(module, src,
-include_directories: include_directories(module_includes),
-name_prefix: '',
-dependencies : module_deps,
-install_dir: dir_mod_bin,
-install: true
- )
-endif
diff --git a/src/modules/ibar/meson.build b/src/modules/ibar/meson.build
index eac5d8942..9d426f36f 100644
--- a/src/modules/ibar/meson.build
+++ b/src/modules/ibar/meson.build
@@ -1,32 +1,5 @@
-module = 'ibar'
-opt= 'ibar'
-conf = 'USE_MODULE_IBAR'
-
src = [
'e_mod_main.c',
'e_mod_config.c',
'e_mod_main.h'
]
-
-icon = [
- 'e-module-' + module + '.edj',
- 'module.desktop'
-]
-
-dir_mod = join_paths(dir_module_e, module)
-dir_mod_bin = join_paths(dir_mod, module_arch)
-
-if get_option(opt) == true
- config_h.set(conf, '1')
- module_files += join_paths(dir_mod_bin, module + '.so')
-
- install_data(icon, install_dir: dir_mod)
-
- shared_module(module, src,
-include_directories: include_directories(module_includes),
-name_prefix: '',
-dependencies : module_deps,
-install_dir: dir_mod_bin,
-install: true
- )
-endif
--
[EGIT] [core/enlightenment] master 01/02: meson - clock and ibar - use same template as most modules now
raster pushed a commit to branch master.
http://git.enlightenment.org/core/enlightenment.git/commit/?id=f6d9eeb99a55e5dcfd3a943fcea9dfafaa993d1b
commit f6d9eeb99a55e5dcfd3a943fcea9dfafaa993d1b
Author: Carsten Haitzler (Rasterman)
Date: Thu Jul 27 17:50:37 2017 +0900
meson - clock and ibar - use same template as most modules now
---
src/modules/clock/meson.build | 45 ++
src/modules/ibar/meson.build | 46 ++-
2 files changed, 48 insertions(+), 43 deletions(-)
diff --git a/src/modules/clock/meson.build b/src/modules/clock/meson.build
index 8fc730244..7d475d491 100644
--- a/src/modules/clock/meson.build
+++ b/src/modules/clock/meson.build
@@ -1,29 +1,32 @@
-clock_dist = [
- 'e-module-clock.edj',
- 'module.desktop',
+module = 'clock'
+opt= 'clock'
+conf = 'USE_MODULE_CLOCK'
+
+src = [
+ 'e_mod_main.c',
+ 'e_mod_config.c',
+ 'e_mod_main.h'
]
-clock_src = [
- 'e_mod_config.c',
- 'e_mod_main.c'
+icon = [
+ 'e-module-' + module + '.edj',
+ 'module.desktop'
]
-clock_dir = join_paths(dir_module_e, 'clock', module_arch)
-if get_option('clock') == true
- config_h.set('USE_MODULE_CLOCK', '1')
+dir_mod = join_paths(dir_module_e, module)
+dir_mod_bin = join_paths(dir_mod, module_arch)
+
+if get_option(opt) == true
+ config_h.set(conf, '1')
+ module_files += join_paths(dir_mod_bin, module + '.so')
- install_data(clock_dist,
- install_dir: join_paths(dir_module_e, 'clock')
- )
+ install_data(icon, install_dir: dir_mod)
-module_files += join_paths(clock_dir, 'clock.so')
- shared_module('clock',
-clock_src,
+ shared_module(module, src,
include_directories: include_directories(module_includes),
-name_prefix: '',
-dependencies: module_deps,
-install_dir: clock_dir,
-install: true
-)
+name_prefix: '',
+dependencies : module_deps,
+install_dir: dir_mod_bin,
+install: true
+ )
endif
-
diff --git a/src/modules/ibar/meson.build b/src/modules/ibar/meson.build
index f5bffbffe..eac5d8942 100644
--- a/src/modules/ibar/meson.build
+++ b/src/modules/ibar/meson.build
@@ -1,30 +1,32 @@
-ibar_dist = [
- 'e-module-ibar.edj',
- 'module.desktop',
+module = 'ibar'
+opt= 'ibar'
+conf = 'USE_MODULE_IBAR'
+
+src = [
+ 'e_mod_main.c',
+ 'e_mod_config.c',
+ 'e_mod_main.h'
]
-ibar_src = [
- 'e_mod_config.c',
- 'e_mod_main.c',
- 'e_mod_main.h',
+icon = [
+ 'e-module-' + module + '.edj',
+ 'module.desktop'
]
-ibar_dir = join_paths(dir_module_e, 'ibar', module_arch)
-if get_option('ibar') == true
- config_h.set('USE_MODULE_IBAR', '1')
+dir_mod = join_paths(dir_module_e, module)
+dir_mod_bin = join_paths(dir_mod, module_arch)
+
+if get_option(opt) == true
+ config_h.set(conf, '1')
+ module_files += join_paths(dir_mod_bin, module + '.so')
- install_data(ibar_dist,
- install_dir: join_paths(dir_module_e, 'ibar')
- )
+ install_data(icon, install_dir: dir_mod)
-module_files += join_paths(ibar_dir, 'ibar.so')
- shared_module('ibar',
-ibar_src,
+ shared_module(module, src,
include_directories: include_directories(module_includes),
-name_prefix: '',
-dependencies: module_deps,
-install_dir: ibar_dir,
-install: true
-)
+name_prefix: '',
+dependencies : module_deps,
+install_dir: dir_mod_bin,
+install: true
+ )
endif
-
--
Re: [E-devel] Git and branching
On 27/07/17 18:14, Stefan Schmidt wrote: > Hello. > > On 07/27/2017 10:18 AM, Simon Lees wrote: >> >> >> On 27/07/17 17:33, Stefan Schmidt wrote: >>> Hello. >>> >>> On 07/22/2017 11:22 PM, Andrew Williams wrote: Hi eflers :) So after thinking about issue management and planning milestones I thought more about our source control. We currently have various different models used but the bottom line is that it all hits master all the time which can lead to less stability than ideal and also makes stabilisation windows critical to enforce. As a suggestion I think we should consider agreeing on a singlet branching model and I'd recommend GitFlow (described quite well here https://www.atlassian.com/git/tutorials/comparing-workflows#gitflow-workflow). As well as being well organised there is a solid gitflow plugin that helps to manage branches and workflows. >>> >>> I read the tutorial now. It is the first time I ever encountered this >>> workflow. Do you know any bigger FOSS projects that use this? The ones >>> I'm familiar with do not (not even EDI, which is unstable on master from >>> time to time. ;)) >>> >> Qt uses this workflow or atleast was last time I was paying attention to >> there development. I'm also in the group thinking this development model >> is better then our current one (but not enough to passionately argue >> for it) > > Hmm, my understanding was that Qt had a master branch which was only > getting commits coming through a CI system after review and testing > passed. Having all actual development work in feature branches without > any shared develop branch. But I got that impression many years back > from a presentation Thiago did. > > You surely do know more about the Qt devel workflow than I do. I will > try to have a look what they do over the next days. to understand better > how it fits with a active FOSS project. Thanks for the tip. > > regards > Stefan Schmidt > As of 2 - 3 years back it was something along the lines of bugfix-x.x(one per version) / stable / development. Anything that was a bugfix ie suitable to go into a point release (1.19.2) would go directly to the bugfix branch while development for the next stable release (1.20) was in the "stable" branch, periodically the "bugfix" branch gets merged back into the "stable" branch so bugfixes go there as well. "Development" contains any new features not going into 1.20, periodically "stable" gets merged back into "development" so that the diff doesn't grow too big. When 1.20 is released the "bugfix-1.20" branch is created from "stable" (similar to what we have now except all bugfixes go into that branch first). The "development" branch is then merged into "stable". Before 1.21 is "frozen" new features that people think will land in 1.21 can be submitted direct to stable if the freeze has started or the feature wont be ready they can go into the "development" branch, obviously as we get closer to release more will go in "development" rather then "stable" They obviously have more contributors though. -- 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] Git and branching
Hello. On 07/27/2017 10:18 AM, Simon Lees wrote: On 27/07/17 17:33, Stefan Schmidt wrote: Hello. On 07/22/2017 11:22 PM, Andrew Williams wrote: Hi eflers :) So after thinking about issue management and planning milestones I thought more about our source control. We currently have various different models used but the bottom line is that it all hits master all the time which can lead to less stability than ideal and also makes stabilisation windows critical to enforce. As a suggestion I think we should consider agreeing on a singlet branching model and I'd recommend GitFlow (described quite well here https://www.atlassian.com/git/tutorials/comparing-workflows#gitflow-workflow). As well as being well organised there is a solid gitflow plugin that helps to manage branches and workflows. I read the tutorial now. It is the first time I ever encountered this workflow. Do you know any bigger FOSS projects that use this? The ones I'm familiar with do not (not even EDI, which is unstable on master from time to time. ;)) Qt uses this workflow or atleast was last time I was paying attention to there development. I'm also in the group thinking this development model is better then our current one (but not enough to passionately argue for it) Hmm, my understanding was that Qt had a master branch which was only getting commits coming through a CI system after review and testing passed. Having all actual development work in feature branches without any shared develop branch. But I got that impression many years back from a presentation Thiago did. You surely do know more about the Qt devel workflow than I do. I will try to have a look what they do over the next days. to understand better how it fits with a active FOSS project. Thanks for the tip. 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] Git and branching
Hello. On 07/27/2017 10:20 AM, Simon Lees wrote: On 27/07/17 17:37, Stefan Schmidt wrote: Hello. On 07/27/2017 12:49 AM, Andrew Williams wrote: Hi Mike, One of the strengths of GitFlow is that all release branches merge back fully so you can't miss fixes. We apply fixes to master first and then backport. No chance to miss them in master. Unfortunately it does mean we occasionally miss backporting features. I would not say we miss them but we intentional leave them out. :) 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] Git and branching
Hello. On 07/27/2017 12:36 AM, Andrew Williams wrote: Whilst I can't argue with the simplicity of our branching model I don't know that I completely agree that stopping for a month every release is indicative of a good process... Who is really stopping his work? If you look at the sheer amount of commits coming in from merged branches within the first week after the development open again I do not believe that this all was coded up in that one week. People develop in branches and merge them in. Coming back to the choice of shutting down master to force people working on stabilization. My guts tell me it helps. Can I be sure? Can I measure my guts feeling? No, surely not. :) 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] Git and branching
Hello. On 07/27/2017 12:44 AM, Andrew Williams wrote: Hi, An interesting point. I guess I figure there is something between massive merges and the alternative of breaking master. Isn't it fair to say that we shouldn't ever be breaking master even if we're doing cool new stuff? (yes, I know I have done it too, it's the way things are just now). And I do not see how a changed workflow would change this behavior. I have been asking people for ages to run make check before they push. No happening as I can clearly see when running it myself. You think this will now longer be the case for the develop branch? I would think it will be. Which means that someone has to test things and poke people to have it fixed up before develop gets merged into master. Who will handle that part? The developer who already did not run make check or did disable some configure options which did hide some problems from him (disabled cxx bindings on developers side is a big source of frustration for me when simply trying to have our normal all, check and examples targets build) I simply fail to see how the new develop buffer branch would fix all these problems. It would hide them in through one more level of abstraction, is my feeling. 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] Git and branching
On 27/07/17 17:37, Stefan Schmidt wrote: > Hello. > > On 07/27/2017 12:49 AM, Andrew Williams wrote: >> Hi Mike, >> >> One of the strengths of GitFlow is that all release branches merge back >> fully so you can't miss fixes. > > We apply fixes to master first and then backport. No chance to miss them > in master. > Unfortunately it does mean we occasionally miss backporting features. With the model suggested its still not really possible to miss fixes because the whole branch of fixes gets merged back in as often as you want. -- 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] Git and branching
On 27/07/17 17:33, Stefan Schmidt wrote: > Hello. > > On 07/22/2017 11:22 PM, Andrew Williams wrote: >> Hi eflers :) >> >> So after thinking about issue management and planning milestones I >> thought >> more about our source control. We currently have various different models >> used but the bottom line is that it all hits master all the time which >> can >> lead to less stability than ideal and also makes stabilisation windows >> critical to enforce. >> >> As a suggestion I think we should consider agreeing on a singlet >> branching >> model and I'd recommend GitFlow (described quite well here >> https://www.atlassian.com/git/tutorials/comparing-workflows#gitflow-workflow). >> >> As well as being well organised there is a solid gitflow plugin that >> helps >> to manage branches and workflows. > > I read the tutorial now. It is the first time I ever encountered this > workflow. Do you know any bigger FOSS projects that use this? The ones > I'm familiar with do not (not even EDI, which is unstable on master from > time to time. ;)) > Qt uses this workflow or atleast was last time I was paying attention to there development. I'm also in the group thinking this development model is better then our current one (but not enough to passionately argue for it) -- 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] Git and branching
Hello. On 07/27/2017 12:49 AM, Andrew Williams wrote: Hi Mike, One of the strengths of GitFlow is that all release branches merge back fully so you can't miss fixes. We apply fixes to master first and then backport. No chance to miss them in master. Additionally all releases are tagged on master so there is a clear record of where all releases were cut from. We do the same for all major releases. Your concern is that the stable update tags and not from master but a stable branch? Hot fixes such as we currently back port are created in a place to be immediately applied to both master and develop such that the next release, whichever it is, will certainly get the fix. These seem like improvements over the "dangling" release branch model that we've used before. About the hotfix branch needs to get merged into master as well as develop I wrote in my other mail. Why would that be easier? 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
[EGIT] [core/efl] master 01/01: evas: Always call show/hide intercept
jpeg pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=936ea58cb9ac3e93aaabb6ec731fc3845cf95826
commit 936ea58cb9ac3e93aaabb6ec731fc3845cf95826
Author: Jean-Philippe Andre
Date: Thu Jul 27 15:45:37 2017 +0900
evas: Always call show/hide intercept
Ref T5370
---
src/lib/evas/canvas/evas_object_intercept.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/src/lib/evas/canvas/evas_object_intercept.c
b/src/lib/evas/canvas/evas_object_intercept.c
index e627daab97..9ce9d0b5a2 100644
--- a/src/lib/evas/canvas/evas_object_intercept.c
+++ b/src/lib/evas/canvas/evas_object_intercept.c
@@ -100,10 +100,13 @@ _evas_object_intercept_call_internal(Evas_Object *eo_obj,
{
case EVAS_OBJECT_INTERCEPT_CB_VISIBLE:
i = !!va_arg(args, int);
-if (i == obj->cur->visible) return 1;
-if (!obj->interceptors) return 0;
-if (i) blocked = evas_object_intercept_call_show(eo_obj, obj);
-else blocked = evas_object_intercept_call_hide(eo_obj, obj);
+if (obj->interceptors)
+ {
+ if (i) blocked = evas_object_intercept_call_show(eo_obj, obj);
+ else blocked = evas_object_intercept_call_hide(eo_obj, obj);
+ }
+if (!blocked && (i == obj->cur->visible))
+ blocked = 1;
break;
case EVAS_OBJECT_INTERCEPT_CB_MOVE:
--
Re: [E-devel] Git and branching
Hello. On 07/22/2017 11:22 PM, Andrew Williams wrote: Hi eflers :) So after thinking about issue management and planning milestones I thought more about our source control. We currently have various different models used but the bottom line is that it all hits master all the time which can lead to less stability than ideal and also makes stabilisation windows critical to enforce. As a suggestion I think we should consider agreeing on a singlet branching model and I'd recommend GitFlow (described quite well here https://www.atlassian.com/git/tutorials/comparing-workflows#gitflow-workflow). As well as being well organised there is a solid gitflow plugin that helps to manage branches and workflows. I read the tutorial now. It is the first time I ever encountered this workflow. Do you know any bigger FOSS projects that use this? The ones I'm familiar with do not (not even EDI, which is unstable on master from time to time. ;)) Bottom line: main development moves from "master" to "develop" and master then remains the most recent release (always stable ;) ). Releases then are created on a branch rather than being branched after release. If we are going to add more process overhead it need to yield a significant improvement somewhere. Best would be a significant measurable improvement (e.g. the work on meson in different project is really driven by the potential speed improvement it can bring to the development). I have a hard time seeing this big improvement coming from an additional buffer branch (develop) before things hit master. How would we define that develop is ready to be merged into master? If we would have a magic script that tells us if a branch is stable or even releasable we could apply the same for commits to master in our current setup. Social wise I have also a hard time to see who in our community would actually handle merges from develop to master. Who would test master? Most of the active devs I would expect to stay on develop and on their feature branches. Neglecting master or the release branches as they have no use for it and want to focus on their work. Hotfixes merge into develop and master which makes it easier to ensure we don't forget to backport fixes :). Err, wait. A current hotfix workflow looks like this Report -> fix in master -> backport to release branch with the gitflow model it looks like this: Report -> fix in hotfix branch -> merge hotfix branch to master -> merge hotfix branch to develop. How would that be easier? When you forget the backport you could also forget to merge the hotfix branch into master. Let me know what you think - it's worked quite well in previous groups but I appreciate it may not for us and I expect there are a lot of experiences here that could feed in :) What have these previous groups been? A company or a FOSS project? I just ask because enforcing such strict rules is way easier in a company environment compared to an very old FOSS project with grumpy people from many different backgrounds :) Bottom line: I do not want to shoot this down but I want to see it in use somewhere before I would even think about all the impacts it might have when using it in efl. I also think that we should not try to make such big changes on our biggest and most complicated project (efl) first but try things out elsewhere. 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] Git and branching
On 27/07/17 16:43, Pierre Couderc wrote: > > On 07/26/2017 10:28 PM, Mike Blumenkrantz wrote: >> There are multiple release branches, the latest of which receives >> backports >> for bug fixes only: see >> https://git.enlightenment.org/core/enlightenment.git/refs/ for any branch >> with the format 'enlightenment-0.XX'. >> > I know that. > But are bad bugs backported ? > When I had a problem on 'enlightenment-0.XX' I was told to switch to > master branch. > But maybe it was an isolated problem. > Then you were likely told the wrong thing, every bugfix should go into enlightenment-0.XX, it that doesn't happen let us know and we will make sure it does. -- 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] Git and branching
On 07/27/2017 02:14 AM, Carsten Haitzler (The Rasterman) wrote: i think what you mean is that the method and "process" is there, but enlightenment is not as stable as you would like it to be? is what what you mean? because the model/process is there exactly as you describe. Yes, and I think too that the method is good. So I suppose that the problem I got was isolated. And I know the cost of backport, and the interest to keep structures light. -- 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] Git and branching
On 07/26/2017 10:28 PM, Mike Blumenkrantz wrote: There are multiple release branches, the latest of which receives backports for bug fixes only: see https://git.enlightenment.org/core/enlightenment.git/refs/ for any branch with the format 'enlightenment-0.XX'. I know that. But are bad bugs backported ? When I had a problem on 'enlightenment-0.XX' I was told to switch to master branch. But maybe it was an isolated problem. -- 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
